I can only say that maybe even if I don’t require it go into supervisor state and issue a SETFRR with Enabled unlocked task
I don’t know if I’ll go there but the registers associated with the creators of the ESTAE are good enough as the base registers are intact enough to point to my retry to clean up resources Thanks On Oct 30, 2018, at 7:47 AM, Peter Relson <rel...@us.ibm.com> wrote: >> programmatically is there a way to determine were the program registers > are > > In general, no. But specifically, "programmatically", sure (not > necessarily easily). > > -- The SDWA for an FRR has the time-of-error registers. > -- The SDWA for an ESTAE has the time-of-error registers and (we can think > of it like this) registers associated with the ESTAE-creator (I use the > term 'associate' loosely). > so neither of those are the registers at the time of the "call" (or, more > correct, the issuance of the DETACH SVC 62). > > How the routine that you called saved registers totally depends on the > routine. > DETACH is a type 2 SVC, thus runs as an SVRB. Therefore the system has > saved registers and PSW of the invoker of the SVC across the SVRB (the > newest RB, pointed to by PSATOLD->TCBRBP, has the regs) and the RB that > the SVRB's RBLINKB field points to (the calling program's RB, has the > PSW). > > Of course these are the RB's at the time that DETACH is running. By the > time recovery gets control for ESTAE-type recovery, it's different because > RTM's SVC D SVRB is in there as is the SYNCH-target RB for your ESTAE. > > Peter Relson > z/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
