Re: DSPSERV CREATE, is ORIGIN parm a relic?
Thank you Gents for the best practice and the explanations. Much appreciated, Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras Sent: Saturday, March 7, 2020 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DSPSERV CREATE, is ORIGIN parm a relic? Caution! This message was sent from outside your organization. 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 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 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-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSPSERV CREATE, is ORIGIN parm a relic?
On Fri, 6 Mar 2020 16:01:41 -0600 Michael Hochee wrote: :>Ideally, I would like to create all future data spaces with a size of 2GB, rather than 2GB OR 2GB-4K (when the returned ORIGIN value is NZ). I looked at assembler service reference manuals as far back as 1999, and they all state that a non-zero origin value (4K) is based on a processor dependency. I eventually found a vintage IBM-Amdahl presentation (1989) indicating the dependency is due to low-address protection being in effect when the PSF (Private-Space Facility) is not active. :>My question is... Is this still relevant 30 years later? Do any G10 or above customers run configurations where PSF is inactive? If you are already changing the code, why not change it to use 64 bit memory objects. That way you can get the exact size. -- Binyamin Dissen 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSPSERV CREATE, is ORIGIN parm a relic?
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 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 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-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSPSERV CREATE, is ORIGIN parm a relic?
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 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 > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Two related alias entry address questions
>did you have an ENTRY BAR statement in the assembly? I did not. I used the form you and Gil showed of "BAR" on the "END" with no entry statement (either in the assembly or the bind). Grrr... But I've even complained of seeing a "I" suffix on messages reporting JCL errors fatal from the programmer's point of view. The rationale is that it's "Informative" from the operator's point of view. Perhaps you have forgotten what message suffixes mean for messages that are not things such as utility/compilation outputs. "W" is not warning, it is wait state. "E" is not error, it is eventual action. "I" is often the only viable choice. In general if the message is documented in "system messages", this applies (I wouldn't bet that there are no exceptions). I don't argue that that was a good decision, but it has "always" been so and will not change. For IEBCOPY, its "W" would indeed be "warning". I'm with Charles that if you get a "W" message I would expect something other than RC=0, likely RC=4. So if the argument is that you asked not to replace, and it did not replace, so that's RC=0 I'm OK with that. But then the message for that case should be "I" not "W". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSPSERV CREATE, is ORIGIN parm a relic?
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
