WHY does DEC keep shooting itself in the foot?

Mark Bartelt

unread,

Jun 5, 1992, 3:06:17 PM6/5/92

to

OK, this is much too long and a bit flamish as well, and my original plan
was not to post it here, but to forward it to a few friends/acquaintances
who work for DEC, more as a cathartic spleen-venting exercise than as an
attempt to actually cause any substantial changes to take place. But one
of the recipients encouraged me to post it anyway, so here it is.

I've also appended some excerpts from one of the replies I got. (And, it
seems, I may get more than I anticipated, since apparently my screed has
gotten forwarded and reforwarded already.) Anyway ...

===============

Background: We've got some money to spend. Not a huge amount, compared
to what a typical corporate data centre (or even a large government lab)
might have to toss around. But more than lunch money.

Two different agendas: First, we have an $80K equipment grant to spend
on upgrading our number-crunching capabilities. No great hurry to buy
anything (after all, the longer we wait, the more horsepower we'll get
for the same amount of money). There is some incentive to spend it now
rather than later, though, since if we carry it over we're not permitted
to apply for another equipment grant in the next budget cycle.

Second, we have a couple dozen old Sun-3/50s, which nobody does any sort
of serious computing on any more; most people use them as X terminals to
faster machines. Anyway, we have a long-range (two to four years) plan
to replace them with modern workstations.

So much for background. Now for the tale of our dealings with DEC.

---------------

Chapter 1 ... Last fall we heard great things (at least in the trade
press) about DEC's latest R3000-based systems. "Digital finally has
a product that will give Sun a run for its money," said the free rags
that appear on my doorstep. Seemed worth looking into.

Now you and I all know that DEC hasn't really been a contender in the
scientific/engineering arena for quite a long time. However, it did
seem worth investigating the latest offerings, if nothing else than
for the sake of completeness. So I contact our DEC salesdroid. (Of
course, having not dealt with DEC in a couple years, I had to call an
information person to find out who handled the UofT account.) So once
that was taken care of, I call the appropriate number, and get voice
mail. I leave a message. I wait a few days. No return call. Repeat
the previous four sentences N times. After several iterations I give
up, and decide to call the sales supervisor to see what's going on.
Whoever screens his calls refuses to put me through, and asks what the
problem is. I explain. She says that our salesdroid *is* around, and
that she'll see to it that someone will call me back.

Finally, after a couple more days, the UofT rep does call back. Turns
out she has very little information about the new systems (specifically
the 5000/25 and /240; this was late last year), but that she expects to
get some soon, and will get it to me as soon as she gets it. So I wait.
And wait some more. Repeat the preceding 1.5 paragraphs N times.

Finally, after several weeks of this, I start getting annoyed. At last
I make contact, express my annoyance, and get a promise to FAX the stuff
to me. It arrives. Not everything I need, but most of it. More than
just glossy brochures! At least a few technical specs! However, more
questions remained, so I call back. She puts me in touch with another
person, with whom she "partners" on these things. He doesn't have any
more information than she does.

However, one thing that does come out of these conversations is: "Oh.
You only want to buy a few workstations? We're not really interested
in talking with you if you want to buy less than a hundred. We refer
people with small requirements to one of our distributors." OK, fine.
They put me in touch with DSA, a DEC-authorized reseller. This has one
advantage, namely that DEC's discount schedule for UofT is embarrassingly
pathetic, whereas DSA does much better. [As to *why* DEC offers us such
a low discount (when its competitors offer 40-50%) is left for a future
discussion.]

The DSA guy clearly isn't up to speed on the UNIX/workstation market
yet, but he's eager and wants to please. Unfortunately, it turns out
that he has an awful time getting technical information out of DEC, and
for that matter even has a lot of trouble getting a demo system.

Now it's worth digressing for a moment here to explain that we *need*
to have a demo system plopped in here for a couple days. Or, at the
very least, we need to be able to submit our benchmark suite to some
system of the vendor's choice. What's important to us, of course, is
how well a system does on *our* applications, and the sorts of number
crunching stuff that we do (e.g. smooth particle hydrodynamics, N-body
problems, and the like) don't necessarily correlate well with standard
MIPS/SPECmarks/MFlops ratings.

Finally, DSA gets us a system to borrow. Performed pretty well (at
least on the things we could try; we couldn't try out the really big
jobs, since it didn't have much physical memory, and not even enough
swap space to run it in heavy-page-thrash mode); even (at the time)
better than Sun in terms of number-crunches per dollar, though not by
enough to make us rush right out and buy a few. We decided to wait
until (1) we can try out our programs on a system with enough memory
to handle the entire benchmark suite, and/or (2) we have a chance to
try out the R4000 followon (whenever *that* arrives).

Option (2) will happen at some undefined future time. However, the
DSA guy says that he'll be getting a /240 from DEC quite soon (this
was around the beginning of the year), which should be a better test
system than the /25 we'd been trying out. I talked with DSA just a
couple days ago. They still haven't gotten a /240 yet. They (and
we) have been waiting for FIVE MONTHS. Sigh.

The DSA arrangement has one other disadvantage, from the customer's
point of view: It layers yet one more level of indirection onto the
mechanism for getting technical information. About the time I first
made contact with DSA, I had a couple rather specific questions (and
pretty obscure/arcane, as I recall; I don't remember the specifics
just now, but could probably dredge them up) about the hardware and
about Ultrix. The DSA guy, of course, didn't have a clue, but he
did try (or, at least, he claimed he tried) to get the information
out of DEC, but without success. I never did manage to get those
questions answered through normal channels. I vaguely recall that
I posted something to comp.sys.dec or comp.unix.ultrix, and got a
useful reply or two. But is this how DEC *expects* its customers
to get their questions answered?

---------------

Chapter 2 ... Of course, one reason we've held off buying anything
at all (Sun, SGI, DEC, or whatever) is that we want to see how the
Alpha pans out. If it lives up to even one-half of all the advance
hype that DEC has been spewing out, it will be quite a system.

Last week was the annual Open Systems show. I trot down for a day,
mostly to have a look at the Sparc-10, and to investigate various
options for colour printers. But I stop by the DEC booth anyway,
and -- YOW! -- there's an Alpha-based system.

However, my joy was tempered when it turned out that (1) this was
the only Alpha system in the booth, and (2) it was running VMS (at
an "open systems" show!), the only non-UNIX beast I encountered.
Someone ought to tell Ken that calling VMS "open" doesn't make it
so.

