Skip to main content

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

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.

  • Close [x]

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.

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

All information submitted is secure.

  • Close [x]

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
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
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:  15352 views
Comments:  

IMS Base (TSR to CA)

IMS Timestamp Recovery using Change Accums to a Recovery Point

Primary site activities

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 RP.

For this second TR solution, we use DB QUIESCE with the default NOHOLD option to pause transaction activity at commit points. This creates an RP, and by default, the OLDS are switched and archived as part of the DB QUIESCE command. GENJCL.CA is used to create the jobs that will create the CA data sets. The CA data sets have changes on them up until the RP created by the DB QUIESCE command. The RECON data set is backed up and transmitted to the remote site with the image copies and CA data sets.

In Figure 3, the steps to run GENJCL to create the CA data sets and the step to back up the RECON data set are shown.


Figure 3. Create Change Accum to up to recovery point (primary site activity)
Image shows building GEMJCL for change accum, run change accum,                         to RP, Show RP, and create backup RECOM

Remote site activities

At the remote site, the backup copy of the RECON data set must be conditioned before it can be used for recovery. When the backup RECON was created, it showed a primary system that was up and running and healthy. The conditioning will change the RECON data set to reflect that a disaster has occurred and IMS was abnormally terminated.

The first conditioning step is to flag the primary image copies as invalid. This is only necessary if dual image copies are being created at the primary site and only the secondary image copy is being transmitted to the remote site. It is common to use dual image copies in this way. The command for this is CHANGE.IC DBD(dbname) DDN(ddname) INVALID.

The second step is to delete the IMS subsystems that were active at the time the RECON was created. A LIST.SUBSYS DBRC command will show which IMS subsystems were active, then a series of four commands are required to delete each subsystem ID.


Listing 2. Commands to delete each subsystem ID
      
CHANGE.SUBSYS SSID(ssidname) ABNORMAL
CHANGE.SUBSYS SSID(ssidname) STARTRCV
CHANGE.SUBSYS SSID(ssidname) ENDRECOV 
DELETE.SUBSYS SSID(ssidname)               				
                			

By deleting the IMS subsystems records, it is no longer possible to emergency-restart the IMS systems at the remote site. For this solution, this is not a problem because the recoveries are to RPs created by clean image copies, and dynamic back-out is not required for any uncommitted updates.

The third conditioning step before IMS is cold-started is to close and archive the open log data sets in the RECON data set. The OLDS data sets are not transmitted to the remote site. However, at the time the backup RECON was created, it would have showed an active OLDS data set. To close and archive the data set, an empty OLDS data set must be allocated, and the active OLDS in the RECON must be flagged for archiving. The archive utility will not care that the OLDS is empty, and it will archive it appropriately. As a result, the PRILOG, PRISLD, and PRIOLD records in the RECON will change from having all zeros in the stop times to having valid timestamps. The command to identify the active OLDS for this is LIST.RECON.

After the OLDS is allocated, the command to notify the RECON that the OLDS needs archiving is NOTIFY.PRILOG OLDS(oldsdd) SSID(newssid) -STARTIME(start) … RUNTIME(start+1).

Prior to running the recovery jobs, the database data sets must be deleted and reallocated as empty data sets. Once this is done, the GENJCL.RECOV command can be issued to create the DBRC recovery JCL and the resulting jobs can be executed. The timestamp used with GENJCL.RECOV is timestamp of the last CA data set that contains the RP created by the DB QUIESCE command. These RECON conditioning steps are shown in Figure 4.


Figure 4. Manually Condition the RECON Data Set (Remote Site Activity)
Image shows flagging primacy IC as invalid, show non-zero stop times for                         PRILOG, PRISLD, PRIOLD, delete SSYS record, and set non-zero stop                         times in PRILOG, PRISLD, PRIOLD

Prior to running the recovery jobs, the database data sets must be deleted and reallocated as empty data sets. Once this is done, the GENJCL.RECOV command can be issued to create the DBRC recovery JCL and the resulting jobs can be executed. The timestamp used with GENJCL.RECOV is timestamp of the last CA data set that contains the RP created by the DB QUIESCE command.

The two final steps are to delete the PRIOLD records and allocate the RDS data set. The OLDS and the RDS were not transmitted to the remote site. Finally, the IMS subsystems can be cold-started.

3 of 9 | Previous | Next

Comments



static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=809816
TutorialTitle=Exploring IMS disaster recovery solutions, Part 2: IMS Base and IMS Tools recovery solutions
publish-date=04122012
author1-email=gallerg@us.ibm.com
author1-email-cc=
author2-email=RBisceglia@rocketsoftware.com
author2-email-cc=