Thread operation attributes

Describes the attributes of the DB2ENTRY resource that relate to thread operations.

ACCOUNTREC({NONE|TASK|TXID|UOW})
Specifies the minimum amount of Db2® accounting required for transactions using this Db2 entry. The specified minimum might be exceeded, as described in the following options.
NONE
No accounting records are required for transactions using threads from this DB2ENTRY

However, Db2 produces at least one accounting record for each thread after the thread is terminated. Authorization changes additionally cause records to be produced.

TASK
The CICS® Db2 attachment facility causes a minimum of one accounting record for each CICS task to be produced.

A transaction that contains multiple units of work (UOWs), and in which the threads are released at sync point, can use a different thread for each of its UOWs. As a result, an accounting record might be produced for each UOW.

TXID
The CICS Db2 attachment facility causes an accounting record to be produced when the transid using the thread changes.

This option applies to Db2 entry definitions that are used by more than one transaction ID. As threads are typically released at syncpoint, a transaction containing multiple UOWs might use a different thread for each UOW. As a result, an accounting record might be produced for each UOW.

UOW
The CICS Db2 attachment facility causes an accounting to be produced for each UOW, assuming that the thread is released at the end of the UOW.
AUTHID(userid)
Specifies the user ID that is used for security checking when using this DB2ENTRY.

Do not specify AUTHID if you are using RACF® for some or all of the security checking in your Db2 address space; use AUTHTYPE instead, with the GROUP, SIGN, or USERID options. You must use AUTHTYPE because threads using an AUTHID do not pass the required RACF access control environment element (ACEE) to Db2.

The ID that you specify can be up to 8 characters in length.
Acceptable characters:
A-Z 0-9 $ @ #
Unless you are using the CREATE command, any lowercase characters that you enter are converted to uppercase.
AUTHTYPE({USERID|OPID|GROUP|SIGN|TERM|TX})
Specifies the type of ID that can be used for security checking when using this DB2ENTRY.

If you are using RACF for some or all of the security checking in your Db2 address space, use the GROUP, SIGN, or USERID options. You must use one of these options because only threads defined with these options pass the required RACF access control environment element (ACEE) to Db2. However, if you specify the SIGN option, the ACEE is passed to Db2 only if the value specified for the SIGNID attribute on the DB2CONN definition matches the CICS region user ID.

The ACEE is not required if you are using Db2 internal security only; so in this case, you can use any of the options.

USERID
The USERID associated with the CICS transaction is used as the authorization ID. If the user ID is less than 8 characters in length, it is padded on the right with blanks.

When the Db2 sample sign-on exit DSN3@SGN is used with AUTHTYPE(USERID), the exit sends the user ID to Db2 as the primary authorization ID and the connected group name to Db2 as the secondary ID. When the sample sign-on exit is used, AUTHTYPE(USERID) and AUTHTYPE(GROUP) are the same.

OPID
The operator identification that is associated with the userid that is associated with the CICS transaction sign-on facility is used as the authorization ID. The 3-character operator identification is padded on the right with blanks to form the 8-character authorization ID.
GROUP
Specifies the 1- to 8-character USERID and the connected group name as the authorization ID. The following table shows how these two values are interpreted by Db2.
IDs passed to Db2 How Db2 interprets values
CICS sign-on user ID (USERID) Represents the primary Db2 authorization ID.
RACF connected group name If the RACF list of group options is not active, Db2 uses the connected group name supplied by the CICS attachment facility as the secondary Db2 authorization ID. If the RACF list of group options is active, Db2 ignores the connected group name supplied by the CICS attachment facility, but the value appears in the Db2 list of secondary Db2 authorization IDs.

To use the GROUP option, you must specify SEC=YES in the system initialization parameters for the region.

If no RACF group ID is available for this USERID, an 8-character field of blanks is passed to Db2 as the group ID.

SIGN
Specifies that the SIGNID attribute of the DB2CONN is used as the resource authorization ID.
TERM
Specifies the terminal identification (4 characters padded to 8) as an authorization ID. An authorization ID cannot be obtained in this manner if a terminal is not connected with the transaction.

If a transaction is started, using a CICS command, and has no terminal associated with it do not use AUTHTYPE(TERM).

TX
Specifies the transaction identification as the authorization ID. The 4-character transaction identification is padded on the right with blanks to form the 8-character authorization ID.
DROLLBACK({YES|NO})
Specifies whether the CICS Db2 attachment facility initiates a SYNCPOINT ROLLBACK in the event of a transaction being selected as victim of a deadlock resolution.
YES
The attachment facility initiates a SYNCPOINT ROLLBACK before returning control to the application. Additionally the attachment facility changes the SQL return code returned by Db2 from -913 to -911, and returns -911 to the application.

Do not specify YES if the DB2ENTRY is used by transactions running enterprise beans as part of an OTS transaction; SYNCPOINT ROLLBACK is not allowed in an OTS transaction.

Similarly, do not specify YES if the DB2ENTRY is used by transactions running as a DPL server without SYNCONRETURN; SYNCPOINT ROLLBACK is invalid in this scenario and would result in an AD2Z abend.

NO
The attachment facility does not to initiate rollback for this transaction. An SQL return code of -913 is returned to the application.
PLAN(plan)
Specifies the name of the plan to be used for this entry.
PLANEXITNAME(DSNCUEXT|DFHD2PXT|exit)
Specifies the name of the dynamic plan exit to be used for this Db2 entry definition. If you change PLAN and PLANEXITNAME while there are active transactions for the Db2 entry definition, the next time the transaction releases the thread, the new values are applied. DFHD2PXT is the sample threadsafe dynamic plan exit and DSNCUEXT is the sample quasi-reentrant dynamic plan exit. For more information, see The sample exit programs, DSNCUEXT and DFHD2PXT.
PRIORITY({HIGH|EQUAL|LOW})
Specifies the priority of the thread TCBs for this DB2ENTRY relative to the CICS main TCB (QR TCB).If CICS is connected to DB2® Version 6 or later, the thread TCBs are CICS open L8 TCBs.
HIGH
Thread TCBs have a higher priority than the CICS QR TCB.
EQUAL
Thread TCBs have equal priority with the CICS QR TCB.
LOW
Thread TCBs have a lesser priority than the CICS QR TCB.
PROTECTNUM({0|value})
Specifies the maximum number of protected threads allowed for this Db2 entry definition. A thread that is released by a transaction when no other work is queued can be protected, meaning that it is does not end immediately. A protected thread ends after two complete purge cycles if it has not been reused in the meantime. For example, if the purge cycle is set to 30 seconds, a protected thread ends 30 - 60 seconds after it is released if it is not reused in the meantime. The first purge cycle after the CICS Db2 attachment facility has been started is 5 minutes, after which the PURGECYCLE value is applied. Threads are protected only while they are inactive. If a transaction reuses a protected thread, the thread becomes active, and the current number of protected threads is decremented.
THREADLIMIT({0|value})
Specifies the maximum number of threads for this Db2 entry definition that the CICS Db2 attachment allows active before requests are made to wait, are abended, or diverted to the pool.
THREADWAIT({POOL|YES|NO})
Specifies whether transactions wait for a DB2ENTRY thread, end abnormally, or overflow to the pool if the number of active DB2ENTRY threads reaches the THREADLIMIT number.
POOL
If all threads are busy, the transaction is diverted to use the pool of threads. If the pool is also busy, and you specified THREADWAIT(NO) on the Db2 connection definition, the transaction ends abnormally with abend code AD3T.
NO
If all threads are busy, the transaction ends abnormally with abend AD2P.
YES
If all threads are busy, the transaction waits until a thread becomes available.