Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!haven!decuac!bacchus.pa.dec.com!shodha.enet.dec.com!elvira!ridder From: ridder@elvira.enet.dec.com (Hans Ridder) Newsgroups: comp.sys.amiga.tech Subject: Re: SCSI Tape handler Message-ID: <1866@shodha.enet.dec.com> Date: 23 Oct 90 19:50:48 GMT References: <0093E482.AA8FD220@msu2.oscs.montana.edu> Sender: news@shodha.enet.dec.com Organization: Digital Equipment Corporation, Customer Support Center Lines: 29 In article <0093E482.AA8FD220@msu2.oscs.montana.edu> osymh@msu2.oscs.montana.edu writes: > I ran into the same problem the first time I tried to use that tape >handler. The problem is that the handler is written for a 3-M MCD-40 >tape drive. From looking at the source, it looks like the 3-M tape >drive is block-addressable, since a block number is inserted into the >SCSI command sent to the drive. Yes, the BTN tape handler was written for the 3M MCD-40 which is a block addressed device. Sorta like a very slow disk. It does *not* act like a normal SCSI tape drive acts (or a normal SCSI disk, for that matter.) The handler doesn't look like it would deal with a normal SCSI tape very well either. Just like the MCD-40, it doesn't know about variable length records, file marks, logical EOT, etc. NOTE: All the folks with drives other than the MCD-40 who are having trouble with BTN-Tape might want to try the tape handler by Markus Wandel (?) It was posted a few days after BTN-Tape. I haven't tried it, but it looks like it was made for *real* SCSI tape drives (variable length records, file marks, etc.) >Michael L. Hitch OSYMH@MTSUNIX1.BITNET -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO