FIXED BINARYの深淵：(15)と(31)が引き起こす「見えない地雷」
メインフレームの心臓部で鼓動するPL/I。その堅牢性は、コンパイラが生成する機械語の精緻さと、プログラマが意図したデータ型の制約から生まれます。しかし、多くの移行プロジェクトで「Javaにはない挙動」としてエンジニアを悩ませるのが、`FIXED BINARY`（以下、BIN）の精度指定と、それが引き起こす演算時のオーバーフローです。
今日は、特に`BIN(15)`と`BIN(31)`の内部表現と、それが現代のマイグレーション設計にどう牙を剥くかを紐解いていきましょう。
1. 内部表現の「差」がもたらす悲劇
まず、メモリレイアウトを理解してください。`BIN(15)`はハーフワード（2バイト）、`BIN(31)`はフルワード（4バイト）を占有します。
- BIN(15): 符号付で -32,768 ～ 32,767。
- BIN(31): 符号付で -2,147,483,648 ～ 2,147,483,647。
ここで注意すべきは、演算時のコンパイラ挙動です。PL/Iは、異なる精度のデータが混在する演算において、値を一時的に高精度側に昇格させて計算します。しかし、計算結果を元の`BIN(15)`変数に戻す際に、格納先が許容範囲を超えていれば、待っているのは`S0C7`ではなく、静かなるデータ破壊、あるいは`Fixed-point overflow`によるアベンド（ABEND）です。
/i
DCL A FIXED BIN(15) INIT(30000);
DCL B FIXED BIN(15) INIT(5000);
DCL C FIXED BIN(15);
/ ここでCには35000が入るべきだが、範囲外のためオーバーフロー発生 /
/ コンパイラオプションでLIMITS(FIXEDBIN(15))を指定していない場合、
実行時に予期せぬ結果や例外となる /
C = A + B;
2. コンパイラ最適化とエッジケースの罠
現場で最も恐ろしいのは、「テスト環境では動いていたのに、本番の特定データでのみ落ちる」という現象です。
コンパイラオプションの`OPTIMIZE(2|3)`を付与すると、計算の過程で中間レジスタのみで演算を行い、メモリへの書き戻しを最小化します。この際、`BIN(15)`と`BIN(31)`が混在した式では、中間結果が`BIN(31)`の精度で保持されますが、最終代入時に`BIN(15)`の制約が適用されることで、稀に意図しない切り捨てが発生することがあります。
特に、組み込みSQL（DB2）との連携では注意が必要です。DB2の`SMALLINT`（2バイト）とPL/Iの`BIN(15)`はマッピング上は一致しますが、DB2側から戻り値として`NULL`や範囲外の値が返された場合、PL/I側で`FIXEDOVERFLOW`条件が有効になっていなければ、後続のプログラムが「汚染されたデータ」で走り続けることになります。
3. ポインタ操作による動的メモリ管理の「暗黒面」
レガシーなバッチ処理で、`BASED`変数を使用して動的に配列を確保するケースがあるでしょう。ここで`BIN(31)`のポインタ（`PTR`）を誤って`BIN(15)`で計算してオフセットを求めようとするコードを見かけますが、これは即座にメモリアクセス違反（`S0C4`）への直行便です。
/i
DCL BUFFER CHAR(1024) BASED(P);
DCL P PTR;
DCL OFFSET FIXED BIN(31);
/ 31bitのフルアドレス空間を考慮しないオフセット計算は致命的 /
P = ADDR(BASE_AREA) + OFFSET;
マイグレーション先がJava等のオブジェクト指向言語である場合、メモリモデルが「ガベージコレクション付きの安全なヒープ」に変わります。PL/I時代の「ポインタ計算によるオフセットずらし」というテクニックは、移行時に完全に書き換える必要があり、ここでのロジックの汲み取りミスが最大のリスクとなります。
4. 現場のテックリードへ：移行設計の指針
システム移行において、私が推奨するのは以下のステップです。
1. コンパイラオプションの可視化: 既存の全ソースの`LIMITS`オプションを確認してください。`FIXEDOVERFLOW`を意図的に無効にしているコードがあれば、そこには必ず「隠れたバグ」が眠っています。
2. パックデシマルとの混在: `FIXED DECIMAL`と`FIXED BINARY`を演算で混ぜることは避けなさい。内部で`BINARY`への変換ルーチンが走り、精度落ちが発生します。特に符号の反転バグは、この変換過程での`Decimal to Binary`変換の失敗に起因することが多いのです。
3. ABENDダンプの解析: SYSUDUMPから、演算直前のレジスタ値を追いかける癖をつけてください。高位16ビットがクリアされていない`BIN(15)`値が、そのまま`BIN(31)`として扱われていないかを確認する。これだけで、解析時間は半分になります。
結びとして
PL/Iの`FIXED BINARY`を使いこなすということは、計算機が扱う「有限の箱」を掌の上で制御するということです。現代の言語はメモリ消費を隠蔽してくれますが、基幹システムのアーキテクトであれば、その裏で何が起きているのかを常に想像し続けてください。
「正しく動いている」ことと「正しく設計されている」ことは別物です。次回のマイグレーション設計時には、ぜひソースコードの背後に潜むこの「精度の境界線」に目を向けてみてください。それが、次の10年も止まらない堅牢なシステムを構築するための唯一の道です。
