こんにちは。日夜、メインフレームのうなりを上げるファン音を聞きながら、COBOLやPL/Iの巨大なソースコードと格闘している皆さん、お疲れ様です。
基幹システムの保守やマイグレーション現場において、最も恐ろしいものの一つが「数値データの桁落ち・四捨五入エラー」です。特にPL/Iの `FIXED DECIMAL`（固定小数点数）を扱う際、何気なく記述した代入文やビルトイン関数のせいで、夜間バッチが突然のOC71（データ例外）や、想定外の金額ズレを起こして冷や汗をかいた経験はありませんか？
今回は、PL/Iにおける `DECIMAL` ビルトイン関数を用いた型変換にスポットを当て、スケール調整の裏側と、精度を完全に維持するための実践的なノウハウを、現場の空気感を交えながら徹底的に解説します。
—
1. なぜ `DECIMAL` ビルトイン関数が必要なのか？
PL/Iは非常に懐の深い言語で、異なるデータ型の間でもコンパイラが勝手に型変換（暗黙の型変換）を行ってくれます。例えば、`FIXED BINARY`（2進固定小数点数）で持っている内部カウンタを、そのまま `FIXED DECIMAL`（10進ゾーン/パック10進数）の定義領域に放り込んでも、一応は動きます。
しかし、ここに大きな罠があります。「コンパイラ任せの暗黙の変換」は、意図しない精度の切り捨てや、中間演算でのオーバーフローを引き起こす元凶なのです。
特にVSAMファイルへの書き込みや、外部の他システムへ渡すレコードレイアウト（COPY句やINCLUDEで展開される構造体）を構築する際、フィールドの属性が厳密に一致していないと、データ整合性エラーの一因になります。ここで `DECIMAL` ビルトイン関数を明示的に使用し、精度（Precision）とスケール（Scale）をプログラマの意図通りにコントロールすることが、プロたるエンジニアの作法です。
—
2. `DECIMAL` 関数の仕様と内部的なスケール調整
まずは基本を確認しましょう。`DECIMAL` ビルトイン関数の構文は以下の通りです。
DECIMAL(x [, p [, q]])
- x: 変換元の式（FIXED BINARY, FLOAT, 甚至いは他のDECIMALなど）
- p: 変換後の全体桁数（精度: Precision）
- q: 小数点以下の桁数（スケール: Scale）
内部で何が行われているか？
コンパイラは、引数 `x` をいったんDECIMAL形式に直す際、指定された `p` と `q` に合わせてデータの位置合わせ（アライメント）と丸め（Truncation / Rounding）を行います。
ここで重要なのは、「整数部の桁数が足りなくなるような切り詰めが発生した場合、コンパイル時あるいは実行時に重大な問題になる」という点です。また、演算途中のモメンタムにおいて、スケール `q` の調整を誤ると、小数点以下の切り捨てによって累積誤差（いわゆる1円のズレ）が発生します。
—
3. 実践！VSAMレコード入出力とONユニットを伴う堅牢なコード例
百聞は一見に如かず。実際のバッチプログラムでよくある、バイナリで計算された金額データを、商用フォーマット（パック10進数）のVSAMレコードへ安全に詰め替える処理を書いてみましょう。
ここでは、データ例外（コンバージョンエラーなど）が発生した際に備えて、`ON` ユニットによる例外処理の枠組みもしっかりと組み込みます。
/ /
/ プログラム名: MTRLCONV /
/ 概要: FIXED BINARYの計算結果をDECIMALへ安全に変換し /
/ VSAMレコードへ格納するサンプル /
/ /
MTRLCONV: PROC OPTIONS(MAIN);
DCL 1 OUT_RECORD,
5 ACCT_ID CHAR(8), / 口座ID /
5 RAW_AMOUNT FIXED BIN(31), / 内部計算用(バイナリ) /
5 EDIT_AMOUNT FIXED DEC(11, 2); / 出力用パック10進数(整数9桁, 小数2桁) /
DCL W_CALC_VAL FLOAT DEC(16); / 浮動小数点ワーク /
DCL 1 ERR_LOG,
5 ERR_CODE CHAR(4),
5 ERR_MSG CHAR(50);
/ — データ例外（CONVERSION）発生時のONユニット — /
ON CONVERSION BEGIN;
PUT SKIP EDIT (‘[SEVERE] データ変換エラーを検知しました。処理を中断します。’) (A);
ERR_CODE = ‘CV01’;
ERR_MSG = ‘FIXED BIN/DECIMAL CONVERSION ERROR’;
SIGNAL CONDITION(ABORT_RTN);
END;
/ — 異常終了用コンディション — /
ON CONDITION(ABORT_RTN) BEGIN;
PUT SKIP EDIT (‘エラーコード: ‘, ERR_CODE, ‘ 理由: ‘, ERR_MSG) (A, A, A, A);
CLOSE FILE(VSAMOUT);
STOP;
END;
/ ダミーデータのセット（実際はDBやファイルから読み込む） /
ACCT_ID = ‘ACC99991’;
RAW_AMOUNT = 123456789; / 内部バイナリ値 /
/ ————————————————– /
/ DECIMALビルトイン関数による厳密な型変換とスケール調整 /
/ ————————————————– /
/
- RAW_AMOUNTを、全体11桁、小数点以下2桁のFIXED DECIMALに変換する。
- ここで DECIMAL(RAW_AMOUNT, 11, 2) と明示することで、
- コンパイラの暗黙の仮定に頼らず、意図したスケーリングを強制する。
/
/ 一度、消費税率（1.10）を掛け合わせる複雑な計算を想定 /
W_CALC_VAL = FLOAT(RAW_AMOUNT) 1.10;
/ 計算結果を、指定の精度を持つDECIMALへ確実に落とし込む /
EDIT_AMOUNT = DECIMAL(W_CALC_VAL, 11, 2);
/ デバッグ用コンソール出力 /
PUT SKIP EDIT (‘口座ID: ‘, ACCT_ID,
‘ 変換後金額: ‘, EDIT_AMOUNT)
(A, A, A, F(11,2));
/ 通常はこの後、VSAMファイルへのWRITEを行う /
/ WRITE FILE(VSAMOUT) FROM(OUT_RECORD); /
END MTRLCONV;
—
4. 現場のシニアが教える！デバッグとコーディングの黄金律
長年メインフレームを見てきたからこそ言える、`DECIMAL` 変換にまつわるトラブルシューティングの極意をいくつか授けましょう。
① ターゲットの定義（ピクチャー句やDECIMALの精度）をケチらない
「どうせそんなに大きな金額は入らないだろう」と `DECIMAL(7,2)` などと小さく見積もると、数年後のインフレやデータ増加に伴って一瞬でオーバーフロー（S0C7の遠因）を起こします。構造体の定義変更は影響範囲が広いため、最初から余裕を持った精度（例: `DECIMAL(11,2)` や `DECIMAL(15,2)`）を設計基準としてチーム内で共有してください。
② 暗黙の変換を許すな（コンパイルオプションの活用）
Enterprise PL/Iコンパイラを使用する場合、意図しないデータ型の混在や暗黙の変換に対して警告を出させるコンパイルオプション（例えば `RULES(ALL)` など）を適切に設定し、JCLのコンパイルステップで厳しくチェックする体制を維持しましょう。警告を無視して通したコードが、月末・年末のクリティカルなバッチを止める犯人になります。
③ 浮動小数点（FLOAT）を経由する場合の丸め誤差に注意
上記のサンプルコードのように `FLOAT` を経由して `DECIMAL` に戻す場合、2進数の無限小数に起因する微小な誤差が混入することがあります。金銭計算などで厳密性が求められる場合は、極力 `FIXED BINARY` 同士、あるいは最初から `FIXED DECIMAL` 同士で演算を行い、最後に `DECIMAL` ビルトイン関数で丸めの桁数を整えるのが王道です。
—
おわりに
PL/Iの `DECIMAL` ビルトイン関数は、単なる「型を合わせるための道具」ではありません。メインフレームという堅牢なプラットフォームの上で、ビジネスデータの信頼性を担保するための極めて重要な防壁です。
移行プロジェクトや日々の保守において、データ定義の裏側にある「精度のストーリー」を意識できるようになれば、あなたも立派なPL/Iアーキテクトです。次のバッチ改修では、ぜひ自信を持って正確な精度指定をコードに刻んでください。
