We've recently shipped some little enhancements which might be of interest. See the APAR descriptions via the URL links for full details.
APAR PH03536 - OPTABLE and MACHINE enhancements See: http://www.ibm.com/support/docview.wss?uid=isg1PH03536 - To make it easier to associate OPTABLE values with IBM Z machine generations, you can now use OPTABLE values Z9 to Z14 instead of ZS3 through ZS8. - Additional MACHINE alias names have been defined, for example z196 and ARCH-0 to ARCH-12, matching the compiler convention. - MACHINE can now be specified on *PROCESS and ACONTROL, having the same effect as the corresponding OPTABLE option. APAR PH06374 - &SYS_HLASM_DATE containing HLASM PTF build date See: http://www.ibm.com/support/docview.wss?uid=isg1PH06374 - There is a new symbol &SYS_HLASM_DATE which contains the date HLASM was built, in the form yyyymmdd, which is usually the date the latest PTF was built. This makes it possible to determine whether a fix is present by checking whether the value is greater than or equal to the date of the corresponding entry in the INFO report. - To avoid errors when referencing any new symbol on older levels of HLASM, it is possible to define a created SET symbol of the same name, which will be referenced if the system symbol is not defined, for example as follows: &(SYS_HLASM_DATE) SETC '00000000' Default low value AIF ('&SYS_HLASM_DATE' LT '20181231').OLD This method is also valid for all previous releases of HLASM. It works because a created SET symbol reference is always taken to refer to a SET symbol, not to a system variable symbol or macro parameter. APAR PH06572 - Truncation checks for DC constants See: http://www.ibm.com/support/docview.wss?uid=isg1PH06572 - This introduces three new options FLAG(TRUNC), FLAG(LONGER) and FLAG(SIGNED) which provide optional warnings for cases where the nominal value for a DC constant may have been changed by truncation. We are hoping to find a way to extend these warnings to cover immediate values in instructions, but the existing rules are very different for signed and unsigned immediate operands, making it difficult to come up with a neat general solution that covers both. Jonathan Scott HLASM Development IBM Hursley, UK
