Generation of distributed processing based on OSI TP

The following KDCDEF statements are provided for generating the communication partners of an application and the connections to these partners:

Statement	Function
ABSTRACT-SYNTAX	Define the abstract syntax for the user data: assign a unique object identifier assign the transfer syntax for data transfer
ACCESS-POINT	Define the name and address of the local OSI TP access point: define the application entity qualifier (AEQ) of the local application (address component of the application entity title)
APPLICATION-CONTEXT	Define the application context for communication with the partner application: assign the abstract syntax for the user data assign a unique object identifier
LTAC	Assign local TAC names for services in the partner application, under which these services are then started locally
MASTER-OSI-LPAP	Define the name and properties of the master LPAP in a OSI-LPAP bundle (see "OSI-LPAP bundles")
OSI-CON	Define connections between the local application and the remote partner and assign these to the OSI-LPAP partner: specify a local OSI TP access point specify the network address of the partner application
OSI-LPAP	Define an OSI-LPAP partner as the logical access point for the partner application: specify the application entity title (i.e. APT and AEQ) of the partner application specify the application context of the partner application define the number of (parallel) connections to the partner and the names of these connections define the number of connections to be established automatically when the application is started define the number of connections for which the local application is to act as the contention winner define the access rights of the partner application in the local application define the administration authorization level of the partner application define maximum values for the message queue of the OSI-LPAP partner define the status of the OSI-LPAP partner on connection setup if necessary, make the OSI-LPAP a slave LPAP of a OSI-LPAP bundle and specify the associated master LPAP If necessary, specify whether asynchronous messages to the OSI-LPAP partner that are deleted as they could not be sent due to a permanent error are saved in the dead letter queue.
TRANSFER-SYNTAX	Define the transfer syntax for data transfer: assign a unique object identifier
UTMD	Define global values and the address of the local UTM application: define the application process title (APT) (address component of the application entity title) define the maximum waiting time for establishing an association define the maximum waiting time for confirmation of asynchronous messages
The following additional parameters are available on Unix, Linux and Windows systems:
MAX XAPTPSHMKEY	Define an authorization key for the XAPTP shared memory segment.
MAX OSISHMKEY	Define an authorization key for the OSS shared memory segment
MAX OSI-SCRATCH-AREA	Define the size of the working area for dynamic data storage

To allow for communication based on the OSI TP protocol, you must perform the following steps:

• Generate the application entity title (AET)

  The statement UTMD...,APPLICATION-PROCESS-TITLE= is used to define the application process title (APT) as the address component of the AET for your application. A remote partner that requires AETs must know this APT in order to establish a connection.

  The application entity title is assigned to the OSI-LPAP partner. In the OSI-LPAP statement, use the APPLICATION-PROCESS-TITLE= operand to specify the APT and the APPLICATION-ENTITY-QUALIFIER= operand to specify the AEQ of the access point for the partner application. The AEQ must already be generated for the access point in the remote partner application.

  Using the statement ACCESS-POINT...,APPLICATION-ENTITY-QUALIFIER=, define the application entity qualifier (AEQ) as the address component of the AET for the access point of the local application. A partner application must know the AEQ of the access point via which communication takes place with the local application.

  The following applies to UTM cluster applications:If you specify an APT with less than 10 elements in the UTMD statement for an OSI-TP link then UTM adds an index (1, 2 etc.) to the APT generated for each node application. This guarantees that the AET is unique. You are therefore recommended to generate no more than 9 elements in UTM cluster applications.

• Define the application context for communication with the partner application

  If you do not wish to work with one of the default application contexts listed in section "OSI terms", you can generate the application context to be used for communication with the partner application using the APPLICATION-CONTEXT statement. This involves assigning defined abstract syntaxes and a unique object identifier to the application context.

  The ABSTRACT-SYNTAX statement serves to specify the abstract syntax used for the transfer of user data and to assign a unique object identifier to this abstract syntax.

  The transfer syntax (which defines how the user data is to be encoded and decoded for data transfer) is also defined using the ABSTRACT-SYNTAX statement. The transfer syntax is identified by means of a unique object identifier.

• Define an access point to the OSI TP services for your UTM application, so that your application can be addressed during communication based on OSI TP.

  The ACCESS-POINT statement is used to specify the address of the access point within the local system, and to assign a symbolic name for addressing the access point in the local UTM application.

  The address defined in ACCESS-POINT must be unique within the UTM application and within the local system (on BS2000 systems for each host). When defining the access point address, you must therefore consult your system or network administrator.

  A partner application that wishes to communicate with the local application on the basis of the OSI TP protocol identifies the local UTM application using the access point address and the network address of your system. The network address of the access point must be specified when generating the remote partner applications.

  Unix, Linux and Windows systems

  Please note the maximum number of connections that can be established at a time via one access point. For details see ACCESS-POINT statement in section "ACCESS-POINT - create an OSI TP access point".

