DBFABT - 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

DBFABT is the Abort Request function of DBCHCL.

DBFABT attempts to abort the current start request and the transaction in which it is embedded. It is used asynchronously to abort a request in progress.

How It Works

DBFRABT performs the following functions:
  • If the application has requested option updates, performs option set/validation logic
  • If specified request is active on the database, sends an Abort Request message and returns to caller; otherwise, returns a error code

Sending an Abort

The sequence of operations to send an abort request follows:
  1. Call DBCHCL for DBFABT.
  2. Check that return code is zero.

A return code of zero indicates that an abort has been sent. It does not guarantee that the abort has been successful; the abort may “cross in the mail” with the response. The application program must also look at the first parcel received in the response to determine if the abort has been successful.

Successful Abort Operation

The sequence of operations for a successful abort operation follows:
  1. Call DBCHCL for DBFABT.
  2. Check that return code is zero.
  3. Call DBCHCL for DBFFET.
  4. Check that return code is zero.
  5. Check that first parcel is Failure.
  6. Check that failure code is ‘user abort’ (3110).
  7. Call DBCHCL for DBFERQ.
  8. Check that return code is zero.

Asynchronous Aborts

If the asynchronous abort reaches the database before it completes the response (spool file), the database aborts the original Teradata SQL request, rolls back the transaction (explicit or implicit) in which it was embedded, if any, and sends a Failure parcel as the response to the original request.

If a transaction is rolled back, any database changed by the transaction is returned to the state it would have been in if the transaction had not been submitted. However, the Teradata SQL response files for any Teradata SQL requests that have already completed are not discarded. They remain in the database until the requests are closed by a call to DBCHCL for the DBFERQ.

If the asynchronous abort reaches the database after it completes the response, the client receives the original response parcels for the original request. The abort does not take place.

To abort one request, the application program specifies that request’s session id and request id in the DBCAREA, sets the function code to abort, and calls DBCHCL. If multiple sessions are being used and more than one request is to be aborted, the application repeats these steps for each request.

The DBFABT is not itself affected by the setting of Wait For Response.

If the application program has a transaction in progress and is between requests, submit a synchronous abort by calling DBCHCL for DBFIRQ with a request consisting of the Teradata SQL ROLLBACK statement, not by calling DBCHCL for the DBFABT.

Values Read and Used, But Not Stored

The values of Wait Across Crash, Tell About Crash, Return Time, and Wait For Response are read and used, but not saved.

Interface

The DBFABT interface is as follows:

Function: DBFABT - Abort Request
Purpose: Attempt to ‘abort’ a currently active request
Parms: