Repositioning, Single Buffering - 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

The following information applies if an application chooses single-buffering and a request is a single statement request. CLI will fetch the response in single buffering mode only; even if double buffering is set and reposition of response is requested.

Application

In the DBCAREA, the application performs the following tasks:
  • Supplies the session id and request id of the response required.
  • Supplies the length of and a pointer to the response area, if the request was submitted with the Move Mode processing option.
  • Sets the DBCAREA fields positioning_action, positioning_value, and positioning_stmt_number, as required.
  • Sets the function code to FETCH(DBFFET).
  • Calls DBCHCL.

DBCHCL

If the specified session is active and the database to which the session is connected supports Cursor Repositioning:
  • The RCB for the active request is located.
  • The waitdata options flag and other cursor repositioning flags are passed to MTDP with session and request identifiers.
  • MTDP is called to check for or wait for completion of the request.
An error is returned to the application in the following scenarios:
  • If keep_resp is not set to 'P' while initiating the request.
  • The request did not complete successfully.
  • The requested reposition is invalid.

Otherwise, DBCHCL places a PclROWPOSITION/PclOFFSETPOSITION parcel in the request buffer for the request, supplies the session id and request id of the specified request in the MTDPCB, sets the MTDPCB function code to MTDPCONT, and calls MTDP.

MTDP

MTDP sends a Continue Request message to the database. It then returns control to DBCHCL.

DBCHCL

A success or error message is generated in the message field of the DBCAREA and DBCHCL returns to the application.

Application

If the return code or the error flag in the DBCAREA is not normal, the application makes the appropriate changes, and re-submits the DBCAREA to DBCHCL, as above. Otherwise, it performs a fetch as for the non-reposition case and consumes the unit of response. Typically, the application loops back for another unit of response until the EndRequest parcel is obtained.