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.
midrange.com
