AS400のMSGWとは?メッセージ待ちジョブを見つけた時の確認手順と返答判断

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

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

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

AS400のWRKACTJOB画面でMSGW状態のジョブが表示されている例。PGM-TEST001Rがメッセージ待ちになっている
MSGWは、ジョブがメッセージ応答待ちになっている状態です。焦って強制終了せず、詳細メッセージとジョブログを確認してから判断します。

MSGWとは

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

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

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

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

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

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

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

確認すること 見る理由
詳細メッセージ 何に対して応答を求められているか確認する
ジョブログ MSGWになる前後の流れを見る
対象プログラム どの処理で止まっているか確認する
業務影響 後続処理や外部連携に影響があるか判断する

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

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

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

返答 意味 現場での考え方
C キャンセル 処理をキャンセルする。後続影響を確認してから判断する
I 無視 処理を続けてもよいと判断できる場合に使う
R リトライ 一時的な原因なら復旧できる可能性がある
D ダンプを取ってキャンセル 基本的に安易に使わない。リトライの選択肢を失うことがある
G 強制的に継続・再試行方向へ進める返答 RPGがこけた時に、原因を見ないまま後続処理を進めるような形になり得るため危険

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

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

初心者が一番やってはいけないのはDを返すこと

初心者がMSGWで一番やってはいけない操作は、焦って D を返すことです。

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

昔、現場で仕事ができない人が勝手にDを返して、大惨事になったことがありました。会社名や顧客名は出せませんが、「メッセージが出ているから早く消す」くらいの感覚で返答すると、本来は楽に復旧できた処理まで壊してしまうことがあります。

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

危ない対応 なぜ危ないか
Dを反射的に返す Rで復旧できた可能性を失う
Gを意味も分からず返す 原因を確認しないまま後続処理を進め、二次災害につながる可能性がある
4番で強制終了する 処理途中のデータや後続処理に影響する
詳細メッセージを見ない 何が起きたか分からないまま対応することになる
ジョブログを見ない 原因や前後関係を見落とす

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

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

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

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

MSGWの対象 怖い影響
受注I/F 受注データが取り込まれず、後続処理が進まない
出荷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. 迷う場合は返答せず、上長・メンバーに確認する
返答 現場での見方 注意点
C キャンセル 後続処理やデータ整合性を確認してから使う
I 無視 無視してよい理由が説明できる時だけ使う
R リトライ ファイル解放や一時的な待ちなら戻せる場合がある
D ダンプを取ってキャンセル リトライできた処理まで戻せなくなることがある
G 強制的に進める系の返答 RPGがこけた状態で後続処理を進める恐れがあり危険

昔、仕事ができない人が勝手にDを返して大惨事になったことがあります。MSGWは「止まっているから邪魔」ではなく、「システムが人間に判断を求めている状態」です。焦って返答するより、落ち着いて原因を見た方が、結果的に復旧は早くなります。

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

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

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

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

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

まとめ

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

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

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