IBM Support



You can track all active APARs for this component.


APAR status

  • Closed as new function.

Error description

Local fix

Problem summary

  • The following problems have been fixed in V91FP6:
    360655:Warmstart of SQLCAPTURE in asynch mode returns
      rc=426 then stops when new partitions added to DPF
    User Affected: Users running SQLCAPTURE with asynchlogrd=y
      in a DPF environment
    Problem Description: After adding a partition, a warmstart
      of SQLCAPTURE in asynchronous mode returns rc=426 then
    Problem Summary: The "partition added or removed" messages
      returned from the log reader were not handled by
      SQLCAPTURE when the asynchronous log reader is used.
    Problem Conclusion: SQLCAPTURE was modified to properly
      handle rc 426 and report the appropriate ASN message and
      continue running.
    359233:If logrd init times out, MSGASN0193 is issued but
      then other errors reported and SQLCAPTURE exits.
      QCAPTURE doesn't exit, but also reports other errors.
    User Affected: SQLCAPTURE and QCAPTURE users
    Problem Description: If the log reader initialization
      times out, MSGASN0193 is reported, followed by erroneous
      messages in SQLCAPTURE and QCAPTURE. QCAPTURE continues
      running, but SQLCAPTURE stops.
    Problem Summary: The log reader is given a few seconds to
      initialize. In some instances, initialization takes
      longer than the time allowed. Capture properly reported
      MSGASN0193, but then did not continue waiting for the
      log reader to initialize.  This resulted in bogus
      messages being reported as well as SQLCAPTURE aborting.
    Problem Conclusion: SQLCAPTURE and QCAPTURE now continue
      to wait for the log reader to initialize or to report a
      specific log reader error.
    353854:Fix SIGSEGV in SQLCAPTURE when CAPSTART in DPF env
      with > 16 partitions defined.
    User Affected: SQLCAPTURE users who migrate from V8 to V91
      and have > 16 partitions defined
    Problem Description: SQLCAPTURE V8 did not have limits on
      number of partitions supported in DPF.  In V91, a limit
      of 16 partitions was imposed. After migration from V8 to
      V91, SQLCAPTURE crashes during startup if more than 16
      partitions are defined.
    Problem Summary: The "limit for only 16 partitions" in V91
      was not performed too late in the startup sequence,
      thus, the log reader was attempting to use memory that
      was not allocated.
    Problem Conclusion: SQLCAPTURE now checks for the 16
      partition limit before the log reader is initialized. If
      more than 16 partitions are defined, the appropriate ASN
      message is reported and SQLCAPTURE exits properly.
    352032: Fix for GRAPHIC data types and CHGONLY
    User Affected: Capture
    Problem Description: Any table replicating GRAPHIC or
      VARGRAPHIC columns using CHGONLY=Y
    Problem Summary: If only the second half of the graphic
      column was updated, this column was not detected to be
      changed and filtered by CHGONLY
    Problem Conclusion: CHGONLY detection will properly detect
      changes to the GRAPHIC columns
    354067: LOB not being sent when CHANGED_COLS_ONLY=Y and
      search condition turns an update into insert
    Defect: wsdbu00348464: Miscellaneous special build fixes
      for customer problems
    User Affected: z/OS or LUW customers needing specific load
      parameters and other fixes.
    Problem Description: Some load parameters like
      MAX_PARALLEL_LOADS needed to be externalized. Also, if
      error_action is 'S', receive queue should not be
      deactivated; when a bad message appears on the queue,
      QAPPLY should give ASN7594W and consume the bad message.
    Problem Summary: Above changes were given as special build
      fixes to different customers
    Problem Conclusion: This defect addresses the changes
      mentioned above.
    Defect: 339390: Change SQLAPPLY to use parameter markers
      instead of fixed strings for all sql statements
    User Affected: SQLAPPLY users
    Problem Description: Change SQLAPPLY to use parameter
      markers instead of fixed strings for all sql statements
    Problem Summary: use parameter markers instead of fixed
      strings for sql statements to reduce number of entries
      in DB2 cache
    Problem Conclusion: using parameter markers for sql

Problem conclusion

  • The problems mentioned in this APAR have been fixed and are
    available in V91FP6.

Temporary fix


APAR Information

  • APAR number


  • Reported component name


  • 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


  • Fixed component ID


Applicable component levels

  • R910 PSY


[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSDP5R","label":"InfoSphere Replication Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1"}]

Document Information

Modified date:
07 October 2021