On 12-Sep-2015 20:29 -0600, Chella R wrote:

As part of our application upgrade, the OS has been upgraded from
V5R4 to V7R1 on our test servers. During this OS upgrade, one of the
issues noticed was the way the records were read of a logical file.

There almost surely was some deletion\re-creation activity that had transpired as part of the application upgrade; the OS upgrade by itself, would not have changed the LF.

The source file of the logical has only one field mentioned in the
key field. This logical was compiled in both versions. In the V5R4,
it will automatically sequence the record based on the key field I
had defined on the logical file.

So "it" is apparently Row-Level-Access (RLA) reading the record data via the Keyed Access Path; i.e. "the way the records were read of a logical file" was via the keyed access path.?

But in V7R1, there seem to be some more internal sequencing
happening.

Presumably [having read the following text already, where apparently the /one key/ has just one value across all rows], the data almost surely appears according to the Arrival Sequence Access Path with FIFO duplicate-key additional ordering in v5r4. But appearing instead, on v7r1, according to a two-key Keyed Access Path [where the physical\LIFO order does not match the ordering by the second key].

When I performed a DSPFD, the V5R4 showed only 1 key field and only
one Unique Partial Key values. When I performed DSPFD on V7R1,
though it showed only 1 key field as per my source file, it shows an
additional key in the Unique Partial key values. It also mentioned
it as Key fields 1 - 2.

The Database enables /sharing/ a compatible Keyed Access Path with another file over that same data. Though the LF DDS source names only one key, any existing and compatible Keyed Access Path over the same data with the same /left-most/ key(s) can be shared. The term /compatible/ is inclusive of the additional keyed attribute of either FIFO, LIFO, or FCFO that is established for duplicate-key ordering.

Given a file that shares the access path of another file, when that other\shared file is deleted, the sharing file will keep that access path [becoming the /owner/ of that AccPth], despite the source specifications not matching exactly with the definition of the Keyed Access Path. That the left-most key(s) match is considered acceptable, and notably, prevents actually having to re-create the access path as the effect of a deletion; the access path /ownership/ simply transfers to the remaining file. In this scenario: 1) A save\delete\restore of the LF would force the access path to match the definition by discarding the AccPth with mismatched key definitions and force the rebuild of the keyed access path with just the one-key; instead of the compatible two-key access path currently /owned/ by that file, the file will be shown as owning the one-key access path [just like with the v5r4 file]. 2) The LF could be deleted and then re-created from source to create the matching keyed access path that matches to the source.

Can you please help me out on understanding this as there are
processes defined based on the sequence getting returned from the
logical.

The Display File Description (DSPFD) will show either that the file is the /owning/ file of an access path [no sharing] or show another file that the displayed-file shares; sharing, only while that other file still exists [see: "Implicit access path sharing" in DSPFD displayed\spooled output]. For the latter case, after the shared file is gone, the file being displayed will since reveal statistics of the current\inherited access path [DSPFD TYPE(*MBR)], but reveal the original definition of the Access Path [DSPFD TYPE(*ACCPTH)] as declared by the LF DDS. The mismatch is deemed acceptable by the database because of the compatibility, and leaves the onus on the user\programmer to ensure the condition is prevented if\when required [by their application(s)].

Once I get to know the understanding, I also will have to fix, which
if you could guide will be great.

Seems... Because there was an already-existing and compatible keyed access path when the newer DDS LF Access Path was created, that newer LF [or LFM] shared the access path of the other\older file. That likely would occur because both files were created without additional duplicate-key ordering specification, thus defaulted to FIFO, and both being FIFO would mean they remained compatible. Data keyed by the non-unique [aka duplicate] data, beyond that one key field, implicitly is defaulted with duplicate-key ordering as FIFO.

In the scenario that the [expected to be one-key] file is still sharing the AccPth of an existing two-key logical file:

An option is to choose an incompatible additional duplicate-key ordering specification for the _shared_ access path [e.g. specify FCFO or LIFO] in the two-key LF source; delete and re-create the two-key LF, Best also to explicitly specify FIFO in the one-key LF. Then the order of LF creation is immaterial.

Another option is to depend on order-of Create\Add [CRTLF\ADDLFM] request, Delete File (DLTF) or Remove Member (RMVM) of the shared LF and create the one-key LFM first instead of second. Because the additional duplicate-key ordering specification remains the same, the undesirable order can recur do to various deletion\creation activity.

The other option of changing the one-key LF to specify incompatible [duplicate key] ordering specification is very probably not going to exactly match what is desired; i.e. choosing FCFO or LIFO for that file are not FIFO, and what is expressed as desired, is probably reflected only by FIFO.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].