What's new in CICS TS 5.1: Replication Logging
AndreClark 270001TR5Q Comment (1) Visits (10172)
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:
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:
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.