Re: MAIN or cycleless programs.

Hi, David:

Rather than passing a single field, e.g. "ClientID" (that might be the "key" to a row in a Clients table), it might be better if the program reads that entire row or record into a data structure, and then passes that data structure, e.g. "ClientDS" (or just "Client") instead of passing only the key. That way, you do not need to use any global variables, and each of those procedures has access to all of the relevant attributes for the client (fields in the record or columns in the row), without having to pass any additional parameters. This would be closer to an "object oriented" design, where each "object" is represented by a data structure, and these procedures represent the methods that act upon those objects.

Also, I think some use of global variables within the same compilation unit is acceptable. Extra care should be taken when using "global" variables across multiple compilation units (*MODULEs).

In the example, as long as "sp1", "sp2" and "sp3" are all procedures within the same source member, and so, by necessity, must be compiled together as a unit, then some global variables shared across these procedures is probably not as bad, because you have the complete cross-reference in the compiler listing, that shows where all such "global variables" are used and set.

See also "Global Variables Considered Harmful" by W. Wolf and M. Shaw in ACM SIGPLAN Notices, Vol.8, Issue 2, pp. 28-34, Feb. 1973.

All the best,

Mark S. Waterbury

> On 11/8/2010 9:25 AM, David FOXWELL wrote:

Hi Vern,

In my experience, when I start passing parameters to internal subprocedures I end up with something like this

Main
ClientID

CALLP sp1(clientID)
call sp2(clientID)
Call sp3 (clientID)

Sod's law states that one day SP3 will need another variable only known to the main procedure, so you have to modify all the interfaces and prototypes for a subprocedure that isn't even exported.

Now if as well, clientID is used in the main procedure to acces a client file and populate a display file and you don't use a local file, then all the sp's have access to all the client information via the global dspf fields. Someone else will always come along and use the client name or something in a subprocedure by simply using the information on the screen instead of passing it via a parameter.

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Vern Hamberg
Envoyé : lundi 8 novembre 2010 14:48
À : RPG programming on the IBM i / System i
Objet : Re: MAIN or cycleless programs.

David

You can still have all the global variables you want - just
declare them outside any subprocedure (other than the default
procedure, which you do not have when using the MAIN keyword)
- you still have D-specs you can write ABOVE any
subprocedures - all that stuff will be global.

If you don't have the MAIN keyword in the H-spec, you have a
regular program or service program with the cycle. MAIN does
2 things, so far as I can tell.

Now should you use global variables? There might be one or
two situations where RPG requires it - seems I ran into
something recently but can't remember what it was. Otherwise,
well, it's a good idea to avoid globals variables as much as
possible. Instead, yes, you pass parameters.

If you keep wanting to have globals available to all
subprocedures, hey, you might as well forget procedures
altogether and go back to subroutines. They don't have local
variables, right? With all the attendant possible problems of
unexpected side effects that local variables and parameters avoid.

So to your question - yes, you could get something similar
this way - by declaring a global client ID above and outside
any procedures with P-specs, like this.

d gClientID s like(dfg)

P myprocedure B
d PI
D pClientID const like(dfq)

If initializedOK;
gClientID = pClientID;
DoStuff();

EndIF

P myprocedure E

I still prefer passing it along as needed. And for other
things you need to pass along that are not parameters, you'd
set them up in myprocedure, then pass them along. Yes, you
COULD use globals, again, but I would try to avoid it.

Things are more self-documenting, too, with parameters. IMHO
And I honestly think that globals are a trap we are
comfortable with because we have had subroutines all these
years. Gotta get outta the tender trap!

Now if only the subroutine support in CL had locals!!

Vern

On 11/8/2010 4:18 AM, David FOXWELL wrote:

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Alan Campin

I am not clear on what you mean by a main procedure. You

do a have a

main procedure. If you are saying you miss writing

monolith programs,

can't agree with you there. I hate monolith programs.

I mean that if I have MAIN(myprocedure) then myprocedure is

the main procedure. Without the MAIN keyword in the main
procedure, the parameters are global. I don't (at least I
think) do monoliths, either, so I have a lot of internal
procedures which are basically just cutting up the code into sections.

So in the main procedure I'll have something like :

P myprocedure B
d PI
D ClientID const like(dfq)

If initializedOK;
DoStuff ( ClientID );

EndIF

P myprocedure E


Using MAIN means I now have to define and pass ClientID to

all the internal procedures whereas without MAIN, all the
procedures can access ClientID. Some of the procedures are
just receiving clientID so they can pass it to another
subprocedure. It would seem to me that as the function of the
program is to treat one client and one client only, then it
would be normal that this was a global variable.

--
This is the RPG programming on the IBM i / System i
(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.