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

Reply via email to