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

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

Product
Call-Level Interface Version 2
Release Number
15.10
Language
English (United States)
Last Update
2018-10-07
dita:id
B035-2418
lifecycle
previous
Product Category
Teradata Tools and Utilities

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:

    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:

  • 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)
  • 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.