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).
>
OK. I'm out of date in my reading. Perhaps IARV64 GETSTOR? But
are any earlier contributors to this thread apt to be rudely
surprised if they unexpectedly need to deal with storage in that
range.
I can imagine a service that accepts 64-bit argument addresses,
but requires that certain arguments be in 31-bit storage. Such
a service might verify by
o Setting bit 32 to 0
o comparing the 64-bit result to 0000 0000 7fff ffff.
Does anyone do this? I'd be inclined simply to fail if a
supplied 64-bit address is not properly below the bar.
I see:
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ieaa900/iea3a9_Description1.htm
IARV64 — 64–bit virtual storage allocation
Description
z/OS MVS Programming: Assembler Services Reference IAR-XCT
SA23-1370-00
The macro creates and frees storage areas above the two gigabyte address ...
Yup. No exclusion for 2GiB <= origin < 4GiB. And, incidentally:
..., [] storage above the two gigabyte address, called above the bar.
The bar is infinitely thin,
I'll trust you; the manual appears not to affirm what others say.
Thanks,
gil
