IBMQREP_SENDQUEUES table

The IBMQREP_SENDQUEUES table contains information about the IBM® MQ queues that are used by a Q Capture program to send data and informational messages. Each instance of the Q Capture program can work with multiple send queues. Each send queue is uniquely defined in the IBMQREP_SENDQUEUES table.

Server: Q Capture server

Default schema: ASN

Primary key: SENDQ

Unique index: PUBQMAPNAME

Important: Do not alter this table using SQL. Altering this table inappropriately can cause unexpected results and loss of data.

Table 1 provides a brief description of the columns in the IBMQREP_SENDQUEUES table.

Table 1. Columns in the IBMQREP_SENDQUEUES table
Column name	Description
PUBQMAPNAME	Data type: VARCHAR(128); Nullable: No The name of the publishing queue map that includes this send queue. For Q subscriptions, this name must match the value of REPQMAPNAME in the IBMQREP_RECVQUEUES table.
SENDQ	Data type: VARCHAR(48); Nullable: No The unique name for this send queue. The name can stand for the local definition of a remote queue, or for a local queue. The name cannot contain blanks.
RECVQ	Data type: VARCHAR(48); Nullable: Yes The name of the receive queue for this Q subscription. This is a local queue on the Q Apply server. Queue names cannot contain blanks.
DESCRIPTION	Data type: VARCHAR(254); Nullable: Yes A user-supplied description of the publishing queue map that contains this send queue.
MESSAGE_FORMAT	Data type: CHAR(1); Nullable: No, with default The format that is used to encode messages that are put on the send queue. C (default) The Q Capture program encodes transactions from the source database in a compact format that is designed to be read by the Q Apply program. X The Q Capture program encodes transactions from the source database in Extensible Markup Language (XML) format. J The Q Capture program encodes transactions from the source database in Extensible Markup Language (XML) format with an MQRFH2 header. D The Q Capture program encodes transactions from the source database in delimited format.
MSG_CONTENT_TYPE	Data type: CHAR(1); Nullable: No, with default A flag that indicates whether messages put on the queue will contain an entire database transaction or a row operation only. T (default) All rows in a transaction are sent in one MQ message. R Messages contain a single update, insert, or delete operation, and information about the transaction to which it belongs. Multiple rows are never combined in one message.
STATE	Data type: CHAR(1); Nullable: No, with default A flag that is inserted by the Q Capture program to show the status of the send queue. A (default) Active. Transactions are being written to this queue. I Inactive. A severe error was encountered on this queue.
STATE_TIME	Data type: TIMESTAMP; Nullable: No, with default The timestamp in the local time of the Q Capture server of the send queue's last state change. Default: Current® timestamp
STATE_INFO	Data type: CHAR(8); Nullable: Yes The number for the ASN message about the queue state. For details, see the IBMQREP_CAPTRACE table, or the Q Capture diagnostic log.
ERROR_ACTION	Data type: CHAR(1); Nullable: No, with default A flag that tells the Q Capture program what to do when the send queue is no longer accepting messages because of an MQ error, or when an error occurs for an active Q subscription on this queue. S (default) The Q Capture program stops. I This value is deprecated and is treated the same as a value of S. Q The Q Capture program continues to put messages on other send queues but stops putting messages on this queue and sets the state for this queue to inactive (I). Q Capture also leaves the state of all Q subscriptions or publications that specify this queue as active (A). After you fix the send queue error, you must take one of the following actions: Issue a startq command to tell Q Capture to start putting messages on the queue (set its state to active). Stop and start the Q Capture program. Use the Q Capture reinit command to reload all Q subscriptions from the Q Capture control tables.
LOB_TOO_BIG_ACTION	Data type: CHAR(1); Nullable: No, with default A flag that tells the Q Capture program what to do when a single large object (LOB) value would exceed the maximum message size that is allowed for this send queue. Q (default) The Q Capture program follows the error action that is defined for the send queue. E The Q Capture program sends empty LOB values if the data does not fit in a single transaction message. If the substitute value does not fit into a message, Q Capture follows the error action for the queue.
XML_TOO_BIG_ACTION	Data type: CHAR(1); Nullable: No, with default A flag that tells the Q Capture program what to do when a single XML document would exceed the maximum message size allowed for this send queue. Q (default) The Q Capture program follows the error action that is defined for the send queue. E The Q Capture program sends an XML placeholder. If the XML placeholder does not fit into a message, Q Capture follows the error action for the queue.
HEARTBEAT_INTERVAL	Data type: INTEGER; Nullable: No, with default How often, in milliseconds, the Q Capture program sends messages on this queue to tell the Q Apply program or a user application that the Q Capture program is still running when there are no changes to publish. The value must be a multiple of the COMMIT_INTERVAL value, or it will be rounded to the nearest multiple (COMMIT_INTERVAL is set in the IBMQREP_CAPPARMS table). A value of 0 tells the Q Capture program not to send `heartbeat` messages. Default: 60000 For versions before 10.2.1, the value is measured in seconds and the default is 60. For delimited messages (MESSAGE_FORMAT=D), the value of HEARTBEAT_INTERVAL must be 0. Note: The HEARTBEAT_INTERVAL defined in the IBMQREP_SENDQUEUES table is different from the HBINT (heartbeat interval) parameter that you can define for an MQ channel.
MAX_MESSAGE_SIZE	Data type: INTEGER; Nullable: No, with default The maximum size (in kilobytes) of the buffer that is used for sending messages over this send queue. The size of the buffer must not be larger than the MQ maximum message length (MAXMSGL) attribute that is defined for any queues that will contain the message, or all Q subscriptions and publications that use this send queue will be invalidated. Default: 64 KB
APPLY_SERVER	Data type: VARCHAR(18); Nullable: Yes The name of the database where the Q Apply program runs and targets are defined. For z/OS®, this is a location name.
APPLY_ALIAS	Data type: VARCHAR(8); Nullable: Yes The DB2® database alias that corresponds to the Q Apply server that is named in the APPLY_SERVER column.
APPLY_SCHEMA	Data type: VARCHAR(128); Nullable: Yes The schema of the Q Apply program that is applying transactions from this send queue.
MESSAGE_CODEPAGE	Data type: INTEGER; Nullable: Yes The code page that is used to encode messages for Event Publishing.
COLUMN_DELIMITER	Data type: CHAR(1); Nullable: Yes A single character that is used to separate header entries and column data within a delimited message. Default: comma (,)
STRING_DELIMITER	Data type: CHAR(1); Nullable: Yes A single character that is used to surround string data in a delimited message. Default: double quotation mark (")
RECORD_DELIMITER	Data type: CHAR(1); Nullable: Yes A single character that is used to separate change-data records in a delimited message. Default: new line character
DECIMAL_POINT	Data type: CHAR(1); Nullable: Yes A single character that is used to separate the fractional portion of numerical data in a delimited message. Default: period (.)
SENDRAW_IFERROR	Data type: CHAR(1); Nullable: No, with default For Event Publishing: Specifies whether character data is published when the data causes a code page conversion error. An example of invalid character data is an incomplete double-byte character and missing shift-in byte ('0F'x) in a string stored in a Japanese or Korean code page. The following string should have `'830F'` at the end, but does not: `x'0E4481448244'`. N (default) No data is sent for the character field that failed code page conversion. For delimited message format, none of the data from character columns in the row is sent when any single character field in the row fails code page conversion. Instead, all the character columns are sent as null values and an indicator at the start of the row is set to IBM-INVALID-COLUMN-`####`-`@`-NULL, where `####` represents the first column in which the Q Capture program detected invalid data and `@` is either B (before value) or A (after value). All large object (LOB) or XML columns are sent as null values. Y The character data is sent in hex string format. For delimited messages, the identifier field is set to IBM-INVALID-COLUMN-`####`-`@`-HEX, and all the character columns in the row are sent in hex string format. The `####` field represents the first column in which the Q Capture program detected invalid data and `@` is either B (before value) or A (after value). All LOB or XML columns are sent as null values.
NUM_PARALLEL_SENDQS	Data type: SMALLINT; Nullable: No, with default A number that indicates how many send queues the Q Capture program uses to replicate transactions for the replication queue map. The default value is 1. If the number is greater than 1, Q Capture expects the send queues to be defined in the following format: `send_queue_name.suffix` Where `send_queue_name` remains the same for all send queues that are part of the queue map, and `suffix` is an integer with a minimum value of 1. For example, if NUM_PARALLEL_SENDQS is 3, Q Capture would expect the following send queue names: `ASN.SRC_TO_ASN.TGT.DATA.1 ASN.SRC_TO_ASN.TGT.DATA.2 ASN.SRC_TO_ASN.TGT.DATA.3` Important: If the value of the NUM_PARALLEL_SENDQS column is greater than 1, the PARALLEL_SENDQS column in the IBMQREP_RECVQUEUES must be set to Y.
MCGNAME	Data type: VARCHAR(64); Nullable: Yes, with default The name of the multiple consistency group that this send queue is part of. For IBM GDPS® active/active continuous availability, the value is the GDPS active/standby workload name. Default: NULL
SEND_RI_COLUMN_VALUES	Data type: CHAR(1); Nullable: Yes, with default A flag that specifies whether the Q Capture program sends foreign key data values for child tables even if the data in the columns did not change. Sending this data enables the Q Apply program to serialize transactions only when an actual referential integrity dependency is in place, based on data values. N (default) Q Capture does not send foreign key data values. Y Q Capture sends foreign key data values for columns that are associated with an RI constraint. Note: If you specify SEND_RI_COLUMN_VALUES=Y, you must also specify RI_DEPENDENCY_BY_VALUES=Y in the IBMQREP_RECVQUEUES table to enable Q Apply to use foreign key data values for dependency checking.