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

See below. It's a long post, so don't bother to read it unless you're
interested in the answers to Buck's questions.

-----Original Message-----
From: Buck Calabro [mailto:Buck.Calabro@commsoft.net]
Sent: Tuesday, October 15, 2002 14:33
To: rpg400-l@midrange.com
Subject: RE: Subprocedures and files (was: Procedures are FUN!)

<snip>

This sounds interesting.  Sounds like a shared ODP situation.  I can't see
any other way this situation can occur (file left open in the AG after one
program has closed it).

<snip>

Is this a SHARE(*YES) environment or are we talking about the IF %OPEN()
test reporting the wrong state?

<snip>

Buck & All,

Oh bother! This bear of little brain crafted an explanation that gave the
opposite impression of what happened to me (probably because I totally
misunderstood what happened to Joe). But let's try again with more detail.
The situation was not a shared ODP. We do not use SHARE(*YES). The %OPEN()
BIF worked just fine.

We manufacture custom printed products. Many of the programs in our legacy
system have been converted from RPG II to RPG III and the RPG IV with very
little change (we still deal with GOTO/TAG loops). We would like to modify
all the code using newest techniques, but resources are limited, so we can
only do so when something is broken or something needs to be added. Since we
never use SHARE(*YES), we decided to put *DFTACTGRP(*NO) in the H-specs of
every mainline program that uses ILE subprocedures so they run in named
activation group 'QILE'. Every service program is compiled using (*CALLER).

Sometimes characteristics (paper colors, ink colors, etc) of one job
determine what is valid for another job in the same order. Checking the
characteristics of both jobs at the same time led the legacy programmers to
CHAIN back and forth, to the great confusion of this bear of little brain.
"Which job is in this record format now?" and "Which file is the data in
this field from?" (because little file prefixing was done) were my constant
questions while changing our job entry program.

To remove a little of the confusion, I moved a specific verification
function out of the monolithic legacy code into a service program compiled
from its own module. That service program needed to use a file already open
in the job entry program. But it did not replace every use of that file.
Using an implicit open in the NOMAIN module caused no problems. Leaving the
file open after a conditioned OPEN also caused no problems. But when I tried
to get rid of the compiler warning message ("File xxxxxxx should be closed
when used in a NOMAIN module" or something like that) by coding an
unconditional CLOSE, the function would complete successfully. However, the
next time the main program tried to access the file, a "file not open"
run-time error resulted. The code I shared earlier in the thread solves that
problem.

>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.
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).
C. The unconditioned CLOSE flagged the activation group's access path as
closed, but did not destroy/reclaim it.
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.

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.

That seems to be our experience. But most of our programs work in an
interactive green-screen environment. We have not tried to apply it to batch
programs yet. Before we put a batch program using service program file I/O
into production, we would want to do some performance benchmarking. If
anyone has already done it, or has time to do it, I'd be interested in the
results.

I hope this makes more sense and saves someone some digging. Despite the
pain of learning how to use them effectively, Joe is right. Subprocedures
are FUN! I'd better wrap this up so we can all go code some more!

Roger Mackie