We've just shipped the PTFs for HLASM APAR PI97142, which fixes
up quite a few loose ends in options processing, especially some
oversights in OPTABLE processing. When support for dynamically
changing the OPTABLE with *PROCESS and ACONTROL was added,
several implications of this change were not spotted at the
time, and there have been several fixes to this area over the
years as people have started to exploit this function.  For
example, only a few weeks ago APAR PI95384 fixed OPSYN to ensure
that it applied to all OPTABLEs in which the relevant
instruction instance was defined, not just the current optable,
ensuring that IEABRCX was still able to convert branches within
code which used ACONTROL to switch to a different OPTABLE.

As part of APAR PI97142, the ASMAOPT macro which is used to
generate the installation default options module ASMADOPT now
supports the option ILMA=YES, which ensures that in-line macros
are automatically assumed to apply to all OPTABLE instruction
sets. However, for "compatibility" with the situation before
this option was provided, the default is currently ILMA=NO.

I personally do not understand why it was previously considered
a good idea to provide the ILMA/NOILMA option to preserve the
original undocumented and unhelpful behaviour, as I cannot think
of any good reason to support the capability to define different
macros of the same name for different OPTABLE values. I'd agree
that it's possible to invent a way to use this function, for
example to generate different instructions within macros for
different OPTABLEs, but it is already possible to do that with
the existing capabilities for a macro to test the OPTABLE value
(or to achieve a similar effect by testing the operation code
attribute of an opcode to determine whether it is supported for
the current OPTABLE).

As the current HLASM team leader, I am considering changing the
default in the supplied defaults module to ILMA=YES, which
although technically incompatible is far more useful, and might
help reduce the frequency with which we have to tell users that
specifying the ILMA option will fix their problems.  I would
like to know if anyone on this list has any opinions on this
change, especially if they are aware of any possible negative
impact of this change.

(If an installation has its own default options module and
does not reassemble it after this change, they would not
pick up the new default of ILMA=YES until they reassembled it
or dropped back to the supplied default options module).

Jonathan Scott, HLASM
IBM Hursley, UK

Reply via email to