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