ADSM-L

Re: Fwd: Re: [ADSM-L] Tape assignments as a mass-flow problem...

2006-01-06 18:18:10
Subject: Re: Fwd: Re: [ADSM-L] Tape assignments as a mass-flow problem...
From: Fred Johanson <fred AT UCHICAGO DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 6 Jan 2006 17:18:00 -0600
Bill, Allen,

Do your scripts verify that the volumes are truly scratch?
Yesterday's big discovery was a number of volumes were still
active on a server.  I haven't yet seen in the ActLog where
they switch owners.  More headscratching for next week.



---- Original message ----
>Date: Fri, 6 Jan 2006 15:20:47 -0500
>From: William Boyer <bjdboyer AT COMCAST DOT NET>
>Subject: Re: [ADSM-L] Fwd: Re: [ADSM-L] Tape assignments as
a mass-flow problem...
>To: ADSM-L AT VM.MARIST DOT EDU
>
>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
Fred Johanson

<Prev in Thread] Current Thread [Next in Thread>