Re: CHGPF on file with multiple format logicals.

Chuck,

Thanks for the reply, and your assumption is correct. After I posted
the example - that shortened version of the LF was not the one that
was causing the problem - I figured out which LF was and yes, ICDETLF1
used the implicit structure of the physical by not naming any fields,
and the second format (ICDETLF2) did list the fields included in that
format.

now, my only question is _why_ is that error expected?

On 12/3/07, CRPence <crp@xxxxxxxxxxxxxxxxxxxx> wrote:

The error is unexpected, with the _given_ source. If however the
MFLF source as it really exists does *not* explicitly list the fields
for a format, then the error is correct. If any format of the MFLF
simply names/refers to the PF format, without naming any fields, then
the error is correct where any format has explicitly named fields.
Because the error was for ICDETLF2, it would seem most likely that the
first format was actually an implicit reference to the format of the
physical, rather than the named format ICDETLF1 with its named list of
fields.?

Regardless, the easiest resolution is by deleting that MFLF before
the ALTER. That action may be the preferred resolution anyhow, because
the desirable outcome is _typically_ that the K DTLINE and the field
DTLINE in the MFLF should reflect the changed field length [of the
physical]. Formats of MFLF which have explicit field lists can never
inherit the changed field, because that LF format is not sharing the
format of the physical file.

I verified on a new PF and LF, that the error did not occur with the
given LF source. However when the LF source was modified such that an
inserted [as the first] format was simply a reference to the physical
format, then CPF3238 was received for each of format that followed.

Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer

rick baird wrote:

I have a physical file with several multiple format logicals built
over it (don't ask, I wouldn't have done it this way). The
multi-formats are used to sub-select certain records from the same
physical.

A simplified look at how the logicals are created:

R ICDETLF1 PFILE(ICDETLP)
DTLVL1
DTWHSI
DTLINE
<snip lots of fields>
K DTWHSI
K DTLINE
O DTLVL1 CMP(EQ '1')

R ICDETLF2 PFILE(ICDETLP)
DTLVL1
DTWHSI
DTLINE
<snip lots of fields>
K DTWHSI
K DTLINE
O DTLVL1 CMP(EQ '2')

R ICDETLF3 PFILE(ICDETLP)
DTLVL1
DTWHSI
DTLINE
<snip lots of fields>
K DTWHSI
K DTLINE
O DTLVL1 CMP(EQ '3')


I'm changing DTLINE from 4A to 6A (the physical uses a reference file
to define the field).

When I start the CHGPF process, it halts with the following message:

CPF3238 Message . : Key field DTLINE not same as previous formats.
Cause . . : A logical file was being created by your job. However,
the key field DTLINE in record format ICDETLF2 has a different type
and/or length than the key fields in the same position in previous
formats. <snip>

So, it converted the initial format (ICDETLF1) but halted on the
second, I assume because it can't match up DTLINE in format ICDETLF2
in the new definition from the temporary new PF.

Has anyone else run into this? any ideas on how I can get CHGPF to
work for these logicals, or should I quit wasting my time and just
delete before and rebuild them afterwards?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.