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.
SNA service TPs are a special set of TPs defined by the the SNA protocols. Each service TP is a specially-defined function with a special name. An SNA service TP name is represented by up to four EBCDIC bytes; the first byte is a hexadecimal number in the range 0x00 to 0x3F, and the remaining bytes are EBCDIC characters. The first byte defines the function class of the TP. Therefore, to convert a service TP name to an ASCII TP name form, convert the first byte as shown in the following table, and convert the EBCDIC values to ASCII letter equivalents.
| First byte of TP name (hexadecimal number) | ASCII character equivalent for WIN.INI |
|---|---|
| 0x07 | DDM |
| 0x20 | DIA |
| 0x21 | SNAD |
| 0x24 | FS |
| 0x30 | PO |
| All others | UN |
For example, an EBCDIC service TP name of 0x21 0xD7 0xD7 is equivalent to a TP name of SNADPP (0x21 converts to SNAD and each 0xD7 converts to P).
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 (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. |
| ALLOCATE or MC_ALLOCATE in this TP has a security parameter of AP_PGM; as a result, the TP passes along the user_id and pwd values supplied in ALLOCATE or MC_ALLOCATE . | ALLOCATE or MC_ALLOCATE in this TP has a security parameter of AP_SAME; as a result, after confirming the user identifier and password, the TP passes along the user identifier and an already-verified flag. | ALLOCATE or MC_ALLOCATE in this TP has a security parameter of AP_SAME; as a result, the TP passes along the user identifier as received, along with the already-verified flag. |
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.
If you want to have a chain of conversations where the user identifier and password are reverified at every step, carry out the following. For all the TPs, set ConversationSecurity to YES, and in each ALLOCATE or MC_ALLOCATE issued, set the security parameter to AP_PGM and the pwd and user_id parameters to valid combinations.
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.