ASN6000-7999

ASN6000W

The average Q Capture latency during the last monitor interval exceeded the alert threshold. Q Capture latency measures the average time between transactions being committed at the source database and the Q Capture program sending the transaction to be replicated. The threshold was set for the QCAPTURE_LATENCY alert condition in the Replication Alert Monitor program.

To reduce Q Capture latency, use the Performance Advisor in the Q Replication Dashboard or follow the instructions in "Actions to take when Q Replication latency is too high."

ASN6001W

One or more replicated transactions exceeded the threshold for memory usage during the last monitor interval. The threshold was set for the QCAPTURE_TRANSIZE alert condition in the Replication Alert Monitor program.

If the amount of memory use is not acceptable, you can increase the value of the Q Capture memory_limit parameter.

ASN6002W

The Q Capture program deactivated the Q subscription, which resulted in the QCAPTURE_SUBSINACT alert condition in the Replication Alert Monitor.

Look for messages from the Q Capture program in the Q Replication Dashboard, Q Capture log, or IBMQREP_CAPTRACE table that state why the Q subscription was deactivated.

ASN6003W

Total memory usage by the Q Capture program during the last monitor interval exceeded the threshold that was set for the QCAPTURE_MEMORY alert condition in the Replication Alert Monitor.

[Optional] If the amount of memory use that is reported in the max-memsize runtime token in this message is acceptable, increase the value of the Q Capture memory_limit parameter to a value that is larger than the amount that is reported in the max-memsize runtime token.

ASN6004W

The average Q Apply latency during the last monitor interval exceeded the alert threshold. Q Apply latency measures the time it takes for a transaction to be applied to a target table after the Q Apply program gets the transaction from a receive queue. The threshold was set for the QAPPLY_LATENCY alert condition in the Replication Alert Monitor program.

To reduce Q Apply latency, use the Performance Advisor in the Q Replication Dashboard or follow the instructions in "Actions to take when Q Replication latency is too high."

ASN6005W

The average end-to-end latency during the last monitor interval exceeded the alert threshold. End-to-end latency measures the total time that replication requires to capture changes and apply those changes to a target database. The threshold was set for the QAPPLY_EELATENCY alert condition in the Replication Alert Monitor program.

Follow the instructions in the Knowledge Center topic "Actions to take when Q Replication latency is too high."

ASN6006W

The peak memory usage by the Q Apply program for processing transactions from this receive queue during the last monitor interval exceeded an alert threshold. The threshold was set for the QAPPLY_MEMORY alert condition in the Replication Alert Monitor program.

To allocate more memory for processing transactions from this receive queue, increase the value of the memory_limit parameter for the replication queue map that includes the receive queue.

ASN6007W

The Q Apply program inserted a row in the IBMQREP_EXCEPTIONS table because of a conflict or SQL error at a target. The Replication Alert Monitor reported the insertion because the QAPPLY_EXCEPTIONS alert condition is enabled.

Use the SQLCODE and SQLSTATE values to determine the cause of the exception. You can use the Q Replication Dashboard to get more detail about the exception, or look at the IBMQREP_EXCEPTIONS table.

ASN6008W

The Q Apply program stopped processing messages on the specified receive queue. This action is also known as deactivating or stopping the receive queue. The Replication Alert Monitor reported the action because the QAPPLY_RECVQINACT alert condition is enabled.

Look for messages from the Q Apply program that explain why it stopped processing messages on the receive queue.

ASN6009W

The fullness of the specified receive queue or spill queue exceeded an alert threshold. The Replication Alert Monitor reported the action because one or both of the alert conditions QAPPLY_QDEPTH or QAPPLY_SPILLQDEPTH are enabled.

Take one of the following actions to reduce the fullness of the receive queue or spill queue:

Receive queue

Follow the instructions in "Checking for and preventing a full receive queue."

Spill queue

If possible, stop the Q Capture program. If necessary, increase the value for the MAXDEPTH attribute of the spill queue.

ASN6010W

The program stopped. The Replication Alert Monitor reported the action because one or both of the alert conditions QCAPTURE_STATUS or QAPPLY_STATUS are enabled.

If the stoppage was unexpected, look for messages from the program to indicate why it stopped.

ASN6011W

An average end-to-end latency event was defined in the IBMQREP_APPEVTDEFS table. The average latency during the event interval exceeded the maximum threshold.

Check the Q Apply server to determine why the latency threshold was exceeded. Further actions might be needed to reduce latency.

ASN6012I

An average end-to-end latency event was defined in the IBMQREP_APPEVTDEFS table. The average latency had exceeded the maximum threshold but now is back within the required specification.

This message is for your information only. No action is required.

ASN6013W

A latency event for point-in-time (PIT) consistency was defined in the IBMQREP_APPEVTDEFS table. The value of PIT-consistency latency exceeds the maximum threshold.

Check the Q Apply server to determine why the maximum threshold was exceeded. Further actions might be needed to reduce the latency.

ASN6014W

A latency event for point-in-time (PIT) consistency was defined in the IBMQREP_APPEVTDEFS table. The value of PIT-consistency had exceeded the maximum threshold and is now is back within the required specification.

This message is for your information only. No action is required.

ASN6200I

This message shows the in-memory EIF event definitions, which were fetched from the IBMQREP_APPEVTDEFS table.

This message is for your information only. No action is required.

ASN6201W

The expected event definition message is too long to fit in the WTO (Write To Operator) message. No messages were sent. The event definitions display in the job log instead.

Update the IBMQREP_APPEVTDEFS table by shortening the workload name or decreasing the number of workloads, and then use the reinitq command to refresh in-memory event definitions.

ASN7000I

This message describes the number of publications or Q subscriptions that are in various states.

This message is for your information only. No action is required.

ASN7001I

The command that was received might be processed asynchronously. The program will issue a message when the command is processed and store that message in the trace table (IBMQREP_CAPTRACE).

This message is for your information only. No action is required.

ASN7002E

The number of messages reached the number that is set for the MAXDEPTH attribute on the send queue. The ERROR_ACTION value determines how the program behaves due to this error. The value for the Q Capture program is stored in the IBMQREP_SENDQUEUES table.

Do not clear the queue or all of the messages containing your changes will be removed.

Make sure that Q Apply or a subscribing application is running.

ASN7003I

This message describes the number of Q subscriptions that are in various states.

This message is for your information. No action is required.

ASN7004E

The column shown in the IBMQREP_SRC_COLS table does not exist in the source table. This error occurred due to one of the following problems:

• The column name was specified incorrectly in the publication or Q subscription.
• The source table changed since the publication or Q subscription was created.
• Extra columns were specified in the publication or Q subscription.

Therefore, the publication or Q subscription cannot be activated.

Ensure that the column name is specified correctly in the publication or Q subscription.

If the publication or Q subscription is not correct (for example, because it contains more columns than are available at the source table), use the replication administration tools to perform the following steps:

1. Delete and recreate the publication or Q subscription.
2. Activate the publication or Q subscription.

ASN7006E

The specified publication or Q subscription was deactivated due to an error that was specified in a previous message.

Look in the Q Capture diagnostic log or in the IBMQREP_CAPTRACE table to find the error message that precedes this one. Take the appropriate action to correct the problem (follow the instructions in the user response of the previous message). Activate the publication or Q subscription.

ASN7007E

If new database partitions were added, warm start the Q Capture program using the add_partition='Y' option.

If the restart message in the restart queue was corrupted, cold start the Q Capture program.

ASN7008I

The REINIT command was processed successfully. As a result, the Q Capture program recognizes any changed attributes for publications, Q subscriptions, and queue maps. Any new publications or Q subscriptions were automatically activated. Refer to the message text for the number of publications or Q subscriptions that are in various states.

This message is for your information only. No action is required.

ASN7010I

The Q Capture program is replicating changes for the active publication or Q subscription.

This message is for your information only. No action is required.

ASN7011E

The source table specified in the publication or Q subscription does not exist. Most likely the wrong table name was specified when attempting to activate the publication or Q subscription. Otherwise, the source table might have been dropped intentionally since the publication or Q subscription was created.

ASN7012I

The Q Capture program successfully reinitialized the publication and it will process transactions according to the new attributes.

This message is for your information only. No action is required.

ASN7013I

The publication or Q subscription was deactivated because the CAPSTOP signal was received.

This message is for your information only. No action is required.

ASN7015W

An unrecoverable MQ error occurred on this send queue. The Q Capture program stops. The error action I to deactivate the publications or Q subscriptions on the send queue has been deprecated.

Look in the Q Capture diagnostic log file or the IBMQREP_CAPTRACE table to find the error message that precedes this one. Take the appropriate action to correct the MQ problem (follow the instructions in the user response of the previous message). After you fix the error, start the Q Capture program in warm mode.

ASN7016E

The publication or Q subscription does not have a load phase (HAS_LOADPHASE=N). This error could be caused by an incorrect publication or Q subscription name specified in the LOADDONE signal or in the load done received message.

If the publication or Q subscription has a load phase and you inserted the LOADDONE signal

Make sure that the publication name or Q subscription name in the signal is correct and re-insert the LOADDONE signal.

If the publication or Q subscription has a load phase and you sent the load done received message

Make sure that the publication name or Q subscription name in the message is correct and resend the load done received message.

ASN7017I

See message text.

This message is for your information only. No action is required.

ASN7018E

The source table is incorrectly defined. No data will be captured for this publication or Q subscription.

Alter the source table so that the DATA CAPTURE CHANGES attribute is set and restart the publication or Q subscription. For example:

 alter table src_owner.src_table     data capture changes 

ASN7019I

See message text.

This message is for your information only. No action is required.

ASN7020I

See message text.

This message is for your information only. No action is required.

ASN7021E

An internal load option (HAS_LOADPHASE=I) is not supported for publications.

Specify a supported load option for the publication (ensure that the correct HAS_LOADPHASE value is in the IBMQREP_SUBS table) and start the publication.

ASN7022W

The program cannot find this publication or Q subscription in the IBMQREP_SUBS control table.

Ensure that the publication or Q subscription name is accurate for the signal.

ASN7023W

Since the source table does not have a primary key, unique constraint, or unique index, all columns except LOB columns were selected as the replication key. This might impact performance because of the amount of data sent. The related publications or Q subscriptions are still activated.

Create a primary key, a unique constraint, or a unique index on the source table and reinitialize all related publications or Q subscriptions if necessary.

ASN7024E

The program detected an internal inconsistency. This could happen if you are falling back from a higher-level PTF or version of Q Capture to a previous PTF level or previous version. Q Capture saves its restart information using a new format. Q Capture can warm start by using restart information from a prior level of Q Capture, but prior levels of Q Capture will not be able to use the new restart information format to warm restart.

Check that the correct version of the Q Capture program is running and that the restart queue was not improperly altered. If you need to warm restart a prior level of Q Capture, you must start Q Capture from a known point in the log by specifying the LSN and MAXCMTSEQ parameters. Look for message ASN7109I in the Q Capture diagnostic log. The value of LSN is described as "the lowest log sequence number of a transaction still to be committed." The value of MAXCMTSEQ is described as "the highest log sequence number of a successfully processed transaction."

ASN7025E

See message text.

Make sure the restart queue is correctly specified and accessible to application programs (GET enabled).

ASN7026E

The signal type or signal subtype is not supported.

Check the SIGNAL_TYPE and SIGNAL_SUBTYPE of the row inserted in the IBMQREP_SIGNAL control table. Ensure that the signal type or signal subtype is correct and try inserting the signal again.

ASN7027E

The Q Capture program could not warm start. See message text.

Cold start the Q Capture program.

ASN7028E

The MAX_MESSAGE_SIZE column value of this send queue is not valid because it exceeds the MAXMSGL attribute of the WebSphere MQ queue manager. The send queue is invalidated.

Decrease the MAX_MESSAGE_SIZE column value for this send queue. If necessary, increase the MAXMSGL attribute:

• For remote send queues, increase the MAXMSGL attribute of the transmission queue.
• For local send queues, increase the MAXMSGL attribute.

Restart any publication or Q subscription on the send queue.

If the send queue is remote, the MAX_MESSAGE_SIZE value must be at least 4 KB smaller than the MAXMSGL attribute of both the transmission queue and the queue manager. This 4 KB difference accounts for the extra information that is carried in the message header while the message is on the transmission queue.

ASN7029E

See message text.

Increase the maximum message size of the restart queue and warm start the Q Capture program.

ASN7030E

The number of messages reached the number that is set for the MAXDEPTH attribute on the restart queue.

If necessary, increase the value for the MAXDEPTH attribute of the restart queue. After you increase the value, cold start the Q Capture program.

ASN7033E

The following values are valid for the reason code:

0

An ordinary identifier for a column name must start with a letter followed by letters, numbers, or underscores.

1

The column name is not followed by a double quotation mark.

4

The search condition is missing the keyword WHERE.

5

The search condition contains a column that is not in the source table

6

The search condition does not contain any source table column names.

7

The combined search condition and change condition does not contain any source table column names or log record variables.

Ensure that the search condition or change condition is in the proper format and restart the publication or Q subscription.

ASN7034W

See message text.

Make sure that the format and the attributes of the control message are correct and put the message on the administration queue again.

ASN7035W

See message text.

Make sure that your WebSphere MQ configuration is correct.

ASN7036E

The program detected an internal inconsistency.

Contact IBM Software Support. Provide the exact message that you received, which identifies the Q Capture schema. Provide the diagnostic log file. Also, provide a trace dump (ASNTRC DMP) file, if available.

ASN7037E

An internal inconsistency was detected.

Contact IBM Software Support. Provide the diagnostic log file. Also, provide a trace dump (ASNTRC DMP) file, if available.

ASN7038E

See message text.

Correct the XML control message so that it satisfies the validity constraints of the XML schema for control messages as specified in the mqsub.xsd file, and put it on the administration queue again.

ASN7039W

The XML control message is not valid and was ignored. The Q Capture program continues to run.

Fix the XML control message and resend it.

ASN7040E

The XML control message is ignored and the Q Capture program continues to run.

Contact IBM Software Support. Provide the diagnostic log file. Also, provide a trace dump (ASNTRC DMP) file, if available.

ASN7043W

The request that was received on the administration queue could not be performed because the publication or Q subscription does not exist or is inactive.

Ensure that the name of the publication or Q subscription is correct and that it is in the active state. Put the control message on the administration queue again.

ASN7045E

The REINITQ command must be issued for an active send queue.

Check that the queue name is correct and reissue the REINITQ command or reinitialize the queue from the Replication Center.

ASN7046I

See message text.

This message is for your information only. No action is required.

ASN7051W

At least one column in the source and target tables must be specified as a key column for the publication or Q subscription. The name of this column is specified in the IBMQREP_SRC_COLS table.

Ensure that at least one column in the source and target tables is specified as a key column for the publication or Q subscription, then activate the publication or Q subscription.

ASN7052E

The source table is incorrectly defined. No data will be captured for this publication or Q subscription.

Alter the source table so that the DATA CAPTURE CHANGES attribute is set to INCLUDE LONGVAR COLUMNS and restart the publication or Q subscription. For example:

 alter table owner.table data capture changes       include longvar columns 

ASN7057I

A duplicate SUB_ID was found in the control table IBMQREP_SUBS for publication or Q subscription name. The value in this column must be unique.

This message is for your information only. No action is required.

ASN7059E

The GROUP_MEMBERS column in the IBMQREP_SUBS table must be null for an inactive Q subscription in multidirectional replication.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7060E

To activate a Q subscription for multidirectional replication, all the corresponding Q subscriptions in the same Q subscription group in the IBMQREP_TARGETS table must be in the active or inactive state. This error might occur if any Q subscriptions in the same Q subscription group are in the process of being initialized or deactivated.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7061E

In multidirectional replication, all Q subscriptions that share the same Q subscription group and table must have the same SOURCE_NODE in the IBMQREP_SUBS table.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7062E

To activate a Q subscription for peer-to-peer replication, all the other Q subscriptions in the same Q subscription group must be in the active or inactive state in the IBMQREP_SUBS table. This error might occur if any Q subscriptions in the same Q subscription group are in the process of being initialized or deactivated.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7063E

In peer-to-peer replication, multiple Q subscriptions in a Q subscription group cannot start at the same time.

Check the IBMQREP_SUBS table to ensure that the other Q subscription is in the active ('A') state. Then activate the Q subscription that was placed in the inactive state.

ASN7065E

In multidirectional replication, the source node and target node in a Q subscription must be in the supported range.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7067E

The program requires a parameter of the signal to be specified in SIGNAL_INPUT_IN. This error will be issued if some of the parameters are missing or in an unexpected format.

Ensure that the SIGNAL_INPUT_IN is specified correctly and re-insert the signal.

ASN7073E

The REINIT_SUB command requires that a publication or Q subscription is active.

Check that the publication or Q subscription was specified correctly in the command parameters and reissue the command.

ASN7074E

The REINIT_SUB command or the REINIT_SUB signal applies only to publications or to Q subscriptions of type U (unidirectional) that are in the ACTIVE state. Unidirectional Q subscriptions or publications in a non-ACTIVE state, or Q subscriptions of type B (bidirectional) or P (peer-to-peer) cannot be reinitialized.

For a publication, ensure that you specify the correct name and that the publication is in ACTIVE state. For a Q subscription, ensure that you specify the correct name, that the SUBTYPE in the IBMQREP_SUBS table is U, and that the Q subscription is in ACTIVE state. Reissue the command or reinsert the signal.

ASN7079W

Both row operations and transaction messages are valid in XML message format, but only transaction messages are valid in compact format.

If you want to publish row operations, the MESSAGE_FORMAT in the IBMQREP_SENDQUEUES control table must be set to 'X'.

ASN7080E

This error is issued when an MQ exception report message is generated by the receiving MCA (message channel agent) in response to a message delivery problem to the target WebSphere MQ queue manager.

See the reason code documentation in the WebSphere MQ application programming reference for an explanation of the reason code and for information about actions that you might need to take for the target WebSphere MQ queue manager.

ASN7081W

See message text.

This message is for your information only. No action is required.

ASN7083E

Columns of LOB data type must not be specified as key columns for a publication or Q subscription.

Make sure that all columns in the publication or Q subscription that are specified as key columns are of a data type other than LOB. Activate your publication or Q subscription.

ASN7084E

All source columns and version columns must be included in the Q subscription for peer-to-peer replication.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7085E

Logical tables for Q subscriptions in peer-to-peer replication must contain version columns.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7086E

The data type of the version column was not defined correctly, or the version column was not defined in the logical table for the Q subscription in peer-to-peer replication.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7087E

In multidirectional replication, the send queue of a Q subscription must use the compact message format.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7088E

Q subscriptions in multidirectional replication must have a Q subscription group, a source node, and a target node.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7089E

The source table for a publication or Q subscription that contains LOB columns must have one or more key columns. All columns that are specified as key columns must be of a data type other than LOB data type

ASN7090E

A Q subscription in peer-to-peer replication cannot contain a search condition.

If this Q subscription is for unidirectional or bidirectional replication, change the subscription type to 'U' or 'B' respectively. If this Q subscription is for peer-to-peer replication, remove the search condition. In any case, redefine the Q subscription using one of the replication administration tools and activate the Q subscription.

ASN7091W

See message text.

Redefine the Q subscription using one of the replication administration tools.

ASN7093E

Only one Q subscription is allowed in a Q subscription group for bidirectional replication.

Redefine the Q subscription using one of the replication administration tools, and then activate the Q subscription.

ASN7094E

The program received an unexpected or invalid signal in regards to a subtype or state of a particular publication or Q subscription.

Make sure that the publication or Q subscription is expecting this signal. For example, a CAPSTART signal should only be targeted at an inactive Q subscription. Re-insert the signal if needed.

ASN7095E

The SUB_ID in the table IBMQREP_SUBS cannot be null for a previously active publication or Q subscription.

Use the ASNCLP command-line program or Replication Center to stop and then start the publication or Q subscription.

ASN7096E

The publication or Q subscription name in the IBMQREP_SUBS control table may not contain a semicolon.

Make sure that the publication or Q subscription name does not contain a semicolon and then start the publication or Q subscription.

ASN7097E

See message text.

Restart the Q subscription after ensuring that there are no other Q subscriptions for the same table in another Q subscription group.

ASN7098W

The source table column that was specified in the ADDCOL signal insert is already part of the Q subscription or publication definition.

Ensure that the column is correctly specified and then insert the ADDCOL signal again if necessary.

ASN7099E

You can only add, drop, or change the specified number of columns for a Q subscription in a single transaction.

Take one of these actions:

• If you were adding a column with the ADDCOL signal, reissue the signal.
• If the column change was made by automatic replication of DDL, delete and recreate the Q subscription.

ASN7100I

Changes to the column are now being captured based on the Q subscription or publication definition. For Q subscriptions, the new column will be added to the target table if the column does not already exist in the target table.

This message is for your information. No action is required.

ASN7101E

Columns that are being added to Q subscriptions or publications with the ADDCOL signal must be nullable or defined as NOT NULL WITH DEFAULT.

Ensure that the column that is being added is correctly defined, and then insert the ADDCOL signal again.

ASN7102E

The Q Capture program is unable to warm start because the restart information in the restart queue is invalid.

Ensure that you specified the restart queue correctly, or empty the restart queue and cold start the Q Capture program.

ASN7103W

The Q Capture program is validating the database partition information that is stored in the restart information. The program found that some database partitions that it knew about from a prior invocation have been removed. The Q Capture program will update its database partition information and continue normally.

Validate that the listed database partitions where actually removed. If so, no further action is required. If the database partitions have not been removed, stop the Q Capture program because it will not capture transactions on the missing database partitions. Start the Q Capture program with a start mode of cold.

ASN7104E

All of the publications that use the same send queue must have the same topic. The publication was not activated because it did not have the same topic.

Ensure that all of the publications that use the same send queue have the same topic.

ASN7105I

The send queue was deleted from the IBMQREP_SENDQUEUES since the last run.

This message is for your information. No action required.

ASN7106I

The restart information for the send queue is not present in the restart message. The restart message might be corrupted. The Q Capture program will fix its restart information.

message is for your information. No action required.

ASN7107E

The Q Capture program can process a maximum of 20 ADDCOL signals within one WebSphere MQ commit interval. This interval specifies how often a Q Capture program commits messages to WebSphere MQ and is set by using the Q Capture program's commit_interval parameter.

Insert the ADDCOL signals that failed so that the Q Capture program can commit them within a new interval.

ASN7108I

The Q Capture program starts and records the values of the restart message. Q Capture will start reading the log from the restart log sequence number (the lowest LSN of a transaction still to be committed) and will ignore any transactions whose commit is before the maximum commit sequence number (the highest LSN of a successful transaction). In a partitioned database, these log indicators come from the partition where the Q Capture program is running.

You can use the LSN and MAXCMTSEQ values to start Q Capture from a known point in the recovery log.

This message is for your information only. No action is required.

ASN7109I

The Q Capture program terminates and records the values of the restart message. During the next run, Q Capture will start reading the log from the restart log sequence number (the lowest LSN of a transaction still to be committed) and will ignore any transactions whose commit is before the maximum commit sequence number (the highest LSN of a successful transaction). In a partitioned database, these log indicators come from the partition where the Q Capture program is running.

You can use the LSN and MAXCMTSEQ values to start Q Capture from a known point in the recovery log.

This message is for your information only. No action is required.

ASN7110E

If you want to start the Q Capture program from a specific point in the recovery log, you must specify both the LSN parameter and the MAXCMTSEQ parameter. The LSN parameter specifies the lowest LSN of a transaction still to be committed. The MAXCMTSEQ parameter specifies the highest log sequence number of a successful transaction.

Restart the Q Capture program and specify both the LSN parameter and the MAXCMTSEQ parameter.

ASN7111E

The Q Capture program was stopped because the LSN parameter and the MAXCMTSEQ parameter must be specified in warm start mode.

Restart the Q Capture program in warm start mode with the LSN parameter and the MAXCMTSEQ parameter.

ASN7112I

ASN7113I

ASN7114I

ASN7115I

ASN7116I

ASN7117I

ASN7118I

ASN7119I

ASN7120I

ASN7121I

ASN7122I

