Resource Recovery Services (RRS)
Article ID: 55758
Updated On:
Products
Issue/Introduction
This KD describes Resource Recovery Services (RRS)
Environment
Release: Datacom
Resolution
Transaction integrity is critical to all applications. It is not a good idea to make data changes (that is, updates, adds or deletes) as part of a complete transaction and then have some of these changes commit and others roll back if the transaction fails before completion. This is true if your update applications are executing against a single Multi-User Facility or if they are executing in a more heterogeneous environment with one or more Multi-User Facilities and other data sources such as DB2, IDMS/DB Database or VSAM.
In the typical Datacom environment where a transaction only runs within a single Multi-User Facility, data integrity is assured using the Log Area (LXX) and the Datacom/DB restart capabilities.
A heterogeneous environment may take three forms. In the first form, a common transaction may perform maintenance on two different Multi-User Facilities. In the second form, the transaction may perform maintenance in Datacom/DB and to another data source such as DB2, IDMS/DB Database, or VSAM. In the third form, it may use both Multiple Multi-User Facilities and other data sources. In these environments, when the transaction issues a commit request, it must know that either all work is guaranteed to be committed across these different Multi-User Facilities and data sources, or that if the transaction fails all work is backed out. Resource Recovery Services (RRS) provides this assurance for batch processing in the z/OS environment.
RRS is a component of the IBM OS platform used for batch application transaction integrity (similar capability has been built into CICS using the CICS Synch point processing).
Each instance of a data source such as a Multi-User Facility or VSAM is called a "resource manager" in RRS. Each transaction has an identifier called the URID which RRS uses to keep track of the transaction. RRS and the resource managers provide transaction integrity using a protocol called two-phase commit, in which each resource manager sees phase one of a commit and votes that it will do the commit. If, once all votes are tallied, it is determined that they are all "yes" votes, RRS sends phase two of the commit in which each resource manager finishes the commit. If a resource manager fails or votes "no" during phase one of a commit, all work in the other resource managers will be backed out and the commit will fail.
Datacom/DB provides a User Requirements Table (URT) parameter on the DBURINF macro of RRS=YES/NO to indicate whether you want maintenance work to interact with RRS. Even though you can always code YES, you should only do so if you are running beyond a single Multi-User Facility, since RRS will be used to manage the commit and rollback process if you code YES, and this will require some additional transaction overhead.
When you use a RRS URT with Datacom and you issue a commit, RRS drives several Datacom/DB exits. The first exit is called a prepare exit. During prepare, Datacom/DB logs to the LXX the phase one with a command of LOGPR and information including the URID and TSN associated with the transaction. The second exit is phase two or commit exit. At this point, Datacom logs a COMIT and commits the work. There is also a back-out exit.
If the Multi-User Facility fails between phase one and phase two, the Datacom/DB restart must query RRS to find out whether the transaction represented by this URID should commit or rollback. RRS in turn has its own log in which it stores the status of each transaction or URID for each resource manager participating in the transaction. Although the window is quite small, the Datacom restart interaction with RRS during a two-phase commit helps to guarantee a transaction's integrity and completeness both within and outside this Multi-User.
In r11 there are two different ways an RRS=YES URT is handled. This is determined by what you specify for the DBURINF URT macro parameter MUFS.
If MUFS=YES is specified and you issue an Datacom/DB commit type request (COMIT, LOGCP, and others), the Multiple Multi-User Facilities interface intercepts the commit and sends it to RRS as an RRS commit. This is true even if you are only interacting with one Multi-User Facility in this application. RRS will then drive the two phase commit process in all Multi-User Facilities connected to this maintenance transaction and any other resource manager connected to this maintenance transaction. This implementation is the simplest from the application program standpoint, since all existing Datacom/DB applications run unchanged. However, you must be aware that work outside of Datacom/DB may be subject to the Datacom/DB commit you issued. Rollback requests are also transmitted to RRS in a similar way.
If MUFS=NO is specified, Datacom/DB does not allow you to issue an Datacom/DB commit or rollback type request if there is outstanding maintenance work in a Multi-User Facility. If you want to issue such request, you must code IBM's Application_Commit_UR which calls RRS to do the two-phase commit. The advantage to this implementation is that this type of commit is unambiguous in that you are clearly asking for a commit across all resource managers, but it may require application changes. Other restrictions exist for RRS=YES and MUFS=NO, so please consult the documentation.
Of course there are some underlying complexities in how all this runs in Multi-User Facility environment when using RRS. These complexities are detailed in the documentation. The important thing to remember is that application transaction integrity in a Multiple Multi-User Facility or multi-product environment can be handled painlessly and completely with the help of RRS.
Feedback
