To:     st_laurent,szubowicz,coughlan
Subj:   Tape density idea
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
Folks -
I had a little idea which I figured should be written down so it might
be available if anyone wants to do anything with it.

Tape density has been a can of worms so far, and looks like it
will take considerable time to get done cleanly.

It occurred to me that a virtual tape driver, or perhaps a driver
intercept, could be used in principle to provide some special tape
andling for density.

On all tapes I've studied (some new ones may differ in this respect)
density needs to be set at BOT. That is, you rewind the tape if it
isn't at BOT, set the density, and write something (data or tape
marks) to get away from BOT, and thereafter the drive retains the
density. Thereafter the tape keeps that density (and compression)
setting. (8mm has some hacks that do extra rewinds and writes of
label records, and a frontend would have to know about that so that
whenever something was to be written at BOT the density could be set.)

A virtual driver frontend might generate the desired density setting
via the diagnose interface (either in kernel by building its own IRP
or from a server) and send the first data to the tape via the diagnose
interface also, sending the IRPs so cloned to mkdriver (or possibly
other drivers) to do the real work, but never letting mkdriver see
any actual WRITExBLK IRPs until it was past BOT. All other IRPs
could just be forwarded to the real tape driver.

This could be done, of course, by editing the "real" tape drivers
themselves, providing a "virtual front panel density select"
which would work like a hardware one on some drives...just ignore
all other density selections and use the selected one...but
if such a thing were ever done, it would be detached from the
normal drivers and so not introduce any messiness that way. This
means it might be thinkable as an INTERIM way to provide density
support, which could be slipped in at almost any time. Using this
technique is an example of using driver intercepts as "streams"
type modules in the unix sense, where in essence you add some
special processing in a part of the i/o stream ahead of the base
tape driver itself. My personal prejudice is of course that a VMS
streams implementation would generally have the sort of character
mentioned above.


OK, that's the idea, which you can file where you please.

Glenn Everhart
8-May-1996