AW: Static and non-static variables in subprocedures

Do you want to define the static variables locally
or could you define global variables instead?
If you can use global variables, you can add an exported procedure
in the same member where your the procedure with the static variables is
located.
This exported procedure does nothing else then reinitializing the global
variables.

If your program ends or at program start or whenever you want,
just call this exported procedure and your variables get reinitialized.

Birgitta
-----Ursprungliche Nachricht-----
Von: rpg400-l-bounces+hauser=sss-software.de@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+hauser=sss-software.de@xxxxxxxxxxxx]Im Auftrag
von Kurt Anderson
Gesendet: Mittwoch, 3. August 2005 17:51
An: RPG programming on the AS400 / iSeries
Betreff: RE: Static and non-static variables in subprocedures


Sorry, hard to find time to reply.
Larry hit it on the head.  The ability to allow local variables to
persist like global variables naturally do.

This would be helpful if I have a procedure that controls the paging
down of a subfile so it could remember what it needs to remember without
me having to pass the values out of the procedure for the sole reason to
pass them back in when the user pages down again.

Hoping for a non activation group answer simply because we aren't
explicitly using them at this time.  If using activation groups is the
only way to do this, then I'll have to consider bringing that up in a
team meeting sometime.

Thanks,

Kurt Anderson
Application Developer
Highsmith Inc

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Larry Ducie
Sent: Wednesday, August 03, 2005 9:53 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Static and non-static variables in subprocedures

Hi Duane,

<snip>
I think what Kurt is saying he wants is a static variable for the life
of the subprocedure no mater which activation group calls it. To do this
your subprocedure would need to be in a service program which has it's
own named activation group. The service program would then be isolated
and the value of the static variable within the subprocedure would be
"static" for the life of the service program's activation group.
</snip>

I think Kurt is alluding to the fact that variables declared as static
within subprocedures are not re-initialised if the program returns with
*INLR on and is called again. This, I believe, is a result of the
program being closed, but not unloaded (it is still active).

The easy way to unload the program (de-activate it) is to end the
activation group the program resides within. Of course, putting the
program in a *NEW activation group does this implicitely. But this is
not what Kurt wants.
Kurt wants the static subprocedure variables to re-initialise each time
the program is closed and re-called (just as global variables are). - At
least I think that's what he wants.

Kurt,

I don't believe there is a standard way to do this as the variables are
only visible within the subprocedure and your prototype is already
defined.

The only way I know is to include an additional (optional) parm to the
subprocedure call which specifies initialisation. OR, make all parms
optional and initialise if you pass nothing.

Such as:

//call as usual...
callProcAsUsual(parm1 :parm2 :parm3);


//call within *inzsr...
callProcAsUsual(*blanks :*blanks :*blanks :initialise); OR
callProcAsUsual();

Cheers

Larry Ducie


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