I don't' really know what the programs David works on pertain to, but there is another purpose of Static.
In my environment, we process millions of records in batch. A procedure could then be called a million times or more within the life of a job. There are times when I will make local variables static so all the stuff that happens under the covers for a non-static local variable every time the procedure is called won't have to happen. I only do this when the procedure doesn't rely on the procedure to initialize the variable (i.e. the procedure will always set the value of the local variable in the calc specs (generally condition-based) before it is used).
-Kurt Anderson
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Tuesday, January 26, 2010 11:36 AM
To: RPG programming on the IBM i / System i
Subject: Re: Correct use of STATIC variables
David
Think of this scenario -
Let's say your procedure receives a number and adds it to a subtotal.
The subtotal is your static variable. Your procedure adds the passed
value to the subtotal and returns.
Now let's say you need to start a new subtotal? How do you do this?
Well, you can't from the outside, directly, because the static variable
is local to the procedure - it is not visible outside of the procedure.
So you have to tell the procedure to initialize it.
RCLRSC is definitely NOT the way to do this - it might have worked in
OPM and would still do, but it is not my idea of good programming technique.
I can get mixed up in this stuff, too, so it is always worthwhile to
review things like scope and lifetime and visibility where variables are
concerned. Those are terms in common usage, I believe. Here's what I
understand about things in RPG, and, I believe, Pascal.
Global variables are static - they exist for the life of the module call
and keep their values between calls (unless LR is set where that
matters). They are visible throughout the module, including procedures,
unless hidden by a variable of the same name in a procedure.
Local variables (not static) are automatic - they exist only so long as
the procedure is active. They are reinitialized the next time the
procedure is called. They are visible only within the procedure -
nothing outside the procedure can see them, therefore, cannot modify them.
Local variables (static) are static - they exist for the life of the
procedure call and keep their values between calls. They are not
reinitialized the next time the procedure is called. They are visible
only within the procedure - nothing outside the procedure can see them,
therefore, cannot modify them.
As to returning without performing the normal task - no, I would not do
that - I would say, do what is done the first time - initialize the
static value and process it in whatever way is done. If building a
subtotal, add the passed value to 0.
HTH
Vern
David FOXWELL wrote:
-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Birgitta Hauser
In this situations I use an optional parameter (simply an
indicator). If this parameter is passed, the static variables
first get initialized.
At the first call, I pass the optional parameter (with *ON)
and for all subsequent the parameter is either not passed or
passed with *OFF.
Hi Birgitta,
Does that mean you have to call all your subprocedures that contain static variables and include code in each subprocedure so that it behaves differently, ie, it initializes the variables then returns without performing its normal task?
midrange.com
