If two partners wish to communicate with each other, the rules they must observe and the services they must provide have been standardized in the OSI protocol (Open System Interconnection).
ISO (International Organization for Standardization) has also developed the OSI reference model, in which the various communication tasks are distributed over seven layers (instances). The services to be provided by each layer are clearly defined. The seven layers form a hierarchical structure, where each layer can access the services of the underlying layer. These services are made available to the overlying layer at service access points.
During communication, the application accesses the services of the communication system via one of these access points:
If two applications wish to communicate and exchange data, they must be linked via a transport connection. A transport connection can only be established between two addressable units in the network. It must therefore be possible to identify each application by means of an address which is unique throughout the network.
In the OSI world, addresses are assigned to service access points rather than applications. Within the network, the application is thus identified by means of the address of the access point via which it communicates.
Each service access point is assigned an address which is unique throughout the network. This consists of a selector and the address of the underlying access point.
The following diagram shows the format of addresses in the OSI reference model.
Figure 7: Addresses of the service access points in the OSI reference model
In order to communicate with other applications in the network, a UTM application links to a service access point. This link is generated using the ACCESS-POINT statement. The UTM application can then be accessed by its partners in the network via the address of this access point.
The format of the access point address via which the application is accessed depends on the access point hierarchy. If the UTM application communicates on the basis of OSI TP, it links to an access point to the services of layer 6. The address of the access point in the local system consists of the transport selector (selector of the transport layer), the session selector (selector of the session layer), and the presentation selector (selector of the presentation layer). The network address of the access point thus comprises the network address of the system and the address of the access point in the local system.
The selectors of the individual layers must be unique in the local system. The system address is unique throughout the entire network. When defining the access point address, you must consult your network administrator.
The selectors consist of octets. An octet is a byte (8 bits) in which the bit numbering and thus the order in which bits are transferred is fixed.
Order of bit transfer in an octet
It is possible to establish several parallel connections (also known as associations) to a certain communication partner. All connections to a remote partner are generated in a single OSI-CON statement. The OSI-LPAP statement can be used to define the number of parallel connections to a particular partner. Each individual connection must be assigned an association name, which is unique throughout the local system. The names of associations with a remote partner are also generated in the OSI-LPAP statement.
Each connection between two partners is managed by one of the partners. This partner is known as the contention winner, while the other partner is referred to as the contention loser. Jobs can be initiated by both partners. If both partners submit a job at the same time, priority is given to the contention winner. The contention winner of a connection should be the communication partner that starts jobs most frequently.
If several parallel connections exist between two partner, it is not necessary to define which partner is the contention loser and which partner is the contention winner for each connection. You simply specify the number of connections for which the individual partners act as the contention winner (OSI-LPAP statement). The partner that starts jobs most frequently should be defined as the contention winner.
openUTM supports TPSU-title (Transaction Processing Service User). This is an OSI TP user which provides certain services within an application. In openUTM this is the sequence of program units which form a service. A TPSU-title is a unique name within the application. In openUTM it is the TAC name of the first program unit of a service. The initiating TPSU-title is the TPSU-title of the job submitter and the recipient TPSU-title is the TPSU-title of the job receiver.
openUTM supports the application entity title (AET) defined by ISO. This is required if you are working with transaction management (commit functional unit), or if a heterogeneous partner requires an AET in order to establish a connection. In openUTM, the AET is specified for information purposes, but it is not used for addressing the partner.
The application context to be used for communication purposes must be defined for each remote partner with which the UTM application wishes to communicate via the OSI TP protocol.
The OSI terms application entity title and application context are described in further detail in the following sections.
Application entity title (AET)
In the OSI world, communication partners are represented by application entities. An application entity is an addressable unit in layer 7 of the OSI reference model (application layer). An example would be the access point of a UTM application, via which an OSI TP communication partner can link to the UTM application. In the OSI TP standard, each application entity is assigned an application entity title, which can be used to uniquely address the application entity in the OSI network.
The ISO standard defines two forms of AET: the directory form and the object identifier form. The latter is supported by openUTM. This is required if you are working with transaction management (commit functional unit), or if a heterogeneous partner requires an AET in order to establish a connection. In the case of homogeneous communication between UTM and UTM, the AET is also specified, but is not used for addressing the partner. It consists of two parts:
the application process title (APT)
the application entity qualifier (AEQ)
Application process title (APT)
The APT is used to identify the application. In accordance with the ISO standard, it must be unique globally (i.e. worldwide). For this reason, it should be assigned and registered by a standardization body, e.g. in Germany this is the Deutsche Gesellschaft for Warenkennzeichnung GmbH (DGWK = Germany company for registering trademarks).
An APT in object identifier form consists of up to 10 components:
(component1,component2,...,component10)
Some of the values for component1 through component10 have been standardized. Here, symbolic names have been assigned to certain numbers. The value range for component2 depends on the value for component1. The table below lists the symbolic names and value ranges supported by openUTM:
component1 |
|
|
|
component2 |
|
| |
Value range: | Value range: | Value range: | |
component3 | Value range: | Value range: | Value range: |
The APT specified in openUTM need not be assigned by a standardization body, i.e. it is freely selectable. However, it must meet the following two requirements:
it must be unique within the network
it must contain permitted values, as shown in the table above
Application entity qualifier (AEQ)
The AEQ identifies an access point within an application. You can only assign AEQs to the access points of an application if you have assigned an APT to the application itself.
The AEQ is a positive integer between 0 and 67108863.
The AEQ must be unique within the application, i.e. the application must not contain two access points with the same AEQ. However, it is not necessary to assign an AEQ to all access points in the application.
When there are parallel associations and a connection is being established, the AEQ is checked to see if it is the same one as used for the first association established.
Application context
The application context to be used for communication purposes must be coordinated with each partner application with which your local application wishes to communicate via the OSI TP protocol.
The application context must be explicitly defined for each partner application. It determines the rules governing the transfer of messages between the local application and partner application. openUTM supports the following predefined application contexts:
UDTAC
UDTDISAC
XATMIAC
UDTCCR
UDTSEC
XATMICCR
If you are not using one of the application contexts listed above you can use the APPLICATION-CONTEXT statement which is described the section "APPLICATION-CONTEXT - define the application context" to generate further application contexts.
All the involved partners must agree the following when using an application context:
An abstract syntax, which defines how the user data is encoded for transfer. By default, openUTM supports the following abstract syntaxes:
UDT (Unstructured Data Transfer)
XATMI
CCR
UTMSEC
See also the ABSTRACT-SYNTAX statement in section "ABSTRACT-SYNTAX - define the abstract syntax".
A transfer syntax, which defines the format in which the user data is transferred. By default, openUTM supports the transfer syntax Basic Encoding Rules (BER).
See also the TRANSFER-SYNTAX statement in section "TRANSFER-SYNTAX - define the transfer syntax".
Both communication partners must generate the same abstract syntaxes as the application context used for communication. If the application context generated locally is not identical to that generated in the partner, openUTM rejects any attempts to establish the association with a corresponding message.
You only need to use the ABSTRACT-SYNTAX, TRANSFER-SYNTAX and APPLICATION-CONTEXT statements if you are not using any of the standard application contexts made available by openUTM.