• Define a logical access point (OSI-LPAP partner) for each partner application and the connections between the local application and partner application

  This involves the definition of an OSI-LPAP statement and an OSI-CON statement. An OSI-LPAP statement must be generated for each partner application. The OSI-CON statement defines the connections between the UTM application and the communication partner. The definition is generated via the two access points (in the local application and in the partner application) between which connections are to be established. The OSI-CON statement is used to specify the network address of the remote access point and the name of the local access point (defined in ACCESS-POINT). The OSI-LPAP statement is used to define the number and names of parallel connections (associations) to the partner application. The address of the remote access point must match that of the access point generated in the partner application.

  If connections are to be established automatically as soon as both communication partners are available (i.e. started), this must be specified when generating both partners. In openUTM, this is achieved using the statement OSI-LPAP...,CONNECT=.

  The partner started last then establishes the connection. With OSI-LPAP...,CONTWIN=, you can also define the number of connections to the communication partner for which the local application is to act as the contention winner.

• Assign local transaction codes to the services of the partner applications, which are then used to address remote services in the local application

  Each of these transaction codes is defined using an LTAC control statement. The transaction code can be assigned uniquely to the partner application via the LPAP partner using LTAC..., LPAP=osi-lpapname. In addition, you must specify the transaction code of the program unit in the partner application using LTAC...,RTAC=. Ask the operator of the partner application for this transaction code. If the name and type of the remote TAC are specified incorrectly, this is not detected by the KDCDEF generation tool, since KDCDEF does not have any information on the configuration of the partner application. The error is not detected until the local application requests this LTAC.

You can also perform the following steps for communication based on OSI TP:

• Define global values for all connections from the application to communication partners

  Using the UTMD statement, you can restrict and define the time spent waiting for confirmation from the communication partner, and specify the total number of jobs submitted to partner applications that can be processed simultaneously in the local application (via OSI TP and LU6.1). By defining appropriate limit values, you can prevent connections from becoming blocked or from being terminated prematurely. You can also ensure that all tasks of the application are occupied by jobs from remote applications. The values defined here also apply for communication based on LU6.1.

• Generate replacement connections

  Replacement connections can be generated by issuing two OSI-CON statements for the same connection. They are used to interact alternatively with various partners without having to take this into consideration in the program units. The two partners may be located in different systems. The replacement connection is generated by assigning two OSI-CON statements with different partner addresses (remote access point addresses) to an OSI-LPAP statement, thereby allocating two different partners to the same logical access point (LPAP partner). However, both connections to the alternative partner applications must not be activated simultaneously. For this reason, ACTIVE=YES may only be specified in one OSI-CON statement. You can switch to the replacement connection to the alternative partner application using the KDCLPAP administration command.

• Define data access control for services of the partner application

  Using the statement LTAC...,LOCK= or LTAC..., ACCESS LIST=, you can secure a partner application service with a lock code. This service is then available locally only to those program units that are running under a user ID (KCBENID) and have been started by a client (KCLOGTER) that have the appropriate authorization.

• Define data access control for services of the local application

  If you wish to restrict a partner application’s access to certain services of the local application, you can secure critical services with a lock code or an access list. With the KSET statement, you can define a key set containing the key codes for services that can be accessed by the partner application. This key set is assigned to the logical access point of the partner application using the statement OSI-LPAP...,KSET=. The partner application can then call only those TACs which are either not secured or for which the partner application has the appropriate authorization.

• Assign administration authorization for TACs of the partner application

  In the OSI-LPAP statement, you can define whether the partner is to be granted administration authorization in the local application. The authorization level is defined using OSI-LPAP...,PERMIT=.

• Assign UTM SAT administration authorization for TACs of the partner application

  Using OSI-LPAP...,PERMIT= you also can define whether the partner is to be granted UTM SAT administration authorization in the local application.

The diagram below summarizes the areas in which the generation of the local application must be coordinated with the generation of the partner application. A standard application context generated by openUTM is used. You must not therefore enter an APPLICATION-CONTEXT statement.

For more information on generating applications with distributed processing, in particular via OSI TP, refer to the example generation „ComfoTravel“ in section "Example generation: ComfoTRAVEL".

Figure 8: Coordination during the generation of OSI TP applications