Network CLIv2 User Exits - Call-Level Interface Version 2

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

Product
Call-Level Interface Version 2
Release Number
17.00
Published
June 2020
Language
English (United States)
Last Update
2021-04-19
dita:mapPath
xen1544831946512.ditamap
dita:ditavalPath
obe1474387269547.ditaval
dita:id
B035-2418
lifecycle
previous
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 */
}QEPLMINFO;

typedef struct QEPLMITEM_ {
   char mech_name[8];
   char default_flag;  /* ‘D’ if default, blank otherwise */
   char future_use[7]; /* reserved for future use */
} QEPLMITEM;

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 above, 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.