Ref: Your note of Fri, 7 Nov 2014 06:12:17 -0700 > On 2014-11-07, at 02:15, Jonathan Scott wrote: > > > > It is obviously necessary to ensure that any case which is already > > supported by HLASM should continue to be processed in exactly the > > same way for complete compatibility. > > > I disagree. I believe that one case in which HLASM produces an > algebraically incorrect base-displacement resolution (but perhaps > this should be considered not "support" but "defect") should > result in "could not be resolved". > > -- gil
If a product does something which is not consistent with its own documentation, then that's clearly not "supported". The solution in such cases depends on consideration of the potential impact of any change, and may involve either changing the code or the documentation (or a bit of both). Although there are well known defects in the area of overflow or wrap relating to HLASM address calculations, I don't recall ever hearing of any customer problem report being submitted for this. In this particular case, it's a bit tricky anyway. HLASM fails to detect overflow and wrap in certain cases, but as always there are cases where intermediate results could wrap but the final result could be correct. As the addressability calculations are implicit, the user does not have direct control over the expression evaluation. Perhaps a workable general rule would be to make it work as if HLASM did addressability calculations using longer arithmetic then only checked for overflow when mapping the final result back to 31-bit signed. Jonathan Scott IBM Hursley, UK
