Skip to Content

Backup and Recovery functions

The following topic provides more information about the functions that are included in the BMC AMI Backup and Recovery for IMS product.

Concurrent Pointer Checking function

The Concurrent Pointer Checking function is available with the following BMC products:

  • BMC AMI Backup and Recovery for IMS for full-function databases and DEDBs
  • BMC AMI Pointer Checker for IMS for full-function databases
  • Fast Path Analyzer/EP for DEDBs

The Backup and Recovery products can invoke the Concurrent Pointer Checking function to verify the validity of database pointers as part of the image copy, incremental image copy, and recovery processes. For more information, see Concurrently-verifying-pointers.

Index Rebuild function

The Recovery utility can invoke the Index Rebuild function to rebuild the primary index and all secondary indexes for a recovered DL/I database. The function rebuilds all indexes associated with a database using only the database as input rather than recovering these indexes from an image copy.

Groups and objects in RMGR

Recovery situations often involve multiple data structures in the IMS environment.

For example, an application logic error usually damages not only the primary database, but also its secondary indexes and other databases that are logically related to it. A hardware failure may damage all of the databases that are stored on a device.

To simplify the recovery management process, ensure consistent activity across related databases, and increase the speed of recovery processing, RMGR works with groups of recoverable objects:

  • A recoverable object corresponds to an IMS full-function (DL/I) database data set, a High Availability Large Database (HALDB) partition data set, or a Fast Path data entry database (DEDB) area that is not designated as USERRECV in DBRC.
  • An elemental group consists of a defined set of one or more recoverable objects.
  • A connecting group consists of a defined set of elemental groups.

RMGR offers interactive and batch methods for defining groups. You can use any of the following criteria to select objects to include in elemental groups:

  • Database definition (DBD) name
  • Program specification block (PSB) name
  • DBRC change accumulation group name
  • DBRC database data set group name
  • Volume serial of a storage device
  • Data set name
  • IMS subsystem ID

In addition, you can choose to include objects that are secondary indexes or logically related databases for the selected objects.

Group Validation function and Group Rebuild function

Your data processing environment will probably change over time.

For example, another secondary index may be defined for a database, or the storage device manager may move a database data set to a different device. After you have defined the criteria for selecting the objects to include in a group, you do not need to manually update the group when changes occur in the environment.

RMGR provides the Group Validation function and Group Rebuild function to automate the tasks of maintaining group and object definitions. You can schedule the functions to run periodically, or you can run the functions on demand.

The Group Validation function compares the current conditions against the original criteria that were used to define the group and reports on any differences that it found. The Group Rebuild function updates the group to match the current conditions by adding any new objects to the group if they meet the group selection criteria, updating the stored information about objects, and removing objects from the group if they no longer meet the group selection criteria.

Recovery Advisor function

The Recovery Advisor function detects, reports, and (when possible) takes action to correct many common conditions that may affect the recovery of IMS databases.

For example, it can detect the condition that a particular database has had no image copy taken within a specified time and can submit a job to take an image copy of the database. Recovery Advisor helps to prevent unrecoverability of databases, lengthy outages for database recoveries, and unnecessary consumption of resources. Recovery Advisor is available only with the BMC AMI Backup and Recovery for IMS product.

Recovery Advisor increases data availability by ensuring that image copies and change accumulations are performed at appropriate intervals to minimize the number of logs required for recovery. It reduces data management costs by automating many tasks and decisions that affect recoverability and by providing easy-to-use information.

Check Assets function

Recovery strategies depend on the availability and usable condition of recovery assets. A recovery asset is any element that may be required for recovery of a particular object:

  • Image copy data sets
  • Input system log data sets (SLDSs) and recovery log data sets (RLDSs)
  • Change accumulation data sets

RMGR provides the Check Assets function to determine whether all required elements for a recovery to current are available—before a recovery is necessary. If an asset is missing, the Check Assets function detects the problem early, when correcting it may still be possible. The Check Assets function can also help you determine whether change accumulation and image copy processes are being performed often enough. You can schedule the function to run periodically, or you can run the function on demand.

Warning

Important

The Check Assets function does not check recovery assets for nonrecoverable indexes.

The Check Assets function generates a DBRC GENJCL request for a recovery to current for the objects in a group. (The databases do not have to be closed or placed in read-only mode before you initiate the function.) The GENJCL request returns a list of the assets that are required for recovery of each object in the list. It also provides information about the status of the assets (for example, whether any asset is marked in error or missing and whether a merge-needed condition exists). Then the Check Assets function checks the operating system catalog to make sure that each asset is cataloged.

Hold Point of Consistency function

A recovery point for an IMS object is a point to which the data can be restored without compromising data integrity.

Standard recovery points occur after a batch image copy or an online image copy in which no overlapping database updates have occurred and when database updates are halted after a /DBR or /DBD command is processed for an online database from all IMS systems that are sharing the database.

Some applications have objects that are related to each other through physically defined relationships. Other databases and data sets are logically related at the application level. When a recovery takes place, you must restore all of these objects to the same recovery point. If you omit one of the objects, data integrity problems occur. A serious challenge in the recovery process is ensuring that you recover all of the objects involved in both physical and logical relationships to the same recovery point.

Recovery points should be established frequently enough to ensure that you can perform a recovery across all related databases and data sets within the parameters of your service level agreements. However, these standard recovery points may be difficult to establish, especially in a continuous-availability environment. Manually performing all the actions needed to establish a consistent recovery point across multiple databases is even more difficult.

RMGR offers the Hold Point of Consistency (HPC) function, which automates the creation of a recovery point (a point of consistency) for all databases that belong to a defined group. A point of consistency occurs when no update activity is occurring for the objects in a group. With the HPC function, you can obtain valid IMS recovery points across multiple objects on a scheduled basis (by initiating the function with a job scheduling package) and then recover a group to one of these recovery points. The HPC function allows for automatic synchronization of recoveries for full-function database data set groups, DEDB areas, and HALDB partitions.

The HPC function can simulate a /DBD command for a DEDB area to place it into read-only mode and create a recovery point. IMS does not provide this feature.

The BMC AMI Application Restart Control for IMS (AR/CTL) product can work with the HPC function to suspend batch message processing (BMP) programs automatically and resume them after the point of consistency is obtained.

Log Sync function

The Log Synchronization (Log Sync) function establishes a consistent disaster recovery point by synchronizing log switches for multiple IMS systems.

To record this disaster recovery point, the function writes a record to the repository that is associated with the RMGR or with the RMGR sharegroup. In a disaster recovery scenario, you can select this recovery point with the RMGR Find Recovery Points function, from the Recovery Options panel in the ISPF interface, or by specifying LOGSYNC as the value for the RECOVERTO keyword in the Batch Interface utility. To perform the recovery, you must use the BMC Recovery utility.

Find Recovery Points function and Log Analysis function

A standard full recovery, in which you recover the object to current, is usually a straightforward process.

However, performing a standard full recovery is not always possible or appropriate, and you may need to recover to a timestamp or point in time other than current. This type of recovery often requires extensive research and analysis of the situation to answer important questions, such as the following:

  • What was the problem, and when did it occur? Did it affect a single database or a group of related databases?
  • What is the general time frame when the database (or all of the databases in the group) were still correct and complete?
  • Was the database (or any database in the group) allocated for update activity at this time? If so, was update activity actually occurring during the time frame that you want to use for the recovery?
  • If no recovery windows (quiet periods when no update activity was occurring for any database in the group) are found, what transactions and processes were updating the databases?

For recovery of a single database, these problems will take some time to answer, and the database remains unavailable while you do so. If you perform the process manually, the analysis time (and elapsed down time) grows exponentially when you must analyze a group of databases.

The Find Recovery Points (FRP) function and the Log Analysis (LGA) function help you identify and evaluate candidate recovery points and recovery windows. Selecting the most appropriate one for a particular recovery situation is far faster, easier, and more reliable with these interactive tools.

The FRP function searches the DBRC recovery control (RECON) data sets and RMGR repository to find recovery points that may have occurred for the selected group of databases during the time range you want to consider. A recovery point can be the timestamp of a batch image copy, the timestamp of a database deallocation record (which can be created with the Hold Point of Consistency function), or a disaster recovery point (which can be created with the Log Sync function).

The LGA function searches the IMS system log data sets (SLDSs) and PRILOG records to find information about online transactions, batch message processing programs (BMPs), and batch DL/I jobs that have updated objects. Analysis of these records indicates not only the time ranges when updates were occurring, but also the time ranges when updates were not occurring. A time range when no updates were occurring indicates the presence of a recovery window that may be appropriate for a point-in-time (PIT) recovery that can be performed by the BMC Recovery utility.

