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