Ref: Your note of Wed, 16 May 2018 10:30:18 -0400 Steve Smith writes: > I certainly agree, and although I suppose it's virtually impossible, I'd > get rid of the option altogether. As you state, it's practically > inconceivable anyone would exploit that hole. I realize that protecting > compatibility is important, but let's be reasonable.
Thanks for the feedback. We definitely have to continue to accept the ILMA/NOILMA option in order to avoid causing errors in existing assembly jobs or source files that specify it. It's probably not so important that NOILMA actually does anything, but as the option has been implemented all we need to do is to change the default. It should really also apply to SYSLIB macros. When a SYSLIB macro is found, it is read into storage and an entry is added to the current OPTABLE referring to that copy of the macro, so if the same macro is used after changing OPTABLE, it is not found in the OPTABLE and a new copy is loaded, which is generally harmless apart from being inefficient. This code is used for inline macros too, but when the ILMA option was added the programmer decided for some reason to add a specific check to make it apply only to inline macros. My guess is that the culture of "if it ain't broke, don't fix it" led to an excess of caution in this case. So if we do ship an APAR to change the default, I might well suggest that we also apply the same logic to SYSLIB macros (which would merely involve deleting the check for an inline macro). Jonathan Scott, HLASM IBM Hursley, UK
