To take advantage of AOTM, you must provide an IP communication path between the TS3000 TSSCs at the cluster sites. Ideally, the AOTM function uses an independent network between locations, but this configuration is not a requirement. 

With AOTM, the user-configured takeover mode is enabled if normal communication between the clusters is disrupted and the cluster that is running the takeover can verify that the other cluster failed or is otherwise not operational. For more information, see 9.3.11, “Service icon” on page 511. 

When a cluster loses communication with another peer cluster, it prompts the attached local TS3000 to communicate with the remote failing cluster’s TS3000 to confirm that the remote TS7700 is down. If it is verified that the remote cluster is down, the user-configured takeover mode is automatically enabled. If it cannot validate the failure or if the system consoles cannot communicate with each other, AOTM does not enable a takeover mode. In this scenario, ownership takeover mode can be enabled only by an operator through the MI or by using the LI REQ  command. 

Without AOTM, an operator must determine whether one of the TS7700 clusters failed and then enable one of the ownership takeover modes. This process is required to access the logical volumes that are owned by the failed cluster. It is important that WOT be enabled only when a cluster failed and not when a problem exists only with communication between the TS7700 clusters. 

If ownership takeover is enabled in the read/write mode against a network-inaccessible cluster and the inaccessible cluster is in fact handling host activity, volumes can be modified at both locations. This issue results in conflicting volume versions. When the Read Ownership Takeover (ROT) is enabled rather than read/write mode, the original owning cluster can continue to modify the volume where peers have read-only access to an earlier version. 

Therefore, manually enabling ownership takeover when only network issues are present should be limited to only those scenarios where host activity is not occurring to the inaccessible cluster. If two conflicting versions are created, the condition is detected when communications are resolved and the volumes with conflicting versions are moved into an error state. When in this error state, the MI can be used to choose which version is most current. 

Even if AOTM is not enabled, configure it to provide protection from a manual takeover mode being selected when the cluster is functional. This extra TS3000 TSSC path is used to determine whether an unavailable cluster is still operational. This path is used to prevent the user from forcing a cluster online when it must not be or enabling a takeover mode that can result in dual volume use. 

## 2.4.34 Selective Write Protect for DR testing 

This function enables clients to emulate DR events by running test jobs at a DR location within a TS7700 grid configuration and enabling volumes only within specific categories to be manipulated by the test application. This configuration prevents any changes to production-written data. Up to 128 categories can be identified and set to be excluded from Write Protect Mode by using the Category Write Protect Property table. 

When a cluster is write protect-enabled, all volumes that are protected cannot be modified or have their attributes changed. Write protection is cluster scope and configured through the MI. Settings are persistent. 

