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

DBFRSUP is the Run Startup function of DBCHCL.

DBFRSUP sends a request to the database to execute the Startup Request stored on the database.

How It Works

The startup request is a Teradata SQL request stored on the database by means of a CREATE USER or MODIFY USER statement that contains a STARTUP clause.

DBFRSUP performs the following functions:
  • If the session is active, awaits completion of the active request
  • If the previous request was a CON and it was not successful, receives an error indicating “unable to initiate because session is not logged on”
    Upon receiving this return error, the application must invoke DBFDSC.
  • If the application has requested option updates, performs option set/validation logic
  • Ensures that request buffer is large enough.
    • Builds request in request buffer, as follows:
    • Request parcel in either Record, Field, or Indicator Mode based on the setting of the Response Mode
    • Input Data parcel in either Record or Indicator Mode based on setting of Using Presence Bits, and
    • Resp or KeepResp parcel based on Keep Response setting
Then DBFRSUP sends a request to the MTDP:
  • If not successful, cleanups and returns to the application
  • Sets Open Request, and so on, and returns to caller

Submitting the Startup Request

The sequence of operations for submitting the startup request follows:
  1. Call DBCHCL for DBFRSUP.
  2. Check that return code is zero.

A return code of zero does not imply that the Teradata SQL request was successful. It does imply that the request has been sent to the database, that is, the initial status is successful. If the request is successful on the client, the database processes it and sends the first portion (buffer-full) of the Teradata SQL response to the client. To verify that the request was successful, call DBCHCL for DBFFET and check that the first parcel in the response stream is not an Error or Failure parcel.

Successful Run Startup Operation

The sequence of operations for a successful run startup operation follows:
  1. Call DBCHCL for DBFRSUP.
  2. Check that return code is zero.
  3. Call DBCHCL for DBFERQ.
  4. Check that return code is zero.

See DBFFET for steps to take until response is “consumed” or no longer required (if rewind is required, see DBFREW and then DBFFET).

If the application program calls DBCHCL for the DBFRSUP without first calling DBCHCL for DBFCON, DBCHCL returns with a return code “first do a connect” (NO SESSION 304).

If the call to DBCHCL for the DBFRSUP results in a non-zero return code, the run startup has failed for the reason indicated by the value of the return code. CLI internal structures for the non-existing request can (and should) be de-allocated by calling DBCHCL for DBFERQ. The Output Request Id from the DBFRSUP is the appropriate value to place in Input Request Id for DBFERQ.

The startup request is not to contain a USING clause. Thus, the value of Use Presence Bits is read and stored, but not used.

Interface

The DBFRSUP interface is as follows:

Function: DBFRSUP - RunStartUp
Purpose: Perform the DBFRSUP
Parms: