Thanks for the explain and history Jonathan. Much appreciated. -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Jonathan Scott Sent: Thursday, July 7, 2022 5:42 PM To: [email protected] Subject: Re: Type attribute changes in a new HLASM version
Caution! This message was sent from outside your organization. The general rule is that HLASM programs which assemble without error should always continue to generate compatible binary code, preferably identical. In this case we failed to spot that people could be using the type attribute to test for a self-defining term and assume that it was positive as a result, because self-defining terms can also be hexadecimal, binary or character, all of which can already have negative values. We sometimes have to make an exception if a program is in error but HLASM failed to detect it. The only "incompatibility" I am aware of in that category relates to APAR PH30060, which added a missing check to detect when an opcode had been changed to a reserved macro opcode using OPSYN between the time the macro was defined and the macro was executed. This check was done if the opcode was generated by substitution, giving message ASMA001E in that case, but was overlooked if the instruction was changed using OPSYN. The result was likely to be HLASM terminating with ASMA951U because of a bad branch, which is what the APAR fixed, but after fixing it we found that someone had been changing PRINT to ANOP with OPSYN and had been getting away with it because in that case the bad branch happened by chance to cause the operation to be ignored! That was easily solved by defining a dummy PRINT macro instead. We sometimes also make harmless changes which affect the object code (although we try to avoid those if possible). Many years ago, when quadword alignment was introduced, support for 16-byte aligned literals was added as a separate alignment level, so existing programs which happened to have 16-byte literals now had those generated before all 8-byte literals, instead of being included in the 8-byte alignment group. (I would personally have said that should only have been done when 16-byte section alignment was in effect, to avoid unnecessary differences, but that was before my time in HLASM). More recently, we discovered some inconsistencies in how literals got defined. Some references to literals in macros were causing the literal to be defined at the time the macro was defined, even if the relevant statement was never reached when the macro was executed. Also, references to attribute of literals (in particular the length attribute) were causing the literal to be defined even when there was no reference to the literal itself, so it was not needed. These problems were fixed as part of APAR PH43846, which can therefore mean that some unreferenced literals will no longer be generated, but this was considered safe enough because it will never cause generation of additional literals. Jonathan Scott, HLASM IBM Hursley UK
