Peter Thank you for explaining it I really think I get it
I agree I can generalize a recovery I am changing file192 thinking of it as estate Including cases where there is abend in 1) SVC 2) PC For these I am going to locate the user registers and off set And include for all cases when appropriate 64 bit regs. Thank you again > On Feb 5, 2024, at 3:20 AM, Peter Relson > <0000056a472f7cb4-dmarc-requ...@listserv.ua.edu> wrote: > > The fact that registers are saved (or at least land) in the "new RB" and the > PSW in the "old RB" was described many posts earlier. That applies in all > cases where a new (not "first") RB is created. Note that just when that > saving happens can be kind of funky for a case such as XCTL(X). > > The problem that keeps cropping up in the posts is that the OP keeps making > judgments and assumptions that are not true (sometimes because they are > wrong, sometimes because they are incomplete). And these are under the guise > of enhancing a general recovery routine that never was a general recovery > routine, and based on the questions being asked will not be (because it won't > be suitable for an FRR). Now if it's a general ESTAE-type recovery routine, > perhaps that would be a reasonable goal. > > If we want to be picky, System 0C1 is not an abend code. System 0C4 is not an > abend code. These are completion codes which might or might not result from > ABEND. > <snip>For purposes of example the hardware gives control to the program check > FLIH for interrupt code 4 the program check FLIH issues ABEND abend code > 0C4 reason 4</snip> > Well, not exactly. Let's try to be accurate. The program check FLIH issues > SOMETHING that results in recovery seeing a system completion code of 0C4 > reason 4. That SOMETHING happens to be CALLRTM TYPE=PROGCK, about which I > will not provide any additional information. There is no ABEND at this point. > > By the way there are more reason codes for 0C4 than 4,10,11 as of > z/Architecture. > We keep saying that not everything that disrupts a running work unit creates > an RB. It is therefore obviously the case that the registers are saved > somewhere; they are not in a "new RB" when there is no new RB. > > Consider the case where there was a program check when there is an FRR. RTM > understands how to convert a program interrupt code to a system completion > code. It does so, so that it can place that in the proper areas (such as the > SDWA and TCBCMPC and STCBCMPC), and it got the time of error regs from where > the PC FLIH put them. If the FRR retries, no new RB was ever involved. > But let's say that all FRRs percolate, now this is where my hint comes in. > RTM issues an SVC D. This is unlike an application-issued (or other > system-issued) SVC D. But it is still an SVC D which is a type 2 SVC and thus > creates a new RB. Within this RB, the system places the time of error regs > that had been stashed earlier.If you want to find the time of error regs and > you can find RTM's SVRB, they are in there. > > As to the question about high halves (and ARs for that matter), they are > saved in the XSB that corresponds to the RB that has the low halves. > > There was mention about SVC D as being an SVC that can be issued in any > environment, such as being disabled (where normal SVCs cannot). That is not > accurate either (although it's not unreasonable to think of it that way). > When any SVC (x'D' is included) is issued in an improper-for-SVC environment, > the same thing happens - the SVC FLIH issues CALLRTM TYPE=SVCERR. You don't > get an RB for CALLRTM for a type 2 SVC (x'D' is included) issued in an > improper-for-SVC environment. Flow then proceeds similar to the program > interrupt case through FRR processing. If an FRR retries (ignoring a nested > FRR), that's that, no "abend" SVC was successfully processed. If we need to > get to RTM 2 for ESTAE (or even task termination) processing, then the > special SVC D is issued. > > Peter Relsonz/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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
