Support MC Press - Visit Our Sponsors

Forums Sponsor

POPULAR FORUMS Rpg sql insert into qtemp table (2021 views) What is better, free code or traditional code ? (1751 views) cant ping workstation from system i (1420 views) was 7 nd server not starting (1251 views) SQL Error 802 Type 6 - Numeric Handling for Joins? (572 views) ODF Release April 28, 2012 (496 views) Forums

Search Sponsor

Search

Prototypes are one of the most powerful enhancements in ILE RPG, particularly in free-form; this article shows you just how productive prototypes can be.

The CALLP opcode is arguably the most significant enhancement in ILE RPG. With the exception of free-format RPG, prototypes are certainly the most extensive addition to the language. Used properly together, the syntax of defining parameters as an extension of the D-specification and the various keywords that assign attributes to those parameters can completely transform the RPG language in ways you might not have foreseen. This article explains one of the subtlest but most important of those changes.

Replacing the PLIST

The simplest way that programs are changed is the replacement of the PLIST with the prototype. In its simplest guise, the prototype is really a parameter list in the D-specs. For example, take a PLIST that looks like this (some spaces have been compressed to fit the page width):

  c   PMISND     plist

  c              parm          PS_MessageID      7

  c              parm          PS_MessageData   80

This is very straightforward—two parameters, one a seven-character alpha field containing the message ID and the other an 80-character field containing message data. The corresponding prototype is here:

 d PMISND          pr                  extpgm('PMISND')

 d   msgid                        7    

 d   msgdta                      80    

Astute readers might recognize this prototype from my previous article on program messages (albeit with a minor difference, which I'll be discussing shortly). The two techniques do pretty much the same thing, although the prototype adds the additional information of the program to call; with the PLIST, this information is provided in the CALL opcode. Let's compare the two approaches:

   move      'CUS0001'     PS_MessageID

   movel     CustNum       PS_MessageData

   call      'PMISND'      PMISND

   eval      wMessageID = 'CUS0001'

   eval      wMessageData = %editc( CustNum: 'X')

   callp     PMISND( wMessageID: wMessageData)

You'll notice some very similar code. And even though I went a little out of my way to write the PLIST version using the RPG III style of code, complete with MOVE and MOVEL, while using RPG IV's EVAL opcode for the prototype technique, you can see the similarities in the two code fragments. Each one has two field initialization statements followed by the call. However, I cheated for the RPG IV fragment by leaving out a couple of lines of code. Can you tell what they are? Here:

 d  wMessageID      s             7    

 d  wMessageData    s            80    

I have to define the two work variables used to transport the message ID and message data from this program to the PMISND program. Somewhat counter-intuitively, the two parameter definitions in the prototype don't actually define variables; they are simply placeholders to tell you the size and type of the parameters. In order to actually use the prototype, I have to pass in variables that match the size and type of the prototype. Typically, that involves using work variables, as shown in the code.

I don't have to create additional variables when I use a PLIST. Since each PARM line in the PLIST definition is its own C-specification, I can use the old RPG III trick of defining the result field right in the specification. I normally frown on that particular technique because it combines two programmatically distinct tasks: variable definition and business logic. But I consider a PLIST to be really a definition statement, not real business logic, so I'm OK with defining the variables right there and saving a few lines of code. Heck, without a D-spec, you'd have to define them in MOVE statements, usually in your *INZSR, anyway. Defining them in the PLIST just makes it a little easier.

Anyway, the result here is that you have to actually add a couple of lines in order to use the prototype methodology. Not exactly a productivity booster, eh? But wait, that's not the whole story. With just a couple of keywords, you'll see how quickly the game changes.

Eliminating Work Variables

The biggest timesaver when using prototypes is the ability to remove work variables. Work variables are not just an annoyance, although they certainly are that, especially since they require you to jump back and forth between the business logic and the variable definitions. But more importantly, work variables are often a source of program errors, including errors that aren't clear until run time. Overflows and truncation occur when you forget to resize work variables, because even the most diligent programmer doesn't always use the LIKE keyword when defining variables.

With a couple of minor changes to the prototype, work variables disappear or at least can be reduced significantly in number:

 d PMISND          pr                  extpgm('PMISND')

 d   msgid                        7    const

 d   msgdta                      80    const

The change may not be completely obvious at first, but look at the keyword section (the rightmost column) of the D-specs for the two parameters. Each one now has the CONST keyword, which tells the compiler that this variable cannot be changed by the calling program. This allows the compiler to create temporary work variables to hold the data being passed to the called program or procedure (in addition to calling programs, prototypes can be used to call subprocedures within your programs as well as procedures in service programs). This seems like a very simple change, but the effect on the code is actually quite pronounced:

   callp     PMISND( 'CUS0001': %editc( CustNum: 'X'))

Note that I don't have to do any initialization. I can pass a literal or even a computed value to the procedure without using a temporary work variable. I also don't have to define the wMessageID and wMessageData fields in the D-specifications. Adding those simple keywords to my prototype reduces my code from five lines to one! That is what I mean when I say prototypes make you more productive.

You might note that I did have to include the prototype, so that's another three lines of code, but in a production environment, you would definitely have the prototype in a /COPY module. That then brings up the issue of managing include files, but that's more an issue of site standards rather than programming methodology.

I called this section "Eliminating Work Variables," but really it's only part one of that particular exercise. Another aspect of using prototypes specific to procedures is the return value. Return values are definitely a new concept to RPG programming, but once you get the hang of them, you can remove nearly all of your temporary variables and—at the very least—all of your global variables. I'll discuss global and temporary variables and their relationship to the return value in another article. Until then, enjoy your prototypes!