Alex Whites solution to end of tape recognition in UNIX

[usenet]

I really like this one --

>> Yes, it is about time that the stupid method of dealing with end of tape
>> on unix disappears.
>> I have changed the drivers locally as follows
>> 	On the write which passes the EOT mark, normal status is returned.
>> 	i.e. the block was written out correctly.
>> 	On any future write, EEOT is returned, and the block isn't written.
>> 	Thus, ordinary processes which know nothing about tapes run
>> 	correctly, and there is no problem; however since they call perror
>> 	you get a reasonable error message when they die.
>> 	However, for smart processes, you can do a MTIOCEOT which say's
>> 	that you know you've hit the end of tape, but you'd like
>> 	to write out trailer records.  It then lets you do whatever you
>> 	like; even go off the end of the tape.
>> 	On reads, you always get the block, it ignores the end of tape;
>> 	its up to you to verify that correct tape marks were written.
>> Anyhow, with this actually fairly trivial change, you can now very
>> easily change dump to correctly handle end of tape.
>> I have fixes for mt.c and ut.c if anybody wants them; you can of course
>> also have the fix to dump.

It is backwards compatible with existing UNIX programs, and retains
both the flavor of UNIX and the flavor of mainframe systems that (have
to) know how to deal with tapes sensibly.

I really hope that the USG folks are listening.  This one is worth
picking up!

UNIX grew up on minis, where the attitude toward tapes was "You got a
tape?  Ok there's the tape drive.  Go hang it yourself."  But
nowadays, most UNIX systems are run by comp centers, and users aren't
allowed anywhere near the hardware.  Now that we have solved the
problem of EOT detection, can anybody think of an equally elegant
hack to solve the problem of getting the operator to retrieve the tape
you want from the library and put it on a drive and notify you when it
is mounted, all without massive use of 'write(1)'.  While I'm at it,
can anybody suggest a way for me to retain exclusive use of the drive
as long as my tape is mounted on it?

Ideally, I would like to be able to follow the following script (or
something like it):
	
>>	hang vol_ser=123456 file=mytape mode=read_write density=1600

The operator is informed to retrieve reel number 123456 from the
library, and hang it on a (system specified?) drive with 1600BPI
capability, and bugged about it until s/he does it.  When the tape is
hung (and only then) the hang command returns after verifying that the
operator put the ring in (allowing read_write access) and checking the
ansi VOL1 label.  The filename 'mytape' in my working directory is now
(?symbolicly?) linked to the appropriate /dev/rmtxx (or whatever) device
and the device has read-write permissions for my userid only.  Since
tapes have lots of optional features (anybody ever used a seven track
tape? with two possible paritys and three possible densities, and n
possible ways of mapping 6 bits per frame to 8 bits per character!)
the hang command would need a flock of options.  Keeping track of the
syntax for all those options will be a chore.

>>	tar xf mytape
>>	rewind mytape
>>	tar cf mytape src/*

The 'rewind' command does the obvious thing.  the 'tar' commands do
their usual (not so obvious) things.

>>	unhang mytape

The tape is rewound and unloaded, and the operator is informed to
return it to the tape library.  The filename 'mytape' is unlinked from
the device and the device is returned to 'normal' modes.  The *only* way
to get the tape rewound with interlock is by using the 'unhang'
command (or ?maybe? also an ioctl() for those who insist on doing *everything*
themselves?)  There should be ioctl() interfaces for the kinds of
operations that are unique to tape drives, like rewind, forward/backward
space to EOF mark, write EOF mark, etc. and commands that do those ioctls.

Now comes the hard part --

If I log off (or the last process with file 'mytape' open exits?? -
would this mean that 'hang' would have to be a shell builtin, so 
my login shell could keep a file descriptor open to 'mytape' -- I
dunno, this is getting complicated... anyway, at least when I log off
...  but what about background processes... like I said, complicated)
the filename 'mytape' should be unlinked from the device and the
device permissions reset to 'normal' (whatever that should be -- maybe
root only?)  Lots of open issues here.  What does the net think?

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