Zoltan,

In playing with various DR scenarios and working through occasional hardware
problems, I found it difficult to get all the right commands entered
correctly and in the correct sequence and with the library/drives in the
correct states so I created scripts that delete and re-define everything.

If things are healthy as far as the hardware is concerned, they work
flawlessly and everything gets redefined and if there is a problem, looking
for the first failure usually tells me where the problem lies.

Bob.

/* define ltolib2 */
del_path:
delete path tsmsrvb mt0.0.0.1 srctype=server desttype=drive library=ltolib2
etc...

del_drive:
delete drive ltolib2 mt0.0.0.1
Etc...

drop_library_path:
delete path tsmsrvb ltolib2 srctype=server desttype=library

drop_library:
delete library ltolib2

create_library:
define library ltolib2 libtype=scsi

create_library_path:
define path tsmsrvb ltolib2 srctype=server desttype=library device=lb0.1.0.1
online=yes

def_drive:
define drive ltolib2 mt0.0.0.1 element=autodetect serial=autodetect
online=yes
Etc...

def_path:
define path tsmsrvb mt0.0.0.1 srctype=server desttype=drive library=ltolib2
device=mt0.0.0.1 online=yes
Etc...

Checkin_scratch:
checkin libv ltolib2 search=yes checklabel=barcode
status=scratchCheckin_scratch:

Checkin_private:
checkin libv ltolib2 search=yes checklabel=barcode status=private

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Friday, July 10, 2009 1:12 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a better
way")

Well  the consensus is to change the serial number of the replaced drive,
which I did.  However, since I had already rebooted the library owning
server, to discover the new serial number, I rebooted it again and it seems
to access the replaced drive, just fine.

However (isn't there always a "however" or "but"), none of the library
client servers can mount a tape on this drive!.  They all fail with a
"Unable to open drive" error.  I have tried updating the paths to this
drive, on the library manager server, telling it to autodetect, which it
does just fine.

Even tried deleting and redefining all the paths to the library client
servers.............nada.........zip...........all library client servers
still fail trying to get to this drive.

More thoughts on how to resolve this?  Do I need to bounce each of the TSM
servers (not the whole machine......just the server)?



From:
"Costa, Justino" <justino.costa AT LOGICA DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
07/09/2009 07:38 PM
Subject:
Re: [ADSM-L] Replacing tape drives (or "there has to be a better way") Sent
by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



There must be a reason why sandiscovery defaults to off on non-windows
platforms.

Anyway, I think you're right and that *should* be the correct behavior of
SANDISCOVERY=ON.

However, I prefer to stick with persistent binding and tight control on SAN
changes. This way, I can at least avoid spending time on false positives
like this one described here
http://www-01.ibm.com/support/docview.wss?uid=swg1IC59807, even for the
latest 5.5.x and 6.1.x versions.

jmC


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wanda Prather
Sent: quinta-feira, 9 de Julho de 2009 18:11
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a better
way")

I've been following this thread and have a question about AUTODETECT:

I've seen this message:
ANR8955I Drive drive name in library library name with serial number serial
number is updated with the newly discovered serial number serial number .

as a result of having the drives defined with AUTODETECT=YES and also
SANDISCOVERY ON with the appropriate HBA library installed.

Can anyone expand on why this does or doesn't always work when changing a
drive serial #?  Or does it only work when the device number changes?

W

> >Subject
> >[ADSM-L] Replacing tape drives (or "there has to be a better way")
> >
> >
> >
> >
> >
> >
> >I need thoughts/suggestions/help on how to deal with SAN attached
> >tape drive replacements when a library is shared amongst 5-servers.
> >
> >We just has a drive replaced, therefore giving us a new serial number

> >(3494ATL - TS1130).  All servers that use these drives/libraries are
> >RedHat Linux and use very current lin_tape drivers.
> >
> >Currently, the method we use is to bounce each server so the system
> >rescans the SAN and gets the new serial number.
> >
> >In the past, just stopping the TSM server and then restarting the
> >lin_tape driver would often be enough. Now with the latest lin_tape
> >drivers, I don't see the lin_taped daemon running any more.
> >
> >Yes, I have tried updating the paths on the library manager server
> >and telling it to autodetect but that didn't help.
> >
> >There has to be a better way!  If you have a similar configuration,
> >how
>
> >do you handle this scenario?
> >

This electronic transmission and any documents accompanying this electronic 
transmission contain confidential information belonging to the sender.  This 
information may be legally privileged.  The information is intended only for 
the use of the individual or entity named above.  If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or the taking of any action in reliance on or regarding the contents of this 
electronically transmitted information is strictly prohibited.