The ILE programming model has drastically changed the way we program on the AS/400-iSeries. We now have modules, service programs, activation groups and a list of other new language-dependent and language-independent "features." But in this haze of new programming concepts, do we still need to worry about file level-checking?
File level-checking protects the database
If you have ever modified a physical file (e.g., added a new field or changed the length of an existing field) and you didn't recompile the programs that use that file, you probably found out the hard way about file level-checking. If level-checking is active for that file (which is the default), any program that has not be recompiled will receive an escape message when called.
The process of level-checking for a file is to ensure that programs using that file always use the current definition of the file, hence ensuring data integrity. An example will help clarify.
Say you have a file with two fields, a packed 5.0 field (3 bytes) followed by a 20-byte character field. In the record buffer, the packed field occupies bytes 1-3 and the character field occupies bytes 4-23.
You then create a program that writes data to this file. The compiler copies the record buffer information into the program so the program will write the data in the proper format.
Later, you decide that the packed field should be a 7.0 field instead of 5.0, and you make the change to the file. The modified packed field will now be 4 bytes long, so the new record buffer will have the packed field occupying bytes 1-4 and the character field occupying bytes 5-24.
If you do not recompile the program and level-checking was not in effect, the next time the program writes data to the file the character field will be written starting at byte 4 of the file. That is because byte 4 was the first byte of the character field in the original buffer layout -- the buffer layout the program will continue to use until recompiled. This causes an obvious problem: Byte 4 is now the last byte of the packed field in the new record layout.
How file level-checking works
There are five steps to the file level-checking process:
- Creation of the record format level-identifiers. When you create a file (physical, logical, display, printer and communications file types), the system generates a level-identifier for each record format in the file. The system uses a sophisticated hashing algorithm to generate a unique identifier based on the record name, the number of fields, the field names, the field types and the field lengths.
- Creation of the file level-identifier. The system also creates a single level-identifier for the file itself. This is simply the timestamp of when the file was created.
- Compiler copies the file level-identifier and the record format level-identifier(s) into the program. When you create a program that uses a file, the level-identifiers are copied into the program. The compiler stores, in the program, copies of the file level-identifier and the record format level-identifiers for each record format used by the program. You can use the Display Program References command (DSPPGMREF) to view the files used by a program and the associated level-identifiers.
- File level-identifier check at program run-time. When a file is opened by a program the system checks the file level-identifier stored in the program against the current file level-identifier in the file (recall, this is the timestamp of when the file was created). This check determines if the file has been recreated since the program was compiled. If the level-identifiers match, the process is done and the program runs as normal.
- Record format level identifier check at program run-time. If the file level-identifiers did not match (in step 4), then the system checks the record format level-identifiers. Each one stored in the program is checked against the corresponding level-identifier in the file. If a mismatch is found, the program gets a "record format level check" escape message. To correct the problem you need to recompile the program.
How to turn off level checking
You can turn level checking off for a file when you create the file. For example, the Create Physical File (CRTPF) command and the Create Logical File (CRTLF) command both have a Level check parameter (LVLCHK) that allows you to control level checking. When you use the default *YES, the system will go through the level checking process describe above. Specify *NO and the system will completely bypass the run-time level checks whenever the file is opened.
You can also control level checking at run time using the Override Database File (OVRDBF) command. It, too, has a Level check parameter that allows you to turn level checking off temporarily. Do this by specifying *NO for this parameter. Note, however, that you cannot specify *YES for this parameter, so you cannot turn on level checking at run time for a file created with LVLCHK(*NO).
Warning: Turning off level checking is dangerous
So, is file level-checking still necessary? You bet. Nothing has changed with ILE or DB2 with respect to file level-checking. Now, that doesn't mean there are no circumstances that call for turning off level checking, because there are. But you need to be extremely careful and know exactly what you are doing when you do turn off level checking.
-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.
