メインフレームの心臓部を守る：FIXED DECIMALの真実とパック10進数の深淵
諸君、お疲れ様。今日もバッチジョブのログと格闘していることだろう。
メインフレームの移行プロジェクトや、20年選手となる基幹システムの保守を任されると、避けて通れないのが「なぜこの数値演算はこんな挙動をするのか？」という問いだ。特に、COBOLからPL/Iへ、あるいはその逆のマイグレーションにおいて、FIXED DECIMAL(p, q) の扱いは、多くのエンジニアを「桁落ち」という奈落の底へ突き落としてきた。
今回は、PL/Iにおけるパック10進数（COMP-3）の内部構造と、演算時の精度保持について、現場の知見を交えて徹底的に紐解こう。
—
1. パック10進数(COMP-3)の内部構造を理解する
まず、PL/Iで `DCL VAR FIXED DECIMAL(5, 2);` と宣言したとき、メモリ上では何が起きているか。
パック10進数は、1バイトに2桁の数値を詰め込む。最後尾（右端）の4ビットには符号（正なら `C`、負なら `D`）が入る。これがIBMメインフレームのハードウェアレベルで高速に処理される理由だ。
- メモリ上の配置: 5桁（p=5）であれば、3バイト（6桁分）を確保する。
- 内部表現: 例えば `123.45` は、`12 34 5C` となる。
この「ハードウェアで直接扱える」という特性が、金融計算において「誤差が出ない」という絶対的な信頼を生んでいる。浮動小数点数（FLOAT）のような、微細な端数誤差に悩まされることはない。ただし、宣言した精度（p）と位取り（q）をプログラマーが完璧に制御できればの話だが。
—
2. 実践：演算精度を維持するためのコーディング標準
PL/Iの演算ルールは、COBOL以上に柔軟で、それゆえに危険だ。演算結果の精度は、オペランドの精度に基づいて動的に決定される。
推奨される実装パターン
計算中に中間結果が溢れれば `FIXEDOVERFLOW` が発生する。これを防ぐには、BUILTIN関数を活用し、明示的に精度を制御するのがプロの作法だ。
1
/ —————————————————————– /
/ パック10進数による演算処理のサンプル /
/ —————————————————————– /
PAYROLL_CALC: PACKAGE;
/ メインプロシージャ /
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
/ 精度保持のための定義：p=9, q=2 (合計9桁) /
DCL SALARY_BASE FIXED DECIMAL(9, 2) INIT(0);
DCL TAX_RATE FIXED DECIMAL(3, 3) INIT(0.050);
DCL TAX_AMOUNT FIXED DECIMAL(9, 2) INIT(0);
ON FIXEDOVERFLOW BEGIN;
PUT SKIP LIST(‘警告: 演算中に桁溢れが発生しました。’);
END;
/ 計算ロジック：精度を意識する /
SALARY_BASE = 150000.00;
/
- 注意: TAX_RATE(3,3)とSALARY_BASE(9,2)の乗算結果は、
- PL/Iのルールでは(9+3, 2+3) = (12, 5)となる。
- これを(9, 2)に戻すため、ADDFIXED関数や代入時の自動切り捨てを理解しておく必要がある。
/
TAX_AMOUNT = SALARY_BASE TAX_RATE;
PUT SKIP EDIT(‘給与:’, SALARY_BASE, ‘ 税額:’, TAX_AMOUNT)
(A, F(12,2), A, F(12,2));
END MAIN_PROC;
END PAYROLL_CALC;
—
3. 現場で遭遇する「罠」：ONユニットと精度ルール
現場でよく見るトラブルに、「計算結果が予期せず切り捨てられる」、あるいは「なぜか演算途中でDECIMAL異常が出る」というものがある。
精度保持の鉄則
1. 中間変数の精度: 複雑な計算を行う際は、あえて大きな精度（例：FIXED DECIMAL(15, 5)など）を持つ一時変数を用意せよ。中途半端な精度で計算を進めると、演算のたびにPL/Iコンパイラが暗黙の変換を行い、予期せぬ精度劣化を招く。
2. ONユニットの活用: `FIXEDOVERFLOW` は、開発時にわざと発生させて挙動を確認しておくこと。本番環境でこの条件が発生したとき、ログにスタックトレースを残し、どの変数で溢れたかを特定できるようにしておくのが、保守効率を上げる秘訣だ。
3. VSAMアクセスとの兼ね合い: レコード定義（COPY句やINCLUDE）で定義されたフィールドは、必ずその定義通りの精度で変数を受け取ること。VSAMのデータ型とPL/Iの変数の精度が不一致だと、データ転送時にハードウェア例外が発生することがある。
—
4. スペシャリストからのアドバイス
「コンパイラが勝手にやってくれる」と信じるのは、大規模システム開発においては甘えだ。特に、既存のCOBOLコードをPL/Iに移行する際、COBOLの `COMP-3` 定義をそのままPL/Iの `FIXED DECIMAL` に置き換えるだけでは不十分なケースが多い。
PL/Iは、その言語仕様の広さゆえに「書き手によって品質が大きく変わる」言語だ。だからこそ、演算精度を定義した定数や、型定義の標準化を徹底してほしい。
もし、計算結果が合わないという不具合に当たったら、まずは `FIXED DECIMAL` の精度を見直せ。次に `OPTIONS(MAIN)` 内のコンパイラオプションを確認せよ。そして何より、「なぜその精度が必要なのか」という仕様の背景を、設計書に書き残すこと。それが、次にこのプログラムを触る「未来の自分」を救うことになる。
技術の深淵を覗き込む勇気を持て。メインフレームの世界は、まだまだ面白いぞ。
