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 [email protected] with the message: INFO IBM-MAIN
