After calling DBCHINI, set the crash/delay options as follows:
- Tell About Crash (or Tell Across Crash) to Y
- Wait Across Crash (or Wait Across Delay) to Y
Given this combination of options, a Teradata Database crash or AP reset can be handled as follows:
- The application program calls DBCHCL for some function.
- The Teradata Database crashes or an AP resets before or after receiving information from DBCHCL.
- CLI returns control to the application program, with return code of EM_DBC_CRASH_B or EM_DBC_CRASH_A.
- The application program can tell its user of the possible crash/delay and can ask the user whether to wait or disconnect.
- Assuming a wait, the application program calls DBCHCL for the fetch function.
- Teradata Database restarts or AP reset completes.
- The application obtains results of the Fetch:
- Teradata Database does not know anything about a request with that request number (Error parcel with error code 2825)
- 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.
Tell and wait may be useful to terminal-oriented applications to distinguish excessive response time from the unlikely, but possible, Teradata Database crash or AP reset.