🚀 go-pugleaf

In article <Oct.12.18.55.52.1990.26131@constance.rutgers.edu>, 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