Check out the "Filling" item:
http://people.bu.edu/rbs/ADSM.QuickFacts

Regards,
Shawn
________________________________________________
Shawn Drew





Internet
asr AT UFL DOT EDU

Sent by: ADSM-L AT VM.MARIST DOT EDU
02/06/2012 04:17 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
[ADSM-L] Excessive number of filling tapes...






So, I've got an offsite machine which exists to accept remote virtual
volumes.  For years, now, the filling volumes have behaved in a way I
thought I understood.

The tapes are collocated by node.  There are about 20 server nodes which
write to it.

My number of filling volumes has rattled around 50-60 for years;  I
interpret this as basic node collocation, plus occasional additional
tapes allocated when more streams than tapes are writing at a time.  So
some of the servers have just one filling tape, some have two, and the
busiest of them might have as many as 6 (my drive count).

Add a little error for occasionally reclaiming a still-filling volume,
and that gives me a very clear sense of what's going on, and I can just
monitor scratch count.

Right now, I have 190 filling volumes.

None of them has data from more than one client.

I have some volumes RO and filling, and am looking into that, but it's
20 of them, not enough to account for this backlog.  Those are also the
only vols in error state.

I've been rooting through my actlogs looking for warnings or errors, but
I've never had occasion to introspect about how TSM picks which tape to
call for, when it's going to write.  It's always Just Worked.


Does this ring any bells for anyone?    Any dumb questions I've
forgotten to ask?  I don't hold much hope for getting a good experience
out of IBM support on this.


- Allen S.Rout



This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.