ASN7123I

ASN7124I

ASN7125I

ASN7126I

ASN7127I

ASN7128I

Q Capture executes the db2flsn (find log sequence number) command when Q Capture starts to display the name of the log file that includes the oldest database log sequence number that is needed for a restart. This number is shown in the ASN7155I message. Q Capture executes db2flsn when Q Capture stops to display the name of the log file that includes the last database log sequence number that was captured. This number is shown in the ASN7156I message. Q Capture also executes db2flsn when it receives the status show details command to display the oldest database log file that is needed for a restart and the current database log file that was captured. If the user ID that runs the Q Capture program does not have read privilege for the SQLOGCTL.LFH.1 and SQLOGCTL.LFH.2 log control files in the database home directory for the Q Capture server, the db2flsn program generates return code -101.

If the utility return code is -101, give the user ID that runs the Q Capture program read privilege on the SQLOGCTL.LFH log control files.

ASN7129I

The Q Capture program was unable to open a pipe to execute the db2flsn utility.

This message is for your information. No action is required.

ASN7130E

The Q Capture program encountered a different version of the table because the table was altered. The Q Capture program was not able to determine the correct version by reading from the IBMQREP_COLVERSION and IBMQREP_TABVERSION tables. The tables might have been dropped.

Ensure that the IBMQREP_COLVERSION and IBMQREP_TABVERSION tables have not been dropped. If they are missing, restore these tables and restart the Q Capture program.

ASN7131I

ASN7132E

The Q Capture program stopped because information that is needed to restart is missing and Q subscriptions are active.

Restart the Q Capture program in cold start mode if needed. You can also use the asnqcap command with the lsn and maxcmtseq parameters to specify a restart point.

ASN7133I

ASN7134E

ASN7135E

Columns of LONG type are not valid for the key that is used for publishing or replication (IS_KEY > 0 in the IBMQREP_SRC_COLS or IBMQREP_TRG_COLS control tables).

Use the Replication administration tools to redefine the columns that are used as a replication or publishing key, and then start the publication or Q subscription.

ASN7136E

The max_message_size value of the queue map that uses this send queue is too large. If the send queue is remote, the max_message_size value must be at least 4 KB smaller than the MAXMSGL attribute of both the transmission queue and the queue manager. This 4 KB difference, which is specified by MQ_MSG_HEADER_LENGTH, accounts for the extra information that is carried in the message header while the message is on the transmission queue.

Use the ASNCLP or Replication Center to reduce the MAX_MESSAGE_SIZE value for the queue map. If necessary, increase the MAXMSGL attribute of the transmission queue, send queue, remote queue, the queue channels, and the client-server connection channels (WebSphere MQ client). Restart any publications or Q subscriptions that use the send queue.

ASN7137W

The MAX_MESSAGE_SIZE value of the publishing queue map or replication queue map that specifies this send queue might too small to contain a row in the WebSphere MQ message. If this problem occurs when the Q Capture program is running, Q Capture stops.

Increase the MAX_MESSAGE_SIZE value for the queue map. Reinitialize the queue map by using the reinitq subcommand of the MODIFY or asnqccmd command.

ASN7138W

The source database columns are encoded using a code page that is different from the code page that is specified in the MESSAGE_CODEPAGE column of the IBMQREP_SENDQUEUES table. The Q Capture program will convert all data in the messages that it puts on the send queue.

No action is necessary if data conversion is acceptable. If you wish to avoid data conversion, stop the Q Capture program and update the MESSAGE_CODEPAGE value to match the source column code page. Then start Q Capture.

ASN7139W

If you specify that a publishing queue map is used for delimited messages, the value for the interval that the Q Capture program uses to send heartbeat messages must be 0 (no heartbeat messages are sent).

No action is necessary. The Q Capture program overrides the HEARTBEAT_INTERVAL value. If you do not wish to see this message, use the ASNCLP command-line program or Replication Center to change the heartbeat interval for the queue map to 0. Then use the reinitq command or replication administration tools to reinitialize the send queue.

ASN7140E

When publishing delimited messages, the Q Capture program always sends before and after values for an update operation. If you specify that a publication uses delimited message format, you must enable before values.

Use the ASNCLP or Replication Center to specify before values for the publication and then start the publication.

ASN7141E

When publishing delimited messages, the Q Capture program always sends all columns for a row even if they are not changed. If you specify that a publication will use delimited message format, the CHANGED_COLS_ONLY attribute must be N.

Use the ASNCLP or Replication Center to specify CHANGED_COLS_ONLY=N for the publication.

ASN7142I

The Q Capture program could not put a message on the queue and received one of the following WebSphere MQ reason codes from the MQPUT operation:

• 2051: MQRC_PUT_INHIBITED
• 2053: MQRC_Q_FULL
• 2192: MQRC_STORAGE_MEDIUM_FULL
• 2346: MQRC_CF_STRUC_IN_USE
• 2373: MQRC_CF_STRUC_FAILED

When this error is received, the Q Capture program retries sending the message based on the WebSphere MQ qfull_num_retries and qfull_retry_delay parameters. This error might occur if the Q Apply program is not processing the messages on the receive queue. The Q Apply program might be stopped or the Q Capture program might be putting messages on the queue faster than WebSphere MQ can process them. The error might also occur if many changes accumulated at the source table while the Q Capture program was stopped. This error is more likely to happen in a queue-sharing environment.

This message is for your information only. No action is required.

ASN7143I

The Q Capture program needed to retry the MQPUT operation multiple times because the queue was full.

This message is for your information only. No action is required.

ASN7145E

Oracle LogMiner found a dictionary mismatch and could not translate the log record. Possible causes include:

• Database-wide supplemental logging is not enabled.
• Table-level supplemental logging is not enabled for the subscribed table.
• A subscribed table was altered and Q Capture was restarted at a system change number (SCN) location that is earlier than the DDL change.

All of these situations can cause a mismatch between the online dictionary and the format of the log records.

Enable database-wide supplemental logging on the Oracle source database. Additionally, enable table-level supplemental logging for all subscribed tables. Start all Q subscriptions for the table.

ASN7146E

Log records that are needed by the Q Capture program are missing. The program stops so that you can locate missing redo log files or archive log files.

Use the Oracle error message to identify which redo or archived logs contain these SCN values and make these files available to Oracle, then start Q Capture. If these missing log files are no longer available, a cold start is required.

ASN7147E

The Q Capture program uses Oracle LogMiner to read log records for the Oracle source table. LogMiner returned an error while trying to start.

See the Oracle messages and codes documentation for the cause and action related to this error and perform the recommended action.

ASN7148E

An error occurred when the Q Capture, Q Apply, or Replication Alert Monitor program issued an OCI call. The error might be caused by an Oracle problem that needs to be investigated, such as an out-of-space condition, or Oracle might be unavailable for use by applications. This message is sometimes followed by a second message that provides information about what the replication program was doing when the error occurred.

See the Oracle messages and codes documentation for an explanation of this error code and for information about corrective actions that you might need to take in Oracle. If a replication program issued another message immediately after this one, see the explanation and user response for that message.

ASN7149E

An error occurred when the Q Capture, Q Apply, or Replication Alert Monitor program issued an OCCI call. The error might be caused by an Oracle problem that needs to be investigated, such as an out-of-space condition, or Oracle might be unavailable for use by applications. This message is sometimes followed by a second message that provides information about what the replication program was doing when the error occurred.

See the Oracle messages and codes documentation for an explanation of this error code and for information about corrective actions that you might need to take in Oracle. If a replication program issued another message immediately after this one, see the explanation and user response for that message.

ASN7150E

An error occurred when the Q Capture, Q Apply, or Replication Alert Monitor program issued an OCCI call. The error might be caused by an Oracle problem that needs to be investigated, such as an out-of-space condition, or Oracle might be unavailable for use by applications. This message is sometimes followed by a second message that provides information about what the replication program was doing when the error occurred.

See the Oracle messages and codes documentation for an explanation of this error code and for information about corrective actions that you might need to take in Oracle. If a replication program issued another message immediately after this one, see the explanation and user response for that message.

ASN7151E

An internal error occurred during processing of an Oracle log record.

Redefine the Q subscription for the table if this data type is not supported. Otherwise, contact IBM Software Support.

ASN7153W

TRUNCATE TABLE statements are not replicated by the Q Capture program. Any rows that were deleted from the source table by the statement were not deleted from the target table.

This message is for your information only, and no action is required.

ASN7154E

The source table is incorrectly defined. The SUPPLEMENTAL LOG DATA attribute must be defined for all columns.

Alter the source table so that SUPPLEMENTAL LOG DATA (ALL) COLUMNS is enabled and restart the publication or Q subscription. For example:

 alter table <src_owner>.<src_table>       add supplemental log data (all) columns; 

ASN7155I

When the Q Capture program started, this log file contained the first database log sequence number (LSN) or Oracle system change number (SCN) that the program read.

This message is for your information only. No action is required.

ASN7156I

When the Q Capture program stopped, this log file contained the last database log sequence number (LSN) or Oracle system change number (SCN) that the program read.

This message is for your information only. No action is required.

ASN7157E

At startup, the Q Capture program found an unsupported value in the COMPATIBILITY column. Q Capture for Oracle sources can only work with Q Apply programs at Version 9.5 or later. The COMPATIBILITY column indicates the version of messages that Q Capture sends to Q Apply.

Update the COMPATIBILITY column in IBMQREP_CAPPARMS to '0905' or above and restart the Q Capture program.

ASN7158E

At startup, the Q Capture program found an unsupported value in the LOB_SEND_OPTION column. Q Capture for Oracle sources only supports the inline send option for LOBs.

Update the LOB_SEND_OPTION column in IBMQREP_CAPPARMS to "I".

ASN7160W

During the last period when Q Capture wrote performance statistics to its control tables, the average amount of time that Q Capture took to receive a batch of log records from LogMiner was greater than the value of the Q Capture commit_interval parameter. This parameter sets the length of time that Q Capture waits to commit messages that are on the send queue to WebSphere MQ. An average fetch time that is larger than the commit interval slows Q Capture performance.

Update the commit_interval parameter to a value in milliseconds that is greater than or equal to the average fetch duration that is shown in this error message.

ASN7166W

The LOB or XML data was too large for the transaction message.

Increase the MAX_MESSAGE_SIZE value in the IBMQREP_SENDQUEUES table. You might also need to increase the size of the MAXMSGL parameter for the WebSphere MQ send queue. Ensure that the value for the MAX_MESSAGE_SIZE parameter is at least 4KB smaller than value for the MAXMSGL parameter.

If you cannot increase the MAX_MESSAGE_SIZE parameter, you can set the LOB_SEND_OPTIONS value in the IBMQREP_CAPPARMS table to 'S' to send the LOB values in a LOB message following the transaction message.

ASN7167E

ASN7168E

None of the four types of delimiters that are used for delimited messages in event publishing can use the same character.

Use the Q Replication Dashboard or Replication Center to change the publishing queue map so that all of the delimiters have unique values. Then restart the Q Capture program.

ASN7169E

The delimiters that are used for delimited messages in event publishing cannot be alphanumeric characters (0-9, aA-zZ).

Use the Q Replication Dashboard or Replication Center to change the publishing queue map so that none of the delimiters use alphanumeric characters. Then restart the Q Capture program.

ASN7170E

A WebSphere MQ message was put on the send queue that is larger than the maximum message size limit that was defined for the queue map that uses this queue.

Increase the value of max_message_size for the queue map and reinitialize the Q Capture program.

ASN7171E

Data in LOB or XML columns is sent within the transaction message. If the LOB or XML data is large, you might need to increase the maximum message size for WebSphere MQ messages. Two parameters govern the allowable size of messages: max_message_size for queue maps, and MAXMSGL (maximum message length) for the WebSphere MQ queue.

Increase the value of max_message_size for the replication or publishing queue map. You might also need to increase the size of MAXMSGL for the WebSphere MQ send queue that is specified in the queue map. Ensure that the value for max_message_size is at least 4 KB smaller than the value for MAXMSGL.

ASN7172E

The delimited message format does not support sending LOB values in a separate message. The delimited message format only supports sending a LOB value within the transaction message (lob_send_options=I).

Use the replication administration tools to set lob_send_options=I. Then reinitialize the Q Capture program and start the publication.

ASN7173W

The Q error action prompts Q Capture to continue putting messages on active send queues even when one send queue is deactivated. Q Capture saves restart information for Q subscriptions or publications that use the deactivated send queue, and can recapture changes for this queue from the log and bring it up to the same restart point as the other queues.

Use the WebSphere MQ error number to determine the problem that caused the error on the queue, and then use the startq command to resume replication or publishing on the queue.

ASN7174I

Q Capture recaptures changes for this queue from the log and brings it up to the same restart point as the other queues.

This message is for your information only. No action is required.

ASN7175E

ASN7176I

Q Capture continues to put messages on active send queues even when one send queue is deactivated. Q Capture saves restart information for Q subscriptions or publications that use the deactivated send queue, and can recapture changes for this queue from the log and bring it up to the same restart point as the other queues.

Use the startq command to resume replication or publishing on the queue.

ASN7177I

The stopq command was issued for a send queue that does not exist or is not known to the Q Capture program.

Check that the queue name is correct and reissue the stopq command. If the queue was added while replication is active, start the Q subscriptions that use the queue so that the Q Capture program becomes aware of the queue.

ASN7178I

While all queues are inactive, the Q Capture program continues reading the log for signals such as CAPSTART, continues inserting into its monitor tables, and waits for commands.

This message is for your information only. No action is required.

ASN7179W

• Use the startq command to resume replication or publishing on the queue.
• Stop all other active Q subscriptions that use the queue and then start the Q subscription that is specified in this message.
• Stopping and starting the other active Q subscriptions prompts a new load (full refresh) of the target tables for all of the Q subscriptions. If you want to prompt a new load for just the table that is specified in the message text, use the startq command.

ASN7180E

The Q Capture program received an error from the database log read interface. The reason code is a DB2 for z/OS reason code or on Linux, UNIX, or Windows a SQLCODE. The error indicates that the data on a log record cannot be processed because the compression dictionary for the corresponding DB2 table or table space is permanently gone. The compressed table or table space that contains this source table was probably reorganized by the REORG utility that ran without the KEEPDICTIONARY option. The Q Capture program cannot read the remaining compressed log records from source changes that occurred before the reorganization, and so it deactivated the Q subscription. Q Capture then activates the Q subscription and prompts a new load of the target table if a load is specified.

If the Q subscription specifies an automatic load of the target table, no action is required. If the Q subscription specifies a manual load, you must take actions to reload the target and issue a LOADDONE signal to Q Capture. Q Apply will spill changes to the spill queue until it sees the LOADDONE message from Q Capture. If the Q subscription specifies no load, you must take actions to reload the target and reactivate the Q subscription.

ASN7181E

The Q Capture program received an error from the database log read. The error indicates that the data on a log record cannot be processed because the compression dictionary for the corresponding DB2 table or table space is temporarily unavailable. For z/OS, the reason code is a z/OS diagnostic code. For Linux, UNIX, and Windows, the reason code is an SQL code. One cause for the problem could be that the compressed table space is in the STOPPED state when the database log Read Interface attempts to read the compression dictionary. DB2 takes a latch on the source compressed table space to access the dictionary and the latch does not work if the table space is stopped. This error prompts the Q Capture program to deactivate the Q subscription for the source table.

The problem will be resolved when the compression dictionary becomes available. Restart the Q Capture program.

ASN7182W

When a send queue is inactive either because it was stopped by a stopq command or because of an error, the Q Capture program cannot process signals for Q subscriptions that use the queue until the queue is started.

Use the startq command to resume replication or publishing on the queue and then reinsert the signal or repeat the action that resulted in the signal insert.

ASN7183I

The source partitioned table was altered to add a partition. The Q Capture or Capture program does not replicate this alteration, and so the new partition is not automatically added to the target table. Subsequent inserts, updates, and deletes to this newly added partition are captured. If the target is an identically partitioned table and the new source partition does not exist at the target, errors occur when the Q Apply or Apply program tries to apply rows to the target.

If you require the new partition at the target you must manually add it.

ASN7184W

The source partitioned table was altered to attach a partition. The Q Capture or Capture program does not support replication of this alteration, and so the new partition is not automatically attached at the target and the existing data in the new partition is not replicated to the target. Subsequent inserts, updates, and deletes to this newly attached partition are replicated.

If you require the new partition at the target you must manually add it. If you require the attached data at the target, you must manually load it into the target.

ASN7185W

The source partitioned table was altered to detach a partition. The Q Capture or Capture program does not support replication of this alteration, and so the detached partition is not detached at the target and the DELETE operations are not replicated to the target.

If you no longer want the partition or its data at the target, detach the partition or delete the data.

ASN7186W

The Q Capture program detected data changes at the source table by one of the following utilities:

DB2 for z/OS

• LOAD SHRLEVEL NONE RESUME YES
• LOAD SHRLEVEL NONE REPLACE
• REORG TABLESPACE DISCARD
• CHECK DATA DELETE YES LOG NO
• RECOVER PIT
• EXCHANGE DATA ON CLONE TABLESPACE

DB2 for Linux, UNIX, and Windows

DB2 LOAD

For the following DB2 utilities, Q Capture acts based on the CAPTURE_LOAD value:

• LOAD SHRLEVEL NONE RESUME YES
• LOAD SHRLEVEL NONE REPLACE
• REORG TABLESPACE DISCARD
• CHECK DATA DELETE YES LOG NO
• RECOVER PIT
• EXCHANGE DATA ON CLONE TABLESPACE
• DB2 LOAD (Linux, UNIX, Windows)

The CAPTURE_LOAD option supports the following actions when a data change operation is detected:

R (restart)

The Q subscription is restarted and the target table is loaded with the data from the source table. The type of load is determined by the LOAD_TYPE value in the IBMQREP_TARGETS control table.

W (warning)

The Q subscription is not restarted, and this warning message is issued.

If CAPTURE_LOAD is set to W or the DB2 utility is not supported by CAPTURE_LOAD, take action to ensure that the source and target tables are synchronized.

ASN7187E

CAPTURE_LOAD is set to R but the Q subscription type is peer-to-peer with more than two servers. The R value is only supported for unidirectional, bidirectional, and peer-to-peer replication with two servers.

Change the value of CAPTURE_LOAD to W for all Q subscriptions that participate in the peer-to-peer group. Because the source table was loaded, the source and target tables are not synchronized. Take the following actions:

1. Manually synchronize the tables by using the asntdiff and asntrep utilities.
2. Set CAPTURE_LOAD to W.
3. Start Q Capture in warm mode. Q Capture issues a warning message when it detects the source table load operation in the log.

ASN7188W

If the Q Capture program detects a load operation and the CAPTURE_LOAD value is set to R, Q Capture restarts the Q subscription. During the restart process the Q Apply program uses the HAS_LOADPHASE value to determine the type of load to use. If the HAS_LOADPHASE value is set to N the Q Apply program does not load the source table. The source and target tables become out of synch because the target table is not loaded with the latest data from the source table. If the source and target tables become out of synch, you must synchronize the tables.

In the IBMQREP SUBS control table, review the settings for the CAPTURE_LOAD option and the HAS_LOADPHASE option for the affected Q subscription.

ASN7189I

The Q Capture program detected a utility operation that changed data in the source table and the CAPTURE_LOAD option is set to R. The Q subscription was restarted. The restart prompts a new load of the target table, which includes, if applicable, any newly loaded data.

This message is for your information only. No action is required.

ASN7190W

The CAPTURE_LOAD option of R is only valid with a compatibility level of 0907 or higher, which requires both the Q Capture and Q Apply program to be at Version 9.7 or higher. When CAPTURE_LOAD is set to R for Version 9.7 and higher, load operations at the source table are replicated by using the load type that was chosen for the Q subscription.

To enable the replicate load feature, upgrade the Q Apply program to Version 9.7 or higher and set the COMPATIBILITY value in the IBMQREP_CAPPARMS table to 0907 or higher.

ASN7191E

The Q Capture program tried to perform a cold or warm start and the source database was not configured correctly for the Q Capture program to work with the Oracle LogMiner utility. The LOG_MODE column in the V$DATABASE dynamic view must be set to ARCHIVELOG.

Change the configuration of the database to enable ARCHIVELOG mode. For more information on enabling archival logging, see the "Managing Archived Redo Logs" chapter in the Oracle Database Administrator's Guide.

ASN7192E

The Q Capture program tried to perform a cold or warm start and the source database was not configured correctly for the Q Capture program to work with the Oracle LogMiner utility. The SUPPLEMENTAL_LOG_DATA_MIN column in the V$DATABASE dynamic view must be set to YES or IMPLICIT.

Enable minimal supplemental logging for the database. For more information, see "Supplemental Logging" in the Oracle Database Utilities guide.

ASN7193I

ASN7194W

When the Q Capture program starts the first Q subscription for a table, it gathers table information from the system catalogs. If a partition was attached to a table before Q Capture starts the first Q subscription for the table, the system catalog information might not correctly reflect where Q Capture is in the log. For a newly attached partition, Q Capture might incorrectly capture rows from the table before it was attached as a partition

Stop and then start the Q subscription.

ASN7195W

When the Q Capture program starts the first Q subscription for a table, it gathers table information from the system catalogs. If a partition was detached from the table before Q Capture starts the first Q subscription for a table, the system catalog information might not correctly reflect where Q Capture is in the log. For a newly detached partition, Q Capture might incorrectly miss rows from the partition before it was detached.

Stop and then start the Q subscription.

ASN7198E

Batching of transactions can only be used when large object (LOB) data is sent within a single transaction message. If the trans_batch_sz parameter is set to greater than 1, the lob_send_options parameter must be set to I (inline) rather than S (separate).

Set the lob_send_option parameter to I and restart the Q Capture program.

ASN7199E

The $AUTHTOKEN and $PLANNAME variables cannot be used for change conditions on Linux, UNIX, and Windows. These variables are only available in the database log record on z/OS operating systems. On Linux, UNIX, and Windows, you can use the $OPERATION and $AUTHID variables.

Ensure that the search condition and change condition are in the proper format and restart the publication or Q subscription.

ASN7200E

The SEARCH_CONDITION column must only contain source table column names or constants. Specify log record variables in the CHANGE_CONDITION column.

Ensure that the search condition and change condition are in the proper format and restart the publication or Q subscription.

ASN7201E

The restart message cannot be processed by this version of Q Capture, possibly because Q Capture was recently upgraded.

Start Q Capture using the asnqcap command, prompting the program to read from the beginning of the log by specifying the parameter "migrate=y". Use this option only the first time that you start Q Capture and specify startmode=warmns.

ASN7202E

The Q Capture program was started with the override_restartq parameter set to Y (yes). This setting prompts Q Capture to look in the restart file instead of the restart queue for restart information. However, Q Capture was unable to open the restart file. The file might have been inadvertently deleted, or the user ID that is associated with the Q Capture process does not have sufficient authority to open the file.

Verify that the user ID that is associated with the Q Capture process has sufficient authority. If the file was inadvertently deleted, create a new restart file and restart Q Capture. Q Capture writes the restart information to standard output (stdout) after it starts reading the log and after its last WebSphere MQ commit before terminating (Q Capture also writes the restart information to the restart data set or file at this time). Copy the restart information from the standard output or job log into the restart message.

ASN7203E

The Q Capture program was started with the override_restartq parameter set to Y (yes). This setting prompts Q Capture to get its restart information from a file instead of the restart queue, and enables you to specify individual restart points for one or more send queues. However, Q Capture was unable to find a queue that is used by any active Q subscriptions in the restart file.

In the restart file, specify a queue that is used by an active Q subscription and restart Q Capture.

ASN7205E

The Q Capture program can be started with global restart information by using the lsn and maxcmtseq parameters together during a warm start. Or, Q Capture can be started from different restart points for each send queue by using the override_restartq=y parameter. You cannot specify both lsn/maxcmtseq and override_restartq.

Start Q Capture with global warm start information (lsn and maxcmtseq) or start Q Capture with warm start information from the restart file (override_restartq).

ASN7206E

The Q Capture program writes restart information for each send queue to a file with the data set name or file name capture_path/qrestart, where capture_path is the value of the capture_path parameter. Either the user ID that started the Q Capture program does not have access authority for the file, or the file is too small.

Ensure that the user ID that started the Q Capture program has correct access and security permissions for the file. Also, ensure that sufficient space has been allocated for the file.

ASN7207I

The Q Capture program records restart information in a data set or file in addition to the restart message. Q Capture starts reading the log from the restart log sequence number (the lowest LSN of a transaction still to be committed) and ignores any transactions whose commit is before the maximum commit sequence number (the highest LSN of a successful transaction). In a partitioned database, these log indicators come from the partition where the Q Capture program is running.

This message is for your information only. No action is required.

ASN7208I

The Q Capture program detected that a column that is part of a Q subscription was altered. A message is automatically sent to the Q Apply program to make a matching alteration of the column at the target.

This message is for your information only. No action is required.

ASN7209I

The Q Capture program detected that a column was added to a subscribed table, and the value of the repl_addcol parameter is Y (yes). The parameter specifies that newly added columns should automatically be added to the Q subscription for the table, and so the column was added. The column will be added to the target table if it does not already exist.

This message is for your information only. No action is required.

ASN7210I

The schema-level subscription specifies that the replication programs should automatically create Q subscriptions for all tables with the specified table owner. The table-level Q subscription was successfully created.

This message is for your information only. No action is required.

ASN7211E

A schema-level Q subscription exists that specifies that the replication programs should automatically create Q subscriptions for all tables with the same table owner. The Q Capture program tried to create a Q subscription for the specified table, but a Q subscription for the table already exists. If the Q subscription were inactive, a new Q subscription would have been created that overwrote the existing Q subscription.

Follow these steps:

1. Use the replication administration tools to delete the existing Q subscription or set its state to inactive (I) so that it can be overwritten.
2. Start the Q Capture program.

ASN7212E

The Q Capture program had previously received a CAPSTOP signal for this Q subscription and was in the process of stopping it.

After the Q subscription state changes to I (inactive), use the replication administration tools or insert a CAPSTART signal to start the Q subscription again.

ASN7213I

A stop command was issued with the captureupto option that specifies that Q Capture stop after publishing database transactions that are committed up to and including the provided timestamp. The timestamp is treated as being in the database time zone.

This message is for your information only. No action is required.

ASN7214I

You can specify when a Q Capture program stops by using the parameter named captureupto. You can cause a Q Capture program to stop after the program publishes all of the database transactions that are committed up to and including a certain timestamp by specifying that timestamp with the captureupto parameter. This message is returned when the Q Capture program was stopped, and the parameter named captureupto was specified. The timestamp is treated as being in the database time zone.

The stopafter option was also specified in the stop command. The program will wait to stop until one of the following conditions is met, depending on which condition was specified:

• The transmission queue is empty (or Q Apply has consumed all messages if the queue is local).
• All changes up to the stopping point are applied at the target.

This message is for your information only. No action is required.

ASN7215I

A stopq command was issued with the captureupto option that specified that Q Capture stop publishing changes to the given queue after publishing database transactions that are committed up to and including the specified timestamp. The timestamp is treated as being in the database time zone.

This message is for your information only. No action is required.

ASN7216I

A stopq command was issued with the captureupto option that specified that Q Capture stop publishing changes to the given queue after publishing database transactions that are committed up to and including the specified timestamp. The timestamp is treated as being in the database time zone.

The stopafter option was also specified in the stopq command. The program will wait to stop until one of the following conditions is met, depending on which condition was specified:

• The transmission queue is empty (or Q Apply has consumed all messages if the queue is local).
• All changes up to the stopping point are applied at the target.

This message is for your information only. No action is required.

ASN7217I

A stop command was issued with the captureupto option eol (end of log), which specifies that Q Capture stop after publishing database transactions up to the end of the active database log.

This message is for your information only. No action is required.

ASN7218I

A stop command was issued with the captureupto option eol (end of log), which specifies that Q Capture stop after publishing database transactions up to the end of the active database log.

The stopafter option was also specified in the stop command. The program will wait to stop until one of the following conditions is met, depending on which condition was specified:

• The transmission queue is empty (or Q Apply has consumed all messages if the queue is local).
• All changes up to the stopping point are applied at the target.

This message is for your information only. No action is required.

ASN7219I

A stopq command was issued with the captureupto option eol (end of log), which specifies that Q Capture stop publishing database transactions to the given queue after it reaches the end of the active database log.

This message is for your information only. No action is required.

ASN7220I

A stopq command was issued with the captureupto option eol (end of log), which specifies that Q Capture stop publishing database transactions to the given queue after it reaches the end of the active database log.

The stopafter option was also specified in the stopq command. After the queue is deactivated, the program will monitor and issue a message when one of the following conditions is met:

• The transmission queue is empty (or Q Apply has consumed all messages if the queue is local).
• All changes up to the stopping point are applied at the target.

This message is for your information only. No action is required.

ASN7221E

A stop or stopq command contains a captureupto parameter with an invalid timestamp. The timestamp must be specified in the time zone of the Q Capture server, in a full or partial timestamp format. The full timestamp uses the following format: YYYY-MM-DD-HH.MM.SS.mmmmmm

For examples of acceptable formats for partial timestamps, see, "Stopping the Q Capture program at a specified point."

As an alternative, you can specify the keyword CURRENT_TIMESTAMP, and the Q Capture program substitutes the current time, causing it to publish transactions that are committed up to that current time.

Correct the timestamp format and reissue the command or signal.

ASN7222I

A stop or stopq command was specified with stopafter=data_sent. Q Capture will monitor the given send queue until all messages have been delivered to the receive queue (that is, until the queue depth becomes 0). For a stop command, Q Capture will terminate after all active queues are empty. For a stopq command, Q Capture will issue a message once the queue is empty. If Q Capture and Q Apply share a local queue, Q Capture will wait until Q Apply has removed all messages from the queue. In configurations where multiple remote queues share a transmission queue, Q Capture might wait longer than expected because of non-Q Capture messages being sent on the transmission queue.

This message is for your information only. No action is required.

ASN7223I

A stop or stopq command was specified with option stopafter=data_applied. Q Apply will notify Q Capture when all messages are applied for the given queue. For a stop command, Q Capture will stop after Q Apply sends a response for all active queues. For a stopq command, Q Capture will issue a message when it is notified by Q Apply. If Q Apply is not running, Q Capture will wait indefinitely.

This message is for your information only. No action is required.

ASN7224I

A stop or stopq command was issued for Q Capture with option stopafter=data_applied. Q Capture requested that Q Apply send a notification when Q Apply has applied all transactions up to the time that the command was issued. Q Apply has notified Q Capture, but continues to process the receive queue.

This message is for your information only. No action is required.

ASN7225I

A stop or stopq command was issued for Q Capture with option stopafter=data_sent. Q Capture detected that all messages have been delivered to the remote receive queue (or consumed by Q Apply if it shares a local queue with Q Capture), and that the queue depth is now 0.

This message is for your information only. No action is required.

ASN7226E

The Q Capture program was started with the override_restartq parameter set to Y (yes). This setting prompts Q Capture to look in the restart file instead of the restart queue for restart information. However, Q Capture was unable to read the restart file.

Verify that the user ID that started Q Capture has read authority on the restart file, which has the data set name or file name capture_path/qrestart, where capture_path is the value of the capture_path parameter.

ASN7227I

A stop or stopq command was specified with option stopafter=data_applied. Q Capture detected that all transactions that were published to the given send queue were applied to the target.

This message is for your information only. No action is required.

ASN7228E

Q Capture could not reliably determine when all messages have been delivered to the remote receive queue, or drained from the local queue if Q Capture and Q Apply are sharing a local queue. Q Capture no longer monitors the queue depth. The following values are valid for the reason code:

1

The transmission queue name could not be derived from the remote queue definition.

2

The transmission queue appears to be shared between Q Capture and another application.

Review the reason codes in the explanation, and take the appropriate action:

1

Check that the remote queue definition contains a valid transmission queue name.

2

Q Capture cannot wait for messages to drain when other applications are sharing the transmission queue. Use a dedicated transmission queue for the send queue to avoid this problem.

ASN7229E

Q Capture could not determine when all transactions that were published to the given send queue were applied at the target. Q Capture is no longer waiting for the transactions to be applied. The following values are valid for the reason code:

1

Q Apply is not currently processing the associated receive queue.

2

One of the following conditions exists:

• Q Apply does not appear to be running, is not processing any receive queues that are receiving messages from this Q Capture, or the response message is not arriving on the Q Capture administration queue.
• A response was not received in a reasonable amount of time.

Review the reason codes in the explanation, and take the appropriate action:

1

Issue a startq command for the corresponding receive queue at the target to allow the transactions to be applied.

2

Check that Q Apply is running, all relevant receive queues are active, and there is connectivity for messages on the administration queue.

ASN7230I

A stop command or signal was issued with captureupto criteria, stopafter criteria, or both that caused Q Capture to wait for a certain condition to become true before stopping.

This message is for your information only. No action is required.

ASN7232E

The program tried to load the Q subscription into memory, but the send queue name that was specified for the Q subscription could not be found in the IBMQREP_SENDQUEUES table. The error might have occurred because the Q subscription was updated with SQL other than that generated by the Replication Center or ASNCLP program, or the SQL generated by these tools was modified.

Use one of the administration tools to drop and recreate the Q subscription.

ASN7236W

After a CREATE TABLE operation for a table with a matching schema-level subscription is detected, the Q Capture program automatically creates the Q subscription entry for this table in the IBMQREP_SUBS and IBMQREP_SRC_COLS control tables. If the Q subscription entry already exists in one or both of these control tables, Q Capture deletes the prior Q subscription entry and creates the new entry.

You might want to determine why the Q subscription entry for the same source table already existed in this control table. If Q Capture was restarted from a prior point in the log, it might have encountered a log record for the same CREATE TABLE operation.

ASN7237W

After a CREATE TABLE operation for a table with a matching schema-level Q subscription is detected, the Q Capture program automatically creates the Q subscription entry for this table in the IBMQREP_SUBS control table. If the insertion of the Q subscription entry fails, the Q subscription is not created and replication does not start for the source table.

If you want to replicate this source table, use the replication administration tools to create a Q subscription for the table. Make sure that the target table exists or let the replication tools create the target table. Check the SQL code or internal reason code to determine why the insert into IBMQREP_SUBS failed.

ASN7238W

After a CREATE TABLE operation for a table with a matching schema-level Q subscription is detected, the Q Capture program automatically adds Q subscription information about the columns in the source table to the IBMQREP_SRC_COLS control table. However, the insertion of this information into the control table failed. The Q subscription will be deactivated in the IBMQREP_SUBS table.

Follow these steps:

1. Check the SQL code or internal reason code to determine why the insertion into IBMQREP_SRC_COLS failed.
2. Use the replication administration tools to delete and recreate the Q subscription for the table. Make sure that the target table exists or let the replication tools create the target table.

ASN7240E

You cannot specify autostop=Y when the value of the term parameter is N (No). You also cannot specify term=N when the saved value of autostop in the IBMQREP_CAPPARMS table is Y.

Restart the Q Capture program while specifying either the autostop parameter or the term=N parameter. Update the value of autostop in the IBMQREP_CAPPARMS table if necessary.

ASN7241E

You can use the percentage sign (%) as a wild card to specify schema-level Q subscriptions and the Q Capture program automatically creates a Q subscription for all tables within the schemas that match the wild card expression. However, you cannot specify the wild card before a schema name, for example "%AN" or "%AN%".

Follow these steps:

1. Change the expression in the schema name in the IBMQREP_SCHEMASUBS table to an allowed wild card expression.
2. Start the Q Capture program.
3. Insert a START_SCHEMASUB signal in the IBMQREP_SIGNAL table.

ASN7242E

You can use the percentage sign (%) as a wild card to specify schema-level Q subscriptions and the Q Capture program automatically creates a Q subscription for all tables within the schemas that match the wild card expression. However, you cannot specify the wild card before an object name, for example "%AN" or "%AN%".

Follow these steps:

1. Change the expression in the object name in the IBMQREP_SCHEMASUBS table to an allowed wild card expression.
2. Start the Q Capture program.
3. Insert a START_SCHEMASUB signal in the IBMQREP_SIGNAL table.

ASN7243E

Overlapping expressions in the schema name are not allowed. For example, expressions such as "ANU%" and "AN%" cannot be used at the same time.

Follow these steps:

1. Change the expression in the schema name or object name in the IBMQREP_SCHEMASUBS table.
2. Start the Q Capture program.
3. Insert a START_SCHEMASUB signal in the IBMQREP_SIGNAL table.

ASN7244E

You can use an expression to exclude objects like tables from schema-level Q subscriptions. The expressions are stored in the IBMQREP_EXCLSCHEMA table. However, you cannot use expressions in the SCHEMA_NAME column of the IBMQREP_EXCLSCHEMA table.

Remove the expression in the SCHEMA_NAME column of the IBMQREP_EXCLSCHEMA table and start the Q Capture program.

ASN7247I

As a result of processing the log record that corresponds to a REINIT_SCHEMASUBS signal, the Q Capture program successfully loaded the schema-level subscription that is defined in the IBMQREP_SCHEMASUBS table and the corresponding profile that is defined in the IBMQREP_SUBS_PROF table.

This message is for your information only. No action is required.

ASN7248W

Q Capture program found an unsubscribed table for the schema-level subscription that is defined in the IBMQREP_SCHEMASUBS table. This situation is unexpected because the replication administration tools create Q subscriptions for all existing tables within a schema when a schema-level Q subscription is created. However, this situation can occur if new tables are created between the time that the table-level Q subscriptions are created and the schema-level subscription is loaded. For example, a user could generate the script to create Q subscriptions for all existing tables, but wait days before running this script, during which time new tables are created.

Use the replication administration tools to create a Q subscription for this table if desired.

ASN7249E

You can use the percentage sign (%) as a wild card in the OBJECT_NAME column of the IBMQREP_EXCLSCHEMA table to specify the names of objects such as tables that should be excluded from a schema-level subscription. Use a single % to specify that all objects for the given schema be excluded. However, you cannot specify the wild card before an object name, for example "%AN" or "%AN%".

Change the expression in the OBJECT_NAME column of the IBMQREP_EXCLSCHEMA table and start the Q Capture program.

ASN7250E

After a CREATE TABLE operation is detected for a table with a matching schema-level Q subscription, the Q Capture program informs the Q Apply program so that it can automatically create and activate a table-level Q subscription. If the Q subscription activation fails, the Q subscription will be deactivated and future changes will be ignored for this source table.

Use the replication administration tools to create a new Q subscription for the table or to activate the existing Q subscription. Make sure that the source and target tables exist or let the replication tools create the target table. Also, verify that the table will be loaded either by the Q Replication programs or externally.

ASN7251I

In response to a STOP_SCHEMASUB signal that was inserted into the IBMQREP_SIGNAL table, the Q Capture program deactivated the schema-level Q subscription.

This message is for your information only. No action is required.

ASN7252I

In response to a REINIT_SCHEMASUB signal that was inserted into the IBMQREP_SIGNAL table, the Q Capture program reinitialized the schema-level Q subscription.

This message is for your information only. No action is required.

ASN7253E

The Q Capture program can replicate some DDL operations at source tables. However, replication of the ALTER TABLE ALTER COLUMN SET DATA TYPE operation is not supported if the value of the Q Capture compatibility parameter is 0907 or lower.

Use the replication administration tools to update the value of the compatibility parameter to 1001 or newer and start the Q subscriptions.

ASN7254W

At least one schema-level subscription is active, but the database is not currently logging DDL statements. To replicate CREATE TABLE and other DDL statements, the database configuration must be updated so that database logs these statements.

Update the database configuration parameter LOG_DDL_STMTS to YES. The change is reflected in the database immediately.

ASN7255E

A utility operation was detected in the log while the Q subscription was still in loading state. The Q subscription was set up to replicate source table loads (CAPTURE_LOAD R). Invoking a utility while the Q subscription is in loading state disrupts the load protocol and might lead to SQL errors while changes are being applied from the spill queue to target tables.

Wait for the Q subscription to stop and become inactive. Then start the Q subscription. If CAPTURE_LOAD is set to R, always wait for the Q subscription to become active before invoking a utility that triggers a reload of the target table.

ASN7256W

The signal that was received cannot be processed because the resulting message that would be sent to Q Apply is restricted by the current compatibility level.

If Q Apply is at the same level as Q Capture, set the Q Capture compatibility level to match the Q Capture version that is installed and reissue the signal.

ASN7257W

The current compatibility level prevents sending of messages to Q Apply that are required to automatically create Q subscriptions and replicate DDL operations. Replication of DDL operations requires a compatibility level of 1001 or higher.

If Q Apply is at the same level as Q Capture, set the compatibility level in Q Capture to match the Q Capture version that is installed.

ASN7262W

The value of heartbeat_interval specifies the number of seconds between heartbeat messages. The value must be a positive integer. A value of 0 specifies that heartbeat messages are not sent.

If you want the Q Capture program to send heartbeat messages, specify a positive integer for the heartbeat_interval parameter of the replication queue map and then use the reinitq command to prompt Q Capture to begin using the new value. Otherwise, no action is required.

ASN7263W

The Q Capture program detected an ALTER TABLE RENAME COLUMN operation for the source table. At compatibility 1001 and below, the replication programs do not automatically replicate the renaming of a column that is part of a Q subscription. At compatibililty 1021 and above, the replication programs automatically update the Q subscription properties with the new column name and in some cases rename the corresponding column in the target table.

1. Update the TARGET_COLNAME and SOURCE_COLNAME columns in the IBMQREP_TRG_COLS table to reflect the changed name of the source table column.
2. Start the Q subscription if it was stopped, or start the receive queue if the browser thread stopped reading from the queue.

ASN7264I

In response to an ADD_REPL_KEY_COL signal, the column was added to the replication key that is used for the Q subscription.

This message is for your information. No action is required.

ASN7265W

An ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal was issued to the Q Capture program to modify the replication key for the Q subscription, but the column is not part of the Q subscription. To be part of the replication key, the column must be part of the Q subscription.

Use the ADDCOL signal first to add the column to the Q subscription and then issue the ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal.

ASN7266W

An ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal was issued to the Q Capture program to modify the replication key for the Q subscription. However, no such column exists in the source table.

1. Add the column to the source table.
2. Use an ADDCOL signal to add the column to the Q subscription.
3. Reissue the ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal to add the column to the replication key for the Q subscription.

ASN7267I

The Q Capture program detected that a column was dropped from a subscribed table. The column was removed from the Q subscription or publication and dropped from the target table.

This message is for your information. No action is required.

ASN7268E

The LSN or MAXCMTSEQ value must be specified as a hexadecimal number in the format xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx or as a timestamp in the format yyyy-mm-dd-hh.mm.ss.nnnnn. The timestamp format is only supported if Q Capture is running in a DB2 for z/OS data-sharing environment.

Restart the Q Capture program, specifying a correct value for the LSN or MAXCMTSEQ parameter.

ASN7269W

An ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal was issued to the Q Capture program to modify the replication key for the Q subscription, but the feature is not supported for peer-to-peer replication.

Use the ADD_REPL_KEY_COL or or REDEFINE_REPL_KEY signal only for unidirectional or bidirectional replication.

ASN7270W

An ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal was issued to the Q Capture program to modify the replication key for the Q subscription, but the target of the Q subscription is a stored procedure.

A stored procedure definition must change if the replication key changes. Follow these steps:

1. Drop the existing Q subscription.
2. Redefine the stored procedure on the target.
3. Recreate the Q subscription with the new replication key.

ASN7271W

An ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal was issued to the Q Capture program to modify the replication key for the Q subscription, but the column type is not eligible to be part of a replication key.

Select a column with a supported data type to be part of the replication key.

ASN7275E

In Q Replication and CDC Replication, the current structure of source tables is made known to the target datastore by running the asndesc command to describe the source tables. The specified mapping was newly defined or changed, and so it must be described so that the target table mapping can be completed or updated.

Run the asndesc utility, specifying the mapping group. All mappings that require a describe are processed.

ASN7276W

The send queue or mapping group for which the start command or signal was issued is already active.

This message is for your information only. No action is required.

ASN7277W

All Q subscription and mapping signals are ignored if the corresponding send queue or mapping group is inactive. The signals are left in pending mode, and will be read again and processed after the send queue or mapping group is restarted.

This message is for your information only. No action is required.

ASN7278E

When Q Capture initially starts, either through start or reinit, it determines if any send queues are defined. If they are not Q Capture does not do any of the initialization required to run them (for example, it does not connect to a queue manager). If a send queue is added later, you must either stop and start Q Capture or run reinit to load the send queue and do the necessary initialization.

Stop and start capture or issue a reinit command, then issue the failing command again.

ASN7279E

When Q Capture starts or is reinitialized, it determines whether any mapping groups are defined, and if they are not, does not do any of the initialization that is required to run them (for example, it does not start the communications library). If a mapping group is added later, you must either stop and start Q Capture or reinitialize Q Capture to load the mapping group and do the necessary initialization.

Stop and start Q Capture or issue a reinit command, then reissue the command to start the mapping group.

ASN7280I

While all mapping groups are inactive, the Q Capture program continues reading the log for signals such as CAPSTART, continues inserting into its monitor tables, and waits for commands.

This message is for your information only. No action is required.

ASN7281E

The target datastore requested an immediate shutdown and the mapping group followed the error action that is specified in the IBMQREP_SENDQUEUES table. The following values are valid for the reason code:

1

An error occurred on the target.

2

A user requested the stopping of the mapping group.

Review the reason codes in the explanation, and take the appropriate action:

1

Investigate the reason for the error by using the log and trace files from the CDC engine instance.

2

Determine the reason for the manual intervention.

If the mapping group was stopped it can be started using the STARTQ command or STARTQ signal.

ASN7282W

The target for the mapping does not support dynamically adding a column to the mapping. The column data is not replicated.

To add the column to replication, add the column to the target table (if needed) and re-map the table.

ASN7283E

The target for the mapping does not support dynamically altering a subscribed column of a mapping.

Change the target table structure and re-map the table to continue replication for this mapping group.

ASN7284E

A source table can only be used in one mapping in the same mapping group, and a table was found to be used in at least two mappings.

Remove or change one or more of the mappings that are defined in the control tables and run the command again.

ASN7285E

A signal could not be processed because the Q subscription or mapping failed to load from either memory or the IBMQREP_SUBS control table. The most common error is to try to load a Q subscription when send queues are not enabled or to load a mapping when mapping groups are not enabled.

Resolve the underlying error and issue the signal again.

ASN7287E

The CCSID that is used for the column is not known to the target. The target instance is not able to translate the data. Q Capture is not able to replicate data from the columns in this table by using the CCSID.

Reconfigure the mapping for this table to exclude columns that use the specified CCSID.

ASN7294I

The Q Capture program detected that a subscribed column was renamed and automatically renamed the column in the Q subscription metadata. If the original column name matched the name in the target table, the Q Apply program automatically renamed the target column to match the new source column name. If the original column names did not match, Q Apply follows the error action that is specified for the Q subscription and you must manually rename the target column.

If the original column names did not match, rename the corresponding target table column and then either start the receive queue, the Q subscription, or Q Apply, depending on the error action for the Q subscription.

ASN7295W

Q Capture found a syntax error while trying to process the change condition or search condition for in-memory evaluation. Either the predicate has a syntax error, or the predicate is too complex for Q Capture to evaluate. In the latter case Q Capture will try to have the database evaluate the predicate.

Take one of the following actions:

• If the predicate cannot be validated by the database, Q Capture stops or the send queue stops, depending on the error action for the Q subscription. In either of those cases, update the Q subscription with correct syntax for the change condition or search condition and restart Q Capture or the send queue.
• If the function that is required is not supported by in-memory evaluation, but is a valid SQL statement, you can instruct Q Capture to always evaluate through the database by prepending @DB to the beginning of the predicate.

ASN7296I

Q Capture is unable to evaluate the predicate in memory, so the database will evaluate the predicate. Alternatively, the predicate was specified with @DB at the start of the predicate. You might experience a small performance impact.

This message is for your information only. No action is required.

