IBM Support

PI66358: ABEND0C4 RC4, LOCATION DSNXGRDS DSNXSRME OFFSET00584

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • ABEND0C4 rc4, location dsnxgrds dsnxsrme OFFSET00584
    (d184537)
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * All DB2 12 for z/OS users of queries that require a sort.    *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * An ABEND0C4-00000004 can occur at location DSNXSRME+584 when *
    * runtimes thinks sort wants it to complete the sort           *
    * processing when in actuality the final result was placed in  *
    * a physical workfile because on the subsequent execution of   *
    * the same query, no in-memory storage was available to use.   *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    An ABEND0C4-00000004 can occur at location DSNXSRME+584 when
    runtimes thinks sort wants it to complete the sort processing
    when in actuality the final result was placed in a physical
    workfile because on the subsequent execution of the same query,
    no in-memory storage was available to use.  This problem may
    occur when on the first invocation of the query, there was
    enough in-memory storage to use and sort sets the access type
    for runtime to complete it.  On the subsequent (or future)
    invocations of the query, for some reason, there is not enough
    in-memory storage for sort or DM to get; it sets bit to say that
    sort is to put the results into a physical workfile and no merge
    phase.  The problem is that sort didn't reset the bit back after
    skipping the merge phase so it can put back the access type back
    to its original value.
    

Problem conclusion

  • DB2 has been modified to reset the bit back to its original
    value after merge phase so sort can let runtime reset the proper
    access type if some failure in getting in-memory storage for
    future invocations of the same query.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI66358

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    C10

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-07-22

  • Closed date

    2016-08-15

  • Last modified date

    2016-09-02

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

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

    UI40112

Modules/Macros

  • DSNXSORI
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RC10 PSY UI40112

       UP16/08/18 P F608

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":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"12.0","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"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":"12.0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 September 2016