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

Chapter 2. Open Transaction Manager Access 19

If all message-switched-to transactions are nonresponse mode or schedule before the CM1

input transaction (or synchronous message-switched-to transaction) ends, there is not a

synchronous transaction scheduled and there is no CM1 output and no DFS2082 message.

In this case, the TIB is orphaned and never deleted (until an IMS cold start).

Conversational transactions

For an input conversational transaction, only the message-switched-to continuation of the

conversation is scheduled synchronously. All other transactions are scheduled

asynchronously.

MSC implications

If a CM1 input message is sent through Multiple Systems Coupling (MSC) to a back-end IMS

and the transaction there does not reply to the IOPCB, there is not a DFS2082 message sent

back to the client.

The OTMA client can hang or time out. The input TIB and ITASK are never freed in the

front-end system and are orphaned.

Shared queues implications

In an IMS shared queues environment for IMS Version 6 and IMS Version 7, CM1 input

transactions must run on the same IMS on which they are received (the front-end IMS

system). For IMS Version 8 and IMS Version 9, CM1 transactions can run on any IMS copy in

the IMSplex (an IMSplex is one or more IMS address spaces that work together as a unit).

IMS Version 9 has a new parameter (AOS=N) that says that CM1 transactions can only run

on the front-end IMS copy (both OTMA and APPC). All of the CM1 IOPCB output is routed

back through the front-end IMS using XCF. RRS is used to coordinate the front-end IMS and

back-end IMS sync point processing.

In an IMS shared queues environment, all message-switched-to transactions from a CM1

input transaction (or synchronous message-switched-to transaction) must run on the same

IMS copy as the original transaction. The only exceptions are IMS conversational

transactions, which can run on any IMS copy in the IMSplex. Message-switched-to

transactions from an asynchronously scheduled transaction can run on any IMS copy.

If a CM1 transaction runs on a back-end IMS copy, a second TIB is built there. If the TIB

becomes orphaned, as described earlier, there are two orphaned TIBs—one in the front end

and one in the back end.

2.4 Implementing OTMA

The OTMA feature is part of IMS Transaction Manager, so it is not necessary to do any

special installation steps for it. You also do not need any IMS system generation

specifications for OTMA.

The following OTMA-related IMS execution parameters can be specified in the IMS startup

procedure or in the DFSPBxxx PROCLIB member:

 GRNAME=

GRNAME specifies the name of the XCF group for OTMA. IMS joins that group during the

startup of IMS or as a result of the /START OTMA command.