RE: lifetime of a static variable

Hmmm...I'll be darned.  I suppose people would find a way to use it.  As
long as the behavior is consistent, you can work with it.  Whether it gives
the programmer more control than having static variables "go away" when the
main program ends with lr on is something I need to think about. I'd never
gotten the concept of the activation group as a kind of super program.  I
thought of the main program as the highest level for resources allocated by
its invocation.  

The scarier thing for me is the potential consequences of compiling *caller,
which I'll readily admit to having done a lot.    

> -----Original Message-----
> From: Jon.Paris@hal.it [mailto:Jon.Paris@hal.it]
> Sent: Wednesday, November 15, 2000 10:19 AM
> To: RPG400-L@midrange.com
> Subject: RE: lifetime of a static variable
> 
> 
> 
>  >> The question remains, whether or not it was designed to 
> work this way,
> is this the way it ought to work?
> 
> Since by now there are many hundreds (if not thousands) of 
> programs that
> rely on this behavior, the question is somewhat academic 
> since IBM couldn't
> change it even if they wanted to.
> 
> I happen to think that the design is fine.  One of the design 
> points for
> ILE was to give the programmer more control and that's what 
> you have here.
> This behavior is only a "problem" when you are running in the 
> default AG
> where only signing off will get rid of the AG (and hence the 
> variables).
> It is normally recommended that you do not run "real" ILE 
> programs (i.e.
> those using subprocs, service programs, etc.) in the default 
> AG anyway for
> exactly this kind of reason.
> 
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---