Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Inquieries for "Bad Aspects" of the RT

1,156 views
Skip to first unread message

John Canati

unread,
Nov 26, 1988, 6:57:00 PM11/26/88
to
I am interested in the RT, and have been looking at it for a while. While
IBM will brag about it, and their salesmen with tell me only the goodies
it has to offer, I would like a "public opinion" as to what are the BAD
aspects of the RT. Why wouldn't I want to use it as a multiuser system
around a small business? Please mail anything you think might will help
me with my question. Thanks in advance -- John - jo...@dasys1.UUCP

Stephen P. Dyer

unread,
Nov 26, 1988, 11:56:50 PM11/26/88
to

There don't seem to me to be many large technical problems with the RT.
I can't speak for the AIX 2.x environment, but running AOS (4.3BSD) here
at MIT, given enough memory, the 2nd generation (APC) RT makes a remarkably
pleasant and fast 4.3BSD/X11/NFS/TCP-IP workstation. I understand that
the latest version of AIX has, or will have soon, many or most of the important
features of 4.3: sockets, X11, sendmail, BSD TCP/IP, long names (soon).

One problem was that the 1st generation RTs were not as competitive as
some other companies' workstations. Still, the DEC uVAX-II was no
faster than the 1st RT (perhaps slower) and it did just fine, so
technical aspects don't make all the difference. The newer APC models
and the latest enhanced APC models are quite competitive, performing
significantly better than most equivalent 68020-based products.

The biggest problem with the RT is that it has been disastrously
marketed. Hardly anyone knows anyone who has bought an RT, and
advertising is practically invisible. And just try to buy one. I
bought a used Model 20 last month, and I am still waiting to talk to
the right person at IBM about purchasing peripherals and getting an APC
upgrade, and the local IBM office is still treating me like a
curiosity instead of a customer--and, with money in my hand, yet!
Don't try to call a dealer, because most salespeople will give
you a blank stare if you don't say PS/2 after the initials "IBM".

A large company like IBM can blow a product like the RT and the red ink
barely makes a blotch in their ledgers. On the other hand, a Sun
Microsystems can not afford to do this--their early products were
everything their company was based on, and they HAD to be marketed well.
I don't see any evidence that the RT is being marketed any better
now than it was before, and I would be much more worried about a
company like IBM pulling out of an unsuccessful product line than, say,
Sun dropping the Sun 3 product line. (Hey, I bought a PC Jr, OK?)

I think the latest RT machines are technically just fine, and I'm glad
I bought mine, since I'm coming out of an environment with a lot of RT
experience, but you'll want to look at all your options before buying
a small business computer. Because of the (relatively) small market for
the RT, there is much less price competition for software than in the
DOS world, or even for the XENIX/UNIX 386 or Sun 3 world. That is,
there will probably be less software available and it will be more
expensive than that for DOS, XENIX, UNIX V/386 or the Sun 3 families.
A 386 machine running SCO XENIX 386 or UNIX V/386 might support your
multiuser needs just as well as a more expensive workstation. Or it
might not; that depends on your situation.
---
Steve Dyer
dy...@arktouros.mit.edu
dy...@spdcc.com aka ...!{harvard,linus,ima,m2c,rayssd}!spdcc!dyer

Rick Kimball

unread,
Nov 27, 1988, 7:42:04 AM11/27/88
to
From article <79...@dasys1.UUCP>, by jo...@dasys1.UUCP (John Canati):

My firm (Software Design Group) writes office automation for
insurance companies using UNIX and the customer's choice of
hardware. One of our clients selected the RT as their machine.
We've had at least two years of experience developing and using it.
Overall, I'm pleased with the machine. Here are some "personal"
observations of RT's running AIX 2.1.2 .

My biggest complaints are IBM service (lack of RT knowledge), and
the Virtual Resource Manager (it just gets in the way).

Here is a typical service call, it goes like this:

Me: "Hello, IBM service? Yes, I'm having trouble with my IBM/RT"

Operator: "RT, no you mean AT ... just bring to a local IBM dealer
the can help you."

M: "No!No! I do mean RT. It's not a PC, it's a mini computer"

O: "Well let me check if we sell those ... Ha, Ha, Yes your right"

... time passes, Tech calls.

IBM Tech: "Ya got one of those RT things ... yuck yuck, What seems
to be the problem?"

