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
[email protected] (personal)
[email protected] (business)
540-456-6518 (cell)
