Re: CHGPF and level check

[CRPence <CRPbottle@xxxxxxxxx>]

  Since CPYF does not support LVLCHK(*YES), presumably the error 
being seen is the diagnostic message CPF2963 [i.e. not a level check 
error, which is the escape message CPF4131], which probably would be 
resolved by specifying the FMTOPT(*DROP *MAP) on the CPYF request; 
mostly noted already, by Dennis.

  It is written in the quoted message, that *LIBL was used to find 
the source member TRNFILE.  So for a changed physical file which 
should match in RcdFmt LvlId to the file created from the same 
source, at least be sure to verify that the same source member is 
accessed by both the CRTPF TRNFILE and CHGPF LOGFILE.  Since a 
request to CHGPF SRCFILE(named) will perform a CRTPF SRCFILE(named), 
the resulting changed file [which is really the newly created file] 
should have the same format as the created file.  A difference seems 
improbable without the TRNFILE having been restored or duplicated, 
perhaps since it was created on another system or ASP.  If the 
source does create two different RcdFmtLvlId, perhaps including the 
DDS source and that identifier shown by DSPFFD and DSPFD *RCDFMT, 
would allow others to perform the create to compare their record 
format level identifier versus the one on your system.

Regards, Chuck

Åke Olsson wrote:
> We have a log file (with lots of members) that should always
> match the layout of a transaction file.
>
> A member is created for each transmission of data.
>
> When the format of the transaction file is changed we do a
> "CHGPF FILE(LOGFILE) SRCFILE(*LIBL/QDBASRC) SRCMBR(TRNFILE)"
>
> After this we expect that the level-ids of the two files are
> identical. However they are not. The record formats are the same
> (number of fields, field placement etcetera).
>
> Because of this we get a level check when doing a CPYF from
> TRNFILE to LOGFILE.
>
> How can we avoid this without having to do it the old way and
> manually copy all data?