After calling DBCHINI, set the delay options as follows:
Given this combination of options, a delay can be handled as follows:
- The application calls DBCHCL for some function
- The Teradata Database delay occurs before or after receiving information from DBCHCL
- CLIv2 returns control to the application, with return code of 286
- The application can tell its user of the possible delay and can ask user whether to wait or disconnect, assuming wait
- The application calls DBCHCL for the fetch function
- Communication is re-established
- The application obtains results of the Fetch, which may be as follows:
- 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 takes action appropriate to the applicationBefore submitting a request, save a copy of the request in case it must be resubmitted. If a transaction spans several requests, save a copy of each request in the transaction in case the transaction must be resubmitted.
Tell and wait may be useful to terminal-oriented applications to distinguish excessive response time.