Good morning everyone,
I have a question, I notice that we do not have 'protected threads' active in CICS for connecting to DB2;
Protected entry threads
Protected entry threads are defined with the following DB2ENTRY parameters: PROTECTNUM and THREADLIMITProtected 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 attachWhen 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 creationA 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 terminationIf 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 reuseOther 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 poolIf 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.
This, I understand, has advantages on performace and since the conn is left open in a cics buffer
I found the following link, a bit dated, with some considerations, what do you think?
While in the following they deactivate the protected threads for the post-tp phase to avoid problems during lock commands for loads.
I honestly find both pros such as cpu savings and cons for storage stress cases.
Kindly share your experiences with me?
4569 Technology DriveSte 1 Wilmington, NC 28405Phone: (910) 660-8649Fax: (910) 523-5504