PTF PH08369 fixes the following issues:
1) Q Capture REINIT of an active subscription issues ASN7341W and does not send a schema message to Q Apply.
2) Q Capture issues ASN7138W each time it initializes a delimited subscription that has a IBMQREP_SENDQUEUES message_codepage that is not 1208.
3) Q Apply ASN7224I message displays an incorrect commit timestamp because Q Capture sent Q Apply an incorrect commit timestamp in a notification message.
4) Q Capture made an MQINQ call to return the number of messages on a queue and the call failed.
5) Q Capture prune positioned DELETE statements are invalidated.
6) Q Capture should check if the any source table columns have field procedures when it processes a CAPSTART signal. Q Capture checks if the source tables have any field procedures at start or reinit time and keeps this information in memory. If a subscription for a source table with a field procedure is activated, it is handled as a table without field procedures until Q Capture is recycled or a REINIT is issued. This causes incorrect data to be replicated or published.
7) The capture log reader makes READS calls for IFCID 306 that include a request to convert returned log records to the format for the table space version in which the data was written, but does not display an error message if Db2 cannot convert the log records.
8) The user cannot identify the UTILID used in ASNLOAD for a specific SQL Apply instance.
9) New function: three new parameters have been added to the Q Apply IBMQREP_APPLYPARMS table (WARNTXLATENCY, WARNTXEVTS, and WARNTXRESET). Q Apply will use these columns to make the browser thread perform checks on committed and in-flight transactions to identify the transactions that are causing Q Apply to exceed latency.
You can get more information and download the fix at http://www-01.ibm.com/support/docview.wss?uid=swg1PH08369.