Nice sleuthing Mr. Scott! Now back to the engine room. 😊
-----Original Message-----
From: IBM Mainframe Assembler List <[email protected]> On Behalf
Of Jonathan Scott
Sent: Monday, September 5, 2022 1:13 PM
To: [email protected]
Subject: Re: Missing ASMA034E message
Caution! This message was sent from outside your organization.
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
