IBM Support

PK84689: ABEND U384-2C DUE TO TEMPORARY DATASET NAME CONFLICT

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • ABEND U384-2C DUE TO TEMPORARY DATASET NAME CONFLICT
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All IMS DRF V3R1 clients that employ the     *
    *                 Integrated Auxiliary Utilities; e.g. HPIC.   *
    ****************************************************************
    * PROBLEM DESCRIPTION: U384-02C ABEND with FRD9003A+FRD4100I   *
    *                      due to failed dynalloc of temp DSN.     *
    ****************************************************************
    * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
    ****************************************************************
    When 2 or more DRF Master Address spaces are simultaneously
    active, it is possible that a temporary dataset name is
    allocated to one MAS and a 2nd MAS attempts dynamic allocation
    for the same dataset. Previously, the DRF MAS attempting
    dynamic allocation took user abend U384-02C; however this
    situation is not serious. Now the DRF MAS skips the allocation
    and instead issues message FRD4101W and ends with RC=4.
    
    FRD4101W:
    ABOVE DSNAME NOT DELETED. PLEASE DELETE IF RPTRET=Y IS USED.
    
    Explanation of FRD4101W:
    
    This message always follows two messages: FRD9003A (dynamic
    allocation error) and  FRD4100I (identifies DSNAME that failed
    dynamic allocation). DRF was attempting to dynamically allocate
    DSNAME with DISP=(OLD,DELETE,DELETE) so that it could be
    deleted; however, the attempt failed for the reason indicated
    in FRD9003A. DSNAME is a temporary data set that
    contains messages related to the recovery; it does not contain
    recovery assets such as a DBDS, a Log, an Image Copy or a Change
    Accumulation file.
    
    If the RPTRET=Y parameter on the REPORT control card is used,
    the DSNAME should be manually deleted because it is possible
    that DRF will attempt to use the DSNAME again on a subsequent
    recovery. If RPTRET=N is used, DRF will delete this DSNAME if
    it is needed on a subsequent recovery and then allocate DSNAME
    as a new data set.
    

Problem conclusion

  • GEN:
    KEYWORDS:
    
    *** END IMS KEYWORDS ***
    Apply this service.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PK84689

  • Reported component name

    IMS DB RECOVERY

  • Reported component ID

    5655I4400

  • Reported release

    310

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2009-04-14

  • Closed date

    2009-05-16

  • Last modified date

    2009-10-01

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

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

    UK46679

Modules/Macros

  •    FRXBDMG0 FRXRAUX0
    

Publications Referenced
SC18940704    

Fix information

  • Fixed component name

    IMS DB RECOVERY

  • Fixed component ID

    5655I4400

Applicable component levels

  • R310 PSY UK46679

       UP09/05/21 P F905

[{"Line of Business":{"code":null,"label":null},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCX88Z","label":"IMS Database Recovery Facility"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.1.0"}]

Document Information

Modified date:
09 November 2020