LTERM bundle

With a LTERM bundle (connection bundle) you distribute queued messages to a logical partner application equally among several parallel connections. The logical partner application can comprise several instances of the partner application (e.g. a UTM cluster application). This type of distribution may make sense when a UTM application sends a very large number of queued messages to a partner application, possibly leading to the overloading of one transport connection.

You define a LTERM bundle using LTERM and PTERM statements as already described in the section "Connecting clients via LTERM partners". The following text describes the additional points you must note to work with LTERM bundles.

A LTERM bundle consists of one master LTERM and several assigned slave LTERMs. The slave LTERMs, which must be assigned using PTERM with PTYPE=APPLI or PTYPE=SOCKET, are assigned to a master LTERM through generation.

Figure 10: Example of a LTERM bundle

FPUT/DPUT calls

FPUT calls sent by program units to the master LTERM are assigned to one of the slave LTERMs at the end of the transaction:

• openUTM first attempts to find a slave LTERM whose PTERM is connected. If openUTM cannot find such a connection, then it searches for a slave LTERM that was generated with RESTART=YES.

  If openUTM finds a slave LTERM, then all queued messages sent in this transaction to this master LTERM are assigned to the slave LTERM.

• If openUTM cannot find such a slave LTERM, then all asynchronous messages sent to the master LTERM are rejected.

• If a slave LTERM is generated with RESTART=NO and the connection is cleared or lost, then all messages pending output on this LTERM are rejected.

Program units can also send FPUT and DPUT calls directly to the slave LTERMs. However, these messages are not subject to the distribution algorithm described above.

Information displayed in the KB header

Messages can also be received through the slave LTERMs of a LTERM bundle. In services started for received messages, openUTM always displays the name of the LTERM through which the message was received in the KB header. The following therefore applies for LPAP bundles:
In services started for messages received through a slave LTERM, the name of this slave LTERM is displayed in the KB header and not the name of the master LTERM.

With the aid of the KDCS call INIT PU you can obtain information on whether the LTERM in the KB header is the slave of an LTERM bundle as well as the name of the master LTERM (see the openUTM manual „Programming Applications with KDCS”).

LTERM statement in section "LTERM - define an LTERM partner for a client or printer" In addition to the properties for LTERM partners already listed (see "Connecting clients via LTERM partners"), the following operands must also be specified for LTERM bundles:

• BUNDLE=

  Specifies the corresponding master LTERM in the definition of a slave LTERM. The master LTERM specified her must have been generated in a preceding LTERM statement:

  LTERM master , ...

  LTERM slave1 , BUNDLE= master , ...
LTERM slave2 , BUNDLE= master , ...

  PTERM slave1 , LTERM= slave1 , PTYPE=APPLI|SOCKET, ...
PTERM slave2 , LTERM= slave2 , PTYPE=APPLI|SOCKET, ...

• RESTART=

  Determines how queued messages are handled when the connection to the client is cleared. Messages pending output on a LTERM that were generated with RESTART=NO may be rejected if necessary (see "FPUT/DPUT calls").

All LTERM parameters of slave LTERMs except for ltermname, USER, QAMSG, RESTART, and STATUS must match the same parameters of the master LTERM. Otherwise they will be overwritten by KDCDEF using the data specified in the master LTERM. No message is output in this case.

When assigning the asynchronous messages to a slave LTERM at the end of a transaction, the QAMSG and RESTART settings are evaluated on the slave LTERM.

All slave LTERMs in a LTERM bundle should be generated identically. KDCDEF does not check this, though.

PTERM statement in section "PTERM - define the properties of a client/printer and assign an LTERM partner" In addition to specifying the properties for physical clients already listed (see "Connecting clients via LTERM partners"), the following operands must also be specified for the PTERMs assigned to the slave LTERMs in a LTERM bundle:

• PTYPE=APPLI | SOCKET

  All PTERMs in a LTERM bundle must be generated with PTYPE=APPLI or PTYPE=SOCKET. The same PTYPE must be specified here for all PTERMs in a LTERM bundle.

• USAGE=D (BS2000 systems only)

  All PTERMs in a LTERM bundle must be generated with USAGE=D.

All PTERMs in a LTERM bundle should address the same partner application or a partner application of the same type. KDCDEF does not check this, though.