Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site abnjh.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!abnjh!usenet From: usenet@abnjh.UUCP (usenet) Newsgroups: net.unix,net.unix-wizards Subject: Re: abnjh.490 Tapes on Unix Message-ID: <497@abnjh.UUCP> Date: Fri, 9-Mar-84 12:11:16 EST Article-I.D.: abnjh.497 Posted: Fri Mar 9 12:11:16 1984 Date-Received: Sat, 10-Mar-84 12:37:20 EST References: <2132@ecsvax.UUCP> <1762@rlgvax.UUCP>, <7175@watmath.UUCP> <490@abnjh.UUCP> Organization: ATTIS, NJ Lines: 86 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