IMS and the Sysplex Environment

Phase in the following sysplex capabilities (in the following order) to enable IMS to make the most of the sysplex environment:

1. Implement data sharing among multiple IMS DBs within the sysplex. For more information on this topic, see "IMS DB and the Sysplex Environment."

2. Distribute the transaction workload of multiple IMS TMs within the sysplex. This involves distributing connections and transactions. For more information on this topic, see "IMS TM and the Sysplex Environment" on page 474.

IMS DB and the Sysplex Environment

The foundation in using Parallel Sysplex with IMS is the implementation of data sharing by IMS DB. Data sharing allows multiple IMS subsystems to access and update the same IMS databases.

Block-level data sharing means that each IMS server has the authority to access and update all shared data. As many as 255 IMS subsystems on up to 32 z/OS images can share IMS databases. Each IMS has full capability to access and update with integrity.

Figure 27-1 on page 470 shows a data-sharing configuration with four IMS systems running on four z/OS images sharing the same set of IMS databases. Each IMS system has its own database buffer pools. Each IMS reads and updates the databases. To support the integrity requirements, IMS utilizes structures in coupling facilities. A lock structure is used to hold locking information that is shared by the lock managers (IRLMs) used by the IMS systems. Information about database blocks and their locations in the buffer pools is stored in cache structures. These locks are used to maintain the integrity of the buffer pools when an IMS updates a block.

Figure 27-1. Example of Sysplex Data Sharing with Four IMSs

Restrictions:

• MSDBs cannot participate in data sharing. They must be converted to DEDBs.

• GSAM and HSAM databases cannot participate in data sharing.

IMS does not force data affinities on an installation because all IMS data can be shared. A data affinity occurs when some data, such as a database, is not shared (access to the database can only occur from one system). Without data affinities, a transaction or batch process is capable of running on any system. It does not have to be routed to a particular IMS because that is the only one with access to the data.

Dependent Regions and Grouped IMSs in a Sysplex

Outside of the sysplex environment, an application runs with only one control region. You do not move an application from one IMS to another. With Parallel Sysplex you might want this ability, especially for applications executing as BMPs. Use the IMSID parameter in the dependent region to specify to which control region the dependent region will connect. Each IMS has a unique IMSID, which makes moving a dependent region, such as a BMP, difficult. Before you can move the dependent region, you must change the JCL to specify a different IMSID. In Figure 27-2, we want to execute dependent region BMPY (which has IMSID=IMS2 specified) on z/OS3 where IMSID=IMS3 is running. This will not work. The job fails because BMPY is associated with IMS2 (IMSID=IMS2) and you cannot dynamically change the IMSID that is specified in BMPY.

Figure 27-2. Moving a Dependent Region Between IMSs

The IMSGROUP parameter allows IMS to be known by both its IMSID and its IMSGROUP name. All the IMSs must have unique IMSIDs, but they can have the same IMSGROUP name. The IMSs register to this group name using z/OS token services and their own unique IMSID. The BMP has an IMSID equal to the IMSGROUP name. The BMP uses token services to see if there is an IMSID using the "IMS" as an IMSGROUP parameter. In Figure 27-3 on page 472, BMPY is running on the same z/OS with IMS3. It would connect to IMS3. In this way, if IMS2 is not running or that system is very busy, the BMP could be routed to any z/OS that has any IMS in the group.

Figure 27-3. Example of a Dependent Region Running with a Different Control Region

You can use the Program Restart Facility for OS/390 (5655-E14) to easily restart a failed BMP on another IMS system. This further extends the capabilities to use BMPs with Parallel Sysplex. For more information about the Program Restart Facility for OS/390, see "IBM IMS Program Restart Facility for OS/390, V2" on page 449.

Fast Database Recovery

You can use Fast Database Recovery (FDBR) to greatly reduce the effect of the failure of an IMS system on data availability to other IMS systems.

If an IMS system fails, the update locks are retained. They must be kept until the inflight work of the failed system is backed out. Without FDBR, the inflight work is backed out during IMS emergency restart. Locked records cannot be accessed by other IMS systems. These systems do not wait for the release of the locks. Instead, their applications get a lock reject condition when they ask for a lock that is retained for the failed system. This lock reject condition typically causes an application abend. The failure of one IMS system affects the other IMS systems. The IMS systems that are still running do not have access to some data until the inflight transactions are backed out.

