Registry Entries for Clients Running Windows NT

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.

Registry Entries for TPName on Clients Running Windows NT

TPName:REG_MULTI_SZ
The name of the transaction program (TP) that is executed. A TP name is up to 64 ASCII characters in length and cannot contain spaces or nulls.

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).

Registry Entries for the TPName Subtree on Clients Running Windows NT

OtherDependencies:REG_MULTI_SZ:SnaBase
For a TP running as a service, ensures that the SnaBase service will be started before the TP is started. This entry belongs under the Linkage subkey.
SNAServiceType:REG_DWORD:{ 0x5 | 0x6 | 0x1A }
Indicates the type of TP. Use a value of 0x5 for an autostarted queued TP, 0x6 for an autostarted nonqueued TP, and 0x1A for an operator-started TP.

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.

PathName:REG_SZ:path
For an autostarted TP running as an application, specifies the path and file name of the TP. The data type of REG_EXPAND_SZ means that the path can contain an expandable data string; for example, %SystemRoot% represents the directory containing the Windows NT system files. Note that for a TP running as a service, an equivalent entry is inserted by the CreateService call; no additional path entry is needed.
LocalLU:REG_SZ:LUalias
Specifies the alias of the local LU to be used when this TP is started on this computer.
Parameters:REG_SZ:ParameterList
Lists parameters to be used by the TP. Separate parameters with spaces.
Timeout:REG_DWORD:number
Specifies the time, in milliseconds, that a RECEIVE_ALLOCATE will wait before timing out. Specify number in decimal; the registry editor converts this to hexadecimal before displaying it. The default is infinity (no limit).
ConversationSecurity:REG_SZ:{ YES | NO }
Indicates whether this TP supports conversation security. The default is NO.
AlreadyVerified:REG_SZ:{ YES | NO }
Indicates whether this TP can be invoked with a user identifier and password that have already been verified. AlreadyVerified is ignored if ConversationSecurity is set to NO. The default value is NO.

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.

Username1:REG_SZ:Password1
...
UsernameX:REG_SZ:PasswordX
Sets one or more user names and passwords to be compared with those sent by the invoking TP. The user name and password can each be as many as 10 characters. Both parameters are case-sensitive.

This variable is ignored if conversation security is not activated or if the password has already been verified, as described for the AlreadyVerified entry.