現場で差がつく！LEランタイムダンプ(CEE3DMP)の「読み解き術」
メインフレームの保守現場で、夜中のバッチが突然のU4038（あるいはS0C7）で異常終了したとき、君はどうする？
まさか、Syslogの「ABEND」という文字を見て頭を抱えるだけで終わらせていないだろうな。
大規模な基幹システムにおいて、LE（Language Environment）が出力する`CEE3DMP`は、我々アーキテクトにとっての「黒箱のブラックボックス」を解き明かす唯一の鍵だ。今日は、この泥臭いけれど極めて重要なデバッグ手法について、現場の作法を叩き込んでやる。
—
1. CEE3DMPが語る「真実」とは何か
`CEE3DMP`の出力には、コンパイラが生成した実行時のスナップショットが全て詰まっている。特に我々が見るべきは以下の3点だ。
- レジスタ情報 (Registers at time of dump): プログラムの制御がどこにあるかを示す。特に基底レジスタの状態を確認し、ベースアドレスが正しいかを疑う。
- スタックトレース (Traceback): どのルーチンで落ちたか。PL/Iなら`ENTRY`ポイント名とオフセットが重要だ。
- 変数ダンプ (Storage in dump): `OPTIONS(MAIN)`で定義された自動変数や、`CONTROLLED`変数の実態がここにある。
2. 実践的なデバッグを想定したコード例
まずは、デバッグを意識したPL/Iの基本構造を見てみよう。ここではVSAMファイルを読み込み、計算処理を行う典型的なバッチ処理を想定している。
1
/ ——————————————————— /
/ PROGRAM: ANALYZE_VSAM_BATCH /
/ DESCRIPTION: VSAM読込とエラーハンドリングの基本構造 /
/ ——————————————————— /
ANALYZE: PROCEDURE OPTIONS(MAIN);
/ VSAMファイルの定義 /
DCL VSAM_FILE FILE RECORD INPUT ENV(VSAM);
DCL 1 VSAM_REC,
5 KEY_FLD CHAR(10),
5 DATA_FLD FIXED BIN(31);
/ 異常終了時のONユニット定義 /
ON ERROR BEGIN;
PUT SKIP LIST(‘— ERROR OCCURRED! DUMPING NOW —‘);
/ CEE3DMPを呼び出し、詳細なメモリダンプを生成 /
CALL CEE3DMP(‘BLOCKS,STORAGE,REGS’, ‘ ‘);
STOP;
END;
OPEN FILE(VSAM_FILE);
/ データの読み込み /
READ FILE(VSAM_FILE) INTO(VSAM_REC);
/ ゼロ除算等のリスクがある計算処理 /
IF DATA_FLD ^= 0 THEN
PUT SKIP LIST(‘RESULT: ‘ || TRIM(CHAR(100 / DATA_FLD)));
ELSE
SIGNAL ERROR; / 強制的にエラーを発生させる例 /
CLOSE FILE(VSAM_FILE);
END ANALYZE;
3. ダンプを読み解く：現場の視点
上のコードで`SIGNAL ERROR`が実行されたとき、ダンプファイルには何が残るか？
1. スタックトレースの確認:
トレースの先頭にある「Entry」名と「Statement」番号を探せ。もしStatement番号が不明なら、コンパイルオプションに`LIST`と`SOURCE`を指定し忘れている証拠だ。次からは忘れずに入れろ。
2. 変数の値を探す:
`Storage in dump`のセクションでは、変数のアドレスを特定する。`VSAM_REC`のような構造体の場合、ダンプ上で16進数（HEX）の羅列を見ることになる。ここで、`KEY_FLD`が意図しない文字化けをしていないか、`DATA_FLD`にゴミが入っていないかを突き止める。
3. ONユニットの制御フロー:
PL/Iの`ON`ユニットは、スタックを巻き戻す（Unwind）性質がある。ダンプ内の「Condition Information」を確認すれば、どの条件（`ZERODIVIDE`, `RECORD`, `SUBSCRIPTRANGE`等）でトラップが起動したのかが一発でわかる。ここがC言語のセグメンテーションフォールトと決定的に違う、PL/Iの強力なデバッグ機能だ。
4. 最後に：アーキテクトからの助言
バグを直すとき、ソースコードだけを見て「ここが怪しい」と推測で修正する者がいる。だが、ベテランは違う。「ダンプが語る事実」と「実行時のデータ状態」を突き合わせ、バグの再現条件を論理的に導き出す。
`CEE3DMP`は、単なるテキストの塊ではない。君たちが書いたコードが、メモリ上でどう暴れたかを示す貴重な証言者だ。ダンプを読むことは、機械の言葉を理解すること。それができて初めて、君たちは一人前のメインフレームエンジニアと呼べる。
もしダンプ解析で詰まったら、まずはスタックトレースから「どのプロシージャが誰を呼んだか」を紙に書き出すことから始めろ。アナログだが、これが最も遠回りのようで近道だ。
健闘を祈る。また次の現場で会おう。