FDBR is the solution for the locked records problem. FDBR is an independent region that runs in its own address space. An FDBR region tracks one IMS control region. For maximum effectiveness, the tracking FDBR region should run on a different operating system than where the tracked IMS is running. Figure 27-4 on page 473 illustrates a sample FDBR configuration.

Figure 27-4. Sample FDBR Configuration

In Figure 27-4, IMS A and its FDBR run on different systems. IMS B and its FDBR run on different systems. If z/OS A or IMS A fails, FDBR A backs out all of the inflight work from IMS A. It also releases the retained locks held for the inflight work of IMS A. This allows IMS B to access all of the IMS data.

Tracking is accomplished by implementing either one of the following methods:

• An FDBR and its IMS system join the same XCF group as the IMS that is being tracked. This allows FDBR to be immediately aware when the tracked IMS address space or z/OS terminates.

• FDBR continually reads the tracked IMS's log (OLDS). If IMS abends, its ESTAE routine writes a failure log record (type X'06'). FDBR can read this log record before the IMS address space terminates.

When either of these tracking methods makes FDBR aware of the IMS failure, FDBR restores the databases to the last point of consistency. For full-function databases, this means FDBR backs out inflight units of work. For DEDBs, this means that FDBR invokes REDO processing for incomplete output threads. These are the same actions that emergency restart would take. When these actions are complete, FDBR releases the locks held by the failed IMS, emulating what emergency restart does.

FDBR is much quicker than emergency restart. FDBR does not have to wait for the restart of IMS nor does it have to wait for the loading of the IMS modules. FDBR does not have to wait for the reading of the log except for the last few records. FDBR is much better because it eliminates many of the potential lock rejects and application abends on the surviving IMSs.

Summary of IMS DB and the Sysplex Environment

Higher availability is provided by the data-sharing configuration, which allows work that might otherwise have to wait for the restart of a failed IMS to run on a surviving IMS. FDBR reduces the impact of the failure by monitoring an active IMS and performing dynamic backout or DEDB REDO processing (or both) sooner than an IMS emergency restart would.

Work can run on any IMS in the sysplex data-sharing group because multiple IMSs have access to the same data. Up to 32 z/OS images can be used to provide maximum capacity.

If every IMS can access all the data, then every IMS can process any of the work. This allows an installation to create IMS clones. In fact, a single system definition can be used for all the IMSs. Cloning allows you to distribute the work to the systems that have the capacity to handle it.

IMS TM and the Sysplex Environment

After data sharing is in place, the next logical step in using Parallel Sysplex with IMS TM is the distribution of connections. For VTAM, connections are sessions. For TCP/IP, they are socket connections. Distributing connections is one of the methods for distributing the workload across multiple IMSs and multiple processors. This is known as static distribution. That is, after a user is connected to an IMS, the user remains connected until the connection is broken. Another connection is required to use this method to distribute the workload to another IMS.

Distributing Transaction Workload

To distribute the transaction workload, use one of the following two basic techniques:

• Distribute the logons so that not all users are logged on to the same IMS. Whichever IMS they are logged on to is the one that processes the transaction.

• Distribute the transactions between IMSs after a transaction has been received from the network.

There is a combination whereby users' logons are distributed and the transactions submitted by these users are also distributed after they are entered.

It does not matter where the transaction is processed if you use data sharing.

Distributing Logons Manually

The earliest approach to distributing logons was to tell the end user which IMS to log on to. Some IMS shops might still use this technique. There are several problems with this technique:

• Balancing the logons becomes an administrative responsibility which must be monitored continuously as users come and go.

• As new IMSs join the group, either no users log on to that IMS (because they do not know about it), or the administrator must reassign users to the new IMSs.

• If an IMS fails, users have to be instructed either to wait for it to restart or to log on to another IMS. After a user knows of another IMS, the user might decide arbitrarily to log on to it instead of his primary IMS, defeating the balancing goal.

Distributing Logons Automatically

Distributing logons can be done automatically using several techniques.

For SNA networks, VTAM Generic Resources can be used to dynamically route a logon request to an active IMS. The IMS is chosen based on Workload Manager (WLM) information or the number of users currently logged on. This capability is available with IMS Version 6 and later releases.

Prior to IMS Version 6, logons could be distributed automatically using a VTAM USERVAR exit routine. This exit routine can be used to direct the logon request to one of several IMSs in the group. Although this method is still supported, IBM recommends using VTAM Generic Resources.

