AS400 / IBM i の障害対応では、ジョブログを読めるかどうかで初動の速さが変わります。CPFエラー、RNXエラー、MSGW、夜間バッチ停止は、どれも最終的にはジョブログで「何が先に起きたか」を確認します。この記事では、初心者がDSPJOBLOGを見る時に迷いやすい読み順を、現場目線で整理します。
ジョブログは、最後のメッセージだけを見ても原因を間違えることがあります。最後に出ているのは結果で、その少し前に本当の原因が出ていることが多いからです。25年以上の現場経験で見ると、若手ほど最後の異常終了メッセージだけを見て判断しがちです。
ジョブログを見る前に控える情報
- ジョブ名、ユーザー、ジョブ番号
- 発生時刻と、業務担当者が気付いた時刻
- 夜間バッチ、画面操作、帳票、出荷確定などの業務名
- MSGWなのか、異常終了なのか、まだ実行中なのか
- 再実行済みか、まだ何も触っていないか
DSPJOBLOGで見る順番
| 順番 | 見る場所 | 判断すること |
|---|---|---|
| 1 | 最後のメッセージ | 異常終了、MSGW、正常終了、キャンセルのどれかを見る |
| 2 | 最後の少し前 | 本当の原因になったCPF/RNX/MCHを探す |
| 3 | プログラム呼び出し前後 | どのCL、RPG、CALLで止まったかを見る |
| 4 | ファイル操作の直前 | ファイル名、ライブラリ、メンバー、権限、排他を確認する |
| 5 | ジョブ開始時刻付近 | 環境、ライブラリリスト、投入元、実行ユーザーを見る |
最後のメッセージだけで判断しない
ジョブログの最後に「ジョブが終了した」「プログラムが異常終了した」と出ていても、それ自体は結果です。原因はその前にあるCPF4101、CPF9802、RNX0100、RNX8888、MCH3601などのメッセージかもしれません。まず最後で状態を見て、少し上へ戻って原因候補を探します。
メッセージIDの入口を整理したい場合は、AS400メッセージID・エラーコード索引を使うと、CPF、RNX、MCH、MSGWを分けて確認できます。
CPFエラーを見る時のポイント
CPFエラーは、ファイル、ライブラリ、権限、装置、ジョブ環境など幅が広いです。たとえばCPF4101ならファイルを開けない、CPF9802なら権限不足を疑います。ファイル名だけでなく、どのライブラリを見ているか、実行ユーザーに権限があるか、他ジョブが排他していないかを確認します。
CPF中心で調べる場合は、AS400のCPFエラーとジョブログ確認手順に詳しく整理しています。
RNXエラーを見る時のポイント
RNXはRPG実行時エラーとして見ると分かりやすいです。数値変換、配列、桁あふれ、想定外データ、再帰的エラーなど、プログラムとデータの関係を確認します。ジョブログだけで終わらず、どの入力データで落ちたか、直前に読んだファイルは何かを追います。
RNX8888のように現場が混乱しやすいエラーは、AS400のRNX8888再帰的エラー対応も合わせて確認してください。
MSGWでは返信前の証跡を残す
MSGWは、返信内容によって後続処理が進むこともあれば、ジョブ終了や手戻りにつながることもあります。返信前に、ジョブ名、メッセージID、メッセージ本文、応答候補、直前の処理、業務影響を控えておくと、後で説明しやすくなります。
MSGWの判断は、AS400 MSGW返答判断表と、MSGWを早期検知する考え方に分けて整理しています。
Codexでジョブログ調査を補助する時
ジョブログの確認観点を整理する用途なら、Codexは調査時間短縮に使いやすいです。ただし、会社名、ユーザー名、取引先名、本番データは伏せて、メッセージID、処理名、匿名化した流れだけを渡すのが前提です。AIの回答をそのまま復旧判断に使うのではなく、調査メモの整理として使います。
AS400保守で安全にAIを使う流れは、AS400 / IBM i 現場向け Codex実戦研修でも扱っています。
まとめ
AS400のジョブログは、最後から見るだけでなく、原因候補へ戻って読むことが大切です。最後のメッセージで状態を見て、その前のCPF、RNX、MCH、MSGWを確認し、ファイル、ライブラリ、業務影響へつなげます。本番障害の初動では、ジョブログを読む順番を決めておくだけで、調査の迷いをかなり減らせます。
関連: AS400保守でAIやCodexを安全に使う実務記事として、AS400障害調査でCodexに渡すプロンプト例｜ジョブログ・MSGW・業務影響を整理する も追加しました。
