The procedure is one of the most powerful additions to RPG, and this article shows you some ways to leverage that power.

Procedures are the Swiss army knife of application architecture on the IBM midrange platform. They provide everything from simple organization of single programs to large-scale inter-language communication across entire business applications. In order to provide all these functions, procedures necessarily have a lot of options that apply to a lot of different situations. Today, we're going to try to standardize a few of those options.

Beyond the CALL

Way back in the murky mists of time, RPG II added a new opcode, the CALL. It revolutionized the way we could program by allowing us to write smaller pieces of code and reuse them. The CALL/PARM linkage with bidirectional parameters was unique and remained so for many years. In fact, when I worked on the conversion of an entire software package from RPG and CL on OS/400 to C and SQL on UNIX in the 1980s, one of the most difficult pieces was support for bidirectional parameters.

CALL with procedures (CALLP) is the next step in the evolution of RPG. Unlike the CALL opcode, we can use CALLP not only to call external logic but also to call internal procedures. This helps us arrange, consolidate, and simplify the code in a program. Inside a program, procedures are subroutines on steroids.

The Prototype

When we talk about procedures, we must necessarily talk about prototypes. A prototype defines the contract between a procedure and its caller: the parameters and an optional return value. A prototype can define either an external call to another program or a call to a procedure defined in the program (often referred to as a subprocedure). In fact, when ILE RPG was first introduced, you had to define the prototypes for subprocedures; otherwise, the compiler would generate an error. This restriction was relaxed in later releases, and that's one of the things we'll talk about.

In a previous article on converting to free-format RPG, I touched briefly on calls to external programs. Here's an example:

       dcl-pr ORDPRT extpgm;

         iOrder char(10);

       end-pr;

I'm calling the program ORDPRT and passing in an order number. The EXTPGM keyword tells you that I'm calling another program. To call an external procedure in a service program, I would use the keyword EXTPROC. Without any parameter, the EXTPGM keyword implies that the program name is the same as the prototype, which is how I prefer to do it. And typically, the protoype is in a /COPY file of some kind so that everyone can share the same definition. I will cover these points in more detail in an article on external program linkage. In this article, I want to focus more on internal procedures.

Defining a Subprocedure

I hope you're using free-format RPG. The examples here are going to use free-format syntax. If you're not, the concepts still apply, but everything is a little less intuitive. I'll show you one example at the end of the article. Right now, let's take a look at the most verbose example of a procedure. The following is a simple procedure that accepts two integers and returns the larger of the two (note that in the latest release of RPG I don't need this procedure any more, since the fine folks at IBM have provided us with %MIN and %MAX BIFs—thank you, IBM!).

       dcl-proc Max;

         dcl-pi Max int(5);

           iVal1 int(5);

           iVal2 int(5);

         end-pi;

         if iVal1 > iVal2;

           return iVal1;

         endif;

         return iVal2;

       end-proc Max;

Looking at this, you may be thinking that it’s not particularly verbose. When I say verbose, though, I'm referring specifically to the fact that I define the same thing in three different places. You'll note that the name Max is defined in the procedure definition (DCL-PROC), the procedure interface (DCL-PI), and the procedure end (END-PROC). You can repeat the same name in a lot of places (in fact, you can even put a name on the end-pi statement, although I've rarely seen that in practice).

This isn't meant to be a primer on subprocedures, so I'm not going to try to explain the purpose of each of those declarations. What I will do, though, is show you what the simpler version looks like:

       dcl-proc Max;

         dcl-pi *n int(5);

           iVal1 int(5);

           iVal2 int(5);

         end-pi;

         if iVal1 > iVal2;

           return iVal1;

         endif;

         return iVal2;

       end-proc;

Notice that the name Max now appears only once. If you need to change the name, you only need to change the DCL-PROC statement; you don't have to remebmer to change the other values. Of course, you find out pretty quickly when you try to compile; you get some name mismatch errors that are relatively easy to correct. It's just that those are changes that you don't need to make, and as a programmer, I prefer less work rather than more.

Speaking of renaming things, this is a great time to plug Rational Developer for i. The latest version of RDi (currently 9.5.1.1) has a very nifty new capability called Refactor. While still in its beginning stages, this promises to be a very powerful feature. With it, I could double-click any reference to the procedure Max anywhere in the code (not just the procedure definition itself) and then select Refactor > Rename from the pop-up context menu. I could then slect a new name for the procedure and the tool would change every reference to the new name. It's really very powerful. I could write an entire tip just on using it. Hmmmm…

Subprocedures and Subroutines

One other thing I'd like to address is the difference between subprocedures and subroutines. I've occasionally read comments from folks who think that all subroutines should be replaced with subprocedures. While I understand the desire to move to the newest syntax (as evidenced by the fact that I exclusively use free-format RPG in new development), I'm not so certain that subroutines are quite ready for the dustbin of development just yet. Let's take a look at an admittedly contrived example that nonetheless shows the utility of the subroutine.

       dcl-proc logEvents;

         if CustomerChanged;

           LOEVNT = 'CC';

           LOKEY = CMCUST;

           LOUSER = psds.user;

           LOWHEN = %timestamp;

           write LOGR;

         endif;

         if ItemChanged;

           LOEVNT = 'CI';

           LOKEY = IMITEM;

           LOUSER = psds.user;

           LOWHEN = %timestamp;

           write LOGR;

         endif;

       end-proc;

The subroutine writes two records to a log file with different data, depending on different events. The event code and key value are different for a customer change than for an item change, but the rest of the fields need to be intiialized and the record written. Since those lines of code are exactly the same, they're a good candidate for a subroutine as shown in the following snippet.

       dcl-proc logEvents;

         if CustomerChanged;

           LOEVNT = 'CC';

           LOKEY = CMCUST;

           exsr writeLog;

         endif;

         if ItemChanged;

           LOEVNT = 'CI';

           LOKEY = IMITEM;

           exsr writeLog;

         endif;

         return;

         begsr writeLog;

           LOUSER = psds.user;

           LOWHEN = %timestamp;

           write LOGR;

         endsr;

       end-proc;

As I said, I stretched things a little to get this example. In reality, I'd probably consider creating a subprocedure that accepted two parameters, the event code and key, and then did all the work. That would actually make the code cleaner. But I just wanted to point out that you could indeed create a subroutine inside of a subprocedure and use it to gather repetitive code. In fact, this is the only way you can call a subroutine from a subprocedure. Subprocedures can only call subroutines defined in that subprocedure and not those in the mainline or in other subprocedures. Similarly, the mainline can’t call a subroutine inside a subprocedure. This concept is called “scope,” and I'll talk more about scope in later articles.

Fixed-Format (and Why I Don't Use It)

I said I'd show you the fixed-format version of the Max procedure. Here it is:

     P Max             B

     D Max           PI             5I 0

     D  iVal1                       5I 0

     D  iVal2                       5I 0

         if iVal1 > iVal2;

           return iVal1;

         endif;

         return iVal2;

     P Max             E

The good news is that, just like in free-format RPG, you can remove all the extraneous occurrences of the name Max in fixed-format code as well, leaving only the one on the beginning prototype specification (the first line). Other than that, though, that's it for good news. I've been using free-format P- and D-specs for long enough now that I find those fixed definitions hard to decipher. But unfortunately, we don't always get to pick the code we work on, so in case you do have some older code, just remember that the same benefits apply.

That's it for this installment of RPG programming techniques. Watch for more on using prototypes and procedures in later articles.