DBCHCL CON Function - Teradata Tools and Utilities

Teradata® Call-Level Interface Version 2 Reference for Mainframe-Attached Systems

Product
Teradata Tools and Utilities
Release Number
16.20
Published
September 2019
Language
English (United States)
Last Update
2019-10-12
dita:mapPath
dsu1527114222346.ditamap
dita:ditavalPath
dsu1527114222346.ditaval
dita:id
B035-2417
lifecycle
previous
Product Category
Teradata Tools and Utilities

Purpose

CON (Connect) logs on to Teradata Database and arranges to have the specified services available for all requests on that session.

Connect also allocates internal control structures that CLIv2 uses to store session context.

Usage Notes

  • If no Logon String is supplied or logon mechanism, a TDP logon exit must furnish the necessary information to complete the logon request. If a TDP logon exit does not exist or is disabled, the connect will be rejected by TDP.
  • The application should call the ERQ function after processing the CON function, regardless of the success or failure of the connect. This releases internal resources used during connect processing.
  • DSC must be performed for each CON request. If the CON results in a nonzero return code, DSC should be called immediately. Otherwise, DSC should be called when the application has completed all work for the session.
  • If Return Code is 0, the application must invoke the FET function to obtain the final status of the connect call.
    • If Connect-type was R, the FET call results in a Return Code of 33 if the connect was successful.
    • If Connect-type was C, the parcels must be processed to determine success or failure of the connect.
  • The FET returns three additional DBCAREA fields set only when CON is being processed. These fields are:
    • Output-TDP-path
    • Output-TDP-session-number
    • Output-host-id
  • Additional fields will be set as normal by the FET call.

    For a discussion of the call and the fields used, see DBCHCL FET Function.

DBCAREA Input Fields

Before using the Connect function, the application must set the DBCAREA fields in the first table and may optionally set those in the second table depending on the application's requirements.

DBCAREA Input Fields Optional for the Connect Function
Anticipated-number-of-concurrent-sessions Automatic-redrive
Change-options Character-set-pointer
Connect-type Country-id
C2S-conversion Data-encryption
Date-form Delegate-user-identity
Extended-load Input-TDP-path
Keep-response Language-conformance
Language-id Locate-mode
Logon-length Logon-pointer
Maximum-parcel Mechanism-data-encoding
Mechanism-data-len Mechanism-data-ptr
Mechanism-name Message-area-pointer
Message-area-length Parcel Mode
Request-buffer-length Request-mode
Request-parcel-format Request-processing-option
Request-token Response-buffer-length
Response-mode Return-time
Run-length Run-pointer
Save-response-buffer Session-desc-length
Session-desc-pointer Set-character-set
Statement-status S2C-conversion
Tell-if-delay Transaction-semantics
Two-response-buffers Two-phase commit
Use-default-conn Use-presence-bits
Utility-workload Varying-length-fetch
Varying-length-request Wait-during-delay
Wait-exclusion Wait-for-response
Workload-length Workload-pointer

DBCAREA Output Fields

Upon completion of the Connect function, CLIv2 will always set DBCAREA fields in the first table and will set those in the second table if the function was successful.

DBCAREA Output Fields Always Set for the Connect Functions
Message-return-code Message-length
Message-text Message-text-length
Current-response-buffer-length Output-CLIv2-request-number
Output-CLIv2-connection-number Return Code
DBCAREA Output Fields Set by Successful Connect Functions
Current-request-buffer-length Mechanism-name
Open-requests Session-status
Output-TDP-request-number