× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.