IBM i > DEVELOPER > RPG

Data Storage Options in Subprocedures

How different types of variable storage impact the behavior of local and global data in subprocedures.

How different types of variable storage impact the behavior

This month we've decided to preview a topic from one of the sessions that we'll cover at the upcoming RPG & DB2 Summit. The session "Subprocedures: Beyond the Basics" will cover the use of local and global data in subprocedures and how the different types of variable storage impact their behavior.

First, a review of local and global data items is in order. Data items (e.g., standalone fields, data structures, named constants) defined inside an RPG subprocedure (i.e., between a pair of beginning and ending P specs) are local to that subprocedure. Local fields can only be referenced by logic in that subprocedure - not in the main procedure or other subprocedures. In contrast, data items defined before the first P spec in a source member are global and are available to all logic in the module--including all subprocedures and the main procedure.

Most developers who have been writing code using subprocedures for a while (and we hope this includes you) are familiar with local and global data. However, many are not fully aware of the differences in the way local and global variables behave. That's what we will explore here. To test your understanding these differences, consider the following simple program. We're using Dsply statements to display the results rather than coding a display file. We often use Dsply when demonstrating a technique. V5's /Free format makes this even easier to use as you'll see in the example. See if you can correctly predict the results appearing on the screen when the program is called. What, if any, differences would you expect in the displayed results if this program were called a second time right away in the same job? We suggest you write down your answers so you won't be tempted to cheat.

H DftActGrp(*NO)   ActGrp('QILE')   Option(*SrcStmt)

 D ProcAuto        PR

 D I               S                5U 0
 D GlobalCount     S                3  0 Inz

  /FREE

   Dsply 'Call to Main Pgm Begins Here';

   For I = 1 to 3; // Call the subprocedure 3 times
     Dsply ('> Call ' + %Char(I) + ' to Subprocedure');
     ProcAuto();
   EndFor;

   *INLR = *On;

  /END-FREE
 P ProcAuto        B

 D                 PI
 D AutoCount       S                3  0
 D StatCount       S                3  0 Static
  /FREE
   StatCount = StatCount + 1;
   AutoCount = AutoCount + 1;
   GlobalCount = GlobalCount + 1;
   Dsply ('>> AutoCount=' + %Char(AutoCount) +
         ', StatCount=' + %Char(StatCount) +
         ', GlobalCount=' + %Char(GlobalCount));

  /END-FREE
 P                 E

We'll look at the right answer first and then explain it--just in case your answers differ from ours. After the first call to the program, you would see:

DSPLY Call to Main Pgm Begins Here
DSPLY > Call 1 to Subprocedure
DSPLY >> AutoCount=1, StatCount=1, GlobalCount=1
DSPLY > Call 2 to Subprocedure
DSPLY >> AutoCount=1, StatCount=2, GlobalCount=2
DSPLY > Call 3 to Subprocedure
DSPLY >> AutoCount=1, StatCount=3, GlobalCount=3

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters