.logmechおよび.logdataの情報の検査を可能にし、これらの修正の可能性を考慮する一連の新しいユーザー出口に加えて、これまでのネットワークCLIv2ユーザー出口も、引き続きサポートされます。 新しい出口では、現存のインプリメンテーションにおいて、さらなる柔軟性と改良が提供されます。 詳細は、CLI出口関数を参照してください。
dbchqep.hでの変更
#define QEPIALM 32
DBCHQE呼び出しでこの項目が選択された場合、CLIv2は対応するメカニズム名の一覧を返します。 これは、QEPIACSクエリーと同様に作動します。 すなわち、新しいQEPフィールドは追加されず、QEPTOKENが渡され、返された情報は、4バイトのトークン、返されなかったログオン メカニズム名の数を示す2バイト カウント、返された同名の数を示す2バイト カウント、それぞれの名前を示す2バイト長、および、ゼロまたは複数の名前と、これらの関連フラグで構成されます(メカニズムあたり16バイト)。 返されたメカニズムの順序は関連性がなく、呼び出しの間に変化する可能性さえあります。
有効なTDPid(メカニズム名)がDBCHQEに渡された場合、クライアントおよびサーバーがサポートするメカニズムのリストから、共通部分が返されます。 TDPidポインタに0が含まれている場合、クライアントでサポートするメカニズムのリストのみが返されます。
何らかの理由でメカニズムが返されなかった場合、エレメントが0(NULL)のリストが返されます。
8バイトのメカニズム名のほかに、フラグが1つ返されます。 このフラグは、関連メカニズムがデフォルトの場合は‘D’、その他の場合はブランクとなります。
デフォルトとして識別されるメカニズムは、1つのみです。
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;
何らかの理由でメカニズムが返されなかった場合、エレメントが0(NULL)のリストが返されます(すなわち、DBCHQE (QEPIALM))の最初の呼び出しに対する返信に基づき、qeralmNRとqeralmNPの両方が0となります)。
同クエリーは、利用可能なメカニズムのリストを表示して(例: ドロップ ダウン ボックス)ユーザーが選択できるよう、GUIアプリケーションで使用されます。 さらに、アプリケーションは同クエリーの項目を使用して、CLIv2に.logmech項目、.logdata項目、またはその両方が含まれているかどうかを判定します。
QEPIALMの場合、qepRALenの最小値は26です(sizeof(QEPLMINFO) + sizeof(QEPLMITEM))。
CLIv2がQEPIALMクエリーをサポートしていない場合、DBCHQE(QEPIALM)呼び出しでCLI355 (QEPITEM)エラーが返されます。
TTU 8.0以降において、クライアント アプリケーションでデータ暗号化の有無を判定する場合は、QEPIALMとQEPIENC DBCHQEのクエリー項目両方を使用する必要があります。 これらのクエリー項目は、いずれも単独では、データ暗号化の可用性を判定するために必要とならず、また十分ではありません。
データの暗号化は通常、QEPIENCで‘Y’が返され、さらにQEPIALMで1つ以上のメカニズムが含まれるリストが返された場合に利用できます。 データ暗号化が利用可能かどうかを検証するのは、クライアント アプリケーションの責任ではありません。データ暗号化が利用できない時に、データ暗号化のリクエストを開始するよう試みた場合、CLIv2がエラー(CLI500 NOENCRYPTION)を返します。