メインフレームの深淵：FIXED BINARY(15)と(31)が支配する演算効率の最適化
基幹システムのコードベースを紐解くと、そこに刻まれた `FIXED BINARY` の定義一つひとつに、当時のアーキテクトが込めた「意図」が見えてくる。現代のJavaやC#の `int` や `short` を見慣れた世代には、PL/Iの `FIXED BINARY(15)` と `(31)` の使い分けは単なる型指定に見えるかもしれない。しかし、z/ArchitectureのCPUレジスタとコンパイラの挙動を熟知している我々にとって、これは「性能」と「信頼性」を左右する最前線の攻防なのだ。
1. ハーフワード(15)とフルワード(31)の境界線
まず、基本を押さえよう。`FIXED BINARY(15)` は2バイト（ハーフワード）、`(31)` は4バイト（フルワード）を占有する。
- FIXED BINARY(15): 符号付き16bit。範囲は -32,768 ～ 32,767。
- FIXED BINARY(31): 符号付き32bit。範囲は -2,147,483,648 ～ 2,147,483,647。
ここで重要なのは、コンパイラが生成する機械語の挙動だ。`FIXED BINARY(15)` を演算する際、システムは内部的に一度フルワードレジスタにロードし、演算後に再度ハーフワードへ切り詰める処理を走らせることがある。もしプログラム内で頻繁に計算を行うなら、`(15)` をわざわざ使うよりも、CPUのネイティブなワードサイズである `(31)` を選ぶ方が、ロード命令のオーバーヘッドが減り、パイプライン効率が向上する場合が往々にしてある。
/i
/ パフォーマンスの観点からの定義例 /
DCL COUNTER_15 FIXED BIN(15) INIT(0); / 境界が厳格な領域なら15で十分 /
DCL COUNTER_31 FIXED BIN(31) INIT(0); / 演算頻度が高いカウンタは31が有利 /
/ 15ビット型は、演算のたびに符号拡張や切り捨て命令が発生する可能性がある /
COUNTER_15 = COUNTER_15 + 1;
2. オーバーフローの罠：ABEND発生時の解析手法
`FIXED BINARY` で最も恐ろしいのは、計算結果が型の上限を超えた際のサイレントな切り捨てや、意図せぬアベンド（S0C7やS0C9）だ。特にマイグレーション時、PL/Iの `SIZE` 条件が `OFF` に設定されている環境から、厳格なチェックを強いる環境へ移行する場合、既存のレガシーコードがいきなり吹き飛ぶことがある。
ダンプ解析の際、`PSW`（プログラム状態語）が指し示す命令が `CVB`（Convert to Binary）や `AR`（Add Register）で停止している場合、まず疑うべきはデータ型の不整合だ。特に、COBOLから移行された `COMP-3`（パックデシマル）を `FIXED BIN` にキャストする際に符号ビットが反転し、予期せぬ巨大な値や負の値に化けるケースには注意が必要だ。
3. 動的メモリ操作とポインタの活用
PL/Iが持つ真の柔軟性は、`BASED` 変数と `POINTER` にある。大規模なバッチ処理において、バッファを動的に確保し、そこへ構造体をマッピングする手法は、今なお現役のアーキテクチャである。
/i
/ 動的領域の確保とポインタによる制御 /
DCL BUFFER_PTR POINTER;
DCL MY_DATA CHAR(100) BASED(BUFFER_PTR);
/ ストレージの確保 /
ALLOCATE MY_DATA;
/ 注意: ポインタ操作はメモリ破壊の温床となる。
特にDB2のFETCHバッファとして使う場合は、
行サイズと型定義の厳密な同期が不可欠。/
4. マイグレーションにおけるエッジケース対策
JavaやC#への移行を検討する際、最も頭を抱えるのが「PL/Iの暗黙的な型変換」だ。PL/Iは非常に寛容であり、異なる精度を持つ `FIXED BIN` 同士の演算でも、コンパイラが気を利かせて（あるいは余計なことをして）内部的な変換を行う。
- DB2埋め込みSQLの罠: `DECIMAL` 型がDB2から返される際、PL/I側で受け取る変数の精度が少しでも異なると、実行時にコード変換エラーが発生する。
- CICSオンライン: 共有ストレージ（TWA/CWA）へアクセスする際、ポインタのオフセット計算を `FIXED BIN(31)` で行わないと、アドレス空間の境界を越えてセグメンテーション違反を引き起こす。
結論：レガシーを「理解」して「超える」
PL/Iのコードを読み解くことは、コンピュータの歴史そのものを読み解くことと同義だ。`FIXED BINARY(15)` か `(31)` か、その小さな選択一つが、メインフレームの限られたリソースをいかに効率的に使い切るかという、職人芸的なこだわりを物語っている。
移行を担当するアーキテクト諸君。コードを単なる文字列としてJavaへ「変換」するのではなく、その裏にある「なぜそのデータ型が選ばれたのか」という意図を再構築してほしい。それができれば、移行先のモダンな環境でも、メインフレームが誇った堅牢性とパフォーマンスを再現できるはずだ。
システムは、書かれた通りに動くのではない。アーキテクトが設計した通りに、魂が吹き込まれて動くのである。
