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

Chapter 6. Accessing IMS Connect 88

been configured to send the message to the appropriate IMS; or IMS shared message queue

support has been enabled. The examples are only two of several possibilities that can be

explored:

1. In the first example, the IMS Connect user message exit is enhanced to verify that the IMS

system, as defined by the datastore ID, is available. If the target IMS is available the exit

makes no changes to the destination. If not, the exit can implement a fail-over solution by

routing the message to another IMS system with an active status.

2. If an IMS Connect system can reach multiple IMSs, it is up to the client program to specify

a target datastore ID. This can be an unwieldy requirement to impose on client

applications. This example provides a generic resource capability. The client programs

are written to specify a generic datastore ID, IMS, that is intercepted by a user message

exit and then changed to a valid value that is marked active in the datastore table.

Additionally, the exit can implement a load balancing algorithm such as a round-robin of

the requests.

The IMS Connect user message exits, therefore, provide an interface that enables a creative

programmer the opportunity to code a solution that answers both failover and load balancing

needs. Refer to IMS Version 9: IMS Connect Guide and Reference, SC18-9287, for more

information about the datastore table and the user message exits.

6.10 Retrieving output messages

The next area of consideration for IMS Connect is the retrieval of output messages. There are

two supported application commit protocols that a remote application can use when

communicating with IMS Connect that control not only the interaction with IMS but also

impact how output messages are to be treated:

 Send-then-commit (CM1)

Remote applications that specify the use of this protocol in the IRM_F2 flag are written to

send an input message and wait for the output reply on the same connection. The IOPCB

reply messages using the CM1 protocol are sent prior to sync point processing. This type

of interaction is easily incorporated into the load balancing, sysplex distribution, and so on,

environment. IMS Connect simply delivers the output message to the waiting remote

application using the same connection that was established on the inbound request.

 Commit-then-send (CM0)

Remote applications can also use the alternative CM0 protocol to send and receive

messages. If the remote application chooses to wait for a reply, the IOPCB message is

delivered as a result of the completion of IMS sync point processing on the same

connection that was used for the input message. However, as documented in Chapter 2,

“Open Transaction Manager Access” on page 7, IMS Connect also supports

asynchronous or unsolicited output from IMS using the CM0 application protocol. The

output messages, either those resulting from ALTPCB calls or any IOPCB replies that

were not delivered to a waiting application, are maintained in a special hold queue in IMS

until a remote TCP/IP application sends a special RESUME TPIPE request to IMS

Connect to retrieve the message.

The CM0 output messages in IMS are queued to a message queue construct that is

identified by Tmember and Tpipe and, therefore, associated with a specific IMS Connect

instance. As a result, there is a potential consideration when using any of the load

balancing or sysplex distribution mechanisms. To retrieve the message, the remote

program will need to establish a connection through the appropriate IMS Connect to the

actual IMS system that queued the message. This can be a challenge because there is no

easy mechanism for a remote program to discover the required connection path, that is, a