17.10 - Default Mechanism Handling - Call-Level Interface Version 2

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

Call-Level Interface Version 2
Release Number
October 2021
English (United States)
Last Update

To relieve users of the necessity of supplying a mechanism name for every connect request, a default mechanism can be used instead. This mechanism name may be supplied at either the client or the server. The specified mechanism must appear in both the client and server lists of supported mechanisms. If there is no match, the default mechanism is not be eligible for use.

A client-supplied default mechanism will take precedence over a server-supplied default mechanism. The default attribute is specified in the XML-based mechanism list that resides on both client and server platforms.

A server default mechanism must always be supplied. The presence of a default mechanism does not prevent users from using an alternative mechanism (provided the mechanism occurs in both the client and server lists of supported mechanisms).

An application-supplied mechanism name (if supplied) is preferred to the client default mechanism (if one exists), which is preferred to the server default mechanism. In all cases the chosen mechanism must exist on the client and the server for a successful connection, otherwise an error (CLI507) will be returned.

CLIv2 will place the name of actual mechanism used into the logmech_name field of the DCBAREA. It will be available to the application after control has been returned from DBCHCL (DBFCON).

If a mechanism has been tagged as disabled in either the client- or server-based XML configuration file, it will be ignored (default or otherwise). The server side config file must contain one and only one default mechanism. The client side config file may or may not contain a default mechanism; if it does, there can only be one default mechanism.