IBM Support

PI94872: Update operations that overlap an external load might not be mirrored correctly

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • If a table is being actively changed with update operations
    while it is being externally refreshed, an edge condition could
    occur that causes subsequent update records for that table to
    be mirrored incorrectly. Specifically, if the update is an
    out-of-place update, for example caused by a change in a
    partition or an increase in size, and the start of the external
    load is logged between the separate log records for the before
    and after images, then subsequent updates could be mirrored by
    using the before image of one update and the after image of
    another. Possible consequences could be lost data on the target
    if the earlier update used a key that is different than the
    later update. In this situation, the mirrored key change would
    have the net effect of deleting the record on the target based
    on the prior update.
    

Local fix

  • Re-do the external load ensuring that the table does not have
    in-flight updates at the time the start of the external load.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: Users of InfoSphere Change Data Capture for  *
    *                 z/OS.                                        *
    ****************************************************************
    * PROBLEM DESCRIPTION: If a table is being actively changed    *
    *                      with update operations while it is      *
    *                      being externally refreshed, an edge     *
    *                      condition could occur that causes       *
    *                      subsequent update records for that      *
    *                      table to be mirrored incorrectly.       *
    *                                                              *
    *                      Specifically, if the update is an       *
    *                      out-of-place update, for example        *
    *                      caused by a change in a partition or    *
    *                      an increase in size, and the start of   *
    *                      the external load is logged between     *
    *                      the separate log records for the        *
    *                      before and after images, then           *
    *                      subsequent updates could be mirrored    *
    *                      by using the before image of one        *
    *                      update and the after image of another.  *
    *                                                              *
    *                      Possible consequences could be lost     *
    *                      data on the target if the earlier       *
    *                      update used a key that is different     *
    *                      than the later update. In this          *
    *                      situation, the mirrored key change      *
    *                      would have the net effect of deleting   *
    *                      the record on the target based on the   *
    *                      prior update.                           *
    ****************************************************************
    * RECOMMENDATION: APPLY CORRECTIVE SERVICE                     *
    ****************************************************************
    The code that constructs update operations from their
    corresponding log records incorrectly associated the second log
    record of the split update with the first log record of the
    next update for that table. Because the split update cannot be
    reconstructed due to the usage pattern of the external load, it
    should be discarded. This process allows following updates to
    be processed normally.
    

Problem conclusion

  • The code that constructs update operations from their
    corresponding log records was modified to discard the split
    update.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI94872

  • Reported component name

    INFO SRVR CDC Z

  • Reported component ID

    5655U7600

  • Reported release

    A21

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-03-08

  • Closed date

    2018-04-04

  • Last modified date

    2018-05-01

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

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

    UI54988

Modules/Macros

  •    CHCDLSGP
    

Fix information

  • Fixed component name

    INFO SRVR CDC Z

  • Fixed component ID

    5655U7600

Applicable component levels

  • RA21 PSY UI54988

       UP18/04/07 P F804

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":"SSTVMA","label":"InfoSphere Data Replication for DB2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.2.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.2.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
01 May 2018