Re: Unique Partial Keys - V5R4 vs V7R1 -- MIDRANGE-L

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.
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. But in V7R1, there seem to be some
more internal sequencing happening. 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. Can you please
help me out on understanding this as there are processes defined
based on the sequence getting returned from the logical. Once I get
to know the understanding, I also will have to fix, which if you
could guide will be great.

Setup and re-create to describe, what I infer is described above as the effect seen:

Member Type Text
KXL_1KFIFO LF LF on KXP (F1)

A R KXPR PFILE(KXP)
A K F1

Member Type Text
KXL_2KFIFO LF LF on KXP (F1, F2)

A R KXPR PFILE(KXP)
A K F1
A K F2

Member Type Text
KXL_RGZPFM LF LF on KXP (F3)

A R KXPR PFILE(KXP)
A K F3

Member Type Text
KXP PF F1, F2, F3

A R KXPR
A F1 00010A
A F2 00010A
A F3 00010A

CRTPF QTEMP/KXP
CPYF QSYS/QADBKFLD QTEMP/KXP MBROPT(*REPLACE)
CRTFILE(*NO) FMTOPT(*NOCHK)
FROMKEY(2 ('QSYS QADB'))
TOKEY(2 ('QSYS QADB'))
CRTLF QTEMP/KXL_RGZPFM
RGZPFM FILE(QTEMP/KXP) MBR(*FIRST) ALWCANCEL(*NO)
KEYFILE(QTEMP/KXL_RGZPFM KXL_RGZPFM)
// physical data setup is now done
CRTLF QTEMP/KXL_1KFIFO
CPYF QTEMP/KXL_1KFIFO *PRINT FROMRCD(*START)
DSPSPLF QSYSPRT SPLNBR(*LAST) /* RCDNBR sequential from 1 */
CPYF QTEMP/KXP *PRINT FROMRCD(1)
DSPSPLF QSYSPRT SPLNBR(*LAST) /* RCDNBR sequential from 1 */
// established that the one-key order matches physical order
CRTLF QTEMP/KXL_2KFIFO
DLTF QTEMP/KXL_1KFIFO
CRTLF QTEMP/KXL_1KFIFO
// msg CPI3210 "File KXL_1KFIFO in QTEMP shares access path"
DSPFD QTEMP/KXL_1KFIFO
//: Access Path Description
//: Number of key fields . . . . . . : 1
//: Record format . . . . . . . . . . : KXPR
//: Key field . . . . . . . . . . . : F1
//: Member Description
//: Number of unique partial key values:
//: Key field 1 . . . . : 1
//: Key fields 1 - 2 . : 35
//: Implicit access path sharing: Yes
//: File owning access path: QTEMP/KXL_2KFIFO
DLTF QTEMP/KXL_2KFIFO
// Although no msg, two-key AccPth owned by KXL_2KFIFO
// was transferred to the one-key file KXL_1KFIFO
DSPFD QTEMP/KXL_1KFIFO
//: Access Path Description
//: Number of key fields . . . . . . : 1
//: Record format . . . . . . . . . . : KXPR
//: Key field . . . . . . . . . . . : F1
//: Member Description
//: Implicit access path sharing: No
//: Number of unique partial key values:
//: Key field 1 . . . . : 1
//: Key fields 1 - 2 . : 35
// absent now, above, is anything about access path sharing
CPYF QTEMP/KXL_1KFIFO *PRINT FROMRCD(*START)
DSPSPLF QSYSPRT SPLNBR(*LAST) /* RCDNBR no longer sequential */
// established that the one-key order no longer matches the
// physical order with the FIFO duplicate-key ordering; instead
// reflects the two-key order of the previously shared keyed
// access path that had been since re-associated\re-assigned
// owner to the one-key LF

One means for corrective; depends on requirements of actual scenario, if the following is sufficiently corrective as contrasted with use of Delete File (DLTF) [vs Remove Member (RVMV) shown]:

RMVM FILE(QTEMP/KXL_1KFIFO) MBR(KXL_1KFIFO)
ADDLFM FILE(QTEMP/KXL_1KFIFO) MBR(KXL_1KFIFO)
DTAMBRS((QTEMP/KXP KXP))
TEXT('rebuild keyed AccPth to match the LF (DDS)')

Verification of corrective action:

CPYF QTEMP/KXL_1KFIFO *PRINT FROMRCD(*START)
DSPSPLF QSYSPRT SPLNBR(*LAST) /* RCDNBR is again sequential */

As I had noted in my prior reply, the corrective may [best] include differentiating /duplicate-key-ordering/ [e.g. FCFO or LIFO DDS keywords] to ensure the access paths are incompatible for that specification; preventive to recurrence for delete\re-create activity, without the need to ensure the activity is carefully\properly /ordered/ as the means for preventive.