The following list gives details about Windows NT registry entries for clients running Windows NT. For each TP type, the applicable variables and their locations are shown in Clients Running Windows NT.
Note that the value for an autostarted TP running as a service must be 0x5, because these TPs are always queued, as described in Invokable TPs.
For a diagram of three TPs in a conversation, where the third TP can be invoked with a password that is already verified by the second TP, see Communication Between TPs. The following table shows the requirements for using password verification in a chain of TPs.
First TP (an invoking TP) | Second TP (invokable TP that confirms password and then invokes another TP)
|
Third and subsequent TPs (invokable TPs that invoke other TPs) |
---|---|---|
Does not need registry or environment variables.
|
ConversationSecurity setting must be YES. | ConversationSecurity setting must be YES. |
Does not need registry or environment variables.
|
AlreadyVerified setting can be YES or NO. | AlreadyVerified setting must be YES. |
Symbolic destination name or Set_Conversation_ Security_Type in this TP specifies PROGRAM for the security type; as a result, the TP passes along the user identifier and password supplied in the symbolic destination name (or through calls1). |
Symbolic destination name or Set_Conversation_ Security_Type in this TP specifies SAME for the security type; as a result, after confirming the user identifier and password, the TP passes along the user identifier and an already-verified flag. |
Symbolic destination name or Set_Conversation_ Security_Type in this TP specifies SAME for the security type; as a result, the TP passes along the user identifier as received, along with the already-verified flag. |
Note:
1 Set_Conversation_Security_User_ID or Set_Conversation_Security_Password will overwrite the user identifier and password specified in the symbolic destination name.
If you set AlreadyVerified to NO, this TP cannot join in a chain of conversations where password verification is already done. (The exception to this is when ConversationSecurity is set to NO, in which case the TP could be the final TP in such a chain, since it performs no checking.)
If you are configuring a TP that sometimes needs to confirm a password and sometimes accepts an already-verified flag, set AlreadyVerified to YES and configure the UsernameX variable appropriately. In this case, whenever the TP is invoked without the already-verified flag set, AlreadyVerified is ignored; verification is attempted with the user identifier and password configured for the TP.
The default for AlreadyVerified is NO. If you set AlreadyVerified to YES, make sure that ConversationSecurity is also set to YES.
This variable is ignored if conversation security is not activated or if the password has already been verified, as described for the AlreadyVerified entry.