Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!tness7!tness1!sugar!ssd
From: ssd@sugar.uu.net (Scott Denham)
Newsgroups: comp.misc
Subject: Re: computer follies
Summary: Bassackwards
Keywords: mag tape problems
Message-ID: <2589@sugar.uu.net>
Date: 2 Sep 88 05:05:03 GMT
References: <5856@ihlpf.ATT.COM> <614@sbsvax.UUCP>
Organization: Sugar Land Unix - Houston, TX
Lines: 23

> In article <5856@ihlpf.ATT.COM>, trdill@ihlpf.ATT.COM (Diller) writes:
> > 
> > If you have any funny stories like this let me know, I'd be
> > interested in them.
> -- 

Here's one that's a "repeating" funny story - I'm sure I wasn't the first
victim and I know I wasn't the last.  As an oil industry service firm,
we recieve LOTS of tapes from remote sites where they are used to record
real-time information. Due to pressure of time, the tapes didn't used to
get rewound on the decks they were recorded on; a new one was popped on
and the (removable) take-up hub was toted over to a rewinder and the 
tape spun back on to an empty reel. Naturally this sometimes got fouled
up and we got the odd tape that was wound backwards (causing no end of
chagrin to rookie operators trying to hang 'em on an autoloader!) Worse
yet, the library/operations staff would sometimes "fix" the problem in
such a way as to scramble things worse. Constant read errors were a 
good indicator that something was amiss. Unfortunately when we went to
1600 BPI, the symmertry of the pre/postamble codes meant you could read
the tape backwards without error. Of course being PE, the data bore no
resemblence whatsoever to what was SUPPOSED to be on the tape!  I clearly
remember viewing with dread this horribly garbled hex dump and trying to
figure out how I was gonna explain that it was unreadable despite the
crew's claim of 'read-after-write' verification.