For TCP/IP, connection distribution can be accomplished using such tools as Domain Name Server/Workload Manager (DNS/WLM), Interactive Network Dispatcher (IND), or the Sysplex Distributor.

The following sections discuss these techniques.

VTAM USERVAR Exit USERVAR is a VTAM capability that can change the value specified for the VTAM application name in a logon request. USERVAR support includes an optional exit routine. The exit routine can choose from multiple application names. A USERVAR exit routine can be used to route a logon to any IMS that it knows about. But, it might not know of configuration changes or of the availability of any particular IMS in the group. For example, in Figure 27-5 on page 476, if IMS1 fails, the exit routine might continue to route logons to IMS1. Similarly, if IMS4 is added to the configuration, the exit routine might not route any logons to it. A sophisticated routine might be able to modify its decisions, but there is no automatic notification to the routine of changes in the configuration.

Figure 27-5. Example of VTAM USERVAR Exit Routing IMS Logons

VTAM Generic Resources VTAM Generic Resources (VGR) is a service provided by VTAM in a Parallel Sysplex. VGR minimizes the knowledge that an end user needs to log on to one of several like instances of an application, such as IMS. Each instance of an application joins a Generic Resource Group by specifying both the group name and its specific VTAM application name. End users specify the group name when logging on. VTAM selects a member of the group for the session.

Definitions:

• Logging on to a terminal establishes a session with IMS for that terminal.

• Signing on to a terminal identifies a user to IMS.

• Logging off from a terminal ends a session with IMS for that terminal.

• Signing off from a terminal ends an identification of a user to IMS.

Generic Resource Groups are dynamic. When a new IMS opens its VTAM ACB, it joins the group and is a candidate for subsequent logons. When an IMS terminates, it is removed from the group. It is then no longer a candidate for logons.

Information about the members of a group is kept in a coupling facility structure, as in Figure 27-6.

Figure 27-6. VTAM Generic Resources Distributing IMS Logons in a Sysplex

APPC/IMS can use VGR, but the support for this configuration is not built into IMS. This support is provided by APPC/MVS.

There are many benefits of VGR over other techniques for distributing logon requests. Some of these benefits are:

Availability

VTAM knows by looking in the coupling facility structure which IMSs are active. It routes requests only to active IMSs. If an IMS fails, its users can immediately log on again using the same generic name. The users are connected to one of the active IMSs.

Capacity

If another IMS is needed to handle the workload, it immediately becomes eligible for user logons. User procedures do not have to be modified.

Workload Balancing

VTAM attempts to balance logons across the available IMSs. It has two ways of doing this.

• If Workload Manager (WLM) goal mode is used, VGR routes a logon to the system with the most available capacity.

• If WLM goal mode is not used, VGR attempts to balance the number of logons for each IMS system.

You can implement a VGR user exit routine to override the VGR decision.

Web and TCP/IP Connections to IMS

Many installations access their IMS systems using TCP/IP. This includes connections from the Web. Web servers can use many different ways of connecting to IMS. The most typical connection types are:

APPC

If the Web server sends requests to z/OS using APPC protocols, then the connections to IMS can be distributed using APPC/MVS support for VTAM Generic Resources.

TCP/IP Telnet

TN3270 allows 3270-style users to use TCP/IP protocols. The end user is a TN3270 client. The TN3270 client communicates with a TN3270 server using TCP/IP. The TN3270 server uses LU2 (3270) protocols to communicate with IMS through VTAM. VGR can be used with TN3270 servers to provide connection balancing.

TCP/IP Sockets

If the Web server uses sockets, the server can communicate with IMS Connect for z/OS, which communicates with IMS. IMS Connect executes in its own address space. It communicates with its client, in this case the Web server, using TCP/IP socket protocols. It communicates with IMS using the IMS Open Transaction Manager Access (OTMA) protocol. OTMA uses z/OS Cross System Coupling Facility (XCF), which allows programs running in different address spaces, possibly on different z/OS images in the Parallel Sysplex, to send and receive messages from each other. The distribution of connections from Web servers to IMS Connect must be done with TCP/IP socket protocols.

