Problems with Masscomp

[Bruce Karsh]

  We have been having lots of problems with our Masscomp systems.  I
would like to hear if other sites are having similar problems.  Perhap
somebody from Masscomp could respond to this.

  1) Ethernet

     a) Telnet and rlogin both drop characters on long printouts.  If
	you telnet or rlogin into another lightly loaded machine, and
	you do, for example, an ls -l /bin /usr/bin, you will start to
	get garbled lines after the first few hundred come out.

        The upshot of this is that users can telnet and rlogin if they
        don't try to look at too many lines.
        

     b) Ftp often can not transfer more than one file successfully.  It
        gives messages about lines not being opened.

        The upshot of this is that users can ftp if they don't try to 
        transfer more than 1 file at a time.

     c) We installed the Berkeley 4.2 talk program.  It crashes the system
        if both talkers are sending at a high rate.  The nature of the crash
        is rather unusual.  All terminals on the system go into a state where
        they drop lots of characters, seemingly at random.  Terminal input
        seems to be processed normally.  At first I thought that the stty
        modes were screwed up.  But I checked by doing a stty -a > file
        before I rebooted.  When the machine came back up, I diff'ed file
        with the output of a stty -a command, and both were identical.

        The upshot of this is that users can use talk if they are careful
        to type slowly.

     d) The subroutine call bindings used by Masscomp are not the same as
        those used in BSD4.2.  I don't know if they are == to anybody else's
        bindings.  [ If they are, I don't think Masscomp says so anywhere
        in their manuals.]

        The upshot of this is that if you want to take Ethernet source from
        net.sources, you've got a lot of converting to do.  And if you
        send sources out to the net, everybody else has a lot of converting
        to do.

     e) Masscomp does not support Ethernet gateways.

        The upshot of this is that it is hard to get onto things like ARPA-NET.

     f) Rlogin and telnet sometimes go into a mode where they will not accept
        a password.

        The upshot of this is that you have to login as superuser, take the
        machine off the net, and bring it up again.  In order to do this, you
        throw off any existing Ethernet links to you machine.

  2) Terminal I/O

     a) The serial ports drop characters on input, especially during uucp.  You
        get screenfuls of buffer overrun messages and/or missed interrupt
        messages on the console.  Masscomp claims that their serial ports
        are good to 2400 baud.  We don't have any problems to report on
        serial output.

        The upshot of this is that you should forget about receiving
        serial data at sustained rates of more than 2400 baud.

  3) Graphics

     a)  The graphics terminal crashes a lot for a lot of different reasons.
         It is fairly easy for a user program to cause a crash.  When this
         happens, the only way to reset the graphics terminal is to reboot
         the system.  [Note, we have 16 termial ports hooked up to the
         system, spread all over our building.  Rebooting it is very unpopular.]

         The upshot of this is that it is difficult to run a multi-user system
         based on Masscomps.

     b)  The subroutine bindings for the Masscomp graphics are unusual, to say
         the least.  Our users find them pretty hard to understand and to use.
         They are in no way device independent.  They don't come with man pages.
         Some operations are  slow.  For example, it takes a minute and a half
         to blank out the screen by setting pixels to white.  The built-in
         operations like fill box are fast though.

         The upshot of this is that Masscomp's graphics library is not for
         beginners.  And it isn't very good for pixel by pixel imaging.

      c) We have a six plane system.  We feel that we should be able to get
         32 different colors on the screen at once.  We can, sort of.  Color
         map register zero is always set to black and can not be changed.
         So you can have any color you want there, as long as it's black.

         The upshot of this is that you will often have to put kluges into
         programs to get around the color map zero problem.

      d) The graphics library links in about 80K of stuff into your a.out
         file.

         The upshot of this is that graphics programs load slowly.  You should
         also consider getting an Eagle disk to hold your graphics binaries.

      e) Masscomp supports the Precision Visuals graphics package.  This is
         what they tell you to get if you complain about their graphics
         package.  The Precision Visuals package is supposed to support device
         independent graphics.  On other systems, it does.  On Masscomps, it
         supports the Masscomp color display and a exactly one HP plotter.

         The HP plotter doesn't work with some of their extended routines.
         A lot of our users would like to hook up their plotter to their
         terminal so they can work from their offices.

         The upshot of this is that you don't really get device independent
         graphics with your Masscomp.

      f) The link time for graphics jobs using the Precision Visuals package is
         quite long.  Not only does it include the Masscomp graphics libraries,
         but it also includes a whole bunch more.

         The upshot of this is that you can go eat lunch while your graphics
         job is compiling.  (Just be sure that you have enough disk space
         before you go.)

      g) It is usually pretty fatal to suspend (i.e. ctrl-z) a graphics job.

         The upshot of this is that you should not suspend graphics jobs.

      h) The keyboard on the graphics terminal does not have auto-repeat
         keys.

         The upshot of this is that you have to hold the repeat key alot.

  4) Service

      a) Service contracts are expensive.  Expect to be charged about $10K/yr
         for a typical system.

         The upshot of this is that you are forced to choose between buying more
         workstations or keeping the ones you've got on service.

      b) Masscomp does not supply enough hardware documentation for you to maintain
         a system yourself.

         The upshot of this is that if you don't have a service contract, you
         should cross your fingers very firmly.

      c) While hardware problems are repaired pretty quickly, software problems
         are not fixed at all.  All you can do is fill out a bug report form
         (unbelievably called a Software Quality Report) and hope that the
         problem is fixed in some later release.  Often they are not.

         If you are having problems with software bugs, they will let you talk
         to a software engineer If you are covered under a software contract.
         The software engineer will politely tell you that you are experiencing
         a software problem and that you should send in a Software Quality Report.

         If you are not covered under a service contract, they will also let you
         talk to a software engineer, for $80/hr.  They first ask you for a
         purchase order number to bill to.

         The upshot of this is that there are an infuriating number of software
         bugs in the system that never get corrected.

  5) Data acquisition and control processor.

      a) The Data acquisition and control processor is, I think, the reason that
         most people buy Masscomps.  The DACP crashes systems.  Masscomp seems
         to show no interest at all in fixing DACP problems.  They do include a
         reasonably complete, but by no means exhaustive bug list with the DACP.
         It is 18 pages long!  It's dated November 1984!

         The upshot of this is that you should get practiced at rebooting the
         system when you develop DACP code.  And you should try to think of more
         than one way to approach your problem so you have more options when you
         run into DACP bugs.

  6) Source code.

      a) Masscomp claims that you can get source for their system.  In our case,
         we paid $2000 and got an out of date version.  We complained, and were
         told that we would get a new version.  This has never happened.   They
         are just about ready to bring out what they claim is a major new release
         of the system (Version 3).  We wonder if we will see the source for our
         current version sometime very close to when version 3 is released.

         The upshot of this is that you can fix problems in the system if the
         source code supplied has not changed too much from the source code for
         the version that you are running.

      b) You don't get source code for the graphics processor, the serial card,
         or the DACP.  Of course, these are some of the biggest problem areas
         that we have.

         The upshot of this is that you can't fix some of the most troubling
         bugs yourself.

  7) Sales.

      a) The sales people have an infuriating habit of not returning telephone
         calls.  This is especially annoying when you are trying to purchase
         things from them.  We have purchased about $200,000 worth of stuff
         from them in the past.  You would think they would be helpful when
         we are having problems.

         The upshot of this is that you should not count on you salesman to be
         helpful when you run into problems.
-- 

Bruce Karsh
U. Wisc. Dept. Geology and Geophysics
1215 W Dayton, Madison, WI 53706
(608) 262-1697
{ihnp4,seismo}!uwvax!geowhiz!karsh