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.