Fixes are available
DB2 Version 9.5 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 4a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 5 for Linux, UNIX, and Windows
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
Closed as program error.
Replication Engine fixes for v95FP4
This APAR provides fixes for the following Replication defects. . Defect 372657: fix 32 vs 64 bit Q Replication binaries for win64 This defect is to fix the duplicate 32 and 64 bit binaries in the Q Replication Windows builds. From the user's perspective, the correct binaries will be included in the install image, and Q Replication will now run correctly on Windows 64. . Defect 378294: SQLAPPLY is not running nocopypend for the LOB tablespace QCAPTURE ABENDS0C4 if SENDQ/RECVQ does not exist. User Affected: QCAPTURE, SQLCAPTURE Problem Description: The CAPTURE cleanup routine does not check if the transMgr was initialized. Problem Summary: The status of transMgr is check before executing the routine. . Defect 390419: LOB data is not replicated when key columns are defined as not null. User Affected: SQLAPPLY Problem Description: LOB data is not replicated when key columns are defined as not null. Problem Summary: SQLAPPLY retrieves LOB value from source table by using incorrect key value Problem Conclusion: Change SQLAPPLY to use correct key value to retrieve LOB from source table. . Defect 373369: Log reader buffer size default of 200KB (on LUW) is too small for some rare DB2 log records (max log rec size 256KB) Problem Summary: Increased size of default log read buffer from 200KB to 256KB. . Defect 378292: CAPTURE ABENDS0C4 when DB2 z/OS V7 table is dropped User Affected: QCAPTURE and SQLCAPTURE Problem Description: CAPTURE cannot always rely on the LRHREL value to determine the version of the DROP TABLE log record contents. Problem Summary: The version is determined via checking the data prefix PGSUBREC. . Defect: 210562: CAPTURE ABENDS0C4 in baseTable::clearDecodeInfo(). User Affected: CAPTURE Problem Description: ABENDS0C4 on subscription activation. Problem Summary: CAPTURE may ABENDS0C4 if 2 new columns were not added to IBMQREP_COLVERSION. Problem Conclusion: CAPTURE will not ABENDS0C4 when we are missing the 2 IBMQREP_COLVERSION columns. . Defect: 215646: QCAPTURE/SQLCAPTURE ABENDS0C4 when a global transaction is rolled back. User Affected: QCAPTURE, SQLCAPTURE Problem Description: The global trans object is not properly initialized that causes ABENDS0C4 Problem Summary: The trans constructor is fixed to initialize the partIndex. . Defect 210425: Performance problem with sleeping when we are spilliing transactions due to transaction memory being full User Affected: CAPTURE Problem Description: CAPTURE performs very poorly when there are large transactions and spilling. Problem Summary: CAPTURE is sleeping incorrectly when it has work to do. Problem Conclusion: CAPTURE will not sleep when it has transactions to process and memory is near full. . Defect 372136: sqlmonss call removed from dbQueryStatus for performance reasons in QCAPTURE Problem Description: Removed use of the db2 API sqlmonss to monitor the state of the connected DB2 database. Frequent calls to this API could cause performance problems for other DB2 applications. An alternative method to determine the database status was implemented. . Defect 397399: Coding error resulting in data loss for customers Problem Description: In the QAPPLY browser, there is an incorrect comparision with the wrong number of bytes. This leads QAPPLY to falsely delete valid messages off of the receive queue and not apply to the target. This results in data loss to the customers. Problem Conclusion: This defect fixes the actual number of bytes compared. . Defect 378508: add new restrictions during automatic/manual select of the load utilities and changed output destination of MSGASN7527 and MSGASN7590 User Affected: QAPPLY Problem Description: 1. QAPPLY would use EXPORT/LOAD when internal load phase and automatic load type (0) was specified and when the target was remote and contained LOB or XML columns - this configuration is not supported by the DB2 LOAD utility. 2. QAPPLY would use EXPORT/IMPORT when internal load phase and automatic load type (0) was specified and when subscription types were Bidirectional or P2P. 3. MSGASN7527 and MSGASN7590 were not put to the z Console only to the log. Problem Summary: 1. QAPPLY must restrict the automatic and manual usage of EXPORT/LOAD when the target is remote. 2. QAPPLY must restrict the automatic and manual usage of EXPORT/IMPORT if the subscription is defined as Bidirectional or P2P. 3. MSGASN7527 and MSGASN7590 need to be shown on the console. Problem Conclusion: 1. During automatic selection of the load utility based on the load type QAPPLY checks whether EXPORT/LOAD can be used or not based on the information if the target is remote with LOB/XML columns. If QAPPLY determines that the target is remote and LOB/XML columns are involved it will try to choose the CROSSLOADER or EXPORT/IMPORT (which is restricted if the subscription is P2P or Bidirectional). If QAPPLY cannot use any of the available (not restricted) load tools MSGASN7532E reason 8 is issued. During manual selection, if EXPORT/LOAD was specified but cannot be used MSGASN7532E reason 7 is issued. 2. During manual selection of the load utility based on the load type QAPPLY whether EXPORT/IMPORT can be used or not. If QAPPLY determines that the subscription type is Bidirectional or P2P it will try to use CROSSLOADER or EXPORT/LOAD (which is restricted if the target is remote with LOB/XML columns). If QAPPLY cannot use any of the available (not restricted) load tools a message "Apply could not select a load utility" is issued. During manual selection, if EXPORT/IMPORT was specified but cannot be used due to the subscription being P2P or Bidirectional MSGASN7532 reason 6 is issued. 3. MSGASN7527 and MSGASN7590 appear on the console. . Defect 376312: <descTable> ASN0552E "QAPPLY" : "QALLTYPE" : "BR00000" : The program encountered an SQL error. The SQL request is "DESCRIBE". The table name is ""QALLTYPE"."ALLTYPE2U_TRG"". The SQLCODE is "239". The SQLSTATE is "01005". Th User Affected: QAPPLY Problem Description: SQL0239 error when QAPPLY tried to describe a table with distinct column types on z/OS Problem Summary: SQLVAR entries needed to be doubled if any of the columns in the result set of a describe is a distinct type Problem Conclusion: SQLVAR entries are now doubled to describe any table with distinct column types . Defect 370366: Avoid deactivating subscription on initialization and RI failures. User Affected: ALL Problem Description: On QAPPLY startup, a subscription initialization failure, such as, SRC_COL_MAP=NULL, would deactivate the subscription. Customer is forced to do a full refresh. Problem Summary: A subscription is no longer deactivated on initialization or RI failures. The Browser is stopped instead. This allows customers to resolve the problem or manually disable the subscription if needed. . Defect 363265: The parameter of asnqcap: add_partition doesn't work for QCAPTURE Problem Description: When adding a new partition, QCAPTURE reported MSGASN7103 upon warmstart (warmns), which was incorrect. It should have reported MSGASN7007. The logic was corrected so that it reported MSGASN7007. However, QCAPTURE should have exited after reporting this error, but it continued to run. This was also fixed. Problem Summary: Now QCAPTURE properly reports MSGASN7007 and exits when new node is added. If add_partition=y is placed on command line, then MSGASN7007 is not reported and capture continues running and adjusts the restart message to reflect the additional restartLSN for the new partition. If a partition is dropped, QCAPTURE reports MSGASN7103, resizes the restart message to remove the restartLSN for the dropped partition, and QCAPTURE continues running. . Defect 372674: Admin thread should always fetch the subname from the SUBS table User Affected: QCAPTURE Problem Description: The admin thread only checked the subscriptions in memory for subname to be used in inserting signals, sometimes the subscriptions are not in memory thus causing problems with the signals when processing admin messages Problem Summary: The admin thread should always query the IBMQREP_SUBS table for the subname to be used in inserting signals when processing admin messages . Defect 397444: Before values are sent incorrectly User affected: customers with CCD targets and bi-dir subscriptions with conflict_rule = 'C'. Problem Description: Before values must always be sent if the before_values option is selected for the column in a uni-directional subscription. The code is suppressing the before values unchanged columns which is causing replication to CCD targets to fail. Also, in bi-dir and p2p subscriptions, before values should be suppressed if the column is unchanged. . Defect 388206: Serious performance degradation in QCAPTURE publishing thread User affected: z/OS and LUW QCAPTURE Problem Description: 73% reduced throughput and a large increase in CPU by QCAPTURE and DB2 as a result of an unneccesary COMMIT in QCAPTURE. The commit occurs once for every row written to the buffer before a transaction is published to the queue. It was added as a safeguard against locks being held in DB2 after a LOB was fetched, but this should not occur for rows that do not contain LOB values. . Defect 396807: The isLast has wrong value in a lob message for Event publishing when setting lob_send_option=S User Affected: QCAPTURE Problem Description: The isLast flag in the EP LOB message had a wrong value when LOB_SEND_OPTION was set to 'S' Problem Summary: The isLast flag should only be set in the last LOB message . Defect 536465: The hasLOBCols has wrong value in message for Event publishing when setting lob_send_option=S User Affected: QCAPTURE Problem Description: The hasLOBCols flag in the EP LOB message had a wrong value when LOB_SEND_OPTION was set to 'S' Problem Summary: The hasLOBCols flag should be set according to the number of LOB columns in the row . Defect 372435: During COLDSTART QCAPTURE issues MSGASN7095E User Affected: QCAPTURE Problem Description: QCAPTURE issued MSGASN7095E on COLDSTART complaining about missing subID for an active subscription Problem Summary: QCAPTURE should not check that on COLDSTART Problem Conclusion: Such check has been removed for COLDSTART and MSGASN7095E will not be issued . Defect 366117: QCAPTURE is sending incorrect messages User Affected: QCAPTURE and QAPPLY Problem Description: QCAPTURE sent incorrect transaction messages when publishing LOB data and the subscription contained a search condition, CHANGED_COLS_ONLY was set to 'Y' and LOB_SEND_OPTION was set to 'S' Problem Summary: QCAPTURE should send transaction data correctly in such scenario . Defect 367039: Check IMPLICITVALUE in SYSCAT.COLUMNS for original ADDCOL default value User Affected: QCAPTURE Problem Description: QCAPTURE was not using the IMPLICITVALUE column as the default value for the added column Problem Summary: QCAPTURE should query the SYSCAT.COLUMNS table for the IMPLICITVALUE of the added column Problem Conclusion: QCAPTURE is now sending the IMPLICITVALUE column as the default value for the added column . Defect 372679: SUPPRESS DELETES with search condition Problem Description: If an UPDATE is changed into a DELETE after the evaluation of a search condition, QCAPTURE should still honor the SUPPRESS DELETES option in the subscription. . Defect 348958: QCAPTURE error MSGASN0575E Problem Description: QCAPTURE was failing with MSGASN0575E. But it did not mention the queue that is in error. . Defect 376308: asntdiff: signed interger overflow when addressing storage in spill file > 2GB Problem Description: asntdiff runs into an integer overflow problem when data beyond 2GB is written into the spill file. . Defect 383374: asntdiff returns one row more than specified in MAXDIFF threshold parameter User Affected: all asntdiff users Problem Description: MAXDIFF parameter does not work as defined. Problem Summary: When the parameter MAXDIFF was employed, asntdiff returned after MAXDIFF+1 differences .
The problems listed in this APAR have been fixed and will be available in DB2 LUW V95FP4.
Reported component name
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
Fixed component ID
Applicable component levels
15 May 2009