Using RULES(LAXCTL) can significantly slow the compiler and cause it to generate more copious and more time-consuming code
For one large customer program, this reduced the compile-time by 40% and run-time by 50%.
To understand this option, consider the following declaration:
DCL 01 VTAB(*) CTL, /* VALOREN-TABLE */ 02 WA0102 CHAR(26), /* MUTATIONSDATUM DB2-TIMESTAMP */ 02 WA0104I BIN FIXED(31), /* PKEY AKTIONSNR-ID: */ 02 WA0104K CHAR(1), /* PKEY VALOREN-KNZ: */ 02 WA0104V DEC FIXED(15,0), /* PKEY VALORENNR */ 02 WA0104L BIN FIXED(15), /* PKEY VV_SEG_LFNR */ 02 WA0104A CHAR(4); /* PKEY TERM_ID */
The bounds of VTAB are clearly not known at compile-time. But is the length of WA0104K really 1 ? The structure would normally be allocated with a statement like one of the following two statements:
ALLOC VTAB( 100 ); ALLOC VTAB( N + M );
After either of these allocations, WA0104K would have length 1.
But the structure could be allocated as follows:
ALLOC
1 VTAB(17),
2 WA0102,
2 WA0140I,
2 WA0104K CHAR(29);
But then WA0104K has length 29 !
The compiler option RULES(LAXCTL) permits allocations such as the one immediately above despite the fact that the original declared length for the string was a constant. However, using this option will also force the compiler to generate much longer code sequences.
In contrast, the compiler option RULES(NOLAXCTL) assumes that all lengths and bounds that are declared as constant are, in fact, constants. - and any ALLOCATE statement that violated this assumption will be flagged with an S-level message IBM2063.
Consequently, using this option will not leave you with any run-time surprises, and it will give you much better performance, both at compile-time and at run-time.