Tony H writes: > In the old version, the type attribute (T') of a macro operand of -1 > was U; in the new one it is, not unreasonably, N. This seems like a > positive change, but it actually broke a macro of ours ...
This particular change was APAR PH10081 in March 2019, which allowed decimal self-defining terms to be negative (making it possible to code -2147483648 as a valid operand) so all other checks for self-defining terms, including the type attribute, were affected as well. As self-defining terms could already be signed, for example X'FFFFFFFF' for -1, we did not think this was going to cause any problems, as all we were doing was extending that notation to include decimal numbers. However, we have since heard of other cases where macros were testing the type attribute specifically because they wanted to check for a positive decimal number, rather than generally for a self-defining term. We are not aware of any other cases in recent years where an existing program that assembles without error could be affected by maintenance to HLASM. Please let us know if you spot any! A simple way to get a summary report of APARs applied is to run HLASM with the INFO option. Jonathan Scott, HLASM IBM Hursley, UK
