RE: lifetime of a static variable

[bmorris@xxxxxxxxxx]

>Date: Wed, 15 Nov 2000 08:54:28 -0800
>From: Joel Fritz <JFritz@sharperimage.com>
>
>I'm willing to accept that that's the way it works and code accordingly.
>I'm curious why it was designed that way.  I guess I think of a static
>variable's lifetime in terms of the way I learned about them in C on the
PC
>nearly 10 years ago.  Once the main program ended, all _properly managed_
>memory was returned to the operating system and the static variable
started
>with its initialized value at each call to the main program.

Joel, the default for CRTPGM is *NEW just so that C programs written with
that assumption would port easily to the AS/400.  In the PC environment,
was it even possible to have static storage retained across calls?

I think what you're suggesting is that when a _module_'s (not program)
main procedure returns with LR on, when that main procedure gets called
again, the subprocedure static should get reinitialized along with the
other globals in the module.  Maybe that would have been the right
behaviour, maybe not.  What about calls to the subprocedures between
calls to the main procedure?  Should the subprocedures be reinitialized
even before the main procedure gets called again?

As to whether this is right or wrong, maybe it would have been better to
have different behaviour for subprocedures in a module with a main.  Maybe
the subprocedures' static should have been subject to LR reinitialization.
Or at least non-exported subprocedures.  But then there would have been
different behaviour for a subprocedure in a NOMAIN module.  Our thinking
was that subprocedures are more ILE-ish than RPG-ish, and should behave
like ILE things, and not be subject to the RPG cycle.

By the way, EXPORT fields behave the same way as subprocedure static
fields.
They only get initialized once, independent of LR.

Barbara Morris


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