We have just shipped APAR PH12052 which enables general support
for built-in functions such as ISSYM in arithmetic and logical
expressions, as requested several times on this mailing list,
for example:
AIF (K'&DD LE 8 AND ISSYM('&DD')).DDOK
The IBM Support Portal may take a day or two to catch up, but the
PTFs have closed in RETAIN. In the mean time, here's the closing
text from the APAR:
--- Start of copied text ---
PROBLEM SUMMARY:
The following built-in functions which take a character operand
and return an arithmetic or logical result could only be used as
the only term on the right hand side of a SETA instruction:
B2A, C2A, DCLEN, D2A, ISBIN, ISDEC, ISHEX, ISSYM, X2A.
If any of these functions was used within parentheses (including
on a SETB or AIF instruction) then this was rejected as an
invalid nested function. If additional terms were used in a SETA
instruction, there were even cases in which the results could
simply be incorrect without any error message.
These functions were originally made available in HLASM R5 and
were intended to be used without such limitations, but an
obscure internal problem caused them to give unpredictable
results, including abend 0C1. The failing cases were therefore
mostly disabled as a "temporary" fix by APARs PK15306 and
PK27577 which caused message ASMA021E with an insert of "Invalid
Nested Function" to be issued in cases where the function was
within parentheses or within a logical expression. However,
SETA expressions with more than one term could still give
incorrect results without producing an error message.
HLASM R5 APAR PK27540 was then scheduled to fix the problems,
but this APAR was cancelled, and replacement APAR PM40634 for
HLASM R6 was closed as a future requirement.
Another problem in the same area was that if a function operand
was accidentally coded in a form which was not a valid character
expression, such as ISSYM(&DD) instead of ISSYM('&DD'), then
this did not produce an error message but could cause abend 0C1
or other errors during macro processing.
CONCLUSION:
All of these built-in functions can now be used in arithmetic
and logical expressions (on SETB and AIF), including within
parentheses. Note that a logical expression must always be
enclosed in parentheses, even on SETB, to support logical
operators delimited by spaces.
If an arithmetic built-in function requires a character operand,
then an operand of the wrong type will now be rejected.
It is still recommended that SET expressions and AIF statements
should not include complex use of built-in functions, especially
nested within operands of other functions. For compatibility
reasons, the current implementation only imposes a few specific
restrictions, but some arithmetic functions will definitely not
be recognised when used nested within the operands of other
arithmetic functions.
These fixes address specific known problems, but it is possible
that certain cases may still cause unpredictable results without
causing an error message. If so, please report this as a product
defect to enable further investigation.
--- End of copied text ---
This problem had been made more difficult to debug by the fact
that some trivial test cases gave the correct result by a total
fluke and misleadingly implied that the problem was not within
the area which was actually at fault. However, some very patient
and time-consuming debugging (with ASMIDF) confirmed the actual
cause of most of the problems, which was an incorrect operator
priority value, causing evaluation to occur in the wrong order.
As this area had never fully worked properly, it had not been
very thoroughly exercised, and we found and fixed a few more
minor bugs during testing of the APAR. We also spotted that the
existing function parsing logic uses some additional variables
which are not pushed and popped during processing of nested
expressions which means that some functions will still not be
considered valid in complex nested contexts. We have noted the
requirement to fix these remaining limitations in the long term
but see this as a much lower priority than the current fix.
Jonathan Scott, HLASM
IBM Hursley, UK
