mbs@ecsvax.UUCP (03/08/84)
<>
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 pesonally 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 own. I'd say
NO, to all that stuff in Unix.
EXEC-8 is the operating system currently available for Sperry-Univac's 1100
series of mainframes, and is trademarked by them.
Unix is a trademark of AT&T/Bell Labs
--- Michael Smith
ECU Comptuting & Information Systems
Greenville, NC 27834
{akgua!mcnc, decvax!mcnc, ittvax!ittr}!ecsvax!mbs
The opinions described above are my opinions only and do not desribe the
official opinion of the ECU Computing & Information Systems.usenet@abnjh.UUCP (usenet) (03/09/84)
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
rpw3@fortune.UUCP (03/11/84)
#R:ecsvax:-213200:fortune:26900031:000:1822
fortune!rpw3 Mar 10 18:16:00 1984
Having been peripherally involved (as a user) in DEC's efforts several
years ago to put "magtape labeling" into TOPS-10, and recently locally
in putting cartridge tape into UNIX, I urge people who are doing work on
magtape handling to get/read/understand the ANSI Magtape Labeling Standard,
especially the appendix on implementation implications. Even though it
may seem "ancient" to many people, the issues, from single-volume-single-file
through multi-volume-multi-file, are clearly laid out and addressed by the
standard.
Personally, I agree that the "funny device name" approach just doesn't hack it.
If you want "transparency" (whatever that is), the "stty" model seems to be a
better one and more consistent with overall UNIX "style" (whatever THAT is).
What seems awkward about it under UNIX is that UNIX doesn't really have
the concept of a "job", as evidenced by the hassles people have talked about
in net.unix* recently about how to kill a background process when you log off.
Another example is the various hacks (including our own "stty ... savemodes")
to get "sticky" characteristics applied to terminals across several opens
and closes, but which revert to system standard on logout.
With the "job" notion, it becomes easier to have logout or daemon processes
undo whatever allocations and modifications you did to peripherals during
your session (unless you were the superuser changing the system defaults!).
Even so, the Bourne Shell "trap 0" can provide some flavor of "job":
$ mytape=`mount -tape -density 1600 -tracks 9`
$ trap "unmount -tape $mytape" 0
$ ...
$ cat myfile > $mytape
$ ...
$ <^D>
<$mytape gets unmounted>
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065howard@metheus.UUCP (Howard A. Landman) (03/16/84)
> 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. Sorry, Rick, I'm afraid I have to cry "Bullshit!" on this one. While it is true that UNIX now runs on some hefty mainframes, it is also true that UNIX runs on quite a few microcomputers. If you look at the total market for UNIX systems I think you will find that the dollar volume of mainframes is small compared with the dollar volume of smaller systems (VAX-11/780 and below). Autoloading, streaming, rack-mountable tape drives now sell for WELL under $10K. The average price of a UNIX system is dropping, not rising. So from a statistical viewpoint your argument is meaningless. I do about half my work on a 780 and the other half on a 68000-based CAD workstation (guess whose). On the VAX I mount all my own tapes, and so does everyone else, because there is only one tape drive. On the workstation I not only mount tapes, but floppies, and paper and pens (for the plotter) as well. In other words, I want it to be as simple as it is in the new days, when UNIX runs on micros and I physically hang my own tape, and set all the options and push all the buttons myself. And it is. And I love it. **THOSE DAYS ARE JUST BEGINNING** Howard A. Landman ogcvax!metheus!howard
usenet@abnjh.UUCP (usenet) (03/19/84)
>> In other words, I want it to be as simple as it is in the new days, when UNIX >> runs on micros and I physically hang my own tape, and set all the options and >> push all the buttons myself. And it is. And I love it. >> >> **THOSE DAYS ARE JUST BEGINNING** >> >> Howard A. Landman >> ogcvax!metheus!howard >> >> Obviously Howard and I are coming at this thing from opposite ends of the question. I envy him his access to the hardware. And he is, of course, right that the statistical majority of UNIX systems in the future (if not today -- I dont want to debate that point) will be micros and super micros with single or very small numbers of users. Nevertheless, I (and many other users of UNIX systems) do not have such ready access to the hardware. The larger number of users per system for comp center type systems and the greater need for tapes on such systems makes it problematical whether the statistical majority of *tape* users in the future will be in his environment or mine. But I dont want to debate that point either. The point is that anytime you have more than one user on the system (and that includes even 'single user' systems like PC/IX if they run anything from the cron or support uucp) you have the potential for resource contention. Tape drives are a resource. Even small systems can benefit from good resource allocation software. The current resource allocation software for tape drives is inadequate not to say nonexistant. If you dont need it, you dont have to use it, but there are some of us who feel the need, and would like to see some discussion of design alternatives to give some guidance to the people at Berkeley and USG who are working on the problem right now. So far, the only proposals I have seen have been Howard's (Leave it alone. I like it the way it is.) and mine (Put an ioctl option into the tape driver to allow manipulation of the hardware and software state settings of the tape drive, and build resource control software at the command level on that basis.) Does anybody have a better suggestion? Rick Thomas ihnp4!abnji!rbt or ihnp4!abnjh!usenet
mat@hou5d.UUCP (03/20/84)
> Tape drives are a resource. Even small systems can benefit from good > resource allocation software. The current resource allocation software > for tape drives is inadequate not to say nonexistant. If you dont > need it, you dont have to use it, but there are some of us who feel The obvious solution is to build a ``user driver'' structure into the UN*X I/O architecture. Such things as tape allocation, special operator intervention, etc, can be inserted there, without changing the kernel, as local site needs dictate. Of course, someone could write a compiler for a special allocation language and ... There are some other gaps in the I/O system. Why can't a program present the same interface to another program that a terminal does? When I use programs that talk to other machines (over communication systems, not general dial-up lines) the programs that I run on the remote machine don't believe that they have a terminal; there is no ``who'' entry; opening /dev/tty fails, and others can't ``write(I)'' to me. Why can't there be user special files which trigger user I/O programs (great for deamons, locking, etc)? Why can't programs present a magtape interface to other programs? This would allow real device independence if, say, the backup program was suddenly given a read/write-once optical disk to play with. Mark Terribile hou5d!mat from Mole End
emjej@uokvax.UUCP (03/24/84)
#R:abnjh:-49700:uokvax:6100028:000:312 uokvax!emjej Mar 22 08:53:00 1984 Gee, I envy both sides of this discussion, i.e. 1) those who have access to the machine and can mount their own tapes and 2) those who work at installations at which there are staff whose job it is to handle requests such as would be issued by the proposed commands under discussion. James Jones