I used Peter Relson suggestion to put a wait macro after release lock Truth is don’t think any thing or a different RB can be scheduled while holding the local lock as the code is serialized
Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Seymour J Metz <sme...@gmu.edu> Sent: Friday, March 1, 2024 1:50:31 PM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Recovery routine for IRB ITYM RQE/IRB. Doees the IQE stll exist? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Joseph Reichman <000005812645a43c-dmarc-requ...@listserv.ua.edu> Sent: Friday, March 1, 2024 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Recovery routine for IRB 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 ---------------------------------------------------------------------- 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
