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.