Veritas-bu

Re: [Veritas-bu] More tapes than cap space on eject

2009-06-12 14:21:20
Subject: Re: [Veritas-bu] More tapes than cap space on eject
From: scott.george AT parker DOT com
To: veritas-bu AT mailman.eng.auburn DOT edu
Date: Fri, 12 Jun 2009 14:17:15 -0400
No, they are right on it, because they initiate the eject with the 
deferred eject.  What happens is the vault runs and does all of its dupes 
and the finishes without ejecting anything.  When they notice the vault is 
done, they expand out "Vault Management" down to the job itself and right 
click --->Deferred Eject.  It then kicks out all of the tapes, well, 78 of 
them.  They are really good on their timing (like within 30 minutes of the 
vault finishing). The problem is, when they empty both caps and close them 
back up, the remaining tapes don't eject, and the deferred eject job hangs 
for a long time (at least an hour).  It was shorter in 6.0.  Today, we 
just killed the job and ran reports from vltopmenu to genterate ftp files 
and reports, and ejected the tapes manually.  I tried ejecting 90 tapes 
manually, and only got 38 of them out.  I checked the ACSLS server and "q 
req all" showed nothing.  The eject job only showed the 39 tapes ejected, 
with the others waiting.  When I emptied and closed the cap, nothing 
progressed.  I ended up killing the eject.





<Rusty.Major AT sungard DOT com> 
06/12/2009 02:07 PM

To
scott.george AT parker DOT com
cc
veritas-bu AT mailman.eng.auburn DOT edu, 
veritas-bu-bounces AT mailman.eng.auburn DOT edu
Subject
Re: [Veritas-bu] More tapes than cap space on eject







We aren't sending that many tapes offsite, but I do have similar issues 
with the ACS libraries hanging in eject mode until the cap is emptied and 
then closed in an empty state. I really hate this operation, btw, but we 
utilize the eject notification to email the operators to inform them they 
need to go empty the cap asap. Is your crew not getting to it in enough 
time (like hours)? If  ours do not get to it in 3 or 4 hours, or don't 
shut the cap when it's empty, this causes vault to hang up because acsls 
doesn't give the all clear. 

Rusty Major, MCSE, BCFP, VCS ▪ Sr. Storage Engineer ▪ SunGard 
Availability Services ▪ 757 N. Eldridge Suite 200, Houston TX 77079 ▪ 
281-584-4693 
Keeping People and Information Connected® ▪ 
http://availability.sungard.com/ 
P Think before you print 
CONFIDENTIALITY:  This e-mail (including any attachments) may contain 
confidential, proprietary and privileged information, and unauthorized 
disclosure or use is prohibited.  If you received this e-mail in error, 
please notify the sender and delete this e-mail from your system. 


scott.george AT parker DOT com 
Sent by: veritas-bu-bounces AT mailman.eng.auburn DOT edu 
06/12/2009 11:39 AM 


To
veritas-bu AT mailman.eng.auburn DOT edu 
cc

Subject
[Veritas-bu] More tapes than cap space on eject








All,

I have a NBU 6.5.3.1 server running AIX. and a STK SL8500 Library with 
dual 39-slot caps, driven by ACSLS.  Our vault jobs are to the point where 

they are consistently more than 78 tapes, and when the deferred ejects are 

performed, the remaining x-78 tapes will not eject.  We just upgraded to 
6.5.3.1 on Wednesday from 6.0MP5, which only seemed to prolong the vault 
job.  The same symptoms ocurred in both versions, but 6.5 is really 
waiting for the final tapes to eject (or so it seems).  Based on our 
observations, it appears that this is an ACSLS problem, but I wanted to 
see if anybody had any suggestions on how to know for sure.  We have 
really been ignoring this since the operators were satisfied with ejecting 

the remaining tapes manually.  But since the deferred eject is now hanging 

until it gets good eject status of the remaining tapes (again, I don't 
know that for sure), this has become a more urgent issue. 

Has anybody seen anything like this before?

Thank you,

Scott


PLEASE NOTE: The preceding information may be confidential or
privileged. It only should be used or disseminated for the purpose
of conducting business with Parker. If you are not an intended
recipient, please notify the sender by replying to this message and
then delete the information from your system. Thank you for your
cooperation.
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu



_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
<Prev in Thread] Current Thread [Next in Thread>