After calling DBCHINI, set the delay options as follows.
Given this combination, the steps if a delay occurs are as follows:
- The application calls DBCHCL for some function
- The delay occurs before or after receiving information from DBCHCL
- The application is not notified of the delay and does not gain control
- Communication is re-established
- The application regains control from CLIv2 with a return code of zero
- When the application calls DBCHCL for the Fetch function, it obtains the following:
- 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.)
If Wait-for-response is set to N, CLIv2 logs the session off when it encounters the delay. CLIv2 sends the logoff request to the Teradata Database when communication is re-established.