Aborting a Request: Example - Call-Level Interface Version 2

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

Product
Call-Level Interface Version 2
Release Number
17.00
Published
June 2020
Language
English (United States)
Last Update
2021-04-19
dita:mapPath
xen1544831946512.ditamap
dita:ditavalPath
obe1474387269547.ditaval
dita:id
B035-2418
lifecycle
previous
Product Category
Teradata Tools and Utilities

Assume a session has been created and a request started as in the single buffering, no rewind example given above. If the application wants to abort the request, the following must be performed.

The application sets the function code to abort (DBFABT) in the DBCAREA and calls DBCHCL.

This implies that if the end-user may need to abort a request, the application must submit the prior-pending request with the Wait For Response option set to no, so that the application can get control before the start response is returned from the database.

DBCHCL

DBCHCL allocates a request buffer and places an Abort parcel in the message body part of the Request Buffer. DBCHCL places the session and Request Ids in the MTDPCB, sets the function code to MTDPABOT, and calls MTDP.

MTDP

MTDP prepares and sends an Abort Request message to the database, and waits for the Abort Response message. MTDP then returns control to DBCHCL.

DBCHCL

If the return code in the MTDP Control Block is not normal, DBCHCL returns the error message pointed to by the DBCAREA to the application. Otherwise, the buffers allocated to the request are returned to free memory and the RCB is removed from its RCB list and returned to free memory.

If the return code or error flag in the DBCAREA is not normal, the application program makes the appropriate changes and then re-submits the DBCAREA to DBCHCL.