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!floyd!whuxle!spuxll!abnjh!usenet From: usenet@abnjh.UUCP (usenet) Newsgroups: net.unix,net.unix-wizards Subject: Re: abnjh.490 Tapes on Unix Message-ID: <509@abnjh.UUCP> Date: Mon, 19-Mar-84 12:25:24 EST Article-I.D.: abnjh.509 Posted: Mon Mar 19 12:25:24 1984 Date-Received: Tue, 20-Mar-84 01:57:39 EST References: <217@metheus.UUCP> Organization: ATTIS, NJ Lines: 42 >> 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