メインフレームの心臓部：「FIXED DECIMAL」という名の深淵を読み解く
メインフレームの基幹バッチで長年戦ってきたエンジニアなら、`DCL VAL FIXED DEC(15, 2);` という一行を見て、単なる変数宣言以上の重みを感じるはずだ。PL/Iにおける`FIXED DECIMAL`、すなわちパック10進数は、我々が扱うお金や数量の「絶対的な正確性」を担保する最後の砦である。
しかし、JavaやC#へのマイグレーションを担う諸君にとって、この型はしばしば「ブラックボックス」として恐れられる。今回は、このパック10進数の内部構造と、現場で遭遇する「悪魔の細部」について、アーキテクトの視点から紐解いていこう。
—
1. パック10進数（COMP-3）の物理構造と符号の罠
IBMメインフレームにおける`FIXED DECIMAL(p, q)`は、メモリ上で「COMP-3」形式として表現される。具体的には、1バイトに2桁の数値を詰め込み、末尾の4ビットに符号を置く。
ここで注意すべきは、符号ビットの「正規性」だ。
標準的な正数は `0xC`、負数は `0xD` が末尾のニブル（4ビット）に付与される。しかし、COBOLやPL/Iの古いコンパイラ、あるいは他言語からのデータ移行において、稀に `0xF`（符号なしと見なされる）や、不適切なビットパターンが混入することがある。
/i
/ パック10進数の内部表現をポインタで覗き見る例 /
DCL VAL FIXED DEC(5, 0) INIT(12345);
DCL PTR PTR;
DCL PTR_VAL BASED(PTR) CHAR(3); / 実態は3バイト /
PTR = ADDR(VAL);
/ ここでPTR_VALをダンプすると、12 34 5C という並びが見えるはずだ /
/ CICSやバッチでS0C7アベンドが発生する場合、まずこの符号部が破壊されていないか疑え /
なぜ「S0C7」は消えないのか？
マイグレーション先でJavaの `BigDecimal` を使っても、DB2から取得したデータの符号が `0xF` だったり、不正なパック形式だったりすると、PL/Iのランタイムが自動的に補正していた挙動が失われ、アプリ層での予期せぬデータ不整合や例外を引き起こす。この「暗黙の救済」を過信しないこと。それが脱レガシーの第一歩だ。
—
2. 演算時の精度保持ルール：コンパイラによる最適化の罠
PL/Iのコンパイラは、演算時に中間結果の精度を自動的に拡張する。これが非常に強力である反面、パフォーマンスと精度のバランスを崩す原因にもなる。
例えば、`FIXED DEC(5, 2) FIXED DEC(5, 2)` を実行する場合、中間結果は `FIXED DEC(11, 4)` に拡張される。このとき、コンパイラオプションの `FIXEDOVERFLOW` が有効だと、計算結果が桁あふれを起こした瞬間にアベンド（ABEND）する。
/i
/ コンパイラオプションを意識した設計 /
/ LIMIT(DECIMAL(15)) や PRECISION(FIXED) の設定が移行時の挙動に直結する /
DCL A FIXED DEC(15, 2) INIT(9999999999999.99);
DCL B FIXED DEC(15, 2) INIT(1.00);
/ 計算結果が15桁を超える場合、オーバーフローを意図的に制御するか、 /
/ あるいは切り捨て処理を明示的に記述する必要がある /
A = A + B; / ここで桁あふれチェックが走る /
移行設計において、この「暗黙的な精度調整」をすべてJavaのコードに移植しようとすると、往々にして「丸め誤差」問題で地獄を見る。DB2の `DECIMAL` 型との整合性を保つには、アプリ側で `BigDecimal` の `RoundingMode` を極めて厳格に定義しなければならない。
—
3. 実践的トラブルシューティング：ダンプ解析の極意
基幹システムが深夜に停止した際、ダンプリストから読み取るべきは、レジスタの値と、その先にあるメモリの16進数ダンプだ。
- 符号反転バグ: 外部システム（メインフレーム外）から受け取ったデータで、符号が反転している、あるいはパック形式ではないデータが混入している場合、`COMP-3` としての計算は必ず失敗する。
- ポインタ操作と基底変数: `BASED` 変数を使用して動的メモリを操作する場合、データ構造のオフセットが1バイトでもズレれば、パック10進数の「桁と符号」は完全に化ける。ダンプ解析時は、必ず「どこからポインタを当てたか」の基点（Address）をオフセット計算し、実際のメモリ値を16進数で確認せよ。
—
アーキテクトからの提言：移行を成功させるために
レガシー移行において最も危険なのは、「PL/Iの挙動をJavaで完全に再現しようとすること」である。PL/Iのランタイムが長年かけて培ってきた「緩やかなエラー許容」と「厳格な精度保持」のバランスは、Javaの世界では別物だ。
1. DBの正規化を見直せ: アプリ側での演算精度を追求する前に、DB2の定義と入出力データの整合性を最優先で担保せよ。
2. ダンプ解析スキルを捨て去るな: Javaに移行しても、メモリ上の表現を意識する能力は、トラブルシューティングの最終防衛線となる。
3. 境界値テストの徹底: `FIXED DEC` の最大値・最小値付近での挙動は、コンパイラのバージョンアップや環境移行で最も変化しやすい。
PL/Iは古いが、その設計思想には「お金を扱うシステム」に必要な美学が詰まっている。この堅牢な思想を、次の世代のシステムへどう翻訳するか。それこそが、我々アーキテクトに課せられた真の仕事なのだ。
諸君、コードの裏側にある「ビット」を信じろ。それこそが、メインフレームの魂だ。
