IBM Support

A fix is available


You can track all active APARs for this component.

APAR status

  • Closed as new function.

Error description

  • Serviceability APAR for LOAD utility

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All DB2 10 for z/OS users of LOAD utility.   *
    * PROBLEM DESCRIPTION: New option for LOAD to generate unique  *
    *                      value for TIMESTAMP column with default *
    *                      precision when not provided by the user *
    * RECOMMENDATION: Apply PTF when available                     *
    User has a table with a unique index defined on a TIMESTAMP
    NOT NULL WITH DEFAULT column, and the LOAD utility is used to
    populate this table with LOAD generating the default timestamp
    value for this column at run time as each record is loaded
    (i.e. user does not provide input value for this column in the
    SYSREC input dataset).
    The above scenario would work as long as the rate of the data
    records being loaded is slower than the highest precision of
    the TIMESTAMP value, resulting in a unique timestamp value for
    each record loaded.  However, after user upgrades to the newer
    faster hardware (e.g. EC12), LOAD is running so fast that the
    same store clock value is generated on the TIMESTAMP column of
    consecutive records loaded.  This resulted in a LOAD failure
    due to unique index key violation in the SORTBLD phase.
    Fundamentally, the above issue is caused by the database design
    where non-unique TIMESTAMP values are used as unique keys, and
    this problem could have happened anytime in the past, with the
    hardware upgrade increases the likelihood of its occurrence.
    As an alternative approach, user can define the unique keys on
    higher precision TIMESTAMP column starting in DB2 V10 NFM, or
    define the unique keys using multiple columns to further
    guarantee uniqueness.
    To provide temporary relief for users hitting this issue, a
    new undocumented option is introduced for the LOAD utility to
    ensure uniqueness of generated TIMESTAMP column values on
    consecutively loaded records.  This function is triggered when
    DIAGNOSE TYPE(556) is specified, as in the example below:
    //SYSIN    DD *
       DIAGNOSE TYPE(556)
    Note that this uniqueness checking is only applicable to a
    single RELOAD task, so user can still encounter non-unique
    TIMESTAMP values when load partition parallelism is used,
    with or without DIAGNOSE TYPE(556) specified.

Problem conclusion

Temporary fix


  • Code has been modified to provide support on the aforementioned
    DIAGNOSE TYPE processing during LOAD execution.

APAR Information

  • APAR number


  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention


  • Submitted date


  • Closed date


  • Last modified date


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

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




Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID


Applicable component levels

  • RA10 PSY UK95285

       UP13/07/09 P F307

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.

Document information

More support for: DB2 for z/OS

Software version: 910

Reference #: PM85771

Modified date: 2013-08-02