× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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?

this is a good example to me that the traditional rpg programming
model of a lot of global variables and reliance on activation groups
is bad programming practice. Much better in my view to use modular
programming methods.  That means declare all variables within the
proc, read and write to database files thru procedure declared data
structs, and pass all persistent variables from proc to proc as
parameters.

As far as activation groups are concerned, I think they just confuse
matters and should be avoided as much as possible.  If you program
modular it should not matter much whether a program is activation
group *new or *caller.  Since it does matter because RPG files are
such non modular, global beasts, I prefer to use activation group
*caller as the default.

-Steve

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.