How IMS Uses zOS Services

How IMS Uses z/OS Services

IMS is designed to make the best use of the features of the z/OS operating system. IMS does so by:

• Running in multiple address spaces: IMS subsystems (except for IMS batch applications and utilities) normally consist of a control region address space, separate address spaces for system services, and dependent address spaces for application programs. Running in multiple address spaces provides the following advantages:

  - Maximizes the use of a central processor complex (CPC). Address spaces can be dispatched in parallel.

  - Isolates the application programs from the IMS system code. Doing so reduces outages from application failures.

• Running multiple tasks in each IMS address space: IMS, particularly in the control region, creates multiple z/OS subtasks for the various functions to be performed. Doing so allows other IMS subtasks to be dispatched by z/OS while one IMS subtask waits for system services.

• Using the z/OS cross memory services: IMS uses z/OS cross memory services to communicate between the various address spaces that make up an IMS system. IMS also uses the z/OS CSA and ECSA to store IMS control blocks that are frequently accessed by the address spaces of that IMS system. Doing so minimizes the overhead of running in multiple address spaces.

• Using the z/OS subsystem feature: IMS dynamically registers itself as a z/OS subsystem and uses the z/OS subsystem feature to detect when dependent address spaces fail, thus preventing the cancellation of dependent address spaces through z/OS command entry.

• Using a z/OS sysplex: Multiple IMS subsystems can run on the z/OS systems that make up the sysplex and, therefore, can access the same IMS databases and the same message queue. Doing so provides:

  - High availability: z/OS systems and IMS subsystems can be taken in and out of service without interrupting production.

  - High capacity: multiple IMS subsystems can process far greater volumes than individual IMS subsystems can.

Related Reading: For information about data sharing and shared queues in a sysplex environment, see:

• IMS in the Parallel Sysplex: Volume I: Reviewing the IMSplex Technology

• IMS in the Parallel Sysplex: Volume II: Planning the IMSplex

• IMS in the Parallel Sysplex: Volume III: IMSplex Implementation and Operations

Transmission Control Protocol/Internet Protocol (TCP/IP)

IMS provides support for z/OS TCP/IP communications through a function called Open Transaction Manager Access (OTMA). Any TCP/IP application can access IMS by using OTMA. Examples of such TCP/IP applications are:

• IMS Connect (a function within IMS TM) uses the OTMA interface to connect IMS to Web servers

• CICS

• DB2 UDB for z/OS stored procedures

• WebSphere MQ

Related Reading: For information about OTMA and IMS Connect, see:

• "Open Transaction Manager Access" on page 179 and "IMS Connect" on page 187

• IMS Version 9: Open Transaction Manager Access Guide and Reference

• IMS Version 9: IMS Connect Guide and Reference

Advanced Program-to-Program Communications (APPC)

IMS supports the z/OS CPI-C (Common Programming Interface for Communications) interface, which is based on Logical Unit type 6.2 formats and protocols for program-to-program communication. APPC is an implementation of the LU type 6.2 protocol. IMS's support for APPC is called APPC/IMS.

APPC/IMS enables applications to be distributed throughout an entire network and to communicate with each other regardless of the underlying hardware.

Related Reading: For more information about IMS's support for APPC, see "APPC/IMS and LU 6.2 Devices" on page 185.

Resource Access Control Facility (RACF)

IMS was developed before the introduction of RACF, which is part of the Security Server for z/OS, and other security products. As a result, IMS has its own security mechanisms to control user access to IMS resources, transactions, and databases.

With the introduction of RACF, IMS was enhanced so that it can use RACF (or an equivalent product) to control access to IMS resources. You can use the original IMS security features, the RACF features, or a combination of both.

Recommendation:

Use RACF for security because it provides more flexibility than the IMS security features provide.

Related Reading: For more information about protecting IMS resources, see Chapter 21, "IMS Security" on page 361. For complete information about IMS security, see the security chapter in IMS Version 9: Administration Guide: System.

Resource Recovery Services (RRS)

z/OS includes a facility for managing system resource recovery, called resource recovery services (RRS). RRS is the sync-point manager, which coordinates the update and recovery of multiple protected resources. RRS controls how and when protected resources are committed by coordinating with the resource managers (such as IMS) that have registered with RRS.

RRS provides a system resource recovery platform such that applications that run on z/OS can have access to local and distributed resources and have system-coordinated recovery management of these resources. RRS support includes these features and services:

• A sync-point manager to coordinate the two-phase commit process^[3]

  ^[3] Two-phase commit processing is a two-step process by which recoverable resources and an external subsystem are committed. During the first step, the database manager subsystems are polled to ensure that they are ready to commit. If all subsystems respond positively, the database manager instructs them to commit.

• Implementation of the SAA® commit and backout callable services for use by application programs

• A mechanism to associate resources with an application instance

• Services for resource manager registration and participation in the two-phase commit process with RRS

• Services to allow resource managers to express interest in an application instance and be informed of commit and backout requests

• Services to enable resource managers to obtain system data to restore their resources to consistent state

• A communications resource manager (called APPC/PC for APPC/Protected Conversations) so that distributed applications can coordinate their recovery with participating local resource managers

Related Reading: For more information about how IMS uses RRS, see IMS Version 9: Administration Guide: System.

Parallel Sysplex

A Parallel Sysplex environment in z/OS is a combination of hardware and software components that enable sysplex data sharing. Data sharing means the ability for sysplex member systems and subsystems to store data into, and retrieve data from, a common area of a coupling facility. In short, a Parallel Sysplex can have multiple CPCs and multiple applications (such as IMS) that can directly share the workload.

In a Parallel Sysplex environment, you can run multiple IMS subsystems that share message queues and databases. This sharing enables workload balancing and insulation from individual IMS outages. If one IMS in the sysplex fails or is stopped, others continue to process the workload, so the enterprise is minimally affected.

Related Reading: For more information, see Chapter 27, "Introduction to Parallel Sysplex" on page 467 and Chapter 28, "IMSplexes" on page 495.