This section describes the replicate database issues and considerations specific to the IBM DB2 Universal Database on the IBM z/OS platform in a Sybase replication system.
As a replicate data server in a gateway environment, IBM DB2 Universal Database for z/OS interacts with the Mainframe Connect DirectConnect for z/OS Option database gateway, which is responsible for accepting commands from the replicate Replication Server and applying those commands to a replicate IBM DB2 Universal Database.
As a replicate data server in a “gatewayless” environment, IBM DB2 Universal Database for z/OS interacts with Mainframe Connect DirectConnect for DB2 UDB through the AMD2 CICS transaction. AMD2 accepts commands from Replication Server and applies those commands to an IBM DB2 Universal Database. Then, AMD2 retrieves the results from those commands and returns the results to Replication Server.
The gatewayless environment requires a TCP/IP
connection to the mainframe. For more information about gatewayless
connections, see the Mainframe Connect Server Option for IBM IMS
and MVS Installation and Administration Guide.
To apply transactions in a replicate database, Replication Server requires a Maintenance User ID that you specify in the Replication Server create connection command. The Maintenance User ID must be defined to the IBM DB2 Universal Database for z/OS data server and granted authority to apply transactions in the replicate database. The Maintenance User ID must have the following permissions in the replicate IBM DB2 Universal Database:
CREATE TABLE authority to create tables used for Replication Server processing
UPDATE authority to all replicate tables and EXECUTE authority to all replicate stored procedures
The only significant intrusions or impacts to the replicate IBM DB2 Universal Database are the database objects created by the hds_db2_setup_for_replicate.sql script to support Replication Server replicate database operations. This script creates three tables in the replicate database to support Replication Server operations:
RS_INFO, which contains information about the sort order and character set used by the replicate database.
Be sure to confirm that the INSERT statements
for this table (in the hds_db2_setup_for_replicate.sql script)
specify the proper character set and sort order for your data server.
When using Replication Server version 12.5 or later, the replicate database sort order and character set must be recorded in the RS_INFO table. To do so, use the Replication Server rs_get_charset and rs_get_sortorder functions to retrieve the character set and sort order from the RS_INFO table in the replicate database.
RS_LASTCOMMIT, which contains information about replicated transactions applied to the replicate database.
Each row in the RS_LASTCOMMIT table identifies the most recent committed transaction that was distributed to the replicate database from a primary database. Replication Server uses this information to ensure that all transactions are distributed.
The Replication Server rs_get_lastcommit function retrieves information about the last transaction committed in the replicate database. For non-Sybase replicate databases, the rs_get_lastcommit function is replaced in the database-specific function-string class by the query required to access the RS_LASTCOMMIT table in the replicate database.
Replication Server version 12.0 or later must use the RS_LASTCOMMIT table
instead of the LTMLASTCOMMIT table that may have
been installed if Replication Agent for DB2 UDB was installed.
RS_TICKET_HISTORY, which contains the execution results of Replication Server command rs_ticket.The rs_ticket command can be issued for the primary database to measure the amount of time it takes for a command to move from the primary database to the replicate database. You can use this information to monitor Replication Server performance, module heartbeat, replication health, and table-level quiesce. The results of each execution of rs_ticket is stored in a single row of the RS_TICKET_HISTORY table in the replicate database. You can query each row of the RS_TICKET_HISTORY table to obtain results of individual rs_ticket executions, or compare the results from different rows. The data stored in this table is not required to support replication and may be manually truncated.
The RS_TICKET_HISTORY table
is only available in Replication Server release 15.1 and later.
A Replication Server database connection name is made up of two parts: a data server name (server_name) and a database name (db_name).
When using the Mainframe Connect DirectConnect for z/OS Option database gateway, the server_name is the name of the database gateway server, and the db_name is the name of the replicate IBM DB2 Universal Database.
The replicate Replication Server looks for an interfaces file entry for the database gateway server_name specified in the Replication Server database connection. The replicate Replication Server logs in to the replicate data server using the user_name and password specified in the database connection.
You must make an entry in the Replication Server interfaces file to identify the host and port where the Mainframe Connect DirectConnect for z/OS Option database gateway server is listening. The interfaces file entry name must match the server_name portion of the Replication Server database connection.
With a gatewayless connection from Replication Server to DB2 UDB using the MainframeConnect DirectConnect for z/OS Option, the server_name is the mainframe host name, and the db_name is the name of the replicate IBM DB2 Universal Database. The interfaces file entry for the server_name maps to the mainframe IP address and port.
Gatewayless replication to IBM DB2 Universal Database for z/OS requires that you:
Use the Mainframe Connect version 15.0 or later.
Define the rs_get_textptr and rs_writetext function strings using the writetext method. See the Replication Server Reference Manual for more information.
Run the following Replication Server HDS scripts:
hds_clt_xxx_to_db2.sql (class-level translations for the primary database)
hds_clt_ase_to_xxx.sql (execute for each database that you connect to)
hds_db2_funcstrings.sql
hds_db2_udds.sql