Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!holos0!lbr
From: lbr@holos0.uucp (Len Reed)
Newsgroups: comp.sys.ncr
Subject: Re: NCR Tape Formats
Keywords: Tape Quick-24 tar cpio formats compatibility
Message-ID: <1991Mar20.135201.2854@holos0.uucp>
Date: 20 Mar 91 13:52:01 GMT
References: <9906@exodus.Eng.Sun.COM> <115@crystal1.UUCP>
Organization: Holos Software, Inc., Atlanta, GA
Lines: 35

In article <115@crystal1.UUCP> jw@crystal1.UUCP (John S. Wainscott) writes:
>In article <9906@exodus.Eng.Sun.COM>, petej@itcode.Eng.Sun.COM (Pete Jolly) writes:
> [Can't read, on Sun, tape made on a Tower.

>I've seen this quite a bit when dealing with Towers.  If you create a tape
>on a Tower and want to load it on another Unix machine use this:
>
>dd if=/dev/[whatever] conv=swab | tar xvf -
>
>This will do some byte swapping so the checksum will come out correctly.

Well, it's more than the checksum, of course.  That's just an indication
that things are really messed up.

>You can use this command on the Tower while trying to load a tape from
>another system.

True.

Beware that there are differences in the Tower tapes.  I've used a V.2
system that exhbits this "btye-reversed" silliness on its QIC 24 tape.
The Tower V.3 QIC 150 tape I've used, though, is "normal."  This means
that if I make a tape on the V.2 system I can read it on the V.3 system
only if a conv=swab it!  The other direction is impossible, since the
V.3 drive only write extra-high density tapes that the QIC 24 system
can't read.

I presume that the new system 3000 (80x86 MCA) systems will use the
"normal" byte ordering on their drives.

-- 
Len Reed
Holos Software, Inc.
Voice: (404) 496-1358
UUCP: ...!gatech!holos0!lbr