It is perfectly valid to "have" an ESTAE-type recovery routine while you hold a lock or are disabled. You might not be able to set it in that environment (the OP's code set the ESTAEX while not in either of those states), but if you set it before, it will participate. Branch-entry ESTAE has some limited use cases where you can set an ESTAE even though locked; ESTAEX does not support that.
An ESTAE-type recovery routine will get control if any/all FRRs have percolated for an error that happened while locked or disabled, but any locks will have been released and enablement will have been re-established so the routine gets control enabled and unlocked (much recovery might need to get control still holding the locks in order not to lose serialization; those cases need an FRR). The lock release(s) and enablement happen at the "transition" from "RTM1" (FRR processing) to "RTM2" (ESTAE-type processing). RTM1 issues an SVC D to get to RTM2 (enabled, unlocked, not XM mode); this is not an "abend" in the normal sense of the term. Regarding the response about "why CIRB", it was not really on point. You likely do not need to build/touch IQE/IRB. The parameters on SCHEDIRB (such as EPPTR, MODE, KEY et al) generally cover all the pieces of data that you would set in the IRB. They do cover all that you showed in your code example. It is documented that SCHEDIRB is suggested rather than CIRB. 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
