When generating two applications that are to communicate using the LU6.1 protocol, you should proceed as described below.
LPAP and SESCHA statements
First you must decide whether the two applications are to be sending jobs to each other on an equally regular basis, or whether one of the applications is to be sending jobs more frequently than the other.
In the first scenario, both applications must be generated with two LPAP statements each; in the second scenario the applications require one LPAP statement each. In this case, that LPAP statement that is designed to send more jobs than it receives is generated with SESCHA ...,CONTWIN=NO; the corresponding LPAP in the partner application is generated with SESCHA ...,CONTWIN=YES. When you have two LPAP statements in an application, one should be generated with SESCHA ... ,CONTWIN=NO and the other with SESCHA ...,CONTWIN=YES.
LPAP statement in section "LPAP - define an LPAP partner for distributed processing based on LU6.1"
The following operands can be used to define an LPAP partner as the logical connection point for the partner application.lpapname
LPAP partner name; this is the logical name of the partner application via which the program units of the local application and the partner application communicate. lpapname is only significant in the local application.
SESCHA=
The session characteristics for communication between local application and partner application as defined under sescha_name in the SESCHA statement are assigned to the LPAP partner.
PERMIT=
Specifies the level of authorization (right to carry out administration and preselection functions) of the partner application.
QLEV=
Specifies the maximum number of asynchronous messages that are permitted to wait in the Message Queue of the LPAP partner.
DEAD-LETTER-Q=
Specifies whether asynchronous messages to the LPAP partner that are deleted as they could not be sent due to a permanent error are saved in the dead letter queue.
STATUS=
This defines whether the partner application is able to work with the local application immediately the local application is started, or whether the administrator must first set the status to ON.
BUNDLE=
Makes the LPAP a slave LPAP of an LU6.1-LPAP bundle and specifies the associated master LPAP.
SESCHA statement in section "SESCHA - define session characteristics for distributed processing based on LU6.1"
You can use the following operands to define the session characteristics that are to be assigned to one of the LPAP partners and therefore to the partner application that connects via this LPAP partner.sescha_name
Defines the name under which the session characteristics are collected. This name is entered in the LPAP statement in the operand SESCHA= to assign the session characteristics to a LPAP partner.
CONTWIN=
Specifies whether the local application is the contention winner (NO) or contention loser (YES). The contention winner application manages the session and controls the utilization of the session by jobs.
Default: If PLU=N, the local application is the contention loser, otherwise it is the contention winner.
PLU=
Specifies which application is able to initiate the session, or in other words, whether the partner application is the primary logical unit (PLU) (YES) or the local application (NO).
PLU=Y must be specified for one of the participating applications, and PLU=N for the other.CONNECT=
Specifies whether the local application is to connect automatically to the partner application on application startup (YES) or whether the connection to the partner application is to be carried out by means of an administration command (NO).
Example
Application A sends jobs to Application B via LPAP B1 and application B sends jobs to application A via LPAP A2.
Application A:
Application B:
LPAP B1, SESCHA=B1
SESCHA B1, CONTWIN=NO, PLU=YES
LPAP B2, SESCHA=B2
SESCHA B2, CONTWIN=YES, PLU=NOLPAP A1, SESCHA=A1
SESCHA A1, CONTWIN=YES, PLU=NO
LPAP A2, SESCHA=A2
SESCHA A2, CONTWIN=NO, PLU=YESBCAMAPPL statements
The next thing to do is to specify how many parallel connections are to be generated between two LPAPs. In accordance with the number you specify, the BCAMAPPL statement is used to generate additional transport system endpoints for both applications. Only one connection may be established between each transport system endpoint and the transport system endpoint of the partner application. Should, for example, nine parallel connections be generated between two LPAPs, then at least three BCAMAPPL statements will be required on each side.
If two LPAPs to the partner application are generated in an application, the BCAMAPPLs of this application should be split into two disjunct groups. The first LPAP communicates using just the BCAMAPPLs of the first group, and the second LPAP uses the BCAMAPPLs of the second group.
BCAMAPPL statement in section "BCAMAPPL - define additional application names"
The following operands are used to define an additional application name for parallel connections to the communication partner.appliname
Additional (BCAM) name of the UTM application.
T-PROT
Specifies the transport protocol.
NEA is the default for BS2000, RFC1006 is the default for Unix, Linux and Windows systems.
If an application communicates with several partner applications, the BCAMAPPLs used to communicate with the one application may also be used to communicate with the other applications.
CON and LSES statements
It is then necessary to assign one CON and one LSES statement to each LPAP statement for each parallel connection via this LPAP. Each CON and each LSES statement must be generated in each of the participating applications and both of these generations must correspond to each other.
Thus:
Each CON name in the one application corresponds to a BCAMAPPL name in the other application and vice versa.
Each LSES name in the one application corresponds to an RSES name in the other application and vice versa.
CON statement in section "CON - define a connection for distributed processing based on LU6.1"
The following operands can be used to assign the LPAP partner in the local application to the real partner application.remote_appliname
Name of the partner application with which communication is to take place via the logical connection.
BCAMAPPL=
Refers to a name of the local application as specified in the control statement MAX or BCAMAPPL. You cannot specify a BCAMAPPL name for which a T-PROT=SOCKET has been generated.
LPAP=
Name of the LPAP partner application to which the connection is to be established. The name of the LPAP partner via which the partner application connects must be defined using the statement LPAP lpapname.
Specifying several CON statements with the same lpapname allows you to generate parallel connections to the partner application.PRONAM=
Name of the partner computer.
The CON statements that are used to describe the connection to the partner application in the local application and the connection to the local application in the partner application refer to the same connection. CON statements must therefore always be entered in pairs. When using parallel sessions, several CON statements are generated for an LPAP partner.
In the example, the assignment is made between the LPAP partner B1 (as generated in application A) and the LPAP partner A1 (as generated in application B):
LSES statement in section "LSES - define a session name for distributed processing based on LU6.1"
The following operands can be used to agree the same session names for the connection and assign them to the LPAP partner.local_sessionname
Name of the session in the local application.
RSES=
Name of the session in the partner application.
LPAP=
Name of the LPAP partner that is assigned to the partner application.
local_sessionname is used for communication with the partner application that is assigned to the LPAP partner lpapname in the local application.
Session names are agreed in the local application and partner application. LSES statements must therefore always be entered in pairs. Since the session name is assigned to the LPAP partners, the LPAP partner assignment defined in the LSES statement must be identical to that defined in the CON statements.
If two LPAP partners are assigned to each other, the LSES and RSES names agreed in the LSES statements must match (see example below). In the case of parallel sessions, several LSES statements are entered with different session names for an LPAP partner lpapname.
The previous example can now be extended as follows.
Example
Application A: Application B: BCAMAPPL A11BCAMAPPL A12LPAP B1, SESCHA=B1SESCHA B1, CONTWIN=NO, PLU=YESBCAMAPPL B11BCAMAPPL B12LPAP A1, SESCHA=A1SESCHA A1, CONTWIN=YES, PLU=NOCON B11, BCAMAPPL=A11, LPAP=B1CON B12, BCAMAPPL=A11, LPAP=B1CON B11, BCAMAPPL=A12, LPAP=B1CON B12, BCAMAPPL=A12, LPAP=B1LSES SESA11, RSES=SESB11, LPAP=B1LSES SESA12, RSES=SESB12, LPAP=B1LSES SESA13, RSES=SESB13, LPAP=B1LSES SESA14, RSES=SESB14, LPAP=B1CON A11, BCAMAPPL=B11, LPAP=A1CON A11, BCAMAPPL=B12, LPAP=A1CON A12, BCAMAPPL=B11, LPAP=A1CON A12, BCAMAPPL=B12, LPAP=A1LSES SESB11, RSES=SESA11, LPAP=A1LSES SESB12, RSES=SESA12, LPAP=A1LSES SESB13, RSES=SESA13, LPAP=A1LSES SESB14, RSES=SESA14, LPAP=A1BCAMAPPL A21BCAMAPPL A22LPAP B2, SESCHA=B2SESCHA B2, CONTWIN=YES, PLU=NOBCAMAPPL B21BCAMAPPL B22LPAP A2, SESCHA=A2SESCHA A2, CONTWIN=NO, PLU=YESCON B21, BCAMAPPL=A21, LPAP=B2CON B22, BCAMAPPL=A21, LPAP=B2CON B21, BCAMAPPL=A22, LPAP=B2CON B22, BCAMAPPL=A22, LPAP=B2LSES SESA21, RSES=SESB21, LPAP=B2LSES SESA22, RSES=SESB22, LPAP=B2LSES SESA23, RSES=SESB23, LPAP=B2LSES SESA24, RSES=SESB24, LPAP=B2CON A21, BCAMAPPL=B21, LPAP=A2CON A21, BCAMAPPL=B22, LPAP=A2CON A22, BCAMAPPL=B21, LPAP=A2CON A22, BCAMAPPL=B22, LPAP=A2LSES SESB21, RSES=SESA21, LPAP=A2LSES SESB22, RSES=SESA22, LPAP=A2LSES SESB23, RSES=SESA23, LPAP=A2LSES SESB24, RSES=SESA24, LPAP=A2
Notes
In the case of applications with distributed processing, the length value specified in the statement MAX...,RECBUF=(number,length),... may have to be increased. Further information can be found in section "Restart area".
The behavior of an application can be influenced by the choice of timer (operand IDLETIME= of the SESCHA statement, operands CONCTIME and PTCTIME of the UTMD statement).