Hi David,
<snip>
However, I don't know if I appreciate the advantage of a separate module over a static variable.
</snip>
At the end of the day it is a design decision. If you want that variable private, and only accessible via procedure calls then you put it in a separate module. That is the advantage - modules make it EASY to do this. This form of encapsulation is the whole point of the existence of multiple-module objects. Local static variables have their place, but for me this scenario not it. The fact that you have to create a single procedure to handle all processes related to the variable is obviously wrong, and goes against all good design philosophies. Unless you are happy with a function definition as; "This function does EVERYTHING you ever want to do to a Transaction Code - just make sure you set the correct mode flag or it could do ANYTHING!" then you would probably want separate procedures to handle the differing processes you want to do with the Transaction Code. I understand that you can wrap that forsaken procedure in many different procedures - each named correctly and each calling it with different mode flags. If this is good for you - go for it. But it is an expensive work-around. All those procedure you are forced to create you could just put in a new module - you're creating them ANYWAY - and have them just access the variable declared in there. No need for the othe central procedure now. It just goes away.
Also remember that local static variables do NOT get re-initialised on a call following a return with *INLR on, or if your program ends in error. Only global static variables are re-initialised. Your local static variable is out of scope and can only be initialised inside the procedure itself. If your program ends with an error - no dice. You are stuck with the value it was last set (unless you code to cater for it).
Although we are all guilty of comparing RPG with JAVA it is reasonable to consider a module as equivalent to a static class definition, and modules bound into a service program or program object do benefit from the equivalent of package protection (exporting a procedure from the module, and in the case of SRVPGM object not including it in the list of exports).
Its funny, in C++ and JAVA there is no issue in creating another class (module) to define a new entity, together with its variables (state) and accessor/mutator procedures (behaviour). In C, C++, JAVA, and other languages there is no real issue with creating small (<5 lines of code) procedures to perform a simple function. However, in RPG, where we come from a legacy of 10,000+ line programs the thought of breaking things up into multiple modules, each containing several procedures and a few variables, seems like wasted coding time.... "3 modules and 25 procedures??? Geez, I could have written 1,000 MOVEL, MOVE, EXSR and CABxx lines in that time!" :-)
Again, it is all down to design decision. If the Transaction code does not belong as a global variable in your module then putting it as a local static variable in the same module seems like a fudge to me. You want it accessible, but you want it private. Guess what - you need a new module.
(If you use service programs - and I strongly suggest you start using them - you would wrap that module in a service program and any of your code that needs to access the transaction code just binds to the service program. Its as easy as that.)
Cheers
Larry Ducie
_________________________________________________________________
View photos of singles in your area Click Here
http://clk.atdmt.com/NMN/go/150855801/direct/01/
midrange.com
