[comp.unix.microport] AT&T 386 UNIX Vr3.1

bill@carpet.WLK.COM (Bill Kennedy) (08/28/88)

I have been a frequent promoter of AT&T's 386 UNIX and a vociferous
criticizer of Microport's System V/386.  I have been asked (that's
why this is so widely cross posted) several times whether or not the
AT&T product will run on a '386 AT clone, where to get it, how much
it costs.

I found it in the latest Elek-Tek catalog, several part numbers but
the most likely is order # 482109, Part # ATT1331003.  That's unlimited
run time and Development (both!) for $695.50.  That's a few dollars
more than Microport Development alone and quite a few dollars less than
the Microport equivalent.

Elek-Tek
6557 North Lincoln Avenue
Chicago, IL 60645-3986       (800) 621-1269, IL 312-982-5765, CN (800)458-9133

Major credit cards welcome.

I was also asked, numerous times, why I felt the product was superior to
Microport V/386.  I'll not do a numbered list because that might look like
a flame and I'm through with that.  The documentation is better.  Microport's
documentation opens with an apology for the crummy appearance and says it's
because they got such poor quality masters from AT&T.  Perhaps that's exactly
right, but I can read AT&T, Microport is as bad as what they apologize for.
AT&T is shipping Vr3.1 which means streams and things that will be available
Real Soon Now.  Microport (to their credit) has virtual consoles, i.e. with
a flick of a keyboard button you're on a different console.  That's missing
from what you get from AT&T.

That covers the cosmetics, why do I think that AT&T is better?  Their
compiler compiles C-Tree (an incredibly portable package) and the binary
that comes out works.  Microport compiles it but breaks when sscanf is
called.  AT&T's compiler doesn't write code that the assembler can't assemble.
AT&T's uugetty doesn't get into debates with an intelligent modem who wants
to talk about answering the phone.  AT&T's terminfo for the AT console doesn't
get lost when you're in vi.  AT&T ships unlimited users standard, not extra
$$.  AT&T's VP/ix (DOS box) works.  AT&T supports big disk drives.  AT&T is
fewer dollars for the same components.

I'd like to repeat that this is not intended as a slam on Microport.  I am
delighted with their '286 product (this is being posted with it).  When I
was flaming Microport for their '386 effort I got a lot of email asking why
I was such a big AT&T booster.  I'm not, but I am encouraged about a product
that works.  I got mine via a VAR connection that wasn't generally available,
now Elek-Tek has it in their catalog.  Admittedly $695.50 isn't pocket money,
but it's a lot fewer $$ than several alternatives and a lot more stable a
product.  Some promise/excuse, some ship.
-- 
Bill Kennedy  Internet:  bill@ssbn.WLK.COM
                Usenet:  { killer | att | rutgers | uunet!bigtex }!ssbn!bill

john@banzai.UUCP (John Canning) (08/29/88)

In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes:
>...Microport (to their credit) has virtual consoles, i.e. with
>a flick of a keyboard button you're on a different console.  That's missing
>from what you get from AT&T.

    With the AT&T port of Unix Vr3.1, you get a program named shl, which
    offers you virtual consoles (up to 8) on the main console, as well
    as on remote terminals.

>...AT&T's compiler doesn't write code that the assembler can't assemble.

    It has been my experience that the AT&T compiler will generate code
    which results in a syntax error from the assembler.  This situation
    usually crops up on certain bit-field operations which could be
    considered non-standard.  However, the C-compiler does not report
    an error, nor does lint....


>AT&T's uugetty doesn't get into debates with an intelligent modem who wants
>to talk about answering the phone.

    However, uugetty is not smart enough to program the modem when you
    first turn the system on.  You must first call a bogus number before
    the modem will be set to answer.

Bill also mentioned that the VP/ix from AT&T works.  The one experience I
had with it resulted in a big mess in the free list.  I'd hate to see
what Microport's version does.

That's all.

mike@cimcor.mn.org (Michael Grenier) (08/29/88)

From article <171@banzai.UUCP>, by john@banzai.UUCP (John Canning):
> Bill also mentioned that the VP/ix from AT&T works.  The one experience I
> had with it resulted in a big mess in the free list.  I'd hate to see
> what Microport's version does.


For whatever its worth, Microport doesn't use VP/ix perferring instead
DosMerge from Locus. I'ved used the beta release on the 386 and was very
happy with it which did a reasonable job of DOS on dumb terminals. 
Everything we tried worked well except for the Multimate print spooler
and I never really looked into it...I'm sure there was a work around.

The DosMerge product on the 286 works quite well also.

    -Mike Grenier
    mike@cimcor.mn.org

cdold@starfish.Convergent.COM (Clarence Dold) (08/29/88)

From article <171@banzai.UUCP>, by john@banzai.UUCP (John Canning):
> In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes:
>>AT&T's uugetty doesn't get into debates with an intelligent modem who wants
>>to talk about answering the phone.
> 
>     However, uugetty is not smart enough to program the modem when you
>     first turn the system on.  You must first call a bogus number before
>     the modem will be set to answer.
You could always run a little script from *rc:

cu -t -l tty001<<Q
~!sleep 1
AT
~!sleep 1
ATAA
~!sleep 1
~.
Q

But even that is unnecessary if you have DTR driven by the system, and leave
the modem set for auto-answer.  The modem I've used won't answer if DTR is low.
DTR shouldn't go high until uugetty is started.  That way, the modem doesn't
answer if the system isn't up, but always answers if the system is up.

keith@uport.UUCP (Keith Hankin) (08/30/88)

In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes:
>I have been a frequent promoter of AT&T's 386 UNIX and a vociferous
>criticizer of Microport's System V/386.
>
>I was also asked, numerous times, why I felt the product was superior to
>Microport V/386.  I'll not do a numbered list because that might look like
>a flame and I'm through with that.
>AT&T is shipping Vr3.1 which means streams and things that will be available
>Real Soon Now.

Microport is shipping Streams now.

>
>That covers the cosmetics, why do I think that AT&T is better?  Their
>compiler compiles C-Tree (an incredibly portable package) and the binary
>that comes out works.  Microport compiles it but breaks when sscanf is
>called.  AT&T's compiler doesn't write code that the assembler can't assemble.

Microport's C compiler is THE SAME COMPILER that you get from AT&T.  Any
problems with Microport's compiler should be the same with AT&T.
Perhaps you got a very new version of the AT&T C compiler, one which we
do not yet have to ship.

>AT&T's uugetty doesn't get into debates with an intelligent modem who wants
>to talk about answering the phone.

Microport's uugetty is THE SAME as AT&T's uugetty.  Perhaps you were trying
the uugetty on a ttyM device rather than tty device.  Microport has not
added any special hooks into uugetty for the ttyM devices (just the standard
AT&T code).

>AT&T's terminfo for the AT console doesn't get lost when you're in vi.

What problems have you been having with vi?  It should be okay.  There
was a new terminfo posted on our BBS, which was incorrect.  Are you using
this, perhaps?

>AT&T ships unlimited users standard, not extra.

And their price includes the unlimited user fee.  If we just had one
version, it would be the price of the unlimited version, but instead we
chose to have another version to save users who did not need the unlimited
capabilities some money.  The extra cost, by the way is royalties and 
reflects our licensing agreement with AT&T.

>AT&T supports big disk drives.

Microport Version 3.0, shipping in two weeks, will have RLL and ESDI support.

>Bill Kennedy  Internet:  bill@ssbn.WLK.COM
>                Usenet:  { killer | att | rutgers | uunet!bigtex }!ssbn!bill

-- 
Keith Hankin	keith@uport
Microport Systems

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/30/88)

In article <441@uport.UUCP> keith@uport.UUCP (Keith Hankin) writes:
| In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes:

| >That covers the cosmetics, why do I think that AT&T is better?  Their
| >compiler compiles C-Tree (an incredibly portable package) and the binary
| >that comes out works.  Microport compiles it but breaks when sscanf is
| >called.  AT&T's compiler doesn't write code that the assembler can't assemble.
| 
| Microport's C compiler is THE SAME COMPILER that you get from AT&T.  Any
| problems with Microport's compiler should be the same with AT&T.
| Perhaps you got a very new version of the AT&T C compiler, one which we
| do not yet have to ship.

I'm going to add some information on the 386UNIX C compiler. I have a
benchmark suite which I have run on about 70 machines, without serious
problems. In trying to run it under 386ix I noted that about 30% of the
programs wouldn't compile, most of which caused the compiler to emit
code the assembler couldn't use ("there is no register 25" messages) and
a few "core dumped" cases.

I have seen this on the 386ix, Microport, and Plexus versions. I have
not had a chance to try it on AT&T or Bell Tech, but I assume there is a
problem in the version used by all as a staring point. I reported the
bug to INteractive and Microport, and have no idea if it's fixed.

The Xenix compiler compiled everything, ran everything, and was faster
for the things which ran on both. This was the basis of my personal
decision to run Xenix, and is not a statement that Xenix would be best
in all applications.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

rich@jpl-devvax.JPL.NASA.GOV (Richard Pettit) (08/30/88)

In article <171@banzai.UUCP> john@banzai.UUCP (John Canning) writes:
>In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes:
>
>Bill also mentioned that the VP/ix from AT&T works.  The one experience I
>had with it resulted in a big mess in the free list.  I'd hate to see
>what Microport's version does.

Hmmm.  Strange, when I used VP/ix (second beta release) way back in
July of 1987, I got Microport windows to work (with the mouse), Ventura
desk top publishing (with the mouse), and all of the Microsoft paint,
and viewgraph crap as well.  In fact, SideKick even worked!  And this
was on a '386 box that I assembled from spare parts, complete with one
of the first post-beta '386 chips and a 10MHz '287.

I'm finding it REAL DIFFICULT TO BELIEVE that the production product does
not function correctly on warrantied hardware.  I'm a little more inclined
to believe that the people using the systems don't function correctly.

Any other VP/ix users want to tell me that I'm full of crap ?

BTW:  I have used the 386 DOSMERGE. It'll run 'hello world'. That's about it.

Rich
-- 
rich@jpl-devvax.Jpl.Nasa.Gov

pim@ctisbv.UUCP (Pim Zandbergen) (08/31/88)

In article <441@uport.UUCP> keith@uport.UUCP (Keith Hankin) writes:
>In article <145@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) writes:
>>AT&T's uugetty doesn't get into debates with an intelligent modem who wants
>>to talk about answering the phone.
>
>Microport's uugetty is THE SAME as AT&T's uugetty.  Perhaps you were trying
>the uugetty on a ttyM device rather than tty device.  Microport has not
>added any special hooks into uugetty for the ttyM devices (just the standard
>AT&T code).

Currently, Microport is shipping Unix System V release 3.0,
while AT&T is shipping release 3.1. I'm not sure about the 386,
but on a 3b2 the UUCP's that come with release 3.0 and 3.1 
are NOT THE SAME.

The Enhanced Basic Networking Utilities from release 3.1 and later
let you specify things like:
	ACU tty52,M - 2400 hayes \T
in your Devices file and
	hayes	=,-,	"" \M\dAT\r\c OK\r \EATDT\T\r\c CONNECT \m\c
in your Dialers file.

This will make cu and uucico open /dev/tty52 without waiting
for carrier, setting clocal while dialing and -clocal when a connection
has been established. This way, you only need a regural device
(one that blocks if DCD is low)
And because you can program your modem to have DCD high only when
a connection is active, incoming RING's will not be heard by
(uu)getty.

This, in my opninion, is the most elegant and efficient way to
enable dial-in and dial-out on the same line.
-- 
--------------------+------------------------------------+---------------------
Pim Zandbergen      | CTI Software BV                    | Phone: +31 70 542302 
pim@ctisbv.UUCP     | Laan Copes van Cattenburch 70      | Fax:   +31 70 512837
..!mcvax!ctisbv!pim | 2585 GD The Hague, The Netherlands | Telex: 32133 CTI NL

samperi@djs.UUCP (Dominick Samperi) (08/31/88)

In article <441@uport.UUCP> keith@uport.UUCP (Keith Hankin) writes:
|Microport's C compiler is THE SAME COMPILER that you get from AT&T.  Any
|problems with Microport's compiler should be the same with AT&T.
|Perhaps you got a very new version of the AT&T C compiler, one which we
|do not yet have to ship.

I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before
Microport existed, and it has NEVER caused the system to panic when I run
trivial programs that do some floating point operations.
-- 
Dominick Samperi
    samperi@acf8.nyu.edu             uunet!hombre!samperi
    cmcl2!acf8!samperi               rutgers!acf8.nyu.edu!samperi
      (^ ell)

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/31/88)

In article <2753@jpl-devvax.JPL.NASA.GOV> rich@jpl-devvax.JPL.NASA.GOV (Richard Pettit) writes:

| Any other VP/ix users want to tell me that I'm full of crap ?
	If it makes you happy ;-)

  The production version seems good for most business use. I did find a
game or two which didn't work, but no real problems.

| 
| BTW:  I have used the 386 DOSMERGE. It'll run 'hello world'. That's about it.

  It's not that bad as far as I can tell, but I wouldn't trade vpix for it.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

james@bigtex.uucp (James Van Artsdalen) (09/01/88)

In article <176@djs.UUCP>, samperi@djs.UUCP (Dominick Samperi) wrote:

> I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before
> Microport existed, and it has NEVER caused the system to panic when I run
> trivial programs that do some floating point operations.

Nor does the Microport compiler.  Microport has been guilty of quality
control lapses in the past, but this problem is solely Intel's.  The
latest step of the 80386 supposedly fixes this problem.  The compiler
has no control over it (well, I suppose you could do all x87 work in
kernel mode to guarantee that no paging could occur, but that is more
of an overall system design decision that a compiler issue).
-- 
James R. Van Artsdalen    ...!uunet!utastro!bigtex!james     "Live Free or Die"
Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746

keith@uport.UUCP (Keith Hankin) (09/01/88)

In article <176@djs.UUCP> samperi@djs.UUCP (Dominick Samperi) writes:
|In article <441@uport.UUCP> keith@uport.UUCP (Keith Hankin) writes:
||Microport's C compiler is THE SAME COMPILER that you get from AT&T.  Any
||problems with Microport's compiler should be the same with AT&T.
||Perhaps you got a very new version of the AT&T C compiler, one which we
||do not yet have to ship.
|
|I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before
|Microport existed, and it has NEVER caused the system to panic when I run
|trivial programs that do some floating point operations.
|-- 
|Dominick Samperi
|    samperi@acf8.nyu.edu             uunet!hombre!samperi
|    cmcl2!acf8!samperi               rutgers!acf8.nyu.edu!samperi
|      (^ ell)

3B2 machines have been around a lot longer, and a compiler for a 3B2,
with regard to floating point handling is completely different.  AT&T
has had a more difficult time (apparently) with the floating point in
80287 and 80387 environments.



-- 
Keith Hankin	keith@uport
Microport Systems

fr@icdi10.uucp (Fred Rump from home) (09/01/88)

In article <12014@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes:
[ In article <441@uport.UUCP[ keith@uport.UUCP (Keith Hankin) writes:
[ | In article <145@carpet.WLK.COM[ bill@carpet.WLK.COM (Bill Kennedy) writes:
[ 
[ | >That covers the cosmetics, why do I think that AT&T is better?  Their
[ | >compiler compiles C-Tree (an incredibly portable package) and the binary
[ | >that comes out works.  Microport compiles it but breaks when sscanf is
[ | >called.  AT&T's compiler doesn't write code that the assembler can't assemble.
[ | 
[ | Microport's C compiler is THE SAME COMPILER that you get from AT&T.  Any
[ | problems with Microport's compiler should be the same with AT&T.
[ | Perhaps you got a very new version of the AT&T C compiler, one which we
[ | do not yet have to ship.
[ 
[ I'm going to add some information on the 386UNIX C compiler. I have a
[ benchmark suite which I have run on about 70 machines, without serious
[ problems. In trying to run it under 386ix I noted that about 30% of the
[ programs wouldn't compile, most of which caused the compiler to emit
[ I have seen this on the 386ix, Microport, and Plexus versions. I have
[ The Xenix compiler compiled everything, ran everything, and was faster

For reference see also September copy of UNIX review. 386ix is compared quite
poorly speed wise to Xenix on Compaq 386/20.
-- 
{allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!cdis-1!cdin-1!icdi10!fr    
26 Warren St.             or ...{bellcore,rutgers,cbmvax}!bpa!cdin-1!icdi10!fr
Beverly, NJ 08010       or...!bikini.cis.ufl.edu!ki4pv!cdis-1!cdin-1!icdi10!fr
609-386-6846          "Freude... Alle Menschen werden Brueder..."  -  Schiller

samperi@djs.UUCP (Dominick Samperi) (09/02/88)

In article <7339@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes:
|In article <176@djs.UUCP>, samperi@djs.UUCP (Dominick Samperi) wrote:
|
|> I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before
|> Microport existed, and it has NEVER caused the system to panic when I run
|> trivial programs that do some floating point operations.
|
|Nor does the Microport compiler.  Microport has been guilty of quality
|control lapses in the past, but this problem is solely Intel's.  The
|latest step of the 80386 supposedly fixes this problem.

I should have made it clear that I was speaking about their 286 compiler, for
which they have admitted that it is a compiler bug, and they have given the
work-around: "buy another vendor's C compiler."
-- 
Dominick Samperi
    samperi@acf8.nyu.edu             uunet!hombre!samperi
    cmcl2!acf8!samperi               rutgers!acf8.nyu.edu!samperi
      (^ ell)

samperi@djs.UUCP (Dominick Samperi) (09/02/88)

In article <446@uport.UUCP> keith@uport.UUCP (Keith Hankin) writes:
|3B2 machines have been around a lot longer, and a compiler for a 3B2,
|with regard to floating point handling is completely different.  AT&T
|has had a more difficult time (apparently) with the floating point in
|80287 and 80387 environments.

Actually, the system panics when "hello, world" class programs are run
if certain simple floating point operations are done, if the program is
compiled in the large model (under System V/286), and if an 80287 is
NOT installed. If an 80287 is installed, you get away with a core dump.
-- 
Dominick Samperi
    samperi@acf8.nyu.edu             uunet!hombre!samperi
    cmcl2!acf8!samperi               rutgers!acf8.nyu.edu!samperi
      (^ ell)

wnp@dcs.UUCP (Wolf N. Paul) (09/02/88)

In article <178@djs.UUCP> samperi@djs.UUCP (Dominick Samperi) writes:
>|> I've used AT&T's C compiler under Sys V Rel. 2 on a 3B2/300 since before
>|> Microport existed, and it has NEVER caused the system to panic when I run
>|> trivial programs that do some floating point operations.
>|Nor does the Microport compiler.  ...
>I should have made it clear that I was speaking about their 286 compiler, for
>which they have admitted that it is a compiler bug, and they have given the
>work-around: "buy another vendor's C compiler."

Well, it is hardly fair to compare Uport's 286 compiler with AT&T's 3B2
offerings, or with ANYONE's offerings on the 386.

It is my understanding that System V/AT (including the C compiler, which
is AT&T's PCC) is a port done by ISC and Intel for AT&T, and that AT&T
certified it. Uport supposedly only added the drivers, just like for
their 386 product.

What I would be interested to know -- and am surprised that we don't hear more
from them -- is what people's experiences are like with AT&T's PC6300 Plus,
with UNIX -- this is a binary-compatible implementation of UNIX for AT&T's
286 machine, presumably derived from the same ISC/Intel port as Uport's
System V/AT.

What problems are there with it? With its floating point implementation?
With it's compiler? With its disk drivers and serial port drivers?

THAT would be comparing apples with apples!
-- 
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP:     killer!dcs!wnp                 ESL: 62832882
DOMAIN:   dcs!wnp@killer.dallas.tx.us    TLX: 910-380-0585 EES PLANO UD