Thanks, John, for the test case. The problem reproduces at both
the latest maintenance level and at the oldest level I can find,
from 2011, so it appears to be previously unknown.
The problem is triggered by the unusually large end limit on
this statement:
USING (#PRGAREA,#E_RENT),R13
If I remove the end limit, or make it less than or equal to the
position of the referenced field, I get a message such as the
following:
0000B2 0000 0000 00000 104 LA R14,SAVE_FILES
** ASMA034E Operand SAVE_FILES beyond active USING range by 230138 bytes
I have noticed that when the message is produced, the numeric
insert is actually the amount by which the field offset exceeds
the end limit, not the amount by which it lies outside the
addressable range, so I suspect that the code is allowing
generation if either of those checks succeeds instead of
requiring them both to succeed.
We therefore have the information needed to debug this problem,
thanks, and we have added it to our known defect list. We may
get round to fixing it anyway eventually, but raising a support
case would definitely help justify producing a fix sooner rather
than later.
Note that since HLASM APAR PH42816 (from January 2022) you can
strictly limit the addressability range for both 12-bit and
20-bit displacement instructions by specifying those limits as
the third and fourth operands on the USING statement, for
example:
USING (#PRGAREA,,#PRGAREA,#E_RENT),R13
That is of course unnecessary when the range is in a separate
DSECT, but it can be useful for mapping part of a section, for
example after it has been copied to a dynamic area.
Jonathan Scott, HLASM
IBM Hursley, UK
