The S0C1 is almost certainly a bug in TESTAUTH, not in his code, and I wouldn't expect him to track down the bug in TEST, nor is it his responsibility. If he's not already licensed, think of this as a marketing opportunity.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of David Cole [[email protected]] Sent: Saturday, February 25, 2023 5:36 AM To: [email protected] Subject: Re: Cant SPKA to PSW Key 4 Hi Joe, Tony is right. It is not possible for SPKA to throw an 0C1. Therefore, the 0C1 has to be occurring somewhere else. When the 0C1 occurs, are you put back into TEST? Or are you blown all the way out to READY? If you're still in TEST, issue WHERE to see where execution is now. WHERE will display a message that looks something like: * "address. LOCATED AT +offset IN modulename .csectname UNDER TCB LOCATED AT whocares." It is vary likely that the "modulename" and "csectname" are not what you will expect them to be. The location given by "address." will be at the end of the bad instruction. To see the bad instruction itself, you will have to back up -2, -4 or -6 bytes. To display that, use "LIST address.-6 LENGTH(32)". So, now you know (more or less) where the 0C1 happened. Now comes the hard part: Figuring out WHY it happened. There basically only three possibilities: * 1) A wild jump occurred that took execution to god knows where. * 2) Corruption occurred that overwrote good code with bad data. * 3) Or both: A corruption occurred that causes a wild jump. I will have to leave it to you to figure that out. Best, Dave Cole, Developer [email protected] (personal) [email protected] (business) 540-456-6518 (cell) At 2/23/2023 10:54 PM, Tony Harminc wrote: >On Thu, 23 Feb 2023 at 21:47, Joseph Reichman <[email protected]> wrote: > >> > >> > I am trying to change psw storage key from "Normal" key 8 to Key 4 >> > >> > SPKA X'40' >> > >> > I have bit 15 of the psw 0 ,meaning I am in supervisor state and >> get a s0c1 >> > running this code under TESTAUTH >> > >A program check 1 is not possible if you execute an SPKA, no matter what >state you're in, and what the content of R0 (the implied register) is. So >I'd say you didn't actually execute it. How, I have no idea. When you say >"running this code", presumably there is more code than the one SPKA >instruction. Please make sure it isn't e.g. the instruction right before >the SPKA that's failing - that could show you the address of the SPKA as >the failing address, depending on how it fails. Perhaps you're branching >into the middle of an instruction somewhere nearby? >TSO TEST[AUTH] does overlay instructions where you have set a breakpoint >with an SVC 97, so if your code is fetching from or storing into the >instruction stream where there's a breakpoint, all bets are off. >I am able to get to PSW key 0 SPKA 0 > > Don't get it > > >Neither do I. But architecturally, SPKA can't fail that way. If you got an >S0C2 that would make sense. >Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
