Okay, while we are delving into nostalgia here. I had a program that was failing with a S0C4 on either a 360/40 or 360/50 -- I remember the customer, and they had one of each, but don't recall which box it was. Probably the 50 -- the 50 was a little touchy while the 40 was a rock.
Anyway, I looked and looked and looked at the code and finally determined that it had to be a hardware error. Try convincing anyone of that! Yeah, right, your S0C4 is a hardware error! But eventually I convinced my boss at the small contracting firm, and then eventually he convinced the customer, and then we finally convinced IBM, who swapped a memory board and the problem went away. But -- the point I am getting to here -- the clincher was that someone (me?) noticed at some point that the exception being reported was a fetch protection exception, and OS/360 did not implement fetch-protected memory, so given that the program was a more-or-less basic application that did not manipulate storage keys, it tended to point to some sort of error outside of my application. Don't recall exactly what triggered the error -- some issue of write address X and then read address Y, or some timing thing, or something. </nostalgia> Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Sunday, March 03, 2013 7:18 AM To: [email protected] Subject: Re: REFRPROT History Question On Mar 2, 2013, at 20:04, Charles Mills wrote: > I recall distinctly the hardware having fetch protection but there being no apparent OS support for it. > That matches my old recollection of an Old Timer's recounting his astonishment at having read a dump in which a Protection Exception appeared to have been taken on a fetch instruction. I believe (with no good evidence) that it was controlled by a bit in the page key. It may have been model-dependent. A matching PSW key always allowed read-write access; a different PSW key might have either no access or read-only access depending on the bit's setting. Truly the Bad Old Days, when there was no privacy enforced between jobs. And IBM OS technology has always trailed the hardware technology. To wit, nowadays, the absence in z/OS of complete support for 64-bit virtual. (The less said of COBOL the better; it's not part of the OS.) Jim Mulder's explanation is most plausible; at some point there may have been understandable reluctance to load user code in key 0, only partly because there would have been no way to guarantee confidentiality of such code. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
