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