I seem to recall that we achieved a “soft” file open/close in RPG
by opening all the files in a CL at the root level of the job and
sharing the ODP. The programs would then issue and OVR
to the version they needed and do their own opens to the
shared ODP.
Having a shared ODP meant quite literally that the file cursor was the
same across multiple programs in the job. Imagine doing a SETLL in
PGMA and then CALL PMB. PGMB does a READ and it gets the first record
pointed to by PGMA.
We definitely did this for performance reasons, but there was a fair
amount of programmer mental overhead. Adding a new file to this
system meant tracing back to where the OPEN happened and adding it
there, too - often in a CLP, or a bespoke RPG program that did nothing
but OPEN and RETURN.
Which reminds me of the other half of those ancient times. RETURN
with LR OFF. RPG does an initialisation of all sorts of things when
it starts up. We all know and love this. Well, if we CALL PGMB which
does a RETURN, and then CALL PGMB again, the RPG runtime will detect
that LR was not on and will skip most of the initialisation. The
point of that is that this is code which does not run thousands and
thousands of times. The Dark Side is that you, the RPG programmer,
need to be very, very careful about /assuming/ the program variables
are reset between CALLs.
If you're thinking about this (and I regret that I am even mentioning
it) then make sure you are running in a single named activation group.
*NEW is not a performance enhancer. There's nothing wrong with *NEW
don't take this as a blanket recommendation to eliminate it - but if
you want to wring every millisecond out of a job, don't use *NEW.
There is one other ancient technique that we used to use back when
terminals were actual 5250 devices the size of a small refrigerator:
FMTSLR. The idea was to create a logical file that had multiple
record formats, typically an order header, detail and total. Just
like program described files <shudder>. The format selector was an
additional program one would write which would tell data management
which of those record formats to write to.
If it were my system and I was the lord of all I survey, I'd use
Mark's technique of a 'router' and offload the actual I/O to one or
more asynchronous processes. But I've never been in that position,
and you may not be either.
Which brings me to the most important idea of all. MEASURE FIRST.
Blindly poking at performance problems often results in more
performance problems. Measure the process, analyse the stats, and
take action based on them. Someone's gut feeling that it's an
OPEN/CLOSE problem may be in the same league as someone's idea to
simply duplicate the files instead of adding another key. You are FAR
more likely to fix the actual performance problem if you identify it.
It could be something as simple as allocating more memory to a
subsystem now that the volume and number of files has grown...
--buck
midrange.com
