×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hi David,
<snip>
I would also prefer 2 procedures. But in Ken's example, the code that is set is a variable that is local to the procedure. Surely that is an advantage compared to using a global variable.
</snip>
Why is using a static local variable an advantage to using a global variable?
From your original post you have the following:
1) A module which manages a customer screen - behaves differently for different transaction of the customer
2) A procedure in the module which needs to be aware of a transaction code. This procedure is used by many other procedures and an optional parameter is ruled out for design reason.
(at this point I am unaware of whether the procedure is exported outside the module AND/OR whether the many procedures that call it are internal/external to the module)
3) You decided to set a global variable to hold the transaction code and let the procedure inspect that value and perform various activities based on the value (setting display indicators)
It seems to me that the transaction code forms part of the state of the module and should therefore be visible to all code running in the module. Also, as you are setting global display indicators to these values I'm not sure what you gain by keeping the values local to a procedure. Do they need to be kept secret from the rest of the module, only to be revealed as values of global indicators anyway?
If you feel the transaction code does NOT form part of the state of the module then please don't create a GetSetInitView procedure to manage it as a local static variable. You could consider using ANOTHER module. You would store the variable as a global variable in that module and provide various procedures to Get/Set/Init/View the value held there. The variable is now only viewable by your procedures designed to work with it. You could go further and place ALL transaction code related variables and accessor/mutator procedures in this module. Further still, you could wrap it in a service program and call it TRANSCODE. That way you have an object that represents the transaction code, all of its associated attributes, and all of its functions.
Got to be better than using local static variables and horribly disfigured procedures for this.
Of course, just MHO.
Cheers
Larry Ducie
_________________________________________________________________
Take a peek at other people's pay and perks Check out The Great Australian Pay Check
http://clk.atdmt.com/NMN/go/157639755/direct/01/
midrange.com
