Some programming languages, such as WFL and ALGOL, allow the initiating program to specify the passing mode for a tasking parameter. In addition, programming languages typically allow the receiving program to specify a passing mode for the formal parameter. Thus, it is possible for the calling program and the receiving program to request different passing modes for the same parameter.

The system is very forgiving of these types of mismatches and generally allows any combination of actual and formal passing modes without issuing an error. However, when the calling program and the receiving program request different passing modes, the system uses the passing mode requested by the calling program. For example, if a call-by-value actual parameter is passed to a call-by-reference formal parameter, the system passes the parameter by value.

Note that the system is less forgiving of passing mode mismatches for parameters passed to library procedures. For a discussion of the allowable passing mode combination for library procedures, refer to Using Libraries.

Be very careful when writing a program that is to be initiated, and passed a parameter, by calling programs written by other people. The calling program might use a different passing mode for the parameter than you expected. For example, you might design the receiving program to receive a parameter by value, and make assignments to the parameter. However, if the calling program actually passes an expression by name, then the receiving program terminates with an error when it attempts to assign a value to the formal parameter. This is true because the calling program implicitly passed a thunk, and it is not possible to store values into thunks. You can avoid these types of problems by not making assignments to the formal parameter.

There is one type of passing mode problem that can make it impossible even for the receiving program to read the value of the formal parameter. If the calling program specifies a constant or an expression as a call-by-name actual parameter, then the compiler creates a thunk. If the receiving program specifies the formal parameter as call-by-reference, then the formal parameter cannot receive a thunk. The calling program can initiate the receiving program successfully. However, when the receiving program attempts to interrogate or modify the value of the formal parameter, the system issues an “INVALID OPERATOR” error and discontinues the receiving program.

Note that this error does not occur if the call-by-name actual parameter is a variable, rather than a constant or an expression. If a variable is used, then the compiler does not create a thunk. The receiving program can use the formal parameter without any problems.

Examples

Suppose that the following COBOL74 program is the receiving program. Note that the formal parameter specification indicates the parameter REAL-PARAM is to be received by reference:

100 IDENTIFICATION DIVISION.
110 ENVIRONMENT DIVISION.
120 DATA DIVISION.
130 WORKING-STORAGE SECTION.
140  77 REAL-PARAM BINARY PIC 9(11) RECEIVED BY REFERENCE.
150 PROCEDURE DIVISION USING REAL-PARAM.
160 START-HERE SECTION.
170 P1.
180     MOVE 15 TO REAL-PARAM.
190 STOP RUN.

The following ALGOL program invokes the preceding program and passes the real variable ACTUALREAL as the actual parameter. Note that the statement at line 150 in the following example specifies that the parameter be passed by value. This statement overrides the RECEIVED BY REFERENCE clause and causes the parameter to be passed by value. When the receiving program assigns a value of 15 to the formal parameter, the value of the actual parameter is not affected. Thus, the statement at line 210 displays a value of 5; but if the statement at line 150 were deleted, the statement at line 210 would display a value of 15.

100 BEGIN
110 FILE TERM (KIND=REMOTE);
120 TASK T;
130 REAL ACTUALREAL;
140 PROCEDURE COBOLTASK (RVAL);
150    VALUE RVAL;
160    REAL RVAL;
170    EXTERNAL;
180 ACTUALREAL := 5;
190 REPLACE T.NAME BY “OBJECT/COBOL/TASK.”;
200 CALL COBOLTASK (ACTUALREAL) [T];
210 WRITE (TERM,*//,ACTUALREAL);
220 END.

Now suppose that the COBOL74 program was invoked by a WFL job instead. The following WFL job invokes the COBOL74 program and passes a real parameter by value (the default passing mode in WFL):

100 ?BEGIN JOB WFL/TEST;
110    CLASS = 2;
120    JOBSUMMARY = SUPPRESSED;
130    ELAPSEDLIMIT = 120;
140 REAL R:= 5;
150 RUN OBJECT/COBOL/TASK (R);
160 DISPLAY STRING(R,*);
170 ?END JOB

The statement at line 160 displays a value of 5. However, if you change the RUN statement to read RUN OBJECT/COBOL/TASK (R REFERENCE); then the parameter is passed by reference and the statement at line 160 displays a value of 15.