AS400 / IBM i の障害対応では、ジョブログを読めるかどうかで初動の速さが変わります。CPFエラー、RNX（RPG実行時エラーのメッセージID）エラー、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ならファイル、メンバー、ライブラリリスト、OVRDBFを疑います。権限不足はCPF9802など、前後のメッセージIDで分けて確認します。ファイル名だけでなく、どのライブラリを見ているか、実行ユーザーに権限があるか、他ジョブが排他していないかを確認します。
CPF中心で調べる場合は、AS400のCPFエラーとジョブログ確認手順に詳しく整理しています。
RNXエラーを見る時のポイント
RNXはRPG実行時エラーとして見ると分かりやすいです。数値変換、配列、桁あふれ、想定外データ、再帰的エラーなど、プログラムとデータの関係を確認します。ジョブログだけで終わらず、どの入力データで落ちたか、直前に読んだファイルは何かを追います。
RNX8888のように現場が混乱しやすいエラーは、AS400のRNX8888再帰的エラー対応も合わせて確認してください。
MSGWでは返信前の証跡を残す
MSGWは、返信内容によって後続処理が進むこともあれば、ジョブ終了や手戻りにつながることもあります。返信前に、ジョブ名、メッセージID、メッセージ本文、応答候補、直前の処理、業務影響を控えておくと、後で説明しやすくなります。
MSGWの判断は、AS400 MSGWとは？原因確認・返答手順と夜間バッチのリラン判断と、MSGWを早期検知する考え方に分けて整理しています。
Codexでジョブログ調査を補助する時
ジョブログの確認観点を整理する用途なら、Codexは調査時間短縮に使いやすいです。ただし、会社名、ユーザー名、取引先名、本番データは伏せて、メッセージID、処理名、匿名化した流れだけを渡すのが前提です。AIの回答をそのまま復旧判断に使うのではなく、調査メモの整理として使います。
実例の考え方
以下は読み分けのための架空例です。実機ログの転載でも、メッセージ全文の再現でもありません。
| 時刻・記録の例 | 読み取れる事実 | まだ分からないこと |
|---|---|---|
| 09:00 バッチ開始 | 対象ジョブが開始した | 前処理が必要なデータを用意できたか |
| 09:02 CPF4101、対象ORDERPF、ライブラリ*LIBL | 記録された実行条件でファイルが見つからなかった | 未作成なのか、参照先・実行条件が違うのか |
| 09:02 呼出元へ異常通知 | 呼出先の失敗が上位処理へ伝わった | それ以前に別ファイルを更新していないか |
この場合の調査メモは「事実：CPF4101と対象ファイル名を確認」「仮説：前処理未完了またはライブラリリスト差」「次の確認：対象バッチの実行条件、前処理ログ、ファイル作成結果」「保留：再実行は途中更新と後続影響の確認・承認後」と分けます。手元の5250ジョブのDSPLIBLだけで対象バッチも同じだと判断しないでください。
Codexでジョブログを整理する場合は、AS400ジョブログをCodexで要約するプロンプト例も参考にしてください。
原因切り分けは、事実・推測・対応を分けて残す
ジョブログ調査では、見つけたメッセージをそのまま原因として書くのではなく、事実として確認できたこと、そこから推測したこと、実際に行った対応を分けて残すと品質が上がります。後から別の担当者が見た時に、どこまで確認済みで、どこから未確認なのかが分かるためです。
| 記録する欄 | 書く内容 | 例 |
|---|---|---|
| 事実 | ジョブログに出ているメッセージ、時刻、ジョブ名、プログラム名 | CPF、RNX、MSGWなど |
| 確認済み | ライブラリ、ファイル、権限、前処理、再実行履歴 | AS400ライブラリの確認方法｜仕組みとオブジェクト管理を初心者向けに解説 |
| 推測 | 可能性は高いが、まだ断定できない原因 | 前処理未完了、データ不足など |
| 対応 | 再実行、保留、担当者連絡、翌営業日確認など | 本番判断 |
| 教育 | 同じ読み方をチームに展開するための観点 | 研修内容を見る |
この整理をしておくと、CodexやClaude Codeに相談する場合も、機密情報を出さずに「概要」「確認済み」「未確認」を分けて入力できます。本番接続情報、パスワード、顧客名、実データ、ソース全文は入力せず、ジョブログの要点だけを扱うのが安全です。
プロンプト例
以下はAS400のジョブログ抜粋です。 機密情報はマスク済みです。 1. 何が起きたか 2. 最初に見るべきメッセージID 3. MSGW、CPF、RNXの関係 4. 原因候補 5. 追加で確認するコマンド 6. 業務担当者へ確認すること 7. 再実行してよいか判断する前の注意点 を整理してください。 分からない点は断定せず、質問として列挙してください。
まとめ
AS400のジョブログは、最後から見るだけでなく、原因候補へ戻って読むことが大切です。最後のメッセージで状態を見て、その前のCPF、RNX、MCH、MSGWを確認し、ファイル、ライブラリ、業務影響へつなげます。本番障害の初動では、ジョブログを読む順番を決めておくだけで、調査の迷いをかなり減らせます。
関連: AS400のRPGソースをAIに読ませる時の注意点もあわせて確認してください。
ジョブログは、最後のエラーだけでなく前後の流れを読みます
AS400のジョブログでは、最後に表示されたCPFやRNXだけを見ても原因が分からないことがあります。直前のファイル、ライブラリ、権限、MSGW、呼び出し元、後続処理の流れを見ることで、最初のきっかけを見つけやすくなります。
ジョブログは、原因だけでなくリラン可否まで読む
ジョブログを見る目的は、エラーIDを見つけることだけではありません。現場では、そのジョブをもう一度流せるのか、途中まで更新済みなのか、前処理や後続処理に影響が出ているのかまで確認します。MSGWで止まっている場合は、QSYSOPRのメッセージとジョブログを合わせて見ます。
- 最初に出たCPF/RNX/MCHと、最後に止めたメッセージを分ける
- MSGWなら、2次テキストと返信候補を確認する
- 夜間バッチなら、前後のジョブと後続処理の有無を見る
- ファイル更新がある処理なら、DSPJRNで更新前後を追えるか確認する
- リラン、戻し、補正更新のどれが安全かを切り分ける
MSGWの返答判断はAS400 MSGWとは？原因確認・返答手順と夜間バッチのリラン判断、DSPJRNで更新前後を見る流れはAS400ジャーナル確認手順も参考にしてください。
参考：IBM公式ドキュメント（DSPJOBLOG）
本記事で扱った DSPJOBLOG の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。