AS400物理ファイルと論理ファイルの違い｜PF・LF・DDS・DSPFDの確認

2026.05.22

PF、LF、DDS（データ記述仕様）、DSPFD、DSPFFDを軸に、RPGのCHAIN、READ、SETLLとファイル定義の関係を確認できるようにしています。

AS400 / IBM i の保守では、物理ファイルと論理ファイルの違いを理解していないと、RPGの読み方を間違えやすくなります。物理ファイルは実データを持つファイル、論理ファイルはそのデータを別の見方で参照するための定義です。

この記事では、PF、LF、DDS、キー、アクセスパス、RPGのCHAIN / READ / SETLLとの関係を、現場での確認順に整理します。

物理ファイルや論理ファイルに入る前に、AS400とIBM iの全体像を確認したい場合は、AS400とは何かを初心者向けに整理した記事 から読むと用語をつなげやすくなります。

物理ファイルと論理ファイルの違い

種類役割保守で見ること
物理ファイル実データを保持する項目定義、データ件数、更新対象かどうか
論理ファイル物理ファイルを別のキーや条件で見るキー順、選択条件、参照元PF
DDSPF/LFの定義を記述するフィールド、桁数、キー、参照関係
アクセスパスキー順に読むための仕組み再作成、性能、順序の影響

RPGから見たPF/LF

RPGが物理ファイルを直接読んでいるとは限りません。ソース上のファイル名がLFの場合、CHAIN や SETLL のキーはLFのキー定義に従います。データが存在するのに見つからない時は、RPGだけでなくLFのキーと選択条件を確認します。

FORDERL1   IF   E           K DISK
C     CUSTNO        SETLL     ORDERL1
C     CUSTNO        READE     ORDERL1

PFとLFの関係は、定義の説明だけでは頭に入りません。既存のDDSとRPGを突き合わせて「このCHAINはどのアクセスパスを使っているのか」を追う作業が要ります。その追い方を実機で練習するのがAS400の若手育成向け研修です。

保守で確認するコマンド

コマンド確認内容使う場面
DSPFDファイル属性、キー、メンバーPF/LFの定義を確認する
DSPFFDフィールド定義桁数、型、フィールド名を確認する
DSPDBR依存関係PFに紐づくLFを確認する
DSPPFMデータ内容少量のデータを直接確認する
WRKOBJLCKロック状況更新できない、待ちになる時

PF/LFでよくある障害

  • RPGはLFを見ているのに、PFだけ確認してしまう
  • LFのキー順が想定と違い、READやREADEの範囲がずれる
  • 同じファイル名が本番・検証ライブラリに存在する
  • DDSの桁数変更後にRPGを再コンパイルしていない
  • アクセスパス再作成やロックでバッチが遅くなる

ジョブログと合わせて見る

ファイルが見つからない、レコードロックで待つ、数値変換で落ちる、フィールドが合わないといった障害はジョブログにヒントが出ます。PF/LFの調査は ジョブログ確認、RPG側の読み方は RPG保守ポイント とセットで見ると確実です。

PF/LFは「どこから使われているか」まで確認する

物理ファイルと論理ファイルの違いを覚えるだけでは、保守作業では足りないことがあります。実際の現場では、対象ファイルをどのRPG、CL、画面、帳票、夜間バッチが参照しているかまで見ないと、項目追加やキー変更の影響範囲を読み違えます。

確認するもの見る理由次に読む記事
PFの項目定義桁数、属性、CCSID、既存データとの整合性を見るDSPFFD/DSPPFMの確認
LFのキーと選択条件同じPFでも、処理順や抽出条件が変わるため目的別コマンド一覧
参照プログラムRPGやCLの影響範囲を見落とさないためAS400保守会社に相談する前のチェックリスト｜障害・小改修・データ抽出・リプレースで整理すること
ライブラリ本番、検証、退避ライブラリの取り違えを防ぐためライブラリとオブジェクト
教育・引き継ぎPF/LFを用語でなく、変更影響として説明できるようにするため研修内容を見る

特に若手へ教える場合は、「PFが実データ、LFが見え方」という説明だけで終わらせず、変更した時にどこへ影響するかを一緒に確認すると理解が進みます。CodexやAIを使う場合も、ファイル名だけではなく、PF/LFの関係、参照元、ライブラリ、ジョブログの情報をセットで渡す方が安全です。

まとめ

物理ファイルは実データ、論理ファイルは見方やキーを変える定義です。AS400 / IBM i の保守では、RPGのファイル名、PF/LFの関係、DDS、ライブラリリスト、ジョブログをつなげて確認することが重要です。

受注照会をPFとLFから追う想定例

たとえば受注データは存在するのに照会画面へ出ない場合、画面が参照するLF名だけを見てデータ欠損と判断しないようにします。PF、LF、キー、選択条件を順番に確認します。

確認点確認内容判断
入口RPGのF仕様やDCL-Fで使うファイル名とライブラリを確認する同名ファイルやライブラリ違いを先に除外する
定義DSPFDやDDSで基礎物理ファイル、キー、選択条件を確認するLFごとの抽出条件や並び順の違いを見分ける
データ対象キーをPFとLFの両方で照合するPFに存在してLFに出ないなら選択条件やキーを疑う

LFを作り直したりデータを直接修正したりする前に、対象レコードが選択条件を満たすかを確認します。調査記録には、見たライブラリ、PF、LF、キー値、確認時刻を残します。

スポンサーリンク