When calling non-Ideal subprograms, CA Ideal does not have control over the entire runtime environment, but only over the way the subprogram is called. For example, if the user coded the following and described an input (I) parameter in the non-Ideal subprogram definition for the subprogram COBOL1 to correspond to the data item named ALPHA, the COBOL subprogram could actually modify the contents of the data item outside the CA Ideal environment.
CALL COBOL1 USING INPUT ALPHA
To protect the integrity of the CA Ideal environment, CA Ideal uses the following technique: When a CA Ideal program calls a non-Ideal subprogram, the parameter definition for the non-Ideal subprogram constructs an intermediate data storage area with the defined characteristics contained in the CA Ideal calling program. For this reason, the non-Ideal subprogram definition must actually exist when the calling program is compiled.
Data items in the intermediate storage area are not aligned. Any alignment required for correct function of the non-Ideal subprogram is the responsibility of the programmer. You can establish this alignment by inserting the appropriate FILLER items in the non-Ideal subprogram parameter definition fill-in.
The field names in the non-Ideal subprogram parameter definition are internally prefixed with a percent sign (%) to avoid duplicate naming problems between the main program and the called program. However, two non-Ideal subprograms called by the same CA Ideal calling program should not have duplicate parameter field names because at compile time, if there is an error on one of the duplicate fields, you might not be able to tell which subprogram contains the error.
When the calling program CALL statement executes, CA Ideal moves the data from the data items named in the USING clause to the intermediate data storage area, using the rules for MOVE BY POSITION, and carrying out any necessary conversion. CA Ideal internal numeric format is converted to zoned decimal, packed decimal, or binary, depending on the non-Ideal subprogram parameter definition.
The addresses of the intermediate storage area data items are passed to the subprogram instead of the original CALL statement data items. Any reference in the non-Ideal subprogram to a parameter is actually a reference to a data item in the intermediate storage area.
When control returns from the called non-Ideal subprogram, CA Ideal then moves only those data items defined as UPDATE from the intermediate data storage area back to the original data items named in the USING clause. In this way, CA Ideal ensures that CA Ideal rules for linkage are observed.
As a result, any data items described as INPUT in the CALL statement cannot be modified by the CALL to the non-Ideal subprogram, even if the non-Ideal subprogram modified its copy of the data item. This also means that a called subprogram cannot alter the address of any updateable intermediate storage area.
The area containing the parameters is not necessarily at the same address each time the subprogram is called. Subprograms should not store the address of any parameter data between calls, as these addresses will be invalid in future calls. If a non-Ideal subprogram requires a workarea for re-entrancy, then fields within the workarea should be addressed relative to the workarea address, storing offsets rather than addresses, or relocating any pointers on each call.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|