A fix is available
APAR status
Closed as new function.
Error description
In-memory evaluation of search or change conditions now support the MOD() function
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: 1- Q Apply * * 2- Q Apply * * 3- Q Capture * * 4- ASNMON * * 5- Q Apply * * 6- Q Capture * * 7- Q Capture * * 8- All Capture customers. * **************************************************************** * PROBLEM DESCRIPTION: 1- Q Apply records the current * * timestamp at load start on the first * * line of the load trace file. If there * * are existing traces from prior loads * * in the same trace file: 1. The start * * timestamp of prior loads do not get * * preserved / get overwritten. 2. The * * load traces from multiple loads do not * * get clearly demarcated with individual * * time stamp records. * * 2- NUM_MQGETS and MQGET_TIME are * * inconsistent. * * 3- A new Q Capture parameter is added * * PARALLEL_MQTHREAD, activating * * publishing to MQ in a dedicated * * thread. * * 4- User incorrectly inserted a few * * alert conditions with mismatching * * COMPONENT and CONDITION_NAME values. * * ASNMON did not check the consistence * * between these two values and used it * * for different purpose, finally made * * the output wired but no corresponding * * errors/warnings in log.. * * 5- Q Apply may issue ALTER TABLE ALTER * * COLUMN for replicating ddl even when * * target column is already altered or * * already has same or larger length than * * source. * * 6- In-memory evaluation of search or * * change conditions now support the * * MOD() function * * 7- A stopq with stopafter=data_applied * * might not issue ASN7227I if a previous * * stopq did not receive a Q Apply * * 8- Capture does not activate a * * subscription if the source table has * * been altered and the table version is * * 0. * **************************************************************** * RECOMMENDATION: * **************************************************************** 1- Q Apply records the current timestamp at load start on the first line of the load trace file. The remaining traces from the load are appended to the end of the trace file. Load start timestamp in load trace file gets overwritten for any prior load traces in the same trace file. 2- NUM_MQGETS does not count the calls that time out, MQGET_TIME includes the time spent in timeouts. 3- This parameter can be used used to increase publish throughput in certain scenarios. 4- The error can be avoided by adding a check routine when fetch alert_conditions. If the COMPONENT is not consistent with CONDITION_NAME, errors will be recorded in log and that condition will be ignored. 5- Q Apply should not issue ALTER TABLE ALTER COLUMN for ddl replication if target column has already been altered to correct type and length or has length greater than that on source. 6- Refer to knowledge center topic 'In-memory evaluation of row filters' for usage and capabilities. 7- Recycling of Q Capture is required before stopafter=data_applied issues correct messages. 8- The table version is not increased after ALTER TABLE ALTER COLUMN increases the length of a VARCHAR column.
Problem conclusion
Temporary fix
Comments
1- Modify the file opening mode for writing timestamp from r+ to a+, modify the closing trace file function to add clear demarcation when loads finished. 2- NUM_MQGETS is changed to count all MQGET calls. NUM_MQMSGS is added to count all MQGET messages received. 3- The new PARALLEL_MQTHREAD parameter has been added. 4- Check on COMPONENT and CONDITION_NAME values when calling the getConditions function. If they are mismatched, ASN5189E will be logged and that condition will be ignored. 5- Q Apply will first check if target column already has correct data type and same or greater length than source column before issuing ALTER TABLE ALTER COLUMN for ddl replication. 6- Support for the MOD() function has been added. 7- The problem is resolved. 8- Capture will be changed to activate a subscription if the source table has been altered and the table version is 0.
APAR Information
APAR number
PI63364
Reported component name
WS REPLICATION
Reported component ID
5655L8800
Reported release
A21
Status
CLOSED UR1
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-05-31
Closed date
2016-06-28
Last modified date
2016-08-02
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI39005 UI39006 UI39007 UI39008
Modules/Macros
ASNAAPP ASNACMD ASNACMP ASNADMSP ASNAFET ASNAISO ASNAMAN ASNAPPLY ASNAPRS ASNAWPN ASNCAP ASNCCMD ASNMCMD ASNMDATA ASNMON ASNQACMD ASNQAHKT ASNQAPP ASNQASUB ASNQBRWZ ASNQCAP ASNQCCMD ASNQCTLZ ASNQDEP ASNQEXRP ASNQLODZ ASNQMFMT ASNQXFMT ASNQ1021 ASNRBASE ASNSQLCZ ASNS1021 ASNTDIFF ASNTDSP ASNTRC ASNVSQL ASNV1021 ASN2BASE ASN2SQLZ
Fix information
Fixed component name
WS REPLICATION
Fixed component ID
5655L8800
Applicable component levels
RA21 PSY UI39005
UP16/07/07 P F607
RA24 PSY UI39006
UP16/07/07 P F607
RA25 PSY UI39007
UP16/07/07 P F607
RA26 PSY UI39008
UP16/07/07 P F607
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"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":"A21","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
02 August 2016