Exploring IMS disaster recovery solutions, Part 3: IMS Recovery Expert solutions

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 3, we explore both the recovery and recovery and restart solutions provided by the IMS Recovery Expert product.

Share:

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

Glenn GallerGlenn 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 BiscegliaRon 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.



19 April 2012

Before you start

About this series

This "Exploring IMS Disaster Recovery Solutions" series covers non-storage mirroring disaster recovery (DR) solutions for the IMS environment. Methods described show how various backup and recovery resources can be combined to reduce time and data loss in the event of a disaster.

About this tutorial

This tutorial describes IMS DR solutions that use the IMS Tools product, IMS Recovery Expert, which uses a recovery resource called a System Level Backup (SLB) to capture the state of the entire IMS production environment. The SLB can be created using storage-based fast replication (FlashCopy technology, for example) to ensure that IMS is unavailable for a couple of seconds or less. Since the SLB can be used for DR and local application recovery purposes, there are solutions shown for both cases.

The IMS Tools Disaster Recovery solutions and two IMS Tools local recovery solutions discussed are:

  • IMS disaster restart from SLB only
  • IMS disaster recovery and restart using point-in-time recovery (PITR) to the last good log data set
  • IMS local application recovery using timestamp recovery (TSR) to a recovery point
  • IMS local application recovery using point-in-time recovery (PITR) to any timestamp

The first two solutions show how DR can be accomplished using only the SLB, and how it can be done starting with the SLB and applying updates from the archived log data sets. The third and fourth solutions show how the same SLB created for DR can be reused for local application recovery using two different forms of recovery: Timestamp Recovery (TSR) and Point-In-Time Recovery (PITR).

If you haven't done so, consider downloading the IMS Disaster Recovery demonstrations, which go hand in hand with this series.

Objectives

After completing the tutorial, you should be able to:

  • Customize the IMS Recovery Expert product
  • Create disaster and application profiles
  • Create an SLB
  • Understand how TSR and PITR work
  • Understand the DR process

Prerequisites

You should have basic knowledge of the following:

  • z/OS® environment
  • IMS operating environment
  • IMS commands and procedures
  • Internet browser, such as Firefox or Internet Explorer

IMS Recovery Expert (one-time setup)

Primary site activities

The one-time setup steps are performed only once and can be changed at any time. In one-time setup, the user:

  1. Registers IMS systems
  2. Analyzes the IMS configuration
  3. Defines the system backup profile
  4. Defines the application profile
  5. Defines the DR profile

The first step is to register the IMS systems. The IMS system setup should be done for all IMS systems you plan to use with the IMS Recovery Expert product. If your IMS systems are members of a data sharing group, you must enter information for each member of the group individually on the IMS Recovery Expert setup screens. Here, we walk through the register IMS systems, parameters for IMS subsystem, and update datasets screens. The Update datasets screen allows you to include non-database data sets or exclude certain IMS data sets from your backups.

The second step is to analyze the IMS environments to discover the data sets and user catalogs that make up your IMS environment to ensure that your IMS environment is properly configured to allow the types of recoveries that could be performed. We enter option 5 from the main menu of IMS Recovery Expert to flow to the System Analysis and Configuration screens that display the results of the analysis. The information from analyzing your IMS system is then used when defining the backup profiles. Backup profiles are used to define how the backups are created. In the demo, we only define one backup profile for an IMS subsystem, but a user can have many backup profiles depending on the backup and recovery requirements for an IMS environment or certain applications.

The third step is to define the System Backup profile, which pertains to the backup of entire IMS system. The demo shows how the system backup profile is created, how to update the target volume information, and how to update the offload options. The backup profile defined is an auto-mapping backup profile, so target pools are also defined on the Target Pool Selection screen. The System Backup profile also defines the offload characteristics used to maintain multiple generations of an SLB or when the SLB needs to be sent off-site for DR. For new system backup profiles, IMS Recovery Expert requires a setup job to be run against the system backup profile before it can be used to create an SLB. The setup job validates that the target volumes specified are sufficient and have the proper size for creating an SLB.

