AS400 / IBM i のRPGやCLを改修する時、いきなりソースだけを読んで判断すると危険です。どのファイルを参照しているのか、どのプログラムを呼んでいるのか、どのライブラリに影響がありそうかを先に押さえておくと、本番改修の事故を減らせます。
その入口として使えるのが DSPPGMREF です。IBMの資料でも、DSPPGMREFは指定したプログラムが参照するシステムオブジェクトを一覧するためのコマンドとして説明されています。この記事では、公式仕様の細かい説明よりも、AS400保守の現場でどう使うかに絞って整理します。
コマンド名から探したい場合は、先に AS400コマンド逆引き も確認してください。RPGやCLの基本から復習したい場合は、AS400総合ガイド に戻ると全体像をつかみやすいです。
DSPPGMREFで分かること
DSPPGMREF は、プログラムが参照しているオブジェクトを確認するためのコマンドです。たとえば、RPGプログラムがどの物理ファイルや論理ファイルを参照しているか、どのプログラムを呼び出している可能性があるかを調べる時に使います。
| 見たいこと | 確認の考え方 |
|---|---|
| 参照ファイル | RPGやCLがどのファイルを使っているか、改修前の当たりを付けます。 |
| 呼び出し先 | 別プログラムを呼ぶ構造になっていないか、影響範囲の入口を見ます。 |
| ライブラリ | 本番、テスト、共通ライブラリなど、どの環境を見ているか意識します。 |
| 調査漏れ | 一覧に出たものだけで完結せず、ソースやジョブログも合わせて確認します。 |
改修前にDSPPGMREFを見る理由
AS400の保守では、「この項目を1つ直すだけ」と見えても、実際には複数の帳票、バッチ、画面、連携処理に影響することがあります。特に販売管理、在庫、出荷、請求のような基幹業務では、1本のRPGが複数ファイルを読み書きしていることも珍しくありません。
DSPPGMREFを見ておくと、少なくとも「このプログラムは何を参照しているのか」という入口を作れます。そこから DSPFFD / DSPPFMでファイル定義やデータを確認 し、必要に応じて ジョブログ や スプール も確認します。
DSPPGMREFだけで判断しない
注意したいのは、DSPPGMREFだけで影響調査が完了するわけではないことです。動的に組み立てるCALL、実行時の条件分岐、CLからの呼び出し、ジョブ記述やライブラリリストの違いまでは、コマンド結果だけでは読み切れない場合があります。
そのため、現場ではDSPPGMREFを「最初の地図」として使います。地図を見た後に、RPGソース、CL、ジョブログ、コンパイルリスト、テスト実行結果を合わせて確認する流れが安全です。
| 確認対象 | 合わせて見るもの |
|---|---|
| RPGのファイル参照 | F仕様、D仕様、SQL、DSPFFD、DSPPFM |
| CLからの呼び出し | CALL、SBMJOB、MONMSG、ジョブログ |
| 帳票影響 | WRKSPLF、コンパイルリスト、出力待ち行列 |
| 本番影響 | ライブラリリスト、ジョブ記述、バックアップ、戻し手順 |
本番環境で見る時の注意
DSPPGMREFは調査系のコマンドですが、本番環境で作業する時は、対象ライブラリと対象プログラムを間違えないことが大切です。テスト環境のつもりで本番ライブラリを見ていた、古いオブジェクトを見ていた、というズレがあると、影響調査の結果もズレます。
特に改修前は、対象プログラム、作成日時、ライブラリ、ソースメンバー、コンパイル結果を合わせて確認します。必要なら コンパイルリスト も見て、どのソースから作られたものかを確認します。
CodexやAIに影響調査を手伝わせる時
DSPPGMREFの結果、RPGソース、CL、ジョブログを整理すると、CodexのようなAIに「このプログラムの影響範囲を表にして」と頼みやすくなります。ただし、本番データ、顧客名、会社名、ユーザー名、ライブラリ名などは必要に応じてマスキングしてください。
AS400保守でAIを安全に使う考え方は、AS400保守でCodexはどこまで使える？ や AS400保守向けCodex研修 でも整理しています。
まとめ
DSPPGMREFは、AS400 / IBM i のRPGやCLを改修する前に、参照ファイルや呼び出し先の当たりを付けるための便利な入口です。ただし、これだけで影響調査が終わるわけではありません。
現場では、DSPPGMREF、ソース、ジョブログ、DSPFFD、DSPPFM、WRKSPLF、コンパイルリストを組み合わせて確認します。改修前にこの流れを作っておくと、本番作業の不安をかなり減らせます。
単一レベル記憶・TIMI・将来性を理解する
AS400が長く使われる理由を理解するには、単一レベル記憶、TIMI、IBM iの互換性、ブラックボックス化リスクも押さえる必要があります。詳しくは AS400の単一レベル記憶とTIMIの解説 を確認してください。概念だけでなく、保守・影響調査・移行判断へつなげて整理しています。
Git・ソース管理・AI活用の前に
RPG/CLの保守をGitやAI活用へつなげる時は、AS400でGit・ソース管理を始める手順を確認してください。ソースの正本、コンパイル手順、レビュー、切り戻し、Codex利用時の注意点を整理します。
関連: 物理ファイルと論理ファイルの依存関係を見る時は、DSPDBRで物理ファイルと論理ファイルの関係を見る も確認してください。削除、復元、改修前の影響調査で見落としを減らせます。
DSPPGMREFはRPG/CLの影響調査の入口
DSPPGMREFは、プログラムが参照するファイルやオブジェクトを見る入口です。ただし、動的SQL、OVRDBF、CLからの呼び出し、実行時のライブラリリストは別途確認が必要です。RPGの読み方はRPGソースの読み方、CL側の流れはCL入門、本番障害時は保守・運用完全ガイドへ戻って確認します。