M: "The machine is hung and there are lights flashing on the led
display. The numbers are "02 C6"... We can't do anything. When
will you be here?"

I: "First I've got to work on a 36 and then a 3800 printer then I'll
be at your place"

... much time passes, Tech shows up ...

I: "This is the first time I've ever seen one of these things.
... Hmm doesn't look like the picatures though"

M: "This is one of the originals. We've had it upgraded"

I: "Well, let's run the advanced hardware diagnostics"

M: "I've already done that. It says everthing is OK"

I: "Well sorry, but that's all I know how to do. That will be $200
cash, check or credit card"

...


The VRM is a great idea if the machine is going to support multiple
operating systems at the same time, but if your only going to run
UNIX it's a real pain in the rear. First you have to set everything
up for VRM, like configuring the disks then you have to do it again
for UNIX. The VRM eats up a significant chunk of the disk for itself.

We've had relatively few complaints with ours since we added more
memory and the upgrade option. Our customer is using a 135 and seems
very pleased with it.


--
____________________________________________________________________________
Rick Kimball | Mac Source BBS, Altamonte Springs, FL DATA (407) 862-6214
| VOICE (407) 788-6875
UUCP: rick@kimbal ..!gatech!fabscal!kimbal!rick ..!ucf-cs!sdgsun!kimbal!rick

Anthony A. Datri

unread,
Nov 27, 1988, 5:28:05 PM11/27/88
to

>I can't speak for the AIX 2.x environment, but running AOS (4.3BSD) here
>at MIT, given enough memory, the 2nd generation (APC) RT makes a remarkably
>pleasant and fast 4.3BSD/X11/NFS/TCP-IP workstation. I understand that
>the latest version of AIX has, or will have soon, many or most of the important
>features of 4.3: sockets, X11, sendmail, BSD TCP/IP, long names (soon).

AIX 2.2 doesn't seem to come with man pages or a man program.

.
.
.
.
.
..
.
.
.
.
--
@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

John Myers

unread,
Nov 29, 1988, 4:24:51 PM11/29/88
to
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....@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
--

6eorge Rankin.

unread,
Nov 30, 1988, 1:57:57 AM11/30/88
to
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 (ran...@cs.uoregon.edu) Mail: George Rankin
625 E 43rd.
Eugene, Oregon
97402

Anthony A. Datri

unread,
Nov 30, 1988, 12:01:19 PM11/30/88
to
In article <37...@pt.cs.cmu.edu> j...@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...

Dennis Ferguson

unread,
Nov 30, 1988, 2:46:44 PM11/30/88
to
In article <37...@pt.cs.cmu.edu> j...@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

Charlie Pilzer

unread,
Dec 1, 1988, 12:31:07 AM12/1/88
to

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
c...@beartrk.UUCP

Robin Cutshaw

unread,
Dec 2, 1988, 8:57:48 PM12/2/88
to

I have been using AIX on the RT for development and networking for
over a year. Our organization is *very* close to IBM (as an IMAP, CSP,
and MAP for various products) and we are making the RT a major part
of our product offerings (along with some bigger iron). I've included
a summary of our experience on the RT up to this point.

The RT Hardware:

Simple to install if you don't have to open the box. If you have
to add a board or two it's not simple to figure out which slot that it
can or cannot go into. The multi-protocol adapter comes by default
with DMA channel one strapped which will not work with SNA services
due to conflicts with the ESDI defaults when using S1. Switch it
to DMA channel five and it will work. If you do want to use channel
one you will have to use the setdma command for the ESDI controller
(which is not easy to find in the reems of documentation). This will
drop DMA support for S1 however.
Some of our installs reached a snag when every time that we tried
to print something the machine would crash. This got to be a pain
because the qdaemon cranks up when you reboot and causes anything
queued to start again. The error messages could not point to the
problem, so with nothing to lose an SE changed the 4MB fast memory
and it solved the problem (go figure).
The machine can get confused as to where it's console display
adapter is. If you change it's location from say slot 4 to slot
2 it won't find it the first time if you put something else in
slot 4. Even if you clear slot 4 you are stuck and have to switch
to 5, reboot and tell diagnostics that you swapped it, then back
to 2 for the same thing. This happened to two different machines.
IBM hardware support wasn't sure why one slot was different
than another on the RT.