Even so, I thought that perhaps this is my chance to probe a bit to
see what the target announcement and ship dates will be. They guy
says that announcement will be September-October, shipping early in
1993. OK, that's cutting it a bit close for the time window which
we've set for ourselves (since we want to unload our money quickly
enough that we don't shut ourselves out of the next grant cycle),
but still reasonable. So I ask when (potential) customers will be
able to submit benchmark suites. "Not until the product ships,"
he says.

I'm incredulous. Every other vendor that we deal with has let us
get in the queue on *announcement* day as a matter of course. And
if you're covered by nondisclosure, you can start running stuff on
the first-off-the-line machines a few months *before* the product
is announced.

If we really can't even start evaluating this thing until January,
there's no way we'll be able to give this box serious consideration,
at least for *this* equipment grant.

And, because of our medium-range upgrade/growth plans, whichever
vendor we choose to spend our $80K with will have one-and-a-half
feet in the door for future purchases over the next two or three
years, since we'll almost certainly be buying an MP-architecture
system of some kind, with the intent of just plugging in more
(and/or faster) CPUs as time goes on.

===============

That (more or less) was the content of the message I sent to a few
DECies. Here's one of the replies ...

| [ ... ] I'm unhappy to tell you your experience resonates
| with mine. We have one fundamental symptom - I'm not really sure it's
| a basic cause - that seems to me to be undeniable, and that is the
| sales force have an impossible task in attempting to master the Digital
| product catalogue, just for shipping products; it's simply too large.
|
| In addition, they get measured, for the most part, on simple dollar
| revenue, which means they try to generate their "budget" figures, i.e.,
| the dollar revenue for which they signed up that year - how that's
| determined is yet another story - independently of the identity of the
| products they sell to make that budget. The effect of this measurement
| scheme is to ensure that they'll first try to sell upgrades to our
| installed base; next, try to sell additional products from what
| fraction of the product catalogue they understand to the same installed
| base; and only last will they try to learn new products, with an eye to
| getting into accounts that may not be Digital customers, at the time.
| The incentive scheme Digital employs pretty much guarantees the
| behavior you observed.
|
| Now, to "support" the efforts of these sales folks, i.e., to be their
| capacity to answer technical customer questions, Digital maintain
| sales support specialists in a variety of specialities, of which RISC
| workstations, UNIX, and IP networking are one, in a ratio of about
| three or four to about fifteen or twenty sales people to each support
| person. The sales folks are told by their management to seek out the
| support specialists when they expect to have need for technical
| information on a customer call - can you imagine how often that
| requirement is *absent* in the market we're discussing? - and take the
| specialist along on the call. Given the ratio I mentioned, it's pretty
| easy to see how long the queues get for the support person's time; that
| means the sales rep often looks like a goof, in front of the customer,
| assuming the sales rep actually makes the customer call - you can see
| how they might not be anxious to.
|
| Further, in an effort better to concentrate the Digital sales force's
| attention on larger opportunities, Digital have encouraged distributors
| to take on customers who wish to make "small" purchases. Now, remember
| the ratio of Digital sales reps to support specialists; this ratio gets
| *much* larger if you begin counting the distributor sales forces, who,
| after all, have less access to technical information than Digital sales
| reps, because they're not Digital employees. You can see where this is
| going. Suffice it to say that the overall sales component of the
| Digital business model could stand improvement; the question is, where
| does one start? I regret to say that we haven't figured that out, yet,
| and I don't know when we will.

===============

OK, enough verbiage for now. I do find the whole situation discouraging,
however. DEC used to be a really great company to do business with, back
twenty or so years ago. Things started to change in the late 70s, though,
and by the mid-80s (if not slightly earlier) the company was a write-off,
IMHBCO. Since then there have been a few encouraging signs, but it seems
that every time something promising starts to peek out from beneath the
covers, it gets gets submerged in layers of pin-striped quilts, never to
be seen again. Sigh ...

Mark Bartelt 416/978-5619
Canadian Institute for ma...@cita.toronto.edu
Theoretical Astrophysics ma...@cita.utoronto.ca

"Clothes not busy being worn are busy drying." - Dylan, on laundry day

Carl J. Appellof

unread,

Jun 6, 1992, 4:56:13 PM6/6/92

to

>However, one thing that does come out of these conversations is: "Oh.
>You only want to buy a few workstations? We're not really interested
>in talking with you if you want to buy less than a hundred. We refer
>people with small requirements to one of our distributors." OK,
>fine.

I had the same problem trying to buy an HP snake directly from HP,
except I didn't get the name of a supplier either.

I'm afraid to say that IBM was quite helpful in selling me a low end
RS/6000, though.

Douglas Miller

unread,

Jun 7, 1992, 3:27:53 PM6/7/92

to

In article <1992Jun5.1...@helios.physics.utoronto.ca>,
sys...@helios.physics.utoronto.ca (Mark Bartelt) writes about problems
with doing business with DEC --- I've got three unrelated points:

> Now it's worth digressing for a moment here to explain that we *need*
> to have a demo system plopped in here for a couple days. Or, at the
> very least, we need to be able to submit our benchmark suite to some
> system of the vendor's choice. What's important to us, of course, is
> how well a system does on *our* applications, and the sorts of number
> crunching stuff that we do (e.g. smooth particle hydrodynamics, N-body
> problems, and the like) don't necessarily correlate well with standard
> MIPS/SPECmarks/MFlops ratings.

It is slightly sad that it necessary for you explain what ought to be
axiomatic. I applaude your fortitude in demanding real benchmarks instead
of subscribing to the MIPS myth.

> Last week was the annual Open Systems show. I trot down for a day,
> mostly to have a look at the Sparc-10, and to investigate various
> options for colour printers. But I stop by the DEC booth anyway,
> and -- YOW! -- there's an Alpha-based system.
>
> However, my joy was tempered when it turned out that (1) this was
> the only Alpha system in the booth, and (2) it was running VMS (at
> an "open systems" show!), the only non-UNIX beast I encountered.
> Someone ought to tell Ken that calling VMS "open" doesn't make it
> so.

DEC have started using the phrase "Open VMS" because they are sick to death
of being kicked about for not being open when in fact VMS has always been
an open systems *leader*. Consider the standards that VMS currently
supports: ANSI standards for terminals, printers and magtape, Ethernet,
X.25, X.400, X, Motif, TCP/IP, ISO/OSI, Posix. How many of the Unix-type
beasts at the show could boast all of these?

