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