ゼロ除算は「例外」ではない。PL/I技術者が知るべきONユニットの流儀
メインフレームのバッチ処理において、最も恐ろしいのは「何の前触れもなく突然落ちる」ことではなく、「中途半端なデータで処理を続行し、後続のDBやVSAMファイルを汚染すること」です。
特に演算エラー、その筆頭である`ZERODIVIDE`（ゼロ除算）は、単なるコーディングミスとして片付けてはなりません。本番環境で何百万件というレコードを処理する際、たった一行の除算式がシステム全体を停止させるリスクを孕んでいます。今日は、PL/Iの`ON`ユニットを活用した、堅牢なエラーリカバリの極意を伝授しましょう。
—
ONユニットは「エラーの避難所」ではない
多くの若手が勘違いしていますが、`ON ZERODIVIDE`は単にエラーを無視するための場所ではありません。メインフレームの基幹バッチにおいて、エラーハンドリングの目的は二つです。
1. 異常終了（ABEND）の回避: システム全体を止めるのではなく、該当レコードだけをスキップ、あるいはエラーログを出力して処理を続行させる。
2. トレーサビリティの確保: どこで、どの値でエラーが起きたのか。デバッグに必要な「証拠」を確実に残す。
これを実現するために、`ON`ユニット内で`ONLOC`（エラー発生箇所）や`ONCHAR`、`ONSOURCE`といった組み込み関数をどう使いこなすかが腕の見せ所です。
—
実践的なコーディング例：安全な除算処理
以下は、VSAMから読み込んだ売上データに対して、単価算出を行うバッチの断片です。単なる`ON`ユニット記述ではなく、構造化したリカバリフローを意識してください。
1
/ ——————————————————————- /
/ PROCEDURE: CALC_UNIT_PRICE /
/ 概要: ゼロ除算発生時にABENDさせず、ログを出力して0をセットする /
/ ——————————————————————- /
CALC_UNIT_PRICE: PROCEDURE(P_AMOUNT, P_QTY) RETURNS(FIXED DEC(15,2));
DCL P_AMOUNT FIXED DEC(15,2) PARM;
DCL P_QTY FIXED DEC(15,2) PARM;
DCL W_RESULT FIXED DEC(15,2) INIT(0);
/ ゼロ除算発生時のONユニット定義（処理の局所化） /
ON ZERODIVIDE BEGIN;
PUT SKIP LIST(‘ 警告: ゼロ除算検知 ‘);
PUT SKIP LIST(‘発生箇所:’, ONLOC);
PUT SKIP LIST(‘エラー時の値: 量=’, P_QTY);
/ ここでゼロ除算時は結果を0として処理を続行する /
W_RESULT = 0;
GOTO CALC_END;
END;
W_RESULT = P_AMOUNT / P_QTY;
CALC_END:
RETURN(W_RESULT);
END CALC_UNIT_PRICE;
—
実務で押さえるべき「制御フローの鉄則」
上記のコードを見て、「なぜ`GOTO`を使うのか？」と疑問に思うかもしれません。しかし、PL/Iの`ON`ユニット内から元の処理へ戻る場合、`GOTO`を用いた局所的な脱出は非常に有効かつ安全な手法です。
1. エラー箇所特定（ONLOCの活用）
`ONLOC`は、コンパイル時に設定された名前（PROCEDURE名やENTRY名）を返します。大規模なバッチプログラムであればあるほど、複数の箇所で除算を行っているはずです。ログに`ONLOC`を出力させておくことは、障害調査の時間を半分に短縮します。
2. VSAMアクセスとの兼ね合い
もし、VSAMの更新処理中にこのエラーが発生した場合、単に`GOTO`で抜けると、ファイルの整合性が崩れる可能性があります。その場合は、`ON`ユニット内でフラグを立て、メインループ側で`ROLLBACK`（CICSやDB2の場合）やエラー処理レコードへの書き出しを行う設計にすべきです。
3. 「何でもかんでもONユニット」は禁忌
全ての演算に`ON`ユニットを設置すると、プログラムの可読性が極端に下がります。本当にゼロ除算の可能性がある計算式のみを関数化（サブプロシージャ）し、その内部に閉じ込めるのが、保守性を高める「大人のコーディング」です。
—
最後に：エンジニアとしての矜持
メインフレームの改修現場では、過去の仕様書が残っていないことも珍しくありません。そんな時、動いているコードの「意図」を読み取る力こそが、我々アーキテクトの武器です。
`ON ZERODIVIDE`を単なる「エラー逃げ」の手段として使うのではなく、「ビジネス継続のための防波堤」として設計してください。どのようなデータが来てもシステムを止めない。その頑強さこそが、IBMメインフレームというプラットフォームが、何十年も基幹システムとして君臨し続けている理由なのですから。
次回の改修作業でこの記述を見かけた時、ぜひ「なぜこの処理が必要なのか」を設計意図から考えてみてください。それが、あなたを一段上のエンジニアへと引き上げるはずです。
