• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • 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.

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags: Tags: 400guru, FHG, Four Hundred Guru, IBM i, RPG, RPGLE

    Sponsored by
    WorksRight Software

    Do you need area code information?
    Do you need ZIP Code information?
    Do you need ZIP+4 information?
    Do you need city name information?
    Do you need county information?
    Do you need a nearest dealer locator system?

    We can HELP! We have affordable AS/400 software and data to do all of the above. Whether you need a simple city name retrieval system or a sophisticated CASS postal coding system, we have it for you!

    The ZIP/CITY system is based on 5-digit ZIP Codes. You can retrieve city names, state names, county names, area codes, time zones, latitude, longitude, and more just by knowing the ZIP Code. We supply information on all the latest area code changes. A nearest dealer locator function is also included. ZIP/CITY includes software, data, monthly updates, and unlimited support. The cost is $495 per year.

    PER/ZIP4 is a sophisticated CASS certified postal coding system for assigning ZIP Codes, ZIP+4, carrier route, and delivery point codes. PER/ZIP4 also provides county names and FIPS codes. PER/ZIP4 can be used interactively, in batch, and with callable programs. PER/ZIP4 includes software, data, monthly updates, and unlimited support. The cost is $3,900 for the first year, and $1,950 for renewal.

    Just call us and we’ll arrange for 30 days FREE use of either ZIP/CITY or PER/ZIP4.

    WorksRight Software, Inc.
    Phone: 601-856-8337
    Fax: 601-856-9432
    Email: software@worksright.com
    Website: www.worksright.com

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Power Systems Software Gets Its Updates And Tweaks Thoroughly Modern: How X-Analysis Transforms IBM i Challenges Into Solutions

    2 thoughts on “Guru: Procedure Driven RPG Means Keeping Your Variables Local”

    • Chris Pando says:
      November 6, 2023 at 4:11 pm

      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.`

      Reply
    • Greg says:
      November 16, 2023 at 4:10 pm

      30 years since ILE was introduced and the few RPG developers who use it write it like OPM.

      Reply

    Leave a Reply Cancel reply

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • The Power11 Transistor Count Discrepancies Explained – Sort Of
  • Is Your IBM i HA/DR Actually Tested – Or Just Installed?
  • Big Blue Delivers IBM i Customer Requests In ACS Update
  • New DbToo SDK Hooks RPG And Db2 For i To External Services
  • IBM i PTF Guide, Volume 27, Number 33
  • Tool Aims To Streamline Git Integration For Old School IBM i Devs
  • IBM To Add Full System Replication And FlashCopy To PowerHA
  • Guru: Decoding Base64 ASCII
  • The Price Tweaking Continues For Power Systems
  • IBM i PTF Guide, Volume 27, Numbers 31 And 32

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle