Resource recovery programs

To understand how to use resource recovery on the z/OS platform, you need to understand both the programs that work together and something of how they work together. First, you need to know what an exit manager is.

An exit manager is an authorized program that controls the flow of a predefined set of events. When a predefined event occurs, the exit manager gives control to an exit routine owned by a program interested in the event. In this exit routine, the program provides the processing for the event. z/OS provides two exit managers: resource recovery services (RRS) and context services.

The following three programs work together to protect resources:

Application program: The application program accesses protected resources and requests changes to the resources.
Resource manager: A resource manager controls and manages access to a resource. A resource manager is an authorized program that provides an application programming interface (API) that allows the application program to read and change a protected resource. The resource manager, through exit routines that get control in response to events, takes actions that commit or back out changes to a resource it manages.
Often an application changes more than one protected resource, so that more than one resource manager is involved.

A resource manager may be an IBM® product, part of an IBM product, or a product from another vendor. There are several types of resource managers; see Types of resource managers.

Note: The resource manager in resource recovery is different from an RTM resource manager, which is related to the operating system's recovery termination management (RTM) and runs during termination processing.
Syncpoint manager: Resource recovery services (RRS) is the syncpoint manager. It uses a two-phase commit protocol, described in Two-phase commit protocol to coordinate changes to protected resources, so that all changes are made or no changes are made. During its processing, RRS drives resource manager exit routines. For example, if a commit event occurs (such as when an application requests changes be made to several resources), RRS drives the commit exit routine for each resource manager involved.

Two other operating system components also play key roles in resource recovery:

Registration services: Registration services coordinates communication between the resource manager and the exit managers. A resource manager must register itself with the system as a resource manager. The resource manager must also set its exit routines with each exit manager; the resource manager identifies the exit manager and the exit routines it provides for resource recovery. Registration services is itself an exit manager, though it drives only one exit routine. There is more information in Using registration services.
Context services: Context services is an exit manager that provides the data constructs and primitives that resource managers can use as an anchor for a given work request to track specific events related to the work request. For example, when a given context ends, context services drives the end-context exit routines for each resource manager involved. There is more information in Using context services.

Registration services, context services, and resource recovery services (RRS) are three separate MVS™ components, but it is sometimes useful to think of them as a single function called recoverable resource management services (RRMS), the z/OS syncpoint manager.

RRMS provides a systems programming interface (SPI) that enables a resource manager:

To register with the system as a resource manager
To express interest in work requests that access its resources
To take part in resource recovery for those work requests

Because RRS provides much of the resource recovery function (syncpoint processing, in particular), technical information, like this book, often uses the term RRS unless specifically describing context services or registration services.

RRS can enable resource recovery on a single system or, with a communications manager such as APPC/MVS, on multiple systems. If the resources used by an application program are distributed, so that they are on multiple systems, a communications resource manager on each system works with the syncpoint manager on that system. The communications resource managers, in cooperation with the syncpoint managers, work together to coordinate the entire set of changes.