On 12/10/2012 7:58 AM, John Gilmore wrote:
Now it is clear that these addresses (or null pointers) must be
doubleword, AMODE(64) ones and that executables that access them and
make use of these addresses must also be AMODE(64)...
It is and has been my contention that to mark such table objects as
AMODE(x) when x is not 64 is hubristic at best. It would now, I
think, be perverse to do so. They can be loaded below the line (sic).
They cannot usefully be accessed by other than AMODE(64) code,
wherever they may be resident.
I agree you should mark these modules AMODE(64). Why? Because it is in keeping
with the existing rule that AMODE cannot be more restrictive than RMODE and
you've made it perfectly clear that you would link these modules RMODE(64) if
you could.
Consider a module with AMODE(24), RMODE(24). One can readily change it to
AMODE(31),RMODE(24) or even AMODE(64),RMODE(24). But, the moment you try to link
the module with RMODE(31), the AMODE(24) option is disallowed:
IEW2322I 1220 25 MODE AMODE(24),RMODE(31)
IEW2658E 5119 USER-SPECIFIED AMODE(24) AND RMODE(ANY) ARE INCOMPATIBLE.
Likewise, it's pretty obvious that AMODE(64) will be the only allowable
addressing mode in a hypothetical future in which the binder allows direct
specification of RMODE(64). Why not get a head-start and specify that now?
P.S. the binder already supports RMODE(64) program objects that contain C_WSA64
data classes only. These program objects will be loaded above the bar by program
fetch. I have not yet seen them used, but I suspect the AMODE values on such
program objects are always AMODE(64).
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
