Using Fetch - Call-Level Interface Version 2

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

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
Lake
VMware
Product
Call-Level Interface Version 2
Release Number
20.00
Published
January 2024
Language
English (United States)
Last Update
2024-05-14
dita:mapPath
bmn1691484839905.ditamap
dita:ditavalPath
obe1474387269547.ditaval
dita:id
fvz1470444150352
Product Category
Teradata Tools and Utilities

An alternate way for the application to wait is to call a synchronous wait using DBCHCL for the Fetch function, using the session id of an active session. The wait ends when the specified session completes.

Usage Notes

On the one hand, the problem with this method is that the application cannot know which of the active sessions will complete first. On the other hand, an asynchronous wait (calling DBCHWAT) maximizes throughput by reducing session idle time. The application can handle the response and dispatch another request as soon as the session completes.

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 session identifier and optional user-specified token associated with the completed request. The application can then handle the response, dispatch another request, and again call DBCHWAT.

Windows and Linux support a maximum of 1024 sessions (for a single process). All other UNIX-based operating systems set the session limit based upon the maximum number of file descriptors returned from the ulimit UNIX command.