Re: How to quietly terminate not detached subtask
On Sat, 18 Oct 2014 23:39:12 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: Is there some kind of USS communication path available? The standard MVS XMEM post requires APF. Classically, there are XMEM communication paths. For example, I believe PDSE, perhaps JES, HSM, Allocation, ..., run in separate address spaces, yet a lowly user address space with no APF authorization can communicate with any of those. Communication across forked address spaces is hardly novel. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
On Sun, 19 Oct 2014 17:46:01 -0500 Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: :On Sat, 18 Oct 2014 23:39:12 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: : :Is there some kind of USS communication path available? The standard MVS XMEM :post requires APF. : :Classically, there are XMEM communication paths. For example, I believe :PDSE, perhaps JES, HSM, Allocation, ..., run in separate address spaces, yet :a lowly user address space with no APF authorization can communicate with :any of those. Communication across forked address spaces is hardly novel. Communication with such address spaces start with an SVC/PC which grants supervisor state. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
On Mon, 20 Oct 2014 06:11:20 +0300, Binyamin Dissen wrote: :Is there some kind of USS communication path available? The standard MVS XMEM :post requires APF. Communication with such address spaces start with an SVC/PC which grants supervisor state. I believe you've answered your own question. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
Well, I have no experience with forking an address space, but how would the two communicate? Usually, there is some sort of common shared storage which does require APF authorization to establish and cleanup. Thanks! This would be a totally different ball game as it brings an extra layer of communication between the address spaces. This would also require extra authorization which wouldn't fly well with the management Yes, it requires extra communication. But it solves your problem in a clean way :) I'm not sure in what sense you mean extra authorization. It does not require any form of system authorization (APF, supervisor state, system key), though it might require that the user ID that the main address space is running under has an OMVS identity (UNIX UID and GID) defined. But the ID may already be set up that way. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
On Sat, 18 Oct 2014 23:39:12 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: Is there some kind of USS communication path available? The standard MVS XMEM post requires APF. You wouldn't be posting; you'd be sending messages back and forth through one of a variety of UNIX communication mechanisms. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
On Thu, 16 Oct 2014 20:27:27 -0500, Walt Farrell wrote: Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. You might consider going a bit further, and using fork() and execmvs() to create a new address space running your new code. That will isolate it quite well from the original task. And since you will not get control to signal it to terminate, it might do so after some period of time without hearing from you, say 5 minutes or whatever value you consider reasonable. fork() should return a descriptor that the parent can use to kill() the child. I don't know that meets the quietly requirement. The child could trap the signal and terminate in an orderly manner. (Does execmvs() return a PID?) A possible disadvantage is that neither fork() nor execmvs() propagates DD statements. This can be merely cumbersome in that the child must perform its own allocations, or more serious if ENQ conflicts result. Descriptors, however, are propagated by fork() and (I've been told) by execmvs(), so the parent can communicate with the child via pipes. Since (I believe) execmvs() creates a new address space, spawn() might be as effective as fork(). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
Thanks! This would be a totally different ball game as it brings an extra layer of communication between the address spaces. This would also require extra authorization which wouldn't fly well with the management === Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. You might consider going a bit further, and using fork() and execmvs() to create a new address space running your new code. That will isolate it quite well from the original task. And since you will not get control to signal it to terminate, it might do so after some period of time without hearing from you, say 5 minutes or whatever value you consider reasonable. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
On 16 October 2014 14:00, Victor Gil victor@broadridge.com wrote: Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I've been pondering these task matters, but it strikes me that this may be entirely the wrong approach. I don't know DB2, but I'd be a little surprised if it keeps track of connection attributes (cursors, locks, etc.) only at the TCB level, and doesn't have any mechanism to maintain independent connections at a lower level. Surely there is some kind of object or control block or the like that can be instantiated more than once in an MVS task that can represent these things. Is it not possible, e.g, for a server to handle multiple users each with their own connection to DB2 using a single TCB? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
Sounds very reasonable. I would certainly think so. I am way less than a DB2 expert but I don't think any cursor type information is maintained in any sort of magic control block. Even a single simple COBOL program can be doing multiple logically independent things at the same time. There is a list where the people who actually are DB2 experts hang out: http://www.idug.org/p/fo/et/topic=19 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Friday, October 17, 2014 10:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to quietly terminate not detached subtask On 16 October 2014 14:00, Victor Gil victor@broadridge.com wrote: Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I've been pondering these task matters, but it strikes me that this may be entirely the wrong approach. I don't know DB2, but I'd be a little surprised if it keeps track of connection attributes (cursors, locks, etc.) only at the TCB level, and doesn't have any mechanism to maintain independent connections at a lower level. Surely there is some kind of object or control block or the like that can be instantiated more than once in an MVS task that can represent these things. Is it not possible, e.g, for a server to handle multiple users each with their own connection to DB2 using a single TCB? Tony H. -- 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: How to quietly terminate not detached subtask
Not reasonable at all! Quoting from the DB2 manual [watch the wrap] http://www-01.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.sqlref/src/tpc/db2z_sql_connect.dita Successful Connection: If the CONNECT statement is successful: • All open cursors are closed, all prepared statements are destroyed, and all locks are released from the previous application server. • The application process is disconnected from its previous application server, if any, and connected to the identified application server. • The actual name of the application server (not an alias) is placed in the CURRENT SERVER special register. • Information about the application server is placed in the SQLERRP field of the SQLCA. If the application server is an IBM® product, the information has the form pppvvrrm, ... == Sounds very reasonable. I would certainly think so. I am way less than a DB2 expert but I don't think any cursor type information is maintained in any sort of magic control block. Even a single simple COBOL program can be doing multiple logically independent things at the same time. There is a list where the people who actually are DB2 experts hang out: http://www.idug.org/p/fo/et/topic=19 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Friday, October 17, 2014 10:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to quietly terminate not detached subtask On 16 October 2014 14:00, Victor Gil victor@broadridge.com wrote: Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I've been pondering these task matters, but it strikes me that this may be entirely the wrong approach. I don't know DB2, but I'd be a little surprised if it keeps track of connection attributes (cursors, locks, etc.) only at the TCB level, and doesn't have any mechanism to maintain independent connections at a lower level. Surely there is some kind of object or control block or the like that can be instantiated more than once in an MVS task that can represent these things. Is it not possible, e.g, for a server to handle multiple users each with their own connection to DB2 using a single TCB? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
Well, I told you I wasn't a DB2 expert! g You can't share the other program's existing connection? Not do a new CONNECT, but just do whatever you have to do? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Victor Gil Sent: Friday, October 17, 2014 12:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to quietly terminate not detached subtask Not reasonable at all! Quoting from the DB2 manual [watch the wrap] http://www-01.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.sqlref/src/tpc/db2z_sql_connect.dita Successful Connection: If the CONNECT statement is successful: • All open cursors are closed, all prepared statements are destroyed, and all locks are released from the previous application server. • The application process is disconnected from its previous application server, if any, and connected to the identified application server. • The actual name of the application server (not an alias) is placed in the CURRENT SERVER special register. • Information about the application server is placed in the SQLERRP field of the SQLCA. If the application server is an IBM® product, the information has the form pppvvrrm, ... == Sounds very reasonable. I would certainly think so. I am way less than a DB2 expert but I don't think any cursor type information is maintained in any sort of magic control block. Even a single simple COBOL program can be doing multiple logically independent things at the same time. There is a list where the people who actually are DB2 experts hang out: http://www.idug.org/p/fo/et/topic=19 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
On 17 October 2014 15:43, Victor Gil victor@broadridge.com wrote: If the CONNECT statement is successful: • All open cursors are closed, all prepared statements are destroyed, and all locks are released from the previous application server. • The application process is disconnected from its previous application server, if any, and connected to the identified application server. • The actual name of the application server (not an alias) is placed in the CURRENT SERVER special register. • Information about the application server is placed in the SQLERRP field of the SQLCA. If the application server is an IBM® product, the information has the form pppvvrrm, It's not obvious to me that a DB2 application process is a TCB. Sure, maybe it is, but then you'd think they'd call it that, or perhaps a task. An application process sounds more to me like an abstraction for DB2's purposes of some kind of run unit - process, thread, task, address space. Think about CICS; surely it runs multiple users, each with quite different DB2 contexts, under a single TCB? It must have some way of maintaining an application process for each user. What about Language Environment enclaves? This sounds like something similar; by default an MVS TCB is its own enclave, but it can certainly support more than one by using the LE anchor block support. But I really know almost nothing about DB2, and it's been decades since I last used its closest relative, SQL/DS, so I may be quite full of it. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
When a load module running under a TCB connects to DB2 for the 1st time, it creates within DB2 something called an ASCE, if no other TCB in the address space has previously connected. That represents the address space connection. The next thing that is created is an ACE, that represents the TCB. If I remember correctly, the connection info for the TCB is hung off the SSAT table, anchored off the TCB. When CICS needs to talk to DB2, it switches the request to one of the DB2 TCB's defined in the CICS region for that purpose. The DB2 DDF address space uses SRB mode code to talk to DB2, but that is the only non-TCB mode DB2 connection that I am aware of. The relationship of the TCB to the ACE is what makes it hang together. There is/are vendor code out there that talks to more than one DB2 system from the same TCB, but they play the usual vendor games to make it happen. Not something for the faint of heart to try. If he needs to talk to more than one DB2 system from the same address space, he is heading down the right path. I thought the earlier suggestion of creating another address space was spot on, but the op stated his management team was comprised of technical wizards that would object. --Dave On 10/17/2014 4:27 PM, Tony Harminc wrote: On 17 October 2014 15:43, Victor Gil victor@broadridge.com wrote: If the CONNECT statement is successful: • All open cursors are closed, all prepared statements are destroyed, and all locks are released from the previous application server. • The application process is disconnected from its previous application server, if any, and connected to the identified application server. • The actual name of the application server (not an alias) is placed in the CURRENT SERVER special register. • Information about the application server is placed in the SQLERRP field of the SQLCA. If the application server is an IBM® product, the information has the form pppvvrrm, It's not obvious to me that a DB2 application process is a TCB. Sure, maybe it is, but then you'd think they'd call it that, or perhaps a task. An application process sounds more to me like an abstraction for DB2's purposes of some kind of run unit - process, thread, task, address space. Think about CICS; surely it runs multiple users, each with quite different DB2 contexts, under a single TCB? It must have some way of maintaining an application process for each user. What about Language Environment enclaves? This sounds like something similar; by default an MVS TCB is its own enclave, but it can certainly support more than one by using the LE anchor block support. But I really know almost nothing about DB2, and it's been decades since I last used its closest relative, SQL/DS, so I may be quite full of it. Tony H. -- 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: How to quietly terminate not detached subtask
On Fri, 17 Oct 2014 12:37:17 -0500, Victor Gil victor@broadridge.com wrote: Thanks! This would be a totally different ball game as it brings an extra layer of communication between the address spaces. This would also require extra authorization which wouldn't fly well with the management Yes, it requires extra communication. But it solves your problem in a clean way :) I'm not sure in what sense you mean extra authorization. It does not require any form of system authorization (APF, supervisor state, system key), though it might require that the user ID that the main address space is running under has an OMVS identity (UNIX UID and GID) defined. But the ID may already be set up that way. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How to quietly terminate not detached subtask
Hi everyone, Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I have no problems attaching a subtask on a first call and connecting from it to a remote subsystem, but I cannot force the caller [because this would mean massive change to the existing source code] to also call me with the end-of-job request, so that I can properly detach the subtask. And if it is not detached the main task will surely get abended. [By the way - can't this get trapped by an ESTAE(X) and converted into RC=0?] Given the above scenario - does anyone have a suggestion on how to quietly terminate both tasks without the detach? Or maybe a suggestion on ANOTHER way of implementing the required functionality? Many thanks in advance! -Victor Gil- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
Is the 1st task, the one with the existing DB2 connection, your task? Do you have control of it, or is your code running on a tcb that is not your code? On 10/16/2014 1:00 PM, Victor Gil wrote: Hi everyone, Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I have no problems attaching a subtask on a first call and connecting from it to a remote subsystem, but I cannot force the caller [because this would mean massive change to the existing source code] to also call me with the end-of-job request, so that I can properly detach the subtask. And if it is not detached the main task will surely get abended. [By the way - can't this get trapped by an ESTAE(X) and converted into RC=0?] Given the above scenario - does anyone have a suggestion on how to quietly terminate both tasks without the detach? Or maybe a suggestion on ANOTHER way of implementing the required functionality? Many thanks in advance! -Victor Gil- -- 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: How to quietly terminate not detached subtask
The 1st task is NOT my code, but it would CALL my service which would attach a subtask. This one will be totally under my control === Is the 1st task, the one with the existing DB2 connection, your task? Do you have control of it, or is your code running on a tcb that is not your code? On 10/16/2014 1:00 PM, Victor Gil wrote: Hi everyone, Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I have no problems attaching a subtask on a first call and connecting from it to a remote subsystem, but I cannot force the caller [because this would mean massive change to the existing source code] to also call me with the end-of-job request, so that I can properly detach the subtask. And if it is not detached the main task will surely get abended. [By the way - can't this get trapped by an ESTAE(X) and converted into RC=0?] Given the above scenario - does anyone have a suggestion on how to quietly terminate both tasks without the detach? Or maybe a suggestion on ANOTHER way of implementing the required functionality? Many thanks in advance! -Victor Gil- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
Hi Victor - Look at the EXTR parameter in the ATTACH(X) documentation. This end-of-task exist gets control on normal and abnormal end-of-task. You can issue the DETACH macro from within this exit. Sam On Thu, Oct 16, 2014 at 11:00 AM, Victor Gil victor@broadridge.com wrote: Hi everyone, Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I have no problems attaching a subtask on a first call and connecting from it to a remote subsystem, but I cannot force the caller [because this would mean massive change to the existing source code] to also call me with the end-of-job request, so that I can properly detach the subtask. And if it is not detached the main task will surely get abended. [By the way - can't this get trapped by an ESTAE(X) and converted into RC=0?] Given the above scenario - does anyone have a suggestion on how to quietly terminate both tasks without the detach? Or maybe a suggestion on ANOTHER way of implementing the required functionality? Many thanks in advance! -Victor Gil- -- 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: How to quietly terminate not detached subtask
Thanks, but the EXTR handles termination of the SUBTASK being attached, not the MAIN task Hi Victor - Look at the EXTR parameter in the ATTACH(X) documentation. This end-of-task exist gets control on normal and abnormal end-of-task. You can issue the DETACH macro from within this exit. Sam On Thu, Oct 16, 2014 at 11:00 AM, Victor Gil victor@broadridge.com wrote: Hi everyone, Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I have no problems attaching a subtask on a first call and connecting from it to a remote subsystem, but I cannot force the caller [because this would mean massive change to the existing source code] to also call me with the end-of-job request, so that I can properly detach the subtask. And if it is not detached the main task will surely get abended. [By the way - can't this get trapped by an ESTAE(X) and converted into RC=0?] Given the above scenario - does anyone have a suggestion on how to quietly terminate both tasks without the detach? Or maybe a suggestion on ANOTHER way of implementing the required functionality? Many thanks in advance! -Victor Gil- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
So, the scenario is that your code gets control running under task A, and will attach task B. You want to get control when task A is terminating normally, so you can detach task B. I don;t know if an estae routine on task A would allow you to detach task B from the estae. Probably would, But if task A is already in termination for trying to exit without detaching, then you probably can't retry out of the estae, the only thing you could do is percolate, so what's the point. You would have to try it, and see what happens. If task A is not the jobstep tcb, you could consider scheduling an IRB onto the jobstep tcb to attach the sub-task. Then, set a resource termination manager for task A. That code could detach the sub-task when task A terminated, and before the jobstep task terminated. --Dave On 10/16/2014 1:07 PM, Victor Gil wrote: The 1st task is NOT my code, but it would CALL my service which would attach a subtask. This one will be totally under my control === Is the 1st task, the one with the existing DB2 connection, your task? Do you have control of it, or is your code running on a tcb that is not your code? On 10/16/2014 1:00 PM, Victor Gil wrote: Hi everyone, Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I have no problems attaching a subtask on a first call and connecting from it to a remote subsystem, but I cannot force the caller [because this would mean massive change to the existing source code] to also call me with the end-of-job request, so that I can properly detach the subtask. And if it is not detached the main task will surely get abended. [By the way - can't this get trapped by an ESTAE(X) and converted into RC=0?] Given the above scenario - does anyone have a suggestion on how to quietly terminate both tasks without the detach? Or maybe a suggestion on ANOTHER way of implementing the required functionality? Many thanks in advance! -Victor Gil- -- 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: How to quietly terminate not detached subtask
When you attach the subtask, specify ESTAI=whatever. When you force DETACH the subtask, the ESTAI will get control. One thing about ESTAIs (that's not true for ESTAEs) is that they can return to RTM with RC=16 (via SETRP of course). This means don't percolate the abend any further. Just go quietly into the night. Do not rage rage against the dying of the light. IHTH, Dave Cole At 10/16/2014 02:00 PM, Victor Gil wrote: Hi everyone, Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. I have no problems attaching a subtask on a first call and connecting from it to a remote subsystem, but I cannot force the caller [because this would mean massive change to the existing source code] to also call me with the end-of-job request, so that I can properly detach the subtask. And if it is not detached the main task will surely get abended. [By the way - can't this get trapped by an ESTAE(X) and converted into RC=0?] Given the above scenario - does anyone have a suggestion on how to quietly terminate both tasks without the detach? Or maybe a suggestion on ANOTHER way of implementing the required functionality? Many thanks in advance! -Victor Gil- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Dave Cole ColeSoft Marketing 414 Third Street, NE Charlottesville, VA 22902 EADDRESS: mailto:dbc...@colesoft.comdbc...@colesoft.com Home page: www.colesoft.com Facebook: www.facebook.com/colesoftware YouTube:www.youtube.com/user/colesoftware -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
In the OP's case, he does not get control in order to issue the DETACH - the DETACH is issued by the system when the JS ends. Also, the DB2 messages are not issued by an ESTAE - it is by the DB2 RTM. It would be quite tricky to get DB2 to skip the RTM routine. It appears that there are two issues - (1) to prevent the JS from the X03 abend (2) to avoid the messages from the subtask There is the requirement that the JS black box not be altered One option would be to replace the JS in the JCL to attach a new task that attaches the original JS task and ends when it does. Then the service subroutine can run in the new JS task and will clean up when the original JS ends. Even a LINK may be adequate. On Thu, 16 Oct 2014 14:40:52 -0400 David Cole dbc...@colesoft.com wrote: :When you attach the subtask, specify ESTAI=whatever. : :When you force DETACH the subtask, the ESTAI will get control. One :thing about ESTAIs (that's not true for ESTAEs) is that they can :return to RTM with RC=16 (via SETRP of course). This means don't :percolate the abend any further. Just go quietly into the night. Do :not rage rage against the dying of the light. : :IHTH, :Dave Cole : : : : : : :At 10/16/2014 02:00 PM, Victor Gil wrote: : :Hi everyone, : :Working on a general purpose callable subroutine to connect to a :remote DB2 subsystem and return values back to the caller. : :Since the caller may [and WILL] have established its own DB2 :connection to a local DB2 subsystem, possibly with some cursors open :and DB2 locks acquired, the subroutine must run under a different TCB. : :I have no problems attaching a subtask on a first call and :connecting from it to a remote subsystem, but I cannot force the :caller [because this would mean massive change to the existing :source code] to also call me with the end-of-job request, so that :I can properly detach the subtask. : :And if it is not detached the main task will surely get abended. [By :the way - can't this get trapped by an ESTAE(X) and converted into RC=0?] : :Given the above scenario - does anyone have a suggestion on how to :quietly terminate both tasks without the detach? Or maybe a :suggestion on ANOTHER way of implementing the required functionality? : :Many thanks in advance! :-Victor Gil- : :-- :For IBM-MAIN subscribe / signoff / archive access instructions, :send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN : :Dave Cole :ColeSoft Marketing :414 Third Street, NE :Charlottesville, VA 22902 :EADDRESS: mailto:dbc...@colesoft.comdbc...@colesoft.com : :Home page: www.colesoft.com :Facebook: www.facebook.com/colesoftware :YouTube:www.youtube.com/user/colesoftware : :-- :For IBM-MAIN subscribe / signoff / archive access instructions, :send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to quietly terminate not detached subtask
On Thu, 16 Oct 2014 13:00:12 -0500, Victor Gil victor@broadridge.com wrote: Working on a general purpose callable subroutine to connect to a remote DB2 subsystem and return values back to the caller. Since the caller may [and WILL] have established its own DB2 connection to a local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, the subroutine must run under a different TCB. You might consider going a bit further, and using fork() and execmvs() to create a new address space running your new code. That will isolate it quite well from the original task. And since you will not get control to signal it to terminate, it might do so after some period of time without hearing from you, say 5 minutes or whatever value you consider reasonable. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
