IBM Support

PM99575: CHANGE THE DISCARDDATA LOGIC FOR REAL FRAMES BASED ON THE CUSTOMER SETTINGS FOR REALSTORAGE_MANAGEMENT.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Existing logic, though working as designed, results in different
    behaviors based on customer workload and thread control
    specifications.  Desire is to move to more uniform and
    predictable function.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All DB2 V10 and V11 users.                   *
    ****************************************************************
    * PROBLEM DESCRIPTION: Functional change to the way 64-bit     *
    *                      REAL storage frames under DB2 storage   *
    *                      management control are handled when     *
    *                      FREE.  Eligible FREE frames will now be *
    *                      returned to z/OS RSM by using           *
    *                      KEEPREAL(YES) on the DISCARDDATA        *
    *                      under normal execution.                 *
    *                      If the user has specified zparm         *
    *                      RealStorage_MAX and DB2 reaches that    *
    *                      limit, or system experiences Auxiliary  *
    *                      storage shortage, KEEPREAL(NO) will     *
    *                      be specified until the condition is     *
    *                      relieved.                               *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    Currently, when DB2 has FREE frames eligible for discard back to
    z/OS RSM, the use of KEEPREAL(NO) tells RSM to remove ownership
    immediately.  This results in a new first reference Page Fault
    and the associated CPU cost when those pages are again used by
    DB2.  This does however, allow DB2 to provide accurate
    statistics on how much REAL storage is being used by each DB2
    for their 64-bit shared and common storage.  The current logic
    does the DISCARDDATA under the control set by the user zparm
    RealStorage_Managment as either ON, OFF, AUTO and certain
    additional system critical events such as Auxiliary storage
    shortage.  The default setting is AUTO which tells DB2 to
    perform the DISCARDDATA only if the system is PAGING.  This
    occurs only when thread pool storage is contracted as part of
    commit processing or freed when the thread is de-allocated.
    If during contraction or de-allocation, the LPAR is not paging
    when the storage is returned to DB2's large storage object, it
    is done without the REAL frames being discarded or unbacked.
    Those frames will remain backed even if paging occurs,
    until those frames are again allocated to an active thread.
    This sequestering of backed frames, can result in unnecessary
    system paging and prevent real storage reconfiguration on the
    LPAR.
    

Problem conclusion

  • DB2 is changing the logic for DISCARDDATA back to KEEPREAL(YES)
    and always performing the discard unless the user has elected to
    retain all backed frames by specifying RealStorage_Management =
    OFF.  If RealStorage_Management = OFF, frames will only be
    discarded if a critical storage event is detected by DB2 storage
    monitor and DB2 goes into discard mode. This allows z/OS to
    steal those frames should that become necessary.  If the user
    has specified RealStorage_MAX and DB2 hits that level or if
    the LPAR experiences critical auxiliary storage shortage, DB2
    will change DISCARDDATA to KEEPREAL(NO).  This remains in effect
    as long as DB2 is in discard mode for those events.
    Since z/OS RSM tracks 64-bit Shared and Common only at the LPAR
    level, DB2 Real Frame statistics will only be able to provide
    numbers which are worst case. This worst case value may result
    in DB2 termination with RC00E20033 for RealStorage_MAX even
    though many of the Shared frames have been discarded with
    Keepreal(YES). For LPARs which do not page, the
    REAL frame usage values before and after PM99575, will remain
    about the same since RSM maintains the charge against DB2 for
    discarded KEEPREAL(YES) frames which have not been stolen.
    Summary of results:
    After PM88804                   After PM99575
    * Auxiliary shortage means      * Auxiliary shortage means
        DISCARDDATA KEEPREAL(NO)        DISCARDDATA KEEPREAL(NO)
    * REALSTORAGE_MANAGEMENT=OFF    * REALSTORAGE_MANAGEMENT=OFF
        No DISCARDDATA                  No DISCARDDATA
    * REALSTORAGE_MANAGEMENT=AUTO   * REALSTORAGE_MANAGEMENT=AUTO
      with no paging means            with no paging means
        No DISCARDDATA at Thread        DISCARDDATA KEEPREAL(YES)
        De-allocation or 120 Commits    at Thread De-allocation or
                                        120 commits
    * REALSTORAGE_MANAGEMENT=AUTO   * REALSTORAGE_MANAGEMENT=AUTO
      or ON with paging means         or ON with paging means
        DISCARDDATA KEEPREAL(NO) at     DISCARDDATA KEEPREAL(YES) at
        De-allocation or 30 commits     De-allocation or 30 commits
        and STACK is also discarded     and STACK is also discarded
    * REALSTORAGE_MAX specified     * REALSTORAGE_MAX specified
      means                           means
        DISCARDDATA KEEPREAL(NO) at     DISCARDDATA KEEPREAL(NO) at
        80%                             100%
    .
    If you have XCF CRITICAL PAGING ENABLED, you also need to apply
    z/OS RSM APAR OA44913. Without this apar, the KEEPREAL(YES)
    Shared frames are not stolen to replenish frame queues when
    paging occurs.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM99575

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    A10

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-10-21

  • Closed date

    2014-04-15

  • Last modified date

    2014-06-09

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

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

    UI17080 UI17081

Modules/Macros

  • DSNSCON2 DSNSCTL  DSNSVSFM DSNSVSPC DSNSVSVP DSNVMON
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RA10 PSY UI17080

       UP14/05/01 P F404

  • RB10 PSY UI17081

       UP14/05/01 P F404

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":"10.1","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":"10.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
09 June 2014