精度と丸めの罠：PL/Iの `BINARY` ビルトイン関数が基幹システムを揺るがす瞬間
メインフレームの現場で長く生きていると、「たかが型変換、されど型変換」という言葉がいかに重い痛みを伴って身に染みてくる。JavaやC#といったモダン言語に慣れ親しんだ若いエンジニアたちが、レガシー移行プロジェクトの現場で最も頭を抱え、そして最も派手にシステムを炎上させるポイントの一つが、このPL/Iにおける数値データ型の制御、特に `BINARY` ビルトイン関数を用いたキャストの挙動である。
「数値をバイナリに変えるだけだろ？ 何が難しいんだ」
そう高をくくったプログラマが、深夜のバッチ処理で突如発生した `S0C7` アベンド（データ例外）や、金額計算における「1円のズレ」の調査に何日も費やす姿を、私は幾度となく目撃してきた。IBMメインフレームのコンパイラは、極めて忠実にコードを解釈するが、それは時にプログラマの意図しない暗黙の型変換や、ハードウェアレベルの演算制約を引き起こす。
今回は、基幹システムのテックリードや、将来のオープン系マイグレーションを控えたアーキテクトに向けて、`BINARY` ビルトイン関数が持つ本質的な挙動と、それにまつわるエッジケースの深淵を徹底的に解き明かしていこう。
—
1. `BINARY` ビルトイン関数の仕様と精度指定のメカニズム
PL/Iにおける `BINARY`（または `BIN`）ビルトイン関数は、任意の数値を `FIXED BINARY` または `FLOAT BINARY` に変換するための強力なツールである。基本的な構文は以下の通りだ。
1
DCL WK_RESULT FIXED BIN(31);
WK_RESULT = BINARY(SOURCE_VAL, PRECISION, SCALE);
ここでエンジニアが最も誤解しやすいのが、第2引数（精度：Precision）と第3引数（スケール：Scale、小数点以下の桁数）の指定方法、そしてソース値との関係性である。
FIXED BINARY の内部表現とビット数の壁
IBM Enterprise PL/Iコンパイラにおいて、`FIXED BIN(p)` の `p` は「総ビット数（符号を除く、または含む文脈での有効桁数）」を意味する。C言語の `int` や `long` とは異なり、PL/Iでは任意のビット長を定義できる。
- `FIXED BIN(1)` から `FIXED BIN(15)` まで：内部的には 2バイト（Hファワード）の領域を使用。
- `FIXED BIN(16)` から `FIXED BIN(31)` まで：内部的には 4バイト（Fファワード）の領域を使用。
- `FIXED BIN(32)` から `FIXED BIN(63)` まで：内部的には 8バイト（Dファワード）の領域を使用。
ここで重要なのは、`BINARY(X, p, q)` を呼び出した際、コンパイラがどのように丸めや切り捨てを行うかだ。例えば、パックデシマル（`FIXED DECIMAL`）や文字列表現からバイナリへ変換する際、指定した `p` や `q` の枠に入りきらない端数は、「算術丸め（Round）」ではなく「切り捨て（Truncation）」に近い挙動を示すケースがある。特にスケール（小数部）の桁落ちが発生した瞬間、下位ビットが容赦なく切り落とされるため、累積計算を行っているロジックでは致命的な誤差を生む。
—
2. 実践コード：ポインタ操作と動的メモリにおける型変換の罠
基幹システムの高速バッチや、ストレージ直叩きの非構造化データを扱うプログラムでは、ベース変数（Based変数）とポインタを駆使した動的メモリ操作が日常茶飯事に行われる。ここで `BINARY` 関数を誤用すると、ストレージ破壊やアベンドの温床となる。
以下の実用的なコード例を見てほしい。ストレージから読み込んだ生バイナリデータを `BASED` 変数経由で解釈し、計算処理を行うモジュールの断片だ。
1
/ ————————————————– /
/ 動的メモリ領域とBINARY変換の検証サンプル /
/ ————————————————– /
TEST_BIN_CONV: PROC OPTIONS(MAIN);
DCL PTR_RAW_DATA POINTER;
DCL 1 RAW_RECORD BASED(PTR_RAW_DATA),
5 REC_ID CHAR(4),
5 RAW_VAL CHAR(8); コピーフランジ由来のゾーン十進数文字列
DCL WK_DEC_VAL FIXED DEC(15,2);
DCL WK_BIN_VAL FIXED BIN(31);
DCL Ptr POINTER;
/ 模擬的にメモリを割り当て、不正または境界値データをセット /
ALLOCATE RAW_RECORD SET(PTR_RAW_DATA);
REC_ID = ‘A001’;
RAW_VAL = ‘000012345’; / 意図された数値文字列 /
/ 【危険なポイント】
- CHARデータを直接または曖昧なキャストを挟んでBINARY変換すると、
- コンパイラの暗黙の変換ルールにより、意図しない解釈がなされることがある。
- 安全のため、一度FIXED DECIMALを経由するべきである。
/
WK_DEC_VAL = FIXED(RAW_VAL, 15, 2);
/ BINARYビルトイン関数による型変換 /
/ 第2引数に31を指定し、32ビット符号付き整数へマッピング /
WK_BIN_VAL = BINARY(WK_DEC_VAL, 31, 0);
DISPLAY(‘CONVERTED BINARY VALUE: ‘ || TRIM(WK_BIN_VAL));
FREE RAW_RECORD;
END TEST_BIN_CONV;
このコードにおいて、もし `WK_DEC_VAL` を経由せず、文字データを直接 `BINARY(RAW_VAL, 31, 0)` などとやろうものなら、コンパイラや処理系によってはゾーン文字のアスキー/エビデンスコードのまま解釈されるか、最悪の場合、実行時データ例外（S0C7）を引き起こす。メインフレームのハードウェアは、型に非常に厳格だ。
—
3. コンパイラオプションと最適化の闇
Enterprise PL/Iコンパイラを使用する際、最適化レベル（`OPT(2)` や `OPT(3)`）を上げると、コンパイラはコードの効率化のために驚くべきインライン展開やレジスタ割り当てを行う。
ここで問題になるのが、オーバーフロー検出（`OVERFLOW` / `FIXEDOVERFLOW` 条件）の有無である。
- コンパイルオプションに `LIMIT(FIXEDDECIMAL)` や `STGOWF`、あるいはデフォルトのままで `FOFL` が有効になっている場合、`BINARY` 変換時に桁あふれが発生すると即座にシグナル（条件）が送出され、適切に `ON CONDITION` が組まれていなければアベンドする。
- しかし、パフォーマンスチューニングの一環として `NOFIXEDOVERFLOW` を指定してコンパイルしてしまうと、オーバーフローが発生してもエラーにならず、上位ビットがサイレントに切り捨てられたまま後続の計算に値が使われる。
金融系のシステムにおいて、金額データがサイレントに切り捨てられることの恐怖を想像してほしい。監査で一発レッドカードをくらうレベルの重大インシデントになり得る。`BINARY` 関数を使用する箇所を含むプログラム群をコンパイルする際は、最適化レベルだけでなく、算術例外に関するオプション（`TRAP` / `NOTRAP`）の挙動を全モジュールで統一・把握しておくことが、シニアアーキテクトとしての必須要件である。
—
4. エッジケース対策：DB2埋め込みSQLとCICSオンライン処理
基幹システムの現場では、PL/Iプログラムは単体で動くことは少ない。DB2の埋め込みSQL（SQL）や、CICSの画面・通信制御（COMMAREA）と密接に連携している。
DB2ホスト変数としての `FIXED BINARY`
DB2のテーブル定義において、金額や数量が `DECIMAL(p,q)` や `INTEGER`（これはPL/Iの `FIXED BIN(31)` に相当）で定義されている場合、PL/I側で `BINARY` 関数を使って値を加工してからホスト変数に渡すケースがある。
ここで、DB2のデータ型とPL/Iの `BINARY` 精度の間に不一致があると、SQL実行時に `-302` エラー（数値変数値が無効、または範囲外）が多発する。
特に、DB2の `SMALLINT` はPL/Iの `FIXED BIN(15)` に、`INTEGER` は `FIXED BIN(31)` に完璧に一致させなければならない。中途半端に `BINARY(X, 20, 0)` などと指定すると、SQLコプロセッサが型ミスマッチを検出し、プレコンパイル時または実行時に容赦なくエラーを吐く。
CICS環境でのバイナリデータ交換
CICSの `COMMAREA` や一時記憶キュー（TSQ）を介して、他システム（例えばオープン系のJavaサーバや、別のCOBOLバッチ）とバイナリデータをやり取りする場合、メインフレーム特有の「エンディアン（Big-Endian）」と「バイナリ表現」の壁にぶつかる。
PL/Iの `FIXED BINARY` は当然ビッグエンディアンで格納されるが、これをそのままバイト列としてCICS経由で外部に出力、あるいは `BINARY` 関数で復元する際、符号ビット（最上位ビット：Sビッド）の扱いに狂いがあると、マイナス値が途方もない巨大なプラス値に化ける「符号反転バグ」を引き起こす。
CICSオンラインの画面応答速度を上げるために、内部的なカウンタをすべて `FIXED BIN` 化しているシステムでは、この変換ロジックの不備が原因で、ピーク時にトランザクションがハングアップするトラブルが後を絶たない。
—
5. レガシー移行（Java / C#化）への処方箋
現在、多くの企業がメインフレームからの脱却、いわゆるレガシーマイグレーションを進めている。PL/Iで書かれた膨大な業務ロジックをJavaやC#に置き換える際、この `BINARY` 関数および `FIXED BINARY` の挙動をどう模倣するかは、移行アーキテクトの腕の見せ所である。
1. 精度の厳密なマッピング
- Javaの `int` や `long` は符号付き固定長（32bit / 64bit）であり、PL/Iのような「任意のビット長（例: `FIXED BIN(20)`）」をネイティブではサポートしていない。
- 移行先でラッパークラスやカスタム数値演算ライブラリを自製するか、あるいは精度オーバーフロー時の挙動（丸め・切り捨て・例外スロー）をPL/Iのそれに完全に一致させるためのカスタムバリデーションを挟む必要がある。
2. テストケースの網羅
- 移行検証（リグレッションテスト）では、正常系だけでなく、`BINARY` 変換の境界値（最大値、最小値、オーバーフロー寸前の値）におけるPL/I版と新言語版の出力結果を1ビット単位で突き合わせる自動テスト基盤が不可欠である。
—
おわりに
PL/Iの `BINARY` ビルトイン関数は、単なる「型の着せ替え衣装」ではない。それはメインフレームという強固なハードウェアアーキテクチャの心臓部に直接アクセスし、数値をビットの単位まで制御するための鋭利なメスである。
この関数の挙動、精度の罠、そしてコンパイラや他ミドルウェアとの連携におけるエッジケースを熟知しているか否かで、システムアーキテクトとしての「格」が決まると言っても過言ではない。
レガシーの荒波を乗りこなし、次世代の堅牢なシステムを設計するためにも、いま一度、コードの隅々に潜むデータ型の定義と変換処理に目を向けてみてほしい。
