Database File-level Checking

If you make a change to a physical or logical file definition, you must either recompile the file using LVLCHK(*NO) or you must recompile all the programs that use the file in order to avoid getting a level check when attempting to open the file. In other words, programs must always be compiled after files. This is a common misconception.

If you enter the Display File Description (DSPFD) command, you will see a file level identifier which consists of the creation date and time for the file. Further down, you will also see a member level identifier which consists of the creation date and time for the file member.

From the member level identifier, you might expect that the file creation date and time were being used to verify that the current definition of the file is the same as the definition that the program was compiled with. However, the file level identifier and the member level identifier are not used in level checking.

Even further down on the file description display, you will find a record format level identifier. This is the level identifier that is used for level checking. This record format level identifier is determined only by the total length of the record format, the record format name, the number and order of the fields in the record format, the data type and size of the fields, the field names, and the number of decimal positions in the field.

Changes to any other DDS information have no effect on the record format level identifier and can be changed without having to specify LVLCHK(*NO) or recompiling the programs that use the file.

For example, the following DDS keywords can be changed without causing a level check: TEXT, COLHDG, CHECK, EDTCDE, EDTWRD, REF, REFFLD, CMP, RANGE, VALUES, TRNTBL, REFSHIFT and DFT. Join specifications, join keywords and access path keywords can be changed. You can even change the key fields and select/omit fields without causing a level check.