An application can have events other than requests for a Teradata session. Depending upon the particular function, calls to DBCHCL may require communication with Teradata Database. If so, control is not returned to the application until Teradata Database responds. But until DBCHCL returns control, the application will be unaware of other events that might have been completed. For example, an application might need to establish a timer and abort a Teradata request that does not complete before the timer interval expires. The three responses follow:
Suspending DBCHCL is the default and simplest handling. DBCHCL is called normally and control is not returned to the application until the request is completed. The application cannot check for completion of other events until control is returned. The DBCAREA Wait‑for‑Response option is set or defaulted to 'Y'.
DBCHCL is called but never waits if a response from Teradata Database is required. Instead, control is returned to the application with return code 150 and the application must call DBCHCL later to retry the operation. The DBCAREA Wait‑for‑Response option is set to 'N'.
DBCHCL is called but never waits if a response from the Teradata Database is required. Instead, control is returned to the application with return code 150, the application chooses when to suspend, then the application must call DBCHCL later to retry the operation. The DBCAREA Wait‑for‑Response option is set to 'N' and the CLIv2 DBCHWAT or DBCHWL service is used. Both DBCHWAT and DBCHWL identify event completions, they differ only in that DBCHWAT responds to any event while DBCHWL responds only to specified events. The following techniques can be used: