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:[email protected]] On Behalf Of Thomas Denier Sent: Wednesday, August 03, 2011 9:03 AM To: [email protected] 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?
