浮動小数点の深淵：PL/Iにおける基数変換の「見えざるコスト」と移行の罠
メインフレームの現場で長年PL/Iコードと対峙していると、時折「なぜここで計算結果が1ビットずれるのか」という問いに突き当たります。特に `FLOAT DECIMAL` から `FLOAT BINARY` への暗黙の型変換が介在する処理は、基幹システムの精度を揺るがす地雷原です。
今日は、現代のオープン系言語（JavaやC#）への移行を見据えたアーキテクトのために、PL/Iの浮動小数点演算における内部挙動と、それにまつわるトラブルシューティングを深掘りします。
—
1. 基数変換のオーバーヘッドと「丸め」の悪魔
PL/Iの柔軟性は、時に開発者を裏切ります。`FLOAT DECIMAL`（10進浮動小数点）と `FLOAT BINARY`（2進浮動小数点）は、内部表現が根本的に異なります。
- FLOAT DECIMAL: 10進数で数値を保持し、主に財務計算の精度要件を満たすために使われます。
- FLOAT BINARY: ハードウェア（System zの浮動小数点ユニット）との親和性が高く、計算速度は圧倒的ですが、10進小数を正確に表現できません。
これらを混在させた演算を行うと、コンパイラは動的に変換処理を挿入します。この際、10進の `0.1` が2進数では無限小数になるという「基数変換の呪い」により、期待値との間にわずかな誤差が生じます。
致命的な精度変換コード例
1
/ 精度変換による比較バグの温床 /
DCL VAL_DEC FLOAT DECIMAL(16);
DCL VAL_BIN FLOAT BINARY(53);
VAL_DEC = 0.1;
VAL_BIN = VAL_DEC; / ここで内部変換発生 /
/ 2進数に変換された0.1は厳密には0.1ではないため、比較が失敗する可能性がある /
IF VAL_BIN = 0.1 THEN
PUT SKIP LIST (‘一致しました’);
ELSE
PUT SKIP LIST (‘精度誤差により一致しません’);
この「一致しない」という事象は、単なるバグ修正で終わらないことがあります。マイグレーション先がJavaの `BigDecimal` であれば誤差は制御できますが、`double`（2進浮動小数点）へ安易に移行すると、本番環境で長年蓄積された計算ロジックが崩壊します。移行設計では、浮動小数点の型をそのまま写すのではなく、計算ロジックの性質に応じて `FIXED DECIMAL` への書き換えを強制する検討が必要です。
—
2. 識別子の自由度と「予約語」なき戦場
PL/Iの設計思想において、識別子（変数名）に「予約語」は存在しません。これはコンパイラが文脈によって識別子を解釈するためです。非常に強力ですが、これがダンプ解析を困難にする原因の一つです。
例えば、`IF` という名前の変数を作ることも（推奨はしませんが）可能です。この特性により、大規模なレガシーコードでは、意図しない変数の参照がコンパイルエラーにもならず、実行時にデータ異常を引き起こすことがあります。
- 対策: 移行時は必ず `NAMES` コンパイラオプションを有効にし、変数名の衝突を静的解析で徹底的に排除してください。また、ポインタ操作を用いた動的メモリ操作では、`BASED` 変数のアライメントに注意を払う必要があります。
—
3. アベンド（ABEND）解析とデータ構造の罠
CICSオンライン処理やバッチにおいて、`S0C7`（データ例外）が多発する場合、その多くはパックデシマルの内部表現不正です。特にポインタを使って構造体をオーバーレイしている場合、メモリ上の符号ビットが破壊されていることがよくあります。
1
/ ポインタを用いた動的構造体操作の実践 /
DCL P PTR;
DCL 1 MY_REC BASED(P),
2 AMOUNT FIXED DECIMAL(15,2),
2 FLAG CHAR(1);
/ ポインタPが指す先に不正な値が入っているとS0C7のアベンドを誘発する /
/ ダンプ解析時は、Pが指すアドレスの符号部分（末尾4ビット）を16進数で確認せよ /
アーキテクトの視点：ダンプ解析の極意
ダンプが出た際、真っ先に確認すべきは「変数の値」ではなく「変数が指しているアドレスの整合性」です。特に、`CICS` の `GETMAIN` で確保した領域に `BASED` 変数をマッピングする際、領域長不足で後続の制御ブロックを破壊していないかを確認してください。
—
4. 移行を見据えたアーキテクチャの指針
レガシー移行のプロジェクトにおいて、我々が守るべきは「過去の計算結果の完全な再現」です。
1. 演算精度の正規化: 全ての計算ロジックを `FIXED DECIMAL`（パックデシマル）へ統一可能か検証する。
2. コンパイラ最適化の副作用: `OPTIMIZE(3)` などの高度な最適化は、時としてレジスタに残ったゴミを正当な値として扱う挙動を誘発します。バグ調査時は `NOOPTIMIZE` でコンパイルし、現象が再現するか確認するのも一手です。
3. DB2埋め込みSQLとの親和性: PL/Iの変数とDB2の型が微妙に一致しない場合、SQL処理中に暗黙のキャストが発生し、これがインデックススキャンを阻害することがあります。`DCL` 定義時の精度をDB2の列定義と厳密に合わせることは、パフォーマンスチューニングの鉄則です。
最後に
PL/Iは、ハードウェアの能力を余すことなく引き出すための「究極の道具」です。しかし、現代の言語への移行においては、その自由度が足かせとなります。
「なぜこのコードは動いているのか」を理解せず、ただコードを変換するだけのマイグレーションは、必ずどこかで致命的な破綻を招きます。コンパイラが内部で何をしているか、その「見えない変換」を想像できる人間こそが、真に信頼されるシステムアーキテクトと言えるでしょう。
何か特定のルーチンで計算結果の不整合に悩まされているなら、まずはその変数の `STORAGE` ダンプをバイナリレベルで比較することから始めてみてください。答えは必ずそこにあります。
