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

Vinay,

You might try to create a simple "dummy pgm" per file,
That starts a separate activationgroup.
The pgm would do nothing but
- an OVRDBF
- ( an OPNDBF with SHARE , or open the file once in the standard pgm)
- scoped within the activationgroup
- call the standard pgm.
- do not close the file within this standard pgm.

Regards,
Luc

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