In a LTERM group you assign one or more LTERMs a connection. The use of LTERM groups is of value if a UTM application is to send queued messages to different partner applications depending on which functional area the message belongs to. In this case, a separate LTERM must be assigned to each functional area in the partner application.
The program units direct their FPUT and DPUT calls to the appropriate LTERM depending on the function. If the partner application to function relationship is 1:1, then each LTERM is assigned one PTERM. If the partner application to function relationship is n:1 and the assignment may change in some cases, then n LTERMs are assigned to one PTERM.
An LTERM group consists of one or more alias LTERMs, called the group LTERMs, and one primary LTERM. You define the group LTERMs using LTERM statements as described in the section "Connecting clients via LTERM partners". Do not assign a PTERM to a group LTERM.
The primary LTERM must be a normal LTERM or the master LTERM of a LTERM bundle. If the primary LTERM is a normal LTERM, then a PTERM with PTYPE=APPLI or PTYPE=SOCKET must be assigned to it. You define the primary LTERM as described in the section "Connecting clients via LTERM partners".
Figure 11: Example of a LTERM group
LTERM groups can also be used in conjunction with LTERM bundles. In this case the primary LTERM is the master LTERM of the LTERM bundle.
Figure 12: Example of a LTERM group in conjunction with a LTERM bundle
FPUT/DPUT calls
FPUT and DPUT calls sent by program units to an alias LTERM are processed as follows:
In a LTERM group without a LTERM bundle:
FPUT and DPUT calls sent to an alias LTERM are sent by openUTM via the PTERM assigned to the primary LTERM.
In a LTERM group whose primary LTERM is the master LTERM of a LTERM bundle:
If FPUT calls are sent to an alias LTERM in this kind of LTERM group, then all queued messages sent in the transaction to alias LTERMs in the group are assigned by openUTM to exactly one of the slave LTERMs at the end of the transaction.
This procedure guarantees that the recipient receives the messages in the same order as they would be generated in a transaction for an LTERM group.
Program units can also send FPUT and DPUT calls directly to the primary LTERM.
Information displayed in the KB header
If the primary LTERM of a LTERM group is not the master LTERM of a LTERM bundle, then messages can also be received via the primary LTERM. In services started for received messages, openUTM always displays the name of the LTERM or LPAP from which the message was received in the KB header. The following also applies to LTERM groups:
In services started for messages received via the primary LTERM, the name of the primary LTERM is displayed in the KB header and not the name of an alias LTERM.
With the help of the KDCS call INIT PU you can obtain information on whether the LTERM in the KB header is the primary LTERM of a LTERM group (see openUTM manual „Programming Applications with KDCS”).
| LTERM statement in section "LTERM - define an LTERM partner for a client or printer" |
GROUP=
Specifies the corresponding primary LTERM in the definition of an alias LTERM. The primary LTERM specified here must have been generated in a preceding LTERM statement:
LTERMprimary, ...PTERMprimary, LTERM=primary, PTYPE=APPLI | SOCKET, ...LTERMalias1, GROUP=primary, ...LTERMalias2, GROUP=primary, ...
Only the generation parameters of the primary LTERM are evaluated for a FPUT or DPUT call.
| PTERM statement in section "PTERM - define the properties of a client/printer and assign an LTERM partner" |
PTYPE=APPLI | SOCKET
The PTERM in a LTERM group must be generated with PTYPE=APPLI or PTYPE=SOCKET.
USAGE=D (BS2000 systems only)
The PTERM in a LTERM group must be generated with USAGE=D.