It really annoys me that the term "open systems" has become so debased that
Unix is widely regarded as a necessary and sufficient condition.
Obviously, neither is true.

> That (more or less) was the content of the message I sent to a few
> DECies. Here's one of the replies ...
>
> | [ ... ] I'm unhappy to tell you your experience resonates
> | with mine. We have one fundamental symptom - I'm not really sure it's
> | a basic cause - that seems to me to be undeniable, and that is the
> | sales force have an impossible task in attempting to master the Digital
> | product catalogue, just for shipping products; it's simply too large.

> | Now, to "support" the efforts of these sales folks, i.e., to be their

> | capacity to answer technical customer questions, Digital maintain
> | sales support specialists in a variety of specialities, of which RISC
> | workstations, UNIX, and IP networking are one, in a ratio of about
> | three or four to about fifteen or twenty sales people to each support
> | person.

I see similar symptoms as you in my dealings with DEC, but on a *much*
smaller scale. I guess it all depends on relative staff levels at your
lcoal office.

The answer seems simple to me: more specialisation amongst sales staff (to
enable them to master the product catalogue in their area) and/or more
sales/sales-support staff overall.

Thor Lancelot Simon

unread,

Jun 7, 1992, 8:16:28 AM6/7/92

to

Thank God that most of the people who buy a *lot* of workstations, generally
for engineering purposes, couldn't give a rat's ass about most of the
"open" "standards" listed above. A few (Ethernet, X, TCP/IP) are simply
barebones essentials today -- you couldn't sell a single machine without them,
which I would imagine is why DEC finally added TCP/IP and X, however crummy
the implementation of either. The others? Most people who buy workstation
hardware today could really hardly care less. It's all so much meaningless
fluff included to meet the requirements of bureaucrats, not end users. I have
said it before in this forum, and I'll say it again, in different words:

Pick whatever standard you damn well please -- call it open if you like to.
If most people out there are using something _else_, it's not.

I think that takes care of X.25, X.400, and ISO/OSI quite nicely. I doubt
someone who needs as much under the hood as he can get, to solve his problems
in smooth particle hydrodynamics and the like, would spend the portion thereof
that most Motif kits I've seen eat for lunch. It's my experience that if
machine used for that kind of thing are running X at all, they've usually got
twm or something similarly frugal on top. Posix? Well, gee. Now Ken can say,
"VMS is more UNIX than UNIX!" Well, I think the absurdity of that claim is
demonstrated by the fact that it would take a hell of a lot of work to make
most stuff from the net compile and run under VMS, as opposed to what's usually
a simple 'make' under most current Unix flavors.

Look, I think VMS is a fine operating system for some purposes. Myself, I find
those purposes quite limited, and I tend to think that most people who are
using VMS are really doing it because they're too sheep-like to look their
DEC salesperson in the eye and Just Say No. If you're an exception, fine. If
you take offense at my second statement, fine. But you're doing VMS a great
disservice by using a term as meaningless as "open" to defend it. I refuse
to consider any system "open" if I can't get the source code for less than
the price of the hardware to run it. That is, of course, my personal definition
and you mileage may vary. The one that DEC and most other vendors would like
us to use, is, however, purely stipulative in nature, by which I mean that it
is *not* an accurate description of the way the word "open" is commonly
used, and it really generaly means whatever a particular vendor's marketroids
find it has to. IBM and SUN and HP claim to have "Open system *leaders*", too.
They're not lying, the term's just so damn nebulous that everyone benefits from
it except the customer.

I guess I should mention that I acquired my deep dislike of the word 'open' when
I spent a summer working in a DEC sales office. In that context, it was used
as more or less a crucifix with which to beat back the evil Truth -- most of
the time when I heard it used, as I recall, it was in an attempt to claim that
because it was more "open", by DEC's definition thereof, DEC product X was
superior to competitor's product Y, usually when this claim was so indefensible
that there was simply no other way to go at the problem! I recall spending
hours trying to explain to a "Technical Workstation Specialist" that no matter
*how* "open" Ultrix 3.1 was, it simply sucked eggs in comparison to 4.1 SunOS,
and that if he couldn't find anything other than his rather nebulous "open"
truncheon to beat the Sun presentaion about the head and shoulders with in the
field, he really shouldn't be so surprised when customers began to defect. He
wouldn't listen, of course. I recall trying to help prepare a proposal for
a large insurance company's claims database, and having to walk out of the
room to calm down when the suggestion was made that "we can't *possibly* lose
to Sequent! We support so many more _open standards!_" Sequent's proposal
incorporated a good-sized Symmetry multiprocessor. Ours was *one* DECstation
5000/200. Both ran the customer's database software of choice. But we were
more "open", so our answer *had* to be better! I don't know what the outcome
of that one was, but I'd say it's a fairly safe assumption that the prospective
customer laughed at what we finally put together. Draw whatever conclusions
you will from all this. I know what *mine* are.

Chris_F...@cup.portal.com

unread,

Jun 7, 1992, 10:55:41 AM6/7/92

to

One possible reason _I_ can see for DEC keeping VMS around, is that a few
of us out here develop and maintain applications for which VMS is far and
away a better platform: Unix and its clones just don't cut it, for us.

To be specific, we need to handle asynchronous events of several types,
something which most programmers, designers, and UNIX in general "don't
do well." We need to support high-volume I/O (several hundred Kbytes/
second, sustained for ~40 minutes at a time) in a multitasking environment
without significantly impacting other low-volume I/O and CPU-bound pro-
cesses executing at the same time. There are a few other less dramatic
requirements, but the point is that VAX/VMS addresses them all. (We've
read some Alpha and Alpha VMS specs, and have our doubts that even THAT
environment will suit us as well as does VAX/VMS. Synchronization looks
to be difficult or impossible, in the Alpha architecture.)

I may sound like a religious VMS devotee, but we do try to keep an open
mind and have repeatedly evaluated various UNIX- and UNIX-clone-based
systems for suitability as a new platform for our application (particular-
ly the last few years, filled as they've been with rumors of VMS' demise).
We've even had vendors offer to port our application from VMS to their
platforms FOR us -- BEFORE they've heard our requirements and the performance
we currently get from our VAX/VMS-based systems. AFTER they hear our
requirements and observe our VAX/VMS-based performance levels, they beat
a quick retreat and are never seen again. We haven't had a Sun represen-
tative come to call in over two years.

To be honest, I've observed that ALL the operating systems and consumer
computing products I've encountered (VAX/VMS, Unix, IBM-PC, Macintosh, Amiga,
Atari) have shortcomings ranging from mild to serious; NO operating system
does EVERYTHING correctly. But my personal opinion after years of the
kind of experience detailed in the previous paragraph is that VMS has the
least number of serious shortcomings FOR OUR PARTICULAR APPLICATION. As
always, "your mileage may vary." But just because YOUR application runs
just dandy on a Unix workstation, don't pressure DEC to get rid of the
only OS that can handle MY requirements!

Chris Chiesa
Chris_F...@cup.portal.com

Mike O'Connor

unread,

Jun 7, 1992, 11:06:47 AM6/7/92

to

In article <1992Jun7.1...@brt.deakin.edu.au> dou...@brt.deakin.edu.au (Douglas Miller) writes:

:It is slightly sad that it necessary for you explain what ought to be

:axiomatic. I applaude your fortitude in demanding real benchmarks instead
:of subscribing to the MIPS myth.

It's not so much "real benchmarks" as "which box looks kike it runs my
app faster and better", especially when the machine itself may BE the app.
(A lot of people like NeXT 'cause it feels faster -- even if it's a dog.)

:DEC have started using the phrase "Open VMS" because they are sick to death

:of being kicked about for not being open when in fact VMS has always been
:an open systems *leader*. Consider the standards that VMS currently
:supports: ANSI standards for terminals, printers and magtape, Ethernet,
:X.25, X.400, X, Motif, TCP/IP, ISO/OSI, Posix. How many of the Unix-type
:beasts at the show could boast all of these?

Leader? <laughs>

VMS led the way in X, POSIX, and TCP/IP? Gimme a break! And it's
really cute how you list X.25, X.400, and ISO/OSI like they're terribly
separate or something. How long has DEC taken to come out with some
sort of TCP/IP for VMS? (Shameless plug: Make mine Multinet!) Any
system sold without Ethernet in the past 10 years hasn't NEEDED
Ethernet and probably isn't comparable. Does VMS have "leading"
revisions of X and Motif? For that matter, do they have good
implementations of X and Motif?

Leader? In a lot of the examples you mentioned above, VMS is
certainly playing catch-up to spark sales. And it's debatable
about just what defines an "open system" -- the implication that
Motif is somehow more "open" is certainly debatable.

:It really annoys me that the term "open systems" has become so debased that

:Unix is widely regarded as a necessary and sufficient condition.
:Obviously, neither is true.

"Obviously?"

I'd love for someone to give me criteria for "open systems" these days.
Standards just aren't going to do it -- someone wants to claim they're
open so they make standards that they conform to and say "Lookee here,
we conform to X, Y, and Z, so we're open!".

--
Mike O'Connor
"The NNTP Administrator"
<m...@snclib.snc.edu>

Marcus J. will do TCP/IP for food Ranum

unread,

Jun 7, 1992, 1:26:45 PM6/7/92

to

Mike O'Connor <m...@snclib.snc.edu> writes:

>I'd love for someone to give me criteria for "open systems" these days.

Ok. Here's mjr's definition of "Open Systems":

Vendor supplied and supported solutions to customer computing
requirements, designed with a built-in focus on interoperating with
existing and/or future systems(*), and delivered with an emphasis on
using existing capabilities, and a clear vendor-neutral(**) path for
adding new capabilities.

Amplification:
"Open Systems" is especially NOT an implementation detail, it's
a strategy for implementing computing. This means that "Open Systems"
is not merely UNIX - UNIX may be a component of an "Open Systems"
strategy, but in a simple case, it's more likely that a network
running TCP/IP will play a more crucial part in an "Open Systems"
solution than UNIX.
"Open Systems" are built by customers, not by vendors. A
vendor may sell components of "Open Systems," but the real "Openness"
comes from the customer's making educated decisions about their
long-term computing strategy, and selecting standards-compliant(***)
technologies that will "plug and play." This means that customers
must be careful to select computing components (hardware and software)
that are as interoperable and modular as possible, and must be
aware of and isolate "nonstandard" components as part of the design.
It is when the customer has decided on the components that they
need to get thier job done that they can ask each vendor for the
specs and prices of their particular offerings in a given technology,
and pick what they want. Thus, "Open Systems" must be driven AND
DEFINED (****) by the customer.

mjr.
----
(*) This means basically meeting de facto industry standards, but not
RULING OUT evolving standards. I.e.; the system should be able
to upgrade to supporting OSI networking if OSI suddenly becomes
the internetworking standard.

(**) This means basically no vendor "lock in."

(***) Where appropriate, and standards should be relevant. Specifying
that an embedded computing solution MUST be capable of
running OSI is perfectly stupid if you are reasonably certain
that within the lifetime of the solution, it will never be
networked.

(****) Excepting this posting, where I am attempting to define it, of
course. ;)

Jack Churchill

unread,

Jun 7, 1992, 6:51:25 PM6/7/92

to

The discussion lately on this topic is quickly degenerating into a war
of o/s and words. People's immaturity is beginning to show. Let's at
least agreee to disagree on whether VMS is more "open" than unix of if
unix is better than VMS or ... All this makes me sick and is pure
trivia. If we are going to judge how "good" an o/s is by its success
or popularity then perhaps we all should switch over to MSDOS! It's
interesting that I'm having the same arguments with our new boss who
keeps asking why are we using VMS? Well, we use MSDOS, UNIX, VMS and
RSX for different reasons and purposes so his question is really
irrelevant. Each have their place and each excell in their own uses.
It's like asking why are you using a blue cotton t-shirt today and not
a white synthetic one or why don't we all drive the same car with the
same engine capacity (and remove all trucks, buses, etc off the road)?
Such silly nonsense.

Let's put this discussion back on track, and that's to discuss what is
Digital going to do to avoid shooting it's foot right off,
particularly with MIPS &/or Alpha. My suggestion is for them to
populate the world with the Alpha like IBM did with the Intel chips.
All that's left is to develop enhanced versions of existing operating
systems (Windows-NT &/or OSF/1 &/or VMS?) to go with them that will
remain useful as we enter the 21st century.

--
Jack N. Churchill | ja...@syd.deg.csiro.au

Douglas Miller

unread,

Jun 8, 1992, 1:09:22 PM6/8/92

to

In article <1992Jun7.1...@panix.com>, t...@panix.com (Thor Lancelot
Simon) writes:

> In article <1992Jun7.1...@brt.deakin.edu.au>
> dou...@brt.deakin.edu.au (Douglas Miller) writes:

