General data restrictions for Q Replication and Event Publishing

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

Data encryption restrictions

You can replicate or publish some types of encrypted data:

EDITPROC: DB2® for z/OS® source tables that are defined with an edit routine (EDITPROC) to provide additional data security are supported.
Encrypt scalar function: Column data can be encrypted and decrypted using the encrypt scalar function in DB2 for Linux, UNIX, and Windows. To use this with replication or publishing, the data type must be VARCHAR FOR BIT DATA at the source. This data replicates successfully as long as the source and target use the same code page and the decrypt functions are available. Replication of columns with encrypted data should only be used with servers that support the DECRYPT_BIN or DECRYPT_CHAR function.

FIELDPROC

Q Replication supports columns that are defined on DB2 for z/OS tables with field procedures (FIELDPROC) to transform values.

If possible, you should create the following index on your SYSIBM.SYSFIELDS table to improve performance:

CREATE INDEX "SYSIBM"."FIELDSX"
ON "SYSIBM"."SYSFIELDS"
(TBCREATOR ASC,
TBNAME ASC,
NAME ASC)
USING STOGROUP SYSDEFLT PRIQTY 100 SECQTY 100
CLOSE NO;
COMMIT;

Data type restrictions

Currently, the following data cannot be replicated or published:

Spatial data types
You can replicate BINARY or VARBINARY data types when the source and target are on z/OS. Replication of these data types from a z/OS source to a DB2 for Linux, UNIX, and Windows target or federated target is not supported. BINARY and VARBINARY data types are supported as targets of source expressions only if the source datatype is CHAR, VARCHAR, GRAPHIC, VARGRAPHIC, or ROWID.

You can replicate or publish the following types of data only under certain circumstances:

LONG VARCHAR and LONG VARGRAPHIC

Columns with long variable character (LONG VARCHAR) and long variable graphic (LONG VARGRAPHIC) data types have the following restrictions:

LONG VARCHAR and LONG VARGRAPHIC cannot be replicated from DB2 for Linux, UNIX, and Windows to DB2 for z/OS. Fields in DB2 for z/OS that contain long variable characters have a smaller maximum length than the fields in DB2 for Linux, UNIX, and Windows. Therefore, replication of these types of fields to DB2 for z/OS from DB2 for Linux, UNIX, and Windows might result in truncation.
When you specify DATA CAPTURE CHANGES for a source table when the table is created, any LONG VARCHAR and LONG VARGRAPHIC columns are automatically enabled for replication. If you add LONG VARCHAR columns to the table after you create a Q subscription and the table previously had no LONG columns, you must use the ALTER TABLE statement to enable DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS for the new LONG VARCHAR or LONG VARGRAPHIC columns.

User-defined data types

You can replicate or publish user-defined distinct data types, but not user-defined structured and reference data types. User-defined distinct data types (distinct data types in DB2) are converted to the base data type before they are replicated. If the target table is created when the Q subscription is created, user-defined distinct data types are converted to the base data type in the new target table.

GRAPHIC data type

Columns with the GRAPHIC data type at the source and target might not match when you use the asntdiff utility to check that the source and target tables are the same. DB2 columns with the GRAPHIC data type have blank padding after the graphic data. This padding might be single-byte or double-byte spaces, depending on the code page that the database was created in. This padding potentially can cause data to not match between the source and the target tables, especially if the source and target tables are in different code pages. This padding applies only to GRAPHIC data types and not other graphic data types such as VARGRAPHIC or LONG VARGRAPHIC.

To compare columns with GRAPHIC data types, you must remove the blank padding in the data before you compare the source and target tables by using the DB2 scalar function:

rtrim(column)

This function eliminates the code page differences for single-byte or double-byte spaces and ensures that the asntdiff utility compares the GRAPHIC data in a consistent manner.

TIMESTAMP WITH TIME ZONE

You can replicate the TIMESTAMP WITH TIMEZONE data type that was introduced in DB2 for z/OS Version 10, with some restrictions. Table 1 shows the supported mappings

Table 1. Supported column mappings for TIMESTAMP WITH TIMEZONE data type
		Target column
		TIMESTAMP WITH TIMEZONE	TIMESTAMP WITHOUT TIMEZONE
Source column	TIMESTAMP WITH TIMEZONE	Allowed if source column length is less than or equal to target column length	Not allowed
Source column	TIMESTAMP WITHOUT TIMEZONE	Not allowed.	Allowed

Note: DB2 for Linux, UNIX, and Windows does not support TIMESTAMP WITH TIMEZONE.