Ref: Your note of 19 January 2018, 17:50:02 EST
Mark Boonie wrote:
> I spent an hour or so fighting with my build environment because
> I thought it was ignoring my options, but now I think I have an
> HLASM bug. I'm specifying OPTABLE(ZS6,LIST) as a *PROCESS
> option. The "Options for this Assembly" page shows that the
> option has been processed correctly ("3 Invocation Parms
> OPTABLE(ZS6,LIST)"), so the option should be in effect, but in
> the opcode-table section of the listing, the mnemonic RISBG
> doesn't appear, and it's getting flagged in the assembly with
> message ASMA057E, undefined operation code. (RISBG is a
> ZS4-level mnemonic.)
Strangely enough, I already spotted last week that *PROCESS OPTABLE does
not work as it should, while checking an odd result encountered while
setting up tests for the recent APAR PI87412 (where an unknown ACONTROL
OPTABLE value was quietly being ignored, because it was trying to issue
a *PROCESS error message instead of an ACONTROL one).
In particular, if *PROCESS OPTABLE issues a warning that something is
being overriden, it can issue the wrong warning and can end up changing
the OPTABLE name (which it shouldn't) without actually changing the
internal OPTABLE selection mask.
Also, *PROCESS OVERRIDE OPTABLE does not work, apparently because the
code was cloned from code for a *PROCESS option (MACHINE) which does not
support OVERRIDE, even though OPTABLE does support OVERRIDE.
While debugging these problems, we also found other related problems,
so we are doing a thorough review of this area to try to ensure that
all option processing conforms to the documented rules.
We also noted that there are inconsistencies in whether or not a message
is issued when a specified option overrides a previous specified option,
in that although the message is set up internally, some of the keyword
routines fail to use it.
We are attempting to find a reliable solution which will fix these
inconsistencies. We are also considering updating the documentation
to make it extra clear that *PROCESS OVERRIDE effectively serves two
purposes:
1. For an option which can be changed by *PROCESS, the OVERRIDE
option quietly ensures that the specified value is used.
2. For an option which cannot be changed by *PROCESS, the OVERRIDE
option can be used to verify that the intended valid being used,
as it will issue a warning if the value does not match, even
though it cannot change it.
I'd expect to see an internal APAR for this within a few days and a fix
for it within two or three weeks. No guarantees, of course, but if you
don't see anything happening soon enough for your requirements, you're
welcome to raise a PMR yourself.
Jonathan Scott
HLASM, IBM Hursley, UK
