Scan for Level Check Errors
Example 210 - Rating: common
This example submits a CL program to batch that scans a partition for level check errors. The CL program uses DSPPGMREF to get the record format level identifiers expected by the LANSA file IO modules, and DSPFD to get the record format level identifiers of the actual physical and logical files, and uses a query to compare the record format identifiers and report on those situations where an IO module needs to be recompiled.
Notes and Suggestions
The problem:
When adding/changing/removing a field in a file A, the programmer sometimes forgets to compile all the other files (B) that reference file A in validation checks. The problem may not be noticed immediately, but eventually a program inserts/updates/deletes to file B and causes the validation to be carried out against file A. When this happens the whole job crashes with message CPF4131. The job log looks like this
Level check on file S210HDR in library SETLIB with member S210HDR.
Function check. CPF4131 unmonitored by S210DET at statement *N,
instruction X'0F42'.
Where S210HDR is file A, and S210DET is file B.
The solution:
The first line of defence is to ensure that when you have made field changes to file A, you also recompile all files that reference file A in validation checks. This can be done using a printout for file A, or using impact lists.
But as a second line of defence, you can use this simple program to scan the partition for level checks.
How does it work?
LANSA files consist of a program (io module) that handles all LANSA function requests to that file, and also the physical and logical file objects that actually hold the data and provide keyed access. When an insert/update/delete to file B causes it to do a file lookup validation against file A, file B’s io module program is directly accessing the physical or logical file for file A.
The level check error occurs when the io module for file B does a validation check against the physical/logical file object for file A, and the record format level identifier for file A stored in the io module for file B does not match the record format level identifier of physical file A
In essence, to identify where a level check is going to occur requires only three steps:
1. Use DSPPGMREF for all the io module programs to list all their references to physical and logical files and the record format level identifiers expected by the program.
2. Use DSPFD (*RCDFMT) for all the physical and logical files to list their actual record format level identifiers.
3. Use a query to match the list of io module references to files with the list of file record formats, and get all the cases where the record format level identifiers don’t match.
Any IO module that shows up on the report needs to be recompiled (which is done using a LANSA file recompile)
Notes:
Note: Files S210HDR (file A) and S210DET (file B) are supplied to demonstrate the problem. An INSERT or UPDATE to file S210DET will cause a level check error when it validates field #S_210CODE against file S210HDR.
Note: *DBOPTIMISE LANSA functions that insert/update/delete to file B will include the relevant parts of file B’s io module in the program object for the function. Hence, if file A’s record format changes or file B’s record format changes, and the *DBOPTIMISE LANSA function inserting to file B is not subsequently recompiled, a level check will occur at run time. These potential level checks can also be detected by the scanner, provided the partition module library is one of the io module libraries being scanned.
Keywords
Example 210 - Rating: common
| The Things that Make Up this Example | To Execute this Example |
This example submits a CL program to batch that scans a partition for level check errors. The CL program uses DSPPGMREF to get the record format level identifiers expected by the LANSA file IO modules, and DSPFD to get the record format level identifiers of the actual physical and logical files, and uses a query to compare the record format identifiers and report on those situations where an IO module needs to be recompiled.
Notes and Suggestions
The problem:
When adding/changing/removing a field in a file A, the programmer sometimes forgets to compile all the other files (B) that reference file A in validation checks. The problem may not be noticed immediately, but eventually a program inserts/updates/deletes to file B and causes the validation to be carried out against file A. When this happens the whole job crashes with message CPF4131. The job log looks like this
Level check on file S210HDR in library SETLIB with member S210HDR.
Function check. CPF4131 unmonitored by S210DET at statement *N,
instruction X'0F42'.
Where S210HDR is file A, and S210DET is file B.
The solution:
The first line of defence is to ensure that when you have made field changes to file A, you also recompile all files that reference file A in validation checks. This can be done using a printout for file A, or using impact lists.
But as a second line of defence, you can use this simple program to scan the partition for level checks.
How does it work?
LANSA files consist of a program (io module) that handles all LANSA function requests to that file, and also the physical and logical file objects that actually hold the data and provide keyed access. When an insert/update/delete to file B causes it to do a file lookup validation against file A, file B’s io module program is directly accessing the physical or logical file for file A.
The level check error occurs when the io module for file B does a validation check against the physical/logical file object for file A, and the record format level identifier for file A stored in the io module for file B does not match the record format level identifier of physical file A
In essence, to identify where a level check is going to occur requires only three steps:
1. Use DSPPGMREF for all the io module programs to list all their references to physical and logical files and the record format level identifiers expected by the program.
2. Use DSPFD (*RCDFMT) for all the physical and logical files to list their actual record format level identifiers.
3. Use a query to match the list of io module references to files with the list of file record formats, and get all the cases where the record format level identifiers don’t match.
Any IO module that shows up on the report needs to be recompiled (which is done using a LANSA file recompile)
Notes:
Note: Files S210HDR (file A) and S210DET (file B) are supplied to demonstrate the problem. An INSERT or UPDATE to file S210DET will cause a level check error when it validates field #S_210CODE against file S210HDR.
Note: *DBOPTIMISE LANSA functions that insert/update/delete to file B will include the relevant parts of file B’s io module in the program object for the function. Hence, if file A’s record format changes or file B’s record format changes, and the *DBOPTIMISE LANSA function inserting to file B is not subsequently recompiled, a level check will occur at run time. These potential level checks can also be detected by the scanner, provided the partition module library is one of the io module libraries being scanned.
Keywords
| Example 210 | Level Check |
| File IO Module level check errors | CPF4131 – Level Check |