×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
John,
A very nicely constructed test scenario. :-)
The record format level ID for LF2 no longer matches because the total record length of LF2 is now different than the record lengths for the PF or for LF1. The hashing algorithm that computes the level ID considers the record length, and the types, lengths, and decimal places of each component field in the record, from left to right. Note that it does not take into consideration the field names, or the field text descriptions, etc.
Record format sharing is also a rather complex subject that has never been well-documented or well explained, except perhaps in some internals documentation within the walls of IBM RTC (aka. RochLabs).
Mark
On Thursday, January 28, 2021, 5:57:27 PM EST, smith5646midrange@xxxxxxxxx <smith5646midrange@xxxxxxxxx> wrote:
It doesn't matter if the format names match in the PF and LFs.
I created the following DDS members
JRSTESTPF
R RTESTPF
FIELD1 10
FIELD2 10
FIELD3 10
K FIELD1
K FIELD2
JRSTESTLF1
R RTESTPF PFILE(JRSTESTPF)
K FIELD2
K FIELD1
JRSTESTLF2
R RTESTPF PFILE(JRSTESTPF)
FIELD1 10
FIELD2 10
FIELD3 10
K FIELD3
K FIELD2
Note that JRSTESTLF2 has the fields included in the DDS.
The record format IDs on all three files match.
I changed FIELD1 from 10 to 20
JRSTESTPF R RTESTPF
FIELD1 20
FIELD2 10
FIELD3 10
K FIELD1
K FIELD2
And then do a CHGPF on JRSTESTPF
FIELD1 in JRSTESTPF is changed to 20
FIELD1 in JRSTESTLF1 is changed to 20
FIELD1 in JRSTESTLF2 is NOT changed. It remains 10 bytes.
Also, the record format ID on JRSTESTPF and JRSTESTLF1 match. JRSTESTLF2 no longer matches.
midrange.com
