Package all database updates into transactions that are consistent at the level of the application logic using the GT.M TSTART and TCOMMIT commands. For information on commands, refer to the "Commands" chapter in the GT.M Programmer's Guide. For any updates not packaged, ensure that the database is logically consistent at the end of every M statement that updates the database; or that there is application logic to check, and restore application-level consistency when the database recovers after a crash.

Ensure that internally driven batch operations store enough information in the database to enable an interrupted batch operation to resume from the last committed transaction. In case of a primary system failure in the middle of a batch process, the secondary system can resume and complete the batch process.

If the application cannot or does not have the ability to restart batch processes from information in the database, copy a snapshot of the database to the secondary system just before the batch starts. In case of primary failure, restore the secondary to the beginning of the batch operations, and restart the batch operation from the beginning on the secondary.

Ensure that externally driven batch processing also has the ability to resume. The external file driving the batch operation must be available on the secondary before starting the batch operation on the primary. This is required to handle primary system failure during the batch process.

Additional requirements for application architecture are discussed in the "Messaging" section which follows. As previously noted, all processes accessing a replicated database must use the same Global Directory. Do not use M extended references since they can have unpredictable results.