Moreover, a CICS macro would start with DFH... it wouldnt be called IDENTIFY.
Joe On Wed, Jul 20, 2022 at 8:41 AM Ward Able, Grant <gwarda...@dtcc.com> wrote: > As stated by IBM Hursley (John Tilling) on the CICS-List, CICS does not > ship an IDENTIFY macro! > > Regards - Grant. > Telephone Internal: 201496 (London) > > EAM - Enterprise Application Middleware > > In theory, there's no difference between theory and practice. In practice, > there is. > > Worry more about your character than your reputation. Character is what > you are, reputation merely what others think you are. - John Wooden > > If you don't have time to do it right, when will you have the time to do > it over? - John Wooden > > > > DTCC Public (White) > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Seymour J Metz > Sent: 20 July 2022 14:18 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS > macro name IDENTIFY > > ATTENTION: External Email - Be Suspicious of Attachments, Links and > Requests for Login Information. > > IDENTIFY has existed and been documented since Old Man Noach got high on > PCP. Yes, CICS should have known better. > > The RFE wouldn't be for unique names; that ship has sailed. It would be > for new syntax on COPY. > > If your program needs both, you're screwed. Welcome to CM Hell. > > > -- > Shmuel (Seymour J.) Metz > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=05%7C01%7Cgwardable%40DTCC.COM%7C84a10466544949519ea508da6a5254cd%7C0465519d7f554d47998b55e2a86f04a8%7C0%7C0%7C637939199102819262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RmTDzrKLqfpMeWzgN3LzujQbqe9CNNgHDschdGnwYwY%3D&reserved=0 > > ________________________________________ > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Paul Gilmartin [0000042bfe9c879d-dmarc-requ...@listserv.ua.edu] > Sent: Wednesday, July 20, 2022 9:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Name conflict: CICS macro name IDENTIFY conflicts with MVS > macro name IDENTIFY > > On Wed, 20 Jul 2022 12:18:56 +0000, Seymour J Metz wrote: > > >There is no COPY ddname(member) in HLASM. That sounds like an obvious > candidate for an RFE. > > > Hasn't the MVS macro name IDENTIFY existed long enough that CICS should > have known better? > > That's not an RFE; tt's a bug; BAD. Suppose a program needs both services. > > > >-----Original Message----- > >From: Farley, Peter x23353 > >Sent: Tuesday, July 19, 2022 2:07 PM > > > >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. > > -- > gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > DTCC DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in error, please > notify us immediately and delete the email and any attachments from your > system. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email. Message content created by DTCC is > automatically secured using Transport Layer Security (TLS) encryption and > will be encrypted and sent through a secure transmission connection if the > recipient's system is configured to support TLS on the incoming email > gateway. If there is no TLS configured or the encryption certificate is > invalid on the recipient's system, the email communication will be sent > through an unencrypted channel. Organizations communicating with DTCC > should be using TLS v1.2 or newer to ensure continuation of encrypted > communications. DTCC will not be responsible for any disclosure of private > information or any related security incident resulting from an > organization's inability to receive secure electronic communications > through the current version of TLS. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
