Re: Strange S0C4 on z15
On a z13 we could access data in the PSA in the 2048 to 4095 range without going into key 0. The specific field is PSASVT. If you can prove that, then please report it immediately as a defect. But I'd think you can't. Is it possible that you used to access the SVT via CVTSVT? 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: Strange S0C4 on z15
Thank you Jim, appreciate the detailed explanation which is understandably similar to Peter Relson's back in March. My intent want not to take this thread in another direction, just thinking about PSF in terms of the poster's original question... On Wed, 19 Aug 2020 19:11:33 + "Christopher Y. Blaicher" wrote: :>We have a program that ran fine on a z13 that now gets an S0C4 on a z15. :>On a z13 we could access data in the PSA in the 2048 to 4095 range without going into key 0. The specific field is PSASVT. :>To get to that data now, we have to do a MODESET to key zero. :>Anyone else find this as a problem? Was it there with a z14? We jumped from a z13 to a z15. Thanks again, Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Wednesday, August 19, 2020 9:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strange S0C4 on z15 Caution! This message was sent from outside your organization. The first machine to implement ESA/370 was the 3090E. This was done via microcode updates (since the 3090E hardware was designed prior to ESA). It was not possible to implement PSF in microcode, so MVS used x'1000' as the data space ORIGIN, Every subsequent machine (starting with the 3090S) implemented PSF, and MVS used 0 as the data space ORIGIN. That is still the case today, unless you specify HIDEZERO=YES on DSPSERV CREATE, in which case the ORIGIN is x'1000' and page 0 is hidden, This is desirable because it avoids PER ZAD events, and gives you a 0C4 abend instead of incorrect results when you accidentally use a bad pointer value in the range 0-FFF. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 08/19/2020 07:01:09 PM: > From: "Mike Hochee" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/19/2020 09:07 PM > Subject: Re: Strange S0C4 on z15 > Sent by: "IBM Mainframe Discussion List" > > Some months ago I asked a question regarding the relevance of the > ORIGIN parm on a DSPSERV macro. During that time I came across older > documentation which referred to low-address protection being in effect > when the PSF (Private Space Facility) was not active. My limited > understanding is that the PSF is active on 'virtually' all systems. > Mr Dissen's post below brought this to mind. > -- 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: Strange S0C4 on z15
The first machine to implement ESA/370 was the 3090E. This was done via microcode updates (since the 3090E hardware was designed prior to ESA). It was not possible to implement PSF in microcode, so MVS used x'1000' as the data space ORIGIN, Every subsequent machine (starting with the 3090S) implemented PSF, and MVS used 0 as the data space ORIGIN. That is still the case today, unless you specify HIDEZERO=YES on DSPSERV CREATE, in which case the ORIGIN is x'1000' and page 0 is hidden, This is desirable because it avoids PER ZAD events, and gives you a 0C4 abend instead of incorrect results when you accidentally use a bad pointer value in the range 0-FFF. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 08/19/2020 07:01:09 PM: > From: "Mike Hochee" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/19/2020 09:07 PM > Subject: Re: Strange S0C4 on z15 > Sent by: "IBM Mainframe Discussion List" > > Some months ago I asked a question regarding the relevance of the > ORIGIN parm on a DSPSERV macro. During that time I came across older > documentation which referred to low-address protection being in > effect when the PSF (Private Space Facility) was not active. My > limited understanding is that the PSF is active on 'virtually' all > systems. Mr Dissen's post below brought this to mind. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange S0C4 on z15
Some months ago I asked a question regarding the relevance of the ORIGIN parm on a DSPSERV macro. During that time I came across older documentation which referred to low-address protection being in effect when the PSF (Private Space Facility) was not active. My limited understanding is that the PSF is active on 'virtually' all systems. Mr Dissen's post below brought this to mind. HTH, Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Wednesday, August 19, 2020 4:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strange S0C4 on z15 Caution! This message was sent from outside your organization. Fetch-protection-override (cr0.38) allowed the OS to put fetch protection on page0 while allowing (legacy) access to 0-2047. Don't know which hardware level allowed exploitation. On Wed, 19 Aug 2020 19:11:33 + "Christopher Y. Blaicher" wrote: :>We have a program that ran fine on a z13 that now gets an S0C4 on a z15. :>On a z13 we could access data in the PSA in the 2048 to 4095 range without going into key 0. The specific field is PSASVT. :>To get to that data now, we have to do a MODESET to key zero. :>Anyone else find this as a problem? Was it there with a z14? We jumped from a z13 to a z15. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange S0C4 on z15
Seems like the real question is how does it work on a z13? 2048-4095 (x'800-FFF') are *supposed* to be key0 fetch-protected. "Fetch Protection Override" (CR0:38) is to allow everyone to fetch from 0-2047 (x'0-7FF'), while leaving 2048-4095 fetch protection in effect. It is not a new feature, nor is it a "legacy" thing. IBM hasn't deprecated the common CVT pointer. It's documented in PoOp: SA22-7832-12 page 3-13. sas On Wed, Aug 19, 2020 at 4:16 PM Binyamin Dissen wrote: > Fetch-protection-override (cr0.38) allowed the OS to put fetch protection > on > page0 while allowing (legacy) access to 0-2047. > > Don't know which hardware level allowed exploitation. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange S0C4 on z15
Generally, that would give you an 0C1. In my case it was a simple LOAD instruction. LR1,X'B4C'(0,0) Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Wednesday, August 19, 2020 4:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strange S0C4 on z15 [ External - This message originated Externally. Use proper judgement and caution with attachments, links, or responses. ] So I had an S0C4 one time - turned out the vendor had used an instruction that was not on the CEC (firmware) we were running. So maybe there is an instruction used on the z13 that the 15 does not have? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Christopher Y. Blaicher Sent: Wednesday, August 19, 2020 12:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Strange S0C4 on z15 We have a program that ran fine on a z13 that now gets an S0C4 on a z15. On a z13 we could access data in the PSA in the 2048 to 4095 range without going into key 0. The specific field is PSASVT. To get to that data now, we have to do a MODESET to key zero. Anyone else find this as a problem? Was it there with a z14? We jumped from a z13 to a z15. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange S0C4 on z15
So I had an S0C4 one time - turned out the vendor had used an instruction that was not on the CEC (firmware) we were running. So maybe there is an instruction used on the z13 that the 15 does not have? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Christopher Y. Blaicher Sent: Wednesday, August 19, 2020 12:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Strange S0C4 on z15 We have a program that ran fine on a z13 that now gets an S0C4 on a z15. On a z13 we could access data in the PSA in the 2048 to 4095 range without going into key 0. The specific field is PSASVT. To get to that data now, we have to do a MODESET to key zero. Anyone else find this as a problem? Was it there with a z14? We jumped from a z13 to a z15. -- 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: Strange S0C4 on z15
Fetch-protection-override (cr0.38) allowed the OS to put fetch protection on page0 while allowing (legacy) access to 0-2047. Don't know which hardware level allowed exploitation. On Wed, 19 Aug 2020 19:11:33 + "Christopher Y. Blaicher" wrote: :>We have a program that ran fine on a z13 that now gets an S0C4 on a z15. :>On a z13 we could access data in the PSA in the 2048 to 4095 range without going into key 0. The specific field is PSASVT. :>To get to that data now, we have to do a MODESET to key zero. :>Anyone else find this as a problem? Was it there with a z14? We jumped from a z13 to a z15. -- 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: Strange S0C4 on z15
zOS V2.2, V2.3 and V2.4, all running on LPARs of a z15. It seems to be a machine issue, not a zOS issue. This is NOT, repeat NOT, code in any Syncsort, now Precisely, product. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Beaver Sent: Wednesday, August 19, 2020 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Strange S0C4 on z15 [ External - This message originated Externally. Use proper judgement and caution with attachments, links, or responses. ] What was your zOS version and what is it now? Sent from my iPhone I promise you I can’t type or Spell on any smartphone > On Aug 19, 2020, at 14:21, Christopher Y. Blaicher > wrote: > > We have a program that ran fine on a z13 that now gets an S0C4 on a z15. > On a z13 we could access data in the PSA in the 2048 to 4095 range without > going into key 0. The specific field is PSASVT. > To get to that data now, we have to do a MODESET to key zero. > Anyone else find this as a problem? Was it there with a z14? We jumped from > a z13 to a z15. > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange S0C4 on z15
What was your zOS version and what is it now? Sent from my iPhone I promise you I can’t type or Spell on any smartphone > On Aug 19, 2020, at 14:21, Christopher Y. Blaicher > wrote: > > We have a program that ran fine on a z13 that now gets an S0C4 on a z15. > On a z13 we could access data in the PSA in the 2048 to 4095 range without > going into key 0. The specific field is PSASVT. > To get to that data now, we have to do a MODESET to key zero. > Anyone else find this as a problem? Was it there with a z14? We jumped from > a z13 to a z15. > > -- > 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
