|
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 +---
As an Amazon Associate we earn from qualifying purchases.
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.