Using BRMS to Duplicate Another Systems Media

DUPMEDBRM works when duplicating media that is owned by another system in the BRMS network . In this example, there are two systems:  SYSA and SYSB.

Setting Systems Up for Remote Duplication and How BRMS Does the Remote DUPMEDBRM

1. BRMS network feature must be installed and systems must be added to the BRMS network.
2. SYSA and SYSB must have the Receive media information in the system policy set to *LIB.
   • Note:  This must be set before the save on SYSA is done.
   • WRKPCYBRM TYPE(*SYS)
   • Press the Enter key.  Then, select Option 4.
     
     • F11 and change the Local Receives to *LIB    
3. The save is done on SYSA and once complete, the volume is owned by SYSA.  The information will be synched or networked to the other systems in the BRMS network.
4. The remote DUPMEDBRM is started on SYSB, specifying a volume owned by SYSA, and SYSA is specified as the remote system.  On the operating system command line, type the following:
   • DUPMEDBRM VOL(BRM001) FROMDEV(TAPMLB01) TODEV(TAPMLB02) FROMVOL(BRM001) FROMSYS(SYSA)
   • Press the Enter key.
5. Under the covers, SYSB takes ownership of the input volume and starts to duplicate to it, using local data (which is why receiving *LIB information is important).
6. DUPMEDBRM goes through regular volume selection to find an output volume and takes ownership of it.
7. During duplication on SYSB, the history records are also duplicated and placed into SYSB's database.  Then, they are synched back to SYSA by the network synchronization job.
8. After duplication, both the input and output volumes are reassigned to SYSA

NOTES:

1. The system running the remote DUPMEDBRM must be at the same release or higher than the system that owns the media.
2. Both the from device (FROMDEV) and to device (TODEV) must have a physical connection to the system performing the DUPMEDBRM.
3. It is important that BRMS maintenance or the Reclaim Wizard is not run on the owning system or the system during the duplication. History will be lost if this occurs.
4. It is possible to save the BRMS recovery information at the end of the duplication. However, this is intended for local duplications only. When doing remote DUPMEDBRM, the SAVMEDINF parameter needs to be set to *NONE.
5. The source system where the saves were done on has to be up and remain up until the remote duplication is complete.
6. BRMS can only duplicate media if there is active history for the volume(s) in the BRMS data base (WRKMEDIBRM)
7. When using IASP FlashCopy - Specific System Synchornization, the volume(s) need to be duplicated on the system that did the backup as the duplicate history ownership will be lost when remote duplicates are done.

Troubleshooting Problems

1. Nothing is duplicated on SYSB.
   •          Q1ABRMNET subsystem is not running on SYSB
   •          QBRMSYNC job is hanging
   •          Receive media Information is system policy is not *LIB on SYSB
2. BRM15A2 - Volume &1 cannot be duplicated by this system.
   •     The DUPMEDBRM command did not specify a remote system name.
3. WRKMEDIBRM VOL(duplicate volume) does not list anything on SYSA.
   • QBRMSYNC job not running or is still sending data to SYSA
   • SYSA does not have Receive Media Information in the system policy set to *LIB
   • Volumes are owned by SYSB.
   • Reassignment failed and did not change volumes back to SYSA because the DUPMEDBRM was cancelled by user.
4. When using this command, users must be aware that they cannot run the DUPMEDBRM  command for a remote system and the DUPMEDBRM  VOL(*SEARCH) command for the local volumes at the same time.  This causes the DUPMEDBRM of the local volumes to fail with message CPF412F.
5. The STRMNTBRM or RMVMEDIBRM command should not be run on the system doing the duplication or on the system that owns the media while the DUPMEDBRM command is running .  If this occurs, the save history on the system owning the volumes will be removed and running the WRKMEDIBRM or WRKMEDBRM command, Option 13 on the original volume will not list anything.
6. DUPMEDBRM requires that BRMS has history of the volume in it's history files on the system running the duplication.  If this history is missing, the duplication will complete successfully (BRM1566 will be posted) but nothing is duplicated.  A common reason the system performing the remote DUPMEDBRM operation did not get it's history updated can be a result of not following Step 2 of this knowledgebase document.
7. Ensure DDM is running on both servers.