How threads are created, used, and terminated

There are three main types of threads that can be used by the CICS® DB2® attachment facility: command threads, entry threads, and pool threads. See Overview: How threads workfor an overview of how threads work, and an explanation of the different thread types. This section deals in more detail with the processes involved in creating, using, and terminating the different types of thread, and attaching thread TCBs, and the implications of these on specifying DB2CONN and DB2ENTRY parameters. Overflow to the pool is also discussed. The section looks closely at thread creation and termination for:

You define the relationship between CICS transactions and DB2 plans using DB2CONN for pool threads, and DB2ENTRY for entry threads. See Overview: How you can define the CICS DB2 connection for an overview of the attributes of DB2CONN and DB2ENTRY.

The CICS DB2 attachment facility uses different types of thread TCB to run threads, depending on whether CICS is connected to DB2 Version 5 or earlier, or to DB2 Version 6 or later. See Overview: How threads work for a full explanation.

When CICS is connected to DB2 Version 5 or earlier, the thread TCB is a subtask TCB created specially by the CICS DB2 attachment facility to run the thread. This subtask TCB remains permanently attached to the DB2 connection control block and thread. In this environment, to reuse the thread, the CICS DB2 attachment facility must reuse the subtask TCB attached to the thread.

When CICS is connected to DB2 Version 6 or later, 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 becomes available for reuse by another open TCB.

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

When CICS is connected to DB2 Version 5 or earlier, and is using specially created subtask TCBs as the thread TCBs, these rules apply to the thread TCBs:

When CICS is connected to DB2 Version 6 or later, and is using open TCBs as the thread TCBs, the rules above do not apply. In this environment, the following rule applies to the thread TCBs:

In both environments, when CICS is connected to DB2 Version 5 or earlier and when it is connected to DB2 Version 6 or later, the following rules apply to the threads:

Protected entry threads

These threads are defined with the following DB2ENTRY parameters:

 
           PROTECTNUM(n)
           THREADLIMIT(n)

Protected entry threads are recommended for:

Protected entry threads are created, used, and terminated as follows:

TCB attach
When CICS is connected to DB2 Version 5 or earlier, the CICS DB2 attachment facility attaches a subtask thread TCB when required. The subtask thread TCB normally remains available for reuse until the CICS DB2 attachment facility is stopped.

When CICS is connected to DB2 Version 6 or later, and is using the open transaction environment, a new or existing open TCB is allocated to the CICS task prior to calling the CICS DB2 attachment facility. If MAXOPENTCBS is reached, no more open TCBs can be created, and the task enters a CICS dispatcher wait until an open TCB is available. At the end of the task, the open TCB is returned to the pool of open TCBs managed by the CICS dispatcher.

Thread creation
A thread is created only if an existing thread is not available.

When CICS is connected to DB2 Version 5 or earlier, if no thread is available, but an unused subtask thread TCB exists for this DB2ENTRY, a new thread is created and related to the TCB, provided THREADLIMIT is not exceeded. If no thread is available and no unused TCB is available, a new TCB is created, and a new thread is built, provided the TCBLIMIT and THREADLIMIT are not exceeded.

When CICS is connected to DB2 Version 6 or later (and so is using the open transaction environment), if no thread is available for a task, a new thread is created and related to the task's open TCB, provided THREADLIMIT is not exceeded. If TCBLIMIT is reached, no more open TCBs can be used as thread TCBs for the DB2ENTRY.

Thread termination
If the current number of protected threads is less than the PROTECTNUM value when the thread is released and there is no new work queued, the thread is marked as protected. Otherwise it is terminated. A protected thread is terminated if it is unused for two consecutive purge cycles.
Thread reuse
Other transactions using the same DB2ENTRY may reuse a thread, if it is available. This is likely because the threads remain active for about 45 seconds after being released, depending on the PURGECYCLE value.
Overflow to pool
Start of changeIf THREADWAIT=POOL is specified, requests for threads are transferred to the pool when the value of THREADLIMIT is exceeded. When a transaction overflows to the pool, the transaction is now controlled by the PRIORITY, THREADLIMIT, and THREADWAIT attributes that are specified for pool threads in the DB2CONN definition, and those attributes in the DB2ENTRY definition are ignored. The remaining attributes that are specified in the DB2ENTRY definition for the entry thread still apply to the transaction, that is, ACCOUNTREC, AUTHID or AUTHTYPE, DROLLBACK, and PLAN or PLANEXITNAME. The PROTECTNUM attribute in the DB2ENTRY definition is no longer relevant for a transaction that overflows to the pool, so this setting is ignored.End of change

Unprotected entry threads for critical transactions

These threads are defined with the following DB2ENTRY parameters:

 
            PROTECTNUM(0)
            THREADLIMIT(n)

This is the recommended type of definition for:

You could use a protected thread for limited concurrency transactions, if the transaction rate makes it possible to reuse the thread.

Unprotected entry threads for critical transactions are created, used, and terminated as follows:

TCB attach
No thread TCBs are attached when the CICS DB2 attachment facility is started.

A TCB is attached only if needed by a thread. When CICS is connected to DB2 Version 5 or earlier, the subtask thread TCB normally remains available for reuse until the CICS DB2 attachment facility is stopped.

