ゼロ除算の深淵：PL/IにおけるON ZERODIVIDEと、その先にあるアーキテクチャの真実
メインフレームの現場で、夜中の3時に叩き起こされる原因のトップランナーといえば、今も昔も「S0C9（固定小数点除算例外）」です。COBOLならなんとなく流れていくような軽微なエラーも、PL/Iのコンパイラとランタイムは容赦なく検知し、場合によってはシステム全体を道連れにしてABEND（異常終了）させます。
しかし、我々アーキテクトにとって、`ON ZERODIVIDE`は単なるエラー回避の道具ではありません。これは、プログラムの「生存戦略」そのものなのです。
1. ONユニットの哲学：停止か、継続か
PL/Iの`ON ZERODIVIDE`は、単に「ゼロで割るな」と警告するものではありません。異常発生時のコンテキストをどう保持し、制御をどこに戻すかという、設計思想を問うものです。
/i
/ ゼロ除算発生時のリカバリルーチン例 /
ON ZERODIVIDE BEGIN;
/ どの変数がゼロだったのか、あるいは不適切な値だったのかを特定する /
PUT SKIP LIST(‘警告: ゼロ除算が発生しました。計算をスキップして続行します。’);
/
- ここで重要なのは、単にエラーを無視することではない。
- ログを出力し、不正な演算結果が後続の処理に波及しないよう、
- 計算結果を強制的にゼロクリアあるいは定数で埋める必要がある。
/
RESULT_VAL = 0;
/
- GO TOによる脱出。
- 注意：ONユニット内でGO TOを使う場合、制御が戻る先が
- 有効なスタックフレーム内にあることを保証しなければならない。
- さもなくば、制御不能なランタイムエラーを招くことになる。
/
GO TO CALC_CONTINUE;
END;
2. ポインタと動的メモリの「地雷」
現代のJavaエンジニアがマイグレーション時に最も苦労するのが、PL/Iのポインタとベース変数の概念です。
特に、`BASED`変数を使用してデータを動的にマッピングしている際、そのベースとなるポインタがNULLに近い状態で演算を行い、ゼロ除算ならぬ「S0C4（保護違反）」を引き起こすケースが多い。あるいは、パックデシマル（`FIXED DECIMAL`）の内部表現が壊れている場合、計算命令そのものが不正とみなされます。
実務レベルで恐ろしいのは、「パックデシマルの符号ビットが壊れたまま演算に入り、ランタイムがそれを値として認識できずに演算例外を吐く」というケースです。この場合、単なるゼロ除算対策だけでは不十分。データバリデーションを演算の直前で行う堅牢な設計が求められます。
3. コンパイラオプションと最適化の罠
`OPTIMIZE(3)`をかけていると、コンパイラは「ここでの除算は発生しないはずだ」という前提でコードを最適化（コードの消去や順序入れ替え）することがあります。
トラブルシューティングにおいて、コンパイラリストを確認し、オブジェクトコードがソースの行番号とどう対応しているかを読み解くスキルは、もはや「職人芸」です。ダンプ（SYSUDUMP）を眺めるとき、PSW（プログラム状態語）がどの命令を指しているか、そしてその命令が最適化によってどのように変容したかを特定できなければ、根本原因の解決には至りません。
4. マイグレーションの文脈：Javaへの架け橋
もしあなたが、今まさにPL/IからJavaやC#への書き換えを進めているのであれば、`ON ZERODIVIDE`を単なる`try-catch`に置き換えて終わりにしてはいけません。
- PL/IのONユニット: 非常に広いスコープを持ち、スタックを巻き戻して制御を移すことができる。
- Javaの例外処理: 基本的にローカルなブロック内でのハンドリング。
この違いを理解せずにコードを翻訳すると、ビジネスロジックの例外処理がバラバラになり、バッチのリカバリポイントが崩壊します。設計段階で、「エラー発生時にどのレベルまでロールバックすべきか」という「回復戦略」を、メインフレームの仕様に合わせて再構築する必要があります。
結論：技術の深層を探求するということ
基幹システムを支えるアーキテクトにとって、言語仕様は「ルール」であると同時に「武器」です。`ON ZERODIVIDE`を使いこなすことは、システムの「死」を「制御された停止」や「安全なバイパス」に変換することに他なりません。
これからマイグレーションに挑むのであれば、まずはコンパイラの生成するリストファイルを読み込み、ランタイムがどうやってエラーをキャッチしているのか、その仕組みを脳内に描き出すことから始めてください。それが、どんな高レイヤーな言語を使おうとも、システムを沈没させないための最低限の礼儀であり、プロフェッショナルの矜持です。
次回の記事では、CICSにおける`HANDLE CONDITION`と、PL/Iの`ON`ユニットが衝突した際の「制御の奪い合い」について深掘りしたいと思います。現場のエンジニア諸君、今日もメインフレームの安定稼働を祈ります。
