Technical Blog Post
What's new in CICS TS 5.1: Replication Logging
As a CICS level 2 support person, lately I have been working on calls that are dealing with Replication Logging which is new in CICS 5.1. So perhaps it would be worthwhile to dig into this and explain exactly what this is and how it can be useful in your shop. This blog will serve as an overview of this topic.
From the CICS Transaction Server for z/OS (CICS TS) 5.1 documentation, here is a description of what Replication Logging is:
"Replication logging is a form of logging in CICS® where updates to VSAM files, including RLS files, in one location are replicated on another site. In this way, multisite operations can reduce their recovery time objective (RTO) to near zero."
And in the Support for GDPS/Active-Active availability solutions section it states:
"CICS® TS 5.1 provides replication logging capability in support of the IBM® GDPS® /Active-Active (GDPS/AA) availability solution which IBM intends, in the future, to enhance to support replication of VSAM data for active-standby and active-query configurations.
Currently GDPS/AA provides software replication of DB2® and IMS™ data between geographically dispersed sysplexes (GDPS). The replication logging in CICS TS is intended to be used by GDPS/AA to provide replication of VSAM data updated under the control of CICS TS and complements replication logging in CICS VR (CICS VSAM Recovery for z/OS) 5.1 which provides the same support for batch jobs.
Replication logging support requires z/OS®, Version 1 Release 13 plus maintenance, as described in the Program Directory."
To learn more about GDPS, see the GDPS webpage.
These days having highly available systems and resources are in the top tier of needs for companies who cannot afford to have long periods of downtime for their regions. GDPS/AA and Replication Logging provide near-continuous data and systems availability across sites separated by unlimited distances. Replication Logging allows for such needs to be satisfied in regards to VSAM/RLS files that are needed by multiple regions at the same time. CICS writes VSAM replication logs to a general log stream defined to the MVS system logger. You can merge replication log data for more than one VSAM data set to the same log stream, or you can dedicate a replication log stream to a single data set. Another benefit of this technology is the ability to have multiple AORs update or perform requests on RLS files at the same time. Using a product like CICS VR for replication logging you can perform:
"...writes before-image and after-image log records to the replication log stream for every update made to a VSAM data set by a batch job. CICS VR batch logger shares forward recovery and replication logs if both forward recovery logging and replication logging are requested.
CICS VR logs VSAM before-image and after-image records to the replication log in the following format:
- The before image, UNDO record, in the same format that is written to the CICS VR undo log.
- The after image, REDO record, in the same format that is written to the forward recovery log. If both the forward recovery and replication are active, one record is written with both fljb_fwd_recovery bit set, and a new fljb_replication bit set."
When performing Replication Logging you will need to define a 'Logging Facility'. A logging facility is simply a facility that is used to replicate VSAM and RLS files from one location to another. In addition you will need to take into account disaster recovery planning and the total time you will allow systems to be offline. This is known as the 'Recovery Time Objective' and will likely differ depending on the requirements of different shops. This will likely already be something that has been investigated and researched in other recovery related situations.
When defining the replication logs for VSAM datasets, you must define them as LOGREPLICATE in order to take advantage of this option. This will be defined in the ICF (integrated catalog facility). If you do not already have a logstream defined you need to define a general log stream for replication data. If you do not define a general log stream, CICS will attempt to create a log stream dynamically.
There have been two known issues with Replication Logging, when the updates from the AORs to the files have been done in the wrong order (the records have not been committed in order) leading to issues, on KSDS files and ESDS files. These problems have resulted in APAR PI13825 (as of the time of this blog entry, a PTF is not available yet) which is for the KSDS files and APAR PM95393 (PTF UI13982) which is for the ESDS files.
The purpose of this blog is to serve as a general overview of what replication logging is and how it can be useful. I myself am still learning more and more about the details of it, the ins and outs and how it actually works to provide the services that it does. As I learn more I will be able to expand further on the intricacies of it and provide a deeper dive into how it all works.