The following sections describe commonly known issues with Capture and Apply for OS/2.
Problem
Capture for OS/2 is not capturing updates.
Any of the following could prevent the Capture program from capturing updates:
Check the ASN.IBMSNAP_TRACE table for possible error messages.
Problem
I'm not sure if the Capture program is running successfully.
After you start the Capture and Apply programs, the Apply program performs a full refresh to populate the target tables. Then the Capture program writes message ASN0104I to the ASN.IBMSNAP_TRACE table, providing information related to table owner name, table name, and starting log sequence number value. This provides a point from which the Capture program starts to capture updates.
Updates captured from then on are placed in change data tables. They are eventually applied to target tables and pruned from the change data table. After the Capture program runs for some time, you should see rows in the change data table if changes are made to the source. Periodically, check the ASN.IBMSNAP_TRACE table to see the Capture program's progress. If it encounters errors, it sends them to the console and also logs them in the trace table. Similarly, the Apply program logs its information in the userid.IBMSNAP_APPLYTRAIL table.
Problem
Capture for OS/2 terminated unexpectedly.
The Capture for OS/2 program terminates either because of a severe error, or when you issue the STOP command. The Capture program terminates with a return code that indicates successful or unsuccessful completion. Return codes are:
Before running the Apply program, ensure that:
When an error occurs while running the Apply program, the status field in IBMSNAP_SUBS_SET is set to -1 for that copy definition.
Errors as well as successful executions are logged in the IBMSNAP_APPLYTRAIL table. APPERRM contains the message text. Any SQL errors are also logged in this table. Error messages are also issued on the console.
Specific Apply program problems are described below.
Problem
I have performed a successful bind, but when running the Apply program I still get SQLCODE -805, SQLSTATE 51002.
Make sure that the user ID has execute privilege on the Apply packages, and make sure to bind the Capture package to the source server database and to bind both Apply packages to the control, source, and target server databases.
Problem
The DB2 log has filled to capacity because I copied a very large table.
If the error occurred during a full refresh, you can use alternative methods to load large tables. You can either use the ASNLOAD exit, described in Table 5, ASNARUN Invocation Parameter Definitions, or you can perform your own load, described in "Loading Large Copies".
If the occurred while applying changed data, then you can change the data blocking parameter to break down large blocks of changed data. See "Specifying Mini-Cycles for the Apply Program to Copy Committed Data" in chapter 7.
Problem
The Capture program was cold started, which caused the Apply program to perform a full refresh, but I don't want a full refresh.
If your target table is very large, and in cases where you have decided to use only your own load mechanism, you might want to suppress any future full refreshes of the Apply program. Set the DISABLE_REFRESH flag to 1 in ASN.IBMSNAP_REGISTER at the source server for the source table. In this case, the Apply program issues message ASN1016E.
Problem
A gap was detected, so the Apply program won't perform a full refresh of my target table.
Force a full refresh by resetting the LAST_SUCCESS, SYNCHTIME, and SYNCHPOINT values in ASN.IBMSNAP_SUBS_SET to null.
I unsuccessfully tried to start a second Apply program instance.
You must run each instance with a unique Apply qualifier.
Problem
I received error ASN1003 with SQLCODE = -1032 and SQLSTATE = 57019.
You must start the database manager before invoking the Apply program.
Problem
Apply components for DB2 Universal Database stops with an SQLCODE= -330, SQLSTATE=22517, "A string cannot be used, because its characters cannot be translated".
When copying between DB2 for MVS and DB2 Universal Database, the CCSID translation can cause an INSERT to fail if a translated value is longer than the DB2 column in which it will be inserted. Apply can generate an SQLCODE -330 when it tries to insert a translated COPY_TABLE column value from the refresh control table on a DB2 Universal Database target server into the pruning control table on a DB2 for MVS source server.
For example, if you use the Korean character set with mixed data at both DB2 for MVS source server and DB2 Universal Database target server, the INSERT fails because the original string is in mixed data ASCII. When it is translated to EBCIDIC mixed data with the Korean character set, if the resulting string length is greater than 18 characters (the maximum COPY_TABLE length), the INSERT fails with an SQLCODE of -330.
| Important: | If you are running in a mixed environment, ensure you have installed the latest maintenance for the CCSID support of your DB2 for MVS program. |
For more information on character translation, see the Character Conversion for Distributed Data chapter in DB2 Version 4 Administration Guide, Volumes 1,2.