汎用機アーキテクチャの深層：PL/I `FIXED BINARY` の内部表現と精度制約、そしてモダナイゼーションの罠
基幹システムの現場で長年生き抜いてきたシニアアーキテクトであれば、夜間バッチの最中に突如発生した `ASRA`（CICSの場合）や、ジョブステップ異常終了のＳＤＵＭＰ（System Dump）を前に、固唾を飲んでPSWとレジスタを睨みつけた経験が一度や二度ではないはずだ。
PL/I（Programming Language One）は、その自由度の高さと強力なデータ制御能力ゆえに、IBMメインフレーム（z/OS）の心臓部で数十年もの間、ミッションクリティカルな処理を支え続けてきた。しかし、その「何でも書ける」言語仕様の裏側には、ハードウェアのアーキテクチャやコンパイラの挙動を熟知していなければ踏み抜くことになる「地雷」がいくつも埋まっている。
今回は、その中でも特に数値演算の根幹をなす `FIXED BINARY`（固定小数点2進数）の内部表現と精度（Precision: P, Q）の制約 について、コンパイラの最適化、動的メモリ操作、さらにはJavaやC#へのマイグレーション（レガシー移行）の現場で直面する致命的なエッジケースに至るまで、徹底的に掘り下げて解説しよう。
—
1. `FIXED BINARY` の内部表現と精度（P, Q）の深淵
PL/Iにおける `FIXED BINARY(P, [Q])` は、IBMメインフレームのCPU（System z）が最も得意とする2進整数演算（2の補数表現）を直接マッピングするデータ型である。
ここで重要なのは、宣言時に指定する `P`（全体のビット数、符号ビットを含む）と `Q`（小数点位置、スケーリングファクター）が、コンパイラによってどのようにメモリ上に切り出され、ハードウェア命令に変換されるかという点だ。
精度 `P` の物理的制約とハーフワード、フルワード、ダブルワード
- `P` が 1 から 15 の場合：
コンパイラはこれを 2バイト（16ビット、H`HALFWORD`）の領域として割り当て、マシン語の `AH`（Add Halfword）や `LH`（Load Halfword）などの命令を生成する。
- `P` が 16 から 31 の場合：
4バイト（32ビット、F`FULLWORD`）の領域となり、`A`（Add）や `L`（Load）などのフルワード命令が適用される。
- `P` が 32 から 63 の場合：
8バイト（64ビット、D`DOUBLEWORD`）の領域となり、64ビットレジスタ演算（`AG` や `LG` など）が駆使される。
ここで現場のエンジニアが陥りがちな罠が、「予約語を持たないPL/Iの構文規則」 とコンパイラオプションによる精度のデフォルト値の差異である。
Enterprise PL/I コンパイラでは、コンパイル時オプションとして `RULES(NOLONGDCL)` や `DEFAULT(BIN(15))` あるいは `DEFAULT(BIN(31))` を指定できる。もしソースコード内で単に `DECLARE X FIXED BIN;` とだけ記述した場合、このコンパイラオプションのデフォルト設定によって、`X` が `FIXED BIN(15)` になるか `FIXED BIN(31)` になるかが変わってくる。
レガシーなソースコードをそのまま別の環境（あるいは別コンパイラの世代）に持っていった際、この暗黙のデフォルト精度の違いによって、算術演算のオーバーフロー挙動や、後述する埋め込みSQL（DB2）とのインターフェースで予期せぬデータ切り捨て・型不一致エラー（SQLCODE -305 や -403 など）を引き起こす主因となる。
—
2. オーバーフロー発生時のハードウェア例外とON条件の罠
`FIXED BINARY` で最も恐ろしいのは、変数の表現し得る数値範囲を超えた値が格納された際の挙動だ。
パックデシマル（`FIXED DECIMAL`）であれば、コンパイルオプションやデバッグ機能によって厳密なデータチェックが行われることが多いが、`FIXED BINARY` はハードウェアのレジスタ演算に直結しているため、オーバーフローが発生した瞬間にプログラムチェック（通常はオペレーティングシステムによる異常終了、システムコード `0C7` や `0C1` ではなく、演算例外を示す `0C8` や、あるいは単なる上位ビットの桁あふれによるサイレントな値の破損）を引き起こす。
PL/Iには、これを捕捉するための `ON FIXEDOVERFLOW` 条件処理が用意されている。
1
/ FIXED BINARYのオーバーフロー制御と動的制御のサンプル /
TEST_OVF: PROC OPTIONS(MAIN);
DCL WS_COUNTER FIXED BIN(15) INIT(32767); / 16ビット符号付き2進数の最大値 /
DCL WS_RESULT FIXED BIN(15);
/ オーバーフロー割り込みの捕捉設定 /
ON FIXEDOVERFLOW
BEGIN;
PUT SKIP LIST(‘ 警告: FIXED BINARY オーバーフローを検出し補正します ‘);
/ ここで代替処理やログ出力を行う /
WS_RESULT = 0;
GOTO OVERFLOW_RECOVERY;
END;
PUT SKIP LIST(‘演算前の値:’, WS_COUNTER);
/ 意図的なオーバーフローの発生（32767 + 1） /
WS_RESULT = WS_COUNTER + 1;
PUT SKIP LIST(‘この行はオーバーフロー発生によりスキップされます:’, WS_RESULT);
OVERFLOW_RECOVERY:
PUT SKIP LIST(‘リカバリー処理後の値:’, WS_RESULT);
END TEST_OVF;
このコードを実行すると、`WS_COUNTER + 1` の瞬間にハードウェアがオーバーフローを検知し、PL/Iのランタイムライブラリを介して `ON FIXEDOVERFLOW` ブロックへと制御がジャンプする。
しかし、高頻度で実行されるバッチ処理の内部でこの `ON` ユニットを乱用すると、ランタイムのオーバヘッドによって処理性能が致命的に劣化する。シニアアーキテクトであれば、例外処理に頼るのではなく、演算前の範囲チェックロジックを事前に記述するか、あるいは適切な精度（例えば `FIXED BIN(31)` への拡張）を設計段階で担保すべきであることは言うまでもない。
—
3. ベース変数（BASED）とポインタ（POINTER）による動的メモリ操作のエッジケース
メインフレームの限界領域（24ビットアドレッシングから31ビット、そしてAMODE(64)の世界）において、大量のレコードを効率的に処理するため、PL/Iの `BASED` 変数と `POINTER` を用いた動的ストレージ操作は不可欠のテクニックである。
しかし、ここで `FIXED BINARY` の精度やアライメント（境界調整）を誤ると、S0C4（Protection Exception） や S0C6（Specification Exception） という、プログラマの精神を抉るアベンドダンプの餌食になる。
System z のアーキテクチャでは、2バイトの整数（Halfword）は偶数アドレスに、4バイトの整数（Fullword）は4の倍数のアドレスに配置されていなければならない（アライメント制約）。もし `ADDR()` ビルトイン関数などで取得した不自然な奇数アドレスをポインタに設定し、そこに `FIXED BIN(31)` のベース変数をマップして参照しようものなら、容赦なく `0C6` アベンドが発生する。
1
/ ベース変数とポインタを用いた動的ストレージ操作の例 /
DEMO_BASED: PROC OPTIONS(MAIN);
DCL 1 DUMMY_AREA UNALIGNED,
2 PADDING CHAR(1), / 奇数アドレスを意図的に作り出すためのダミー /
2 TARGET_BIN FIXED BIN(31); / アライメント違反を引き起こす可能性がある構造 /
DCL MY_PTR POINTER;
DCL MAPPED_DATA FIXED BIN(31) BASED(MY_PTR);
/ 意図的に未調整のアドレスを指すポインタを作成 /
MY_PTR = ADDR(TARGET_BIN);
/ 注意: UNALIGNED指定がない場合、FULLWORD境界に強制されないため
ハードウェアアーキテクチャによっては演算時に例外が発生するリスクがある /
PUT SKIP LIST(‘ポインタアドレス取得完了’);
END DEMO_BASED;
特に、CICSの通信領域（`COMMAREA`）や外部から渡されたストレージを `BASED` 変数でオーバーレイして解析する際、データのパディング（余白）や `UNALIGNED` 属性の有無を見落とすと、フィールドのズレによる大惨事を引き起こす。マイグレーション時には、このメモリの物理レイアウトの差異がバグの温床となる。
—
4. モダナイゼーション（Java/C#移行）における致命的な差異
現在、多くの企業がレガシーシステムのオープン化・クラウド移行を進めている。PL/Iで書かれた基幹システムを Java や C# にリライト、あるいは自動マイグレーションする際、この `FIXED BINARY` の仕様の違いは最も警戒すべきポイントの一つである。
① 符号なし（UNSIGNED）の概念の欠如と拡張
PL/Iでは `FIXED BINARY(15) UNSIGNED` のように、符号を持たない純粋な2進数を定義できる。これにより、16ビットをフルに使い `0` から `65535` までを表現可能だ。
しかし、Javaの基本データ型（`short`, `int`, `long`）はすべて符号付き（2の補数）である。Java 8以降では `Short.toUnsignedInt()` などのAPIでカバーできるものの、自動マイグレーションツールがこの差異を見落とし、Javaの `short`（-32768 ～ 32767）にそのままマッピングしてしまった結果、上位ビットが立ったデータを読み込んだ瞬間に負の値に反転し、業務ロジックが崩壊するバグが後を絶たない。
② パックデシマル（`FIXED DECIMAL`）との暗黙の型変換バグ
PL/Iでは、`FIXED BINARY` と `FIXED DECIMAL`（パックデシマル）の間で、コンパイラが自動的に型変換（COBOLにおける `COMP` と `COMP-3` の混在のようなもの）を行う。
この変換の際、小数点以下のスケーリングや四捨五入（ROUNDビルトイン関数の有無）の挙動が、Javaの `BigDecimal` の丸めモード（`RoundingMode`）のデフォルト挙動と完全に一致しているとは限らない。金銭計算や金利計算のモダナイゼーションにおいて、このわずか「1円のズレ」が、監査における致命的な指摘事項となる。
—
5. シニアアーキテクトからの提言：移行と保守の現場で守るべき鉄則
PL/Iの `FIXED BINARY` を含むデータ制御のコードを保守し、あるいは安全にモダナイズするための指針を最後に残しておこう。
1. 暗黙の定義に頼らない：
`DECLARE` 文においては、単なる `FIXED BIN` ではなく、必ず `FIXED BIN(15)` や `FIXED BIN(31)` のようにビット数を明示し、さらに `ALIGNED` または `UNALIGNED` を意識的に指定せよ。コンパイラオプションへの依存は、環境移行時のリスクを増大させるだけである。
2. ストレージ・オーバーレイの排除：
`BASED` 変数や不条理な `UNIONS` 的使い方によるメモリの直接ハッキングは、現代の安全なソフトウェア工学の観点からは負債でしかない。マイグレーションを視野に入れるならば、構造体を明確に定義し、セマンティクスに基づいたデータ構造へリファクタリングする勇気を持て。
3. 境界値テストの徹底：
`FIXED BINARY(15)` の限界値（32767, -32768）および `FIXED BIN(31)` の限界値（2147483647）周辺における境界値テストケースを必ず網羅せよ。例外処理（ON条件）の挙動も含めて、移行先の言語（Java/C#の例外機構）で完全に同等な振る舞いをするか検証することが、移行プロジェクトの成否を分ける。
レガシーシステムの深部にあるコードは、当時のハードウェア制約とエンジニアの知恵が凝縮された芸術品でもある。その仕様の本質を正確に理解した者だけが、次の時代へとシステムを安全に導くことができるのだ。
