× 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.



A secretary once told me that we don;t care about efficiency, we care about effectiveness. This, to my mind, is an example of that. If performance is a concern then the differences between SETLL and CHAIN are not going to solve his problem. He needs to look in other areas. If performance isn't the issue then wouldn't it make sense to opt for the clearest, most easily maintained code?

Rory Hewitt wrote:
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-Ups:
Replies:

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.