Fixes are available
DB2 Version 9.1 Fix Pack 7 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 7a for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 8 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 9 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12 for Linux, UNIX and Windows
APAR status
Closed as new function.
Error description
Local fix
Problem summary
The following Replication Server defects have been fixed in V91FP7: . 363138: SQLAPPLY fails with ASN1016 when disable_refresh=1 and loadx_t User Affected: SQL Replication Problem Description: SQLAPPLY fails with ASN1016 for disable_refresh=1, when the member has loadx_type=6 or MEMBER_STATE='D' Problem Summary: SQLAPPLY should not issue error message ASN1016 for members with loadx_type=6 or MEMBER_STATE='D' Problem Conclusion: SQLAPPLY will not detect setting of disable_refresh for members with loadx_type=6 or MEMBER_STATE='D' . 379123: SQLAPPLY fails with SQL104N if target table is CCD and TARGET_STRUCTURE value is 9 User Affected: SQL Replication users Problem Description: SQLAPPLY fails with SQL104N if target table is CCD and TARGET_STRUCTURE value is 9 Problem Summary: Apply missed IBMSNAP_COLUMNS in insert statement for type 9 target Problem Conclusion: added IBMSNAP_COLUMNS for type 9 target . 365917: SQLCAPTURE (in DPF): Restart LSN for partitions not updated properly User Affected: SQLCAPTURE Problem Description: The restart LSN for each partition is updated: (1) asynchronously by the admin thread (which doesn't guarantee the update is done in the same commit interval). (2) only one partition's restart LSN is updated per commit interval in a round-robin fashion (which leaves all other partitions very outdated and makes warmstart re-read hours of log data that has already been processed) Problem Conclusion: SQLCAPTURE will now update every row in IBMSNAP_PARTITIONINFO upon commit interval. Previously, it updated only one row each commit interval . 373983: Log reader buffer size default of 200KB (on LUW) is too small for some rare DB2 log records (max log rec size 256KB) Problem Conclusion: Increased default LOGBUFSIZE from 200KB to 256KB. . 368060: CAPTURE ABENDS0C4 while REINIT/STOP is being processed. User Affected: QCAPTURE, SQLCAPTURE Problem Description: The worker thread terminates before the logreader terminates. Problem Summary: The worker/logreader communication is inadequate Problem Conclusion: The worker turns on the stop flag to signal the logreader to stop. . 369811: Before values for LOB/XML should not be counted in max message User Affected: QCAPTURE Problem Description: QCAPTURE was counting the LOB and XML columns for before values in max message size estimation Problem Summary: QCAPTURE should set not count those columns because they are never sent Problem Conclusion: QCAPTURE is now excluding those columns in max message size estimate . 367038: 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 . 328559: SUPPRESS DELETES with search condition User Affected: QCAPTURE Problem Description: QCAPTURE did not suppress deletes after search condition evaluation Problem Summary: QCAPTURE should also suppress the deletes after search condition evaluation Problem Conclusion: QCAPTURE now suppresses the deletes after search condition evaluation . 362819: 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 Problem Conclusion: The admin thread now always queries the IBMQREP_SUBS table for the subname to be used in inserting signals when processing admin messages . 371385: statement owner should be invalidated in getPrepredStmt() if handle is stolen. User Affected: QCAPTURE Problem Description: SQL statement handles were not invalidated when they were overtaken by new owners, causing erroneous SQL statements to be executed Problem Summary: Internal SQL statement cache manager should invalidate obsolete SQL statement handles Problem Conclusion: Obsolete SQL statement handles are now invalidated . 373770: asnmon: bug fix for QCAPTURE/QAPPLY V8 monitor interval to be in seconds not in milliseconds User Affected: All users that use asnmon to monitor QReplication Problem Description: The monitor_interval for QCAPTURE and QAPPLY was changed in V9 to be in milliseconds. Monitor code however processes the monitor_interval as if it was in seconds although the value is in millisecond. Problem Summary: Asnmon interprets the monitor_interval of V9 QCAPTURE/QAPPLY in seconds. Problem Conclusion: Asnmon had to be changed to interpret QCAPTURE/QAPPLY monitor_interval column in V8 in seconds and V9 in milliseconds. . 373773: asntdiff: signed interger overflow when addressing storage in spill file > 2GB User Affected: Users that run asntdiff on a 64bit system, against tables with huge amount of data. Problem Description: Asntdiff runs into an integer overflow problem when it tries to access more than 2GB of data in the spill file. Problem Summary: Asntdiff uses a signed integer to address records in the spill file. Problem Conclusion: On 64bit systems, asntdiff is now capable to address spill file content beyond 2GB due to a 8Byte offsets. . 366114: linuxamd64: ASN1980E "Asnpwd" : "" : "Initial". The program did not complete successfully because "Operation not permitted" User Affected: The problem was only observed during an asnpwd init invocation on a 64bit linux system. Problem Description: Asnpwd init invocation results in ASN1980E "Asnpwd" : "" : "Initial". The program did not complete successfully because "Operation not permitted" Problem Summary: Asnpwd does not allow the user to create the initial password file, but returns an "Operation not permitted error". Problem Conclusion: The asnpwd file handling operations had to be changed. .
Problem conclusion
The defects mentioned in this APAR have been fixed in DB2 LUW V91 FP7.
Temporary fix
Comments
APAR Information
APAR number
JR30371
Reported component name
REPLICATION SER
Reported component ID
5724N9800
Reported release
910
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2008-08-28
Closed date
2009-05-07
Last modified date
2009-05-07
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
REPLICATION SER
Fixed component ID
5724N9800
Applicable component levels
R910 PSY
UP
[{"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