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:[email protected]] On Behalf Of Tony Harminc Sent: Friday, October 17, 2014 10:52 AM To: [email protected] Subject: Re: How to quietly terminate not detached subtask On 16 October 2014 14:00, Victor Gil <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
