Hi, Joe:
This is indeed the $64,000 question in application design.
I recall many years ago, after coming over to AS/400 from IBM
mainframes, while attending COMMON, I asked one of the Rochester
developers if the overhead for a file OPEN was comparable to that of
OPEN on the IBM mainframes, e.g. on MVS, it was about a million
instructions to open each file. His answer was "Yes." (That was on the
CISC IMPI machines, so it is probably many more RISC instructions now,
but they run faster.) Suffice to say, OPENs are "expensive", while
exiting with *INLR = *OFF is not that bad -- that just leaves a bunch of
"resources" (open data paths, buffers, etc.) allocated in virtual
storage. In the worst case, if the user waits a long time before
revisiting that menu option, those pages containing those resources all
get paged out, so the next time the user chooses that option, it may
take a while for that stuff to get paged into real main storage again.
This is not such a big deal on i5/OS or OS/400, due to the vast address
space available with single-level storage, and the much larger real main
storage sizes we see today, as compared with MVS of old, where the
address space was limited to 24-bit or 31-bit addressing. Of course, a
possible "down-side" to leaving many files open is that there are
"locks" on the files, so if you needed to perform certain operations on
those files, you cannot do it while any users actively have those files
"open." (There is always some trade-off or compromise, it seems...)
If it was my shop or my decision, I would try something like this first.
1. ensure that each top-level RPGLE program always returns with *INLR =
*ON (so that it closes all files, etc.) and specify ACTGRP(*NEW) as was
suggested previously. That way, each time the program exits, the AG gets
cleaned up. Then see if any users complain about the extra time it
takes when they return to a menu option they have visited recently.
2. if many users complain, then you could change the above to
ACTGRP(named) and set *INLR = *OFF. Then, you leave everything open, as
you are doing now.
2.(a) you might even want to replace those "top-level" programs with
small CL programs that call the previous "top level" program, and on
return, it could pop-up a window to ask the user if they plan to re-use
this menu option within the next 5 minutes. If they answer "No", it
could then issue RCLACTGRP ACTGRP(name) ...?
(This lets the user decide whether to leave the files open or not.)
That's my opinion; what's yours? ;-)
Mark
> Joe D wrote:
(do you really want to close the AG each time the user exits to the main menu? maybe, but maybe not?)
This is the million dollar question for me right now.
I had a user who was sitting on the main menu screen (no app other than menu
running) but had over 500 open files. Most of the files listed actually had
multiple instances listed - one logical file I counted was listed 21 times.
I am assuming he built up to this number of open files through the course of
the day and a dozen or more application calls, but the number seems extreme
no matter how long it took him to reach it.
These open files may make it quicker for him to go back into Order Inquiry,
for example, but at what point do all the open files start affecting system
performance for the user or all users? Or do these open files NOT really
affect system performance that much?
midrange.com
