Re: READE with partial key

As long as the partial key specifications are correctly coded, as they appear to be, for the declared keyed file [thus opened by keyed sequence access path vs arrival access path], then the effects *must* reflect the keyed Access Path order as defined by that file. The first Item of the positioned key will have the *lowest* date value. Even accidental changes to access path sharing [e.g. due to restores] can not impact that.

However if the /date/ is not the DATE data type or the field is NULL-capable, then the effects might be easily misinterpreted, but the order must still reflect the keyed AccPth.

Any other effect would be a defect or a usage error. And I have since noticed, that the most recent followup message seemed to imply the latter... an error as a side effect of mis-reading and\or mistyping the date value(s) rather than an error with the coding. I am posting my reply anyhow, because the above *however* may have value to someone combing the archives for a similar described difficulty... with a different origin.

Regards, Chuck

On 19 Jun 2013 12:26, Jeff Crosby wrote:

<GASP!> I spoke too soon. I _could_ run through this section twice
and only set the date to *loval before the first time.

Jeff Crosby on Wednesday, June 19, 2013 2:54 PM wrote:

Suppose I have a file defined via DDL with unique key
consisting of:

Item (ascending)
Date (ascending)

// Set position in file
SETLL Item FILE;
// Only while this item
Dow '1';
Reade Item FILE;
If %EOF(FILE);
Leave;
Endif;
process record . . .
Enddo;

I am not assured of getting records within this item in
ascending Date sequence, am I? Some testing I'm doing now shows
that I don't.