AIX:
2.1.X was a joke. Many, many bugs. 2.2 fixed most of the bugs
and added many new and wonderful features (rlogin, rwhod, etc). I
hope they fold all of the BSD based network daemons into inetd to
clean things up a bit. 2.2 is fast, it runs rings around our uVAXII's
running Ultrix 2.3 in CPU and file access benchmarks. If they would
clean up the BSD support and add job control we would probably convert
from our VAX's to the RT's as our primary development environment.
2.2 added much better BSD library support and fixed lot's of BSD bugs
but is still not quite there. Async for multiple dialups is still
very fragile and needs much work (no RTS/CTS flow control for high speed!).
Long file names would be wonderful!
Rlogin swaps CR's and LF's which can get confusing as to when to
hit ^J's instead of Enter's. If you rlogin from a non AIX environment,
vi won't work (a bug in their curses support). A workaround is to
rlogin back into yourself (potentially dangerous these days) and it
will fix itself.

X:
X-windows release 1.1 has many, many bugs (even with the updates).
Try echoing <ESC>[x while in xterm and watch the core dump. We
should get our 2.X release next week (X11R2) and hope to see lots of
working code.

SNA:
Not for novices! Don't do this without a license (dog, that is).
If it hadn't been for our high powered scope I would have never figured
out all of the right parameters (this is probably the worst set of
documentation in the whole AIX doc release).

SUPPORT:
The worst. When you call, it's "AIwhat, on an Rwhere?". This should
improve with more customers. The front line Austin support cannot (and
would rather not) answer any semi-technical questions. The first response
is always "have your SE come out and help with that problem". That's
probably OK for many customer installations but, we trained our SE on
the RT. She had never seen one before our account hit her desk. This
newsgroup will probably turn out to be the best forum for problems and
questions.
I have seen improvements as of late in the support. IBM has
recently put a major emphasis on RT sales and they seem to be gearing up.
It now takes two to three months to get delivery due to the larger
demand. The marketing rep's get major brownie points (Merps in the
lingo) for RT sales so we should see more activity and hopefully
more expertise.

<FLAME OFF> :-)

Even with all of the above observations and problems, we are still
very high on the RT and AIX. I attended a foo-foo AIX forum for
IBM's closest personel software developers and xMAPs, and it was
made very clear that AIX is going to be a major strategic direction
in the coming years. Major discounts and bene's are available to
software developers if you know where to find them. The upper
management in IBM is pushing hard at this AIX thing and it's starting
to seep down into the hords. We feel that with our head start in
the AIX world we will do well in most of IBM's hardware environments
in the future.

