Parameter-Passing Considerations

When designing a call interface, you must make a number of decisions in terms of how parameters will be passed. On the other hand, if you are the caller then most of the decisions have already been made for you. The following lists some of the parameter-passing considerations to keep in mind when you are designing a call interface.
  • Compile-time parameter checking
    The call interface of a prototyped call is checked at compile time. This checking ensures that:
    • the data types are correctly used
    • correct files are passed to file parameters
    • all required parameters are passed
    • *OMIT is only passed where it is allowed.
  • Parameter passing method

    Each HLL provides one or more ways of passing parameters. These may include: passing a pointer to the parameter value, passing a copy of the value, or passing the value itself.

  • Passing operational descriptors

    Sometimes you may not be sure of the exact format of the data that is being passed to you. In this case you may request that operational descriptor be passed to provide additional information regarding the format of the passed parameters.

  • Number of parameters

    In general, you should pass the same number of parameters as expected by the called program or procedure. If you pass fewer parameters than are expected, and the callee references a parameter for which no data was passed, then the callee will get an error.

  • Passing less data

    If you pass a parameter and you pass too little data, your application may not work correctly. If changing the parameter, you may overwrite storage. If using the parameter, you may misinterpret the parameter. By prototyping the parameter, the compiler will check to see that the length is appropriate for the parameter.

    If the callee has indicated (through documentation or through that prototype) that a parameter can be shorter than the maximum length, you can safely pass shorter parameters. (Note, however, that the called procedure must be written in a way to handle less data than required.)

  • Order of evaluation

    There is no guaranteed order for evaluation of parameters on a prototyped call. This fact may be important, if a parameter occurs more than once in the parameter list, and there is the possibility of side effects.

  • Interlanguage call considerations

    Different HLLs support different ways of representing data as well as different ways of sending and receiving data between programs and procedures. In general, you should only pass data which has a data type common to the calling and called program or procedure, using a method supported by both.

    RPG file parameters are not related to file parameters of other HLLs; you can only pass an RPG file parameter to another RPG program or procedure.

Table 1 associates the above considerations with the two types parameters: prototyped or non-prototyped.

Table 1. Parameter Passing Options
Parameter Option Prototyped

Not
Prototyped

See Page
Compile-time parameter checking Yes   Passing Prototyped Parameters
Pass by reference Yes Yes Passing by Reference
Pass by value Yes (b)   Passing by Value
Pass by read-only reference Yes   Passing by Read-Only Reference
Pass operational descriptors Yes (b) Yes (b) Using Operational Descriptors
Pass *OMIT Yes Yes (b) Omitting Parameters
Control parameter omission Yes Yes Leaving Out Parameters
Get number of passed parameters Yes Yes Checking for the Number of Passed Parameters
Disallow incorrect parameter length Yes   Passing Less Data Than Required
Pass file parameters Yes   Passing File Parameters
Note: (b) – applies to bound procedures only.