We have some old RPGIII that are using arrays instead of files.
These programs are used by a lot of different applications and can
be called many times by the same program. The programs in question
load a file into an array in the INZSR, then each time the program
is called, it's the array that is searched instead of the file.
Apparently, this is or was supposed to be quicker. The program
however, needs to be maintained as eventually the arrays get
overfilled as records get added to the file.
Is this kind of thing justified? If not, was it ever?
Yes - it most always will be justified but only you can compute the pain/gain
equation.
We've written a couple of articles related to this topic you can find them
here (
http://tinyurl.com/pk7ref and here
http://tinyurl.com/qxa4x4) it
includes some simple timing tests.
One thing you might think about - if the look up is being used by multiple
jobs, then the array could be loaded into a User Space so that it would not
increase the memory usage and the space would only have to be loaded (say)
once a day. All your code has to do is get the pointer. Assuming that the
file does not change frequently during the day, this would further reduce the
run time of the programs that use it since the build occurs only once a day.
In some case I have had a completely separate program build these arrays in
User Spaces and then used bsearch to search them. using bsearch means that the
array can grow dynamically since I never have to actually define it to RPG as
an array - just as a based field. The RPG Redbook "Who Knew You Could ..."
contains examples of bsearch.
In the past I've used the technique to significantly reduce as customer's
batch run times. Maintenance is admittedly a little more than for a simple
CHAIN in that as you note you have to update the maximum array size from time
to time but if you use %Lookup and limit the search to active elements and
make sure to use the ASCEND keyword on the array the look up speed is very
fast 'cos a binary search is performed.
Don't forget that even if you use SETOBJACC that all you have done is saved
the system from retrieving the data from disk (assuming it is still in real
memory). The code path length will still be far longer for a CHAIN than a
%LookUp because you are still going through all of the I/O routines.
Most batch routines are I/O bound not CPU - so making it a memory look up
removes it from the I/O stream and moves it to a CPU load.
Jon Paris
Partner400
www.Partner400.com
midrange.com
