序章：なぜ今、PL/Iの「FIXED DECIMAL」なのか
メインフレームの現場で長年システムを支えてきたエンジニアであれば、「パック10進数（Packed Decimal）」の不気味な挙動に一度や二度は泣かされた経験があるはずだ。JavaやC#といったモダン言語の `BigDecimal` や浮動小数点数とは異なり、IBMメインフレームのPL/Iにおける `FIXED DECIMAL`（内部属性としては `PACKED-DECIMAL`）は、S/370アーキテクチャのハードウェア命令と密着して動作する。
コンパイラはこのデータ型を処理する際、私たちが記述した高水準のコードを、ベアメタルの十進演算命令（`AP`, `SP`, `MP`, `DP`）へと直結させる。マイグレーションの現場において、この「ハードウェアレベルの厳密な仕様」を理解せず、単に数値型だからと安易にJavaの `Long` や `BigDecimal` へ置き換えた結果、端数処理の丸め誤差や、符号ビットの解釈違いによるデータ破損を引き起こす事故が後を絶たない。
今回は、PL/Iの `FIXED DECIMAL` が内部でどのように息づき、コンパイラによっていかなるアセンブラ命令に翻訳され、そして現場のトラブルシューティングにおいていかにして我々の牙を剥くのかを、徹底的に解剖しよう。
—
1. パック10進数（PACKED-DECIMAL）の内部構造と符号ビットの真実
まず、ハードウェアがメモリ上でどのように数値を保持しているかを確認する。
`FIXED DECIMAL (p, q)` は、1バイト（8ビット）のなかに2桁の10進数（ニブル＝4ビット×2）を詰め込み、最後の1ニブルに符号（Sign）を格納する。
例えば、`DCL WS-AMT FIXED DECIMAL(5, 2) INIT(123.45);` という変数を定義した場合、必要なメモリサイズは計算式により算出される。
$$\text{バイト数} = \lfloor \frac{p + 2}{2} \rfloor$$
桁数 $p=5$ の場合、$(5 + 2) / 2 = 3.5$ の切り捨てで 3バイト が割り当てられる。
メモリ上のバイナリイメージは以下のようになる。
[ 012345 C ] -> 1バイト目: ’01’, 2バイト目: ’23’, 3バイト目上位: ’45’, 3バイト目下位: ‘C’ (正の符号)
符号ニブルのバリエーション
IBMメインフレーム（System/390および z/Architecture）では、EBCDICの符号付ゾーン10進数およびパック10進数において、以下の符号ビット（最下位4ビット）が標準として使用される。
- `C` : 正の数（Plus）※標準生成
- `D` : 負の数（Minus）※標準生成
- `F` : 符号なし、または正（符号化されていない場合や、ゾーン10進数からの変換時）
- `A` : 正の数（一部の外部システム連携で見られる変則パターン）
内部符号反転バグとS0C7アベンドの恐怖
レガシーシステムで最も頻発する障害の一つが、外部ファイルや他系システムから不正な符号（例えば `E` や `B` など）が混入した状態で演算を行った際に発生する S0C7（Data Exception） である。
PL/Iプログラムが `FIXED DECIMAL` 同士の加算や比較を行う際、CPUはこれを有効なパックデータとして解釈しようとする。もし最下位ニブルに `C` `D` `F` 以外のビットパターンが存在する場合、ハードウェア例外（プログラム割込みコード 0007：データ例外）が発生し、一瞬でジョブが異常終了する。
ここで、実務で使えるPL/Iコード例を見てみよう。ポインタとベース変数を用いて、ダンプ解析時に怪しい領域を直接覗き見し、不正符号を検知・修正するロジックの断片である。
/ —————————————————————- /
/ FIXED DECIMAL 変数の内部構造解析と不正符号チェックサンプル /
/ —————————————————————- /
SAFE_CHECK: PROC OPTIONS(MAIN);
DCL 1 RAW_AREA,
5 PTR_VAL POINTER,
5 DATA_LEN FIXED BIN(31) INIT(3);
/ 対象となるパック10進数変数（3バイト） /
Dcl TARGET_DEC FIXED DEC(5,2) STATIC INIT(0);
/ BASED変数を定義し、任意のメモリアドレスをマッピングする /
DCL BASED_RAW_CHAR CHAR(3) BASED(P_RAW);
DCL P_RAW POINTER;
P_RAW = ADDR(TARGET_DEC);
/ ワーキングストレージ上の1バイトずつをスキャンする処理のイメージ /
PUT SKIP LIST(‘Target Dec Address: ‘, HEX(P_RAW));
/ 正常な符号（C, D, F）が最下位ニブルに存在するかチェックするロジック /
/ （実際の現場ではSUBSTRとUNSPECを組み合わせて最下位4ビットをマスクする） /
RETURN;
END SAFE_CHECK;
—
2. アセンブラ命令（AP, SP, MP, DP）への展開プロセス
PL/Iコンパイラ（IBM Enterprise PL/I for z/OS）は、`FIXED DECIMAL` に対する算術演算を、高水準言語の抽象度を保ったまま最適化し、S/390の強力な十進演算命令（Decimal Instructions）へと直訳する。
コンパイラがどのようなアセンブラコードを裏で生成しているかを知ることは、性能チューニングの観点から極めて重要である。
主要な十進演算命令
1. AP (Add Decimal) : $D_1(L_1, B_1) \leftarrow D_1(L_1, B_1) + D_2(L_2, B_2)$
- メモリ上で直接十進数の加算を行う。桁あふれ（Overflow）が発生するとプログラム割込み（コード 000B）を引き起こす。
2. SP (Subtract Decimal) : 引き算。
3. MP (Multiply Decimal) : 掛け算。乗算先のレジスタ/メモリ領域は、被乗数と乗数の合計桁数を収められるだけの十分なサイズがなければならない。
4. DP (Divide Decimal) : 割り算。商と余りが特定のメモリレイアウトで返されるため、PL/Iコンパイラは一時的なワークエリア（レジスタ・セーブエリア周辺）を自動的に割り当てて余りの処理を隠蔽している。
コンパイラオプションによる最適化の罠
Enterprise PL/Iのコンパイル時に指定する `OPTIMIZE` オプション（OPTIMIZE(2) または OPTIMIZE(3)）は、これらの十進演算において目覚ましい最適化を行う。例えば、連続する加算をまとめたり、レジスタへのロード・ストアを最小限に抑えたりする。
しかし、「厳密なオーバーフロー検知（ON OVERFLOW）」を使用している場合、最適化レベルによっては例外発生時の正確なステートメント番号の特定が困難になるケースがある。基幹システムのバッチにおいて、監査ログや金額計算の厳密性が求められるプログラムでは、デバッグのしやすさと実行パフォーマンスのトレードオフを慎重に見極める必要がある。
—
3. エッジケース対策：埋め込みSQL（DB2）とCICSオンライン処理
マイグレーションや保守の現場で最もシビアな問題が起きるのは、DB2の表定義（`DECIMAL` または `NUMERIC`）と、PL/I側の `FIXED DECIMAL` 定義が微妙に乖離しているケース、あるいはCICSのコミット境界を跨ぐ領域でのデータ授受である。
1. DB2埋め込みSQLにおけるホスト変数
DB2のデータ型 `DECIMAL(p, q)` は、そのままPL/Iの `FIXED DEC(p, q)` に対応する。しかし、マイグレーション時にJavaの `BigDecimal` へ置き換える際や、CICSのコンテナ（Commarea）経由でデータを渡す際に、以下のようなトラップを踏む。
- スケール（小数点以下の桁数）の不一致による自動丸め
DB2側が `DECIMAL(9, 2)` であるにもかかわらず、PL/I側でうっかり `FIXED DEC(9, 0)` と定義してホスト変数に取得した場合、小数点以下が切り捨てられるか、最悪の場合はコンパイル警告を無視して実行時に予期せぬスケールシフトが発生する。
2. CICSにおけるCOMMAREAとアライメント
CICSの領域間通信で使用される `COMMAREA` の中で `FIXED DECIMAL` を使用する場合、特に注意すべきは「パック変数のパディング」と「境界整列（Alignment）」である。
PL/Iではデフォルトで `ALIGNED` 属性が効くことがあり、構造体（`1 DCL`）のメンバ間に意図しないパディングバイトが挿入されることがある。
他言語（C#やJavaのJNI、あるいは別システムのCOBOL）とバイナリレベルでデータを完全に一致させるためには、明示的に `UNALIGNED` 属性を付与しなければならない。
/ CICS通信領域などで他言語やCOBOLとレイアウトを完全一致させる例 /
DCL 1 CICS_MSG UNALIGNED,
5 MSG_ID CHAR(4),
5 TRANS_AMT FIXED DEC(9,2); / パディングなしで密に配置される /
この `UNALIGNED` を忘れてマイグレーション設計を進めると、CICSの画面から渡ってきた金額データがズレて読み込まれ、全銀協フォーマット等の外部連携電文で大惨事を引き起こすことになる。
—
4. モダン言語（Java/C#）へのマイグレーションにおける設計指針
もしあなたが今、このPL/Iの `FIXED DECIMAL` で書かれたレガシー資産をJava（Spring Boot等）やC#（.NET Core）へ移行するアーキテクトの立場にあるなら、以下の鉄則をチームに周知徹底してほしい。
1. ネイティブな浮動小数点（`float`, `double`）の使用は厳禁
金融系や基幹システムの計算において、浮動小数点は誤差を生むため絶対に許されない。Javaであれば `java.math.BigDecimal` を一択とし、丸めモード（`RoundingMode.HALF_UP` など）をPL/Iの挙動と完全に一致させること。
2. 符号ニブルのバリデーションレイヤーの実装
レガシーDBやファイルから読み込んだ段階で、パック10進数の最下位バイトの符号が正しいか（`C`, `D`, `F` の範囲内か）を検証するバリデーションフィルターを移行先の中間層に必ず設けること。これをサボると、Java側で予期せぬ `NumberFormatException` や、さらに厄介な「サイレントな計算ミス」の温床となる。
—
結び：レガシーの構造を極めた者だけが到達できるアーキテクチャ
PL/Iの `FIXED DECIMAL` は、単なる古い言語仕様の残骸ではない。それは、ハードウェアの能力を極限まで引き出し、1バイトの無駄もなく正確な数値を処理するために先人たちが築き上げた、美しき低水準の芸術である。
その内部表現、アセンブラへの翻訳メカニズム、そして周辺ミドルウェア（DB2/CICS）との相互作用を完全に理解したアーキテクトだけが、安全で、信頼性の高いモダン移行プロジェクトを成功させることができる。
コードの表面をなぞるだけの「なんちゃってモダナイゼーション」でシステムを崩壊させないためにも、今一度、足元にあるレガシーのバイナリ構造に目を向けてほしい。コンパイラとハードウェアが対話するその息吹を聞き取れた時、あなたのシステムアーキテクトとしての視野は、確実にあらゆるモダン技術の土台を支える強靭なものとなっているはずだ。
