Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL

Chapter 6: Accessing IMS Connect > Retrieving output messages - Pg. 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: