Connection attributes

Describes the attributes of the DB2CONN resource that relate to the connection.

CONNECTERROR({SQLCODE|ABEND})

Specifies the way that the information, that CICS® is not connected to DB2® because the attachment facility is in 'standby mode', is reported back to an application that has issued an SQL request.

ABEND: The application abends with abend code AEY9.
SQLCODE: The application receives a -923 sqlcode. SQLCODE cannot be specified if STANDBYMODE is set to NOCONNECT.

DB2GROUPID(name)

Specifies the group ID (up to four characters) of a data sharing group of DB2 subsystems. The group attach facility connects CICS to any active member of this data sharing group. Match the group ID to the group attachment name defined in DB2. With DB2 Version 10, the group ID can be a subgroup attachment name defined to DB2 which defines a subset of the data sharing group. If the DB2GROUPID attribute remains blank, group attach is not used. You cannot specify both DB2GROUPID and DB2ID, the priorities are as follows:

Specifying a DB2GROUPID blanks out any DB2ID that is already set in the DB2CONN definition.
If you attempt to specify both a DB2GROUPID and a DB2ID on the same CEDA panel, the DB2ID is used.
If the DB2ID of an individual subsystem is specified in a CEMT or EXEC CICS SET DB2CONN command, or in a DSNC STRT command, this DB2ID overrides any DB2GROUPID attribute that is set in the installed DB2CONN definition. The DB2GROUPID in the installed DB2CONN definition is blanked out, and must be set again (using CEDA or a SET DB2CONN command) to use group attach.

DB2ID(name)

Specifies the name of the DB2 subsystem to which the CICS DB2 attachment facility is to connect. By default this field is blank. If you want to use group attach, specify a DB2GROUPID in the DB2CONN definition, instead of a DB2ID. The DB2ID set in the installed DB2CONN definition can be overridden by a DB2 subsystem ID specified on a DSNC STRT command, or by a DB2ID specified in a SET DB2CONN command. If the DB2ID in the installed DB2CONN definition remains blank, and the DB2GROUPID also remains blank, you can specify a DB2 subsystem ID on the INITPARM system initialization parameter. If no DB2 subsystem ID is specified by any of these means, and no DB2GROUPID is specified, the default DB2ID of blanks is replaced by DSN when the connection is attempted. Hence, the hierarchy for determining the DB2 subsystem is as follows:

Use the subsystem ID if it is specified in a DSNC STRT command.
Use the DB2ID in the installed DB2CONN if it is not blank.
Use the DB2GROUPID in the installed DB2CONN for group attach, if it is not blank.
Use the subsystem ID if it is specified on the INITPARM when the DB2ID and DB2GROUPID in the last installed DB2CONN are blank (or have later been set to blanks). On any startup, INITPARM is always used if the last installed DB2CONN contained a blank DB2ID and a blank DB2GROUPID, even if the DB2ID or DB2GROUPID was later changed using a SET command.
Use a default subsystem ID of DSN.

You cannot specify both DB2GROUPID and DB2ID — if you attempt to specify both on the same CEDA panel, the DB2ID is used. If a DB2GROUPID is specified in a CEMT or EXEC CICS SET DB2CONN command, this overrides any DB2ID that is set in the installed DB2CONN definition, and the DB2ID is blanked out.

MSGQUEUE1({CDB2|tdqueue})

Specifies the first transient data destination to which unsolicited messages from the CICS DB2 attachment facility are sent. This first destination cannot be blank.

MSGQUEUE2(tdqueue)

Specifies a second transient data destination to which unsolicited messages from the CICS DB2 attachment facility are sent.

MSGQUEUE3(tdqueue)

Specifies a third transient data destination to which unsolicited messages from the CICS DB2 attachment facility are sent.

NONTERMREL({YES|NO})

Specifies whether a non-terminal transaction releases threads for reuse at intermediate sync points.

NO: Non-terminal transactions do not release threads for reuse at intermediate sync points.
YES: Non-terminal transactions release threads for reuse at intermediate sync points.

PURGECYCLE({00|mm},{30|ss})

