DBCHCL IRQ Function - Call-Level Interface Version 2

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

Product
Call-Level Interface Version 2
Release Number
16.10
Published
May 2017
Language
English (United States)
Last Update
2018-05-07
dita:mapPath
jen1488824663137.ditamap
dita:ditavalPath
Audience_PDF_include.ditaval
dita:id
B035-2417
lifecycle
previous
Product Category
Teradata Tools and Utilities

Purpose

IRQ (Initiate Request) sends a request to the Teradata Database to be processed.

Usage Notes

  • If Initiate Request is called without first calling CON, Initiate Request performs the CON. In this case, the information needed for a CON call should be supplied when doing the Initiate Request call.
  • If Return Code is 0, the application must invoke the FET function to process the response. After the response has been totally processed, the application must invoke the ERQ function to release resources used by the Initiate Request.
  • When initiating a request in a Two-phase commit session, Initiate Request will be rejected if the session has a Two-phase commit vote or terminate activity in progress.
    • After they are started, activities such as vote and terminate must be completed by the coordinator.
    • The vote can result from a previous Initiate with Protocol-Function (IWPF) function.
    • The terminate could have resulted from an Abort or Logoff or from any response that contained a Failure parcel.
    • If any of these occur, the coordinator must be requested to perform a syncpoint.

DBCAREA Input Fields

Before using the Initiate Request 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 Required for the Initiate Request Function
DBCAREA Input Fields Required for the Initiate Request Function
Function Input-CLIv2-connection-number
Request-length Request-pointer
DBCAREA Input Fields Optional for the Initiate Request Function
DBCAREA Input Fields Optional for the Initiate Request Function
Anticipated-number-of-concurrent-sessions APH-response-OK
Array-transforms-off Change-options
Character Set C2S-conversion
Column-info Continued-character-state
Data-encryption Extension-pointer
Inhibit-buffer-expansion Input-TDP-path
Input-CLIv2-connection-number Keep-response
Locate-mode Logon-length
Logon-pointer Max-decimal-returned
Maximum-parcel Message-area-length
Message-area-pointer Multi-statement-errors
Parcel Mode Period-as-Struct
Pointer Refresh-cached-data
Request-buffer-length Request-mode
Request-parcel-format Request-processing-option
Request-token Response-buffer-length
Response-mode Result-sets-OK
Return-identity-data Return-result-to
Return-statement-info Return-time
Row-count Run-length
Run-pointer Save-response-buffer
Set-character-set Statement-status
S2C-conversion Tell-if-delay
Transforms-off Trusted-request
Two-response-buffers USING-data-pointer
USING-data-length Use-presence-bits
Variable-length-fetch Variable-length-request
Wait-during-delay Wait-exclusion
Wait-for-response XML-response-format

DBCAREA Output Fields

Upon completion of the Initiate Request 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 by the Initiate Request Function
DBCAREA Output Fields always set by the Initiate Request Function
Current-response-buffer-length Message-return-code
Message-text Message-text-length
Output-CLIv2-request-number Return Code
DBCAREA Output Fields Set by Successful Initiate Request Functions
DBCAREA Output Fields set by Successful Initiate Request Functions
Current-request-buffer-length Open-requests
Output-TDP-request-number