Thread creation
A thread is created only when needed by a transaction.

When CICS is connected to DB2 Version 5 or earlier, if no thread is available, but an unused subtask thread TCB exists for this DB2ENTRY, a new thread is created and related to the TCB, provided THREADLIMIT is not exceeded. If no thread is available and no unused TCB is available, a new TCB is created, and a new thread is built, provided the TCBLIMIT and THREADLIMIT are not exceeded.

When CICS is connected to DB2 Version 6 or later (and so is using the open transaction environment), if no thread is available, but an open TCB can be used as a thread TCB for this DB2ENTRY, a new thread is created and related to the TCB, provided THREADLIMIT is not exceeded. If TCBLIMIT is reached, no more open TCBs can be used as thread TCBs for the DB2ENTRY.

Thread termination
The thread is terminated immediately after it is released, unless it has a transaction queued for it.
Thread reuse
Other transactions specified to use the same DB2ENTRY can reuse a thread, if it is available. This happens only if a transaction is waiting for the thread when the thread becomes available.
Overflow to pool
Start of changeIf THREADWAIT=POOL is specified, requests for threads are transferred to the pool when the value of THREADLIMIT is exceeded. When a transaction overflows to the pool, the transaction is now controlled by the PRIORITY, THREADLIMIT, and THREADWAIT attributes that are specified for pool threads in the DB2CONN definition, and those attributes in the DB2ENTRY definition are ignored. The remaining attributes that are specified in the DB2ENTRY definition for the entry thread still apply to the transaction, that is, ACCOUNTREC, AUTHID or AUTHTYPE, DROLLBACK, and PLAN or PLANEXITNAME. The PROTECTNUM attribute in the DB2ENTRY definition is no longer relevant for a transaction that overflows to the pool, so this setting is ignored.

Note that you should not allow overflow to the pool for limited concurrency transactions.

End of change

Unprotected entry threads for background transactions

These threads are defined with the following DB2ENTRY parameters:

 
              PROTECTNUM(0)
              THREADLIMIT(0)
              THREADWAIT(POOL)

This is the recommended type of definition for transactions with low volume that do not require a fast response time. All transactions are forced to use pool threads.

Unprotected entry threads for background transactions are created, used, and terminated as follows:

TCB attach
No subtask thread TCB is ever attached for this thread definition because THREADLIMIT=0. A pool thread TCB (or, in the open transaction environment, an open TCB) is used. All activity related to this entry definition is forced to a thread and a TCB in the pool. A transaction is then under the control of the PRIORITY, THREADLIMIT, and THREADWAIT parameters for the pool. The transaction keeps the PLAN and the AUTHID/AUTHTYPE values you specified for the entry thread.
Thread creation
A thread is created in the pool when needed by a transaction unless the THREADLIMIT value for the pool was reached.
Thread termination
The thread is terminated when it is released, unless it has a transaction queued for it.
Thread reuse
Other transactions using the same plan can reuse the thread, when it becomes available.

Pool threads

These threads are defined with the following DB2CONN parameter:

 
                THREADLIMIT(n)

There are four cases when a pool thread can be used:

  1. A transaction is not specified in any DB2ENTRY or DB2TRAN, but issues SQL requests. This transaction defaults to the pool and uses the plan specified for the pool.
  2. A transaction is specified in a DB2ENTRY or DB2TRAN referencing a DB2ENTRY, but is forced to the pool because the DB2ENTRY specifies THREADLIMIT(0) and THREADWAIT(POOL). This transaction uses the plan specified in the DB2ENTRY.
  3. A transaction is specified in a DB2ENTRY or DB2TRAN referencing a DB2ENTRY, but overflows to the pool (THREADWAIT=POOL) when the THREADLIMIT value is exceeded. This transaction uses the plan specified in the DB2ENTRY.
  4. A transaction is specified in a DB2ENTRY or a DB2TRAN referencing a DB2ENTRY, but the DB2ENTRY is disabled. The DISABLEDACT keyword is set to POOL, therefore a pool thread is used. This transaction uses the plan specified for the pool.

Pool threads are always unprotected threads.

Pool threads are created, used, and terminated as follows:

TCB attach
No thread TCBs are attached when the CICS DB2 attachment facility is started.

A TCB is attached only if needed by a thread. When CICS is connected to DB2 Version 5 or earlier, the subtask thread TCB normally remains available for reuse until the CICS DB2 attachment facility is stopped.

Thread creation
A thread is created only when needed by a transaction.
Thread termination
The thread is terminated immediately after it is released, unless it has a transaction queued for it.
Thread reuse
Other transactions using the same plan can reuse a thread when it becomes available. In the pool this happens only if there is a queue for threads and the first transaction in the queue requests the same plan used by the thread being released.

Related concepts
Defining the CICS DB2 connection
Using the DB2 group attach facility
The MAXOPENTCBS system initialization parameter and TCBLIMIT
What happens during SQL processing
Selecting thread types for optimum performance
Selecting BIND options for optimum performanceCoordinating your DB2CONN, DB2ENTRY, and BIND options
[[ Contents Previous Page | Next Page Index ]]