From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX"  5-AUG-1992 21:36:12.26
To:	"info-vax@crvax.sri.com"
CC:	
Subj:	Clustering problem

Paul Repacholi's comment about backup/clustering issues reminds
me of some problems I saw at the Atlanta DECUS symposium that
may be related.
   I was making a saveset of the S92 sigtape material to move over
DECnet to a machine with 8mm tape (and BTW kudos are due to
Marilyn Fedele and the DEC crew for supplying us such complete
tape facilities!). This was a simple backup command
..something like
$ back/trunc/inter/block=4096 [...] [save]s92.bck/save
which was running on a 6600 and appeared to go perfectly OK. However
when unpacking it on the 4060 across the net, I encountered a number
of block lost errors, errors fixed by XOR groups, and had to pull
those files over individually. A backup/compare on the 600
revealed the problem was on the saveset at that end. There were
no soft errors indicated on the 6600 and no errors indicated 
during backup...just a corrupt saveset. Needless to say I ran
some copies with /verify to 9trk from a slower uniprocessor
to ensure the material did not get lost, but it was a disquieting
experience, which I related to some of the VMS people while there.
   During the saveset creation, I was running concurrent backups to
9trk from the same data, but it was not otherwise unusual. The disk
was, I believe, not shadowed...just a normal ra90 or some such.
   The savesets on 9trk all appeared OK when read, as did the one
written to 8mm from the 4060 (with the files that had errors separately
and individually copied over DECnet so I had 'em all).
   During the creation of the saveset, the vax 6600 was otherwise
lightly used, since this occurred fairly late in the evening. The
VMS version was 5.5.
   Anyone else seen any such thing? This could be SMP/XQP errors, or
Backup errors or something else. (I seem to recall there were some
hardware problems that had had to be fixed prior to the cluster being
usable in Atlanta, and Sunday before a DECUS symposium is not a great
time to be coolly thinking about what is causing hardware grief.)
Glenn Everhart
Everhart@Raxco.com