PL/Iの異端児か、神の機能か：`PRECISION`ビルトイン関数とメモリ再割り当ての深淵
メインフレームの現場で何十年も稼働し続ける基幹システムのソースコードを覗くと、現代のオブジェクト指向言語の常識では計り知れない、PL/I特有の「底知れぬ自由度」に直面することがある。JavaやC#の厳格な型安全性に慣れ親しんだモダンなマイグレーションエンジニアたちが、こぞって頭を抱えるポイントの一つが、PL/Iにおける変数名の命名規則の緩さと、言語仕様上の「予約語を持たない」という圧倒的な設計思想、そして今回メスを入れるビルトイン関数 `PRECISION`（あるいは組み込み関数としての精度制御）による動的なデータ制御の挙動だ。
「変数宣言時の桁数（精度）を、実行時に自在に変更できる」――一見すると、可変長データを扱うバッチ処理においてこれほど強力な武器はないように思える。しかし、IBM Enterprise PL/Iコンパイラがこのコードをどのように解釈し、S390/z/Architectureのハードウェアレベルでどのような命令に翻訳しているかを知らなければ、生産本番環境での突発的なアベンド（ABEND）や、データ破壊という悪夢から逃れることはできない。
今回は、基幹システムのテックリードやレガシー移行アーキテクトに向けて、`PRECISION`関数が引き起こす内部処理のメカニズム、メモリ再割り当ての隠れたオーバーヘッド、そしてDB2やCICSの現場で踏み抜きがちなエッジケースを、容赦ない実務の視点から徹底的に解剖する。
—
1. `PRECISION`関数の本質と内部処理のメカニズム
まず、PL/Iにおける `PRECISION(x, p [, q])` （または組み込み関数 `PREC`）の仕様を正確に押さえておこう。この関数は、算術式や変数の精度（全体桁数 $p$ と小数点以下桁数 $q$）を明示的に変更した新しい一時的な値を返す。
しかし、ここでJava出身のエンジニアが勘違いしやすい最大の罠がある。それは、「既存の変数の属性そのものを書き換えているわけではない」という点だ。
1
DCL WK_AMT FIXED DEC(9,2) INIT(12345.67);
DCL WK_EXT FIXED DEC(15,2);
/ PRECISION関数による精度の拡張 /
WK_EXT = PRECISION(WK_AMT, 15, 2);
このコードを実行したとき、コンパイラは何をしているのか。`PRECISION` が評価されると、コンパイラは実行時（あるいは最適化されたコード内）において、指定された新しい精度（この場合は `FIXED DEC(15,2)`）を持つ一時的なワーキングストレージ（Temporary Storage）を暗黙裏に割り当てる。そして、元の変数 `WK_AMT` の値をその一時領域へとパッキングし直し、パディングや丸め処理を行った上で、代入先の `WK_EXT` へ引き渡すのである。
メモリ再割り当てのオーバーヘッドとコンパイラ最適化
もし、この `PRECISION` の評価が、数百万件をループする月次バッチの内部で、しかも記述ミスによって都度評価されるような構造になっていたらどうなるか。
1
/ 悪夢のループ処理例 /
DO I = 1 TO 10000000;
/ ループ内で動的に精度変更を伴う演算を行う /
G_TOTAL = G_TOTAL + PRECISION(TBL_VAL(I), 15, 4);
END;
IBM Enterprise PL/I コンパイラ（OPTIMIZE(2)以上）は、多くの場合、ループ外へのコード移動（Code Hoisting）やレジスタ割り当ての最適化を試みる。しかし、データ属性が動的に変動する可能性があるとコンパイラが判断した場合、厳密なセマンティクスを維持するために、ループのイテレーションごとにテンポラリ領域のスタック割り当て（あるいは解放）に類似した処理、あるいはパックデシマル（COMP-3）の長大桁数に対するシフト・アラインメント命令（`ZAP`, `SRP` など）を生成せざるを得なくなる。
これが、バッチ処理のCPU使用率（S/C）を高騰させ、スループットを著しく劣化させる隠れた主犯格なのだ。
—
2. パックデシマルの内部符号反転バグとエッジケース
メインフレームの基幹系で最も恐れられている障害の一つが、パックデシマル（`FIXED DECIMAL`）のデータ例外（S0C7アベンド）や、符号（ゾーン・ニブル）の意図しない反転による数値化けである。
`PRECISION` 関数を用いて精度を縮小、あるいは拡張する際、コンパイラは内部の符号ニブル（通常、末尾バイトの下位4ビットに `C`, `D`, `F` などが格納される）を適切に維持しようとする。だが、以下のようなケースで予期せぬバグが顔を出す。
1. オーバフロー時の丸め（Truncation）と例外
高精度のデータを低い精度に `PRECISION` で無理やり押し込めようとした際、上位桁の切り捨てが発生する。PL/Iのデフォルトでは、サイズエラー（`SIZE`条件）が無効化されている場合、警告なしに上位桁が切り捨てられ、最悪の場合、有効数字が失われた不正な数値が後続のDB2更新処理に流し込まれる。
2. 符号付きゼロ（Positive/Negative Zero）の扱いの差異
マイグレーション時に、PL/Iの `PRECISION` 演算結果と、移行先（Javaの `BigDecimal` や C#の `decimal`）の間で、マイナスゼロの丸め挙動やパディングの差異により、突合テストで一致率が微妙に割れる現象が頻発する。
—
3. 現場で役立つ！堅牢なPL/Iコード実装パターン
では、アーキテクトとして我々はどう設計し、実装すべきなのか。動的な精度変更が必要な場面では、場当たり的な `PRECISION` 関数の乱用を避け、明示的なデータ定義とデータ構造のレイアウト（`OVERLAY` や `UNSPEC`）を活用するか、あるいはあらかじめ十分な精度を持った共通定義（マスター構造体）を設計すべきである。
以下に、安全かつ高パフォーマンスを意識した実務的なPL/Iコードの断片を示す。
1
——————————————————————
- モジュール名: MIGR001P
- 概要 : 精度変更を安全に行うための定石とエラーハンドリング
——————————————————————
MIGR001P: PROC OPTIONS(MAIN);
DCL SRC_DATA FIXED DEC(9,2) INIT(9876543.21);
DCL DST_DATA FIXED DEC(13,4) INIT(0);
DCL SAFE_CONV FIXED DEC(13,4) INIT(0);
/ SIZE条件を有効化し、桁あふれを確実に検知する /
ON SIZE BEGIN;
DISPLAY ‘【SEVERE】数値の切り捨て（桁あふれ）を検出しました。’;
/ 異常終了またはエラールーチンへ分岐 /
SIGNAL ERROR;
END;
/ 1. 非推奨：不必要なループ内での動的精度変更の回避 /
/ 2. 推奨：明示的な型変換とセーフティネットの構築 /
BEGIN;
DCL TEMP_WORK FIXED DEC(13,4);
/ PRECISIONを使用する場合は、あらかじめ領域のサイズを確定させる /
TEMP_WORK = PRECISION(SRC_DATA, 13, 4);
DST_DATA = TEMP_WORK;
DISPLAY ‘変換後データ: ‘ || EDIT(DST_DATA, ‘999,999,999.9999’);
END;
RETURN;
END MIGR001P;
—
4. 埋め込みSQL（DB2）およびCICSオンラインにおけるエッジケース
この問題は、単体バッチの領域にとどまらない。特にCICSオンラインの擬似会話型（Pseudo-conversational）トランザクションや、DB2（Embedded SQL）との連携において、`PRECISION` の挙動は致命的な影響を持つ。
CICSでのコールドスタート・ストレージ破壊
CICSのゴッサム領域（`GETMAIN`）やDFHCOMMAREAにデータを渡す際、`PRECISION` によって暗黙的に生成された一時変数が、意図しないストレージ長（ALIGNMENT属性の差異によるパディング含む）を持ち、COMMAREAのオフセットを狂わせるケースがある。これにより、次画面へ引き継ぐべき構造体の後半部分が文字化けし、トランザクションが突如としてAEIVやASRAといった恐怖のアベンドに見舞われる。
DB2ホスト変数との型不一致
ホスト変数として定義されたデータに対して `PRECISION` 関数を通した結果を `EXEC SQL UPDATE …` のパラメータに渡すと、DB2プリコンパイラとPL/Iコンパイラの間のデータ記述子（SQLDA）の不整合を引き起こすことがある。DB2側は厳密なDECIMAL(15,2)を期待しているのに、PL/I側が一時的に異なる精度の記述子を生成して渡してしまうと、SQLCODE -301（ホスト変数のデータ型が無効）や SQLCODE -420（文字から数値への変換エラー）が返される。
—
5. マイグレーション（レガシー近代化）への提言
PL/IからJava（Spring Boot）やC#へシステムを移行する際、こうした「PL/Iコンパイラが隠蔽していた動的精度のマジック」をそのままターゲット言語に直訳しようとすると、必ず痛い目を見る。
Javaの `BigDecimal` で同等の動的精度変更を行おうとすると、以下のような冗長なコードが必要になる。
// Javaにおける動的精度・スケール変更の例
BigDecimal srcData = new BigDecimal(“9876543.21”);
BigDecimal dstData = srcData.setScale(4, RoundingMode.HALF_UP);
移行設計においては、以下のアーキテクチャ方針を徹底すべきである。
1. 暗黙の型変換の排除：ソースコード解析フェーズにおいて、`PRECISION` や暗黙のデータキャストが使われている箇所をすべて洗い出し、入出力インターフェースの精度を固定化する。
2. テストカバレッジの担保：丸め誤差（Rounding Mode）の仕様差異が業務上の金額計算の端数処理に影響を与えないよう、マイグレーション前後のリグレッションテストで1円単位の突き合わせを自動化する。
PL/Iの `PRECISION` は、ハードウェア資源が極めて高価で、メモリの1バイト、CPUの1サイクルを絞り出していた時代のエースたちの知恵の結晶である。しかし、現代のオープン系マイグレーションにおいては、その「便利すぎる動的処理」が技術的負債の温床になり得る。
アーキテクトたる者、その裏で何が起きているのかをコンパイラ視点、さらにはメインフレームのハードウェア視点で完全に透視し、安全で堅牢なシステム設計へと昇華させなければならない。
