When you make program calls, the way you pass the parameters can impact the way the called program executes. For that reason, you need a good understanding of the parameter passing styles available. In this TechTip, I'll review the three parameter passing styles supported on the iSeries.

Style Choices

The three parameter styles supported by the iSeries are by reference, by read-only reference, and by value. It's important to understand that program calls that are not prototyped can only be called when passing parameters by reference. Prototyped program calls can support all three of these parameter styles. Let's take a look at the differences between each of these styles.

By Reference

This parameter passing style is generally used when the called procedure or program needs to modify the parameter value. This is because this parameter passing style actually passes the address of the value being passed, so any updates to the parameter within the called program or procedure update the value in the calling program directly. As a result, the field formats used when calling a program or procedure by reference must match those used by the called procedure or program exactly. This style is not only the style used by non-prototyped program calls but is actually the default used by ILE RPG. Therefore, this is the style that is used if no parameter passing style is explicitly defined on the procedure prototype. No keyword needs to be specified on the procedure prototype to select this parameter style. It's also important to remember that this style should always be used if the procedure to be called needs to modify the value of the parameter.

By Read-Only Reference

An alternative to passing parameters by reference is to pass parameters by read-only reference. This parameter passing style can be used with prototyped calls to allow you to specify parameter values using fields whose definitions do not exactly match the format expected by the calling program. To pass parameters by read-only reference, specify the CONST keyword on the parameter definition within the prototype definition. This style also allows you to specify complicated expressions or literals as parameter values. This means that the following free-form ILE RPG statement would be completely acceptable if the parameter passing style is defined as read-only reference:

When passing parameters by read-only reference, it's important that the called program honor the "read only" state of the parameter. Otherwise, if the called program is written in a language that does not use prototypes, there's no way to ensure that the parameter will not be modified.

By Value

When passing a parameter by value, the value itself is passed, rather than a reference to the parameter from the calling program. With this style, the prototyped call can accept complex expressions, including literals and results from functions. This style also allows the passing of parameters that are not defined as exactly the same data type or length used in the called program. When parameters are passed by value, the called procedure can modify the passed parameter; however, the resulting value will never be returned to the calling program. This differs from passing by read-only reference in that even if the called program or procedure modifies the value, the calling program will not see the result.

What's Your Style?

When choosing a parameter passing style, you must consider a few factors. First and foremost, what style does the calling program expect? For example, if the called program is coded to expect to update a passed parameter, the prototype should be defined to pass the parameter by reference. If the called program will not be updating the parameter value or does not expect to return the updated value, calling by read-only reference or by value are the best choices. When passing large parameters, passing by read-only reference is generally the best choice. When passing a numeric or pointer parameter, in some cases passing by value will offer better performance.

No matter which parameter passing style you choose, understanding the options is an important first step.

Mike Faust is a Business Analyst for Invivo Corp. in Orlando, Florida. Mike is also the author of the books The iSeries and AS/400 Programmer's Guide to Cool Things and Active Server Pages Primer and SQL Built-in Functions and Stored Procedures. You can contact Mike at This email address is being protected from spambots. You need JavaScript enabled to view it..