Re: START KEY EQUAL TO

I'm going to go way out on a limb here, and assume that the SELECT statement
for Filename includes ORGANIZATION INDEXED ACCESS DYNAMIC RECORD KEY IS
PRIME-KEY, and that there are no alternate keys decleared. I'm also going
to presume that there actually exists a record in the file in which PK-VAR1,
PK-VAR2, PK-VAR3 and PK-VAR4 all match EXACTLY what you've put into the
record description of Filename immediately before the START.

The declaration of "PF-KEY1" falls in the cracks of the '74 standard syntax
rule 5: "... data-name-1 may reference a data item specified as a record
key ... , or it may reference any data item of category alphanumeric
subrdinate to the data-name of a data item specified as a record key ...
whose leftmost character position corresponds to the leftmost character
position of that record key data item." PF-KEY1 is NOT subordinate to
PF-KEY. This is clarifed in the '85 standard to eliminate this ambiguity
(by eliminating the "subordinate to ..." qualification); thus, PF-KEY1
*does* produce meaningful results in '85-and-later COBOL dialects.

Presuming that the current "key of reference" is PRIME-KEY, or that the
START is attempting to establish that field as the "key of reference", I
would expect the comparison on any implementation conforming to the '85
standard to be between the first 17 characters of PRIME-KEY and the
corresponding information in the file. If there are records satisfying that
criterion, I would not expect an error on the START. Note that the
standards explicitly state that when the data items involved in the
comparison are of unequal length, comparison is for the length of the
*shorter* (START statement, General Rule 4 in both the '74 and '85
standards; various rules conspire to produce the same result in the '02
standard).

If all of these criteria are met and demonstrable -- PRIME-KEY is the record
key, you've valid information in PK-VAR1 through PK-VAR4, you know that at
least one record exists in the file that matches all four of these values, a
nd you still get a "23" on the START ... KEY IS EQUAL TO -- I'd have a talk
with your vendor's support folk.

ISTM that the most likely compiler bug, if compiler bug there be, is that
the code generated is doing a "normal" comparison between unequal-length
alphanumeric items, which requires *space fill* of the shorter and
comparison for the size of the longer. That convention is expressly
COUNTERMANDED for the KEY comparisons for START in conforming COBOL
implementations by the aforementioned General Rule 4.

-Chuck Stevens

<cblkid@xxxxxxxxx> wrote in message
news:1119973385.735390.239950@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> I am working with a client who is using a START ...KEY IS EQUAL TO. We
> are migrating the code from an MVS system to Windows. The FD for the
> file is similar to:
>
> FD Filename
> 01 KEY-REC.
> 05 PRIME-KEY.
> 10 PK-VAR1 PIC 99.
> 10 PK-VAR2 PIC X(10).
> 10 PK-VAR3 PIC X(3).
> 10 PK-VAR4 PIC X(2).
> 10 PK-VAR5.
> 15 PK-VAR5A PIC X(2).
> 15 PK-VAR5B PIC X(4).
> 15 FILLER PIC X(10).
> 10 PK-VAR6 PIC 9(4).
> 05 PK-KEY1 REDEFINES PRIME-KEY PIC X(17).
>
> They supply values for PK-KEY1 and do a START on it (START filename KEY
> IS EQUAL TO PF-KEY1). They say this works on the mainframe. In the PC
> environment we are receiving an error (file status '23': Record not
> found). We agree with the PC version and have asked for a mainframe
> output to show this working.
>
> The logic being this is a partial key. When an EQUAL TO is used
> 'partial keys' can not be used. Is this correct? Can partial keys be
> used when a START EQUAL TO is?
>
> Thank you for all your insight and assistance!
>
> Long Live COBOL!!!
>


.