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



I suggest a good look at the SETOBJACC command, which will pin specified
objects in memory. For example, the critical index of a table may be locked
in memory via this command, hopefully eliminating most concerns about CHAIN
performance hit.

Like all performance questions, the correct answer to this one depends. I
question the validity of loading "the first x entries" into an array and
leaving the rest to CHAIN, since "the first x entries" will probably not be
the ones you want in any given situation. So for those, you have the CHAIN
impact PLUS the array lookup that theoretically preceded it.

I have used user indexes in the past, and they are wonderfully quick. You
have to decide how well the maintenance and usability of those fits your
shop's needs.

Since there is no index, I expect that the performance of a lookup in a
32K-entry table would struggle to keep up with a similar CHAIN. Not to
mention the impact that such lookup has on the other processes on the
system. For anything of that volume, I wouldn't hesitate to use data files.
I'd avoid user indexes in general for anything that's somewhat fluid just
because of the maintenance aspect.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
Change is inevitable, except from a vending machine.


We have a number of programs, some in RPG/400 and others in RPG IV,
that
load reference data from various files into arrays in an attempt to
reduce the performance impact of multiple chains to database files.

The trouble with this approach is that the arrays are limited in size,
a
maximum 9,999 elements in RPG/400 and 32,767 elements in RPG IV.

One thought was to use the arrays for the first however many records
would fit and then chain to the database file for the remaining records,
but there's concern about the performance impact of that approach.

An alternative is to make use of user indexes, which could provide a
lot
more space for storing entries, but we're not sure on the performance
impact of that approach.

Does anybody have any knowledge of the performance benefits and
pitfalls
of any of these approaches? What do others do when faced with the same
problem?



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.