Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!lll-winken!uunet!ibmarc!kurt
From: kurt@ibmarc.uucp (Kurt Shoens)
Newsgroups: comp.arch
Subject: Re: SCSI on steroids, mainframes move over
Summary: It's a good time to be a programmer
Message-ID: <1026@ks.UUCP>
Date: 22 Aug 89 17:41:55 GMT
References: <5932@pt.cs.cmu.edu>
Sender: news@ibmarc.UUCP
Reply-To: kurt@ks.almaden.ibm.com.UUCP (Kurt Shoens)
Organization: IBM Almaden Research Center, San Jose
Lines: 34

In article <5932@pt.cs.cmu.edu> butcher@g.gp.cs.cmu.edu (Lawrence Butcher)
writes about the new NCR SCSI chip and stipulates the following about
business systems:

>The biggest, fastest business computers seem to run 1960's operating systems
>without protection, and allow user programs to do I/O without OS assistance.
>My new question.  Is fast I/O all that micros need to bury mainframes?  Or
>is user level I/O needed?  If needed, how can simple hardware be built which
>allows direct user level DMA I/O?
 
I was wondering what operating system this refers to.  IBM sells "TPF"
(actually it's the latest version of the old Airline Control Program) to
airlines, etc. that comes close to this description.  I think TPF turns off
the paging hardware (makes the machine run faster, apparently), but
applications do not perform their own I/O.  I think it would be messy trying
to get applications to cooperate on the interrupt handlers.
 
My stab at answering the question:  I don't think that direct user level
DMA I/O is necessary or desirable.  User level I/O would take fewer
instructions than having the operating system do it, but there should be
plenty of mips anyway.  Hardware-wise, you'd need lots of memory bandwidth
and the ability to connect to many disks, tapes (or insert your favorite
large number of bits per cubic inch archive medium here), and networks.
Software-wise, I think you need a system that can credibly manage lots of
disks and "terminals" (anything at the other end of the wire that people use),
accommodates the kinds of applications businesses run (databases, transaction
stuff, batch, and timesharing (if still appropriate)), has error
recovery so that the system stays up mostly if pieces of it fail or
experience transient problems, and has error reporting so that when software
or hardware breaks the finger is pointed at the broken part or program.

When you've got this complicated beast running a machine room floor full
of disks, etc. it becomes hard to believe that it is still a micro.
--
Kurt Shoens, IBM Almaden Research Center, ...!uunet!ibmarc!kurt