RE: A different kind of persistence? -- RPG400-L

Bob C. - this was my understanding as well, and the reason I asked the
question.  Since the code in the procedure (*MODULE object) is bound by
copy, once the *PGM sets on LR, the program is no longer resident, and
all storage should be freed...no?

The program remains resident until the activation group ends (unless you're running in OPM compatbility mode -- otherwise known as DFTACTGRP(*YES) )

In fact, you can experience this same symptom with a one-module program by defining static variables in a subprocedure, or EXPORTed global variables. In that case, they also will not be reinitialized by *INLR.

Scott K. - As stated above, not a service program, a simple 'nomain'
module.  The job that is calling the RPG program belongs to IBM and is a
listener job that once connected, stays active until the connection is
terminated.  Therefore, it makes multiple calls (dynamic I presume) from
the same job. It does not submit a new job for each call.  Never
implied that one module should affect another...I was simply trying to
ask the question of why a procedure (within a module that is bound by
copy into a *PGM object that does set on LR) persists any data at all?
I should have been more specific.

*INLR is a per-module thing, and is part of the RPG cycle. Since each module has it's own RPG cycle, *INLR has to be set individually. When the module is defined as NOMAIN, then there is no cycle, and *INLR has no effect whatsoever.

In that case, if you want it to be reinitialized, you have to either end the activation group, or run code in your program, such as the CLEAR or RESET op-code, to initialize it.

Eric D. - yes, I think all of what you stated is accurate.  Named
activation group for all programs (*PGM objects) called from this job.
However, some of your comments contradict those of Bob C's regarding the
persistence of data.  Does LR have no impact on global variables within
an activation group...period, the end?

At a certain point in the RPG cycle, if *INLR=*ON, a flag will be set so that next time the main procedure of the module gets called, all of the global variables will be reset. This only affects that module, only if the module has a main procedure (i.e. NOMAIN is not defined) and does not affect static variables in subprocedures or variables that are exported to the activation group.

For everything else... I had a computer programming teacher who always used to say "Take control of your program, don't let it take control of you." Basically what he meant was, if you explictly code something, you're in control. You know that it'll happen. If you rely on the semantics of the language to do it for you "automatically" then you're giving it control, and leaving yourself open to problems when it doesn't do what you want it to.

The point is... if you want to be sure that the memory gets initialized, code a routine that initializes it.

Steve R. - I don't believe this is an example of traditional or
non-modular programming at all.  All of the variables and files in
question are declared in the procedure (or in the case of the f specs,
at the 'module' level since we still can't declare them within the PI).
So, apparently this fact alone makes file fields global to an activation
group?  This is the part that intrigues and confuses me.

The part that's "traditional" about it is the reliance on *INLR, which is an old-school RPG-only technique to reinitialize storage that's part of a modular program. Frankly, *INLR wasn't designed for this, it was designed for the old, monolithic, programs.

So, are we saying that all input field values from files (accessed by
chain, read, etc.) during program execution within an activation group
are persistent to every procedure that is used by the program in
question?   If so, then what ever happened to the concept of local
variables in procedures?  Does this simply not apply to file input
fields?  Maybe that is why we still can't declare the file spec within
the PI?

Files in RPG have always been global to the module, they've never been local to a subprocedure. You can code a data structure that's local to the module with LIKEREC and read the file into that -- that's much closer to having it be local to the subprocedure (but the ODP is still global!)

Or, if you really want to make it local, you can use the _Ropen(), _Rreadk(), etc routines from the ILE C runtime... that would really make it local, and would give you the ability to have many copies of the same file open at the same time, in different subproedures, without affecting each other.