🚀 go-pugleaf

In article <L-VMCTR%92112415245210@VM1.CC.UAKRON.EDU> Ken Koester <MAINT2@ERS.BITNET> writes:
>On Tue, 24 Nov 1992 18:54:53 GMT Mark A. Stevens said:
>>. . . .  We are forever closing a
>>tape set because of I/O errors caused by a bad tape or flaky drive.  Then
>>you have to have the copies around just to be sure they match, sort of,
>>since VMARCHIVE twins are not exact copies any more than VMBACKUP twins
>>are exact copies.
>>
>Not sure I understand the above.  Are you referring to separate reel-to-reel
>devices with possibly different head alignments (so that a tape can only be
>read on the drive that wrote to it)?

We have *OLD* 3420 drives that create errors on *OLD* tapes that we got
for free (no comment, please.)  Given those two conditions when we
write on a tape we can get PE burst errors, I/O errors, data checks,
machine checks, and so on.  When this happens, VMARCHIVE abends and the
systems programmer has not set up things so the large red light and
warning sirens go off to alert the operators that there is a problem.

Next time the tape(s) is/are used, VMARCHIVE complains and we have to
close the tape set and go on to the next new *OLD* tape set and
repeat.

We have had alignment problems, too.  Thank God most of those were backup
tapes that eventually were scratched.
-- 
Mark A. Stevens                           Phone:    708-534-0200
Systems Programmer                        Internet: xmas@uxa.ecn.bgu.edu
Educational Computing Network             BITNET:   XMAS@ECNUXA.BITNET
Board of Governors Universities           VMSHARE:  ECE/MARK