Re: A different kind of persistence?

[Barbara Morris <bmorris@xxxxxxxxxx>]

Dane Cox wrote:
> 
> Okay, let me see if I can reply to all of these in the same e-mail...but
> first a little more detail.  I thought I had enough, but apparently I am
> not using terminology the way that some others are...

I'm sure most of what I'll say here has already been said in this thread
or another related one; sorry for any duplication.

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

No.  The only way that would be true is if the *PGM is in the *NEW
activation group.  When the program returns (not necessarily when it
sets on LR), its activation group ends.  It would also be true for a
DFTACTGRP(*YES) program, but in that case you could not have any
submodules.

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

When a program or service program is an activation group that persists
(not *NEW), its storage persists in memory until the activation group is
destroyed.  How the storage is reinitialized is up to the application
(from the system's point of view).  From RPG's point of view, the
storage is reinitialized in any given module according to the RPG
cycle.  If you have a NOMAIN module, it is never reinitialized by RPG.

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

LR only has an impact on the variables in the same module as the LR.  If
a variable is exported, it is not affected by LR.

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

The variables aren't global to the activation group.  They are global to
the module, in static storage (all RPG global variables are static, but
anyway non-static variables can't be accessed by other procedures). 
Variables in static storage are initialized once by the system, and
never again.  They may be initialized further by RPG due to the RPG
cycle in that module.

I-spec fields are not local variables, so the concept of local variables
doesn't apply to them.  If you want to use a local variable, specify the
variable as a result field in your I/O statement (supported for
externally-described record formats starting in V5R2, also
externally-described files starting in V5R3.)