sco, mpx, multi processor
Larry Snyder
>In October we took delivery of a twin processor Olivetti LSX 5030
>machine.
>This machine has 128mb of ram and two 1.4gb hard disks and of course
>two 33mhz 486 cpu.
>Unfortunately this machine does not stay up for more than a couple of
>days at a time, Olivetti has changed memory, one cpu, and last week
>the mother board that holds all the expansion card, but still it
>panics.
>I am curious if it is the machine or ODT 2.0, does anyone use MPX with
>multi processor machines, preferably Olivetti's LSX machines, if so,
>could you mail me to tell me if you are experiencing problems, we are
>about to receive 13 more of these and one 4 processor machine and I
>was interested to see how everyone else is doing ?
>BTW, we are about to hoick out SCO and give AT&T SVR4 a go, but I'm
>curious.
Try SVR4 and see what happens. Does Olivetti officially support
SCO?
It is quite possible that there is some internal tweaking to be
done with SCO MPX..
--
Larry Snyder internet: la...@gator.use.com
keeper of the Gator uucp: uunet!gator!larry
Jerry Rocteur
>je...@incc.com (Jerry Rocteur) writes:
>
>
>>In October we took delivery of a twin processor Olivetti LSX 5030
>>machine.
>
>>This machine has 128mb of ram and two 1.4gb hard disks and of course
>>two 33mhz 486 cpu.
>
>>Unfortunately this machine does not stay up for more than a couple of
>>days at a time, Olivetti has changed memory, one cpu, and last week
>>the mother board that holds all the expansion card, but still it
>>panics.
>
>>I am curious if it is the machine or ODT 2.0, does anyone use MPX with
>>multi processor machines, preferably Olivetti's LSX machines, if so,
>>could you mail me to tell me if you are experiencing problems, we are
>>about to receive 13 more of these and one 4 processor machine and I
>>was interested to see how everyone else is doing ?
>
>>BTW, we are about to hoick out SCO and give AT&T SVR4 a go, but I'm
>>curious.
>
>Try SVR4 and see what happens. Does Olivetti officially support
>SCO?
In Belgium they are because the European Commision's Informatics
Directorate is going the SCO way so Olivetti support and sell it, mind
you their expertise on SCO is hmmmmmmm.
>It is quite possible that there is some internal tweaking to be
>done with SCO MPX..
Well when you see above what they have changed on the machine, you
wonder, now it appears they say that they have a patch to allow for
128MB ram and are going to try that....
>--
>Larry Snyder internet: la...@gator.use.com
>keeper of the Gator uucp: uunet!gator!larry
--
__^__ __^__
( ___ )------------------------------------------------------------( ___ )
| / | Jerry Rocteur Email: je...@InCC.COM | \ |
| / | Independent Computer Consultants | \ |
George Wenzel
multiprocessor enviroments? There are a number of manufacturers making
multi-processor machines that look quite interesting, they can't /all/ be
designed for SCO only, can they?
I have heard a rumor from a friend at Dell that they had multi processor
support, but when I asked him to get details, he came back empty handed.
So what else it out there?
George
--
George Wenzel | Real/Time Communications
geo...@wixer.cactus.org 459-4391 | "faster, smarter and costs less..."
Get your wixer account today! | "Hardware solutions for the real world."
-----------------------------------------------------------------------------
p...@ankh.metrolink.com
I was wondering, what is available other than SCO MPX that supports
multiprocessor enviroments? There are a number of manufacturers making
multi-processor machines that look quite interesting, they can't /all/ be
designed for SCO only, can they?
I have heard a rumor from a friend at Dell that they had multi processor
support, but when I asked him to get details, he came back empty handed.
So what else it out there?
Microport has SVR4 MP for a variety of PC platforms. You can reach them
at 408.438.8649.
Pax.
Disclaimer: Microport OEM's (includes) Metro Link's Metro-X envrionment
in their product.
--
Metro Link Incorporated. 2213 W. McNab Rd. Pompano Beach, Florida 33069
Killer X11.5 (133k xstones) and OSF/Motif for SVR3, SVR4.[012], SCO, QNX
UnixWare, LynxOS, DESQview/X, Venix, ISC, Solaris, Pyramid, SunOS
Voice: 305.970.7353x402 Fax: 305.970.7351 Email: p...@ankh.metrolink.com
--
Metro Link Incorporated. 2213 W. McNab Rd. Pompano Beach, Florida 33069
Killer X11.5 (133k xstones) and OSF/Motif for SVR3, SVR4.[012], SCO, QNX
UnixWare, LynxOS, DESQview/X, Venix, ISC, Solaris, Pyramid, SunOS
Bob Palowoda
: I was wondering, what is available other than SCO MPX that supports
: multiprocessor enviroments? There are a number of manufacturers making
: multi-processor machines that look quite interesting, they can't /all/ be
: designed for SCO only, can they?
:
: I have heard a rumor from a friend at Dell that they had multi processor
: support, but when I asked him to get details, he came back empty handed.
:
: So what else it out there?
Last I heard Wyse released their 740MP ESIA machine. 1 to 5 33Mhz CPU's
runs Wyse Unix 3.2, Wyse SVR4 5.4. Out of all the ports I know are
MP, fully symmetrical are Microport SVR4, Denstiny, Solaris and Wyse's
Unix. I believe all of the ports where based on the Sequent sources from
USL. From useing all of the above ports, all of them where more stable
than SCO's MPX. Not only that I beleive that in the future these will
be much more cost/performance effective. At least we shall see some
more muilti-cpu machines in the future not only for UNIX (or SCO, SCO
dosn't like to be called unix because they only run applications) but
for NT also. I beleive NT is going to help the MP UNIX market because
the above vendors should have an easy time porting over to hardware
designed for multi-cpu NT.
---Bob
palo...@netcom.com
--
---
Bob Palowoda
palo...@netcom.com
Fred Rump from home
>I was wondering, what is available other than SCO MPX that supports
>multiprocessor enviroments? There are a number of manufacturers making
>multi-processor machines that look quite interesting, they can't /all/ be
>designed for SCO only, can they?
>So what else it out there?
There is always OSF/1 and promises. :-)
Other than that it's still pretty much of a propriatery game. There are rumors
of a SYS V r4 multi-processor version out there but I've yet to hear of one in
real life.
Fred
--
W. Fred Rump office: fr...@COMPU.COM "A man's library is a sort of
26 Warren St. home: f...@icdi10.compu.com harem" - Emerson (1860)
Beverly, NJ. 08010
609-386-6846 bang:uunet!cdin-1!icdi10!fr
Larry Snyder
> Last I heard Wyse released their 740MP ESIA machine. 1 to 5 33Mhz CPU's
> runs Wyse Unix 3.2, Wyse SVR4 5.4. Out of all the ports I know are
> MP, fully symmetrical are Microport SVR4, Denstiny, Solaris and Wyse's
> Unix. I believe all of the ports where based on the Sequent sources from
> USL. From useing all of the above ports, all of them where more stable
I'm glad to see hardware vendors still getting involved with Unix. Wyse
is taking a system approach which is the way to do things.
> than SCO's MPX. Not only that I beleive that in the future these will
How much is Wyse charging for the OS (SVR4 and 3.2?).
> be much more cost/performance effective. At least we shall see some
> more muilti-cpu machines in the future not only for UNIX (or SCO, SCO
> dosn't like to be called unix because they only run applications) but
Yes, let's not forget that -- SCO isn't Unix -- it's, well - SCO.
--
Larry Snyder internet: la...@gator.rn.com
Fred Rump from home
> Last I heard Wyse released their 740MP ESIA machine. 1 to 5 33Mhz CPU's
> runs Wyse Unix 3.2, Wyse SVR4 5.4. Out of all the ports I know are
> MP, fully symmetrical are Microport SVR4, Denstiny, Solaris and Wyse's
> Unix. I believe all of the ports where based on the Sequent sources from
> USL.
Alan Deny told me that AT&T/NCR also have symmetrical multi-processor systems.
These may actually have some sales out there. Between Palowoda's four horsemen
certainly the count must be rather inconsequential even if they are stable.
Certainly an MPX environment will become standard fare, but so far there is
but one main player much to the chagrin of our friendly SCO bashers club.
Corollary is presently selling an NT development box to get a head start in
the game.
Bill Campbell
:I was wondering, what is available other than SCO MPX that supports
:multiprocessor enviroments? There are a number of manufacturers making
:multi-processor machines that look quite interesting, they can't /all/ be
:designed for SCO only, can they?
:I have heard a rumor from a friend at Dell that they had multi processor
:support, but when I asked him to get details, he came back empty handed.
:So what else it out there?
Sequent was one of the first players in the symmetric
multiprocessing marketplace. They produce very high performance
machines (with prices to match).
Bill
--
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Software
UUCP: ...!thebes!camco!bill 6641 East Mercer Way
uunet!camco!bill Mercer Island, WA 98040; (206) 947-5591
SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
Bob Palowoda
: palo...@netcom.com (Bob Palowoda) writes:
:
: > Last I heard Wyse released their 740MP ESIA machine. 1 to 5 33Mhz CPU's
: > runs Wyse Unix 3.2, Wyse SVR4 5.4. Out of all the ports I know are
: > MP, fully symmetrical are Microport SVR4, Denstiny, Solaris and Wyse's
: > Unix. I believe all of the ports where based on the Sequent sources from
: > USL.
:
: Alan Deny told me that AT&T/NCR also have symmetrical multi-processor systems.
: These may actually have some sales out there. Between Palowoda's four horsemen
: certainly the count must be rather inconsequential even if they are stable.
I somehow doubt the it is "inconsequential". I would venture to say that
thier will be a larger marketplace for multi-processor SVR V.4's in the
future over SCO's.
: but one main player much to the chagrin of our friendly SCO bashers club.
I'm not SCO bashing. I just don't think SCO has big plans to push
MPX on "as many symmetrical" hardware architectures as USL and Novell will.
Strickly my opinion.
: Corollary is presently selling an NT development box to get a head start in
the game.
Did Corollary release any symmetrical hardware? Which processor?
Why buy a development sysatem while such companies as Wyse is selling
the real machine for MP NT. I'm sure Altos is going to sell for NT
also. Hey really I'm just curious about what's going to happen.
I did at one time do some contract work writing the network test suites
for Wyse and I was impressed with the MP ESIA machine. But I still
beleive there has to be more MP machines out there. What's wrong with
with the idea of cheap MP units? By the way you wouldn't beleive
the prices Wyse is offering the NT Developers for the machines.
I can imagine Dell is going to do the same thing. Still if you
think about it the multi-cpu RISC systems from Sun and SGI are
much further ahead. Where's the Intel competition in this area?
Larry Snyder
>palo...@netcom.com (Bob Palowoda) writes:
>> Last I heard Wyse released their 740MP ESIA machine. 1 to 5 33Mhz CPU's
>> runs Wyse Unix 3.2, Wyse SVR4 5.4. Out of all the ports I know are
>> MP, fully symmetrical are Microport SVR4, Denstiny, Solaris and Wyse's
>> Unix. I believe all of the ports where based on the Sequent sources from
>> USL.
>Alan Deny told me that AT&T/NCR also have symmetrical multi-processor systems.
>These may actually have some sales out there. Between Palowoda's four horsemen
>certainly the count must be rather inconsequential even if they are stable.
In your opinion if they are running something other than SCO than is it
inconsequential.
I don't know why you have to be so rude and make such brainless comments.
Larry Snyder
>I somehow doubt the it is "inconsequential". I would venture to say that
>thier will be a larger marketplace for multi-processor SVR V.4's in the
>future over SCO's.
Remember that SCO is based on technology that is 5 years old.
Tom Haapanen
>> I somehow doubt the it is "inconsequential". I would venture to say that
>> thier will be a larger marketplace for multi-processor SVR V.4's in the
>> future over SCO's.
la...@trauma.rn.com (Larry Snyder) writes:
> Remember that SCO is based on technology that is 5 years old.
Sheesh. SVR4 is based on technology that is 20 years old (as is SCO). Do
you still remember AT&T Bell Labs, V5, V6, V7 and the other V's that we
never saw? And being 20 years old doesn't make Unix any less attractive to
me...
[ \tom haapanen "i don't even know what street canada is on" -- al capone ]
[ to...@wes.on.ca "trust the programmer" -- ansi c standard ]
[ waterloo engineering software "to thine own self be true" -- polonius ]
Gary Whisenhunt
Destiny is not MP capable. Most (but not all) of the symmetric MP ports for
SVR4 that are available today are based on SVR4MP (based on SVR4 Version 4)
from USL. The multiprocessor work for this was originally developed by
a consortium of x86 companies and licensed by USL. NCR and Unisys sell
products based on this.
Stacey Campbell
In article <C1q1E...@trauma.rn.com> la...@trauma.rn.com (Larry Snyder) writes:
>Yes, let's not forget that -- SCO isn't Unix -- it's, well - SCO.
Larry raises an interesting point. How exactly do you define something
to be Unix? When I started here in '89 SCO was just ramping up their
Unix effort and a lot of the machines were running Xenix. I had just
come from HCR where we ran a straight port of System V 3.1 (or was it
3.0?) on a number of VAX 750 machines. The port was done as a research
project by a single HCR engineer who is still at SCO Canada and occasionally
posts to some of these newsgroups.
As far as I was concerned that was "real" Unix. Any program I wrote
on another System V 3 machine would compile without source modifications
on the VAX. When I moved to SCO they had just completed some Xenix work
that involved moving the stock System V 3.1 libraries to Xenix, so I
was amazed to see all my old VAX source compile and run unchanged on
a 386. Some of my old BSD based source (written on a Pyramid mini) even
compiled and ran on an old 286 box running an earlier version of Xenix.
Hell, I thought that was Unix too.
It seems clear that a few perceptions are changing. Some of my stock
System V source trees are unchanged from the time they were compiled on
that VAX, and they compile and run fine under any operating system I
have used at SCO including SCO Xenix 2.3.2, SCO Unix versions 1, 2, 3,
and 4, as well as stock Unix System V 3.2 running on a 3b2. This, however,
no longer appears to mean that a system is Unix. Larry, I suspect, is of
the school of thought that unless a system can run any binary produced
on a stock System V R4 then it may not be Unix.
A thing that has muddied the issue for some people is the extra work
that most Unix vendors had to add to early System V releases to make
the systems usable for "Real World Applications". Stock System V R3
didn't allow a process to sleep() for less than 1 second, there was no mouse
support, even a basic library, like curses, required for normal
applications didn't support alternate character sets or color until 3.1
and 3.2 respectively. Things like support for high-end graphics cards
and networking had sparse to no support. A lot of this support was
added or itegrated by SCO engineers, since it wasn't forthcoming from
elsewhere, who attempted to stick to whatever official or unofficial
standards were about at the time. When the standards did become official
we tried to stay with them, or at least get them to stay with us. ;-)
Just recently things have got even more interesting, if not downright
complicated. In the good old days at HCR (way before my time ;-) a
Unix source tape would come along from the gang at AT&T, then the people
at HCR would compile it and do the porting work, which frequently
involved e-mail flowing between the AT&T and HCR Unix sites. AT&T's
Unix market (if it can be called that) never seemed to conflict with
the few commercial Unix houses out there, which were basically SCO and
HCR in the early years.
Then USL emerged as a general wholesaler of Unix source to the new
porting houses which now include all the brand names we are familiar
with such as Interactive, Microport, Dell, ESIX, Univel as well as a
bunch of other hardware vendors who wanted Unix on their systems.
The System V source tapes were still coming from an "independent"
source who had no real direct market competition with any of the people
or companies using the source.
Now with USL being purchased by Novell, and with Univel presumably
selling directly into the same market as the other folks who have
been getting their source from USL it will be interesting to see what
lies in the future of System V. Anyone care to reveal what their
crystal ball says?
--
Stacey Campbell - sta...@sco.com - uunet!sco!staceyc
"mathematically alive"
Stacey Campbell
[I hope you don't mind me changing the subject since it is getting away
from the original MPX problem. This article attempts to describe what
some of the old timers at SCO have been up to in the last decade or so,
I am not one of these people ;-]
In article <C1ru5...@trauma.rn.com> la...@trauma.rn.com (Larry Snyder) writes:
>Remember that SCO is based on technology that is 5 years old.
Our technology base is actually older than that Larry. One of the SCO
old timers (who now works on high performance graphics software in my
group amongst other things) dropped by my office and I asked him to
refresh my rusty and incomplete knowledge of the history of Xenix.
Xenix came from Version 7 which was modified by folks at Microsoft to
run on small systems. Selected parts of System III were later added,
and when System V 3.0 came out some important pieces were also
incorporated. So Xenix is effectively based on technology that was
developed back in the '70s (which of course was based on some even
earlier operating system and compiler work from the late '60s).
The people here who replaced the kernel virtual memory subsystem in
Xenix, or added support for new classes of hardware bring all that
development and integration experience to our latest releases, and
still manage to keep us running fast, stable, and conformant with
the seemingly endless standards we support.
It's fair to say there is a great depth of engineering knowledge at SCO
that covers issues such as small systems performance, software stability,
and compatability. As the Intel architecture has evolved, so has our
engineering knowledge and our technology. As such I struggle to see how
being based on something that was originally written 5 years ago is a priori
an issue when obtaining software. If I had to throw out or attempt to
replace every piece of software I use simply because its first rev was
written more than 5 years ago I would be one mighty unhappy developer.
Greg Andrews
>palo...@netcom.com (Bob Palowoda) writes:
>
>>I somehow doubt the it is "inconsequential". I would venture to say that
>>thier will be a larger marketplace for multi-processor SVR V.4's in the
>>future over SCO's.
>
>Remember that SCO is based on technology that is 5 years old.
>
Don't look now, Larry, but your WorldBlazers are based on technology
that's SEVEN years old! And that's only the 18,000+ bps versions of
PEP. Counting back to PEP's actual birth would tack on another year.
(Turbo-PEP is only different from the previous form (18,000 bps) only
by expanding the constellation and adding trellis coding, which aren't
new techniques. See the V.32 reference below.)
The ZyXel and HST 16,800 bps modulations are, like HST 14,400, V.32bis,
and HST 9600, based on V.32. According to my copy of the "Blue Book",
V.32 was first introduced in 1984, more than eight years ago.
Care to guess whether TCP/IP passes your five-year age test?
Larry, if using five year old technology upsets you, then you ought to
be terrified every time you look at your modems and network connections.
This is silly. Are you stooping to spreading fear, uncertainty and
doubt because you have no other arguments against SCO?
-Greg
--
::::::::::::::::::: Greg Andrews ge...@netcom.com :::::::::::::::::::
ObGuindon: The fad of throwing tofu, Japanese bean curd, at the
ceilings of restaurants to see how long it will stick
has really gotten out of hand in some cities.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Andrew Mullhaupt
>Remember that SCO is based on technology that is 5 years old.
And counting...
Later,
Andrew Mullhaupt
Clayton Haapala
>
>The people here who replaced the kernel virtual memory subsystem in
>Xenix, or added support for new classes of hardware bring all that
>development and integration experience to our latest releases, and
>still manage to keep us running fast, stable, and conformant with
>the seemingly endless standards we support.
>
I have wondered, on occasion, if there were/are pieces of the kernel
that are much BETTER than the original source tapes of System III/V7
were? Obviously, Xenix's memory model would make for such an
opportunity. For another, in my subjective opinion, Xenix handles
large numbers of small files MUCH better than later AT&T kernels,
though it does suffer when doing mass copies of large files.
Any observations you porting folks care to share?
--
Clay Haapala "Behold the Holy Pogo Stick"
cl...@haapi.mn.org
Bob Palowoda
I think you are very confused. There is SystemV 4.2 (Destiny) and at the
same time SystemV 4.2 ES.MP which is enhanced security multi-procssor.
Now you can call the latter what ever you want. Ok so there are 4.0
MP ports and 4.2 MP ports I don't think there is going to be a binary
compatibility issue here. So who was in the consortium? Anyone want
to take a guess?
---Bob
Bob Palowoda
: > palo...@netcom.com (Bob Palowoda) writes:
: >> I somehow doubt the it is "inconsequential". I would venture to say that
: >> thier will be a larger marketplace for multi-processor SVR V.4's in the
: >> future over SCO's.
:
: la...@trauma.rn.com (Larry Snyder) writes:
: > Remember that SCO is based on technology that is 5 years old.
:
Sheesh. SVR4 is based on technology that is 20 years old (as is SCO). Do
: you still remember AT&T Bell Labs, V5, V6, V7 and the other V's that we
: never saw? And being 20 years old doesn't make Unix any less attractive to
: me...
Whoah, hold on there. I think you are both right and wrong so why don't we
(as in everyone) decide to stop babbling and look at some of the details.
Nothing wrong about useing old technology until it's appearent it really
outdated. SCO originally wrote the MPX on a piece of asymmeticial piece
of hardware. They where by no means the first to do this, I was working
on a similar hardware/os designed 15 years ago. It became appearent the
the price/performance of the asymmetrical design was becomeing out dated.
This was just about the time Collary released thier asymmetical design
out to the public in PeeCee Land. But now symmetrical designs are become
more cost effective. Now set me straight if I am wrong SCO's MPX would
take alot of software development to rewrite the kernel to adapt it
to symmetical hardware. Fred said they did it with the Altos machine.
Maybe he can get some of the engineers to comment on this port.
For the most part if you take into account the above, Larry is right
old software technology hinders developers, old developers will bitch
and complain that they have to learn something new etc etc, on and on.
I think developers who want to work with new software technology just
get frustrated on how long it takes SCO to come out with it. Yet the
old technology of BSD is still concidered advanced by some of the
marketplace. Of coarse I will have to give SCO some sort of slack.
SCO dosn't manufacture hardware. In writing a MP UNIX OS you are really
tied to the hardware architecture. If Colloary or Altos makes the slightest
change in hardware they screwup SCO's port. The same applies to SVRV.4
MP systems it's just that all those system hardware manufactures have
source lic's and do the port.
In no place between SCO's MPX and SVRV.4's MP's is there any standard
in hardware software combination the will help the Intel marketplace
with either UNIX or NT. SVRV.4 are trying to move in the right direction.
Is SCO moveing in the right direction?
Of coarse I work RISC based MP systems now so it dosn't matter much to
me. I'm just curious.
---Bob
palo...@netcom.com
Roger B.A. Klorese
>I think you are very confused. There is SystemV 4.2 (Destiny) and at the
>same time SystemV 4.2 ES.MP which is enhanced security multi-procssor.
>Now you can call the latter what ever you want. Ok so there are 4.0
>MP ports and 4.2 MP ports I don't think there is going to be a binary
>compatibility issue here. So who was in the consortium? Anyone want
>to take a guess?
The Intel Multiprocessor Consortium that did the SVR4 MP work included
Wyse, NCR, Unisys, and some others. SVR4.2 ES/MP was largely done by
Sequent.
--
ROGER B.A. KLORESE +1 415 ALL-ARFF
rog...@unpc.QueerNet.ORG {ames,decwrl,pyramid}!sgiblab!unpc!rogerk
"Sometimes you wake up. Sometimes the fall kills you. And sometimes, when
you fall, you fly." -- N. Gaiman
Evan Leibovitch
sta...@sco.COM (Stacey Campbell) writes:
>In article <C1q1E...@trauma.rn.com>
la...@trauma.rn.com (Larry Snyder) writes:
>>Yes, let's not forget that -- SCO isn't Unix -- it's, well - SCO.
>Larry raises an interesting point.
Dammit, no he doesn't.
It's a flat-out lie, stated for no other reason than to provoke.
You should all know better than to justify this crap (as well as his
"5-year-old-technology" crack) with reasoned answers.
>Now with USL being purchased by Novell, and with Univel presumably
>selling directly into the same market as the other folks who have
>been getting their source from USL it will be interesting to see what
>lies in the future of System V. Anyone care to reveal what their
>crystal ball says?
This is a different issue so I'll take a stab at it, and change the
subject line. I've added GNU and Linux groups into the cross-posting,
but have directed followups to the single common-ground newsgroup,
comp.unix.pc-clone.32bit.
The first time that the owner of UNIX was considered a competitive
threat in the market, was when AT&T bought a piece of Sun. That, as
you may all recall, led to the creation of an anti-AT&T/Sun cabal
which eventually became the Open Software Foundation. OSF became the
creator of DCE, Motif, and a whole pile of confusion in the marketplace.
I believe that Novell does not want to repeat this scenario. Since it
does not sell hardware, Novell is not a threat to the full-system
vendors like IBM, DEC or Sun. Thankfully, TCP/IP is too firmly
entrenched for Novell to use UNIX to force IPX on the market, but
the recent events mean that more UNIX systems will have improved
connectivity with existing NetWare installations (a Good Thing).
It's in Novell's best interest to have UNIX continue to be seen as an
open system, at very least one that's a lot more open than anything
Microsoft does. So I don't expect UNIX International to go away, as it
serves as an excellent way for Novell/USL to respond to industry and
marketplace needs.
The two question marks in my mind caused by the aquisition are (a) the
academic community and (b) the Intel UNIX market.
While universities have generally stayed away from commercial UNIX, it
seems that VAXen running BSD have generally given way to BSD-derived
SunOS running on SPARCstations. Now that Sun is committed to an R4-based
product, the lines between commercial UNIX and academic UNIX are to blur
even further.
In its place, I see a new community -- based on Linux and GNU rather
than BSD -- springing up to serve the non-commercial counter-culture.
It's significant to me that this environment has shifted from what was
previously ivory-tower elitist (in the days before BSD4.3, VAXen were
hardly cheap, and you still needed a UNIX source license to run BSD) to
something (like Linux on a 386SX) that just about anyone can afford.
As for the market for commercial UNIX on Intel platforms, I believe
there will indeed be some shakeups, but they can't be too heavy-handed.
Novell must run the fine line between a desire to stabilize the industry
and the need to be seen as a neutral supplier of source.
How will it turn out? I don't know if this is conjecture or wishful
thinking, but here goes:
USL and Intel will co-operate on a major effort to recruit ISVs, through
porting centres and special incentives. Special effort will be taken to
make sure that ODT and Sun applications are runnable on Destiny, either
through (painless) recompilation or server modifications. Perhaps a company
will come out with a library that translates Motif toolkit calls into
MoOLIT, so that apps written for the Motif APIs can be more easily ported.
Perhaps under Novell's direction (probably with Intel's help), there will
be an Intel equivalent to 88open, initially joined by every current vendor
except SCO and Sun. Faced with accusations of un-cooperative behaviour,
SCO will eventually join, and ensure that there is a minimum level of
binary and API compatability amongst the vendors. I see it possible that
Sun will never join such a group, though it would be nice if they did.
There is also a chance that SCO may make the plunge into USL, maybe
starting at 4.3. This situation would allow each vendor to start with a
single base, *really* concentrate on added value, and spend less time
whining about who's UNIX and who's not.
I see both SCO and Univel doing well in the foreseeable future, keeping
each other on their toes with a healthy rivalry. I'm not so sure about
the other vendors, though. They will have to differentiate themselves
from Univel and SCO with either bare-bones pricing, or significant added
value that differentiates their products. Mere bundling diffrences or bug
fixes won't be enough.
I believe the companies that will be worst hit by Univel's entry will be
MST, UHC, Microport, ESIX and Dell. There will be intense pressure on
them to go to Destiny, and even then, just going to 4.2 won't be enough.
If these companies don't specialize in certain kinds of added value, they
won't last.
Consensys, which should also be on this list, has already established
itself by coming out of the blocks with an agressively priced version
of Destiny. That company can probably do well enough to survive as the
industry's loss leader, if it maintains that position. If one of the
other vendor chooses to get into a price war with Consensys, the short
term will benefit consumers, but ultimately both Consensys and its
challenger could go under from the strain.
Especially interesting to watch will be Larry's darling Dell, which is
no longer cutting-edge technology. The company will have to decide soon
whether it wants to remain in the UNIX value-added field or to simply
resell Solaris and/or UnixWare the way it now sells SCO. OEMing existing
packages is far easier for Dell, especially if its UNIX division turns
out to be less profitable than expected, despite the glowing reviews.
I suspect that selling high volumes of UNIX without a loyal VAR/reseller
channel has proven far more difficult than Dell expected.
Dell has plowed considerable money and effort into R4.0, only to see
its product obsoleted by Destiny. It'll be interesting to see how Dell
copes with the same situation Larry has repeatedly taken SCO to task
over: How do you justify an investment of thousands of person-hours
of work on a package, just to throw it out in order to stay "current"?
Dell -- and to a lesser extent, all of the other R4 vendors -- will now
pay the price for not previously co-operating on bug fixes and other
non-added-value issues. Let's see if they can afford to keep up. I'm
sure that not all of them will.
As for Intel Solaris, I don't expect it to be more than a niche product,
one that will allow Sun to keep market share by offering traditional
SPARC customers a very entry-level option using commodity PC hardware. I
don't think Sun will have its heart into Intel Solaris, though, and I
don't see most Catalyst apps being ported to it.
As for Coherent, it was once a good idea. I expect that in the future,
it will only be bought by people who haven't heard about Linux.
Ah, the crystal's gone hazy again. Enough babble for now. Are you sorry
you asked?
--
Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, Ontario
ev...@telly.on.ca / uunet!utzoo!telly!evan / (416) 452-0504
What's with all this multimedia stuff? Most vendors can't get *one* done right.
Bill Campbell
:palo...@netcom.com (Bob Palowoda) writes:
:>I somehow doubt the it is "inconsequential". I would venture to say that
:>thier will be a larger marketplace for multi-processor SVR V.4's in the
:>future over SCO's.
:Remember that SCO is based on technology that is 5 years old.
I'm getting pretty tired of that argument (which must be at least
5 years old :-). I'll go back to my race car analogy for a
while. There are lots of young fast drivers, but few who win
races. I raced a 1972 Hawke DL-9 Formula from 1972->1976 with
the following results:
1972 The car broke a lot (it was English remember). I had
to rebuild it completely replacing flakey British
components with mil-spec aircraft parts. They were a
little heavier and not so pretty, but they didn't
break.
1973 Won a few races, but spent most of the season
tweaking things here and there and getting the car to
really fit me properly.
1974-> Won more races than any other Formula Ford driver in
the history of Summit Point Raceway. The drivers who
had to have the ``letest and greatest'' (Lola one
year, Crossle, Van Dieman...) were still trying to
get theirs to stay together, much less go fast.
Does this sound anything like OS development? I'm happy to have
others work the bugs out (I didn't start using any Intel-based
Xenix until 1988 staying with the NCR Towers to give SCO time to
get their product stable).
There has to be a compelling reason for me to change vendors
because it's too time consuming and expensive to switch (there
was about a 4 month period after SCO Unix 3.2v4 was released last
year when many vendor's products didn't work on it. This really
caused me problems on a major installation because several things
just didn't work (Chantal Paragon, MaxSpeed terminals, CTAR...).
The rapid rate of change in this industry is one of the most
enjoyable factors for me as a developer because I always have new
toys, but a real pain as a businessman because the new technology
(NT) doesn't always work or takes a lot of effort to implement.
Bill Campbell
.....
:Now with USL being purchased by Novell, and with Univel presumably
:selling directly into the same market as the other folks who have
:been getting their source from USL it will be interesting to see what
:lies in the future of System V. Anyone care to reveal what their
:crystal ball says?
I had an interesting thought -- what happens to Unix if Novell
decides to get out of the Unix business?
Jeff Finkelstein
have literally thousands of applicationDEC 433MP's with from 1-6 processors
out there running SCO UNIX and ODT (in various incarnations). The main problem
we have seen regarding MPX is problems surrounding counters and such that
make sar give erroneous results. Overall, the majority of problems are
in relation to IRQ's being stomped by multiple devices at the same address.
I can't speak for other vendors, but in terms of customer satisfaction of
MP OS's, SCO and their products get some of the highest ratings we have seen.
From my own personal perspective, I work daily on a MPX based system and the
main problems I have are the ones I create for myself.
--
jeff finkelstein | disclaimer:
j...@alf.dec.com | Digital has many spokespeople,
digital equipment corporation | And obviously I am not one of them.
customer support center |
Joe Sharkey
Also: "Take a reality check" "Smell the coffee"
> SCO originally wrote the MPX on a piece of asymmeticial piece
>of hardware.
Hmmm.. History check, too.
> They where by no means the first to do this, I was working
>on a similar hardware/os designed 15 years ago.
This is you doing this, 15 years ago, right? SCO didn't exist then...
>This was just about the time Collary released thier asymmetical design
>out to the public in PeeCee Land.
Corollary: 5 years ago?
> But now symmetrical designs are become
>more cost effective. Now set me straight if I am wrong SCO's MPX would
>take alot of software development to rewrite the kernel to adapt it
>to symmetical hardware.
Hmm... My DEC 433MP boots with Corollary copyrights all over - I'll tell
it SCO wrote it and see what it says ;)
>SCO dosn't manufacture hardware. In writing a MP UNIX OS you are really
>tied to the hardware architecture. If Colloary or Altos makes the slightest
>change in hardware they screwup SCO's port.
They "port" SCO's port to their own hardware. If they make a mess, SCO
just says "not us, *they* did the port...."
>Is SCO moveing in the right direction?
They're moving with the Intel world - cheap MIPS for all..
>Of coarse I work RISC based MP systems now so it dosn't matter much to
>me. I'm just curious.
Wrong, too.
>---Bob
--
Joe Sharkey j...@jshark.inet-uk.co.uk ...!uunet!ibmpcug!jshark!joe
150 Hatfield Rd, St Albans, Herts AL1 4JA, UK Got a real domain name
(+44) 727 838662 Mail/News Feeds (v32/v32bis): in...@inet-uk.co.uk
Red Sonja
>
>In article <C1q1E...@trauma.rn.com> la...@trauma.rn.com (Larry Snyder) writes:
>>Yes, let's not forget that -- SCO isn't Unix -- it's, well - SCO.
>
>
>Now with USL being purchased by Novell, and with Univel presumably
>selling directly into the same market as the other folks who have
>been getting their source from USL it will be interesting to see what
>lies in the future of System V. Anyone care to reveal what their
>crystal ball says?
>--
Well, my magic 8 ball says, "Reply hazy, try again later." My New York
Times Help Wanted says "CNE - 55K to start. CBE - 55-65K. Unix Admin -
45K. Unix Admin - 35K..."
--
-----------------------------------------------------------------------------
reds...@olias.linet.org \\\RS/// Self possession is 9/10 of the law.
-----------------------------------------------------------------------------
Fred Rump from home
>I somehow doubt the it is "inconsequential". I would venture to say that
>thier will be a larger marketplace for multi-processor SVR V.4's in the
>future over SCO's.
I was talking present tense. The future will come tomorrow and we'll have to
see what it brings.
>: but one main player much to the chagrin of our friendly SCO bashers club.
> I'm not SCO bashing. I just don't think SCO has big plans to push
> MPX on "as many symmetrical" hardware architectures as USL and Novell will.
> Strickly my opinion.
I don't know if I'm revealing secrets but believe me there are other big SCO
systems out there and in the back room they are working on even bigger stuff.
I just don't think SCO will simply lie down and take a fall. They have too
many years into this thing to just let some newcomers who just joined the
INTEL market grab their business from them.
Right now the market is in a transition from accepting other hardware besides
IBM as OK for mission-critical work. The big boys are still skeptical about
all these little machines being able to do real work. How could they if they
are so cheap. The beancounters are finally looking at the DP budgets and
asking why they are so high. As they get lousy answers, heads will start to
fly and change will ensue. It's the natural course of things.
>
>: Corollary is presently selling an NT development box to get a head start in
> the game.
>Did Corollary release any symmetrical hardware? Which processor?
The present ads claim 3 486s.
>Why buy a development sysatem while such companies as Wyse is selling
>the real machine for MP NT. I'm sure Altos is going to sell for NT
>also. Hey really I'm just curious about what's going to happen.
I think Altos will stay in the UNIX systems business and let ACER take the
ball with dos/nt networking type stuff.
Fred Rump from home
>In your opinion if they are running something other than SCO than is it
>inconsequential.
>I don't know why you have to be so rude and make such brainless comments.
Are you now writing fiction too? How do you know what my opinion is?
I said the volume, the numbers, are inconsequential to the market at
this time. If that is rude, I'm sorry. Maybe someday NOVELL will own the
market for MPX boxes and then SCO's numbers will be inconsequential but why do
facts bother you so much?
If something doesn't please you it's brainless? I'm glad you're still a
student. You have much to learn.
Fred Rump from home
>Remember that SCO is based on technology that is 5 years old.
I wonder how many shops are still running operating systems that are much
older than that. I wonder who many shops still run COBOL and BASIC
applications? I wonder why they should not if they do the job.
Fred Rump from home
>to symmetical hardware. Fred said they did it with the Altos machine.
>Maybe he can get some of the engineers to comment on this port.
One of the BIG problems I have with Altos is that they are so damn net
ignorant. As far as I know they still only have an old Altos 500 sitting there
as altos.com, further, very few people use it. The only comments I've had are
from folks who used to be with Altos and worked on this port in past times.
I think the biggest difference is really on the I/O side where Altos has
always been able to do wonders even in single processor boxes. Somehow they
know how to make data fly with enhanced drivers and hardware mods. NEC was
working on a similar MPX I/O box that would have a 128b bus. They deemed the
market was not ready to support such a high flyer and backed off. The VAR
market they were attempting to enter simply was not into dealing with big
systems from a total support angle. They do not have the organization of NCR
or AT&T, HP etc in place. We talked, we were interested, but there must not
have been enough of us.
Altos does have an established VAR & support base and they could go for it.
>In no place between SCO's MPX and SVRV.4's MP's is there any standard
>in hardware software combination the will help the Intel marketplace
>with either UNIX or NT. SVRV.4 are trying to move in the right direction.
>Is SCO moveing in the right direction?
That is the $64 K question, isn't it.
>Of coarse I work RISC based MP systems now so it dosn't matter much to
>me. I'm just curious.
We'll have to see were it all bottoms out. I simply assume that the market is
big enough for many vendors and many different approached towards the same
end.
Larry Snyder
>For the most part if you take into account the above, Larry is right
>old software technology hinders developers, old developers will bitch
My original comments were based on the fact that SCO is based on
3.2 which has been around for > 5 years, while most of the other
vendors have jumped on the SVR4 bandwagon. Granted, SCO has refined
their 3.2 based product to a point defined by others "as beyond" -- but
then they should have considering how old 3.2 is, their staff, and
how much time they've had to work with a 3.2 based product. To
futher complicate the market, SCO added features from SVR4 to their
3.2 based product -- namely symbolic links and long file names --
which have been included with SunOS and SVR4 for years. SCO has not
added large amounts of inodes and many of the other hundreds of
features available from the other Unix releases to their 3.2 based
UNIX product. Granted, SCO has spent millions in programming and
marketing enhancing and building their product which is 3.2 based,
and for SCO to come out with a SVR4 product would be a major undertaking
for them. But then at what point does an organization move forward?
Gary Whisenhunt
|> Gary Whisenhunt (gwh...@hydra.urbana.mcd.mot.com) wrote:
|> :
|> : Destiny is not MP capable. Most (but not all) of the symmetric MP ports for
|> : SVR4 that are available today are based on SVR4MP (based on SVR4 Version 4)
|> : from USL. The multiprocessor work for this was originally developed by
|> : a consortium of x86 companies and licensed by USL. NCR and Unisys sell
|> : products based on this.
|>
|>
|> I think you are very confused. There is SystemV 4.2 (Destiny) and at the
|> same time SystemV 4.2 ES.MP which is enhanced security multi-procssor.
|> Now you can call the latter what ever you want. Ok so there are 4.0
|> MP ports and 4.2 MP ports I don't think there is going to be a binary
|> compatibility issue here. So who was in the consortium? Anyone want
|> to take a guess?
|>
SVR4 ES/MP isn't generally available yet. Last I heard it was scheduled for
release sometime this year. That's just the technology release. Expect
a few months after that before system vendors produce products based on
it. Destiny focused on the desktop environment by making SVR4 much
more more configurable as well as adding things such as a desktop manager.
USL also spent a great deal of effort fixing 1000s of bugs and making
Destiny a "binary quality" release. For those of you unfamiliar with
USL's normal technology release, this was quite a step forward. Motorola has
fixed 1000s of bugs in its SVR4 release prior to making it commercially
available. As for compatibility, SVR4, SVR4MP, and SVR4 ES/MP should be
binary compatible (upwards). Great pains were taken to try and insure
that things like multithreaded device drivers and STREAMS modules would be
usable from SVR4MP to SVR4 ES/MP even though the mutual exclusion primitives
used in the kernel are different in the 2 releases.
As for the Intel consortium, it was comprised of Intel, NCR, Unisys, and
some others that I can't remember (I think Ollivetti and ICL). The work
started on SVR4 Version 3 and was later upgraded to version 4. It's fully
symmetric and designed to scale well up to 8 processors although last I
heard it was shown to be scalable up to 5 on a Wyse machine.
Motorola sponsored an 88K consortium that ported this to the 88K architecture.
How do I know this stuff? I led the Motorola 88K consortium and worked with
the Intel consortium and USL on a lot of this stuff...
Jerry Rocteur
>I work at the Customer Support Center in Atlanta and provide UNIX support. We
>have literally thousands of applicationDEC 433MP's with from 1-6 processors
>out there running SCO UNIX and ODT (in various incarnations). The main problem
>we have seen regarding MPX is problems surrounding counters and such that
>make sar give erroneous results. Overall, the majority of problems are
>in relation to IRQ's being stomped by multiple devices at the same address.
I raised the 'sar' point with SCO and they recommended I use u386mon,
which I have compiled and run daily.
I recommend u386mon for SCO MPX, it works great!
Jerry.
--
__^__ __^__
( ___ )------------------------------------------------------------( ___ )
| / | Jerry Rocteur Email: je...@InCC.COM | \ |
| / | Independent Computer Consultants | \ |
Bob Palowoda
: In article <1993Feb2.0...@netcom.com>, palo...@netcom.com (Bob Palowoda) writes:
: |> Gary Whisenhunt (gwh...@hydra.urbana.mcd.mot.com) wrote:
: |> :
: |> : Destiny is not MP capable. Most (but not all) of the symmetric MP ports for
: |> : SVR4 that are available today are based on SVR4MP (based on SVR4 Version 4)
: |> : from USL. The multiprocessor work for this was originally developed by
: |> : a consortium of x86 companies and licensed by USL. NCR and Unisys sell
: |> : products based on this.
: |>
: |>
: |> I think you are very confused. There is SystemV 4.2 (Destiny) and at the
: |> same time SystemV 4.2 ES.MP which is enhanced security multi-procssor.
: |> Now you can call the latter what ever you want. Ok so there are 4.0
: |> MP ports and 4.2 MP ports I don't think there is going to be a binary
: |> compatibility issue here. So who was in the consortium? Anyone want
: |> to take a guess?
: |>
:
: SVR4 ES/MP isn't generally available yet. Last I heard it was scheduled for
: release sometime this year. That's just the technology release. Expect
: a few months after that before system vendors produce products based on
: it.
More than likey all the SVR4 houses who have symmetrical hardware that
is based on Sequent already has the port done. Now the question is
how is USL/Novell going to market such a product? Will there be
cheaper MP machines. Don't tell me it cannot be done because it is
too difficult or complex. I have much more confidence in that American
hardware engineers can come up with an inexpensive design.
: Destiny focused on the desktop environment by making SVR4 much
: more more configurable as well as adding things such as a desktop manager.
: USL also spent a great deal of effort fixing 1000s of bugs and making
: Destiny a "binary quality" release. For those of you unfamiliar with
: USL's normal technology release, this was quite a step forward. Motorola has
: fixed 1000s of bugs in its SVR4 release prior to making it commercially
: available. As for compatibility, SVR4, SVR4MP, and SVR4 ES/MP should be
: binary compatible (upwards). Great pains were taken to try and insure
: that things like multithreaded device drivers and STREAMS modules would be
: usable from SVR4MP to SVR4 ES/MP even though the mutual exclusion primitives
: used in the kernel are different in the 2 releases.
:
:
: As for the Intel consortium, it was comprised of Intel, NCR, Unisys, and
: some others that I can't remember (I think Ollivetti and ICL). The work
: started on SVR4 Version 3 and was later upgraded to version 4. It's fully
: symmetric and designed to scale well up to 8 processors although last I
: heard it was shown to be scalable up to 5 on a Wyse machine.
Actualy it was 8 cpus.
:
: Motorola sponsored an 88K consortium that ported this to the 88K architecture.
:
: How do I know this stuff? I led the Motorola 88K consortium and worked with
: the Intel consortium and USL on a lot of this stuff...
I wrote the networking test suites for the SVR4.0MP releases.
---Bob
Ken McDonell
>palo...@netcom.com (Bob Palowoda) writes:
>
>> MP, fully symmetrical are Microport SVR4, Denstiny, Solaris and Wyse's
>> Unix. I believe all of the ports where based on the Sequent sources from
>> USL.
I just couldn't let this pass ... Pyramid's DC/OSx operating system is
a true SMP developed by merging our technology from the older OSx into
the SVR4.0 code base from USL. DC/OSx has been out and about on customer
machines since June _1991_, and definitely uses none of the Sequent SMP
technology, although DC/OSx is the code base for the USL (non-SMP)
SVR4/MIPS ref port.
>Alan Deny told me that AT&T/NCR also have symmetrical multi-processor systems.
The AT&T systems may well be the Pyramid ones AT&T re-sells; this is
most likely the case if the processors are R3000s, rather than 80486s.
The same DC/OSx code base is also used in MP systems from Siemens Nixdorf
and some 80x86 systems from Olivetti.
>Certainly an MPX environment will become standard fare, but so far there is
>but one main player much to the chagrin of our friendly SCO bashers club.
I doubt that there is much potential overlap between the potential
markets for SCO-based systems and the markets for Pyramid/Sequent systems.
--
Ken McDonell E-mail: ke...@pyramid.com
Systems Technology Laboratory ke...@yarra.pyramid.com.au
Pyramid Technology Corporation Phone: +61 3 521 3799
Melbourne, Australia Disclaimer: I speak for me alone, of course.
Geoffrey Welsh
> Larry raises an interesting point. How exactly do you define something
> to be Unix?
Although I'd agree that SCO products have an exceptionally high degree of
UNIX compatibility, a friend is working on using gcc under ODT; he reports
that he's having some difficulties with systems calls. This may be a
mere documentation issue, but perhaps it wouldn't be if he was using something
that Larry would consider "real UNIX". Perhaps "100% *standard* UNIX" would
be a better term than "real UNIX".
> Now with USL being purchased by Novell, and with Univel presumably
> selling directly into the same market as the other folks who have
> been getting their source from USL it will be interesting to see what
> lies in the future of System V. Anyone care to reveal what their
> crystal ball says?
I don't know what the future holds, but Novell has promised that they will
keep Univel at the same level as other USL customers. Since giving Univel an
unfair advantage over other USL customers would result in many UNIX houses
turning their backs on UNIX, and since I believe that Novell would profit more
from promotinf UNIX and linking it with their existing NetWare than from
killing it off in a competetive market that will soon be wrenched yet again by
MicroSloshed's latest wunderOS, I believe them.
Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
ge...@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
Geoffrey Welsh
> Our technology base is actually older than that Larry. One of the SCO
> old timers (who now works on high performance graphics software in my
> group amongst other things) dropped by my office and I asked him to
> refresh my rusty and incomplete knowledge of the history of Xenix.
> Xenix came from Version 7 which was modified by folks at Microsoft to
> run on small systems. Selected parts of System III were later added,
> and when System V 3.0 came out some important pieces were also
> incorporated. So Xenix is effectively based on technology that was
> developed back in the '70s (which of course was based on some even
> earlier operating system and compiler work from the late '60s).
I'd be interested in knowing the history of the various UNIX systems... and
why SysV seems to be the one that caught on.
Fred Rump from home
>I work at the Customer Support Center in Atlanta and provide UNIX support. We
>I can't speak for other vendors, but in terms of customer satisfaction of
>MP OS's, SCO and their products get some of the highest ratings we have seen.
>From my own personal perspective, I work daily on a MPX based system and the
>main problems I have are the ones I create for myself.
>--
>jeff finkelstein | disclaimer:
>j...@alf.dec.com | Digital has many spokespeople,
>digital equipment corporation | And obviously I am not one of them.
Strangely enough, another report of customer satisfaction from the real world.
It is folks like Jeff who sit on the firing line day in day out. If he's
happy, his customers must also be. It is the kind of stuff that must make
Larry wince. :-)
Jerry Rocteur
>In article <1993Jan31.1...@compu.com> f...@compu.com (Fred Rump from home) writes:
>>palo...@netcom.com (Bob Palowoda) writes:
>>
>The AT&T systems may well be the Pyramid ones AT&T re-sells; this is
>most likely the case if the processors are R3000s, rather than 80486s.
>The same DC/OSx code base is also used in MP systems from Siemens Nixdorf
>and some 80x86 systems from Olivetti.
Just out of interest, for those who are :-) Olivetti Europe sell the Risc
Pyramid range of computers, they call them the LSX 65??, we have a twin
processor one, well it was only installed last week, but this machine
is quick, super quick, I've never seen anything like it.
Looking at the box it is about 14" wide and 4' high I guess, it has a
little trap door in the front and a sysadm op system called Pecos or
something, I've only just starting to get familiar with it and I'm
real impressed.
I'm sorry, this *is* comp.unix.sysv386 so I'll leave it there.
Fred Rump from home
>In article <1993Jan31.1...@compu.com> f...@compu.com (Fred Rump from home) writes:
>>palo...@netcom.com (Bob Palowoda) writes:
>>> Unix. I believe all of the ports where based on the Sequent sources from
>>> USL.
>I just couldn't let this pass ... Pyramid's DC/OSx operating system is
>a true SMP developed by merging our technology from the older OSx into
>>Alan Deny told me that AT&T/NCR also have symmetrical multi-processor systems.
>The AT&T systems may well be the Pyramid ones AT&T re-sells; this is
>most likely the case if the processors are R3000s, rather than 80486s.
>The same DC/OSx code base is also used in MP systems from Siemens Nixdorf
>and some 80x86 systems from Olivetti.
I presume then that this DC/OSx operating system can not run off the shelf
software designed for the Intel based UNIX V marketplace. This was the point
of contention vis a vis 'them' and SCO in cost/performance measurement.
>>Certainly an MPX environment will become standard fare, but so far there is
>>but one main player much to the chagrin of our friendly SCO bashers club.
>I doubt that there is much potential overlap between the potential
>markets for SCO-based systems and the markets for Pyramid/Sequent systems.
I doubt that too. Especially from the pricing angle. Whether the kind of
system that a Wyse or Altos can produce will be 'that' far from a performance
position as the Pyramid/Sequent world presently offers remains to be seen in
the future. A 500 user Altos or Wyse is not that far from reality right now.
How far does one have to go to be in the mainframe class when counting
potential users in a typical business environment?
Colonel Panic
>>Alan Deny told me that AT&T/NCR also have symmetrical multi-processor systems.
>
>The AT&T systems may well be the Pyramid ones AT&T re-sells; this is
>most likely the case if the processors are R3000s, rather than 80486s.
No, I was referring to the StarServer E line and the NCR 3000 line.
To my knowledge, Pyramid has never used Intel CPUs; they currently use MIPS
processors, and back in the pre-MIServer days, they made their own processors.
>>Certainly an MPX environment will become standard fare, but so far there is
>>but one main player much to the chagrin of our friendly SCO bashers club.
Fred, given that the two examples above were news to you, I don't think you
know enough about that end of the industry to make such comments, unless
you have hard numbers to back you up.
--
Alan Denney al...@informix.com {pyramid|uunet}!infmx!aland
"The mist clung to the mountain the same way a thirteen-year-old girl clings
to her boyfriend, although the mountain wasn't thinking about "getting lucky."
(1990 Bulwer-Lytton Fiction Contest entry)
Charles Meo
>ke...@yarra.pyramid.com.au (Ken McDonell) writes:
Hi ken!
>>>> Unix. I believe all of the ports where based on the Sequent sources from
>>>> USL.
I don't think this is correct.
>>>Alan Deny told me that AT&T/NCR also have symmetrical multi-processor systems
Probably badged Pyramids until they can get the large NCRs working.
>I presume then that this DC/OSx operating system can not run off the shelf
>software designed for the Intel based UNIX V marketplace. This was the point
>of contention vis a vis 'them' and SCO in cost/performance measurement.
In that SVR4 uses an ABI, this should not be a problem on any SVR4 system, as
long as the software uses the ABI and not native code. Why on earth should
anybody but Intel use their byzantine instruction set? I thought this was the
whole point of the wretched thing (SVR4 that is). If you use the ABI versions
under MPX, this may throw a whole new light on your price/performance. You must
compare apples to apples.
>>I doubt that there is much potential overlap between the potential
>>markets for SCO-based systems and the markets for Pyramid/Sequent systems.
>A 500 user Altos or Wyse is not that far from reality right now.
Without a decent system bus technology, yes it is. You are not going to hang
500 users off an eisa or MC bus since it ain't got enough bandwidth. The issue
of CPU speed is of no real importance for large scale business computing beyond
a certain point--certainly if you can't harness it to tons of peripherals.
To the best of my knowledge no current or envisaged MPX platform has the kind of
expandability of IO devices which this class of system requires. And didn't I
read somewhere (Unix .* Magazine, I forget which) that the scaling factor
for MPX is under 40%? That is, for 200% more CPUs you get 140% more throughput.
This is well behind Sequent, Pyramid and of course Solbourne, which all boast
scalability of 80% or better. Now, I don't know whether this is due to
limitations in MPX or what it runs on, but the fact remains that this order
of performance is well below what the market leaders can deliver now. SMP
development is no doddle, and it takes a lot of pain the get it right.
Of course, if anyone knows better, they will no doubt enlighten me!
Chuck
--
Chuck Meo
Solbourne Computer Australia
c...@ariel.ucs.unimelb.edu.au
'SYS5R4: One Size Fits Nobody'
Fred Rump from home
>No, I was referring to the StarServer E line and the NCR 3000 line.
>To my knowledge, Pyramid has never used Intel CPUs; they currently use MIPS
>processors, and back in the pre-MIServer days, they made their own processors.
>Fred, given that the two examples above were news to you, I don't think you
>know enough about that end of the industry to make such comments, unless
>you have hard numbers to back you up.
Since I am not nearly as omniscient as you and didn't know which AT&T computer
you may have been speaking of especially since the Starserver E is not exactly
a household word around these parts. The only comments from anybody about MPX
AT&T hardware brought up the Pyramid boxes they sell. This may or may not
mean something to the rest of us who deal in business systems. I think it can
safely be assumed that AT&T made these computers for their internal use more
than for the open market. It may also be assumed that failure to find other
clients for their wonderful hardware made AT&T buy a computer company in order
to try to market or discontinue them.
Being that confusion still reigns as to what they're selling today, only the
very knowledgeable programmers from Informix really know what is going on in
the marketing world right down to this weeks latest hardware feature.
I'm not sure if anybody ever said that Pyramid uses INTEL, but that may come
tomorrow.
Fred
--
W. Fred Rump office: fr...@COMPU.COM "Home to a boy is merely like
26 Warren St. home: f...@icdi10.compu.com a filling station" (He's 25)
peter da silva
> But then at what point does an organization move forward?
They are moving forwards. They're taking a different path: one where new
enhancements must be made without breaking existing software. When there is
a compelling new technology that requires introducing a new product line to
support it, they will. They have found that their customers are less
appreciative of the bleeding edge: did you hear the screams when they tried
to drop Xenix?
Speaking as someone who has Intel and Bell Tech SVR2 boxes still in productive
use, and has been having serious trouble "advancing" to SVR4, I can certainly
appreciate SCO's strategy. If SCO supported our critical networking product
we'd be using them now.
--
Peter da Silva `-_-'
Ferranti International Controls Corporation 'U`
Sugar Land, TX 77487-5012 USA
+1 713 274 5180 "Zure otsoa besarkatu al duzu gaur?"
Eric Kozowski
>ke...@yarra.pyramid.com.au (Ken McDonell) writes:
>
>>In article <1993Jan31.1...@compu.com> f...@compu.com (Fred Rump from home) writes:
>>>palo...@netcom.com (Bob Palowoda) writes:
>>>> Unix. I believe all of the ports where based on the Sequent sources from
>>>> USL.
>
>>I just couldn't let this pass ... Pyramid's DC/OSx operating system is
>>a true SMP developed by merging our technology from the older OSx into
>
>>>Alan Deny told me that AT&T/NCR also have symmetrical multi-processor systems.
>
>>The AT&T systems may well be the Pyramid ones AT&T re-sells; this is
>>most likely the case if the processors are R3000s, rather than 80486s.
>>The same DC/OSx code base is also used in MP systems from Siemens Nixdorf
>>and some 80x86 systems from Olivetti.
>
NCR sells their own line of 486 based MP systems and also sells the
former AT&T StarServer E. The SSE is a SMP box using 1-4 486 (33 or
DX-2 66 MHz) chips. It also has THE fastest system bus available
linking the CPU's and memory. It has a sustained throughput of
267M/second using dual 64bit data channels and a 32 address channel. It
also has an EISA bus for I/O. Really neat machines. Really fast, too.
A SSE with 4 DX-2 66 CPU's and 96M of memory has a tpsB benchmark of
207.83. The price/performance ratio is real good, also. It is around
$1400/tpsB. Like I said, the SSE is a real nice system.
--
Eric Kozowski | System/Network Administrator
kozo...@ohsu.edu | Oregon Health Sciences University
| 840 SW Gaines Rd GH113
503/494-4537 | Portland, Oregon 97201
Warren Tucker
Subject: Re: "SCO isn't Unix" - Larry Snyder
Newsgroups: comp.unix.sysv386,biz.sco.general,comp.unix.sys5.r4,comp.unix.sys5.r3,comp.unix.
Organization: TuckerWare/ARS N4HGF
In article <FkaFyB...@zswamp.UUCP> ge...@zswamp.UUCP (Geoffrey Welsh) wrote:
: Although I'd agree that SCO products have an exceptionally high degree of
: UNIX compatibility, a friend is working on using gcc under ODT; he reports
: that he's having some difficulties with systems calls.
Can you be more specific? System calls are executed in library code
(usually), so he must mean library calls. Which version of gcc?
I've run a few lines (chortling at understatement deleted) thru
gcc versions 1.3 to 2.3.3, including gcc, gnu binutils, psroff,
groff, less, pty, tcsh, elm, tin, mush, telnet, pbmplus, cproto,
Roell's X (1.1b -- compiled all day), smail, C-Kermit, ECU, and scores
of custom systems, including ones using SV IPC (shm, sem and msg).
Add to that 1/2 of the stuff that comes through
comp.sources.{misc,unix,x}, a real test for any compilation
system :-). There are few if any library calls I haven't used
with gcc. (I haven't used ftok() for a while and will never use
putprdfnam() ;-> )
A few problems have been gcc-related (earlier versions) and
fixable with compiler switches. It may be sufficient with gcc
2.3.3 and the 3.2v4 DS to use -D__STDC__=0, but this usually work
for any rev of gcc or SCO UNIX/386 for K&R code (you may need to tweak):
-traditional -fno-builtin\
-D_NO_PROTOTYPE -D_SVID -D_KR -D__STDC__=0 \
-DM_BITFIELDS -DM_COFF -DM_I386 -DM_I86 -DM_I86SM \
-DM_INTERNAT -DM_SDATA -DM_STEXT -DM_SYS3 -DM_SYS5 \
-DM_SYSIII -DM_SYSV -DM_UNIX -DM_WORDSWAP -DM_XENIX -Dunix -Di386\
(Don't fake a polemnic puke :-| ... this is reality )
Kernel drivers are a problem if you do anything to call on libgcc.a
(which is likely).
I find the SCO system an excellent platform for native development
and to port code to and from.
----------------------------------------------------------------------------
Warren Tucker (404)587-5766 n4hgf!wht or w...@n4hgf.Mt-Park.GA.US
American air lines have now lost more money that the total profits since the
beginning of commercial aviation. -- McNeil-Lehrer news Hour 2/8/93
: ge...@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
--
------------------------------------------------------------------------------
Warren Tucker (404)587-5766 n4hgf!wht or w...@n4hgf.Mt-Park.GA.US
All readers cannot be leaders, but all leaders must be readers. - Harry Truman
leaders, but all leaders must be readers. - Harry Truman
Warren Tucker
Colonel Panic
>>>Alan Deny told me that AT&T/NCR also have symmetrical multi-processor systems.
>>The AT&T systems may well be the Pyramid ones AT&T re-sells; this is
>>most likely the case if the processors are R3000s, rather than 80486s.
>>The same DC/OSx code base is also used in MP systems from Siemens Nixdorf
>>and some 80x86 systems from Olivetti.
>
>I presume then that this DC/OSx operating system can not run off the shelf
>software designed for the Intel based UNIX V marketplace. This was the point
>of contention vis a vis 'them' and SCO in cost/performance measurement.
True, but the systems I was referring to (StarServer and NCR 3000 lines)
*can* run SVR3.2 or SVR4 binaries. SCO can't.
>W. Fred Rump office: fr...@COMPU.COM "A man's library is a sort of
--
Alan Denney al...@informix.com {pyramid|uunet}!infmx!aland
Circle number 408 on Usenet Reader Service Card.
Khalid Bahey-elDin
I have been lurking passively reading this thread, and now is the time for
somebody in NCR to tell some facts.
Disclaimer: In these parts of the world, pre-merger AT&T machines are not
common, and therefore these platform may be seen more in the US
and maybe Europe.
Other standard disclaimers apply.
Please understand that my purpose is to set the facts straight, and not to
advertise AT&T/NCR's products.
NCR's main product line is the system 3000, which is all Intel based. They
contain 7 level (1-7) with 1 being a notepad/laptop, and 7 being a massively
parallel mainframe. Obviously, each level is targeted to a different usage than
others.
Levels 2,3,4 can run SCO UNIX (and I think MPX as well), DOS, OS/2, and
Netware.
level 4 and up are all Symmetric Multi Processing machines (SMP), (varies from
2 to 4000 CPUs).
The main Multiuser O.S. NCR has is UNIX V.4 based, and is called UNIX MP-RAS
(Multi-Processing, Reliable, Available, Servicable). And conforms to Intel
Binary compatibility standards, and does what any SVR4 does, and is compatible
with other SVR4s.
Levels 3 and up are really meant for SVR4, although other O.S. are available
for the customer to choose from (as above).
NCR has optimized the 3000 series for UNIX V.4 performacne especially the
multi-processor ones, and have been known to have industry leading benchmarks.
The AT&T Pyramid-sourced machines are pre-merger machines that got incorporated
in the product line as a result of the merger. They are MIPS R3/4000 and run
SVR4 as well.
What I can tell you is that the 3000 is the main NCR product, at least in our
part of the world we don't see the MIPS machines.
So, SCO is not the only MP offering in the UNIX/Intel arena, and if you really
look into it, only a handful of vendors support SCO MPX, and they don't have
much CPU to offer (2-4-8?), and not all are SMP machines.
If you need SVR4 SMP, or need a really large machine, then SCO is not an option,
and the PC architecture will show its limitations.
I hope that the subject is clarified, and I hope we end this thread and start
something useful.
Regards
--
Khalid M. Bahey-elDin | Voice: +966-2-651-2727 | Fax: +966-2-651-8804
Systems Services Division | Email: Khalid.Ba...@SaudiArabia.NCR.COM
NCR Corp., Saudi Arabia | also: kba...@ncrsaud.saudiarabia.ncr.com
P.O.Box 13964, Jeddah 21414 | UUCP: ..!uunet!ncrlnk!ncrsaud!kbahey
Topher Eliot
|> I don't know what the future holds, but Novell has promised that they will
|> keep Univel at the same level as other USL customers. Since giving Univel an
|> unfair advantage over other USL customers would result in many UNIX houses
|> turning their backs on UNIX,
departed from reality. I can't conceive of any vendor of hardware (assuming
that's what you mean by 'UNIX houses') 'turning their back on UNIX.'
I can think of at least two reasons that I consider insurmountable.
1) Licensing. To turn their back on Unix, they would have to stop making
royalty payments. That would involve asserting that they aren't shipping
*anything* that includes or is derived from any of the Unix source code they
ever received. Right. Try convincing a court of that.
2) Marketing. The company would have to publicly announce that it was no
longer in the Unix business, but was now something that, true or not,
would be perceived as non-standard, or (gasp) proprietary by customers.
Show me a vendor of Unix systems that has such an option in their business
plan. Forget it. Even if their system was superior in every imaginable
technical aspect, they would lose business hand over fist.
BTW, my understanding is that USL has "Unix" copyrighted, and you must have
their permission to call your system a "Unix" system. Moreover, I think they
impose some pretty exhaustive criteria, so if you decide not to do something
on their list, you can't use the U-word. Which is one reason you see "DG/UX"
and "Xenix" and ... But that's not to say any of those vendors could cancel
their contract with USL, just because right now they don't call their product
"Unix".
Yes, I'm aware of things like Mach and GNU. I don't think they make a dent
in either of these arguments.
For example NeXT uses a Mach kernel, and I think they use GNU compilers. Do
they get USL source code? I mean who wants to re-implement ed?
DG has basically implemented their own kernel, but we certainly get source code
from USL.
Now I think a much more interesting idea is what kind of anti-trust
ramifications there are to this deal. THAT might keep Novell on the straight
and narrow.
--
Topher Eliot Data General DG/UX Systems Administration Development
(919) 248-6371 el...@dg-rtp.dg.com
Obviously, I speak for myself, not for DG.
misc.consumers.house archivist. Send mail to house-...@dg-rtp.dg.com
Who is this Nosmo guy, and why do so many people want him to be king?
Robert S. Yen
>al...@informix.com (Colonel Panic) writes:
>>No, I was referring to the StarServer E line and the NCR 3000 line.
>>To my knowledge, Pyramid has never used Intel CPUs; they currently use MIPS
>>processors, and back in the pre-MIServer days, they made their own processors.
>>Fred, given that the two examples above were news to you, I don't think you
>>know enough about that end of the industry to make such comments, unless
>>you have hard numbers to back you up.
>Since I am not nearly as omniscient as you and didn't know which AT&T computer
>you may have been speaking of especially since the Starserver E is not exactly
>a household word around these parts. The only comments from anybody about MPX
>AT&T hardware brought up the Pyramid boxes they sell. This may or may not
>mean something to the rest of us who deal in business systems. I think it can
>safely be assumed that AT&T made these computers for their internal use more
>than for the open market.
As a former kernel developer for the StarServer E, I guess I should step in
here and comment. For you clarification, these computers (SMP StarServer E's)
were most definitely *not* made "for their internal use more than for the
open market." We were shooting for a low-cost, transaction processing server.
The initial multi-processer StarServer E's were available (i.e. you could
actually buy one in a multi-processor configuration) well over a year and a
half ago. The SMP configuration supported from one to four 33 MHz 80486 CPUs
and I believe we set the record for lowest $/TPS on the TPC/B benchmark (at
the time). The SMP version of SVR4 was done "in house" within AT&T Computer
Systems in conjunction with another company. However, AT&T in their infinite
wisdom, purchased NCR a little over a year ago. It turns out they also had
(have) SMP 80486 machines and their own SMP version of SVR4. To make a long
story short, they continued to "support" the (small) existing customer base,
but had (have) no long range plans to support the StarServer E nor the version
of the OS I worked on. This was done despite the fact we outperformed their
System 3000 equivalent machine. I won't bore you with the details, but suffice
to say that I was asked to join NCR and no longer work there. The AT&T/Pyramid
System 7000 line was similarly "integrated" into the AT&T/NCR product line, so
I doubt many NCR salespeople know about it. So, there are at least three SMP
"variants" that came out of the AT&T/NCR camps, of which, only the System 3000
ones are "officially licensed products of NCR."
>It may also be assumed that failure to find other
>clients for their wonderful hardware made AT&T buy a computer company in order
>to try to market or discontinue them.
I won't even go into this, as there are far more questions than answers as to
why AT&T bought a computer company than the (simple) one listed here . . .
>Being that confusion still reigns as to what they're selling today, only the
>very knowledgeable programmers from Informix really know what is going on in
>the marketing world right down to this weeks latest hardware feature.
See above -- the StarServer E has been out for quite a while. Of course, that
doesn't mean everyone should know about it, but it's certainly not "this weeks
latest hardware feature."
Robert S. Yen
Motorola Inc.
rs...@rtsg.mot.com
Topher Eliot
|> In article <1993Jan31.1...@compu.com> f...@compu.com (Fred Rump from home) writes:
|> >palo...@netcom.com (Bob Palowoda) writes:
|> >
|> >> ... Out of all the ports I know are
|> >> MP, fully symmetrical are Microport SVR4, Denstiny, Solaris and Wyse's
|> >> Unix. I believe all of the ports where based on the Sequent sources from
|> >> USL.
|>
|> I just couldn't let this pass ... Pyramid's DC/OSx operating system is
|> a true SMP developed by merging our technology from the older OSx into
|> the SVR4.0 code base from USL. DC/OSx has been out and about on customer
|> machines since June _1991_, and definitely uses none of the Sequent SMP
|> technology, although DC/OSx is the code base for the USL (non-SMP)
|> SVR4/MIPS ref port.
And I just couldn't let this pass. Using the words of someone else here at
DG:
"Data General's DG/UX is a fully SMP Unix operating system originally
released on DG's proprietary Eclipse line in 1987. This was ported to
the AViiON line (Motorola 88000 based) and has been available with
these systems since their debut in 1989. The kernel was completely
designed and implemented from scratch especially for SMP, based on
previous proprietary OS work (going as far back in some cases as the FHP
work described in Tracy Kidder's "Soul of a New Machine"). Thus, it is
not based on USL (AT&T), Sequent, or any other sources. It was designed
to the SVID & POSIX interfaces, and DG does use the standard USL SVR4
commands and libraries (with some modifications and additions)."
Michael P. Deignan
>Kernel drivers are a problem if you do anything to call on libgcc.a
>(which is likely).
Exactly. If you compile kernel drivers with GCC, chances are that you'll
end up with GCC using one of its internal functions stored in libgcc.a.
Then you'll have real problems getting your kernel to link and run
correctly!
MD
--
-- Michael P. Deignan / Since I *OWN* SBS.COM,
-- Domain: m...@anomaly.sbs.com / These Opinions Generally
-- UUCP: ...!uunet!anomaly!mpd / Represent The Opinions Of
-- Telebit: +1 401 455 0347 / My Company...
Fred Rump from home
>I have been lurking passively reading this thread, and now is the time for
>somebody in NCR to tell some facts.
>So, SCO is not the only MP offering in the UNIX/Intel arena, and if you really
>look into it, only a handful of vendors support SCO MPX, and they don't have
>much CPU to offer (2-4-8?), and not all are SMP machines.
You are obviously talking hardware vendors. This brings us back full circle in
that hardware/software at the MP level is in another ballgame. Software folks
get involved to make a unique box perform to its ultimate level.
If I could buy NCR UNIX RASle-Dazzle OS and stick it onto a Compaq, DEC,
Corollary or MITAC MPX machine we'd be in there comparing apples with apples.
But I doubt very much that this can be done. Yet SCO can run on the 1 to 4
level NCR boxes.
Since only one or two vendors, that I know of, have taken SCO MPX by the horns
and extended it to function more specifically and efficiently on their
hardware we do have a level of comparison available regardless of the
commentary below.
>If you need SVR4 SMP, or need a really large machine, then SCO is not an option,
>and the PC architecture will show its limitations.
>I hope that the subject is clarified, and I hope we end this thread and start
>something useful.
>P.O.Box 13964, Jeddah 21414 | UUCP: ..!uunet!ncrlnk!ncrsaud!kbahey
Few people really need SYS V R4 to run an application. It may be their choice
their preferred choice but NEED has many alternatives. But what then is a
really large machine?
How big is the market for 1000 processor NCR 3000s? Granted, if that is what I
need, there are precious few places to go to find it. It may be why AT&T
bought the company.
But since we may be speaking about the more typical 50 to 200 user market,
there will be many players to compete with NCR in the MPX marketplace. At that
level there will be and are many alternatives for INTEL based applications.
One of them is SCO.
I think the exchange has been wonderful. Even though we had to go all the way
to Saudi Arabia, we did hear from an unofficial NCR person on the net.
Now where is UNISYS?
Steve Bleazard
>w...@n4hgf.Mt-Park.GA.US (Warren Tucker) writes:
>
>>Kernel drivers are a problem if you do anything to call on libgcc.a
>>(which is likely).
>
>Exactly. If you compile kernel drivers with GCC, chances are that you'll
>end up with GCC using one of its internal functions stored in libgcc.a.
>Then you'll have real problems getting your kernel to link and run
>correctly!
Err, with gcc-2.3.3 on the 386 you'll find fixdfsi is the only helper routine
actually required by the compiler. gcc-1.40 also requires fixunsdfsi and I
think one other FP routine. Most device drivers don't use FP anyway! I
have successfully built several xenix kernels using GCC-1.40. I have
assembler versions of all the required routines if anyone actually needs
them.
Steve
--
Steve.B...@RoboBar.Co.Uk | Phone: +44 81 991 1142 x153
Snr Software Engineer, Robobar Ltd. | Fax: +44 81 998 8343 (G3)
22 Wadsworth Road, Perivale. |
Middx., UB6 7JD ENGLAND. | ...!ibmpcug!robobar!steve
Jeff Finkelstein
In article <1993Feb13.0...@informix.com>, al...@informix.com
(Colonel Panic) writes:
>Why? Jeff is comparing their SCO machines only with other DEC environments.
>DEC doesn't sell an Intel-based SVR4 solution. Having worked on the DEC
>642X and 643X running DEC MP System V, I'd probably prefer SCO as well. ]-:
First off, how dare you imply that you know what I was comparing it too. You
never contacted me or asked me what I was thinking. Secondly, your statement
about systems from Digital not running SVR4 are ill-informed at best.
We sell boxes that are more than happy to run many different flavors of SVR4,
i.e. Microport, Solaris, UHC, etc.. (I particularly like Microport, which I
run very happily). Please check your facts before posting.
--
jeff finkelstein | disclaimer:
j...@alf.dec.com | Digital has many spokespeople,
digital equipment corporation | And obviously I am not one of them.
customer support center |
Khalid Bahey-elDin
[stuff deleted]
>The AT&T systems may well be the Pyramid ones AT&T re-sells; this is
>most likely the case if the processors are R3000s, rather than 80486s.
Sorry! I couldn't let this one pass either!
Even though I have posted a clarification about NCR's SMP SVR4 products, it
seems that the confusion is still there:
NCR main product line now is the system 3000, which is build internally by NCR
and not sourced from anywhere. They are 486 machines both uniprocessor and
Symmetric Multi Processors from 2 to 4096 CPUs.
NCR took the USL SVR4, and build their own SMP enhancements (this is why the
O.S. is called SVR4 MP-RAS) locking, granularity, ..etc.
The interesting thing is that NCR SMP code was submitted to and accepted by
USL and is in the SVR4 ES/MP code.
[Can somebody from NCR Columbia, SC give me a hand here?)
The Pyramid sourced stuff may well be sold only in the US and maybe Europe.
It definitely doesn't show up much in NCR's international operations.
Again, Please let us end this multi-month thread , and discuss something
useful.
--
Khalid M. Bahey-elDin | Voice: +966-2-651-2727 | Fax: +966-2-651-8804
Systems Services Division | Email: Khalid.Ba...@SaudiArabia.NCR.COM
NCR Corp., Saudi Arabia | also: kba...@ncrsaud.saudiarabia.ncr.com
Jeff McElroy x6996
|> NCR took the USL SVR4, and build their own SMP enhancements (this is why the
|> O.S. is called SVR4 MP-RAS) locking, granularity, ..etc.
|>
Specifically, NCR optimized SVR4 to include fine-grain locking support for
high-performance SMP, removed many unnecessary panic conditions, added a
high-availability journaling file system, fixed many problems in UNIX
utilities, kernel code, and subsystems, developed optimized SCSI drivers,
created a comprehensive systems management package (OSA). NCR SVR4-MP/RAS
operates on both small servers and large enterprise systems,
such as the System 3000 models 3450, 3550, and 3600.
The changes were undertaken to ensure the levels of system availability
and performance required for a commercial mission-critical computing
environment.
|> The interesting thing is that NCR SMP code was submitted to and accepted by
|> USL and is in the SVR4 ES/MP code.
This is true, most vendors running SVR4 multiprocessing today are using a
large amount of the NCR developed multiprocessing code.
|>
|> [Can somebody from NCR Columbia, SC give me a hand here?)
|>
My pleasure.
--
-Jeff McElroy
UUCP: jeff.m...@ColumbiaSC.NCR.COM -or- ncrcom!ncrcae!endeavor!jeff
PHONE: 803.739.6065 - main number at 803.796.9250 - fax at 803.739.7317
USPS: NCR MCPD Columbia, 3325 Platt Springs Road, West Columbia, SC 29170
Bob Palowoda
: |>
: |> NCR took the USL SVR4, and build their own SMP enhancements (this is why the
: |> O.S. is called SVR4 MP-RAS) locking, granularity, ..etc.
: |>
:
: Specifically, NCR optimized SVR4 to include fine-grain locking support for
: high-performance SMP, removed many unnecessary panic conditions, added a
Ok I give up which necessary panic condiitons did you leave in?
---Bob
palowoda@netcom