VMCHANGE 2

[YouEnjoyMyself]

Awhile back I posted a question about the vmchagne command. I wanted to get a script for ejecting multiple tapes which i have succeeded in doing. The problem I run into is that when a tape isnt in the robot the vmchange command errors out. Is there a way to get around this? Has anyone ran into this problem before?

 

[creakyjoe]

Just tried with a tape that's definitely not in the robot ->

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

Slot# MediaID Barcode MAP_Element# Batch Status
0 5719L1 UNKNOWN -1 -1 Eject aborted.
failed receiving from robotic software daemon (44)


Have only ever come across this before if mistyped a tape number, so guess the only advice is the obvious - never allow a vacant tape to enter your vmchange list..

Rich

 

[Stumpr]

Haven you thought of running your list through twice.
1st time check to see if in the library and build the second list
2nd time process the new list you just created.

Bob Stump
Incorrigible punster -- Do not incorrige

 

[YouEnjoyMyself]

Ok so I am really stumped. Here is what I did. When I arrived at work this morning I ran my script (see below) that ejects my daily tapes that are taken off site. I only did this as a test so when the tapes were ready to be removed from the robot cap I hit return to the prompt that script gives me. Which aborts the eject and returns the tapes to there previous slots. (I didnt take the tapes out of the robot for specific reasons.) Now when I tried to run through this script later to eject the tapes (the real thing not a test) I get this error:

One of the media id provided does not exis, or is not in the correct location


The tapes were in the robot and should be in thier correct location. Can anyone else repeat this error for me or has anyone run into this? I am really stumped.

Script:

FOR /F %%i IN (D:\\tapestoeject.txt) DO D:\\veritas\volmgr\bin\vmchange -res -multi_eject -w -verbose -rn 1 -rt tld -rh verbackup -vh verbackup -ml %%i

 

[GreyWanderer]

The run the list twice is definately the right way to go, or purchase the vault option.

As for your error, the tape was probably not returned the the same slot that it was orginially in, since you did not reinventory the robot, you got the error. Whenever a CAP is emptied, reinventory and update....it takes no time in a script.

 

[GreyWanderer]

\\Veritas\Volmgr\bin\vmupdate -rn 1 -rt tld -empty_ie -rh rob_hostname -use_barcode_rules


Performs inventory, empties CAP, uses barcodes rules.

 

[YouEnjoyMyself]

Thanks for all the suggestions, I will give that last one a shot GreyWanderer. I figured the problem was with the tapes not going back to thier slots, but i tried reinventorying the robot through the GUI and that did not change the problem. Basicly I hate Veritas...lol..such head aches sometimes.

 

[creakyjoe]

i don't see why you need to run this twice to get the correct tapes. As long as you religiously inventory the robot etc after any physical swapouts, then it doesn't matter if the tapes are in different slots. As i've said above, never let a non-physically present tape be passed thru your scripts. My scripts use output from available_media but as long as your script(s) pull in tapes that are 'TLD' or similar you should bo ok.

I detailed my process for doing this in another of your threads -

http://www.tek-tips.com/viewthread.cfm?qid=1009028&page=2

..so all should be working ??

Rich

 

[YouEnjoyMyself]

So I believe I have worked through the issues I have. I still dont understand why after I reinventory the robot (religously) and try to eject a set of tapes and maybe only one tape is missing from the set of tapes i want to eject from the robot it errors out the entire eject. I think this is an bug in veritas software? Just my opinion. Maybe I try comparing my lists to the available media command output. Funny how that command is unsupported by veritas....

Thanks for all the help. These forums help out a lot.

 

[creakyjoe]

well the command is going to fail if you're asking it to swap out a non-(physically)-existant tape. I concede that the command maybe should flag an error instead of failing, but unfortunately you need to workaround it. The root cause of your problem is script(s) allowing a non-present tape to trip up the vmchange command. Lol maybe it's Windows that's the problem

Rich

 

[YouEnjoyMyself]

Veritas, windows who knows both I dislike, but again thanks for the help.