Specifies the duration, in minutes and seconds, of the purge cycle for protected threads. The duration of the purge cycle is in the range 5 seconds to 59 minutes 59 seconds. If you do not specify a value for PURGECYLE, it defaults to 30 seconds; PURGECYCLE= 00, 30.

A protected thread is not terminated immediately when it is released. It is terminated only after two completed purge cycles, if it has not been reused in the meantime. Therefore, if the purge cycle is set to 30 seconds, a protected thread is purged 30 - 60 seconds after it is released. The first purge cycle after the attachment facility starts is always 5 minutes. After that the purge cycle values are applied. An unprotected thread is terminated when it is released (at sync point or end of task) if there are no other transactions waiting for a thread on that DB2ENTRY. Only threads belonging to a DB2ENTRY can be protected. Pool threads and command threads cannot be protected.

RESYNCMEMBER({YES|NO})

If you are using group attach, use the RESYNCMEMBER attribute to select the strategy that CICS adopts if outstanding units of work are being held for the last DB2 data sharing group member to which CICS was connected.

YES: Indicates that if outstanding units of work are held, you require resynchronization with the last DB2 data sharing group member to which CICS was connected. CICS ignores the group attach facility, and the CICS-DB2 attachment facility waits until it can reconnect to that last connected DB2 data sharing group member, to resolve the indoubt units of work. Units of work which are shunted indoubt are not included in this process, because CICS itself is unable to resolve those units of work at this time. Resynchronization for those UOWs occurs when CICS has resynchronized with its remote coordinator.
NO: Indicates that you do not require resynchronization. CICS makes one attempt to reconnect to the last connected DB2 data sharing group member. If this attempt is successful, the indoubt units of work (except for UOWs that are shunted indoubt) can be resolved. If it is unsuccessful, then CICS uses group attach to connect to any active member of the DB2 data sharing group, and a warning message (DFHDB2064) is issued stating that there can be unresolved indoubt units of work with the last member of the group to which CICS was connected.

REUSELIMIT(value)

Specifies a value in the range 0 - 10000 representing the maximum number of times a thread can be reused before it is terminated. The default is 1000. A value of 0 means that there is no limit on the number of times that a thread can be reused; this was the situation before CICS TS 4.2. However, long-running CICS DB2 threads that are constantly being reused build up resources in DB2 that can cause storage problems leading to abends and DB2 subsystem outages.

The reuse limit applies to unprotected threads both in the pool and on a DB2ENTRY, and to protected DB2ENTRY threads. An unprotected thread is reused if, at the time it is released from a transaction, there is a new transaction waiting. A protected thread is reused if a new transaction requires a thread during the time the thread is protected from being terminated. In either case, when the reuse limit is reached no further transactions can use the thread. When the transaction that is currently using the thread releases it, CICS terminates and re-creates the thread to free up DB2 resources before determining if there is new work for the thread to do, or whether the thread is to be protected.

Using the default of 1000 provides sufficient protection against over-allocating thread storage and EDM pool storage below the 2 GB bar when you are using a DB2 bind option of RELEASE(DEALLOCATE) without adversely affecting performance. If, however, DB2 monitoring and statistics show excessive DB2 thread storage, excessive EDM pool storage usage, or both, this limit can be lowered. Conversely, if CICS-DB2 statistics show that pool or entry threads are hitting the reuse limit frequently and there is sufficient virtual and real storage available to allow more DB2 thread storage, this limit can be raised.

Setting a low value for the reuse limit has a performance impact in terms of an increase in processor activity and a decrease in throughput. However, there are situations where you might choose to set a low value. For example, if you wanted to evaluate changing DB2 bind options from RELEASE(COMMIT) to RELEASE(DEALLOCATE) for a plan or package, you might use a low value temporarily to test the scenario.

SIGNID(name)

Specifies the authorization ID to be used by the CICS DB2 attachment facility when signing on to DB2 for pool and DB2ENTRY threads that specify AUTHTYPE(SIGN). The default is blanks which are replaced by the applid of the CICS system when the DB2CONN is installed. 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 that you enter are converted to uppercase.

