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://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason > .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
