>Does IBM guarantee that any macros it distributes will work
>correctly regardless of customers' setting of these options,
no. If a macro accepts KEY=PETER then it is your responsibility to get
PETER to the macro. That could perhaps be by typing KEY=PETER, or by
typing KEY=peter with COMPAT(MACROCASE) in effect, but not by typing
KEY=peter with COMPAT(NOMACROCASE) in effect. So maybe the answer is "yes"
rather than "no" -- the macro works correctly, but it's up to the user to
get the operand correct.
>Will macros be tested under all combination of these settings?
no. We rely on the assembler having correctly implemented what it
documents. As above, you should expect that PETER will be handled properly
if the macro is documented to accept PETER. And if you provide some other
value (including a mixed or lower case analog), you should have no
expectation about the result.
>some people suspect that IBM
>itself tests largely the PL/S branch and leaves testing of
>the assembler branch to customers.
That suspicion has merit given the too large number of errors in our
assembler macros but is incorrect.
>The misguided attempt to add case-insensitivity causes chaos
>and instability.
I think of pre-HLASM not as being "case sensitive" but as being "lower
case intolerant". I think of "case sensitive" really applying to "I treat
the characters Ab as different than aB". I believe that the assembler has
this sort of case sensitivity only if aB is within quotes. In other
situations it treats Ab the same as ab, aB, and AB.
I strongly disagree that the lower/mixed case support is misguided or
causes chaos (if that's what "case-insensitivy" is referring to). Quite
the reverse. I believe numerous studies have proven conclusively that
reading mixed (or even lower) case is far more effective for comprehension
than reading all upper case. Since our code is read a lot more than when
it is written (and you do read the code, not just the commentary), that
argues that code (not just comments) should in regard to readability not
be all upper case. Perhaps I am not understanding what "attempt to add" is
referring to, since that support was introduced many many years ago,
CASE/NOCASE has I think existed since the introduction of HLASM/ I'm not
sure about MACROCASE/NOMACROCASE.
I personally believe that case sensitivity (using my definition) is highly
unproductive and error-prone, as it forces the user to know exactly the
case that the definer used. If you're cutting and pasting, then it doesn't
matter much. But if you're typing.... And if you are writing code that
makes the user need to know whether he is using Case1 or CAse1 that is
highly error-prone.
IIRC, the assembler was somewhat late in providing a "make this operand
upper-case" function (as exists now via UPPER). If that had been part of
initial HLASM, then far more macros would be case-tolerant (accepting
upper, mixed, or lower case variants of many fixed-text operands such as
my "KEY=PETER"). Unfortunately, if my test was correct, the UPPER
function cannot, it appears, be used within an AIF as I would have
desired, using
AIF (UPPER('&OP') EQ 'PETER')
rather than having to do the UPPER as part of a SETC and then using the
result within the AIF.
Peter Relson
z/OS Core Technology Design
