PL/I「PRECISION関数」の魔力：基幹システムを揺るがす数値演算の罠とモダナイゼーションの定石
メインフレームの心臓部で稼働するPL/Iプログラムにおいて、数値データの精度（Precision）とスケール（Scale）の制御は、単なる「型合わせ」ではない。それは、1円の狂いも許されない金融勘定系システムの信頼性を担保し、時には夜間バッチをアベンド（ABEND）の淵から救うための極めて高度なエンジニアリング領域である。
特に、`PRECISION`（あるいは組み込み関数の `PREC`）を扱う際、コンパイラの暗黙の型昇格（Promotion）や、固定小数点数（`FIXED BINARY` / `FIXED DECIMAL`）の内部表現の壁に阻まれ、予期せぬオーバーフローやデータ切り捨てに直面したアーキテクトは少なくないはずだ。
本稿では、PL/Iにおける `PRECISION` 関数の厳密な仕様と挙動を紐解きつつ、JavaやC#へのマイグレーションを見据えたエッジケースの対策、そして基幹システムの現場で培った泥臭いトラブルシューティングの知見を共有する。
—
1. PRECISION関数の基本仕様と「見えないコンパイラ最適化」
`PRECISION(expression, p [, q])` は、式（expression）の結果を指定された精度 `p` とスケール `q` を持つ `FIXED` 値に変換するための強力な組み込み関数だ。
しかし、ここで多くのエンジニアが誤解しているのは、「指定した精度への変換は、単なる見栄えの調整ではなく、演算途中の中間バッファの桁溢れを防ぐための防壁である」という点である。
内部表現とコンパイラの挙動
PL/I（IBM Enterprise PL/Iなど）では、`FIXED DECIMAL` はパック10進数（Packed Decimal）、`FIXED BINARY` は2進整数として扱われる。`PRECISION` 関数を評価する際、コンパイラは以下のように振る舞う。
1. 引数の評価: 第1引数の式が持つ現在の精度とスケールに基づき、一時的なワークエリア（通常は最大精度）で演算が行われる。
2. 丸め（Rounding）の発生: スケール `q` が元の値より小さくなる場合、あるいは整数部を収めるために精度 `p` が小さくなる場合、端数の切り捨て（Truncation）または丸めが発生する。PL/Iのデフォルトでは切り捨て（Truncation）となるため、四捨五入が必要な場合は `ROUND` 関数併用の設計が不可欠である。
3. オーバーフローの判定: 変換後の整数部の桁数（`p – q`）が、実際のデータの整数部を収しきれない場合、その瞬間に `FIXEDOVERFLOW`（略称: `FOFL`）条件が発火する。
—
2. 実務で遭遇する地獄：エッジケースとトラブルシューティング
オンライン（CICS）やバッチ（DB2/IMS）の現場で、`PRECISION` や算術代入に起因するトラブルは、往々にして「本番環境のデータ量になって初めて顕在化する」。
エッジケース①：DB2埋め込みSQLとの型不整合
CICS環境下で、DB2から `DECIMAL(11,2)` のカラムデータを `FIXED BINARY(31,0)` の変数に受け渡す際、暗黙の精度変換が発生する。ここで `PRECISION` 関数を適切に挟まないと、高位桁のデータがロストするだけでなく、マイグレーション先のJava（`BigDecimal` から `int` へのキャスト等）で深刻なバグを引き起こす温床となる。
エッジケース②：パックデシマルの符号反転バグとダンプ解析
レガシーデータが何らかの理由で破損し、パックデシマルのゾーン部（最下位バイトの符号ニブル）が不正な値になった状態で `PRECISION` 変換を通すと、コンパイラはS0C7アベンド（DATA EXCEPTION）を発生させる。
SYSUDUMPやCEEDUMPを解析する際、当該変数のメモリ上の16進数表現（例: `1234567F` が `1234567E` になっている等）を確認し、どの演算ステップで精度の再割り当てが行われたかを特定するのが、シニアアーキテクトの腕の見せ所となる。
—
3. 実践：PL/Iコード例と安全な数値制御
以下のサンプルコードは、基幹システムの金額計算バッチを想定したものである。`PRECISION` 関数を用いて、オーバーフローを回避しながら安全にスケールを調整するパターンを示す。
1
——————————————————————
- モジュール名: MBNK0101
- 概要: 口座残高の金利計算と精度・オーバーフロー制御のサンプル
——————————————————————
MBNK0101: PROC OPTIONS(MAIN);
DCL W_BALANCE FIXED DEC(11,2) INIT(987654321.99); / 元本 /
DCL W_RATE FIXED DEC(5,4) INIT(0.0125); / 利率 /
DCL W_INTEREST FIXED DEC(11,4); / 利息（中間） /
DCL W_ROUND_INT FIXED DEC(11,2); / 利息（丸め後）/
/ 1. オンコンディション（割り込み）の捕捉設定 /
ON FIXEDOVERFLOW
BEGIN;
DISPLAY(‘【SEVERE】固定小数点オーバーフローを検知しました。処理を中断します。’);
/ ここにログ出力や異常終了コード設定を記述 /
SIGNAL ERROR;
END;
/ 2. 演算とPRECISION関数による明示的な精度・スケール制御 /
/ 精度(15,6)の一時ワークエリアを確保しつつ演算を実施 /
W_INTEREST = PRECISION(W_BALANCE W_RATE, 15, 6);
DISPLAY(‘計算直後の利息（精度15, 6スケール）: ‘ || W_INTEREST);
/ 3. 最終的な表示用（スケール2桁）への丸めと代入 /
/ ここでPRECISIONを使うことで、意図しない桁落ちを明示的にコントロール /
W_ROUND_INT = ROUND(W_INTEREST, 2);
DISPLAY(‘確定利息（精度11, 2スケール）: ‘ || W_ROUND_INT);
END MBNK0101;
—
4. モダナイゼーション（Java / C# 移行）へのインプリケーション
レガシーマイグレーションのプロジェクトにおいて、PL/Iの `FIXED DECIMAL` および `PRECISION` の挙動をモダン言語へ正確に移植することは、プロジェクトの成否を分ける。
Java (`BigDecimal`) への置き換え戦略
PL/Iの `PRECISION(expr, p, q)` は、Javaの `java.math.BigDecimal` のコンストラクタや `setScale()` メソッド、および `MathContext` に直訳することができる。
- PL/Iの挙動: `FIXED DEC(p, q)` は最大 `p` 桁、小数点以下 `q` 桁。
- Javaの対応:
BigDecimal balance = new BigDecimal(“987654321.99”);
BigDecimal rate = new BigDecimal(“0.0125”);
// PRECISION(expr, 15, 6) の相当処理
BigDecimal interest = balance.multiply(rate)
.setScale(6, BigDecimal.ROUND_DOWN); // PL/Iのデフォルト切り捨てに合わせる
// 最終的なスケール調整と丸め
BigDecimal roundInt = interest.setScale(2, BigDecimal.ROUND_HALF_UP);
マイグレーション時に見落とされがちなのが、「PL/Iではオーバーフロー時に強制終了（`FIXEDOVERFLOW`）していた処理が、Java移行後に何のエラーも出ずに丸められてしまう（サイレントエラー）」という現象である。この差異を埋めるため、移行先の共通ライブラリ側でオーバーフロー検知のバリデーションを厳格に実装する必要がある。
—
5. 結びにかえて
PL/Iの `PRECISION` 関数は、単なる文法要素の1つではない。それは、ハードウェアの制約とビジネスロジックの厳密さを繋ぐ、極めて洗練されたインターフェースである。
レガシーシステムのブラックボックスを剥ぎ取り、その背後にあるコンパイラの意図や数値演算の哲学を理解すること。それこそが、メインフレームの知見を受け継ぐ真のシステムアーキテクトに求められる素養であり、次世代への確実なバトンタッチの第一歩となる。
