ゼロ除算の深淵：PL/IのONユニットと「落とさない」ためのアーキテクチャ
メインフレームの現場で、バッチ処理中に突如として発生する「S0CBアベンド（ゼロ除算）」。これに遭遇した際、皆さんはどう対処してきただろうか。単に修正して再実行するだけならジュニアエンジニアの仕事だ。我々アーキテクトが考えるべきは、「異常系をいかにして自律的に制御し、後続処理を健全に継続させるか」という、PL/Iが古くから備える「ONユニット」の真髄である。
PL/Iには、他言語のような「厳格な予約語」という概念が希薄だ。この柔軟性は強力だが、不用意な命名は後のメンテナンス時に悪夢を生む。しかし、この自由度こそが、複雑なビジネスロジックを詰め込んだ基幹システムを支えてきた血脈でもある。
1. ON ZERODIVIDEによる例外トラップの設計思想
PL/Iにおいて、`ON ZERODIVIDE`は単なるエラーハンドラではない。スタック上の制御を一時的に中断し、例外処理ルーチンへ飛ばすための強力なトラップメカニズムだ。
/i
/ ゼロ除算発生時のリカバリ処理のサンプル /
CALC_PROC: PROCEDURE;
DCL DIVISOR BIN FIXED(15);
DCL DIVIDEND BIN FIXED(15);
DCL RESULT BIN FIXED(15);
/ ゼロ除算が発生した瞬間にここへ制御が飛ぶ /
ON ZERODIVIDE BEGIN;
PUT SKIP LIST(‘ゼロ除算を検知：計算をスキップして0を代入’);
RESULT = 0;
/ GOTOにより、エラー発生箇所の直後へ復帰させるのが定石 /
GOTO RESUME_LABEL;
END;
DIVISOR = 0; / ここでS0CBが発生するリスクがある /
RESULT = DIVIDEND / DIVISOR;
RESUME_LABEL:
/ ここから計算後処理を再開する /
CALL UPDATE_DATABASE(RESULT);
END CALC_PROC;
ここで重要なのは、`GOTO`による復帰制御だ。近年のJava等のtry-catch構文に慣れた世代には「GOTOを使うのか」と眉をひそめられるかもしれないが、これはメインフレーム特有の「コンテキストの保持」を目的としたアーキテクチャである。
2. コンパイラ最適化と「予期せぬ挙動」の境界線
基幹システムの移行プロジェクトにおいて最も頭を悩ませるのが、最適化オプション（`OPT(2)`や`OPT(3)`）によるコードの再配置だ。PL/Iコンパイラは、演算の並列化やレジスタへの退避を極限まで行う。
特に、パックデシマル（FIXED DEC）の内部符号反転バグには注意が必要だ。特定の演算順序において、コンパイラが中間結果を最適化した際に、符号ビットが正しく評価されないケースが稀に存在する。アベンドダンプ（SYSMDUMP）を解析すると、期待した値とメモリ上の値が微妙に食い違っていることがある。これこそが、機械語レベルまで意識した「コンパイラ挙動の解読」を要求されるポイントだ。
3. マイグレーション時のエッジケース：CICSと埋め込みSQL
JavaやC#への移行を検討する際、最も大きな壁となるのが「CICS環境でのトランザクション整合性」である。PL/Iはタスク単位でONユニットを管理できるが、Javaの例外スローはトランザクション全体のロールバックを誘発しやすい。
- ポインタと基底変数（Based Variable）の罠:
PL/Iの`DCL P PTR; DCL B CHAR(10) BASED(P);`のような動的メモリ操作は、C#の`Unsafe`コードに近い。これをオブジェクト指向言語へ移植する場合、メモリレイアウトを完全に再現しない限り、DB2のフェッチ結果と構造体がズレるという致命的な不整合を招く。
- 埋め込みSQLの挙動:
`WHENEVER SQLERROR`と`ON CONDITION`を混在させると、エラーの二重ハンドリングが発生し、ダンプ解析が困難になる。移行時には、SQLの戻り値（SQLCODE）を明示的にチェックするロジックへ書き換えるのが、堅牢なシステム設計の第一歩だ。
結論：レガシーは「古き遺物」ではなく「磨き抜かれた解」である
PL/Iがなぜ半世紀以上も基幹システムで生き残っているか。それは、この言語が「障害発生時の挙動を、言語仕様レベルで開発者が完全にコントロールできる」からに他ならない。
Javaの例外スタックトレースを眺めて「なぜこうなった」と悩む前に、メインフレームのダンプを読み、レジスタの値を追い、コンパイラが生成したコードの意図を汲み取る。このプロセスこそが、真のシステムアーキテクトとしての素養である。
移行担当者諸君、既存のPL/Iコードを単なる「書き換え対象」として見るのはやめよう。そこに込められた「異常系への執念」を読み解くことこそが、次世代システムの信頼性を担保する唯一の鍵となる。
