This is for database backups only.

The messages you are getting could be caused by your paths not being
correct.  I would run robtest and move tapes in and out of the drives in
question.  If the drives are ok, check the media.

Penelope



-----Original Message-----
From: paulg AT CDCNA DOT COM [mailto:paulg AT CDCNA DOT COM]
Sent: Tuesday, June 03, 2003 7:29 AM
To: Steven L. Sesar; Paul Gimpelev
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Tape unmount delay


Steve,

        Thanks for the response.  According to NBU 4.5 documentation
MEDIA_UNMOUNT_DELAY applies only to user operations.  Are you saying NBU
docs
might be inaccurate :-0 ?  Did you see these error messages by any chance(if
you have Solaris, of course):


Jun  2 00:11:31 nbackps1 tldcd[28671]: [ID 183166 daemon.error] TLD(0) key =
0x5, asc = 0x3a, ascq = 0x0, MEDIUM NOT PRESENT
Jun  2 00:11:31 nbackps1 tldcd[28671]: [ID 841094 daemon.error] TLD(0)
Move_medium error: CHECK CONDITION
Jun  2 00:11:31 nbackps1 tldd[12811]: [ID 219836 daemon.error] TLD(0) drive
7
(device 6) is being DOWNED, status: Robotic dismount failure
Jun  2 00:11:31 nbackps1 tldd[12811]: [ID 229259 daemon.error] Check
integrity
of the drive, drive path, and media

Thanks,

paulg

On Jun 2,  9:10pm, Steven L. Sesar wrote:
> Subject: Re: [Veritas-bu] Tape unmount delay
> MEDIA_UNMOUNT_DELAY is exactly what you want to tune. I ran into the very
same thing. What was happening in my environment was that NBU was issuing a
SCSI drive unmount command, before the tape was finished unwinding. Setting
MEDIA_UNMOUNT_DELAY=1800 did the trick. My drives no longer are being downed
as
a result of this condition.
>
> --Steve
>
> On Mon, 2 Jun 2003, Paul Gimpelev wrote:
>
> > Date: Mon, 2 Jun 2003 17:39:50 -0400
> > From: Paul Gimpelev <paulg AT CDCNA DOT COM>
> > To: veritas-bu AT mailman.eng.auburn DOT edu
> > Subject: [Veritas-bu] Tape unmount delay
> >
> >     Does anyone know if NBU 4.5 has a tunable "tape unmount delay"?  I
> > don't mean the MEDIA_UNMOUNT_DELAY that they use to determine how long
the
tape
> > stays in the drive post backup/restore.  I am running into an issue
where
it is
> > possible that NBU does not wait long enough for a DLT IV drive to rewind
and
> > initiates an attempt for a robotic tape move prematurely.  This in turn
causes
> > the drive to go down.
> >
> > I would appreciate any information from someone who had a similar
occurence.
> >
> > Thanks,
> >
> > paulg
> > _______________________________________________
> > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >
>
> --
> ========================================
>
> Steven L. Sesar
> Senior Operating Systems Programmer/Analyst
> UNIX Applications Services R10A
> The MITRE Corporation
> 202 Burlington Road - MS K101
> Bedford, MA 01730
> tel: (781) 271-7702
> fax: (781) 271-2600
> mobile: (617) 893-9635
> email: ssesar AT mitre DOT org
>
> ========================================
>
>
>-- End of excerpt from Steven L. Sesar


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu