AS400 RPG/CL影響調査チェックリスト｜小改修前に見る呼び出し元・ファイル・後続処理

AS400 / IBM i のRPGやCLを修正する時に怖いのは、修正そのものよりも影響範囲の見落としです。画面、帳票、夜間バッチ、ファイル更新、後続処理、外部連携のどこに影響するかを押さえないまま本番反映すると、請求締めや出荷確定のような業務で手戻りが起きます。

この記事では、AS400のRPG/CL保守で小改修や障害対応を行う前に見るべき影響調査の順番を、現場目線で整理します。保守会社へ依頼する時も、Codexで調査メモを整理する時も、この観点を持っておくと会話が早くなります。

影響調査で最初に見る5つ

CLは、単なる起動用プログラムではなく、業務の流れを読む入口になります。どのRPGをCALLしているか、どのJOBQへ投入しているか、エラー時にMONMSGで拾っているか、後続処理を呼んでいるかを見ます。CLを読まずにRPGだけを見ると、後続影響を見落としやすくなります。

RPGの修正では、画面や帳票だけでなく、どの物理ファイルを更新しているかを確認します。DSPFFDで項目定義を見て、DSPPFMやSQLで実データの入り方を確認すると、桁数、符号、日付、コード値の見落としを減らせます。

ファイル確認の基本は、DSPFFD・DSPPFMでファイルを確認する手順、目的からコマンドを探す場合は AS400コマンド逆引きを使うと早いです。

現場で多いのは、正常系だけを見て本番反映し、エラー時の後続処理で止まるケースです。MSGW、CPF、RNX、MONMSG、リカバリー用CL、再投入手順を確認し、ジョブログに何が残るかまで見ておくと、本番障害時に説明しやすくなります。

ジョブログの読み方は、AS400ジョブログの見方、本番障害の初動は AS400本番障害の初動チェックリストに整理しています。

外部へRPG/CLの影響調査を依頼する時は、「このプログラムを直してほしい」だけでなく、業務名、入力画面、出力帳票、更新ファイル、夜間バッチ、再実行可否を伝えます。業務影響まで共有できると、見積もりや調査範囲がずれにくくなります。

保守会社選びの観点は、AS400保守会社・開発会社の選び方にまとめています。

Codexは、RPG/CLの処理概要、呼び出し順、テスト観点、ジョブログの整理に使いやすいです。ただし、本番データや会社名をそのまま入れず、匿名化したソース断片や処理名で確認します。AIは影響調査の補助であり、本番反映の判断者ではありません。

AS400のRPG/CL影響調査では、呼び出し元、ファイル更新、後続処理、エラー時の動き、テスト観点を順番に確認します。ソースだけでなく、業務名、ジョブ、ファイル、ジョブログをつなげて見ることで、本番反映後の手戻りを減らせます。

関連する確認手順

RPG/CLの影響調査を外部へ相談する時は、ソース名だけでは判断できません。業務で何を変えたいのか、どのファイルや後続処理に影響しそうか、どこまで社内で確認済みかを分けて渡すと、初回調査の精度が上がります。

渡す情報	確認される理由
変更したい業務	画面、帳票、バッチ、締め処理のどこに影響するかを見ます。
対象候補	プログラム名、CL名、ファイル名、ライブラリ名を候補として渡します。
確認済み事項	呼び出し元、ファイル更新、ジョブログ、スプールの確認状況を共有します。
テスト条件	通常処理、例外、取消、再実行、月末などの確認範囲を決めます。

業務側の聞き取りが不足している場合は、AS400業務ヒアリングシートから先に整理すると安全です。外部へ依頼する範囲を決めたい場合は、AS400保守会社に相談する前のチェックリストも確認してください。具体的な小改修や影響調査を相談したい場合は、お問い合わせから概要を共有できます。

RPG/CLの影響調査は、変更箇所を探すだけでは不十分です。呼び出し元、呼び出し先、参照ファイル、更新ファイル、バッチ、帳票、エラー時の戻り、後続処理まで確認して、変更してよい範囲と触ってはいけない範囲を分ける必要があります。

チームで保守するなら、調査結果を担当者の頭の中に残さず、レビューできるチェックリストに落とすことが大切です。若手に教える時も、ソースを読む順番、DSPFFDで見る項目、ジョブログで確認する観点をセットにすると、改修前レビューの品質が安定します。

本記事で扱った DSPFFD の全パラメーターと表示項目の定義は、IBM公式ドキュメントで確認できます。指定できる値や既定値はOSリリースによって異なるため、本番環境では自社のリリースに合わせて確認してください。