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

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

MSGW は、ジョブがメッセージ応答待ちになっている状態です。処理が完全に終わったわけではなく、AS400側が「どうしますか」と返答を待っている状態です。

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

MSGWとは

MSGW は Message Wait、つまりメッセージ待ちです。AS400上のジョブが、エラーや確認メッセージに対する応答を待っています。

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

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

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

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

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

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

C / I / R / D の返答はジョブログを見て判断する

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

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

私の感覚では、Dは使わないですね。Dは「ダンプを取ってキャンセル」です。これを返すと、Rを返してリトライできた可能性がある処理まで終わらせてしまうことがあります。

もう一つ、Gも危険です。Gは、RPGがこけた時に強制的に継続・再試行方向へ進めようとするような返答で、原因を確認しないまま後続処理を進めてしまう可能性があります。メッセージの意味を理解せずに返すものではありません。

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

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

Dはダンプを取ってキャンセルです。つまり、これを返すと、そのジョブはキャンセル方向へ進みます。もしRでリトライすれば復旧できた処理だった場合、Dを返したことでリカバリーが難しくなることがあります。

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

また、別記事でも書いている通り、4番でジョブを強制終了させるのも危険です。MSGWは「止まっているから消せばいい」という状態ではありません。処理途中のデータや後続処理が残っていることがあります。

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

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

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

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

MSGWを見つけた若手に最初にさせること

若手がMSGWを見つけたら、まず上長に報告です。

焦って勝手にDを返したり、4番でジョブを強制終了させたりすると、本来はメッセージの返し方でリカバリーが楽になった処理でも、二次災害を起こしてしまうことがあります。

現場では、監視システムや検知メールでMSGWを拾う仕組みを作っていることもあります。それでも、画面でMSGWを見つけた人が勝手に判断しないことは大切です。

MSGW対応の基本手順

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

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

MSGWで返答する前に確認する判断フロー

MSGWは、返答文字を入れれば画面上は先に進みます。ただし、それが正しい復旧とは限りません。特にDやGを軽く使うと、リトライで戻せた処理を壊したり、後続処理を無理に進めて二次災害につなげたりします。

1. 7番で詳細メッセージを確認する
2. ジョブログで前後のメッセージを見る
3. 対象ジョブが販売管理のどの処理に関係するかを見る
4. Rで復旧できる状態か、C/Iで止めるべき状態かを判断する
5. 迷う場合は返答せず、上長・メンバーに確認する

以前、詳細を確認しないままDが返され、復旧対応が大きくなったことがあります。MSGWは「止まっているから邪魔」ではなく、「システムが人間に判断を求めている状態」です。焦って返答するより、落ち着いて原因を見た方が、結果的に復旧は早くなります。

MSGWを見つける入口としては、WRKACTJOBで活動ジョブを確認する手順も合わせて読むと理解しやすいです。本番作業の判断は、本番対応で初心者がやってはいけないことにもまとめています。

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

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

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

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

MSGWは「止める」より先に、後続処理を残せるかを見る

現場で怖いのは、MSGWになったジョブを中身を見ずに終了させてしまうことです。若い頃に返信を深く考えずジョブを終わらせてしまい、本来なら適切な返信で後続処理へ流せたものを、別途リカバリー手順で対応することになった、という失敗は珍しくありません。

MSGWは「Cで終わらせる」「Iで無視する」といった文字だけで判断せず、直前のジョブログ、対象ファイル、更新済みデータ、後続バッチ、業務担当者への影響を見てから決めます。夜間バッチや締め処理では、返信ひとつでリラン範囲と復旧時間が変わります。

MSGW対応は、技術的には小さな返信でも、業務的には大きな判断になることがあります。誰が判断したか、何を見て返信したか、後続処理をどう確認したかをメモに残しておくと、翌朝の説明や再発防止がかなり楽になります。

まとめ

MSGWは、AS400の保守で避けて通れない状態です。見つけた時に大事なのは、焦って返答しないことです。

まず7番で詳細メッセージを確認する。ジョブログを見る。何が起きているのかを把握する。C、I、Rは状況を見て判断する。DやGは安易に使わない。若手なら、勝手に返答せず上長に報告する。

MSGW対応は、単なる画面操作ではありません。販売管理のI/F処理や後続処理に影響することがあるため、落ち着いて判断することが大切です。

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

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

• MSGW返信判断表でC、I、R、D、Gを返す前の確認を整理する
• ジョブログ実例集で、MSGW直前のCPF、RNX、MCHを確認する
• 夜間バッチ障害対応フローで、後続ジョブとリラン範囲を確認する
• MSGW検知とメール通知で、早期検知の仕組みを検討する
• ジャーナルとDSPJRNの確認手順で、更新前後の履歴を確認する
• Codex研修で、ジョブログ整理と障害調査の時間短縮を相談する

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