Synchronization of source and target IMS databases

Because Data Replication for IMS sends only change data to the target database, generally you should begin replication with matching copies of your source and target databases.

Data Replication for IMS does not provide support for initially populating your target databases. Two basic approaches are possible for populating your target databases:

  • You can use various IBM® or third party utilities that allow you to unload the source database and reload its contents at the target site, once you transfer the data from the source site to the target site.
  • You can organize your databases so that you can use flash copy operations to create copies of the source databases and transfer them to the secondary site where they are restored. In this type of environment the source and target sites are mirrors of each other.

Additional setup steps might also be required to define the databases at the target site depending upon whether you already have a mechanism in place to support a secondary site or you are starting from scratch.

Data Replication for IMS sends only changed data to a target server to be applied to your target databases by reading and merging data capture log records produced by IMS at your source site. These data capture log records identify:
  • The database and segment that was updated by one of your source applications.
  • The operation the application performed (insert, update, or delete).
  • Information about the segments that were updated by the application.

In addition to using data capture log records, Data Replication for IMS also captures and analyzes other kinds of log records produced by IMS to determine whether a unit of recovery (UOR) was committed or rolled back. Using this information Data Replication for IMS can keep your source and target databases synchronized and mirrors the actions performed by the source IMSs. For example, if your source BMP or online transaction abnormally terminates, the source IMS automatically backs out those changes and produces additional IMS log records indicating that the UOR failed. Data Replication for IMS intercepts those log records and does not forward the associated changes to the target since those updates were never hardened to the source databases.

A possible exception to this rule is when a DL/I batch job abnormally terminates. In these cases, Data Replication for IMS determines that the last (and possibly only) UOR produced by the failing batch job should not be applied at the target but some or all of the changes were applied to the source databases. To ensure that source and target databases match after a DL/I batch job abends, you must run the IMS Batch Backout Utility (DFSBBO00) in default mode before making any further changes to the source database. If a batch backout is not performed, you might have to reload the target database before restarting replication. If you are using a conflict exit, you might be able to re-apply or ignore updates that were made by the batch application when it is re-run; otherwise you must reload the target databases before starting replication.

To ensure that replication is successful, Data Replication for IMS requires, by default, that the source and target DBD structures are identical based on key attributes. These attributes are identified in the topic DBD validation. However, you can relax this requirement and replicate data provided that the source and target database are compatible. This capability is provided to give flexibility while upgrading databases and applications to support new business requirements and can be used to assist in this process.