In passive mode, the Source Server acts as a stand-by server, waiting to activate in case of a failover. When a passive server is started, it computes the startup JNL_SEQNO. When a passive server is activated, it establishes a connection with the specified Receiver Server, and operates as a Source Server in active mode.

The sequence number from which the Source Server starts transmitting updates to the secondary is jointly determined by the Source Server and Receiver Server.

The Source Server automatically locates the journal update records from either the Journal Pool or the journal file, and sends them to the Receiver Server on the secondary.

GT.M provides the functionality for an application to provide continuous availability even as the application is periodically upgraded. This capability is called rolling upgrades. Since an application upgrade may involve a database schema change, GT.M provides for a filter to be inserted into the replication stream. This filter will either upgrade the schema if the secondary is running the newer version of the application software, or downgrade it if the primary is running the newer version.

If you specify a filter, the Source Server will send the replication stream to the filter, and the output of the filter, to the Receiver Server on the secondary system. Refer to the "Filters" section for more information.

The Source Server automatically handles buffer overflows in the Journal Pool and failure in the communication channel. When the next update to be transmitted is not in the Journal Pool, the Source Server automatically retrieves the record and subsequent records from the journal files until it catches up. The Journal Pool can overflow when the secondary is down. Once it catches up, the Source Server sends records from the Journal Pool. When journal files are switched, the new journal files have a back pointer to the old journal files so that the Source Server can find needed update records.

Since the Source Server searches through old journal files when bringing a secondary back in synchronization, it is not safe to delete or move old files until the transactions are permanently on the secondary system (i.e., the transactions in the journal files should be on the secondary database and backed up). Also, assure that the Source Server will never attempt to access them again. Refer to the "Switching Journal Files" section for the MUPIP commands to perform journal file link changes.

If the connection is broken (e.g., due to secondary system failure) the Source Server periodically tries to reestablish a connection with the Receiver Server. Once it establishes this connection, the Source Server waits for a restart message from the other end and sends journal records from the point requested by the Receiver Server. The restart message sent by the Receiver Server contains the restart point and information that instructs the Source Server to either deactivate any currently active filter or maintain the existing filter, if any.

Flow control is implemented between the Source and the Receiver Servers. When the Source Server receives a message to stop sending journal records, it stops until it receives a restart request. When the Source Server restarts, it reads from the Journal Pool and from the journal files, if necessary.

	Note
	GT.M provides an interface for deactivating an active Source Server (i.e., changing an active mode server to passive mode). Refer to "Starting the Source Server" section for more information.

A keep-alive protocol ("heartbeat") between the Source Server and Receiver Server detects problems with the communication channel. Specifically, the Source Server periodically sends a heartbeat message to the Receiver Server. For every message sent, the Source Server expects a heartbeat response from the Receiver Server within a specified period. If a heartbeat response does not arrive within that period, the Source Server starts a recovery process in a manner similar to that triggered by a communications failure.

The Source Server logs its actions and errors in a log file. It also periodically logs statistics such as the current backlog, the number of journal records sent since the last log, the rate of transmission, the starting and current JNL_SEQNO, and the path of the filter program, if any.

It is possible to determine whether the Source Server is running by using a GT.M interface that reports the system status. Refer to "Starting the Source Server" for more information. The server can be restarted if it is no longer running due to forced termination. In this instance, the Source Server establishes a connection with a specified Receiver Server without performing initial steps of region startup, Journal Pool creation, and computation of the startup JNL_SEQNO.

	Note
	The Source Server must have previously created the Journal Pool in order to restart.