That is an excellent overview of z/OS virtual storage. Now that you've
reminded me, I believe that's where I got a lot of my knowledge of
64-bit space.
One more thing, is that I think that storage above the 512TB "barrier*"
is currently unsupported, as I also think that the Region-1 table for
DAT isn't supported yet. I don't see that as much of a limitation in my
lifetime (being middle-aged... assuming I live to 114). Anyway, I'd
like to know of any testimony or evidence to the contrary.
*I'm not intending to coin the term, if it even needs one.
sas
On 11/6/2014 11:07, Dale R. Smith wrote:
On Wed, 5 Nov 2014 14:19:59 -0700, Paul Gilmartin <[email protected]> wrote:
On 2014-11-05, at 13:11, Walt Farrell wrote:
On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin <[email protected]> wrote:
Nevertheless, as long as z/OS and z/VSE exclude 2GiB <= address < 4GiB,
I prefer your interpretation. Is "bar" prevalent in VM or Linux argot?
But z/OS does not exclude that range anymore, gil, as others have said. It is
true that STORAGE OBTAIN will not give you those addresses, but it never gave
them to you before we had 64-bit addressing either. STORAGE OBTAIN deals with
31-bit addresses and storage.
I don't recall that anyone has said "z/OS does not exclude that range anymore".
In fact most of the plies in this thread seem to say that range is excluded
and it's a good thing.
The addresses between 2G and 4G are valid via other mechanisms, though they were initially
restricted when z/OS >>implemented 64-bit storage. You simply have to use those other
mechanisms for any usage of storage above 2G (that is, >>for any 32- to 64-bit
storage addressing).
Take a look at this presentation:
http://proceedings.share.org/client_files/SHARE_in_Boston_2/Session_7511_handout_419_0.pdf
