AS400ライブラリリスト違いによる障害の調べ方｜開発・本番・テスト環境差を見る

2026.06.11

AS400 / IBM i では、開発環境では動くのに本番環境で動かない、テストでは読めたファイルが本番で読めない、コンパイルは成功したのに実行時に別のファイルを見る、という相談があります。原因の一つがライブラリリストの違いです。

環境差で見ること

確認見るもの判断
実行時LIBLジョブのライブラリリスト本番で正しい順番か
コンパイル時LIBL参照したDDS、ファイル、プログラム開発用定義を見ていないか
同名オブジェクトライブラリ別のファイル、プログラム別ライブラリのものを先に拾っていないか
JOBDジョブ記述、初期ライブラリ対話とバッチで差がないか
リリース手順反映先、戻し先、確認者古いオブジェクトが残っていないか

同名オブジェクトは事故の元

AS400では、同じ名前のファイルやプログラムが複数ライブラリに存在することがあります。ライブラリリストの順番が変わると、意図しないオブジェクトを参照してしまいます。特にテスト用ライブラリや一時対応用ライブラリが残っている場合は注意が必要です。

コンパイル時と実行時を分けて見る

コンパイル時に参照した外部記述と、実行時に参照するファイルが違うと、桁数や項目の不一致、データ誤読、実行時エラーにつながります。修正後は、コンパイルリスト、DSPFFD、実行ジョブのLIBLをセットで確認します。

ライブラリの基本は AS400ライブラリとオブジェクトの基本、コンパイルエラーは AS400 RPG/CLコンパイルエラーの調べ方、本番反映は AS400本番反映・戻し手順チェックリスト を参照してください。

Codexで差分表を作る

Codexには、匿名化したライブラリ名、ジョブ種別、参照順、エラー文を渡すと、開発・テスト・本番の差分表を作りやすくなります。実環境名や顧客名は入れず、確認観点の整理に使います。

関連: AS400 SAVF移送・復元チェックリスト｜FTP転送・RSTOBJ・ライブラリ違いで見ることもあわせて確認してください。

関連: AS400 RPG/CLコードレビュー観点｜本番障害を減らすために見るポイントもあわせて確認してください。

対話処理は成功しバッチだけ失敗する例

同じプログラムが対話処理では成功し、SBMJOB後だけファイル未検出になる場合、ライブラリリスト差を疑います。

確認点確認内容判断
対話ジョブ現在ライブラリとユーザー部のライブラリ順を記録する偶然先に見つかった同名オブジェクトがないか確認する
バッチジョブジョブ記述、投入元、開始プログラム、実行中の変更を確認する対話ジョブから継承したと思い込まない
再現確認テスト環境で対象ライブラリを修飾して同じ処理を試す恒久対応はジョブ設計とオブジェクト参照を見直す

ADDLIBLEやCHGLIBLによる変更は実行中のジョブに作用します。原因確認のための一時変更と恒久設定を分け、変更前の順序を必ず記録します。

仕様確認: IBM公式のライブラリリスト解説

現場で一番よく見る失敗｜自分のライブラリの古いファイル定義でコンパイルしてしまう

ライブラリリスト絡みで運営者が一番よく見てきた失敗は、これです。

通常の実行環境のライブラリリストの上に、自分の作業用ライブラリが乗っている状態で作業している。そこに古いファイル定義が残っている。この状態でコンパイルすると、ライブラリリストの検索順で自分のライブラリのファイルが先に見つかるため、古い定義を参照した形でプログラムができあがります。

コンパイル自体は通ります。自分の環境で動かしても、たいてい普通に動きます。問題が出るのはその後です。自分のライブラリが乗っていない通常の実行環境で、他の人がそのアプリを動かした時にアベンドします。

自分の手元では再現しないので、報告を受けた側も「こちらでは動くのですが」となりがちです。実際には、プログラムが覚えているファイルの形と、通常環境にある実ファイルの形が食い違っています。

レベルチェックとして表に出る

この食い違いは、ファイルを開いた時点でレベルチェックとして検出されます。IBM iはファイル作成時にレコード様式ごとに固有のレベル識別子を割り当てており、プログラムが持っている識別子と実ファイルの識別子が一致しないとエラーになります。メッセージは CPF4131（Level check on file）です。

確認は、ファイル側とプログラム側のレベル識別子を突き合わせます。

DSPFD     FILE(TESTLIB/ORDERPF)
DSPPGMREF PGM(TESTLIB/TEST001R)

DSPFD でファイルのフォーマットレベル識別子を、DSPPGMREF でプログラムが参照しているファイルとその識別子を見ます。ここが一致していなければ、そのプログラムは通常環境で落ちます。

確認見るもの判断
コンパイル時のライブラリリスト自分の作業用ライブラリが上に乗っていなかったか乗っていたなら、どのファイルを拾ったかを疑う
自分のライブラリの中身古いファイル定義が残っていないか使わないファイルは消すか、リストから外す
フォーマットレベル識別子DSPFD の値と DSPPGMREF の値不一致なら通常環境でレベルチェックになる
再現環境自分の環境でしか動かない状態になっていないか通常のライブラリリストで再コンパイルして確認する

やってはいけない対応

レベルチェックは LVLCHK(*NO) を指定すれば止められます。ただし、これはエラーを消しているだけで、形の食い違いは残ったままです。読み書きする位置がずれて、気づかないままデータが壊れる可能性があります。エラーを黙らせる前に、どのライブラリのどのファイルを拾ってコンパイルされたのかを先に確認してください。

正しい直し方は、通常の実行環境と同じライブラリリストで再コンパイルすることです。詳しい仕様はSpecifying the record format level check (LVLCHK) parameter – IBM Documentationで確認できます。

関連するAS400確認ルート

ライブラリリスト違いは、開発・検証・本番の取り違えや、同名オブジェクト参照ミスにつながります。DSPLIBLやWRKOBJだけでなく、障害時の確認順と基本構造を合わせて見ます。

環境差はライブラリリストの順番で起きる

開発では動くのに本番で動かない、検証では別の結果になる、という時はライブラリリストの順番を確認します。同じオブジェクト名が複数ライブラリにあると、*LIBL指定では先に見つかったものが使われます。私はDSPLIBLとWRKOBJを並べて、どのライブラリのオブジェクトが参照されるかを確認します。

  • 本番・検証・開発のライブラリ順を比較する
  • 同名オブジェクトが複数ないかWRKOBJで見る
  • JOBDやSBMJOB時のライブラリ設定を確認する
  • 一時的なCHGLIBLが残っていないか確認する
スポンサーリンク