Scope of variables and subprocedures.

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 subprocedures and I
am hoping that folks might have some suggestions, although I feel 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 like 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 down 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 ProcessScreen01 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 so 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 any
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 so have
both of my programmers Most of the time, we just end up using subroutines
but 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 procedures?
 
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
+---