Another alternative is to OPSYN delete the new instructions that conflict. I think that will work: I rtfm, but not tested.
Personally, I think adding :MAC would just be more work. You might as well rename the macro. While I really find gratuitous usage of national character prefixes to be ugly, it does tend to future-proof macros named with such, as I think we can assume IBM won't ever invent an instruction mnemonic that starts with one. Anyway, nothing here looks nearly as bad as the infamous introduction of the MSG operation. sas On Sat, Apr 16, 2022 at 5:35 PM Paul Gilmartin < [email protected]> wrote: > On Apr 16, 2022, at 14:22:59, Ed Jaffe <[email protected]> > wrote: > > > > We just applied this APAR to our systems: > > > > https://www.ibm.com/support/pages/apar/PH39324 > > > ... which links to a "Fix Readme" with recommendations > for dealing with possible clashes between 30 new > instruction mnemonics and customer-defined macro names. > > One suggested remedy is: > If the macro names cannot be easily changed, then > the programs can use the ":MAC" suffix to ensure that > the macro is used rather than the instruction. > > Would defensive programming recommend that all macro > invocations use the ":MAC" suffix lest a name become > an instruction mnemonic in the z17? > > An alternative not mentioned might be if references > are numerous to COPY the affected macro definitions > into source programs. > > -- > gil >
