2GiB <= address < 4GiB

[Paul Gilmartin]

I know that z/OS STORAGE OBTAIN will never return a block of storage
with 2GiB <= address < 4GiB. But what's the rationale for this?
ISTR that I once knew, but I've forgotten, or always misunderstood.
Is there a superstitious phobia of having bit 32 of a 64-bit
address be 1? If so, isn't 6GiB <= address < 10GiB similarly
offensive? Is it because 2GiB <= address < 34GiB is dedicated
to Java?

-- gil

[Tony Thigpen]

The first bit of the address in the PSW indicates that the address is a
31 bit address. So, there was ambiguity for any address with the first
bit set on.
Was the bit on because it was 31bit code setting the flag, or was it a
real address in 64bit mode?
It was easier to just block out the range as unusable.

Tony Thigpen

[Paul Gilmartin]

On 2014-11-04, at 17:07, Tony Thigpen wrote:

> The first bit of the address in the PSW indicates that the address is a 31 bit address. So, there was ambiguity for any address with the first bit set on.
> Was the bit on because it was 31bit code setting the flag, or was it a real address in 64bit mode?
> It was easier to just block out the range as unusable.
>

Wouldn't that be similarly true for ranges such as 6GiB <= A < 8GiB,
10 GiB <= A < 12 GiB, ...? Are all such ranges blocked out?

-- gil

[Tony Thigpen]

It's only the single bit that causes ambiguity:
80000000 or 00000000800000000

0000000081234567 can be 01234567 (31bit mode)
0000000081234567 can be 81234568 (64bit mode)

SO, they just said that any address with the following bit is invalid:
0000000080000000

Tony Thigpen

[Chuck Arney]

A 64-bit address is only ambiguous when the high word is zero and the high bit of the low word is on. When the high word is non-zero all 32 bits of the low word can address storage locations without ambiguity.

Chuck Arney
Arney Computer System

[Tony Thigpen]

Thanks Chuck. That was the piece I was forgetting to actually say.

Tony Thigpen

[Paul Gilmartin]

On 2014-11-04, at 19:25, Chuck Arney wrote:

> A 64-bit address is only ambiguous when the high word is zero and the high bit of the low word is on. When the high word is non-zero all 32 bits of the low word can address storage locations without ambiguity.
>

I'm not sure why you're even discussing 64 bit addresses when in
in AMODE 31. Isn't that a contradiction in terms?

How do VM and Linux, which I understand to not block that range of
addresses deal with the problem?

Isn't there a bit in the old PSW that distinguishes between
AMODE 31 and AMODE 64?

Give me more context. Where might I encounter a 64-bit address
such as 0000 0000 8000 1000 and be uncertain whether it was to
be interpreted in AMODE 31 or AMODE 64?

-- gil

[Paul Gilmartin]

On 2014-11-04, at 19:25, Chuck Arney wrote:

> A 64-bit address is only ambiguous when the high word is zero and the high bit of the low word is on. When the high word is non-zero all 32 bits of the low word can address storage locations without ambiguity.
>

[Binyamin Dissen]

On Tue, 4 Nov 2014 20:27:09 -0700 Paul Gilmartin
<00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:

Never.

The issue is addresses accesses via L when in 64-bit mode. There are various
conventions where setting the high order bit is meaningful such as the end of
a parmlist or indicating that the routine expects to be called in 31 bit mode.
Until the code is changed to use LLGT(r) to clean the high order bit, it was
felt that it was better to force an abend (by not allowing virtual addresses
in that range to be assigned) rather than allow erroneous access to the wrong
storage..

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Bernd Oppolzer]

Maybe it can be explained this way:

when we migrated from 24 bit to 31 bit, we had lots of problems
when loading 24 bit addresses (for example parameter addresses)
from fullwords and using them in 31 bit mode,
and the addresses had some non zero values in the first (leftmost) byte
of the register (which was no problem in 24 bit mode). There was no way
around this but to clean the register's first byte before doing the storage
address (if the address was a 24 bit address in the beginning).

Now we have the same situation; the leftmost bit of the fullword is
ignored when using the addresses in storage access (in 31 bit mode),
be it 0 or 1 ... and it is 1 sometimes.

When expanding a 31 bit address to 64 bit, simply by adding 32 zero
bits on the left or by loading a fullword into the right half of a 64
bit register,
the 31 bit address will be the wrong address, if the leftmost bit in the
fullword
was set.

But this time we have the chance to flag such errors, simply by
excluding this
address range (0x00000000_80000000 to 0x00000000_FFFFFFFF) from
the range of allowable 64 bit addresses in z/OS. It is, given the overall
address range, not too large.

This is, as I understand it, a design decision of z/OS; Linux and z/VM
deciced
that they don't regard such problems as severe enough, or they even don't
exist, because Linux is 64 bits from the start (but I don't really know
this,
only a guess).

Kind regards

Bernd

[Tony Thigpen]

And z/VSE followed the same pattern as z/OS.

And, as a little extra, this is why the 31/64 line is called a BAR, not
a LINE. The unusable addresses are what is in the BAR. So, you can be
above the bar, or below the bar, but not in the bar. (No drinking
allowed. :-) )

Tony Thigpen

[Paul Gilmartin]

On 2014-11-05, at 01:27, Bernd Oppolzer wrote:

> Maybe it can be explained this way:
>
> when we migrated from 24 bit to 31 bit, we had lots of problems
> when loading 24 bit addresses (for example parameter addresses)
> from fullwords and using them in 31 bit mode,
> and the addresses had some non zero values in the first (leftmost) byte
> of the register (which was no problem in 24 bit mode). There was no way
> around this but to clean the register's first byte before doing the storage
> address (if the address was a 24 bit address in the beginning).
>
> Now we have the same situation; the leftmost bit of the fullword is
> ignored when using the addresses in storage access (in 31 bit mode),
> be it 0 or 1 ... and it is 1 sometimes.
>
> When expanding a 31 bit address to 64 bit, simply by adding 32 zero
> bits on the left or by loading a fullword into the right half of a 64 bit register,
> the 31 bit address will be the wrong address, if the leftmost bit in the fullword
> was set.
>

A similar approach as for 24 to 31 bit conversion applies. Simply
clear bit 0.

> But this time we have the chance to flag such errors, simply by excluding this
> address range (0x00000000_80000000 to 0x00000000_FFFFFFFF) from
> the range of allowable 64 bit addresses in z/OS. It is, given the overall
> address range, not too large.
>

Are you suggesting that someone might do 64-bit STORAGE OBTAIN and save
only low-order fullword. This will certainly cause problems, but those
are not solved by excluding that address range. Or that someone do 64-bit
STORAGE OBTAIN and decide based on whether the high-order fullword is 0
that it suffices only to store the right half?

I still don't envision a plausible scenario in which a problem is avoided
by excluding that range of addresses. Supply context.

More:

I understand that BASSM sets bit 63 of the return address to indicate
that the return address is to AMODE 64. Does Content Supervision
follow the same convention, setting bit 63 when LOADing an AMODE 64
module?

Hmmm. I believe I can declare an ENTRY at an odd offset from the CSECT.
(It had better be data, not a branch target.) I can make that ENTRY an
ALIAS for my module. When I LOAD it, how can I tell if it the address
returned with bit 63 set indicates an AMODE 64 CSECT or an actual odd
address.

Perhaps the answer is, "Don't do that!"

Does Binder resolve 31-bit V-CONs setting bit 0 to indicate AMODE 31?
Does Binder resolve 64-bit V-CONs setting bit 63 to indicate AMODE 64?

-- gil

[Steve Smith]

It's important to note that the reservation of x'80000000' through
x'FFFFFFFF' is merely to help avoid addressing issues, as well-explained
previously. It's not a fundamental issue at all, and the architecture
itself doesn't have any such restriction.

Also, you CAN allocate memory in this area (which was extended to
x'7_FFFFFFFF'). There's an undocumented keyword on IARV64 called something
like USE2GTO32G. You can expect no one to help you debug storage overlays
if you decide to do that!

I read somewhere that Java wanted this area because it could "compress"
pointers to 4 bytes. I presume that they only need to address to
doubleword granularity, and so can shift the address 3 bits to the right to
store it in a 4-byte word (and conversely shift left 3 bits to use it).
Addresses up to 32G are the maximum that will fit in that scheme, and
that's where the "restricted" area now ends.

I don't know why Java (or anyone else) would really need to do that - I'd
think just going to 8-byte addresses would be more sensible. But there it
is.

--
sas

[John McKown]

On Wed, Nov 5, 2014 at 8:57 AM, Steve Smith <sas...@gmail.com> wrote:

> It's important to note that the reservation of x'80000000' through
> x'FFFFFFFF' is merely to help avoid addressing issues, as well-explained
> previously. It's not a fundamental issue at all, and the architecture
> itself doesn't have any such restriction.
>
> Also, you CAN allocate memory in this area (which was extended to
> x'7_FFFFFFFF'). There's an undocumented keyword on IARV64 called something
> like USE2GTO32G. You can expect no one to help you debug storage overlays
> if you decide to do that!
>
> I read somewhere that Java wanted this area because it could "compress"
> pointers to 4 bytes. I presume that they only need to address to
> doubleword granularity, and so can shift the address 3 bits to the right to
> store it in a 4-byte word (and conversely shift left 3 bits to use it).
> Addresses up to 32G are the maximum that will fit in that scheme, and
> that's where the "restricted" area now ends.
>
> I don't know why Java (or anyone else) would really need to do that - I'd
> think just going to 8-byte addresses would be more sensible. But there it
> is.
>

​Well, my _guess_ about this is that Java runs (or is supposed to run) the
same "everywhere". Part of that "everywhere" is in the embedded space where
bits remain more precious that they are on the desktop and enterprise class
machines. So this address compression doesn't do much for most, but does in
the embedded arena.​



--
The temperature of the aqueous content of an unremittingly ogled
culinary vessel will not achieve 100 degrees on the Celsius scale.

Maranatha! <><
John McKown

[Bernd Oppolzer]

Am 05.11.2014 15:18, schrieb Paul Gilmartin:
> On 2014-11-05, at 01:27, Bernd Oppolzer wrote:
>
>> Maybe it can be explained this way:
>>
>> when we migrated from 24 bit to 31 bit, we had lots of problems
>> when loading 24 bit addresses (for example parameter addresses)
>> from fullwords and using them in 31 bit mode,
>> and the addresses had some non zero values in the first (leftmost) byte
>> of the register (which was no problem in 24 bit mode). There was no way
>> around this but to clean the register's first byte before doing the storage

>> access (if the address was a 24 bit address in the beginning).

>>
>> Now we have the same situation; the leftmost bit of the fullword is
>> ignored when using the addresses in storage access (in 31 bit mode),
>> be it 0 or 1 ... and it is 1 sometimes.
>>
>> When expanding a 31 bit address to 64 bit, simply by adding 32 zero
>> bits on the left or by loading a fullword into the right half of a 64 bit register,
>> the 31 bit address will be the wrong address, if the leftmost bit in the fullword
>> was set.
>>
> A similar approach as for 24 to 31 bit conversion applies. Simply
> clear bit 0.
>
>> But this time we have the chance to flag such errors, simply by excluding this
>> address range (0x00000000_80000000 to 0x00000000_FFFFFFFF) from
>> the range of allowable 64 bit addresses in z/OS. It is, given the overall
>> address range, not too large.
>>
> Are you suggesting that someone might do 64-bit STORAGE OBTAIN and save
> only low-order fullword. This will certainly cause problems, but those
> are not solved by excluding that address range. Or that someone do 64-bit
> STORAGE OBTAIN and decide based on whether the high-order fullword is 0
> that it suffices only to store the right half?
>
> I still don't envision a plausible scenario in which a problem is avoided
> by excluding that range of addresses. Supply context.

load a 31 bit address which points to storage below the bar from a fullword;
the fullword has the first bit set (maybe because it is the last
fullword in an address list).
The target of the load is a 64 bit register (say reg 5), where the left
half is zero.
Now you switch to AMODE 64 and use that register for adressing ... ouch.

Without excluding that address range, you risk to access wrong storage
(if at
that wrong address there is accessible storage, by chance). By excluding
that
address range, you will get an ABEND in any case, which is better.

> **

> More:
>
> I understand that BASSM sets bit 63 of the return address to indicate
> that the return address is to AMODE 64. Does Content Supervision
> follow the same convention, setting bit 63 when LOADing an AMODE 64
> module?

I don't think so; what LOAD does, depends on the RMODE of the module.
It may be different for LINK, XCTL, ATTACH ...

> Hmmm. I believe I can declare an ENTRY at an odd offset from the CSECT.
> (It had better be data, not a branch target.) I can make that ENTRY an
> ALIAS for my module. When I LOAD it, how can I tell if it the address
> returned with bit 63 set indicates an AMODE 64 CSECT or an actual odd
> address.

don't know, what exactly will happen, but the module containing this
ENTRY has an
RMODE, and you will not get an address different from that module's RMODE.

Don't mix up addresses in the PSW which are always even with data adresses,
which may be even or odd. Because addresses in the PSW are even all the time
(all instructions are on even adresses), the last bit in the instruction
address in the PSW
can be used for any other information (in theory) ... but in fact it is
not used;
it is always zero. BTW: in the PSW bit 31 indicates AMODE 64, this is
not part
of the instruction address (which is at bits 64 to 127; 127 is always
zero and needs
not to be saved by BASSM, for example).

> Perhaps the answer is, "Don't do that!"
>
> Does Binder resolve 31-bit V-CONs setting bit 0 to indicate AMODE 31?
> Does Binder resolve 64-bit V-CONs setting bit 63 to indicate AMODE 64?

storing the AMODE information in bit 63 of an address is only valid for
addresses
that are related to machine instructions, such as return addresses;
there are only
some instructions like BASSM that use this technique. V-CONs can be
related to
data areas as well or they are not used with AMODE switches, so it would
make no
sense for me if V-CONs would do something implicitly with bit 63.

> -- gil
>

HTH,
kind regards

Bernd

[Paul Gilmartin]

On 2014-11-05, at 05:10, Tony Thigpen wrote:

> And z/VSE followed the same pattern as z/OS.
>
> And, as a little extra, this is why the 31/64 line is called a BAR, not a LINE. The unusable addresses are what is in the BAR. So, you can be above the bar, or below the bar, but not in the bar. (No drinking allowed. :-) )
>

This been discussed, tediously, in these lists. The statement, including
from some IBM employees, perhaps unofficial, is that the BAR is an
infinitesimal boundary immediately below 2GiB. Any address >= 2GiB
is considered *above*, never in, the BAR.

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?

-- gil

[John McKown]

​On the Linux-390 forum, I've never seen the use of "​bar" in this context.
Only 64 bit mode or 31 bit mode. In the same context as the x86_64 or i386
mode for Intel.



>
> -- gil

[Walt Farrell]

On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin <PaulGB...@AIM.COM> 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.

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).

--
Walt

[Rob van der Heij]

Yes, z/VM has a bar. With our first 64-bit version, there were some
restrictions that virtual machine pages for guest I/O had to be under the
bar. That was rather unpleasant for Linux that does not use dedicated
memory areas as I/O buffer. It got crowded under the bar.
And the 32-bit Linux s390 had some challenges because a process would only
be able to span 2GB where the x86 folks could have 4GB. Even though we kept
kernel memory out of that 4GB, we did run a bit sort with Java for example.

Don't think Linux folks refer to either as the "bar" but they're probably
not of legal age yet ;-)

[Rob van der Heij]

> Java already decides based on the maximum heap size whether it will need
64-bit addresses or not. The challenge apparently is that they can have a
*lot* of pointers in their objects. So typically when you go somewhat over
the 4G of heap, you would end up having less room for your objects. Taking
advantage of the alignment you get more out of your 32-bit pointers. Even
though shifting a few bits is not hard, it does take CPU. There's
-Xnocompressedrefs to override the default for heaps between 4G and 25G or
so.

Rob

[Paul Gilmartin]

On 2014-11-05, at 13:11, Walt Farrell wrote:

> On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin <PaulGB...@AIM.COM> 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

[Rob van der Heij]

I stand corrected: at least with JVM7 the compressed references is by
having part of the heap under the 4G used for a certain subset of objects
that is most often pointed at. As with any partitioning, this creates
opportunities for running out of memory though there is enough space on the
heap.

[Tony Harminc]

On 5 November 2014 16:19, Paul Gilmartin

<00000014e0e4a59...@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.

[Paul Gilmartin]

On 2014-11-05, at 08:54, Bernd Oppolzer wrote:
>
> load a 31 bit address which points to storage below the bar from a fullword;
> the fullword has the first bit set (maybe because it is the last fullword in an address list).
> The target of the load is a 64 bit register (say reg 5), where the left half is zero.
> Now you switch to AMODE 64 and use that register for adressing ... ouch.
>

The programmer was expected to clear bits 1-7 before using a 24-bit
address in AMODE 31. The programmer should clear bit 32 before using
a 31-bit address in AMODE 64.

> Without excluding that address range, you risk to access wrong storage (if at
> that wrong address there is accessible storage, by chance). By excluding that
> address range, you will get an ABEND in any case, which is better.
>

Now Java spoils that by using that address range. ABEND is less likely.

-- gil

[Walt Farrell]

On Wed, 5 Nov 2014 18:07:17 -0500, Tony Harminc <to...@HARMINC.COM> wrote:

>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.

As others have mentioned, IARV64 _will_ give you back storage between 2GiB and 4Gib, if you ask it to using the right (perhaps undocumented except in the code) parameters. However, asking for that storage is not part of the intended customer programming interface; it is intended (as I remember) only for use by Java.

--
Walt

[Walt Farrell]

On Wed, 5 Nov 2014 14:19:59 -0700, Paul Gilmartin <PaulGB...@AIM.COM> wrote:

>>
>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.

Someone earlier in this thread mentioned IARV64 and the special (undocumented, except in the code?) keyword you need to use to get storage in that range. I vaguely recall that it came in around z/OS R12. In any case, it's intended user is Java, as I recall, and it's not part of the documented customer programming interface.

--
Walt

[Steve Smith]

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

[Peter Relson]

>I still don't envision a plausible scenario in which a problem is avoided
>by excluding that range of addresses. Supply context.

Many start a conversion to AMODE 64 by changing to AMODE 64 without
adequate analysis of their data. Maybe they even clear all the high
halves.

If there was "L" to load a pointer field, then a subsequent reference in
AMODE 64 would fail if the pointer had bit 0 on. Obviously the "L" in this
case should be changed to LLGT. It was to help these cases jump out at you
that the BAR was defined. This is in a way similar to setting up the
x'7FFFF000' page of an address space not to be addressable. Instead of
initializing a pointer to 0, you could initialize it 7FFFF000 (if you're
AMODE 31) and then if you mistakenly use it without setting it, you blow
up instead of accessing the PSA (which, true, would now get a ZAD event if
PER ZAD is active). You might also see 7FFFFBAD as an address used for the
same purpose (of course it doesn't accomplish its purpose if the offset >=
x'453').

To the question about the ambiguity of 00000000_80001000: it could be
considered ambiguous to Java which is given access to storage within the
bar. We normal users steer clear of that area.

>I understand that BASSM sets bit 63 of the return address to indicate
>that the return address is to AMODE 64. Does Content Supervision
>follow the same convention, setting bit 63 when LOADing an AMODE 64
>module?

Well, there is no "return address" for LOAD, but the returned entry point
output from LOAD is intended to be suitable for use in BASSM.
So an AMODE 64 entry point wil have bit 63 on so that you can use BASSM
(and if you want to use it on BASR, you must clear that bit). The value
placed into reg 14 is for use on BSM.

>Hmmm. I believe I can declare an ENTRY at an odd offset from the CSECT.
>(It had better be data, not a branch target.) I can make that ENTRY an
>ALIAS for my module. When I LOAD it, how can I tell if it the address
>returned with bit 63 set indicates an AMODE 64 CSECT or an actual odd
>address.
>

>Perhaps the answer is, "Don't do that!"

This is an excellent observation. And it is exactly correct, including the
"answer".
If you are an AMODE 64 then do not create an alias or an entry point that
is odd.
This should have been documented long ago but was not. We intend to do so,
but have not quite figured out where. Feel free to suggest "where".

It applies only to AMODE 64,RMODE 24 (or AMODE 64, RMODE 31 if above-16M
storage is not available) vs AMODE 24.
-- AMODE 31, any RMODE: the answer would have bit 32 on
-- AMODE 64, RMODE 31 (at least when storage is available), some bit 33-39
would be non-0
-- AMODE 64, RMODE 64 (some day), some bit 0-31 would be non-0
-- AMODE 64, RMODE 24 (or AMODE 24 for an odd address) bits 0-39 would be
0, bit 63 would be 1

The caveat to be documented is: If your module is AMODE 64, do not create
an alias or entry point that is at an odd offset from the beginning.
(You might say that if you happen to "know" that it's at an odd offset,
then it's OK to do so.)

Peter Relson
z/OS Core Technology Design

[Dale R. Smith]

On Wed, 5 Nov 2014 14:19:59 -0700, Paul Gilmartin <PaulGB...@AIM.COM> wrote:

>On 2014-11-05, at 13:11, Walt Farrell wrote:
>
>> On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin <PaulGB...@AIM.COM> 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

--
Dale R. Smith

[Steve Smith]

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