IMS Version 8 Implementation Guide A Technical Overview of the New Features

62 IMS Version 8 Implementation Guide

During a batch run when the application program issues either a CHKP or a ROLB call, IMS

will determine whether it should coordinate the subsequent syncpoint itself or participate in

the syncpoint coordinated by RRS.

It determines this by expressing interest in the current UOW, and then retrieving the count of

interests expressed. If the count is one, then the lone interest must be IMS's itself and it then

deletes its own interest and coordinates the syncpoint itself.

However, if there has been more than one interest expressed, then batch will initiate the RRS

syncpoint via the ATRCMIT (or ATRBACK) call and assume the role of a syncpoint participant

to RRS.

4.5 Coordinated IMS/DB2 disaster recovery support

There have been additional enhancements to aid in the coordination of disaster recovery for

installations accessing DB2 and IMS. They are in response to user requirements asking for

synchronized disaster recovery support using independent transfer mechanisms to send both

IMS and DB2 logs to the remote site. You will find further information on Coordinated

IMS/DB2 disaster recovery support in

IMS Version 8: Release Planning Guide,

GC27-1305.

The enhancements are based on the usage of Remote Site Recovery (RSR) for IMS and

eXtended Remote Copy (XRC) for your DB2 environment. RSR utilizes APPC to send IMS

log data from the active site to the remote site. The RSR tracker instance at the remote site

which is writing its copy of log records received from the active site is also recording into the

tracking RECON data set and optionally updating its own “shadowed” databases if running on

database level tracking (DLT), shown in Figure 4-1,

Figure 4-1 IMS RSR

XRC is a function of DASD storage servers (3990 control units and Enterprise Storage Server

(ESS)) and is using DFSMS System Data Mover (SDM) for asynchronous mirroring of the

necessary DB2 logs and boot strap data sets as shown in Figure 4-2.

IMS Databases Shadow IMS Databases

(optional)

IMS Log Records

APPC

IMS

RSR Tracker

IMS

Active Site

IMS Logs

Chapter 4. Database management enhancements 63

Figure 4-2 DB2 XRC

For more information about XRC please refer to IBM Redbook

Implementing ESS Copy

Services on S/390

, SG24-5680, Chapter 3, XRC.

Coordinated recovery operations now allow users to recover IMS and DB2 data to a

consistent point in time. The highlights are:

򐂰 “eXtended Remote Copy (XRC) tracking” is added to IMS RSR

򐂰 IMS and DB2 log synchronization for disaster recovery

򐂰 Support of RSR for IMS logs and optionally, “shadowed” databases

򐂰 Support of XRC for DB2 logs, together with the boot strap data sets (BSDS) on a single

XRC session to keep both synchronized to each other; DB2 databases (tables) may not

be included

This support is especially interesting for environments with limited bandwidth for XRC

transmissions. Those environments probably cannot support the transmission of the entire

DB2 databases and their updates. Instead, only the logged DB2 and IMS data and the DB2

BSDSs are transmitted.

IMS TM Version 8 can be connected to the DB2 Version 6 and Version 7. The DB2 logs and

BSDSs must reside on devices supporting XRC. DB2 must be running in data sharing mode

since this mode provides timestamps in the DB2 log. Without data sharing mode the DB2

subsystem would use RBAs instead.

4.5.1 XRC tracking

Since XRC tracking is implemented in our IMS RSR process the IMS truncation point is

issued in the new

DFS2933I

message.

The IMS log truncation point will be kept behind XRC consistency time. This means the RSR

tracking subsystem (the log router function) ensures that the routing of IMS logs is always

behind that of the DB2 logs. To get this information, the RSR tracker will frequently invoke an

“XRC Query API” request against the DFSMS system data mover (SDM). This XRC tracking

is running under its own ITASK and is using SDM’s API provided by the ANTRQST macro call

‘REQUEST(XCONTIME)’. So it is a requirement that the SDM is running on the same OS/390

system as the IMS RSR tracking subsystem is running. Otherwise the previously invoked API

Storage Server Storage Server

DFSMS

System Data Mover

ESCON with

DASD Channel Extenders