jgm@k.gp.cs.cmu.edu (John Myers) (11/30/88)
Two disclaimers: One, these are my opinions only; two, I'm not running the absolute latest release of the software I'm discussing. The major problem I have found with ACIS 4.3 is the lack of a production-quality C compiler. ACIS comes with two C compilers, "High C" from MetaWare, Inc. (hc), and a version of the Portable C Compiler (pcc). AOS apparently comes with three compilers, pcc and two versions of hc. hc claims to be draft ANSI conformant, but really doesn't come close. A large number of Makefiles invoke hc with the "-U__STDC__" switch as a matter of course and a number of system-wide header files have constructs surrounded by "#if defined(__STDC__) && !defined(__HIGHC__)". hc has a number of bugs--the usual method of compiling a program is to run a "make", compiling what one can with hc, and then doing a "make CC=pcc" to compile the rest. Sometimes this won't work--I have one program that I simply cannot compile on the RT because it tickles bugs in both compilers. Most of the bugs I reported seem to be fixed in the latest release, but from what I read on the xperts mailing list, the latest release still has problems. hc also has some static limits on the size of internal data structures which are (by definition) too low. APAR 407, which complains about the too-low limit on the number of nodes, has been open for over a year. It also generates the "stabs" debugging information in the wrong format--when porting the GNU debugger, the programmer had to put in a heuristic to determine which compiler was used to compile the program and deal with hc as a special case. pcc would fit the bill of a production-quality compiler, but it still has a few bugs which IBM refuses to fix. They wish to "... [promote] the use of a C compiler in the IBM Academic Operating System 4.3 that follows the Proposed ANSI Standard for the C programming language (hc) over a C compiler that does not (pcc)...". Right. Since when does hc follow the draft ANSI standard? If you manage to get your programs compiled, the APC RT is a nice, fast piece of metal. I haven't used the 6152's all that much, but they leave a rubber-band-and-chewing-gum taste in my mouth. The 8514 display card (am I getting the numbers right?) for the 6152 is undocumented, or at least what documentation exists is currently IBM Confidential Restricted. IBM has this tendency to foist off monitors that are much too small. Most RT monitors around here are 3rd party. I have not had any problems with hardware service; in fact I've been fairly impressed. I am at CMU though--there are a lot of the buggers around here, so the IBM Techs are somewhat familiar with them. Stay away from AIX if at all possible. I spent three days installing AIX on a machine--managed to bring up the network and create a user before my boss figured that I had better things to do. The manuals have a low signal-to-noise ratio--I remember spending lots of time flipping through pages of blue-ink examples looking for the single item of information that I needed. I also remember some bogosities like having to specifiy at configuration time whether a given pty was to have a getty running on the slave end. -- _.John G. Myers Internet: John.Myers@cs.cmu.edu LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up "Whenever faced with a problem, some people say `Lets use AWK.' Now, they have two problems." -- D. Tilbrook --
rankin@uoregon.uoregon.edu (6eorge Rankin.) (11/30/88)
The lack of a "good" C compiler for the IBM/RT is a serious limitation.
Has anybody tried to port the gnu C compiler? We have had very good
results with gcc on our Suns, so the effort could be worthwile.
Now, for my gripes about the RT:
1) It is very silly to market a U**X machine without support for a
half-inch tape drive. My other job (Springfield Public Schools)
bought an RT to support assessment data services. (Remember the
standardized tests that you hated in high-school?) We use data
that is created by sites who still believe in EBCDIC, and think
that a cartridge tape is something that you store Commodore/64
programs on. There are a suprising number of these places in
world -- take a look at the operations center of your local bank.
The half-inch standard is a format that almost all data processing
sites can handle.
2) The VRM (Virtual Resource Manager) that AIX runs under (over?)
makes it difficult to get support from second-source software
companies. The company that developed our tape driver (CFN
Industries) had experience developing PC and Unix applications,
but had difficulties implementing the VRM code. There have been
repeated rumors that the "next" version of AIX will not have the
VRM in it, which makes it not worthwile for a company to spend time
developing applications for it.
3) IBM does not know how to support the RT. I have been annoyed by
representatives who, even now, say "RT? You must mean the XT."
One of them recently told me that IBM doesn't know whether to
support the RT as a personal computer or a minicomputer yet. (I
was asking about a software support contract.) This is a problem,
because the machine has been available for about three years.
4) RT components (disk drives, software upgrades, etc.) take several
months to arrive.
The hardware is fine: the only components that have failed us were the
battery for the real-time clock and a latch on our floor-standing case.
I would not recommend the IBM/RT for the faint-of-heart, at least until
IBM has some more direction with the product. A PC-386 with lots of memory
and disk (and SCO Xenix or the like) is probably the safest IBM U**X route
for now.
-------------------------------------------------------------------------------
These comments do not represent the official opinions of any person, entity,
or anything else that I work for.
-------------------------------------------------------------------------------
George Rankin (rankin@cs.uoregon.edu) Mail: George Rankin
625 E 43rd.
Eugene, Oregon
97402dennis@gpu.utcs.toronto.edu (Dennis Ferguson) (11/30/88)
In article <3707@pt.cs.cmu.edu> jgm@k.gp.cs.cmu.edu (John Myers) writes: > hc claims to be draft ANSI conformant, but really doesn't come close. > A large number of Makefiles invoke hc with the "-U__STDC__" switch as > a matter of course and a number of system-wide header files have > constructs surrounded by "#if defined(__STDC__) && !defined(__HIGHC__)". Hc really is draft ANSI conformant if you let it use its own preprocessor. The problem is that by default, in deference to all the system code which just won't compile with an ANSI compiler, hc uses /lib/cpp instead. The bug is that it defines __STDC__ even when using the nonstandard preprocessor. >hc has a number of bugs--the usual method of compiling a program is to >run a "make", compiling what one can with hc, and then doing a >"make CC=pcc" to compile the rest. Sometimes this won't work--I have >one program that I simply cannot compile on the RT because it tickles >bugs in both compilers. Most of the bugs I reported seem to be fixed >in the latest release, but from what I read on the xperts mailing >list, the latest release still has problems. Hc does have bugs (I also have programs I can't compile on the RT), but I find that failures to compile are most often a result of some pretty dubious (i.e. definitely non-ANSI) code. The compiler is quite strict (perhaps to a fault) and complains about things that even lint misses. It is a very good compiler if you want to do development of code you want to be portable, though, since if you can get it through hc without complaint you can be pretty sure it will compile anywhere. I like hc (sans bugs), but I realize the strictness isn't everyone's cup of tea. Pcc does have the merit of hardly ever complaining no matter how bad the stuff it's compiling is, and I also use it if I don't care enough about what I'm compiling to look and see what is wrong. Dennis Ferguson University of Toronto
aad@stpstn.UUCP (Anthony A. Datri) (12/01/88)
In article <3707@pt.cs.cmu.edu> jgm@k.gp.cs.cmu.edu (John Myers) writes: >item of information that I needed. I also remember some bogosities >like having to specifiy at configuration time whether a given pty was >to have a getty running on the slave end. I'd be happy if I could even figure out *how* to make my ptys take logins -- I've got one that works, but others that appear identically configured don't work. GRRRRRRRRR. Boy, I'd sure love man pages... -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) stpstn!aad
clp@beartrk.UUCP (Charlie Pilzer) (12/01/88)
I've been using the RT for about 2 years now and I've found it to be an underrated machine. Currently my system is a 6151 model 25 with 3 70 MB disks and 4 MB memory. I'm upgrading it soon to a model 125 (using the upgrade kit). Once the upgrade is finished, the system will have 1 by 310 MB disk and 2 by 70 MB disk, 8 MB FAST RAM and the APC card. I only have serial peripherals at the current time. I've recently upgraded to AIX 2.2 but I've been running AIX and not AOS or ACS. Not only do I use the machine in my business but I've sold the machine to clients. My clients machines are configured similar to my own. Surprisingly, I have found the machine to be quite a good small multi-user system. Up to about 8 users works quite well. AIX has proven to be stable although I've had some problems. AIX 2.2 seems to be a major improvement. The systems have not had any downtime due to either hardware or O/S problems. The downsides to the machine are: 1) The 6157 tape drive is inadequite. Its slow and doesn't hold all that much. I had some trouble with tapes at first, but find that DEI 600 foot tapes work well and allow for about 60 MB (84000 blocks). I would prefer a 120 MB tape unit or 1/2 inch tape. But at least the cartridges are compact and the tape drive doesn't take much room. I wonder if some of the slowness of the drive is due to the driver as opposed to drive itself. 2) The documentation is a strange mixture of good and bad. I think that a reasonable job of rewriting for novice users has been accomplished. Unfortunately, the new text is overly verbose if you are an experienced user. Information is scattered throughout several different books. My feeling is that "they broke the manuals"; especially if you are used to the BSD 4.x manuals. Some information is difficult to find or non-existent. 3) Support from IBM is not terrific. Very few of the customer support staff even know about RTs. However, those members of the support staff who do know the machine can get the answers. A knowledgable user would do fine with this level of support. 4) Upgrades of the software can run into some money if you want to upgrade the documentation as well. Most manuals are not included in the upgrade price. 5) The C compiler is unbelievably slow. Despite all the foregoing, I'm pleased with the machine and use it as my main development machine. I have to admit that I selected the machine prior to the wide availability of 386 machines. I suspect that if I were to choose a new machine now, it would be some kind of 386 running AT&T Sys V rel 3. Charlie Pilzer clp@beartrk.UUCP