16.20 - Multi-Session Management - Teradata Tools and Utilities

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

prodname
Teradata Tools and Utilities
vrm_release
16.20
created_date
September 2019
category
Programming Reference
featnum
B035-2417-108K

Two or more sessions can be connected simultaneously to the same (or different) Teradata Databases. Each session can process two or more requests simultaneously as previously discussed for multi-request management.

Prior to considering a multi-session approach, an application programmer should determine whether multi-statement requests on a single session satisfy throughput and response time requirements. A multi-session application is much more complicated to implement, debug, and maintain. In addition, depending on the application, multi-session techniques can result in deadlocks and open timing windows that can leave Teradata Database in an inconsistent state. Nevertheless, CLIv2 provides facilities to assist implementation of multi-session applications.

Because each session can have an active request, an application can do one of the following:
  • wait for completion of a particular request on a particular session, just as it would if only one session existed,
  • wait for the completion of any of the active requests, or
  • wait for any combination of the previous two.

Waiting for completion of a particular request is the simplest from a programming standpoint, but it may result in more time spent waiting than is necessary because other requests might complete before the one being waited upon, and the application could be processing those responses.

Waiting for the completion of any request is more complex programming, but results in the minimum amount of time waiting because the application is never waiting when a response is available for processing.

How It Works

Each concurrent request can be identified to CLIv2 by using both the ID of the session with which it is associated (that is, the value in Output-CLIv2-connection-number from a call to DBCHCL for the Connect function) and its own ID (that is, the value in Output-CLIv2-request-number from a call to DBCHCL) for these functions:
  • Connect
  • Initiate Request
  • RunStartUp
  • Initiate with Protocol-function
  • Command

Using Tokens

An application can also supply a token for each request when it is initiated. That token is returned by the DBCHWAT routine when a request response arrives. An application can have requests pending on several sessions simultaneously.

One way for an application to wait is to call DBCHWAT. The wait ends when any request completes. The advantage of this first method is that it maximizes throughput by reducing session idle time. The application can handle the response and dispatch another request as soon as the previous request completes.

Using Fetch

An alternate way for an application to wait is to call DBCHCL for the Fetch function, using the Output-CLIv2-connection-number of an active session. The wait ends when the specified request completes. The problem with this method is that the application cannot know which of the active requests will complete first. The application calls DBCHWAT, which determines which requests are active and waits for any of them to complete. When a request completes, DBCHWAT returns to the caller the Output-CLIv2-connection-number and optional user-specified token associated with the completed request. The application can then handle the response, dispatch another request, and again call DBCHWAT.

Language Location of Sample on the Release Tape
IBM Assembler EX2
COBOL CLI2MCB
PL/I CLI2MPB