[Info-vax] Help with DECBasic: reading a record in an INDEX SEQ file using a compound key

[Paul Sture]

In article 
<12e2a011-8f9f-4823-8d89-60e7883fcac4 at a15g2000yqm.googlegroups.com>,
 Hein RMS van den Heuvel <heinvandenheuvel at gmail.com> wrote:

> On Jan 6, 3:16 pm, Paul Sture <paul.nos... at sture.ch> wrote:
> > In article
> > <768fc126-2441-4edc-83b9-6e71e2de0... at m3g2000yqf.googlegroups.com>,
> >  Hein RMS van den Heuvel <heinvandenheu... at gmail.com> wrote:
> >
> > > Notice how  I replaces FIND + GET with a direct call to GET.
> > > That saves a trip into RMS.
> > > There are  times and places where FIND should be used, but they are
> > > relatively rare.
> >
> > FIND + GET is something that I remember a RSTS BASIC programmer banging
> > on about many years ago for performance reasons, and I never understood
> > why he got so heated about it.
> 
> Ok, if you really want to know...

Thanks for the following explanation.
 
> The $FIND call has two potential purposes:
> 
> - The $FIND call does NOT copy the record data to the user provided
> record buffer, and thus saves on memory transfers and decompression.
> Not a big deal really. It helps just a tiny bit (1 % CPU ? ;-) for
> example when expunging a bunch of records.
> 
> - More importanly (IMHO) It establishes a CURRENT record without
> changing the NEXT record.  Thus you can be reading a file record after
> record by ordered by primary or alternate key, and still make a side
> trip to see whether an other records exists and update or delete if it
> does exist. The update is of course a little scary, as per above you
> did not get the old data, yet you will 'blindly' provide new data.
> Hmmm... ample opportunity for 'hidden' updates.
> 
> The $find has two missing features IMHO
> 1) It does not return the record length.. for quick counts or to grab
> the right size buffer.
> 2) It does not have an option to just return an RFA for alternate
> keys. It will always go to the data record to make sure it was not
> deleted, but causing what may be an expensive IO + potential RRV IO.
> 3) It does not have an option to just return the KEY value. Again for
> alternate keys without visiting the data: Find persons with lastname
> which starts with V and ends in L
> 
> The reason I want the second feature is because I'd lover to do a
> multi-key lookup by doing a  FINDs and establishing arrays of
> candidates, then visit the data records based on matching, or non-
> matching, RFA. For example: find all 'SMITH' records, find all
> 'NASHUA' records, retrieve data for records in both collections. Since
> this feature is not there, and RMS goes 'down' to the data record
> anyway, you might as well get all 'SMITH's records and look in the
> data for the other match criteria.
> 

Yes, the saving of CPU didn't overcome the lack of 1-3 IMHO.

I'll add:

3a) It does not have an option to just return the KEY value. Useful for 
partial or match on .GE. or .GT. reads.

-- 
Paul Sture