DBFRSUP - Call-Level Interface Version 2

DBFRSUP

DBFRSUP is the Run Startup function of DBCHCL.

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

How It Works

The startup request is a Teradata SQL request stored on the Teradata 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”

Note: 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 is:

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 Teradata Database, that is, the initial status is successful. If the request is successful on the client, the Teradata 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 is:

1 Call DBCHCL for DBFRSUP

2 Check that return code is zero

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

3 Call DBCHCL for DBFERQ

4 Check that return code is zero

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:

DBCAREA Parameters

The following fields in the DBCAREA may be read or written to by DBCHCL’s DBFRSUP, depending on the application program’s environment.

Input Arguments

Change Options

Column Title and Format Information

Data Encryption

Dynamic Result Sets Allowed

Function

Input Session Id

Keep Response

Locate Mode

Maximum Parcel

Parcel Mode

Period-as-Struct

Request Buffer Length

Request Processing Option

Response Buffer Length

Response Mode

Return Time

Save Response Buffer

Stored Procedure Return Result

Tell About Crash

Token

Transforms-off

Trusted-request

Two Response Buffers

Use Presence Bits

Variable Length Fetch

Variable Length Request

Wait Across Crash

Wait For Response

XML-Response-Format

Output Arguments

Current Response Buffer Length

Message Length

Message Text

Output Request Id

Return Code

Return Identity Data

TDP Request Number