>> On Wed, 21 Dec 2005 16:08:32 -0600, Fred Johanson <fred AT uchicago DOT edu> 
>> said:


> 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.


I'm seeing these too.  Any progress on the circumstances?

I found a bunch of them last night, reset them to be scratch, and in a
set of some 16 STGDELETE volumes today, 10 of them (from a total of 2
libraries) ended up owned by the lib mgr, status private.

Seeing so many of them crop up so fast, I decided I needed to automate
the fix: Here's how I'm finding these, and setting up the script to
fix them.

dsmadmc -tab -dataonly=yes -id=query -password=query -se=ctrl
  "select 'update libvolume', library_name, volume_name, 'status=scratch' \
   from libvolumes where owner='CTRL' and last_use is null" \
 | perl -ne ' s/\t/ /g; print; '  > /tmp/temp.scr


- Allen S. Rout