Re: IEABRC anomaly
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 on behalf of Ngan, Robert (DXC Luxoft) 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 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 > on behalf of Peter Relson > 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 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
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 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 > on behalf of Peter Relson > 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 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
Re: IEABRC anomaly
In general, but not when there are addressability issues. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> Sent: Thursday, May 2, 2024 8:49 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly Would it help to use IEABRCX and disable it around that macro? -- Tom Marchant On Thu, 2 May 2024 21:50:26 +, Seymour J Metz wrote: >It's not clear that the author ever heard of EX. Some of the code is decades >old, and a mass cleanup is not authorized. I'm not rven sure whether I can get >permission to fix a macro that IEABRC breaks (it uses the BDDD of a B as a >first-time switch. > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 >עַם יִשְׂרָאֵל חַי >נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > >From: IBM Mainframe Assembler List on behalf >of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> >Sent: Thursday, May 2, 2024 5:12 PM >To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >Subject: Re: IEABRC anomaly > >On 5/2/24 11:16:13, Seymour J Metz wrote: >> Except that IEABRC is only necessary for old code. I've inherited code that >> uses NOP as a switch, overlaying the mask with F. >> . >Self-modifying or EX code!? > >-- >gil
Re: IEABRC anomaly
Would it help to use IEABRCX and disable it around that macro? -- Tom Marchant On Thu, 2 May 2024 21:50:26 +, Seymour J Metz wrote: >It's not clear that the author ever heard of EX. Some of the code is decades >old, and a mass cleanup is not authorized. I'm not rven sure whether I can get >permission to fix a macro that IEABRC breaks (it uses the BDDD of a B as a >first-time switch. > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 >עַם יִשְׂרָאֵל חַי >נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > >From: IBM Mainframe Assembler List on behalf >of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> >Sent: Thursday, May 2, 2024 5:12 PM >To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >Subject: Re: IEABRC anomaly > >On 5/2/24 11:16:13, Seymour J Metz wrote: >> Except that IEABRC is only necessary for old code. I've inherited code that >> uses NOP as a switch, overlaying the mask with F. >> . >Self-modifying or EX code!? > >-- >gil
Re: IEABRC anomaly
It's not clear that the author ever heard of EX. Some of the code is decades old, and a mass cleanup is not authorized. I'm not rven sure whether I can get permission to fix a macro that IEABRC breaks (it uses the BDDD of a B as a first-time switch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Thursday, May 2, 2024 5:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly On 5/2/24 11:16:13, Seymour J Metz wrote: > Except that IEABRC is only necessary for old code. I've inherited code that > uses NOP as a switch, overlaying the mask with F. > . Self-modifying or EX code!? -- gil
Re: IEABRC anomaly
On 5/2/24 11:16:13, Seymour J Metz wrote: Except that IEABRC is only necessary for old code. I've inherited code that uses NOP as a switch, overlaying the mask with F. . Self-modifying or EX code!? -- gil
Re: IEABRC anomaly
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 > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Assembler List on > behalf of Peter Relson > 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 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
Re: IEABRC anomaly
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 http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Peter Relson 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 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
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 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
Re: IEABRC anomaly
In my case it gets an addressability error. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Joseph Reichman Sent: Wednesday, May 1, 2024 11:25 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly There is a B2D2 there just the mask is zero So it falls thru > On May 1, 2024, at 11:06 AM, Pieter Wiid wrote: > > NOP translates to BC 0 > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Paul Gilmartin > Sent: Wednesday, 01 May 2024 16:21 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: IEABRC anomaly > >> On 5/1/24 07:56:17, Seymour J Metz wrote: >> It turns out that IEABRC does not convert NOP to JNOP. Is that a bug or a >> feature? >> . > Does NOP depend on a base register? > > -- > gil > > > -- > This email has been checked for viruses by Avast antivirus software. > http://www.avast.com/
Re: IEABRC anomaly
I just tested JNOP with a constant operand of "1" and the only issue is the warning-level message which results in RC=04: 74 A704 0001149 JNOP 1 ** ASMA056W Absolute value found when relocatable value expected - 1 IMHO that's not so bad that it should have been left out of IEABRC/IEABRCX, or perhaps provided as an option (e.g., with a GBLB setting that defaults to FALSE). The danger of NOT translating NOP to JNOP happens when the NOP operand is an actual DDD(I,B) based address, where the base is not an existing USING register. THAT results in an RC=08 error, not a warning: 74 049 NOP RETURN ** ASMA307E No active USING for operand RETURN OTOH, the RC=08 gives you a clear indication where you have to change the code when converting to relative branch logic. Water under the bridge, I know, and very unlikely to ever change. I can live with that. Peter From: IBM Mainframe Assembler List On Behalf Of Jonathan Scott Sent: Wednesday, May 1, 2024 11:15 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly As NOP is not a branch, I would not expect NOP to be converted by IEABRC. It is true that NOP has an address operand. If NOP is executed using EX with a suitable mask in the register it can be used for execution purposes, although this is rather obscure. However, as the address operand is not normally used for a branch, it might not work to convert it to relative. For example, I have seen code which uses NOP 1, NOP 2 etc. as markers for debugging purposes, which would definitely cause problems if changed to relative addressing. Jonathan Scott, HLASM IBM Hursley, UK -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: IEABRC anomaly
There is a B2D2 there just the mask is zero So it falls thru > On May 1, 2024, at 11:06 AM, Pieter Wiid wrote: > > NOP translates to BC 0 > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Paul Gilmartin > Sent: Wednesday, 01 May 2024 16:21 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: IEABRC anomaly > >> On 5/1/24 07:56:17, Seymour J Metz wrote: >> It turns out that IEABRC does not convert NOP to JNOP. Is that a bug or a >> feature? >> . > Does NOP depend on a base register? > > -- > gil > > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com
Re: IEABRC anomaly
As NOP is not a branch, I would not expect NOP to be converted by IEABRC. It is true that NOP has an address operand. If NOP is executed using EX with a suitable mask in the register it can be used for execution purposes, although this is rather obscure. However, as the address operand is not normally used for a branch, it might not work to convert it to relative. For example, I have seen code which uses NOP 1, NOP 2 etc. as markers for debugging purposes, which would definitely cause problems if changed to relative addressing. Jonathan Scott, HLASM IBM Hursley, UK
Re: IEABRC anomaly
NOP translates to BC 0 -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, 01 May 2024 16:21 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly On 5/1/24 07:56:17, Seymour J Metz wrote: > It turns out that IEABRC does not convert NOP to JNOP. Is that a bug or a > feature? > . Does NOP depend on a base register? -- gil -- This email has been checked for viruses by Avast antivirus software. www.avast.com
Re: IEABRC anomaly
On 5/1/24 07:56:17, Seymour J Metz wrote: It turns out that IEABRC does not convert NOP to JNOP. Is that a bug or a feature? . Does NOP depend on a base register? -- gil
