Remote Resource Manager (RRM)

Products

• Datacom
• DATACOM - AD
• Datacom/AD
• Datacom/DB
• Datacom/Server

Issue/Introduction

This KD describes Remote Resource Manager (RRM) 

Environment

Release: Datacom

Resolution

A previous e-News article dealt with the need for two-phase commit using the z/OS or OS/390 component of Resource Recovery Services (RRS). This two-phase commit is needed to guarantee transaction integrity when maintaining data in multiple data sources, such as multiple Multi-User Facilities (MUFs), or a MUF and another data source (perhaps DB2, IDMS, or VSAM) in a single batch transaction. Before r11 SP1, a Datacom batch application must run on the same system (LPAR) as MUF in order to use RRS. Remote Resource Manager (RRM) allows you to run the application remotely using XCF while still taking advantage of the capabilities of RRD.

To some degree, RRM can be thought of as a small subset of a MUF. Its purpose is to act as the Datacom resource manager that interacts with the local RRS on the system on which the application runs. When your application opens a URT with RRS=YES specified and the DBSIDPR directs the application to a remote MUF using XCF, Datacom will attempt to find and use DBRRMPR using the RRMNAME=parameter specified in the DBSIDPR.

The only time RRM is actually invoked is when the two-phase commit is processed. At that point, RRM uses a new dataset called the WXX to record the start and the progress of the two-phase commit and to provide persistent storage in case a component fails during two-phase commit. The WXX will be very small since these rows only exist for the life of a two-phase commit.

One instance of DBRRMPR can service many applications talking to many remote MUFs on many separate systems. RRM will join each unique remote group on an as-needed basis as it receives two-phase commit requests. Once it joins the group, it remains as a member of the group for the life of RRM.

Once you truly start using RRM, except for rare occasions, you will probably leave it enabled permanently. This is because your remote applications will need RRM in order to interact with RRS, and if there is ever a MUF failure, the MUF restart may need to interact with RRM through XCF to resolve outstanding two-phase commits.

RRM has simple administrative needs. It does require and use the Datacom dataspace to pass information from the application to RRM.

You will have to change your application DBSIDPR and add the RRMNAME= parameter in order to take advantage of RRM.

A multiple MUF application may access both a local MUF and a remote MUF. All local work will ignore RRM. The local part of its two-phase commit processing will be processed through the local MUF.

RRM should prove to be a simple and effective tool for dealing with a local RRS and a remote MUF by acting as the local RRS resource manager for Datacom.