金融基幹の現場を揺るがす「定数の精度」という爆弾
メインフレームの現場で30年以上生き残ってきたシステムアーキテクトであれば、一度や二度は「なぜ、あのバッチは本番環境の特定データだけでS0C7（データ例外アベンド）を起こしたのか」という夜更けの謎解きに直面したことがあるはずだ。
現代のオープン系言語、例えばJavaやC#に慣れ親しんだエンジニアから見れば、PL/Iのデータ型や演算規則は、まるで深海魚のような奇妙さと圧倒的な重厚感を備えている。特に、`FIXED BINARY`（固定小数点二進数）および`FIXED DECIMAL`（固定小数点十進数／パック十進数）の定数定義における「精度のデフォルトルール」は、基幹システムの移行プロジェクトにおいて、幾多のアーキテクトを絶望の淵に追いやってきた。
今回は、ソースコード上では何気なく記述されている「数値リテラル」が、コンパイラの内部でどのように解釈され、演算結果にどのような致命的な影響を与えるのか。そして、JavaやC#へのマイグレーション時になぜそれが地雷となるのかを、極限まで実務的な視点から解き明かしていこう。
—
リテラル値のデフォルト精度と、サイレントなオーバーフローの恐怖
PL/Iにおいて、私たちがプログラム内に直接記述する数値リテラル（例: `12345` や `0`）は、コンパイラによって自動的にデータ属性が割り当てられる。ここで多くのエンジニアが勘違いしているのは、「リテラルは必要十分な最小限のサイズで保持される」という誤った思い込みである。
IBM Enterprise PL/Iコンパイラでは、固定小数点定数のデフォルトの属性はコンパイラのオプションや値の大きさによって決定されるが、一般的に`FIXED DECIMAL`または`FIXED BINARY`として扱われる際の有効桁数（プレシジョン）のデフォルト規則が存在する。
例えば、以下のような単純な代入文を考えてみてほしい。
DCL WK_AMOUNT FIXED DEC(9, 2);
DCL WK_RESULT FIXED DEC(9, 2);
/ ここに潜むコンパイラの暗黙の型昇格と精度の罠 /
WK_RESULT = WK_AMOUNT 1.05;
一見すると、金額に1.05（消費税率などの係数）を掛けているだけの健全なコードに見える。しかし、この `1.05` というリテラルは、PL/Iコンパイラによってどのように評価されるだろうか。
リテラル `1.05` は、明示的なスケール指定がない場合、コンパイラはその実装依存のデフォルト精度（通常は `FIXED DEC(5, 2)` あるいは環境によってはより大きな精度）として解釈する。
問題は、この乗算式全体の評価時に発生する。PL/Iの算術式評価規則では、演算に関わるオペランドの精度から、中間結果の精度が自動算出される。
もし `WK_AMOUNT`（`FIXED DEC(9,2)`）とリテラルから生成された中間ワークエリアの精度計算において、コンパイラが想定外のスケール拡張や切り捨てを行った場合、あるいは逆に桁あふれ（オーバーフロー）のチェックが甘くなった場合、実機では恐ろしい現象が起きる。
アベンドS0C7への最短ルート
CICSオンラインや深夜のバッチ処理で、突如として発生するシステム・アベンド S0C7（Data Exception）。その多くは、パック十進数（COMP-3）の領域に、ゾーン部や数値部として不正な文字コード（例えばスペースや未初期化のゴミ、あるいは演算結果のあふれによるオーバーフロー兆候）が流れ込んだ瞬間に引き起こされる。
定数定義やリテラル演算において、以下のようなコードは極めて危険だ。
DCL TOTAL_AMT FIXED DEC(11, 2) INIT(0);
DCL BASE_VAL FIXED DEC(9, 2) INIT(1000000.00);
/ 定数との演算による中間ワークの桁あふれ /
TOTAL_AMT = BASE_VAL 1.000000;
この例では、リテラル `1.000000` のスケール（小数点以下の桁数：6桁）が、演算結果のスケール決定に影響を与える。PL/Iの規則では、乗算の精度は「精度の和」に向かうため、コンパイラは内部で巨大な一時ワークエリアを割り当てるか、あるいは逆に精度の丸め（Truncation）を暗黙的に行い、最上位桁のロストを引き起こす。これが、DB2への書き込み時や、COBOL副プログラムとのインターフェース部における「突然のデータ不整合」の正体である。
—
ポインタ、ベース変数、そしてストレージ上でのバイナリ破壊
基幹システムのパフォーマンス極限チューニングや、巨大な世代管理ファイルの高速アンロード処理などでは、動的メモリ管理（`ALLOCATE` 闘病や `POINTER` を使ったベース変数）が多用される。ここで定数や精度の罠が絡むと、アベンドS0C7どころか、ストレージ破壊（Storage Overwrite）という最も厄介なデバッグ地獄へと突入する。
以下の実装例を見てほしい。
DCL 1 P_RECORD BASED,
3 REC_ID FIXED BIN(15, 0), / 2バイトの整数 /
3 REC_VAL FIXED DEC(7, 2); / 4バイトのパック十進数 /
DCL MY_PTR POINTER;
DCL WORK_BUF CHAR(100) BASED(MY_PTR);
/ 動的領域の取得 /
ALLOCATE P_RECORD SET(MY_PTR);
/ 【危険な操作】リテラル代入による精度のミスマッチ /
REC_VAL = 99999.99;
ここで、もしマイグレーション先の仕様変更や、C言語の構造体パディングのノリで `REC_VAL` の定義を安易に変更したり、あるいはポインタ経由で外部から生データ（Binary Stream）を流し込んだりした場合、どうなるか。
PL/Iの `FIXED DEC` は、内部的にパック十進数形式（1バイトに2桁の数字と、右端に符号が入る）で保持される。
もし、定数や他の変数との演算において、コンパイラオプション（例えば `FIXEDOVERFLOW` や `ARITHMETIC` の設定）がデフォルトのままであると、オーバーフローが発生した瞬間に例外割り込みが発生するか、あるいは最悪のケースとしてフラグが立ったままサイレントに上位桁が切り捨てられ、隣接するメモリ領域（今回の例では `REC_ID` や後続のポインタ制御域）を破壊し始める。
レガシーシステムのダンプ解析において、制御ブロックのチェーンが壊れてフリーズする現象の多くは、この「暗黙のデータ型変換と精度のミスマッチによるバッファオーバーラン」が原因である。
—
埋め込みSQL（DB2）およびCICSエッジケース対策
オンライン処理（CICS）の領域では、応答速度のミリ秒単位の短縮が求められるため、ホスト変数（Host Variables）の精度定義には神が宿る。
DB2のテーブル定義（例えば `DECIMAL(11,2)`）に対して、PL/I側のホスト変数を以下のように定義したとする。
/ DB2側: DECIMAL(11, 2) に対するPL/I側の定義 /
DCL HV_SALES_AMT FIXED DEC(11, 2);
ここに、ビジネスロジックの記述ミスや、定数の型推論の勘違いから、以下のような処理を挟み込んだとする。
/ 定数 ‘0’ との比較、あるいは演算 /
IF HV_SALES_AMT > 0 THEN DO; / この ‘0’ の扱いは？ /
/ 処理ロジック /
END;
一見、何の問題もないように見える。しかし、比較演算子の一方にリテラル `0` が置かれた場合、コンパイラはこれをどのような精度として評価し、DB2プリコンパイラ（SQLプレフィックス処理）はこれをどう解釈するのか。
DB2のSQL文中でホスト変数と比較される際、PL/I側のランタイムライブラリ（Language Environment: LE）が暗黙のデータ型変換を行うことがある。この変換コストが、数千件のループ処理内で発生すると、CICSのCPU使用量（Task Elapsed Time）が跳ね上がり、スループット低下という形でシステム全体に波及する。
さらに、CICSのコミット境界や、エラーハンドリング（`ON ERROR` / `ON FIXEDOVERFLOW`）を正しく実装していない場合、精度の不一致による例外は、そのままトランザクションの異常終了（アベンドコード: ASRA 等）を引き起こし、最悪の場合はDB2のログとCICSのリカバリーマネージャの間でリソース不整合を起こす。現場の運用担当者が夜間に叩き起こされる悪夢のシナリオだ。
—
マイグレーション（Java / C#）における最大のリスク
さて、ここからがレガシー移行アーキテクトとしての本題だ。
「PL/Iで動いている古臭い基幹システムを、モダンなJava（Spring Boot）やC#（.NET Core）にリライトしてクラウドへ載せよう」というプロジェクトにおいて、最も失敗するパターンは、「PL/Iのデータ精度規則や演算の挙動を無視して、単にJavaの `int` や `BigDecimal` に置き換えること」である。
1. 丸めモード（Rounding Mode）の差異
PL/Iの算術演算における端数処理（切り捨て、四捨五入の挙動）と、Javaの `BigDecimal.setScale()` やC#の `Math.Round()` のデフォルト挙動は、厳密には一致しない。
PL/Iでは、コンパイラオプションや演算の文脈によって、中間結果の保持方法や丸め方式がレガシー特有の仕様になっている。これをそのままJavaに移植すると、「本番同等テストの突合で、数円〜数十円の金額のズレが全件発生する」という、監査法人をも巻き込む大惨事に発展する。
2. リテラルの型推論の違い
Javaでは、例えば `1.05` はデフォルトで `double` 型（浮動小数点数）として扱われる。これをそのまま金額計算に使うと、IEEE 754に起因する浮動小数点の誤差（例: `0.1 + 0.2 != 0.3`）が猛威を振るう。
PL/Iの `FIXED DECIMAL`（固定小数点）の厳密な演算ロジックを、Javaの `BigDecimal` へ完全にマッピングするには、すべての定数リテラルや演算式に対して、明示的なスケールと丸めモードの指定をコードジェネレータまたは手動で強制しなければならない。
—
アーキテクトが取るべき実務的な防衛策
では、我々システムアーキテクトは、この「定数定義と精度の罠」に対してどのように立ち向かうべきか。現場で直ちに実践すべき鉄則を提示しよう。
1. リテラルを野放しにするな（精度の明示化）
計算式や代入文において、小数点を伴う数値リテラルや整数リテラルをそのまま記述せず、可能な限り十分な精度を持たせた定数変数（`DCL` で `FIXED DEC` や `FIXED BIN` を明示定義したもの）として定義し、それらを演算に用いること。コンパイラの「気まぐれな暗黙の型昇格」に運命を委ねてはならない。
2. コンパイラオプションの厳格な固定
IBM Enterprise PL/Iコンパイラのオプションにおいて、`LIMITS` や `FIXEDOVERFLOW`、`TRUNC` などの設定を開発チーム間で厳格に統一し、意図しない精度の拡張や切り捨てが起きた場合に即座にコンパイルエラーまたはランタイム例外として検知できるようにする。
3. マイグレーション時の自動変換ツールの限界を直視する
レガシーマイグレーション用の自動変換ツール（トランスレータ）は、構文の置き換えは行ってくれても、「PL/I特有の暗黙の精度拡張がビジネスロジックに与えていた暗黙の整合性」までは理解してくれない。移行先のJava/C#コードにおいては、金額計算に関するすべての箇所で `BigDecimal` のスケールと `RoundingMode` をコードレビューで徹底的に監査し、テスト段階で網羅的な境界値テスト（桁あふれ寸前の値での検証）を実施すること。
—
結びにかえて
PL/Iという言語は、ハードウェアのアーキテクチャ（S/390、z/Architecture）と極限まで密結合した、美しくも恐ろしい言語である。その基本データ型である `FIXED BINARY` と `DECIMAL`、そしてリテラルが織りなす挙動の裏側には、計算機科学の歴史と、基幹システムが守り抜いてきた信頼性の重みが詰まっている。
「たかが定数の精度」と侮るなかれ。その微細な解釈のズレを見逃さないことこそが、真に信頼されるレガシーシステムの番人であり、次世代への安全な橋渡しを成し遂げるシステムアーキテクトの矜持なのである。
