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