浮動小数点の深淵：IBMメインフレームにおけるFLOAT演算の罠とレガシー移行の鉄則
メインフレームの現場で長く生きていると、ある種の「職人気質」が試される場面に遭遇する。特にPL/Iを用いた基幹バッチにおいて、計算結果の僅かな誤差が、数十年動いてきた勘定系システムの整合性を揺るがすケースだ。
今日は、若手エンジニアやマイグレーション担当者が最も見落としがちな「浮動小数点形式の選択」と、それがシステム全体の信頼性にどう直結するかについて、私の経験を紐解きながら語ろう。
—
1. 浮動小数点形式の選択：IBM形式か、IEEE 754か
PL/Iには `FLOAT BINARY` と `FLOAT DECIMAL` が存在するが、コンパイラオプションの `FLOAT(IBM)` と `FLOAT(IEEE)` の違いを理解せずに移行を進めるのは、爆弾を抱えて走るようなものだ。
IBM形式（Hexadecimal Floating Point）は、かつてのSystem/360から続く伝統的な形式だ。これに対し、近年のJavaやC#、あるいは現代のハードウェアとの親和性を考慮して選ばれるIEEE 754形式は、構造そのものが全く異なる。
- IBM形式: 指数部が16の累乗。精度が保証されやすいが、現代のx86_64アーキテクチャやJavaの `double` とはビット表現が異なる。
- IEEE 754: 指数部が2の累乗。モダンな環境への移行には親和性が高いが、既存のデータセット（QSAMやVSAM）に直接書き込まれたバイナリデータとの互換性を崩すリスクがある。
教訓: 「とりあえず最新のコンパイラオプションを使えば良い」という考えは捨てろ。既存のダンプを解析する際、この設定一つで浮動小数点のビットパターンが解釈不能になる。マイグレーション時には、必ず旧環境でのダンプと新環境での出力結果をビット単位で突き合わせる必要がある。
—
2. コードで見る浮動小数点の取り扱いと最適化
PL/Iで厳密な計算を行う場合、`FLOAT` を不用意に使うのではなく、`FIXED DECIMAL`（パックデシマル）を原則とすべきだ。しかし、科学計算や複雑な統計処理で `FLOAT` を避けられない場合、以下のコードのように精度を意識した記述を心がけよ。
/i
/ FLOAT処理の際の安全策と型指定 /
DECLARE (VALUE_A, VALUE_B) FLOAT BINARY(53) INITIAL(0); / 53bit精度でダブル精度を確保 /
DECLARE RESULT FLOAT BINARY(53);
/ 演算前に値を明示的に丸めるテクニック /
/ 浮動小数点の誤差を最小化するため、必要に応じて基数変換を行う /
RESULT = ROUND(VALUE_A + VALUE_B, 15);
/ CICS/DB2環境での注意点：浮動小数点による比較は絶対に避けること /
/ IF A = B THEN … はアベンドや誤判定の温床となる /
IF ABS(VALUE_A – VALUE_B) < 1E-10 THEN
DO;
/ 近似値として許容するロジックを組む /
END;
---
3. ダンプ解析とアベンドの現場から
基幹システムで最も恐ろしいのは、計算誤差が原因で発生する、原因不明の異常終了（ABEND）だ。特に浮動小数点の計算結果が「非数（NaN）」や「無限大（Infinity）」となり、それがDB2のテーブルへ格納される際にエラーを吐くケースは非常に多い。
ダンプを解析する際、汎用レジスタや浮動小数点レジスタを確認するだけでなく、以下の点に着目せよ。
- パックデシマルの符号反転バグ: DB2連携時に、外部システムから受け取ったデータの符号（通常は `C` や `D`）が異常な値（例えば `E` など）になっていると、算術演算時にデータ例外（S0C7）が発生する。`PL/I` の `CHECK` 条件や `ON FIXEDOVERFLOW` を活用し、境界値を徹底的に監視せよ。
- ポインタによるメモリ破壊: `BASED` 変数を多用する場合、ポインタの参照先が期待した領域外を指していないか。特に動的メモリ割り当てを繰り返す処理では、`ALLOCATE` と `FREE` の整合性が崩れると、浮動小数点の演算結果が突然化ける。
—
4. マイグレーションを成功させるために
JavaやC#への移行を検討しているアーキテクト諸君へ。PL/Iの `OPTIONS(MAIN)` で定義されたエントリポイントの挙動は、単なるプログラムの開始点ではない。それは、OSとのインターフェース、つまり `EXEC CICS` や `EXEC SQL` といった環境依存コードと一体化している。
1. データ型のマッピングを可視化せよ:
`FLOAT BINARY(53)` は Java の `double` と完全一致するか？ パックデシマル `FIXED DECIMAL(15,2)` は Java の `BigDecimal` で正しくスケールを制御できているか？ これをExcelシート一枚に落とし込めていないチームは、必ずテストフェーズで詰む。
2. 誤差の許容範囲を定義せよ:
浮動小数点計算の結果は、言語やコンパイラによって数ビットの差異が生じる。その「誤差」がビジネス的に許容されるのか、あるいは四捨五入のルールを厳密に合わせる必要があるのか、ユーザー部門と合意形成しておくことが、真の意味での「移行責任」だ。
最後に：技術は変われど、真理は不変
PL/Iという言語は、古臭いようでいて、実はハードウェアの限界と正面から向き合うための非常に「正直な」言語である。浮動小数点の誤差やメモリの動的管理を理解することは、現代の抽象化された高レイヤー言語しか知らないエンジニアにとって、最高の教養となるはずだ。
システムを移行する際、コードを書き換えることは手段に過ぎない。真の目的は、そのシステムが長年守り続けてきた「データの正確性」という魂を、次のプラットフォームへ如何に無傷で継承するかにある。
迷ったときは、マニュアルを読む前に、アセンブラのダンプを見よ。機械は嘘をつかない。コンパイラが吐き出した最適化後のコードこそが、君たちのシステムの「真実」なのだから。
