夜間バッチが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 | スプール、帳票、コンパイルリスト | 出力結果やエラーリストを見る |
バッチ確認の基本手順
バッチ処理は、「投入したか」だけで判断しない方が安全です。投入、待ち、実行中、メッセージ待ち、異常終了、出力確認、後続影響の順に見ます。
- 投入したコマンド、対象日、対象ライブラリ、対象会社や店舗を確認する
WRKSBMJOBで投入済みジョブの状態を見るWRKACTJOBで実行中、待ち、MSGWを確認する- 対象ジョブを選び、
WRKJOBからジョブログを確認する DSPJOBLOGで原因メッセージと結果メッセージを分けて読むWRKSPLFで帳票、エラーリスト、コンパイルリストを確認する- 後続処理、外部連携、再実行可否を確認してから対応する
MSGWで止まった時の考え方
MSGW は、ジョブがメッセージへの応答待ちで止まっている状態です。AS400保守でよくあるのは、夜間バッチがMSGWで止まり、翌朝の業務開始まで後続処理が進んでいないケースです。
MSGWを見つけても、すぐに応答してはいけません。まずメッセージID、メッセージ本文、対象プログラム、対象ファイル、ライブラリ名、発生時刻を確認します。応答値の意味が分からないまま C、I、R、D などを返すと、処理を止めすぎたり、逆に危ない状態で続行したりすることがあります。
| 見るもの | 確認する理由 |
|---|---|
| メッセージID | CPF、RNX、MCHなど、原因の種類を切り分ける |
| メッセージ本文 | 対象ファイル、ライブラリ、プログラム名を確認する |
| 発生時刻 | どの処理順で止まったかを見る |
| 応答候補 | キャンセル、再試行、無視、ダンプ取得などの意味を確認する |
| 後続影響 | 続行してよいか、止めるべきかを判断する |
ジョブログは最後だけ見ない
ジョブログを見る時は、最後のメッセージだけで判断しないことが大切です。最後に出ているメッセージは「処理が異常終了した」という結果であり、本当の原因は少し上の行に出ていることがあります。
例えば、最終的にはジョブ異常終了のメッセージが出ていても、その前に「ファイルが見つからない」「レコードロックで待っている」「権限がない」「数値変換で失敗した」といった原因が出ている場合があります。原因メッセージと結果メッセージを分けて読むことが、バッチ障害調査の基本です。
再実行する前に確認すること
バッチ処理で一番危ないのは、原因を確認しないまま再実行することです。処理によっては、途中までデータが更新されていることがあります。その状態で再実行すると、二重計上、二重出力、二重送信、在庫差異、帳票の重複につながることがあります。
| 確認項目 | 理由 |
|---|---|
| 途中更新の有無 | 一部データだけ更新されていないかを見る |
| コミット制御の有無 | 異常終了時に戻っているか、残っているかが変わる |
| 出力済みファイル | 外部連携や帳票が二重作成されないかを見る |
| 後続ジョブ | すでに次の処理が動いていないかを見る |
| 戻し手順 | 再実行前にデータを戻す必要があるかを見る |
夜間バッチで見るべき業務影響
販売管理システムでは、夜間バッチが止まると翌日の業務に影響しやすいです。受注、出荷、在庫、売上、請求、会計連携、外部連携のどこまで進んだかを確認します。
技術的にはジョブを再実行できても、業務的に再実行してよいとは限りません。例えば、出荷指示ファイルをすでに外部へ送っている場合、同じ処理を再実行すると二重送信になる可能性があります。バッチ障害では、技術ログと業務影響をセットで確認する必要があります。
初心者がやりがちな見落とし
- 投入しただけで完了したと思ってしまう
- MSGWにすぐ応答してしまう
- ジョブログの最後だけを見て原因と判断する
- 対象ライブラリを確認せずに調査する
- 後続ジョブや外部連携の影響を見ない
- 再実行前に途中更新や出力済みファイルを確認しない
バッチ処理の確認メモに残すこと
保守チームで引き継ぐなら、毎回の調査結果を同じ形式で残すと、次回対応がかなり楽になります。最低限、ジョブ名、ユーザー、ジョブ番号、発生時刻、メッセージID、対象プログラム、対象ファイル、対応内容、再実行有無、業務影響を残します。
| 項目 | 記録例 |
|---|---|
| ジョブ | JOB名、USER、JOB番号 |
| 発生時刻 | いつ止まったか、いつ気付いたか |
| メッセージID | CPF、RNX、MCHなど |
| 対象 | プログラム、ファイル、ライブラリ |
| 対応 | 応答値、再実行、戻し、連絡先 |
| 影響 | 出荷、売上、請求、外部連携など |
夜間バッチを引き継ぐ時に最初に見る順番
夜間バッチの引き継ぎでは、コマンド名だけを覚えるよりも、ジョブがどこから投入され、どのサブシステムで動き、止まった時に誰が何を見るかを決めておく方が実務では役に立ちます。障害時に焦らないためには、平常時の流れを先に整理しておくことが大切です。
| 確認順 | 確認する内容 | 次に読む記事 |
|---|---|---|
| 1. 投入元 | CL、スケジューラ、手動投入のどれか。SBMJOBの指定値も確認します。 | CLの読み方 |
| 2. 実行場所 | JOBQ、SBSD、実行ユーザー、ライブラリリストを確認します。 | サブシステム確認 |
| 3. 停止理由 | MSGW、異常終了、未実行、待機中の違いをジョブログで分けます。 | CPFエラーとジョブログ確認 |
| 4. 影響範囲 | 帳票、データ更新、後続ジョブ、外部連携への影響を確認します。 | WRKACTJOB確認 |
| 5. 社内教育 | 再実行してよい条件、止めて相談する条件、記録する内容をそろえます。 | AS400 / IBM i Codex実戦研修 |
バッチ処理は、担当者の経験に依存しやすい領域です。現地で画面や運用ルールを確認しながら、日次・月次・締め処理ごとに「正常時」「止まった時」「再実行前」の確認順をそろえておくと、若手への引き継ぎや属人化対策につながります。
まとめ
AS400のバッチ処理は、投入して終わりではありません。投入後の状態、MSGW、ジョブログ、スプール、後続影響、再実行可否まで確認して、はじめて安全に対応できます。
最初はコマンドをたくさん覚えるより、WRKACTJOB、WRKSBMJOB、WRKJOB、DSPJOBLOG、WRKSPLF の使い分けを押さえる方が実務に入りやすいです。ジョブログの読み方は AS400のジョブログ確認手順、保守全体の流れは AS400保守・運用完全ガイド もあわせて確認してください。
