実例で確認したい場合は、CPF4101の調査例、RNXエラーの調査例、MSGW夜間バッチ停止の対応例 も参考にしてください。
AS400 / IBM i の障害調査で最初に見るべきものがジョブログです。画面でエラーが出た時、バッチが止まった時、RPGやCLが異常終了した時、原因の入口はほとんどの場合ジョブログに残っています。
この記事では、初心者が迷いやすい「最後のメッセージだけ見て終わる」状態から抜け出し、CPF、RNX（RPG実行時エラーのメッセージID）、MCH、MSGW（メッセージ応答待ち）、呼び出し元、対象ファイル、ライブラリまでつなげて確認する手順を整理します。
ジョブログで分かること
| 見るもの | 分かること | 次に確認する先 |
|---|---|---|
| メッセージID | CPF、RNX、MCHなどエラーの種類 | IBM iのメッセージ説明、前後のログ |
| 重大度 | 警告か異常終了に近いか | ジョブ終了理由、後続処理 |
| プログラム名 | どのRPG/CLで発生したか | ソース、呼び出し元、コンパイルリスト |
| ファイル名 | 対象PF/LF、プリンターファイル、ワークファイル | ライブラリ、ロック、権限、存在確認 |
| 直前のメッセージ | 本当の原因に近い情報 | 最後ではなく少し上へ戻って読む |
基本コマンド
| コマンド | 用途 | 使う場面 |
|---|---|---|
| DSPJOBLOG | 自分のジョブログを表示する | 画面操作直後の確認 |
| WRKJOB | 対象ジョブの詳細を開く | ジョブ番号やユーザーが分かる時 |
| WRKACTJOB | 実行中ジョブを見る | MSGW、LCKW、CPU高騰の確認 |
| WRKSBMJOB | 投入済みバッチを見る | 自分が投入したバッチの確認 |
| WRKSPLF | スプールを確認する | コンパイルリスト、帳票、エラーリスト確認 |
ジョブログは最後から読む
ジョブログは長くなります。頭から時系列に追っていくと、正常な情報メッセージを大量に読むことになり、それだけで時間が過ぎます。
運営者の読み方は逆です。まず最後（最新のログ）を確認します。そこから状況を見ながら、最初のログへ向かって遡っていきます。
理由は単純で、ログの最後に結論が書いてあるからです。ジョブが何で終わったのか、どのメッセージで止まったのか。まずそれを掴んでから、なぜそうなったのかを遡って探すほうが速く着きます。
「最後から読む」と「最後だけで判断する」は違う
ここは混同しないでください。この記事の別の項目にも書いたとおり、最後のメッセージだけで原因を決めてはいけません。最後にあるのは結論であって、原因ではないからです。
最後から読むのは、調査の起点としてです。結論を先に押さえ、そこから遡って原因にたどり着く。頭から読むのでもなく、最後だけを見て終わるのでもなく、最後を入口にして逆向きに追う、という順番です。
| 順番 | 見るところ | 知りたいこと |
|---|---|---|
| 1 | ログの最後（最新） | 結論。何で終わったのか、どこで止まったのか |
| 2 | その少し手前 | 直前に動いていた処理。CALL、ファイル操作、パラメーター |
| 3 | さらに遡る | 最初に異常が出たメッセージ。ここが原因の候補 |
| 4 | 原因候補のメッセージ | カーソルを合わせてF1。原因と回復方法を読む |
遡る途中で「ここから先は正常に動いている」という地点が見つかります。その地点と結論の間に、原因があります。範囲が狭まれば、あとはメッセージの詳細を開いて確認するだけです。詳細の開き方はWRKJOBとDSPJOBLOGの使い方にまとめています。
最後のメッセージだけで判断しない
ジョブログ調査でよくある失敗は、最後に出ている「ジョブが異常終了しました」という結果メッセージだけを原因だと思ってしまうことです。本当の原因は、その少し前に出ているファイル未検出、権限不足、レコードロック、数値変換、配列範囲外、RPG実行時エラーなどです。
| メッセージ | よくある意味 | 確認ポイント |
|---|---|---|
| CPF | IBM i全般のメッセージ | 権限、ファイル、オブジェクト、コマンドエラー |
| RNX | RPG実行時エラー | 数値変換、ゼロ除算、配列、ファイル処理 |
| MCH | 低レベルの実行時エラー | プログラム異常、ポインタ、呼び出し関係 |
| CPA | 応答が必要な問い合わせ | MSGWで止まっている可能性 |
MSGWで止まった時
MSGW はジョブがメッセージ応答待ちで止まっている状態です。すぐに応答する前に、メッセージID、応答候補、対象プログラム、対象ファイル、発生時刻、後続処理への影響を確認します。応答値の意味が分からないまま C や I を返すと、処理を必要以上に停止させたり、危険な状態で継続したりすることがあります。
RPG・CLとつなげて読む
ジョブログだけで完結しない場合は、RPGやCLのソースと合わせて確認します。CLのMONMSGでエラーを拾っているのか、RPGのCHAINやUPDATEで失敗しているのか、呼び出し先プログラムで落ちているのかを分けて見ます。
関連する読み方は、RPG保守の確認ポイント と CLのCALL・SBMJOB・MONMSG でも整理しています。バッチ全体の確認は AS400のバッチ処理確認手順 を見てください。
対象のジョブログを見つける順番
ジョブログ調査で最初につまずきやすいのは、エラーの意味よりも「どのジョブを見ればよいか」です。画面名や処理名だけで探さず、分かっている情報に合わせて入口を変えます。
| 分かっている情報 | 確認の入口 | 記録するもの |
|---|---|---|
| ジョブ番号・ユーザー・ジョブ名 | DSPJOBLOG JOB(番号/ユーザー/ジョブ名) または WRKJOB | 三つを組み合わせた完全なジョブ名 |
| 実行ユーザーだけ | WRKUSRJOB USER(ユーザー) | 同時刻に動いた候補と状態 |
| ジョブ名だけ | WRKJOB JOB(ジョブ名) や稼働中ジョブの一覧 | 同名ジョブを時刻とユーザーで区別 |
| 処理は終了済み | WRKJOBLOG や出力済みスプール | 終了コード、最後の正常処理、原因メッセージ |
同じジョブ名が複数ある場合は、発生時刻だけで決めません。投入ユーザー、ジョブ番号、サブシステム、対象会社や処理日など、運用記録と照合してから対象を確定します。
ジョブログが短い・残っていない時の確認
原因になりそうなメッセージが見つからない時は、エラーがないと決めつけず、ジョブ記述のログ設定、ログ出力方法、CLプログラム内のメッセージ処理、スプールの出力先を確認します。本番のログ設定をその場で変更すると出力量や性能へ影響するため、変更は運用責任者と範囲を決めてから行います。
- ジョブ名・ユーザー・番号を取り違えていないか
- 原因メッセージがCLの
MONMSGで処理され、後続の結果メッセージだけ残っていないか - ジョブログがスプール化され、別の出力待ち行列に残っていないか
- ジョブ記述のログレベルとログ出力方法が調査に必要な範囲を残す設定か
調査メモに残す7項目
- 発生日時と利用者が行った操作
- ジョブ番号・ユーザー・ジョブ名
- 最初の原因候補と最後の結果メッセージ
- 対象プログラム、ファイル、ライブラリ
- MSGWへ応答した場合は応答値と判断者
- 再実行・取消・戻しの実施有無
- 帳票、後続バッチ、外部連携への影響
コマンドの詳細は、IBM Supportのジョブログ検索手順も確認してください。
ジョブログ調査を研修で扱うとき
ジョブログは、メッセージIDを検索するだけでは現場対応につながりません。発生時刻、ジョブ名、ユーザー、呼び出し元CL、対象RPG、対象ファイルを同じ線で追い、どこまでが結果メッセージで、どこからが原因候補なのかを分けて読む練習が必要です。
法人向けのAS400 / IBM i Codex研修では、ジョブログ、RPGソース、CL、実行環境を並べて確認し、Codexに読ませる前に何を伏せ、どこまでを要約すればよいかも扱います。詳細は AS400 / IBM i Codex研修の内容・料金 にまとめています。
まとめ
AS400 / IBM i のジョブログは、障害調査の出発点です。最後の結果メッセージだけでなく、直前の原因メッセージ、対象プログラム、対象ファイル、ライブラリ、呼び出し関係まで追うことで、RPGやCLのどこを見ればよいかが分かります。
