AS400 / IBM i のRPGやCLを修正する時に怖いのは、修正そのものよりも影響範囲の見落としです。画面、帳票、夜間バッチ、ファイル更新、後続処理、外部連携のどこに影響するかを押さえないまま本番反映すると、請求締めや出荷確定のような業務で手戻りが起きます。
この記事では、AS400のRPG/CL保守で小改修や障害対応を行う前に見るべき影響調査の順番を、現場目線で整理します。保守会社へ依頼する時も、Codexで調査メモを整理する時も、この観点を持っておくと会話が早くなります。
影響調査で最初に見る5つ
| 確認すること | 見るもの | 判断すること |
|---|---|---|
| 呼び出し元 | CL、CALL、メニュー、SBMJOB | どこから実行されるか |
| 参照・更新ファイル | DSPFFD、DSPPFM、ソース内のF仕様 | どの業務データに影響するか |
| 後続処理 | JOBQ、夜間バッチ、帳票、外部連携 | 後で動く処理があるか |
| エラー時の動き | MONMSG、MSGW、ジョブログ | 止めるのか、続行するのか |
| テスト観点 | 正常系、異常系、再実行、戻し | 本番反映前に何を確認するか |
CLは業務の流れを見る入口になる
CLは、単なる起動用プログラムではなく、業務の流れを読む入口になります。どのRPGをCALLしているか、どのJOBQへ投入しているか、エラー時にMONMSGで拾っているか、後続処理を呼んでいるかを見ます。CLを読まずにRPGだけを見ると、後続影響を見落としやすくなります。
ファイル更新はDSPFFDと実データで確認する
RPGの修正では、画面や帳票だけでなく、どの物理ファイルを更新しているかを確認します。DSPFFDで項目定義を見て、DSPPFMやSQLで実データの入り方を確認すると、桁数、符号、日付、コード値の見落としを減らせます。
ファイル確認の基本は、DSPFFD・DSPPFMでファイルを確認する手順、目的からコマンドを探す場合は AS400コマンド逆引き を使うと早いです。
エラー時の後続処理を必ず見る
現場で多いのは、正常系だけを見て本番反映し、エラー時の後続処理で止まるケースです。MSGW、CPF、RNX、MONMSG、リカバリー用CL、再投入手順を確認し、ジョブログに何が残るかまで見ておくと、本番障害時に説明しやすくなります。
ジョブログの読み方は、AS400ジョブログの見方、本番障害の初動は AS400本番障害の初動チェックリスト に整理しています。
Codexで影響調査を補助する時
Codexは、RPG/CLの処理概要、呼び出し順、テスト観点、ジョブログの整理に使いやすいです。ただし、社内規程・契約で利用と情報提供を許可された範囲だけを使い、本番データや会社名を除いたソース断片や処理名で確認します。AIは影響調査の補助であり、本番反映の判断者ではありません。
どこまで調べたら止めてよいか
影響調査で必ず聞かれるのが「どこまで調べれば十分か」です。変更点から呼び出し元と影響先をたどり、調査範囲・根拠・未確認事項をレビューで合意します。「全部見た」という言葉だけでは、動的呼出しや外部連携の見落としを否定できません。
長く担当したシステムの知識は、調査の優先順位を付けるのに役立ちます。ただし、自信の有無だけで調査完了とはしません。今回の変更から影響先をたどり、確認した版・呼び出し関係・更新先・テスト結果を残します。未確認範囲は明示して、レビュー担当と扱いを決めます。
過去の調査結果を再利用する場合は、その後の変更履歴と今回の対象版を照合します。根拠が古い、動的呼び出しがある、外部連携の担当が不明といった場合は、確認範囲を追加するか作業を止めます。
「知っているつもり」が一番危ない
気をつけたいのは、以前は知っていたが今は変わっている場合です。しばらく触っていない、担当が交代した、外部が改修した。こういう時は知識が古くなっているので、自信の根拠が失われています。
| 状況 | どこまでたどるか | 理由 |
|---|---|---|
| 自分が長く担当している | 既知の構造を起点に、今回の差分と影響を証跡で確認する | 未確認範囲は残し、レビューと承認で完了を判断する |
| しばらく触っていない | 現行の呼び出し元と影響先を洗い直し、不明な経路を明示する | その間に変わっている可能性がある |
| 担当が交代した後 | 現行の呼び出し元と影響先を洗い直し、不明な経路を明示する | 前任者の改修を把握していない |
| 外部が改修した可能性がある | 現行の呼び出し元と影響先を洗い直し、不明な経路を明示する | 変更内容が共有されていないことがある |
| 新任・外部として入った | 現行の呼び出し元と影響先を洗い直し、不明な経路を明示する | 省略の根拠になる理解がない |
これはCodexをAS400保守で使う場合と同じ考え方です。自分が判断できる範囲なら任せて速くできますが、判断できない領域は省略も委譲もできません。調査の完了は、合意した範囲の証跡、未確認事項の扱い、レビューと承認で判断します。
小改修を相談する前に渡す情報
RPG/CLの影響調査を外部へ相談する時は、ソース名だけでは判断できません。業務で何を変えたいのか、どのファイルや後続処理に影響しそうか、どこまで社内で確認済みかを分けて渡すと、初回調査の精度が上がります。
| 渡す情報 | 確認される理由 |
|---|---|
| 変更したい業務 | 画面、帳票、バッチ、締め処理のどこに影響するかを見ます。 |
| 対象候補 | プログラム名、CL名、ファイル名、ライブラリ名を候補として渡します。 |
| 確認済み事項 | 呼び出し元、ファイル更新、ジョブログ、スプールの確認状況を共有します。 |
| テスト条件 | 通常処理、例外、取消、再実行、月末などの確認範囲を決めます。 |
業務側の聞き取りが不足している場合は、業務ヒアリングシートで、対象業務と未確認事項を先に整理してください。小改修や影響調査を外部へ依頼する時は、保守会社に相談する前のチェックリストを使い、調査する範囲、必要な資料、未確認事項、成果物を依頼先と合意してから進めます。
参考：IBM公式ドキュメント（DSPFFD）
本記事で扱った DSPFFD の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。
想定例：商品コードの桁数を増やす改修
以下は調査票の作り方を示す架空例です。DB項目だけを広げて完了とせず、その項目が通る境界を一つずつ確認します。
| 対象 | 調べる差分 | テストと証拠 |
|---|---|---|
| PFと参照LF | 項目の型・長さ、キー、選択条件、依存する様式 | 新旧キーでの検索、定義差分 |
| RPG/CL | 外部記述、内部変数、パラメータ、部分文字列 | 最大桁・既存桁の入出力と呼出し結果 |
| 画面・帳票 | 入力桁、編集、表示幅、印字位置 | 切れ・桁ずれ・旧データ表示の画面と帳票 |
| CSV・EDI | 固定長位置、相手側仕様、文字コード | 送受信の照合と相手側受入結果 |
対象版、確認日、担当者、未確認の外部仕様を同じ票に残します。未確認部分が更新・出荷・請求に関わるなら、確認方法と承認が決まるまで本番反映へ進めません。