>>In article <1992Jun5.1...@helios.physics.utoronto.ca>,
>>sys...@helios.physics.utoronto.ca (Mark Bartelt) writes:

>>> Last week was the annual Open Systems show. I trot down for a day,
>>> mostly to have a look at the Sparc-10, and to investigate various
>>> options for colour printers. But I stop by the DEC booth anyway,
>>> and -- YOW! -- there's an Alpha-based system.
>>>
>>> However, my joy was tempered when it turned out that (1) this was
>>> the only Alpha system in the booth, and (2) it was running VMS (at
>>> an "open systems" show!), the only non-UNIX beast I encountered.
>>> Someone ought to tell Ken that calling VMS "open" doesn't make it
>>> so.
>>
>>DEC have started using the phrase "Open VMS" because they are sick to death
>>of being kicked about for not being open when in fact VMS has always been
>>an open systems *leader*. Consider the standards that VMS currently
>>supports: ANSI standards for terminals, printers and magtape, Ethernet,
>>X.25, X.400, X, Motif, TCP/IP, ISO/OSI, Posix. How many of the Unix-type
>>beasts at the show could boast all of these?

> Thank God that most of the people who buy a *lot* of workstations, generally
> for engineering purposes, couldn't give a rat's ass about most of the
> "open" "standards" listed above.

Probably. What does this have to do with the point at issue --- whether
VMS qualifies to be demonstrated at an "open systems show"?

> Pick whatever standard you damn well please -- call it open if you like to.
> If most people out there are using something _else_, it's not.

Absolutely.

> I think that takes care of X.25, X.400, and ISO/OSI quite nicely.

In some markets, yes. In others, vendors had better have an OSI offering if
they expect to do business.

> Posix? Well, gee. Now Ken can say, "VMS is more UNIX than UNIX!" Well, I
> think the absurdity of that claim is demonstrated by the fact that it would
> take a hell of a lot of work to make most stuff from the net compile and
> run under VMS, as opposed to what's usually a simple 'make' under most
> current Unix flavors.

What are you saying? That most stuff from the net won't work on a posix
compliant operating system without a hell of a lot of work? Sounds a bit
dubious to me.

> Look, I think VMS is a fine operating system for some purposes. Myself, I
> find those purposes quite limited, and I tend to think that most people who
> are using VMS are really doing it because they're too sheep-like to look
> their DEC salesperson in the eye and Just Say No. If you're an exception,
> fine. If you take offense at my second statement, fine.

I am not here to promote VMS (its functionality, its value-for-money,
etc.), so don't bother attacking it general. My point is only that VMS has
a right to considered at least as open as any Unix system.

> But you're doing VMS a great
> disservice by using a term as meaningless as "open" to defend it.

An open system is one built by a customer that minimises vendor lock-in (to
the extent that is appropriate to the customer).

Hence VMS is very open because it can be used by a customer as a component
in implementing very vendor neutral applications. For example, an
application developed on VMS using X, Motif, and Posix could be transferred
to another platform with no change to the user interface and (almost?) no
change to the application.

Douglas Miller

unread,

Jun 8, 1992, 1:30:29 PM6/8/92

to

In article <1992Jun7.1...@meteor.wisc.edu>, m...@snclib.snc.edu
(Mike O'Connor) writes:

> In article <1992Jun7.1...@brt.deakin.edu.au> dou...@brt.deakin.edu.au (Douglas Miller) writes:
>
> :It is slightly sad that it necessary for you explain what ought to be
> :axiomatic. I applaude your fortitude in demanding real benchmarks instead
> :of subscribing to the MIPS myth.
>
> It's not so much "real benchmarks" as "which box looks kike it runs my
> app faster and better", especially when the machine itself may BE the app.
> (A lot of people like NeXT 'cause it feels faster -- even if it's a dog.)
>
> :DEC have started using the phrase "Open VMS" because they are sick to death
> :of being kicked about for not being open when in fact VMS has always been
> :an open systems *leader*. Consider the standards that VMS currently
> :supports: ANSI standards for terminals, printers and magtape, Ethernet,
> :X.25, X.400, X, Motif, TCP/IP, ISO/OSI, Posix. How many of the Unix-type
> :beasts at the show could boast all of these?
>
> Leader? <laughs>
>
> VMS led the way in X, POSIX,
> and TCP/IP? Gimme a break! And it's

I did say *a* leader, and VMS qualifies here for X and Posix. As I've said
elsewhere, VMS *is* playing catch-up with TCP/IP. On the other hand VMS is
years ahead of some Unix vendors in support for ANSI standards. Across the
board, it seems to me that VMS is at the forefront. I'll repeat my
question: What other operating systems currently support this list of
standards to the same extent as VMS?

> And it's debatable
> about just what defines an "open system" -- the implication that
> Motif is somehow more "open" is certainly debatable.

I'm not presenting the above list of standards as definitive (although the
seem like a pretty solid basis to me). By all means debate them. What is
the problem with Motif? It is the most widely vendor-supported X GUI.

Thor Lancelot Simon

unread,

Jun 8, 1992, 2:48:56 AM6/8/92

to

