Fred Johanson

--- Begin Message ---

Subject:	Re: [ADSM-L] Tape assignments as a mass-flow problem...
From:	Fred Johanson <fred AT uchicago DOT edu>
To:	Allen S. Rout <asr AT ufl DOT edu>
Date:	Wed, 21 Dec 2005 15:19:30 -0600

Allen,

I don't know if your situation is the same as ours, but I've
found that in 5.3.2.1 with a Library Server Manager (ours
handles a 3494 and a 3584 four 4 TSM servers on separate
machines) under some circumstances as yet undtermined a
volume that goes thru STGDELETE on a client server goes to
SCRATCH, but the owner is the LSM, so the volume isn't usable
in the general scratch pool.  I'll try and determine those
circumstances when I get back next year.


---- Original message ----
>Date: Wed, 21 Dec 2005 11:42:12 -0500
>From: "Allen S. Rout" <asr AT ufl DOT edu>
>Subject: [ADSM-L] Tape assignments as a mass-flow
problem...
>To: ADSM-L AT VM.MARIST DOT EDU
>
>Greetings, all.
>
>
>I'm noodling with tracking down where in my TSM
infrastructure a particular
>drain of tapes is happening.  There are several ways I might
do this, but the
>angle I decided to try to work was querying the library
manager for when tapes
>were allocated to library clients, and when they come back.
>
>So what I discovered is that -assignments- are memorialized
with 'ANR9791I
>Volume [foo] in library [bar] ownership is changing'
messages, but from what I
>can see the return of a volume is not recorded in the lib
manager actlog at
>all.
>
>Now, I can collect the 'ANR1341I Scratch volume [foo] has
been deleted' from
>the library clients, but that's vaguely unsatisfying and
depends on access
>which might be difficult to achieve in some places.
>
>So, has anyone else found a satisfying solution to this kind
of measurement?
>
>
>- Allen S. Rout
Fred Johanson

--- End Message ---