AS400 / IBM i の保守で怖いのは、日中の軽いエラーよりも、夜間バッチが止まって翌日の業務開始に影響するケースです。販売管理システムでは、受注、出荷、在庫引当、売上計上、請求、店舗連携、物流連携などがつながっているため、夜間処理のどこかが止まると、翌朝に基幹システムを使えない、外部連携データが届かない、帳票が出ていない、といった状態につながることがあります。
このページでは、AS400の夜間バッチ障害を見つけた時に、どの画面から確認し、どの順番でジョブログまで追うかを現場目線で整理します。単なるコマンド説明ではなく、実際の保守で「投入しただけで安心しない」「MSGWを見つけたら勝手に返答しない」「DやGを安易に返さない」という判断を重視しています。
現場目線の結論 夜間バッチ障害では、まずWRKACTJOBで異常ジョブやMSGWを探し、必要に応じてWRKSBMJOBで投入済みジョブを確認し、最後はジョブログで原因を追います。ジョブを強制終了する、DやGを返す、原因を見ずに再投入する、といった対応は二次災害になりやすいので避けます。
本番障害の初動対応も確認 作業者、環境、影響範囲、ジョブログ、MSGW、データリカバリーをどの順番で見るかは、AS400本番障害の初動対応チェックリスト にまとめています。焦って作業する前の確認用に使えます。
販売管理システム保守の全体像も確認 受注、出荷、在庫、売上、請求、店舗連携、物流連携をAS400保守でどう見るかは、AS400販売管理システム保守ガイド にまとめています。業務影響を見ながら保守するための入口です。
- 夜間バッチ障害で最初に見る全体フロー
- 深夜のMSGWで、私が最初にやったのは電話でした
- 1. WRKACTJOBでMSGWと暴走ジョブを見る
- 2. MSGWを見つけても勝手に返答しない
- 3. WRKSBMJOBで投入済みジョブを確認する
- 4. ジョブログで原因と結果を分けて読む
- 5. 販売管理で夜間バッチが止まると怖い処理
- 6. 再投入・リカバリー前に確認すること
- 7. 若手に伝えたい夜間バッチ対応の注意点
- リランで一番怖いのは、データが二重にできること
- 夜間バッチ障害対応チェックリスト
- 予定時刻を過ぎてもバッチが始まらない例
- 関連して読む記事
- JOBQ・SBSD・JOBSCDEでバッチを確認する
- MSGWでジョブが止まった時
- 夜間バッチは早期検知と返信判断が勝負になる
- 夜間バッチ停止はスケジュールと投入状態も確認する
- 夜間バッチ停止を朝までに収める
夜間バッチ障害で最初に見る全体フロー
夜間バッチ障害では、いきなりソースやデータを見に行くより、まず「ジョブが動いているのか」「止まっているのか」「MSGWで待っているのか」を確認します。自分なら、最初にWRKACTJOBを見て、暴走ジョブがCPUを食っていないか、MSGWで止まっているジョブがないかを確認します。
| 順番 | 見るもの | 確認すること | 関連記事 |
|---|---|---|---|
| 1 | WRKACTJOB | CPU使用率、MSGW、RUN、DEQW、SELWなどの状態を確認 | WRKACTJOBの見方 |
| 2 | WRKSBMJOB | 自分や該当ユーザーが投入したバッチジョブの状態を確認 | SBMJOB/WRKSBMJOB |
| 3 | WRKJOB | ジョブのスプール、ジョブログ、実行属性を確認 | WRKJOB/DSPJOBLOG |
| 4 | DSPJOBLOG | メッセージID、重大度、エラー前後の流れを確認 | ジョブログ確認手順 |
| 5 | 業務影響 | 受注、出荷、在庫、外部I/F、翌日業務への影響を確認 | AS400データ復旧｜本番障害で戻す・リランする前に確認すること |
深夜のMSGWで、私が最初にやったのは電話でした
昔の話です。夜間バッチでMSGWが出ると、携帯にメールで通知が届く仕組みになっていました。深夜に鳴るので、画面を見るより先に目が覚めます。
通知を見て私が最初にやったのは、コマンドを打つことではなく上司に電話することでした。その後で状況を調べ、対応策を考えて実行する、という順番です。
手順書に起こすと「まずWRKACTJOBで確認、次にジョブログ」から始まります。ですが実際の順番は違いました。調べるより先に、人に連絡していました。順番として見ると、深夜の判断を一人で抱えない形になっています。夜中に一人で決めて動かした結果は、翌朝、自分ひとりで説明することになります。
なお、リランで実際にデータが二重になったことがあったかどうかは、正直なところ覚えていません。この記事の他の部分に書いた確認事項は、そうならないための一般的な注意点として読んでください。覚えていないことを、あったことにして書くつもりはありません。
1. WRKACTJOBでMSGWと暴走ジョブを見る
WRKACTJOBは、AS400上で動いているジョブを一覧で見る入口です。夜間バッチが怪しい時は、まずここでCPU使用率が異常に高いジョブがないか、MSGWで待っているジョブがないかを見ます。WRKACTJOBでF5更新を続けるだけでは、原因の切り分けに必要な情報が不足します。状態を見て、次に何を調べるかを決めるために使います。
WRKACTJOB 状態の例: RUN 実行中 DEQW 待機中 SELW 選択待ち MSGW メッセージ待ち
特に見るべきなのはMSGWです。MSGWは、ジョブがメッセージ返答待ちで止まっている状態です。販売管理システムで外部I/Fや夜間バッチがMSGWになっていると、翌朝に店舗連携、物流連携、帳票出力、会計連携などへ影響する可能性があります。
2. MSGWを見つけても勝手に返答しない
MSGWを見つけた時に一番危ないのは、原因を見ずにジョブを強制終了したり、DやGを返してしまうことです。原因を確認しないままWRKACTJOBから4番でジョブを強制終了すると、影響が広がる可能性があります。まず落ち着いて、ジョブログを見て、何が起きているのかを把握します。
| 返答例 | 意味の例 | 現場での考え方 |
|---|---|---|
| C | キャンセル | 処理を止める判断。後続影響を確認してから使う |
| I | 無視 | 無視して続行する判断。安全に進めてよい根拠が必要 |
| R | 失敗したコマンドや入出力操作の再試行 | 原因が解消しても、途中更新・二重処理・再開位置を確認し、承認された場合だけ返信する |
| D | ダンプを取ってキャンセル | リトライできる可能性を消すことがあるため、勝手に返さない |
| G | 該当するILE RPG照会ではGet Input | RPGサイクルの入力処理へ戻る。Rと同じ再試行ではなく、再開位置とデータへの影響を確認する |
以前、状況を確認せずDを返したことで、復旧が難しくなったことがあります。リトライで復旧できたかもしれない処理を、Dでキャンセルしてしまうと、その後のリカバリーが難しくなることがあります。MSGWは「返せば終わり」ではありません。返答する前に、必ずジョブログと業務影響を見ます。
上の表は例であり、すべての照会に共通する返答一覧ではありません。有効な選択肢と意味はメッセージ詳細で確認します。DやCで終了する範囲はプログラム／プロシージャと呼出し側の例外処理にも依存し、Dを返せば必ずジョブ全体が終了するとは限りません。IBM公式：ILE RPGの未処理の例外も参照してください。
MSGWの返答判断は、AS400 MSGWとは？原因確認・返答手順と夜間バッチのリラン判断 にまとめています。C/I/R/D/Gの意味だけでなく、若手がやりがちな危険操作も確認しておくと安全です。
3. WRKSBMJOBで投入済みジョブを確認する
SBMJOBは、バッチ処理を投入するコマンドです。画面でプログラムをCALLすると、自分の画面はその処理が終わるまで待ちになります。一方でSBMJOBを使うと、処理はバッチジョブとして投入され、自分の画面はすぐ使えるようになります。
以下は仕組みの説明用です。障害調査のために本番で実行・再投入しないでください。 オンライン実行の例: CALL PGM(TEST001R) バッチ投入の例: SBMJOB CMD(CALL PGM(TEST001R)) JOB(TEST001)
ここで初心者がやりがちなのは、SBMJOBで投入した時点で「処理が終わった」と思ってしまうことです。実際には、ジョブはQBATCHなどのサブシステム内で動きます。投入しただけでは完了ではありません。WRKSBMJOBやWRKACTJOBで、RUNなのか、MSGWなのか、終了しているのかを確認します。
WRKSBMJOB SBMFROM(*JOB) は、このコマンドを実行中のジョブから投入したジョブが対象です。同じユーザープロファイルのジョブから投入したものを見る指定は SBMFROM(*USER) です。別のスケジューラから投入されたジョブが見えないこともあるため、一覧にないだけで未実行とは判断しません。また、投入時にDSPSBMJOB(*NO)を指定したジョブは表示されません。IBM公式：WRKSBMJOBの対象範囲を確認してください。夜間バッチでは、投入済みジョブが止まっていないか、終わったつもりのジョブがアベンドしていないかを見るために使います。
4. ジョブログで原因と結果を分けて読む
ジョブログを見る時は、最後に出ているエラーだけを見て判断しないことが大切です。最後のエラーは、原因ではなく結果として出ていることがあります。自分なら、ログの一番下の重大度やメッセージを見たうえで、少し上に戻って、何でアベンドしたのか、どのプログラムやファイルで止まったのかを追います。
| 見るポイント | 判断すること |
|---|---|
| メッセージID | CPF、RNX、MCHなど、どの種類のエラーか |
| 重大度 | 警告なのか、処理停止に近いエラーなのか |
| プログラム名 | どのRPG/CLで止まったのか |
| ファイル名・ライブラリ名 | 対象環境や参照先が間違っていないか |
| エラー前後のメッセージ | 原因メッセージと結果メッセージを切り分ける |
メッセージIDの見方は、AS400メッセージID・エラーコード一覧、CPF系はCPFエラー一覧、RNX（RPG実行時エラーのメッセージID）系はRNXエラー一覧にも整理しています。
5. 販売管理で夜間バッチが止まると怖い処理
販売管理システムでは、夜間バッチが止まると、翌日業務にそのまま影響することがあります。受注、発注、出荷、在庫引当、売上計上、請求、店舗連携、物流連携などは、ひとつの処理だけで完結していないことが多いです。どこかが止まると、後続処理に影響します。
| 処理 | 止まった時の怖さ | 最初に見ること |
|---|---|---|
| 受注連携 | 翌日の出荷や在庫引当に影響する | 連携データ作成済みか、後続バッチが動いたか |
| 出荷処理 | 物流側へデータが渡らない可能性がある | 外部I/F、帳票、出荷指示データ |
| 在庫引当 | 在庫数や引当状態に差異が出る可能性がある | 対象ファイル、更新件数、再実行可否 |
| 売上計上 | 会計連携や請求に影響する | 計上済みデータ、二重計上リスク |
| 店舗・物流連携 | 外部システムとの送受信が止まる | I/Fファイル、送受信履歴、再送可否 |
現場では、バックオフィス系よりも、まず商品が客に届くところ、受注や発注が動くところを優先して確認します。もちろんシステムによりますが、販売管理では「どの業務が止まると翌朝困るか」を意識して調査順を決めます。
6. 再投入・リカバリー前に確認すること
夜間バッチが止まった時、すぐ再投入すればよいとは限りません。途中までデータが作られている場合、再投入で二重作成になることがあります。逆に、前処理が終わっていないのに後続だけ動かすと、古いデータや不完全なデータを元に処理してしまうことがあります。
- 対象ジョブがどこまで進んだか
- 対象ファイルにデータが作られているか
- 後続処理が動いているか、止まっているか
- 再投入して二重処理にならないか
- リカバリーSQLや手作業更新が必要か
- ライブラリリスト、対象ファイル、実行環境が正しいか
データリカバリーが必要な場合は、必ず影響範囲、対象ファイル、実施内容、実行環境を整理します。特にSQLでデータ修正をする場合は、ライブラリ名の確認が重要です。詳しくはAS400データ復旧にまとめています。
7. 若手に伝えたい夜間バッチ対応の注意点
若手に夜間バッチ対応を教えるなら、まず「MSGWを見つけたら上長に報告」と伝えます。今どきは監視や検知システムで自動的にメールが届く仕組みを作っている現場も多いですが、それでも人が見るべき判断は残ります。
危ないのは、焦って勝手にDを返す、ジョブを強制終了する、投入しただけで完了したと思い込む、ジョブログを見ずに再実行する、といった行動です。夜間バッチは、単体のプログラムだけでなく、翌日の業務全体につながっています。落ち着いて、ジョブ、ログ、業務影響、再実行可否の順に確認します。
リランで一番怖いのは、データが二重にできること
夜間バッチが落ちた朝、一番やってはいけないのは「落ちたからもう一度流す」です。まず何が起きてどういう状態かを確認し、再実行条件を満たし、責任者が安全と判断できた場合に限ってリランします。
確認を先に置く理由は単純で、リランするとデータが二重にできることがあるからです。バッチが途中まで更新して落ちていれば、その分はもう反映されています。頭から流し直すと、同じ更新をもう一度かけることになります。売上が二重に計上される、出荷データが二重に送られる、請求が二重に立つ。どれも後から直すほうが何倍も大変です。
リラン前に確認する状態
| 確認 | 見る内容 | 二重になるとどうなるか |
|---|---|---|
| どこまで更新されたか | 更新対象ファイルの件数、最終更新のキー、ジョブログの進み具合 | 途中まで反映済みの分をもう一度かける |
| 後続処理が走っていないか | 後続ジョブ、JOBQ、スケジュール | 先に進んだ処理を前提に、また同じ処理が動く |
| 外部へ送信済みか | EDI、FTP、CSV、相手先への通知 | 取引先に同じデータが二度届く |
| 中間ファイル・ワークの状態 | クリアされているか、前回分が残っていないか | 前回分と今回分が混ざる |
確認後も、リラン・補正・停止継続を分けて判断する
確認後は、リラン、途中からの再開、データ補正、停止継続のどれが安全かを決めます。判断を先送りして業務影響を広げないことは重要ですが、期限が迫っていても、二重処理や誤送信の可能性が残る状態ではリランしません。責任者と業務担当へ判断を上げ、暫定対応と恒久対応を分けます。
再実行する場合は、状態を確定し、二重にならない条件を作り、その条件自体をレビューします。途中からの再開、更新済み分の除外、対象日付の限定は有効な候補ですが、場当たり的に条件を書き換えず、テスト、更新前退避、実行後検証をそろえます。
逆に言うと、どこまで進んだか分からない状態でリランするのが一番危険です。その場合は流す前に、更新前データが戻せるかを確認します。判断の順番はAS400ジャーナル確認手順と同じで、戻せる状態を先に用意してから動きます。
夜間バッチ障害対応チェックリスト
| チェック | 確認内容 |
|---|---|
| ジョブ状態 | WRKACTJOBでRUN/MSGW/DEQW/SELWを確認したか |
| 投入状況 | WRKSBMJOBで投入済みジョブを確認したか |
| ジョブログ | 最後のエラーだけでなく、前後の流れを見たか |
| 業務影響 | 受注、出荷、在庫、外部I/F、翌日業務への影響を見たか |
| 返答判断 | C/I/R/D/Gを勝手に返していないか |
| 再投入判断 | 二重処理、途中データ、後続処理への影響を確認したか |
| 環境確認 | ライブラリリスト、対象ファイル、本番/テスト環境を確認したか |
| 共有 | ジョブ名、ユーザー、番号、メッセージID、判断内容を共有したか |
予定時刻を過ぎてもバッチが始まらない例
JOBSCDEに登録があっても、ジョブ投入、JOBQ、SBSDの各段階で待つ可能性があります。どこまで進んだかを順番に確認します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 予定 | 登録名、次回実行日時、曜日、保留状態、投入コマンドを確認する | 時刻やカレンダー条件の誤りを分ける |
| JOBQ | 対象ジョブが投入済みか、ジョブキューが保留されていないか確認する | 未投入と投入後待機を混同しない |
| SBSD | サブシステムの稼働、JOBQ割り当て、実行枠、ジョブ記述を確認する | 同じジョブを手動で重複投入しない |
手動実行する場合は、予定ジョブが後から開始しないよう状態を管理し、重複処理の影響を確認します。復旧後は次回予定時刻と通常運用へ戻した設定を記録します。
公式情報: IBM Documentation: Job queues
関連して読む記事
- AS400 WRKACTJOBの見方
- AS400 SBMJOB・WRKSBMJOB・DSPJOBDの確認手順
- AS400のジョブログ確認手順
- AS400 MSGWとは？原因確認・返答手順と夜間バッチのリラン判断
- AS400データ復旧｜本番障害で戻す・リランする前に確認すること
- AS400の本番対応で初心者がやってはいけないこと
法人向けのAS400 / IBM i × Codex研修について
AS400 / IBM i の開発・保守でCodexを活用する法人向け研修を行っています。御社PC・御社環境で、RPG/CLソース読解、プログラム調査、改修案作成、動作確認・テストまで実戦形式で学べます。
JOBQ・SBSD・JOBSCDEでバッチを確認する
夜間バッチが始まらない、ジョブキューに溜まる、予定時刻に動かない時は、AS400のJOBQ・SBSD・JOBSCDE確認ポイント を確認してください。投入前、投入待ち、実行中、異常停止を分けて見ます。
MSGWでジョブが止まった時
ジョブがMSGWで止まっている時は、すぐ返信する前に AS400のMSGW対応手順 を確認してください。ジョブ名、メッセージID、ジョブログ、応答候補、業務影響を残してから判断すると、保守会社や開発担当へ説明しやすくなります。
夜間バッチは早期検知と返信判断が勝負になる
25年以上AS400現場を見ていると、夜間バッチ停止や本番環境でのプログラムアベンドの相談で多いのは、原因そのものより「いつ止まったか分からない」「朝まで気づけなかった」「MSGWの返信判断が分からない」という初動の問題です。在庫照会、出荷確定、請求締めのような業務では、夜間処理の停止が翌日の現場作業に直結します。
監視サービスを使う方法もありますし、MSGWを検知してメール配信する仕組みを自社向けに作る方法もあります。大事なのは、通知を出すだけで終わらせず、ジョブ名、メッセージID、応答候補、後続処理、リカバリー手順まで運用に落とすことです。
関連: MSGWや夜間バッチ停止を早く見つけたい場合は、MSGWを早期検知してメール通知する考え方 で、検知対象、通知先、返信判断、業務影響を整理してください。
夜間バッチ停止はスケジュールと投入状態も確認する
夜間バッチ停止の調査では、止まったジョブだけでなく、そもそも予定通り投入されたか、JOBQやSBSDで待っていないかも確認します。JOBSCDE、JOBQ、SBSDの確認はJOBQ・SBSD・JOBSCDE確認、投入済みジョブの確認はSBMJOB・WRKSBMJOB確認を合わせて見てください。
関連: ジョブログをどの順番で読めばよいか迷う場合は、AS400ジョブログの見方で、DSPJOBLOGからCPF・RNX・MSGWの原因を追う流れを確認できます。
関連: AS400月次締め・請求締めが終わらない時の確認手順は、こちらの記事で確認できます。
関連: AS400が遅い時の確認手順｜WRKACTJOB・ロック・バッチ負荷・SQLを切り分ける で、CPU、ロック、バッチ負荷、SQLの切り分けも確認できます。
関連: AS400 MSGW監視とメール通知の考え方｜夜間バッチ停止を早く検知する仕組み
夜間バッチ停止を朝までに収める
夜間バッチ停止では、止まったジョブだけを見ると判断を誤ります。MSGW、再実行可否、締め処理、出荷、請求、在庫更新、後続ジョブの開始条件を並べて確認します。朝の業務開始に影響する場合は、原因調査と暫定復旧を分けて進めるのが現実的です。
- MSGWでジョブが止まった時の確認
- MSGW早期検知と通知
- 現場で多いAS400相談トップ10
夜間バッチ対応を、翌朝に慌てない手順へ整理する
夜間バッチ障害は、止まったジョブだけでなく、後続処理、締め、出荷、請求、外部連携まで確認します。法人向けCodex研修では、ジョブログ確認と業務影響の聞き取りを合わせて、社内で説明できる確認順に落とし込みます。
関連: より具体的な確認手順は、AS400日次監視チェックリスト｜朝一番に見るジョブ・メッセージ・容量・スプールで整理しています。