【PL/I深掘り】BINARYビルトイン関数でハマる「精度の罠」と実務的ベストプラクティス
若手エンジニアからよく相談されるのが、「PL/Iの型変換で計算結果が微妙にズレる」「なぜか意図しない切り捨てが発生する」というトラブルだ。メインフレームの基幹バッチで、金額計算や件数カウントの数バイトの誤差は、そのまま決算の不整合という大事故に直結する。
今日は、`BINARY`ビルトイン関数を使いこなすための勘所と、`FIXED BINARY`への変換における「精度（Precision）」の制御について、現場の知見を交えて徹底解説しよう。
—
1. なぜBINARYビルトイン関数を正しく理解すべきなのか
PL/Iは「汎用プログラミング言語」という名の通り、データ型の柔軟性が非常に高い。しかし、その柔軟性が災いして、暗黙の型変換が意図せぬ精度低下を招くことがある。
特にVSAMファイルから読み込んだ`FIXED DECIMAL`（パック10進数）を、高速な演算のために`FIXED BINARY`へキャストする際、精度の指定を怠ると、コンパイラが「デフォルトの精度」を勝手に適用してしまう。この「コンパイラ任せ」こそが、デバッグを困難にする元凶だ。
2. BINARY関数の仕様と精度指定の黄金律
`BINARY(x, p, q)` 関数は、式 `x` を `FIXED BINARY(p, q)` 型に変換する。
- p (精度): 全ビット数。
- q (位取り): 小数点以下のビット数。
ここで重要なのは、「pとqを明示しない場合、コンパイラは実装依存のデフォルト値を選択する」ということだ。メインフレームの現場では、このデフォルト値が環境（コンパイラオプションやシステム設定）によって揺らぐリスクを常に想定しなければならない。
実践的なコーディング例
以下のコードを見てほしい。VSAMから読み込んだ金額（`PIC S9(9)V99`）を演算用に変換する際の作法だ。
1
//
/ サンプルプログラム: 型変換における精度制御 /
//
MY_PROC: PROCEDURE OPTIONS(MAIN);
DCL RAW_AMOUNT FIXED DEC(11, 2) INIT(12345.67);
DCL BIN_AMOUNT FIXED BIN(31, 0); / 演算用ワーク /
/
- [教訓]
- 第2引数(p)と第3引数(q)を明示する。
- 特に計算過程でのオーバーフローを防ぐため、
- 変換先には十分なビット数を確保すること。
/
BIN_AMOUNT = BINARY(RAW_AMOUNT, 31, 0);
/
- ONユニットによる例外制御の重要性
- 変換時にサイズが超過する場合に備え、CONVERSION例外を捕捉する。
/
ON CONVERSION BEGIN;
PUT SKIP LIST(‘データ変換エラーが発生しました。値が大きすぎます。’);
SIGNAL ERROR;
END;
PUT SKIP EDIT(‘変換結果:’, BIN_AMOUNT) (A, F(12));
END MY_PROC;
—
3. 現場で「唸る」ための3つのポイント
① 切り捨てか、丸めか？
`FIXED BINARY`への変換時、PL/Iは基本的に「切り捨て（Truncation）」を行う。もし四捨五入が必要であれば、変換前に`ROUND`ビルトイン関数を挟む必要がある。
「計算結果が1円足りない」というバグの多くは、この変換時の切り捨てを考慮していないことに起因する。
② VSAMアクセスとパック10進数との付き合い方
VSAMの定義（COBOLコピーブック等）で`COMP-3`（パック10進数）となっているデータを扱う際、いきなり演算してはならない。必ず一度中間変数へ格納し、必要に応じて`BINARY`関数で型を揃えてから演算ループに入る。これが、大規模バッチで計算の整合性を保つための「防波堤」だ。
③ ONユニットの活用
`CONVERSION`例外を甘く見てはいけない。型変換時に値が収まりきらない場合、システムは容赦なく異常終了コードを吐く。上記コード例のように、`ON CONVERSION`ブロックを適切に配置し、エラー発生時のログ出力と後処理を確実に記述することが、保守性の高いコードを作るコツだ。
—
結びに代えて
PL/Iは古くからある言語だが、その堅牢さは現代のシステムでも色褪せない。特に`BINARY`ビルトイン関数のような、一見地味な型変換関数をどう制御するかで、そのエンジニアの「メインフレームへの理解度」が透けて見えるものだ。
「とりあえず動く」コードから、「精度を厳密に定義した」コードへ。皆さんの書く一行が、明日誰かのデバッグの手間を減らすことを願っている。
もし、特定の複雑な計算ロジックで数値が合わないといった悩みがあれば、いつでも相談してくれ。この言語の癖を知り尽くしたアーキテクトとして、また一緒に紐解いていこう。
