導入：なぜ例外発生時の「場所」と「引数」が重要なのか
メインフレームのPL/I開発において、障害発生時のデバッグは骨の折れる作業です。特に、何千行ものコードの中で「どのモジュールが」「どのような引数で」異常終了したのかを突き止めるのは容易ではありません。そんな時、エラーハンドリングの仕組みであるON-Units内でONLOCやONARGSLISTを活用すれば、障害解析に必要な情報を自動的にログへ出力できます。これは現代のJavaにおけるスタックトレース取得に近い、プロフェッショナルな障害追跡手法です。
基礎知識：ON-Unitsとイントロスペクション機能
PL/Iには、例外が発生した際に特定の処理を実行する「ON-Units」という機能があります。
ONLOCは、例外が発生したプロシージャの名前を返す組み込み関数です。これにより、共通エラー処理ルーチンを作成しても、どこの処理でエラーが起きたかを即座に特定できます。
ONARGSLISTは、例外発生時の引数リストを取得するための関数です。プログラムが動的にどのような値を受け取って異常系に陥ったのかを把握する、「システムレベルのイントロスペクション（自己観察）」を可能にします。
実装：障害調査用ログの自動生成
障害発生時の解析を効率化するために、ON-Unitsの中にこれらの関数を組み込みます。これにより、運用中のジョブが異常終了した際、SYSOUTへ詳細なコンテキスト情報を書き出すことが可能です。特にバッチ処理において、再実行不可能な障害の事後解析において絶大な威力を発揮します。
サンプルプログラム：例外発生時の情報出力コード
以下のコードは、エラー発生時にモジュール名と引数リストを標準出力へ書き出す例です。
/ エラー発生時の共通ハンドラ /
ON ERROR BEGIN;
/ エラー発生元のモジュール名を取得して表示 /
PUT SKIP LIST(‘障害発生モジュール: ‘ || ONLOC());
/ 呼び出し時の引数リスト情報を取得して表示 /
PUT SKIP LIST(‘呼び出し時引数情報: ‘ || ONARGSLIST());
/ 必要に応じてダンプを出力するなどの後続処理 /
STOP;
END;
/ 実行処理本体 /
PROC_SAMPLE: PROC(PARAM1, PARAM2);
DCL PARAM1 CHAR(10);
DCL PARAM2 FIXED BIN(31);
/ 何らかの例外が発生する処理 /
…
END PROC_SAMPLE;
応用と注意点：現場での活用ポイント
1. ログの可読性を高める
ONARGSLISTの出力は環境によってフォーマットが異なる場合があります。運用ログとして利用する際は、出力された文字列を整形して、障害管理票のフォーマットに合わせておくことをお勧めします。
2. パフォーマンスへの配慮
ON-Units内でのPUT文は、高頻度で発生するエラーに対してはI/O負荷となります。本番環境では、障害ログ専用のデータセットへ書き込むように設計し、デバッグ時のみ詳細を出力するスイッチを設けるのがベストプラクティスです。
3. 移行時の注意
オープン系環境へ移行する際、これらはJava等の例外スタックトレース出力に置き換わります。移行設計を行う際は、この「ONLOCで得ていた情報」と同等の情報を、新しい言語のロギングライブラリでどのようにキャプチャするかを事前に検討してください。
コメント