This is actually APAR IC47950. I just looked and it's still listed as open. The 
tape is deleted in the library client (STGDELETE)
and the volhistory entry in the library manager is removed, ownership changes 
to the library manager, but it doesn't get put back as
scratch. I do something similar to Allen to identify those tapes and update 
libv back to scratch.


Bill Boyer
"Some days you're the bug, some days you're the windshield" - ??

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Allen S. Rout
Sent: Friday, January 06, 2006 2:52 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Fwd: Re: [ADSM-L] Tape assignments as a mass-flow problem...

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