But isn't that just the start of the answer? What is described here is
the need for a separate module (a very small one, I admit) which has
it's own global, non-exported, variable and at least 2 exported
procedures. One for reset and one for fetching (and perhaps one for
modifying, so additions, subtractions, muliplications, etc.). Bind it to
the program which is using this and voila, your meal is cooked!
That way you have protected the variable from direct access, you don't
have to cleverly lie to the compiler (sorry, divert it from the true
situation) and implement it quite cleanly.
Just thought I'd mention it...
Cor
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: donderdag 7 februari 2008 23:19
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Static Variables in a subprocedure
Ken Sims wrote:
...
Personally I define all such "resetable" variables as global
variables. Most of my service programs have an "open" procedure
(which calls the "reset" procedure), a "reset" procedure, and a
"close" procedure.
If the module is acting as an "abstract data type", where all the
procedures work with the same static data, it makes perfect sense to use
global variables for the data. What you describe sounds like this type
of module.
In the case where a single procedure has some static data that should be
private to the procedure, using a global variable opens up the
possibility that all the procedures in the module can mess with the
data. Physically limiting access to just that one procedure tends to
simplify maintenance. Even though you have to jump through a hoop to be
able to reset the private static data, it's a small and finite hoop.
Figuring out what will be impacted if you change the nature of your
should-be-private-but-is-public static variable can be a large and
infinite hoop.
--
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 e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
midrange.com
