Re: [ADSM-L] Preventing TSM from using a certain library port

Yes, that is what I meant.
If that doesn't help, it is indeed sad - and it sounds like your picker has
other problems, as well.

To answer your original question, TSM finds out what slots exist when it
starts up and first contacts the library.

If your "slot obstructed" error is resulting in an error code on the front
panel of the 3583, it probably needs IBM service.  If you can't get it
serviced and want to limp along for a while, here's something you could try
to prevent TSM from accessing that slot any more:

1) check out and eject the tape that is in the problem slot.
2) manually put a scratch tape in the problem slot
3) checkin libv your-library-name search=yes checklabel=barcode
status=scratch
4) update libv your-library-name vvvvvv status=private
where vvvvvv is the scratch tape in the bad slot
5) check the ejected tape back in with appropriate status
TSM will put it in a different slot this time.

That leaves a scratch tape in the bad slot, then changes the status so it
isn't scratch.  Since there is no data on it, TSM will NEVER have any reason
to call for that tape - not for migration, not for reclaims, nothing.

If the problem really is just that one slot, that should give you breathing
room.  Until the next problem hits...

Best of luck !

W

On Wed, May 27, 2009 at 7:32 PM, Stephan Boldt <
stephan.boldt+adsm-l AT gmail DOT com <stephan.boldt%2Badsm-l AT gmail DOT 
com>> wrote:

> Hello Wanda,
>
> do you mean
>
> Main Menu (initial screen) —> More —> Service —> Library—> Exercise —> More
> > Teach ?
>
> If you're referring to this procedure, I've already done it. However, I
> couldn't see any difference between this "teach" and the "teach" procedure
> performed during a cold start of the lib... And sadly it didn't fix the
> problem.
> Initially I hoped this procedure would fix another problem of our lib: the
> picker doesn't have the right angle towards the lowest tape drive and
> because of that it can't get out the tapes properly and sometimes drops
> them
> or leaves them in the drive. That's why we have disabled this drive. The
> angle towards the upper two drives is pretty perfect and I can't see a
> reason why it has a different one towards the lowest.
>
> BTW: To disable a drive in TSM, do I have to disable both, the drive and
> the
> path to this drive or just one of them. If the latter is  true, which one
> is
> recommended to be disabled and why?
>
> Kind regards,
> Stephan
>
>
>
> On Wed, May 27, 2009 at 11:12 PM, Wanda Prather <wprather AT jasi DOT com> 
> wrote:
>
> > I have several customers who have (or had) 3583 libraries.
> > Look in the 3583 Setup and Operator guide, and run the RECALIBRATE
> > procedure.
> >
> > It will correct some errors that a teach will not.  My recommendation is
> to
> > run the recalibrate at least once a year.
> >
> >
> > W
> >
> >
> > On Wed, May 27, 2009 at 5:06 PM, Stephan Boldt <
> > stephan.boldt+adsm-l AT gmail DOT com <stephan.boldt%2Badsm-l AT gmail DOT 
> > com> <
> stephan.boldt%2Badsm-l AT gmail DOT com <stephan.boldt%252Badsm-l AT gmail 
> DOT com>> <
> > stephan.boldt%2Badsm-l AT gmail DOT com <stephan.boldt%252Badsm-l AT gmail 
> > DOT com> <
> stephan.boldt%252Badsm-l AT gmail DOT com <stephan.boldt%25252Badsm-l AT 
> gmail DOT com>
> >>>
> > wrote:
> >
> > > Everytime we get thesese "Slot obstructed" errors we turn the library
> off
> > > and on again. After the library finished teaching its inventory we do a
> > > "audit library" to sync the informations about the tapes. Yesterday
> I've
> > > noticed that the the last times I've seen this error it was the same
> > slot.
> > > But I'm not the only one who has recovered our lib from this error
> state
> > > and
> > > the other persons who did it don't remember with which slot the error
> > > occurred. Maybe it's just coincidence, but because the tapes where
> > > different
> > > ones I suspect it's a problem related to this very slot.
> > > I'd really like to replace the barcode reader to eliminate this as a
> > > possible error cause, but the lib is out of mainenance and shall be
> > > replaced
> > > next year, so I don't get a budget for doing this. The lib "works" most
> > of
> > > the time but for me its really annoying :-(
> > >
> > > kind regards,
> > > Stephan
> > >
> > > On Wed, May 27, 2009 at 9:58 PM, Henrik Vahlstedt <
> SHWL AT statoilhydro DOT com
> > > >wrote:
> > >
> > > > So If i understand you correctly.
> > > > Barcode reader and gripper works perfectly on all slots exept one.
> > > > Tapeutil can read the volumelabel in the faulty slot.
> > > >
> > > > Can the library read the label if the tape is stored and checked in
> > from
> > > > a mailslot?
> > > > And you sure that 3583 volume inventory is up to date, and is
> matching
> > > > TSM library volume inventory?
> > > >
> > > >
> > > > //Henrik
> > > >
> > > > -----Original Message-----
> > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf
> > Of
> > > > Stephan Boldt
> > > > Sent: 27. mai 2009 16:13
> > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > Subject: Re: [ADSM-L] Preventing TSM from using a certain library
> port
> > > >
> > > > Hello Henrik,
> > > >
> > > > I cannot see how this should solve the problem. If the library can't
> > > > read the tape's barcode (or can't store it in its database, whatever
> > the
> > > > reason is), an 'audit library' command would tell TSM that the slot's
> > > > empty and tsm would not checkin the volume. But it would try to move
> > > > another volume into this slot, when checking them in from the
> > > > mailslot...
> > > >
> > > > Maybe I just didn't get the point of your idea...
> > > >
> > > > kind regards,
> > > > Stephan
> > > >
> > > > On Wed, May 27, 2009 at 10:06 AM, Henrik Vahlstedt
> > > > <SHWL AT statoilhydro DOT com>wrote:
> > > >
> > > > > Run an 'audit library "3583" checkl=barcode' to update library
> > > > > inventory in TSM and a 'checkin libv "3853" search=yes
> checkl=barcode
> > > > stat=pri'.
> > > > >
> > > > > Let us know if the problem presists after the two commands have run
> > > > > successful.
> > > > >
> > > > > Thanks
> > > > > Henrik
> > > > >
> > > > > -----Original Message-----
> > > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> > Behalf
> > > > > Of Stephan Boldt
> > > > > Sent: 27. mai 2009 09:47
> > > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > > Subject: [ADSM-L] Preventing TSM from using a certain library port
> > > > >
> > > > > Hello,
> > > > >
> > > > > our IBM 3583 library seems to have a problem using a certain port.
> > > > > Sometimes we get a "slot obstructed" error message because the
> > library
> > > >
> > > > > tries to put a tape into a slot which is already filled with
> another
> > > > > tape. Looking into the librarys slot information reveals that it
> > > > > assumes this slot is empty! First I thought the cause would be the
> > > > > tape itself / its barcode. But after removing this tape from the
> lib,
> > > > > the "slot obstructed" problem still occurres with the same slot but
> a
> > > > > different tape.
> > > > > Whatever the cause is, is there a way to tell TSM _not_ to use this
> > > > > slot, even if its empty? Is my assumption right that TSM and not
> the
> > > > > lib decides where to put a tape when checking it in or removing it
> > > > > from a tapedrive? But when does TSM get the information about which
> > > > > slots are present in a library? During an "audit library"?
> > > > >
> > > > > Thanks in advance,
> > > > > Stephan
> > > > >
> > > > >
> > > > > -------------------------------------------------------------------
> > > > > The information contained in this message may be CONFIDENTIAL and
> is
> > > > > intended for the addressee only. Any unauthorised use,
> dissemination
> > > > > of the information or copying of this message is prohibited. If you
> > > > > are not the addressee, please notify the sender immediately by
> return
> > > > > e-mail and delete this message.
> > > > > Thank you.
> > > > >
> > > >
> > > >
> > > > -------------------------------------------------------------------
> > > > The information contained in this message may be CONFIDENTIAL and is
> > > > intended for the addressee only. Any unauthorised use, dissemination
> of
> > > the
> > > > information or copying of this message is prohibited. If you are not
> > the
> > > > addressee, please notify the sender immediately by return e-mail and
> > > delete
> > > > this message.
> > > > Thank you.
> > > >
> > >
> >
>