The following sections describe commonly known issues with Capture and Apply for MVS.
Before running Capture for MVS, ensure that you have all the PTFs for your level of DB2 and for the IFI installed on your DB2 subsystem. Specific Capture program problems are described below.
Problem
Capture for MVS does not start.
Ensure that APF authorization has been performed for all STEPLIB libraries as specified in the RUN JCL.
Problem
Capture for MVS 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
Updates to the base table are not being replicated to the target table.
DB2 writes log information to the active log in multiples of 4KB VSAM control intervals (CI). In order for Capture to obtain these log records, there must be at least one CI written to the log. If your application has base table updates less than 4KB in a quiet DB2 (no other log updates), you do not see the update results in the change data table until the 4KB limit is reached. To see your updates you can either:
See Capture for MVS's program directory for information on creating a sample filler table. You can insert dummy rows into this table to reach the 4KB limit, so Capture can see other updates immediately.
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 Capture 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 Capture 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 Capture 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 progress made by Capture. 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 MVS failed while using LE/370 environment.
Capture can run under both C/370 and LE/370 environments. If running under LE/370 environment, you must specify REGION=3M in the RUN step.
Problem
Capture for MVS issued message ASN0000E instead of the proper message number.
If you receive message ASN0000E, it implies that a generic message has been issued instead of a proper message. This happens if the specified VSAM message file in RUN JCL was not found. See the Capture for MVS program directory for information on installing the VSAM message file.
Problem
Capture for MVS terminated unexpectedly.
The Capture for MVS 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 program packages, and make sure to bind the Capture package to the source server database and to bind both the Apply program 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 occured during a full refresh, you can use an alternative method to load large tables, described in "Loading Large Copies".
If the error occured 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".
Problem
Capture 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 LASTSUCCESS, 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 program 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 copy 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.