RPCR scenarios

The RPCR function can assist you in creating a valid recovery point.

When attempting to create a valid recovery point during which one or more databases are not being updated, perform the following tasks:

  • Manually /DBR or /DBD a single database or group of databases
  • Manually start the databases after all of the databases were stopped to create a recovery point during which the databases were not allocated to an online subsystem.

    However, this manual process is error prone because, not only would you have to manually verify that each IMS command is done correctly in all IMS subsystems, you would also manually have to verify that the databases were not started or allocated before all of the databases in the list are deallocated (both batch and online).

    This manual processing could be inconvenient and this processing can cause the databases to remain offline for some amount of time.

The IMS Database Recovery Facility Extended Functions RPCR function can help you create a valid recovery point easily, without manually invoking the IMS commands and simultaneously verify that the DBDSs were not reallocated by any other subsystem or batch job during the deallocation process.

RPCR also pauses any BMPs that have the databases allocated to allow the deallocation of all of the databases in the list to occur simultaneously.

Here are some scenarios that might be applicable to your environment:

Scenario 1: Determine if a large group of allocated databases can be deallocated

In this scenario, you deallocate a large group of databases that are allocated and updated by several online subsystems to create a valid recovery point.

  1. Run the RPCR function with PARTIAL(N) to perform all of the following tasks:
    1. Quickly pause any BMPs that have reached a checkpoint or prevent any BMPs that have not yet started during the process.
    2. Successfully deallocate all of the databases in the list for all of the IMS subsystems that have the databases allocated.
    3. Verify that no other jobs or subsystems have accessed the databases during the time it took for the RPCR deallocation to complete.
    4. Immediately restart the databases in their appropriate online systems with little or no impact to the online systems.
    5. Generate a report with the timestamp of the last database that was deallocated by RPCR.

      This timestamp can be used as a common recovery point for all of the databases in the list.

      If any of the databases in the list could not be deallocated, the entire process fails.

      The report indicates which databases caused the process to fail.

Scenario 2: Determine if a small group of unrelated databases can be deallocated

In this scenario, you deallocate a small group of databases that are unrelated to each other.

  • Run the RPCR function with the PARTIAL(Y) option to quickly deallocate the databases in the list for all IMS subsystems that have the databases allocated.

    A report is generated with the timestamp that the last database was successfully deallocated by RPCR.

    If any of the databases in the list could not be deallocated, the report indicates which databases failed and which databases were successful.