Re: CHGPF

David FOXWELL wrote:

CRPence wrote:

The limitations are fewer than manual, but a review of the DSPDBR RCDFMT(*ALL) of the PF should be done to know what LF will change,
and that the exception of that list from DSPDBR RCDFMT(*NONE)
represents those LF that will not change; the manual method
results, will depend on the DDS and/or methods used for creating
the LF.

I'm having some difficulty with this.

I have LF1, a logical that names the zones of the PF in the DDS.
LF2 just names the key fields.

I can't see any reference to LF1 when I do DSPDBR.

DSPDBR FILE(mylib/PF) RCDFMT(*none) shows LF2.

DSPDBR FILE(mylib/PF) RCDFMT(*all) shows LF2 and the PF plus some
other LFs in other libraries. I assume these are due to shared access
paths.

The RCDFMT(*ALL) request shows files sharing the /format/, not those sharing the access path. The described LF1, whereby it names the fields in the DDS, would not be expected to be seen in the second DSPDBR, but it would be expected to be seen in the first DSPDBR.

If no LF1 appears in DSPDBR FILE(mylib/PF) RCDFMT(*NONE) MBR(*NONE), then there is most likely no LF1 built on that PF. If there is a somelib/LF1 that is expected to be built over mylib/PF, then verify by DSPFD somelib/LF1 what is its 'based on' file. If the 'based on' file for DSPFD somelib/LF1 shows PF *in mylib*, then there is an error that can /only/ be corrected by re-creating the database file network. More often than not with such an error, in my experience, the origin for error is with a false assumption about what files are related; perhaps due to object text making that false implication and thus the reader trusting versus verifying, perhaps due to its PF having been renamed.

Regards, Chuck