Thank you, John!
This is a good solution, and it's a "doh" moment for me that I did
not think of it myself.
Your suggestion gives the equivalent functionality, So I'll adopt it,
but with a variation.
Ideally, I'd like to create your MNOP macro in my macro library, but
then OPSYN won't work.
But I don't want to have to define an in-line MNOP macro definition
in every assembly.
Similarly, I could pull in a library resident MNOP macro with a COPY
statement, but again, I do not want to have to do that in every
assembly either.
So instead, I'll create a do-nothing PRINT macro (and EJECT and TITLE
macros) that I can put into maclib. Then when I want the assembler to
use it, I'll just issue "PRINT OPSYN ," to nullify the assembler
statement, thus forcing the assembler to pull in the macro from maclib.
Again, thanks for the suggestion. I'm happy with the workaround.
Best,
Dave Cole
dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)
At 9/28/2021 08:19 AM, Jonathan Scott wrote:
Ref: Your note of Tue, 28 Sep 2021 07:47:02 -0400
Steve Smith <sasd...@gmail.com> writes:
> From reading the APAR, it seems HLASM thought it better to
produce ASMA001E
> rather than (potentially) ASMA951U. I can't see it was worth
breaking Dave
> Cole's scheme. It seems that ANOP is on the "restricted" list,
and you'll
> have to OPSYN to something that isn't. And hopefully that
doesn't mess the
> scheme up too much. Or maybe IBM can be persuaded to allow ANOP as a
> special case.
ASMA951U is a "should not occur" error where the internal
representation of the macro is somehow corrupted, and from
debugging we found that it was caused by failing to check for
generation of a restricted opcode via OPSYN, resulting in a bad
branch. The existing code only checked the generated opcode
type if it had been generated by substitution. The simple fix
was to remove the substitution test and check unconditionally
whether the generated opcode is marked as restricted,
automatically including the OPSYN case.
At the time we coded APAR PH30060, we were unaware that people
were using the PRINT OPSYN ANOP trick, and even then it works
fine provided that it is issued before the macro is first
referenced (so that it takes effect at definition time).
The PRINT OPSYN ANOP trick however came to our attention when we
started getting reports that SHOWZOS was getting ASMA001E
errors. A general solution is to define PRINT as an OPSYN for a
inline no-operation macro, for example:
MACRO
MNOP
MEND
PRINT OPSYN MNOP
In that case, the PRINT operation can be enabled and disabled as
for existing PRINT OPSYN statements, with the only difference
being that the OPSYN is for MNOP rather than ANOP.
Jonathan Scott, HLASM
IBM Hursley, UK
