× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Scope of variables and subprocedures.
  • From: "Scott Klement" <infosys@xxxxxxxxxxxx>
  • Date: 12 Dec 1999 20:55:30 -0600

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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.