Coordination with Other Events - Call-Level Interface Version 2

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

Product
Call-Level Interface Version 2
Release Number
15.00
Language
English (United States)
Last Update
2018-09-28
dita:id
B035-2417
lifecycle
previous
Product Category
Teradata Tools and Utilities

Coordination with Other Events

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:

  • Allow DBCHCL to suspend
  • 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'.

  • Retry if DBCHCL would suspend
  • 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'.

  • Suspend only in the application
  • 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:

  • Call DBCHWAT or DBCHWL when suspension is allowed. If suspension can be tolerated at times, then DBCHWAT or DBCHWL can be called to suspend if necessary until a Teradata request completes. When DBCHWAT or DBCHWL returns control, the completed request is indicated and DBCHCL can be retried.
  • Include another event when calling DBCHWAT or DBCHWLD. These calls can be informed of another event using the DBCHUE service and DBCHWAT, or DBCHWL can be called to suspend if necessary until either a Teradata event or the other event completes. A return code 160 indicates that the other event completed; otherwise, the completed event is indicated and DBCHCL can be retried
  • Include Teradata events in another event. The completion of a Teradata request can be included into another event by using the DBCHME service. The application then suspend on that event using an operating system service. When completion is indicated, the application must determine whether the other event completed. If not, then a Teradata request has completed and DBCHWAT or DBCHWL is called to identify the request so that DBCHCL can be retried. Since it is known that some Teradata request has completed, it is known that DBCHWAT or DBCHWL will not suspend.