Nathan,

It looks like the veritas DB is wigging out on the tapes and the slots they are suppose to be in, I would rescan the library (inventory the robot) and apply any changes.

JD

Nathan,

Do you encounter this only when ejecting approx. more than 16 tapes (i.e. more than one loadport)? Try ejecting less media and update me the result (I'm suspecting is the same problem we encountered here..... but it's consider "half fixed" with a new device_mapping file from Veritas).

Yes, I am usually ejecting between 25 - 40 tapes. Is this a Netbackup 5.1 error or does this happen in 6.0 too?

nk

Can you eject media successfully from GUI?
Show us the output of following conmmand if possible.

# /usr/openv/volmgr/bin/tpconfig -d
# /usr/openv/volmgr/bin/scan

And, can you try this?
# /usr/openv/volmgr/bin/vmchange -h -res -multi_eject -rt tld -rn 0 -rh -ml -single_cycle

> Yes, I am usually ejecting between 25 - 40 tapes. Is
> this a Netbackup 5.1 error or does this happen in 6.0
> too?

I'm not sure on 6.0 but basically the reply from Veritas is that the library does not response immediately after you have close the loadport and therefore when you hit enter "too quick" in response to the vmchange command, you would encounter such problem.

To verify try testing this:
1. Eject just a few tapes and wait a while before you hit enter in response to vmchange prompt. It should not give you any problem.
2. Eject large number of tapes and wait for about 1min before you hit enter. It should be ok or at least the error is less.

I've compared the new device_mappings.txt from Veritas against my existing, the different is the new one has added line "MAILSLOT_DELAY=30" under my tape library product type.

i.e.


VENDOR_ID=HP
PRODUCT_ID=ESL E-Series
ROBOT_TYPE=8
COMPATIBILITY_TAG=4194305
DRIVE_NEEDS_CLEANING_SENSE=8001,8002
LIBRARY_SERIALIZATION=3
MAILSLOT_DELAY=30

i've been having these 'Eject aborted' messages for longer than i can remember, but subsequently running the vmupdate command to re-inventory always works fine. I've never worries about it, i vaguely (and i really mean vaguely) recall this happening since we went to NBU 4.5.

Here's an example. i just moved a tape out to load port and back in, via the exact same way i always do it -

vmchange -res -multi_eject -w -verbose -rn 0 -rt tld -rh nthsunbackup -vh nthsunbackup -ml CH5704

*** Eject volume batch #1 is ready to be removed ***
remove 1 volume(s) from media access port(s) of robot number 0 now
(press to continue)

Slot# MediaID Barcode MAP_Element# Batch Status
31 CH5704 UNKNOWN 1 1 Eject aborted.

vmupdate -rt tld -rn 0 -rh nthsunbackup -vh nthsunbackup -use_barcode_rules -empty_map

Generating list of recommended changes ...

Proposed Change(s) to Update the Volume Configuration
=====================================================
Volume configuration is up-to-date with robot contents.


Rich

thank you all for your feedback.

Just to clarify this error only happens occasionally when ejecting multiple media from the command line. I've rarely encountered problems ejecting media from the GUI.

I believe this error might be related to trying to eject media when the robot is busy or perhaps when the library is inventorying itself after a loadport has been closed.

Again ... I mostly have this problem when I'm working on a remote library -- which means there very well could be people at the remote site doing stuff with the library... (opening/closing load ports.. that's all they can do..)

I'll post to this thread if I continue having a problem or if I find out from VERITAS any worthwhile info.

Thanks again for your replies!

nk

I have the errors/messages every single time i change tapes, but it's never caused a problem; and it happens when the robot is completely quiet too.
I've long ignored the errors myself

Richard,

The problem I have is when I do get this error the tapes don't eject and it causes me grief. :) Sometimes I'll even have to reboot my library to get it working how I want it to. (Not the best solution but it works.)

By the way, I use the vmchange command in a script .. whenever I eject tapes from the gui its usually not very many. (I hate trying to highlight all the tapes i need.)Message was edited by:
Nathan Kippen

did you try ejecting the same medias in a one by one manner, please do check up on the
please do check up on the bptm log.

ciao
Ankur Kumar

Nathan, that's definitely not good.
i always use the command i posted, whether at the command line or via script (i detest/distrust GUI's). anyway, i can happily vmchange upwards of 30 tapes in one sitting with no problems. The only time i have problems is every time i dawdle in responding to the prompt that vmchange gives to when you need to tell it that you've swapped the required tapes out. This command times out after a while and drops you back to the command line. No biggie. However what i don't have is a solution to your library locking up, seems vmchange is the least of your problems.

RIch