What about the following suggestion?
MACRO ,
&LABEL DIAG &R1,&R2,&I1
&LABEL DS 0H
&X SETC '&SYSNDX'
IHB&X LA &R1,&I1.(&R2.,0) Diagnose
IHB&X.A DS 0H
ORG IHB&X
DC X'83'
ORG IHB&X.A
MEXIT
MEND
If is is absolutely necessary to avoid the relative addressing *-4
and *+3 in the ORG instructions (I don't see the reason for that,
the lengths are well known and fixed, there is no danger doing so),
you could do it this way, spending two new labels using &SYSNDX.
But isn't my point valid, that the first ORG will not work in
John G's solution, in the absence of a label on the macro call?
Every macro caller, IMHO, should be free to specify a label
on the macro call, or to omit it (if, like in this case, the
macro generates an instruction or a sequence of instructions
that just can be stepped into).
This, BTW, is "bullet proof", IMHO. If there are any errors in the
macro call, they will show up either on the generated DS 0H or on
the generated LA, so the macro needs not to take care about it.
There is no need for such simple macros to do futther tests. But:
a macro which shows no syntax error in assembly should produce the
expected code, and this is not the case in John G's solution.
Kind regards
Bernd
Am 21.12.2013 19:20, schrieb John Gilmore:
Steve Comstock wrote:
<begin extract>
Neither version is bullet proof, but Ed's works in both cases of a
label supplied or not (neither of which is an error, so 'bullet
proofing' for a missing label is really irrelevant).
</end extract>
and this---Let me quote him---is
Nonsense!
When someone writes a macro definition he or she is free to make the
omission of or a putatively inappropriate value of any symbolic
parameter an error, as I did with the skeletal sample lines that
tested for the presence or absence of a label in the DIAG macro
instruction. In general the omission of a label may be innocuous in
one context and a severe error in another, in the judgment of the
writer of a particular macro instruction.
Bullet proofing is never irrelevant. It is tedious, certainly; but
the only appropriate stance for the writer of a production macro
definition is that those who write macro instructions that use it will
be ignorant, malicious or perhaps both.
Ed Jaffe's point is more substantial; but, as he well knows, there are
simple ways to guard against the difficulty he raised. Indeed, there
are alternative ways to induce the assembler to do the necessary
arithmetic without resort to the magic numbers 3 and 4, which still
seem to me to be ugly.
I do not at all mind being ganged up upon. Let's do it again sometime soon.
John Gilmore, Ashland, MA 01721 - USA
