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:[EMAIL PROTECTED] On Behalf Of Allen S. Rout Sent: Friday, January 06, 2006 2:52 PM To: ADSM-L@VM.MARIST.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 <[EMAIL PROTECTED]> 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
