How threads are created, used, and terminated

Three main types of threads are used by the CICS® DB2® attachment facility: command threads, entry threads, and pool threads. There are specific rules that apply to thread creation, use, and termination.

When CICS is connected to DB2, the thread TCB is the open TCB on which the CICS DB2 attachment facility is already running. When it needs to run a thread, the CICS DB2 attachment facility associates the open TCB with the DB2 connection control block and thread it wants to use, and the open TCB then runs the thread. When the thread is no longer needed, the open TCB dissociates from it, and the DB2 connection control block and thread become available for reuse by another open TCB.

The following general rules apply to thread creation, use, and termination:

When CICS is connected to DB2 and is using open TCBs as the thread TCBs, before an SQL request can be passed to DB2 a thread must be available for the transaction. The open TCB associates itself with the thread, and becomes the thread TCB until it dissociates from the thread.
When a thread is created and another transaction with a new authorization ID is reusing a thread, DB2 makes an authorization check for the new authorization ID.
A terminal-oriented transaction typically releases the thread at sync point and end-of-task. The thread is not released at sync point if held cursors are open or any modifiable special registers are not in their initial state.
A non-terminal-oriented transaction releases the thread at end-of-task only, unless NONTERMREL=YES is specified in the DB2CONN.
When a transaction releases a thread, the thread can be reused by another transaction that is specifying the same plan and that is defined in the same DB2ENTRY. Pool threads can be reused by any waiting (queued) transaction that is specifying the same plan and using a pool thread.
An unprotected thread is terminated immediately it is released, unless another transaction is waiting (queued) for the thread.
A protected thread is terminated if it is not used during two consecutive purge cycles. With default settings, this averages about 45 seconds. This value can be modified by the PURGECYCLE parameter of the DB2CONN.
A thread is canceled and terminated if it is active in DB2 at the time the CICS task that is using the thread is purged or forcepurged.
The REUSELIMIT parameter of the DB2CONN specifies the maximum number of times a thread can be reused before it is terminated. The reuse limit applies to unprotected threads both in the pool and on a DB2ENTRY, and to protected DB2ENTRY threads.
The THREADWAIT parameter defines whether the requests for a thread should be queued, abended, or sent to the pool thread in the case of a shortage of entry or command threads. If THREADWAIT=YES is specified instead of THREADWAIT=POOL the transaction is queued rather than sent to the pool thread. Using THREADWAIT=YES avoids the thread initialization and termination overhead. If a transaction is made to wait because of the lack of entry threads, the CICS DB2 attachment facility queues the transaction. The advantages of this queuing are that, when the entry thread finishes its current piece of work, it continues with the next transaction immediately.
TCBLIMIT specifies the maximum number of TCBs that can be used to run DB2 threads, which, in turn, limits the maximum number of active DB2 threads. THREADLIMIT specifies the maximum number of active DB2 threads. THREADLIMIT is modified dynamically. CTHREAD is specified in ZPARMS, and it defines the number of concurrent threads for all of DB2. The sum of all the active threads from TSO users, all CICS and IMS systems and other systems accessing DB2 should not exceed CTHREAD. Otherwise, the result could be unpredictable response times. When this occurs, a CICS DB2 attachment facility create thread request is queued by DB2, and the CICS transaction is placed is a wait state until a thread is available.
CICS manages the total number of L8 and L9 mode TCBs that the CICS region has in operation at any one time. The maximum number of L8 and L9 mode TCBs in the open TCB pool is controlled by either the MXT or MAXOPENTCBS system initialization parameters. The MAXOPENTCBS system initialization parameter, if specified, sets the value for the open TCB pool. If the MAXOPENTCBS system initialization is not specified, CICS sets the limit for the L8 and L9 mode open TCB pool automatically based on the maximum number of tasks specified for the CICS region (the MXT value), using the formula (2 * MXT Value) + 32. In the open transaction environment, TCBLIMIT controls how many of these open TCBs can be used by the CICS DB2 task-related user exit to run threads into DB2. If the limit set by CICS is reached, no more open TCBs are allowed in the CICS region, and the CICS DB2 task-related user exit cannot obtain an open TCB for its use.

Each thread linking CICS to DB2 has a corresponding TCB in the CICS address space. Too many TCBs per address space involve the MVS™ dispatcher scanning the TCBs to identify an active TCB. If there are a large number of TCBs, there could be a significant cost of processor time. However, if you have too few TCBs available to meet your DB2 workload, transactions must wait to obtain a TCB.

Increasing the TCBLIMIT value or setting up an additional CICS system with access to the same DB2 system may require increasing the CTHREAD parameter of DB2.

For a protected entry thread environment, review the number of application plans and, if possible, reduce the number of plans by combining infrequently used ones while balancing the issues of plan size and security. Initially, you should start with one thread per plan. In a high-volume transaction processing environment, you can estimate the initial number by using the occupancy time of a thread by a transaction and multiplying it with the expected transaction rate. For example, an occupancy time of 0.2 seconds and a transaction rate of 20 transactions per second (0.2 x 20) would give an initial thread number of between three and four.