Domain Name Server/Workload Manager (DNS/WLM) can be used in conjunction with TN3270 to distribute the connection requests across multiple TN3270 servers in the Parallel Sysplex. The TN3270 client request goes to one DNS/WLM, which then uses the WLM to decide which TN3270 server should get the connection request. After the DNS/WLM chooses a TN3270 server, it is no longer involved (communications go directly between the TN3270 client and the TN3270 server). The TN3270 server can then use VTAM Generic Resources to distribute sessions across the IMS members. VGR always uses a local IMS if one is available. A local IMS is an IMS that is using the same VTAM as the TN3270 server is using. However, if the TN3270 server is on a z/OS image without an IMS, VGR can send the logon request to an available IMS on any z/OS.

Figure 27-7 illustrates the use of Telnet 3270. The diagram shows four systems:

Figure 27-7. TN3270 Client Connecting to IMS

• One system (in the upper portion of the diagram) consisting of a DNS/WLM, a TN3270 Server, and an IMS

• The other three systems in the Parallel Sysplex being second copies of the DNS/WLM, TN3270 Server, and IMS

The second DNS/WLM in the diagram is a backup for the first (in case the first one fails).

While the configuration illustrated in Figure 27-7 provides good connection balancing, it is fairly expensive, in CPU usage, to establish and terminate the connection. Therefore, this is not a good configuration for connections that are short term.

The Interactive Network Dispatcher (IND) can be used to distribute connection requests from a Web server to one of several IMS Connect address spaces in the Parallel Sysplex. IND is much more efficient than DNS/WLM at handling connection requests, but requires a separate hardware box (such as an IBM 2216 router) and so can be more expensive. IMS Connect then sends work to one of several IMSs using XCF services and IMS OTMA, as is illustrated in Figure 27-8.

Figure 27-8. IND Connecting to Multiple IMSs through IMS Connect

In Figure 27-8, both IMSs can be reached through either instance of IMS Connect. Exit routines in IMS Connect can be used to choose which IMS the request is sent to. These routines can access information that describes which IMSs are currently active.

The network dispatching function of IND is included in IBM WebSphere Edge Server. There are WebSphere Edge Servers for Linux, AIX, Windows, and Sun Solaris.

A better product for both long and short connections is the Sysplex Distributor, which is part of the z/OS Communications Server. The Sysplex Distributor is software that runs on the host system and distributes sockets across multiple target systems. Like DNS/WLM, a backup Sysplex Distributor can be running on another z/OS image in the sysplex.

The example in Figure 27-9 on page 481 uses multiple instances of IMS Connect. Input messages go through the Sysplex Distributor. Responses do not go through the Sysplex Distributor. In Figure 27-9, the responses go directly from IMS Connect to the Web Server.

Figure 27-9. Web Connections to IMS Using the Sysplex Distributor and IMS Connect

Distributing Transactions

After the connections are distributed within the sysplex, the next step in using Parallel Sysplex with IMS TM is the distribution of transactions. This involves processing a transaction on a system other than the one that initially received the input message.

The techniques used to distribute connections from users across IMS systems might not balance the workload. Several possible causes are:

• A large batch workload on one system might overload it. Users who are already connected to that system remain connected to it. Their response times could be affected by this overload.

• The volumes of inputs from connected users might vary. This could result in peak loads on one system while another system has a lull in inputs.

• Other factors could also cause unbalanced workloads across the systems.

The techniques to address this imbalance involve distributing transactions to other IMS TM systems.

When you distribute transactions, an input transaction can be routed from one IMS to another for processing. There are two methods of doing this in IMS.

Multiple Systems Coupling (MSC)

With MSC, multiple IMS systems are connected by communication links. An IMS system can send a message across one of these links to another IMS. The receiving system processes the transaction and sends its reply to the original system. The original system sends the reply to the user.

IMS Shared Message Queues

With shared queues, IMS systems share one set of message queues. They are stored in list structures in coupling facilities. Any IMS system can process a transaction because the queues are available to all the IMS systems. It is a "pull" implementation. Those with more processing capacity tend to process more transactions.

With either of these implementations, a user can be connected to any system and have an input message processed on another IMS system. In some cases, input messages from these connections must be processed by the system where the connection exists.

Routing Messages with MSC

As illustrated in Figure 27-10, MSC is comprised of VTAM sessions between multiple IMS systems. When an IMS transaction is received by any IMS, its definitions determine where that transaction is to execute. The transaction might be processed locally (on the IMS system that receives the transaction). However, the transaction might be processed remotely (on another system). If the transaction is defined to run remotely, the IMS system that receives the message sends it to the remote system.

