浮動小数点の深淵：PL/IにおけるFLOAT BINARYとDECIMALの「食い違い」を解く
メインフレームの現場で長年生きていると、ふとした瞬間に「なぜこんな挙動をするのか」という壁に突き当たることがある。特に、浮動小数点数の扱いは、レガシー移行の最前線で設計者が最も頭を抱えるポイントの一つだ。
PL/Iの美学は、その自由度にある。予約語という概念を極限まで排除した構文規則は、初心者には悪夢だが、我々のようなアーキテクトにとっては、コンパイラを飼いならすための強力な武器となる。今日は、`FLOAT BINARY`と`FLOAT DECIMAL`の深淵に触れつつ、マイグレーション時に絶対に踏んではいけない地雷について語ろう。
—
1. IEEE 754 vs IBM形式：計算精度の亡霊
まず理解しておくべきは、PL/Iがターゲットとするハードウェアの歴史だ。古いS/370アーキテクチャ由来の「IBM形式（16進浮動小数点）」と、現代の標準である「IEEE 754（2進浮動小数点）」の間には、単なるビット表現の違い以上の隔たりがある。
- IBM形式: 16進数ベースのため、計算の「丸め」の特性が独特だ。
- IEEE 754: 現代のJavaやC#が採用している形式。
移行プロジェクトで最も多いトラブルは、「これまでメインフレームで計算していた中間値が、移行先のJava環境で微妙にズレる（誤差が累積する）」という現象だ。これはバグではなく、ハードウェアの浮動小数点ユニット（FPU）が処理する精度の定義そのものが異なることに起因する。
ストレージ消費量と精度指定
`FLOAT BINARY(21)`のような宣言を見たとき、コンパイラはこれを単精度(4バイト)で扱うか、倍精度(8バイト)で扱うかを決定する。
/i
DCL A FLOAT BINARY(21); / 単精度(SHORT) 4バイト /
DCL B FLOAT BINARY(53); / 倍精度(LONG) 8バイト /
安易に精度を上げれば良いというものではない。CICS上のオンライン処理でこれらの変数を大量にスタックに積めば、メモリオーバーフローやパフォーマンス劣化を招く。特に、パックデシマル(`FIXED DECIMAL`)から浮動小数点へのキャストが発生する箇所では、コンパイラが暗黙の変換ルーチンを挿入する。この時、パックデシマルの内部符号（例えば負数の’D’や’C’）が正しく認識されず、予期せぬアベンド（S0C7）を引き起こすケースが多発する。
—
2. 実務の現場から：ポインタと動的メモリ操作の危険な遊戯
PL/Iの真骨頂は、`BASED`変数とポインタを用いたメモリ操作だ。しかし、ここには「型」という安全装置が存在しない。
/i
DCL PTR POINTER;
DCL MY_FLOAT FLOAT BINARY(53) BASED(PTR);
/ 外部から取得したメモリ領域を浮動小数点として強引にマッピング /
PTR = ADDR(STORAGE_AREA);
/ ここで型変換ミスがあれば、ダンプ解析で地獄を見る /
/ 浮動小数点の指数部が不正な値（非数: NaN）として解釈されると、 /
/ 後続の演算で即座に例外が発生する /
もし、この`STORAGE_AREA`がDB2の`SELECT`文で取得したデータで、かつ構造体にズレが生じていたらどうなるか。CICSのトランザクションダンプ（CEEDUMP）を眺めながら、数千行のコードを追う羽目になる。特に、パックデシマルの符号反転バグ（符号ビットの破損）が浮動小数点変換時に表面化するパターンは、まさにベテラン殺しの難問だ。
—
3. マイグレーションに向けた設計の指針
JavaやC#へ移行する際、PL/Iの`FLOAT`型をそのまま言語の`double`に置き換えるのは早計だ。以下のチェックリストを常に念頭に置いてほしい。
1. 丸めモードの統一: メインフレーム側の `ROUND(X, N)` と、移行先言語の丸めアルゴリズムを一致させること。
2. 中間計算の保持: 浮動小数点計算の結果をファイルやテーブルに格納する際、単なるバイナリコピーではなく、文字列（`PICTURE`句）への変換を介して正規化を検討すること。
3. アベンド解析: `S0C7`（データ例外）が出た際、コンパイラの最適化オプション（`OPT(3)`など）がかかっていると、レジスタの値とソースコードが一致しないことがある。解析時は必ず`NOOPTIMIZE`でコンパイルし直す勇気を持つこと。
—
結びに代えて：技術への敬意
PL/Iは、汎用機という巨大な獣を乗りこなすための言語だ。IEEE 754のような現代的な標準に準拠することは重要だが、我々が扱うべきは「数十年前から稼働し続けているビジネスロジック」という名の生きた遺産である。
コンパイラの最適化オプション一つで計算結果が数ビット変わる世界。その微細な違いにまで意識を巡らせることが、システムアーキテクトとしての矜持ではないだろうか。移行プロジェクトは、単なるコードの書き換えではなく、そのシステムの「思想」を新しい言語に継承する儀式なのだから。
もし、貴方の現場で不可解な浮動小数点の挙動に悩まされているなら、まずはダンプの16進ダンプを信じろ。言語仕様の裏側に隠れた、ハードウェアの生の声がそこに刻まれているはずだ。