The FRP and LGA functions identify the recovery points and recovery windows that are available for each object in the group and that are common to all databases in the group. You can work with the information interactively to include or exclude objects and to narrow time ranges. You can also display the information in a variety of ways.

Create Recovery JCL function

All of the plans, preparations, and decisions you make in your recovery strategy ensure the success of the main event--the recovery process itself.

When the time comes for performing a recovery, the Create Recovery JCL function helps you get the recovery process running as quickly and efficiently as possible. You initiate this function interactively or with a batch utility. The function builds recovery JCL for a selected group of objects according to the recovery options and information that you specify. After the function completes, you can interactively edit and submit the created JCL to perform the recovery and related processes.

You specify the options and information to use for the recovery in one or more predefined profiles and when you initiate the function. The options and information you can specify include the following:

  • You can choose the recovery point to use: current, the last batch image copy with an optional timestamp, the last point-in-time (PIT) change accumulation, a standard timestamp, the last Log Sync PIT timestamp, the Disaster Recovery RECON Cleanup utility PIT timestamp, or any other PIT timestamp.
  • You select the data set and member to contain the created JCL and, for a connecting group, whether to write the JCL to a combined member or separate members.
  • If you are using the BMC Recovery utility, you can specify whether to create JCL that can be automatically restarted.
  • If you are using the BMC Recovery utility, you can request a simulated recovery. You might want to request a simulated recovery to verify the results of a recovery before the utility updates any elements in the environment. You can request a simulated recovery to the last batch image copy or to any timestamp. Databases are not stopped during a simulation.
  • If you are using the BMC Recovery utility, you can specify whether to recover objects to alternate data sets and, if so, the data set name mask to use and whether and how to generate JCL for allocating the alternate data sets. You can use these data sets for testing and other purposes.
  • You can choose whether to issue commands to close the databases:
    • If you are using the BMC Recovery utility, the Create Recovery JCL function creates /DBR commands in the recovery JCL. (This action is not available if you are using the IMS Database Recovery utility.)
    • If you are using the IMS Database Recovery utility, RMGR issues /DBR commands for the databases in the specified group immediately when you submit the Create Recovery JCL function for execution.
    • RMGR can bypass issuing /DBR commands. If you are using the IMS Database Recovery utility, this action results in sample JCL (created while databases are allocated to the IMS online region).
  • You specify information about the utilities for performing the recovery process and related tasks. The Create Recovery JCL function builds optimal JCL for the utilities you are using.
  • You can choose whether to create JCL to perform an image copy of the recovered databases. The image copy process can produce a single image copy or dual image copies and, depending on the image copy utility you use, can be performed during the recovery process or in a separate step that executes after the recovery process.
  • If change accumulation is optional in this situation, you can choose whether to build change accumulation JCL. The Create Recovery JCL function automatically builds change accumulation JCL whenever this process is required.
  • You can choose whether and how the Create Recovery JCL function places database start (/STA) commands in the recovery JCL.
  • You can choose whether to use secondary image copies, secondary logs, or both as input if these assets are available. This option is useful if a primary data set has been damaged or in a disaster recovery scenario when you have sent secondary data sets to the disaster recovery site.
  • You can choose whether to create JCL to delete and redefine the database data sets.
  • You can choose whether to create JCL to rebuild secondary indexes and Fast Path indexes. Rebuilding indexes from the primary database, rather than recovering them from an image copy, can help reduce resource consumption because you do not need to maintain image copies for the indexes.
  • You can choose whether to create JCL to perform pointer validation as part of the overall recovery process. By checking the pointers in the recovered database, you are assured that the database is structurally valid and that no problems were introduced by the recovery process.

Create Image Copy JCL function

The Create Image Copy JCL function provides an easy and efficient way to generate JCL to back up objects in an elemental or connecting group.

The BMC Image Copy utility is used to perform the backup. You can specify options to use for the image copy in one or more predefined profiles:

  • You select the data set and member name to contain the created JCL.
  • You can specify whether to create JCL that can be automatically restarted.
  • You can choose whether to use predefined models for output image copy data sets.
  • You can choose whether to make one or two copies.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC AMI Backup and Recovery for IMS 5.2