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 <[email protected]> On Behalf Of Seymour J Metz Sent: 20 July 2022 14:18 To: [email protected] 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 [[email protected]] on behalf of Paul Gilmartin [[email protected]] Sent: Wednesday, July 20, 2022 9:11 AM To: [email protected] 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 [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 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 [email protected] with the message: INFO IBM-MAIN
