Re: File level identifier is changed by CRTDUPOBJ

[CRPence <CRPbottle@xxxxxxxxx>]

  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>>