IBM Support

PH19594: REORG SPENDS A VERY LONG TIME IN LOG ITERATION CAUSED THE TIMEOUT IN THE APPLICATION

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • REORG spends a very long time in the Log Iteration and causes
    timeout in the application transactions.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * All Db2 11 for z/OS and Db2 12 for z/OS                      *
    * users of REORG SHRLEVEL CHANGE or REFERENCE                  *
    * utility                                                      *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * Extended duration of REORG last log                          *
    * iteration resulted in application                            *
    * timeout                                                      *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Apply corrective PTF when available                          *
    ****************************************************************
    During a REORG execution with log phase processing, the utility
    decided to break-in on the very first major log iteration in
    the LOG phase.  However, due to the short elapsed time of the
    REORG job to the start of the LOG phase, coupled with a high
    volume of log records generated in the same period of time,
    REORG was not able to process the last log iteration within
    the effective MAXRO value and subsequently caused concurrent
    applications to timeout due to the extended outage.
    The reported problem was caused by inaccurate and missing
    historical iteration statistics for REORG to correctly
    estimate the projected elapsed time of the very first major
    log iteration.  This problem can happen for REORG SHRLEVEL
    CHANGE as well as REORG TABLESPACE PART SHRLEVEL REFERENCE
    execution when there is a LOG phase.
    Additional keywords:  RC00C900BA DSNT500I SQLCODE-911
    

Problem conclusion

  • Code has been modified to alleviate the aforementioned scenario
    by ensuring REORG does not begin the last read-only iteration
    when it is the very first major log iteration.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PH19594

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    B10

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2019-11-24

  • Closed date

    2020-04-15

  • Last modified date

    2020-05-02

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

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

    UI69028 UI69030

Modules/Macros

  • DSNURLOG
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RB10 PSY UI69028

       UP20/04/23 P F004

  • RC10 PSY UI69030

       UP20/04/23 P F004

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"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
04 May 2020