Re: Need ideas to reduce open/close in RPG program

So if I were to have a subroutine upfront, which does a OPNDBF for all
files with SHARE(*YES), I could leave rest of my program unchanged?

I have following statements already in the program:

Close FILEA;

CMD = 'OVRDBF FILE(FILEA) TOFILE(*LIBL/' +

FILNAME(S) + ') LVLCHK(*NO) SHARE(*YES)';

CALLP(e) SYSTEM(CMD : %len(CMD) );
OPEN FILEA;

I could leave all these unchanged and my performance would improve?


On Mon, Dec 14, 2015 at 11:33 AM, Mark Murphy/STAR BASE Consulting Inc. <
mmurphy@xxxxxxxxxxxxxxx> wrote:

Try shared opens. Someone started down this path, but didn't quite get to
the end of it. You need a program at the beginning of the process that
reads through and opens each file in your control file with SHARE(*YES).
Leave them all open. Now call your current program, and the only change you
need to make is to set your override to use SHARE(*YES). It will pick up
the already opened file, and though it is closed by the program, the open
data path will stay open for the previous program that is holding all the
files open. The ODP's won't close until all the opens with SHARE(*YES) are
closed. That won't happen until the job ends.

You could probably even do the initial opens within your RPG program, but
you will still have to execute the CL commands OVRDBF SHARE(*YES) and
OPNDBF for each file named in your control file. That will get you open
data paths without having to link them to your RPG file declaration leaving
you free to open and close that as many times as you want.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx


-----Vinay Gavankar <vinaygav@xxxxxxxxx> wrote: -----
To: "RPG programming on the IBM i (AS/400 and iSeries)" <
rpg400-l@xxxxxxxxxxxx>
From: Vinay Gavankar <vinaygav@xxxxxxxxx>
Date: 12/11/2015 06:52PM
Subject: Need ideas to reduce open/close in RPG program


Hi,

We have a program which receives some values thru Data Queue read and it
updates a file with the values received.

The problem is that there are multiple copies of the file it needs to
update.

Let us say it is updating FILEA, so that is what is in the compiled code.

On the system there are currently 15 files which are exact copies of this
file. They have a different file name, but the the same record format name,
field names etc.

The program reads a 'control' file, which has the names of these 15 files.
For every file, it does an OVRDBF of FILEA to the actual file name, Opens
the file, updates/writes the record, and then Closes the File.

The system was built for 'flexibility' years back, when they started with 2
or 3 files. It is flexible, in the sense it did not need a code change as
the files being updated grew from 3 to 15.

This is a very 'busy' program, meaning it is constantly receiving data thru
the data queue. Actually there are multiple copies of this program running
simultaneously receiving data from the same data queue and all of them are
pretty busy.

Now they are finding that all these open/closes are seriously impacting the
CPU usage.

An architectural change is obviously indicated, but that would take time to
implement.

As usual, they are looking for a 'short term', quick and dirty fix (to be
implemented in 2 weeks) to eliminate these open/close.

The only thing we could think of was to define the current 15 files
separately in the program and then update them as needed, losing all
flexibility.

Any other ideas or suggestions would be greatly appreciated.

TIA
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.