AS400 WRKPRB・ANZPRBの確認ポイント|問題ログから障害原因を調べる

WRKPRBを見る前に整理しておく情報

WRKPRB や ANZPRB は、AS400 / IBM i 側で発生した問題の入口を確認するための手段です。ただし、問題ログだけを見ても業務影響までは判断できません。確認前に、発生時刻、操作していた画面、対象ジョブ、出ていたメッセージID、直前に実施した変更、同時刻に動いたバッチをメモしておくと、後から原因を追いやすくなります。

  • 発生時刻が分かる場合: その時間帯のジョブログ、QSYSOPR、履歴ログを合わせて見る
  • 画面や帳票で異常が出た場合: 操作ユーザー、端末、帳票名、OUTQを控える
  • 変更後に起きた場合: PTF、プログラム入替、CL変更、権限変更の有無を確認する
  • 再発している場合: 同じメッセージIDや同じジョブ名で絞り込む

問題ログの確認だけで終わらせず、QSYSOPRメッセージ確認ジョブログ確認リリース後の切り戻し判断 とつなげて見ると、現場での説明や再発防止に使いやすくなります。調査手順を若手へ引き継ぐ場合は、AS400 / IBM i Codex研修 で調査メモの作り方まで整理できます。

問題ログを見た後に確認するもの

WRKPRBやANZPRBは、障害の入口として役立ちます。ただし、問題ログだけで原因を決めるのではなく、同じ時刻のジョブログ、MSGW(メッセージ応答待ち)、システムメッセージ、利用者の操作を合わせて見ます。問題ログを印刷や画面コピーで残す場合は、調査時刻も一緒に残しておくと後で追いやすくなります。

  • 問題ログの時刻とジョブログの時刻を合わせる
  • 同時刻にMSGWや通信エラーがないか見る
  • 再発時に同じ問題番号で追えるように記録する

WRKPRBを見ても原因が分からない時

問題ログは障害の手がかりですが、業務影響までは教えてくれません。WRKPRBやANZPRBを見た後は、同じ時刻に利用者が何をしていたか、MSGWが残っていないか、通信や装置関連のメッセージが出ていないかを確認します。

問題ログで見るもの次に確認するもの
発生時刻同時刻のジョブログ、DSPMSG、運用予定
装置名・資源名通信、プリンター、ディスク、テープ装置の状態
重大度業務停止か、警告として経過観察か

問題ログは「原因確定」ではなく、調査の入口として扱う

WRKPRBやANZPRBで問題ログを見ると、エラーの発生時刻や関連するジョブ、システム側の検出情報を確認できます。ただし、問題ログだけで原因が確定するとは限りません。実務では、問題ログを入口にして、ジョブログ、QSYSOPR、直前の変更、バッチ実行状況までつなげて確認します。

確認する情報見る理由次に確認する記事
発生日時同じ時間帯のジョブ、MSGW、バッチ停止と照合するためWRKJOBとDSPJOBLOG
関連ジョブ問題ログと実行ジョブの関係を見るためCPFエラーとジョブログ
QSYSOPRメッセージオペレーター応答待ちや装置系メッセージを見落とさないためQSYSOPR確認
直前の変更PTF、設定変更、バッチ改修との関係を見るためリリース・戻し確認
引き継ぎ観点次回同じ問題が出た時に、誰でも追える状態にするため研修内容・料金を見る

若手や兼任担当へ教える場合は、「問題ログを見る」だけでなく、「問題ログで得た情報を、どの順番で裏取りするか」までセットにすると実務で使いやすくなります。障害対応メモには、見たコマンド、確認したジョブ名、判断した理由、未確認の点を分けて残すと、後日の再調査でも迷いにくくなります。

問題ログとジョブログを使い分ける例

装置エラーが疑われる場合、WRKPRBの問題ログは有力な入口ですが、業務プログラムの失敗をすべて記録する一般的なジョブログではありません。

確認点確認内容判断
問題ログ発生時刻、リソース、メッセージID、状態、分析結果を確認するシステムまたはユーザー検出の問題記録を追う
ジョブログ同時刻のジョブ、CPF/RNX、呼び出し元を確認する業務処理側の直接原因を追う
時系列QHSTやQSYSOPRと照合して前後関係を作る問題ログだけで原因確定としない

ANZPRBは未記録のユーザー検出問題を分析し、結果を問題記録へ残す用途があります。権限と保守契約上の手順を確認し、削除や報告操作は勝手に行いません。

仕様確認: IBM公式のANZPRB解説