OTMA restrictions and requirements

A number of general restrictions and requirements apply to OTMA.

Restrictions

The maximum total length of all prefixes for an OTMA message is 4096 bytes. This length does not include any application data.

Existing IMS application programs that use SETO calls might not run as expected. APPC/IMS application programs using SETO calls might require modification to use implicit OTMA support.

OTMA does not support the IMS Message Format Service (MFS). However, the MFS message output descriptor (MOD) name can be specified by the client in the prefix of an OTMA message.

OTMA does not support IMS Front-End Switch.

OTMA messages cannot be encrypted.

OTMA has read only access to the main storage data base (MSDB). No update access is available to MSDB from OTMA.

OTMA does not operate in the IMS DBCTL environment.

OTMA does not allow IMS terminal control commands, such as /FORMAT, /HOLD, /RCL, and /SIGN commands.

OTMA restrictions for OpenTelemetry

OTMA does not provide OpenTelemetry support for:
  • Conversational transactions.
  • Fast Path transactions in a shared queues environment if the backend IMS processes the transaction.
However, OTMA provides OpenTelemetry support for:
  • Fast Path transactions in a single IMS (non-shared queue environment) without ESAF.
  • Fast Path transactions processed by the front-end IMS in a shared queues environment without ESAF.

Requirements

IMS conversational and Fast Path transactions must be defined as send-then-commit. Existing Fast Path applications can run with OTMA.

A transaction from an IMS terminal (for example, a SLU 2 terminal) cannot route output directly to a client, but must use an OTMA Destination Resolution user exit (OTMAYPRX).

All user IDs must be verified by RACF® , unless the client specifies no security checking in the security-data section of the message prefix.

IMS modules that contain z/OS® cross-system coupling facility (XCF) macros must be reassembled for new releases of IMS.

OTMA protected conversation messages that are part of the same z/OS Resource Recovery Services (RRS) unit of recovery and that access common database resources must be scheduled and executed on the same IMS system.

IMS shares locks and database buffers between protected conversation transactions, but this support is restricted to within a single IMS system. It does not function across shared queues. You must ensure such messages schedule on the same IMS system.