The fourth step is to define the local application recovery profile. The databases listed for local recovery can be listed individually, as indices, or as DBRC groups. Here, we use the recovery group RECG1. This group can be "exploded" to see the individual databases in the recovery group. There are many recovery options that can be updated in this profile. For example, the user needs to specify the recovery utility that will be used along with information on an index builder utility, change accumulation utility, image copy utility, and HALDB utilities. Once recovery options are selected, the recovery job is created so it is available when it needs to be run. Our recovery job is called RECOVERY.

The final step is to define the DR profile. A DR profile is used to specify recovery assets to be sent to a remote site and the recovery options to be used at the remote site. The DRESTART job that creates the remote PDS data set with the IMS Recovery Expert Repository and recovery JCL is also created.

Figure 1. IMS Recovery Expert one-time setup steps (primary site activity)
Image shows IMS Recovery Expert one-time setup steps with user settings, system analysis and configuration, system backup profiles, application profiles, and disaster recovery profiles

IMS disaster recovery (SLB)

IMS restart from system-level backup only

Primary site activities

IMS Recovery Expert has the ability to back up an entire IMS environment at a consistent point in time. The backup IMS Recovery Expert creates is the SLB, which is a 1:1 mapping of every IMS production source volume to a target volume. IMS Recovery Expert uses FlashCopy for a Consistency Group on a volume level to copy every volume to its corresponding target volume. There is a two-step process in preparing for DR at the production site. The first step is to run a job (CREATSLB) to create the SLB; and the second step is to run the DRESTART job, which creates a PDS data set, which is transmitted with the SLB to the remote site. The PDS data set contains the JCL needed to restore the SLB, as well as a copy of the IMS Recovery Expert Repository. Since IMS is unavailable for a brief period of time (usually less than 1 second), the SLB and the PDS can be created periodically throughout the day and transmitted to the remote site.

At the remote site, the jobs in the remote PDS are executed to rebuild the IMS Recovery Expert repository and restore the SLB. With all of the data sets (OLDS, RECON, etc.) exactly as they were when the SLB was created, IMS can be emergency-restarted /ERE OVERRIDE, for example). This DR situation is analogous to a power outage at the primary site.

In this demonstration, we show how a user can create a system-level backup using FlashCopy for a consistency group for all IMS production volumes. After the SLB is created, another IMS Recovery Expert job is run to create the remote PDS data set that contains the restart JCL for the remote site, along with a copy of the IMS Recovery Expert repository. The CREATSLB job creates the SLB, and the DRESTART job creates the remote PDS data set. IMS Recovery Expert has an ISPF interface that allows the user to view information about the SLBs created. To ensure that there are some uncommitted updates on the OLDS at the time the SLB is created, we run a BMP job (IMS0BMP), and we artificially hold it up using a WTOR after we update the database and before we commit the updates. These CREATSLB and DRESTART jobs are shown in Figure 2.

Figure 2. Create the SLB and remote PDS data set (primary site activity)
Image shows IMS Recovery Expert (Create SLB), ane IMS Recovery Expert (Create Restart JCL)

Remote site activities

