When using the CALL statement, there are a number of ways to optimize the calling of the subprogram.
You can optimize CALL statements in the following ways:
Use a literal in a CALL statement rather than a data-name, so that the statement can be optimized. For example:
CALL "myprog" USING
is faster than:
CALL program-name USING
where
program-name is a data item containing the value
myprog.
In native code, calling using a procedure pointer is efficient. However, in .NET COBOL code, it is not.
Each CALL statement takes time, so try not to arbitrarily split a program into too many subprograms. On the other hand, small
dynamically loadable programs make efficient use of memory, and may improve performance even though the calls themselves take
time. In which case, use CALL and CANCEL to dynamically load the subprograms when they are needed. Note that cancelling a
program does not, by default, free any memory.
CALL statements that do not alter the RETURN-CODE special register, or whose effect on RETURN-CODE are of no interest, should
use a calling convention of 4. The Compiler directive DEFAULTCALLS can be used to set this globally.
Calls to the COBOL system library routines that carry out logical operations, such as CBL_AND, are optimized by the Compiler
to actual machine logic operators, provided the parameters are eight bytes long or less and the length parameter is a literal
value. These too should use a calling convention of 4.
Calls can be made faster by using call convention 256, which eliminates parameter-count checking on individual entry points.
Use call prototypes as a way of type-checking your sub-programs at compile time, instead of encountering them at run time.
See
About Call Prototypes for more information.
Code a STOP RUN statement immediately after CALL statements that you know execution will not return from; for example, calls
to programs that will tidy up and terminate an application. This technique ensures that there is no trickle effect in execution
and also enables the Compiler to produce better code, in terms of run-time performance and analysis.