RE: A different kind of persistence?

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

The procedure is contained in a very simple 'nomain' module (compiled to
*MODULE object) that is bound by copy to the RPGLE program (*PGM object)
through the use of a binding directory.  The procedure explicitly opens
and closes the file in question.  The RPGLE program that invokes the
procedure does not use the file in question and there are no global
variables with the same names as those in the file.  All RPGLE programs
(*PGM objects) are compiled with the header spec (H actgrp('QILE')).

Now, I am certainly not saying that the way this is coded is the most
correct.  I am simply trying to understand the scope of variables in
this situation.  I need input so I can either change the code and/or use
different methodologies to prevent this type of thing from happening.

So, addressing them in the order in which they have come in...

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?

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.

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?

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?

Thanks for your input so far...more thoughts?

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bob Cozzi
Sent: Monday, January 10, 2005 10:50 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: A different kind of persistence?

Global variables, which are what the input fields of a file are... are
retained in memory until the *SRVPGM or *PGM in which they are stored is
terminated. 
In the case of that procedure being in a *SRVPGM, they are retained
until
the *SRVPGM is reloaded.
In the case of that procedure being in a *PGM they are retained until
that
program is ended with *INLR = *ON. When the program is called again, the
fields (i.e., program storage) are reinitialized. So those input fields
should be empty.
You could always issue a CLEAR opcode to the record format of the file
as
the procedure is being called just to make sure they are empty.
-Bob Cozzi



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Brad Stone
Sent: Monday, January 10, 2005 10:28 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: A different kind of persistence?

The life of the job, yes.. but more specifically, the life
of the activation group (which in your case may be the job,
depending on how you compile your apps).

This shouldn't be an issue, though.  Since you should know
if you don't get a hit on the CHAIN, and not even care
about the values then.  Right?

Brad


On Mon, 10 Jan 2005 08:36:50 -0600
 "Dane Cox" <DCox@xxxxxxxxxxxxx> wrote:
> The last few weeks I have been reading the threads on
> persistence and
> static variables and have actually come across a similar
> but slightly
> different 'issue' that I thought I'd try and get some
> insight on.
>  
> I have an RPGLE program that calls a procedure contained
> in a module.
> The procedure chains to a file and makes a determination
> based on the
> contents of the record being chained to.  The calling
> program (the one
> that calls the RPGLE program just mentioned) uses a job
> running in batch
> to handle its calls.  Therefore, multiple calls are made
> to the RPGLE
> program (and consequently the module) during the life of
> the job.
>  
> The issue is this.  If a chain to the file in the module
> is successful,
> all of the fields from the data file are filled with the
> appropriate
> data.  The module 'returns' to the RPGLE program which
> ends by setting
> LR on.  Now, on any subsequent call to the module (within
> the same job)
> the fields from the data file retain there previous
> values.  Of course,
> once the job is restarted, the variables are
> re-initialized, and there
> is no problem.
>  
> So, fields from files declared and chained to in modules
> retain their
> data for the life of the job?  Is this normal behavior or
> am I just
> missing something?
>  
> Regards,
> Dane
>  
>  
> 
> 
> 
> 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.
> 
> 
> 
> -- 
> 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.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com
-- 
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.




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