On Aug 4, 2010, at 1:00 PM, rpg400-l-request@xxxxxxxxxxxx wrote:
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.
In the case of RPG IV this is no longer true as of V6.1. For that
matter it was only true prior to V6.1 if you actually defined the
arrays to RPG. If you just use a User Space or dynamic memory and
qsort/bsearch this is not an issue.
For conventional RPG arrays _the_ critical factor is coding the ASCEND
(or DESCEND) keyword. With these in place %LookUp will do a binary
search and is very fast - faster than bsearch. Of course you do have
to be sure that the array is in the sequence you said <grin>. It is
the old LOOKUP op-code (and %lookup in cases without an ASC/DECend
keyword) that has poor performance.
In tests I have run, the array approach outperforms a CHAIN or SETLL
by many orders of magnitude. In one set of tests the difference was in
excess of 10,000 to 1 and that is 1) after including the time to load
the array _and_ 2) comparing against a CHAIN scenario where SETOBJACC
had been used on the file. Remember when comparing the SETOBJACC
scenario that by using that most of what you save is the physical disk
reads. The path length through the I/O system is still fairly lengthy.
One approach that I have used in the past is to place the array in a
User Space. Every time that you get a "miss" then CHAIN to the file.
If found by CHAIN add it to an array of "updates" for the User Space
array. At the end of the batch job add the updates to the end of the
array and sort it. This avoids the overhead of having to load the
array each day and ensures that your most frequently used products/
customers/codes are present in the array. Now it is ready for the next
day. If you can prime the array by running a quick analysis over the
last few days transactions you're ahead of the game.
Jon Paris
www.Partner400.com
www.SystemiDeveloper.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.