I am trying to determine the causes of two anomalies in the behavior of a
deduplicated storage pool in our TSM test environment. The test environment
uses TSM 6.2.5.0 server code running under zSeries Linux. The environment has
been using only server side deduplication since early September. Some tests
before that time used client side deduplication.

The first anomaly has to do with reclamation of the deduplicated storage pool.
For the last several days 'reclaim stgpool' commands have ended immediately
with the message:

ANR2111W RECLAIM STGPOOL: There is no data to process for LDH.

This was surprising, given the amount of duplicated date reported by 'identify
duplicates' processes. Yesterday I discovered that the storage pool had several
volumes that were eligible for reclamation with the threshold that had been
specified in the 'reclaim stgpool' commands. There had been a successful
storage pool backup after the then most recent client backup sessions. I was
able to perform 'move data' commands for each of the eligible volumes.

The second anomaly has to do with filling volumes. The deduplicated storage
pool has 187 filling volumes with a reported occupancy of 0.0. Most of these
also have the percentage of reclaimable space also reported as 0.0, and all
have the percentage of reclaimable space below 20. Most of the last write
dates are concentrated in three afternoons. I maintain a document in
which I log changes in the test environment and observations of the
behavior of the environment. This document does not show any change
in the environment or any observed anomalies on the days when most
of the low occupancy volumes were last written. The test environment
has two collocation groups. I have verified that the deduplicated storage
pool is configured for collocation by group and that every node is in
one of the collocation groups. All of the volumes in the storage pool
have  an access setting of 'READWRITE'. I have tried performing 'move
data' commands for a few of the low occupancy volumes. The test
environment consistently allocated a new scratch volume for output
rather than adding the contents of the input volume to one of the
few filling volumes with substantial amounts of data or to one of the
many other low occupancy volumes.

Web searches for the ANR2111W message turned up nothing except
reminders that a storage pool backup is needed before reclamation.
Web searches for various groups of keywords related to the second
anomaly have turned up nothing recognizably relevant.

Thomas Denier
Thomas Jefferson University Hospital
The information contained in this transmission contains privileged and 
confidential information. It is intended only for the use of the person named 
above. If you are not the intended recipient, you are hereby notified that any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply email and destroy all copies of the original message.

CAUTION: Intended recipients should NOT use email communication for emergent or 
urgent health care matters.