There are many, many neet and wonderful things to explore on the RT
under AIX. Our APA8C works very well with X even though it has
limited colors and resolution. Metafont is included along with
several different fonts. Graphics support libraries are quite
extensive (even though there is nothing that can show them off).
Async SLIP support seems to be there (we haven't tried it yet).
With X for DOS around the corner, my programming staff will have
X servers instead of VT320's to do their work on the RT's and on
the VAX's. Distributed services will help to grow our client
bases when they max out any given RT.

For us, the future looks good with AIX (both on the RT and on smaller
and larger hardware in the future). The performance will continue
to improve with the micro-channel and on-board CPU cache.

This group has the potential to help both the first time users and
the experts. We have an excellent resource for question and problem
resolution as our ranks grow. I offer what little help I can give
to anyone comming up in the ranks...

robin

--
----------
Robin Cutshaw {gatech,rebel}!itcatl!robin
Disc Access, Atlanta, Ga. (404)261-1264 (formerly ITC)

Ed Clarke

unread,
Dec 4, 1988, 12:56:13 AM12/4/88
to
From article <23...@stpstn.UUCP>, by a...@stpstn.UUCP (Anthony A. Datri):

> AIX 2.2 doesn't seem to come with man pages or a man program.

I think it's an optional part of AIX. I've got it on my system and /usr/bin/man
is just a shell script. The man pages are in /usr/man/cat? in either straight or
packed pre-nroffed format. The shell script also seems to be able to handle user
provided man pages in 'nroff -man' format.
--
Ed Clarke
uunet!bywater!acheron!clarke

Danny Backx

unread,
Dec 5, 1988, 8:32:27 AM12/5/88
to
In article <3...@itcatl.UUCP> ro...@itcatl.UUCP (Robin Cutshaw) writes:
>AIX:
> 2.1.X was a joke. Many, many bugs. 2.2 fixed most of the bugs
>and added many new and wonderful features (rlogin, rwhod, etc). I

Indeed. I routinely use a telnet connection to work with an RT. This was
absolutely impossible with 2.1.2. I think the Ethernet software was broken.
(AIX 2.2 is better, but still not good.)
What happens on 2.2: when a large amount of data is being sent to my terminal,
(say the output of 'ls -l /etc'), the first part gets tru, then the output
stops, and after a LONG time, it continues (also in bursts).
I suspect the timeout strategy in TCP.

In 2.1.2, the first burst got tru, and then after some time the telnet
connection broke. (Logging me out...)
Rlogin is slightly better than telnet (don't ask why), but I can't use vi
with it.

> [..] . If you rlogin from a non AIX environment,


>vi won't work (a bug in their curses support). A workaround is to
>rlogin back into yourself (potentially dangerous these days) and it
>will fix itself.

As mentioned, vi doesn't work in an rlogin session. It does under telnet.
I tried your workaround, but it didn't work for me.

-- Danny
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Danny Backx | mail: Danny Backx
Tel: +32 16 200656 x 3544 | Katholieke Universiteit Leuven
Fax: +32 16 205308 | Dept. Computer Science
E-mail: dan...@kulcs.UUCP | Celestijnenlaan 200 A
... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven
dan...@blekul60.BITNET | Belgium

Usenet file owner

unread,
Dec 5, 1988, 9:10:22 AM12/5/88
to
in article <23...@stpstn.UUCP>, a...@stpstn.UUCP (Anthony A. Datri) says:
> AIX 2.2 doesn't seem to come with man pages or a man program.

However, man is mentioned in the Commands Reference manual as being
optionally available. I checked with our sales rep and:

IBM AIX RT Online Publications
RPQP91026
Price: $50

That number is supposed to be enough to order it. You may want to verify
that number before you order. According to our rep. the online manuals
cover the Commands Ref. and the Tech. Ref.

I've always wondered, why doesn't IBM include the Tech. Ref. for AIX in
with the standard manual set? Considering the Tech. Ref. is the
essential manual for programmers....

John H. Lawitzke UUCP: ...rutgers!mailrus!frith!fciiho!jhl
Michigan Farm Bureau ...decvax!purdue!mailrus!frith!fciiho!jhl
Insurance Group ...uunet!frith!jhl
"What?!? Real computing at an insurance company?!? AND in Michigan!?!"

Usenet file owner

unread,
Dec 6, 1988, 8:01:01 AM12/6/88
to
in article <1...@icarus.kulcs.uucp>, dan...@kulcs.uucp (Danny Backx) says:
>
> Indeed. I routinely use a telnet connection to work with an RT. This was
> absolutely impossible with 2.1.2. I think the Ethernet software was broken.
> (AIX 2.2 is better, but still not good.)
> What happens on 2.2: when a large amount of data is being sent to my terminal,
> (say the output of 'ls -l /etc'), the first part gets tru, then the output
> stops, and after a LONG time, it continues (also in bursts).
> I suspect the timeout strategy in TCP.

This probably isn't TCP's fault. I work on a 3162 async terminal
attached via an RS422 card to a Model 135 runnning AIX 2.2. I used to be
hooked to a Model 125 running AIX 2.1.2. The pause on long outputs
occurs on both these systems with no Ethernet involved. From what I saw,
long outputs should be feed to pg. The subsequent pause every page is
enough inactivity to avoid being swapped out as a result of alot of
output.

Charlie Sauer

unread,
Dec 6, 1988, 3:08:56 PM12/6/88
to
In article <23...@stpstn.UUCP>, a...@stpstn.UUCP (Anthony A. Datri) writes:
> AIX 2.2 doesn't seem to come with man pages or a man program.

Yes, unfortunately, but there is a PRPQ to get man pages and a man program.
The PRPQ # is P91026, title is "IBM AIX/RT ON LINE PUBS," price is $50.

Directory structure is a subset of BSD, but the command itself is a shell
script.
--
C.H. Sauer IBM Advanced Workstations Div. uucp: cs.utexas.edu!ibmaus!sauer
11400 Burnet Road, D75/802 822: @CS.UTEXAS.EDU:sa...@ibmaus.uucp
Austin, Texas 78758-2502 aesnet: sauer@auschs
(512) 823-3692 vnet: SAUER at AUSVM6

0 new messages