The EGL call statement transfers control to another program and optionally passes a series of values. Control returns to the caller when the called program ends; and if the called program changes any data that was passed by way of a variable, the storage area available to the caller is changed, too.
The specified name cannot be a reserved word. If the caller must call a non-EGL program that has the same name as an EGL reserved word, use a different program name in the call statement, then use a linkage options part, callLink element to specify an alias, which is the name used at run time.
If the called program is a Java program, the called program name is case-sensitive; calledProgram is different from CALLEDPROGRAM. Otherwise, the determination of whether the program name is case-sensitive depends on the system on which the called program resides: case-sensitive for UNIX, case-insensitive otherwise.
In the EGL debugger, the called program name is case-insensitive.
It is recommended that a non-EGL-generated program be identified as externally defined not in the call statement, but in the linkage options part that is used at generation time. (The related property is in the linkage options part, callLink element, and is also called externallyDefined.)
The indicator is supported (at development time) if the program property VAGCompatibility is selected or (at generation time) if the build descriptor option VAGCompatibility is set to yes.
This indicator is appropriate if the caller is in a run unit that presents text forms to a screen and either of these situations is in effect:
It is recommended that you indicate your preference for screen refresh not in the call statement, but in the linkage options part that is used at generation time. (The related property is in the linkage options part, callLink element, and is called refreshScreen.)
An example is as follows:
if (userRequest = "C") try call programA; onException myErrorHandler(12); end end
The number, type, and sequence of arguments in a call statement must correspond to the number, type, and sequence of values expected by the called program.
It is strongly recommended that the number of bytes passed in each argument be the same as the number of bytes expected.In the case of an EGL-generated Java program, a length mismatch causes an error only if the run-time correction of that mismatch causes a type mismatch:
In the case of Java, an error occurs if blanks are added to a data item of type NUM, for example, but not if blanks are added to a data item of type CHAR.
The following rules apply to literals and constants:
The behavior of call depends partly on the target system, as shown in the next table.
Target system | Platform-specific details |
---|---|
AIX | Recursive calls are supported. |
iSeries COBOL | Recursive calls are not supported. |
iSeries Java | Recursive calls are supported. |
Linux | Recursive calls are supported. |
z/OS batch | Recursive calls are not supported. |
Windows 2000, Windows NT | Recursive calls are supported. |
z/OS UNIX System Services | Recursive calls are supported. |
The call is affected by the linkage options part, if any, that is used at generation time. (You include a linkage options part by setting the build descriptor option linkage.)
For details on linkage, see Linkage options part.
Related concepts
Linkage options part
Syntax diagram
Related reference
EGL statementsException handling
linkage
Primitive types
(C) Copyright IBM Corporation 1992, 2005. All Rights Reserved.