ゼロ除算の深淵：PL/Iにおける例外処理と、レガシー移行の「作法」
汎用機（メインフレーム）の現場で、深夜のバッチジョブが `S0CB` アベンドで停止したとき、真っ先に疑うのは何でしょうか。多くのエンジニアが「ゼロ除算」と即答するでしょう。しかし、PL/Iの `ZERODIVIDE` 条件は、単なる算術エラー以上の「システムのほころび」を我々に突きつけてきます。
今回は、PL/Iの `ON ZERODIVIDE` ユニットを巡る深淵と、それが現代のマイグレーションプロジェクトにおいて何を意味するのかを紐解いていきます。
—
1. ZERODIVIDE条件の発生と「制御の譲渡」
PL/Iにおいてゼロ除算が発生すると、ハードウェアの例外が検知され、コンパイラが生成したランタイムルーチンが `ZERODIVIDE` 条件を発生させます。ここでのポイントは、ONユニットが未定義であれば、即座にプログラムは異常終了（ABEND）し、ダンプが出力されるという点です。
現場で遭遇する「パックデシマルの罠」
基幹系システムでは `FIXED DECIMAL` を多用しますが、ここで注意すべきは、データ定義（PICTURE句）と実際のメモリ上の値の不整合です。例えば、DB2から取得した値が初期化不良で `00000F` ではなく不正な符号ビットを持っていた場合、計算時に予期せぬ挙動を示すことがあります。
/i
/ 不正な計算を防ぐためのONユニットの配置例 /
ON ZERODIVIDE BEGIN;
/ ここでシステムログを出力し、異常時のステータスを退避する /
PUT SKIP LIST (‘エラー: ゼロ除算が発生しました。計算値を再確認してください。’);
/ 本来はここで適切な復旧処理を行い、GOTOやSIGNALで制御を戻す /
SIGNAL ERROR;
END;
/ 計算ロジックの実行 /
RESULT = DIVIDEND / DIVISOR;
重要なのは、`BEGIN; END;` ブロックを用いたONユニットでは、制御が戻る場所（REVERTの挙動）を厳密に管理しなければならないという点です。これを怠ると、無限ループやスタック破壊を引き起こします。
—
2. マイグレーションにおける「例外ハンドリング」の設計思想
JavaやC#への移行を検討する際、最も頭を抱えるのがこの「ONユニットの継承と制御フロー」です。PL/Iの `ON` 文は動的なスコープ（スタックを遡って処理を探す）を持ちますが、現代のオブジェクト指向言語にはこの概念がありません。
移行アーキテクトが留意すべきエッジケース
1. DB2埋め込みSQLとの相性: CICS環境下でDB2を呼び出す際、SQLCODEがゼロであっても、結果セットの値がゼロ除算を誘発するケースがあります。これらをJava側に移植する際は、単なる `try-catch` ではなく、ビジネスロジック層での「事前ガード条件」の徹底が求められます。
2. ポインタ操作と動的変数: `BASED` 変数を用いた動的メモリ割り当てを行っている場合、ポインタが指す先が不正な領域であることに起因するゼロ除算（またはメモリアクセス例外）が多発します。マイグレーション時には、PL/Iの `ADDR` 関数と `OFFSET` の関係を、現代のメモリ管理モデルへどうマッピングするかが勝負となります。
—
3. 最適化コンパイラとダンプ解析の極意
`OPTIMIZE(3)` を指定したコンパイルコードでは、コードの実行順序が最適化により入れ替わることがあります。この状態でゼロ除算が発生すると、ダンプから読み取れるプログラムカウンタ（PSW）と、ソースコード上の行が一致しないことが多々あります。
そんな時、ベテランはこう考えます。
「コンパイラが変数をレジスタに保持したまま計算をショートカットしているのではないか？」
ダンプ解析のチェックリスト
- レジスタの値を凝視せよ: 演算に使用しているレジスタにゼロがセットされている瞬間を特定する。
- コンパイラ・リスティングの確認: `OFFSET` カラムとアセンブラ展開部を確認し、最適化によってレジスタ間演算に置き換わっていないかを確認する。
- CICSのEIB（EXEC Interface Block）: オンライン処理であれば、EIB内の異常コードと併せて、直前のDB2ステータスを確認する。
—
結びに：レガシーは「悪」ではない
PL/Iの `ZERODIVIDE` は、単なるエラーハンドリングの道具ではありません。それは、メインフレームという過酷な環境で、データの一貫性をいかに守り抜くかという「先人たちの哲学」が凝縮されたものです。
現代的な言語へ移行する際、安易にすべてを `try-catch` で囲むのは逃げです。PL/Iが持っていた、条件発生時に「プログラムの正常な状態」をいかに定義し、保守するかという設計思想を、新しいアーキテクチャの例外処理設計にどう落とし込むか。それこそが、我々レガシー移行スペシャリストが果たすべき真の価値なのです。
システムが「ゼロ」で割られることを拒絶するその瞬間、そこに潜むデータの真実を読み解く。それこそが、この仕事の醍醐味だと言えるでしょう。
