Topic
8 replies Latest Post - ‏2011-12-01T19:59:33Z by brataj
SystemAdmin
SystemAdmin
403 Posts
ACCEPTED ANSWER

Pinned topic GLOBAL/EXTERNAL data in recursive COBOL programs

‏2011-10-27T14:10:19Z |
I am using IBM Enterprise COBOL for z/OS to build a program with a large data structure (about 30M) shared among mutually recursive subroutines. Following is
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?
Updated on 2011-12-01T19:59:33Z at 2011-12-01T19:59:33Z by brataj
  • SystemAdmin
    SystemAdmin
    403 Posts
    ACCEPTED ANSWER

    Re: GLOBAL/EXTERNAL data in recursive COBOL programs

    ‏2011-10-27T14:47:46Z  in response to SystemAdmin
    Several questions come to mind:
    1) What is the REGION size specified on your JOB and EXEC statements?
    2) What is the actual size of the HEAP being allocated? You can find out by using the Storage Report if you do not know.
    3) Does your installation have a maximum REGION set such that, no matter what your REGION request on the JOB/EXEC, you will not get what you want/need?

    While this is very, very basic, what is the AMODE/RMODE of your Load Module? Yes, COBOL will always generate AMODE31 code, you need to be sure nothing has accidentally changed the module setting. e.g., An Assembler program component, included via AUTOCALL that is 24-bit code can mess up all your planning in the COBOL program.
    • SystemAdmin
      SystemAdmin
      403 Posts
      ACCEPTED ANSWER

      Re: GLOBAL/EXTERNAL data in recursive COBOL programs

      ‏2011-10-27T16:01:40Z  in response to SystemAdmin
      Well... I tried to turn on the storage report, and by doing so, went from specifying the LE options on the EXEC as a PARM to using a CEEOPTS DD. Seems it all works now!

      I don't see the problem with the PARM. Best I can tell it follows the guidelines in Specifying Run-Time Options in the EXEC Statement but if I keep the same options and specify them via CEEOPTS it all works.

      Thanks, Neal
      • brataj
        brataj
        40 Posts
        ACCEPTED ANSWER

        Re: GLOBAL/EXTERNAL data in recursive COBOL programs

        ‏2011-10-28T13:04:52Z  in response to SystemAdmin
        By default Cobol programs expect LE options AFTER the slash.

        The NOCBLOPTS option can be used to make Cobol behave like other languages with repect to runtime options, but of course you need to be careful using it as it may invalidate existing option coding.
        • uskobus
          uskobus
          2 Posts
          ACCEPTED ANSWER

          Re: GLOBAL/EXTERNAL data in recursive COBOL programs

          ‏2011-10-31T16:14:09Z  in response to brataj
          External Data and Local-Storge are impacted by the ALL31 Heap(below/any), and Stack(below/any) run time options.

          External data will be from unrestricted storage (above the line) if you have compiled the module Rent and data(31); plus run time options ALL31(on), Heap(anywhere). Checke all these compile and run time options to get external above the line.

          Local storage is from above the line if you have all31(on) and stack(anywhere).
  • JonButler
    JonButler
    2 Posts
    ACCEPTED ANSWER

    Re: GLOBAL/EXTERNAL data in recursive COBOL programs

    ‏2011-11-30T20:30:45Z  in response to SystemAdmin
    Being a PL/I and Java programmer with a part-time interest in COBOL, I'm amazed the first program does not compile. I understand the rule about RECURSIVE on the outermost program, but I'm wondering why that rule exists?
    • brataj
      brataj
      40 Posts
      ACCEPTED ANSWER

      Re: GLOBAL/EXTERNAL data in recursive COBOL programs

      ‏2011-12-01T15:06:15Z  in response to JonButler
      Jon,

      The nested procedures share the same stack frame as the outermost procedure; in that respect they're little more than paragraphs that can accept parameters.

      Bernie
      • JonButler
        JonButler
        2 Posts
        ACCEPTED ANSWER

        Re: GLOBAL/EXTERNAL data in recursive COBOL programs

        ‏2011-12-01T15:58:17Z  in response to brataj
        Thanks. So an internal COBOL subroutine is not the same as a PL/I internal subroutine/function nor a JAVA method that is recursive (although you don't need the word RECURSIVE in Java.) What's the advantage then of using an internal subroutine in COBOL rather than simply using say "perform a_paragraph thru a_paragraph_exit."
        • brataj
          brataj
          40 Posts
          ACCEPTED ANSWER

          Re: GLOBAL/EXTERNAL data in recursive COBOL programs

          ‏2011-12-01T19:59:33Z  in response to JonButler
          Hi Jon,

          There are basically two advantages.

          You get to use parameters on the CALL rather than implicitly using some data items as would be the case for paragraphs.

          Any data items defined inside the internal routine are not visible outside it (even though the storage for them is physically part of the enclosing routine's working-storage and local-storage).

          Bernie