Recovering from database access thread failure

When a database access thread is deallocated, a conversation failure occurs, and you need to recover from this situation.

Symptoms

In the event of a failure of a database access thread, the Db2 server terminates the database access thread only if a unit of recovery exists. The server deallocates the database access thread and then deallocates the conversation with an abnormal indication (a negative SQL code), which is subsequently returned to the requesting application. The returned SQL code depends on the type of remote access:

  • DRDA access

    For a database access thread or non-Db2 server, a DDM error message is sent to the requesting site, and the conversation is deallocated normally. The SQL error status code is a -30020 with a resource type 1232 (agent permanent error received from the server).

Environment

Normal Db2 error recovery mechanisms apply, with the following exceptions:

  • Errors that are encountered in the functional recovery routine are automatically converted to rollback situations. The allied thread experiences conversation failures.
  • Errors that occur during commit, rollback, and deallocate within the DDF function do not normally cause Db2 to abend. Conversations are deallocated, and the database access thread is terminated. The allied thread experiences conversation failures.

Diagnosing the problem

System programmer response: Collect all diagnostic information that is related to the failure at the serving site. For a Db2 database access thread (DBAT), a dump is produced at the server.

Resolving the problem

Operator response: Communicate with the operator at the other site to take the appropriate corrective action, regarding the messages that are displayed at both the requesting and responding sites. Ensure that you and operators at the other sites gather the appropriate diagnostic information and give it to the programmer for diagnosis.