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

["Mackie, Roger L. (Precision Press)" <RLMackie@xxxxxxxxxxxxx>]

Barbara,

Thanks for your gentle correction. I still wonder what happened when I
closed a file in the service program and the caller found the file closed.
We don't use RCLRSC, so that couldn't be it. But it's no big deal. I just
won't close files in service programs unless I run into a problem with
leaving them open.

Thanks again for all your contributions,
Roger Mackie

-----Original Message-----
From: Barbara Morris [mailto:bmorris@ca.ibm.com]
Sent: Wednesday, October 16, 2002 11:20
To: rpg400-l@midrange.com
Subject: 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


_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.