Merging BRMS Data to Target System with Existing BRMS

There are specific steps needed to be followed to move BRMS from a donor system to a target system when the target system has BRMS installed. BRMS is running backup policies on the target system, so there exists on this system history and media information owned by the target system. The merge operation basically consists of combining the BRMS data from the donor system with the BRMS data on the target system.  Because BRMS is already installed on the target system, no installation of BRMS is required.

Important: The merge operation is not intended to be used to recover data from an older version of the QUSRBRM library on the same system.  This may cause unpredictable results, such as duplicate records being generated.

Important: The merge operation is not intended to be used when running a FlashCopy backup process. This may cause unpredictable results, such as incomplete history or mismatched media

The merge steps are as follows:

  1. Ensure all prerequisites for merging BRMS data are met.

  2. Review the printed outputs of the data you intend to merge to assure there are no duplicates.  Only unique BRMS objects and information will be merged.

  3. If using Software Encryption, you might need to translate all the necessary keystore files in QUSRBRM

 On the donor system

  1. Verify you are signed on with a user profile with *SECOFR authority.

  2. If donor system is part of a BRMS network group, use the following command to display the active records for this system:

    • DSPPFM FILE(QUSRBRM/QA1ANET2)  
          Verify the QUSRBRM/QA1ANET2 file is empty.

  3. If you want to differentiate the media of the donor system from that of the target system, you can update the media records with unique text using a SQL command similar to the following example:

    • UPDATE QUSRBRM/QA1AMM SET TMTEXT = 'unique-text' WHERE TMSYID = 'donor’ AND TMCNET = 'network-ID’

    • Using network-ID.donor as specified in the System column when viewing locally owned media with WRKMEDBRM SYSNAME(*LCL)

  4. If you want to differentiate the save history of the donor system from that of the target system, you can update the history records with a unique control group using the following SQL command:

    • UPDATE QUSRBRM/QA1AHS SET BKHGRP=’new-control-group-name’ WHERE BKHGRP=’old-control-group-name’
          
      This step is optional and may not even be necessary if the save on the donor system was performed using control groups which do not exist on the target system.  Once you have completed the rename and merge the data to the target system, you will be able to view these older saves using the following command:
          
          WRKMEDIBRM CTLGRP(new-control-group-name)

  5. Save the QUSRBRM and Q1ABRMSF* libraries on donor system by using the following command:

    • SAVLIB LIB(QUSRBRM Q1ABRMSF*) DEV(tape_device)

    
    NOTE: You do not need to save the Q1ABRMSF* libraries if you do not intend to merge the save history of the donor system to the target system.

   
 On the target system

  1. Verify you are signed on with a user profile with *SECOFR authority.

  2. Save the QUSRBRM and Q1ABRMSF* libraries on target system using the command:

    • SAVLIB LIB(QUSRBRM Q1ABRMSF*) DEV(tape_device) - The save of these libraries will protect you in the event you need to back off the merge.

  3. If you intend to merge the save history of the donor system to the target system, you should use the following command to restore the save files in the Q1ABRMSF* libraries to the target system:

    • RSTOBJ OBJ(*ALL) LIB(Q1ABRMSF*) DEV(tape_device) ALWOBJDIF(*ALL) MBROPT(*ALL)

  4. Restore the QUSRBRM library from the donor system to a temporary library on the target system using the following command.

    • RSTLIB LIB(QUSRBRM) DEV(tape_device) RSTLIB(temp-library-name) ALWOBJDIF(*ALL) MBROPT(*ALL)

    • NOTE: Do not restore the QUSRBRM library from the donor system to the QUSRBRM library on the target system.

  5. Merge the BRMS data from the temporary library to QUSRBRM on the target system using the following:

    • If using Software Encryption and your keystore files had to be translated, you should issue this command:

      • INZBRM OPTION(*MERGE) FROMLIB(temp-library-name) TOLIB(QUSRBRM) MERGE(merge-options) KEYSTORE((source-keystore-file translated-keystore-file)) - You can specify more then one keystore file on the Keystore parameter.

    • Otherwise, issue this command:

      • INZBRM OPTION(*MERGE) FROMLIB(temp-library-name) TOLIB(QUSRBRM) MERGE(merge-options) - where merge options specifies the types of BRMS data to be merged.

    • NOTES: 

      1. Extensive file processing is involved in the merge operation and could be a long-running process depending on the  merge options you select and the size of the merged files.

      2. Reorganizing files in QUSRBRM on both donor and target system prior to the *MERGE operation may speed up file processing.

      3. All changes will be rolled back if the *MERGE is cancelled before completion.

      4. This process can be used when migrating from one system to another and the target system is at a higher release than the source system . If the donor system is not at a currently supported release, results may be unpredictable.

      5. BRMS does not verify if there is sufficient space on the system to merge the BRMS files. It is the users responsibility to ensure that there is enough space on the system for the restore of the QUSRBRM library from the donor system and additional space to merge the files into the current QUSRBRM library. 

  6. Review the job log or the BRMS log for messages related to the merge processing.  Verify the merge completed successfully.  Assure that objects not merged are not required.

  7. Verify the merged policies by editing or changing the policy using the standard BRMS interfaces.  Resolve any errors that may occur during the validation processing.

  8. If the target system has a different local location name, network ID, or system name than the donor system and you want to consider the saved history and media as now owned by the current system, you should transfer ownership of the merged BRMS data to the target system using the command:

    • INZBRM OPTION(*CHGSYSNAM) PRVSYSNAM(netword-id.donor-system-name) NEWSYSNAM(*LCL)

    
NOTE:  Merging BRMS data to a target system with existing BRMS will not merge save file history because of possible naming collisions on the target system. When consolidating systems and removing the source system from the BRMS network, if the target system is not changed to own the media and history from the source system by running the INZBRM OPTION(*CHGSYSNAM) function, history will be removed during a run of maintenance.  BRMS does not allow history from another system on the local system if the systems are not networked.



Restrictions

  1. If the data has been saved to save files, the history will only be merged on a system that has no other BRMS history.

  2. If the target and source system have IFS (*LNK) data that have the same save date/time stamp, the records will not be added to the history file.

  3. Object level detail for IFS data will not be added if the target and source systems have the same save date/time stamp or the same named object.

  4. Some directories will not be listed from the source system when a WRKLNKBRM is run after the merge is complete.

  5. Systems should have the List of BRMS Service Packs for the specific release applied

  6. No BRMS activity can occur on any system in the BRMS network while the merge is running.  It is recommended that the system running the merge be removed from the BRMS network and then added back in, once the merge is complete.

  7. BRMS does not verify if there is sufficient space on the system to merge the BRMS files. It is the users responsibility to ensure that there is enough space on the system for the restore of the QUSRBRM library from the donor system and additional space to merge the files into the current QUSRBRM library.

  8. If it is desired to merge only history information (not using MERGE(*ALL)), merge options *DEV, *MED and *HST must all be specified. If *DEV is not included with the merge and the BRMS devices are not the same on the source and target systems, all BRMS history data may not be merged. *MED is required because if only history exists with no volume information, BRMS may delete the history.   For example, use the following command to merge all BRMS media and history information:

    • INZBRM OPTION(*MERGE) FROMLIB(OLDLIB) TOLIB(QUSRBRM) MERGE(*MED *DEV *HST)  -  where OLDLIB is the library containing QUSRBRM/QA1AHS from the previous system.



Copyright © Fortra, LLC and its group of companies. All trademarks and registered trademarks are the property of their respective owners.