I have observed that for primary storage pools where the tape volumes have been 
DEFINEd to belong to that pool, MOVE DATA to consolidate tapes belonging to the 
same collocation group has unexpected results.  The database reliably selects 
the volume copied FROM as the primary candidate for the next tape to be written 
TO for that collocation group, resulting in a ping-pong effect...  This 
behavior can be subverted by using DELETE VOLUME after MOVE DATA, and assigning 
the volume to another pool.

- Margaret Clark

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Thomas Denier
Sent: Wednesday, August 03, 2011 9:03 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] BACKUP STGPOOL and collocation

We have a new TSM 6.2.2.0 server running under mainframe Linux. It has a
primary storage pool on file devices and a copy pool on TS1120 tape. The
tape library is located in a different building than the server and its
clients, so we do not eject and vault copy pool volumes. We normally run
storage pool backups with 'maxproc=4', but occasionally use 'maxproc=5'.
Backup storage pool operations do not seem to be following the documented
rules for collocation. The server currently has 7 collocation groups.
Yesterday morning, the copy pool had 25 volumes in filling status, with
one collocation group having 5 volumes in filling status. I executed
'move data' commands to consolidate some of the volumes. After the
storage pool backups this morning I found 6 new filling volumes, all
for collocation groups that already had filling volumes with free space.
I have verified that the copy pool specifies collocation by group, that
every node is assigned to a collocation group, and that every filling
volume has read/write access.

Am I misreading the documentation regarding volume usage in collocated
storage pools?