RE: CHAIN Versus SETLL and READ When Data Needed

That's a good idea Rory, and we actually do that for smaller files. For
the files that have six million or more records, however, that's not
such a good solution.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Rory Hewitt
Sent: Wednesday, February 28, 2007 8:54 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: CHAIN Versus SETLL and READ When Data Needed

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"--