IBM Support



You can track all active APARs for this component.


APAR status

  • Closed as program error.

Error description

  • V91Fp8 Engine Fixes

Local fix

  •           V91Fp8 Engine Fixes

Problem summary

  • The following Replication Server problems have been fixed
    in DB2 LUW V9.1 FP8.
    Defect 554291: The HH.MM and HH formats of applyupto
     parameter of asnqapp aren't supported for Qrepl
    Problem Description: The HH.MM and HH formats of applyupto
     parameter of asnqapp do not work correctly on Linux IA32.
    Problem Conclusion: The root cause is due to out of bounds
     memory access exacerbated on optimized builds - which has
     been fixed.
    Defect 549309: Stored proc string parms codepage recorded
     incorrectly in SRC_COL_MAP of IBMQREP_TRG_COLS table
    Problem Description: For target Stored Procedures, if
     parameters are string like (CHAR/VARCHAR/...) the
     codepage info is incorrectly recorded in QAPPLY catalogs
     as '0'.  This causes no codepage conversions to occur for
     these parms.  Also subscription activation fails (schema)
     for stored proc targets if there are other subs defined
     (even if inactive) that have same target stored proc.
     This is due to an incorrect query in QAPPLY for finding
     number of columns of the stored proc.
    Problem Conclusion: Set and use correct codepage info for
     target stored proc columns. Also correct the query to
     find number of stored proc columns to ignore other
     subscriptions using same target stored proc.
    Defect 237668: An Update (a rework from an Insert) fails
     with sqlcode -313 when target_key_chg=Y and a key column
     is renamed in target table
    User Affected: SQLAPPLY
    Problem Description: An Update (a rework from an Insert)
     fails with sqlcode -313 when target_key_chg=Y and a key
     column is renamed in target table
    Problem Summary: SQLAPPLY does not construct the Update
     correctly when a key column is renamed in target table
    Problem Conclusion: Correct SQLAPPLY so that it'll use the
     renamed target column to construct the update statement
    Defect 543951: The asnqccmd status show details command
     displays *ERROR* (db2flsn rc=-101) instead of the oldest
     and current log file names.
    User Affected: All LUW QCAPTURE customers using asnqccmd
     status show details command.
    Problem Description:  The asnqccmd status show details
     command displays *ERROR* (db2flsn rc=-101) instead of the
     oldest and current log file names.
    Problem Summary: QCAPTURE calls db2flsn to determine the
     log file names. QCAPTURE should use the db2flsn -db
     option in order to locate the capture_server LFH file.
    Problem Conclusion: This problem has been fixed
    Defect 551475: asntrep abends with SIGSEGV when invoked
     with non-existing diff_schema
    Problem Description: This defect fixes multiple problems
     in asntdiff/asntrep:
    - On Solaris platforms, asntdiff and asntrep could
      generate a SIGSEGV abend in case a none existing
      differencing schema is specified.  This problem was only
      observed on Solaris platforms so far.  The fix corrects
      this behavior, i.e. asntdiff/asntrep will now generate a
      SQL error instead of an abend, specifying the none
      existing differencing schema in the message token and
      the program stops gracefully.
    - Asntdiff ran into a storage overlay problem when more
      than 17 key column were registered, or when no
      replication key was specified and the subscription
      contained more than 17 registered columns in a table.
      This fix makes the Q asntdiff implementation consistent
      to the SQL implementation to allow for up to 65 key
      columns for asntdiff execution.
    - Asntrep ran into a SQL Error with SQLCODE 0 when more
      than 1 row had to be updated. The problem was
      encountered in a setup where XML columns where involved,
      however the root cause is independent of XML columns and
      can happen with any column type that should get updated
      through asntrep. This happened because a special return
      structure was not initialized in the successful case,
      but only in the error case. The defect fixes this
      behavior and ensures that asntrep processes all required
      update statements.
    Defect 551483: Optimize SQL queries
    Problem Description: This defect fixes two problems:
    - The pruning queries for the tables IBMSNAP_ALERTS,
      rewritten to an equivalent query so that the optimizer
      can make use of the index for an applied range
      predicate. This results in a huge performance
    - The index on the MONITOR_TIME column of the
      IBMQREP_CAPMON table has been defined with default sort
      order DESC as this resulted in a performance improvement
      for some specific scenarios. However, the logic of
      asnmon relies on an ASC default sort order, otherwise
      the same alert will appear multiple times in successive
      asnmon interval.  The fix in this defect ensures that
      the asnmon logic receives the CAPMON rown in the order
      in which they are expected.

Problem conclusion

  •  The problems listed in this APAR have been
    fixed in V91FP8.

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


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

Document Information

Modified date:
28 October 2009