3.3.二つのレベル識別コードについて |
レコード様式レベル識別コード外部記述は別の言い方をすれば、『プログラム作成前の事前のバッファー定義』と言えます。 残念ながら、実行時にOSによって、動的にバッファーの変更はされません。
これが所謂、『レベルチェック』で、その識別子を『レコード様式レベル識別コード』といいます。 これを自分で確認する方法は、 DSPFD file *RCDFMT 予め、QRYなどで見ておけば、『レベルチェック』でエラーとなるか否かは判断できます。マスターファイルの変更のときに、これを調べれば、リコンパイルもれを防ぎ、レベルチェックエラーを未然に防げます。但し、QRYプログラムは、DSPPGMREFでファイルを取り出せませんので、注意して下さい。 LVLCHKについてファイル定義上にパラメータLVLCHKがありますが、これは上記のバッファーの同一性を検査するか、否かの指定です。(CRTPF/CRTLF/OVRDBF...) 通常、LVLCHK=*YESですが、これを*NOにしてしまう場合もあります。例えば、極めて多くのプログラムが参照するファイルにフィールドを追加する場合、レコードの最後ならば、そのファイルのLVLCHK=*NOとすれば、すべてのプログラムのリコンパイルをしなくて済みます。しかし、これは、レベル検査を放棄することで、極めて危険な行為であるため、なるべく避けたほうが無難です。 メンバーレベル識別コード通常のプログラム開発でこれが出てくることはあまりありませんが、保管・復元操作で出てきます。 OS/400が、保管するときに、そのメンバーの作成日と作成時刻を識別コードとして一緒に保管して、復元時にディスク上のメンバーの作成日と作成時刻の識別コードを比較して、復元可能か否かの判断材料にしています。RSTOBJのMBROPTが関係します。この識別子を『メンバーレベル識別コード』といいます。 訪問者の方から、ご指摘を頂きました。レコード様式レベル識別コードには、アクセスパスの情報(キーの構成)は、含まれません。従って、 キーの変更は、レベルチェックにかかりません。従って、もし、既存のキーの後ろに、他のキーを追加するだけなら、コンパイルの必要はありません。なぜなら、入力バッファに変更がないからです。 しかしながら、既存のキーの構成を変更(追加ではなく、すでに定義されているキーの順番を変更)した場合、レベルチェックエラーにならないため、
など、RPGを実行して初めて、エラーとなるものがあります。これに気づく手だては、実際にコンパイルをしてみるしか、今のところありません。もしかすると、ILEではAPIでRPGのキー情報を取り出せるかも、しれませんが(不明です)、少なくとも、OPMでは、コンパイルにで、エラーを起こすか、実際に実行してエラーを起こすか、しか、気づく手だてはありません。上記のことに注意をしてください。 まあ、予め、そのキー構成を変更しようとしているファイルを、FNDSTRPDMで、RPGの定義を検索して調べておく、くらいの用心深さを必要とします。 以上 |
You are at K's tips-n-kicks of AS/400
|
SEO | [PR] 爆速!無料ブログ 無料ホームページ開設 無料ライブ放送 | ||