What is the difference between COBOL Nested Program vs. Subroutine in Z/OS

In COBOL, you may enclose a subroutine as nested program or as a stand-alone module. I want to know what are the differences between the two approaches in terms of speed of execution, memory usage, and whether both methods are allowed in CICS or not. Any references would be great. The run environment is Z/OS.



  • Both methods are allowed in CICS.

    The difference in memory usage, if any, is going to be negligible. The compiler will generate reentrant code and thus your Working-Storage will be dynamically allocated on first execution per CICS transaction and your Local-Storage dynamically allocated per execution. The Language Environment memory allocation algorithm is designed to be speedy. Only one copy of your executable code will be present in the CICS region.

    Packaging your subroutine as a nested program or statically linking your modules together at bind time avoids the overhead of the LOAD when the subroutine is called.

    Packaging your subroutine as a nested program prevents it from being called by other programs unless you package the nested program as a copybook and use the COPY compiler directive to bring it into your program. This technique can lead to interesting issues, such as changes to the nested program copybook should probably require recompilation of all programs using the copybook in order to pick up the new version; but this depends on your source code management system. Static linking of the subroutine has similar issues.

    If you package your subroutine as a separate module you have the option of executing it via EXEC CICS LINK or COBOL dynamic CALL. The former causes the creation of a new Language Environment enclave and thus the latter is more efficient, particularly on the second and subsequent CALL and if you specify the Language Environment runtime option CBLPSHPOP(OFF).

    Much of the above was gleaned from SHARE presentations over the years.

    Some tuning information is available in a SHARE presentation from 2002 S8213TR.PDF currently available here (the information is still valid). Note that there are many tuning opportunities relative to Language Environment runtime options related to storage allocation. There exist a number of different mechanisms to set Language Environment options. Your CICS Systems Programmer likely has an opinion on the matter. There may be shop standards regarding Language Environment runtime options.

    Generally speaking, mainframe CICS COBOL application tuning has more to do with using efficient algorithms, variable definitions, compile options, and Language Environment runtime options than it does with application packaging.