現場のPL/I職人が語る：FIXED BIN(15)と(31)がバッチ性能に与える「意外な」影響
メインフレームの現場で何十年とバッチ処理を見守っていると、「なぜこの変数は15なのか、31なのか」という些細な選択が、数百万件のレコードを処理する深夜のジョブで無視できない差を生むことに気づかされます。
今回は、PL/Iにおける`FIXED BINARY(15)`（ハーフワード）と`(31)`（フルワード）の使い分けについて、CPU命令セットの裏側と、実務でハマりやすい罠を深掘りします。
—
なぜ(15)と(31)で「速さ」が違うのか
結論から言えば、IBM z/Architectureにおいてフルワード（31ビット/4バイト）の演算は、CPUにとって最も「自然」かつ高速な領域です。
- FIXED BIN(31): 32ビットの汎用レジスタにそのまま収まるため、`A`（加算）や`L`（ロード）命令一つで処理が完結します。
- FIXED BIN(15): 16ビットのデータですが、演算時には一度レジスタ内で拡張（符号付き拡張）されるか、あるいはハーフワード専用の命令（`AH`等）が走ります。
現代のCPUではその差は縮まっていますが、VSAMファイルを大量に読み込み、複雑な加算を繰り返すようなループ処理では、31ビットに統一しておくほうがコンパイラの最適化も利きやすく、命令セットの無駄がありません。
現場で遭遇する「オーバーフロー」という落とし穴
「メモリを節約したいから」という理由で、カウンターに`(15)`を使い、痛い目を見るエンジニアを何人も見てきました。`FIXED BIN(15)`の最大値は32,767。これを超えた瞬間に`FIXEDOVERFLOW`のONユニットが発火します。
もし、ONユニットで`SYSTEM`や`SNAP`を指定していれば、ジョブは即座に異常終了（U4038など）です。特に、件数が数万件を超える集計バッチでは、`(15)`は地雷になり得ます。
実践的コーディング例：安全なデータ定義とデバッグ
以下は、レコード処理における推奨される書き方です。パフォーマンスと安全性を両立させるためのテンプレートとして活用してください。
1
/ ————————————————————- /
/ レコード処理用データ定義のベストプラクティス /
/ ————————————————————- /
DCL 1 WS_REC_COUNT,
3 TOTAL_READ FIXED BIN(31) INIT(0), / カウンターは迷わず(31) /
3 ERR_CODE FIXED BIN(15) INIT(0); / 状態フラグは(15)で十分 /
DCL ONCODE BUILTIN;
/ オーバーフロー制御：本番環境での安全策 /
ON FIXEDOVERFLOW BEGIN;
PUT SKIP LIST(‘WARNING: 演算オーバーフローが発生しました。’);
PUT SKIP LIST(‘ONCODE値:’, ONCODE);
SIGNAL ERROR; / 意図的な異常終了でログを保護 /
END;
/ ————————————————————- /
/ VSAM読み込みループの例 /
/ ————————————————————- /
DO WHILE (VSAM_EOF = ‘0’B);
READ FILE(INPUT_FILE) INTO(REC_BUFFER);
/ 31ビット演算はCPU効率が最適 /
WS_REC_COUNT.TOTAL_READ = WS_REC_COUNT.TOTAL_READ + 1;
/ 複雑な条件判定 /
IF REC_TYPE = ‘A’ THEN DO;
/ 処理ロジック /
END;
END;
スペシャリストからのアドバイス：どう使い分けるべきか
1. カウンター・インデックス:
基本は`FIXED BIN(31)`です。メモリ数バイトの節約のために性能リスクを冒す必要はありません。現代のメインフレームでメモリ不足に陥る原因の多くは、変数のサイズではなく、不適切な配列の持ち方やバッファ戦略にあります。
2. フラグ・小規模なステータス:
`0`か`1`、あるいは数パターン程度のフラグであれば`FIXED BIN(15)`で十分です。また、これらを構造体の中で連続して定義することで、境界調整（アライメント）を意識した効率的なメモリレイアウトが期待できます。
3. VSAMのキーフィールド:
これだけは別格です。VSAMのキー定義とプログラム側の変数が型不一致を起こすと、コンパイラが暗黙の変換コードを生成し、ループのたびに変換コストが発生します。必ず定義書と突き合わせ、型を完全に一致させてください。
最後に：PL/Iは「直感」よりも「仕様」を信じろ
PL/Iは非常に柔軟な言語ですが、その柔軟さが仇となり、意図しないデータ変換（DecimalとBinaryの混在など）を隠蔽してしまうことがあります。`FIXED BIN(15)`と`(31)`の選択もその一つです。
「たかが整数」と思わず、計算の規模を予測し、最も安全で、かつCPUが最も好む型を選択する。こうした細部の積み重ねが、何年経っても「落ちない」「速い」と言われる基幹バッチを支えるのです。
もし、既存の古いプログラムで`(15)`が多用されている箇所を見つけたら、まずはその範囲でオーバーフローの可能性がないか検証することから始めてみてください。それが、レガシーシステムの品質を守る第一歩です。