ASN7297I

The Q Capture program uses an in-memory interpreter to process SQL statements wherever possible. When the data type of a variable in a search condition cannot be handled by the in-memory interpreter, then the search condition is passed to the SQL interpreter of the database engine to be processed.

This message is returned when a search condition cannot be evaluated by the Q Capture in-memory interpreter, and as a result the search condition will be evaluated by the database engine SQL interpreter.

No response is required. This message is for your information only.

ASN7298W

The Q Capture program normally reads the database recovery log for data to replicate, but when a source table contains large object (LOB) or XML data Q Capture reads the source table directly. Q Capture tried to perform a SELECT operation on a source table that contains one or more LOB or XML columns but the user ID that runs Q Capture does not have SELECT privilege on the table.

Grant the ID that starts the Q Capture program SELECT privilege on the source table, then start the Q subscription or receive queue.

ASN7299E

The Q Capture program tried to load a peer-to-peer Q subscription and found that the versioning columns were not in the IBMQREP_SRC_COLS table. For peer-to-peer replication, these two columns must be part of the Q subscription. This message is issued when Q Capture starts in warm mode or when the first CAPSTART signal is received for a peer-to-peer Q subscription.

1. Drop and recreate the peer-to-peer Q subscription, making sure to include the IBMQREPVERNODE and IBMQREPVERTIME columns.
2. Start the Q subscription.

ASN7302E

The CODEPAGE_OVERRIDE column in the IBMQREP_SRC_COLS table must contain a valid CCSID value ranging from 0 - 65535. For a newly activated Q subscription, the Q subscription deactivates. For an existing Q subscription, the Q Capture program either stops publishing to the send queue or stops, depending on the error action that is specified for the send queue.

1. Correct the CODEPAGE_OVERRIDE value for the column.
2. Restart the Q subscription, the Q Capture program, or the send queue.

ASN7303I

A command was received to change the state of a send queue. However the state of the send queue already reflects the result of that command. For example, a startq command was received, but the send queue is already active. The command is ignored.

This message is for your information only. No response is required.

ASN7304W

The Q Capture program uses IBMQREP_SUBS_PROF to determine default values for automatically creating table-level Q subscriptions when tables are added to databases with schema-level subscriptions. The program could not find the specified subscription profile in the table.

• If the profile exists, verify that the name that is stored in the SUBPROFNAME column of the IBMQREP_SCHEMASUBS table is correct, and if not correct the name.
• If the profile does not exist, use the ASNCLP CREATE SUBSCRIPTION OPTIONS command to create a profile.

ASN7305W

A command was issued to perform an action on a schema-level subscription, but no subscription with the specified name could be found in the IBMQREP_SCHEMASUBS control table.

Ensure that the schema-level subscription name is accurate, and reissue the command.

ASN7306W

The Q Capture program detected that a Unicode column was added to an EBCDIC table. The Q Apply program will create the target column without specifying a CCSID clause if Q Capture is running with compatibility set to 1001.

This message is for your information only. No action is required.

ASN7307W

When a CREATE TABLE operation for a table with a matching schema-level Q subscription is detected, the table must have the DATA CAPTURE CHANGES attribute set. If the CREATE TABLE command explicitly specifies DATA CAPTURE NONE, it is treated as an indication that the user does not want this table replicated, and this takes precedence over any matching schema-level Q subscription.

If you want to replicate this table, follow these steps:

1. Alter the table with DATA CAPTURE CHANGES.
2. Use the replication administration tools to create a table-level Q subscription for the table.

ASN7308W

During program shutdown, the log reading thread did not terminate in the expected amount of time. This situation normally occurs when the thread is in an interruptible call while reading the log, and the call is taking longer than anticipated to complete.

If the log reading thread was blocked within a log read API call, the resources might continue to be held after the Q Capture or Capture program shuts down completely. On DB2 for z/OS, a CANCEL THREAD command might be required to release resources that are held by the log reading thread. On DB2 for Linux, UNIX, and Windows, a FORCE APPLICATION (agentid) command might be required to release these resources.

ASN7309E

The database log read interface returned a log record with compressed data, but the available compression dictionary for the table space was not the correct one. The table space that contains this source table was probably reorged without specifying KEEPDICTIONARY. If the value of LOGRD_ERROR_ACTION for the Q subscription is D or E, Q Capture deactivated the Q subscription. If the value was S, Q Capture stopped. Q Capture automatically activates the Q subscription and sends a schema message to Q Apply to activate the Q subscription and follow the load option that is specified in the HAS_LOADPHASE column of the IBMQREP_TARGETS table:

• I: Q Apply reloads the target table.
• E: You load the target.
• N: No load is done.

If the Q subscription specifies a manual load, reload the target table and signal the replication programs when the load is complete.

ASN7310E

The database log read interface returned a log record with compressed data, but the compression dictionary for the table space was not available. The table space that contains this source table might have been stopped when the database log read interface attempted to read the compression dictionary. DB2 takes a latch on the source table space to access the dictionary and the latch does not work if the table space is stopped. If the value of LOGRD_ERROR_ACTION for the Q subscription is E, Q Capture attempted to reread the log record and deactivated the Q subscription. If the value is D or S, Q Capture stopped. Q Capture automatically activates the Q subscription and sends a schema message to Q Apply to activate the Q subscription and follow the load option that is specified in the HAS_LOADPHASE column of the IBMQREP_TARGETS table:

• I: Q Apply reloads the target table.
• E: You load the target.
• N: No load is done.

If the Q subscription specifies a manual load, reload the target table and signal the replication programs when the load is complete.

ASN7311I

To ensure that the export of data from the source table includes a complete image, Q Capture waits until all in-flight transactions at the source database commit before it starts to capture changes for the source table.

This message is for your information only. No action is required.

ASN7312I

Q Capture detected that the SYSPROC.ADMIN_MOVE_TABLE stored procedure was used to move a subscribed table, and in response it updated the IBMQREP_TABVERSION and IBMQREP_COLVERSION control tables with the new table space and table IDs and also updated the Q subscription.

This message is for your information. No action is required.

ASN7313W

Q Capture detected that SYSPROC.ADMIN_MOVE_TABLE was used on a subscribed table. The IBMQREP_TABVERSION and IBMQREP_COLVERSION tables need to be updated with the new table space ID and table ID, but an SQL error was encountered while the program tried to delete the old rows from these tables. The Q subscription is still active, but might encounter problems if Q Capture is restarted or the Q subscription is reinitialized.

Either update or remove all of the rows for this table in IBMQREP_TABVERSION and IBMQREP_COLVERSION.

ASN7314W

Q Capture detected that SYSPROC.ADMIN_MOVE_TABLE was used on a subscribed table. The IBMQREP_TABVERSION and IBMQREP_COLVERSION tables need to be updated with the new table space ID and table ID, but an SQL error was encountered while the program tried to insert new rows into these tables. The Q subscription is still active, and the control table information will be correctly updated when Q Capture restarts or the Q subscription is reinitialized.

This message is for your information. No action is required, although the SQL error might indicate a problem with the database or control tables.

ASN7315W

Q Capture detected that SYSPROC.ADMIN_MOVE_TABLE was used on a subscribed table that is partitioned. The IBMQREP_PART_HIST table needs to be updated with the new table space ID and partition object ID, which are queried from the system catalogs. However, an SQL error was encountered while the program tried to update the table. The Q subscription is still active, but has not been updated with the new table space and table ID so it will fail to replicate DML changes.

Delete, recreate, and reactivate the Q subscription.

ASN7316W

The Q Capture mqthread_bufsz parameter specifies a temporary buffer in memory that is used for a dedicated MQ publishing thread. This buffer size must be at least as big as a single message that is put to the queue. The minimum value is 50 KB and the maximum is 100 MB.

If Q Capture publishes no message exceeding the mqthread_bufsz value, no action is required. If the value is too small, the program stops with ASN7317E and should be restarted

ASN7317E

The Q Capture mqthread_bufsz parameter specifies a temporary buffer in memory that is used for a dedicated MQ publishing thread. This buffer size must be at least as big as a single message that is put to the queue. The minimum value is 50 KB and the maximum is 100 MB. Q Capture tried to put a message that was larger than the mqthread_bufsz value into the buffer.

Increase the size of mqthread_bufsz and restart the program. Alternatively, avoid using the MQ publish thread by setting parallel_mqthread=n and restart the program.

ASN7319I

A CAPSTOP command was inserted into the IBMQREP_CAPCMD table but the specified Q subscription does not exist.

Check that the Q subscription name is correct and reissue the CAPSTOP command.

ASN7327W

IFI is the facility that is used to return log records to the Q Capture or Capture program. Multiple consecutive calls were made to IFI where IFI returned the same LRSN. In a proxy log read configuration, this warning message can indicate that IFI is being held back from merging all log records across members. The exact time period when no progress was being made can be seen in the NUM_LOGREAD_NO_PROG column of the IBMQREP_CAPMON table.

Look for message ASN7328I to indicate that Q Capture resumed reading the log normally. If you see this warning message, you might want to check for issues with the source DB2 group that are preventing new log records from being returned. Alternatively, one or more members on the source might have extremely light workload levels that are affecting IFI from merging log records across different members effectively. Q Capture keeps running while in this condition.

ASN7328I

After previously encountering an issue where IFI was returning the same LRSN continually to Q Capture or Capture, the programs have resumed reading the log correctly.

This message is for your information only. No response is required.

ASN7329I

Q Apply notified Q Capture of the value of its current_level parameter. The APPLY_LEVEL column in the IBMQREP_SENDQUEUES table was updated accordingly.

This message is for your information only. No action is required.

ASN7330I

The apply_level value in the IBMQREP_SENDQUEUES table is used to determine the message level for messages that are published on this queue. If the value is NULL, Q Capture deactivates the queue until the level of Q Apply is known.

Q Capture automatically processes any notification from Q Apply and starts the queue automatically. Q Apply must be running, or a receive queue must be restarted, to send a new notification to Q Capture.

ASN7331I

A stop command was issued with the logs_avail_after_disaster option of the captureupto parameter. This option specifies that when Q Capture is running in proxy mode the program stops after publishing database transactions up to the end of the active database log. Any log records that were not written to the log will be skipped.

This message is for your information only. No action is required.

ASN7332I

A stop command was issued with the logs_avail_after_disaster option of the captureupto parameter. This option specifies that when Q Capture is running in proxy mode the program stops after publishing database transactions up to the end of the active database log. Any log records that were not written to the log will be skipped.

This message is for your information only. No action is required.

ASN7333W

The Q Capture program processed the log record for a TRUNCATE on a replication source table. A warning is issued; the target table is not truncated. The source and target tables are no longer synchronized. Rows that were deleted from the source might still exist at the target.

If the target table needs to be synchronized with the source table, you might need to restart the Q subscription to reload the target table.

ASN7334W

The Q Capture program detected a TRUNCATE log record at the source side, but the Q Apply arch_level is lower than 1021, which does not support replication of TRUNCATE operations. Q Apply will load the target table according to the value of the HAS_LOADPHASE column in the IBMQREP_SUBS control table. If HAS_LOADPHASE=N, Q Apply will perform an internal load.

• If HAS_LOADPHASE=N or I, and the Q Apply log indicates a load failure, take action to ensure that the source and target tables are synchronized.
• If HAS_LOADPHASE=E, manually load the target table and send a LOADDONE signal to Q Capture when the load is done.

ASN7335I

The Q Capture program detected data changes at the source table by one of the following utilities:

Db2 for z/OS

• LOAD SHRLEVEL NONE RESUME YES
• LOAD SHRLEVEL NONE REPLACE
• REORG TABLESPACE DISCARD
• CHECK DATA DELETE YES LOG NO
• RECOVER PIT
• EXCHANGE DATA ON CLONE TABLESPACE

Db2 for Linux, UNIX, and Windows

Db2 LOAD

For the following Db2 utilities, Q Capture acts based on the CAPTURE_LOAD value:

• LOAD SHRLEVEL NONE RESUME YES
• LOAD SHRLEVEL NONE REPLACE
• REORG TABLESPACE DISCARD
• CHECK DATA DELETE YES LOG NO
• RECOVER PIT
• EXCHANGE DATA ON CLONE TABLESPACE
• Db2 LOAD (Linux, UNIX, Windows)

The CAPTURE_LOAD option supports the following actions when a data change operation is detected:

R (restart)

The Q subscription is restarted and the target table is loaded with the data from the source table. The type of load is determined by the LOAD_TYPE value in the IBMQREP_TARGETS control table.

W (warning)

The Q subscription is not restarted, and this warning message is issued.

If CAPTURE_LOAD is set to W or the Db2 utility is not supported by CAPTURE_LOAD, take action to ensure that the source and target tables are synchronized.

ASN7336E

The CDDS is required for Q Capture to operate in proxy mode. Without a valid CDDS, the proxy Db2 cannot guarantee that it correctly returned all log records to Q Capture, and the target tables must be reloaded after the CDDS is rebuilt or recovered (a full refresh is required).

ASN7337I

When you set the Q Capture parameter LOB_SEND_OPTION=I, all LOB values are sent within the transaction message. If a LOB value causes the size of the transaction message to exceed the maximum message limit, then all LOB column values in that row are sent in separate mode. The maximum message limit is set in the MAX_MESSAGE_SIZE parameter of the send queue.

If you see only a few ASN7337I messages, no response is needed because the performance effect is small. If you see many instances of this message, consider increasing the MAX_MESSAGE_SIZE value of the corresponding send queue.

ASN7338E

The CDDS is required for Q Capture to operate in proxy mode.

ASN7339E

Proxy Db2 returned a resource unavailable error when Q Capture called the Db2 log API (IFCID 306). The Q Capture program stops.

Check the DB2MSTR log or system console for any additional diagnostic information to identify the cause of the problem. Try to restart Q Capture after you have collected the necessary diagnostics and resolved any problems.

ASN7341W

The Q Capture REINIT command deactivates and reactivates all subscriptions without reloading them to pick up any changes to the subscription attributes in the Q Capture control tables. Q Capture also activates all subscriptions in N state.

During the load of a subscription, Q Apply spills row changes at the target into a spill queue and then applies them after the load is done. Changes to the subscription attributes can create incompatibilities between the spilled rows and the rows that are sent by Q Capture after the reinitialization. For this reason, reinitializing a subscription that has an external load phase is not allowed until you finish loading the table, Q Apply finishes processing the backlog of spilled changes, and the subscription is active.

For an internal load, Q Apply first completes the load and then clears up the spill queue before processing the REINIT command. Reinitializing a subscription while tables are being loaded automatically by Q Apply might have a detrimental performance impact. Q Apply does not process transactions until it has finished reinitializing all the subscriptions.

If changes are needed to a subscription in loading phase, issue a REINITSUB command after the load is done and the subscription is active.

ASN7350I

The replication key was modified in response to a REDEFINE_REPL_KEY signal.

This message is for your information only. No action is required.

ASN7352W

The REDEFINE_REPL_KEY signal is only supported when Q Apply and Q Capture are 1140 and function level 1140.103 and higher.

This is a warning message. Correct the Capture / Apply program and rerun

ASN7353E

The OCI encountered a potential truncate or null fetch when performing a fetch on V$LOGMNR_CONTENTS.

This condition generally has no negative effects on replication. If there is any cause for concern, restart Q Capture with STOP_ON_OCI_SUCCESS_WITH_INFO=Y.

ASN7358I

When the TRANS_BATCH_SZ parameter is set to n, Q Capture combines up to n captured Db2 transactions per MQ message. The MQ messages are propagated when Q Capture commits the MQ transaction, which is either when COMMIT_INTERVAL is reached or when MAX_TRANS transactions have been put into MQ messages. For example, with a MAX_TRANS value of 200 and a TRANS_BATCH_SZ value of 60, Q Capture does not write more than four MQ messages per MQ COMMIT_INTERVAL, possibly three messages with 60 database transactions each, and one message with 20 database transactions. A larger number of MQ messages per MQ transaction results generally in better performance, particularly when the distance between systems is large. For this reason, Q Capture automatically increases the value supplied for MAX_TRANS, by multiplying it by the TRANS_BATCH_SZ value.

When using the TRANS_BATCH_SZ parameter for achieving optimal MQ message size, an adjustment to the MAX_TRANS value to achieve an optimal number of MQ messages per MQ COMMIT_INTERVAL can help you meet your performance objectives. The value specified for the MAX_TRANS parameter is automatically multiplied by the TRANS_BATCH_SZ value, unless the MAX_TRANS value is supplied as a Capture startup parameter. In this case, the MAX_TRANS value is used as specified.

ASN7504E

The Q Apply program did not have enough physical memory that was requested from the operating system to allocate an internal data structure.

Ensure that enough memory is available from the operating system before starting the Q Apply program.

ASN7505E

An error in the setup of the columns of the IBMQREP_TRG_COLS table. The following values are valid for the reason code:

0

The number of columns specified in the IBMQREP_TRG_COLS table does not match the number of columns in the target table. There are more columns defined in the IBMQREP_TRG_COLS table than exist in the target.

1

The value of the MSG_COL_NUMBER column in the IBMQREP_TRG_COLS table is not unique.

2

The key columns are not the leading columns with respect to the MSG_COL_NUMBER in the IBMQREP_TRG_COLS table.

3

The value in the MSG_COL_NUMBER column is out of range. The value is either less than zero or greater than the maximum columns that are defined by the IBMQREP_TRG_COLS table.

4

No columns are defined that can uniquely identify a row. Q Replication requires that at least one column is unique.

5

One or more of the following columns are NULL in the IBMQREP_TRG_COLS table: MSG_COL_NUMBER, MSG_COL_TYPE, MSG_COL_CODEPAGE, or MSG_COL_LENGTH.

6

No unique index corresponds to the declared key columns. The DB2 database must have a constraint that one row from the source table corresponds to exactly one row in the target table. The Q Apply program uses unique index information to schedule parallelism of transactions. Therefore a unique index must be declared for each target table.

7

The target column has SQL Expressions in a key column but the source columns are not part of replication IS_KEY. All source columns used in a key expression must be defined as key columns in the IBMQREP_SRC_COLS control table at the capture server.

8

The Q subscription specifies an expression on both XML columns and key columns. You cannot replicate XML expressions on both XML columns and key columns.

Review the reason codes in the explanation, and take the appropriate action:

Reason Codes 0, 1, 2, 3, and 5 require the same user response. For each of these reason codes take the following user response action.

Redefine your Q subscription by using the replication administration tools and activate the Q subscription.

4

Redefine the Q subscription and identify the unique columns by using one of the replication administration tools. Then activate the Q subscription.

6

1. Choose a different set of columns that have a unique index defined as the key columns for this Q subscription,
2. or, create a unique index or a unique constraint on the target table.
3. Then restart the corresponding Q subscription.

7

Set the value of IS_KEY to 1 for the affected source columns in the IBMQREP_SRC_COLS control table.

8

Redefine your Q subscription and remove the expression on either the key columns or the XML columns. Then restart the corresponding Q subscription.

If the problem persists, contact IBM Software Support. Provide an Analyzer report.

ASN7506E

The target for the Q subscription as defined in the IBMQREP_TARGETS table does not exist. Either the target was specified incorrectly or it does not exist.

Make sure that the target exists in the target database. Verify that the values are correct for this target in the TARGET_OWNER, TARGET_NAME columns in the IBMQREP_TARGETS table. Also, make sure that the value in the TARGET_TYPE column is appropriate for the target. For example, if the target is a stored procedure make sure that the target type in the IBMQREP_TARGETS table is '5'. If the Q subscription is not valid, redefine it using one of the replication administration tools.

ASN7510E

The Q subscription must be active before you can add a new column to it.

Start the Q subscription.

ASN7512E

The Q subscription definition is incorrect. The error may have occurred because the Q subscription was updated with SQL other than that generated by the Replication Center or ASNCLP program, or the SQL generated by these administrative tools was modified. The following values are valid for the reason code:

0

The Q subscription does not exist in the IBMQREP_TARGETS control table.

1

The value of the STATE column in the IBMQREP_TARGETS control table is not I.

2

The type of Q subscription on the Q Capture and Q Apply servers is different.

3

The DESCRIBE statement failed for the target.

4

The value in the TARGET_COLNAME column in the IBMQREP_TRG_COLS table does not match any of the target columns in the target.

5

A value in the TARGET_COLNAME, MSG_COL_TYPE, or MSG_COL_LENGTH columns in the IBMQREP_TRG_COLS table does not match the name, type, or length of the corresponding column in the target table or stored procedure.

6

The SOURCE_COLNAME column in the IBMQREP_TRG_COLS table does not match the value of the SRC_COLNAME in the IBMQREP_SRC_COLS table.

7

The Q subscription ID is not unique for the receive queue.

8

The Q subscription is defined as bidirectional and, according to the conflict rules, the Q Capture sending options are incorrect. The CONFLICT_RULE column in the IBMQREP_TARGETS table is set to A or C and the sending option BEFORE_VALUES column in the IBMQREP_SUBS table is not set to Y.

9

The values of the SOURCE_OWNER, SOURCE_NAME columns in the IBMQREP_TARGETS table do not match the values in the IBMQREP_SUBS table. Also the value of the SOURCE_SERVER column in the IBMQREP_TARGETS table is not the server on which the Q Capture program is running.

10

The value of the IS_KEY column in the IBMQREP_TRG_COLS table does not match the value of the IS_KEY column in the IBMQREP_SRC_COLS table.

11

The code page of the source column cannot be converted to the Q Apply program code page.

12

The CONFLICT_ACTION column in the IBMQREP_TARGETS table is set to F, but the Q Capture sending options are incorrect. For the CONFLICT_ACTION F, the message needs to include all the columns not just the changed columns. The CHANGED_COLS_ONLY should be set to N in the IBMQREP_SUBS table.

13

The CONFLICT_RULE in the IBMQREP_TARGETS is set to K, but the Q Capture sending options are incorrect. The BEFORE_VALUES column should be set to N in the IBMQREP_SUBS table.

14

The Q Capture sending options specifies CHANGED_COLS_ONLY=N in the IBMQREP_SUBS table, but the value should be Y because of one or both of the following settings in the IBMQREP_TARGETS table:

• CONFLICT_ACTION is not F
• CONFLICT_RULE is not A

15

There are extra columns in the target that do not exist in the IBMQREP_TRG_COLS table and they are NOT NULL and are not defined with default.

16

The value of the SEARCH_CONDITION column in the IBMQREP_SUBS table is not specified correctly.

17

The values of the SOURCE_NODE and TARGET_NODE columns in the IBMQREP_SUBS and the IBMQREP_TARGETS table do not match.

18

The stored procedure parameters which represent the columns do not match the SRC_COLNAME fields of the IBMQREP_SRC_COLS table.

19

The Q subscription is type 'U' (unidirectional), but the CONFLICT_RULE column in the IBMQREP_TARGETS table is not set to K.

20

The target type for this Q subscription is a CCD table. CCD tables must have the following four columns:

• IBMSNAP_INTENTSEQ
• IBMSNAP_OPERATION
• IBMSNAP_COMMITSEQ
• IBMSNAP_LOGMARKER

21

The target type for this Q subscription is a CCD table and the subscription type is either for bidirectional or peer-to-peer replication. CCD tables are only supported in unidirectional replication. This error should not occur unless one of the following is true:

• The Q subscription has been updated with SQL other than that generated by the Replication Center or ASNCLP command-line program.
• The SQL script generated by the Replication Center or ASNCLP was modified before it was run.

22

The target is a noncondensed CCD table. The only valid value for CONFLICT_ACTION in the IBMQREP_TARGETS table is F (force). Because all incoming changes are always inserted, the only valid Q Capture sending options in the IBMQREP_SUBS table are BEFORE_VALUES = Y and CHANGED_COLS_ONLY = N.

23

The target type for the Q subscription is a condensed and complete CCD table. The value for CONFLICT_ACTION in the IBMQREP_TARGETS table must be F (force) or I (ignore). For F (force) the only valid Q Capture sending options in the IBMQREP_SUBS table are BEFORE_VALUES = Y and CHANGED_COLS_ONLY = N. For I (ignore) the only valid Q Capture sending options are BEFORE_VALUES = N and CHANGED_COLS_ONLY = Y.

