When generating UTM applications that are to communicate using the LU6.1 protocol, you must bear the following information in mind.
In each application, either one or two LPAP statements and the appropriate SESCHA, CON and LSES statements must be generated for each of the partner applications.
Only one LPAP statement is required for a partner application if only one of the two applications is to be sending jobs. However, if both applications are intended to send jobs to the partner application, then both applications will require two LPAP statements.
An LPAP that is used mainly to send jobs is generated in its SESCHA statement using CONTWIN=NO; this ensures that the local application becomes the contention winner for this LPAP. The corresponding LPAP in the partner application must then be generated with CONTWIN=YES.
For each connection/each session, one CON or one LSES statement must be generated in each of the partner applications.
For each CON statement, the CON name and the BCAMAPPL name in the one application must correspond to the names in the partner application.
In the same way, for each LSES statement, the LSES name and the RSES name of the one application must correspond to those in the partner application.In the case of standalone applications, the same number of CON and LSES statements must be generated for each LPAP; the number of CON or LSES statements determines the number of parallel connections to the partner application that are possible via this LPAP. Other rules apply to UTM cluster applications on Unix, Linux and Windows systems, see "Special issues with LU6.1 connections".
All CON and LSES statements of an LPAP must address the same partner application and must also be assigned to a single LPAP name in the partner application. It is not permitted to generate several CON statements leading to different applications for one LPAP name.
It is also not permitted to generate several CON statements for a single LPAP which are assigned to different LPAP statements via the corresponding CON statements in the partner application.
This generation error cannot be recognized by openUTM, but will lead to errors during connection or session establishment and during session restart.
In order to establish several parallel connections between two applications, a UTM application opens several transport system end points at the transport system. Each transport system end point of a UTM application is generated using its own BCAMAPPL statement.
Unix, Linux and Windows systems
Please note the maximum number of connections that can be established at a time via one transport system end point. For details see BCAMAPPL statement in section "BCAMAPPL - define additional application names".
Figure 5: Two applications with several transport connections
In the example above, A and B are the names of the applications as specified using the MAX APPLINAME= statement; B1 and B2 are defined using separate BCAMAPPL statements.
Terminals are able to establish connections to application A using the application name A and to application B using the application name B. But application A is able to connect to application B using the application names B, B1 or B2.
BS2000 systems
From the network administration point of view, the UTM application B consists of several BCAM applications. BCAM administration commands for one of the application names have an effect on the entire UTM application B. So in other words, a BCAPPL APPLICATION=B,MODE=DEACTIVATE command not only terminates UTM application B, but also signs the applications B1 and B2 off from BCAM.
Between two given transport system end points of both applications only a single transport connection can be established. If two transport system end points are generated in one of the applications and three in the other, then up to six parallel connections can be established between the two applications.
If both a contention winner LPAP and a contention loser LPAP are generated for a partner application (SESCHA statement), then transport system end points (BCAMAPPL statement) are established via the contention winner connections and should not be used simultaneously for the contention loser connections! This means that both contention winner and contention loser LPAPs are generated in a single application, thus the BCAMAPPLs of this application should be split into two disjunctive groups, where the BCAMAPPLs of the one group are assigned only to contention winner connections and the BCAMAPPLs of the other group are only ever used for contention user connections.