はじめに：なぜ今、PL/Iの「固定小数点数比較」の裏側を覗くのか
基幹システムの現場において、深夜のバッチ処理が突如として「S0C7」や「S0C4」のアベンドを吐き出し、あるいはもっとタチの悪いことに、エラーも出さずに「数ペンスの金額ズレ」という致命的なサイレントエラーを引き起こす――。あなたも、そんな冷や汗をかくような修羅場をくぐり抜けてきたことだろう。
オープン系エンジニアから見れば、PL/Iの `FIXED DECIMAL` や `FIXED BINARY` は「ただの数値型」に映るかもしれない。しかし、IBMメインフレームのアーキテクチャを知り尽くした我々システムアーキテクトにとって、これらはハードウェアの演算器（Decimal Arithmetic Instructions）とコンパイラの最適化ロジックが緻密に絡み合う、極めてスリリングな領域だ。
特に、「異なる精度を持つ固定小数点数同士の比較演算」。この一見何気ない処理の裏で、コンパイラはどのようなコードを生成し、プロセッサは内部でいかにしてデータを正規化しているのか。今回は、このテーマを深く掘り下げ、マイグレーション時の罠からダンプ解析の極意まで、現場の知見を余すところなくお伝えしよう。
—
1. 異なる精度を持つ固定小数点数比較の内部挙動
PL/Iにおいて、例えば `FIXED DECIMAL(5,2)` と `FIXED DECIMAL(7,4)` のような、精度（P）やスケール（Q）が異なる変数同士を比較する場合、コンパイラ（Enterprise PL/Iなど）はどのようなコードを吐くのか。
オープン系言語（JavaやC#）であれば、暗黙的な型昇格（Promotions）が行われて一瞬で終わる話だが、メインフレームの世界では「スケールの合わせ込み（Alignment）」という明確なステップが存在する。
スケール調整とパディングのメカニズム
PL/Iの言語仕様では、比較演算を行う際、必要に応じて一時的なワーク領域（あるいはレジスタ上）でオペランドのスケールを一致させる。
- 小数部の桁数が異なる場合: スケール（Q値）が大きい方に合わせるため、小さい方の数値を10の階乗で乗算（シフト）し、下位にゼロパディングを行う。
- 整数部の桁数が異なる場合: 最大長に合わせたパック十進数（Packed Decimal）の形式へ正規化される。
ここで注意すべきは、「比較の瞬間に、見えないオーバーヘッドとデータ例外（Data Exception）のリスクが潜んでいる」という点だ。
以下のPL/Iコード例を見てほしい。
DCL WS-AMT-A FIXED DEC(5,2) INIT(123.45);
DCL WS-AMT-B FIXED DEC(7,4) INIT(123.4500);
/ 精度とスケールが異なる変数同士の比較 /
IF WS-AMT-A = WS-AMT-B THEN
PUT SKIP LIST(‘EQUAL’);
ELSE
PUT SKIP LIST(‘NOT EQUAL’);
END;
このコード、人間から見れば「等しい」に決まっている。しかし、内部的には `WS-AMT-A` の値を拡張し、スケールを4桁（.xx00）に揃えてから、IBM汎用機の機械語命令である `CP`（Compare Decimal）命令や `SRP`（Shift and Round Decimal）命令へと翻訳される。
もし、この正規化の過程でデータがゾーン10進数や不正なパック10進数（例えば、符号ニブルに `C` `D` `F` 以外が入っているなど）であった場合、容赦なく S0C7アベンド（Data Exception） が発生する。
—
2. マイグレーション時の罠：Java/C#への移行における意味論の乖離
レガシーマイグレーション（PL/IからJavaやC#へのリライト）において、最もエンジニアを悩ませるのが、この「固定小数点数の比較・丸め誤差・オーバーフロー挙動」の差異である。
パックデシマルの内部符号反転バグとデータ互換
メインフレームのDB2（表スペース）やVSAMファイルからデータを読み込んだ際、PL/Iの `FIXED BINARY` と `FIXED DECIMAL` が混在していると、Java側（`BigDecimal` や `int`/`long`）で厳密なエミュレーションを行わない限り、比較結果が一致しなくなる現象が起きる。
特に、CICSオンラインやバッチで使われる埋め込みSQL（DB2 for z/OS）において、ホスト変数の定義とデータベースの列定義が微妙に異なるケースでの比較は危険だ。
/ DB2のDECIMAL(9,2)を受け取るホスト変数 /
DCL HV-SALES FIXED DEC(9,2);
/ ワーク領域の変数 /
DCL WK-LIMIT FIXED DEC(7,2) INIT(50000.00);
EXEC SQL
SELECT SALES INTO :HV-SALES
FROM EMP_TABLE
WHERE EMP_ID = :V-EMP-ID;
/ ここでの比較：HV-SALES(9,2) と WK-LIMIT(7,2) /
IF HV-SALES > WK-LIMIT THEN
CALL PROCESS-HIGH-SALES;
ENDIF;
これをJava（Spring Boot + MyBatis等）へ移行する際、単なる `BigDecimal` 同士の比較として実装すると、PL/Iコンパイラが暗黙的に行った「オーバーフローチェックの有無」や「中間小数点の切り捨てルール（ROUNDオプションの有無）」の違いにより、境界値（Boundary Value）で挙動が分岐してしまうバグが頻発する。移行設計では、コンパイラオプション（`DEC(31)` や `TRUNC` など）の挙動をJava側で完全に再現するラッパーが必要となる。
—
3. コンパイラオプションと最適化：プロセッサを唸らせるコード
Enterprise PL/Iコンパイラを使用する際、数値演算や比較のパフォーマンスを極限まで高めるためには、コンパイラオプションの選択が死活問題となる。
1. `TRUNC(BIN)` vs `TRUNC(STD)`
`FIXED BINARY` 変数に対する演算・比較において、`TRUNC` オプションの指定は極めて重要だ。
- `TRUNC(STD)`: 標準仕様に準拠し、代入時に宣言された精度（例えば `FIXED BINARY(15)` ならば -32768 ～ 32767）に合わせて切り捨てを行う。これにより、比較時に予期せぬ不一致を防ぐが、余分なマシン語命令が生成される。
- `TRUNC(BIN)`: ハードウェアのレジスタサイズ（32ビットまたは64ビット）までフルに値を使用する。パフォーマンスは向上するが、宣言桁数を超えるデータが入った場合の比較挙動が変わり、オープン系との互換性問題を生む。
2. `STGDOSTG` とポインタによる動的メモリ操作のエッジケース
極限のパフォーマンスを追求する超高速バッチでは、ベース変数（Based Variable）とポインタを用いて、ストレージ上のパックデシマルデータを直接比較することがある。
DCL P-RAW-DATA PTR;
DCL 1 RAW-RECORD BASED(P-RAW-DATA),
5 F1 FIXED DEC(5,2),
5 F2 FIXED DEC(5,2);
/ ポインタ経由でアドレスを直叩きして比較 /
IF RAW-RECORD.F1 = RAW-RECORD.F2 THEN
…
このようなポインタ操作を伴う比較では、コンパイラによる最適化（`OPTIMIZE(FULL)` など）が有効な場合、レジスタへのキャッシュ最適化が働き、メモリ上のリアルタイムな書き換えが反映されない「レジスタ退避の罠」に陥ることがある。これを防ぐためには、`REORDER` / `NOREORDER` 属性の制御がプロフェッショナルの腕の見せ所となる。
—
4. アベンド（ABEND）発生時のダンプ解析：S0C7の真犯人を見つけ出す
万が一、深夜バッチで `COMPARE` 命令やその前段階の正規化で `S0C7`（Data Exception）が発生した場合、シスマネやアーキテクトである我々は、SYSUDUMPやCEEDUMPから瞬時に原因を特定しなければならない。
ダンプから読み解く「ズレた精度」
1. PSW（Program Status Word）の確認: アベンドを引き起こした機械語命令（`CP` 命令や `SP` 命令など）のアドレスを特定する。
2. レジスタとストレージの逆算: 該当命令のオペランドが指すストレージアドレス（例：ワーク領域やファイルバッファ）をDUMPフォーマットからダンプリストで追う。
3. ゾーン・パックの破損: 比較演算の片方のデータが、前段のMOVEや外部からの不正入力によって、有効なパックデシマル形式（下位4ビットが符号 `C`,`D`,`F`、それ以外が `0`～`9`）を破壊されているケースがほとんどだ。
特に、異なる精度同士の比較における暗黙の `SRP`（Shift and Round Decimal）命令実行時に、桁あふれ（Overflow）が発生してS0C7になるケースは、ソースコード上の宣言精度（P, Q）の設計ミスに起因する。ここを見誤ると、パッチ当てを繰り返す泥沼にハマることになる。
—
おわりに：レガシーの神髄を知るアーキテクトであれ
PL/Iの固定小数点数比較という、一見すると地味なテーマ。しかし、その裏側には、IBMメインフレームのハードウェアアーキテクチャの歴史、コンパイラの最適化思想、そして基幹システムが何十年にもわたって死守してきた「1円の狂いも許さない」という信頼性の哲学が凝縮されている。
単に「Javaに置き換える」「動けばいい」という表層的なマイグレーションではなく、こうした内部挙動の機微を完全に理解した上で設計・実装に臨むこと。それこそが、真のレガシー移行スペシャリスト、そしてテックリードに求められる条件なのだ。
さあ、今日もメインフレームの深い森へとダイブし、完璧なシステムを組み上げよう。
