Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!husc6!bloom-beacon!gatech!emcard!stiatl!john
From: john@stiatl.UUCP (John DeArmond)
Newsgroups: comp.dcom.lans
Subject: Re: Request for Opinions, LAN vs MULTI-USER
Message-ID: <3281@stiatl.UUCP>
Date: 19 Feb 89 22:15:50 GMT
References: <471@ralmar.UUCP>
Reply-To: john@stiatl.UUCP (John DeArmond)
Distribution: usa
Organization: Sales Technologies Inc., Atlanta, GA
Lines: 59

In article <471@ralmar.UUCP> ralph@ralmar.UUCP (Ralph Barker) writes:
>
>I am doing research on the question of "LANS vs. MULTI-USER SYSTEMS," 
>and would like to get opinions from the Net.  
>
Ralph,
Actually you should not look at it as "multiuser vs lans"  - it should
be "multiuser AND lans".  This brings into the picture the whole concept
of distributed processing.

Consider a couple of examples: 

A couple of years ago, I created a telephone operator system around a 
network (Novell in this case) of PCs.  Each operator workstation was a
cheap clone configured as a diskless workstation.  The clone ran one part
of the application - the user interfase and so on.  We built a rate server
(calculated the cost of a call; ie "rate") on a compaq 386 box.  This
server services all the workstations via a peer-to-peer protocol.  Other
boxes implemented other servers.  One 386 could handle over 75 workstations
at a time because the user interface code was executed on each workstation.
If more users came on line, so did more cpu power.  This is an example of
multiuser but not multitasking, for the most part.

Another example.  In our current software development environment, we
have a myrid of machines linked via ethernet.  This includes PCs, VAXs,
Unix systems and several SUN  386i's.  The Suns in particular, demonstrate
what can be done with multiuser AND lans.  Even though the development of
the environment is in it's infancy, already jobs can be dispatched to
the cpu with the lowest load or multiple cpus can be put to work on the 
same job.  This means that I can, for example, push a compile off onto
anohter Sun which at the moment is lightly loaded and continue working
with full response speed on my machine.  

Another aspect that most PC users can't even start to appreciate is an
integrated Email system.  This to me is perhaps one of the strongest 
features of Unix.  At the highest level, people on our team can communicate
effortlessly and without having to all be available at once.  At a lower 
level, since mail is built into standard Unix, a program can use it to, for
example, send error messages to the user and an administrator or tech 
support system.  This is especially revelant for programs that run on off-
hours.  Like backups, for instance.  This process can send Email confirming
either success or failure.

consider another example.  If we have a developer whos needs will not 
load a sun too heavily, we can buy a relatively cheap X terminal and
hang it on the ethernet.  It uses a specified Sun as its cpu.  Then
if the load develops to the point that response degrades, we can buy 
another cpu for that user.   Thus you can bootstrap another work
station up for very little initial cost and delay the large purchase of
another CPU until the workload justifies it.

Hope this helps a bit.

john

-- 
John De Armond, WD4OQC                     | Manual? ... What manual ?!? 
Sales Technologies, Inc.    Atlanta, GA    | This is Unix, My son, You 
...!gatech!stiatl!john                     | just GOTTA Know!!!