🚀 go-pugleaf

In article <9073@ritcv.UUCP> spw2562@ritcv.UUCP (S. Wall) writes:
[a followup to 275@tut.UUCP]
>
>We have 5 masscomps here at RIT, 3 are faculty only, and the students are
>very happy about that.  They'd be even happier if all 5 were faculty only,
>but that would upset the faculty a great deal.
etc., etc., etc. -- As Casey Stengel said: "You could look it up."

Far be it from me to contradict the authoritative postulations of an
undergraduate ;-), but I cannot let this pass without comment.  I was in
on the selection of the Masscomps, and I still think they were the
right choice given the constraints we worked under (I'd have gladly
taken a Cray-2, but we were a few million dollars short).  While we had some
problems initially, these were in part due to our own over-optimism
and our unconventional use of the systems (see below).  Suffice it to
say that were we in the same position again, I'd still choose Masscomp.
Of course, having recommended Masscomp in the first place, I have a
vested interest in seeing the systems work out.  You can read what
follows with as many grains of salt as you like; I just ask that you
apply the same saline solution to Mr. Wall's fulminations.

Two years ago this month, RIT dropped a bundle of money in our laps to
improve the computing environment in the School of Computer Science and
Technology.  The kicker was that the funds had to be spent (and the
equipment had to be on site) by the end of the fiscal year (July 1).
Given this, we started looking at various vendors, using the following
guidelines:

1.	The system had to run UNIX(tm).  Essential, as we think it's the best
	general purpose development system around, and we're educating students
	who at least begin their careers as programmers.
2.	The vendor had to have a product available for testing, and had to
	commit to delivery by July 1.
3.	We wanted as much power as we could get for our money, and were willing
	to gamble a bit with new companies.  Our 8+ years of UNIX experience
	seemed sufficient to get us over any rough spots.
4.      The systems had to support timesharing.  Much as we like
	workstations, the money on hand was insufficient to purchase
	enough single user boxes to significantly reduce the load on
	our main systems (at the time, 2 11/780s).  We're talking about
	a program with ~950 undergraduates, with all but the most
	advanced courses filling to capacity each term.
5.	The systems had to support TCP/IP over Ethernet.  In retrospect, this
	was a gamble for us (as we hadn't installed 4.2 yet, and UUCP was
	our only network).

We narrowed the field to 3 vendors, two supplying 11/780 class systems (or
a bit more), and Masscomp with 5 workstations.  We chose Masscomp, in part
because they used industry-standard peripheral busses and a widely-available
microprocessor.  We also liked the idea of smaller systems dedicated to
specific purposes (R&D, graphics, systems software courses, etc.).

Well, come last fall (9/84), we ran into a lot of problems.  Some were
attributable to the newness of Masscomp systems in general, some were
due to the fact that we were essentially the only customers using Masscomps
for time sharing, and some were due to our own over optimism.  Examples:

NEWNESS		The original Masscomp serial line multiplexor would rapidly
		generate spurious interrupts when connected to a long,
		unterminated RS232 line (antenna effects), crippling or
		crashing the system.  We fixed this locally (by telling people
		"DON'T DO THAT!").  The current multiplexor handles such
		problems much more gracefully.
TIMESHARING	The initial Ethernet hardware & software would go autistic,
		and leave the attached system isolated until it was
		rebooted.  No other customers had complained about this
		because most of the Masscomps were single user machines
		in a lab; if the net went down, you leaned over and hit
		RESET.  Our machines are located far from the terminals;
		what is more, randomly rebooting a timesharing system can
		be be dangerous to your health.  The current network
		hardware and software are quite reliable.
OPTIMISM	We were real enthusiastic about "servers", and put all our
		printers (eggs) on one node (basket).  Result: if a system's
		Ethernet interface went catatonic, that system's users
		were without a printer.  We mitigated this by putting
		a cheap dot-matrix printer on every system (not
		just the Masscomps).

All in all, things were running pretty smoothly by Christmas last
year.  The only lingering problem is incompatibility between Masscomp's
RTU (SysIII + 4.1c + a pinch of paprika) and our 4.2 Vaxen.
This is more annoying than crippling, as it means we have to do some
work to get 4.2 programs running.  The newest RTU release purportedly
addresses these problems, using dual universes (much like Pyramid).  I
won't know for certain a couple of weeks: contrary to Mr. Wall's
assertions, V3.0 for our systems has not been shipped yet, and we do
not have it in any form.

In summary, Masscomp produced (and still produces) systems targeted
mainly towards real time data acquisition, process control, and
graphics.  The characteristics of such systems also make them
attractive for software development (which is why we bought them), but
until now such use has been tangential to Masscomp's marketing strategy.
Nonetheless, we've received prompt service and solid support when
problems arose (not to say that the solutions were easy or obvious, but
at least we knew the issues were being addressed).  Given that a Masscomp
MC500 is 50-60% of an 11/780 in our environment, and that we ended up
with 5 systems for much less than the cost of an 11/780, I'd say we made
the right choice.  I'd have no hesitation to go with Masscomps again if
they met our needs.

Mike Lutz

P.S. On the question of Emacs:

I've only glanced at GNU Emacs, but it seems to be chock-full of
4.2isms and Vaxisms, so my bet is it would be a bear to port to almost
any other hardware/software combination.
-- 
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{allegra,seismo}!rochester!ritcv!mjl
CSNET:		mjl%rit@csnet-relay.ARPA