abnjh.490 Tapes on Unix

[usenet]

Mark Callow says:

> >>	hang vol_ser=123456 file=mytape mode=read_write density=1600
> 
> I have no objection to a hang command which requests an operator to
> mount a tape.  But let's be sensible about the infor the operator
> needs.  "vol_ser" smacks of big blue and doesn't really seem necessary.
> The density field is completely redundant.  Any halfway decent tape drive
> automatically senses the density of a tape it is to read.  The density
> you write at is determined (in Unix) by the device you write to.
> 
> Some people must love typing.

I used vol_ser because thats what the ANSI standard for tape labels
calls it (actually they call it 'volume serial number', I abbreviated
it to keep from having to type all that verbiage).  But actually, I
was *not* suggesting any particular command syntax.  I chose one that
would make the semantics clear without a man page, for purposes of
illustration only.  The density field is not redundant for a tape that
is to be written.  I dont want to have to specify a particular device
name.  That is the whole point.  The system may have several drives
with the particular set of capabilities I require.  I want one of them,
but I dont care which one.

Of course, there should be defaults.
Most people would not use all the options of the 'hang' command, any more
than most people use all the options of the 'pr' command.  But they all
have to be there, because they will be needed sometime by somebody.
A good example for contemplation in the present UNIX system is the
'stty' command.  It has loads of esoteric options, each of which 
reflects an option available via an 'ioctl' system call.  Most
people dont use any but a trivial subset of those options, but they
all have to be there, to provide access to the ioctl options for
non-interactive shell scripts.

Michael Smith says:

> Concerning all of the options that you want for tapes; it sounds like what
> you are describing is the setup available under EXEC-8 from Sperry-Univac,
> and of all the mainframes I've used, they are the only ones that I know of
> that allow all that crap. Yes, crap, because even though all that stuff
> looks real nice, it becomes a real pain to use.....I would personally rather
> do it all under programmatic control myself, AND make all those write's
> to the operator----since then you know *exactly* what's going on. I'd say
> NO, to all that stuff in Unix.

As a matter of fact, I *was* using Exec 8 as my model when I wrote the
referenced article.  And you are right, Exec 8 tapes are
unnecessarily complex for the average random user to use.  But I claim
that was because of a poor system of defaults, *not* because all those
options were unneeded.	(Let me know sometime if you want a
description of the historical development of Exec 8's tape handling 'features'
 -- but dont expect me to post it to the net, most people
could care less!)  In regards to "doing it all under programmatic
control", see above regarding 'ioctl' usage.  The 'hang' command would
be just a command language level interface to those 'ioctl's.  (If you think
about it for a minute, given the architecture of the UNIX kernel, it
has to be that way!)

As I read your complaint, you want it to be as simple as it was in the
old days, when UNIX ran on minis and you physically hung your own
tape, and set all the options  and pushed all the buttons yourself.
What I have been trying to point out is that
		**THOSE DAYS ARE GONE FOREVER**.
The mainframes provide a (potentially very) complex tape interface,
because it all has to be done by remote control.  You arent allowed
in the computer room, so you cant see what the tape is doing and
correct errors on the fly.  UNIX is now running on mainframes (UNIVAC 1100
series and IBM 370 series, to my personal knowledge.  I hear rumors of
Crays and others as well.)  It is time for unix tape handling to
grow up.

If you want a concrete example where you actually need all those
options, try thinking about a script invoked by 'cron' at midnight
that backs up a very important database.  It has to be fool proof and
it has to do its job without programmer intervention.  And it has to do
it reliably.

Now, doing all that, and remaining backwards compatible with the old
interface where device names determined the option settings, and all
tape drives were publicly accessible, is an interesting problem.

What does the net think?

Rick Thomas
ihnp4!abnjh!usenet   or   ihnp4!abnji!rbt