PM81805: MODIFY RECOVERY PLACES A PART IN COPY PENDING STATUS WHEN THERE ARE NO MORE IMAGE COPIES, BUT A VALID SYSTEM LEVEL BACKUP EXISTS

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Customer runs SYSTEM BACKUP so has SLB available as a recovery
    base.  They also have zparm SYSTEM_LEVEL_BACKUPS turned on.
    Reorg is run on some partitions of a partitioned table space,
    but not all parts.
    
    If Modify removes all the image copies for one of the
    partitions that has NOT been reorganized, it is set to
    COPY PENDING ( MSGDSNU380I ).  SLB should be able to be used
    as a recover base for that partition.
    

Local fix

  • execute image copy to remove copy pending status
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All DB2 9 for z/OS and DB2 10 for z/OS users *
    *                 of MODIFY RECOVERY utility at table space    *
    *                 level on a partitioned table space.          *
    ****************************************************************
    * PROBLEM DESCRIPTION: MODIFY RECOVERY at table space level    *
    *                      on a partitioned table space left some  *
    *                      partitions in COPY-pending (COPY)       *
    *                      status and issued MSGDSNU380I when no   *
    *                      more image copies remained in SYSCOPY   *
    *                      but a valid system level backup (SLB)   *
    *                      existed.                                *
    ****************************************************************
    * RECOMMENDATION: Apply corrective PTF when available.         *
    ****************************************************************
    REORG LOG NO utility at part level on a partitioned table space
    was run after a system level backup (SLB) was made by BACKUP
    SYSTEM utility. Then, MODIFY RECOVERY utility at table space
    level left partitions which had not been REORGed in COPY PENDING
    status even if the SLB was more recent than the user-specified
    date or age of the MODIFY RECOVERY and could be used for
    recovery of those parts. This is because the logic that
    determines whether or not a SLB is a valid recovery base is
    done at the table space level when MODIFY RECOVERY is at table
    space level.
    
    The same issue occurs when LOAD LOG NO, LOAD REPLACE LOG NO
    or MODIFY RECOVERY at part level was run after SLB.
    

Problem conclusion

  • The MODIFY RECOVERY utility executed at the table space level
    now correctly considers LOG NO utility events at the partition
    level and will not place a partition in COPY-pending status if
    it can be recovered using a SLB.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM81805

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    910

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-01-31

  • Closed date

    2013-05-22

  • Last modified date

    2013-07-03

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UK94486 UK94487

Modules/Macros

  •    DSNUMDEL
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RA10 PSY UK94486

       UP13/06/07 P F306

  • R910 PSY UK94487

       UP13/06/07 P F306

Fix is available

  • Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

DB2 for z/OS

Software version:

910

Reference #:

PM81805

Modified date:

2013-07-03

Translate my page

Machine Translation

Content navigation