Oppolzer - Informatik / Blog

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 J.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 J.G.'s solution.

Kind regards

Bernd



Am 21.12.2013 19:20, schrieb J.G.:
> S.C. 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.
>
> E.J.'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.
>
>
> J.G.
>