> George Sinclair 
> 
> I think it's generally safer to import the tape using:
> 
> nsrjb -j libname -d -S slot_num
> 
> and then do the inventory once it's been deposited in the slot.

On our previous libraries, I always did this (unless I had a lot of tapes 
to swap), but these are Sun L100s (Quantum L2500s, I think) and they're 
configured with no ports for max capacity. So, I have to open the doors. I 
just make sure there's no picker activity when I do. Maybe I missed 
something, though. In 5+ years of using them, this is the first time I've 
seen this happen.


> That message is typical when you have a disabled drive. I always see 
> that - one for each such disabled drive, but it shouldn't prevent you 
> from inventorying the tape in another available drive, but it will 
> report on juts about every nsrjb command.

My thoughts exactly.  :-)


> Is it possible that you have a bar code, with bar code reader enabled, 
> and it just inventoried it from the bar code and never had to physically 

> load it? Alternatively, perhaps that pool is not allowed to use the 
> available devices?

No - The tape has been used/loaded many times; in fact, the data I need to 
restore is on it and one other tape. The pool/devices are also correctly 
configured.



> You should be able to run: nsrjb -s server -j jukebox -I -S slot_num -f 
> /dev/rmt/5ubn to force it to use that device, assuming the pool 
> configuration doesn't prohibit it.

Exactly, but it didn't. First time I've seen that.


> NW can be very picky with this. Did you see any Invalid argument 
> messages? If it thinks there's something in there, even from how ever 
> far back, then you have to end up putting something in there and 
> unmounting it and let it do what it wants until it completes the 
operation.

No messages other than it telling me about the disabled drive.


> I've seen things get so fowled up that I had to stop/restart the 
> software on the snode to straighten it out. It would get to the point 
> where any 'nsrjb' commands would just run forever and nothing would ever 

> do anything. This happens sometimes when NW gets confused over a tape 
> that it thinks is in a drive but isn't, never mind what I think. 
> Regardless of how much we try to make sense out of it, sometimes you 
> have to just manually insert a tape into the affected drive and still 
> stop/restart NW and then subsequently unmount it in order to wrest 
> control over the whole ensemble.

Yep. Same here. I'm going to cancel cloning in a little while, get this 
straightened out and them complete these clones from where we left off. I 
would love to know exactly where/how this state information is held and 
how to clear it, but so far, no luck.

Thanks for the reply.

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER