AS400 MSGWとは？原因確認・返答手順と夜間バッチのリラン判断

AS400 / IBM i の保守で WRKACTJOB を見ていると、ジョブの状態に MSGW が出ていることがあります。

MSGW は、ジョブがメッセージ待ちになっている状態です。照会への応答を待つ場合のほか、プログラムがメッセージを受信するための通常待機もあります。このページでは、主に照会への応答待ちで業務が止まった場合の確認と返答判断を扱います。

この記事では、MSGWを見つけた時に最初に確認すること、C / I / R / D の考え方、初心者がやってはいけない操作、販売管理システムでMSGWが怖い理由を、現場目線で整理します。

MSGWとは

MSGW は Message Wait、つまりメッセージ待ちです。照会への応答待ちの場合は、AS400上のジョブがエラーや確認メッセージへの返答を待っています。

販売管理システムのような基幹処理では、MSGWになっているジョブがあると、後続のバッチ処理、データ連携、売上計上、請求、物流連携などに影響することがあります。

ただし、MSGWを見つけたからといって、すぐにジョブを終わらせればよいわけではありません。むしろ、焦って返答すると二次災害につながることがあります。

MSGWを見つけた時に最初に確認すること

MSGWを見つけた時、私が最初に確認するのは詳細メッセージです。画面上では、対象ジョブに対して7番を使って詳細メッセージを確認します。

WRKACTJOB
-- MSGW のジョブを見つける
-- 対象ジョブで 7=メッセージの表示 を確認する

詳細メッセージを見ないまま返答するのは危険です。何が起きているのか、どのプログラムで止まっているのか、リトライできるのか、キャンセルすべきなのかを判断する材料が足りないからです。

表示された返信候補はジョブログを見て判断する

MSGWでは、状況によって C、I、R、D、G などの返答を選ぶことがあります。

C / I / R / D / Gが常にすべて表示されるわけではありません。有効な返信候補は、メッセージIDとメッセージ記述によって異なります。画面に表示された候補と二次レベルの説明を確認し、ジョブログ、更新済みデータ、後続処理への影響を見て判断してください。

ただし、返答は必ずジョブログを見て判断します。メッセージだけを見て反射的に返すものではありません。

DやGを含む返信文字の意味は、メッセージ記述によって異なります。画面に候補が表示されても、文字だけで処理結果を決めつけず、二次レベルの説明とジョブログを確認します。ダンプ取得、取消、継続、再試行などを伴う場合は、途中更新と後続処理への影響を確認し、運用手順と責任者の承認に従います。

Dを返す前に影響を確認する

MSGWで避けたいのは、詳細を確認しないまま D を返すことです。

Dがダンプ取得と取消を意味する照会では、例外を受けたプログラムやプロシージャが終了し、呼出し側へ影響が及ぶことがあります。ジョブ全体が終了するかは呼出し側の例外処理などにも依存します。有効な返信とその意味を二次レベルの説明で確認し、復旧に必要な証跡と途中更新を確かめてから判断します。

以前の現場で、詳細を確認しないままDが返され、復旧対応が大きくなったことがありました。「メッセージが出ているから早く消す」という感覚で返答すると、原因が解消し、再試行してよいと確認できた処理までキャンセルしてしまうことがあります。

本番環境で返答する時の判断は、本番対応で初心者がやってはいけないことにもまとめています。

また、別記事でも書いている通り、WRKACTJOBの4番はジョブの終了操作です。終了には制御終了と即時終了があり、4番を選ぶこと自体が常に強制終了を意味するわけではありません。いずれも業務への影響を確認して承認を受けます。MSGWは「止まっているから消せばいい」という状態ではありません。処理途中のデータや後続処理が残っていることがあります。

販売管理でMSGWが怖いのはデータI/F系

販売管理システムでMSGWが出た時の業務影響は、一概には言えません。受注、出荷、在庫、売上、請求、店舗連携、物流連携など、止まっている処理によって影響は変わります。

その中でも特に怖いのは、データI/F系です。外部システムとの送受信や連携処理が止まっている場合、とてつもない業務影響が出ることがあります。

