17.10 - Case 1: Tell and Wait - Call-Level Interface Version 2

Teradata® Call-Level Interface Version 2 Reference for Workstation-Attached Systems

Call-Level Interface Version 2
Release Number
October 2021
English (United States)
Last Update
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 database crash or AP reset can be handled as follows:
  1. The application program calls DBCHCL for some function.
  2. The 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. The database restarts or AP reset completes.
  7. The application obtains results of the Fetch:
    • The database does not know anything about a request with that request number (Error parcel with error code 2825)
    • The 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)
  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.

Tell and wait can be useful to terminal-oriented applications to distinguish excessive response time from the unlikely, but possible, database crash, or AP reset.