You're right, aren't you? <g> There would be no need for IBM to touch the opcode logic to support ddname.IDENTIFY or anything like that. IBM could do the trick with a simple (well, simple for me to say) enhancement to COPY to allow ddname(member) or whatever equivalent syntax made sense to IBM.
A macro copied into the source code comes ahead of SYSLIB in the search order, right? So copying the right IDENTIFY at the start of the source code would solve the problem, right? (And yes, I know the OP's error has been resolved: the CICS IDENTIFY in question is spurious.) Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Seymour J Metz Sent: Wednesday, July 20, 2022 5:19 AM To: [email protected] Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY There is no COPY ddname(member) in HLASM. That sounds like an obvious candidate for an RFE. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Charles Mills [[email protected]] Sent: Tuesday, July 19, 2022 5:31 PM To: [email protected] Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY In COBOL you can say COPY member OF ddname, so you can get an instance of 'member' that is not the first one in SYSLIB. PL/I has something similar. I don't think there is any way to do that in HLASM, is there? That would be nice. Perhaps a *PROCESS option to say "find macro IDENTIFY in the SYSMAC concatenation." (And then you would provide a SYSMAC DD statement pointing to SYS1.MACLIB or similar.) Or a hierarchical opcode name scheme like SYSMAC.IDENTIFY. Classic name collision problem. Many languages provide some way to control namespaces at the individual source code level. If IDENTIFY had been invented today they would have been called IEFIDENT and DFHIDENT, thereby solving the problem (but at a cost in memorability). Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Tuesday, July 19, 2022 2:07 PM To: [email protected] Subject: Name conflict: CICS macro name IDENTIFY conflicts with MVS macro name IDENTIFY Cross-posted to IBM-MAIN and CICS-L. We just encountered this. Our SDLC mechanism has CICS.BASE.MACLIB (an ALIAS for the current product version library) positioned in the assembler translate step BEFORE the SYS1.MACLIB library. SOP, put all licensed product libraries ahead of base system libraries, right? Not in this case. Turns out we have some old assembler ode that uses the MVS IDENTIFY macro for reasonable business purposes, but now the CICS MACLIB ALSO has a macro named IDENTIFY. Now that assembler program cannot be maintained or changed until the SYSLIB setup in the SDLC mechanism is updated (never a short process). The obvious solution here is of course to change the SDLC setup to put the CICS MACLIB after SYS1.MACLIB, but was this documented to the sysprogs that there is a (new?) name conflict here? Do the CICS and MVS sysprogs even talk to each other or to the SDLC mechanism maintainers? ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
