Filter
Top Products
Passing Prototyped Parameters
Checking for the Number of Passed Parameters
At times it may be necessary to check for the number of parameters that are
passed on a call. Depending on how the procedure has been written, this number
may allow you to avoid references to parameters that are not passed. For example,
suppose that you want to write a procedure which will sometimes be passed three
parameters and sometimes four parameters. This might arise when a new param-
eter is required. You can write the called procedure to process either number
depending on the value that is returned by the built-in function %PARMS. New calls
may pass the parameter. Old calls can remain unchanged.
%PARMS does not take any parameters. The value returned by %PARMS also
includes any parameters for which *OMIT has been passed. For the main proce-
dure, %PARMS returns the same value as contained in the *PARMS field in a
PSDS, although to use the *PARMS field, you must also code the PSDS.
For both *PARMS and %PARMS, if the number of passed parameters is not
known, the value -1 is returned. (In order to determine the number of parameters
passed, a minimal operational descriptor must be passed. ILE RPG always passes
one on a call; however other ILE languages may not.) If the main procedure is not
active, *PARMS is unreliable. It is not recommended to reference *PARMS from a
subprocedure.
Using %PARMS
In this example, a procedure FMTADDR has been changed several times to allow
for a change in the address information for the employees of a company.
FMTADDR is called by three different procedures. The procedures differ only in the
number of parameters they use to process the employee information. That is, new
requirements for the FMTADDR have arisen, and to support them, new parameters
have been added. However, old procedures calling FMTADDR are still supported
and do not have to be changed or recompiled.
The changes to the employee address can be summarized as follows:
Initially only the street name and number were required because all employees
lived in the same city. Thus, the city and province could be supplied by default.
At a later point, the company expanded, and so the city information became
variable for some company-wide applications.
Further expansion resulted in variable province information.
The procedure processes the information based on the number of parameters
passed. The number may vary from 3 to 5. The number tells the program whether
to provide default city or province values or both. Figure 68 on page 142 shows
the source for this procedure. Figure 69 on page 143 shows the source for /COPY
member containing the prototype.
The main logic of FMTADDR is as follows:
1. Check to see how many parameters were passed by using %PARMS. This
built-in function returns the number of passed parameters.
If the number is greater than 4, then the default province is replaced with
the actual province supplied by the fifth parameter P_Province.
If the number is greater than 3, then the default city is replaced with the
actual city supplied by the fourth parameter P_City.
Chapter 10. Calling Programs and Procedures 141