Or maybe concatenate the MACRO you want to use in front of SYSIN (could sometimes clash with directives that must be first)
On Wed, Jul 20, 2022 at 2:19 PM Seymour J Metz <[email protected]> wrote: > 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
