For more information, see IBM TS7700 Series Grid Resiliency Improvements User’s Guide , WP102742. 

## 2.4.37 Service preparation mode 

The transition of a cluster into service mode is called service prep . Service prep enables a cluster to be gracefully and temporarily removed as an active member of the grid. The remaining sites can acquire ownership of the volumes while the cluster is in service. If a volume that is owned by the service cluster is not accessed during the outage, ownership is retained by the original service cluster. Operations that target the distributed library that is entering service are completed by the site going into service before the move to service completes. 

Other distributed libraries within the composite library remain available. The host device addresses that are associated with the site in service send Device State Change alerts to the host enabling those logical devices that are associated with the service preparation cluster to enter the pending offline  state. 

If a cluster enters service prep, the following copy actions are processed: 

GLYPH<SM590000> All copies in flight (running currently), regardless of whether they are going to or from the cluster, are finished. 

GLYPH<SM590000> No new copies from other clusters to the cluster that is entering the service mode are started. 

GLYPH<SM590000> All logical volumes that are consistent only on the service prep cluster and require at least one peer copy are copied to at least one other cluster in the grid. This is true for all copies except those that are Time Delayed. 

GLYPH<SM590000> For time delayed copies, all data that should be copied in the next 8 hours to the target clusters is copied. All other data is not copied, even if the data is only in the cluster that is entering the service mode. 

GLYPH<SM590000> Any pending updates (hot tokens) to peer clusters where the service-prep cluster is the current owner must be reconciled or the volume ownership must be transferred to an available peer. 

When service prep completes and the cluster enters service mode, nodes at the site in service mode remain online. However, the clusters are prevented from communicating with other sites. This stoppage enables service personnel to run maintenance tasks on the site’s nodes, run hardware diagnostics, and so on, without affecting other sites. 

Only one service prep can occur within a composite library at a time. If a second service prep is attempted while another cluster is still in service prep, the second request fails. You should put only one cluster in the service prep mode at the same time. After service prep completes, another cluster can then be put into service prep. 

