Re: Array vs file access -- RPG400-L

Your boss is partially correct. Given the Single Level Store (SLS),
the record should still be in memory if you repeatedly chain to it.

However, even with that fact, there's overhead involved in moving the
data from the block of the DB table in memory to your RPG program
buffer and into the RPG program variables. Addition overhead occurs
due to the validation of the data done by the RDBMS each time the
record is read (when the file is DDS defined...for SQL defined files
data is validated once when the file is written).

If you're doing it a significant number of times, you can save
significant time by using the array.

In addition, depending on the memory pool the job runs in and how
often the job is called, you did to remember that the block of memory
containing the DB record could be page out of memory in between
chains. Whereas with the array, if your job (+ array ) is page out
when the job goes to run again the array would already be paged back
in.

I would strong agree that this process is a good candidate for your
first service program.

I would also agree with Rick that a user index may be a better
solution that an array. Though RPG IV uses a binary search to search
a sorted array and is pretty dang fast.

Lastly Set Object Access (SETOBJACC ) is the command Rick mentioned
that moves an object into memory. The way it works is you create a
private memory pool that's not used for running jobs. You use
SETOBJACC to place the object, be it a *FILE or *USRIDX, or whatever
into that private pool and the object will stay there until IPL. Any
job that uses the object will benefit. You can put as many objects in
as will fit in the amount of memory you define for the pool.

HTH,
Charles Wilt

On Wed, Jun 3, 2009 at 5:22 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx> wrote:

Hi all,

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?

The boss is saying that it is not, because repeatedly chaining to the same record by different calls to the program would mean that the record would always be available in memory without having to read from disk. I think that's possible, but no way of knowing for sure. When the program was written, only 50 records were in the file. Now there are more than 800.

For now, I'm going to increase the size of the array in the program that's causing problems. I was thinking, however, that this program would be an ideal candidate for our shop's first ever service program, as all our RPGIV do a bound call to this program via an encapsulating program.

Any thoughts?

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.