24

The target is a condensed and noncomplete CCD table. The CONFLICT_ACTION in the IBMQREP_TARGETS table is F (force). The only valid Q Capture sending options in the IBMQREP_SUBS table are BEFORE_VALUES = Y and CHANGED_COLS_ONLY = N.

25

The target is a CCD table. The value in one or both of the columns CCD_CONDENSED and CCD_COMPLETE in the IBMQREP_TARGETS table are null.

26

The target type for this Q subscription is a noncomplete CCD table, but the HAS_LOADPHASE column in the IBMQREP_SUBS table has a value other than N.

27

The target is a CCD table. The Q Apply program read a message from the Q Capture program that has a version lower than Version 9 (for example, Version 8.2). The Q Apply program can process such down-level messages, but Version 9 function such as CCD targets cannot be supported in this configuration.

28

The target column information in IBMQREP_TRG_COLS table is not set up correctly.

29

The target type for this Q subscription is a stored procedure and the Q subscription is for replication from or to a database with the DB2 pureScale Feature. Stored procedure targets are only supported in unidirectional replication and are not supported with the DB2 pureScale Feature.

30

The target table is a system period temporal table or a bitemporal table on a DB2 whose version is older than V10.1 Fix Pack 2 on Linux, UNIX, and Windows or APAR PM31315 on z/OS. The Q Apply program does not support replication to temporal tables before these versions.

Review the reason codes in the explanation, and take the appropriate action:

0

Verify the definition of the Q subscription, the SUBNAME column in the IBMQREP_SUBS table and the IBMQREP_TARGETS table. Redefine the Q subscription using the replication administration tools and activate the Q subscription.

1

Deactivate the Q subscription by setting the value of the STATE column of the IBMQREP_TARGETS control table to I. On the Q Capture server, deactivate and activate the Q subscription.

2

Check that the value of the SUBTYPE column in the IBMQREP_SUBS table matches the value of the SUBTYPE column in the IBMQREP_TARGETS tables. Redefine the Q subscription by using one of the replication administration tools.

3

Refer to the Q Apply diagnostic log file or the IBMQREP_TRACE table for the message ASN0552E, which contains the SQL return code information.

4

Verify that the Q subscription is set up correctly. Do a describe on the target table and the values stored in the IBMQREP_TRG_COLS table for the target table to identify differences. Redefine the Q subscription using one of the replication administration tools.

5

Verify that the Q subscription is set up correctly. Do a describe on the target table or stored procedure and check the values stored in the IBMQREP_TRG_COLS table to identify differences. Redefine the Q subscription using one of the replication administration tools.

6

Redefine the Q subscription using one of the replication administration tools.

7

Redefine the Q subscription using one of the replication administration tools.

8

Redefine the Q subscription using one of the replication administration tool. If the problem persists, contact IBM Software Support. Provide an Analyzer report.

9

Redefine the Q subscription using one of the replication administration tool. If the problem persists, contact IBM Software Support. Provide an Analyzer report.

10

Redefine the Q subscription using one of the replication administration tool. If the problem persists, contact IBM Software Support. Provide an Analyzer report.

11

Refer to the Q Apply diagnostic log file for the message ASN0568E, which specifies the CCSID that was not converted. Recommendation: Change the Q Apply code page to be the same as the source database code page.

12

Redefine Q subscription using one of the replication administration tools. If the problem persists, contact IBM Software Support. Provide an Analyzer report.

13

Redefine Q subscription using one of the replication administration tools. If the problem persists, contact IBM Software Support. Provide an Analyzer report.

14

Redefine Q subscription using one of the replication administration tools. If the problem persists, contact IBM Software Support. Provide an Analyzer report.

15

Modify the target attributes or subscribe to those extra columns.

16

Check the text in the SEARCH_CONDITION column of the IBMQREP_SUBS table and ensure that only the column names of the table being replicated are enclosed in square brackets. Redefine the Q subscription using one of the replication administration tools.

17

Redefine the Q subscription using one of the replication administration tools. If the problem persists, contact IBM Software Support. Provide an Analyzer report.

18

Redefine the Q subscription using one of the replication administration tools. If the problem persists, contact IBM Software Support. Provide an Analyzer report.

19

Redefine the Q subscription using one of the replication administration tools. If the problem persists, contact IBM Software Support. Provide an Analyzer report.

20

Use the Replication Center or ASNCLP program to add the four mandatory columns to the CCD table, and then activate the Q subscription.

21

Do one of the following things:

• Correct any SQL that was generated by the Replication Center or ASNCLP program and then modified.
• Drop the Q subscription and recreate it by using one of the administration tools.

22

Change the CONFLICT_ACTION column in the IBMQREP_TARGETS table and the BEFORE_VALUES and CHANGED_COLS_ONLY columns in the IBMQREP_SUBS table to the values that are specified in the explanation.

23

Change the CONFLICT_ACTION column in the IBMQREP_TARGETS table and the BEFORE_VALUES and CHANGED_COLS_ONLY columns in the IBMQREP_SUBS table to the values that are specified in the explanation.

24

Change the CONFLICT_ACTION column in the IBMQREP_TARGETS table and the BEFORE_VALUES and CHANGED_COLS_ONLY columns in the IBMQREP_SUBS table to the values that are specified in the explanation.

25

In the IBMQREP_TARGETS table, set the CCD_CONDENSED column to Y for condensed CCDs or N for noncondensed CCDs; set the CCD_COMPLETE column to Y for complete CCDs or N for noncomplete CCDs.

26

If the target table needs to be loaded, the CCD table must be complete. If you need a noncomplete CCD table, the value for HAS_LOADPHASE must be N.

27

Upgrade the Q Capture program at the source system to Version 9 and then start the Q subscription.

28

Look in the Q Apply diagnostic log file or IBMQREP_APPLYTRACE table for messages that might indicate the problem with the column definition. Redefine the Q subscription using one of the replication administration tools, and then start the Q subscription.

29

Use a source database, target database, or both that does not have the DB2 pureScale Feature.

30

Upgrade DB2 on the target database to V10.1 Fix Pack 2 on Linux, UNIX, and Windows or APAR PM31315 on z/OS.

ASN7513W

ASN7514W

The number of messages reached the number that is set for the MAXDEPTH attribute on the administration queue. The administration queue is full and the Q Apply browsers cannot write to it. Perhaps the Q Capture program is not reading from that administration queue.

Ensure that the Q Capture program is running. If it is not, restart it.

If necessary, increase the value for the MAXDEPTH attribute of the administration queue.

ASN7515E

This message version is not supported by this version of the Q Apply program. The Q Capture program is not compatible with the Q Apply program version.

Set the value of the COMPATIBILITY column in the IBMQREP_CAPPARMS table to match the version of the Q Apply program. The Q Apply version is recorded in the ARCH_LEVEL column of the IBMQREP_APPLYPARMS table. If Q Capture works with multiple Q Apply programs, set COMPATIBILITY to match the version of the oldest Q Apply program. You can use the Replication Center or Q Replication Dashboard to change the Q Capture COMPATIBILITY value.

ASN7516E

ASN7517E

ASN7519E

The SUB_ID can be NULL only if the Q subscription state is 'I' (Inactive). The Q subscription definition was altered.

Deactivate the Q subscription, redefine it, and activate it.

ASN7522E

The Q Apply program encountered an error or conflict while trying to apply a transaction for this target. The error or action for this Q subscription is S (stop the Q Apply program). Refer to the Q Apply diagnostic log file and the IBMQREP_EXCEPTIONS table for details as to why the error occurred.

Address the problem that was identified in the diagnostic log file or the IBMQREP_EXCEPTIONS table and restart the Q Apply program. No changes will be lost. If the problem is only related to the target for this Q subscription, deactivate the Q subscription and restart the Q Apply program. The Q Apply program will be able to apply changes to other targets.

ASN7523E

The Q Apply program encountered an error or conflict while trying to apply a transaction for this target. The error or action for this Q subscription is Q (stop reading from the queue). Refer to the Q Apply diagnostic log file and the IBMQREP_EXCEPTIONS table for details as to why the error occurred.

Address the problem that was identified in the diagnostic log file or the IBMQREP_EXCEPTIONS table and resume reading from the queue using the startq command. No changes will be lost. If the problem is only related to the target for this Q subscription, deactivate the Q subscription and resume reading from the queue. The Q Apply program will be able to apply changes to other targets.

ASN7524E

The Q Apply program encountered an error or conflict while trying to apply a transaction for this target. The error or action for this Q subscription is 'Q' (stop reading from the queue).

Address the problem that was identified in the diagnostic log file or the IBMQREP_EXCEPTIONS table and resume reading from the queue using the startq command. No changes will be lost. If the problem is only related to the target for this Q subscription, deactivate the Q subscription and resume reading from the queue. The Q Apply program will be able to apply changes to other targets.

ASN7525W

The receive queue is inactive. The STATE column in the IBMQREP_RECVQUEUES table is marked as I (inactive) for this receive queue. If the skiptrans parameter was specified on Q Apply program invocation, the parameter is ignored.

This message is for your information only. No action is required. If you want the Q Apply program to process the queue, use one of the following methods:

• Issue the startq command without restarting Q Apply.
• Change the STATE column in the IBMQREP_RECVQUEUES table to A and restart Q Apply.

ASN7526I

The Q Apply program has started reading from the receive queue.

This message is for information only. No action is required.

ASN7527I

The startq command was issued for the receive queue, and the Q Apply program has started the Q Apply browser for the queue.

This message is for your information only. No action is required.

ASN7528I

The loadphase for this Q subscription is specified as internal. Q Apply has chosen this utility to perform the load.

This message is for your information only. No action is required.

ASN7529I

The load utility specified finished successfully. Look at the detail message from the utility for the statistics.

This message is for your information only. No action is required.

ASN7530E

The load utility encountered an error for the Q subscription. The Q subscription cannot be activated.

Refer to the detailed message from the load utility for the return code and the SQL return code. Fix the problem and then activate the Q subscription. If the problem persists, select a different load utility.

ASN7531I

The Q subscription specifies that the Q Apply program will load the target table. Q Apply chose this load utility based on the replication environment. The following values are valid for the reason code:

0

The target is DB2 for Linux, UNIX, and Windows Version 8 or later and one of the following conditions is true:

• A nickname is defined for the source table or the source table is local to the target system, and the server option CONCURRENT_ACCESS_RESOLUTION=W is supported. In this case LOAD from CURSOR uses the nickname to load the target table.
• No nickname is defined for the source table and the source table has no XML columns. In this case, LOAD from CURSOR is performed by using a cataloged DB2 alias.

1

The target is DB2 for Linux, UNIX, and Windows Version 8 or later and the source does not have a nickname and the source is remote to the target.

2

The target is DB2 for z/OS Version 7 or later.

3

The target is DB2 for Linux, UNIX, and Windows Version 8 or later and either the source nickname is defined or the source is local to the target, or the target is DB2 for z/OS Version 7 or later.

4

The target is DB2 for Linux, UNIX, and Windows Version 8 or later.

5

The target is DB2 for Linux, UNIX, and Windows Version 8 or later and one of the following conditions is true:

• The target is a nickname.
• The target is remote and the source table contains large object (LOB) columns that are part of a unidirectional Q subscription.

6

The target is Version 8 or later of DB2 for Linux, UNIX, and Windows and the source nickname is defined but does not use the server option CONCURRENT_ACCESS_RESOLUTION=W. This option is required to use LOAD from CURSOR to ensure that the utility waits until all in-progress transactions that modify the source table are completed before beginning the load. Q Apply selected the next best alternative utility for the load.

7

The target is a Lakehouse table. Initial loading of the source table is done by running a SELECT FROM the source operation and an INSERT INTO the target operation, row by row.

This message is for your information only. No action is required.

ASN7532E

The following values are valid for the reason code:

0

The target is distributed but it is not DB2 for Linux, UNIX, or Windows Version 8 or later.

1

The target is not DB2 for z/OS Version 7 or later.

2

The target is DB2 for Linux, UNIX, or Windows Version 8 or later and one of the following conditions is true:

• A nickname is not defined for the source table and the source table is not local to the target database.
• The source table is remote from the target database and an XML column is part of the Q subscription.

3

The target is not distributed.

4

The load type is not valid.

5

The target is a nickname and the load type specified is not valid. For nicknames, the valid load type is EXPORT/IMPORT. However, importing into a nickname is not supported for federated targets when the Q Apply server uses the DB2 pureScale Feature.

6

The Q subscription is bidirectional or peer-to-peer and the EXPORT/IMPORT method can cause rows to be recaptured at the target. Valid load types are LOAD FROM CURSOR or EXPORT/LOAD.

7

The target is a remote database and the source table contains large object (LOB) or XML columns that are part of a Q subscription. The EXPORT/LOAD option does not support loading remote targets with LOB or XML data. The only valid load type is LOAD FROM CURSOR.

8

To specify an automatic load, you must use LOAD from CURSOR because the target is remote and the source table contains LOB columns that are part of a bidirectional or peer-to-peer Q subscription. On a remote target, LOB or XML data cannot be loaded using EXPORT/LOAD. For a bidirectional or peer-to-peer Q subscription the IMPORT utility is not a valid option because loaded data might be recaptured at the target. To use LOAD from CURSOR, the target must be DB2 for Linux, UNIX, or Windows Version 8 or later. If the source is remote from the target, you can use LOAD from CURSOR over a source nickname or a cataloged DB2 alias.

9

The target is Version 8 or later of DB2 for Linux, UNIX, and Windows and the source does not use the server option CONCURRENT_ACCESS_RESOLUTION=W. This option is required to use LOAD from CURSOR to ensure that the utility waits until all in-progress transactions that modify the source table are completed before beginning the load. If you need to use this utility, you must update the federated server options by using the following command:

 db2 alter server <name>   options (add   CONCURRENT_ACCESS_RESOLUTION 'W') 

10

Moving data from XML to LOB columns (BLOB, CLOB, DBCLOB) is not supported by the DB2 load utilities (LOAD/IMPORT). No automatic load type could be chosen.

11

LOAD from CURSOR over a cataloged DB2 alias cannot be selected because the Q subscription includes XML columns.

12

The target is not a Lakehouse table.

Refer to the detailed message from the utility for the return code and SQL return code. Select a different load type for this Q subscription. Activate the Q subscription. For reason code 8, if you cannot set up LOAD FROM CURSOR, specify a manual load or no load for HAS_LOADPHASE in the IBMQREP_TARGETS control table. For reason code 10, you must specify a manual load or no load.

ASN7533E

Any column in the target table that is not part of the Q subscription must be nullable or have a default value.

Modify the attributes of the target or add the column to the Q subscription. Deactivate and then activate the Q subscription.

ASN7534E

A stored procedure that is used as a target must define four mandatory parameters plus parameters that can be mapped back to source columns.

The following example shows a valid stored procedure.

 CREATE TABLE mySource (Parm1 INT NOT NULL, Parm2 VARCHAR(20) NOT NULL, Parm3 TIMESTAMP, Parm4 DATE, Parm5 CHAR(2), PRIMARY KEY(Parm1, Parm2)); CREATE statement for stored procedure: CREATE PROCEDURE storedprocedure_name( INOUT operation integer, IN suppression_ind VARCHAR(size), IN src_commit_lsn CHAR(10) FOR BIT DATA, IN src_trans_time TIMESTAMP, IN XParm1 INT NOT NULL, IN Parm1 INT NOT NULL, IN XParm2 VARCHAR(20) NOT NULL IN Parm2 VARCHAR(20) NOT NULL, IN Parm3 TIMESTAMP, IN Parm4 DATE, IN Parm5 CHAR(2) ) 

The following values are valid for the reason code:

0

The stored procedure must contain at least five parameters: four required parameters (OPERATION, SUPPRESSION_IND, SRC_COMMIT_LSN, and SRC_TRANS_TIME) and at least one parameter each source column.

1

The first parameter in the stored procedure must be OPERATION.

2

The second parameter in the stored procedure must be SUPPRESSION_IND.

3

The third parameter in the stored procedure must be SRC_COMMIT_LSN.

4

The fourth parameter in the stored procedure must be SRC_TRANS_TIME.

5

The INOUT attribute value of the OPERATION parameter is not equal to INOUT.

6

The INOUT attribute value of the SUPPRESSION_IND, SRC_COMMIT_LSN, or SRC_TRANS_TIME parameter is not equal to IN.

7

The first parameter must have the parameter mode INOUT. All other parameters must have parameter mode IN.

8

No parameters were found that map to the before values of key columns. Before values for key columns are required for key updates. Before values of key columns have the name of the source column prefixed by the letter X. For example, if the key parameter is named Col3, then the before value for that key parameter must be named XCol3.

9

A key column does not have a parameter in the stored procedure that maps to the key column's before value. Before values for key columns are required for key updates. Before values of key columns have the name of the source column prefixed by the letter X. For example, if the key parameter is named Col3, then the before value for that key parameter must be named XCol3.

10

One of the four mandatory parameters was not of the expected data type. Expected data types are:

1. OPERATION: INTEGER
2. SUPPRESSION_IND: VARCHAR(x)
3. SRC_COMMIT_LSN: CHAR(10) FOR BIT DATA. If the COMPATIBILITY column in the IBMQREP_CAPPARMS table is 1001 or higher, the data type must be VARCHAR(16) FOR BIT DATA.
4. SRC_TRANS_TIME: TIMESTAMP

Modify the stored procedure by performing the action that corresponds to the reason code. Register the stored procedure again and restart the Q subscription.

0

Add the following mandatory parameters as the first parameters: OPERATION, SUPPRESSION_IND, SRC_COMMIT_LSN, SRC_TRANS_TIME). Next add one parameter that matches the data type for each primary key column and one identical parameter for the before image of updated key columns. Then add one parameter for each non-key column with data types that match each source column.

1

The first parameter in the stored procedure must be OPERATION.

2

The second parameter in the stored procedure must be SUPPRESSION_IND.

3

The third parameter in the stored procedure must be SRC_COMMIT_LSN.

4

The fourth parameter in the stored procedure must be SRC_TRANS_TIME.

5

Declare the OPERATION parameter to be INOUT.

6

Declare the parameters SUPPRESSION_IND, SRC_COMMIT_LSN, and SRC_TRANS_TIME to be IN parameters.

7

Ensure that the first parameter has the parameter mode INOUT and that all other parameters have parameter mode IN.

8

Ensure that the stored procedure has a parameter that maps to the before value for each key column. Add any missing parameters to handle before values for all key columns.

9

Ensure that the stored procedure has a parameter that maps to the before value for each key column. Add parameters to handle before values for all key columns.

10

Ensure that the four mandatory parameters have the following data types:

1. OPERATION: INTEGER
2. SUPPRESSION_IND: VARCHAR(x)
3. SRC_COMMIT_LSN: CHAR(10) FOR BIT DATA or VARCHAR(16) FOR BIT DATA
4. SRC_TRANS_TIME: TIMESTAMP

ASN7535E

ASN7536E

Redefine the Q subscription using one of the replication administration tools.

ASN7537E

Redefine the Q subscriptions to and from this node using one of the replication administration tools.

ASN7538E

The Q subscription is not correctly defined for peer-to-peer or bidirectional replication.

Redefine the Q subscriptions to and from the table at this server using one of the replication administration tools.

ASN7539E

Some Q subscriptions cannot be found. Some Q subscriptions might have been deleted, or were not created to begin with. All Q subscriptions going to and from this node cannot be deactivated.

The Q subscriptions were not properly defined because they are not fully connecting all physical tables from this logical table. Therefore the deactivation protocol cannot automatically deactivate all of the Q subscriptions to and from this node.

ASN7540I

The Q subscription is specified with a loadphase, either internal or external. During the load, the referential constraints are dropped from the target table and saved in the IBMQREP_SAVERI table.

This message is for your information only. No action is required.

ASN7541I

The Q Apply program has finished loading the Q subscription, and has added the referential constraints back to the target. The referential constraints were removed from the IBMQREP_SAVERI table.

This message is for your information only. No action is required.

ASN7542E

The Q subscription definition in the IBMQREP_SUBS table was dropped during the initialization of a new member.

Redefine the Q subscriptions to and from the node using one of the replication administration tools.

ASN7543W

A REINITQ command was issued to change the memory limit for the receive queue, but the memory limit value specified was the same as the existing value.

If you want to change the memory limit from the current value, reissue the REINITQ command for the receive queue, specifying a new memory limit in MB.

ASN7544W

A REINITQ command was issued to change the number of apply agents for the receive queue, but the number of agents specified was the same as the existing number.

If you want to change the number of agents for this receive queue, reissue a REINITQ command for the receive queue that specifies a new number of agents.

ASN7545W

REINITQ command was issued to change the number of agents; however, after the change there would be 0 agents left. Because of this fact, the REINITQ command was not processed.

Verify that the correct number of agents was specified for this receive queue.

ASN7546W

The Q Apply program allows a maximum number of agent threads for each replication queue map. If the number is exceeded, the REINITQ command to refresh the attributes of the queue map fails.

Reduce the number of agent threads that you specify for the queue map and then reissue the command.

ASN7547I

The REINITQ command that you issued to decrease the number of agents for the receive queue was processed successfully.

This message is for your information only. No action is required.

ASN7548I

The REINITQ command that was issued to increase the number of agents was processed successfully.

This message is for your information only. No action is required.

ASN7549I

The REINITQ command was issued successfully to increase the memory limit for this receive queue.

This message is for your information only. No action is required.

ASN7550E

An internal inconsistency was detected.

Contact IBM Software Support. Provide an Analyzer report.

ASN7551E

To make it easier for Q Apply programs or subscribing applications to detect missing or out-of-sequence messages, Q Replication and event publishing programs use a dense numbering system. A dense numbering system is one where each message is assigned a positive integer with no gaps between numbers. The Q Capture program assigns a unique identifier to each message that it puts on the send queue. These identifiers are necessary because the Q Apply program processes messages in a strict order. When a message does not arrive in the receive queue in its expected order, the Q Apply program continues to look for the message. The Q Apply program will apply all changes that belong to messages that it already received.

Look for the message with the expected message ID on all the dead letter queues of all the WebSphere MQ queue managers that are used to transmit messages between the Q Capture and Q Apply programs. If you recover the message, put it on the receive queue, preserving the WebSphere MQ message header information (especially the message ID). If the message cannot be recovered, follow these steps:

1. Stop the send queue so that no new messages are transmitted.
2. Purge the receive queue.
3. Stop Q Capture.
4. Update the restart file with the restart point for the send queue.
5. Start Q Capture to re-read the log for the send queue.

You can also use the Recovery Advisor lost messages procedure in the InfoSphere Data Replication Dashboard to perform these steps.

ASN7552W

The Q Apply program detected a gap in the message ID and cannot proceed until that message ID is found. This message will continue to be issued periodically until the message with the expected message ID is put on the send or receive queue.

Look for the message with the expected message ID on all the Dead Letter Queues of all the WebSphere MQ queue managers that are used to transmit messages between the Q Capture and Q Apply programs. If you recover the message, put it on the receive queue, preserving the WebSphere MQ message header information (especially the message ID). If the message cannot be recovered, follow these steps:

1. Use the stopq command to stop the Q Apply program from reading from the receive queue.
2. Deactivate all the Q subscriptions for this replication queue map.
3. Empty the send queue and the receive queue.
4. Use the startq command so that the Q Apply program resumes reading from the receive queue.
5. Activate all the Q subscriptions for this replication queue map.

ASN7553E

ASN7554W

See message text.

Determine why the dependent Q subscription is in the inactive state. If it has not been activated, activate it. If it is in inactive state due to an error, fix the error by looking at the Q Apply diagnostic log file. After the dependent Q subscription is active, the Q Apply program will add the RI constraints that were saved in the IBMQREP_SAVERI table.

ASN7555W

The Q Apply program encountered SQLCODE 667 when trying to add RI constraints for the Q subscription. The Q Apply program might not know about the dependent table because there is no Q subscription defined on it, or because a Q subscription is defined on it but a CAPSTART signal was never issued. After the dependent Q subscription is active, the Q Apply program will add the RI constraints that were saved in the IBMQREP_SAVERI table.

