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

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

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

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

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

外部監視サービスと自前検知の考え方

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

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

MSGW検知後の運用を決める

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

決めること 理由 見る記事
通知先 夜間・休日に誰が初動を見るかを明確にする 本番障害の初動対応
返信判断 MSGWの内容を見ずに終了しない MSGW返信判断表
確認コマンド QSYSOPR、DSPMSG、ジョブログをそろえて見る MSGW・QSYSOPRで内容を確認する
業務影響 夜間バッチ、締め、EDI、出荷への影響を分ける 夜間バッチ障害対応
復旧記録 発生時刻、返信内容、再実行結果を残す 【初心者向け】AS400保守で使う調査メモの作り方|障害対応を早くする記録術

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

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

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

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

監視を運用開始する前の確認表

次は検証環境や監視側のテスト機能で行う想定試験です。通知試験のために本番バッチを意図的に停止させません。

試す状態 期待する結果
対象ジョブがMSGWになる 合意した検知時間内に、番号・ユーザー・ジョブ名で特定できる通知が届く
同じMSGWが継続する 毎回無制限に送らず、決めた再通知と担当者への段階連絡が行われる
解消後に別のMSGWが発生する 過去の通知抑制が新しい異常を隠さない
メール経路や監視処理が停止する 監視停止を検知でき、別の連絡経路か手動確認へ移れる
ジョブがMSGWにならず異常終了する 終了/予定未実行/遅延の監視が別にあり、MSGW監視だけで正常判定しない

試験結果には発生時刻、検知時刻、到達時刻、担当者の確認時刻を残します。通知遅延と人の対応待ちを分けて測ると、次に直す箇所を選べます。