Archive 2150S behaves erratically under SCO SysV/386 3.2

[Peter Reilley]

chap at art-sy.detroit.mi.us (j chapman flack) writes:

>The system: SCO Open Desktop 1.0.1 UFE (System V/386 3.2),
>	    Adaptec 1540A SCSI host adapter
>	    one Archive 2150S QIC tape drive, SCSI ID 2
>	    one fixed disk, Seagate ST1201N, SCSI ID 0

>What it does:  The 2150S seems to like to respond to commands the SECOND
>time.  For instance, I pop a tape in the drive and say "tape load".  The
>command returns, successfully, immediately, and the drive has done nothing.
>The light remains off.  I type exactly the same command a second time,
>the light comes on, the drive whirrs, and the tape is loaded.

	The "tape load" command is totally unnecessary.   I have exactly the
same system and have a scsi analyzer.   The first time the command is
issued you get a notification that the tape has been changed, the second
time nothing.   Cartridge tapes do not need a load command.   The reason
that the tape moves the second time has to do with the internal drive 
microcode and not unix or the device driver.

>Similarly, I then do a find ... | cpio ... to write on the tape, and a
>screenful of file names flies by (about a blocksize worth, I guess) and then
>cpio gives me a write error and exits.  I repeat exactly the same command
>again, the same file names whiz by, then the drive whirrs into action and the
>command executes through to completion successfully.

>But SOMETIMES things work the FIRST time.  I haven't found a pattern.

This can occur when you have a marginal tape or a dirty drive head.

>"tape status"  ALWAYS  shows:

>     status :
>soft errors : 0
>hard errors : 0
>  underruns : 0

>no matter what.  The man page lists messages like "Beginning of tape,"
>"Write protected," "No tape," etc.  I get the above non-message under all
>circumstances.

This data structure is cleared when the device is closed.   You can only
obtain the status when the device remains open.   If the device is open
you can access the /dev/xct0 device to get the status.   This control
device is indicated by the high bit on in the minor number.

>If I do a tar to a non-write-enabled tape, the file names whiz by on my
>screen and the command completes successfully.  The tape just never moves,
>is all.  (The FIRST TIME I try it, I might get a "write error" message, but
>that's just the same message I get the FIRST TIME with a write-enabled tape.)

The SCO driver has a large buffer in the device driver to enhance streaming.
You can write to the buffer before the tape drive is accessed.  Only when
the tape is accessed does the driver relalize that the tape is write 
protected.

>There's more.  I've been trying to use the no-rewind-on-close device to put
>multiple files on one tape.  (What fun is a 150MB tape otherwise?)  My idea
>has been to write a small "header" file, then tar something, say, then
>another header file, tar something else, etc.  I could write a little shell
>script to read the header file and then either tar in the tarchive or skip
>it with a "tape rfm" and read the next header, etc.  (If there already exists
>a utility for doing this, I'd like to hear about it.)

>But when I put, say, a tarchive on the tape, and then write a little header
>file, in MOST cases it works right and a "tape rfm" at the beginning of the
>tarchive will skip it and the next read gets the header file.  BUT SOMETIMES
>IT DOESN'T!  The little header gets appended to the end of the tarchive, so
>"tape rfm" skips BOTH of them and the next read FAILS.  tar, of course, now
>finds rubbish at the end of the tarchive.

I don't understand what could be causing this,  but be aware that buffering,
if improperly done, can cause a misconception between what you think that 
you are writting to the tape and what gets put on the tape.   QIC format
tape drives are fixed at 512 block size and buffering can make you think
that you can write or read other block sizes.

>What the Dickens is going on?  Is the SysV SCSI tape driver this buggy?  Is
>it a SCO problem?  Is my tape drive busted?  (I got it used....)  What do I
>need to make it work?

The Archive drive is quite good most of the time.   You should occassionally
clean the heads and tapes do go bad.   The driver does have some odd
characteristics, especially with variable block tape drives, but seems
pretty good with the Archive drive.
-- 
>>>>>>>>>>>>>>>> Peter Reilley ..... pvr at wang.com <<<<<<<<<<<<<<<<<<<<<<<
                     Well, that about says it.