DB2 DataPropagator Version 7.1 is compatible with the Windows 2000 operating system.
You cannot replicate DATALINK columns between DB2 databases on AS/400 and DB2 databases on other platforms.
On the AS/400 platform, there is no support for the replication of the "comment" attribute of DATALINK values.
If you are running AIX 4.2, before you run the default user exit program (ASNDLCOPY) you must install the PTF for APAR IY03101 (AIX 4210-06 RECOMMENDED MAINTENANCE FOR AIX 4.2.1). This PTF contains a Y2K fix for the "modtime/MDTM" command in the FTP daemon. To verify the fix, check the last modification time returned from the "modtime <file>" command, where <file> is a file that was modified after January 1, 2000.
If the target table is an external CCD table, DB2 DataPropagator calls the ASNDLCOPY routine to replicate DATALINK files. For the latest information about how to use the ASNDLCOPY and ASNDLCOPYD programs, see the prologue section of each program's source code. The following restrictions apply:
Condensed internal CCD tables cannot contain references to LOB columns or LOB indicators.
You must use DataJoiner Version 2 or later to replicate data to or from non-IBM servers such as Informix, Microsoft SQL Server, Oracle, Sybase, and Sybase SQL Anywhere. You cannot use the relational connect function for this type of replication because DB2 Relational Connect Version 7.1 does not have update capability. Also, you must use DJRA (DataJoiner Replication Administration) to administer such heterogeneous replication on all platforms (AS/400, OS/2, OS/390, UNIX, and Windows) for all existing versions of DB2 and DataJoiner.
If you want to set up update-anywhere replication with conflict detection and with more than 150 subscription set members in a subscription set, you must run the following DDL to create the ASN.IBMSNAP_COMPENSATE table on the control server:
CREATE TABLE ASN.IBMSNAP_COMPENSATE (
APPLY_QUAL char(18) NOT NULL,
MEMBER SMALLINT,
INTENTSEQ CHAR(10) FOR BIT DATA,
OPERATION CHAR(1));
On page 65, "Connectivity" should include the following fact:
If the Apply program cannot connect to the control server, the Apply program terminates.
When using data blocking for AS/400, you must ensure that the total amount of data to be replicated during the interval does not exceed "4 million rows", not "4 MB" as stated on page 69 of the book.
On page 95, "Customizing CD table, index, and tablespace names" says that the DPREPL.DFT file is in either the \sqllib\bin directory or the \sqllib\java directory. Actually DPREPL.DFT is in the \sqllib\cc directory.
The Replication Analyzer runs on Windows 32-bit systems and AIX. To run the Analyzer on AIX, ensure that the sqllib/bin directory appears before /usr/local/bin in your PATH environment variable to avoid conflicts with /usr/local/bin/analyze.
The Replication Analyzer has two additional optional keywords: CT and AT.
Example:
analyze mydb1 mydb2 f=mydirectory ct=4 at=2 deepcheck q=applyqual1
For the Replication Analyzer, the following keyword information is updated:
Analyzer tools are available in PTFs for replication on AS/400 platforms. These tools collect information about your replication environment and produce an HTML file that can be sent to your IBM Service Representative to aid in problem determination. To get the AS/400 tools, download the appropriate PTF (for example, for product 5769DP2, you must download PTF SF61798 or its latest replacement).
Add the following problem and solution to the "Troubleshooting" section:
Problem: The Apply program loops without replicating changes; the Apply trail table shows STATUS=2. The subscription set includes multiple source tables. To improve the handling of hotspots for one source table in the set, an internal CCD table is defined for that source table, but in a different subscription set. Updates are made to the source table but the Apply process that populates the internal CCD table runs asynchronously (for example, the Apply program might not be started or an event not triggered, and so on). The Apply program that replicates updates from the source table to the target table loops because it is waiting for the internal CCD table to be updated. To stop the looping, start the Apply program (or trigger the event that causes replication) for the internal CCD table. The Apply program will populate the internal CCD table and allow the looping Apply program to process changes from all source tables. A similar situation could occur for a subscription set that contains source tables with internal CCD tables that are populated by multiple Apply programs.
On page 178, "A note on work management" should read as follows:
You can alter the default definitions or provide your own definitions. If you create your own subsystem description, you must name the subsystem QZSNDPR and create it in a library other than QDPR. See "OS/400 Work Management V4R3", SC41-5306 for more information about changing these definitions.
Add the following to page 178, "Verifying and customizing your installation of DB2 DataPropagator for AS/400":
If you have problems with lock contention due to high volume of transactions, you can
increase the default wait timeout value from 30 to 120. You can change the job every
time the Capture job starts or you can use the following procedure to change the default
wait timeout value for all jobs running in your subsystem:
1. Issue the following command to create a new class object by duplicating QGPL/QBATCH:
CRTDUPOBJ OBJ(QBATCH) FROMLIB(QGPL) OBJTYPE(*CLS) TOLIB(QDPR) NEWOBJ(QZSNDPR)
2. Change the wait timeout value for the newly created class (for example, to 300 seconds):
CHGCLS CLS(QDPR/QZSNDPR) DFTWAIT(300)
3. Update the routing entry in subsystem description QDPR/QZSNDPR to use the newly
created class:
CHGRTGE SBSD(QDPR/QZSNDPR) SEQNBR(9999) CLS(QDPR/QZSNDPR)
On page 195, the ADDEXITPGM command parameters should read:
ADDEXITPGM EXITPNT(QIBM_QJO_DLT_JRNRCV)
FORMAT(DRCV0100)
PGM(QDPR/QZSNDREP)
PGMNBR(*LOW)
CRTEXITPNT(*NO)
PGMDTA(65535 10 QSYS)
On page 339, append the following sentence to the STATUS column description for the value "2":
If you use internal CCD tables and you repeatedly get a value of "2" in the status column of the Apply trail table, go to "Chapter 8: Problem Determination" and refer to "Problem: The Apply program loops without replicating changes, the Apply trail table shows STATUS=2".
Message ASN1027S should be added:
ASN1027S There are too many large object (LOB) columns specified. The error code is "<error_code>". Explanation: Too many large object (BLOB, CLOB, or DBCLOB) columns are specified for a subscription set member. The maximum number of columns allowed is 10. User response: Remove the excess large object columns from the subscription set member.
Message ASN1048E should read as follows:
ASN1048E The execution of an Apply cycle failed. See the Apply trail table for full details: "<text>" Explanation: An Apply cycle failed. In the message, "<text>" identifies the "<target_server>", "<target_owner, target_table, stmt_number>", and "<cntl_server>". User response: Check the APPERRM fields in the audit trail table to determine why the Apply cycle failed.
On page 399 of the book, a few errors appear in the comments of the Sample routine that starts the Capture and Apply programs; however the code in the sample is correct. The latter part of the sample pertains to the Apply parameters, despite the fact that the comments indicate that it pertains to the Capture parameters.
You can get samples of the Apply and Capture API, and their respective makefiles, in the following directories:
For NT - sqllib\samples\repl For UNIX - sqllib/samples/repl