AS400 MSGWを早期検知する考え方|夜間バッチ停止をメール通知で見逃さない

AS400 / IBM i の夜間バッチや本番処理でよくある相談が、「MSGWに気づくのが遅い」「プログラムアベンドに朝まで気づけない」「通知は来たが誰が判断するか決まっていない」というものです。25年以上の現場経験から見ても、障害対応は原因調査だけでなく、早期検知と連絡設計で大きく差が出ます。

この記事では、MSGWを検知してメール通知する仕組みを考える時の確認ポイントを整理します。IBMが提供する監視サービスを使う場合も、自社や保守エンジニアが作ったMSGW検知の仕組みを使う場合も、通知後の判断フローまで作っておくことが重要です。

MSGW検知で最初に決めること

確認項目見る理由関連ページ
検知対象全MSGWを見るのか、夜間バッチや重要ジョブだけを見るのか決めるMSGW対応
通知先運用担当、開発担当、業務責任者の誰へ送るか決める本番障害初動
通知内容ジョブ名、ユーザー、メッセージID、応答候補、発生時刻を入れるQSYSOPR確認
返信判断通知だけではジョブを進められないため、判断基準を持つMSGW返答判断表
業務影響在庫照会、請求締め、出荷確定などの影響を判断する夜間バッチ障害対応

ROMSなどの監視サービスと自前検知の考え方

IBMが提供する監視サービスに加入している環境もあれば、現場でMSGWを検知してメール配信する仕組みを作っている環境もあります。肌感覚としては、自社業務に合わせて作ったMSGW検知の方が、重要ジョブの異常に早く気づけることがあります。ただし、どちらが絶対に優れているという話ではなく、対象ジョブ、通知間隔、通知先、判断フローが業務に合っているかが重要です。

  • 重要ジョブだけを絞って検知するか
  • QSYSOPR、WRKACTJOB、ジョブキューのどこを見るか
  • 通知が多すぎて無視されないか
  • 夜間・休日の連絡先が決まっているか
  • 通知後に誰がC、I、R、Dなどの応答判断をするか

通知だけでは障害対応は終わらない

MSGWを早く検知できても、返信判断を誤ると後続処理を止めたり、リカバリープログラムや手作業の戻しが必要になったりします。若い担当者ほど「止まっているから終わらせる」と考えがちですが、MSGWは業務を安全に進めるための分岐点です。

通知メールには、ジョブ名、メッセージID、メッセージ本文、応答候補、発生時刻、サブシステム、業務名、直前のジョブログ確認先を入れると、保守担当者と業務担当者が会話しやすくなります。

AIで調査時間を減らすなら

MSGW通知、ジョブログ、夜間バッチの処理順、RPG/CLの分岐をCodexで整理できると、初動の調査時間を減らしやすくなります。ただし、会社名、ユーザー名、取引先名、実データはマスキングし、AIの回答は仮説として扱います。

MSGW検知後の運用を決める

MSGWを早く検知しても、受け取った人が判断できなければ復旧は早くなりません。監視設計では、検知対象だけでなく、通知先、返信判断、業務影響、記録方法まで決めます。

決めること理由見る記事
通知先夜間・休日に誰が初動を見るかを明確にする本番障害の初動対応
返信判断MSGWを内容を見ずに終了しないMSGW返信判断表
確認コマンドQSYSOPR、DSPMSG、ジョブログをそろえて見るQSYSOPR確認
業務影響夜間バッチ、締め、EDI、出荷への影響を分ける夜間バッチ障害対応
復旧記録発生時刻、返信内容、再実行結果を残す障害報告書テンプレート

ROMSと自前監視は役割で使い分ける

外部監視サービスを使う場合でも、自前でMSGWを拾う場合でも、見るべきポイントは同じです。重要ジョブだけを早く拾いたいのか、システム全体の監視を広く任せたいのかで役割を分けます。現場では、自社業務に合わせたMSGW検知の方が早く気づける場面もありますが、その分、通知条件と判断ルールを曖昧にしないことが大切です。

MSGW検知の次に確認する記事

午前2時10分のMSGWを通知する想定例

夜間ジョブがMSGWになった時は、メールを送るだけでなく、対象ジョブを特定でき、重複通知を抑え、次の確認へ進める情報をそろえます。

確認点確認内容判断
検知ジョブ名、ユーザー、番号、メッセージID、発生時刻を記録する同名ジョブを取り違えない
通知業務影響、確認先、一次連絡先、未応答であることを簡潔に伝えるジョブログ全文や機密データをメールへ載せない
継続一定時間の重複通知をまとめ、未解消時の再通知とエスカレーションを決める通知成功を復旧完了とみなさない

自動監視は、問い合わせメッセージへ自動応答させる仕組みとは分けます。応答内容、再実行、ジョブ終了は人が前後メッセージと業務影響を確認して判断します。