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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
