As far as I know, it’s not possible to add or delete a field definition without altering the record format level identifier. The level ID is calculated based on the field definitions.
I concur with Martin. This cannot be done and it’s a good thing.
The level identifier is used by RPG(LE) and COBOL programs when they use Externally defined files to make certain that the data map they were compiled with is current.
On crtpf or chgpf you can set the Record format level check . . . *NO and the programs will not abort but this is a really bad idea.
The correct process is to recomile all of the programs that use the datafile when it’s changed.
The DSPFD will show the level identifier and the DSPPGMREF shows the level identifiers of the files that the program was compiled with.
SQL can avoid some of these issues when field names are used.
I have small question about above answers,
if we do CHGPF on Phisical File after addition of one field ihave seen with DSPFD on file, there is no change of Level Identifier.
if we add or delete any field in PF and after that if we compile it then Level Identifier will change
Please find below example:
Level Identifier in PF before any changes to it is: 28C5A9410A6DD
Level Identifier in PF after addition of one field to it and CHGPF is: 28C5A9410A6DD(above and this is same)
Level Identifier in PF after addition of one field to it and Compile PF is: 2B4E71BDCD54D(now it has changed).
my conclusion is we can add one extra field to PF without changing of Level Identifier
Please tell me whether i am correct or not ?
Sorry, you are wrong. I think that when you did the CHGPF you failed to identify the source member (see below example) and the field wasn’t added. The CHGPF can also be used for changing a number of other parameters so it doesn’t assume that it should get the source and add in the new fields.
CHGPF FILE(Myfile) SRCFILE(mylib/QDDSSRC) SRCMBR(Myfile)
The level identifier will always be created from the file structure, that’s it’s purpose.