Figure 27-10. VTAM Sessions of Three IMSs Connected Using MSC

MSC can be used to distribute transactions across multiple IMSs. The definitions are static. An IMS makes its decision about whether or not to process a transaction based on the transaction code. This decision is not dynamic. Decisions are not based on workloads. It is relatively difficult to add a new IMS system to the complex. A new IMS system requires changes in the definitions for the other existing IMS systems.

MSC definitions can be used to distribute the workload, but they do not balance the workload. MSC definitions in a shared-queues group are subsumed by the shared queues, and workload balancing is automatic.

A link failure or an IMS failure can mean that a transaction cannot be processed until the failure is corrected.

MSC users can include MSC exit routines to override the definitions of where transactions are processed. This adds some dynamic capabilities to MSC routing. The IBM IMS Workload Router (WLR) for z/OS (product number 5697-B87) provides a set of these exit routines.

The IBM IMS Workload Router for z/OS (WLR) uses MSC directed routing to distribute transactions across multiple IMSs without regard to how they have been defined. For example, if TRANA is received at IMS1, it can be processed on IMS1, IMS2, or IMS3. The WLR can be directed to process a certain percentage of transactions locally and to send others to remote IMSs. This provides some workload balancing capability.

Related Reading: For more information about the IMS Workload Router product, see the IBM IMS Workload Router for z/OS User's Guide.

Distributing Transactions Using Shared Message Queues

IMS TM is a queue-driven system. Transaction input messages can be received from terminals or programs. Output messages can be sent to terminals or programs. All of these messages are placed in message queues.

In conventional (non-shared queues) systems, each IMS has its own set of queues; see Figure 27-11 on page 484. These queues are accessible only by the IMS system that owns them. When MSC is used, one IMS sends a message from its queues to another IMS system, which places the message in its queues. In any case, a message can be processed only by the IMS system on whose queues it resides.

Figure 27-11. A Single IMS with a Single Message Queue

With shared queues, the message queues are moved to list structures in coupling facilities where they are available to any IMS in the shared-queues group. See Figure 27-12 on page 484. A terminal is connected to one IMS system. Input messages from the terminal are placed in the shared queues. They are accessible from any IMS using those queues. This means that another IMS system, not the one to which the terminal is connected, can process the input message.

Figure 27-12. Two IMSs Accessing One Message Queue on a Coupling Facility

All messages (input and output) go into the shared queues. IMS subsystems register interest in specific queues, such as the queue for transaction TRANA or for terminal TERMX. An IMS system registers interest for queues it can process. This includes the queues for the terminals connected to it and the transactions that are defined to it.

When there is work on a registered queue, the IMS systems that have registered interest in the queue are notified. When an IMS has the resources available to process the transaction, such as an available dependent region, it attempts to read a message from the shared queue. If it receives a message, it processes it and puts the response back on a shared queue. Multiple IMSs can attempt to retrieve messages from a queue, but only one will receive an individual message. Terminal output messages are retrieved from the queue by the IMS to which the terminal is connected. This IMS sends the output message to the terminal.

Only those IMS systems with available resources ask for and process the transaction because any IMS can process a shared-queues message. This tends to distribute the workload to the systems best able to handle it. Those systems with the most free resources ask for work most frequently.

By using shared queues, the application workload is balanced dynamically. If there is any processing capacity available anywhere in the shared-queues group, queued transactions are scheduled and processed. The user is not forced to wait because a single IMS is overloaded.

Shared queues can also be used in conjunction with connection balancing provided by VTAM Generic Resources or one of the techniques used for TCP/IP.

Summary of IMS TM and the Sysplex Environment

In a Parallel Sysplex environment, you can take advantage of multiple capabilities:

• VTAM Generic Resources provides connection balancing for SNA sessions. It improves availability for users connected via VTAM and makes it easy to add new systems without changing user logon procedures.

• The various TCP/IP distributors provide connection balancing for TCP/IP users. The distributors provide improved availability for these users and make it easy to add capacity for systems with these users.

• The IMS Workload Router provides workload balancing capabilities for users of conventional queueing.

• Shared queues provide:

  - Dynamic workload balancing by allowing an IMS system with available capacity to process any transaction in the shared-queues group.

  - Availability benefits by allowing any active IMS to process transactions when another IMS fails or is stopped. Capacity is easily added because modifications to the previously existing IMS systems are not necessary.