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 On Thu, Jul 9, 2009 at 12:12 PM, Costa, Justino <justino.co...@logica.com>wrote: > > > I don't care if the serial number changes. > > In one of the sites I manage, I have 47 drives in use by 1 library > manager, sharing them with 4 servers and 60 storage agents. This results > on more than 1400 paths defined on the library manager. > > As each path must match the machine device, manually redefining a drive > and it's paths (due to serial number change) it's an headache and, most > importantly, a very time consuming task. > > So, I manage this with a script that reads a config file, with server, > sta, libs and drive's characteristics and it outputs all the define, > delete, update drive and update path commands (among others). > > As such, when I need to replace a drive or update the device special > file of a drive instance, I simply run the script, grep the output and > pipe it directly to another script. > > Replacing a drive in this way turns out to be as simple and as fast as > (for example): > > If I need to replace drive 23, the procedure is more or less like this: > > Remove drive: > 1) run the script greping for "delete" path of drive 23 => seconds > 2) run the script greping for "delete" drive drive 23 => seconds > 3) prepare acsls for drive change => couple of minutes > > Change HW: > 4) Do the manual work of replacing the failed drive for a new one > => support task, don't care how long it takes (sort of ;-) > 5) Update operating systems device drivers if needed => It depends... > > Add drive: > 6) update acsls config for the new drive => couple of minutes > 7) run the script greping for "define" drive 23 but leave it offline => > seconds > 8) run the script greping for "define" path for drive 23 => seconds > 9) put drive nline and audit the library when possible (no activity on > the other drives) => a couple of minutes > > Total time spent = minutes ! > > > jmC > > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of > Roger Deschner > Sent: quinta-feira, 9 de Julho de 2009 16:07 > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a > better way") > > NOW you tell me. I just went through a terrible time replacing a HP > LTO-4 drive in a library. After futzing around for several hours, I > wound up bouncing the TSM server. Other vendors (Sun/STC, HP...) aren't > sympathetic to requests to change the drive serial number. > > I don't think serial number changing is a realistic solution to this > issue. It kinda takes away the whole point of serial numbers in the > first place. Perhaps I should APAR the failure of DEFINE PATH, DEFINE > DRIVE, etc to deal with a drive swap and serial number change. (AIX > 5.5.1 TSM server) > > Roger Deschner University of Illinois at Chicago rog...@uic.edu > Academic Computing & Communications Center > > > On Wed, 8 Jul 2009, Len Boyle wrote: > > >In fact we found out that for lto-3 and lto-4 tape drives in an IBM > 3584 library, it is required that they change the serial number to > match the old tape drive. Because IBM tracks the drives by serial number > for maint contracts. This we found when the serial numbers that we send > in for a maint contract renewal were kicked out as field engineering > had not been updating the serial numbers. But not for lto-2 tape drives. > > > >len > > > >-----Original Message----- > >From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf > >Of Sean English > >Sent: Wednesday, July 08, 2009 11:47 AM > >To: ADSM-L@VM.MARIST.EDU > >Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a > >better way") > > > >Zoltan, > > > >The majority of our TSM servers are AIX and we do have a setup where we > > >share multiple library clients with one library. When we have IBM CEs > >come out and replace drives, they just change the serial number on the > >new drive to match the old drive they are replacing. Apparently there > >is a way to do that on the drive itself. > > > >Thanks, > >Sean > > > > > > > > > > > > > >Zoltan Forray/AC/VCU <zfor...@vcu.edu> > >Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > >07/08/2009 11:30 AM > >Please respond to > >"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > > > >To > >ADSM-L@VM.MARIST.EDU > >cc > > > >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? > > > > > Please help Logica to respect the environment by not printing this email / > Pour contribuer comme Logica au respect de l'environnement, merci de ne pas > imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen > Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a > respeitar o ambiente nao imprimindo este correio electronico. > > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be copied, > disclosed to, retained or used by, any other party. If you are not an > intended recipient then please promptly delete this e-mail and any > attachment and all copies and inform the sender. Thank you. >