黙ってスルーされる「数字の爆弾」：ON FIXEDOVERFLOWが守る基幹システムの深層
メインフレームの現場で長くシステムアーキテクトをやっていると、夜間バッチの終了間際に突如発生する「原因不明の計算誤差」や「意図しないデータ化け」ほど、背筋が凍る瞬間はない。
JavaやC#といったモダン言語の世界からやってきたエンジニアが、PL/Iのコードレビューで口を揃えて驚く点がある。それは、「PL/Iには明確な予約語というものが存在せず、コンテキストによって識別子がいくらでも再定義できる」という独特の柔軟性だ。しかし、その柔軟性の裏で、コンパイラが黙認してしまう「危険なデフォルト挙動」が潜んでいることを知る者は少ない。
その代表格が、今回取り上げる `ON FIXEDOVERFLOW` 条件である。
固定小数点数（`FIXED BINARY` および `FIXED DECIMAL`）の演算において、桁あふれ（オーバーフロー）が発生した際、コンパイラやランタイムがどのように振る舞うべきか。この本質を理解していないと、基幹システムの信頼性は文字通り砂上の楼閣となる。
—
1. なぜ「デフォルトで無効」なのか？ 潜在するサイレントバグの恐怖
C/C++やJavaであれば、オーバーフローは例外（Exception）をスローするか、少なくともハードウェアレベルのフラグを立てる。しかし、IBM Enterprise PL/I コンパイラのデフォルトでは、`FIXEDOVERFLOW` 条件はDISABLED（無効）状態にある。
これが何を意味するか。
例えば、最大5桁の `FIXED DECIMAL(5,0)` で定義された変数に、演算結果として6桁目が溢れ出たとする。通常、人間であれば「異常終了（ABEND）」して止まってほしいところだが、PL/Iのデフォルト動作はこうだ：
1. 上位の桁あふれ部分は、何の前触れもなく切り捨てられる（Truncation）。
2. エラーメッセージすら出ない。
3. 処理はそのまま次の行へ進む。
金融システムにおいて、口座残高や金利計算の「上位桁の切り捨て」がサイレントに発生したとしたらどうなるか。翌朝の決算照合で莫大なアンバランス（不一致）が発覚し、夜通しのログ解析という名の泥沼に引きずり込まれる。これが、「予約語を持たない自由な構文」を許容するPL/Iの厳格な世界において、最も恐れられている「静かなる爆弾」の正体なのだ。
—
2. 実践：ON条件の捕捉と、ベース変数・ポインタによる動的制御
では、この桁あふれを検知し、単なるサイレントバグで終わらせずに適切にハンドリング（あるいは意図的なアベンドへ誘導）するにはどうすればよいか。
実務で即座に使える、`ON FIXEDOVERFLOW` を明示的に有効化し、さらに動的なメモリ管理（ベース変数とポインタ）を組み合わせた堅牢なPL/Iコードのサンプルを示す。
1
———————————————————————-
- 概要: FIXEDOVERFLOW条件の捕捉とベース変数を用いた動的バッファ制御
———————————————————————-
SAMPLE_OFL: PROC OPTIONS(MAIN);
/ 1. 動的メモリ管理のための構造体定義（ベース変数） /
DCL 1 ERROR_LOG_REC BASED(P_LOG),
5 ERR_TIMESTAMP PIC ‘9999/99/99 99:99:99’,
5 ERR_CODE CHAR(4),
5 ERR_MSG CHAR(64);
DCL P_LOG POINTER; / ポインタ変数の宣言 /
DCL WORK_AMT FIXED DEC(5,2); / テスト用の小さめの金額フィールド /
DCL RESULT_VAL FIXED DEC(7,2);
/ 2. ON-UNITの設定：桁あふれ発生時のトラップを定義 /
ON FIXEDOVERFLOW
BEGIN;
DISPLAY(‘ 致命的エラー: 固定小数点桁あふれを検知しました ‘);
- 動的メモリ（LLSQ等に相当）の獲得とエラーログの構築
ALLOCATE ERROR_LOG_REC SET(P_LOG);
ERR_TIMESTAMP = ‘202X/10/31 12:34:56’;
ERR_CODE = ‘OV01’;
ERR_MSG = ‘FIXED DECIMAL OVERFLOW IN CALCULATION’;
DISPLAY(‘LOG_REC: ‘ || ERR_TIMESTAMP || ‘ ‘ || ERR_MSG);
- 意図的なABEND（ユーザコード 9999）を発火させる
SIGNAL ERROR;
END;
/ 3. 処理の実行ブロック /
BEGIN;
- FIXEDOVERFLOWの有効化（スコープを限定して安全に制御）
SIGNAL ON FIXEDOVERFLOW;
WORK_AMT = 999.99;
RESULT_VAL = 0.00;
DISPLAY(‘演算開始: 限界値を超える乗算テストを行います。’);
- わざと桁あふれを起こす計算（7桁の領域に入るべき値が溢れる）
RESULT_VAL = WORK_AMT 10000.00;
DISPLAY(‘演算結果（到達しないはずのコード）: ‘ || RESULT_VAL);
END;
RETURN;
END SAMPLE_OFL;
このコードでは、`SIGNAL ON FIXEDOVERFLOW` によって明示的に条件監視を有効化し、万が一のオーバーフロー時には `ALLOCATE` 文で動的に確保したベース変数領域にエラー情報を展開し、最終的に `SIGNAL ERROR` で安全にジョブを異常終了させている。
—
3. レガシー移行（Java/C#等へのマイグレーション）におけるエッジケース対策
現在、多くの企業がメインフレームからの脱却（レガシーマイグレーション）を推進している。PL/Iで書かれた数十年前のコアロジックをJavaやC#へ自動変換、あるいはリライトする際、この `FIXEDOVERFLOW` の挙動の違いが深刻なトラップとなる。
① パックデシマルの内部符号反転とマイグレーションの罠
PL/Iの `FIXED DECIMAL` は、IBMハードウェアのネイティブなPacked Decimal形式（ゾーン10進数・パック10進数）としてメモリ上に配置される。
マイグレーション先のJavaでは `java.math.BigDecimal` に置き換えられることが一般的だが、ここで問題になるのが「オーバーフロー時の丸めモード（Rounding Mode）」と「符号（Sign）の扱い」である。
PL/Iで切り捨てられたデータが、Java側で `ArithmeticException` を吐かずに丸められてしまうと、新旧システム間の突合テストで「数セント〜数円のズレ」が頻発する。移行プロジェクトのアーキテクトは、変換ツールのコード生成ルールにおいて、単なる型変換だけでなく、オーバーフロー検出時のポリシーをPL/Iの挙動（あるいは厳格なABEND方針）に完全一致させる必要がある。
② 埋め込みSQL（DB2）およびCICSオンライン処理への影響
CICS（Customer Information Control System）のオンライン画面や、DB2のホスト変数（Host Variables）にデータを渡す瞬間にもリスクはある。
画面定義（BMS）やDB2のテーブル定義（COLUMN DEFINITION）を超える桁数のデータが `FIXEDOVERFLOW` 無効状態で生成された場合、DB2側で `-302` エラー（コンバージョンエラー）や、CICS側でのアベンド（ASRA等）を引き起こす。
オンライン応答性能を担保するためにも、バッチ・オンライン問わず、クリティカルな計算パスの冒頭では必ず `ON FIXEDOVERFLOW` またはコンパイラオプション（`RULES(OVERFLOW)` など）による静的・動的な二重のガードが不可欠である。
—
4. スペシャリストからの提言：コンパイラ最適化と運用の哲学
最後に、コンパイラオプションのチューニングについて一言添えておきたい。
IBM Enterprise PL/Iコンパイラには、パフォーマンスを極限まで引き出すための `OPTIMIZE(2)` や `OPTIMIZE(3)` といった最適化オプションが存在する。コンパイラは、コード解析の過程で「この変数はオーバーフローしないはずだ」と勝手に判断し、ハードウェアのオーバーフローチェック命令をインライン展開から削ぎ落とすことがある。
もし、貴社システムの基幹ロジックが「絶対に桁あふれを許さない金融・勘定系」であるならば、単にソースコード内に `ON FIXEDOVERFLOW` を書くだけでなく、コンパイルJCLにおいてプログラマの意図しない最適化によるチェックの省略を防ぐビルドガバナンスを敷くべきだ。
「予約語を持たない自由な言語」であるからこそ、プログラマの意図とコンパイラの機械的な最適化の隙間に、システムを揺るがすバグが入り込む余地が生まれる。
PL/Iアーキテクチャの底流にあるハードウェアとの対話を熟知し、目に見えない「数字の爆弾」をコードの網の目で確実に捕らえること。それこそが、レガシーの猛者たちに残された、時代を超えた使命である。
