On Fri, 17 Dec 2010 07:50:48 -0500 Peter Relson <[email protected]> wrote:
:>Bill Fairchild wrote: :>At some time later, IBM also added a special protection feature for bytes :>512-2047 of page 0. This feature, described in the Principles of :>Operation, and which is also both hardware and software, causes a program :>interrupt by any attempt for a non-key-0 program to fetch any storage in :>the first virtual 2K, where many register save areas are located, except :>for bytes 0-511, which may be fetched by a non-key-0 program. This allows :>the normal program to do a L instruction at location 16, which is where :>the address of the CVT is located. If you try to display bytes 0-511 with :>TSO, you should be able to, but not bytes 512-2047. And you can display :>bytes 2048-4095 with TSO. :>Close, But not right. It is the 2nd 2K, bytes 2048-4095, that have this :>special attribute. I would look at it differently. The fetch protection on the first page is the very old fetch protection bit. All of the 4K is fetch protected. Since common pointers (basically the CVT, but TOLD/TNEW/AOLD/ANEW as well) are fetched by non-privileged callers IBM could not page protect page 0. By adding the Fetch-Protection-Override Control feature, IBM can now fetch protect page zero while allowing access to the common fields that are de facto part of the MVS architecture. Thus the bytes 0-2047 have this special attribute. -- Binyamin Dissen <[email protected]> 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. ---------------------------------------------------------------------- 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
