When to use a dynamic call with subprograms

Your decision to use dynamic calls with subprograms depends on factors such as location of the program object, frequency of calls to the subprograms, size of the subprograms, ease of maintenance, the need to call subprograms in their unused state, the need for AMODE switching, and when the program-names are known.

The program object that you want to dynamically call must be in an MVS load library rather than in the z/OS® UNIX file system.

If subprograms are called in only a few conditions, you can use dynamic calls to bring in the subprograms only when needed.

If the subprograms are very large or there are many of them, using static calls might require too much main storage. Less total storage might be required to call and cancel one, then call and cancel another, than to statically call both.

If you are concerned about ease of maintenance, dynamic calls can help. Applications do not have to be link-edited again when dynamically called subprograms are changed.

When you cannot use the INITIAL attribute to ensure that a subprogram is placed in its unused state each time that it is called, you can set the unused state by using a combination of dynamic CALL and CANCEL statements. When you cancel a subprogram that was first called by a COBOL program, the next call causes the subprogram to be reinitialized to its unused state.

Using the CANCEL statement to explicitly cancel a subprogram that was dynamically loaded and branched to by a non-COBOL program does not result in any action being taken to release the subprogram's storage or to delete the subprogram.

Suppose you have an AMODE 24 program in the same run unit with Enterprise COBOL programs that you want to run in 31-bit addressing mode. COBOL dynamic call processing includes AMODE switching for AMODE 24 programs that call AMODE 31 programs, and vice versa. To have this implicit AMODE switching done, the Language Environment® runtime options ALL31(OFF) and STACK(,,BELOW) must be in effect.

When dynamic call is performed, control is passed from the caller to a Language Environment library routine. After the switching is performed, control passes to the called program; the save area for the library routine will be positioned between the save area for the caller program and the save area for the called program.

If you do not know the program-name to be called until run time, use the format CALL identifier, where identifier is a data item that will contain the name of the called program at run time. For example, you could use CALL identifier when the program to be called varies depending on conditional processing in your program. CALL identifier is always dynamic, even if you use the NODYNAM compiler option.

Examples: static and dynamic CALL statements