CHRIS@YMIR.BITNET (Chris Yoder) (10/07/87)
[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.)
Software in question: Backup or DCL.
Problem: I have a command procedure that does the backups that I need to
do when I need to do them. It backs up various disks to tapes mounted on the
TU81+. When run as a batch job (usual case that worked fine under VMS 4.5C)
the following BACKUP command generates the errors:
$ 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
When the *exact* same command procedure is run on the console terminal (a
DECwriter III) with verify enabled it works just fine, and does *not* generate
any such errors.
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.
-- Chris Yoder Internet --- Chris@Ymir.Claremont.Edu
Harvey Mudd College Bitnet ----- Chris@Ymir.Bitnetsherr@MITRE.ARPA (Guy Sherr) (10/08/87)
Replying-to your message received on Tue, 06 Oct 87 18: 13:00 -0700
Date: Wed, 07 Oct 87 17:01:01 EDT
From: sherr
[more bug]
My experience with backup in 4.6 is as odd. I have a fairly large
configuration which (until this AM) includes two vaxes running 4.6
and one running 4.3. The two running 4.6 are an 8700 and an 11/730.
For the 8700, the tape drive is a tu81+, but for the 730 is a
Kennedy with a dilog lookalike controller.
The 8700 would not write a backup tape, with the same error
message. Since the console is a vr201+pro/380, and since the
command itself was issued (in no procedure), this may have been
considerably different. The interesting thing about this is that
I put the saveset on another disk (it was small, but an image),
and copied it to the tape successfully with the copy command.
4.6 backup was able to READ the saveset, but could not append
another to the logical end-of-tape; SAME error.
The 730 works fine. Other than being somewhat slow, it was able
to write an image backup tape (differing equipment may have made
the difference).
-- Guy Sherr, MITRE corp., McLean, VA.
-- sherr@mitre.arpa
Received: from wiscvm.wisc.edu by KL.SRI.COM with TCP; Tue 6 Oct 87 18:16:43-PDT
Received: from YMIR.BITNET by wiscvm.wisc.edu ; Tue, 06 Oct 87 20:16:35 CDT
Date: Tue, 6 Oct 87 18:13 PDT
From: Chris Yoder <CHRIS%YMIR.BITNET@wiscvm.wisc.edu>
Subject: VMS 4.6 and Backup
To: info-vax@kl.sri.COM
X-Vms-To: INFO-VAX-SUBMIT,CHRIS
[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.)
Software in question: Backup or DCL.
Problem: I have a command procedure that does the backups that I need to
do when I need to do them. It backs up various disks to tapes mounted on the
TU81+. When run as a batch job (usual case that worked fine under VMS 4.5C)
the following BACKUP command generates the errors:
$ 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
When the *exact* same command procedure is run on the console terminal (a
DECwriter III) with verify enabled it works just fine, and does *not* generate
any such errors.
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.
-- Chris Yoder Internet --- Chris@Ymir.Claremont.Edu
Harvey Mudd College Bitnet ----- Chris@Ymir.Bitnetrcb@rti.UUCP (Random) (10/08/87)
In regards to the vms backup problem, I can reproduce the problem on
any nonprivledged account and have found that if the privilege PHY_IO
is granted, the error goes away. The reason copy works is that the
tape is being handled by an ACP and not directly by your process as
with a mount/foreign. Apparently DEC messed up on this one, but it is
not a serious problem.
--
Randy Buckland (919)-541-7103
Research Triangle Institute
rcb@rti.rti.org [128.109.139.2]
{decvax,ihnp4}!mcnc!rti!rcbhelen@uhccux.UUCP (Helen Rapozo) (10/12/87)
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.