RE: A different kind of persistence?

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

> 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.