ADSM-L

Re: [ADSM-L] 3584/3494 differences with tape issues

2007-03-27 09:55:40
Subject: Re: [ADSM-L] 3584/3494 differences with tape issues
From: Fred Johanson <fred AT UCHICAGO DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 27 Mar 2007 08:55:23 -0500
Actually, we saw this, or something very similar, often in
the 10 years we had a 3494.  When TSM had an empty tape
listed as PRIVATE we

upd libv libname vol# stat=scr owner=''



---- Original message ----
>Date: Mon, 26 Mar 2007 14:08:20 -0700
>From: "Gill, Geoffrey L." <GEOFFREY.L.GILL AT SAIC DOT COM>
>Subject: [ADSM-L] 3584/3494 differences with tape issues
>To: ADSM-L AT VM.MARIST DOT EDU
>
>I've run into a couple of situations where what works very
easily with a
>3494 does not at all with a 3584. For instance, I had a
scratch tape
>that was mounted as part of a TSM process and there was an
issue with
>the tape that caused the path to go offline. The tape stayed
stuck in
>the drive and after we removed it I was thinking that as
long as the
>tape was in a dismounted state in the drive the library
would put it
>away once I closed the door, but it did not.
>
>
>
>TSM put this tape in a private status but there is no data
on the tape.
>So the question is how to get this tape, either out of the
inventory so
>I can get it out of TSM or put away from the drive or door
since TSM has
>no idea the tape is still sitting there. I don't understand
an ejected
>tape not getting put away by the library but maybe the
simplistic
>architecture of the 3584 prevents that from happening. I
also don't
>understand this library not having a 'lost cell' but then
again maybe
>the answer is the same.
>
>
>
>Does anyone have a procedure to clean this up or any
suggestions?
>
>
>
>
>
>Geoff Gill
>TSM Administrator
>PeopleSoft Sr. Systems Administrator
>SAIC M/S-G1b
>(858)826-4062
>Email: geoffrey.l.gill AT saic DOT com
>
>
Fred Johanson

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