Start of change

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:

  1. Modify the MONITOR IDLE THREADS exception threshold in the SYSIBM.DSN_PROFILE_ATTRIBUTES table.
  2. Issue the START PROFILE command to refresh the exception threshold value.
End of change