PRINT OPSYN ANOP

[David Cole]

This is about debugging a complex mesh of macro calls when PRINT OFFs
and PRINT NOGENs are used by the macros.

When print suppression is scattered all hither and yon throughout a
complex set of inner macros, debugging subtle problems can be
seriously hindered. So how do you easily get rid of print suppression?

For over five decades, I've been using PRINT OPSYN ANOP to do this.

Bingo! everything (and I do mean EVERYTHING!) gets emitted to
//SYSPRINT. It's quick, it's easy, and it's effective.



But now, after more than 50 YEARS, HLASM development has decided to
change the rules! Starting with the advent of
https://www.ibm.com/support/pages/apar/PH30060, my macros are
intermittently failing with ASMA001E.

There are, of course, good reasons to issue PRINT/TITLE/EJECT OPSYN
ANOP statements from *within* macros, not just globally outside of
all macros. This is something that's worked fine and now suddenly is failing.

Examples? Some of IBM's own cblock mapping macros use PRINT OFFs,
PRINT NOGENs, TITLEs and EJECTs in exasperating and highly
inconsistent ways. So I have written a very large set of #cblockname
macros to provide standard envelops for IBM's hodgepodge. For instance:

- REXX's Environment Block mapping macro is named IRXENVB.

- IRXENVB use the EJECT statement in a way I wish it wouldn't.

- So my envelop macro (#RXENVB) contains the following statement sequence:
TEJECT OPSYN EJECT SAVE
EJECT OPSYN ANOP SUPPRESS
IRXENVB ,
EJECT OPSYN TEJECT RESTORE

That's worked for 30+ years, but it now fails!



So I have two issues:

1) Why has the HLASM development team suddenly decide to break what
has worked so well for so long???

2) Can anyone think of an alternative way to eliminate unwanted
PRINT, TITLE and EJECT statements as invisibly and as
non-disruptively as turning them into ANOPs does?


Thanks,

David Cole
dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)

[Martin Ward]

On 28/09/2021 11:53, David Cole wrote:
> When print suppression is scattered all hither and yon throughout a
> complex set of inner macros, debugging subtle problems can be seriously
> hindered. So how do you easily get rid of print suppression?

I use the assembler option:

PCONTROL(GEN,MCALL,ON)

This overrides all PRINT directives to turn on printing,
ensures that all macro calls are printed along with
all macro expansions.

--
Martin

Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4

[Jonathan Scott]

Ref: Your note of Tue, 28 Sep 2021 06:53:32 -0400

The quick and safe solution to suppress PRINT instructions is to
define a dummy inline PRINT macro that does nothing.

PRINT OPSYN ANOP is legal if used before a macro is defined, but
it is not allowed to be used at generation time when it was not
in effect at definition time, because it dynamically generates a
restricted instruction that should have been converted to an
internal form at macro definition time, as documented for
message ASMA001E.

This resulted in a wild branch because the vector of branch
addresses to handle generated instruction types does not include
types which should have been encoded at macro generation time,
which use a different range of codes. For ANOP, the branch just
happened to have the effect of ignoring the instruction, but for
other instructions this could for example cause termination with
message ASMA951U. This was fixed for APAR PH30060, at which
point the ASMA001E check was corrected to take into account
OPSYN as well as instruction mnemonics created by substitution
(and other related loopholes were also fixed).

We have been considering adding code to tolerate ANOP as a
special case in this context, but we feel that special cases
like that are generally to be avoided when there is a perfectly
good alternative that doesn't break any rules.

Jonathan Scott, HLASM
IBM Hursley, UK

[Steve Smith]

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.

PCONTROL is great for overriding PRINT, when you really want to see what
macro authors are hiding, but it doesn't do anything for TITLE & EJECT
abuse.

https://xkcd.com/1172/

sas

[Jonathan Scott]

Ref: Your note of Tue, 28 Sep 2021 07:47:02 -0400

Steve Smith <sas...@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.

[David Cole]

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)