petej@itcode.Eng.Sun.COM (Pete Jolly) (03/16/91)
I am having problems reading my NCR Tower 1/4 inch cartridge tapes on other Unix machines (such as Sun equipment). I have a Tower 32 with a M68020 and 2 HPSIO boards (16 ports). I don't know what format the tape drive is writing and why doing a tar tvf on a Sun 68020 based workstation won't read this tape. I have tried reading the tape using the quick-24 and quick11 and quick-3 formats but I always get: tar: directory checksum error (1 != 5663) Anyone else had such a problem or know details of the type of tape drive my NCR might have? The NCR cannot read any tapes produced on Sun equipment either so it seems they are incompatible in both directions. I Haven't been able to try other brands of machines yet. Thanks in advance. Pete J.
wescott@Columbia.NCR.COM (Mike Wescott) (03/17/91)
In article <9906@exodus.Eng.Sun.COM> petej@itcode.Eng.Sun.COM (Pete Jolly) writes: > I always get: > tar: directory checksum error (1 != 5663) With tapes there are three areas of compatibility to check. First is the format (Q-24 et. al.), streaming tape drives on NCR Towers are capable writing one format and are capable of reading that format and (except for some old models) of reading the next lower density format. The inability to read is ususally a consequence of the wrong format or of misaligned (or dirty) heads on the writer or reader. If dd(1) can read the tape, this is not the problem. The second area (probably the case here) is byte-swapping. Some multibus machines using the 68k family of processors had this big-endian vs. little- endian problem. It usually only becomes an issue when interchange among machines is required. This can be overcome with dd if=/dev/rstp/... conv=swab | .... when necessary. The newer Towers with SCSI tapes use the "right" byte order, older machines use the swapped order. The third area is the method of archiving. Use dd(1) to dump a few blocks from the tape to a file. Then use file(1) and od(1) to figure out whether tar(1) or cpio(1) was used. One can usually figure out the byte ordering this way as well. cpio archives have octal or ascii 070707 magic numbers at the start of each file. Byte-swapped it's 707070 for the ascii version and an octal 143561 for the non-ascii headers. Tar archives begin with a file name. Between byteswapping and tar vs. cpio I have been able to read tapes on Towers made on a number of different machines. Only the 3b2 seemed to go out of its way to make life difficult for "foreign" machines. Likewise, I would expect to be able to read tar and cpio tapes made on a Tower, on other unix boxes using the same techniques. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM
sleepy@wybbs.mi.org (Mike Faber) (03/19/91)
In article <9906@exodus.Eng.Sun.COM; petej@itcode.Eng.Sun.COM (Pete Jolly) writes:
;I am having problems reading my NCR Tower 1/4 inch
;cartridge tapes on other Unix machines (such as
;Sun equipment). I have a Tower 32 with a M68020 and
;2 HPSIO boards (16 ports). I don't know what format the
;tape drive is writing and why doing a tar tvf on a Sun 68020
;based workstation won't read this tape. I have tried
;reading the tape using the quick-24 and quick11 and quick-3
;formats but I always get:
;
;tar: directory checksum error (1 != 5663)
;
;Anyone else had such a problem or know details of the
;type of tape drive my NCR might have? The NCR cannot read
;any tapes produced on Sun equipment either so it seems they
;are incompatible in both directions. I Haven't been able
;to try other brands of machines yet.
;
;Thanks in advance.
;
I've had no end of trouble using NCR's tar. Even with itself. (cvf -> xvf/tvf),
so, it does;t suprise me. I use cpio almost exclusivly, now. Anybody else had
any such problems?
--
sleepy@wybbs.UUCP
Michael Faberjw@crystal1.UUCP (John S. Wainscott) (03/19/91)
In article <9906@exodus.Eng.Sun.COM>, petej@itcode.Eng.Sun.COM (Pete Jolly) writes: > I am having problems reading my NCR Tower 1/4 inch > cartridge tapes on other Unix machines (such as > Sun equipment). > > tar: directory checksum error (1 != 5663) > 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. You can use this command on the Tower while trying to load a tape from another system. John Wainscott Software Clearing House, Inc.
davel@booboo.SanDiego.NCR.COM (David Lord) (03/20/91)
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: >> tar: directory checksum error (1 != 5663) >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. >You can use this command on the Tower while trying to load a tape from >another system. This actually only happens on certain models of Towers. I believe the 600 was this way. I think all the newer Towers have normal byte ordering. I used to have to do this a lot even going from one Tower to another one of a different model, and of course we don't put the model number on the front of the box so you have to guess which way it's going to be. Typically I try to read it without byte swapping first and if that doesn't work then I use the byte swapping. Oh, and when you read a Sun tar tape on a Tower you will get an error at the end of the tape which you can just ignore. While I work for NCR my only connection with Towers is that I've used a bunch of them. Now I'm using the 486's which I like a lot better than I ever liked the Towers (or the Suns for that matter). Dave.Lord@SanDiego.NCR.com
lbr@holos0.uucp (Len Reed) (03/20/91)
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
dickh@pink_floyd.FtCollins.NCR.com (Dick.Heyman) (03/21/91)
We haven't had any trouble with tar on a Tower 32/650 to and from itself and the few times that we tried to tar to and from other machines (Suns) the problems were related either to byte swapping or incompatible tape density (QIC-150 vs QIC-24). We've been bitten by the QIC-150 to QIC-24 problem on Sun to Sun tar's also. Dick Heyman (303)223-5100 ext 323 Dick.Heyman@FtCollins.NCR.COM (NCR Voice+ 464 1323)