IMS Connectivity in an On Demand Environment: A Practical Guide to IMS Connectivity

Chapter 2. Open Transaction Manager Access 9

Path transactions, Multiple Systems Coupling (MSC) processing, and IMS commands, can be

implemented with OTMA. OTMA does not support Message Format Service (MFS), although

MODname can be provided within the messages. This MODNAME will be placed in the

IOPCB MODNAME field so that it can be used by the IMS application.

2.2 OTMA message structure

The OTMA client communicates with IMS by sending and receiving messages. It adds the

OTMA message prefix to the input messages and it uses the message prefix to route the

output data to the originating device or program. The OTMA message prefix consists of the

following sections, shown in Figure 2-2:

 Message Control Information (MCI), such as the transaction-pipe name, message type,

sequence numbers (if any), processing flag, response indicator, and chaining indicator

 State data, such as map name, synchronization level and commit mode for the

transaction, various tokens, and server state

 Security data, such as the type of the user information, user ID or user token, and various

security flags

 User data, which is any special information needed by the client, or IMS commands to be

executed

Figure 2-2 OTMA message structure

The message prefix is followed by the application data section of the message, which can be

the data sent to the IMS application, or the response sent to the client.

OTMA headers are written into the IMS log record type X'01' for OTMA input messages and

into the IMS log record X'03' for responses to the OTMA destination. OTMA messages can be

mapped by the DFSYMSG DSECT in IMS.SDFSMAC. For a detailed description of the

message structure, see Chapter 5 IMS Version 9: Open Transaction Manager Access Guide

and Reference, SC18-7829.

The key parameters that affect the nature of the transaction processing and the message flow

are the commit mode, synchronization level, and processing flag. Not all of the combinations

of these parameter values are valid. For example, the synchronization level is ignored for the

commit-then-send commit mode (sync level

confirm is always used), and synchronized

Tpipes can only be used with commit-then-send mode. The send-then-commit mode must be

used for IMS conversational and Fast Path expedited message handling (EMH) transactions.

Here is a brief explanation of these key parameter values:

 Commit mode (synchronization flag in state data portion of the OTMA headers), as shown

in Table 2-1 on page 10

< ------------------------------------ OTMA PREFIX -------------------------->

Message Control

Information

State Prefix Security Data User Data Application

Data