RE: Are subroutines codependent?

We have made use of import/export declarations to share data across > modules instead of having to pass it

Thanks! This is what I was going to mention - you have to declare a global to *EXPORT for the caller bound program to have access to it.

You could have a global variable in a service program module that is used only in that module but that is accessed by a restricted set of procedures. The idea of Getter and Setter procedures comes to mind, where you can "emulate only" this idea borrowed from the OO type languages. NOT THE SAME I know but...

You could still eliminate that kind of global variable altogether with another technique I have put to good use:

You can also emulate the idea of setter/getter by using a third GetOrSet() procedure where GetOrSet() has an optional parameter. If it's only one stand-alone value, for example, you can have just one parameter and a return value.

If the parameter is received, then use the variable to SET the value to a local STATIC variable inside the procedure.

If the parameter is NOT received, then use the variable to GET the value FROM a local STATIC variable inside the procedure.

Thanks for sharing.

Alan

-----Original Message-----
Chris Holko
Sent: Tuesday, July 08, 2014 10:03 AM

We have made use of import/export declarations to share data across
modules instead of having to pass it

Sent from my iPhone

On Jul 8, 2014, at 9:57 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>

wrote:

If I may expand on this - I think that global variables are useful for things

that are used everywhere. An alternative is to pass them as parameters to
every procedure - this can get a bit cumbersome - so one makes one's
choice.

The challenge with globals as I see it is to be sure that there are no side

effects - that once set, they are pretty static. Or at least very carefully
managed - that has always been a challenge with subroutines.

Now for a utility procedure - with a specific purpose - everything could and

perhaps should be done using parameters and local variables and maybe a
return value.

JMHO
Vern

On 7/8/2014 8:48 AM, Henrik Rützou wrote:
Buck

this is very easy - take middleware service programs as CGIDEV2,
HTTPAPI or powerEXT. They all have a lot of subprocedures that shares
global variables within the service program and general storage
allocations otherwise they could not run.

On Tue, Jul 8, 2014 at 3:22 PM, Buck Calabro <kc2hiz@xxxxxxxxx>

wrote:

On 7/8/2014 4:46 AM, D*B wrote:
Additinal note:
global data and coupling procedures by global data is not bad design!
Bad design is to define data global, which is needed only local!!!

Hi Dieter,
This surprises me, which means I probably do not understand what you
mean. Could you please give an example of good design that couples
subprocedures with global variables?
--buck
--
This is the RPG programming on the IBM i (AS/400 and 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 is the RPG programming on the IBM i (AS/400 and 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 is the RPG programming on the IBM i (AS/400 and 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.

--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------