Re: READE with partial key

[CRPence <CRPbottle@xxxxxxxxx>]

  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.