Messages sent by OTMA clients

An OTMA client communicates with IMS by sending messages.

First, a user enters application data using a device or program that is connected to the client. Next, the client adds some information (the message prefix) and sends the message to IMS. Output from IMS is sent to the client as a message, and the client uses the message prefix to route the data to the correct device or program.

Parts of the OTMA message prefix

The OTMA message prefix has the following sections:
  • Message-control information

    This section includes the transaction-pipe name, message type, sequence numbers (if any), the time out value for send-then-commit messages, and various flags and indicators.

  • State data

    This section includes a destination override (if any), map name, synchronization level, commit mode, tokens, and server state.

  • Security data

    This section includes the user ID, user token, and security flags.

  • User data

    This section includes any special information needed by the client.

Following the message prefix is the application-data section of the message. This section contains either the data to be sent to IMS for processing or the IMS response.

OTMA message-prefix rules

Because a message can have a single segment or multiple segments, the following rules apply to OTMA message prefixes:
  • Single-segment messages can have the full prefix (message-control information, state data, security data, and user data).
  • Only the first segment of multi-segment messages has the full prefix. Subsequent segments are sent with only the message-control information and application-data sections.
  • Acknowledgment (ACK or NAK) messages sent by IMS only return the first input buffer. This message carries the full prefix, and the application-data section (if it is included in the client request).

Sequence numbers used by OTMA

OTMA uses two types of sequence numbers for messages: send-sequence numbers and recoverable sequence numbers. Send-sequence numbers and recoverable sequence numbers are used differently in OTMA.

Using send-sequence numbers

Send-sequence numbers are used for input and output messages. Send-sequence numbers should be incremented by a client for every input message. When IMS sends output to a client, the send-sequence numbers in the output message are also incremented. The send-sequence numbers are used for all the OTMA input/output messages. The send-sequence numbers in the input messages are also used to identify multi-segments.

For example, there is a two-segment OTMA input message. The first segment message will have send-sequence number=XXX and segment number=1. The second segment message should have the same send-sequence number=XXX and segment number=2. OTMA chains the two-segment message together because the send sequence numbers are the same.

OTMA uses send-sequence numbers in the following ways:
  • All ACK and NAK messages from IMS use the send-sequence numbers submitted by the client on input.
  • All OTMA commands that IMS sends to the client have send-sequence number 0 (zero). And, except for the resynchronization flows, these OTMA commands are all single segment.
  • Send-sequence numbers for IMS error messages and IMS transaction output are set for each transaction pipe. The send-sequence number for a given transaction pipe is incremented by one for each message, and it is never 0 (zero). When the sequence number exceeds 4,294,967,295 (the 32-bit maximum), it is reset to 1.
Using recoverable sequence numbers

Recoverable sequence numbers are used only to control resynchronization. If a client does not support resynchronization, recoverable sequence number=0 (zero). Resynchronization is only valid for synchronized tpipe and commit-then-send input/output. The recoverable sequence numbers are also incremented for every input/output message. Resynch support has an added logic to check if the recoverable sequence numbers are properly incremented. If the sequence numbers are not properly incremented, a NAK is sent. Because the resynch is dependent on the recoverable sequence numbers, the resynch must be correct for every input/output. Recoverable sequence numbers apply to transaction pipes, which use them to control resynchronization.