Thread operation attributes

The thread operation attributes of a DB2ENTRY are:

ACCOUNTREC({NONE|TASK|TXID|UOW})
Specifies the minimum amount of DB2® accounting required for transactions using this DB2 entry. The specified minimum may 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 containing multiple UOWs (assuming the thread is released at syncpoint) may use a different thread for each UOW. The result may be that an accounting record is 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 may use a different thread for each UOW. The result may be that an accounting record is produced per 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 to be used for security checking when using this DB2ENTRY. If AUTHID is specified, AUTHTYPE may not be specified.

AUTHID is not suitable if you are using RACF® for some or all of the security checking in your DB2 address space; use AUTHTYPE instead, with the USERID or GROUP options. This is because threads using an AUTHID do not pass the required RACF access control environment element (ACEE) to DB2. The ACEE is not required if you are only using DB2 internal security, so in this case, you can use AUTHID.

The ID that you specify can be up to eight characters in length.
Acceptable characters:
A-Z 0-9 $ @ #
Unless you are using the CREATE command, any lowercase characters 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 AUTHTYPE is specified, AUTHID may not be specified.

If you are using RACF for some or all of the security checking in your DB2 address space, you need to use the USERID or GROUP options. This is because only threads defined with these options pass the required RACF access control environment element (ACEE) to DB2. The ACEE is not required if you are only using DB2 internal security, 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.

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, there is no difference between AUTHTYPE(USERID) and AUTHTYPE(GROUP).

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 (three characters padded to eight).
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 the CICS system must have RACF external security SEC=YES specified in the CICS system initialization table (SIT).

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 (four characters padded to eight) 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, AUTHTYPE(TERM) should not be used.

TX
Specifies the transaction identification (four characters padded to eight) as the authorization ID.
DROLLBACK({YES|NO})
Specifies whether or not the CICS DB2 attachment should initiate a SYNCPOINT rollback in the event of a transaction being selected as victim of a deadlock resolution.
YES
The attachment facility issues a syncpoint rollback before returning control to the application. An SQL return code of -911 is returned to the program.

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

NO
The attachment facility does not to initiate a 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. If PLAN is specified, PLANEXITNAME cannot be specified.
PLANEXITNAME(DSNCUEXT|exit)
Specifies the name of the dynamic plan exit to be used for this DB2 entry definition. If you change the PLAN and PLANEXITNAME while there are active transactions for the DB2 entry definition, the next time the transaction releases the thread, the plan/exit will be determined using the new rules. If PLANEXITNAME is specified, PLAN cannot be specified.
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. If CICS is connected to DB2 Version 5 or earlier, the thread TCBs are private TCBs created by the CICS-DB2 Attachment Facility.
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 lower priority than the CICS QR TCB.
PROTECTNUM({0|value})
Specifies the maximum number of protected threads allowed for this DB2 entry definition. A thread, when it is released by a transaction and there is no other work queued, can be protected, meaning that it is not terminated immediately. A protected thread is terminated after only two complete purge cycles if it has not been reused in the meantime. Hence, if the purge cycle is set to 30 seconds, a protected thread is terminated 30 - 60 seconds after it is released, assuming 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 only protected 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 or not transactions should wait for a DB2ENTRY thread, be abended, or overflow to the pool should the number of active DB2ENTRY threads reach 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 NO has been specified for the THREADWAIT attribute on the DB2 connection definition, the transaction is terminated with abend code AD3T.
NO
If all threads are busy, a transaction is terminated with an abend code AD2P.
YES
If all threads are busy, a transaction waits until one becomes available.