DBFABT
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:
Sending an Abort
The sequence of operations to send an abort request is:
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 is:
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 Teradata Database before it completes the response (spool file), the Teradata 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 data base 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 Teradata Database until the requests are closed by a call to DBCHCL for the DBFERQ.
If the asynchronous abort reaches the Teradata 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: |
|
DBCAREA Parameters
The following fields in the DBCAREA may be read or written to by DBCHCL’s DBFABT, depending on the application program’s environment.