Mark.Donaldson AT cexp DOT com wrote:
> Still, all you should have to do is "bpexpdate" the tape number and the
> tape should be reusable.
>   
That has worked in the past.  It just seems to be this one batch had 
problems.
> deassignbyid is a bit of a big hammer to use casually.  I'd do:
>
> bpexpdate -d 0 -m <tapenum> -force
> ..then a...
> bpexpdate -deassignempty -m <tapenum> -force
> ..this'll make the tape available sooner..
>   
I'll look into using these.  The deassignbyid came up for a reason at 
some point.  I think it was because a policy would pull a tape from the 
scratch pool and not the archive pool it was supposed to.  It seems this 
was needed before it would let us move the tape from the archive pool.  
It's legacy and can probably be removed.  I'll try the "-force" options 
with these and see how they do.
> Loaded every tape, then requested a new one? I've seen this on
> write-protected tapes and on physical drive errors.  If it loads the
> tape, finds it unusable for some reason, it'll dump it and request a new
> one.  Did some enthusiastic tape monkey write-protect all your tapes?
I wondered about them being write protected because I wasn't sure how 
they may have been put into the boxes for Iron Mountain.  I was told by 
the local guy that he verified the tapes are not write protected.  It 
seems something still has the VSN recorded somewhere or something like 
that.  The local person had some blank tape labels.  When he put them on 
the tapes and scanned them into the library, everything was fine.  The 
nightly backups started using them.  It isn't the ideal solution but it 
works for now. 

I'm out of town working on another project and will try and re-visit 
this next week sometime. 

Thanks for all the help.

Jeff

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu