RE: A different kind of persistence?

Wow, thanks everybody for the information.  This has been quite
educational!  I do have one more observation/question if you'll bear
with me a little longer...

Let's take this scenario one step further and say that I have a second
RPGLE 'main' program that is bound to the same 'nomain' module exactly
the same way as the first and that the program is called from the same
'batch' job.  It is also compiled with the same options as the first.
In other words, same everything except program name (and likely
different internal functionality).

Does this second program create a different 'instance' of the module for
its own use, or will it use the one that is already resident in the AG?

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Monday, January 10, 2005 3:51 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: A different kind of persistence?

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

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




NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information. Any unauthorized review, use, printing, saving, 
copying, disclosure or distribution is strictly prohibited. If you have 
received this message in error, please immediately advise the sender by reply 
email and delete all copies.