Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site geowhiz.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!uwvax!geowhiz!karsh From: karsh@geowhiz.UUCP (Bruce Karsh) Newsgroups: net.unix-wizards,net.works Subject: Problems with Masscomp Message-ID: <233@geowhiz.UUCP> Date: Mon, 2-Sep-85 06:09:00 EDT Article-I.D.: geowhiz.233 Posted: Mon Sep 2 06:09:00 1985 Date-Received: Tue, 3-Sep-85 01:43:59 EDT Reply-To: karsh@geowhiz.UUCP (Bruce Karsh) Organization: UW Madison, Geology Dept. Lines: 212 Xref: watmath net.unix-wizards:14679 net.works:1125 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