After the z/OS system is up and running at the remote site, the PDS created by the DRESTART job run at the production site must be restored. This step is not shown in the demo. Once the PDS is restored, the restart job (IMS0#JC1) is run to restore the IMS Recovery Expert Repository and the SLB from tape or other medium back to the source volumes at the remote site. The volume restores can be restored in parallel depending on how they are stored on the tapes. There are options to stack multiple volumes on a single tape or store each volume on its own tape. These offloading options were set up in the one-time setup demonstration. In the demonstration, the volume is shown to be empty before the SLB is restored, and it is shown to contain IMS data sets after the SLB is restored. These jobs and TSO screens are shown in Figure 3.

Figure 3. Restore the SLB (remote site activity)
Image shows IMS Recovery Expert Restore the SLB at the remote site

The SLB contains all the IMS production volume data taken at the primary site at a specific point in time. There is no need to condition the RECON data set because the RECON was included in the SLB, and it is consistent with all other data in IMS at the time the SLB was created. There could be uncommitted updates in the OLDS since the SLB did not wait for a Recovery Point (RP) to be created, so it is necessary to perform an emergency restart (/ERE OVERRIDE) of the IMS subsystem. In this demonstration, we made sure there was a BMP with uncommitted updates at the primary site while the SLB was created so the user could see IMS perform dynamic back-out during the IMS restart, as shown in Figure 4.

Figure 4. IMS dynamic back-out during emergency restart (remote site activity)
Image shows IMS Dynamic Backout during emergency restart (remote), shows successfully backed out

Finally, the IMS High Performance Pointer Checker (HPPC) is run to verify that the database data sets were recovered correctly.


IMS disaster recovery (PITR)

IMS restart from system-level backup and logs using PITR

Primary site activities

The IMS Recovery Expert product has the ability to back up an entire IMS environment at a consistent point in time. The backup IMS Recovery Expert creates is called a system-level backup (SLB). The SLB is a 1:1 mapping of every IMS production source volume to a target volume. IMS Recovery Expert uses FlashCopy for a consistency group on a volume level to copy every volume to its corresponding target volume. There is a two-step process in preparing for disaster recovery at the production site. The first step is to run a job (CREATSLB) to create the SLB; and the second step is to run the DRESTART job, which creates a PDS data set, which is transmitted with the SLB to the remote site. The PDS data set contains the JCL needed to restore the SLB as well as a copy of the IMS Recovery Expert Repository. Since IMS is unavailable for a brief period of time (usually less than 1 second), the SLB and PDS can be created periodically throughout the day and transmitted to the remote site.

The IMS Recovery Expert product also can apply log updates using the IBM IMS Database Recovery Facility (DRF) product and to restore the database data sets using point in time recovery (PITR). This allows the databases to be brought forward to a later point in time at the remote site, lowering the RPO (data lost in the event of a disaster). Each time a log is archived, an additional IMS Recovery Restart job is run to condition the RECON, gather information about the archived log, create a copy of the IMS Recovery Expert Repository, and create the recovery JCL for the remote site. The information created by this recovery job goes into the remote PDS data set. For this DR strategy, the data transmitted to the remote site now includes the SLB, the remote PDS data set, and the archived logs.

At the remote site, the jobs in the remote PDS are executed to rebuild the IMS Recovery Expert Repository, restore the SLB, and drive DRF to forward recover the IMS database data sets using PITR to apply the committed updates to the end of the last log data set that was sent to the remote site. Since there were no uncommitted updates applied to the database data sets, it is unnecessary to do an emergency restart of IMS. Instead, a cold start is sufficient.

In this demonstration, we show how a user can create an SLB using FlashCopy for a consistency group for all IMS production volumes. After the SLB is created, another IMS Recovery Expert job is run to create the remote PDS data set that contains the restart JCL for the remote site, along with a copy of the IMS Recovery Expert repository. The CREATSLB job creates the SLB, and the DRESTART job creates the remote PDS data set. IMS Recovery Expert has an ISPF interface that allows the user to view information about the SLBs created.

After the SLB is created, we run several BMPs to update the IMS database data sets, followed by a /SWI OLDS command executed under the TSO Single Point of Control (SPOC) to force the logs to switch and be archived. Since the archived logs are also being transmitted to the remote site, an additional IMS Recovery Expert job called DRECOVER is run after a new archive log is created. The DRECOVER job will obtain information about the archived log, create a copy of the IMS Recovery Expert Repository, copy and condition the RECON data set for the remote site, and create the recovery jobs to be run at the remote site. All of these items are placed in the remote PDS data set transmitted to the remote site together with the archived log. The archive step and the DRECOVER job is shown in Figure 5.

Figure 5. Create the remote PDS data set after log archive (primary site activity)
Image shows IMS Recovery Expert Archive Log and Run Recovery Job (primary), includes Run BMP4, TSO SPOC, Archive OLDS, and IMS Recovery Expert (Create Recovery JCL)

The IMS0BMP6 job was artificially held up using a WTOR after it had updated the database, but before it could commit the updates. While it was held up, the log was switched and archived, and the DRECOVER job was run to create the remote PDS data set. After the DRECOVER job completed, the WTOR for IMS0BMP6 was released, and the BMP committed the updates so the database had updates for Segments 1, 4, 5, and 6. However, the last good log to be transmitted to the remote site only had committed updates for Segments 1, 4, and 5. This is shown in Figure 6. When the databases recovered at the remote site using PITR, they should have only Segments 1, 4, and 5 since the updates for IMS0BMP6 (Segment 6) were not committed on the last log that was archived and transmitted to the remote site.

Figure 6. Create uncommitted updates with BMP6 and create remote PDS data after log archive (primary site activity)
Image shows IMS BMP6 with Uncommitted Updates and IMS Recovery Expert DRECOVER Job (primary)

Remote site activities

After z/OS is up and running at the remote site, the PDS created by the DRESTART job run at the production site must be restored. This step is not shown in the demo. Once the PDS is restored, there are three IMS Recovery Expert jobs that need to be executed to restore and recover the entire IMS environment: IMS0#JC1, IMS0#JC2, and IMS0#JC3. IMS0#JC1 will restore the IMS Recovery Expert repository and restore the last SLB sent to the remote site. IMS0#JC2 will delete and redefine the OLDS and Write-Ahead Data Sets (WADS) since we will be doing a cold start after performing recovery of the database. IMS0#JC2 will also restore the conditioned RECON and copy any archive logs from tape to disk to speed recovery if the option was specified when the DR profile was built during one-time setup. IMS0#JC3 will perform the steps necessary to recover and databases and rebuild any indices to the end of the last archive log sent to the remote site. These jobs are shown in Figure 7.

Figure 7. Restore the SLB and perform PITR with IMS DRF (remote site activity)
Image shows IMS Recovery Expert Restore the SLB and Perform PITR with IMS DRF (remote)

To restore any image copies created after the SLB and sent to the remote site, and apply any log updates from the archive logs created after the SLB, IMS Recovery Expert will invoke DRF to perform a PITR. The timestamp specified for PITR recovery is the timestamp of the end of the last archive log and with PITR-only committed updates prior to this timestamp are recovered. For this reason, there are no uncommitted updates that need to be dynamically backed out during emergency restart, so a cold start of IMS is sufficient. Once IMS is up and running, a program (DBPOSTRM) is run to show that the only segments to be recovered at the remote site were Segments 1, 4, and 5.


IMS local recovery (TSR)

IMS local application recovery (TSR from RP)

Primary site activities

The system-level backup (SLB) has multiple uses. It can be used to restore an entire IMS subsystem in a disaster recovery solution, and it can be used as a replacement for most image copies used for local application recovery. With disaster recovery, the full SLB is generally restored. However, with local application recovery, only one or more databases may need to be restored and recovered. In this demonstration, we show how a group of databases can be recovered using TSR to a specific recovery point created using the IMS 11 DB QUIESCE function.

The local application profile was created during IMS Recovery Expert one-time setup as explained earlier. This is where the local recovery options were identified (recovery and image copy utilities, for example). This is also where the recovery job was created.

In this demonstration, we created a full SLB for all IMS production resources. We also created some image copies for specific database data sets to show that the recovery operation will detect and use image copies created after the SLB was created. These steps are shown in Figure 8.

Figure 8. Create the full SLB
Image shows create SLB and create image copies

Next, we start a BMP that updates and commits some updates to a database. However, we cause the BMP to artificially wait after updating the database and prior to committing the data. While the BMP is held up, we issue the TSO SPOC DB QUIESCE command to create a recovery point in IMS. This command is shown in Figure 9.

Figure 9. Create a recovery point using IMS DB QUIESCE
Image shows UPD DATAGRP NAME(RECG1) START(QUIESCE) SET(TIMEOUT(100))

The DB QUIESCE request cannot complete while there are updates in flight, so we must reply to the WTOR to let the BMP commit the updates. Once the CHKP call by the BMP is completed, the QUIESCE of the databases is completed. We can view the QUIESCE point create by doing a DBRC LIST.HISTORY of the database and viewing the ALLOC records. This can be seen in the LISTHIST output.

After the recovery point is created, we start a second BMP that runs to completion and creates an application error in the database. The decision is made to recover the database using TSR to the last good recovery point created using the TSO SPOC DB QUIESCE command. The IMS recovery expert ISPF interface is used to find this recovery point using the RPID function, as shown in Figure 10. There are two recovery points identified, and the second timestamp is selected for this TSR. This is shown in Figure 11.

Figure 10. Use IMS Recovery Expert ISPF interface to find recovery points
Image shows that recovery point is 4
Figure 11. Show recovery points in IMS
Screen capture shows start timestamd and end timestamp

Once the timestamp for the recovery point is selected, we must specify that this is a TSR. The timestamp specified for a TSR recovery must be a valid recovery point, meaning that none of the databases being recovered were allocated at the recovery timestamp. This is shown in Figure 12.

Figure 12. Select RP for TSR
Image shows that recovery point is 2 and timestamp is 103361046001

The application profile is saved after the recovery point is selected. The original recovery job built during one-time setup will pick up the recovery timestamp from the application profile saved in the IMS Recovery Expert repository, so no modifications need to be made to the recovery JCL. The recovery job (RECOVERY) drives the recovery utilities established during IMS Recovery Expert one-time setup. In our demonstration, the IMS Recovery Solution Pack products IMS Database Recovery Facility (DRF) and IMS High Performance Image Copy (HPIC) are driven to recover the databases in the recovery group. This is shown in Figure 13.

Figure 13. Drive IMS DRF to perform TSR to a recovery point
Image shows drive DRF to do TSR

We can see in the IMS Recovery Expert Recovery Report generated by the RECOVERY job that the timestamp selected through the ISPF interface was used to perform a TSR to a valid recovery point. If we look at the information in this report for all of the database data sets recovered with this job, some databases, like DBHDV were recovered using image copies created after the SLB, while other databases, like DBHIO, were recovered using the SLB. This is shown in Figure 14.

Figure 14. Show image copy and SLB selected for recovery
Image shows DBHDV recovered using image copy and DBHIO recovered using SLB

IMS local recovery (PITR)

IMS local application recovery

Primary site activities

The SLB has multiple uses. It can be used to restore an entire IMS subsystem in a DR solution, and it can also be used as a replacement for most image copies used for local application recovery. With DR, the full SLB is generally restored, but with local application recovery, only one or more databases may need to be restored and recovered. In this demonstration, we show how a group of databases can be recovered using PITR to any timestamp. A PITR recovery requires functionality that is not included in the IMS base product. In our demonstration, we do a PITR recovery using the IMS Database Recovery Facility (DRF) utility, which is found in the IMS Recovery Solution Pack.

The local application profile was created during IMS Recovery Expert one-time setup, as explained earlier. This is where the local recovery options were identified (recovery and image copy utilities, for example). This is also where the recovery job was created.

In this demonstration, we create a full SLB for all IMS production resources. Next, we start two BMPs that commit updates to a database. Then we start a third BMP that updates a database and artificially waits before committing the update. In the demonstration, we make the decision that there was an application error during the processing of the third BMP as shown in Figure 15.

Figure 15. Create committed and uncommitted updates with BMPs
Image shows creating committed and uncommitted updates with BMPs

Since we are doing a PITR to a timestamp, we use the IMS Recovery Expert ISPF interface to specify the timestamp for the recovery. The timestamp selected was during the processing of the third BMP after some updates were done, but before the CHKP call was issued. The specification of this timestamp and that a PITR recovery is wanted is shown in Figure 16.

Figure 16. Use IMS Recovery Expert ISPF interface to select timestamp for PITR
Image shows selecting timestamp for PITR using IMS RE ISPF

The application profile is then updated after the timestamp and PITR is specified. The original recovery job built during one-time setup will pick up the recovery timestamp from the application profile saved in the IMS Recovery Expert repository, so no modifications need to be made to the recovery JCL.

The recovery job (RECOVERY) was prebuilt during the IMS Recovery Expert one-time setup as shown in Figure 1. This recovery job will drive the IMS Database Recovery Facility (DRF), which is available in the IMS Recovery Solution Pack, to do PITR recovery, as shown below.

Figure 17. Drive IMS DRF to perform PITR to timestamp selected
Image shows driving IMS DRF to Perform PITR

There are a couple of interesting things to point out regarding this local application recovery. First, we can see in the IMS DRF recovery report, shown in Figure 18, that a PITR recovery was requested, and the timestamp specified for the PITR is the same timestamp we save in the application profile.

Second, the SLB was created before the BMPs were initiated, and there were also some image copies created for some of the database data sets after the SLB. With IMS Recovery Expert, the databases are recovered using the SLB or a later image copy. DRF will apply any updates on the log data sets, along with an image copy or directly to a database data set. In our demonstration, the databases in the recovery group have a mixture of SLB and image copies available for the recovery. For example, the databases (DBHIO, DBHIOI, DBHIOS1, and DBHIOS2), have an image copy that is later than the SLB. The database (DBHDV) does not have a later image copy, so the recovery will use the SLB. Both databases will use the log data sets in the recovery. We can see in the IMS DRF recovery report, as shown in Figure 18, that some database data sets used image copies, and others only applied logs to data sets restored from the SLB in the prior step.

Figure 18. Show IMS DRF output report for PITR
Image shows IMS DRF output for PITR

After the PITR completes, we run a job (DBAFRECV) to show all DB records in the databases. We can see that the databases contain all the DB records inserted by the two BMPs that completed prior to the timestamp specified in the application profile. We can also see that none of the segments inserted by the third BMP but not committed prior to the timestamp specified are in the databases.


Conclusion

This tutorial has shown how disaster recovery and local application recovery can be accomplished using the IMS Tools product, IMS Recovery Expert, which uses system-level backup as a recovery resource.

There were two disaster recovery solutions and two local application recovery solutions shown. The first DR solution used only the SLB for recovery without applying any log updates. The second applied log updates to the databases in the SLB. The first local application recovery solution used timestamp recovery using a recovery point created by the IMS 11 DB QUIESCE function. The second local application recovery solution used point-in-time-recovery to restore the application to a specified timestamp that was not a true recovery point.

In Part 4, learn how IMS Recovery Expert — together with the DB2® Tools product DB2 Recovery Expert — can provide a coordinated IMS and DB2 DR solution, where IMS and DB2 are restored to a consistent point in time.


Downloads

DescriptionNameSize
IMS Disaster Recovery Demonstrations1IMS_Backup_and_Recovery_Demos.zip3330KB
Download Instructions for Demonstrations2IMSBackupandRecoveryDemoInstructions.pdf768KB

Notes

  1. This download is the same for all parts of this article/tutorial series.
  2. This PDF file is the same for all parts of this series. If you have downloaded it for a previous article or tutorial in the series, there is no need to download it again.

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.
  • Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edition and provides a solid base to build and deploy applications.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


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

All information submitted is secure.

Choose your display name



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.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=810728
ArticleTitle=Exploring IMS disaster recovery solutions, Part 3: IMS Recovery Expert solutions
publish-date=04192012