There is some misinformation in this thread already. (I apologize if my answers aren't fully correct, as this is from memory; Jim Mulder can correct me)
<snip> That loaded program had its PSW regs at SDWAEC2 and SDWASRSV respectively </snip> Ignoring what is meant by the "loaded program had its...", the thing to remember is that there are two sets of regs and two PSWs in the SDWA for an ESTAE-type recovery routine. The two sets of regs are SDWASRSV and SDWAGRSV. One set is "time of error". The other is "time of last interrupt" but beware that not all interrupts count (for example, a time slice would not count). I rarely found "time of last interrupt" to be of much use, but it is one way (for example) to help set retry regs. Many abends put caller-reg information into time-of-abend regs (and document so), such as the caller's reg 1. Of course my "rarely" might be related to the fact that I had access to system listings.... <snip> Each RB has unique recovery. Your PRB has an ESTAE. If as you believe the abend was in an SVC (SVRB) then it too would have different recovery from your ESTAE. The SVRB passes the abend to your PRB and then terminates. That is why you don't see the SVRB and instead, see your PRB and your PRB's PSW in the SDWA. </snip> Sort of. The reason you see the PRB and your PRB's PSW in the SDWA is because the ESTAE-type recovery is associated with your PRB. As to "and then terminates", not really, at least in system terms. Let's say the "caller" issued an SVC that created an SVRB and the service issues ABEND. An Abend SVRB is created (the issuer's SVRB is still there). RTM gives control to an ESTAE-type recovery routine via SYNCH which creates a new PRB for the recovery routine. No RB in this picture has yet "terminated". If the Recovery routine is for the ABEND-issuer and it percolates then that Recovery PRB will terminate; if there is no recovery routine for the abend-issuer then that doesn't happen of course, Then RTM will use SYNCH for the caller's recovery routine.So now we have caller's PRB, SVC's SVRB, abend's SVRB, caller's ESTAE's PRB. The relevant RB's don't actually "terminate" (in system terminology) until RTM2 retries or the last recovery routine percolates. It is true that the code for the SVC's SVRB would never get control again in this scenario; so maybe you think of that as "terminates". <snip> I've written PC routines but never bothered to see if it runs under an SVRB, PRB or ???. An abend in a PC routine simply goes away without propagating the abend to the caller. My recovery in the PC updated the return code instead of passing an abend There must be a method for passing an abend because IBM converted STORAGE from an SVC to PC and retained the S8x8 abends. </snip> A PC routine does not create an RB so it runs under whatever RB (or SRB) is currently active. I'm not sure why you'd say that the abend is not propagated to the caller. Sure it is. If the caller has a recovery routine and issues a PC and the PC routine abends (and the PC routine does not have recovery that retries) then the caller's recovery routine would get control. An SVC-entry or branch-entry service is the same. IBM didn't really "convert" STORAGE from an SVC to PC. It "created" STORAGE as a PC. Subsequently we added LINKAGE= options so that you could get SVC-entry and branch-entry forms generated by the STORAGE macro.This was done simply to save cost -- when a new option was added, it could be supported only in the STORAGE macro and did not also have to be done (and tested) in the GETMAIN/FREEMAIN macros. <snip> But the rb had an CDE pointing not to the loaded module but the main module </snip> That's what you should expect. When non-zero, RBCDE is the CDE that was used to load the module represented by the (P)RB which in your terminology is the "main module". It has nothing to do with modules loaded by the main module. Peter Relson ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
