Using shared queues with OTMA

This topic describes general information about using IMS shared queues with OTMA.

To ensure delivery of alternate PCB processing, enable OTMA on all IMS systems; assign each IMS system in the shared queue group a unique z/OS® cross-system coupling facility member name.

Use the /DISPLAY TRANS ALL QCNT to view all the OTMA transactions currently in the shared queue group waiting to be processed. Use /DISPLAY QCNT OTMA MSGAGE 0 to view all the OTMA outbound messages on the shared queues.

Note: If OTMA outbound messages remain on a shared queue when the IMS system that was processing them is shutdown normally and then cold started, the outbound messages become stranded on the shared queue and cannot be delivered. However, if a normal shutdown is followed by a warm start, any outbound messages on the shared queue at the time of the shutdown can be delivered.

For OTMA hold-queue capable clients, such as IMS Connect, using the OTMA super member function can ensure that outbound messages do not become stranded on a shared queue and can be delivered to the client.

As the result of a temporary shortage in the HIOP storage pool, you might receive message DFS1269E, which notifies you of an internal IMS failure to register a shared queue resource. To re-register the shared queue resource for OTMA, issue the IMS commands /STOP OTMA and /START OTMA.

In a shared queues environment, IMS removes idle, non-queued, non-synchronized transaction pipes after three system checkpoints.

If you send OTMA ALTPCB messages to a remote IMS system via an IMS-to-IMS TCP/IP connection from the shared-queues environment, the transaction messages can be sent to the remote IMS system only from the IMS system that is directly connected to the IMS Connect instance that is managing the TCP/IP connection.

For OTMA commit-then-send messages in a shared queues environment, a new ITASK under a new OID TCB is created to process the messages, separately from the main ITASK under OIC TCB that is used for other jobs.