In addition to transaction-oriented distributed processing, which requires high-level communication protocols, a UTM application can also communicate with applications running directly above the transport system interface without global transaction management. Examples of such applications include the CMX applications on Unix, Linux or Windows systems, DCAM applications on BS2000 systems or any TCP/IP socket applications. On socket connections, UTM supports the HTTP protocol as well as the UTM-specific UTM socket protocol (USP). In the following, socket applications that communicate with the UTM application via HTTP are referred to as HTTP clients (see chapter "Communication with HTTP Clients"), while transport system applications that communicate with the UTM application via USP are referred to as socket USP applications.
Since high-level protocols are not used, support for global transactions cannot be provided when communicating with transport system applications. In this case, openUTM can only provide local transaction processing capability.
In the event of errors in the transport system or an abnormal termination of the UTM application, there is no guarantee that a message sent to another application will be received or processed by the target application. It is thus possible for messages to be lost or duplicated.
The following sections contain some useful information regarding interaction between a UTM application and transport system applications.
Connection establishment
The initiative for establishing a connection may come either from the other application or from the UTM application. When communicating with HTTP clients, the HTTP client always initiates the connection establishment.
Establishing a connection to the UTM application
If the transport system application establishes the connection, then it is signed on to the UTM application using a user ID permanently assigned to the partner, also called the connection ID.
If the UTM application has a user-written sign-on dialog (SIGNON event service, see "System access control (identification and authentication)"), then this dialog is also run when transport system applications (except HTTP-clients) sign on. This sign-on dialog can be used, for example, to assign the transport system application a real user ID for subsequent processing.
Transport system applications can use the “multi-signon” function, i.e. several transport system applications can sign on under the same real UTM user ID at the same time, but only if the service restart functionality is not used for this user ID.
A transport system application can establish several parallel transport connections to a UTM application under the same application name (“multi-connect”).
Processing jobs
A transport system application (not equal to HTTP client) can send both asynchronous and dialog jobs to the UTM application. An HTTP client can only send dialog requests to the UTM application. However, the following conditions must be observed:
The Jobs of a transport system application (not equal to HTTP client) must be submitted in the format expected by openUTM, i.e. the first eight characters of the message must contain the transaction code under which the service to be started was generated for openUTM. This transaction code enables openUTM to determine whether the service is a dialog or asynchronous service.
- Socket USP applications send a byte stream, while openUTM works on a message-oriented base. To enable the UTM application to recognize message boundaries, a socket USP application must use the UTM socket protocol (USP) from which the length of a message can be recognized. The USP allows messages to be sent in several parts, which means that the entire message can be larger than the size of the input buffer. The USP can also be used for output, as well, if you choose.
- HTTP clients also send a byte stream. HTTP clients also send a byte stream that is described by the HTTP protocol. openUTM analyzes the HTTP protocol and transfers the query and the message body of the HTTP request to the user program as message parts. You can use an HTTP exit to split the message into several message parts for a program unit.
In the case of dialog jobs, you must adhere strictly to the dialog format required by openUTM, i.e. the partner application must wait to receive a response from the UTM application before sending the next message.
openUTM does not send any messages of length 0 to transport system applications. Although such messages are not actually sent, they do switch send authorization from one application to the other. openUTM then waits for a message from the transport system application. With multi-step dialogs, it is therefore important to observe the logic of the dialog sequence. In principle it is not possible to send messages with a length of 0 to HTTP clients.
In communication with HTTP-clients and non-socket partners, message lengths are limited by the size of the input/output buffer.
When communicating using the USP protocol, the messages can be fragmented (see the note above on the USP). Only the length of fragments is limited; there is no limit on the length of the entire message.
openUTM does not format messages intended for other applications, i.e. the target application receives the message in the format in which it was supplied to the message area by the program unit.
Automatic code conversion (ASCII-EBCDIC) can be initiated at generation.
Restart capability: if necessary, dialog services can be restarted. During a service restart, the last output message is repeated.
While running a UTM application, messages may occur which refer to the communication partner of the UTM application. Only those UTM messages for which the destination PARTNER was specified in the UTM message module are dispatched to the communication partner. By creating a local message module, this destination can be added to or removed from other messages (see the corresponding openUTM manual ”Messages, Debugging and Diagnostics”). These UTM messages can occur within or outside a dialog. The communication partner must be able to respond to the messages accordingly. To HTTP-clients only messages K017 and K034 are sent, regardless of whether the message target PARTNER has been specified.
If UTM user commands are issued by another application, these are not interpreted by openUTM as commands.
Connection shutdown
The initiative for shutting down a connection may come from the transport system application or from the UTM application. If the connection is to be shut down by the UTM application, this can be achieved either by entering an administration command directly or by using an administration call or a KDCS call (SIGN OFF) from a program unit run. For HTTP clients, UTM closes the connection after each service, if the connection header in the HTTP request is not set to "Keep Alive".
| You will find more information on interconnection with socket-USP-applications in the openUTM manual “Generating Applications”. |
