System i modularization: How-to tips -- part 4

Ron Turull

Modularization is key to reaping the benefits of ILE. It is the major factor in cutting development time and increasing programmer productivity – the more effective the modularization, the more productive the programming staff. But it's important to arm yourself with a reliable method when modularizing your applications.

More Information

In part 1, we discussed the first few tips. We discussed some code examples in part 2. Let's now wrap up with the last couple of tips.

Tip 6: Put procedure prototypes in /COPY members

When using prototyped procedures in RPG, as we did in our SQL CLI example discussed in part 2. , put the prototypes in a /COPY member. Include the member in both the source member where you define the procedures and in any member that uses the procedures. This drastically reduces typing and eliminates a source of errors. And, if you later change a procedure interface (e.g., you add a new parameter to the procedure), you will not have to update the prototypes in the calling members (since there are none); although, you may have to update the calls to the procedure to reflect the change.

We have done this with the prototypes for the SQLSetup and SQLCleanup procedures. The prototypes are now in a file called #SQLCLIXTR [see below]. A better place for them would actually be in our original #SQLCLI include file. You are encouraged to put them there either by manually copying them into #SQLCLI or by automatically copying them by placing a nested /Copy in #SQLCLI.


  d SQLSetup        pr            10i 0
     d   pHandles                      *   Value

     d pSQLCleanu      s               *   ProcPtr Inz(%paddr('SQLCLEANUP'))
     d SQLCleanup      pr
     d   pHandles                      *   Value

     d ChkSQLRC        pr
     d   Function                    10    Value
     d   SQLRetCode                  10i 0 Value

Tip 7: Don't forget about data

Global variables are often frowned upon and usually for good reason. They can make code confusing, hard to follow, and when overused tend to lead to "buggy" code. But, if you have used RPG for any length of time, you are quite familiar with them and used to using them because every variable in the old RPG (a.k.a., OPM RPG or RPG III) is global.

Things are different in COBOL and ILE RPG. These languages support local and global data. A local data item can be accessed only from within the procedure in which it is declared. This prevents other procedures from inadvertently modifying the data item, thus, reducing bugs.

However, there are some situations where global data is preferable – not all data, just a variable or two. For example, if a number of different procedures all use the same data item and it is not global, you must pass that data item to every procedure. This increases the complexity of the procedure interfaces, which should be avoided. A solution is to declare the data item as global so that every procedure has access to it. A good example of this is a variable that keeps track of a counter.


To lessen the likelihood of a procedure inadvertently modifying a global variable, use some kind of identifier to indicate that a variable is global. For example, use a "G_" or "G-" prefix (or just 'G' if you use mixed-case names).

About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.

This was first published in April 2007

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.