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

Chapter 6. Accessing IMS Connect 87

After H1 is reactivated, dynamic VIPA takeback begins. Again, this is nondisruptive to existing

connections. H2 sends its connection information to H1 so that it can rebuild its table and

resume its activities.

In this environment, the only time that remote clients see a connection failure is when the

back-end host running IMS Connect fails. This is because that host is the terminating point of

the failure. Failures of other hosts or stacks, including the distributing stack, are transparent.

When a connection failure is received, the remote client can immediately resend a new

connection request. As long as an IMS Connect is active on a listening port, the request can

be satisfied.

6.9 IMS Connect load balancing and failover

After a message destination has been resolved to a particular host system and IMS Connect,

the next set of configuration decisions deals with connectivity between IMS Connect and the

IMS systems in the sysplex. IMS Connect can be partnered with a single IMS, or it can be

given access to several as shown previously in Figure 6-1 on page 78.

When provided with access to multiple IMS systems, code can be added to the IMS Connect

user message exits to perform load balancing and failover. The code to do this has to be

user-written unless the environment includes a product such as IMS Connect Extensions

(5655-K48) that provides an interface that facilitates this capability. Regardless of whether

code has to be written or a product is used, IMS Connect provides a datastore table that

keeps track of the status, active or inactive, of all the IMS systems that are defined in the

HWSCFG file. The table is updated as events occur, such as whenever a member of the

group, IMS, or IMS Connect joins or leaves. When a message reaches IMS Connect, the

appropriate user message exit is invoked. All user message exits have access to the

datastore table and can take action based on the information. Figure 6-9 describes two

possibilities.

Figure 6-9 Using the datastore table

Be aware that the examples in Figure 6-9 assume that the input messages can be accepted

by any of the IMS systems. In other words, the systems are cloned and data sharing is

implemented; or an IMS routing mechanism such as Multiple Systems Coupling (MSC) has

can take action to reroute

message to an active IMS

on the list

HWS (ID=IMSCONN,RACF=Y)

TCPIP (HOSTNAME=TCPIP,RACFID=IDX,PORTID=(5000),EXIT=(HWSIMSO0,HWSSMPL0)

DATASTORE (ID=IMSA,GROUP=IMSXCF,MEMBER=ICONN1,TMEMBER=IMSA)

DATASTORE (ID=IMSB,GROUP=IMSXCF,MEMBER=ICONN2,MEMBER=IMSB)

DATASTORE (ID=IMSC,GROUP=IMSXCF,MEMBER=ICONN3,TMEMBER=IMSC)

IMS Connect

Message exits

input msg for IMSA

IMSA - inactive

IMSB - active

IMSC - active

Datastore table

IMSA

IMSB

IMSC

1.

input msg for a

generic name IMS

IMSA - active

IMSB - active

IMSC - active

action is to

round-robin requests

across the active IMSs

IMSA

IMSB

IMSC

IMSA - 5 , IMSB - 8, IMSC - 2

optional table to

keep track of usage

2.

HWSCGF00

action is to send the

request to the next

IMS in the list

IMS Connect

Extensions

(5655-K48)

OR