R.S. wrote:
I'm not so slow, call me RadaFAST (or Radoslaw) <g>
I understand, the hole is only in virtual memory, the real memory
between 2G and 4G will not be wasted.
However I don't understand the reason why any bit in any 24-bit
address could mess someting in 64-bit addressing mode. Is it a problem
with low-order bit ?
The consideration of AMODE(24) programs demonstrates quite clearly why
the z/OS virtual storage "dead" zone was purely an option ... never a
requirement.
In the early 1980s, the 370/XA bi-modal addressing architecture was
implemented. There were many, many issues with programs that -- either
accidentally or intentionally -- placed "garbage" in the upper eight
bits of an address word. For example, a 24-bit program created an
address word containing x'87654321' instead of x'80654321'. A 31-bit
program referenced the storage at x'07654321', which was not the
intended storage. These issues resulted in all kinds of "wrong"
processing, including storage overlays. It was ugly! And, these bugs
were very difficult; nearly impossible to find. Back then, I was an
application programmer and had no access to SLIP. I traced through
thousands of lines of code using TSO TEST. As I said, Ugly!
If you were lucky, and the "gods" smiled upon you that day, the 31-bit
program processing the "bad" address would suffer an 0C4 abend because
the storage (in this case at x'07654321') was not GETMAINed. This was
the _best possible_ outcome! It made finding and correcting the problem
(relatively) easy!
Those experiences were the impetus for the z/OS developers' decision to
create a virtual storage "dead" zone between 2G and 4G. (Fortunately for
us, these developers are old enough to actually remember what happened
in the early 1980s.) They learned from that experience and did not allow
history to repeat itself, They understood that, had they not done so,
our programming community (IBM included) would have had to suffer with
untold numbers of bugs, similar to what we dealt with (then) 20 years
ago with XA, due to 64-bit programs processing 32-bit address words with
the high order bit set. In each case, an LLTR or LLTRG is the answer.
But, in the absence of a hard failure, recognizing, finding and
correcting such bugs would have been extremely difficult.
The result of this purely optional, yet extremely wise, design decision,
is that a 32-bit address word with the high order bit set -- either
accidentally or intentionally -- will cause an 0C4 abend when processed
by a 64-bit mode program. No need for luck or a smiling deity,. It is
the stated policy of the z/OS operating system that such addresses are
guaranteed never to be valid. Hallelujah!
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
