I can't remember where this is fully documented, but 64-bit storage is
currently divided into about five types: Restricted (2G-32G), LSA, Low
(sic) User Region, Common, and Shared. On my test system, LSA starts at
x'8_00000000', User region at x'48_00000000', Common at x'1EF_80000000',
and Shared at x'200_00000000'. Most of these are configurable, but I
suspect these are the current (z/OS 1.12 - 2.1) defaults. There is a
High User Region, and others, that I don't believe are actually
implemented yet.
I have no idea what VM and VSE provide.
A regular IARV64 gets memory in the Low User Region. Unauthorized
programs can't get anything else.
sas
On 11/5/2014 18:07, Tony Harminc wrote:
On 5 November 2014 16:19, Paul Gilmartin
<00000014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
The bar is infinitely thin,
I'll trust you; the manual appears not to affirm what others say.
Architecturally (at both the P of O and z/OS levels) the bar may well
be infinitely thin, but that doesn't mean that IARV64 and friends will
hand you an address between 2GiB and 4GiB. I'm not sure why you seem
to find such great significance or puzzlement in this. Virtual storage
addresses in the 64-bit range are -- for the moment, at least --
almost unimaginably abundant, and it seems unremarkable that a system
service should do this little thing to avoid a certain class of
programming error. For all I know IARV64 may have other ranges that it
doesn't allocate from; does some programming technique depend on this
not being the case?
Tony H.
