I use the following technique for YES/NO type variables:
FOO &UPCB=YES
&uUPCB SETC (UPPER '&UPCB')
AIF ('&uUPCB' EQ 'NO').OK
AIF ('&uUPCB' EQ 'YES').OK
MNOTE 8,'Invalid UPCB= value, specify either YES or NO'
MEXIT
.OK ANOP ,
All subsequent references in macro are to &uUPCB instead of &UPCB.
And you can alter &uUPCB to a default value if &UPCB was not specified or
nullified, whereas you cannot alter a macro parameter value.
Robert Ngan
CSC Financial Services Group
IBM Mainframe Assembler List <[email protected]> wrote on
2014/07/23 10:44:17:
> From: John Gilmore <[email protected]>
> To: [email protected]
> Date: 2014/07/23 10:44
> Subject: The rationale for using macros i
> Sent by: IBM Mainframe Assembler List <[email protected]>
>
> What follows, in a sequence of posts having this same title suffixed
> with the successive roman numerals i, ii, . . . , is an attempt to
> restate the case for macro-intensive use of the HLASM.
>
> Much of It is perforce language-specific. The macro language of the
> HLASM is a powerful (string-processing and arithmetic) statement-level
> procedural language embedded in the assembler. The macro languages of
> other assemblers are usually different from and much inferior to that
> of the HLASM, so much so that much of what follows here would be
> inapplicable to them.
>
> First, some generalities. The classical criticisms of assembly
> languages are 1) that they are long-winded and detail-ridden and 2)
> that assembly-language routines are not portable from one machine
> architecture/platform to another. Macros can very largely eliminate
> prolixity and déjà vu; they can only mitigate portability problems.
>
> The arguments for the use of assembly-time macros are very like the
> arguments for the use of execution-time subroutines. They encapsulate
> a repeatedly required function; and, once written, tested, and
> documented in situ, they can be used over and over again without much
> fear that they will bite, that they will themselves be the source of
> errors.
>
> Another important argument for their use is that they can make
> techniques available that many of their users do not or cannot
> otherwise employ.
>
> An example will help here. Many macro definitions have keyword
> parameters of the form
>
> | . . .
> | whatever=yes, -- |no
> +
> | . . .
>
> or, of course,
>
> | . . .
> | whatever=no, -- |yes
> +
> | . . .
>
> I have seen much code that examines the value of &whatever to
> determine whether it has, say, the value 'yes' and then, if it does
> not, assumes that it instead has the value 'no'. A better approach
> is to write a macro definition, call it YESNOCHK, that
> can recognize any CIDT (case-independent disambiguating truncation) of
> yes or no, viz., any of no|nO| No| NO| n| N|
> yes|yeS|yEs|yES|Yes|YeS|YEs|YES, setting two binary/boolean created
> set symbols, one to indicate recognition|non-recognition of an input
> and the other to specifiy the boolean value of a recognized input.
>
> In fact one can go further. This is a special case of a more general
> problem. Consider that of recognizing one of the elements of the set
>
> dither
> wait
> tergiversate
> start
> falter
> delay
> stop
> procrastinate
> waver
>
> given a putative, not necessarily proper CIDT. We first put them into
> ascending lexicographic sequence, padded on the right with nuls,
> x'00', to make their lengths equal, and then note the leftmost
> character position in which each differs from its predecessor and/or
> successor.
>
> The result is
>
> delay, de, 2
> dither, di, 2
> falter, f, 1
> procrastinate, p, 1
> start, sta, 3
> stop, sto, 3
> tergiversate, t, 1
> wait, wai, 3
> waver, wav, 3
>
> We can now 1) use lub-seeking binary search in an assembly-time table
> and then 2) iff this search is successful, determine whether the
> search argument is a CIDT, whether, that is, it matches the leftmost
> substring of its lub of its length and this length is greast enough,
> that, for example, all of
>
> o sta, star, start, are recognized as instances of start,
>
> o sto, stop are recognized as instances of stop, and
>
> o s and st are not recognized as instances of either.
>
> This machinery can be, and in my macro CIDTTCON is, entirely
> automated. It generates macro definitions containing already
> initialized tables. YESNOCHK is not written; it is generated.
>
> Now this example is trivial, but it does illustrate that power and
> convenience are available to those who will but [learn to and] write
> macro definitions. It also illustrates one of the chief merits of
> macros. They can be used to treat an entire class of problems, not
> just one instance/special case of that class.
>
> Worth noting explicitly is that the traditional definition of a macro
> as a mechanism for generating many lines of code from only a few of
> them is, while not entirely wrong, inadequate. Many of the most
> useful macros in my libraries do not generate even a single line of
> code. Others use them to generate code. Created global set symbols
> and arrays of them have made it possible to get data out of macros as
> readily as one puts data into them.
>
> An important characteristic of many of these service macros is that
> other programmers need to know only what, functionally, they do. They
> are also welcome to learn how these macros do what they do, but many,
> regrettably, do not do so. Deadlines make intellectual curiosity
> expensive.
>
> More in subsequent instalments.
>
> John Gilmore, Ashland, MA 01721 - USA