In article <1992Jun8.1...@brt.deakin.edu.au> dou...@brt.deakin.edu.au (Douglas Miller) writes:
>In article <1992Jun7.1...@meteor.wisc.edu>, m...@snclib.snc.edu
>(Mike O'Connor) writes:
>
>> In article <1992Jun7.1...@brt.deakin.edu.au> dou...@brt.deakin.edu.au (Douglas Miller) writes:
>>
>> :It is slightly sad that it necessary for you explain what ought to be
>> :axiomatic. I applaude your fortitude in demanding real benchmarks instead
>> :of subscribing to the MIPS myth.
>>
>> It's not so much "real benchmarks" as "which box looks kike it runs my
>> app faster and better", especially when the machine itself may BE the app.
>> (A lot of people like NeXT 'cause it feels faster -- even if it's a dog.)
>>
>> :DEC have started using the phrase "Open VMS" because they are sick to death
>> :of being kicked about for not being open when in fact VMS has always been
>> :an open systems *leader*. Consider the standards that VMS currently
>> :supports: ANSI standards for terminals, printers and magtape, Ethernet,
>> :X.25, X.400, X, Motif, TCP/IP, ISO/OSI, Posix. How many of the Unix-type
>> :beasts at the show could boast all of these?
>>
>> Leader? <laughs>
>>
>> VMS led the way in X, POSIX,
>> and TCP/IP? Gimme a break! And it's
>
>I did say *a* leader, and VMS qualifies here for X and Posix. As I've said

For X? How long ago did DEC finally reach R4 with their VMS server?
X has been primarily a Unix gig more or less since the beginning, the way I
understand it. Correct me if I'm wrong.

>elsewhere, VMS *is* playing catch-up with TCP/IP. On the other hand VMS is
>years ahead of some Unix vendors in support for ANSI standards. Across the
>board, it seems to me that VMS is at the forefront. I'll repeat my
>question: What other operating systems currently support this list of
>standards to the same extent as VMS?

SunOS. 4.4BSD, when it finally shows up. I don't think including Motif is
fair, given the split between Motif/OL at the vendor level. After all, where's
Open Look for VMS? Besides, as I said before, an awful lot of people prefer to
run one of the twm family because mwm is such a crock, and an awful lot of
software *doesn't* use Motif because it quite possibly might *not* be there on
whatever machine you intend to compile on next. Xt and Xaw are all you can
ever really absolutely count on in that regard, I think.

>
>> And it's debatable
>> about just what defines an "open system" -- the implication that
>> Motif is somehow more "open" is certainly debatable.
>
>I'm not presenting the above list of standards as definitive (although the
>seem like a pretty solid basis to me). By all means debate them. What is
>the problem with Motif? It is the most widely vendor-supported X GUI.

Yeah, but the community of Motif users is fairly small compared to the community
of X users. If we're using the definition of "open" != "vendor locked-in",
if you include Motif you're playing fast and loose with that rule. A lot of
systems *don't* ship with Motif, and it can cost an awful lot of money.

Mike O'Connor

unread,

Jun 8, 1992, 7:28:32 AM6/8/92

to

In article <1992Jun8.1...@brt.deakin.edu.au> dou...@brt.deakin.edu.au (Douglas Miller) writes:

:I did say *a* leader, and VMS qualifies here for X and Posix. As I've said

:elsewhere, VMS *is* playing catch-up with TCP/IP. On the other hand VMS is
:years ahead of some Unix vendors in support for ANSI standards. Across the
:board, it seems to me that VMS is at the forefront. I'll repeat my
:question: What other operating systems currently support this list of
:standards to the same extent as VMS?

Some of the standards were based on DEC hardware, making DEC a leader,
but not necessarily VMS as a leader. TOPS-10 and TOPS-20, mebbe.

VMS qualifies for POSIX? POSIX is a series of Unix look-alike standards.
Most Unix systems were quite far ahead of looking like Unix systems as
opposed to VMS (unless you count Eunice -- :) ). Granted, some of the
specifics are missing out of the OSes that predated the standards, but
the formation of the standards was certainly more Unix-based than VMS
and VMS is playing the follower.

:> And it's debatable

:> about just what defines an "open system" -- the implication that
:> Motif is somehow more "open" is certainly debatable.
:
:I'm not presenting the above list of standards as definitive (although the
:seem like a pretty solid basis to me). By all means debate them. What is
:the problem with Motif? It is the most widely vendor-supported X GUI.

There are more people with Suns using OpenWindows than there are people with
other things using Motif. And the XView stuff is available for anonymous
FTP. X as an "open" standard? Certainly. Motif as "open" standard?
I dunno... how much do I have to pay to be open?

Thaddeus P. Floryan

unread,

Jun 8, 1992, 8:11:34 AM6/8/92

to

In article <1992Jun7.1...@brt.deakin.edu.au> dou...@brt.deakin.edu.au (Douglas Miller) writes:

>[...]

>DEC have started using the phrase "Open VMS" because they are sick to death
>of being kicked about for not being open when in fact VMS has always been
>an open systems *leader*. Consider the standards that VMS currently
>supports: ANSI standards for terminals, printers and magtape, Ethernet,
>X.25, X.400, X, Motif, TCP/IP, ISO/OSI, Posix. How many of the Unix-type
>beasts at the show could boast all of these?

>[...]

Huh? What kinda hogwash is this when the only "ANSI" standard C compiler
on VMS is GCC (which is NOT from DEC). VMS/VAX C is braindead (its use of
"prototypes" notwithstanding).

A discussion of the "openness" of VMS recently transpied in comp.sys.dec;
there is no conclusive evidence VMS is "open" by any definition. VMS' roots
are proprietary and no amount of PD or freely-distributable add-ons can change
that foundation.

This is not to mean VMS is unusable. Far from it. I have 6 systems myself,
and three major commercial products used by 100's of "large" clients.

But VMS is far from "open" no matter what KO and his minions espouse.

