AS400 / IBM i では、プログラム、ファイル、ジョブ記述、出力キューなど多くのものがオブジェクトとして管理されます。そして、それらを入れておく場所がライブラリです。Windowsのフォルダに近い説明をされることもありますが、IBM iではライブラリリストの順序が実行結果に大きく影響します。
ライブラリやオブジェクトを学ぶ前にシステム全体の役割を整理したい場合は、AS400とは何かを初心者向けに解説した記事 を先に読むと理解しやすくなります。
ライブラリとオブジェクトの基本
| 用語 | 意味 | 保守で見ること |
|---|---|---|
| ライブラリ | オブジェクトを管理する入れ物 | 本番、検証、開発、退避の区別 |
| オブジェクト | プログラム、ファイル、キューなどの管理単位 | 種類、所有者、権限、更新日時 |
| *LIBL | ライブラリリストから探す指定 | 同名オブジェクトの解決順序 |
| QTEMP | ジョブごとの一時ライブラリ | 一時ファイル、作業用データ |
| QGPL | 共通利用されやすいライブラリ | 安易に置かれた共有オブジェクト |
*LIBLが危ない理由
CALL PGM(MYPGM) のようにライブラリを省略すると、IBM iはライブラリリストの順にオブジェクトを探します。本番と検証でライブラリリストの順序が違うと、同じCLやRPGでも別のプログラムやファイルを参照することがあります。
DSPLIBL CALL PGM(MYPGM) CALL PGM(PRODLIB/MYPGM)
確認コマンド
| コマンド | 確認内容 | 使う場面 |
|---|---|---|
| DSPLIBL | 現在のライブラリリスト | *LIBL参照の解決順を見る |
| WRKOBJ | オブジェクト一覧 | 同名オブジェクトを探す |
| DSPOBJD | オブジェクト詳細 | 作成日時、更新日時、所有者、タイプ |
| WRKLIB | ライブラリ一覧 | 環境別ライブラリの確認 |
| WRKOBJLCK | オブジェクトロック | 更新待ち、削除不可、バッチ停止時 |
保守でよくある事故
- 検証ライブラリを見ているつもりで本番ライブラリを参照する
- 同名プログラムが複数あり、古い方が先に解決される
- QTEMP(ジョブ専用の一時ライブラリ)に作った一時ファイルがジョブ終了で消える
- QGPLに置かれた共通オブジェクトを誰が使っているか分からない
- 権限不足をプログラム不具合と勘違いする
RPG・CL・ジョブログとの関係
RPGでファイルを開けない、CLでCALL先が見つからない、バッチで権限エラーになる場合、ライブラリとオブジェクトの確認が必要です。調査時は CLのライブラリリスト確認、RPGのファイル確認、ジョブログ確認 をセットで見ると早く切り分けできます。
ライブラリ確認を研修で扱うとき
ライブラリとオブジェクトは、AS400 / IBM i の保守で最初につまずきやすい部分です。*LIBL、QTEMP、本番ライブラリ、検証ライブラリ、同名オブジェクトの優先順位を理解しないままRPGやCLを読むと、原因ではない場所を追い続けてしまいます。
ライブラリ確認は本番・検証・退避の取り違え防止にも効く
AS400 / IBM iの保守で怖いのは、コマンド自体を間違えることだけではありません。どのライブラリの、どのオブジェクトを見ているのかを取り違えると、正しい調査をしているつもりでも、本番とは違う結果を見てしまうことがあります。
| 確認観点 | 見落とすと起きること | 関連する確認 |
|---|---|---|
| *LIBL | 想定外のライブラリにある同名オブジェクトを参照する | CLの読み方 |
| 本番/検証ライブラリ | 検証環境を見て本番判断してしまう | 本番確認の基本 |
| オブジェクト属性 | プログラム、ファイル、DSPFなどの種類を誤認する | コマンド逆引き |
| ジョブログ | 実行時にどのライブラリを見たか追えない | CPFエラーとジョブログ |
| 社内教育 | 「名前は知っているが実務で判断できない」状態になる | 研修内容・料金を見る |
ライブラリとオブジェクトは、AS400の基礎でありながら、障害調査、改修影響、権限確認、引き継ぎのすべてに関わります。若手や兼任担当へ教える時は、用語説明だけでなく「どのライブラリを見ているかを毎回確認する」習慣までセットにすると、現場での事故を減らしやすくなります。
まとめ
AS400 / IBM i の保守では、ライブラリとオブジェクトの理解が土台になります。特に*LIBL、QTEMP、同名オブジェクト、権限、ロックは障害原因になりやすいため、ソースを見る前に実行環境を確認する習慣が大切です。
対話処理だけ成功する時のライブラリ確認例
同じプログラムが対話処理では動き、バッチでは別のファイルを参照する場合、オブジェクト名だけでなくライブラリリストの順序を比較します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| オブジェクト | 名前、種類、所在ライブラリを確認する | 同名の*FILEや*PGMを取り違えていないかを見る |
| ライブラリリスト | 対話ジョブとバッチジョブの現在ライブラリとユーザー部を比べる | 先に見つかる同名オブジェクトが違わないか判断する |
| 参照方法 | 一時確認ではライブラリ修飾名で対象を明確にする | 恒久対応はジョブ記述と配置ルールを見直す |
原因調査のためにライブラリリストを変更する場合は、変更前の順序を記録し、影響するジョブを限定します。確認できた事実と恒久対応を分けて残すと、別環境での再発を防ぎやすくなります。

