PL/Iの深淵：FIXED BINARYの精度とメモリ効率が語る「生」のアーキテクチャ
メインフレームの現場で長年PL/Iコードと対峙していると、言語仕様の「自由度」という名の諸刃の剣に何度も翻弄される。特に、`FIXED BINARY`（二進固定小数点数）は、その定義の仕方一つで、システムの処理効率からデータ整合性、さらにはマイグレーション時の致命的なアベンド（ABEND）の温床にまでなり得る。
今回は、この「一見単純だが奥深い」データ型の真実を、基幹システムのアーキテクトの視点から紐解いていこう。
—
1. FIXED BINARYの精度(p)と内部表現の境界線
PL/Iにおいて `FIXED BINARY(p, q)` を定義する際、我々アーキテクトが意識すべきは「コンパイラがこれをどうストレージへマップするか」である。
- p=1 to 15: ハーフワード（2バイト）として扱われる。
- p=16 to 31: フルワード（4バイト）として扱われる。
この境界線は、単なるメモリ消費の問題ではない。もし、あなたがJavaへのマイグレーションを控えたコードを解析しているなら、ここの設計意図を汲み取らなければならない。
/i
DCL COUNTER_S FIXED BINARY(15); / ハーフワード：最大値 32767 /
DCL COUNTER_L FIXED BINARY(31); / フルワード：最大値 2,147,483,647 /
/
注意：p=16を指定した瞬間に、コンパイラはフルワードを割り当てる。
境界値付近での演算で、p=15から16へ変更すると、
アライメント境界が変わるため、既存の構造体のオフセットがズレる。
バイナリ・データの外部ファイル連携時にパニックを起こす原因だ。
/
なぜ「p=31」なのか？
多くのレガシーシステムで `FIXED BINARY(31)` が多用されるのは、IBM z/Architectureの命令セットにおいて、レジスタ操作が最も効率的に行えるサイズだからだ。これをケチって `FIXED BINARY(15)` を多用すると、かえってロード時の拡張命令（`LH` -> `L` 等）が挟まり、CPUサイクルを無駄に浪費することになる。
—
2. 動的メモリ操作とポインタの落とし穴
PL/Iの強力な武器であるポインタ操作。しかし、`FIXED BINARY` が格納された領域を `ADDR()` で指し、別の構造体を重ね書きする（Overlay）ようなテクニックは、現代のコンパイラ最適化（`OPTIMIZE(3)`など）では禁じ手になりつつある。
特にDB2の埋め込みSQLやCICSの通信エリア（COMMAREA）でこの手法を使うと、コンパイラが「値は変更されない」と判断し、レジスタにキャッシュした古い値を使い回すことがある。これによる不可解なバグは、ダンプ解析で最も骨が折れる案件の一つだ。
/i
DCL PTR_DATA POINTER;
DCL BASED_DATA FIXED BINARY(31) BASED(PTR_DATA);
/
ポインタ操作で値を書き換える場合、
コンパイラ最適化によるキャッシュを無効化するために
‘AUTOMATIC’ や ‘DEFINED’ の制約を正しく理解せよ。
最悪の場合、volatileキーワード的な挙動を期待して
コンパイルオプションを調整する必要がある。
/
—
3. 現場で遭遇する「パックデシマル」との暗黙の型変換
FIXED BINARYの話をしていると必ずぶつかるのが、`FIXED DECIMAL`（パックデシマル）との混在だ。特に、COBOLからPL/Iへ移行した古いコードベースでは、計算精度を維持するためにパックデシマルが多用されている。
- 落とし穴: `FIXED BINARY` と `FIXED DECIMAL` を演算すると、PL/Iは一時的に `FIXED DECIMAL` へ変換しようとする。このとき、内部表現が壊れることがある。特に、DB2から取得した値をそのまま演算に回すと、`S0C7`（データ例外）アベンドが頻発する。
解決のヒント:
数値計算を行う際は、一度 `FIXED BINARY` に統一キャストしてから演算させること。また、DB2の値がNULLである可能性を考慮し、標識変数（Indicator）のチェックを怠らないことだ。これをサボると、CICSのオンライン処理でアベンドが連鎖し、トランザクションのバックアウト処理に追われることになる。
—
4. アーキテクトとしての助言：マイグレーションへの備え
JavaやC#等の言語へ移行する場合、最も苦労するのは「PL/Iの予約語がない」という言語仕様と、「柔軟すぎるデータ型」の整合性だ。
1. 暗黙の変換を可視化せよ:
ソースコードの変換ルールを作成する際、`FIXED BINARY(p,q)` の演算を全て `BigDecimal` や `int` へ単純変換してはならない。精度がオーバーフローする可能性をスタティック解析で洗い出すこと。
2. ダンプ解析の心構え:
アベンドが発生した際、ダンプリスト上の16進数を見れば、それが「2の補数（Binary）」なのか「パック（Decimal）」なのかを即座に見分けられるスキルを養え。それは、このレガシーの世界で生き残るための最低限の教養である。
最後に
PL/Iは、機械の挙動を直接制御できる「計算機のための言語」だ。我々が書いているのは、単なるビジネスロジックではなく、ハードウェアと対話するための設計図である。`FIXED BINARY` のたった1ビットの差異が、数千万件のトランザクションの運命を左右する。
その重みを感じながら、今日もまたメインフレームの黒い画面に向き合ってほしい。それが、この過酷で魅力的な世界での、アーキテクトとしての流儀なのだから。
