IMSplex overview

Connected systems such as Multiple Systems Coupling and replicated systems such as XRF are used in an IMSplex.

An IMSplex can be defined as:

• A set of IMS systems working together to share resources or message queues (or both) and workload.
• A single IMS system using the Common Service Layer (CSL) without the Resource Manager (RM) to have a single point of control. This configuration allows you to use IMS type-2 commands, which can be issued only through the Operations Manager (OM) APIs by an automated operator program (AOP). Optionally, IMSplexes of this type can also include the CSL Open Database Manager (ODBM).
• A single IMS system using the CSL with an RM.

Contrast the description of an IMSplex with a description of a Parallel Sysplex® (hereafter referred to as sysplex). A sysplex is multiple z/OS images working together, connected by a coupling facility. One or more IMSplex systems can be defined on one or more z/OS images; however, you do not have to have an IMS instance on every z/OS image in the sysplex.

The concept of data sharing is important in an IMSplex, specifically in an IMSplex that shares resources and workload.

This allows IMS batch jobs, online applications, or both, to run anywhere in the IMSplex. These batch jobs and applications can also access all of the data in the shared IMS databases. You can distribute your IMS workload according to your business requirements. After data sharing is enabled, you must create a plan for distributing batch and transaction workload across the IMSplex and then implement that plan. One technique is using shared queues (SQ). With SQ, any transaction can be entered from the network to any IMS system in the IMSplex and be executed by any IMS system in a shared-queues group. If one IMS system is unavailable, a different system can handle the work.

If you have multiple IMS systems sharing resources or message queues, administration and operation can be simplified by using the IMS Common Service Layer (CSL), which reduces complexity by providing a single-image perspective. With CSL, you can manage multiple IMS systems as if they were only one system. For example, instead of entering type-1 commands from multiple MTOs or a single point of control (SPOC) to perform local online changes, you can enter a type-2 command from one SPOC to perform global online change. The following figures contrast the relative complexity of managing an IMSplex with and without a CSL.

Managing an IMSplex using CSL provides:

• Improved systems management
• A single-system image
• Simpler operations through a single point of control
• Shared resources across IMS systems

Figure 1. Complex management of an IMSplex without CSL

Figure 2. Simplified management of an IMSplex with CSL

When you manage an IMSplex with the CSL, the resulting environment is comprised of multiple IMSplex components. An IMSplex component either manages resources, manages operations, or facilitates communication among IMSplex components. The following are IMSplex components:

• Operations Manager (OM)
• Resource Manager (RM)
• Open Database Manager (ODBM)
• Structured Call Interface (SCI)
• IMS Connect
• Database Recovery Control (DBRC)
• Common Queue Server (CQS)
• Repository Server (RS)
• TSO Single Point of Control (SPOC)
• REXX SPOC API for automation programs
• Online control regions

Any program that registers with the SCI is considered an IMSplex component. Users and vendors can also write programs that register with SCI; these programs are also considered IMSplex components. Note that batch regions and dependent regions (MPR, BMP, and IFP) are not IMSplex components. Although DBRC code running within a batch region registers with SCI, the batch region itself is not a component. When an IMSplex component is initialized and joins the IMSplex, it becomes an IMSplex member.