Re: File level identifier is changed by CRTDUPOBJ

It is already noted that the "File Level Identifier" is the timestamp of the file creation, unrelated to the "Record Format Level Identifier" and level checking by QDMCOPEN; albeit somewhat insufficient for the lack of milliseconds, to serve its intended purpose well.

If there is a CPF4131 condition even where the DSPPGMREF shows the *matching* value 4AE630978C180 for the RcdFmt LvlID, then FWiW there was for some time a chain of defective PTFs [never on a cumulative AFaIK, so only orders outside cumulative would have experienced the problem] which caused a "correction" to the record format level identifier, but without also correcting the member level identifier. The Data Management level checking [honoring a LVLCHK of *YES] will report the difference between the member and the program, *not* the difference between the RcdFmtLvlID and the program. So a condition originating from the side effect of that defect can prove confusing. There is no external user interface which manifests the record format level identifier stored in the *MEM object, except DMPOBJ for all members or DMPSYSOBJ for any one member; e.g. the DSPFD *MBR does not show the value. I described something about this problem in a past discussion somewhere; it should be in the archives here, although I can not find any.

The following APAR, IIRC, provides one of the highest PTF fix levels required to be preventive for that.
http://www.ibm.com/support/docview.wss?uid=nas2dffd8a903d89060486256f8800424638
SE18855 - OSP-MSGCPF4131 CRTDUPOBJ CHANGES FORMAT LEVEL ID RCDFMT LVLID DFT DFTVAL DDS LF JLF OVER SQL TABLE R510 R520 R530

IIRC some information on recovery was in Informational APAR II14134
http://www-912.ibm.com/n_dir/nas4apar.NSF/1be1a5b61b213a6c86256c23007048f4/21529fcce2f4b070862571010041fe11?OpenDocument

Regards, Chuck

Pete Hall wrote:

This is causing level check errors in our RPG programs, even though the record format level ID is unchanged. Anybody have
any insight on this?

I conducted a little experiment:

Original file (Attribute = PF-DTA)
file: 1100119152826
Record: 4AE630978C180

After CRTDUPOBJ with DATA(*NO) CST(*NO) TRG(*NO)
File: 1100121153527
Record: 4AE630978C180

<<SNIP>>