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



Seems to me the bigger issue is opening the file every time - that's probably the most expensive part of this.

Once loaded into memory, the records do stay until paged out for some other process. It is possible to preload things using the SETOBJACC command - best practice is to have a fixed pool that is never used for running any jobs - then the file will not be paged out. It seems the file is not the large, so this might be a reasonable application of this technique.

As to the file opens, I'm thinking of a NEP - never-ending-program - that might wait on a file or data queue with requests to get data - this would open the file once, then take requests with the same content as you use now, maybe. You'd be changing all the programs, anyhow, so why not go all the way?

I love making work for other people!!!

Actually, the question is, how many programs are involved? David, you mention some that are called by several applications - these would be the ones to change - keep their interface, just change how they do things. This is basic object-oriented design.

HTH
Vern

Rick.Chevalier@xxxxxxxxxxxxxxx wrote:
David,

Two things come to mind.

First, there have been numerous posts in the past about loading an entire file into memory. I have never done it and don't remember the command but you could probably find something in the archives.

Second, you might consider a user index. It functions like a file but access is faster. Instead of loading into an array load into the user index. As long as you don't exceed the maximum size of an index the number of entries doesn't matter. Check out the user index API's in the IBM documentation web site.

Rick

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of David FOXWELL
Sent: Wednesday, June 03, 2009 4:22 AM
To: RPG programming on the IBM i / System i
Subject: Array vs file access

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.



Privileged and Confidential. This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information. If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail. You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.