汎用機の深淵：FIXED BINARYの挙動と、モダナイゼーションにおける「見えない地雷」
メインフレームの現場で長く生きていると、ふとした瞬間に「なぜこんな挙動をするのか」という壁に突き当たることがある。特に、PL/Iという言語は、その極めて柔軟な言語仕様ゆえに、安易なコードが後に巨大な技術的負債となる典型例だ。
今日は、システムアーキテクトとして避けては通れない、`FIXED BINARY(15)`と`(31)`の内部表現、そしてそれが現代的なJavaやC#への移行時にどのような「負の遺産」として牙を剥くのかを深掘りする。
1. FIXED BINARYのメモリレイアウトと内部表現の真実
まず、PL/Iにおいて`FIXED BINARY`は単なる数値型ではない。それは、マシン（z/Architecture）のレジスタ操作と直結した、極めて物理に近い存在だ。
- FIXED BINARY(15): 2バイト（ハーフワード）符号付き整数。値の範囲は -32,768 ～ +32,767。
- FIXED BINARY(31): 4バイト（フルワード）符号付き整数。値の範囲は -2,147,483,648 ～ +2,147,483,647。
ここで重要なのは、コンパイラがこれをどのようにアラインメントするかだ。`ALIGNED`を指定した場合、これらはワード境界に配置されるが、`UNALIGNED`を指定するとメモリ密度は上がる一方で、CPUのロード・ストア命令の効率は低下する。
DCL VAR1 FIXED BIN(15) ALIGNED; / 2バイト境界に配置 /
DCL VAR2 FIXED BIN(31) UNALIGNED; / 1バイト境界に配置、メモリ節約だがアクセス速度にペナルティ /
移行設計において、この`UNALIGNED`指定は要注意だ。x86系やARM系のプロセッサではアラインメント違反で例外が発生したり、極端な速度低下を招く。マイグレーション先の言語で型を定義する際、この「詰め物」の構造を正確に再現しなければ、構造体（`BASED`変数）を用いた動的なバッファ操作で致命的なオフセットズレが生じる。
2. ON FIXEDOVERFLOW：沈黙の破壊者
多くの若手エンジニアが誤解しているのが、`FIXEDOVERFLOW`の挙動だ。PL/Iプログラムで計算結果が精度を超えた際、デフォルトでは`SIGNAL`が発生し、OSレベルのABEND（S0C1やS0C7に近い深刻な事態）へと直結する。
ON FIXEDOVERFLOW BEGIN;
PUT SKIP LIST(‘オーバーフロー発生：論理ミスを検知’);
/ ここでログを出して安全に終了するか、値をクランプするかの判断が分かれる /
STOP;
END;
/ 下記の演算はFIXED BIN(15)の限界を超えるため、上記ONブロックが発火する /
DCL A FIXED BIN(15) INIT(30000);
A = A + 5000;
アーキテクトの視点：
実務上の問題は、このオーバーフローが「サイレントに発生している」ケースだ。コンパイラオプションの`NOFIXEDOVERFLOW`を指定していると、チェックがスキップされ、上位ビットが切り捨てられた状態で後続のSQL処理へ流れていく。これがDB2の制約違反や、CICSの予期せぬトランザクション異常の温床となる。
3. 移行設計の現場：パックデシマルとの混在による地雷
PL/Iの真に厄介な点は、`FIXED BINARY`と`FIXED DECIMAL`（いわゆるパックデシマル）が混在する算術演算だ。
コンパイラは、演算時にこれらを「より安全な型」へと暗黙的に昇格させる。しかし、この昇格ルールは複雑怪奇だ。特に、内部表現としてのパックデシマルの符号（最後のニブル）が`0x0C`（正）や`0x0D`（負）であるべきところ、データ破損や不正なパッチ作業により`0x0F`（符号なし）として読み込まれた場合、`FIXED BINARY`への変換過程で予期せぬ例外が発生する。
Javaへの移行時には：
Javaの`int`型は常に4バイト符号付き整数だ。PL/Iの`FIXED BIN(15)`から移行する場合、単純に`short`へマッピングして安心していてはならない。オーバーフローのチェックを、Java側で明示的に`try-catch`あるいはチェック演算を行うロジックに置き換える必要がある。
4. ダンプ解析の勘所
ABEND発生時、ダンプリストを眺める際に最も重要なのは、`FIXED BIN(31)`の値がレジスタのどの位置に格納されているかを確認することだ。
- `S0C7`（データ例外）の場合は、パックデシマルのフォーマットを確認せよ。
- `S0C9`（固定小数点除算例外）の場合は、除数が0になっていないか、あるいは計算結果が`FIXED BIN(31)`の範囲を逸脱していないかを確認せよ。
特に、`BASED`変数とポインタを駆使した動的なメモリ操作を行っている箇所では、ポインタの指し示すアドレスが境界を跨いでいないか、あるいはアセンブラルーチンとの境界で型変換が正しく行われているかを、バイナリダンプと突き合わせて検証する必要がある。
最後に：レガシーを「言語化」する責任
PL/Iが持つ「予約語を持たない（文脈で意味が決まる）」という自由奔放さは、確かに強力だが、現代の厳格な型安全性を求める開発者にとっては理解不能な闇だ。
もしあなたが今、これらのコードを解読し、マイグレーションを主導しているなら、単にコードを変換するのではなく、「なぜその精度で、なぜその型が必要だったのか」というビジネス上の意図を読み解いてほしい。その先にこそ、真のメインフレームアーキテクトとしての価値がある。
何か具体的なコードの挙動や、特定のコンパイラオプション（`OPT(3)`など）による最適化の副作用で悩んでいるなら、いつでも深淵の向こう側を覗きにいこう。現場の知見は、マニュアルの行間にあるものだ。
