メインフレームの守護者たれ：PL/Iにおけるユーザー定義例外（SIGNAL CONDITION）の実践的活用
古くからこの業界に身を置いていると、「なぜこんな仕様になっているのか」と頭を抱えたくなるような、スパゲッティに近いエラーハンドリングに出くわすことが多々ある。特に長年運用されてきた勘定系や大規模バッチシステムでは、エラー処理が各処理の末端に散らばり、保守性が著しく低下しているケースが少なくない。
今日は、PL/Iにおいて「例外処理を一元管理する」ための強力な武器である、`SIGNAL CONDITION`と`ON CONDITION`によるユーザー定義例外について、現場の知見を交えて解説しよう。
なぜSIGNAL CONDITIONなのか
標準的なエラー処理として`ON ERROR`や`ON ENDFILE`を使うのは基本だが、ビジネスロジック上の「異常」を通知する際、わざわざフラグ変数を戻り値として全てのサブプロシージャに伝搬させていないだろうか？
`SIGNAL CONDITION`を使えば、呼び出し階層をまたいで、あらかじめ定義しておいたエラーハンドラに制御をジャンプさせることができる。これにより、メインのビジネスロジックを汚すことなく、例外発生時のリカバリ処理を「司令塔」に集約できるのだ。
実践：ユーザー定義例外によるエラーハンドリング
以下のコードは、VSAMファイル更新時に特定のビジネスルール違反を検知し、それを例外として捕捉する構成例だ。
1
/ —————————————————————— /
/ PROGRAM: EXCEPTION_DEMO /
/ 機能: ユーザー定義 CONDITION によるエラーハンドリングの一元管理 /
/ —————————————————————— /
EXCEPTION_DEMO: PROCEDURE OPTIONS(MAIN);
/ ユーザー定義 CONDITION の宣言 /
DEFINE CONDITION BUSINESS_RULE_ERR;
/ エラーハンドリングの司令塔（ONユニット） /
ON CONDITION(BUSINESS_RULE_ERR) BEGIN;
PUT SKIP LIST(‘ 業務ルール違反を検知しました ‘);
PUT SKIP LIST(‘詳細なログを出力し、後続のロールバック処理へ’);
/ ここでVSAMのクローズや異常終了コードの設定を行う /
CALL ABEND_ROUTINE;
END;
/ メイン処理 /
CALL PROCESS_DATA;
/ 正常終了 /
RETURN;
/ —————————————————————— /
/ データ処理サブプロシージャ /
/ —————————————————————— /
PROCESS_DATA: PROCEDURE;
DCL DATA_VAL FIXED BIN(15) INIT(999);
/ 何らかのVSAM読み込みや計算ロジック… /
IF DATA_VAL > 100 THEN DO;
/ 条件を満たした瞬間に例外を発生させる /
SIGNAL CONDITION(BUSINESS_RULE_ERR);
END;
END PROCESS_DATA;
ABEND_ROUTINE: PROCEDURE;
/ 実際のメインフレーム環境ではここでダンプログ出力や /
/ 異常終了コードをセットする処理を記述する /
PUT SKIP LIST(‘システムを停止します…’);
STOP;
END ABEND_ROUTINE;
END EXCEPTION_DEMO;
現場で「生き残る」ためのコーディングTips
この手法を使う際、ベテランとしていくつか守ってほしい鉄則がある。
1. CONDITION名はグローバルにスコープを広げる
`DEFINE CONDITION`は、可能な限りメインの`PACKAGE`や最上位の`PROCEDURE`で定義すること。サブプロシージャ側で見えないと、コンパイルエラー以前にメンテナンス性が破綻する。
2. スタックの巻き戻し（UNWIND）を意識する
`SIGNAL CONDITION`が発行されると、PL/IはONユニットを探してコールスタックを遡る。この時、動的に確保したストレージや開いたままのファイルがないか、十分に注意が必要だ。`ON BEGIN`ブロック内で`CLOSE`処理を確実に実行する癖をつけよう。
3. デバッグ時は「デバッグ・ツール」を併用せよ
`ON CONDITION`でトラップした箇所は、デバッガのブレークポイントと相性が良い。もし本番環境で原因不明のエラーが出るなら、`ON CONDITION`のブロック内に`PLIDUMP`を仕込んで、レジスタ情報やストレージの状態をSYSPRINTに吐き出させるのが、我々メインフレームエンジニアの定石だ。
最後に：綺麗なコードは信頼の証
「エラー処理は面倒だ」と思うかもしれない。しかし、複雑なシステムであればあるほど、エラーの発生源と、その後の処理を切り離せるこの設計は、後の保守フェーズで必ず自分を救うことになる。
PL/Iは古臭いと言われることもあるが、その言語仕様の堅牢性は、現代の言語にも決して引けを取らない。標準化されたルールに従い、正しく例外を制御する。それこそが、大規模システムの安定稼働を支えるプロフェッショナルの仕事だ。
次回の改修作業では、ぜひこの`SIGNAL CONDITION`を取り入れて、読みやすく堅牢なプログラムを書いてほしい。健闘を祈る。
