d. Resume the Global Mirror between the Local System and Remote System 1. e. Start/resume the Global Mirror between Remote System 1and Remote System 2. The first time that these operations are performed, a full copy between Remote System 1  and Remote System 2 occurs. Later executions of these operations perform incremental  resynchronization instead. After the Global Mirror between Remote System 1 and Remote  System 2 is in  ConsistenSynchronized  state, the consistency point in Site C is created.  The Global Mirror between Remote System 1 and Remote System 2 can now be stopped  to be ready for the next consistency point creation. An IBM Spectrum Virtualize based system generates a 1920 error message whenever a  Metro Mirror or Global Mirror relationship stops because of adverse conditions. The adverse  conditions, if left unresolved, might affect performance of foreground I/O.  A 1920 error can result for many reasons. The condition might be the result of a temporary  failure, such as maintenance on the intersystem connectivity, unexpectedly higher foreground  host I/O workload, or a permanent error because of a hardware failure. It is also possible that  not all relationships are affected and that multiple 1920 errors can be posted. The 1920 error could be triggered both for Metro Mirror and Global Mirror relationships.  However, in Metro Mirror configurations the 1920 error is associated only with a permanent  I/O error condition. For this reason, the main focus of this section is 1920 errors in a Global  Mirror configuration. Although Global Mirror is an asynchronous remote copy service, the local and remote sites  have some interplay. When data comes into a local volume, work must be done to ensure that  the remote copies are consistent. This work can add a delay to the local write. Normally, this  delay is low. The IBM Spectrum Virtualize code implements many control mechanisms that  mitigate the impacts of the Global Mirror to the foreground I/Os. The  gmlinktolerance  parameter helps to ensure that hosts do not perceive the latency of the  long-distance link, regardless of the bandwidth of the hardware that maintains the link or the  storage at the secondary site. The hardware and storage must be provisioned so that, when  combined, they can support the maximum throughput that is delivered by the applications at  the primary that is using Global Mirror.  If the capabilities of this hardware are exceeded, the system becomes backlogged and the  hosts receive higher latencies on their write I/O. Remote copy in Global Mirror implements a  protection mechanism to detect this condition and halts mirrored foreground write and  background copy I/O. Suspension of this type of I/O traffic ensures that misconfiguration or  hardware problems (or both) do not affect host application availability. Global Mirror attempts to detect and differentiate between backlogs that occur because of the  operation of the Global Mirror protocol. It does not examine the general delays in the system  when it is heavily loaded, where a host might see high latency even if Global Mirror were  disabled. To detect these specific scenarios, Global Mirror measures the time that is taken to perform  the messaging to assign and record the sequence number for a write I/O. If this process  exceeds the expected value over a period of 10 seconds, this period is treated as being  overloaded ( bad period ). 6.3.5 1920 error Internal Global Mirror control policy and raising 1920 errors gmmaxhostdelay and gmlinktolerance Chapter 6. Copy services  203