Chapter 4. IMS connectivity options 107
4.4.1 Local IMS connection in same sysplex: Attributes
Figure 4-6 Local connection in same sysplex: Attributes
A single IMS Connect, as in Figure 4-6, can be configured to support a very high
transaction rate. In this scenario there are two separate IMS systems residing in
different LPARs within the same Sysplex, a combination of local and remote
processing. The local service time will have better response than the remote
because inter-LPAR communication is not involved.
There is a cost to data-sharing with shared message queues. The performance
costs that arise from exercising the Parallel Sysplex functions are variable.
Hardware configurations and workload characteristics, such as the amount of
sharing required by applications, are all factors in the evaluation of the
performance of customer environments.
Tip: A best practice for configuring IMS Connect for multiple IMS instances for
performance is to segregate the ports for each IMS. Do not send the request
for different IMS systems along the same port.
• Single IMS Connect supports a very
high transaction rate
• Cost in using shared data queues
• Shared message queues for IMS and
multiple IMS Connect address spaces
• IMS Connect is a single point of failure
• Thread Identity (RunAs) Identity for
• RACF setting in IMS Connect used
to set authorization.
• User Message Exit can be implemented
for security authentication
• RRS Compliant for 2PC in local LPAR
• XA Compliant for 2PC in remote LPAR
• Uses WebSphere global transaction support
• Shared queues can be used with multiple IMS
108 WebSphere for z/OS Connectivity Architectural Choices
This scenario contains a number of single points of failure. If LPAR1, the
Websphere Application Server in it, or IMS Connect fails, then both IMS systems
For availability, several IMS Connects can be configured to communicate with
multiple IMS systems within a sysplex.
Use shared message queues by using the Coupling Facility list structures. If one
IMS subsystem fails, the rest of the IMS subsystems sharing the message
queues can continue to process work, including any message placed on the
shared queues by the failed IMS subsystem. IMS Connect and the IMS datastore
must be in the same XCF Group in order to communicate.
Websphere Application Server for z/OS allows you to assign a thread identifier
as an owner of a Local connection (IMS1), when you first obtain the connection.
In terms of thread identity we refer to the J2EE Identity, the
RunAs Identity, for
When you use the Local Option and IMS Connect is configured to use RACF, it
will authenticate every request unless the exits are used to enable trusted user
Another means of security verification, other than using RACF password, is
using a PassTicket. You use a PassTicket to authenticate user IDs and log on to
application systems that communicate with RACF. You can select PassTicket
support through an IMS Connect client and send a PassTicket in the IRM in
place of a RACF password.
See 4.8, “IMS security flow: Container-managed” on page 120 for more
Websphere Application Server supports the coordination of resource managers
through their RRS and XA Resource interface and participates in distributed
Note: The IMS Connect User Message Exits provide an interface that
allows you an opportunity to customize a solution for fail-over and load
Refer to the
IMS Connect Guide and Reference Version 2 Release 2,
SC18-7260 for more information on the message exits.