AS400 / IBM iの障害調査でよくある失敗が、ジョブログの最後に出ているエラーだけで判断することです。最後のCPFやRNX（RPG実行時エラーのメッセージID）は結果であり、原因はその前のメッセージ、CALL、ファイル、ライブラリ、MSGW（メッセージ応答待ち）にあることがあります。
見る順番
| 順番 | 見ること |
|---|---|
| 1 | どのジョブ、どのユーザー、どの時間で止まったか |
| 2 | 最後のエラーだけでなく、直前のメッセージを見る |
| 3 | CALLやCLの流れを追う |
| 4 | ファイル、ライブラリ、権限、ロックを確認する |
| 5 | MSGWの場合は返答前に業務影響を確認する |
実例の考え方
例えば最後にRNXが出ていても、原因は入力ファイルの想定外データかもしれません。CPF4101が出ていても、ライブラリリスト違いやファイル未作成が原因かもしれません。MSGWが出ている場合は、返答次第で後続処理が流れることもあるため、強制終了だけで片付けないようにします。
Codexでジョブログを整理する場合は、AS400ジョブログをCodexで要約するプロンプト例も参考にしてください。
原因切り分けは、事実・推測・対応を分けて残す
ジョブログ調査では、見つけたメッセージをそのまま原因として書くのではなく、事実として確認できたこと、そこから推測したこと、実際に行った対応を分けて残すと品質が上がります。後から別の担当者が見た時に、どこまで確認済みで、どこから未確認なのかが分かるためです。
| 記録する欄 | 書く内容 | 例 |
|---|---|---|
| 事実 | ジョブログに出ているメッセージ、時刻、ジョブ名、プログラム名 | CPF、RNX、MSGWなど |
| 確認済み | ライブラリ、ファイル、権限、前処理、再実行履歴 | ライブラリリスト確認 |
| 推測 | 可能性は高いが、まだ断定できない原因 | 前処理未完了、データ不足など |
| 対応 | 再実行、保留、担当者連絡、翌営業日確認など | 本番判断 |
| 教育 | 同じ読み方をチームに展開するための観点 | 研修内容を見る |
この整理をしておくと、CodexやClaude Codeに相談する場合も、機密情報を出さずに「概要」「確認済み」「未確認」を分けて入力できます。本番接続情報、パスワード、顧客名、実データ、ソース全文は入力せず、ジョブログの要点だけを扱うのが安全です。
まとめ
AS400ジョブログは、最後のエラーではなく、前後の流れで読みます。CALL、ファイル、ライブラリ、権限、MSGW、業務影響をつなげて見ることで、原因切り分けの精度が上がります。
関連するAS400確認ルート
ジョブログ調査では、最後のエラーだけで判断せず、最初に崩れた処理、MSGW、呼び出し元、業務操作を並べて確認します。トラブル逆引きと一緒に見ると初動が安定します。
最後のエラーより、最初に崩れた場所を見る
ジョブログで最後に出ているメッセージは、原因ではなく結果のことがあります。たとえば帳票が出ない問い合わせでも、最後は印刷関連のエラーに見えて、実際にはその前のRPG処理で対象データが作られていないことがあります。私は最後の1行ではなく、処理が正常から異常に変わった場所を探します。
| 見える症状 | 最後のメッセージだけで疑いがちなこと | 実際に見る場所 |
|---|---|---|
| 帳票が出ない | プリンターやOUTQ | 帳票作成前のRPG、スプール作成有無、ジョブ終了状態 |
| 夜間処理が止まった | MSGWの返信内容 | MSGWの直前CPF、対象ファイル、後続ジョブ |
| データが更新されない | 画面操作ミス | 権限、ライブラリリスト、入力チェック、コミット範囲 |
原因を切り分ける時は、発生時刻、ジョブ名、直前の正常メッセージ、最初の異常メッセージをメモに残します。この形で残すと、翌日別の担当者が見ても調査を引き継ぎやすくなります。