I believe there was a patch for that in 7.3.1 - or at least that's what I seem to remember. It wouldn't be bad to open this with support and discuss it with them.

The problem cause is, that the barcode labels do not match the library. We found out that Overland, StorageTek, Quantum etc libraries use different barcode label formats. Some of them match other libraries, some of them do not. When you received your new library, there was a barcode label example in the package. If there wasn't an example, I suggest you call Overland Support and ask them to send you the barcode label example. You should order exactly the same barcode labels where you order them.

Sagi, the issue here described by user is not when changing library, but when changing NW version. It was tested with two different libraries - it is not that tapes were moved between them or that first one was upgraded to secone one.

I've got a new Overland ArcVault12 and used the Barcodes that were delivered with the Library, so i dont't belive this is an barcode issue.

Did you speak with support?

Have you already run a complete nsrjb -Iv on the library?

We have the same problem. Our barcode reader worked fine until we upgraded to v7.3.1

I opened a ticket with our third-party support vendor and they told me that after buying Legato, EMC put out Networker 7.3.x in which they replaced the Legato library code with their own.

I now get the message "expected '-', got 'TK954S2'" as I am forced to physically inventory each tape in the library. I set my inventories to "fast" but it does "slow" inventories anyway pulling each tape into the drives to have their magnetic labels read. EMC informed our support vendor that there are currently no plans to change the code back or otherwise modify it to correct this problem. Isn't that nice of them?

I was able to see fast inventory doing whole library inventory too with 7.3.2. However, the question remains what happens when you run inventory from command line. Change in code is not related to EMC buying LGTO - someone just told you the story

Hi Hrvoje,

Thanks for doubting the "story" from the Legato Partner who we have a support contract with. Really. When you suggested that I see what happens if I use the command-line utility instead of the GUI to perform a fast inventory, it gave me an great idea.

This is from the Networker v7.3.x Command Reference Guide:
"nsrjb communicates directly with a locally managed jukebox,
there is no intervening agent."

I took a look at the nsrjb.exe utility on my v7.3.1 Networker server and found that it was at version 7.3.1 and had been compiled on June 5, 2006. Then I took a look at the nsrjb.exe utility on my 7.2.0 server and found that it was at version 7.2.0 and had been compiled on October 25, 2004.

I decided to try a little experiment. I renamed nsrjb.exe on my Networker v7.3.1 server to nsrjb.new. Then I copied the nsrjb.exe utility from my Networker v7.2.0 server to my Networker v7.3.1 server.

Yay!!! My fast inventory now works like before but I still need to do a library reset afterward so that my library screen updates to reflect the new information. I also performed a test backup on one of my clients and a tape was loaded into one of the drives, it was formatted and data was written to it. I stopped the backup and performed a library reset. The tape was unloaded and the library screen updated on its own to show that the tape had been put back into the cartridge.

Still, this give you now unsupported environment and that's not something you want. So I would rather chase it with support... From what you have said, you didn't do test with nsrjb from cmd line using nsrjb.731?