<snip> z/OS does never allocate virtual addresses from 0x80000000 to 0xFFFFFFFF. </snip>
Not quite true. Never say never :-) . History: XA architecture in effect introduced the "line", an obvious differentiating point between 24-bit and 31-bit storage at 16M. z/OS (not z/Architecture) introduced the "bar", a differentiating area from 2G to 4G-1, an area that was never "given out" to a requestor (but was perfectly valid in real) for all the reasons that have been mentioned. Then z/OS gave the "bar" to Java. So if you're running in a space that has Java active, your "AMODE 64 when the address has bits 0-31 off and bit 32 on" cases might not get an exception. <snip> I believe the greater accommodation was the hardware architecture's expanding from 24-bit addressing to only 31 rather than 32 because software so pervasively uses the sign bit for a flag. </snip> I suspect that that was not the reason. More than just the high bit, the entire high byte was used quite pervasively for flags. A remember a binary search algorithm that did just that. One might say that the architects were extremely forward-thinking. They realized the need for "pointer-defined" (namely an address and AMODE in the same field). They knew that the requirement for instructions was halfword boundary. They could have possibly chosen bit 31. But by choosing bit 0, they left bit 31 available (now bit 63) which became useful for indicating AMODE 64. Peter Relson z/OS Core Technology Design
