ZAD is to deal with base registers (register 0 can never be a base register)
loaded with 0 being incorrectly used to read data in the first 4k by 
instructions
with a base/12-bit displacement.  While long-displacement instructions could
incorrectly read data in the first 512K of a dataspace, I doubt there has been
much evidence of this happening. The whole point of using HideZero is to reduce
the false-positives in the zad reports. It's not as if there's anything wrong
with actually looking at that storage if there's some reason to do so. Just use
R0 when you do. The first 8K of a dataspace is not unique to each processor.

In article <CAJTOO59vMMoCuVZ=h9zv6d8q8w-mjzkpz6rmfmqjo6_asyk...@mail.gmail.com> 
you wrote:
> With 64 bit machines, each processor now has 8K unique to it.  Do they
> need to avoid the first 8K?

> On Sat, Mar 7, 2020 at 7:25 AM Peter Relson <rel...@us.ibm.com> wrote:
> >
> > Answer: Not totally
> >
> > It is true that all current machines support page 0 in a data space, and
> > for them the "normal" origin returned would be 0.
> > That is not a guarantee that all future machines would have such support,
> > but I find it hard to believe any would not.
> >
> > However, we have found it highly desirable to avoid using page 0 of the
> > data space, in order to avoid ZAD events (which in turn make it more
> > difficult to spot ZAD errors).
> > The best way to do that is to use HideZero=YES on DSPSERV CREATE
> > (available since z/OS 2.1). And when that is done, the origin returned is
> > x'1000'. With HideZero=YES, any reference to the first 4K will fail, so
> > that you don't even need ZAD to find erroneous references.
> >
> > For us, best practice is to create a 2G data space (not 2G-4K), treat RC=0
> > and RC=4 as OK, use HideZero=YES, and use an Origin of x'1000'.
> >
> > So you never really need to use the Origin keyword if you simply start at
> > x'1000'. There is a non-zero but miniscule risk if you assume that it is
> > OK to use an origin of 0.
> >
> > Peter Relson
> > z/OS Core Technology Design

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com           (919) 531-5637                Cary, NC 27513

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to