mag tape driver interface program

[utzoo!duke!decvax!ucbvax!htwalton at LL-XN]

Some years ago we wrote a rather fancy V6 mag tape driver because
we did a lot of tape work.  I am not sure that I would recommend the
driver, because it was a bit large and of course did not use IOCTL's,
and because it perhaps provides a bit more than really necessary.
However, we have an interface program to the driver, which turns out
to be just about the only program that needs to interface to
any special IOCTL calls.  The following is essentially the beginning
part of this programs manual entry:

 .so /usr/lib/tmac.tl
 .th SMT I 7/26/77
 .sh NAME
smt \*- set magnetic tape drive
 .sh SYNOPSIS
% smt unit_number [ operation ... ]

operations:

backward  sets drive so read command reads backward
-backward sets drive so read command reads forward
bpi=200	  sets 7 channel drive density to 200 bits per inch
bpi=556	  sets 7 channel drive density to 556 bits per inch
bpi=800	  sets 7 channel drive density to 800 bits per inch
dump	  sets 7 channel drive for 800 bpi dump mode
eofcl	  sets drive to write end of file on close
-eofcl	  sets drive not to write end of file on close
errms	  sets drive to print error messages on system console
-errms	  sets drive not to print error messages on sys console
even	  sets drive to even parity
file=m	  positions drive to beginning of file m = 1, 2, 3, ...
fskip=0	  positions drive to beginning of current file
fskip=j	  positions drive to beginning of j'th file after this
fskip=-j  positions drive to beginning of j'th file before this
help	  prints list of smt operations
odd	  sets drive for odd parity
ready	  if tape is not ready on drive, prints message and waits
rec=n	  positions drive to before record n = 1, 2, ... on tape
reset	  -backward dump eofcl errms odd retry -rewcl -short
retry	  sets drive to retry failed read/write 10 times
-retry	  sets drive not to retry failed read/write
rew	  rewinds tape on drive
rewcl	  sets drive to rewind on close
-rewcl	  sets drive not to rewind on close
shell	  tells smt program it is being called from shell
short	  sets drive to ignore short (noise) records
-short	  sets drive not to ignore short (noise) records
skip=k	  skips tape forward k records
skip=-k	  skips tape backward k records
standard  -backward dump eofcl errms odd retry rewcl -short
stat	  print tape status
stat=o	  interprets octal number from sys console error message
unl	  rewind tape and take it off-line (unload)
unlock	  unlock tape so others can use it
vol	  move tape to end of volume mark  (between to consecutive eof's)
weof	  write end of file mark on tape
weov	  write end of volume mark on tape
wready	  if tape not ready for writing, prints message and waits

Smt was used in shell files to pre- and post-position and set options,
and as a diagnostic tool for finding tape errors.
There was a lock/unlock system for giving unique ownership of a unit
to a particular person.  If someone else had the drive the program
asked if you wanted it, unless the shell option were present to
indicate there was noone to ask.  The stat operation was very useful:
it told you in detail exactly what happened on the last tape operation
on a unit: e.g. read obtained 35 bytes with CRC error from record 1764 file 2.
The things that can go wrong with a tape are many, and stat is
essential.  The printing of error messages on the console was a
complete loser.  The driver kept a count of the number of
tape marks previous to the current location, and the number
of records since the last tape mark, provided one had not
traveled backward over the last tape mark.
A major feature of smt is that one simply does not have to be
near the tape drive hardware in order to use it, except of course
for the actual tape mount/dismount.

Although I do not recommend the driver per se, there are a number
of reliability features it had that are worth noting.

First, there is a standard V6/7 bug: you cannot sleep at positive
priority in an open routine, least the delete key lockup your device.
This was corrected with a bsleep routine that was like sleep but
returned to its caller with an error code instead of trapping back
up the stack.  This bug was ubiquitous in V6, and also unfortunately
in V7: also, you cannot sleep at positive priority if you have
called mapalloc in read or write, but sleeping a negative priority
locks up a tape drive on which you tried to read a record from
a blank tape, unless you build timeout into the driver.

Second, on writing a lot in cooked mode all the buffers got tied up.
I guess V7's treating of writing to a rewinding tape as an error
might fix this; in any case I'd almost recommend elimination of
cooked mode.  Our V6 driver went to the effort of allowing itself
to use at most 2 buffers for writing.  We had to modify getblk to do
this.

Third, and this is important in many drivers, and unfortunately
not in most UNIX drivers, a history is kept of the registers:
those previous to loading a new command, those just after loading,
and those after command termination.  This history turns the
driver into a diagnostic: almost essential since tapes and tape controls
are rather flaky beasts.  A trace mode can be set by a
global variable, changeable using adb, to trace all commands
with any error, or all commands, on the system console.
This is for debugging flaky hardware.

Fourth, in the event of any unusual error, like UNIBUS overrun,
a power clear was issued to the tape controller.  This is also
essential for any i/o controller: the old DEC tm-11 controller
was left in an awful state by a UNIBUS overrun, in which it
failed to execute the subsequent skip reverse without giving any
error indication .  In general controllers are not graceful
about unusual failures.

The Berkeley IOCTL's look fine: I'd like to see the reliability
features just indicated included in any driver, and a better
register history available.
Also, the driver might keep a better record of tape position, including
perhaps the length in records of the last 10 files.


We have not yet moved the old V6 driver to V7.  The complaints from
users at ll-xn about the V7 driver have just about reached the limits of
endurability, but at the moment we are trying to avoid UNIX kernel
work.  We can give sources for the old V6 stuff to anyone
who is seriously interrested in working on them.