Yes the doc URL would be useful if you could share that would be appreciated.
The answer was in the scan output for the changer.
You have 13 drives, but 11 are listed:
Drive 1 Serial Number : "576004004141"
Drive 2 Serial Number : "576004004140"
Drive 3 Serial Number : "576004004111"
Drive 4 Serial Number : "576004004171"
Drive 5 Serial Number : "576004004169"
Drive 6 Serial Number : "576004003920"
Drive 7 Serial Number : "576004005851"
Drive 8 Serial Number : "576004004170"
Drive 9 Serial Number : "576004004404"
Drive 10 Serial Number : "1068013405"
Drive 11 Serial Number : "576004002235"
So, straight away we can see something isn't right. You pointed out that the library detected 13 drives, so the question then should have been, ok - why is it only listing the serial numbers for 11 of them.
What you may not know, so I will share with you is that what is seen from scan, is sent from the devices - it has 100% absolutly nothing to do with NBU. In fact, if you stop NBU services, you will find that scan still works. That is the big part of solving these issues as it instantly proves that NBU cannot possibly be the cause in any way shape of form.
scan simply sends scsi commands, and displays the output (OK, there is a bit of formatting of the results but that is all).
NBU configures drives to be robotic by noticing that the serial number of the drive is also listed as one of the serial numbers of the drives listed in the changer, and in this case, as the drives were missing it couldn't match them to a robot, and so they end up as stand-alone, or in NBU terms, AVR.
I'm not famialr with the SL3000 (as in I've never seen or used one) but I will hazard a guess that it is a partitionable library, and that the 2 drives were not assigned to a partition (even if there is only one partition, or the library was unpartitioned, I suspect you still have to assign the drives withing the library config).
TBH, NBU does't really care about the make of library, certainly for TLD type, which is mostly what we see, they all work in roughly the same way, so if you see an issue on one make, it's at least reasonable that the same symptoms of that issue on another make will have the same, or similar cause. there are a few exceptions where library options/ settings are unique to a make, which can cause havic with NBU but I try not to worry to much about those as fortunatly we don;t seem to see them that often (as they can be real hard to identify).
One case I remember that was fun, I won't name the vendor - but they just point blank refused it was them and blamed NBU (given that robtest wasn't showing some of the tapes, it couldn't be us (robtest is like scan, what is shown is sent from the library, we just display it). Eventually I got fed up, had a look via webex and we ended up changing, one at a time, every option on the library console until we found the one that was causig the issue.
Hope this helps.
