Overview: How threads work
Each CICS transaction needs its own thread to access DB2.
Threads are created when they are needed by transactions, at the point when the application issues its first SQL or command request. The transaction uses the thread to access resources managed by DB2. When a thread is no longer needed by the transaction, because the transaction has accessed all the resources it needs to use, the thread is released (typically after syncpoint completion). It takes processor resources to create a thread, so when a thread is released, the CICS DB2 attachment facility checks to see if another transaction needs a thread. If another transaction is waiting for a thread, the CICS DB2 attachment facility reuses the existing thread for that transaction to access DB2. If the thread is no longer needed by any transaction, it is terminated, unless you have requested that it should be protected (kept) for a period of time. A protected thread is reused if another transaction requests it within that period of time; if not, it is terminated when the protection time expires.
There are different types of thread, and you can set a limit on the number of each type of thread that can be active at any one time. This prevents the overall CICS DB2 connection from becoming overloaded with work. A special type of thread is used for DB2 commands issued using the DSNC transaction, and you can also define special threads for CICS transactions with particular requirements, such as transactions that require a fast response time. You can define what a transaction must do if no more threads of the type it needs are available — it can wait until a thread of the right type is available; it can use a general-purpose thread, called a pool thread; or it can abend.
- Command threads
- Command threads are reserved by the CICS DB2 attachment facility for issuing commands to DB2 using the DSNC transaction. They are not used for commands acting on the CICS DB2 attachment facility itself, because these commands are not passed to DB2. When a command thread is not available, commands automatically overflow to the pool, and use a pool thread. Command threads are defined in the command threads section of the DB2CONN definition.
- Entry threads
- Entry threads are
specially defined threads intended for transactions with special requirements,
such as transactions that require a fast response time, or transactions
with special accounting needs. You can instruct the CICS DB2 attachment
facility to give entry threads to particular CICS transactions. You
define the different types of entry threads that are needed for different
transactions, and you can set a limit on the number of each of these
types of entry thread. If a transaction is permitted to use an entry
thread, but no suitable entry thread is available, the transaction
can overflow to the pool and use a pool thread, or wait for a suitable
entry thread, or abend, as you have chosen in the definition for the
entry thread.
A certain number of each type of entry thread can be protected. When an entry thread is released, if it is protected it is not terminated immediately. It is kept for a period of time, and if another CICS transaction needs the same type of entry thread during that period, it is reused. This avoids the overhead involved in creating and terminating the thread for each transaction. An entry thread that is unprotected is terminated immediately, unless a CICS transaction is waiting to use it the moment it is released.
Entry threads are defined using a DB2ENTRY definition.
- Pool threads
- Pool threads are used for all transactions and commands that are not using an entry thread or a DB2 command thread. Pool threads are intended for low volume transactions, and for overflow transactions that could not obtain an entry thread or a DB2 command thread. A pool thread is terminated immediately if no CICS transaction is waiting to use it. Pool threads are defined in the pool threads section of the DB2CONN definition.
For more detailed information on how the different types of thread are created, used and terminated, see How threads are created, used, and terminated.
Each thread runs under a thread task control block (thread TCB) that belongs to CICS. CICS and DB2 both have connection control blocks linked to the thread TCB. They use these connection control blocks to manage the thread into DB2, and to communicate information to each other about the thread. The DB2 connection control block controls the thread within DB2. The CICS connection control block, called the CSUB, acts as a pointer to the DB2 connection control block, and contains the information CICS requires to call the DB2 connection control block when the thread is needed. DB2 calls these connection control blocks “agent structures”.
While CICS is connecting to a DB2 subsystem, the CICS DB2 task-related user exit (the module that invokes DB2 for each task) is automatically enabled as open API, so it can use the open transaction environment (OTE).
Both types of TCB that the CICS DB2 attachment facility uses to run the threads, the open TCBs and the subtask TCBs, are referred to in this documentation as “thread TCBs”. In many situations, the different nature of the two types of thread TCB does not lead to any differences in the operation of the CICS DB2 connection. Where the different types of thread TCB do cause the CICS DB2 connection to behave differently, a distinction is made between the two types. For more technical information on thread TCBs, see Thread TCBs (task control blocks).