If you specify a user ID on the SIGNID attribute, CICS performs a surrogate user check against the user ID that is performing the installation. Similarly, the CICS region user ID is subject to a surrogate user check during group list installation on a CICS cold or initial start.

If the ID you specify matches the CICS region user ID, and you specify AUTHTYPE(SIGN) for any command, pool, or entry threads, the RACF® access control environment element (ACEE) for the CICS region user ID is passed to DB2.

STANDBYMODE({RECONNECT|CONNECT|NOCONNECT})

Specifies the action to be taken by the CICS DB2 attachment facility if DB2 is not active when an attempt is made to connect CICS to DB2.

CONNECT: Specifies that the CICS DB2 attachment facility is to wait in 'standbymode' for DB2 to become active. If the connection is made, and DB2 later fails, the CICS DB2 attachment facility terminates.
NOCONNECT: Specifies that the CICS DB2 attachment facility is to terminate.
RECONNECT: Specifies that the CICS DB2 attachment facility is to go into 'standby mode' and wait for DB2. If DB2 later fails after the connection is made, the CICS DB2 attachment facility reverts to 'standby mode', and CICS then reconnects to DB2 when DB2 recovers.

STATSQUEUE({CDB2|tdqueue})

Specifies the transient data destination for CICS DB2 attachment facility statistics produced when the CICS DB2 attachment facility is shut down.

TCBLIMIT({12|value})

Specifies the maximum number of TCBs that can be used to process DB2 requests. The default is 12. The minimum number is 4 and the maximum is 2000. CICS uses L8 and L9 mode open TCBs to process DB2 requests. The TCBLIMIT attribute of the DB2CONN definition governs how many of the open TCBs can be used to access DB2, that is, how many of them can identify to DB2 and create a connection into DB2.

For more information about TCB limits and open TCB modes, see Open TCB management.

The TCBLIMIT value controls the total number of threads for the CICS region. For this reason, the recommended value for TCBLIMIT is the sum of all the thread limit values (that is, the sum of all THREADLIMIT attributes on the DB2 connection and DB2 entry resource definitions, plus the COMTHREADLIMIT value on the DB2 connection definition) up to the limit of 2000.

If the limit set automatically by CICS for the number of L8 and L9 mode open TCBs is reached, so no more open TCBs can be created, the task is suspended with HTYPE(DISPATCH) and HVALUE(OPEN_TCB). CICS sets this limit using the formula (2 * MXT value) + 32, with the MXT or MAXTASKS limit for the CICS region. If this limit is not exceeded but TCBLIMIT is exceeded, then the task is suspended with HTYPE(CDB2CONN). In this situation, although CICS has an open TCB available, the maximum allowed number of open TCBs are being used to access DB2 (as defined in TCBLIMIT).

When determining the number for TCBLIMIT, you must consider the amount you specified for the MAX USERS parameter on DB2 installation panel DSNTIPE.

THREADERROR({N906D|N906|ABEND})

Specifies the processing that is to occur following a create thread error.

ABEND: When the first SQL error is detected, CICS takes a transaction dump for abend code AD2S, AD2T, or AD2U, depending on the type of error. For the first error, the transaction does not abend. For a second or subsequent SQL error, the transaction abends with abend code AD2S, AD2T, or AD2U. The transaction must be terminated and reinitialized before it is allowed to issue another SQL request.
N906D: A transaction dump is to be taken and the DSNCSQL RMI associated with the transaction is not to be disabled. The transaction receives a -906 SQLCODE if another SQL is issued, unless the transaction issues SYNCPOINT ROLLBACK. SYNCPOINT without the ROLLBACK option results in an ASP3 or ASP7 abend. The transaction dump records an abend of AD2S, AD2T, or AD2U.
N906: The DSNCSQL RMI associated with the transaction is not to be disabled. The transaction receives a -906 SQLCODE if another SQL request is issued, unless the transaction issues a SYNCPOINT ROLLBACK. SYNCPOINT without the ROLLBACK option results in an ASP3 or ASP7 abend.