IBM AS/400 Frozen Dessert Maker User Manual


 
Passing Prototyped Parameters
Figure 71 on page 146 shows the prototype for QCMDEXC, where the first param-
eter is defined with OPTIONS(*VARSIZE) meaning that you can pass parameters
of different lengths for the first parameter. Note that OPTIONS *VARSIZE can only
be specified for a character field, a graphic field, or an array.
*-------------------------------------------------------------
* This prototype for QCMDEXC defines three parameters. The
* first parameter can be passed character fields of
* different lengths, since it is defined with *VARSIZE.
*-------------------------------------------------------------
D qcmdexc PR EXTPGM('QCMDEXC')
D cmd 3000A OPTIONS(*VARSIZE) CONST
D cmdlen 15P 5 CONST
D 3A CONST OPTIONS(*NOPASS)
Figure 71. Prototype for System API QCMDEXC with *VARSIZE Parameter
Order of Evaluation
There is no guaranteed order for evaluation of parameters on a prototyped call.
This fact may be important when using parameters that cause side effects, as the
results may not be what you would expect.
A side effect occurs if the processing of the parameter changes:
The value of a reference parameter
The value of a global variable
An external object, such as a file or data area
If a side effect occurs, then, if the parameter is used elsewhere in the parameter
list, then the value used for the parameter in one part of the list may not be the
same as the value used in another part. For example, consider this call statement.
CALLP procA (fld : procB(fld) : fld)
Assume that procA has all value parameters, and procB has a reference param-
eter. Assume also that
fld
starts off with the value 3, and that procB modifies
fld
to
be 5, and returns 10. Depending on the order in which the parameters are evalu-
ated, procA will receive either 3, 10, and 5 or possibly, 3, 10, and 3. Or possibly, 5,
10, and 3; or even 5, 10, and 5.
In short, it is important to be aware of the possibility of side effects occurring. In
particular, if you are providing an application for third-party use, where the end user
may not know the details of some of the procedures, it is important ensure that the
values of the passed parameters are the expected ones.
Interlanguage Calls
When passing or receiving data from a program or procedure written in another
language, it is important to know whether the other language supports the same
parameter passing methods and the same data types as ILE RPG. Table 11 on
page 147 shows the different parameter passing methods allowed by ILE RPG
and, where applicable, how they would be coded in the other the ILE languages.
The table also includes the OPM RPG/400 compiler for comparison.
146 ILE RPG for AS/400 Programmer's Guide