a rough outline illustrating the "natural" (although illegal) stucture of the program:
ID DIVISION. PROGRAM-ID PROGA. WORKING-STORAGE 01 VERY-LARGE-DATA PIC X(30000000) GLOBAL. 01 OTHER-DATA PIC X(10). PROCEDURE DIVISION ... references to VERY-LARGE-DATA CALL PROGB USING OTHER-DATA ... GOBACK . ID DIVISION. PROGRAM-ID PROGB RECURSIVE. LINKAGE SECTION. 01 OTHER-DATA PIC X(10). PROCEDURE DIVISION USING OTHER-DATA. ... references to VERY-LARGE-DATA references to OTHER-DATA IF some-condition CALL PROGC USING OTHER-DATA END-IF ... GOBACK . END-PROGRAM PROGB ID DIVISION. PROGRAM-ID PROGC RECURSIVE. LINKAGE SECTION. 01 OTHER-DATA PIC X(10). PROCEDURE DIVISION USING OTHER-DATA. ... references to VERY-LARGE-DATA references to OTHER-DATA IF some-condition CALL PROGB USING OTHER-DATA END-IF ... GOBACK . END-PROGRAM PROGC. END-PROGRAM PROGA.
Of course this doesn't even compile because only the outermost program can be declared RECURSIVE and recursive programs cannot contain nested subprograms.
The obvious fix is to make each program stand-alone by moving END-PROGRAM PROGA to just before the ID DIVISION of PROGB. However that means VERY-LARGE-DATA is not 'visable' to PROGB and PROGC. To fix that I changed GLOBAL to EXTERNAL and added
the same declaration of VERY-LARGE-DATA to PROGB and PROGC.
It all compiles but now comes up with a run-time error:
CEE0813S Insufficient storage was available to satisfy a get storage (CEECZST)
Programs were compiled with DATA(31). The region allocated in the run JCL is significantly larger than the total declared program storage areas. The EXEC card is:
EXEC PGM=PROGA,PARM= 'ALL31(ON),HEAP(,,ANYWHERE)/'
Any ideas what my problem is, or any suggestions as to how I could restructure these programs - with the objective of not having to pass VERY-LARGE-DATA as linkage parameters to each called subroutine?