Rob Think sterilization in this case is only for the purpose of putting the IRB on the RB chain once thats don't the RB/IRB can run Just have to have to make sure the TCB is still valid as Peter pointed out by having a wait without being posted
Thanks > On Mar 1, 2024, at 11:23 AM, reichman...@gmail.com wrote: > > Peter > > Thanks for suggesting that I put a wait after the release of the lock > since as Rob Scott pointed the estate will not run while the lock is held > > I chose to use the CRIB because it returns an IRB or RB/IRB and I would > like to initialize the RB or IRB > > Thank You > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Peter Relson > Sent: Friday, March 1, 2024 9:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Recovery routine for IRB > > If an ESTAE-type recovery routine (whether ESTAE or ESTAEX or ARR or > IEAARR) is established when the IRB blows up, it will get control. > Therefore we conclude that that is not the case. > > What you have shown is not a "recovery routine for IRB" but rather a > recovery routine for the mainline that would cover an IRB if that IRB > happened to run before you terminated and if that IRB blew up so that the > mainline's recovery was the most recent recovery routine. That would not > be intrinsically different than if you LINK'd to a routine and that > routine blew up without recovery. > > You have made an assumption that just because you issued SCHEDIRB that the > IRB will run before the mainline continues. That is not a valid > assumption. It might run as soon as you release the LOCAL lock, it might > not. If you are trying to test what happens when an IRB pops on top of > your RB and that IRB blows up and your RB's recovery gets control, > consider doing something like WAIT on an ECB that is initialized to 0 and > that is never posted. In your testcase that would be right after you > release the LOCAL lock. That would make sure that your mainline did not > proceed too far. > > I don't know why you want to go the route of CIRB to accomplish your test > (and if you must use SCHEDIRB, why not use the form that has the system > initialize the IRB for you and not need you to use CIRB?). Why not use > STIMER or STIMERM to wait for, say, 0.01 seconds, with an exit? The exit > routine runs as an IRB. > > You have not initialized your ESTAEX execute form from a static list form. > Whether that's relevant to your problem or not, I have no idea. > > But it is easily demonstrated that your scenario is not as you describe, > otherwise the ESTAEX routine would get control. > If, for debugging, you want to see if the recovery is in effect (not in > control) when your IRB gets control, see if the +x'A0' word in the TCB > pointed to by PSATOLD is non-0. It will be 0 if there is no > ESTAE/ESTAEX/FESTAE. In the simple case you describe you would expect to > see a non-0 address there (which locates the STAE Control Block, SCB). > > When you are providing a code example and there is any possibility that > someone will want to assemble it (perhaps even to try it), please make > sure it assembles or provide guidance on what to do to get it to assemble. > > 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
