AS400が遅いと言われた時に先に聞くこと｜時間帯と待ち状態から切り分ける

「AS400が遅い」と連絡を受けたら、最初に聞くのはどの操作が、いつ、誰に、普段と比べてどう遅いかです。原因の名前を聞くより、遅くなった瞬間の状況をそろえます。この記事は、問い合わせを受けた担当者が調査担当へ渡す記録を作るための手順です。

すでに対象ジョブが分かっていて、コマンドによる調査へ進みたい場合は、WRKACTJOB・ジョブログ・バッチ・SQLの確認手順へ進んでください。

最初の聞き取りは「遅い操作」を一つに絞る
コピーして使う問い合わせ記入票
記入例：「朝の受注照会が遅い」と連絡された場合
聞き取り結果から次の確認先を選ぶ
現象が消えても「直った」で閉じない

最初の聞き取りは「遅い操作」を一つに絞る

どこからどこまでが遅いですか？「受注照会で検索を押してから一覧が出るまで」のように開始と終了を決めます。ログイン、画面表示、検索、更新、印刷は分けます。
いつから、普段と比べてどの程度ですか？発生日時と最後に正常だった時刻を聞きます。「普段3秒、今日は20秒」が利用者の感覚なら、計測値とせず「利用者申告」と書きます。
同じ操作をする他の人にも起きていますか？未確認なのに「全員」と書かず、確認できた人数・部署の範囲を残します。他の画面が正常かも聞きます。
条件は普段と同じですか？対象日付、検索条件、処理件数、接続場所などの違いを聞きます。実データやパスワードをメールに貼る必要はありません。
どの業務が何時までに必要ですか？処理が遅くても進んでいるのか、止まっているのか、出荷や締め処理の期限に間に合うかを確認します。

更新処理の返答が遅い場合は、再実行による二重登録を避けるため、連打や再投入を求めず処理結果を担当者に確認します。原因調査のために本番で重い処理を繰り返すことも避けます。

コピーして使う問い合わせ記入票

以下を社内の障害票へコピーし、分からない欄は「未確認」と記入してください。空欄を埋めるためだけに、権限のない操作や本番再実行をする必要はありません。

受付日時・記録者：
発生日時・タイムゾーン：
最後に正常だった日時：
業務・画面・操作：
計測の開始点／終了点：
普段の時間／今回の時間：
時間の根拠（計測・利用者申告）：
対象日付・検索条件・件数の違い：
影響範囲（確認済み人数・他の操作の状態）：
業務への影響・期限：
対象ジョブ（番号／ユーザー／ジョブ名）：
確認時刻・ジョブ状態・証跡の保管先：
同時刻のバッチ・変更（確認済みの事実）：
まだ確認していないこと：
次の確認担当・確認内容・連絡時刻：

ジョブの情報は技術担当が追記します。同じジョブ名が複数ある場合に備え、番号・ユーザー・ジョブ名をセットにします。画面やログを添える場合は撮影・取得時刻を付け、社内の許可された保管先で共有してください。外部へ渡す資料では顧客情報、ユーザー情報、接続先などの秘匿が必要です。

記入例：「朝の受注照会が遅い」と連絡された場合

以下は書き方を示す架空の例です。実際の顧客事例や性能測定結果ではありません。

欄	記入例
現象・時刻	9時05分ごろから、受注照会で検索ボタンを押して一覧が表示されるまでが遅い。
時間の根拠	利用者申告で「普段2〜3秒、今日は約20秒」。担当者による計測は未実施。
確認した範囲	同じ部署の2人で発生を確認。他部署は未確認。メニュー画面への移動は普段どおりとの申告。
条件・業務影響	当日分の受注照会。通常日と件数が同じかは未確認。10時の出荷確認に使うため、9時30分までに状況連絡が必要。
ジョブ・並行処理	対象ジョブは未特定。朝のバッチが終了済みかも未確認。
次の担当作業	運用担当が発生中の対象ジョブを特定し、時刻と状態を記録。業務担当が検索条件と通常時の件数の違いを確認する。

この段階で言えるのは「確認した2人の特定の照会操作が遅い」までです。「IBM i全体が遅い」「朝のバッチが原因」「CPU不足」はまだ分かりません。同時刻にバッチが動いていたと判明しても、それだけで原因と確定せず、対象ジョブの待ちや処理の重なりを調べます。

聞き取り結果から次の確認先を選ぶ

分かったこと	次に確認すること
特定端末だけで発生	接続場所・回線・端末の違いを確認する。ただし検索条件や利用権限が違う可能性も残す。PING・NETSTATの確認範囲を参照。
複数人の同じ処理で発生	対象ジョブと発生時刻をそろえ、CPUだけでなく状態・メッセージ・ロックを調べる。WRKACTJOB確認手順へ。
夜間処理が朝まで終わらない	実行中なのか投入待ちなのか、先行処理が終わっているかを確認する。夜間バッチ障害対応フローへ。