Find the dependent table and define a Q subscription on it. If a Q subscription is defined, issue a CAPSTART signal on it.

ASN7557W

See message text.

Increase the MEMORY_LIMIT value in the IBMQREP_RECVQUEUES table for the specified replication queue map.

ASN7558E

The number of messages on the spill queue has reached the number set by the MAXDEPTH attribute for that spill queue. The spill queue is full and the Q Apply program cannot write to it. Perhaps the Q Apply program is still loading the target table, but the corresponding source table is being heavily updated.

If possible, stop the Q Capture program. If necessary, increase the value for the MAXDEPTH attribute of the spill queue.

ASN7559W

See message text.

Lower the MEMORY_LIMIT value in the IBMQREP_RECVQUEUES table for the specified replication queue map.

ASN7583W

See message text.

Drain all messages from the queue and activate the Q subscription.

ASN7584E

The Q subscription cannot be activated as the stored procedure name as defined in the IBMQREP_TARGETS could not be found or the stored procedure is not registered.

Check for the stored procedures schema and name in the TARGET_OWNER,TARGET_NAME column of the IBMQREP_TARGETS table. Register the stored procedure using the "CREATE PROCEDURE" statement.

ASN7586E

The memory_limit is the amount of memory used by the Q Apply program to store transactions to be applied. It needs to be big enough to contain at least 1 incoming message.

Check the maximum message size of the incoming send queue in the IBMQREP_SENDQUEUES table. The memory limit needs to be able to contain many messages else performance would not be acceptable. So you need to increase the memory_limit value in the IBMQREP_RECVQUEUES table and issue the REINITQ command or stop and start the Q Apply process.

ASN7587E

The memory limit for the receive queue is too high.

Lower the MEMORY_LIMIT value in the IBMQREP_RECVQUEUES table for the specified replication queue map.

ASN7588E

ASN7589E

The Q Apply browser while trying to update this receive queue state, could not find an entry corresponding to the receive queue name, in the IBMQREP_RECVQUEUES table.

Check the RECVQ column in the IBMQREP_RECVQUEUES table. Redefine the Q subscription using one of the replication administration tool, and activate the Q subscription again.

ASN7590I

The following values are valid for the reason code:

0

The Q Apply program is running with the AUTOSTOP parameter option and it encountered an empty receive queue.

1

The Q Apply browser thread received the STOPQ command.

2

The Q Apply browser thread received the PURGEQ command.

This message is for your information only. No action is required.

ASN7591I

The Q Apply agents started for this receive queue.

This message is for your information only. No action is required.

ASN7592E

A character field inside an internal message that was sent by the Q Capture program and processed by the Q Apply program cannot be converted to Q Apply program code page (the code page code is called CCSID). It is highly recommended that you run the source database, the Q Capture program, the Q Apply program, and the target database in the same code page to avoid unnecessary conversions. In this case the ICU library used to convert one code page to another is not able to convert the Q Capture program code page to the Q Apply program code page. For DB2, you can set the application code page with the command db2set DB2CODEPAGE=[CCSID].

Issue the command to set the Q Apply program code page to the Q Capture program code page, or set it to a code page that can be converted by the ICU library.

ASN7593E

Some data types are not supported in Q Replication and Event Publishing and some data types can be used only under certain circumstances.

Check the data type of the column, and ensure that DB2 supports the data type on the target. Also check the Q Replication documentation for information about data types that are not supported.

ASN7594W

ASN7595W

The Q Apply program is not replicating or loading the Q subscription corresponding to the incoming message.

If the Q subscription is already inactive (state 'I' in the IBMQREP_TARGETS table) nothing needs to be done. If the Q subscription SUB_ID cannot be found in the IBMQREP_TARGETS table, the Q subscription is defined only for the Q Capture program. Define the Q subscription so that the target information is part of the Q subscription.

ASN7597E

The Q Apply program encountered an error or conflict while applying a change from a transaction, and the Q subscription specifies a conflict action, error action, or both to deactivate the Q subscription when conflicts or errors occur. The row that caused the conflict or error is saved to the IBMQREP_EXCEPTIONS table. All further changes from the source table are ignored until the Q subscription is restarted, which will trigger a new load of the target table.

Check the IBMQREP_EXCEPTIONS table for details about the conflict or error. Fix the problem, and then start the Q subscription again. If no row exists in the IBMQREP_EXCEPTIONS table, then either the row was deleted or the error occurred during the initial load process. During the load process, no further information is stored in the IBMQREP_EXCEPTIONS table. Instead, the information is stored in the Q Apply log file (either the present log file or a previous log file).

ASN7598E

The Q subscription probably specifies N in the BEFORE_VALUES column of the IBMQREP_SUBS table but the CONFLICT_RULE column in the IBMQREP_TARGETS table specifies C or A. Such a configuration is not valid. This configuration might have resulted if the IBMQREP_SUBS table was modified without first stopping the Q subscription.

Ensure that the Q subscription is defined correctly by following these steps:

1. Stop the Q subscription.
2. Use the replication administration tools to correctly define the Q subscription. If the conflict rule for the Q subscription is C (check changed columns) or A (check all columns), then the BEFORE_VALUES column in the IBMQREP_SUBS table must be set to Y.
3. Start the Q subscription

ASN7605I

See message text.

This message is for your information only. No action is required.

ASN7606I

See message text.

This message is for your information only. No action is required.

ASN7607I

See message text.

This message is for your information only. No action is required.

ASN7608I

See message text.

This message is for your information only. No action is required.

ASN7609W

The source and target tables do not use the same codepage. While the Q Apply program was performing the codepage conversion, the data of one column expanded. Because the expanded data does not fit in the target column, a database error will occur, which will trigger the Q Apply error action for this Q subscription. The Q Apply error action will be logged in the Q Apply log file and the IBMQREP_APPLYTRACE table.

Alter the target table column to increase the column's length. For example, if the column is declared as VARCHAR(10), you can extend it to be VARCHAR(30). Look in Q Apply log file or the IBMQREP_APPLYTRACE table for the message that will be issued after the Q Apply error action is triggered.

ASN7610E

An AddCol signal was issued to the Q Capture program, which resulted in a message being sent to the Q Apply program. However, the Q subscription is not known by the Q Apply program either because the Q subscription was never started, it was stopped because of an error, or it was dropped.

Look in the Q Apply log file or the IBMQREP_APPLYTRACE table for related messages. For example, if you see the message ASN7512E, then the Q subscription was never started, and if you see the message ASN7597E, then the Q subscription was stopped. If the Q subscription exists, restart it. If the Q subscription does not exist, create and start it.

ASN7611I

The Q Apply program tried to alter the target table to add a new column, but the new column already existed. The Q Apply program will add this column to the Q subscription and start replicating changes.

This message is for your information. No action is required.

ASN7612I

The Q Apply program processed the AddCol signal successfully. Changes for the newly added column are now being replicated to the target table.

This message is for your information. No action is required.

ASN7613I

This message contains the codepage information for the replication queue map.

Use this information to know which codepages (CCSID) are used by the Q Apply program and possibly to debug issues that are related to codepage conversion.

ASN7614W

The Q Apply program detected that the timestamp of a replicated row in a peer-to-peer configuration is ahead of the local time. To avoid inconsistencies the apply agent that is processing this change will not apply the change until the local time is equal to or more than the change's own time.

Adjust the time of the local clock. The local operating system and software packages offer commands to adjust the local time. The local time on the system that is running the Q Apply program should be moved ahead to match the time of the machine where the Q Capture program is running. It is not advisable to move a clock back in time.

ASN7615W

The Q Apply program periodically deletes rows from the IBMQREP_DELTOMB table if there are any active Q subscriptions in a peer-to-peer configuration. A row is not deleted until the Q Apply program sees a transaction message or a heartbeat message that has a later timestamp than the current row. A queue is either not being processed, no messages are going through it, or no messages are being put on it by the Q Capture program.

ASN7616E

On DB2 for z/OS, any LOB column (BLOB, CLOB, DBCLOB) that is added to a Q subscription must be defined on the target table before you issue the ADDCOL signal. The column that was in the ADDCOL signal does not exist at the target.

Create the LOB column on the target table and reissue the ADDCOL signal.

ASN7617E

Check the table status and complete the definition to add the LOB column to the target table by adding the corresponding index. Then reissue the AddCol signal.

ASN7618I

This informational message (that corresponds to SQL0911) indicates that a transaction is retried because of a lock timeout or deadlock. The following values are valid for the reason code:

2

Transaction got rolled back

68

Lock timeout

The transaction log sequence number (LSN) can be used to identify whether the same transaction gets retried multiple times. A transaction is retried multiple times until the number in DEADLOCK_RETRIES from the IBMQREP_APPLYPARMS table is reached. If this limit is reached, the Q Apply program stops processing changes for this replication queue map.

For peer-to-peer replication only, run the runstats program on the target tables and the Q Apply internal tables: IBMQREP_DONEMSG, IBMQREP_SPILLEDROWS, IBMQREP_DELTOMB.

In a peer-to-peer environment where many conflicts are expected, many deadlocks should be expected as well. It is also advised to increase the DEADLOCK_RETRIES limit to a value that is greater than the default. On z/OS, the target table and the Q Apply internal tables (IBMQREP_DONEMSG, IBMQREP_SPILLEDROWS, IBMQREP_DELTOMB) should use row level locking. The database or subsystem generates deadlock event files that you can use to find the exact participant of a deadlock.

It is also possible to lower the number of apply agents for this replication queue map to have less concurrency and avoid chances of deadlocks.

ASN7619W

Changes are replicated between two float columns. The source is a non-z/OS server and the target is a z/OS server. A non-z/OS server uses the IEEE floating point number representation standard, while a z/OS server has its own format. Conversion is possible between the two formats. However, every value cannot be represented, and some values must be approximated. The replication configuration is not altered if this warning is issued, and the Q Apply error action will not be performed. Because of this approximation, the target table will not necessarily match the source table exactly.

Float columns should be avoided for primary key columns when you are replicating between a z/OS and a non-z/OS server to avoid breaking the one-to-one mapping between the source and target rows if there is a chance that floating point values get approximated.

This message is for your information. No user response is required.

ASN7620W

The Q Apply program's monitoring thread was not able to gather monitoring information for at least one Q Apply agent or spill agent. The monitoring data for the monitoring interval is not reliable, so reporting will be skipped for this monitoring interval. However, the data will be reported in the next monitoring interval, so it will not be lost. If a similar message continues to be reported, then the Q Apply agent or spill agent stopped or unexpected errors were detected in structures that are used in memory to collect performance statistics.

Respond to the message in one of the following ways:

• If this message appears only once, no action is required.
• If multiple monitoring cycles are skipped, perform the following troubleshooting steps:
  1. Look for additional error messages that might identify the problem, and try to correct the problem.
  2. If you cannot identify or correct the problem, stop and start the Q Apply program.

Determine the best time to start and stop the Q Apply program so that you minimize the effect on data replication, which should be continuing because replication is not affected by this problem.

ASN7621E

Modify the target or source columns (or both) so that they are compatible. Recreate and restart the Q subscription.

ASN7622W

The maximum length of a VARCHAR column is less than the length of a LONG VARCHAR column. Some incoming data might be truncated while it is replicated.

If data truncation is not acceptable, create the target column as LONG VARCHAR. Then redefine and restart the Q subscription. If truncation is acceptable, no action is required.

ASN7623E

An AddCol signal was issued to the Q Capture program for a Q subscription that has a nickname as the target. Because the Q Apply program cannot alter the nickname directly, the AddCol signal cannot be processed.

Redefine the nickname to include the new column and reissue the AddCol signal.

ASN7624I

The Q Apply program loads unique index information for all target tables so that it can correctly order transactions and apply them in parallel. This message specifies how many secondary unique indexes were found. The number does not include the unique index that is used to be the replication key.

This message is for your information. No action is required.

ASN7625E

When the target type of a Q subscription is a nickname and this nickname has more than one unique index, the Q Apply program requires the Q Capture program to send the before values of columns that have changed, and the values of columns that have not changed. These sending options allow Q Apply to apply transactions in the correct order without violating unique constraints on the target. These options are not required when the target type is a user table because the database manager provides the necessary index identifier that is used to order transactions. However, this identifying information is not always available.

At the source system change the BEFORE_VALUES attribute for this Q subscription to be Y and CHANGED_COLS_ONLY to be N in the IBMQREP_SUBS table.

ASN7626E

When you use the IMPORT utility to load data into federated targets, the target table should be empty. The IMPORT utility does not support the REPLACE option.

Delete the contents of the target table and activate the Q subscription.

ASN7627E

A previous error or condition caused the Q Apply browser to terminate. The reason code could be an SQLCODE, a WebSphere MQ reason code, or a replication diagnostic code.

Check the Q Apply log file for any diagnostic or error messages prior to this message.

ASN7628E

Q Apply browser tried to add the RI constraints to the tables after the table was loaded. However, the operation failed because of a constraint violation. Since there are no more transactions that can resolve this violation, the Q Apply browser stopped.

Compare the source and target tables and fix the rows that cause the constraint violation. Tip: You can use the asntdiff program to compare the source and target tables.

ASN7629E

The spill queue name is generated in Q Apply by concatenating the name of the model queue with the Q subscription information. The maximum length allowed is 48 characters.

Update the MODELQ column in the IBMQREP_TARGETS table with a model queue name that is smaller in length, so the spill queue name will not exceed 48 characters.

ASN7630I

ASN7631I

ASN7632I

ASN7633I

ASN7634I

ASN7635I

ASN7636I

ASN7637I

ASN7638I

ASN7639I

ASN7640I

ASN7641I

ASN7642I

ASN7643I

The target of the Q subscription is a nickname that refers to a table in the non-DB2 database

This message is for your information. No action is required.

ASN7644W

The clocks at the source and target server machines may not be synchronized.

Adjust the clocks at the source or target server so that they match. This will avoid the clock skew.

ASN7645E

The Q Apply program tried to find the target table when activating the Q subscription, but the table does not exist in the target database.

Redefine the Q subscription with the replication administration tools, and either specify a table that does exist or let the administration tools create a new target table. Then activate the Q subscription.

ASN7646E

The Q Apply program was unable to insert a row into the IBMQREP_EXCEPTIONS control table. It unsuccessfully tried to apply a row to the replication target. The information in this message identifies the row that the agent tried to apply.

Use the SQLCODE, SQLERRMC, OPERATION, and REASON in the message to determine the problem that prevented the Q Apply program from applying the row at the target. Also, ensure that the IBMQREP_EXCEPTIONS table for this Q Apply schema exists and is available.

ASN7647E

The specified CCD column for the Q subscription has an unexpected data type, data length, or both.

Alter the CCD table so that the specified column has the correct data type and data length.

ASN7648E

• If you want to specify a SQL expression for the Q subscription, change the Q subscription so that any columns with unsupported data types are not replicated.
• Use the ASNCLP command-line program or Replication Center to change the Q subscription so that expressions are not specified and the MAPPING_TYPE value in the IBMQREP_TRG_COLS table is R (regular).

ASN7649E

ASN7650I

A command was issued to specify that the Q Apply browser thread stop at the specified timestamp. The browser thread will stop after it processes all transactions with a source commit time that is less than or equal to the specified timestamp.

This message is for your information only. No action is required.

ASN7651I

The Q Apply program was started with the applyupto parameter, which specified that the browser thread stop at a specified timestamp. The browser thread detected a transaction with a source commit time that was greater than or equal to the timestamp, and so the browser thread will stop.

This message is for your information only. No action is required.

ASN7652E

The timestamp that was provided for the applyupto parameter in the command to start the Q Apply program has an invalid format. The expected format is one of the following: YYYY-MM-DD-HH.MM.SS.MMMMMM, YYYY-MM-DD-HH.MM.SS, YYYY-MM-DD-HH.MM, YYYY-MM-DD-HH, HH.MM, or HH.

Restart the Q Apply program and specify a valid timestamp for the applyupto parameter.

ASN7653E

The applyupto parameter cannot be specified when the value of the autostop parameter is Y (yes). So you cannot specify both applyupto and autostop =Y when you start the Q Apply program. You also cannot specify applyupto when the saved value of autostop in the IBMQREP_APPLYPARMS table is Y.

Restart the Q Apply program while specifying either the autostop parameter or the applyupto parameter. Update the value of autostop in the IBMQREP_APPLYPARMS table if necessary.

ASN7654E

When you use the asnqacmd command to operate the Q Apply program, the autostop and applyupto parameters cannot be enabled at the same time.

Reissue the asnqacmd command without specifying the autostop parameter.

ASN7655E

The MAXAGENTS_CORRELID value cannot be greater than the NUM_APPLY_AGENTS value.

Set the MAXAGENTS_CORRELID value lower than the NUM_APPLY_AGENTS value in the IBMQREP_RECVQUEUES table.

ASN7656W

Because the MAXAGENTS_CORRELID value is the same as the NUM_APPLY_AGENTS value, the Q Apply browser will not serialize transactions based on the correlation ID.

If lock contention is a problem, you can serialize transactions by setting the MAXAGENTS_CORRELID value smaller than the NUM_APPLY_AGENTS value. If you set the MAXAGENTS_CORRELID value to zero, you will not receive this warning and the browser will continue applying transactions in parallel.

ASN7657E

The following values are valid for the reason code:

0

The program is in the initialization phase.

1

The specified receive queue was not found.

2

The specified Q subscription was not found.

3

The spillsub command can only be issued to subscriptions in A (active) state. The Q subscription was in a state other than active.

4

The target table for the specified Q subscription has a referential integrity relationship with another table.

5

The temporary spill queue could not be created.

Perform the action that corresponds to the reason code:

0

Reissue the command after the program has finished initializing.

1

Check that the name of the receive queue is correct and reissue the command.

2

Check that the name of the Q subscription is correct and reissue the command.

3

If the state of the Q subscription is I or T, an error might have occurred with the Q subscription before the spillsub command was issued. Check the previous messages from the Q Apply program to determine the cause of the error. For other states, you must wait for the Q subscription to become active.

4

The spillsub command is not supported for target tables that have referential integrity relationships. To stop applying replicated transactions to target tables with referential integrity relationships, you must stop the entire receive queue by using the stopq command.

5

Check the log file for the Q Apply program for previous diagnostic or error messages to determine the cause of the failure.

ASN7658E

The Q Apply program was following the specified error action for the Q subscription because of an error during the attempt to apply a row. The specified action prompts Q Apply to place messages in a temporary spill queue until the error is corrected. However, Q Apply was unable to place the Q subscription in spill mode and so Q Apply will stop the browser thread.

Look in the Q Apply diagnostic log file or the IBMQREP_APPLYTRACE table for messages that might indicate the cause of the failure. Make sure that the WebSphere MQ model queue that is used to create spill queues for the Q subscription is created, and that the queue is correctly specified in the IBMQREP_TARGETS table.

After the problem is corrected, use the startq command to restart the receive queue.

ASN7659I

The Q Apply program is placing messages for the Q subscription in a temporary spill queue as directed by the spillsub command.

This message is for your information only. No action is required.

ASN7660I

The Q subscription that was placed in spill mode will be returned to normal processing as directed by resumesub command. Spilled messages will be applied. New messages will continue to be spilled and referential integrity constraints are still dropped on the target table. When the spill queue is empty, the constraints will be added back and the Q subscription will be placed in active (A) state.

This message is for your information only. No action is required.

ASN7661I

The MAXAGENTS_CORRELID parameter specifies the maximum number of agent threads that can process transactions with the same z/OS correlation ID or job name. This parameter allows you to reduce lock contention by limiting parallelism for transactions from the same batch job on a z/OS Q Capture server. Reducing lock contention can lower latency.

By using this setting, the Q Apply program will limit parallelism during batch workloads to prevent lock contention.

This message is for your information only. No action is required.

ASN7662E

The following values are valid for the reason code:

0

The program is in the initialization phase.

1

The specified receive queue was not found.

2

The specified Q subscription was not found.

3

The resumesub command can only be issued to Q subscriptions in S (spilling) or P (pending) state. The Q subscription was in a state other than spilling or pending.

Perform the action that corresponds to the reason code:

0

Reissue the command after the program finishes initializing.

1

Check that the name of the receive queue is correct and reissue the command.

2

Check that the name of the Q subscription is correct and reissue the command.

3

Take one of the following actions, depending on the Q subscription state:

• If the state is I or T, an error might have occurred with the Q subscription before the resumesub command was issued. Check the previous messages from the Q Apply program to determine the cause of the error. After the error is fixed, reissue the resumesub command.
• If the state is A, R, or F, the Q subscription already resumed and you do not need to issue the resumesub command.

ASN7663E

The following values are valid for the reason code:

0

The program is in the initialization phase.

1

The specified receive queue was not found.

2

The specified Q subscription was not found.

3

The loaddonesub command can only be issued for Q subscriptions in the E state.

4

The loaddonesub command should be issued only for the peer-to-peer Q subscription that was used for the CAPSTART signal. This subscription is the same subscription that has the source table that was used as the load source for the manual load.

Perform the action that corresponds to the reason code:

0

Reissue the command after the program has finished initializing.

1

Check that the name of the receive queue is correct and reissue the command.

2

Check that the name of the Q subscription is correct and reissue the command.

3

If the state of the Q subscription is I or T, an error might have occurred with the Q subscription before the loaddonesub command was issued. Check the previous messages from the Q Apply program to determine the cause of the error. For all other states, verify that you specified the correct Q subscription and verify that the state of the Q subscription is 'E.' Reissue the command.

4

Check that you specified the correct peer-to-peer Q subscription for the loaddonesub command. Use the Q subscription that specifies the source table that you used to perform the initial load. Reissue the command for the correct Q subscription.

ASN7664W

The MAXAGENTS_CORRELID value cannot be greater than the NUM_APPLY_AGENTS value.

Set the MAXAGENTS_CORRELID value lower than the NUM_APPLY_AGENTS value in the IBMQREP_RECVQUEUES table.

ASN7665E

The Q Apply program encountered an error while applying a row that contained LOB data to a target table with an XML column. If the error occurred during spill queue processing, the Q subscription is deactivated. Otherwise the browser thread terminates.

To replicate LOB data to an XML column at the target, the LOB data must be sent within the transaction message, also known as inline, rather than in segments. Follow one of these procedures:

If the Q subscription was deactivated

1. Stop the Q Capture program.
2. Update the LOB_SEND_OPTION column in the IBMQREP_CAPPARMS table with a value of I.
3. Start the Q Capture program in warm mode.
4. Use the replication administration tools to activate the Q subscription.

If the browser thread stopped

1. Change the value of the STATE column for the Q subscription to I in the IBMQREP_TARGETS table.
2. Use the asnqacmd startq command to start the browser for the receive queue.
3. Wait until the STATE column in the IBMQREP_SUBS table changes to a value of I.
4. Stop the Q Capture program.
5. Update the LOB_SEND_OPTION column in the IBMQREP_CAPPARMS table with a value of I.
6. Start the Q Capture program in warm mode.
7. Use the replication administration tools to activate the Q subscription.

ASN7666E

You can use one of two methods to prevent recapture of transactions in a bidirectional replication environment:

• Accept the default behavior in which the Q Capture and Q Apply programs use signal inserts (insert_bidi_signal=Y).
• Use the Q Capture program's ability to ignore specified transactions (insert_bidi_signal=N and an entry to the IBMQREP_IGNTRAN table with Q Apply's authorization ID or plan name).

If you want to use the ignore transaction method, insert a valid identifier for the Q Apply program into the AUTHID or PLANNAME column of the IBMQREP_IGNTRAN table at the server that is shared by the Q Apply program and Q Capture program in the bidirectional configuration. Then restart the Q Apply program.

ASN7667E

You can use one of two methods to prevent recapture of transactions in a bidirectional replication environment:

• Accept the default behavior in which the Q Capture and Q Apply programs use signal inserts (insert_bidi_signal=Y).
• Use the Q Capture program's ability to ignore specified transactions (insert_bidi_signal=N and an entry to the IBMQREP_IGNTRAN table with Q Apply's authorization ID or plan name).

If you want to use the ignore transaction method, take these actions:

