The following discussion applies to separately compiled subprograms only, not to nested programs. For information about calls within a nested program structure, see Calling Nested Programs.
The binding process differs, depending on whether your ILE COBOL program uses static procedure calls or dynamic program calls. When a static procedure call is used to call an ILE COBOL subprogram, it must first be compiled into a module object and then bound, by copy or by reference, into the same program object as the calling ILE COBOL program. When a dynamic program call is used to call an ILE COBOL subprogram, the ILE COBOL subprogram must be compiled and bound as a separate program object. For more information on the binding process, see the ILE Concepts book.
Static procedure calls offer performance advantages over dynamic program calls.
When an ILE COBOL subprogram is called using a static procedure call, it is already activated, since it is bound in the same program object as the calling program, and it is performed immediately upon receiving control from the calling ILE COBOL program.
When an ILE COBOL subprogram is called using a dynamic program call, many other tasks may need to be performed before the called ILE COBOL program is actually performed. These tasks include the following:
Thus, a dynamic program call is slower than a static procedure call due to the cost of activation the first time it is performed in an activation group.
Dynamic program calls and static procedure calls also differ in the number of operands that can be passed from the calling ILE COBOL program to the called ILE COBOL program. You can pass up to 255 operands using a dynamic program call. With a static procedure call, you can pass up to 400 operands.
Arguments that are designated as OMITTED or as having associated operational descriptors can only be passed using a static procedure call. These arguments cannot be passed using dynamic program calls.
You can perform a static procedure call by using the CALL literal statement (where literal is the name of a subprogram). There are three ways to specify that the call is to be a static procedure call. They are listed in order of precedence:
PROCEDURE DIVISION.
·
·
·
CALL LINKAGE TYPE IS PROCEDURE literal-1
ENVIRONMENT DIVISION. CONFIGURATION SECTION.
·
·
·
SPECIAL-NAMES. LINKAGE TYPE IS PROCEDURE FOR literal-1.
·
·
·
PROCEDURE DIVISION.
·
·
·
CALL literal-1.
CRTCBLMOD MODULE(MYLIB/XMPLE1) SRCFILE(MYLIB/QCBLLESRC) SRCMBR(XMPLE1) LINKLIT(*PRC)
PROCEDURE DIVISION.
·
·
·
CALL literal-1.
You can perform a dynamic program call by using the CALL literal statement (where literal is the name of a subprogram) or the CALL identifier statement. Refer to Using CALL identifier for more information about CALL identifier. There are three ways, using CALL literal, to specify that the call is to be a dynamic program call. They are listed in order of precedence:
PROCEDURE DIVISION.
·
·
·
CALL LINKAGE TYPE IS PROGRAM literal-1
ENVIRONMENT DIVISION. CONFIGURATION SECTION.
·
·
·
SPECIAL-NAMES. LINKAGE TYPE IS PROGRAM FOR literal-1.
·
·
·
PROCEDURE DIVISION.
·
·
·
CALL literal-1.
CRTCBLMOD MODULE(MYLIB/XMPLE1) SRCFILE(MYLIB/QCBLLESRC) SRCMBR(XMPLE1) LINKLIT(*PGM)
PROCEDURE DIVISION.
·
·
·
CALL literal-1.
A dynamic program call activates the subprogram at run time. Use a dynamic call statement when:
When a subprogram is changed, all module objects, except for service programs, that call it statically and are bound by copy must be re-bound. If they are bound by reference, they do not need to be re-bound provided that the interface between the subprogram and the module objects is unchanged. If the changed subprogram is called dynamically, then only the changed subprogram needs to be re-bound. Thus, dynamic calls make it easier to maintain one copy of a subprogram with a minimum amount of binding.
If the subprograms are called only on a few conditions, dynamic calls can activate the subprograms only when needed.
If the subprograms are very large or there are many of them, use of static calls might require a larger working set size in main storage.
(C) Copyright IBM Corporation 1992, 2005. All Rights Reserved.