Re: CHGPF and level check

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?