MSGWで止まった時に見るメッセージと返信前の注意点は、MSGWの原因確認・返答手順で確認できます。
AS400 / IBM i のバッチ処理は、画面で人が操作している処理より見えにくいぶん、確認順を決めておくことが大切です。投入できたか、実行待ちなのか、実行中なのか、MSGWで止まっているのか、異常終了したのかを切り分けないと、夜間処理や月次処理の対応が遅れます。
この記事では、AS400初心者や保守担当者向けに、バッチ処理を確認する時の基本手順を現場目線で整理します。コマンド名の暗記ではなく、「今どの状態を確認しているのか」「次に誰へ連絡するのか」「再実行してよいのか」を判断するための流れとして読んでください。
AS400のバッチ処理とは
AS400 / IBM i のバッチ処理は、ユーザーの画面操作とは別に、ジョブキューへ投入され、サブシステム上で実行される処理です。販売管理システムであれば、受注締め、出荷データ作成、在庫引当、売上計上、請求データ作成、外部連携ファイル作成などがバッチ処理として動くことがあります。
バッチ処理は、ひとつのプログラムだけで完結するとは限りません。CLからRPGを呼ぶ、複数のプログラムを順番に実行する、途中でファイルを作成する、スプールを出す、後続ジョブへデータを渡す、という流れになっていることが多いです。そのため、止まったジョブだけを見ても全体影響が分からないことがあります。
| 処理例 | 現場で見るポイント | 止まった時の影響 |
|---|---|---|
| 受注締め | 対象日、対象店舗、対象会社、締め済み状態 | 出荷、在庫、売上計上へ影響する |
| 在庫引当 | 対象倉庫、対象伝票、引当結果 | 出荷可否や欠品判断へ影響する |
| 売上計上 | 計上日、対象伝票、エラー件数 | 請求、会計連携へ影響する |
| 外部連携 | 送受信ファイル、送信先、再送可否 | 取引先や別システムへ影響する |
まず確認するコマンド
バッチ処理の調査では、最初からソースを読みに行くより、まずジョブの状態を確認します。よく使う入口は、WRKACTJOB、WRKSBMJOB、WRKJOB、DSPJOBLOG、WRKSPLF です。
| コマンド | 見ること | 使う場面 |
|---|---|---|
| WRKACTJOB | 実行中ジョブ、MSGW、CPU使用、状態 | 今止まっているジョブを探す |
| WRKSBMJOB | 自分や対象ユーザーが投入したジョブ | 投入済みか、待ちか、終了済みかを見る |
| WRKJOB | ジョブ詳細、ジョブログ、スプール、属性 | 対象ジョブを深掘りする |
| DSPJOBLOG | メッセージID、重大度、異常終了原因 | 原因メッセージを探す |
| WRKSPLF | スプール、帳票、コンパイルリスト | 出力結果やエラーリストを見る |
バッチが止まった場所を5段階で分ける
「バッチが終わらない」という連絡だけでは、まだ再実行の判断はできません。未投入、ジョブキュー待ち、実行中、応答待ち、終了後の後続未完了を分けると、確認先がはっきりします。
| 段階 | 見える状態 | 次に確認すること |
|---|---|---|
| 1. 未投入 | 対象ジョブが見つからない | スケジューラ、投入元CL、投入条件、直前ジョブ |
| 2. 実行待ち | JOBQにある | ジョブキューの保留、サブシステム、同時実行数 |
| 3. 実行中 | ACTIVEだが進まない | CPU、ロック、待機状態、処理件数の変化 |
| 4. 応答待ち | MSGW | メッセージID、応答候補、対象プログラム、業務影響 |
| 5. 終了後 | ジョブは終了したが帳票や連携がない | 終了コード、スプール、後続ジョブ、作成ファイル、送信結果 |
MSGWで止まった時の考え方
夜間バッチで本当に困るのは、確認の仕方ではなく再実行してよいかを判断できる人が一人しかいないことです。その判断に必要な材料をそろえる手順を扱うのが現場向けCodex実践研修（法人向け・半日ハンズオン）です。
MSGW は、ジョブがメッセージ待ちになっている状態です。照会への応答待ちと、通常のメッセージ受信待ちを区別して確認します。AS400保守でよくあるのは、夜間バッチがMSGWで止まり、翌朝の業務開始まで後続処理が進んでいないケースです。
MSGWを見つけても、すぐに応答してはいけません。まずメッセージID、メッセージ本文、対象プログラム、対象ファイル、ライブラリ名、発生時刻を確認します。応答値の意味が分からないまま C、I、R、D などを返すと、処理を必要以上に停止させたり、逆に危ない状態で続行したりすることがあります。
| 見るもの | 確認する理由 |
|---|---|
| メッセージID | CPF、RNX、MCHなど、原因の種類を切り分ける |
| メッセージ本文 | 対象ファイル、ライブラリ、プログラム名を確認する |
| 発生時刻 | どの処理順で止まったかを見る |
| 応答候補 | キャンセル、再試行、無視、ダンプ取得などの意味を確認する |
| 後続影響 | 続行してよいか、止めるべきかを判断する |
ジョブログは最後だけ見ない
ジョブログを見る時は、最後のメッセージだけで判断しないことが大切です。最後に出ているメッセージは「処理が異常終了した」という結果であり、本当の原因は少し上の行に出ていることがあります。
例えば、最終的にはジョブ異常終了のメッセージが出ていても、その前に「ファイルが見つからない」「レコードロックで待っている」「権限がない」「数値変換で失敗した」といった原因が出ている場合があります。原因メッセージと結果メッセージを分けて読むことが、バッチ障害調査の基本です。
再実行する前に確認すること
バッチ処理で一番危ないのは、原因を確認しないまま再実行することです。処理によっては、途中までデータが更新されていることがあります。その状態で再実行すると、二重計上、二重出力、二重送信、在庫差異、帳票の重複につながることがあります。
| 確認項目 | 理由 |
|---|---|
| 途中更新の有無 | 一部データだけ更新されていないかを見る |
| コミット制御の有無 | 異常終了時に戻っているか、残っているかが変わる |
| 出力済みファイル | 外部連携や帳票が二重作成されないかを見る |
| 後続ジョブ | すでに次の処理が動いていないかを見る |
| 戻し手順 | 再実行前にデータを戻す必要があるかを見る |
夜間バッチで見るべき業務影響
販売管理システムでは、夜間バッチが止まると翌日の業務に影響しやすいです。受注、出荷、在庫、売上、請求、会計連携、外部連携のどこまで進んだかを確認します。
技術的にはジョブを再実行できても、業務的に再実行してよいとは限りません。例えば、出荷指示ファイルをすでに外部へ送っている場合、同じ処理を再実行すると二重送信になる可能性があります。バッチ障害では、技術ログと業務影響をセットで確認する必要があります。
バッチ処理の確認メモに残すこと
保守チームで引き継ぐなら、毎回の調査結果を同じ形式で残すと、次回対応がかなり楽になります。最低限、ジョブ名、ユーザー、ジョブ番号、発生時刻、メッセージID、対象プログラム、対象ファイル、対応内容、再実行有無、業務影響を残します。
| 項目 | 記録例 |
|---|---|
| ジョブ | JOB名、USER、JOB番号 |
| 発生時刻 | いつ止まったか、いつ気付いたか |
| メッセージID | CPF、RNX、MCHなど |
| 対象 | プログラム、ファイル、ライブラリ |
| 対応 | 応答値、再実行、戻し、連絡先 |
| 影響 | 出荷、売上、請求、外部連携など |
まとめ
AS400のバッチ処理は、投入して終わりではありません。投入後の状態、MSGW、ジョブログ、スプール、後続影響、再実行可否まで確認して、はじめて安全に対応できます。
最初はコマンドをたくさん覚えるより、WRKACTJOB、WRKSBMJOB、WRKJOB、DSPJOBLOG、WRKSPLF の使い分けを押さえる方が実務に入りやすいです。ジョブログの読み方は AS400のジョブログ確認手順、保守全体の流れは AS400保守・運用完全ガイド もあわせて確認してください。
リランで怖いのは、同じデータが二度登録されることです。出荷連携での確認手順は出荷データの二重送信・未送信の調べ方にまとめています。
関連: より具体的な確認手順は、AS400月次締め・請求締めが終わらない時の確認手順｜夜間バッチ・ジョブログ・再実行判断で整理しています。
