Re: CHAIN Versus SETLL and READ When Data Needed

["Rory Hewitt" <roryhewitt@xxxxxxxxx>]

Actually, if all Shannon is interested in is performance, it *might* make
sense to initially load all the records into an array and perform a lookup
(using bsearch() or similar if necessary) with each of the keys, as Tony
suggests. If a record needs to be written, the record can be written to the
database and then added to the array (which is then re-qsort()ed). Of
course, like Tony's solution, you could just have the keys in the array,
which would reduce the amount of memory required for the array, but you'd
need to actually access the file to get the data.

You could probably have a single procedure, which accepts all 3 key fields
and returns the record which matches (either all 3 keys or only 2 or only
1):

RcdFmt = GetMatch( Key1 : Key2 : Key3 );

I'm serious. This would certainly be faster than doing 3 I/O's. It's a great
system for 'control' files where the data won't change during the lifetime
of a job. All the I/O is done in a single hit up front. I use this method *a
lot* for situations where performance is critical.

I've also written a procedure which loads an entire file into memory,
removes duplicate records and 'dummy' records and then uses a combination of
memcmp()/memchr() to find a matching record. It's *blazing* fast - much
better than direct file access.

Rory

On 2/28/07, Tony Carolla <carolla@xxxxxxxxx> wrote:
> Items to consider:
>     A)  The data in the tables might change throughout the day -- perhaps
> the users should notify each other when they make changes, so that they
> can
> signoff/sign on and rebuild their "arrays"
>     B)  The number of unique fields might cause your *SRVPGM to allocate
> too much memory (in each and every client job) -- consider upgrading your
> RAM
>     C)  You will have the privelige of being the only one on the planet
> who
> knows how to make any changes.
>
> PS.  If you do this, you have probably studied one too many "Sorcerer's
> Guides"--