The Receiver Server receives the journal records sent by the Source Server from the primary and puts them in the Receive Pool for future processing. This shared buffer is analogous to the Source Server's Journal Pool. An Update Process then updates the database from the Receive Pool.

The Receiver and Source Servers treat initial and post-recovery startup in a similar manner. Upon startup, the Receiver Server creates the Receive Pool, starts the Update Process, and waits until the Update Process informs it of the reference point for starting (or restarting) the transmission of journal records from the primary. Then, the Receiver Server waits for a connection request from the primary. Once it receives the request, the Receiver Server sends a request to the Source Server to start or restart transmitting journal records from the specified reference point. The Receiver Server tags the restart message with a flag. A startup option controls the value of this flag. Based on the startup option, the flag value is set to indicate whether the Source Server should stop any active filter or maintain the existing status of the filter.

The Receiver Server waits to receive journal records. If the connection breaks during this time, the Receiver Server waits for a connection request from the primary system. The Receiver Server puts the records in the Receive Pool in the order they are received. The TCP/IP connection maintains the order of the journal records in transmission.

If any application filter is active, the Receiver Server collects the received journal records into groups of records that belong to the same transaction, and inputs each group into the filter. Then, the Receiver Server puts the filter output into the Receive Pool.

The Receiver Server treats the Receive Pool like a circular buffer. When the Receiver Server notices that the space occupied by unprocessed input in the Receive Pool is about to exceed a threshold, it sends a message to the Source Server to stop sending journal records. When the Receiver Server detects that the Receive Pool has adequate free space, it sends the Source Server a message to restart the process of sending journal records from the point that the process stopped.

The Receiver Server logs its actions, errors, statistics, starting and current JNL_SEQNO, and the path of the filter program, if any, in a log file. The Receiver Server participates in the keep-alive protocol by responding to every heartbeat message it receives from the Source Server with another heartbeat message. The heartbeat message from the Receiver Server contains the last JNL_SEQNO the Update Process successfully processed. The Receiver Server also periodically checks to see if the Update Process is running. If the Update Process is not running, the Receiver Server logs an error message. It continues logging error messages until an Update Process starts. The Receiver Server will not automatically start an Update Process.

GT.M provides an interface for determining whether the Receiver Server is running. Use this interface in a manner similar to the Source Server.

If the Receive Pool already exists, the Receiver Server skips the step of creating the Receive Pool, and starts a new Update Process if one is not already running. Then it sets the restart flag in the Receive Pool that informs the Update Process to restart operations. The Receiver Server then continues operations in a manner similar to initial startup.