現場の「数値化け」を未然に防ぐ：PL/IにおけるON SIZE条件の正しい流儀
メインフレームの基幹バッチにおいて、最も恐ろしいのは「システムが異常終了（ABEND）すること」よりも「何の警告もなく、数値の桁あふれを起こして誤った値をDBに書き込むこと」です。
PL/Iは極めて強力で柔軟な言語ですが、その自由度の代償として、デフォルトでは数値のオーバーフローに対して非常に寛容です。計算結果が変数の定義精度を超えても、上位桁を切り捨てて何食わぬ顔で処理を続行してしまう。これが深夜のバッチ処理で起きると、翌朝の突き合わせで泣きを見ることになります。
今回は、この「見えないデータ欠損」を防ぐための、PL/Iの防波堤『ON SIZE条件』の実践的な実装術を伝授します。
—
1. なぜ「SIZE条件」を意識すべきなのか
PL/Iの変数宣言で `FIXED DECIMAL(5,0)` と定義した場所に、演算の結果 `999999` が入ろうとした時、何が起きるか。実は、コンパイラオプションの指定にもよりますが、多くの環境ではエラーを出さずに上位の `9` を捨て、`99999` として格納してしまいます。
これを防ぐためのスイッチが `SIZE` 条件です。これを利用することで、精度を超えた瞬間にプログラムへ「待った」をかけさせることができます。
—
2. ON SIZEユニットの基本構造
PL/Iにおいて、特定の例外を捕捉するのは `ON` ユニットの役割です。以下に、実務で使える堅牢なテンプレートを示します。
/i
/ メインプログラムの骨格 /
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
/ SIZE条件を有効化（デフォルトでは無効なことが多い） /
ON SIZE BEGIN;
PUT SKIP LIST(‘ 警告: 数値オーバーフローが発生しました ‘);
PUT SKIP LIST(‘処理を中断し、エラーログを出力して終了します’);
/ ここでダンプ取得やエラーフラグの制御を行い、正常なABENDへ誘導する /
CALL ABEND_ROUTINE;
END;
/ 演算処理の実装例 /
DCL VAL_A FIXED DEC(5,0) INIT(99999);
DCL VAL_B FIXED DEC(5,0) INIT(10);
DCL RESULT FIXED DEC(5,0);
/ コンパイルオプションでSIZEチェックを有効にしている場合、以下でトラップされる /
(SIZE): RESULT = VAL_A + VAL_B;
PUT SKIP LIST(‘結果:’, RESULT);
MAIN_PROC_END: END MAIN_PROC;
—
3. 現場で使える「デバッグと制御」の勘所
実務の現場では、すべての演算に `ON` ユニットをベタ書きするのは非現実的です。以下の3つのポイントを意識してください。
① コンパイルオプションの活用
ソースコードに `(SIZE):` と書くのは、特に注意が必要な特定の演算だけで十分です。しかし、開発段階ではコンパイラオプションに `SIZE` を指定することで、プログラム全体でオーバーフローを監視できます。リリース時にパフォーマンスを優先して外すという判断も可能ですが、まずは「すべて検知する」環境を作ることがバグの早期発見に繋がります。
② VSAMレコード処理時の注意点
VSAMファイルから読み込んだデータを演算に使う際、データの桁数が定義と合っていない（いわゆる「ゴミデータ」が混入している）ことがよくあります。
- 演算前に `CHECK` などの組み込み関数で値を検証する。
- あるいは、入力データが定義通りであることを前提とせず、大きめの型で演算してから、最後に `FIXED DEC` 等へ代入する際に `SIZE` チェックを噛ませる。
③ ONユニット内での「後始末」
`ON SIZE` が発火した際、単に `STOP` するだけではいけません。基幹バッチであれば、以下の処理を組み込むのがプロの流儀です。
- ログ出力: どの変数が、どのような値の時に溢れたのかを `PUT DATA` で出力する。
- リターンコードの設定: 後続のステップに異常を伝えるため、戻り値（`RETURN CODE`）をセットする。
- クリーンアップ: オープンしているファイル（`CLOSE`）があれば、不整合を防ぐために必ず閉じる。
—
最後に：アーキテクトからの助言
「PL/Iは古臭い」と揶揄する声も聞きますが、これほど厳格にデータ精度を管理できる言語は現代でも稀です。
皆さんが今担当しているバッチ処理で、もし「数値がなぜか合わない」という不可解な現象に遭遇したら、まずはコンパイルリストのオプションを確認してください。`NOSIZE` になっていないでしょうか。
「動くコード」を書くのはジュニアエンジニア、「壊れないコード」を書くのがシニアエンジニアです。 数値の境界線を意識したプログラミングこそが、メインフレームという巨大システムの信頼性を支えています。何か行き詰まったら、いつでも相談してください。共に堅牢なシステムを作り上げていきましょう。
