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の回答は仮説として扱います。
AS400保守で安全にAIを使う研修は、AS400保守向けCodex研修 にまとめています。
