浮動小数点の深淵：FLOAT BINARY(21)と(53)が引き起こすマイグレーションの悪夢
メインフレームの心臓部で稼働し続けるPL/Iコード。現代のJavaやC#、あるいはクラウドネイティブなマイクロサービスへと移行する際、最も「静かに、しかし確実に」プロジェクトを破壊しにくるのが、浮動小数点数の内部表現の差異です。
特に `FLOAT BINARY(21)`（単精度相当）と `FLOAT BINARY(53)`（倍精度相当）の扱いは、単なる精度の問題ではありません。IEEE 754という共通規格の皮を被りながら、かつてのS/370アーキテクチャの癖を色濃く残すPL/Iコンパイラの挙動を理解していないと、本番稼働後の「微小な計算誤差による突き合わせ不整合」という、最も胃が痛むバグを招くことになります。
なぜ(21)と(53)なのか：ハードウェア演算の境界線
PL/Iにおいて `FLOAT BINARY(p)` を宣言する際、`p` はビット精度を指定します。
- FLOAT BINARY(21): 内部的には4バイト（32ビット）の短精度浮動小数点形式にマップされます。
- FLOAT BINARY(53): 8バイト（64ビット）の長精度浮動小数点形式にマップされます。
ここで注意すべきは、IBMメインフレーム（z/Architecture）のハードウェア命令セットです。`FLOAT BINARY(21)` は、古い短精度演算命令を呼び出す可能性がありますが、現代のJavaの `float` とは丸めモードのデフォルト挙動が異なる場合があります。
特にマイグレーション時、DB2の `FLOAT` 型（実体はDOUBLE PRECISION）とのマッピングにおいて、PL/I側で `FLOAT BINARY(21)` を使用していると、DB2からフェッチした瞬間にビット落ちが発生し、その後の計算ロジックで上位システム（Java側）と結果が乖離するというケースを何度も見てきました。
/i
/ 誤った定義例：DB2とのインターフェースで精度が落ちるリスク /
DCL VAL_SINGLE FLOAT BINARY(21);
DCL VAL_DOUBLE FLOAT BINARY(53);
/ DB2からのFETCH時、コンパイラは暗黙の型変換を行う場合がある /
EXEC SQL FETCH C1 INTO :VAL_SINGLE;
/ ここでVAL_SINGLEに対して複雑な演算を行うと、 /
/ コンパイラはハードウェアの短精度演算命令を生成する。 /
/ 現代のプロセッサでIEEE 754に準拠した計算を行うJava/C#とは、 /
/ 演算順序によって微小な差（ULP: Unit in the Last Place）が生じる。 /
パックデシマルと浮動小数点の「魔の交差点」
基幹システムにおいて、浮動小数点数と `FIXED DECIMAL(n, m)`（パックデシマル）が混在する計算式は、常にアベンド（S0C7等）の温床です。
特に恐ろしいのが、パックデシマルから浮動小数点へ変換する際の「符号ビット」の扱いです。稀に、古いCOBOLから移行してきたデータで、パックデシマルの符号部分（ニブル）が標準外のビットパターンになっている場合、コンパイラが生成する変換ルーチンが例外を投げるか、あるいは意図しない負のゼロ（-0.0）を生成します。
/i
/ 符号反転バグを回避するための防御的コーディング例 /
DCL PACK_VAL FIXED DEC(15, 2) INIT(12345.67);
DCL FLOAT_VAL FLOAT BIN(53);
/ 直接代入せず、一度アブソリュート値で評価するか、 /
/ 組み込み関数で明示的に変換する習慣をつける /
FLOAT_VAL = FLOAT(PACK_VAL);
IF FLOAT_VAL < 0 THEN DO; / 負のゼロ判定やアンダーフロー時のケア / FLOAT_VAL = 0.0; END;
動的メモリ操作とポインタによる「地雷」
ポインタ（`PTR`）を用いた動的メモリ操作はPL/Iの強力な武器ですが、マイグレーションにおいては最大の敵となります。特に `BASED` 変数を用いた構造体のマッピングは、オフセットの計算がコンパイラの `ALIGN` オプションに強く依存します。
もし、移行先の言語で構造体のパディングルール（Struct Alignment）が異なる場合、バイナリダンプから読み込んだデータが壊滅的に化けます。
- アドバイス: コンパイラオプションを確認してください。`ALIGNED` か `UNALIGNED` か。この一つで、構造体のサイズが変わります。ダンプ解析（`SYSUDUMP`）を行う際は、必ずその時のコンパイルリストの `STORAGE MAP` を手元に置いてください。マップを見ずにアベンドを追うのは、目隠しをして地雷原を歩くようなものです。
最後に：移行アーキテクトが持つべき視点
PL/Iのプログラムは、単なるビジネスロジックの羅列ではありません。ハードウェアの特性を直接叩くための命令列です。
マイグレーションを担当するあなたが直面するのは、コードの書き換え以上に「数値の解釈の差異」との戦いです。
1. 演算精度を(53)で統一せよ: 現代の64ビット環境で(21)を使用するメリットは皆無です。
2. DB2の型と一致させよ: SQL記述とプログラム上の宣言を完璧に同期させてください。
3. ダンプを愛せ: アベンドが発生したら、逃げずに制御ブロックとレジスタを見てください。そこにはPL/Iがどう動きたかったのか、その「意志」が刻まれています。
レガシーシステムの移行は、単なるリプラットフォームではありません。先人が築き上げた「計算の厳密さ」という遺産を、現代のプラットフォームへと正しく継承する儀式なのです。迷ったときは、基本に立ち返り、コンパイラが生成したアセンブラコードを覗き込む勇気を持ってください。
