Re: ESTAEX exit WAIT question
On 2020-08-01 18:47, Charles Mills wrote: I only know for a fact that all of the swans I have ever seen were white. At least on the side of the swans that you saw. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
Right. I only know for a fact that all of the swans I have ever seen were white. I believe what is happening is that the DETACH is posting the ATTACH completion ECB and therefore making it available to be waited upon again. Because my ESTAEX exit code, that always WAITs on the same ECB following the DETACH, never* ABENDs S301. I am going to remove the WAIT because it is apparently superfluous. Were it not superfluous it would be ABENDing S301. *Never in my experience, of course. One machine, one LPAR, one z/OS, one program, one short timeframe. > Isn't that what began this whole discussion? Yes. At that point I did not know exactly what was happening. I was getting mysterious results and was looking for clues. I was getting a UNIX program that was failing because some other process already owned signal processing -- and the task that previously owned it should have already been terminated and cleaned up. Grasping at straws, I wondered "could I be coming through my ESTAEX exit twice? Or might the DETACHed task not really be done cleaning up (not complete, ECB not posted)?" I think I now understand the whole process pretty well. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Saturday, August 1, 2020 5:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question I know for a fact that DETACH causes (via some route) the ECB to be posted. To be snide, I'd say that you know for a fact that in all the cases you've seen DETACH causes the ECB to be posted. That's not the same as "know for a fact". Fortunately, it is a fact. DETACH processing "steals" the field used to hold the address of the attach ECB for a while so that the system can wait for the task to terminate. Once that has happened, DETACH processing posts the ATTACH-specified ECB. I always WAIT on the ATTACH ECB and it always works. Isn't that what began this whole discussion? You wanted to wait for the DETACH from your recovery to complete and wanted to do so by waiting on the ATTACH ECB (your mainline had already been waiting on it as part of an ECB list). You can't just do that because you'd get a 301 abend -- the ECB is already marked waiting and nothing in the path that would have gotten you into recovery would have changed that ECB. So "it always works" is not "a fact". Perhaps what is a fact is the wait that you have chosen to do (in the mainline) always works. To avoid the 310 abend, the question would arise of "can you just change the ECB not to be waiting anymore?" and the answer would be at best "maybe". Perhaps fortunately, the better response is "there is no need to do so if you're going to do a DETACH and want to continue only once the task has terminated". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
Outstanding, Peter. Just checking: do you actually want to be snide? First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Saturday, August 1, 2020 8:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question [External Email. Exercise caution when clicking links or opening attachments.] I know for a fact that DETACH causes (via some route) the ECB to be posted. To be snide, I'd say that you know for a fact that in all the cases you've seen DETACH causes the ECB to be posted. That's not the same as "know for a fact". Fortunately, it is a fact. DETACH processing "steals" the field used to hold the address of the attach ECB for a while so that the system can wait for the task to terminate. Once that has happened, DETACH processing posts the ATTACH-specified ECB. I always WAIT on the ATTACH ECB and it always works. Isn't that what began this whole discussion? You wanted to wait for the DETACH from your recovery to complete and wanted to do so by waiting on the ATTACH ECB (your mainline had already been waiting on it as part of an ECB list). You can't just do that because you'd get a 301 abend -- the ECB is already marked waiting and nothing in the path that would have gotten you into recovery would have changed that ECB. So "it always works" is not "a fact". Perhaps what is a fact is the wait that you have chosen to do (in the mainline) always works. To avoid the 310 abend, the question would arise of "can you just change the ECB not to be waiting anymore?" and the answer would be at best "maybe". Perhaps fortunately, the better response is "there is no need to do so if you're going to do a DETACH and want to continue only once the task has terminated". 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 Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
I know for a fact that DETACH causes (via some route) the ECB to be posted. To be snide, I'd say that you know for a fact that in all the cases you've seen DETACH causes the ECB to be posted. That's not the same as "know for a fact". Fortunately, it is a fact. DETACH processing "steals" the field used to hold the address of the attach ECB for a while so that the system can wait for the task to terminate. Once that has happened, DETACH processing posts the ATTACH-specified ECB. I always WAIT on the ATTACH ECB and it always works. Isn't that what began this whole discussion? You wanted to wait for the DETACH from your recovery to complete and wanted to do so by waiting on the ATTACH ECB (your mainline had already been waiting on it as part of an ECB list). You can't just do that because you'd get a 301 abend -- the ECB is already marked waiting and nothing in the path that would have gotten you into recovery would have changed that ECB. So "it always works" is not "a fact". Perhaps what is a fact is the wait that you have chosen to do (in the mainline) always works. To avoid the 310 abend, the question would arise of "can you just change the ECB not to be waiting anymore?" and the answer would be at best "maybe". Perhaps fortunately, the better response is "there is no need to do so if you're going to do a DETACH and want to continue only once the task has terminated". 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
Re: ESTAEX exit WAIT question
> And you probably always got a 13E abend message on the console. No, never in my recollection. None yesterday with all of my testing. But I do see there is a SLIP set for S13E so perhaps that is suppressing it. > The normal thing to do is to tell the subtask to end That would indeed be a wonderful design but I have no control over the logic of the subtask, and it does not include a "tell me to end" interface. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras Sent: Friday, July 31, 2020 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question And you probably always got a 13E abend message on the console. :) The normal thing to do is to tell the subtask to end (usually by posting an ECB the subtask can wait on) and when the ATTACH ECB is posted, the parent wakes up and issues DETACH to clean up. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
And you probably always got a 13E abend message on the console. :) The normal thing to do is to tell the subtask to end (usually by posting an ECB the subtask can wait on) and when the ATTACH ECB is posted, the parent wakes up and issues DETACH to clean up. In article <02d201d66750$066475e0$132d61a0$@mcn.org> you wrote: > I know for a fact that DETACH causes (via some route) the ECB to be posted. > I always WAIT on the ATTACH ECB and it always works. > Whether that WAIT is superfluous or not is something I have no way of > testing. > I believe you (of course!) but the WAIT is harmless at worst so I think I > will leave it in place. > Charles > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Relson > Sent: Friday, July 31, 2020 7:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ESTAEX exit WAIT question > If I remember correctly, DETACH of a subtask does not return to the > invoker until that task has completely terminated (and I mean completely > -- all resmgrs have run, the TCB is freemained). If so, there is no reason > to have an ECB to wait upon. In fact I think the ATTACH ECB is not even > used once DETACH is done. (I'm hoping that my thought does not pertain > only to the branch-entry DETACH that RTM does, but also pertains to the > SVC-entry DETACH that you would be doing.) > If you want your recovery to > -- end the task > -- upon end, attach a new task > then > -- detach > -- attach > Peter Relson > z/OS Core TEchnology Design -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
I know for a fact that DETACH causes (via some route) the ECB to be posted. I always WAIT on the ATTACH ECB and it always works. Whether that WAIT is superfluous or not is something I have no way of testing. I believe you (of course!) but the WAIT is harmless at worst so I think I will leave it in place. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Friday, July 31, 2020 7:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question If I remember correctly, DETACH of a subtask does not return to the invoker until that task has completely terminated (and I mean completely -- all resmgrs have run, the TCB is freemained). If so, there is no reason to have an ECB to wait upon. In fact I think the ATTACH ECB is not even used once DETACH is done. (I'm hoping that my thought does not pertain only to the branch-entry DETACH that RTM does, but also pertains to the SVC-entry DETACH that you would be doing.) If you want your recovery to -- end the task -- upon end, attach a new task then -- detach -- attach 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
Re: ESTAEX exit WAIT question
If I remember correctly, DETACH of a subtask does not return to the invoker until that task has completely terminated (and I mean completely -- all resmgrs have run, the TCB is freemained). If so, there is no reason to have an ECB to wait upon. In fact I think the ATTACH ECB is not even used once DETACH is done. (I'm hoping that my thought does not pertain only to the branch-entry DETACH that RTM does, but also pertains to the SVC-entry DETACH that you would be doing.) If you want your recovery to -- end the task -- upon end, attach a new task then -- detach -- attach 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
Re: ESTAEX exit WAIT question
Hmmm. That would have been a much simpler approach, although I am a little reluctant to touch my dub setting because that code is early in the process and has been working for years. If I screw it up, gosh knows what stops working. This new code -- it only runs if the user cancels the job. There's a limit to how badly you can screw up a job that the user has already cancelled! Ah, looking at my code DUBPROCESS (1) is what I *am* setting, when I do a set_dub_default(), which is not always. Not sure if I am doing one in my ABEND test situation or not. I think not. Thanks. I will keep this in mind. If this turns out to be problematic then DUBPROCESS would be an alternative approach. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, July 30, 2020 4:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question Taking these two posts together, I think you should look at BPX1SDD/BPX4SDD a.k.a. set_dub_default(). If you set the value to DUBPROCESS in the job step, before ATTACHing your subtask, the subtask will be a separate process and should clean up at its termination. The default, DUBTHREAD, does not cause the subtask to be a separate process, and in that case I would expect that the cleanup will not occur until the parent (job step) task ends. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxb100/sdd.htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
Forty years or whatever and MVS still holds surprises for us! I guess that's what makes it still fun after all these years. I did this in another situation: did a TON of stuff in an ESTAEX exit. Yes, you are on life support, there is no getting away from that, and any ABEND is fatal (well, I read something today about a "Nested ESTAE" but without that, any ABEND is fatal) but you can do a ton of stuff before you die. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Thursday, July 30, 2020 4:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question OK, great. I was surprised you can ATTACH from your ESTAE recovery routine at all... so I picked up something new. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
On 2020-07-30 12:59, Charles Mills wrote: Thanks @Peter. I wondered about an ATTACH RMTR. I was fishing a bit when I wrote the OP. I understand the problem now: I have a non-authorized batch program. I have complete control over the logic. It runs a UNIX program as a subtask. I have no control over the logic of the UNIX program. Under certain circumstances -- a timeout -- the batch program cancels the UNIX program subtask. (DETACH and ABEND S13E) The batch program then runs another UNIX program as a subtask -- with no issues. This has been working perfectly for years. I want to add logic such that if the batch program user cancels (CANCEL ABEND S222) the batch program it similarly cancels the UNIX program and attaches another. I have an ESTAEX exit that catches the ABEND Sx22 and does the DETACH and ATTACH. The problem I am seeing is that the second UNIX program fails with Reason Code 0D070201 JRAlreadySigSetUp: BPX1MSS found the process already set up for signals. My inference is that the first UNIX program does not finish "cleaning up" in this situation. It does not finish cleaning up when DETACHed by an ESTAEX exit, even though it does clean up properly when DETACHed by the mainline in a timeout situation. (I can't clean up the signal registration myself with BPX1MSD() -- that fails because the running main task does not own the signal registration, the terminated subtask does.) Any thoughts or suggestions? I tried STAE=YES on the DETACH with no apparent effect other than that it changed the subtask ABEND from S13E to S33E. I have not tried using ETXR (or RMTR ). Not sure what I would do differently or additionally with an ETXR. ETXR is documented as running on the originating task, so I would have the same problem with BPX1MSD(). On 2020-07-30 14:12, Charles Mills wrote: > Ah! No, I understand that. I am not trying to "defeat" S222. The second subtask is a legitimate cleanup effort. When it ends, the main program will return, percolate and ABEND. Taking these two posts together, I think you should look at BPX1SDD/BPX4SDD a.k.a. set_dub_default(). If you set the value to DUBPROCESS in the job step, before ATTACHing your subtask, the subtask will be a separate process and should clean up at its termination. The default, DUBTHREAD, does not cause the subtask to be a separate process, and in that case I would expect that the cleanup will not occur until the parent (job step) task ends. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxb100/sdd.htm -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
OK, great. I was surprised you can ATTACH from your ESTAE recovery routine at all... so I picked up something new. sas On Thu, Jul 30, 2020 at 6:53 PM Charles Mills wrote: > I think I have it. I call mvsprocclp (BPX1MPC, BPX4MPC) — Clean up kernel > resources from the main task and that seems to do the trick. > > Not sure if it undubs me. If so, I may have to re-do my setdubdefault(1). > Still testing, but I seem to be past the main issue. > > @Steve, all the "MVS" stuff has always been fine: I catch the ABEND, > attach the UNIX program, wait for it to complete, do the rest of my > cleanup, percolate and end. That all has worked more or less from the > get-go. My only problem was that the UNIX program was "completing" with a > total failure. > > Thanks for the suggestions. > > Charles > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
I think I have it. I call mvsprocclp (BPX1MPC, BPX4MPC) — Clean up kernel resources from the main task and that seems to do the trick. Not sure if it undubs me. If so, I may have to re-do my setdubdefault(1). Still testing, but I seem to be past the main issue. @Steve, all the "MVS" stuff has always been fine: I catch the ABEND, attach the UNIX program, wait for it to complete, do the rest of my cleanup, percolate and end. That all has worked more or less from the get-go. My only problem was that the UNIX program was "completing" with a total failure. Thanks for the suggestions. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Thursday, July 30, 2020 11:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question On Thu, 30 Jul 2020 at 12:59, Charles Mills wrote: > > (I can't clean up the signal registration myself with BPX1MSD() -- that > fails because the running main task does not own the signal registration, > the terminated subtask does.) > > Any thoughts or suggestions? > Could you use a task level resource manager? This gets control under an RB for the terminating task. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
I believe an ESTAI recovery runs on the subtask as well. Can't say which is better. Either may obviate the need to re-attach it, which would be good, because you might find more problems with that. sas On Thu, Jul 30, 2020 at 2:44 PM Tony Harminc wrote: > On Thu, 30 Jul 2020 at 12:59, Charles Mills wrote: > > > > > (I can't clean up the signal registration myself with BPX1MSD() -- that > > fails because the running main task does not own the signal registration, > > the terminated subtask does.) > > > > Any thoughts or suggestions? > > > > Could you use a task level resource manager? This gets control under an RB > for the terminating task. > > Tony H. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
On Thu, 30 Jul 2020 at 12:59, Charles Mills wrote: > > (I can't clean up the signal registration myself with BPX1MSD() -- that > fails because the running main task does not own the signal registration, > the terminated subtask does.) > > Any thoughts or suggestions? > Could you use a task level resource manager? This gets control under an RB for the terminating task. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
Ah! No, I understand that. I am not trying to "defeat" S222. The second subtask is a legitimate cleanup effort. When it ends, the main program will return, percolate and ABEND. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Thursday, July 30, 2020 11:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question If I understand what you're saying, you want to treat being CANCELed like a message to recycle your subtask. That will not work. An ESTAE recovery routine isn't allowed to retry for a CANCEL. All sorts of things happen with RTM for a cancel, and trying to continue running isn't a viable option. The jobstep is on the gurney with the needle in its arm, awaiting only its last wor... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
If I understand what you're saying, you want to treat being CANCELed like a message to recycle your subtask. That will not work. An ESTAE recovery routine isn't allowed to retry for a CANCEL. All sorts of things happen with RTM for a cancel, and trying to continue running isn't a viable option. The jobstep is on the gurney with the needle in its arm, awaiting only its last wor... sas On Thu, Jul 30, 2020 at 1:42 PM Charles Mills wrote: > ... > I want to add logic such that if the batch program user cancels (CANCEL > ABEND S222) the batch program it similarly cancels the UNIX program and > attaches another. I have an ESTAEX exit that catches the ABEND Sx22 and > does > the DETACH and ATTACH. > ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
FWIW I note that the BPX1MSS documentation (z/OS V2R1.0 UNIX System Services Programming: Assembler Callable Services Reference) says "Both MVS task termination and the mvsprocclp service (BPX1MPC, BPX4MPC) perform the mvsunsigsetup service." It appears that may not be happening in task termination. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, July 30, 2020 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question Thanks @Peter. I wondered about an ATTACH RMTR. I was fishing a bit when I wrote the OP. I understand the problem now: I have a non-authorized batch program. I have complete control over the logic. It runs a UNIX program as a subtask. I have no control over the logic of the UNIX program. Under certain circumstances -- a timeout -- the batch program cancels the UNIX program subtask. (DETACH and ABEND S13E) The batch program then runs another UNIX program as a subtask -- with no issues. This has been working perfectly for years. I want to add logic such that if the batch program user cancels (CANCEL ABEND S222) the batch program it similarly cancels the UNIX program and attaches another. I have an ESTAEX exit that catches the ABEND Sx22 and does the DETACH and ATTACH. The problem I am seeing is that the second UNIX program fails with Reason Code 0D070201 JRAlreadySigSetUp: BPX1MSS found the process already set up for signals. My inference is that the first UNIX program does not finish "cleaning up" in this situation. It does not finish cleaning up when DETACHed by an ESTAEX exit, even though it does clean up properly when DETACHed by the mainline in a timeout situation. (I can't clean up the signal registration myself with BPX1MSD() -- that fails because the running main task does not own the signal registration, the terminated subtask does.) Any thoughts or suggestions? I tried STAE=YES on the DETACH with no apparent effect other than that it changed the subtask ABEND from S13E to S33E. I have not tried using ETXR (or RMTR ). Not sure what I would do differently or additionally with an ETXR. ETXR is documented as running on the originating task, so I would have the same problem with BPX1MSD(). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
Thanks @Peter. I wondered about an ATTACH RMTR. I was fishing a bit when I wrote the OP. I understand the problem now: I have a non-authorized batch program. I have complete control over the logic. It runs a UNIX program as a subtask. I have no control over the logic of the UNIX program. Under certain circumstances -- a timeout -- the batch program cancels the UNIX program subtask. (DETACH and ABEND S13E) The batch program then runs another UNIX program as a subtask -- with no issues. This has been working perfectly for years. I want to add logic such that if the batch program user cancels (CANCEL ABEND S222) the batch program it similarly cancels the UNIX program and attaches another. I have an ESTAEX exit that catches the ABEND Sx22 and does the DETACH and ATTACH. The problem I am seeing is that the second UNIX program fails with Reason Code 0D070201 JRAlreadySigSetUp: BPX1MSS found the process already set up for signals. My inference is that the first UNIX program does not finish "cleaning up" in this situation. It does not finish cleaning up when DETACHed by an ESTAEX exit, even though it does clean up properly when DETACHed by the mainline in a timeout situation. (I can't clean up the signal registration myself with BPX1MSD() -- that fails because the running main task does not own the signal registration, the terminated subtask does.) Any thoughts or suggestions? I tried STAE=YES on the DETACH with no apparent effect other than that it changed the subtask ABEND from S13E to S33E. I have not tried using ETXR (or RMTR ). Not sure what I would do differently or additionally with an ETXR. ETXR is documented as running on the originating task, so I would have the same problem with BPX1MSD(). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, July 30, 2020 8:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESTAEX exit WAIT question Another "option" you could consider: use an RMTR for your ATTACH and have the RMTR post an ECB that is not the ECB specified on ATTACH (if using an RMTR you probably wouldn't use an ECB on ATTACH at all). Oops. ETXR not RMTR Those darn "4 letter words"... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAEX exit WAIT question
Another "option" you could consider: use an RMTR for your ATTACH and have the RMTR post an ECB that is not the ECB specified on ATTACH (if using an RMTR you probably wouldn't use an ECB on ATTACH at all). Oops. ETXR not RMTR Those darn "4 letter words"... 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
Re: ESTAEX exit WAIT question
>Is it legal for the ESTAEX exit code to WAIT on one of those ECBs? Any code in a suitable environment (e.g., it can't be disabled) can wait on anything that is of a suitable key and is not already waiting. If already waiting, wait abends. > Is it possible to cancel a WAIT? I call that "post". If you are waiting on an ECB list with a count of "n" and the nth ECB is posted, then the post processing will unwait the other ECBs (i.e, turn off the wait bit). That makes it so that when you "wake up" from the wait, you can re-enter the wait. The unwaiting does not happen if you were waiting and then "blew up" (perhaps by a cancel or an abending IRB). But you are of course not truly waiting any longer. An ECB marked waiting is managed by post. Post might be keeping track (it has a "wait post request block" to track things for unauthorized wait/post); even if you have the local lock and update the ECB you would be creating a mismatch between the state that the system expects and reality. That could be problematic. Another "option" you could consider: use an RMTR for your ATTACH and have the RMTR post an ECB that is not the ECB specified on ATTACH (if using an RMTR you probably wouldn't use an ECB on ATTACH at all). 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
