You are currently on IBM Systems Media’s archival website. Click here to view our new website.

MAINFRAME > Administrator > IMS

Bringing IMS and SOA Together With IMS Connect

New requirements for IMS Connect functionality could make implementing an SOA environment with IMS easier and more flexible.

New requirements for IMS Connect functionality could make implementing an SOA environment with IMS easier and more flexible.

Commit Mode Selection

CM1 requests are synchronous transactions and flow over a logical OTMA connection called a tpipe identified by the IMS Connect port number that the client uses. All of the IMS Connect clients connected to the same port use the same OTMA tpipe.

CM0 requests are asynchronous transactions. Each IMS Connect client uses a separate, dedicated OTMA tpipe that’s identified by the client’s ID. When many IMS Connect clients use CM0, it results in many OTMA tpipes, which can potentially exhaust the virtual storage used by the IMS control region. Limit the number of OTMA tpipes by specifying a maximum number of sockets on which IMS Connect can accept connections.

When IMS uses shared queues there are additional considerations when the client chooses a commit mode. IMS shared queues allow transactions submitted to a front-end IMS system to be processed on a back-end IMS system. Using Resource Recovery Services (RRS) multisystem cascaded transactions (MSCT), CM0 doesn’t require RRS MSCT to run on back-end IMS systems in a shared-queues environment.

Asynchronous Output of the Send-Only Protocol

The IMS Connect send-only protocol, which maximizes input capacity for high-volume transaction processing, returns all output to the asynchronous hold queue. If an IMS Connect client that uses the send-only protocol requires asynchronous output to be queued in the order that the input was received, steps should be taken.

First, to ensure that IMS starts processing each message in the order it was received, the client must send all of its ordered input to the same IMS datastore. Second, the client can specify either send-only with ACK or send-only with serial delivery.

The send-only with ACK protocol forces the client to wait for an ACK response before sending the next message; however, this reduces the rate at which the client can input new messages, decreasing the rate of input.

The send-only with serial delivery protocol ensures that IMS receives the input messages in the same order that IMS Connect received them. In this case, the client must also specify SCHDTYP=SERIAL on the IMS transaction definitions.

Asynchronous Output Among Multiple Instances of IMS Connect

The tpipe hold queue used to return asynchronous output can be accessed only by the IMS Connect client for which it was created. If the IMS Connect client is unavailable to retrieve the output from its hold queue, that output can’t be retrieved.

To eliminate the risk of stranded asynchronous output, asynchronous output can be shared by enabling the OTMA super member feature that allows IMS Connect clients to access hold queues of other IMS Connect clients. The OTMA super member function protects against a single point of failure in IMS Connect and the temporary loss of asynchronous output.

IMS Connect Configuration and Security

IMS Connect connects to IMS systems through XCF. Each instance of IMS Connect can define multiple datastore connections to the same or different IMS systems, which is useful when IMS systems are cloned in a sysplex environment, and instances of IMS Connect and the IMS systems are spread across different LPARs.

IMS Connect is responsible for authenticating the user. If needed, IMS OTMA can verify the user’s authority to use input transactions and commands. IMS Connect calls RACF* to authenticate users only when the RACF support is enabled in IMS Connect.

When RACF is enabled, each request from an IMS Connect client must contain a user ID and password or a RACF PassTicket. The authentication call is made to RACF before passing the user ID on to OTMA for authorization. On persistent sockets, the user ID is authenticated for each request, because the user ID can be different on each request.

IMS Connect provides clients with the capability to change the RACF password for a user ID and supports the use of PassTickets. The RACF APPL Class resource used for PassTickets can also be used to control access to that datastore because RACF requires the user to be permitted access.

IMS Connect user message exit routines allow users to define and perform their own security processing and, optionally, define user IDs as “Trusted Users,” which bypasses user-ID authentication.

IMS Connect supports SSL. Only one port can be used for SSL and client certificates are optional. Minimize the overhead of SSL handshakes by using persistent sockets.

Customers can optionally require authorization for the retrieval of asynchronous messages. The authorization is made for each Resume TPIPE request so the use of AUTO or NOAUTO options can reduce the number of authorizations.

IMS OTMA Considerations

When receiving incoming requests from IMS Connect, OTMA performs authorization checking. The security information for each user is stored in a RACF accessor environment element (ACEE) and cached to reduce how often OTMA needs to call RACF.

The frequency with which OTMA refreshes the cached ACEE can affect the transaction throughput. This frequency is controlled by defining the length of time between refreshes. If the length of time is short, then the frequency of calling RACF for a new cached ACEE becomes high. Balance the need of transaction throughput against your installation’s security needs.

The Future of IMS Connect

The IMS organization is actively promoting IMS as a solid participant in any SOA environment. The IMS Connect development team has received requirements for new IMS Connect functionality that could make implementing an SOA environment with IMS easier and more flexible.

The IMS organization is considering a customer requirement to add support to IMS Connect for the IMS Open Database Access interface, which could provide TCP/IP access to IMS databases without having to write IMS transactions. The IMS organization is considering a requirement for a simplified IMS Connect API for roll-your-own IMS Connect client applications, which could speed development of new IMS Connect client application programs.

Ben Johnson is an IBM information developer. He has been writing about IMS since 2003, focusing on both IMS database administration and IMS communications and connections, with a particular interest in OTMA and IMS Connect. He can be contacted at bpj@us.ibm.com.

Dave Cameron is a senior software engineer for IMS development. He can be contacted at daveac@ca.ibm.com.

Jack Yuan is a senior software engineer for IMS development. He can be contacted at jackyuan@us.ibm.com



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Bringing IMS and SOA Together With IMS Connect

New requirements for IMS Connect functionality could make implementing an SOA environment with IMS easier and more flexible.

Celebrating 40 Successful Years

IMS version 10 supports synchronous and asynchronous callout

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters