[Info-vax] Indexed file read question

[abrsvc]

On Thursday, 19 November 2020 at 12:36:50 UTC-5, Hein RMS van den Heuvel wrote:
> On Thursday, November 19, 2020 at 10:47:07 AM UTC-5, Stephen Hoffman wrote: 
> > On 2020-11-19 04:50:35 +0000, Hein RMS van den Heuvel said: 
> > 
> > > ...with duplicates the first (by time) inserted with that first key... 
> > 
> > Which I've incorrectly referred to as "indeterminate" here, though I've 
> > approximately never been seeking duplicate records returned in 
> > insertion-time order.
> You have... Remember VMSmail? The FOLDER name? That's an alternate key with duplicates! 
> So a DIR/FOL=xxx returns messages in the order you'd expect. 
> Least surprise engineering. 
> 
> Business applications might have a 'status' flag say 'A' for Action, 'P' for Print and ' ' <space> for 'done' with a NULL key value of space. 
> The application can subsequently ask for the first A row to be processed or P row to be printed. 
> It can be useful, but it is not very robust. 
> 
> To build on my earlier example, see what CONVERT does to the file: 
> 
> $ conv/key=1 tmp.idx tt:/fdl=nl: 
> noot A 
> aap A 
> vuur B 
> mies B 
> $ conv tmp.idx new.idx 
> $ conv/key=1 new.idx tt:/fdl=nl: 
> aap A 
> noot A 
> mies B 
> vuur B 
> 
> Mind you for VMSmail, this caused no issue because the PK was a timestamp and thus convert delivered messages in folders by time order. 
> Many, if not most, business application essentially hand out PK's in always increasing order again making the right thing happen in general, but not guaranteed. I'm sure this has caused head-scratching or perhaps support calls over time. 
> 
> Fun? 
> Hein

Yes its fun...

Once again I see that an application works by accident rather than intent.  This is not the first nor I suspect, will it be the  last.