Undeliverable mail

[PMDF Mail Server]

The message could not be delivered to:

Addressee: TRIN4
Reason:
  %MAIL-E-SYNTAX, error parsing 'DJA1::[TRIN4.BOX1024]'

----------------------------------------

Received: from JNET-DAEMON by TRINCC.BITNET; Fri, 1 Jul 88 13:52 EST
Received: From YALEVM(MAILER) by TRINCC with Jnet id 7349 for TRIN4 at TRINCC;
 Fri,  1 Jul 88 13:52 EST
Received: by YALEVM (Mailer X1.24) id 7345; Fri, 01 Jul 88 01:41:13 EST
Date: Thu, 23 Jun 88 07:25:02 MST
From: Duke Mangum <dwm%asbf-cs.huachuca-em.arpa at huachuca-em.arpa>
Subject: labelit/volcopy.
Sender: Info-Unix distribution list <I-UNIX at TCSVM.BITNET>
To: Robert Cummings <TRIN4 at TRINCC.BITNET>
Reply-to: INFO-UNIX at BRL.ARPA
Comments: To: info-unix at BRL.ARPA

Hope someone out there has an answer to this problem :

I'm the SA on a Unisys ( Sperry ) 5000/80. A week or so ago, I was getting
ready to do some file system volcopies. The target device for the volcopies
is a 1600 bpi Cypher tape drive.  The first file system I went to volcopy
required three reels, so I executed 'labelit' on these three reels
preparatory to using them. I used labelit as follows ( the reel/volume
names changed for each reel, of course ) :

    labelit /dev/rmt/c0d0h work 1462 -n

I next used labelit to verify the labels on the three tapes. So far, so
good !    I then did the volcopy - no problems. The next file system I
needed to volcopy required two reels. I used labelit ( -n ) as above to
label these tapes; however (comma) when I then used labelit to verify the
labels, I got a 'printout' of the labels followed by the nastygram :

    "illegal blocksize=512"

Subsequent attempts to get around this, using different variations of
everything I could think of, produced no change. Finally, I decided to go
ahead and try the volcopy. The file system I was volcopying has a partition
size of 50024 blocks. At the end of the volcopy execution, the blocks
copied figure was 100048 blocks. 'Restoring' from these tapes produces
the same block count, however a subsequent 'df -t' shows the partition
to be the expected size.

What is irritating is that, if memory serves me correctly, I had this same
problem on our Gould 6032 about two years ago, but I do NOT remember what
caused it and how I finally got around it; I just remember that I did.

I called this situation in on the Unisys 'hotline', but they seem to feel
( at the moment, anyway ) that this is not a problem !

If anyone out there has a solution to this problem, I would *really*
appreciate it. If I didn't have a memory fault in this sector, it wouldn't
BE a problem. Many (hopeful) thanks in advance.