Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!OSYMH@msu2.oscs.montana.edu From: osymh@msu2.oscs.montana.edu Newsgroups: comp.sys.amiga.tech Subject: Re: SCSI Tape handler Message-ID: <0093E482.AA8FD220@msu2.oscs.montana.edu> Date: 16 Oct 90 19:19:03 GMT References: Sender: usenet@dali.cs.montana.edu Reply-To: osymh@msu2.oscs.montana.edu Organization: Systems and Computing Services, MSU Lines: 51 In article , armhold@constance.rutgers.edu (George Armhold) writes: >I've just downloaded the "BTN" SCSI tape handler from the net, but >have not been able to get it to work. I'm using a "MaxStream" SCSI >streaming tape, hung off of the A2091's external port. > >When I mount TAPE:, it tells me "Please insert volume TAPE:", and >popping a tape into the drive and clicking retry satisifies the >requester. But when I try to write to the drive, (say using 'tar', or >the formattape file,) I get an I/O error. The tapemon program reports >error code 45. I have the SCSI address of the tape drive set to 1, >and the mountlist ID number set appropriately. > >Is there anything blatantly wrong that I'm doing here? Has anyone had any >luck with this hardware combination? > >Any hints or suggestions greatly apprecited. > >Thanks, >-George And in article <1990Oct15.154914.11593@agora.uucp> billsey@agora.uucp (Bill Seymour) replies: > I'm getting the same types of errors with the Adaptec 3530, Emulex >MT-02 and Archive Viper. I believe it has something to do with the command >for READ_CAPACITY that's sent out. Possibly that puts the drive into some >mode it shouldn't be in. (Note that none of those controllers support that >command.) It's possible that just commenting out that portion of the source >and recompiling will allow it to work with your hardware. You might also >check out the tape handler from Markus Wandel that Larry posted. 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. Also, the command does not have the "fixed" bit set in byte 1, which may cause the command to be rejected if the tape drive does not support variable length blocks. The Wangtek drive I am using only supports a fixed-length block. I was able to patch the read command setup to set cdb[1] to 0x01 and not store the block number in cdb[2] and cdb[3]. Then the driver was able to read the tape. I did not do anything more with that driver, but the same thing could be done with the write command setup. I'm not sure what affect the READ_CAPACITY command would have, since the command would fail and could come up with garbage for the capacity of the tape. That could cause the end of tape to occur anywhere. The write would need to be modified to detect the End-of-Medium sense status to trigger a new tape. --- Michael L. Hitch OSYMH@MTSUNIX1.BITNET Computer Services Consultant osymh@msu2.oscs.montana.edu Office of Systems and Computing Services Montana State University Bozeman, MT USA