RE: Scope of variables and subprocedures. -- RPG400-L

>>I can still put them in separate modules, but group them together into a
single service program

My apologies for not mentioning that I already make heavy use of modules in
all my ILE RPG programming. I break down and group together all functions by
module for just the reason that you stated. That is the reason for the
breaking down of the various screens per module. This lets me isolate all
the logic for one type of screen in one module. I use the same concept in
building my common functions library

XVSYSC
    XVSYSC_R01  Error Handling.
    XVSYSC_R02  String Handling.
    XVSYSC_R03  Message Functions.
    XVSYSC_R06  Modulus Functions.

I fully realize that is the reason IBM included the module to give us a way
to separate functions but there are still times where it doesn't make sense
logically to put stuff into a separate modules. It just would make it a lot
simpler if we could nest the procedures and give them scope to variables in
the main procedure.  

Part of the reason that I wrote the message was to see if there was another
solution in terms of coding the functions. I have the vague feeling
something is not right in my design but can't isolate it. Just wondered if
others had a way to logically design the module to avoid the problem.

>> Also, I'm wondering why you're taking the solution of using
>> subroutines instead of using subprocedures with global variables?

Time and simplicity in the beginning. We had code in subroutines and it was
easier at the time to use subroutines. Also, less resistance from other
programmers. Am in the process of trying to convert some of the code into
straight subprocedures and eliminate all subroutines which is what prompted
the questions and I agree with about the flaws of a subroutine. I end up
with a big procedure with a lot of subroutines and I have the same problems
with having dozens of variables and having to worry about changes to them
all which is why I don't like using them as I indicated in my message. 


-----Original Message-----
From: Scott Klement [mailto:infosys@klements.com]
Sent: Sunday, December 12, 1999 7:56 PM
To: RPG400-L@midrange.com
Subject: Re: Scope of variables and subprocedures.


Hi Alan,

I've also run into this situation.  What I've started doing is putting
the procedures that need to share data amongst themselves into a
module by themselves.  Then, I can declare any variables that need
to be shared across the procedures as "global", but since they're
the only procedures in the module, I don't have to worry about other
procedures attempting to change them.

Of course, if I have many related procedures that I don't want to
have exposure to the variables, I can still put them in seperate
modules, but group them together into a single service program, and
by creating source code to tell the CRTSRVPGM what exports I want,
I can also make procedures available across modules without opening
them up to the outside programs.

I agree that something in-between "global" and "local" for variables
would be quite useful...   Maybe we'll see that in a future version?

Also, I'm wondering why you're taking the solution of using
subroutines instead of using subprocedures with global variables?
It seems to me that subroutines will have the same flaws of having
to retest your entire program (instead of just a sub proc) so why
give up all of the OTHER advantages of subprocedures?

HTH

Alan Campin <Alan.Campin@CaseLogic.com> wrote:
>
> Sorry for the length of this message. Don't know how to layout the
>  problem without this detail.
>
> I keep running into the same problems using ILE RPG and subprocedure
>  and I am hoping that folks might have some suggestions, although I
>  feel that this is just an inherent flaw in ILE RPG.
>
> The problem concerns the scope of variables. In language like "C" or
>  "Java" or "Pascal", I can do the following:
>
> Procedure A
>     Start
>            Variable X1
>            Variable Y1
>            Procedure B
>               Start
>                   Variable B1
>                   ...
>               End
>            Procedure C
>               Start
>                   Variable C1
>                   ...
>               End
>            ....
>     End
>
> In this example, any variable B1 can only be seen inside procedure B
>  and variable C1 can only be seen inside C. But variable X1 and Y1
>  can be seen inside of procedure A and, also, by procedures B and C.
>  Procedures B and C are considered to be nested in procedure A and
>  procedures B and C have scope to any variables in A.  In a language
>  Java, you can nest classes
>
> In ILE RPG, I would have to do it like this.
>
> Procedure A
>   Start
>      Variable X
>      Variable Y
>      ...
>   End
> Procedure B
>  Start
>      Variable B1
>       ...
>  End
>  Procedure C
>    Start
>       Variable C1
>        ...
>     End
>
> Why is this a problem? In a simple example, I build all my screens
>  using multiple modules. One module per screen.
>
>   EX0001  Top level - Just calls the first screen and then shuts dow
>  each screen.
>      EX0001_R01 - First screen.
>      EX0001_R02 - Second screen.
>
> Each Rxx module has at least two procedures. ProcessScreenNN and
> CloseScreenNN where NN is a screen number 01 to 99 so ProcessScreen0
>  does all the processing for one screen and say, for example,
>  this is a single page load subfile, I would have the following
>  structure
>  ProcessScreen01.
>     Mainline code
>     Functions
>         ClearSubfile
>         PositionInputFile
>         LoadOnePageOfSubFile
>         LoadPreviousPageOfSubfile
>         WriteOneSubfileRecord
>         Get changed records
>         ValidateOneRecord
>           etc.
>
> The problem arises because there are variables declared in procedure
> ProcessScreen01 that are needed to be accessed by the other
>  procedures. An example might be a current count of records loaded
>  to the screen. To get around this, I have three choices that I can
>  see.
>
> 1. Pass every variable needed by anyone of the procedures to each
>       procedure. This quickly breaks down because procedure A
>       calls procedure B which calls procedure C and procedure C
>       needs access to variable in procedure A.  I have to pass
>       procedure variable needed by C to B even if B doesn't need
>       them.
>
> 2. Make any variable needed by different subprocedures global. This
>       solves the problem but now I have opened up the variable
>       to be changed by a procedure in the module, not just the ones
>       I want to give scope to and that defeats the purpose of
>       using subprocedures. If I make a change to the module, how
>       do I know that none of those variables have changed? I end
>       up having to retest everything.
>
> 3. Use subroutines. This works but, again, I have given up all the
>       advantages of using subprocedures. I have to consider the
>       whole procedure rather than just the individual procedures
>       when I am testing and debugging
>
> As I indicated above, in other languages, I could just nest these
>  functions inside of ProcessScreen01 and all the nested procedures
>  would have access to any variables in ProcessScreen01 and no one
>  outside of ProcessScreen01 could change them.
>
> Does anyone else run into this problem? I run into all the time and
>  have both of my programmers Most of the time, we just end up
>  using subroutines but I really dislike that solution.  I want to
>  write everything using subprocedures.
>
> Is there another way to design the program that would avoid this
>  problem?
>
> Does anyone else see the need to nest procedures inside of procedure
>
> Any help would be appreciated.
>
> Alan Campin
> Case Logic, Inc.

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---