Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!sdcsvax!nosc!humu!uhmanoa!uhccux!helen
From: helen@uhccux.UUCP (Helen Rapozo)
Newsgroups: comp.os.vms
Subject: Re: VMS 4.6 and Backup
Message-ID: <944@uhccux.UUCP>
Date: Mon, 12-Oct-87 00:44:51 EDT
Article-I.D.: uhccux.944
Posted: Mon Oct 12 00:44:51 1987
Date-Received: Tue, 13-Oct-87 04:42:12 EDT
References: <8710070323.AA25742@ucbvax.Berkeley.EDU>
Reply-To: helen@uhccux.UUCP (Helen Rapozo)
Organization: U. of Hawaii, Manoa (Honolulu)
Lines: 47

In article <8710070323.AA25742@ucbvax.Berkeley.EDU> CHRIS@YMIR.BITNET (Chris Yoder) writes:
>[bug food]
>
>     Well, I took that giant leap of faith forward and installed VMS 4.6...
>So I'm wondering if anybody else has had the following problem, or if it's just
>a hardware problem:
>
>     Hardware in question: 11/750 (we're on a tight budget...) and TU81+. (The
>750 is the boot node of a LAVC that includes a uVAX II and a Vaxstation 2000.)
>
>$       backup/image/ignore=interlock/jour=BACKUP$JOURNAL:MONTH10_MATH2.BJL -
>                MATH2: -
>                MUA0:MATH2.bkp/block=32528/density=6250/label=D31006 -
>                        /norewind/buffer=5/nocrc/fast
>%BACKUP-F-LABELERR, error in tape label processing on _HELA$MUA0:[]MATH2.BKP;
>-SYSTEM-F-BADPARAM, bad parameter value
>
>     Both processes are running at prio 4 and have the same privileges.  I have
>attempted to place a wait statement prior to the backup command thinking that
>the tape drive needed a minute or two to synchronize, but that didn't help.
>Anybody have similar experiences?  ideas?  (Shooting that tape drive at dawn
>isn't an option  :-)  )  I am currently suspecting 4.6 backup, but I cannot be
>certain.

We have a 8200 with a TU81+ running VMS 4.3A and some times we get the
same message that you got.  The procedures that we use tend to write
two savesets on one tape.  The first saveset will always work.  It is
writing that second saveset on that same tape that we experience the 
problem.  It doesn't happen all the time, just some of the time.  As far
as what our backup command looks like it looks something like this:

$backup/ignore=interlock/jour/buffer=5/verify/nocrc/image -
   dua1: -
   mua0:save.bck/den=6250

We have been doing backups on our system since Jan. of 87 and we
never had this problem until we added /NOCRC to the backup procedures.

One explaintion from the local DEC field engineer suggest that the
tape drive may be still in the tape streamming mode.

However if we run the job again (we tend to batch our backup procedures)
it will work right (actually we run a modifed batch job to do the second
save set).  For the time being it seems like a workable trade off.
Without /NOCRC the daily backups would take 1 hour, with /NOCRC it
takes 35 or 40 minutes and there is still enough CPU power to do
other things.