Aucbvax.1397
fa.unix-wizards
utzoo!duke!decvax!ucbvax!htwalton@LL-XN
Sat May 23 03:30:24 1981
mag tape driver interface program
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.


-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <[email protected]>
of http://communication.ucsd.edu/A-News/


This Usenet Oldnews Archive
article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.