Increased performance and throughput for CICS programs. Nested subprograms allow the programmer to avoid the overhead of CICS LINK, permitting one to use a static CALL instead of CICS LINK.
Constructing nested subroutines using COPY members for data areas and procedure code permits sharing common data areas and code with batch program usage, increasing reusability of code, though this can obviously also apply to separately compiled CICS subprograms. CICS does permit dynamic CALL now via CICS LE facilities, but the maintenance cost of supporting a small set of application subprograms used in only a handful of CICS main programs can be eased by using nesting and static CALL's inside those few main programs instead of using separate compilation. There is a tradeoff point of course - subprograms used in a larger count of CICS main programs would argue for separate compilation and dynamic call rather than nesting and static CALL, but the maintenance tradeoff point has to be determined at the application team level. To quote the perl mongers, TMTOWTDI. Peter -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Don Leahy Sent: Saturday, October 16, 2021 12:00 PM To: [email protected] Subject: Re: COBOL 6.2 - use of identical data name in a nested COMMON subpro Just to satisfy my curiosity, is there a compelling use case for nested programs? I have played with them, but, possibly due to a lack of imagination on my part, I cannot think of a reason to use them. On Fri, Oct 15, 2021 at 13:12 Farley, Peter x23353 < [email protected]> wrote: > Lo and behold, that was exactly the problem! Two COPY statements, > both containing the same group name. One of them can be changed to > use a different REPLACING phrase to provide unique names, but I missed > that in my initial analysis because the one with just the common group > name (which is a subset a larger COPY) also has a higher-level group > name and that name was the one referenced in the TO phrase of the > MOVE. I only saw the higher-level name and missed that the COPY below > name that had identical names as the larger COPY (used the same > REPLACING phrase as the larger COPY). > > Many thanks for nailing the reason for this issue. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Farley, Peter x23353 > Sent: Friday, October 15, 2021 1:01 PM > To: [email protected] > Subject: Re: COBOL 6.2 - use of identical data name in a nested COMMON > subpro > > Thanks Frank. I did not think that was the case, but I will double > check that in the original program. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Frank Swarbrick > Sent: Friday, October 15, 2021 5:32 AM > To: [email protected] > Subject: Re: COBOL 6.2 - use of identical data name in a nested COMMON > subpro > > My guess is that you have a COPY statement in the inner program that > includes another field with the same name. > > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on > behalf of Farley, Peter x23353 > <[email protected]> > Sent: Thursday, October 14, 2021 6:19 PM > To: [email protected] <[email protected]> > Subject: Re: COBOL 6.2 - use of identical data name in a nested COMMON > subpro > > Hi Tom, > > My case is that the names are not unique and they are passed to the > nested subroutine via CALL parameter. Like this, to use your short example: > > ID DIVISION. > PROGRAM-ID. OUTER1. > ENVIRONMENT DIVISION. > DATA DIVISION. > LINKAGE SECTION. > 1 X1 PIC X(8). > PROCEDURE DIVISION. > MOVE 'SUB1' To X1. > CALL 'SUB1' USING X1. > ID DIVISION. > PROGRAM-ID. SUB1. > ENVIRONMENT DIVISION. > DATA DIVISION. > LINKAGE SECTION. > 1 X1 PIC X(8). > PROCEDURE DIVISION USING X1. > MOVE 'DONE' TO X1. > EXIT PROGRAM. > END PROGRAM SUB1. > END PROGRAM OUTER1. > > But this example does not generate the compiler error that I > originally saw. I fiddled around with the original program that had > the problem, trying to cut it down to the minimum that would > demonstrate the error, but I have not been able to duplicate the error in a > simpler form so far. > > Round tuits being so incredibly scarce at the moment, I sadly will > have to drop this line of inquiry and hope I can get back to it at a later > time. > The program which had the compiler error works with the "correction" > as coded, so now I need to move on to my employer's other priorities. > > Thank you very much for your help. I will resurrect this thread or > start a new one if I ever find time to get back to the issue. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Tom Ross > Sent: Thursday, October 14, 2021 6:26 PM > To: [email protected] > Subject: Re: COBOL 6.2 - use of identical data name in a nested COMMON > subpro > > >In my specific case, there is a COPY structure populated in the > >outermost p= rogram level that is passed in CALL statements to nested > >COMMON subprograms= (which can also CALL each other) and all the > >COMMON subprograms use the sa= me COPY structure to define their > >LINKAGE parameter. I just did not and do= not understand why the > >compiler cannot use the "local" LINKAGE section def= inition in the > nested COMMON subprograms. > > > >There are only two levels of nesting here, outermost and then each > >COMMON s= ubprogram at the same level below that. > > > >This works flawlessly when subprograms are not nested but separately > >compil= ed as stand-alone units, so I do not see why it is different > >in a nested ve= rsion. It makes no sense. > > > >Is there a way to tell the compiler that a structure at the OUTERMOST > >level= is NOT to be shared with nested programs? That would solve > >the particular= > > problem that I have, I think. > > I tested this out myself, and I was able to refer to a data item X1 in > a nested program even though X1 was also defined in the containing program. > I was thinking that names in containing programs are automatically > GLOBAL, but they are not. Are you sure the name in the containing > program is not GLOBAL? > > This worked for me: > > WORKING-STORAGE SECTION. > 1 X1 PIC X(8) VALUE 'SUB1'. > PROCEDURE DIVISION. > MOVE 'SUB1' To X1. > ID DIVISION. > PROGRAM-ID. SUB1. > ENVIRONMENT DIVISION. > DATA DIVISION. > WORKING-STORAGE SECTION. > 1 X1 PIC 9. > PROCEDURE DIVISION. > Compute X1 = 5. > > > With X1 being non-unique...I wonder why it did not work for you? > > > Cheers, > TomR >> COBOL is the Language of the Future! << > -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
