Guru: Procedure Driven RPG Means Keeping Your Variables Local
November 6, 2023 Gregory Simmons
One of the things I love most about procedure driven RPG is that it allows me to keep my variables locally defined. Imagine this horror story that happens all too often in RPG shops.
Jake: “Hey Gregory, Accounting just called; seems the rebalancing report program is acting up. Didn’t I hear you were working on that the other day?”
Me: “Ugh, yes. All I had to do was reset this field that was used to show or not show the totaling line between branches. I tested in my library and the fix worked fine.”
Jake: “Yeah, I had to change that program last month. That program is a beast. What’s worse is it’s called the ‘rebalancing report program,’ but it does a lot more than that. And there’s a ton of global variables.”
Well, I’ll spare you the gory details, but the lesson here was that the variable he used was also used in other subroutines that had nothing to do with the report.
Using local variables means that the variables you define inside your procedure are only visible/usable inside that procedure. Thus, you cannot accidentally reference variables inside a procedure in any place other than in that procedure. As was the cause of the horror story from above.
1 **FREE 2 dcl-proc calculateTotalDue; 3 dcl-s totalDue packed(10:2); 4 dcl-s i int(3); 5 dcl-s itemPrice packed(10:2); 6 dcl-s quantity packed(5); 7 for i = 1 to 100; 8 itemPrice = getPrice(i); 9 quantity = getQuantity(i); 10 totalDue += itemPrice * quantity; 11 endfor; 12 return totalDue; 13 end-proc calculateTotalDue;
In this example, the variables itemPrice and quantity are declared locally within the procedure calculateTotalDue. This means that the values of these variables are stored in the procedure’s stack frame and do not need to be copied from the heap each time the procedure is called. This can improve performance, especially if the procedure is called frequently.
It is important to note that using global variables can make code more difficult to read and maintain. This is because global variables can be accessed from anywhere in the program, which can make it difficult to track where the variables are being used and modified. Therefore, it is important to use global variables sparingly and only when necessary.
That said, there is a time and a place for global variables. For example, I only use global variables in situations where I will initialize those variables when the program starts up or when the program resets. Another good use case for a global variable is when I have a constant that will be used by multiple procedures.
Here are some additional tips for using global variables in RPGLE:
- Avoid using global variables whenever possible. Instead, try to declare variables locally within procedures whenever possible.
- If you do need to use global variables, give them meaningful names (I prefer to start them with gbl_) and document their usage carefully.
- Avoid modifying global variables in multiple procedures. If a global variable needs to be modified, then it is generally best to do so in a single procedure. For instance, if you have a global variable called gbl_store_sales_tax, then have one procedure called calculate_store_sales_tax and that procedure is the only procedure that changes that value; all others just use that variable.
By following these tips for when to use local variables versus global variables, you can help ensure that your code is readable, maintainable, and efficient.
Until next time, happy coding.
Gregory Simmons is a software engineer with PC Richard & Son. He started on the IBM i platform in 1994, graduated with a degree in Computer Information Systems in 1997 and has been working on the OS/400 and IBM i platform ever since. He has been a registered instructor with the IBM Academic Initiative since 2007, and holds a COMMON Application Developer certification. When he’s not trying to figure out how to speed up legacy programs, he enjoys speaking at COMMON and other technical conferences, running, backpacking, SCUBA diving, hunting, and fishing.
When I was in college, the language we used was PL/I. Transitioning to pre ILE/RPG was brutal. My happiest day as a data processing professional was the introduction of ILE, allowing RPG to be a modern language. Scoped variables make for much more reliable code.`
30 years since ILE was introduced and the few RPG developers who use it write it like OPM.