00E30502
Explanation
A thread was canceled because the length of time that a thread was idle exceeded the exception setting for the MONITOR IDLE THREADS keyword in a monitor profile for one of the following filtering scopes:
- LOCATION
- PRDID
- ROLE_AUTHID
- ROLE
- AUTHID
- COLLID_PKGNAME
- COLLID
- PKGNAME
- CLIENT_APPLNAME
- CLIENT_USERID
- CLIENT_WRKSTNNAME
The server thread was holding Db2 resources and the requesting application did not make a request to the Db2 server thread for an extended period of time.
System action
Db2 issues message DSNT772I.
The subsequent system action depends on the ATTRIBUTE1 column value in the SYSIBM.DSN_PROFILE_ATTRIBUTES table:
- If the ATTRIBUTE1 value is EXCEPTION, Db2 abnormally terminates the execution unit, terminates the server thread to release resources that might affect other threads, and terminates the connection with the remote application.
- If the ATTRIBUTE1 value is EXCEPTION_ROLLBACK, the server thread is aborted. The connection with
the remote application is maintained.
If the aborted transaction performed database updates, the application environment is placed in a must-abort state so that the application environment is made aware of the resources that have been destroyed as a result of the aborted threads.
Important: If either of the following situations are true, Db2 hides the EXCEPTION_ROLLBACK event from the remote application environment:- The aborted transaction performed only read-only operations.
- The transaction committed or aborted, but the associated database access thread remained active before it became idle.
Because the EXCEPTION_ROLLBACK event is not visible to the remote application environment in those cases, it might appear to the remote application environment that the database resources are unexpectedly disappearing. For example, held cursors, kept dynamic statements, and declared temporary tables that were created in the transaction are destroyed. Use EXCEPTION_ROLLBACK only if the remote application environment can account for this apparent loss of database resources.
Operator response
Notify the system programmer.
System programmer response
Review the information provided in message DSNT772I. Determine why the requesting application did not make a request to the Db2 server in the specified time.
This condition typically occurs for one of the following reasons:
- The ACTIVE thread option was specified in the DDF THREADS field of the DSNTIPR installation
panel, and a requester application or its user did not make a request to the Db2 server for an extended period (such as a lengthy
user absence). As a result, the server thread becomes susceptible to cancellation because of the
timeout value.
Action: Determine why the requesting application did not make a request to the Db2 server in the specified time.
- The INACTIVE thread option was specified in the DDF THREADS field of the DSNTIPR installation
panel, and a requester application or its user failed to commit before an extended dormant period
(such as user absence). It is also possible that, despite committing before an extended dormant
period, database resources are still held because of other existing conditions. As a result, the
server thread cannot be moved to the inactive state and becomes susceptible to being canceled
because of the timeout value.
Action: Determine why the server thread was not moved to the inactive state.
If the application requires additional time:
- Modify the MONITOR IDLE THREADS exception threshold in the SYSIBM.DSN_PROFILE_ATTRIBUTES table.
- Issue the START PROFILE command to refresh the exception threshold value.