LTERM pools

A particular number of LTERM partners with the same logical properties are defined for an LTERM pool as logical connection points for clients. Clients with the same technical properties (partner and processor type) can connect to a UTM application via these LTERM partners. The assignment only applies for the duration of a session; there is no static assignment between a client and an LTERM partner.

An LTERM pool must be configured in a TPOOL statement (in place of LTERM/PTERM statements). In addition, in the same way as for a single connection, a BCAMAPPL statement may be necessary, see "Connecting clients via LTERM partners". The settings in the MAX statement are also valid for LTERM pools, see "Connecting clients via LTERM partners".

Various types of LTERM pools can be configured:

• LTERM pools via which only clients of a particular type (PTYPE=), located on a particular processor (PRONAM=), can connect to a UTM application.

• LTERM pools, via which clients of a particular type can connect to a UTM application, regardless of the processor on which they reside (open LTERM pools).

In UTM applications on BS2000 systems you can also generate the following types of LTERM pools:

• LTERM pools for all terminals regardless of the terminal type, yet located on a particular processor.

• LTERM pools for all terminals regardless of the terminal type and regardless of type of the computer on which it is located.

TPOOL statement in section "TPOOL - define an LTERM pool" The most important properties for LTERM pools are defined with the following operands:

• BCAMAPPL=

  Name of the local application via which the transport system establishes the connection between the client and the UTM application. The name must be defined in a BCAMAPPL statement or using MAX ...APPLINAME=.

• CONNECT-MODE=

  With CONNECT-MODE= you specify if a UPIC client or TS application may connect to the application multiple times under the same name via the LTERM pool.

• KSET=

  Key set of the LTERM pool that uses key codes to define the access rights of the clients which connect to the UTM application via the LTERM pool.

• USER-KSET=

  In UTM applications with user IDs the USER-KSET key set for UPIC clients and TS applications specify limited system access rights (in comparison with KSET). The key set in USER-KSET takes effect when the client does not pass a user ID to openUTM while establishing the connection/conversation or while in the sign-on service.

• LOCK=

  System access control of the LTERM pool, i.e. lock code assigned for all LTERM partners of the pool. The connection is only established if the client signs on to openUTM with a user ID whose key set has the corresponding key code.

• ENCRYPTION-LEVEL=

  For UPIC clients you specify the minimum encryption level that must be maintained on the connection to the client. You can specify trustworthy for the client. See also "Message encryption on connections to clients" for more information on encryption.

• LTERM=

  LTERM prefix from which unique LTERM partner names are created with number LTERM partners of the LTERM pool.

• NUMBER=

  Number of LTERM partners configured for this LTERM pool. This also implicitly defines the maximum number of clients that can connect to this LTERM pool at the same time.

• PRONAM=

  Name of processor which must contain the client connected via the LTERM pool.

• PROTOCOL=

  Specifies if the user services protocol is used or not.

• PTYPE=

  Type of client connected via the LTERM pool.

• LOCALE=

  LTERM-specific language environment that applies to all clients which connect to the application via LTERM partners. This language environment is also used byopenUTM to output messages, as long as no user is signed on.

LTERM pools and subnets

IP address ranges can be defined using the SUBNET statement. These address ranges are referred to as subnets. Each subnet can be assigned to an LTERM pool using a TPOOL statement. All clients which set up a connection to the UTM application from a subnet defined in this way are then allocated to this LTERM pool.

SUBNET statement in section "SUBNET - define IP subnets"  The properties for subnets are defined with the following operands:

• mapped-name

  Local name of the subnet. This name must be specified for PRONAM in the TPOOL statement.

• BCAMAPPL=

  Name of the local application to which the client can establish the connection to the UTM application. This name must be defined in a BCAMAPPL statement or with MAX ...APPLINAME= and specified in the TPOOL statement with BCAMAPPL=.

  The client must use this local application name to connect to the UTM application using a TPOOL linked to a SUBNET statement. This assigns it directly to the subnet and the associated LTERM pool. In this case no name resolution via the DNS takes place.

  When a client from the subnet uses a different local application name for connection setup, the client's host name is determined via DNS, and the host name thus ascertained is used for the assignment to the generated partner.

• IPV4-SUBNET= or IPV6-SUBNET=

  Defines the IPv4 or IPv6 subnet.

Assignment of client to an LTERM pool

For clients that want to connect to an application via an LTERM pool, please note that openUTM only assigns a client to one LTERM pool. When selecting the LTERM pool, openUTM considers it more important to match the processor name than the client type.

The table below shows the sequence in which openUTM attempts to assign a client to the generated PTERMs and LTERM pools. The grayed out rows in the table represent LTERM pools that can only exist in a UTM application on BS2000 systems. but not on Unix, Linux and Windows systems.

Assignment of a client	KDCDEF statements: definition of client		Remark
1.	PTERM	PTYPE=partnertype PRONAM=processorname
2.	TPOOL	PTYPE=partnertype PRONAM=processorname
3.	TPOOL	PTYPE=*ANY  PRONAM=processorname	only on BS2000 systems
4.	TPOOL	PTYPE=partnertype PRONAM=*ANY
5.	TPOOL	PTYPE=*ANY PRONAM=*ANY	only on BS2000 systems

1. When establishing a connection, it is first of all checked whether a PTERM statement exists for the client.
   UTM first searches for a PTERM-entry using the short processor name of up to 8 characters as supplied by the transport system in the connection request. If no matching PTERM-entry can be found, then UTM retrieves the long processor name of the communication partner from the transport system which can be up to 64 characters long, and searches for a PTERM-entry with this long processor name.
   A client that was explicitly generated with a PTERM statement cannot connect to a UTM application via an LTERM pool.

2. If an LTERM pool is generated for the processor name (PRONAM) and type (PTYPE) of a client, this client is assigned to this LTERM pool.
   PRONAM can also be the mapped name of a SUBNET statement if a subnet is generated for the IP address of the client.

3. (only on BS2000 systems) If there is no LTERM pool with the processor name and type of the client, the client is assigned to the LTERM pool with the same processor name and PTYPE=*ANY.
   
   UTM first performs steps 2 and 3 using the short processor name of up to 8 characters as supplied by the transport system in the connection request. If in neither one of the steps 2 and 3 a matching LTERM pool can be found, then UTM retrieves the long processor name of the communication partner from the transport system and repeats the search of steps 2 and 3 with this long processor name.
   
   

4. If no such LTERM pool exists, the client is assigned to an “open” LTERM pool with the same type and PRONAM=*ANY, i.e. all clients of a type can connect to the UTM application, regardless of the processor on which they reside.

5. (only on BS2000 systems) If no such LTERM pool exists either, the client is assigned to an LTERM pool with PTYPE=*ANY and PRONAM=*ANY.

If there is no LTERM pool of this type or if the capacity of the LTERM pool selected by openUTM is exceeded, the connection setup request is rejected.