ゼロ除算の深淵：PL/Iにおける例外処理と、コンパイラが隠蔽する「真実」
メインフレームの現場で長年コードを追い続けていると、若手エンジニアから「なぜか突然S0CBアベンド（ゼロ除算）で落ちる」という悲鳴と共に、数百万行のレガシーコードの海に放り込まれることがある。
JavaやC#の `try-catch` に慣れ親しんだ現代のアーキテクトにとって、PL/Iの `ON ZERODIVIDE` は一見して「古臭い仕組み」に見えるかもしれない。しかし、この仕組みは汎用機のパイプライン処理の根幹に深く食い込んでおり、その挙動を正しく制御できなければ、基幹システムの信頼性は一瞬で崩壊する。
今日は、単なる文法解説を超えて、コンパイラの最適化とハードウェア割込みの境界線に位置する「ゼロ除算の捕捉」について語ろう。
1. ON ZERODIVIDE：基本の構文と落とし穴
まずは基本を押さえておこう。PL/Iにおいてゼロ除算を制御する最小単位は以下の通りだ。
/i
/ 例外処理の定義 /
ON ZERODIVIDE BEGIN;
/ ログ出力やエラーフラグのセット /
PUT SKIP LIST (‘警告: ゼロ除算を検知しました。処理をスキップします。’);
/ 戻り先を指定しないと、発生箇所に戻ろうとして無限ループの罠に陥る /
GOTO ERROR_RECOVERY_ROUTINE;
END;
ここで多くのアーキテクトが犯す最大の過ちは、ONユニット内で「戻り先（GOTO）」を明示しないことだ。デフォルトでは、例外が発生した命令の直後に制御が戻ろうとする。もしそれが除算命令であれば、再び同じゼロ除算が発生し、システムは無限の地獄へ足を踏み入れる。
2. コンパイラ最適化と「予期せぬアベンド」
我々が特に注意すべきは、`OPTIMIZE` オプションをかけた際のコンパイラの挙動だ。
現代のコンパイラは、コードが「ゼロで割られる可能性がない」と静的解析で判断した場合、除算命令そのものを最適化によって削除、あるいは置換してしまうことがある。この時、実行時に予期せぬ値が変数に入り込むと、コンパイラが想定した前提が崩れ、`ON ZERODIVIDE` が捕捉できない形でS0CBが飛んでくる。
特に、パックデシマル（FIXED DECIMAL）の内部符号反転バグが絡むと悲劇的だ。メインフレームのデータは、時として上位システムからの不正なデータ移行により、正当な符号ビットを持たない領域が紛れ込む。これが数値演算に回された瞬間、ハードウェアが「ゼロ」と判定しきれず、しかし「除算不可」と判定する……この際、ONユニットが機能するか否かは、コンパイラのバージョンと最適化レベルという「運」に左右されることもある。
3. 実践：CICSオンラインとDB2のエッジケース
オンライン処理（CICS）でゼロ除算が発生すると、そのトランザクションだけでなく、タスク全体が異常終了し、最悪の場合は共用領域のメモリ破損を引き起こす。
マイグレーションの設計において、私は必ず「ガード条件」を設けるよう指導している。
/i
/ ゼロ除算を未然に防ぐ防御的プログラミングの例 /
PROCEDURE_MAIN: PROC OPTIONS(MAIN);
DCL DIVIDEND FIXED DEC(15,2);
DCL DIVISOR FIXED DEC(15,2);
DCL RESULT FIXED DEC(15,2);
/ DB2からフェッチした値がNULLまたは不正な場合のガード /
IF DIVISOR = 0 THEN DO;
/ ここで独自のエラー制御を行う /
CALL LOG_ERROR(‘DIVISOR_IS_ZERO’);
RESULT = 0; / 代替値を設定 /
END;
ELSE DO;
RESULT = DIVIDEND / DIVISOR;
END;
END PROCEDURE_MAIN;
4. ダンプ解析の現場から：アベンド時のポインタ追跡
もし `ON ZERODIVIDE` を突き抜けてS0CBが発生してしまった場合、残されたのは「SYSUDUMP」のみだ。
ここで重要になるのが、基底変数（Based Variable）とポインタ（Pointer）を多用した動的メモリ操作の結果としてのダンプ解析である。PL/Iはポインタの生存範囲（Scope）を厳格に管理するが、ポインタが指し示す先の構造体がメモリ上で破壊されていた場合、レジスタの値は一切信用できない。
ダンプを読む際は、以下の点に注目せよ。
1. PSW（プログラムステータスワード）の命令アドレス: どの命令が犯人か。
2. 浮動小数点レジスタ（FPR）の状態: 演算対象が本当に「ゼロ」であったか、あるいは「ガベージ値（不正データ）」であったか。
3. ストレージのダンプ: `DCL P PTR;` で定義された変数が、どこを指しているのか。もし0番地や、あり得ないアドレスを指していれば、それはロジックのバグではなく、メモリ破壊の連鎖である。
結論：マイグレーション担当者への提言
PL/IからJava/C#への移行を進める際、最も苦労するのは「言語仕様の違い」ではなく、「ハードウェアの挙動に対する甘え」の排除だ。
PL/Iの `ON` 条件は、ハードウェアの例外をソフトウェアで包み込む、非常に強力かつ危険なツールである。しかし、移行先であるJavaには、CPUレベルの例外を直接ハンドリングするような甘い環境はない。
もし貴方が今、レガシーシステムの移行設計をしているなら、`ON ZERODIVIDE` に依存したコードをすべて「演算前の正当性チェック」に書き換えることだ。泥臭い `IF` 文の積み重ねこそが、クラウド環境や分散システムにおいても堅牢性を担保する、唯一にして最強のアーキテクチャであると確信している。
技術を愛する者よ、ダンプを恐れるな。そこに書かれているのは、機械の「嘘」ではなく、我々が書き記した「論理の限界」なのだから。
