🚀 go-pugleaf

In article <FLEE.89Aug25165610@shire.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes:
>Who uses IBM/4.3 (AOS) out there?  What do you run it on?  This is an
>informal survey.  Tell me about your installation.  (E-mail, please.)
>


Since your asking for replies to be emailed, would you summarize
the responses? I'm interested and I think that other people might
be as well.


Eric Brunner, IBM AWD Palo Alto
inet: brunner@monet.berkeley.edu or brunner%ibmsupt@uunet.uu.net
uucp: uunet!ibmsupt!brunner		(415) 855-4486

Yes, I will be posting a summary of responses soon; probably this
weekend.  Instant summary: fifteen responses, most of them just a
handful of RTs, and a large amount of griping.
--
Felix Lee	flee@shire.cs.psu.edu, psuvax1!flee

>In article <FLEE.89Aug25165610@shire.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes:
>Who uses IBM/4.3 (AOS) out there?  What do you run it on?  This is an
>informal survey.  Tell me about your installation.  (E-mail, please.)

At IBM Research in Yorktown Heights NY, the math department maintains about
45 RTs using 4.3 BSD UNIX (AOS).  We have been very happy with this operating 
system.  Some features that we really appreciate are full 4.3 BSD, source
code available for practically all utilities and the kernel, good X11R3,
the andrew toolkit, NFS, good asynch support, complete online manuals and
documentation, and easily available fixes distributed on usenet.  The
800 USC technical support number is useful for quick help with system
problems.  Most public domain software built for BSD UNIX systems builds
and runs on AOS with little or no modification.  What I like most about AOS
is that it is 4.3 BSD to the core and not System V with some BSD goodies
patched on as an afterthought.

Charlie Slater, Eric Brunner, and Jeff Weinstein at IBM Palo Alto have
been very helpful in helping to fix the few problems that we have had.

We use these RTs for almost all of our computing including operating systems
research, networking tool development, networking kernel research, SLIP, 
usenet, mail, gateways, printing, editing, text formatting, internet access,
VM terminal emulation, graphing...

I think that AOS has improved greatly in 1989.  Most of the problems that I've
had with it in the past have been fixed (high speed serial line support (thanks
to Charlie Slater), X11R3 (not perfect, but overall quite good with the
Megapel, and the C compiler among other parts of the OS have been greatly 
improved).

I highly recommend trying 4.3 AOS, if it is available to you.

------------------------------------------------------------------------------
| Jacob M. Parnas                    | DISCLAIMER: The above message is from |
| IBM Thomas J. Watson Research Ctr. | me and is not from my employer.  IBM  |
| Arpanet: jparnas@ibm.com           | might completely disagree with me.    |
| Bitnet: jparnas@yktvmx.bitnet      \---------------------------------------|
| Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635     |
------------------------------------------------------------------------------

Jacob Parnas, from IBM Thomas J. Watson Research Center writes:
| Charlie Slater, Eric Brunner, and Jeff Weinstein at IBM Palo Alto have
| been very helpful in helping to fix the few problems that we have had.

Based on my experience, what you say makes me suspect that Yorktown
Heights gets, ummm, slightly better service than we do.  Maybe that's
not surprising. :-)

I think very highly of the people from IBM Palo Alto that I've met.
The problem is that we have to deal with USC/ACSC as the middleman.

| ... the C compiler among other parts of the OS have been greatly 
| improved).

Errr.  The unwashed masses are holding their breath waiting for the
gcc port.  Let me be as blunt as I can: I won't use "hc" for anything
that actually needs to work.  This is not a flame, just a frightened
observation.

We'll see about the new release (2.1s) as soon as it is installed.  My
first test program will look like this:

#ifdef __STDC__		/* Oh good, a 100% ANSI conforming compiler! */
#define FOO(x) #x
static char foo[] = FOO(bar);
			/* should expand to ``static char foo[] = "bar";'' */
#endif

All previous releases of hc get this wrong; they fail to compile it.

| I highly recommend trying 4.3 AOS, if it is available to you.

Agreed.  Get real unix while you still can.

disclaimer: I'm just a grad student and my opinion doesn't count for anything.
--
Scott Schwartz		<schwartz@shire.cs.psu.edu>
"APAR's?  We don' neeed no steeenking APARS!"

In article <SCHWARTZ.89Sep8161603@shire.cs.psu.edu>, schwartz@shire.cs.psu.edu (Scott Schwartz) writes:
> 
> Jacob Parnas, from IBM Thomas J. Watson Research Center writes:
> | Charlie Slater, Eric Brunner, and Jeff Weinstein at IBM Palo Alto have
> | been very helpful in helping to fix the few problems that we have had.
> 
> Based on my experience, what you say makes me suspect that Yorktown
> Heights gets, ummm, slightly better service than we do.  Maybe that's
> not surprising. :-)
> --
> Scott Schwartz		<schwartz@shire.cs.psu.edu>
> "APAR's?  We don' neeed no steeenking APARS!"

I don't know specifically about Yorktown Heights and possibly some
backdoor help they might get, but the story I got from several people
inside IBM trying to support the RT under AIX was that real, paying
customers get first priority.  As a matter of fact, I know of one contractor
on the RT in Austin who found it faster to submit APAR's to have the
bugs he found fixed than to actually find the (obvious) bugs in the
source available to him and have them fixed directly.


-- 
A. Lester Buck		...!texbell!moray!siswat!buck

In article <448@siswat.UUCP> buck@siswat.UUCP (A. Lester Buck) writes:
| I don't know specifically about Yorktown Heights and possibly some
| backdoor help they might get, but the story I got from several people
| inside IBM trying to support the RT under AIX was that real, paying
                                            !!!
| customers get first priority.  

Do you mean AIX or AOS???  I have no doubt that AIX customers get
great support.  It's the BSD (aka AOS) folks that we are talking
about.

| As a matter of fact, I know of one contractor
| on the RT in Austin who found it faster to submit APAR's to have the
| bugs he found fixed than to actually find the (obvious) bugs in the
| source available to him and have them fixed directly.

Oh come now... faster to submit an APAR than to recompile?  No way.
Are sources for AIX even available, by the way?

--
Scott Schwartz		<schwartz@shire.cs.psu.edu>
"APAR's?  We don' neeed no steeenking APARS!"

In article <SCHWARTZ.89Sep8161603@shire.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes:
>
>We'll see about the new release (2.1s) as soon as it is installed.  My
>first test program will look like this:
>
>#ifdef __STDC__		/* Oh good, a 100% ANSI conforming compiler! */
>#define FOO(x) #x
>static char foo[] = FOO(bar);
>			/* should expand to ``static char foo[] = "bar";'' */
>#endif
>
>All previous releases of hc get this wrong; they fail to compile it.
>

Actually all releases of hc have had an ANSI preprocessor that handles 
stringizing.  You can disable cpp, and enable the ANSI preprocessor, with the
command-line option -Hnocpp.  See the hc(1) man page for this, -Hcpp, 
and other useful options.

Cpp is the default preprocessor on AOS because we weren't willing,
in 1967, to try to force a nonstandard preprocessor on customers. 
(For one thing, Berkeley source wouldn't preprocess.)  Yet, the language  
supported is ANSI C, so __STDC__ really has to be on.  I should have taken
this inconsistency more seriously; Scott's note is evidence of the confusion
my choice caused.  


Disclaimer: Don't blame my employer, blame:
Larry Breed			(415) 855-4460
uucp: uunet!ibmsupt!lmb		inet: ibmsupt!lmb@uunet.uu.net

In article <2151@ibmpa.UUCP> lmb@ghoti.uucp (Larry Breed) writes:
| You can disable cpp, and enable the ANSI preprocessor, with the
| command-line option -Hnocpp.  

I think it should be the default.  In fact, I'm going to change the
compiler driver (thank heavens we have src for that) to make it
so locally.

| Cpp is the default preprocessor on AOS because we weren't willing,
| in 1967, to try to force a nonstandard preprocessor on customers. 

1967?  Wow!  IBM is waaaaay ahead of us. :-) :-) 

But really, what is the difference between a compiler that adheres to
the new standard and a preprocessor that does?  Very little.  The
new cpp semantics are upwardly compatable with the language described in
K&R I. 

| (For one thing, Berkeley source wouldn't preprocess.)  

(Parenthetical note: the BSD source relies on a bug in the Reiser cpp
implementation that allows substitution inside of quotes.  Things like:
	#define foo(x) 'x'
This is used in the ioctl related header files.)

Only a couple header files need to be changed in order to fix this up.
In fact, the (ANSI conformant) GNU C compiler comes with a script that
will do it automagically for you.

| Yet, the language supported is ANSI C, so __STDC__ really has to be on. 

But the claim that the language is ANSI C is open to question: the
preprocessor is now offically part of the language, and if that part
is nonstandard then the whole thing is.  More importantly __STDC__ is
often used to test for the new preprocessor behavior, since the new
compiler accepts old style code without changes.

One interesting point (gleaned from comp.lang.c when this issue was
discussed there last year) is that a non conforming implementation can
-- by definition -- do whatever it wants, including defining __STDC__.

Sigh.


--
Scott Schwartz		<schwartz@shire.cs.psu.edu>
"APAR's?  We don' neeed no steeenking APARS!"