A Replication Agent sends data one-way to Replication Server. It logs in to the Replication Server, connects as an LTM thread to the Replication Agent User thread of a Replication Server connection, and communicates with Replication Server over that connection. This has the following implications:
A valid user ID, which the Replication Agent uses to log in to the Replication Server, must be defined at the Replication Server.
The Replication Agent user ID must be granted connect source permission in Replication Server. connect source permission allows the Replication Agent to send commands that are valid only on a Replication Agent User thread.
The Replication Agent must record this user ID and associated password.
The Replication Agent must record the server and database portions of the Replication Server connection definition to identify and connect to the correct Replication Agent User thread.
The DSI thread for this connection is not used. Replication Agents do not support sending transactions or other operations back to a primary database.
Adding the with dsi_suspended clause
to the Replication Server create connection command
suspends the DSI thread for the Replication Agent connection.
The user_name and password defined in the Replication Server create connection command must be a valid user ID and password for the primary database represented by the Replication Agent.
The Replication Agent validates that the connection user_name exists in the primary database. However, Replication Server does not know if (or when) a DSI thread will be used. Therefore, the user ID and password must be valid in case the DSI thread is active.
The requirement for a valid primary database user ID
varies by Replication Agent. Some Replication Agents do not require
(nor do they check for) a valid user ID on the Replication Server
connection.
The Replication Server resume connection command initiates activity with the DSI thread of the specified connection. The Replication Agent will not respond to an attempt to connect the DSI thread, since the Replication Agent uses only the Replication Agent User thread. Since Replication Server does not initiate communication with Replication Agent User threads, no activity takes place.
Attempts by Replication Server to communicate with the DSI thread on a Replication Agent connection are recorded as failures in the Replication Server log.
For the interaction between a Replication Agent and a Replication Server, the only interfaces file entry that may be required is one identifying the Replication Server.
The Replication Agent for DB2 UDB for OS/390 requires an interfaces file entry for the Replication Server.
The Sybase Replication Agent (for DB2 Universal Database on UNIX and Windows platforms, Informix, Microsoft SQL Server, and Oracle) does not require an interfaces file entry, as it records the Replication Server host name and port number in configuration parameters.
The values of the server and database names are not significant in a Replication Server connection definition for a Replication Agent User thread. However, they must be properly configured in the Replication Agent.
The Replication Agent rs_source_ds and rs_source_db configuration parameters must be configured to match the ds.db values of the Replication Server connection name. If they do not match, the Replication Agent will not find a Replication Server connection to send information to.
Since Replication Server never attempts to contact the Replication Agent User thread of a connection, if the connection is only for a Replication Agent User thread, there is no need for the server name portion of the connection to exist in an interfaces file. The database name portion of the Replication Server connection is also arbitrary, if the connection is only for a Replication Agent User thread.
Any unique combination of two strings (namex.namey) can be used to identify a Replication Agent User thread connection. For convenience, you should choose names that have some meaning in your particular environment (for example, host.db2_subsystem, host.oracle_sid, and so on).
