IBM Support

DFSMShsm: Resolving intermettent ARC1806E RC10 messages when adding/removing volumes from a Copy Pool and Copy Pool Backup Storage Group

Troubleshooting


Problem

In an example scenario, a user added new volumes to a storage group that is part of a copy pool (IE: DSN$JV$DB) and also added volumes to the copy pool backup storage group. Afterwards, an FRBACKUP PREPARE was executed which failed with an ARC1806E RC10. This indicates that an eligible backup storage group target volume could not be found for a storage group source volume in the copy pool. Though a subsequent FRBACKUP was successful, the next FRBACKUP failed as well with an ARC1806E RC10. 

Although the user identified an error with the volumes that were added and corrected that error, all subsequent FRBACKUPs and FRBACKUP PREPAREs failed for this copy pool.

Symptom

ARC1806E FAST REPLICATION BACKUP HAS FAILED FOR COPY POOL cpname VOLUME volser, RC=10

Environment

In the example scenario, the copy pool has the 'Number of DASD Fast Replication Backup Versions with Background Copy' parameter set to 2 and the FRBACKUP command used does not dump the target volumes to tape. With a value of 2, this means that the copy pool backup storage group must contain 2x the number of volumes in the copy pool itself and the target volumes must be eligible FlashCopy targets for the source volumes.

Diagnosing The Problem

Take the following steps to diagnose the issue:

  1. Focus on what transpired that caused the first ARC1806E RC10
  2. Gather the following documentation:

    1. PDA from all HSM hosts issuing FRBACKUP commands covering the timeframe the first FRBACKUP PREPARE was issued, through the time the last ARC1806E RC10 was surfaced. If the issue can be recreated, the commands below may be issued to aid in problem diagnosis. The SETSYS command causes HSM to issue ARC1809I messages which provide information about why HSM did not pair certain source and target volumes. The PATCH command causes additional PDA trace points to be recorded during FRBACKUP.

      SETSYS FASTREPLICATION(VOLUMEPAIRMESSAGES(YES))
      PATCH .FRGCB.+80 BITS(.1......)

      To revert the changes:

      SETSYS FASTREPLICATION(VOLUMEPAIRMESSAGES(NO))
      PATCH .FRGCB.+80 BITS(.0......)

    2. SYSLOG from all HSM hosts issuing FRBACKUP commands covering this same time frame
    3. A list of the volumes added or removed from the copy pool, as well as added or removed from the copy pool backup storage group prior to the first FRBACKUP PREPARE that surfaced the ARC1806I RC10
    4. LIST CP(copypoolname) ODS(outputdataset)
    5. LIST CPBSG(copypoolbackstoragegroupname) ODS(outputdataset)
    6. AUDIT COPYPOOLCONTROLS NOFIX ODS(outputdataset)
    7. AUDIT COPYPOOLCONTROLS(copypoolname) NOFIX ODS(outputdataset)

    8. HSM Journal covering this same timeframe

      The following JCL may be used to make a copy of the journal:

       

      //S1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DISP=SHR,
// DSN=inputdatasetname
//SYSUT2 DD DISP=(NEW,CATLG),
// DCB=(LRECL=32756,BLKSIZE=32760,RECFM=VB),
// UNIT=SYSDA,SPACE=(CYL,(100,30),RLSE),
// DSN=outputdatasetname

      *depending on the size of your journal, you may wish to change the
      SPACE allocation for the new dataset, as well as the UNIT it is to be
      allocated to

    9. Use the output from steps 2-7 to attempt to determine the root cause of the issue

    10. If you are not able to determine the root cause of the issue, engage DFSMShsm Support

       

Resolving The Problem

If multiple FRBACKUP PREPAREs and FRBACKUPs have been issued and continually fail with an ARC1806E RC10 even though it is believed the root cause was identified and corrected (for example, not adding enough volumes to the copy pool backup storage group to account for the number of backup versions kept on DASD), it may be that the FRBACKUP records for this copy pool and copy pool backup storage group are in an unpredictable condition and this condition is preventing a successful execution of the FRBACKUP PREPARE or FRBACKUP command.

To correct this problem: 
Since the only backup copies were on DASD and the target volumes were reinitialized (due to the failed FRBACKUP), users may issue an FRDELETE of the failed version. This should delete all the FRBACKUP records related to that failed copy pool version and allow HSM to "start over" when the next version is created.

Issue the following command to delete the FAILED backup version:

FRDELETE CP(copypoolname) VERSIONS(xxx) 

*where xxx is the failed version number.

The next FRBACKUP PREPARE should end with RC0, as well as the next FRBACKUP.

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB56","label":"Z HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG90","label":"z\/OS"},"ARM Category":[{"code":"a8m0z0000000AGRAA2","label":"DFSMS-\u003EHSM-\u003EFRBACKUP"}],"ARM Case Number":"TS020456824","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"2.3.0;2.4.0;2.5.0;3.1.0;3.2.0"}]

Document Information

Modified date:
20 February 2026

UID

ibm17255432

Page Feedback