Chapter 11. Advanced Copy Services 537
If a relationship (or set of relationships) is inconsistent and an attempt is made to start an 
application by using the data in the secondaries, the following outcomes are possible:
/SM590000The application might decide that the data is corrupted and crash or exit with an event 
code.
/SM590000The application might fail to detect that the data is corrupted and return erroneous data.
/SM590000The application might work without a problem.
Because of the risk of data corruption, and in particular undetected data corruption, MM/GM 
strongly enforces the concept of consistency and prohibits access to inconsistent data.
Consistency as a concept can be applied to a single relationship or a set of relationships in a 
Consistency Group. Write ordering is a concept that an application can maintain across 
several disks that are accessed through multiple systems. Therefore, consistency must 
operate across all of those disks.
When you are deciding how to use Consistency Groups, the administrator must consider the 
scope of an application’s data and consider all of the interdependent systems that 
communicate and exchange information.
If two programs or systems communicate and store details as a result of the information that 
is exchanged, either of the following actions might occur:
/SM590000All of the data that is accessed by the group of systems must be placed into a single 
Consistency Group.
/SM590000The systems must be recovered independently (each within its own Consistency Group). 
Then, each system must perform recovery with the other applications to become 
consistent with them.
Consistent versus synchronized
A copy that is consistent and up-to-date is described as synchronized. In a synchronized 
relationship, the master and auxiliary volumes differ only in regions where writes are 
outstanding from the host.
Consistency does not mean that the data is up-to-date. A copy can be consistent and yet 
contain data that was frozen at a point in the past. Write I/O might continue to a master but 
not be copied to the auxiliary. This state arises when it becomes impossible to keep data 
up-to-date and maintain consistency. An example is a loss of communication between 
systems when you are writing to the auxiliary.
When communication is lost for an extended period and Consistency Protection was not 
enabled, MM/GM tracks the changes that occurred on the master, but not the order or the 
details of such changes (write data). When communication is restored, it is impossible to 
synchronize the auxiliary without sending write data to the auxiliary out of order. Therefore, 
consistency is lost.
Note: MM/GM relationships with Consistency Protection enabled use a point-in-time copy 
mechanism (FlashCopy) to keep a consistent copy of the auxiliary. The relationships stay 
in a consistent state, although not synchronized, even if communication is lost. For more 
information about Consistency Protection, see 11.6.20, “Consistency Protection for Global 
Mirror and Metro Mirror” on page 532.