8464ch11_Monitoring.fm Draft Document for Review February 7, 2020 3:15 pm As part of normal processing in a TS7700 Cluster, you can specify that after a certain time  after being returned to scratch, the contents of a volume can be deleted. This field  indicates whether the data that is associated with the volume was deleted on the cluster. GLYPH<SM590000> Data Deleted GLYPH<SM590000> Removal State GLYPH<SM590000> Hot As part of normal processing in a TS7700 Grid configuration where a mixture of both  TS7700T and TS7700D clusters exists, a data removal or migration process occurs where  data is removed from TS7700D clusters to prevent TS7700D clusters from overrunning  their TVC. This field, and the removal time stamp, can be used to determine whether the  data that is associated with the volume was removed. This field represents the cluster’s view of wh ich clusters include obsolete token or volume  metadata information as a result of a cluster outage. When clusters are unavailable  because of expected or unexpected outages, the remaining clusters mark the unavailable  cluster for pending reconciliation by updating this hot mask. The field represents Insert or  Eject pending updates, or regular pending updates.  Insert/Eject updates are related to volumes that are inserted or ejected during the outage.  Regular pending updates are for updates that occur to the volume during an outage as a  result of normal operations, such as host I/O. Each bit within the mask represents which  clusters are viewed as needing reconciliation. This report provides a list of all volumes that are kept in cache. The contents of the cache that  are associated with the specific cluster that the request volume is written to are returned in  the response records. In a TS7700 grid configuration, separate requests must be sent to each  cluster to obtain the cache contents.  The response records are written in 80-byte fixed block (FB) format. Remember:  The generation of the response might take several minutes to complete,  depending on the number of volumes in the cache and how busy the TS7700 cluster is at  the time of the request. The contents of the cache typically are all private volumes. However, some might be  returned to SCRATCH status soon after being written. The TS7700 does not filter the  cache contents based on the private or SCRATCH status of a volume. The TS7700 maintains the mapping between logical and physical volumes in a database on  each cluster. It is possible that inconsistencies exist in the mapping information that is  provided with this function. This inconsistency results when a logical volume is being moved  from one physical volume to another. For a while, the volume is shown on more than one  physical volume. This issue can result in a few logical volumes that are reported as being on  physical volumes that they were on in the past, but are not presently on. Even with inconsistencies, the mapping data is useful if you want to design jobs that recall  data efficiently from physical volumes. If the logical volumes that are reported on a physical  volume are recalled together, the efficiency of the recalls is increased. If a logical volume with  an inconsistent mapping relationship is recalled, it recalls correctly, but an extra mount of a  separate physical volume might be required. Physical volume to logical volume mapping information Cache content information 656  IBM TS7700 Release 5.0 Guide