1. Upgrade the Q Capture control tables to Version 9.1 Fix Pack 2 or newer to add the IBMQREP_IGNTRAN table.
2. Insert a valid identifier for the Q Apply program into the AUTHID or PLANNAME column of the IBMQREP_IGNTRAN table at the server that is shared by the Q Apply program and Q Capture program in the bidirectional configuration.
3. Restart the Q Apply program.

ASN7668E

The Q Apply program detected that the number of key columns for the unique index exceeds the maximum number that DB2 allows. The limit differs by platform and version.

Drop and recreate the unique index so that it is within the maximum number of key columns.

ASN7669W

The Q Apply program uses the MAXAGENT_CORRELID setting for the receive queue only if the Q Capture server is on z/OS and at Version 9.1 with the PTF for APAR PK49430 or later. The following reason codes apply:

0

The Q Capture program is an older version that does not support sending correlation ID information.

1

The Q Capture server is not on z/OS. Correlation ID information is not valid for non-z/OS sources.

Upgrade the Q Capture server, or if the Q Capture server is on Linux, UNIX, or Windows, set the MAXAGENT_CORRELID column in the IBMQREP_RECVQUEUES table to NULL for this receive queue.

ASN7670I

The transaction ID that was specified with the skiptrans parameter on program invocation or with the startq command was successfully skipped from the receive queue.

This message is for your information only. No action is required.

ASN7671I

The transaction IDs in the range that was specified in the skiptrans parameter on program invocation or with the startq command were read from the receive queue but not applied. The messages were deleted from the receive queue.

This message is for your information only. No action is required.

ASN7673E

The transaction ID that was specified with the skiptrans parameter on program invocation or with the startq command has an invalid format or was not found on the receive queue. The following values are valid for the reason code:

0

The transaction ID to skip was not found on the receive queue.

1

The transaction ID to skip has an invalid format

Review the reason codes in the explanation, and take the appropriate action:

0

Use the asnqmfmt tool or asnqxmfmt tool on z/OS to check if the transaction ID exists on the receive queue. If it exists and you want to skip it, start the program again while specifying this transaction ID with the skiptrans parameter.

1

The following characters can be used to specify a transaction ID with the skiptrans parameter:

• Uppercase A-F
• Lowercase a-f
• Numerics 0-9
• Special characters: "-" and ":" only

For example, the following transation IDs are allowed:

 0000:0000:0000:51a1:0000  00000000000051a10000  0000:0000:0000:0000:51a1-     0000:0000:0000:0000:51a8 

Note:

• Leading zeros cannot be omitted in a transaction ID. The transaction ID can be specified with or without colons. For example, 0000:0000:0000:51a1:0001 is treated the same as 00000000000051a10001.
• The length of each unit between colons in the input transaction ID should be equal to 4. For example, 0000:1090:1234:5671:001 is not allowed because the length of the last unit is less than 4.
• Wild card characters such as (*) are not allowed. For example, a range clause such as "* -1123:0000:01fa:bbc2:0001" is not allowed.
• No spaces are allowed between the delimiters (semi-colon, hyphen, comma) that are used in the syntax for skiptrans parameter.
• The range of transaction IDs to skip includes beginning and ending transaction IDs.

ASN7674E

The Q Apply program received a schema message for the Q subscription that indicates that the target table was loaded. The Q subscription state in the IBMQREP_TARGETS table should be W but is a different value.

Review the setup and restart the Q subscription.

ASN7675I

The Q Apply program received a schema message for the Q subscription and successfully changed its state.

This message is for your information only. No action is required.

ASN7676I

The Q Apply program received a schema message for the Q subscription and successfully changed its state.

This message is for your information only. No action is required.

ASN7677I

ASN7678I

ASN7679I

ASN7680I

ASN7682I

ASN7684E

The Q Apply program had an unrecoverable failure while trying to put a row message for the Q subscription on a temporary spill queue. Q Apply stopped the browser thread.

Check the Q Apply log file or any diagnostic or error messages before this message to determine the cause of the failure. For problems with the spill queue, the diagnostic message lists the WebSphere MQ error code. The spill queue might be full. Fix the cause of the underlying failure and use the startq command to restart message processing on the receive queue.

ASN7687E

The Q Apply program encountered an error or conflict while trying to apply a transaction for this Q subscription in buffered insert mode. When it runs in this mode, Q Apply ignores regular conflict or error handling options, and any SQL error that is encountered by a browser causes Q Apply to stop reading from the affected receive queue. No entry is added to the IBMQREP_EXCEPTIONS table. Refer to the Q Apply diagnostic log file for details about why the error occurred.

Address the problem that was identified in the diagnostic log or restart the Q Apply program with buffered_inserts=n. Then activate the receive queue by using the startq command to move past the exception. No changes are lost. The Q Apply program continues to apply changes to other targets.

ASN7690I

ASN7694I

To ensure that the DB2 EXPORT utility successfully exports all data from the source server, Q Apply must bind the SQL packages for this utility (in @db2ubind.lst) with this option. This option forces DB2 EXPORT to wait until all in-progress transactions that modify the source table are completed before beginning the export.

This message is for your information only. No action is required.

ASN7695E

The program encountered an error while attempting to bind a required package.

Interpret the SQLCODE of the failed bind call. Fix the problem and then activate the Q subscription. You can manually bind the required packages by connecting to the source database and running the following command:

 db2 bind @db2ubind.lst CONCURRENTACCESSRESOLUTION     WAIT FOR OUTCOME COLLECTION ASN. 

Rebinding the utilities package in collection ASN does not affect the use of those utilities by other applications. If you cannot rebind the utilities packages, you might also consider a different load type for the Q subscription.

ASN7697E

A valid replication message comes from the Q Capture program and has C (compact) format. The Q Apply browser thread read a message that is not a valid replication message. The message was left on the queue for diagnostic purposes.

Use the asnqmfmt command to format the first 50 messages on the queue and save the formatted message output. Contact IBM Software Support with the formatted message output and Q Apply diagnostic log file. Use the following syntax for asnqmfmt:

 asnqmfmt receive_queue_name queue_manager_name          -mqmd -hex -l 50 -o filepath 

Where filepath is the location on your system where you want asnqmfmt to save the text file with the formatted messages output, and the name of the file.

Inspect the output to see if the "MsgId" field contains the specified message ID. If not, continue getting the asnqmfmt output of more messages until the output contains the ID in question.

ASN7699I

The Q Apply program's caught-up point with respect to the source is reported in the message text. You can use the value that is appropriate for your source operating system for the Q Capture maxcmtseq parameter to restart Q Capture without the need for a full refresh of target tables in situations where the Q Capture restart information or WebSphere MQ messages are lost.

This message is for your information only. No action is required.

ASN7700I

The program received a message from the Q Capture program to deactivate the Q subscription. A user might have deliberately deactivated the Q subscription, or the Q Capture program might have deactivated it because of an error during processing.

This message is informational only. If the deactivation of this Q subscription was unexpected, check the associated Q Capture log file for reasons for the deactivation.

ASN7701W

The program determines whether the source database uses CURRENTLY COMMITTED locking semantics by default. If the load utility does not disable this behavior, data loss will result if in-flight transactions are in progress at the time a load phase is initiated. See the reason code for possible workarounds. For all situations, the default workaround to prevent potential data loss is to suspend applications from the time the Q subscription is started (when a CAPSTART signal is inserted into the IBMQREP_SIGNAL table) until at least the start of the load phase (when the Q subscription state changes to L or A in the IBMQREP_SUBS table). Possible reason codes are as follows:

0

The DSNUTILS package (z/OS only) that enables LOAD from CURSOR cannot be bound at the source database with WAIT FOR OUTCOME semantics. An application suspend is required.

1

LOAD from CURSOR (Linux, UNIX, and Windows only) has no option to set WAIT FOR OUTCOME behavior. Either perform an application suspend or perform the following steps:

1. Bind the db2cli packages at the source database with the following command:

    db2 bind @db2cli.lst     CONCURRENTACCESSRESOLUTION     WAIT_FOR_OUTCOME COLLECTION ASN 

2. Add the following name-value pair to the db2cli.ini file at the federated database, under the stanza that declares the options for the server definition to which the nickname belongs:

    [data_source_name]  CURRENTPACKAGESET=ASN 

   Where data_source_name is the source database that the db2cli.bnd packages were bound against.

2

The LOAD utility from a local database (Linux, UNIX, and Windows only) has no option to set WAIT FOR OUTCOME behavior. An application suspend is required.

Refer to the details in the "Explanation" section that are associated with the reason code in the message text.

ASN7704W

To improve performance for federated targets, use the following settings:

Oracle targets

Set VARCHAR_NO_TRAILING_BLANKS = Y for the RECVQ column of the IBMQREP_DONEMSG nickname and for the SPILLQ column of the IBMQREP_SPILLEDROW and IBMQREP_SPILLQS nicknames.

Microsoft SQL Server targets

Set BINARY_REP = Y for the MQMSGID column of the IBMQREP_DONEMSG nickname.

Change the settings to the recommended ones if you are observing slow performance from the Q Apply program. The following SQL can be used to add the settings:

Oracle targets

 alter nickname     apply_schema.IBMQREP_DONEMSG     alter COLUMN RECVQ OPTIONS     (ADD VARCHAR_NO_TRAILING_BLANKS 'Y') alter nickname     apply_schema.IBMQREP_SPILLEDROW     alter COLUMN SPILLQ OPTIONS     (ADD VARCHAR_NO_TRAILING_BLANKS 'Y') alter nickname     apply_schema.IBMQREP_SPILLQS     alter COLUMN SPILLQ OPTIONS     (ADD VARCHAR_NO_TRAILING_BLANKS 'Y') 

Microsoft SQL Server targets

 alter nickname     apply_schema.IBMQREP_DONEMSG alter COLUMN MQMSGID     OPTIONS (ADD BINARY_REP 'Y') 

ASN7705I

The Q Apply program was started with the applyupto parameter with a specified timestamp and the NOWAIT optional qualifier. NOWAIT specifies that the browser thread should stop when it encounters an empty receive queue even if the specified timestamp has not been exceeded by any transactions processed so far.

This message is for your information only. No action is required.

ASN7706W

Messages with a size of zero are not expected. The Q Apply browser continues normal processing after not processing this message. Because this message did not have any content, Q Apply could not determine if this was a transaction message or a control message such as a heartbeat message.

Check the Q Capture log for other errors that might have occurred while Q Capture was replicating or publishing messages to WebSphere MQ.

ASN7707E

When the source database uses LSN or UOWID values that are larger than 10 bytes, CCD target tables must allow longer data lengths for the columns that store these values.

Migrate the CCD target table so that the IBMSNAP_COMMITSEQ, IBMSNAP_INTENTSEQ, and IBMSNAP_UOWID columns are correctly defined as specified in the error message.

ASN7708W

The error action that was specified for the Q subscription (value of B in the ERROR_ACTION column of the IBMQREP_TARGETS table) prompts the Q Apply program to direct data for the Q subscription to a spill queue when SQL errors are detected.

Take the following actions:

1. Look for messages in the IBMQREP_APPLYTRACE table or Q Apply log file that indicate which SQL error occurred.
2. Fix the error.
3. Issue the resumesub command to prompt Q Apply to apply data from the spill queue and begin normal processing for the Q subscription.

ASN7709E

The table that is specified for this Q subscription has a referential integrity relationship with one or more other tables. Error action B is not allowed for tables with referential integrity constraints.

Take the following actions:

1. Use the replication administration tools to choose a different error action for the Q subscription.
2. If the Q subscription is disabled, restart the Q subscription.
3. If the browser thread for the receive queue was stopped, use the startq command to restart message processing on the receive queue.

ASN7710E

The Q Apply program tried to create a Q subscription for the table in response to a schema-level Q subscription at the source, but a Q subscription for the table already exists. To create a new Q subscription, the existing Q subscription must be in inactive state so that it can be deleted. The Q Apply program will stop reading from the receive queue.

Follow these steps:

1. Deactivate the existing Q subscription.
2. Use the replication administration tools to delete the existing Q subscription.
3. Issue a startq command to tell Q Apply to start reading from the receive queue.

ASN7711I

The Q Apply program was prompted to automatically create a Q subscription by the Q Capture program because a schema-level subscription was defined at the source for all tables with the same owner. The Q subscription was successfully created.

This message is for your information only. No action is required.

ASN7712I

The Q Apply program successfully replicated the specified DDL operation. The SQL statement might be truncated if it is too long to be printed.

This message is for your information only. No action is required.

ASN7713E

The Q Apply program failed to execute the DDL operation that was replicated from the source. An SQL error is likely to have occurred.

Follow these steps:

1. Look for prior messages that mention SQLSTATE and SQLCODE information.
2. Fix the error.
3. Issue the startq command on the receive queue.

ASN7716W

An ALTER COLUMN SET DATA TYPE operation was performed on the source table. However, the altered source column is part of an SQL expression that is used to generate the contents of a target table column. Q Apply will not alter the target table column or its SQL expression.

Check if the SQL expression is still compatible with the new altered data type of the source column, and take one of these steps:

• If the SQL expression is not correct, delete and recreate the Q subscription with the correct SQL expression. Ensure the new Q subscription specifies an automatic (I) or manual (E) load. Then activate the new Q subscription to prompt a new load of the target table.
• If the SQL expression is compatible, no further action is needed.

ASN7719W

The Q Apply program performed an ALTER TABLE ALTER COLUMN SQL statement that changed the status of an index for the altered column to REBUILD pending. REBUILD-pending state indicates that the affected index or index partition is broken and must be rebuilt from the data. All subsequent DML SQL statements on the affected table will fail until the index is removed from REBUILD-pending state.

You can reset the REBUILD-pending status for an index with any of these operations:

• REBUILD INDEX
• REORG TABLESPACE SORTDATA
• REPAIR SET INDEX with NORBDPEND
• START DATABASE command with ACCESS FORCE

ASN7721I

A command to start the browser thread for the receive queue was received, but the browser thread is already active.

This message is for your information only. No action is required.

ASN7722I

A command to stop the browser thread for the receive queue was received, but the browser thread is already inactive.

This message is for your information only. No action is required.

ASN7723E

The following values are valid for the reason code:

1

The IBMQREP_RECVQUEUES table contains no information about this queue.

2

The program is still in the initialization phase.

Review the reason codes in the explanation, and take the appropriate action:

1

Check the IBMQREP_RECVQUEUES table for the information about the queue. Redefine the Q subscription by using one of the replication administration tools.

2

Reissue the command later.

ASN7727W

The Q Apply program tried to alter the target table to add a new column, but the new column already exists with a default value that is different from the default value at the source. Q Apply added the column to the Q subscription and started replicating changes.

Check the definitions of the source and target tables to determine the default column values. If the mismatch is not intended, alter the source or target table.

ASN7728W

The Q Apply program did not process a replicated DDL operation because the related Q subscription was either not found or inactive.

No action is required if you deleted the Q subscription or expected it to be inactive. Otherwise, follow these steps:

1. Manually alter the target table with the DDL operation that could not be replicated.
2. Look for previous error messages to determine what caused the Q subscription to become inactive, and fix the error.
3. Use the replication administration tools or a CAPSTART signal to activate the Q subscription.

ASN7729W

After a CREATE TABLE operation is detected for a table with a matching schema-level Q subscription, the Q Capture program informs the Q Apply program so that it can automatically create the Q subscription entry in the IBMQREP_TARGETS and IBMQREP_TRG_COLS control tables. If the Q subscription entry already exists in one or both of these control tables, Q Apply deletes the prior Q subscription entry and creates the new entry.

You might want to determine why the Q subscription entry for the same target table already existed in one or both of these control tables. If Q Capture was restarted from a prior point in the log, it might have encountered a log record for the same CREATE TABLE operation and replicated details of this operation to the target.

ASN7730W

After a CREATE TABLE operation for a table with a matching schema-level Q subscription is detected, the Q Capture program informs the Q Apply program so that it can automatically create the Q subscription entry in the IBMQREP_TARGETS table. If the insertion of the Q subscription entry fails, the Q subscription is not created and replication does not start for the source table.

If you want to replicate this source table, use the replication administration tools to create a Q subscription for the table. Make sure that the source and target tables exists or let the replication tools create the target table. Check the SQL code or internal reason code to determine why the insert operation into IBMQREP_TARGETS failed.

ASN7731W

After a CREATE TABLE operation for a table with a matching schema-level Q subscription is detected, the Q Apply program automatically adds Q subscription information about the columns in the target table to the IBMQREP_TRG_COLS control table. However, the insertion of this information into the control table failed. The Q subscription will be deactivated in the IBMQREP_TARGETS table.

Follow these steps:

1. Check the SQL code or internal reason code to determine why the insert into IBMQREP_TRG_COLS failed.
2. Use the replication administration tools to delete and recreate the Q subscription for the table. Make sure that the target table exists or let the replication tools create the target table.

ASN7732E

When a Q subscription specifies that the target table should be loaded with data from the source, either by the Q Apply program (automatic load) or outside of replication (manual load), a spill queue must exist to hold changes from the source table during the loading process. The Q Apply program could not find a spill queue with the name that is specified for the Q subscription, and so it deactivated the Q subscription. This situation can occur if the same model queue name is used for multiple Q Apply programs that share the same queue manager and one Q Apply program deletes the spill queue after using it.

Model queue names can be specified in two ways:

• At the Q subscription level (the names are stored in the MODELQ column of each Q Apply program's IBMQREP_TARGETS table).
• At the Q Apply instance level by using the dftmodelq initialization parameter.

When multiple Q Apply programs use the same queue manager, all model queue names that are specified through either of these methods must be unique.

Check to see if the specified spill queue was deleted. If multiple Q Apply programs share the same queue manager, ensure that all model queue names are unique. After you change the spill queue name, activate the Q subscription.

ASN7733W

The Q Apply program did not process a replicated DDL operation because the object that was created at the source and for which the DDL was replicated already exists at the target.

No action is required unless the object at the target does not match the object definition at the source. In that case, manually alter the object to match the source definition.

ASN7734W

The Q Apply program did not process a replicated DDL operation because the object that was to be dropped was not found.

No action is required if the object was intentionally dropped. Otherwise, look for prior messages to determine what caused the object to be missing.

ASN7735E

You cannot specify autostop=Y when the value of the term parameter is N (No). You also cannot specify term=N when the saved value of autostop in the IBMQREP_APPLYPARMS table is Y.

Restart the Q Apply program while specifying either the autostop parameter or the term=N parameter. Update the value of autostop in the IBMQREP_APPLYPARMS table if necessary.

ASN7737E

The model queue that is associated with the Q subscription is not valid or was defined incorrectly on WebSphere MQ. The Q Apply program could not activate the Q subscription. Model queues can be specified in the MODELQ column of the IBMQREP_TARGETS table (Q subscription level) or with the dftmodelq initialization parameter (Q Apply instance level) The following values are valid for the reason code:

0

The model queue name that was specified does not exist in WebSphere MQ.

1

The model queue was not defined on WebSphere MQ as a permanent dynamic type of queue.

Review the reason codes in the explanation, and take the appropriate action:

0

Define the model queue on WebSphere MQ and activate the Q subscription.

1

Change the model queue definition on WebSphere MQ to include permanent dynamic type by using the DEFTYPE (PERMDYN) keywords, then activate the Q subscription.

ASN7740E

The specified table-level Q subscription is based on a schema-level Q subscription that is defined at the source database or subsystem. The Q Apply program encountered errors while trying to activate this table-level Q subscription. Further changes will be ignored for this Q subscription. The following values are valid for the reason code:

0

The value of the STATE column in the IBMQREP_TARGETS control table is not I or U.

1

The target is a nickname. Nickname targets are not supported for Q subscriptions that are created based on schema-level Q subscriptions.

2

The target table does not have a unique index or primary key that corresponds to the replication key that was chosen by Q Capture and Q Apply and the attempt to create such a unique index failed.

For reason codes 0 and 1, if you want to replicate this source table, use the replication administration tools to create a new Q subscription for the table. Make sure that the source and target tables exist or let the replication tools create the target table. For reason code 2, look at the Q Apply log file or IBMQREP_APPLYTRACE table for messages that might explain the reason that the unique index could not be created, try to correct the problem, and then use the replication administration tools to create a new Q subscription for the table.

ASN7741I

Q Apply successfully created a unique index on the target table that is based on the replication key of the Q subscription. For a Q subscription that is based on a schema-level subscription, if the target table is missing a unique index or primary key that matches the replication key that was chosen by Q Capture, then Q Apply creates a unique index for the columns of the replication key before it activates the Q subscription.

This message is for your information only. No action is required.

ASN7742E

Databases with the DB2 pureScale Feature use 16-byte log sequence numbers (LSN) to record the number of each pureScale member. If the source database uses the DB2 pureScale Feature, you can continue to use stored procedure targets if the following conditions are met:

• You change the stored procedure target to use the VARCHAR(16) data type for the SRC_COMMIT_LSN parameter.
• The Q Capture compatibility parameter is set to 0907. In this case, Q Capture continues to use 10-byte LSNs and the CHAR(10) data type is supported for the SRC_COMMIT_LSN parameter.

Change the stored procedure target to use the VARCHAR(16) data type for the SRC_COMMIT_LSN parameter, or change the value for compatibility to 0907.

ASN7748W

The Q Apply program performed the DDL operation that was replicated from the source, but a SQL warning was reported. The program continues to process the receive queue.

Review the reported SQLSTATE and SQLCODE information. To address the SQL warning, perform any corrective steps that are required or suggested in the message or documentation.

ASN7749W

The event thread failed with an unexpected SQL code. The generated events for this interval are not inserted into the IBMQREP_APPEVENTS table. The program tries again at the next interval. This error does not cause the program to terminate.

If this SQL code indicates a temporary error, then no action is required. Otherwise, take action as indicated for the SQL error.

ASN7750W

The TCP/IP connection to the event server failed. The generated EIF messages for this interval are not sent, and the program tries again at the next interval. This error does not cause the program to terminate.

Review the most recently issued ASN0686W, ASN0687W, ASN0688W, or ASN0689W messages to determine the cause of the error.

ASN7753I

The Q Apply program created a separate thread for generating events that are defined in the IBMQREP_APPEVTDEFS table. You can direct events to the console, IBMQREP_APPEVENTS table, and Event Interface Facility (EIF) servers. The EIF servers can be specified by using two different mechanisms:

• The eif_conn1 and eif_conn2 parameters of the asnqapp command
• The eif_conn1 and eif_conn2 columns of the IBMQREP_APPLYPARMS table

This message is for your information only. No action is required.

ASN7754E

The IBMQREP_APPEVTDEFS table stores definition for events that are generated by Q Apply. The value that was provided for the event definition is not valid. Valid values include AVERAGE_LATENCY, LONG_COMMITTED_TRANS, HEARTBEAT, QUEUE_UP, QUEUE_DOWN, and PIT_CONSISTENCY_LATENCY.

Insert a valid event type and reissue the task.

ASN7755E

The following values are valid for the reason code:

1

When TYPE is AVERAGE_LATENCY, PIT_CONSISTENCY_LATENCY, or HEARTBEAT_INTERVAL, the value of RESET (the reset average latency threshold) must be less than 80 percent of MAX (maximum average latency threshold).

2

When TYPE is AVERAGE_LATENCY, the value of MAX (the maximum average latency threshold) must be greater than or equal to 250 milliseconds.

3

When TYPE is AVERAGE_LATENCY, the value of RESET (the reset average latency threshold) must be greater than or equal to 100 milliseconds.

4

When TYPE is LONG_COMMITTED_TRANS, the value of MAX (the maximum threshold for long-committed transactions) must be greater than or equal to 251 milliseconds.

5

When TYPE is PIT_CONSISTENCY_LATENCY, the value of MAX (the maximum threshold for point-in-time consistency latency) must be greater than or equal to 1500 milliseconds.

6

When TYPE is PIT_CONSISTENCY_LATENCY, the value of RESET (the reset threshold for point-in-time consistency latency) must be greater than or equal to 800 milliseconds.

7

For a specific replication group, the average maximum latency threshold (the value of MAX when TYPE is AVERAGE_LATENCY) must be less than the long committed transaction latency threshold (the value of MAX when TYPE is LONG_COMMITTED_TRANS). All of the event types for a replication group have identical values for WORKLOADNAME and QMAPNAME.

8

The valid values of EIF_WORKLOADTYPE are Active/Standby and Active/Query.

9

When EIF is Y in the IBMQREP_APPEVTDEFS table, you must provide both the EIF_CONN1 and EIF_CONN2 parameters when you start the Q Apply program.

11

The valid values of the EIF, TABLE and CONSOLE column are N and Y.

12

The value of the CONSOLE column must be N when the value of the TYPE column is neither AVERAGE_LATENCY nor PIT_CONSISTENCY_LATENCY.

13

The value of the EIF column must be N when the value of the TYPE column is PIT_CONSISTENCY_LATENCY.

14

The value of the EIF column must be Y and the TABLE and CONSOLE columns must be N when the value of the TYPE column is HEARTBEAT.

15

When TYPE is LONG_COMMITTED_TRANS, the column value of RESET must be NULL.

16

When TYPE is either QUEUE_UP, QUEUE_DOWN, or HEARTBEAT, the value of RESET and MAX must be NULL.

Verify that the information that you entered is correct, and reissue the task.

ASN7756I

The QUEUE_DOWN event specifies that Q Apply has stopped processing messages on a receive queue. Before the event is generated, the event thread waits until all browser threads have stopped.

This message is for your information only. No action is required.

ASN7757E

If the value of the EIF column in the IBMQREP_APPLYEVTDEFS table is Y, connection information must be specified for either a primary or backup event server. These servers are the destination for generated EIF messages. When Q Apply started, it tried to connect to an event server but was unsuccessful. The following values are valid for the reason code:

1

A TCP/IP GetAddrInfo socket call failed.

2

A TCP/IP create socket call failed.

3

A TCP/IP SetSockOpt socket call failed.

4

A TCP/IP connect socket call failed.

5

A TCP/IP send socket call failed.

If you do not need to generate EIF events, change the value of EIF to N and restart the Q Apply program. Otherwise, take one of the following actions depending on the reason code and then restart Q Apply:

1

Make sure that the EIF_CONN1 and EIF_CONN2 columns in the IBMQREP_APPLYPARMS table specify valid host names or IP addresses, service names, or ports. If the host name is correct, then TCP/IP is unable to resolve the host name to an IP address. Make changes that are needed to allow for proper resolution of host name to IP address. If the changes have been made to the name server or local host table, refresh the resolver.

2

Review the most recently issued ASN0686W message to determine the cause of the error.

3

Review the most recently issued ASN0687W message to determine the cause of the error.

4

Review the most recently issued ASN0688W message to determine the cause of the error.

5

Review the most recently issued ASN0689W message to determine the cause of the error.

ASN7758W

If the value of the EIF column in the IBMQREP_APPLYEVTDEFS table is Y, connection information must be specified for either a primary or backup event server. These servers are the destination for generated EIF messages. The existing connection to the event servers was lost. Q Apply will try to reconnect.

Make sure that the TCP/IP protocol is working on the specified event servers.

ASN7759I

Q Apply connects to a primary or backup event server to send EIF messages.

This message is for your information only. No action is required.

ASN7761E

Send queues are said to be parallel when multiple send queues that each use a different transmission queue all route to the same receive queue. When a Q Capture program uses parallel send queues, the replication queue map option parallel_sendqs must be set to y (yes) to handle messages that do not arrive in the receive queue in dense message order.

Use one of the replication administration tools to change the value of the replication queue map option parallel_sendqs to y and then restart message processing on the receive queue.

ASN7762E

When a receive queue is running with the queue map option parallel_sendqs=y, the Q Apply instance-level parameter prune_method must be set to 2.

Restart the Q Apply program with prune_method=2, and restart message processing on the receive queue.

ASN7763I

The event definition was updated for a particular event type in the workload of the queue map. The reinitq command prompts Q Apply to begin using the updated definition.

This message is for your information only. No action is required.

ASN7764W

The following values are valid for the reason code:

1

When TYPE is either AVERAGE_LATENCY or PIT_CONSISTENCY_LATENCY, the value of RESET (the reset average latency threshold) must be less than 80 percent of MAX (maximum average latency threshold).

2

When TYPE is AVERAGE_LATENCY, the value of MAX (the maximum average latency threshold) must be greater than or equal to 250 milliseconds.

3

When TYPE is AVERAGE_LATENCY, the value of RESET (the reset average latency threshold) must be greater than or equal to 100 milliseconds.

4

When TYPE is LONG_COMMITTED_TRANS, the value of MAX (the maximum threshold for long-committed transactions) must be greater than or equal to 251 milliseconds.

5

When TYPE is PIT_CONSISTENCY_LATENCY, the value of MAX (the maximum threshold for point-in-time consistency latency) must be greater than or equal to 1500 milliseconds.

6

When TYPE is PIT_CONSISTENCY_LATENCY, the value of RESET (the reset threshold for point-in-time consistency latency) must be greater than or equal to 800 milliseconds.

7

For a specific replication group, the average maximum latency threshold (the value of MAX when TYPE is AVERAGE_LATENCY) must be less than the long committed transaction latency threshold (the value of MAX when TYPE is LONG_COMMITTED_TRANS). All of the event types for a replication group have identical WORKLOADNAME and QMAPNAME.

11

The valid values of the EIF, TABLE, and CONSOLE columns are N and Y.

12

The value of the CONSOLE column must be N when the value of the TYPE column is neither AVERAGE_LATENCY nor PIT_CONSISTENCY_LATENCY.

13

The value of the EIF column must be N when the value of the TYPE column is PIT_CONSISTENCY_LATENCY.

14

The value of the EIF column must be Y when the value of the TYPE column is HEARTBEAT.

15

When the value of the TYPE column is LONG_COMMITTED_TRANS, the value of the RESET column must be NULL.

16

When TYPE is either QUEUE_UP, QUEUE_DOWN, or HEARTBEAT, the value of RESET and MAX must be NULL.

17

The valid TYPE values include AVERAGE_LATENCY, LONG_COMMITTED_TRANS, HEARTBEAT, QUEUE_UP, QUEUE_DOWN, and PIT_CONSISTENCY_LATENCY.

1. Verify that the information that you entered is correct. If not redo the update of the IBMQREP_APPEVTDEFS table.
2. Issue the reinitq command for the receive queue that is specified in the queue map to prompt Q Apply to begin using the updated definitions.

ASN7765W

A reinitq command was issued to prompt the Q Apply program to begin using updated event definitions for the receive queue, but the definitions that were updated in the IBMQREP_APPEVTDEFS table were the same as the existing values.

If you want to change the related event definitions from the current values, follow these steps:

1. Redo the update of the IBMQREP_APPEVTDEFS table, making sure the new values are included.
2. Issue the reinitq command for the receive queue that is specified in the queue map to prompt Q Apply to begin using the updated definitions.

ASN7766E

The target table is a system period temporal table or bitemporal table. To be able to replicate the system period columns correctly and to disable history recording, Q Apply attempted to call the system stored procedure SYSPROC.SET_MAINT_MODE_RECORD_NO_TEMPORALHISTORY. However Q Apply encountered a failure while invoking the system stored procedure.

• Check the Q Apply diagnostic log file or IBMQREP_APPLYTRACE table for any prior error messages that might indicate the underlying cause of the failure.
• Make sure that the target database is at the right release or level that supports the system stored procedure. On z/OS, you must install APAR PM31315 at the target. On Linux, UNIX, and Windows, the target must be at DB2 Version 10.1 Fix Pack 2.
• Make sure that the required privileges are granted to the user ID that runs Q Apply so that it can access and execute the system stored procedure.

ASN7769W

The qmapeventdefs command displays the event definitions that are currently in memory for all of the workloads that are associated with a particular queue map. However, the queue map that was specified with the command does not exist in the in-memory definitions. The queue map name might have been specified incorrectly, or the IBMQREP_APPEVTDEFS table might have been updated after Q Apply was started.

Take one of the following actions before reissuing the qmapeventdefs command:

• Check whether the queue map name was specified correctly.
• If the IBMQREP_APPEVTDEFS table was updated after Q Apply started, use the reinitq command to refresh in-memory event definitions.

ASN7770E

The value of the EVENT_GEN column in the IBMQREP_APPLYPARMS table is Y. Based on the fetched event definitions from the IBMQREP_APPEVTDEFS table, no event will be issued because of one of the following reasons as denoted by the reason code:

1

The value of the column QMAPNAME in the IBMQREP_APPEVTDEFS table does not match any value of the column REPQMAPNAME in the IBMQREP_RECVQUEUES table.

2

The values of column EIF, CONSOLE, and TABLE are N for all the fetched rows from the IBMQREP_APPEVTDEFS table.

If event generation is necessary, update the IBMQREP_APPEVTDEFS table by inserting a correct queue map name in the QMAPNAME column and changing the values of the EIF, COSOLE and/or TABLE columns to Y; otherwise, update the IBMQREP_APPLYPARMS table by setting EVENT_GEN to N. Then, restart Q Apply.

ASN7771I

The Q Apply program received an mcgsynchon or mcgsynchoff command. The Q Apply browser thread was restarted after turning synchronization on or off for the consistency group that uses the specified replication queue map.

This message is for your information. No action is required.

ASN7772I

The Q Apply program received an mcgsynchon or mcgsynchoff command for turning synchronization on or off for this consistency group. However, the command was ignored because the consistency group was already in the desired state.

This message is for your information. No action is required.

ASN7773E

The following values are valid for the reason code:

0

The program is still in the initialization phase.

1

The IBMQREP_RECVQUEUES table contains no information about this queue or queue map.

2

The IBMQREP_RECVQUEUES table contains no information about the multiple consistency group to which this queue map and queue belong.

3

The ASN.IBMQREP_MCGPARMS table contains no information about this multiple consistency group.

4

The ASN.IBMQREP_MCGSYNC table contains no information about this queue map or multiple consistency group.

5

The ASN.IBMQREP_MCGPARMS table entry for this multiple consistency group has incorrect values.

6

The ASN.IBMQREP_MCGSYNC table entry for this queue map or multiple consistency group has incorrect values.

Review the reason codes in the explanation, and take the appropriate action:

0

Reissue the command after the Q Apply program has fully started.

1-6

Use the replication administration tools to update the receive queue, replication queue map, multiple consistency group or all of these objects to ensure that the specified queue, queue map and multiple consistency group are known to replication, and have been set up with correct parameters. Then reissue the failed command.

ASN7774E

Neither the ASN.IBMQREP_MCGSYNC table nor the or ASN.IBMQREP_MCGPARMS table contain information about the replication queue map (consistency group) to which the receive queue belongs, or about the multiple consistency group to which the consistency group belongs.

Use the replication administration tools to update the receive queue, replication queue map, multiple consistency group, or all of these to ensure that the specified queue, queue map, and multiple consistency group are known to replication.

ASN7775W

The consistency group that is associated with the specified queue map is part of a multiple consistency group, but it is not actively synchronizing with other consistency groups. This situation might be the result of a prior mcgsyncoff command.

No action is required if the mcgsyncoff command was issued and active synchronization is not desired with other consistency groups. To resume active synchronization, issue the mcgsyncon command.

ASN7776E

The Q Apply browser thread failed to start because the ASN.IBMQREP_MCGPARMS table or ASN.IBMQREP_MCGSYNC table has an incorrect value in the specified column.

Correct the specified column value and then issue the startq command to restart the Q Apply browser thread.

ASN7777W

The value in the specified column is outside of the recommended range for optimal results from Q Replication.

Update the column to a value that is within the recommended range.

ASN7778I

The Q Apply program received a purgeq command and is removing all messages from the specified receive queue. When the purge operation completes successfully, Q Apply will issue the ASN7779I informational message

This message is for your information. No action is required if Q Apply issues the ASN7779I informational message.

ASN7779I

The Q Apply program successfully removed all messages from the specified receive queue as a result of a purgeq command.

This message is for your information. No action is required.

ASN7780E

The receive queue that was specified with the purgeq command could not be completely purged because of an unexpected error. Some messages might have been removed from the receive queue as a result of the incomplete purge operation.

Look for any prior ASNxxxxE error messages, ASNxxxxD diagnostic messages, or both to determine the cause of the failure. If possible, correct the underlying cause. Reissue the purgeq command to complete the purgeq operation.

ASN7781E

The following values are valid for the reason code:

0

Another purge operation for this queue was already under way when the purgeq command was received.

1

The IBMQREP_RECVQUEUES table does not contain any information about the specified receive queue or replication queue map.

2

The Q Apply program was still starting when the purgeq command was received.

3

The PURGEQ AFTER MCGSYNC command was ignored because synchronization is not active for the consistency group that uses the specified replication queue map.

Review the reason codes in the explanation, and take the appropriate action:

0

No action required.

1

Use the replication administration tools to update the Q subscription, replication queue map, or both to ensure that the specified queue is known to replication, and then reissue the purgeq command.

2

Reissue the purgeq command after Q Apply has fully started.

3

Take one of the following actions:

• Reissue the purgeq command without the AFTER MCGSYNC parameter if the consistency group is not participating in synchronization with the multiple consistency group.
• If the consistency group should be synchronized with other members of the multiple consistency group, check your setup and reissue the purgeq command with correct parameters after the multiple consistency group is active and Q Apply has fully started.

ASN7782I

When the Q Apply program receives a purgeq command, it stops the receive queue before it purges messages. The specified receive queue is already inactive but the purge operation will be performed.

This message is for your information. No action is required.

ASN7787E

When you use the Q Apply program to replicate natively to Oracle targets, peer-to-peer or bidirectional Q subscriptions are not supported.

Define a unidirectional Q subscription for the table.

ASN7788E

When you use the Q Apply program to replicate natively to Oracle, stored procedure targets are not supported.

Redefine the Q subscription to use a regular table as a target.

ASN7789W

The Q Apply program's call to DSNRLI RRSAF SET_REPLICATION failed. Q Apply at ARCH_LEVEL 1021 requires DB2 APARs PM90970 and PM94353 for SET_REPLICATION. The return code is the DB2 for z/OS code.

If you are running Q Apply with DB2 V10 you must have DB2 V10 PTFs for APAR PM90970 and APAR PM94353 (PTF UK98030). The PTF for APAR PM90970 must be applied to all members of a DB2 V10 data-sharing group before you apply the PTF for APAR PM94353 and exploiting RREPL. Note: You must follow the ++HOLD actions for APAR PM94353 and reassemble the DSNTIJUZ job to pick up changes to DSN3DIR1.

ASN7790E

Q Apply will follow the queue error action. If the target table space is set with ACCESS(RREPL), the Q Apply program must be APF authorized to register itself as a replication program with DB2.

Check the access mode of the target table space to see if the Q Apply program has write access. Check whether the ASN7789I message was issued.

ASN7791I

In response to an ADD_REPL_KEY_COL signal, the Q Apply program tried to alter the IBMQREP_TRG_COLS table to add a column to the replication key. However, the column already exists in IBMQREP_TRG_COLS with a value of Y for IS_KEY. The Q Apply program will ignore this action and continue replicating changes.

This message is for your information. No action is required.

ASN7792W

When loading a target table, Q Apply temporarily drops RI constraints on the table and restores them after the table is loaded. If child tables are also being loaded, RI constraints cannot be restored until these tables are loaded and the CHECK DATA utility runs. In this case both parent and child tables were dummy loaded at the source and the dummy load was replicated to the target.

Wait for the CHECK DATA utility to complete on all related tables.

ASN7793I

The Q Apply program processed the ADD_REPL_KEY_COL or REDEFINE_REPL_KEY message successfully. The column is now included in the replication key for the Q subscription. Any target columns that are populated by an expression that uses the specified source column are also added to the replication key.

This message is for your information. No action is required.

ASN7797I

The Q Apply program tried to drop a column at the target table because the column was dropped from the source table and was part of a Q subscription. However, the column does not exist at the target.

This message is for your information. No action is required.

ASN7798I

The Q Apply program successfully dropped the column after it was dropped from the source table and removed from the Q subscription.

This message is for your information. No action is required.

ASN7799I

The Q Apply program was started with multi_row_insert=y but Q Apply detected that the Q subscription does not satisfy the multirow insert conditions. The following values are valid for the reason code:

0

The target database is not on z/OS.

1

The source table includes LOB or XML columns that are part of the Q subscription.

2

The target is a stored procedure.

3

The target table is a system period temporal table or bitemporal table.

4

The Q subscription is for peer-to-peer replication.

5

Internal memory allocation is not enough for a multi-row insert operation to complete.

6

In the Q subscription, key columns are not defined with expressions but non-key columns are defined with expressions.

7

The source table is a self-referencing table.

This message is for your information only, and no action is required.

ASN7802I

The reinitq command was issued successfully to increase the memory limit for multirow inserts for Q Apply agent threads for this receive queue (MRI_MEMORY_LIMIT in the IBMQREP_RECVQUEUES table).

This message is for your information only. No action is required.

ASN7803I

The reinitq command was issued successfully to increase the value of the MRI_MEMORY_LIMIT parameter for agent threads for this receive queue. The memory allocation is now large enough to use multirow inserts for this Q subscription.

This message is for your information only. No action is required.

ASN7804E

The Q Capture program received ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal to modify the replication key at the source and sent a message to the Q Apply program. The Q Apply program tried to add the column to the replication key at the target but could not do so because of an SQL error.

1. Correct the problem that is identified by the SQLCODE.
2. Start the Q subscription if the ERROR_ACTION is D. Otherwise, start the receive queue.

ASN7805E

The Q Capture program sends a DROP_REPL_COL message to Q Apply when it detects that a subscribed column was dropped from the source table. However, Q Apply cannot drop the column from the target table and the Q subscription because the target is a stored procedure.

1. Use SQL to remove the dropped column from the Q subscription by modifying the stored procedure definition that is stored in the TARGET_COLNAME column of the IBMQREP_TRG_COLS table.
2. Start the receive queue.
3. Start the Q subscription.

ASN7806E

An ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal was issued to the Q Capture program to modify the replication key for the Q subscription at the source. The Q Apply program tried to add the column to the replication key at the target, but the column is not part of the Q subscription at the target.

1. Redefine the Q subscription to include the new column and include the column as part of the replication key if desired.
2. Start the receive queue.
3. Start the Q subscription.

ASN7807E

The Q Capture program detected that a column was dropped from the source table. The Q Apply program tried to drop the column from the target table but could not do so because of an SQL error.

1. Correct the problem that is identified by the SQLCODE.
2. Start the receive queue.

ASN7808E

The Q Capture program issued a DROP_REPL_COL message for a Q subscription that has a nickname as the target. Because the Q Apply program cannot alter the nickname directly, the DROP_REPL_COL message cannot be processed.

1. Use SQL to remove the column from the Q subscription.
2. Redefine the nickname to remove the column.
3. Drop the column from the target table if desired.
4. Start the receive queue.
5. Start the Q subscription.

ASN7809E

The Q Capture program sends a DROP_REPL_COL message to Q Apply when it detects that a subscribed column was dropped from the source table. However, Q Apply cannot drop the column from the target table and the Q subscription because the column is part of one or more expressions.

1. Use SQL to remove the dropped column from expressions that contain the column, which are stored in the SOURCE_COLNAME column of the IBMQREP_TRG_COLS table.
2. Start the receive queue.

ASN7810E

The Q Capture program detected that a column was dropped from the source table. The Q Apply program tried to drop the column from the target table but could not do so because the column is not part of the Q subscription.

If you no longer need the column in the target table, manually drop the column.

ASN7812W

The MRI_MEMORY_LIMIT parameter sets the memory limit per Q Apply agent thread for performing multirow inserts at the target table. A reinitq command was issued, but the value of the MRI_MEMORY_LIMIT column in the IBMQREP_RECVQUEUES table was the same as the existing value.

If you want to change the memory limit for multirow insert from the current value, change the value of MRI_MEMORY_LIMIT in the IBMQREP_RECVQUEUES table and then reissue the reinitq command for the receive queue.

ASN7813E

The Q Capture program sends a DROP_REPL_COL message to Q Apply when it detects that a subscribed column was dropped from the source table. However, the Q subscription must be active before the replication programs can automatically remove a column from the Q subscription.

1. Use SQL to remove the column from the Q subscription.
2. Drop the column from the target table.
3. Start the Q subscription.

ASN7814E

The Q Apply program could not process the message because of a previous error and either stopped reading from the queue or deactivated the Q subscription.

1. Look for a previous message that indicates an error with the same Q subscription and use the information in the message to correct the error.
2. Start the Q subscription if it was deactivated, or start the receive queue if the browser thread stopped reading from the queue.

ASN7815E

The Q Capture program sends an ADD REPL KEY COL or REDEFINE_REPL_KEY message to Q Apply when it processes the ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal for the Q subscription at the source. However, the Q subscription must be active before the Q Apply program can automatically modify the replication key for the Q subscription.

Start the Q subscription and then reissue the ADD_REPL_KEY_COL or REDEFINE_REPL_KEY signal

ASN7816W

The Q Apply program received a purgeq command and is removing all messages from the specified receive queue. When the purge operation completes successfully, Q Apply will issue the ASN7779I informational message.

If Q Apply terminates before the ASN7779I message is logged, start Q Apply and then reissue the purgeq command to complete the purge operation.

ASN7817E

The Q Apply program started removing messages from the specified receive queue in response to a purgeq command. However, some messages could not be purged.

Reissue the purgeq command to complete the purge.

ASN7818W

The Q Apply program started removing messages from the specified receive queue in response to a purgeq command. However all corresponding messages could not be deleted from the IBMQREP_DONEMSG table because of an error.

Take one of the following steps:

• Look for any prior ASNxxxxE error messages, ASNxxxxD diagnostic messages, or both to determine the cause of the failure. If possible, correct the underlying cause and reissue the purgeq command to complete the purgeq operation.
• If the messages were successfully deleted from the receive queue as indicated by an ASN7779I message in the log, then you can manually delete the entries for that receive queue from the IBMQREP_DONEMSG table to complete the purge operation. Follow these steps:
  1. Manually delete the appropriate rows from the IBMQREP_DONEMSG table.
  2. Start Q Capture.

ASN7819W

The Q Apply program was started with multi_row_insert=y to enable the multirow insert feature when applicable. Q Apply encountered an unexpected error and will no longer use multirow inserts for this Q subscription.

If multirow inserts are not required for the specified Q subscription then no action is required. Otherwise contact IBM support to troubleshoot the cause that is preventing multirow insert operations from being used.

ASN7820E

The Q Apply program could not process the message from Q Capture because of a previous error and either stopped reading from the queue or deactivated the Q subscription.

1. Look for a previous message that indicates an error with the Q subscription and use the information in the message to correct the error.
2. Start the Q subscription if it was deactivated, or start the receive queue if the browser thread stopped reading from the queue.

ASN7827W

If the value of the EIF column in the IBMQREP_APPEVTDEFS table is Y, you must specify connection information for either a primary or backup event server. These servers are the destination for generated EIF messages. When Q Apply started, it tried to connect to an event server but was unsuccessful. The following values are valid for the reason code:

1

A TCP/IP GetAddrInfo socket call failed.

2

A TCP/IP create socket call failed.

3

A TCP/IP SetSockOpt socket call failed.

4

A TCP/IP connect socket call failed.

5

A TCP/IP send socket call failed.

If you do not need to generate EIF events, change the value of EIF to N and restart the Q Apply program. Otherwise, take one of the following actions depending on the reason code and then restart Q Apply:

1

Make sure that the EIF_CONN1 and EIF_CONN2 columns in the IBMQREP_APPLYPARMS table specify valid host names or IP addresses, service names, or ports. If the host name is correct, then TCP/IP is unable to resolve the host name to an IP address. Make any changes that are needed to allow for proper resolution of host name to IP address. If the changes were made to the name server or local host table, refresh the resolver.

2

Review the most recently issued ASN0686W message to determine the cause of the error.

3

Review the most recently issued ASN0687W message to determine the cause of the error.

4

Review the most recently issued ASN0688W message to determine the cause of the error.

5

Review the most recently issued ASN0689W message to determine the cause of the error.

ASN7828W