Limitations and known issues for Db2 Data Gate

The following known issues and limitations apply to the Db2 Data Gate service.

• A single Db2 Data Gate instance can have a maximum of one Db2 for z/OS® sources.
• A single Db2 Data Gate instance can have a maximum of one target database ( Db2 or Db2 Warehouse).
• A single Db2 Data Gate instance always runs on same node as Db2 or Db2 Warehouse target database. You cannot dedicate one or more worker nodes to a Db2 Data Gate instance.
• When a table has been selected for an instance and synchronization has been activated, an ALTER TABLE command on the Db2 for z/OS source table will cause the synchronization of this table to stop with an error. To recover from this situation, remove the table from the instance and add it again.
• Columns with a data type of XML or LOB are not supported. Columns of these types will therefore be missing from Db2 Data Gate tables.
• A table cannot be loaded and synchronized if one or more of the following conditions apply:
  • A mask has been defined for the table by means of a CREATE MASK statement.
  • A permission has been granted on a table column by means of a CREATE PERMISSION statement.
  • One or more table columns have a security label.
  • One or more table columns use a field procedure (FIELDPROC).
  Important: If you try to load and synchronize a table that satisfies one of these conditions, the Db2 Data Gate server on Cloud Pak for Data stops and then restarts automatically after an outage period of five to ten minutes. Hence you need not do anything to recover from the server shutdown.
• You can load a maximum of 100 synchronization-enabled tables concurrently.
• Currently, the Db2 Data Gate synchronization function does not support an automatic failover in high-availability environments. That is, synchronization will not continue after a failover.
• Indexes and access control lists defined on the Db2 for z/OS source tables will not be inherited by the Db2 Data Gate target tables.
• A Red Hat® OpenShift® route can only expose a single hostname with a fixed port of 443 for external access. Therefore, when you provision your first Db2 Data Gate instance, the route port is 443 by default. If you want to provision more than one instance to connect to the same z/OS LPAR, you must specify a different port, for example 44443. This means that on the z/OS side, you must configure the Policy Agent rule accordingly. That is, the rule needs to specify the second host name and port specified when the Db2 Data Gate instance is provisioned. On the Linux® side, you must configure the firewall iptable so that it forwards requests from the port for each Db2 Data Gate instance to the Red Hat OpenShift route port (port 443). For example:

  iptables -t nat -A PREROUTING -p tcp --dport data-gate-instance-port -j REDIRECT --to-port 443

• You cannot load and synchronize tables if the name of the table schema begins with the string SYS, as in SYSIBM, SYSA, and so on. The reason is that an alias is created for such tables. This alias includes a schema name and a table name. The schema name is the name of the source table schema, and the table name in the alias is the name of the source table. This limitation is caused by a limitation on alias names in Db2 and Db2 Warehouse databases. See CREATE ALIAS statement.