Re: ATTACHX/STIMERM WAIT=YES
On Tue, 14 Nov 2023 12:49:54 + Peter Relson wrote: :>As was alluded to, if it doesn't work when you "do that" (STIMERM WAIT), then don't "do that". :>If you want to be able to "communicate" then you wait on multiple ECBs and do not use STIMERM WAIT, but use STIMERM with an exit that posts one of the ECBs. The "communication" can be by posting one of the other ECBs. :>If you want only to terminate B (disruptively) then use DETACH. Don't recall ever looking at this, but if STIMER(M) WAIT is instantiated by SUSPENDing the RB, the parent task can RESUME it. But as that requires supervisor state, I wonder if it may have side effects when the timer eventually pops. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACHX/STIMERM WAIT=YES
As was alluded to, if it doesn't work when you "do that" (STIMERM WAIT), then don't "do that". If you want to be able to "communicate" then you wait on multiple ECBs and do not use STIMERM WAIT, but use STIMERM with an exit that posts one of the ECBs. The "communication" can be by posting one of the other ECBs. If you want only to terminate B (disruptively) then use DETACH. 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: ATTACHX/STIMERM WAIT=YES
On Mon, 13 Nov 2023 18:37:15 -0600 Paul Schuster wrote: :>How to handle this situation: task A attaches a subtask, task B. :>The B task issues a STIMERM WAIT=YES :>Task A terminates, but gets the A03 abend since task B still active. :>How can task A communicate to the subtask B that it (task B) needs to terminate? Task B is in the STIMERM wait, so it cant do anything. :>I didnt see this scenario documented in the Assembler Services Guide or the Assembler Services References. Programming. If you want B to come down nicely you need to provide communication so that A can tell B to shutdown. Don't care? Do a DETACH. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACHX/STIMERM WAIT=YES
If the OP would like to see some example source for this sort of thing, I included simple task and timer interactions in the "Example Cross-Memory Server" code I wrote for Share Dallas. You can download the code from : https://github.com/rscott-rocket/mxe Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Tuesday, November 14, 2023 2:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACHX/STIMERM WAIT=YES EXTERNAL EMAIL On Mon, 13 Nov 2023 at 19:37, Paul Schuster wrote: > How to handle this situation: task ‘A’ attaches a subtask, task ‘B’. > > The ‘B’ task issues a STIMERM WAIT=YES > > Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active. > > How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’) > needs to terminate? Task ‘B’ is in the STIMERM wait, so it can’t do anything. > The typical approach is to not use WAIT on the STIMERM in Task B, but rather specify a local ECB to be POSTed. Then do your own WAIT, specifying both that ECB and also an ECB that Task A passes to Task B as an argument on the ATTACH[X]. When Task A wants to shut things down, it POSTs the ECB it passed to B, and then in turn *it* WAITs on the other ECB that you specified on the ATTACH with ECB=. When Task B awakes from its WAIT, it checks which ECB was posted. If it's the STIMER one, it does whatever it does for that, and goes back and re-issues the STIMERM and the WAIT. If it's the one saying "A says to shut down", B cleans up and returns to the system, which then POSTs the ECB that A put on the ATTACH. This assumes that in your description Task A *intends* to shut down B and then itself. If Task A instead terminates unexpectedly, then you need to figure out what you *want* it to do. You could put ESTAI= on the ATTACH, and catch B's abend there. But if A abended in the first place... This isn't really as complex as I'm making it sound with a poorly organized description. Just don't do that WAIT on the STIMERM. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACHX/STIMERM WAIT=YES
On Mon, 13 Nov 2023 at 19:37, Paul Schuster wrote: > How to handle this situation: task ‘A’ attaches a subtask, task ‘B’. > > The ‘B’ task issues a STIMERM WAIT=YES > > Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active. > > How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’) needs > to terminate? Task ‘B’ is in the STIMERM wait, so it can’t do anything. > The typical approach is to not use WAIT on the STIMERM in Task B, but rather specify a local ECB to be POSTed. Then do your own WAIT, specifying both that ECB and also an ECB that Task A passes to Task B as an argument on the ATTACH[X]. When Task A wants to shut things down, it POSTs the ECB it passed to B, and then in turn *it* WAITs on the other ECB that you specified on the ATTACH with ECB=. When Task B awakes from its WAIT, it checks which ECB was posted. If it's the STIMER one, it does whatever it does for that, and goes back and re-issues the STIMERM and the WAIT. If it's the one saying "A says to shut down", B cleans up and returns to the system, which then POSTs the ECB that A put on the ATTACH. This assumes that in your description Task A *intends* to shut down B and then itself. If Task A instead terminates unexpectedly, then you need to figure out what you *want* it to do. You could put ESTAI= on the ATTACH, and catch B's abend there. But if A abended in the first place... This isn't really as complex as I'm making it sound with a poorly organized description. Just don't do that WAIT on the STIMERM. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACHX/STIMERM WAIT=YES
Just off the top of my head from having a similar issue a few years ago, you may need to be watching two ECBs (EVENTS). But I'm not sure that the STIMERM won't cause a squawk when you have the task end. And I think you will have to pass the address of the ECB you will POST for termination to the Attached task. Otherwise, you might be able to do a CALLRTM to terminate the subtask. Now, the subtask will need an error recovery routine to hide the fact that you just term'ed it. Here is what the macro contains relative to this: THE STIMERM MACRO ALLOWS THE ISSUER TO SET, TEST OR CANCEL UP TO 16 REAL TIME INTERVALS. AT THE TIME THE INTERVAL IS ESTABLISHED, THE CALLER MAY OPTIONALLY SPECIFY AN EXIT ROUTINE TO BE GIVEN CONTROL ASYNCHRONOUSLY AFTER THE TIME INTERVAL EXPIRES OR THAT EXECUTION OF THE CURRENT TASK IS TO BE SUSPENDED. AN ERROR EXIT MAY ALSO BE SPECIFIED WHICH MAY BE GIVEN CONTROL IF THE STIMERM FUNCTION CANNOT BE PERFORMED. Steve Thompson On 11/13/2023 7:37 PM, Paul Schuster wrote: How to handle this situation: task ‘A’ attaches a subtask, task ‘B’. The ‘B’ task issues a STIMERM WAIT=YES Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active. How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’) needs to terminate? Task ‘B’ is in the STIMERM wait, so it can’t do anything. I didn’t see this scenario documented in the Assembler Services Guide or the Assembler Services References. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACHX/STIMERM WAIT=YES
DETACH? Or do you need something less disruptive? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי From: IBM Mainframe Discussion List on behalf of Paul Schuster Sent: Monday, November 13, 2023 7:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ATTACHX/STIMERM WAIT=YES How to handle this situation: task ‘A’ attaches a subtask, task ‘B’. The ‘B’ task issues a STIMERM WAIT=YES Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active. How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’) needs to terminate? Task ‘B’ is in the STIMERM wait, so it can’t do anything. I didn’t see this scenario documented in the Assembler Services Guide or the Assembler Services References. Thank you. -- 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
ATTACHX/STIMERM WAIT=YES
How to handle this situation: task ‘A’ attaches a subtask, task ‘B’. The ‘B’ task issues a STIMERM WAIT=YES Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active. How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’) needs to terminate? Task ‘B’ is in the STIMERM wait, so it can’t do anything. I didn’t see this scenario documented in the Assembler Services Guide or the Assembler Services References. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
