AS400 / IBM i の本番障害では、最初の10分で見る順番を間違えると、復旧までの時間が大きく伸びます。夜間バッチ停止、MSGW、CPFエラーやRNX（RPG実行時エラー）、オブジェクト未検出、ライブラリ違いは、それぞれ見る画面と判断が違います。この記事では、25年以上の現場経験を前提に、本番で慌てないための初動チェックを整理します。
目的は「すぐ原因を断定すること」ではありません。まず、業務を止めるべきか、後続処理を流せるか、担当者へ何を伝えるべきかを判断できる状態にすることです。AS400の障害対応は、ジョブログ、メッセージID、ジョブ状態、ライブラリ、データの順に見ていくと混乱しにくくなります。
初報と並行して「状況の整理」を進める
障害の連絡を受けたら、まず確認できた事象と業務影響を整理します。ただし、全容が判明するまで初報や調査を待つわけではありません。既知と未確認を分けて関係者へ連絡し、役割分担して原因調査と影響確認を並行します。
状況整理では、次の2つを更新していきます。初報で不明な点があっても、未確認として明示します。
- 何が起こったかを把握する
- どこに影響が出ているかを調査する
事象や影響範囲が未確定の段階では、確認できた範囲、担当者、次回連絡時刻を共有します。原因の仮説は事実と分け、証跡を保全しながら範囲を絞ります。全容確認のために必要な初動を遅らせないことが重要です。
業務影響の確認を抜かさない
障害対応に慣れていない時は、連絡を受けた瞬間に「なぜ起きたのか」を追いがちです。業務影響の確認が抜けないよう、原因調査と並行して担当を決めます。原因が分かっても、影響範囲が分かっていなければ対処の判断ができません。
| 整理で出すもの | 具体的に見ること |
|---|---|
| 何が起こったか | いつ、どの処理が、どういう形で止まった／おかしくなったか |
| どこに影響が出ているか | 対象データの範囲、後続処理、外部連携、業務がいま止まっているか |
影響範囲は、原因や途中更新の状態とともに、その後の判断に使う材料になります。戻すか、その場で直すかも、リランしてよいかどうかも、どこまで壊れているかが分からなければ「確実」と言えません。整理は、その後の判断材料を作る作業です。
業務側へは、確認済みの停止処理・影響と、まだ分かっていない点を早めに伝えます。続行や停止の判断が必要な業務と次回報告時刻も示し、判明した情報で続報を更新します。
実行担当と連絡担当を決める
本番障害では、複数人が同時に触ると危険です。誰が画面を見るのか、誰がジョブログを確認するのか、誰が顧客や現場へ連絡するのか、誰が実行担当なのかを決めます。作業者が曖昧なまま進めると、同じジョブを二重に再実行したり、別の人が先にメッセージを返したりすることがあります。
若手に任せる場合でも、最初から単独で本番を触らせるのは避けた方が安全です。接続先のシステム名を確認していない、本番とテストを勘違いする、F4で入力内容を確認しない、といったミスは実際に起こります。まずは上長やメンバーと作業範囲を合わせます。
本番環境とテスト環境を間違えない
本番対応で一番怖いのは、環境を間違えることです。テスト環境だと思って本番でCLRPFMを実行する、逆に本番だと思ってテスト環境を見て「データがない」と判断する、といったミスは致命的です。接続先のシステム名（表示位置は環境によって異なります）、ジョブ情報、ライブラリリスト、対象ファイルを確認します。
確認例: DSPLIBL WRKOBJ OBJ(TESTLIB/TEST001R) OBJTYPE(*PGM) DSPFD FILE(TESTLIB/TESTFILE) DSPFFD FILE(TESTLIB/TESTFILE)
特にSQLでデータ修正する時は、指定するライブラリ名が一番怖いです。目視確認しかない場面もありますが、だからこそ実行前にメンバーと手順をレビューします。自分だけで「たぶん合っている」と判断しない方が安全です。
DSPLIBLは実行した現在スレッドのライブラリリストです。障害バッチや外部接続ジョブを調べる時は、番号・ユーザー・ジョブ名で特定してWRKJOB等から対象ジョブの情報を確認します。手元の対話ジョブが正しいことだけで、別ジョブの参照先も正しいとしないでください。
本番障害で最初に確認する5つ
| 確認すること | 見るコマンド・画面 | 判断すること |
|---|---|---|
| ジョブが動いているか | WRKACTJOB / WRKJOB | 実行中、待機中、MSGW、異常終了のどれか |
| 何のメッセージで止まったか | DSPJOBLOG / DSPMSG | CPF、RNX、MCH、MSGWの入口を分ける |
| 後続処理に影響するか | JOBQ / 投入済みジョブ / CL定義 | 後続ジョブを流してよいか、止めるべきか |
| ファイル・ライブラリが合っているか | DSPLIBL / WRKOBJ / DSPFFD | ライブラリ違い、権限、ファイル状態を切り分ける |
| 業務影響がどこまであるか | 運用メニュー・締め処理・出荷処理 | 在庫照会、請求締め、出荷確定などの影響を確認する |
MSGWなら、返信より前にジョブログを見る
MSGWでは、経験が浅い時ほど「とりあえず終わらせる」と判断しやすいため注意が必要です。メッセージによっては適切に返信すれば後続処理を流せる場合があります。逆に、内容を読まずにジョブを終了すると、別途リカバリープログラムや手作業の戻しが必要になることがあります。
MSGWを見たら、まず MSGWでジョブが止まった時の確認手順 と MSGWを早期検知する考え方 を確認してください。夜間バッチで気付くのが遅れる場合は、QSYSOPRや重要ジョブのMSGWを検知してメール通知する仕組みも検討対象です。
CPF・RNX・MCHは同じエラーとして扱わない
AS400の障害調査では、メッセージIDの先頭で入口を分けるだけでも調査時間が短くなります。CPFはファイル、権限、ライブラリ、システム操作に関係することが多く、RNXはRPG実行時のデータや配列、数値変換などに関係することが多いです。MCHはポインターや低レベルの異常として見ます。
| 入口 | よく見る原因 | 詳しい確認先 |
|---|---|---|
| CPF | ファイル未検出、権限、ライブラリ違い、排他 | CPFエラーとジョブログ確認 |
| RNX | RPG実行時エラー、数値変換、配列、データ不整合 | RNX8888の確認手順 |
| MCH | プログラム異常、ポインター、呼び出し関係 | メッセージID・エラーコード索引 |
| MSGW | 応答待ち、夜間バッチ停止、判断待ち | MSGW返信判断表 |
業務別に影響範囲を確認する
本番障害では、技術的な原因調査と同時に、業務影響を見ます。販売管理システムなら、まず受注系、発注系、出荷系が動くかを確認します。バックオフィス系は後回しにできることもありますが、商品がお客様に届くところ、外部連携が止まるところは優先度が高いです。
| 業務領域 | 止まると怖いこと | 初動で見ること |
|---|---|---|
| 受注 | 注文処理や出荷指示に影響する | 受注データ作成、後続バッチ、I/F |
| 出荷 | 物流側へデータが渡らない | 出荷指示、帳票、物流連携 |
| 在庫 | 引当や在庫数に差異が出る | 在庫引当、更新件数、対象ファイル |
| 売上・請求 | 計上や請求に影響する | 二重計上、未計上、会計連携 |
| 外部I/F | 相手先や店舗に影響する | 送受信履歴、再送可否、連携ファイル |
暫定対応を行う場合は、止める影響、継続する業務、実施責任者、戻し方を決めます。暫定復旧を恒久対策の完了とせず、原因と再発防止の確認を残します。
販売管理で私が優先して見るところ
販売管理システムで本番トラブルが起きた時、私ならまず受注系、出荷系、在庫引当、物流連携を優先して見ます。バックオフィス系も重要ですが、商品が客に届くところが止まると、業務影響が一気に大きくなります。
たとえば、受注データは作られているが出荷連携が止まっている場合、画面上は受注済みに見えても、倉庫側に情報が渡っていない可能性があります。逆に、出荷は進んでいるのに売上計上が止まっている場合は、請求や会計連携に影響します。AS400保守では、プログラム単体だけでなく、業務の流れで見ることが大事です。
WRKACTJOBでMSGWとCPU使用状況を確認する
問い合わせが来た時、AS400保守でよく使う入口がWRKACTJOBです。私はまずCPU使用率を見て、異常な負荷の候補となるジョブや、MSGWで止まっているジョブがないかを確認します。CPUが高いだけでは暴走と確定できないため、通常時との差、処理件数、待ち状態、業務内容を照合します。
ただし、WRKACTJOBを開いてF5で更新し続けるだけでは原因の切り分けになりません。MSGWや異常なCPU使用率を見つけたら、そのジョブの周辺状況を調べ、ジョブログを確認し、どう対応するかを考える必要があります。WRKACTJOBは眺める画面ではなく、調査の入口です。
- MSGWのジョブがないか
- CPUを食っているジョブがないか
- 夜間バッチがRUNのまま残っていないか
- DEQWやSELWなど、待ち状態が業務上問題になっていないか
- 同じようなジョブが複数止まっていないか
WRKACTJOBの基本は、AS400のWRKACTJOBとは？MSGW・暴走ジョブ・バッチ確認で最初に見るポイントで詳しく整理しています。
外部へ相談する前に残す情報
本番障害は、復旧を急ぐほど情報が散らばります。AS400 / IBM i の障害を外部へ相談する場合は、ジョブ名やメッセージIDだけでなく、業務影響と確認済み事項をまとめておくと初回の切り分けが早くなります。
| 残す情報 | 相談時に役立つ理由 |
|---|---|
| 発生時刻と業務影響 | どの処理が止まり、どの部署や締め処理に影響しているかを判断できます。 |
| ジョブ名・ユーザー・画面 | WRKACTJOB、WRKJOB、DSPJOBLOGで追う対象を絞れます。 |
| メッセージID | CPF、RNX、MCH、CPAなど、調査の入口を分けられます。 |
| 実施済みの対応 | 返信、再実行、保留、キャンセルなど、二重対応を避けられます。 |
対象ジョブの詳細を確認する時は、ジョブログ確認手順も参照してください。復旧判断や再発防止を外部の保守先へ引き継ぐ場合は、保守会社に相談する前のチェックリストに沿って判明済みの情報と未確認事項を分け、契約先の緊急連絡手順に従って共有してください。
