AS400 / IBM i の保守で最初に覚えるべきことは、コマンドをたくさん暗記することではありません。問い合わせを受けた時に、慌てずに状況を分解し、業務影響を確認し、必要なログを見て、勝手な操作をしないことです。
私は2000年からAS400 / IBM i の開発・保守に関わり、販売管理システムを中心に、アパレル、小売、卸売の現場を見てきました。販売管理では、受注、出荷、在庫引当、売上計上、請求、店舗連携、物流連携などがつながっています。どこか一つが止まると、後続処理や外部連携まで影響することがあります。
この記事では、AS400保守で初心者が最初に覚えるべき初動対応を、現場の順番で整理します。詳しい個別コマンドは、AS400保守・運用完全ガイドから順番に確認してください。
AS400保守の初動で一番大事なのは「すぐ触らない」こと
問い合わせが来ると、初心者ほどすぐにコマンドを打ちたくなります。しかし本番環境では、最初の一手を間違えると状況を悪化させます。MSGWのジョブを見つけて、いきなり4番でジョブを終了させたり、メッセージにDを返したりするのは危険です。
まずやることは、操作ではなく整理です。誰から、どの業務で、何が、いつから、どの範囲で起きているのかを確認します。販売管理なら、受注が止まっているのか、出荷が止まっているのか、在庫引当なのか、売上計上なのか、請求や外部I/Fなのかで優先度が変わります。
問い合わせを受けたら最初に確認する順番
| 順番 | 確認すること | 現場での見方 |
|---|---|---|
| 1 | 業務影響 | 受注・出荷・在庫・売上・請求・外部連携のどこに影響しているかを見る |
| 2 | 対象範囲 | 特定店舗、特定ユーザー、特定ジョブ、全体影響のどれかを切り分ける |
| 3 | 実行環境 | 本番かテストか、対象ライブラリやライブラリリストを確認する |
| 4 | ジョブ状態 | WRKACTJOBでMSGWやCPU暴走ジョブがないかを見る |
| 5 | ジョブログ | DSPJOBLOGやWRKJOBから、何が起きたかを時系列で確認する |
| 6 | 報告判断 | 自分で返答・復旧してよいか、上長判断が必要かを分ける |
ここで重要なのは、最初から原因を決めつけないことです。利用者から「画面がおかしい」と言われても、原因がプログラムとは限りません。ジョブが止まっている、外部連携が遅れている、夜間バッチが終わっていない、過去のゴミデータが残っている、ライブラリを間違えているなど、現場ではいろいろあります。
販売管理では「商品が客に届くところ」を優先する
販売管理システムで本番トラブルが起きた時、私ならまず受注系、出荷系、在庫引当、物流連携を優先して見ます。バックオフィス系も重要ですが、商品が客に届くところが止まると、業務影響が一気に大きくなります。
たとえば、受注データは作られているが出荷連携が止まっている場合、画面上は受注済みに見えても、倉庫側に情報が渡っていない可能性があります。逆に、出荷は進んでいるのに売上計上が止まっている場合は、請求や会計連携に影響します。AS400保守では、プログラム単体だけでなく、業務の流れで見ることが大事です。
WRKACTJOBで見るのはMSGWと暴走ジョブ
問い合わせが来た時、AS400保守でよく使う入口がWRKACTJOBです。私はまずCPU使用率を見て、暴走しているジョブがないか、MSGWで止まっているジョブがないかを確認します。
ただし、WRKACTJOBを開いてF5で更新し続けるだけでは意味がありません。MSGWや異常なCPU使用率を見つけたら、そのジョブの周辺状況を調べ、ジョブログを確認し、どう対応するかを考える必要があります。WRKACTJOBは眺める画面ではなく、調査の入口です。
- MSGWのジョブがないか
- CPUを食っているジョブがないか
- 夜間バッチがRUNのまま残っていないか
- DEQWやSELWなど、待ち状態が業務上問題になっていないか
- 同じようなジョブが複数止まっていないか
WRKACTJOBの基本は、AS400のWRKACTJOBとは？MSGW・暴走ジョブ・バッチ確認で最初に見るポイントで詳しく整理しています。
MSGWを見つけた時に初心者がやってはいけないこと
MSGWを見つけた時、初心者が一番やってはいけないのは、内容を確認せずにジョブを終了させることです。4番でジョブを強制終了させたり、メッセージにDを返したりすると、本来はRでリトライできた処理まで復旧しにくくなります。
現場では、C、I、R、D、Gなどの返答がありますが、どれを返すかはジョブログを見て判断します。私はDは基本的に使いません。Dはダンプを取ってキャンセルする返答なので、リトライで戻せる可能性を消してしまうことがあります。Gも危険です。RPGがこけた時に強制的に後続へ進めるような返し方になる場合があり、二次災害につながることがあります。
| 返答 | 意味 | 初心者への注意 |
|---|---|---|
| C | キャンセル | 処理を止める判断が必要。後続影響を確認する |
| I | 無視 | 無視してよい根拠がないなら勝手に返さない |
| R | リトライ | 復旧できる可能性があるが、原因確認後に行う |
| D | ダンプ取得後キャンセル | 安易に使わない。復旧手段を狭めることがある |
| G | 後続続行系の返答 | 処理を進めてよい根拠がなければ危険 |
MSGWの基本は、AS400のMSGWとは？メッセージ待ちジョブを見つけた時の確認手順と返答判断も参考にしてください。
ジョブログは「最後のエラー」だけで判断しない
ジョブログを見る時は、最後に出ているメッセージだけを拾って終わりにしないことが大事です。最後のメッセージは結果であって、原因は少し前に出ていることがあります。メッセージID、重大度、実行されたコマンド、CALLされたプログラム、ファイルオープン、MSGWになったタイミングなどを時系列で見ます。
初心者には、まず重大度やメッセージIDを見るところから教えてもよいと思います。ただ、保守で本当に必要なのは、ジョブログを見て「何が起きたか」「どこから影響したか」「この後どうすべきか」を判断することです。
ジョブログの読み方は、AS400のジョブログ確認手順と、AS400のWRKJOB / DSPJOBLOG確認手順で補足しています。
ライブラリリストを飛ばす人は本番対応で危ない
AS400保守で本番環境を触る時、ライブラリリストの確認は必須です。特にSQLでデータ修正をする場合、更新先のライブラリを間違えると事故になります。私はライブラリ名の確認が一番怖いと思っています。
若手に説明するなら、ライブラリリストは「上から順番にオブジェクトやファイルを探しに行くもの」と伝えます。*LIBL指定で動いている処理では、どのライブラリのオブジェクトを見ているかを確認しないと、テスト環境と本番環境を間違える原因になります。
- 本番環境かテスト環境か
- 画面右上のシステム名や接続先
- ライブラリリスト
- 対象ファイルのライブラリ
- 対象プログラムのライブラリ
- SQLやCLRPFMの指定先
上長へ報告すべき状態
AS400保守では、何でも自分だけで片付けようとする人は危ないです。特に本番環境、MSGW、データ更新、リカバリー、外部I/F、出荷や請求に影響する処理は、勝手に判断せず上長やメンバーへ共有した方が安全です。
| 状態 | 報告判断 |
|---|---|
| MSGWで本番ジョブが止まっている | ジョブログ確認後、原則報告 |
| 外部I/Fや出荷連携が止まっている | 業務影響が大きいので早めに共有 |
| データ更新やリカバリーが必要 | 手順作成とレビューが必要 |
| CLRPFMやSQL更新を使う | 対象ライブラリとバックアップを確認してから判断 |
| 原因が分からないまま後続処理へ進めたい | 単独判断しない |
できるPMやリーダーは、まず障害状況を確認し、止血の暫定対応と本格対応を分けます。だめな対応は、その場しのぎで変な操作をして、あとで二次災害を起こすことです。
AS400保守の初動チェックリスト
- 問い合わせ内容を業務単位で整理したか
- 受注・出荷・在庫・売上・請求・外部I/Fのどこに影響しているか確認したか
- 本番環境とテスト環境を取り違えていないか
- ライブラリリストを確認したか
- WRKACTJOBでMSGWやCPU暴走ジョブを確認したか
- ジョブログを時系列で確認したか
- メッセージにDやGを安易に返そうとしていないか
- データ更新が必要な場合、手順とレビューを準備したか
- 上長へ報告すべき状態ではないか確認したか
まとめ：AS400保守は落ち着いて全体を見る仕事
AS400保守は、コマンドを知っているだけでは足りません。業務の流れ、ジョブの状態、ログ、ライブラリ、後続処理、報告判断をつなげて見る必要があります。
初心者に最初に伝えたいのは、焦って作業しないことです。MSGWを見つけたら上長へ報告する。ジョブログを見る。ライブラリを確認する。勝手にDやGを返さない。本番データを単独で触らない。この基本を守るだけでも、事故の確率はかなり下げられます。
AS400保守の全体像を順番に学びたい方は、AS400保守・運用完全ガイドから読み進めてください。
