The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

All information submitted is secure.

My developerWorks:

My notifications:

Sign out

Select a language:

Exploring IMS disaster recovery solutions, Part 2: IMS Base and IMS Tools recovery solutions

Glenn Galler (gallerg@us.ibm.com), Certified IT IMS Specialist, IBM

Glenn Galler is a certified IT specialist for the IMS product in the IBM Advanced Technical Skills (ATS) group. He is a senior programmer specializing in disaster recovery. He joined the ATS group in March 2007. Galler is also the campus recruiting manager for the IBM Software Group for the University of Michigan, holding this position since 1998. He joined IBM in 1982 receiving his bachelor's degree in computer science from the University of Michigan. In 1989, he received a master's degree in computer engineering from the University of Santa Clara. Galler has worked in many areas of IMS, including testing, development, marketing and management. From 1992 to 1997, he held an international assignment in England as the European program manager for the IMS Quality Partnership Program (QPP).

Ron Bisceglia (RBisceglia@rocketsoftware.com), Lead Software Developer, Rocket Software

Ron Bisceglia is a lead software developer for Rocket Software, based in Houston. He has worked with IMS for more than 24 years, and for the past 20 years has been involved in the design, development, and support of a range of IMS tools. He has been involved in the development of database reorganization utilities, data propagation tools, database monitoring and analysis solutions, data replication, and backup and recovery products.

Summary: Every customer needs a Disaster Recovery (DR) plan. The strategies used differ from one customer to another and they differ in time to recovery and loss of data. For IMS®, there are five types of DR solutions: restart, recovery, recovery and restart, coordinated IMS and DB2® restart, and coordinated IMS and DB2 disaster recovery and restart. Here in Part 2, we explore the recovery solutions that use only the IMS base functions and some of the functions in the IMS Tools.

View more content in this series

Date: 12 Apr 2012
Level: Intermediate
PDF: A4 and Letter (1007 KB | 17 pages)Get Adobe® Reader®

Activity: 15339 views
Comments:

IBM Tools IMS Recovery Pack (TSR to IIC)

IMS Tools Timestamp Recovery to IICs Only

With TR, it is necessary to create an RP that is consistent for the databases being recovered. An RP is a period of time when the database is not allocated. Generally, the ALLOC records in the RECON data set can be analyzed to determine periods of time when the database is not allocated. An RP can be created for a database by taking it offline with a /DBR command or the equivalent UPDATE DB STOP(ACCESS) command, or with a /DBD command or the equivalent UPDATE DB STOP(UPDATES) command. In IMS 11, the DB QUIESCE function provided the ability to create an RP without taking the database data sets offline. This function is provided by the UPDATE DB START(QUIESCE) command, and it allows transaction activity to be paused at commit points. In the RECON data set, these DB QUIESCE RPs are indicated with ALLOC records that have been updated with a DEALLOC time and the QUIESCE flag turned on. A new ALLOC record will be written when the database data set is updated again after the DB QUIESCE recovery point.

In this IMS Tools disaster recovery scenario, an RP is created using the IMS 11 DB QUIESCE command with the default NOHOLD option, which pauses transaction activity at commit points. As soon as the RP is created by IMS, the transactions are released to continue processing. In this disaster recovery scenario, the IMS Recovery Solution Pack and High Performance Pointer Checker products are used. For instance, after the RP is created, the Recovery Point Identification (RPID) function is used in the DRF/XF product. This function shows the RP time spans for the set of databases specified. This is illustrated in Figure 6.

Figure 6. IMS DRF/XF Recovery Point Identification (RPID) (primary site activity)
Image shows that recovery time spans comman to all entries in the DBLIST

Image shows that recovery time spans comman to all entries in the DBLIST

The DRF product is used to create the IIC. An IIC is created using an offline utility without taking the databases offline or affecting IMS (outside of registering the IIC with DBRC). Effectively, a TR is performed for one or more databases using an image copy (or IIC) as input along with one or more archived logs. The value for the OUTPUT parameter specified to DRF is ICR, indicating that the resulting data set is an IIC. An IIC is itself a stand-alone image copy, meaning that it contains a copy of the entire database data set, and it does not need to be combined with other IIC or IC data sets when needed for recovery. It is necessary to use the DRF product to restore an IIC. In this disaster recovery scenario, the last archived log used to create the IIC ended in an RP created by the IMS 11 DB QUIESCE command, so the IIC is registered to DBRC as a batch IC. If the archived log had not ended in an RP, the IIC would have been registered to DBRC as a concurrent IC. This is important to this disaster recovery scenario because it means that a TR can be performed at the remote site using only IIC data sets. The creation of the IIC by the DRF product is shown in Figure 7.

Figure 7. IMS DRF Incremental Image Copy (primary site activity)
Image shows creating incremental IC, DRF master address space, recovery sort subspace

Image shows creating incremental IC, DRF master address space, recovery sort subspace

(View a larger version of Figure 7.)

It is still necessary to condition the RECON data set for it to be used at the remote site. In this case, the RECON Cleanup (RCU) function of the IMS DRF/XF product, which is included in the IMS Recovery Solution Pack, is used to make a copy of the RECON and condition it, too. It is necessary to make sure the conditioned copy of the RECON created by RCU gets sent to the remote site. This is done at the primary site after the IIC is created. This is shown in Figure 8.

Figure 8. IMS DRF/XF RECON Cleanup (RCU) (primary site activity)
Image shows cleaning up Recon Backup (IMS DRF/XF) (RCU) (primary)

At the remote site, a TR can be performed immediately using only the IIC data sets and conditioned RECON since the RECON data set was conditioned just after the IICs were created at the primary site. The TSR is performed in parallel for all of the database data sets in the recovery group by the IMS DRF product using only the IIC data sets. This is shown in Figure 9.

Figure 9. IMS DRF Timestamp Recovery to Incremental Image Copies (Remote Site Activity)
Image shows IMS DRF Timestamp Recovery to Incremental Image Copies (primary)

Image shows IMS DRF Timestamp Recovery to Incremental Image Copies (primary)

(View a larger version of Figure 9.)

After the database data sets are restored using TSR, the indices are rebuilt using IMS Index Builder, an image copy is created using IMS High Performance Image Copy (HPIC), and pointer-checking is performed using IMS High Performance Pointer Checker. IMS is cold-started following the recovery of the databases and the recreation of the RDS data set since there are no uncommitted updates to back out with dynamic back-out following a TSR to an RP.

Comments