たとえば、店舗連携、物流連携、外部倉庫連携、受注データ連携などが止まると、客に迷惑がかかります。商品が届かない、出荷が遅れる、在庫が合わない、売上や請求に影響する。そういう事故につながる可能性があります。

MSGW対応の基本手順

1. WRKACTJOBでMSGWのジョブを見つける
2. 7番で詳細メッセージを確認する
3. ジョブログで前後の流れを確認する
4. 対象プログラムと業務影響を確認する
5. 必要なら上長やメンバーへ報告する
6. C / I / R の判断をする。DやGは安易に使わない

関連する入口として、AS400のWRKACTJOBとは？MSGW・暴走ジョブ・バッチ確認で最初に見るポイント、ジョブログの見方は AS400のジョブログ確認手順 で整理しています。

MSGW対応ではジョブ名・ユーザー・番号を残す

MSGWを見つけた時は、返答文字だけでなく、どのジョブで起きたのかを後から追えるようにしておくことが大事です。最低限、ジョブ名、ユーザー、番号はメモに残します。

この3つがあれば、WRKJOBやDSPJOBLOGで同じジョブを追いやすくなります。スクショで共有する時も、ジョブ名・ユーザー・番号が見える状態にしておくと、メンバー間の認識違いを減らせます。

WRKJOBからスプール・ファイルやジョブログを見る流れは、WRKJOBとDSPJOBLOGの使い方を参照してください。

すぐ返信してよいかの判断

運用手順書に応答値が明記されていても、対象ジョブ、実際のメッセージIDと置換値、発生条件、途中更新、後続処理の状態が、その手順の適用条件と一致するか確認します。一致し、実行権限と承認条件を満たす場合だけ手順に従います。同じ文字の返信や毎日出るメッセージという理由だけでは判断しません。条件が違う・分からない場合は、証跡を残して責任者へ確認します。

よくある原因

• 存在しないファイル、ライブラリ、メンバーを参照している
• プリンター、OUTQ、装置、通信先が応答していない
• 権限不足で処理が止まっている
• プログラム例外が発生し、RNXやCPFメッセージが出ている
• 前処理が失敗し、後続バッチが必要なデータを読めない
• ロック待ちがタイムアウトするなどして例外になり、その後に照会メッセージへの応答が必要になった

ロック待ちを表すLCKWと、メッセージ待ちのMSGWは別の状態です。ロックが関係するかは直前のメッセージと対象を確認し、LCKW・WRKOBJLCKの確認手順へ進みます。メッセージIDから調べる場合は、AS400メッセージID・エラーコード索引を起点にしてください。

DSPMSGとWRKMSGQの使い分け

運用メモに残すこと

• 発生時刻、メッセージID、メッセージ本文
• 対象ジョブ、ユーザー、ジョブ番号
• 返信した場合は返信値と判断理由
• 夜間バッチ、印刷、バックアップ、通信への影響
• 再発時に見る画面と担当者

QSYSOPRは、AS400運用の早期警戒画面です。メッセージを消すことよりも、何が起きていて、どの処理に影響するかを残すことが大切です。

MSGWで迷った時に次に確認すること

MSGWは、返信して画面を進めれば終わりではありません。特に夜間バッチ、締め処理、EDI、ファイル更新が絡む場合は、ジョブログ、返信候補、後続処理、リラン可否を分けて確認します。

• MSGW返信判断表で、表示された候補へ返信する前の確認を整理する
• メッセージID・エラーコード索引で、MSGW直前のCPF、RNX、MCHの各解説へ進む
• 夜間バッチ障害対応フローで、後続ジョブとリラン範囲を確認する
• MSGW検知とメール通知で、早期検知の仕組みを検討する
• ジャーナルとDSPJRNの確認手順で、更新前後の履歴を確認する

頻発するMSGWは、担当者の勘だけに任せず、検知、通知、返信判断、リラン確認までを手順に落としておくと、若手や外部担当者でも初動が安定します。

終了方式の詳細はIBM公式：ENDJOBで確認できます。制御終了でも指定時間内に終了処理が完了しなければ即時終了へ移るため、安全な停止を保証するものではありません。