Thanks Mike, But that's not the issue. I failed to mention that the stuck/bad tape issue is not a problem. I updated the volume, joined it to a tapepool and destroyed the tape, system pulled in a new scratch and kept going. Again, manual intervention. Someone has to type upd libv, why?
What's the deal? Why isn't this automated? Am I asking too much of TSM, I mean how hard would it be to have the system recognize when this issue arises. Simple if statement, if can't mount scratch volume goto next available scratch. Anyone? Should I open a new PMR an put this on a wish list, or am I behind the times and it's already been done? Thanks, Mark Bertrand -----Original Message----- From: Quiros, Mike [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 3:04 PM To: [EMAIL PROTECTED] Subject: Re: Scratch mount failed Just use the upd libv command to change the status from scratch to private. TSM will skip that tape and go on to the next scratch tape. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Mark Bertrand Sent: Thursday, August 19, 2004 12:55 PM To: [EMAIL PROTECTED] Subject: Scratch mount failed Over the last weekend we had a tape get stuck in a drive and threw the drive offline, no big deal, right? This happens enough that we know how to deal with it, but... this is the first time that this has happened (in my limited three years experience) in that the stuck tape was a scratch tape. This caused any job needing to mount a scratch tape to fail until manual intervention. Let me tell you, this is not a good thing. My question.., is this by design? If so who can we contact to get this written in the next release? Why can't TSM recognize that the scratch tape requested is not available and move to use another scratch, simple enough right? Storage Management Server for Windows - Version 5, Release 1, Level 6.3 Windows 2k Library IBM 3584 w/ 6 lto1 fiber channel drives Probably a setting that I missed in setup three years ago and just never had this happen before, any help is appreciated as always. Thanks, Mark Bertrand
