Case 1: Tell and Wait
After calling DBCHINI, set the crash/delay options as follows:
Given this combination of options, a Teradata Database crash or AP reset can be handled as follows:
1 The application program calls DBCHCL for some function.
2 The Teradata Database crashes or an AP resets before or after receiving information from DBCHCL.
3 CLI returns control to the application program, with return code of EM_DBC_CRASH_B or EM_DBC_CRASH_A.
4 The application program can tell its user of the possible crash/delay and can ask the user whether to wait or disconnect.
5 Assuming a wait, the application program calls DBCHCL for the fetch function.
6 Teradata Database restarts or AP reset completes.
7 The application obtains results of the Fetch:
8 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.
Note: 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.