Re: Subprocedures and files (was: Procedures are FUN!)

My comments inline.

"Mackie, Roger L. (Precision Press)" wrote:
>
> ...
> From what I heard at last fall's COMMON, this is my explanation of what
> happened (subject to correction by someone who really knows what's going
> on):
> A. The main program performed an implicit OPEN of the file in activation
> group QILE. That means an access path to the file was 1) created and 2)
> opened in the activation group.

Correct.

> B. When the NOMAIN module was initialized, it detected the open access path
> and did not create and open one of its own. When the USROPN keyword was used
> on the file, the %OPEN() BIF correctly found the open access path to the
> file. If the file had been closed, the %OPEN BIF would have failed. But the
> OPEN opcode would not have to re-create the access path. It would only need
> to flag it as open (usable).

That would only happen if the file was shared.  Otherwise, you would get
a new ODP (open access path).

> C. The unconditioned CLOSE flagged the activation group's access path as
> closed, but did not destroy/reclaim it.

Only if the file was shared.

> D. When the main program tried to used the activation group's access path,
> the system reported it as closed and the CHAIN failed, even though the
> access path still existed in the activation group.
>
> Because of this behavior, the programmers I learned ILE techniques from
> never closed files in NOMAIN modules. But the Boy Scouts taught me to clean
> up after myself, so I like to do it when possible. If I open the file, I
> close the file. But I dare not close it if it was open in the activation
> group already.

Something else must have been happening.  The problem you describe
normally happens when a service program running in *CALLER leaves a file
open and then a RCLRSC is done.  This closes the file but the service
program's storage doesn't get reset (the problem doesn't occur for
programs).

>
> And what about performance? One of the great benefits of subprocedures is
> the fact that once called, they exist in the activation group until the job
> ends or the activation group is reclaimed. Initialization only needs to take
> place once. If opening and closing a file in a NOMAIN module required the
> access path to be re-created in the activation group every time a
> subprocedure opened it, IBM's suggestion that you close files in NOMAIN
> modules would cause severe performance penalties. However, if closing the
> access path does not destroy it but merely sets a bit somewhere, then
> opening it again just means flipping the value of the bit. The expected
> performance penalty would be relatively small. And the performance gain over
> the traditional call to an outside program is still very noticeable.

The message about closing files doesn't mean they should be closed on
each subprocedure call.  The only point of that message (I know because
I wrote the message) is to make the programmer aware that there's no way
for the file opened by the module to ever be closed.  That may or may
not be a problem.

> ...

Barbara Morris