Ending a Request - 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.10
Published
October 2021
Language
English (United States)
Last Update
2021-11-02
dita:mapPath
ttt1608578409164.ditamap
dita:ditavalPath
obe1474387269547.ditaval
dita:id
B035-2418
lifecycle
previous
Product Category
Teradata Tools and Utilities

If the database is processing a request submitted under the Resp processing option and sends a Response Message that contains the last parcel of the Teradata SQL response, it discards the Teradata SQL response and closes the Teradata SQL request.

If the database is processing a request submitted under the KeepResp processing option and sends a Response Message that contains the last parcel of the Teradata SQL response, it keeps the Teradata SQL response and does not close the Teradata SQL request.

If a Teradata SQL response is being held by the database (because the last parcel has not been sent or because the KeepResp option is in effect) and the application program no longer needs the Teradata SQL response, the application program can have the Teradata SQL response discarded and Teradata SQL request closed out. The next sections describe this process.

Application

In the DBCAREA, the application supplies the session id and request id, if they changed since the DBCAREA was last used, and sets the function code to DBFERQ. It then calls DBCHCL.

DBCHCL

DBCHCL first determines whether to use the DBCAREA or the RCB for the specified request when testing options by testing the set options flag of the DBCAREA. If it is “Y,” the DBCAREA options are used; otherwise, the RCB options are used. If the specified session is active, MTDP is called with the session and request identifiers of the active request, the function code set to MTDPRET, and the waitdata flag set according to the value of the selected options area’s waitdata flag.

MTDP

MTDP checks if the specified request has completed, and, if it has not completed and the waitdata option is set, waits until the response message for the prior request arrives, or an error occurs, and then returns control to DBCHCL.

DBCHCL

If MTDP fails (either because of a fault or because the waitdata option was not set), DBCHCL returns an error message to the application. DBCHCL builds a Cancel parcel in the message body part of the Request Buffer, sets the function code in the MTDP Control Block to MTDPCONT, and calls MTDP.

MTDP

MTDP sends a Continue Request message containing a Cancel parcel to the database, and returns control to DBCHCL.

DBCHCL

If the return code in the MTDP Control Block is not normal, DBCHCL returns an error message to the application. Otherwise, in the MTDP Control Block DBCHCL sets the waitdata option to “on” and sets the function code to MTDPRET. DBCHCL then calls MTDP.

MTDP

MTDP waits for the arrival of the Continue Response Message and then returns control to DBCHCL.

DBCHCL

DBCHCL returns an error message to the application if the MTDP indicated a failure. Otherwise, the buffers allocated for the requests are returned to the free memory pool, the RCB is removed from the request list of its SCB and returned to free memory, and a success message is returned to the application.

Application

If the return code in the DBCAREA is not normal, the application makes the appropriate changes and re-submits the DBCAREA to DBCHCL, as above. Otherwise, the application consumes the response.