AS400 / IBM i でSQLを実行した時に SQL7008 が出ると、テーブルやメンバーの状態、ジャーナル、コミットメント制御、権限、SQL実行環境のどこを見ればよいか迷いやすくなります。特に、RPGやCLでは動いていた処理をSQLや外部連携から実行した時に表面化することがあります。
この記事では、DB2 for i でSQL7008が出た時の確認順を、AS400保守現場の目線で整理します。エラー文だけで判断せず、対象ファイル、メンバー、ジャーナル、コミット、ジョブログを合わせて確認します。
最初に確認すること
- 対象が物理ファイルか、論理ファイルか、ビューか
- メンバーが存在するか、指定メンバーが正しいか
- SQL実行ユーザーに権限があるか
- ジャーナルとコミットメント制御が関係しているか
- RPG、CL、ODBC、ACS、外部APIのどこから実行しているか
DSPFFDとDSPPFMでファイル状態を見る
まず対象ファイルの定義をDSPFFDで確認し、必要ならDSPPFMでメンバーやデータの状態を確認します。SQLで参照している名前と、ライブラリリスト上の実体がずれていると、想定と違うファイルを見ていることがあります。
外部連携やWeb化の途中でSQL7008が出る場合は、対話型ジョブとサーバージョブでライブラリリスト、ユーザープロファイル、コミット属性が違うこともあります。5250画面からの実行結果だけでなく、実際の実行ジョブのジョブログを確認します。
コミットメント制御とジャーナルを疑う
更新系SQLでSQL7008が出る場合、コミットメント制御やジャーナル設定が関係することがあります。RPGやCLからは問題なく動く処理でも、SQL実行環境がコミットを要求している、または対象ファイルがジャーナルされていない、といった差で失敗することがあります。
この場合は、STRJRNPF、ENDJRNPF、DSPFD、DSPJRNなどをむやみに実行する前に、現行運用でジャーナルがどう使われているか確認します。会計、在庫、受注、出荷など本番データに関係する場合は、設定変更を急がず、影響範囲を整理してから対応します。
ジョブログで直前メッセージを見る
SQL7008だけを見ても原因が絞れない時は、ジョブログで直前のCPF、SQL、MCHメッセージを確認します。エラーの最後だけでなく、最初に失敗したオブジェクト名、ライブラリ名、メンバー名、SQL文、実行ユーザーを控えます。
メッセージIDから調べる場合は、AS400メッセージID・エラーコード索引、SQL Servicesの基本は IBM i SQL Services入門、Web/API化でSQLを使う場合は AS400のWeb化・API連携ガイド を合わせて確認してください。
対応前チェックリスト
- SQL7008が出たSQL文を保存したか
- 対象ライブラリ、ファイル、メンバーを確認したか
- 実行ユーザーとライブラリリストを確認したか
- コミット、ジャーナル、ロックの状態を確認したか
- 本番ファイルの設定変更前にバックアップと影響範囲を確認したか
SQL7008は、SQLだけの問題に見えて、AS400のファイル運用、ジャーナル、ジョブ環境、権限に関係していることがあります。外部連携やモダナイゼーションの途中で出た場合は、SQL文だけでなく実行環境ごと確認するのが近道です。
