Protected entry threads

Protected entry threads are defined with the following DB2ENTRY parameters: PROTECTNUM(n) and 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, and is using the open transaction environment, a new or existing open TCB is allocated to the CICS task before calling the CICS DB2 attachment facility. If the limit set automatically by CICS for the number of L8 and L9 mode open TCBs 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. 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.