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 the CICS DB2 attachment facility is started no subtask
thread TCBs are started. They are started as needed when work arrives.
- Before an SQL request can be passed to DB2, a subtask thread TCB
and a thread must be available for the transaction.
- Once attached, a subtask thread TCB is normally available until
the CICS DB2 attachment facility is stopped.
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:
- 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.
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:
- 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 usually releases the thread at
syncpoint and end-of-task. The thread is not released
at syncpoint 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 specifying the same plan and defined in the
same DB2ENTRY. Pool threads can be reused by any waiting (queued)
transaction 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 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.
- The THREADWAIT parameter defines whether the requests for a thread
should be queued, abended, or overflowed to the pool in case of entry
thread shortage.
These threads are defined with the following DB2ENTRY parameters:
PROTECTNUM(n)
THREADLIMIT(n)
Protected entry threads are recommended for:
- High-volume transactions of any type
- Terminal-oriented transactions with many commits
- Non-terminal-oriented transactions with many commits (if NONTERMREL=YES
is specified in the DB2CONN)
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
If 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.
These threads are defined with the following DB2ENTRY parameters:
PROTECTNUM(0)
THREADLIMIT(n)
This is the recommended type of definition
for:
- Critical transactions requiring a fast response time, but with
a volume so low that a protected thread cannot be used
- Limited concurrency transactions
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
If 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.
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.
These threads are defined with the following DB2CONN parameter:
THREADLIMIT(n)
There are four cases when a pool
thread can be used:
- 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.
- 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.
- 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.
- 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.
[[ Contents Previous Page | Next Page Index ]]