IBM Support

PK61511: FDBR ATTEMPTED TO ALLOCATE DELETED "A" SIDE INSTEAD OF ACTIVE "M" SIDE DATA SET DURING DYNAMIC BACKOUT AFTER AN EARLIER OLR

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • OLR ran on system IMSB to normal completion.  Later that day,
    an abend on IMS8 caused FDBR to do dynamic backout. The "A"
    side (deleted by OLR) was picked to allocate instead of the
    "M" side (active) data set that wrote the type50 log record
    being backed out.  The flow was as follows:
    1) FDBR(IMS8) backout failure of HALDB following OLR(IMSB)
    2) OLR of HOTLT1 was successfully completed at 11:58
       (Active now set for DBST.DSW4.HOTEL.M00001)
    3) DBST.DSW4.HOTEL.A00001 DELETED at 11:58:35
    4) Later the same day at 21:03, LPAR image J80
       which is where IMS8 was running failed.
       FDBR8 running on TPN, began backing out failed
       transactions, but then failed back out:
         DFS2503W DYNAMIC ALLOCATION   FAILED FOR  420
         (DFS2503W) DATASET NAME DBST.DSW4.HOTEL.A00001
         (DFS2503W) DATABASE HOTLT1   WITHIN PSB PROGHR2T
         REASON CODE 1708 FDR8
    5) Recon shows: ACTIVE DBDS=M-V
    The log record being backed out was written on IMS8 to an
    M-side data set (DDSID=81)
    DDIR for HOTLT1 on IMS8 shows DDIRORAM=00
    (OFF: A-J,X DATA SETS ARE THE ACTIVE OR INPUT SET).
    However, the M-side AMP shows: DMBORAM  EQU   X'80'
    M-V DATA SETS USED (BIT OFF=A-J) .
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All IMS V10 customers with High              *
    *                 Availability Large Databases ( HALDB )       *
    *                 using HALDB online reorganization            *
    *                 ( OLREORG ) which is tracked by a Fast       *
    *                 Database Recovery ( FDBR ) region.           *
    ****************************************************************
    * PROBLEM DESCRIPTION: Errors occur when a FDBR region gets    *
    *                      control and tries to backout the        *
    *                      updates for an OLREORG of a HALDB       *
    *                      partition.  A DFS2503W error message is *
    *                      issued because backout is trying to     *
    *                      allocate the A-J data sets while it is  *
    *                      the M-V data sets which are now active. *
    ****************************************************************
    * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
    ****************************************************************
    The customer was running in a data sharing environment where
    one of the IMS systems ( IMSA ) was being monitored by a fast
    database recovery ( FDBR ) region.  On the other IMS ( IMSB )
    a HALDB Online Reorg ( OLREORG ) was done against a partition.
    IMSA was notified of the OLR and it correctly built that AMPs
    for the now active data sets ( M-V ). The problem was that the
    FDBR region, associated with IMSA, only knows of changes by
    reading the log records from IMSA.  The information about the
    now active data sets ( M-V ) associated with the partition
    which was reorged was never logged so FDBR region only knew
    of the A-J data sets being active.
    
    A short time later, IMSA suffered an abend which brought down
    the control region.  The FDBR region, which was monitoring
    IMSA, automatically began the recovery process.  As part
    of this process FDBR allocated and opened all of the database
    data sets which IMSA had opened so that all of the updates can
    be backed out.  When trying to back out the updates associated
    with the OLR, backout failed because FDBR was trying to open
    The A-J data sets which were no longer active and had been
    deleted.  The customer got the following messages:
    
    DFS2503W DYNAMIC ALLOCATION   FAILED FOR  420
    (DFS2503W) DATASET NAME DBST.DSW4.HOTEL.A00001
    (DFS2503W) DATABASE HOTLT1   WITHIN PSB PROGHR2T REASON CODE
    1708 FDR8
    DFS629I IMS CTL TCB DUMP  - TYPE UNK          FDR8
    DFS629I PSW AT ERROR = *** NO SDWA ***    FDR8
    DFS3932I IMS DUMP REQUEST COMPLETED - RETURN CODE = 000  FDR8
    DFS984I UNABLE TO OPEN DATA BASE HOTLT1  , PROGRAM PROGHR2T FOR
    BACKOUT FDR8.
    
    To fix this backout problem on the FDBR region, the X'4C08'
    record has to be changed to log when the OLR is active
    ( DDIROLRA ) and when the M-V data sets are active
    ( DDIROLAM ).  When the FDBR region processes the X'4c08' log
    record it will check for these conditions and will set the
    corresponding bits in it's DDIR.  Later when FDBR begins the
    recovery process, it will open the correct side and will
    build the amps correctly for the backout.
    
    Additional Keywords: MSGDFS2503W MSGDFS984I
    

Problem conclusion

  • AIDS: RIDS/DBS RIDS/INTRF DBS INTRF
     GEN:
    KEYWORDS:
    
    *** END IMS KEYWORDS ***
    To fix this problem code was added to the following modules.
    
    ************
    * DFSDBAU0 *
    ************
    Code was added into the routine which builds the x'4C08' log
    record after label LOG4C08A.  Here the code will check if the
    cursor is active, DDIROLRA is on. If so, STLOLRA is set.
    The code will then check which of the OLR data sets are active
    A-J or M-V by checking a flag in the DDIR ( DDIRORAM is on if
    M-V data sets are active ). If the M-V data sets are active
    set STLOLRM.
    
    ************
    * DFSRESP0 *
    ************
    After label LG4C010A the code will check fields in the X'4C' log
    record to see if STLOLRA or STLOLRM are on.  If so, the
    associated bits in the DDIR ( DDIROLRA and DDIRORAM ) are set.
    
    
    ************
    * DFSLOG4C *
    ************
    Two new flag bits are set in flag byte STLFLG3 to indicate
    the following:
    
    STLOLRA is used to indicate that the OLR cursor is active.
    STLOLRM is used to indicate that DDIRADDR is pointing at the
    M-V data sets.
    

Temporary fix

  • *********
    * HIPER *
    *********
    

Comments

APAR Information

  • APAR number

    PK61511

  • Reported component name

    IMS V10

  • Reported component ID

    5635A0100

  • Reported release

    010

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2008-02-21

  • Closed date

    2008-08-13

  • Last modified date

    2009-02-02

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

    PK51418

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

    UK38952

Modules/Macros

  • DFSDBAU0 DFSLOG4C DFSRESP0
    

Fix information

  • Fixed component name

    IMS V10

  • Fixed component ID

    5635A0100

Applicable component levels

  • R010 PSY UK38952

       UP08/08/22 P F808 Ž

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.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.1","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCVRBJ","label":"System Services"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 February 2009