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



Leaving LR off is not as important if the main RPG is a NEP that monitors the data queue. But, even if you set on LR, it won't do a full close of the files that were opened using OPNDBF. You will have to use the CLODBF command to do that. Or just let end of job handle it for you. In addition, the RPG will have to do RPG opens and closes of the files with intervening OVRDBF for the switch to occur.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx


-----"Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx> wrote: -----
To: "'RPG programming on the IBM i (AS/400 and iSeries)'" <rpg400-l@xxxxxxxxxxxx>
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
Date: 12/14/2015 01:25PM
Subject: RE: Need ideas to reduce open/close in RPG program


More important is not to set on LR when exiting.
All your files would open one time only when you first call the program, init routine.
Should also NOT be closing the closing the files.

Paul

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vinay Gavankar
Sent: Monday, December 14, 2015 12:49 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: 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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.