Network CLIv2 User Exits | Analytics Database (SQL Engine) - Network CLIv2 User Exits - Call-Level Interface Version 2

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

Call-Level Interface Version 2
Release Number
January 2024
English (United States)
Last Update
Product Category
Teradata Tools and Utilities

The existing network CLIv2 user exits continue to be supported in addition to a new set of user exits that allow for the inspection and possible modification of .logmech and .logdata information. These new exits offer additional flexibility as well other improvements over the extant implementation. For more information, see CLI Exit Functions.

Changes to dbchqep.h

#define QEPIALM 32

When this item is selected for a DBCHQE invocation, CLIv2 will return a list of supported mechanism names. It will operate similarly to the QEPIACS query. That is, no new QEP fields will be added, QEPTOKEN will be honored, and the returned information will consist of a 4-byte token, a 2-byte count of the number of logon mechanism names not yet returned, a 2-byte count of the number of logon mechanism names returned by this query, a 2-byte length of each name, and zero or more names and associated flags themselves (16 bytes per mechanism). The order of returned mechanisms is irrelevant and may even vary between invocations.

If a valid TDPid (machine name) is passed to DBCHQE, then intersection of the list of client- and server-supported mechanisms will be returned. If the TDPid pointer contains 0, only a list of client-supported mechanisms will be returned.

If no mechanism(s) can be returned for whatever reason, a list consisting of 0 (that is, null) elements will be returned.

In addition to the 8-byte mechanism name, one flag will be returned. It will be set to ‘D’ if the associated mechanism is the default mechanism; otherwise, the flag will contain a blank.

Only one mechanism will be identified as the default mechanism.

typedef struct QEPLMINFO_ {
   UInt32 qeralmTk; /* Token, !should not modified by application*/
   UInt16 qeralmNR; /* Number of mechanisms not returned */
   UInt16 qeralmNP; /* Number of mechanisms returned */
   UInt16 qeralmLn; /* Length of each mechanism name plus flags */
                   /* Variable part follows in QEPAREA */

typedef struct QEPLMITEM_ {
    char    mech_name[8];
    char    default_flag;             /* 'D' if default, blank otherwise */
    char    generate_cred_from_logon; /* 'Y' or 'N' */
    char    ci_bypass_support;        /* 'Y' or 'N' */
    char    future_use[5];            /* reserved for future use and alignment */

If no mechanism(s) can be returned for whatever reason, a list consisting of 0 (that is, null) elements will be returned (that is, both qeralmNR and qeralmNP will be zero upon return from the first invocation of DBCHQE (QEPIALM)).

This query item can be used by GUI applications that want to display a list of available mechanisms (for example, a drop down box) for a user to select. Also, applications can use this query item to determine whether CLIv2 can accommodate .logmech items, .logdata items, or both.

For QEPIALM, the minimum value for qepRALen is 26 (sizeof(QEPLMINFO) + sizeof(QEPLMITEM).

CLI355 (QEPITEM) error will be returned from the DBCHQE(QEPIALM) call if CLIv2 does not support the QEPIALM query.

For TTU 8.0 and earlier, client applications that want to determine whether data encryption can be employed should use both the QEPIALM and QEPIENC DBCHQE query items. Neither of these, by themselves, is necessary and sufficient for determining the availability of data encryption.

Data encryption is generally available if QEPIENC returns ‘Y’ and QEPIALM returns a list of one or more mechanisms. It is not incumbent upon the client application to verify data encryption availability; CLIv2 will return an error (CLI500 NOENCRYPTION) if an attempt is made to initiate a request with data encryption when data encryption is not available.