JR34455: REPLICATION ENGINE FIXES FOR DB2 LUW V95 FP6

DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows

APAR status

• Closed as program error.

Error description

• REPL ENGINE APAR FOR V95FP6
  

Local fix

• Fix for V95fp6
  795402:SQL Capture gets sqlcode -437 or SQL0437W, a DB2 warning
  and stops.  It should not stop for a SQL warning.  Code was
  added to tolerate this sql warning and keep Capture up and
  running.
  Workaround is to do runstats and reorg the table in the message.
  

Problem summary

• .
  The following Replication Server engine problems have been
  fixed in DB2 LUW V9.5 FP6.
  .
  379845:bind qcapture.lst failed as asnqsql.bnd not found
  Problem Summary: asnqsql.bnd file was removed but its
   reference in qcapture.lst wasn't removed. This causes a
   bind failure.  The reference to asnqsql.bnd has been
   removed from qcapture.lst.
  .
  626439:QCAPTURE:Possible SIGILL during log reading when
   connected to a DPF system.
  Users Affected: Q/SQL Capture for LUW
  Problem Description: A timing issue (race condition)
   between two components of Capture during transaction
   processing (process log records) and transaction
   publishing may cause a SIGILL.
  Problem Summary: SIGILL may be encountered in the log
   reader thread when processing transactions in a DPF
   environment. Capture stops.
  Problem Conclusion: The problem has been fixed.
  .
  598357:QAPPLY:Insufficient diagnostics for ASN7614W when
   P2P row shows future timestamp or possible clock skew
  Problem Summary: The diagnostics reported should also
   include details like the ibmqrep_vertime value, the row
   and transaction details including the MQ msgId.  Current
   diagnostics are not helpful in isolating and resolving
   the underlying issue.
  .
  584279:QAPPLY sub activation fails if col expression
   contains colons within single quotes but not preceding a
   column name
  Problem Summary: For subscriptions using column SQL
   expressions, QAPPLY treats anything following a colon as
   a source column name if it is not contained within double
   quotes.  It should not do so, if the colon is contained
   within single quotes too, so that DATETIME / TIMESTAMP
   values like '23:00:00' can be included in the expression.
   This leads to failure in activating the subscription as
   QAPPLY fails to find the non-existent source column.
  .
  745948:QAPPLY:SQL0311 is encountered upon retry of row
   changes with LOB columns if endianness needs to be
   converted
  Problem Summary: On LUW only. LOB columns are subscribed.
   Source endianness is different than target endianness
   (e.g. Replication from AIX to Linux).  Behavior: QAPPLY
   stops queue or comes down when it encounters SQL0311
   upon retrying after a deadlock.
  Reason: The data length for the LOB data is incorrect if
   no codepage conversion is required.  On the first try the
   length value from the message is converted into the
   target endianness but stored back at the message buffer.
   Upon retry the length value is again converted but this
   time back into the source endianness.  This leads to
   incorrect length values for LOB data in the SQLDA and
   SQL0311 during execution.
  .
  620553:COMMON:dbQueryStatus implementation is too
   expensive on some platforms (LUW only)
  Problem Summary: For remote connections on linux, a
   connect using SERVER ENCRYPTION for credentials consumes
   a lot of CPU.
  .
  625417:SQLCAPTURE, and SQLAPPLY executing with the TERM
   option set to 'N' stop if DB2 is terminated or quiesced.
  Users Affected: SQLCAPTURE and SQLAPPLY customers.
  Problem Description: SQLCAPTURE and SQLAPPLY executing
   with the TERM option set to 'N' stop if DB2 is terminated
   or quiesced.
  Problem Summary: SQLCAPTURE and SQLAPPLY should continue
   executing until they can either establish a DB2
   connection or they are stopped by a STOP command if TERM
   is set to 'N'.
  Problem Conclusion: Modify the programs to continue
   executing until they can either establish a DB2
   connection or they are stopped if TERM is set to 'N'.
  .
  614334 : SQL/Q CAPTURE can miss rows when a transaction a
   transaction already published is spilled by the log
   reader thread because memory limit is reached
  User Affected: SQLCAPTURE and QCAPTURE
  Problem Description: Replication users might experience
   data loss when a transaction is spilled by the Capture
   program, which is not larger than the memory limit and
   has already been published.
  Problem Summary: In asynchronous log reading mode, which
   is the default for the QCAPTURE program and enabled by
   setting the invocation parameter ASYNCHLOGRD to Y for
   the SQLCAPTURE program, a dedicated log reader thread
   reads the log records and spills transactions to disk
   when MEMORY_LIMIT is about to be exceeded.  A memory
   corruption can occur within a small timing window if a
   transaction already published by the worker thread is
   selected for spilling by the log reader thread. (This
   problem does not exist if the transaction is the only one
   being captured, such as when a single transaction is
   larger than the memory limit for the Capture program) As
   a result, the spilled transaction or parts of the spilled
   transaction might not get published. This problem can
   actually also cause data loss or duplicate rows in
   transactions that follow the spilled transaction.
  Problem Conclusion: The Capture logic has been fixed to
   prevent a transaction already published by the worker
   thread from being selected for spilling.
  .
  617851: SQLAPPLY fails with status=-1 (error message
   ASN1050E) when the row with IBMSNAP_OPERATION='G' is
   returned from Oracle source
  User Affected: SQLAPPLY
  Problem Description: The row with IBMSNAP_OPERATION='G'
   resides in supported non-DB2 servers and contains
   IBMSNAP_COMMITSEQ=x'00000000000000000000'.  It should
   never be returned to SQLAPPLY from federation server.
   Apply treats the 'G' record as an invalid row and fails
   current cycle when the record is returned from federation
   source server.
  Problem Conclusion: The Apply logic has been changed to
   skip the row with IBMSNAP_OPERATION='G' if the target
   is a condensed table/view.
  .
  

Problem conclusion

• The problems listed in the previous section
  have been fixed in DB2 LUW V9.5 FP6.
  

Temporary fix

Comments

APAR Information

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

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

  IC66217 IC67091

Fix information

• Fixed component name

  WS Q-REPLIC LUW

• Fixed component ID

  5724N9801

Applicable component levels

• R950 PSY

     UP