Thad Floryan [ th...@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

Steve McKinty - Sun ICNC

unread,

Jun 8, 1992, 12:19:17 PM6/8/92

to

In article <69...@public.BTR.COM>, th...@public.BTR.COM (Thaddeus P. Floryan) writes:

>
> Huh? What kinda hogwash is this when the only "ANSI" standard C compiler
> on VMS is GCC (which is NOT from DEC). VMS/VAX C is braindead (its use of
> "prototypes" notwithstanding).

I heard that from someone else a few years ago, and when pressed the only
justification he could come up with is that you can't call 'main()'
as a function from another program. What ANSI features does it lack? (I'm
not claiming it is ANSI, but just curious to know why you say it isn't)

>
> A discussion of the "openness" of VMS recently transpied in comp.sys.dec;
> there is no conclusive evidence VMS is "open" by any definition. VMS' roots
> are proprietary and no amount of PD or freely-distributable add-ons can change
> that foundation.

Can you name a major OS that is any different?

Steve

(If it's not obvious, these are my own views. I _know_ my employer won't
share them)

amol...@eagle.wesleyan.edu

unread,

Jun 8, 1992, 3:56:41 PM6/8/92

to

In article <1101a5...@grapevine.EBay.Sun.COM>,
smck...@sunicnc.France.Sun.COM (Steve McKinty - Sun ICNC) writes:
>
> [some quoted remarks to the effect that Vax C is brain dead]

>
> I heard that from someone else a few years ago, and when pressed the only
> justification he could come up with is that you can't call 'main()'
> as a function from another program. What ANSI features does it lack? (I'm
> not claiming it is ANSI, but just curious to know why you say it isn't)

Err, it's not even C. See, it's case insensitive.. You can ask it
nicely to be case sensitive, but then you have to type any references
to the standard library in uppercase, since they're uppercased in the
library (under VMS). At least, I was unable to persuade it to behave
both case sensitively and usably.

On the up side, it's got a decent optimizer -- or at least an
optimizer that writes better machine code than I can.

Andrew

Michael A. Thomas

unread,

Jun 8, 1992, 5:13:38 PM6/8/92

to

In article <1992Jun8...@eagle.wesleyan.edu>, amol...@eagle.wesleyan.edu writes:
> In article <1101a5...@grapevine.EBay.Sun.COM>,
> smck...@sunicnc.France.Sun.COM (Steve McKinty - Sun ICNC) writes:
> >
> > [some quoted remarks to the effect that Vax C is brain dead]
> >
> > I heard that from someone else a few years ago, and when pressed the only
> > justification he could come up with is that you can't call 'main()'
> > as a function from another program. What ANSI features does it lack? (I'm
> > not claiming it is ANSI, but just curious to know why you say it isn't)
>
> Err, it's not even C. See, it's case insensitive.. You can ask it
> nicely to be case sensitive, but then you have to type any references
> to the standard library in uppercase, since they're uppercased in the
> library (under VMS). At least, I was unable to persuade it to behave
> both case sensitively and usably.

Actually the gripe ought not be with the C compiler but the VMS linker.
It is the culprit, not the compiler. As I recall inter-program is all
case sensitive as one would expect. The global references however are
resolved by the case insensitive linker (sigh)

--
Mike -- who has had many a battle with porting to VMS with
symbols who's case is different to trap the call...

j...@cmkrnl.com

unread,

Jun 8, 1992, 3:55:30 PM6/8/92

to

In article <1992Jun7.1...@panix.com>, t...@panix.com (Thor Lancelot Simon) writes:

> Pick whatever standard you damn well please -- call it open if you like to.
> If most people out there are using something _else_, it's not.

And then he says

> I refuse
> to consider any system "open" if I can't get the source code for less than
> the price of the hardware to run it. That is, of course, my personal definition
> and you mileage may vary.

Your personal *two* definitions, looks like to me.

But anyway, wrt VMS, it depends on what you want the source for. If you want
to look at it, search it, etc., as an aid to development work, DEC will sell
you the VMS listings kit on CD-ROM for about three thousand bucks. A buildable
source kit is something like $25K.

I have no idea how these compare with Unix source prices -- I don't pay that
much attention. I mention this mainly because a lot of folks out there would
like to buy a VMS Listings kit but don't know that it's available.

--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru, VMSnet (DECUS uucp) Working Group, and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
Internet: j...@cmkrnl.com, hanr...@eisner.decus.org, or j...@crash.cts.com
Uucp: ...{crash,eisner,uunet}!cmkrnl!jeh

Ted Lemon

unread,

Jun 8, 1992, 8:33:01 PM6/8/92

to

>Probably. What does this have to do with the point at issue --- whether
>VMS qualifies to be demonstrated at an "open systems show"?

What on earth does VMS qualifying for demonstration at an "open
systems show" have to do with the discussion at hand? Whether or not
*you* think that VMS is a win over Unix, most people don't. If DEC
is serious about selling into the "open systems" market, demonstrating
VMS is the equivalent of aiming a howitzer at their toes and setting
it off.

>I am not here to promote VMS (its functionality, its value-for-money,
>etc.), so don't bother attacking it general. My point is only that VMS has
>a right to considered at least as open as any Unix system.

VMS is available from one (1) vendor. Not two vendors. Not all
vendors. One vendor. Please, name a computer vendor that doesn't
have a Unix offering. If I want to use any of the many free
applications available on the net, which machine is almost guaranteed
to be the hardest to bring them up on? You guessed it, VMS. Have
you ever tried bringing up GCC on VMS? People have bent over
backwards to make bringing it up on VMS easy, and it's still a royal
pain in the ass.

If you like VMS, more power to you. You're a member of the shrinking
market that DEC is still betting its family jewels on. Maybe if you
say VMS is a win often enough, a few people might believe you, and the
VMS market might actually grow slightly.

However, my opinion is that if DEC continues to so VMS-centric as to
demonstrate their last, best hope of a computer system using VMS as
their open systems standard, they will be out of business in way less
than a DECade. I have a lot of friends at DEC who are doing their
best even now to drag DEC kicking and screaming out of the dark ages,
but I'm increasingly afraid that they're fighting a losing battle, and
people like you who parrot their party line back at your salesdroids
aren't doing DEC any service at all.

Sigh.

_MelloN_

amol...@eagle.wesleyan.edu

unread,

Jun 9, 1992, 1:04:03 AM6/9/92

to

mel...@ncd.com (Ted Lemon) writes:
>
> If I want to use any of the many free
> applications available on the net, which machine is almost guaranteed
> to be the hardest to bring them up on? You guessed it, VMS. Have
> you ever tried bringing up GCC on VMS? People have bent over
> backwards to make bringing it up on VMS easy, and it's still a royal
> pain in the ass.

Gee, I had no idea it was so easy to bring up all the neat free
stuff up on VM/CMS, MVS/TSO, oh, let's see, AOS, NOS.. etc etc.
Get real. Unix-centrism is just as narrow-minded as VMS-centrism.
The whole world does NOT run pizza boxes with BSD-derived Unix and
TCP/IP networking. A large hunk of it does, but not the whole thing.

Andrew

> _MelloN_

Jack Churchill

unread,

Jun 9, 1992, 4:58:21 AM6/9/92

to

I said it before and I'll say it again. This o/s war just has to stop!
You guys are beating down the wrong track. The problem at hand, which
is not just Digital's but it's customers too, is: what is Digital going
to do about the integration of MIPS and Alpha hardware and software (I
should also add PCs and Macs), and the upgrade path to Alpha. You can't
and won't convince everyone to use any single o/s, whether it be OSF/1,
unix (which one?!), VMS, openVMS, MSDOS, OS/2, Windows-NT, MVS, RSX,
RT-11, TSX, RTE, .... all of which have their place. Anybody who just
uses one of these and is human will often fall into the bad trap of
rubbishing everything else (I know because I used to to it myself). So,
it's a total waste of time trying to bash people over the head with the
winge that this is better than that, blah, blah, blah. It may be a
surprise to some but we are not all academics who want to tinker with
unix, or we are all not mission critical corporations who love playing
with VMS security and shadowing, or we are all not simple users at home
and the office writing word processing documents on a PC, or we are all
not electrical engineers who enjoy interfacing a mass-spectrometer to a
PDP-11, or we are all not advertising/publishing companies who like to
use the great imaging software packages on Macs, etc, etc. Believe it
or not!

Now for my gripe...

I don't think this is true but if Digital does place more emphasis on
VMS then OSF/1 then it's history. Digital should know by now that we
want open systems in the sense all the major systems can talk and
exchange data without pain. Is that too much to ask in this age of
computers? When we have true open systems, computers can then just
become commodities - purchasing decisions are then made on the basis of
what best meets my need without the worry of managing a hybrid
environment. A rough analogy is the current use of many programming
languages on the one computer. Each have their own advantages and uses.
We want many o/s's on the one network without the pain we currently have
to go through to install, maintain, exchange and share data (NFS is not
enough). This is not just Digital's problem but all computer companies'
problem. If they want to survive then the problem must be solved. If
Digital thinks VMS is the answer for most (which it must be if Digital
expects most of it's future revenue to come from VMS users) then
convince me. Convince me that enough SG, HP, IBM, Sun, PC users are
going to move over to VMS (or openVMS). If Digital can do that then I
commend them. I don't think they can (I wish they could but that's my
past bias starting to show through :-). If anything the trend will be
the other way. So Digital better concentrate on providing at least one
really good "industry standard" open o/s, namely OSF/1 for their great
new Alpha systems and their MIPS systems. Cheers.

Thor Lancelot Simon

unread,

Jun 9, 1992, 6:30:43 AM6/9/92

to

In article <1992Jun8....@cmkrnl.com> j...@cmkrnl.com writes:
>In article <1992Jun7.1...@panix.com>, t...@panix.com (Thor Lancelot Simon) writes:
>> Pick whatever standard you damn well please -- call it open if you like to.
>> If most people out there are using something _else_, it's not.
>
>And then he says
>
>> I refuse
>> to consider any system "open" if I can't get the source code for less than
>> the price of the hardware to run it. That is, of course, my personal definition
>> and you mileage may vary.
>
>Your personal *two* definitions, looks like to me.

No, it's my personal definition of "standard", followed by my personal
definiton of "open". Two different words, last I checked. You must have
some weird #defines in your system header files... ;-)

>But anyway, wrt VMS, it depends on what you want the source for. If you want
>to look at it, search it, etc., as an aid to development work, DEC will sell
>you the VMS listings kit on CD-ROM for about three thousand bucks. A buildable

I still have the source listings on fiche that came with our 750. They're mostly
in MACRO, and have had the comments excised, and as you mention, aren't
exactly buildable...

>source kit is something like $25K.

Which is why 4BSD went on it as soon as we got the thing, way back when.
Not all of us have a spare $25K.

>
>I have no idea how these compare with Unix source prices -- I don't pay that
>much attention. I mention this mainly because a lot of folks out there would

Well, they're a lot more than we paid for our 32V license, but I don't even
know if you can *get* one of those now. They're a good bit more than what
Net/2, BSDI, Mach, or 386BSD cost. They *are* lower than what it'd cost to buy
Ultrix :-/ but a lot of that is the cost of a System V license.

Robin Fairbairns

unread,

Jun 9, 1992, 7:03:43 AM6/9/92

to

In article <1992Jun8...@eagle.wesleyan.edu>,
amol...@eagle.wesleyan.edu writes (of VMS C):

> Err, it's not even C. See, it's case insensitive.. You can ask it
> nicely to be case sensitive, but then you have to type any references
> to the standard library in uppercase, since they're uppercased in the
> library (under VMS). At least, I was unable to persuade it to behave
> both case sensitively and usably.

Aside from the facts (a) that even VMS compilers - I don't know about C
specifically - are (now, finally) allowed to make case-sensitive
external references, and (b) that VMS C seems to be about to be replaced
with the new all-singing, all-dancing, DEC C, I would draw your
attention to the following statement from my copy of ISO/IEC DIS 9989, C
language:

3.9 FUTURE LANGUAGE DIRECTIONS

3.9.1 External names

Restriction of the significance of an external name to fewer
than 31 characters or to only one case is an obsolescent feature
that is a concession to existing implementations.

I.e., VMS C is at worst obsolescent, but it's still C.

Note: I don't have the final standard - the first DIS (the one I have)
is identical to the ANSI standard, I believe: ISO ironed out a round of
what seemed to me trivial bugs in the standard, which were discovered
after the ANSI standard was published.
--
Robin Fairbairns, Senior Consultant, postmaster and general dogsbody
Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK
Email: ro...@lsl.co.uk --or-- r...@cl.cam.ac.uk
Disclaimer: I've hardly had any involvement with C standardisation

Robin Fairbairns

unread,

Jun 9, 1992, 6:40:24 AM6/9/92

to

In article <1992Jun8.1...@meteor.wisc.edu>, m...@snclib.snc.edu (Mike O'Connor) writes:
> VMS qualifies for POSIX? POSIX is a series of Unix look-alike standards.
> Most Unix systems were quite far ahead of looking like Unix systems as
> opposed to VMS (unless you count Eunice -- :) ). Granted, some of the
> specifics are missing out of the OSes that predated the standards, but
> the formation of the standards was certainly more Unix-based than VMS
> and VMS is playing the follower.

The point being made is that VMS's _compliance_ to Posix gives it a
place among the leaders. You do not _comply_ to a standard by being a
`look-alike'.

For the purposes of those who acquire systems to a spec that requires
compliance to a particular standard, where the ideas came from in the
first place is neither here nor there.

You should note that such people's acquisitions include _every_
public-sector computing procurement in the EEC of value >= 100K ECUs
(an ECU is, to first order, US $0.75).

Mike O'Connor

unread,

Jun 9, 1992, 8:36:01 AM6/9/92

to

In article <1992Jun9.1...@lsl.co.uk> ro...@lsl.co.uk (Robin Fairbairns) writes:

:The point being made is that VMS's _compliance_ to Posix gives it a

:place among the leaders. You do not _comply_ to a standard by being a
:`look-alike'.

And you do not "lead" by jumping onto a bandwagon that's many years old.

:For the purposes of those who acquire systems to a spec that requires

:compliance to a particular standard, where the ideas came from in the
:first place is neither here nor there.

'cept of course if you were talking leadership. And that *was* the topic at
the time.

:You should note that such people's acquisitions include _every_

:public-sector computing procurement in the EEC of value >= 100K ECUs
:(an ECU is, to first order, US $0.75).

Maybe i missed something here, but where is this a pertinent point?

Frederick M. Avolio