Overview: How threads work

Within the overall connection between CICS® and DB2®, each CICS transaction that accesses DB2 needs a thread, an individual connection into 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.

The types of thread provided by the CICS DB2 attachment facility are:

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".

The nature of the thread TCBs, and the way in which they are linked to the DB2 connection control block (and therefore to the thread), differs depending on the version of DB2 to which CICS is connected.

While CICS is connecting to a DB2 subsystem, it checks the DB2 release level of the subsystem. If CICS is connecting to DB2 Version 6 or later, 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). If CICS is connecting to DB2 Version 5 or earlier, the task-related user exit is not enabled as open API, and does not use the open transaction environment.

Thread TCBs in a non-open transaction environment

When CICS is connected to DB2 Version 5 or earlier, and so is not using the open transaction environment, the thread TCBs are subtasks created by the CICS DB2 attachment facility to run each thread that is requested by transactions or DB2 commands. The CICS DB2 task-related user exit itself remains on the CICS main TCB, the QR TCB.

Once created, the subtask thread TCBs are permanently associated with a particular CSUB and DB2 connection control block. When the process for which a subtask thread TCB was created is complete, the subtask thread TCB, CSUB, DB2 connection control block and thread are released, and the whole assembly can be reused by another CICS transaction to access DB2 resources. So to reuse an existing thread, the CICS DB2 attachment facility must also reuse the subtask thread TCB associated with it.

If the thread is terminated before it is reused, the subtask thread TCB and its associated CSUB and DB2 connection control block remain available in the system. Like the threads themselves, it takes processor resource to create these, so the CICS DB2 attachment facility reuses them. If a thread is requested and no existing threads are available, the CICS DB2 attachment facility looks for an unused subtask thread TCB, CSUB and DB2 connection control block, and reuses them to run a new thread into DB2.

Figure 2 summarizes how thread TCBs operate in a non-open transaction environment.

Figure 2. Thread TCBs in a non-open transaction environment
 The content of this figure is explained by the text that follows it.

In Figure 2, situation  1  shows CICS using a thread to access DB2. On the CICS main TCB, the language interface that is link-edited with the application program calls the Resource Manager Interface (RMI), which invokes the CICS DB2 attachment facility's task-related user exit. The CICS DB2 task-related user exit, operating on the CICS main TCB, uses an assembly consisting of a subtask TCB, a CSUB, and a DB2 connection control block to run a thread into DB2. The plan associated with the thread is held in DB2.

Situation  2  shows a thread that is not currently in use, but is protected. The subtask TCB, CSUB and DB2 connection control block are still assembled together, and the thread runs into DB2. The thread is available for reuse.

Situation  3  shows an assembly that is left after a thread was terminated. The assembly, consisting of the subtask TCB, CSUB and DB2 connection control block, is available for reuse. It needs a new thread.

Thread TCBs in the open transaction environment

When CICS is connected to DB2 Version 6 or later, it is using the open transaction environment. (This situation therefore applies to users with DB2 Version 7 or later and JDBC 2.0.) In this environment, the CICS DB2 attachment facility uses open TCBs (L8 mode) as the thread TCBs, rather than using specially created subtask TCBs. Open TCBs perform other tasks besides accessing DB2 resources. In the open transaction environment, the CICS DB2 task-related user exit runs on an open TCB rather than on the CICS main TCB. If the application program that made the DB2 request is threadsafe, it can also run on the open TCB. (See Enabling CICS DB2 applications to exploit the open transaction environment (OTE) through threadsafe programming for more information on application programs in the open transaction environment.)

Open TCBs are not permanently associated with a CSUB and DB2 connection control block. The CICS DB2 attachment facility can associate them with any CSUB and DB2 connection control block that are available, and therefore with any thread that is available. When the open TCB no longer needs the connection to DB2, it dissociates from, or releases, the thread, CSUB and DB2 connection control block. The thread, CSUB and DB2 connection control block can then be used by a different open TCB for the tasks it wishes to perform in DB2.

If the thread is terminated before it is reused, the CSUB and DB2 connection control block remain available in the system. If no existing threads are available, and an open TCB needs a connection to DB2, the CICS DB2 attachment facility can associate the unused CSUB and DB2 connection control block with the open TCB, and reuse them to run a new thread into DB2.

Figure 3 summarizes how thread TCBs operate in the open transaction environment.

Figure 3. Thread TCBs in the open transaction environment
 The content of this figure is explained by the text that follows it.

In Figure 3, situation  1  shows CICS using a thread to access DB2 in the open transaction environment. The CICS DB2 task-related user exit has been invoked by the Resource Manager Interface (RMI), and it is operating on an open TCB. The CICS DB2 attachment facility has associated a CSUB and a DB2 connection control block with the open TCB. The DB2 connection control block has a thread into DB2. The plan associated with the thread is held in DB2.

Situation  2  shows a thread that is not currently in use, but is protected. The CSUB and DB2 connection control block are still linked to each other and have a thread, but no open TCB is attached to them. The thread is available for reuse.

Situation  3  shows an assembly that is left after a thread was terminated. The CSUB and DB2 connection control block are available for reuse. They need a new thread.

Situation  4  shows open TCBs that are available for reuse. The CICS DB2 attachment facility can use these open TCBs and associate CSUB and DB2 connection control block assemblies with them to run threads into DB2.

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).

Related concepts
Overview of the CICS DB2 interface
Overview: How CICS connects to DB2
Overview: How you can define the CICS DB2 connection
Overview: Enabling CICS application programs to access DB2
[[ Contents Previous Page | Next Page Index ]]