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 <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
