After calling DBCHINI, set the crash/delay options as follows:
- Tell About Crash (or Tell About Delay) to N
- Wait Across Crash (Wait Across Delay) to Y
Given this combination, the steps if a Teradata Database crash/delay occurs follow:
- The application program calls DBCHCL for some function.
- The system crashes or an AP resets before or after receiving information from DBCHCL.
- The application program is not notified of crash or reset and does not gain control.
- The database system restarts or an AP reset completes.
- The application program regains control from CLI with a return code of EM_OK (0).
- When the application program calls DBCHCL for the Fetch function, it obtains
- The Teradata Database does not know anything about a request with that request number (Error parcel with error code 2825).
- The Teradata Database aborted that request (Failure parcel with failure code 2828).
- The request completed successfully but the response has been lost (Error parcel with error code 2826).
- The application program takes action appropriate to the application.
Before submitting a request, save a copy of the request in case it must be re-submitted. If a transaction spans several requests, save a copy of each request in the transaction in case the transaction must be re-submitted.
If a restart occurs during a logoff request, CLI automatically resubmits the request.
The setting of Wait For Response has no effect on the processing shown above.