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

On 14-Dec-2015 10:33 -0600, Mark Murphy/STAR BASE Consulting Inc. 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.

Exactly what my prototyped example does, and since mine was CLP, doing the OPNDBF _within_ the program was the obvious choice; and although my program had to do one additional shared opn\clo, something the OP would not need to do in the RPG program [though may need to add code to establish desired position], and I still saw an 18% improvement in overall clock-time with an external call to effect that open\position\close, so I expect the OP could see that or better as improvement.

And to explain why that functions, *without* needing to declare each file separately [i.e. just using the same OPEN FILEA each time] as was alluded in the thread, is because the Data Management for the Open processing will search the DMCQ [effectively, the list of open members] for a shared open of the TOFILE.MBR specified on the Override With DataBase File (OVRDBF). Essentially whereas the RPG program determines which file to open and then issues the appropriate override, the DM determines the appropriate file member to open _per that override_; i.e. the proper\desired member is opened, despite the reference to the generic name\label of FILEA.

Having the Share attribute allows the DM to /route/ [QDMROUTE] the open to the QDBSOPEN program [DB Shared-Open] program instead of the routing to the QDBOPEN program [DB Full-Open] program. And IIRC rather than a new entry for the additional shared-open in the DMCQ, i.e. there is not an actual ODP created and thus nor is one tracked there, so the eventual corresponding call to CLOSE FILEA will essentially just decrement the shared-open count that was incremented for the prior shared-open. Thus why the file remains open until the full-close, which for a NEP is either left to a termination handler or the EOJ itself.