Robert Ngan writes:
> Maybe what we need is a new HARDWARE table type that groups by instruction
> availability instead on mnemonic introduction (I was going to suggest
> MACHINE but that already used as a synonym for OPTABLE).

The reason that HLASM does not retrofit new mnemonics to old
tables is compatibility.  If a local macro had the same name as
a new instruction mnemonic, then applying maintenance which adds
a new mnemonic to an old table could break compatibility.  This
can still happen with OPTABLE(UNI) but for other tables HLASM
now has a policy of avoiding any further updates after the table
has been created.  (This was as a result of reports of customer
and IBM product problems specifically caused by maintenance
adding new mnemonics to existing tables).

Sometimes a new instruction is provisionally expected to be made
available after initial hardware GA, in which case HLASM needs
to define the new instruction mnemonic and format in advance to
avoid the need to update an existing table.  This was done for
the SORT LISTS (SORTL) instruction.  When this happens, there is
no guarantee that the instruction will actually become
available, but for SORT LISTS it was announced a little later.
Some other instructions have been quietly removed from previous
tables because they were never made generally available.

So the specific tables remain in step with the edition of
z/Architecture Principles of Operation in which the mnemonic was
introduced, even if it is an extended mnemonic for a hardware
instruction which was already available.

The table which I am trying to get added to the Programmer's
Guide refers to the base instruction for any extended mnemonic,
so it is then possible to check when that became available.

In some cases such as LFI, if LFI is undefined but IILF is
defined (which can be tested using O'LFI and O'IILF) then it
is safe to use LFI OPSYN IILF to define it anyway.  However,
for more complex cases such as the high/low shift mnemonics
this would require macro logic to handle the mapping.

Jonathan Scott, HLASM
IBM Hursley, UK

Reply via email to