AS400 / IBM i の現場で多い相談の一つが、夜間バッチや本番ジョブがMSGW（メッセージ応答待ち）で止まっているのに、朝まで気づけない問題です。IBMの監視サービスを使う会社もありますが、現場では自社でMSGWを検知してメール通知する仕組みを作ることもあります。肌感覚では、現場の処理に合わせて作ったMSGW検知の方が、通知までが早いこともあります。
MSGW監視で決めること
| 確認 | 見るもの | 判断 |
|---|---|---|
| 対象ジョブ | 夜間バッチ、本番更新、締め処理 | 何を監視対象にするか |
| 検知条件 | MSGW、待ち時間、重要ジョブ名 | 通知する条件を絞るか |
| 通知先 | 保守担当、運用担当、利用部門 | 誰が初動判断するか |
| 返信ルール | メッセージID、応答値、手順書 | 適当に返信しない仕組みがあるか |
| 記録 | 発生時刻、返信内容、再実行結果 | あとで再発防止できるか |
通知だけでは障害対応にならない
MSGWをメールで知らせるだけでは、まだ半分です。大切なのは、通知を受けた人がどのメッセージを見て、返信してよいのか、ジョブを止めるべきか、再実行前に何を確認するかを判断できることです。若手が適当に返信すると、後続処理やリカバリープログラムが必要になることがあります。
現場向けの通知文にする
通知メールには、ジョブ名、ユーザー、発生時刻、メッセージID、メッセージ本文、対象業務、確認先リンクを入れると実務で使いやすくなります。単に「MSGWが発生しました」だけでは、夜間に受けた担当者が判断できません。
夜間バッチ全体は AS400夜間バッチ障害対応フロー、ジョブスケジュールは AS400ジョブスケジュール運用チェックリスト、本番障害の初動は AS400本番障害の初動チェックリスト にまとめています。
Codexで使える部分
Codexには、匿名化したメッセージID、ジョブ名、通知文案、運用フローを渡すと、メール文面や対応チェックリストを整えやすくなります。本番メッセージへの返信やジョブ終了判断は、必ず人が行います。
MSGW通知メールに入れる項目
MSGW監視メールは、発生を知らせるだけでは足りません。夜間や休日に受けた担当者が、返信してよいのか、止めるべきか、業務担当者へ連絡するべきかを判断できる材料を入れます。
| 項目 | 入れる理由 |
|---|---|
| ジョブ名・ユーザー | どの処理が止まったかを特定する |
| メッセージID・本文 | 返信候補と危険度を判断する |
| 発生時刻・経過時間 | 夜間バッチや締め処理への影響を見る |
| 対象業務 | 出荷、請求、在庫、EDIなど影響先を分ける |
| 初動手順へのリンク | 担当者による判断ぶれを減らす |
通知後の初動手順を決めておく
MSGWを検知したら、すぐにENDJOBするのではなく、メッセージID、ジョブログ、QSYSOPR、業務影響を確認します。正しく応答すれば後続処理を流せる場合もあるため、通知先と返信ルールをセットで決めておくことが重要です。
- 返信してよいMSGWと、保留するMSGWを分ける
- 夜間バッチ、締め処理、EDIなど影響が大きいジョブを優先する
- 通知先だけでなく、エスカレーション先を決める
- 返信内容、再実行、業務連絡を記録する
- 翌営業日に再発防止と監視条件を見直す
MSGW監視の次に確認する記事
夜間MSGW通知に含める判断材料の例
通知メールはMSGWの発生を伝えるだけでなく、一次対応者が安全に状況を判断できる最小情報を含めます。秘密値や生データは載せません。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 対象 | システム識別名、ジョブ名、ユーザー、番号、発生時刻 | 同名ジョブを取り違えない |
| メッセージ | メッセージID、要約、応答待ちか、後続停止の有無 | 返信値をメールだけで決めない |
| 連絡 | 業務影響、当番、エスカレーション条件、手順書URL | 未承認者が本番応答しない |
復旧後は通知時刻、確認開始時刻、応答時刻、後続再開時刻を残します。通知件数が増えた場合は、単なるメール追加ではなく発生原因と閾値を見直します。