AS400のジョブログ確認手順｜エラー調査で最初に見るポイント

2026.05.22

症状に応じて、CPF4101の確認ポイント、RNXエラー一覧、バッチ処理が止まった時の確認手順 も参考にしてください。

AS400 / IBM iでエラーが出たものの、どのジョブログを開けばよいか分からない人向けの記事です。ジョブ名・ユーザー・番号を手掛かりに対象を絞り、実行中と終了済みで確認先を選ぶ手順を整理します。

対象ログでメッセージID、プログラム、ファイル、ライブラリを確認し、次の調査へ渡す情報をそろえます。ジョブログが短い・見つからない場合の確認先と、筆者が末尾から遡って読む方法も扱います。

ジョブログで分かること

見るもの分かること次に確認する先
メッセージIDCPF、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実行時エラーなどです。

メッセージよくある意味確認ポイント
CPFIBM i全般のメッセージ権限、ファイル、オブジェクト、コマンドエラー
RNXRPG実行時エラー数値変換、ゼロ除算、配列、ファイル処理
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項目

  1. 発生日時と利用者が行った操作
  2. ジョブ番号・ユーザー・ジョブ名
  3. 最初の原因候補と最後の結果メッセージ
  4. 対象プログラム、ファイル、ライブラリ
  5. MSGWへ応答した場合は応答値と判断者
  6. 再実行・取消・戻しの実施有無
  7. 帳票、後続バッチ、外部連携への影響

コマンドの詳細は、IBM Supportのジョブログ検索手順も確認してください。

まとめ

AS400 / IBM i のジョブログは、障害調査の出発点です。最後の結果メッセージだけでなく、直前の原因メッセージ、対象プログラム、対象ファイル、ライブラリ、呼び出し関係まで追うことで、RPGやCLのどこを見ればよいかが分かります。

スポンサーリンク