RULES(LAXCTL) を指定すると、コンパイラーは、速度が大きく低下し、 より時間のかかるコードをより多く生成する可能性があります。
ある大規模な顧客のプログラムの場合には、このオプションにより、 コンパイル時間を 40%、ランタイムを 50% 削減しました。
このオプションを理解するために、 次の宣言を考えてみましょう。
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 */
VTAB の境界は、明らかにコンパイル時には不明です。 しかし、WA0104K の長さは本当に 1 でしょうか ? この構造体は通常、次に示す 2 つのステートメントのいずれかのような ステートメントによって割り振られます。
ALLOC VTAB( 100 ); ALLOC VTAB( N + M );
このいずれかの割り振りの後で、WA0104K の長さは 1 に なります。
しかし、この構造体は次のように割り振られている可能性もあります。
ALLOC
1 VTAB(17),
2 WA0102,
2 WA0140I,
2 WA0104K CHAR(29);
この場合、WA0104K の長さは 29 になってしまいます。
コンパイラー・オプション RULES(LAXCTL) を指定すると、 ストリングに対して最初に宣言された長さが定数であったにもかかわらず、 上記に示したような割り振りが許可されます。 ただし、このオプションを指定すると、コンパイラーははるかに長いコード・シーケンスを 生成するようになります。
これとは対照的に、コンパイラー・オプション RULES(NOLAXCTL) は、定数として 宣言されたすべての長さおよび境界が実際に定数であることを 想定します。この想定に反する すべての ALLOCATE ステートメントは、S レベルのメッセージ IBM2063 を発行して フラグを立てられます。
したがって、このオプションを使用すると、ランタイムに 発生する問題が除去され、コンパイル時にもランタイムにも、 はるかに優れたパフォーマンスが得られます。