Does anybody know what causes this error:/usr/openv/volmgr/bin/vmchange -res -multi_eject -w -verbose -rn 0 -rt tld -rh uslshr01 -ml 006122:006162:006172:006232:006262:006282:006342:006502:006512:006702:006782:006822:006842:007002:007022:007292:007302:007422:007532:007742:007822:007932:SL0106:SL0112:SL0113:SL0134:SL0135:SL0136:SL0138:SL0139:SL0140:SL0143:SL0144:SL0158:SL0160(Line breaks added for readability)Slot# MediaID Barcode MAP_Element# Batch Status 101 006122 UNKNOWN -1 -1 Eject aborted. 3 006162 UNKNOWN -1 -1 Eject aborted. 110 006172 UNKNOWN -1 -1 Eject aborted. 38 006232 UNKNOWN -1 -1 Eject aborted. 69 006262 UNKNOWN -1 -1 Eject aborted. 56 006282 UNKNOWN -1 -1 Eject aborted. 105 006342 UNKNOWN -1 -1 Eject aborted. 40 006502 UNKNOWN -1 -1 Eject aborted. 17 006512 UNKNOWN -1 -1 Eject aborted. 52 006702 UNKNOWN -1 -1 Eject aborted. 9 006782 UNKNOWN -1 -1 Eject aborted. 128 006822 UNKNOWN -1 -1 Eject aborted. 81 006842 UNKNOWN -1 -1 Eject aborted. 62 007002 UNKNOWN -1 -1 Eject aborted.....-------------------------------It almost seems random but usually happens when trying to perform an eject remotely. Does somebody have my load ports opened?Quantum PX720Netbackup 5.1MP5

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/scanAnd, 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=HPPRODUCT_ID=ESL E-SeriesROBOT_TYPE=8COMPATIBILITY_TAG=4194305DRIVE_NEEDS_CLEANING_SENSE=8001,8002LIBRARY_SERIALIZATION=3MAILSLOT_DELAY=30

Help: vmchange eject error

11 Replies

zippy
Level 6
18 years ago
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
Chia_Tan_Beng
Level 6
18 years ago
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).
Nathan_Kippen
Level 6
18 years ago
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
Yasuhisa_Ishika
Level 6
18 years ago
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
Chia_Tan_Beng
Level 6
18 years ago
> 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
Richard_Bannist
Level 5
18 years ago
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
Nathan_Kippen
Level 6
18 years ago
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
Richard_Bannist
Level 5
18 years ago
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
Nathan_Kippen
Level 6
18 years ago
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
Ankur_Kumar
Level 5
18 years ago
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