CALLed COBOL Subprogram with alternate Entry points gets reset for subsequent access
In Enterprise COBOL for z/OS, a subroutine reads a file and builds a table on its initial CALL; however, the subroutine's WORKING-STORAGE is reset for the second and subsequent CALLs.
The data in the WORKING-STORAGE SECTION is lost.
The subprogram contains two alternate ENTRY points.
- The calling program uses different ENTRY points for table setup and later access.
- The main program is compiled with DYNAM (compile options RENT or NORENT make no difference).
There is documentation that advises against this.
Chapter 24 in the Enterprise COBOL Programming Guide, V4R2, includes the following under the topic:
"Making dynamic calls":
"Restrictions: You cannot make dynamic calls to:
(skip to the last bullet here)
. More than one entry point in the same COBOL program
(unless an intervening CANCEL statement was executed)."
Resolving the problem
The following suggestion worked in the particular situation described above. It has not been tested formally and may or may not work in other cases. Because no rigorous testing was done for COBOL programs, it is not discussed or endorsed in the Enterprise COBOL documentation.
If the subroutine is linked with Linkage Editor option REUS (for example //LKED EXEC PGM=IEWL,PARM='LIST,XREF,LET,MAP,REUS',.....) these are the informal test results for a MAIN program with one SUBROUTINE:
- Both MAIN and SUBROUTINE linked with REUS - retains WORKING-STORAGE in its last-used state.
- SUBROUTINE is linked with REUS, but MAIN is not - retains WORKING-STORAGE in its last-used state.
However, if the SUBROUTINE is not linked with REUS, the SUBROUTINE does NOT retain WORKING-STORAGE, regardless of how the MAIN program is linked.
A manual that discusses the REUS Linkage Editor option is z/OS 1.11 MVS Program Management: User's Guide and Reference (SA22-7643-09).
- See pages 97-98 (hard-copy page numbers). The default for REUS with no options is REUS=SERIAL.
Translate this page: