That's how I changed it for testing, but I don't know whether they will allow the fix in production. Meanwhile, I've added comments on the IEABRCX hack just in case.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> on behalf of Ngan, Robert (DXC Luxoft) <robert.n...@dxc.com> Sent: Friday, May 3, 2024 2:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly I remember (a long time ago) we had "first time" code preceded by a NOP, which altered the NOP condition code to branch around the "first time" code on subsequent invocations. Robert Ngan DXC Luxoft -----Original Message----- From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf Of Abe Kornelis Sent: Thursday, May 2, 2024 14:59 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly [Some people who received this message don't often get email from a...@bixoft.nl. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Shmuel, all, it's been a long time since I last saw code like that. Worst example was code that XOR-ed the opcode of an AH instruction to switch back and forth between AH and SH to print a report in two columns. If I still had code like that in my code base, I'd prioritize to make that code RENT. (if I had enough breathing room to make that decision) Kind regards, Abe === Op 02/05/2024 om 19:16 schreef Seymour J Metz: > Except that IEABRC is only necessary for old code. I've inherited code that > uses NOP as a switch, overlaying the mask with F. > > -- > Shmuel (Seymour J.) Metz > https://secure-web.cisco.com/1hq5TPW9p1rQ9PcYL1V69Y4MDh5ECPN79dsvNxzpDZNOLyKkXJkaX5k8nFSb_DDXsVQyrEciAZkbttxpkpd2W5ZDt9YExftC2pGJOxWylN7ZcENyuD-YmwHkTh6RjpYCQwNREyGx6RWJDKd_C_y8VlPdgbm2tYZrxLUMyE0qDqGnKl4-h4moEbbZoSCCQmx3aI8n5QB28Q9zmtjaTIGZs13NmST7LT--RpCOz07PMJ3AA08qP3TgstuIXRadzzBy77qBdbRqlZe9HgNQZpfBijiG95d8jlf4m1I0MGdlsQlOlWlye86hlCXH6MRIaVoUTeXU9izzFEffYFvjCG5tat5YvDx3t00NkFMIaQFBf-lorck60IoiPse3HuDHVt_2_4Enw3-i8OtCrhQYEf0zRVTgtV8t5-Gsmc0qhDHQq234/https%3A%2F%2Fnam12.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fmason > .gmu.edu%2F~smetz3&data=05%7C02%7Crobert.ngan%40dxc.com%7Cc9f10e081dd6 > 47cf875a08dc6ae2549e%7C93f33571550f43cfb09fcd331338d086%7C0%7C0%7C6385 > 02767524497151%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l > uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1205muWAwyyeshC > OveMPL6ffrbRvqWVIgVKRulIjy%2BA%3D&reserved=0 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > ________________________________________ > From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> > on behalf of Peter Relson <rel...@us.ibm.com> > Sent: Thursday, May 2, 2024 8:37 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: IEABRC anomaly > > I don't recall having thought about this when providing IEABRC. But the > conclusion that it's not going to get added is likely a correct one. > > Without a complex macro (which definitely is not going to happen), changing > NOP to JNOP for the cases Jonathan Scott mentioned will reject operands that > are fully valid (avoiding RC=4 if you suppress ASMA212W Branch address > alignment for <x> unfavorable). I believe his case is a very common one of > using the operand of NOP for diagnostic purposes. > > While NOP perhaps isn't a branch (because it never goes anywhere), it is the > conditional branch opcode so could have been a candidate for conversion. But > functionally it is not necessary. Anyone who truly wants conversion of the > operand for some reason could avoid using NOP and code a conditional branch > with mask 0. That will get converted. > > Peter Relson > z/OS Core Technology Design
