OTMA and IMS-to-IMS TCP/IP communications

Any responses generated by the remote IMS system are queued to a tpipe hold queue in the remote IMS system for asynchronous retrieval.

To define an IMS-to-IMS TCP/IP communications path for OTMA, you must code the following items in the IMS Connect and IMS instances at each side of the connection:

• In the sending IMS Connect, the IMS Connect configuration statements, including the RMTIMSCON statement, which is required for IMS-to-IMS TCP/IP communications, and the DATASTORE statement, which is required for communication between IMS Connect and OTMA.
• In IMS, either the OTMA destination descriptor in the DFSYDTx member of the IMS.PROCLIB data set or the OTMA User Data Formatting exit routine (DFSYDRU0).

Security for the TCP/IP connection can be implemented by using the optional RACF® PassTicket support. Transaction authorization can also be implemented in the IMS system.

OTMA requires the RMTIMSCON statement in only the IMS Connect instance that sends messages on the TCP/IP connection.

OTMA sends transaction messages across IMS TCP/IP connections using commit mode 0 and the send-only with acknowledgment protocol. Any responses generated at the remote IMS system to the OTMA transaction messages are queued to a tpipe hold queue for asynchronous retrieval.

You can define a separate TCP/IP connection to return responses back to their originating IMS system; however, the responses must be sent back to the originating IMS system as new transactions for the originating system and the correlation of responses to their original transaction must be managed by your installation.

In IMS Connect, you can monitor, stop, and restart the TCP/IP connections by using IMS Connect WTOR, z/OS® MODIFY, or IMS type-2 commands.