Eric,

I'm seing this phenomenon too, and think I found the explanation for it
(but it's a very specific case) :

Looks like those tapes where written by clients having
resourceutilization set to something higher than 2, that performed their
backup on a stg pool where data should be written first to disk and then
migrated to collocated tapes. At the time where the client backup was
running, the disk pool had reached it's highmig threshold and was being
flushed to tape. Client data that came at this moment has been written
to several tapes (non respectfull to the max mount point value
attributed to this node, but that's another problem), and the data lies
now on those tapes, which never went accessed later, as this specific
case never happened again.

What you could do to check if this happens to you, is to use following
sql (use it in a dsmadmc command, as it takes a long time to be
performed) :
select a1.node_name as "Node ID", a1.volume_name as "Volume ID",
a2.pct_utilized from volumeusage as a1, volumes as a2 where
a1.stgpool_name=upper('$1') and a1.volume_name=a2.volume_name group by
a1.node_name, a1.volume_name, a2.pct_utilized 

Basically it will show you which tapes are being used by wich node, and
how many % of tape is used. Use it only on collocated pools, and if you
see that a node has several volumes with few % used, you may be hit by
the problem !

Hope this made sense to you ...
Cheers.   

Arnaud 

************************************************************************
******
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone:  +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
************************************************************************
******