Compaq: VMS is alive and kicking
Peter Kastner
Carly talks to Aberdeen Group =>Aberdeen Group recommends HP not
complete VMS port => Carly praises Aberdeen Group report => Compaq
itself files said report with SEC. What part of this is hard to figure
out?
From Aberdeen Group's perspective, here are the facts:
1. We did write reports on the merger and posted them to the world at our
web site http://www.aberdeen.com/ab_company/freeresearch/hp_compaq.htm
2. We did not talk to Carly first, nor to anyone else in senior management
positions at HP or Compaq. We didn't talk to Carly after publication about
this either.
3. We gave HP and Compaq permission to post our research at internal
intranet web sites at no charge.
4. We have not received a nickel for this research and analysis from
anybody.
5. Compaq and HP are customers of Aberdeen (along with most of the IT
industry suppliers), but our revenues with them are not material, nor would
we sully our good name in a senseless "pay for play".
6. I was surprised to hear that Compaq had filed our reports with the SEC.
That would seem to violate (3), but, hey, we're talking antitrust lawyers
here. The SEC hasn't called us...
As to the root question, I recommend that concerned VMS users look up their
counterparts who own HP 3000's. From our vantage point, HP is not giving
any more support to its own venerable HP 3000 base than it is to the Compaq
VMS base. If enough critical customers of either/both platforms make enough
noise and promise to buy enough computers, then the not unintelligent
executives at HP will make a sensible business decision.
Peter
Peter S. Kastner
Chief Research Officer (617) 854-5221
Aberdeen Group, Inc.
One Boston Place
Boston, MA 02108
JF Mezei
> From Aberdeen Group's perspective, here are the facts:
Thank you for chiming in.
> 3. We gave HP and Compaq permission to post our research at internal
> intranet web sites at no charge.
What I find interesting is that Compaq would proudly post a document not meant
to be public which paints a poor picture of the future of Compaq's most
profitable product. If some consulting firm says that customers shouldn't
trust Compaq because it is about to kill a product, Compaq shouldn't be
trumpeting around that report.
Can we draw a conclusion that Compaq is happy with rumours that it will not
continue with VMS for very long ?
Or is there some legal requirement that Compaq post to the SEC any and all
reports it sees about itself ? SHouldn't it also have posted the Shannon
Knows ________ newsletters as well then ?
> 6. I was surprised to hear that Compaq had filed our reports with the SEC.
> That would seem to violate (3), but, hey, we're talking antitrust lawyers
> here. The SEC hasn't called us...
Which makes the reason why Compaq posted that material even more interesting.
> As to the root question, I recommend that concerned VMS users look up their
> counterparts who own HP 3000's.
Are HP 3000 users based on a dead chip and with a migration to IA64 too ?
Alan Greig
wrote:
>On Weds Oct 24th, Alan Greig (a.g...@virgin.net) wrote:
> Carly talks to Aberdeen Group =>Aberdeen Group recommends HP not
>complete VMS port => Carly praises Aberdeen Group report => Compaq
>itself files said report with SEC. What part of this is hard to figure
>out?
>
>From Aberdeen Group's perspective, here are the facts:
Well, well thanks for the comments.
>1. We did write reports on the merger and posted them to the world at our
>web site http://www.aberdeen.com/ab_company/freeresearch/hp_compaq.htm
>2. We did not talk to Carly first, nor to anyone else in senior management
>positions at HP or Compaq. We didn't talk to Carly after publication about
>this either.
My recollection is that Carly said something along the lines (in a
soundbyte from the web - I'm thinking Techweb or something like that):
"Initially all the analysts were very negative but as we've got round
to explaining things to them they are beginning to understand a bit
more. For instance the Aberdeen Group has just produced a positive
report," It was this quote that set me off looking for the Aberdeen
Group report. I have not been able to track down the quote again as I
can't find a way to search back these video archives. Still I'm sure I
can find a quote where Carly or Curly say they've been talking to all
the analysts they can manage regarding the deal. Seems unfortunate
that they hadn't managed to talk to yourselves when you produced the
most positive report I've seen!
>3. We gave HP and Compaq permission to post our research at internal
>intranet web sites at no charge.
>4. We have not received a nickel for this research and analysis from
>anybody.
>5. Compaq and HP are customers of Aberdeen (along with most of the IT
>industry suppliers), but our revenues with them are not material, nor would
>we sully our good name in a senseless "pay for play".
>6. I was surprised to hear that Compaq had filed our reports with the SEC.
>That would seem to violate (3), but, hey, we're talking antitrust lawyers
>here. The SEC hasn't called us...
Surprised. I was astonished. If they hadn't filed it I'd have probably
never found it so easily nor wondered why Compaq picked that one to
file. They don't seem to have filed any other reports unless Compaq/HP
senior management were directly involved in the document.
>As to the root question, I recommend that concerned VMS users look up their
>counterparts who own HP 3000's. From our vantage point, HP is not giving
>any more support to its own venerable HP 3000 base than it is to the Compaq
>VMS base. If enough critical customers of either/both platforms make enough
>noise and promise to buy enough computers, then the not unintelligent
>executives at HP will make a sensible business decision.
I think here we are coming into agreement. I'm still progressing
purchasing plans for more VMS Alpha systems and just last week gave a
presentation of some of our web enabling and B2B/B2C interface work to
board members including our CIO and IT Director (we are a
multinational US Fortune 500 company). However you have to fight
against comments such as "VMS can't do that" and "didn't Compaq kill
Alpha" and "will it run SAP if we decide to migrate". Compaq's actions
in downplaying VMS and being unable/unwilling to fund a SAP port over
RDB seriously hinder our ability to propose what even the IT Director
calls the "most reliable systems we have ever had".
Still I've won more arguments than I've lost and we continue to
develop and run very significant parts of the business on VMS - still
over 1/2 billion US Dollars of manufacturing.
As to "not unintelligent executives at HP" (I note you didn't say
Compaq but will resist reading anything into that) you say in your
report that the Alpha/VMS business together with NSK has contributed
much of Compaq's profits (and DEC before it) in recent years. The
Industry Standard business being loss making or breaking even at
best. Yet Compaq have downplayed this business and emphasized their
Wintel credentials. Do you have any comments on this?
And finally do you stand by your recommendation that HP end the
Itanium port? That would seem a bit strange in a thread subject
"Compaq: VMS is alive and kicking".?
Thanks for clarifying things and we both seem to agree that if we want
to keep VMS and push it back to the forefront we must not let up.
Perhaps VMS engineering could invite you round for a briefing on just
what VMS can do today and where they want to take it. You might be
pleasantly surprised.
>
>Peter
>
>Peter S. Kastner
>Chief Research Officer (617) 854-5221
>Aberdeen Group, Inc.
>One Boston Place
>Boston, MA 02108
>
>
--
Alan
JF Mezei
> And finally do you stand by your recommendation that HP end the
> Itanium port? That would seem a bit strange in a thread subject
> "Compaq: VMS is alive and kicking".?
What if Compaq were to announce the stop of the IA64 port and instead devote
all engineering resources to a SAP port to VMS (or some other endeavour that
would bring new modern apps to VMS to grow out of its limited niches) ?
Considering Alpha has perhaps another 6-7 years of life into it and that a
port might take 1-2 years, I think that it would make a lot of sense to kill
the port, give VMS a infusion of new energy and if that succeeds, then
announce a port later once IA64 is more than just hypeware.
Alan Greig
<jfmezei...@videotron.ca> wrote:
>Alan Greig wrote:
>> And finally do you stand by your recommendation that HP end the
>> Itanium port? That would seem a bit strange in a thread subject
>> "Compaq: VMS is alive and kicking".?
>
>
>What if Compaq were to announce the stop of the IA64 port and instead devote
>all engineering resources to a SAP port to VMS (or some other endeavour that
>would bring new modern apps to VMS to grow out of its limited niches) ?
Given the prior Alpha announcements I think it would be en extremely
bad idea to end or delay the Itanium port. I continue to believe that
Compaq/HP should simultaneously fund a SAP port. I can guarantee that
the combination would provide an incredibly powerful marketing tool
and show that HP/Compaq were serious. HP would then have a SAP
platform which could be clearly differentiated from other bog-standard
Wintel or SAP on Unix offerings. Recall that RDB has won Database
Magazines database of the year on numerous occasions. We run RDB and
native Oracle on VMS as well as Oracle on both HP-UX and NT. It is a
no-brainer that RDB is simpler to use, better thought out, more
cluster aware out of the box and more reliable than Oracle. After all
that's what DEC wrote it to be.
Plus SAP have just fallen out with Microsoft according to latest press
reports - they have chosen JAVA based future functionality over .NET
much to Microsoft's annoyance. With Microsoft trying to move away from
JAVA VMS could soon have better JAVA support than NT.
I could almost guarantee that we would be willing to be a
development/pilot site for such a project timescales permitting...
>Considering Alpha has perhaps another 6-7 years of life into it and that a
It is my strongly held belief that HP will not wish to be selling
state-of-the-art Alpha systems in 7 years time or anything like that.
Major telecoms companies etc who need the fastest VMS systems they can
get their hands on would be forced to Unix or some other platform if
the raw hardware could not keep up no matter how could the operating
system is.
>port might take 1-2 years, I think that it would make a lot of sense to kill
>the port, give VMS a infusion of new energy and if that succeeds, then
>announce a port later once IA64 is more than just hypeware.
If I could not at least point to an upcoming IA64 port it would be
even harder for me to argue internally that VMS has a future.
--
Alan
Nic Clews
Excellent suggestion Alan, Peter you're less than a 2 hour drive from
Nashua, NH from Boston, and I guarantee you'd find their world
fascinating. Anyone from Compaq sending an invite to Peter?
--
Regards, Nic Clews CSC Computer Sciences
nclews at csc dot com
Rob Young
> Alan Greig wrote:
>> And finally do you stand by your recommendation that HP end the
>> Itanium port? That would seem a bit strange in a thread subject
>> "Compaq: VMS is alive and kicking".?
>
>
> What if Compaq were to announce the stop of the IA64 port and instead devote
> all engineering resources to a SAP port to VMS (or some other endeavour that
> would bring new modern apps to VMS to grow out of its limited niches) ?
>
Wrong tree to bark up.
In theory (roadmap theory) , DII-COE pieces make its way into
base VMS somewhere out there. In theory, Unix port to VMS becomes very
simple. I take it to be so. I take it that DII-COE is much better
than Posix stuff from years back. We know some of the nastier Unixisms
have been dealt with (see multiple "fork" discussions in cov over
the months).
All that to say , much wiser to wait 'til COE pieces show up in
VMS to revisit some of these tougher ports as they won't be so tough
in a couple years.
Rob
JF Mezei
> It is my strongly held belief that HP will not wish to be selling
> state-of-the-art Alpha systems in 7 years time or anything like that.
Agree with the above because of your use of "wish". HP is clearly not
interested in Alpha and VMS, just like Compaq wasn't interested in them.
But as long as they generate the profits that subsidize their wintel stuff and
as long as they can generate such profits without advertising, then they will
continue to make that technology available to the installed user base.
It is also my opinion that the remaining installed base will want to stay on
Alpha as long as possible, especially if they bother with a migration to EV7
which won't be possible inside their exsiting wildfires.
WILLIAM WEBB
I was told some time ago that DII-COE on VMS would be
a two parter-
First step would be a revision and updating of the POSIX kit;
Second step would be full integration of the interfaces into the OS.
WWWebb
Fred Kleinsorge
>I was told some time ago that DII-COE on VMS would be
>a two parter-
>
>First step would be a revision and updating of the POSIX kit;
>Second step would be full integration of the interfaces into the OS.
Correct. Adding native UNIX capabilities to OpenVMS is progressing
independently of the initial COE product. IMHO the two most critical parts
are a native FORK and SELECT capabilities. But the work done for COE has
fixed a number of issues, such as UNIX file system and naming semantics.
_Fred
JF Mezei
> All that to say , much wiser to wait 'til COE pieces show up in
> VMS to revisit some of these tougher ports as they won't be so tough
> in a couple years.
Would large packages such as SAP really be able to run well in "unix
emulation" as opposed to being truly tailored to take advantage of the VMS
stuff ?
If they just recompile their unix version without really adding the stuff to
take advantage of clustering, distributed lock manager, file version numbers
etc, would the package really run well enough ?
Assuming that SAP is ported only to Itanium VMS (since you indicate it would
likely way for the DII-CEO thing to be ready before porting to VMS), will the
performance penalty of not being truly VMS-native and running in unix
emulation on VMS be such that customers would just prefer to run it on a real
unix on the same box ?
In other words, if the SAP port doesn't get tailored sufficiently to take
advantage of VMS' features and doesn't get adapted enough to use VMS
efficiently, would it really be a good solution ?
I realise that the goal of that posix-version-2 is to provide much better
emulation of unix with reasonable performance. But still, how much of a
performance hit will there be ?
Peter Kastner
news:c3afutsiacnglkef3...@4ax.com...
>
> As to "not unintelligent executives at HP" (I note you didn't say
> Compaq but will resist reading anything into that) you say in your
> report that the Alpha/VMS business together with NSK has contributed
> much of Compaq's profits (and DEC before it) in recent years. The
> Industry Standard business being loss making or breaking even at
> best. Yet Compaq have downplayed this business and emphasized their
> Wintel credentials. Do you have any comments on this?
We didn't mention Compaq executives because they are the acquirees and don't
have as much say in what happens as the HP execs do (with absolutely no
disrespect to new Platforms executive Peter Blackmore).
Compaq has lost a lot of money in the last year or two in the industry
standard PC business. They've made money on Intel-based servers, but the
margins have deteriorated there too (read: Dell), but the storage business
is way up ... it's a constantly changing linear equation.
It's a fact that computer companies do not tout their cash-cow installed
bases if for no other reason than legacy is not "new technology" nor does it
necessarily appeal to new customers. More than 75% (sometimes 95%) of
marketing dollars go to landing new accounts, not keeping old customers.
And it would be unseemly to remind legacy customers that the profits they
bring fuel new-product R&D.
>
> And finally do you stand by your recommendation that HP end the
> Itanium port? That would seem a bit strange in a thread subject
> "Compaq: VMS is alive and kicking".?
The thread I picked up from an October 23rd message I can no longer
retrieve. Apologize for the mischaracterization, but I did get a discussion
started!
Yes, we still feel that a VMS port to Itanium should be cancelled. First,
it would be a complex and probably costly migration that many customer
business managers would flinch at. Second, what's the price/performance on
Itanium compared to Alpha -- and when could that be measured? Third, it's
actually less likely that application providers would support a subset of
today's VMS base on Intanium with new ports (e.g., SAP) than on a stable
(loyal) VMS base.
If I could invest HP's money (ha!), I'd make sure that VMS customers were
kept happy with a secure Alpha roadmap for the rest of the decade. If that
means some modest Alpha improvements, then show me a budget.
>
> Thanks for clarifying things and we both seem to agree that if we want
> to keep VMS and push it back to the forefront we must not let up.
> Perhaps VMS engineering could invite you round for a briefing on just
> what VMS can do today and where they want to take it. You might be
> pleasantly surprised.
>
I doubt I would be surprised. I worked for DEC in 1987 in marketing (DECtp
and RDB 3 launch. TPC founder), so I have a deep and abiding respect for
VMS.
Peter
Alan Greig
wrote:
>
> All that to say , much wiser to wait 'til COE pieces show up in
> VMS to revisit some of these tougher ports as they won't be so tough
> in a couple years.
I'm well aware of the potential benefits of the DII-COE work and I've
put the COE/SAP question directly to various appropriate Compaq folks.
It is my understanding that the COE work is now quite advanced and it
would seem that *now* might be an appropriate time to consider such a
SAP project - not 2 or 3 years down the line when perhaps 50% of the
manufacturing business currently running on VMS (but in non VMS "core
industries" such as ourselves) might have already been forced to move
by various forces. A target release date of SAP on VMS two years from
now might swing POs hanging in the balance at the moment. It looks
right now as if I am about to lose another European plant (although
one of our smallest) to SAP. I can't keep taking hits for ever and
keep the remaining VMS MANMAN systems viable in an ocean of SAP. I'd
just end up centralizing more of our dwindling worldwide VMS services
- which would increase VMS presence locally for a few years but only
as a prelude to a final phase out perhaps 2-4 years away.
We need a clearer planning horizon if I hope to influence corporate
planning to consider VMS as potentially viable in the long term. And,
believe me, VMS is liked by many of our middle and senior worldwide IT
managers - it isn't just me although I am the most vocal :-) but we
need something more concrete to point to.
>
> Rob
--
Alan
Alan Greig
<klein...@star.zko.dec.com> wrote:
>
>Correct. Adding native UNIX capabilities to OpenVMS is progressing
>independently of the initial COE product. IMHO the two most critical parts
>are a native FORK and SELECT capabilities. But the work done for COE has
>fixed a number of issues, such as UNIX file system and naming semantics.
Now that's something which might interest the Aberdeen Group. And If
you could also get them up in one of the JSTARS planes (threatening to
drop them over Afghanistan if they don't come round :) that might help
as well. Let them see VMS in *real* action.
And with Microsoft almost certain now to be forced to fully document,
release and *help* third parties support it's API, if you could add a
(possibly sandboxed) WINE Windows Emulation Environment as well as the
COE work, then we might see VMS start to seriously take back the
desktop as IA64 works its way down.
>
>_Fred
>
>
>
--
Alan
Hoff Hoffman
:...I'm still progressing
:purchasing plans for more VMS Alpha systems and just last week gave a
:presentation of some of our web enabling and B2B/B2C interface work to
:board members including our CIO and IT Director (we are a
:multinational US Fortune 500 company). However you have to fight
:against comments such as "VMS can't do that" and "didn't Compaq kill
:Alpha" and "will it run SAP if we decide to migrate". Compaq's actions
:in downplaying VMS and being unable/unwilling to fund a SAP port over
:RDB seriously hinder our ability to propose what even the IT Director
:calls the "most reliable systems we have ever had".
Alan, if you would prefer, I can ask the local OpenVMS Ambassador to
look into this opportunity.
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoffman#xdelta.zko.dec.com
Alan Greig
<jfmezei...@videotron.ca> wrote:
>
>Would large packages such as SAP really be able to run well in "unix
>emulation" as opposed to being truly tailored to take advantage of the VMS
>stuff ?
>
>If they just recompile their unix version without really adding the stuff to
>take advantage of clustering, distributed lock manager, file version numbers
>etc, would the package really run well enough ?
This side of things would be handled by RDB providing the SQL service
to SAP. In ERP systems the underlying database is doing most of the
work most of the time. You could easily have a SAP port taking
advantage of the COE work but using native RDB as its engine.
SAP already supports Oracle, DB2, SQL Server and other database
engines. At one time I think it *did* support RDB. And modern RDB can
be made to present an interface almost identical to Oracle to an
application. For instance we use Oracle's own Developer/2000
application development tools to talk to a back-end RDB database.
Works well.
--
Alan
Fred Kleinsorge
>On Tue, 6 Nov 2001 10:08:23 -0500, "Fred Kleinsorge"
><klein...@star.zko.dec.com> wrote:
>
>
>>
>>Correct. Adding native UNIX capabilities to OpenVMS is progressing
>>independently of the initial COE product. IMHO the two most critical
parts
>>are a native FORK and SELECT capabilities. But the work done for COE has
>>fixed a number of issues, such as UNIX file system and naming semantics.
>
>Now that's something which might interest the Aberdeen Group. And If
>you could also get them up in one of the JSTARS planes (threatening to
>drop them over Afghanistan if they don't come round :) that might help
>as well. Let them see VMS in *real* action.
>
With the current situation, the plane is off limits (guys with M16's
guarding it).
>And with Microsoft almost certain now to be forced to fully document,
>release and *help* third parties support it's API, if you could add a
>(possibly sandboxed) WINE Windows Emulation Environment as well as the
>COE work, then we might see VMS start to seriously take back the
>desktop as IA64 works its way down.
>
I'm not sure any more that Windows emulation is the way. To my mind, Gnome
and Star Office might be a better alternative. But first things first... we
are getting all the X11 infrastructure back up to current revisions.
Rob Young
> Rob Young wrote:
>> All that to say , much wiser to wait 'til COE pieces show up in
>> VMS to revisit some of these tougher ports as they won't be so tough
>> in a couple years.
>
> Would large packages such as SAP really be able to run well in "unix
> emulation" as opposed to being truly tailored to take advantage of the VMS
> stuff ?
>
Absolutely... these are native system calls, not emulation.
SAP and and/or large DBs do this:
1) Read blocks
2) Write blocks
That is a simplification.
Much of the Read and Writing is a no brainer regardless of OS. While
folks have been real busy on the software side, the storage picture
has not been static. Today , if you are doing large DBs you are
most likely using one of the following for storage:
1) Compaq StorageWorks
2) HDS
3) EMC
4) IBM
5) Sun
6) Xiotech's Magnitude (good little product)
The picture is changing even as we speak. Compaq's HSV is a killer.
Absolutely grand product. I encourage everyone to read up a bit:
http://www.compaq.com/products/storageworks/enterprise/index.html
Tech Overview:
ftp://ftp.compaq.com/pub/products/storageworks/whitepapers/Storage_VirtualizationWP.pdf
All this to say, blocks are getting faster to read and just as
fast to write (writeback cache has been catching writes for a few
years, nothing new under the sun there).
With Compaq's product and Xiotech's, Virtualization is shining.
That RAID1 you wish to create could be spread across 100+ drives in
Compaq's product and 64 drives in Xiotechs. Say you had a DB
environment (200 Gig DB). It could be a single RAID1 that would
push 17000 I/Os per second. No problem. At 4K I/O size you would
be pushing 66 MByte/sec and a single RAID1 could be the home of
your DB spread across 100 drives. Many variations on this...
> If they just recompile their unix version without really adding the stuff to
> take advantage of clustering, distributed lock manager, file version numbers
> etc, would the package really run well enough ?
>
A lot of these products are pretty stupid. They support a broken
version of clustering, whereby you have this monster server and
a hotstandby... I can't speak for SAP (never used it) , but I do
know of a very large application that I was surprised to learn
works this way.
> Assuming that SAP is ported only to Itanium VMS (since you indicate it would
> likely way for the DII-CEO thing to be ready before porting to VMS), will the
> performance penalty of not being truly VMS-native and running in unix
> emulation on VMS be such that customers would just prefer to run it on a real
> unix on the same box ?
>
Find us a performance penalty.
> In other words, if the SAP port doesn't get tailored sufficiently to take
> advantage of VMS' features and doesn't get adapted enough to use VMS
> efficiently, would it really be a good solution ?
>
They don't need VMS feature set. They have to support many
Unixes and a guess would be they are using lowest common denominator
development strategy... i.e. don't use system specific bells and
whistles. Oracle, with RAC is going in the opposite direction.. but
keep in mind Oracle rolls their own DLM and now intend to roll their
own cluster filesystem (if I get that wrong, please clarify... that
is from memory).
> I realise that the goal of that posix-version-2 is to provide much better
> emulation of unix with reasonable performance. But still, how much of a
> performance hit will there be ?
If you are reading and writing blocks, I can help you mask that
"hit" with storage. As will many others. Not a problem. You
would be hard-pressed to find a performance hit (assuming your
application isn't brain dead and you are performing 100 forks
a second, sure there would probably be a heavier fork in VMS
than Unix. But again, an application written that poorly isn't
the norm).
Rob
WILLIAM WEBB
From your mouth to God's ears.
WWWebb
> -----Original Message-----
> From: Info-VAX...@Mvb.Saic.Com at INTERNET
> Sent: Tuesday, November 06, 2001 11:36 AM
> To: Webb, William W Raleigh, NC; Info...@Mvb.Saic.Com at INTERNET
> Subject: RE: Compaq: VMS is alive and kicking
>
>
> On Tue, 6 Nov 2001 10:08:23 -0500, "Fred Kleinsorge"
> <klein...@star.zko.dec.com> wrote:
>
>
> >
> >Correct. Adding native UNIX capabilities to OpenVMS is progressing
> >independently of the initial COE product. IMHO the two most
> critical parts
> >are a native FORK and SELECT capabilities. But the work
> done for COE has
> >fixed a number of issues, such as UNIX file system and
> naming semantics.
>
> Now that's something which might interest the Aberdeen Group. And If
> you could also get them up in one of the JSTARS planes (threatening to
> drop them over Afghanistan if they don't come round :) that might help
> as well. Let them see VMS in *real* action.
>
> And with Microsoft almost certain now to be forced to fully document,
> release and *help* third parties support it's API, if you could add a
> (possibly sandboxed) WINE Windows Emulation Environment as well as the
> COE work, then we might see VMS start to seriously take back the
> desktop as IA64 works its way down.
>
> >
> >_Fred
> >
> >
> >
>
> --
> Alan
>
Fred Kleinsorge
>>
>> And finally do you stand by your recommendation that HP end the
>> Itanium port? That would seem a bit strange in a thread subject
>> "Compaq: VMS is alive and kicking".?
>
>The thread I picked up from an October 23rd message I can no longer
>retrieve. Apologize for the mischaracterization, but I did get a
discussion
>started!
>
>Yes, we still feel that a VMS port to Itanium should be cancelled. First,
>it would be a complex and probably costly migration that many customer
>business managers would flinch at. Second, what's the price/performance on
>Itanium compared to Alpha -- and when could that be measured? Third, it's
>actually less likely that application providers would support a subset of
>today's VMS base on Intanium with new ports (e.g., SAP) than on a stable
>(loyal) VMS base.
>
>If I could invest HP's money (ha!), I'd make sure that VMS customers were
>kept happy with a secure Alpha roadmap for the rest of the decade. If that
>means some modest Alpha improvements, then show me a budget.
>
I can't (and don't) speak for Compaq or OpenVMS (nor can I comment at-all on
any merger related issues)...
But I do believe that the strategy that OpenVMS is currently on will keep
our Alpha customers happy, and we will deliver the Alpha EV6x/EV7/EV79
roadmap. It also provides a path to future hardware (the Itanium family) so
that there is life for VMS *after* the Alpha roadmap ends.
I believe that we can do this while continuing to provide new features, and
performance enhancements on Alpha, that will also apply to Itanium. That
unlike the "split" that exists now between the VAX and Alpha, that we will
be able to provide ongoing enhancements to both platforms by the use of a
single common source pool. The port to Itanium will *not* destablize
OpenVMS, and once complete nearly all software written for OpenVMS on one
architecture should simply compile and work on the other (exceptions being
things that know specifics about the underlying architecture - something
that is not common).
I also believe that the "migration" process between Alpha and Itanium will
be trivial in comparison to VAX to Alpha. While *any* migration needs to be
approached with some caution, we will make it as painless as possible for
customers to do, while not "forcing" them to abandon their Alphas now or in
the future. See the recent satisfaction guarantees we recently announced in
connection with Itanium.
My personal experience with presenting our plans to several large defense
customers was that they were satisfied with our plans. Mostly the questions
were as to timing, so they could decide between planning for Alpha of
Itanuim platforms on their future projects.
Not porting to Itanium places OpenVMS into truly a legacy/maintenance
position. And while there are some who already place us there today - you
might be suprised about the new and old business that we are in, which are
truly *not* legacy.
I have yet to hear from anyone here in OpenVMS engineering who thinks that
we can't deliver on the plans that are in place.
_Fred
Jerry Leslie
:
: And with Microsoft almost certain now to be forced to fully document,
: release and *help* third parties support it's API,
Not according to:
http://www.theregister.co.uk/content/4/22647.html
MS snags crucial authentication, DRM opt-outs in DoJ settlement
"...The biggest omission you'll notice, when comparing the agreement
against Judge Jackson's proposed behavioral remedies is the absence of
technical disclosure practice. The original conduct obliged Microsoft
to disclose APIs, and did so in some detail. It outlined the creation
of a neutral clean room: an independent verification facility staffed
by both industry opponents and Microsoft representatives, to ensure
that compatibility issues were solved within a fixed time period. Or
else.
In today's agreement, not only is Redmond not obliged to disclose APIs
to third parties, it's secured an explicit guarantee that it doesn't
have to. The small print in Section J 1 of the 'Prohibited Conduct'
notes:- .
"No provision of this Final Judgment shall:
1.Require Microsoft to document, disclose or license to third parties:
(a) portions of APIs or Documentation or portions or layers of
Communications Protocols the disclosure of which would compromise the
security of anti-piracy, anti-virus, software licensing, digital
rights management, encryption or authentication systems, including
without limitation, keys, authorization tokens or enforcement
criteria;
or (b) any API, interface or other information related to any
Microsoft product if lawfully directed not to do so by a governmental
agency of competent jurisdiction."
It's the most significant part of the entire agreement document, as it
describes oversight of Microsoft's future conduct in the most critical
areas of web services (authentication) and multimedia content (DRM).
It also represents an end-run around the AntiTrust Laws: Microsoft
only needs to claim that its security is being compromised to get the
authority of a Government policeman. In its own way, this section
institutionalizes corporate malfeasance..."
Here's a review of the "caress on the wrist" settlement:
http://www.ccianet.org/ms_antitrust/sell_out.htm
Analysis Of a Sell-Out: The DOJ-Microsoft Deal
--Jerry Leslie (my opinions are strictly my own)
Robert Deininger
<kas...@aberdeen.com> wrote:
> > Thanks for clarifying things and we both seem to agree that if we want
> > to keep VMS and push it back to the forefront we must not let up.
> > Perhaps VMS engineering could invite you round for a briefing on just
> > what VMS can do today and where they want to take it. You might be
> > pleasantly surprised.
> >
>
> I doubt I would be surprised. I worked for DEC in 1987 in marketing (DECtp
> and RDB 3 launch. TPC founder), so I have a deep and abiding respect for
> VMS.
Do you mean you're making recommendations about a product you've been away
from for 14 years? I'm sure you've had some contact since 1987, but a
visit to bring you up-to-date would probably be helpful.
--
Robert Deininger
rdein...@mindspring.com
Rob Young
> Peter Kastner wrote in message <9s8vd5$6...@dispatch.concentric.net>...
>>>
>>> And finally do you stand by your recommendation that HP end the
>>> Itanium port? That would seem a bit strange in a thread subject
>>> "Compaq: VMS is alive and kicking".?
>>
>>The thread I picked up from an October 23rd message I can no longer
>>retrieve. Apologize for the mischaracterization, but I did get a
> discussion
>>started!
>>
>>Yes, we still feel that a VMS port to Itanium should be cancelled. First,
>>it would be a complex and probably costly migration that many customer
>>business managers would flinch at. Second, what's the price/performance on
>>Itanium compared to Alpha -- and when could that be measured? Third, it's
>>actually less likely that application providers would support a subset of
>>today's VMS base on Intanium with new ports (e.g., SAP) than on a stable
>>(loyal) VMS base.
>>
Peter,
To jump in on what you wrote here (I actually planned a lengthy
response to shoot holes in your HP/MPE comparison, more on
that later)... Few things:
To retrive other messages, click on:
click on "Advanced Search"
A top-notch analyst like yourself should try to come up to speed
on technique.
Second.. and more to the chase. In other trade rag writings (can't
source it, but someone with your resources should be able to find
it), a writer points out that VMS engineering has 30-35 engineers
dedicated to the port. So while you state:
"Yes, we still feel that a VMS port to Itanium should be cancelled. First,
it would be a complex and probably costly migration that many customer
business managers would flinch at."
Strike 1 on that, see above. Just as importantly, it seems as if you
are making that judgement in a vacuum. Have you even contacted
VMS engineering to hear from the horses mouth just how difficult
/expensive this migration is? Someone actually involved in the
port (Fred Kleinsorge) points out the ease of the port. It seems as
if you haven't explored the cost. Do you make all your judgements and
analysis in a vacuum?
Further, another of your strikes against the port:
"Second, what's the price/performance on Itanium compared to Alpha -- and when
could that be measured?"
By this reasoning, no one should be porting as X86 outperforms
Itanium and will for some time. SGI shouldn't port Irix *yet*,
should they? And why in the world is HP porting? Are you fishing
for a future crossover point when the actual migration Alpha->Itanium
occurs or makes sense? We speculate on that too. Why not contact
Compaq and get their read. To suggest the port shouldn't occur
*because* of performance issues is laughable as FRV of Itanium sucks
regarding performance and it may take 1-2 more generations to come up
to RISC. The former Alpha engineers will surely help that,
why not contact Intel to find out what their outlook is on
Itanium performance futures.
"Third, it's actually less likely that application providers would support a
subset of today's VMS base on Intanium with new ports (e.g., SAP) than on a
stable (loyal) VMS base."
Okay.. whatever that means. I think you are stating they will lose
ISVs going to Itanium. They may actually gain some. Why not
contact Compaq and find out their read on that one too.
All and all, I would say your reasons for cancelling the port are
very poor and not supported by Compaq in their public statements.
Your Weakest Link is the whole cost issue. Not well researched
at all there.
Take care,
Rob Young
Alan Greig
Hoff Hoffman wrote:
> Alan, if you would prefer, I can ask the local OpenVMS Ambassador to
> look into this opportunity.
>
Thanks Hoff but you'll be pleased to hear he's well aware of what we hope to do and has always been
very helpful. Also the senior guy at our preferred channel partner is a former DEC colleague of the
local VMS ambassador (Dave Foddy btw) and the two have discussed a tentative disaster tolerant
solution. I've also discussed things with one or two ex VMS engineering types who happen to be local
to us these days.
All I can really do now is keep fingers crossed but even if the main project does not go ahead we
still have some existing development work.
--
Alan Greig
Alan Greig
Fred Kleinsorge wrote:
> With the current situation, the plane is off limits (guys with M16's
> guarding it).
>
Hmm... could advising the termination of a current key defence operating system
be considered treason. You're right - better not let them near the Aberdeen
Group :-) :-)
And, if I recall correctly, the US army executed Bill Gates in the South Park
movie.
> I'm not sure any more that Windows emulation is the way. To my mind, Gnome
> and Star Office might be a better alternative. But first things first... we
> are getting all the X11 infrastructure back up to current revisions.
I agree. Microsoft has been at least slowed by all the legal action surrounding
them and existing alternatives could always 'grow up' on VMS with the right
help. But it would still be nice if VMS could one day run MS apps better than
NT. If resources could be found.
--
Alan Greig
Rob Young
Peter Kastner wrote:
"Yes, we still feel that a VMS port to Itanium should be cancelled. First,
it would be a complex and probably costly migration that many customer
business managers would flinch at. "
Misread that , and picking up on your meaning and not my read...
Having been involved in a number of sizable migrations from VAX to
Alpha, I have done it two different ways:
1) Immediate cutover
2) Long migration
2) involves plugging Alphas into the existing VAXCluster.
This was mostly homegrown applications that involved recompiling
source code. A few applications remain on VAX (2 actually) due to
source code loss and/or no port being available for Alpha. A recent
example of 1) involved a cutover in less than 8 hours time. DBs
using Alpha based executables instead of VAX. Weeks of testing prior
to cutover. Very simple and flawless. All scripting of course
required little or no modification. The vendor supports both
platforms. The cost in both cases was easy to justify. Higher
performing boxes, cheaper and warranty bundles to further lessen
the cost. No source code issues on my end, the vendor was/is
responsible for those deliverables. I would suspect many VMS shops
aren't homegrown and if they have an VAX->Alpha migration under
their belt, the Alpha->Itanium migration will be a piece of cake.
One would also imagine there will be substantial incentives to
kick start VMS on Itanium. There is a porting program for ISVs
to port their apps to Itanium and I do believe that has been mentioned
here before (in other words, VMS ISVs may get money to make their
apps available on Itanium).
It is been stated here that Itanium servers will plug into existing
Alpha clusters.
I have performed VAX->Alpha immediate cutover numerous times, the
long term migration route once. In all cases, it was a demonstratable
win on cost. Alpha compilers deal well with VAX source. The Itanium
compilers should be even cleaner on re-compile. I challenge you to
come up with evidence that supports a "complex" and "costly migration"
scenario.
As I pointed out earlier, the VMS migration to Itanium certainly
doesn't fit that bill, I seriously doubt that will be the case
for us end users either.
Rob
Bob Ceculski
> Compaq has lost a lot of money in the last year or two in the industry
> standard PC business. They've made money on Intel-based servers, but the
> margins have deteriorated there too (read: Dell), but the storage business
> is way up ... it's a constantly changing linear equation.
and they will continue to do so Peter, as home sales shrink to the
coming
cable internet explosion (aol, time warner) as i will be able to surf
the
web, email, do banking, get movies, etc. from a do-it-all smart cable
box.
with the power of chips exponentially increasing, backend servers
running
vms, unix, and linux will dominate as these platforms are more well
suited
to running multiple apps and users well, unlike windows ... vms could
rule
the high end if continued ...
> It's a fact that computer companies do not tout their cash-cow installed
> bases if for no other reason than legacy is not "new technology" nor does it
> necessarily appeal to new customers. More than 75% (sometimes 95%) of
> marketing dollars go to landing new accounts, not keeping old customers.
> And it would be unseemly to remind legacy customers that the profits they
> bring fuel new-product R&D.
vms is hardly legacy ... it is a terrific web platform, if only
development
will continue ... if legacy means security, reliability and
scalability, then i'll take legacy over blue screens and IIS ...
>
> Yes, we still feel that a VMS port to Itanium should be cancelled. First,
> it would be a complex and probably costly migration that many customer
> business managers would flinch at. Second, what's the price/performance on
> Itanium compared to Alpha -- and when could that be measured? Third, it's
> actually less likely that application providers would support a subset of
> today's VMS base on Intanium with new ports (e.g., SAP) than on a stable
> (loyal) VMS base.
wrong, we would port and vms is not expensive!
>
> If I could invest HP's money (ha!), I'd make sure that VMS customers were
> kept happy with a secure Alpha roadmap for the rest of the decade. If that
> means some modest Alpha improvements, then show me a budget.
then why not tell them that?
> I doubt I would be surprised. I worked for DEC in 1987 in marketing (DECtp
> and RDB 3 launch. TPC founder), so I have a deep and abiding respect for
> VMS.
>
> Peter
dec had a marketing department? your kidding, aren't you?
John Vottero
> >
> > And finally do you stand by your recommendation that HP end the
> > Itanium port? That would seem a bit strange in a thread subject
> > "Compaq: VMS is alive and kicking".?
>
> The thread I picked up from an October 23rd message I can no longer
> retrieve. Apologize for the mischaracterization, but I did get a
discussion
> started!
>
> Yes, we still feel that a VMS port to Itanium should be cancelled. First,
> it would be a complex and probably costly migration that many customer
> business managers would flinch at. Second, what's the price/performance
on
> Itanium compared to Alpha -- and when could that be measured? Third, it's
> actually less likely that application providers would support a subset of
> today's VMS base on Intanium with new ports (e.g., SAP) than on a stable
> (loyal) VMS base.
>
> If I could invest HP's money (ha!), I'd make sure that VMS customers were
> kept happy with a secure Alpha roadmap for the rest of the decade. If
that
> means some modest Alpha improvements, then show me a budget.
>
Are you really recommending that HP/Compaq announce the retirement of VMS?
Even with a 10 year roadmap, if they cancel the plans for year 11 onward,
then that means we had better get started migrating to something else
because it's going to take at least 10 years. If HP/Compaq starts us on a
forced march, we won't be marching towards HP-UX.
(Note: "We"/"us" refers to the typical OpenVMS user).
Keith Parris
...some very good information.
Peter, thanks for participating in this discussion and lending an ear
to our feedback.
Some comments on the analysis:
> The customer base ranges from fanatical (HP 3000 and VAX)
> to somewhat satisfied.
This drastically understates the fanaticism of OpenVMS
users on Alpha. :-)
Or did you mean to say VMS instead of VAX? (don't feel bad
-- it's a very common mistake).
> Tru64 Unix development has remained active... OpenVMS
> has basically been in maintenance mode for the past
> several years -- with a few new features added to help
> retain the large installed base
If you check the numbers from Compaq, I think you'll find
there's been far more spending on VMS development than on
Tru64. VMS has been getting between $200 and $300
million per year. Tru64 has probably gotten far more
marketing dollars (a well publicized $100 million not long
ago comes to mind), but its development dollars are
probably less than half those of VMS development.
Tru64 development finally shipped TruClusters recently (a
big accomplishment, but that had been in the works since
bout 1994). On the VMS side, support for new hardware,
including NUMA systems and Fibre Channel storage, might be
taken for granted, as may the XFC cache, Volume Shadowing
Mini-Copy with Write Bitmaps, significant recent
performance improvements to RMS, the lock manager, LAN
clustering, and SMP scalability, but there's been a lot of
major new work recently that can't be dismissed as
insignificant, particularly Galaxy and the DII-COE effort.
> Digital had planned to migrate OpenVMS users to Windows
> NT on Alpha, but...
Oh, you must have missed the "Digital had planned to
migrate OpenVMS users to Digital Unix" phase which
immediately preceded that strategy.
> NonStop Kernel is the OS for the MIPS-based NonStop
> Himalaya servers. These systems are high-end,
> low-volume, niche market systems with few, if any
> competitors. They play primarily in markets like
> financial services that place the greatest premium
> on system availability.
Why Compaq and Aberdeen can recognize this, but fail
to see the unique value that VMS high-availability and
disaster-tolerant clusters (also popular in the
financial world) provide, eludes me. And VMS has 3
imes the revenues of NonStop, with profits to match.
> HP/Compaq should complete the port of NonStop Kernel
> to Itanium. This technology, which has little
> credible competition now that Stratus is no longer a
> serious player, cannot be replaced by HP-UX. Without
> this port, the new HP/Compaq will lose this market
> and the high margins that come with it to IBM -- as
> well as damage relationships established at household
> name customers like NASDAQ.
This same logic applies even more strongly to VMS, which
has a much larger installed base and 3 times the
revenues/profits of NonStop Kernel, and a much larger
list of "household name" customers to offend as well.
> The HP Marketing organization should take the lead for
> the remaining server OSs because it has focused on
> Itanium over the past year and has functioning
> marketing programs in place.
Over the past year? For crying out loud, HP has been
able to prepare so well because Itanium was _years and
years_ late getting out of the gate.
> By contrast, Tru64 UNIX and OpenVMS marketing has only
> recently considered any strategy that looks beyond
> Alpha.
Until the June 25 announcement which blind-sided both of
those marketing groups, Alpha was only halfway through
its 25-year lifetime. If anything, I'm surprised
they've been able to do as well as they have given the
cards they were dealt.
> StorageApps should be the survivor. VersaStor is very late
VersaStor is shipping. Take a look at the HSV, and you
might find good reasons to reconsider that recommendation.
> Service Opportunities and Challenges
As others have pointed out in this group, service revenues
depend on having an installed base left to service, and
service margins for VMS are much better than those for PCs.
-------------------------------------------------------------------
Keith Parris | parris at encompasserve dot org | VMS consulting on:
Clusters, Disaster Tolerance, Internals, Performance, Storage & I/O
JF Mezei
> All and all, I would say your reasons for cancelling the port are
> very poor and not supported by Compaq in their public statements.
> Your Weakest Link is the whole cost issue. Not well researched
> at all there.
Mr Young, while you make fair points, the validity of that report in VMS
engineer's eyes is less important that its reception by the public/IT managers/CIOs.
It is especially the fact that Compaq chose to publish this report to the SEC
because it supported the merger even though it was very damning to VMS that is
important here. It means that Compaq doesn't mind/care when those
report-producing outfits portray VMS very negatively.
If those 35 engineers working for a few years on that port to a hype-ware chip
causes a delay in the completion of the unix compatibility (DII-COE) then VMS
loses.
By the time intel might release a palatable chip with VMS actually running on
it in configurations that compete against alpha, VMS customers may have
already had in invest in EV7 wildfire boxes and they are not likely to migrate
to that IA64 thing any time soon.
JF Mezei
> using Alpha based executables instead of VAX. Weeks of testing prior
> to cutover. Very simple and flawless.
Will Compaq pay for the customer's "weeks of testing" ? If you have to take
resources away from your core business to have them do a project which brings
the company absolutely nothing new and is the result of Curly killing his own
superior and profitable products in favour of intel/microsoft , then that
means you have weeks of staff being paid to do very unproductive stuff.
And since the remaining VMS customers tend to be those large shops with
mission critical systems, having dual systems running at the same time during
testing means that a large percentage of the remaining MS customers base will
see that migration as a major capital outlay as well as costing a lot of human
resources to test the new environment.
And don't forget the softwrae makers of those mission critical systems. They
too will have to do extensive testing to certify their application on the new platform.
At a time when VMS isn't doing too well, asking customers to do that migration
is asking too much. That is one reason I firmly believe that customers will
stay on Alpha as long as possible and the longer they wait to move to IA64,
the more the chances that other vendors' products will have grown sufficient
features to be chosen to replace VMS.
Bill Todd
Fred Kleinsorge <klein...@star.zko.dec.com> wrote in message
news:KMUF7.1320$RL6....@news.cpqcorp.net...
> Peter Kastner wrote in message <9s8vd5$6...@dispatch.concentric.net>...
...
> >Yes, we still feel that a VMS port to Itanium should be cancelled.
First,
> >it would be a complex and probably costly migration that many customer
> >business managers would flinch at. Second, what's the price/performance
on
> >Itanium compared to Alpha -- and when could that be measured? Third,
it's
> >actually less likely that application providers would support a subset of
> >today's VMS base on Intanium with new ports (e.g., SAP) than on a stable
> >(loyal) VMS base.
> >
> >If I could invest HP's money (ha!), I'd make sure that VMS customers were
> >kept happy with a secure Alpha roadmap for the rest of the decade. If
that
> >means some modest Alpha improvements, then show me a budget.
> >
>
>
> I can't (and don't) speak for Compaq or OpenVMS (nor can I comment at-all
on
> any merger related issues)...
>
> But I do believe that the strategy that OpenVMS is currently on will keep
> our Alpha customers happy,
Only until such time as Alpha ceases to be a attractive platform (due to
performance obsolescence, purchasing difficulty/expense, and/or
disinclination to continue investing in a dying architecture). At that
point, they'll have to migrate, which is never a happy occasion and
justifiable only when the new platform offers some significant feature
(e.g., absolute, industry-leading performance, cost/performance, and a
bright future in the migration from VAX to Alpha) that the old one lacked.
IPF will never offer industry-leading performance unless IBM drops POWER4
and its descendents: it carries around far too much useless fat on its
chip, the complexity of which also makes it harder to incorporate those
features that could help it out of the hole it's in even when shrinks make
more chip area available for them.
IPF will never offer great cost/performance unless AMD folds its tent:
POWER4 will be more attractive at the high end (where ancillary server
hardware makes per-processor cost far less important) and IA32 plus Hammer
will be *far* more attractive at the low end.
Which means that IPF likely won't be able to offer much in the way of a
bright future, either: strike 3.
and we will deliver the Alpha EV6x/EV7/EV79
> roadmap. It also provides a path to future hardware (the Itanium family)
so
> that there is life for VMS *after* the Alpha roadmap ends.
Better to state that IPF offers a life-line that *could* save VMS after
Alpha's disappearance - if anyone is interested.
...
> Not porting to Itanium places OpenVMS into truly a legacy/maintenance
> position.
Only if it's not accompanied by a resurrection of Alpha development, which
was the other half of Peter's suggestion: with continued Alpha development,
it rather keeps VMS on an industry-leading hardware platform - and without
the migration hassles for customers that would occur with, for example, a
port to POWER4...
Now that Bill Hewlett's family has taken a stand against the acquisition by
HP, we may (one hopes) be one step closer to waving a none-too-early
farewell to Curly and his cohorts. If so, Alpha might yet have a chance to
rise again; if not, my guess is that nothing cHomPaq does will make all that
much difference to their (or VMS's) viability.
- bill
Bill Todd
Rob Young <you...@encompasserve.org> wrote in message
news:hi9cwi...@eisner.encompasserve.org...
...
> Second.. and more to the chase. In other trade rag writings (can't
> source it, but someone with your resources should be able to find
> it), a writer points out that VMS engineering has 30-35 engineers
> dedicated to the port. So while you state:
>
>
> "Yes, we still feel that a VMS port to Itanium should be cancelled.
First,
> it would be a complex and probably costly migration that many customer
> business managers would flinch at."
>
> Strike 1 on that, see above.
Since you've already corrected your above erroneous impressions elsewhere, I
won't do so again here.
...
> Further, another of your strikes against the port:
>
> "Second, what's the price/performance on Itanium compared to Alpha -- and
when
> could that be measured?"
>
> By this reasoning, no one should be porting as X86 outperforms
> Itanium and will for some time.
Surprise: no one *is* porting, at least not any customers. For that
reason, and for the additional reason that there's little to make one
suspect that IPF will *ever* be competitive in performance or
cost/performance - and certainly not soon enough for anyone to be in any
rush to port to it.
SGI shouldn't port Irix *yet*,
> should they?
SGI performed a great deal of their porting effort under the impression that
IPF was going to be a significant step forward, before events proved that
this was not the case at all. They're now keeping their MIPS options open
for the indefinite future, unlike Compaq with Alpha.
And why in the world is HP porting?
Given the continued viability of PA-RISC, that's an excellent question.
Perhaps it's because this was all their brain-child, starting 12 years ago
as the follow-on to PA-RISC, and they still believe in it. But they're
keeping their PA-RISC options open for the indefinite future as well (again,
unlike Compaq with Alpha).
Of course, neither SGI nor HP had a platform with Alpha's current and
potential future performance, so using them as examples wouldn't be entirely
persuasive even if they *were* as committed to jettisoning their existing
platforms as Compaq is.
Are you fishing
> for a future crossover point when the actual migration Alpha->Itanium
> occurs or makes sense? We speculate on that too. Why not contact
> Compaq and get their read.
Because Compaq is clearly run by idiots whose opinion is less than
worthless - even if you thought they could be relied upon to give an honest
answer in the first place? That would be my guess, but Peter will have to
answer for us to know for sure.
To suggest the port shouldn't occur
> *because* of performance issues is laughable as FRV of Itanium sucks
> regarding performance and it may take 1-2 more generations to come up
> to RISC.
One generation is McKinley, and all indications are that it won't cut the
mustard (and won't even come close to doing so).
Then come Madison (a shrunk McKinley core, with more on-chip cache) and
Deerfield (a cost-reduced Madison, with less on-chip cache): they won't cut
the mustard either, but since they're basically rehashed McKinleys perhaps
they don't qualify as the next generation.
Whatever generation you want to call it, it's looking like about 2005 before
an IPF member comes down the pike that might start looking better than what
IBM offers today and EV7 - and Hammer - will offer next year. Plenty of
time to crank up a VMS port if/when that schedule (and its resulting
product) is better defined.
The former Alpha engineers will surely help that,
> why not contact Intel to find out what their outlook is on
> Itanium performance futures.
Their outlook, last I knew, was very optimistic: there's just *so much*
room for improvement. But the complexity of the architecture not only makes
that improvement difficult (pushing a resulting product out to 2005 for
peripheral enhancements like on-chip glue for MP and memory and 2006 for
gut-level changes like incorporating OOO and SMT into an architecture
explicitly predicated on their absence) but keeps the result one step behind
cleaner designs that don't have all that useless baggage to carry around.
...
> All and all, I would say your reasons for cancelling the port are
> very poor and not supported by Compaq in their public statements.
> Your Weakest Link is the whole cost issue. Not well researched
> at all there.
Hmmm. Low per-processor cost has little to do with mid-range-and-up server
pricing. And the added expense of industrial-strength boxes - regardless of
what processors are inside - means that they'll never penetrate the low-end
server market, and hence never attain the volumes necessary to break that
rule. Methinks Peter is not the Weak Link here.
- bill
JF Mezei
> And why in the world is HP porting?
Could it be that they saw a threath from Alpha and decided to team up with
Intel to come up with a chip that could compete ? And now that IA64 is about
to be a flop, killing Alpha was an easy way to save the day.
> Then come Madison (a shrunk McKinley core, with more on-chip cache) and
> Deerfield (a cost-reduced Madison, with less on-chip cache): they won't cut
> the mustard either, but since they're basically rehashed McKinleys perhaps
> they don't qualify as the next generation.
For all its design flaws, if intel was able to take the 8086 and turn into
some respectable high end chip, shouldn't it eventually be able to take the
bloated IA64 and make it pretty fast ?
Joseph B. Gurman
<kas...@aberdeen.com> wrote:
[snip]
>
> As to the root question, I recommend that concerned VMS users look up
> their
> counterparts who own HP 3000's. From our vantage point, HP is not giving
> any more support to its own venerable HP 3000 base than it is to the
> Compaq VMS base. If enough critical customers of either/both platforms make
> enough noise and promise to buy enough computers, then the not unintelligent
> executives at HP will make a sensible business decision.
Mr. Kastner's message is a serious one, so I will not mock it, but I
find it very difficult to refrain from asking, "Could you please name
them [the execs]?" in response to the last sentence, particularly in
light of the Hewlett family's far better appreciation of the core
business of HP than the top execs'. (Or maybe that should be "exec's?")
It seems that every time a large computer vendor has absorbed
another with different major markets, they have shown that they failed
to understand the those markets, or even the products sold to them. And
every time, that misunderstanding has proven very bad for the buying
company's shareholders.
Not being an industry analyst, and with no experience in corporate
management, I can only surmise that such a situation occurs because the
boards of major computer vendors feel more comfortable with generalist
CEO's at the helm, rather than individuals with first-hand knowledge of
the customer's-eye-view of the business. I believe that is in the long
run a fatal weakness, and I trust the wisdom of the Hewlett family
members over the apparent desperation of HP and Compaqupper management.
Joe Gurman
Strictly amateur industry observer
Rob Young
True... no more than if someone just purchased GS320s. They would
be doing incremental upgrades to EV69 if CPU horsepower became
inadequate or more than likely plugging more into their SAN fabric.
But one of my main points can't be ignored. Cross-architecture
VMS clusters are common , adding another architecture isn't that
difficult, nor costly, and I suspect Itanium servers will be quite
a bit cheaper than AlphaServers.
I think there is a great overlooked in examining paradigms. The Wintel
way is to buy servers .. many of them and structure your application
accordingly... VMS has never been part of that paradigm. However,
it will benefit immensely. After all , those "rabbit" servers (keep
getting more and more of them) have to stay cheap or the Wintel
paradigm and the cost center it generates and supports will break down
and Wintel certainly isn't going to let that happen.
Rob
Bill Todd
...
> But one of my main points can't be ignored. Cross-architecture
> VMS clusters are common , adding another architecture isn't that
> difficult, nor costly,
It may not be all that costly for *Compaq* to add the IPF architecture to
VMS's repertoire, but that cost will pale in comparison with the aggregate
cost across all ISVs and customers of porting their applications and
installations to it (unless most don't bother to). If indeed there are
anything like 400,000 VMS installations, an average porting cost of just a
few hundred dollars would likely exceed Compaq's costs - and the *real*
average porting cost is much more likely to be at least a couple of orders
of magnitude higher.
and I suspect Itanium servers will be quite
> a bit cheaper than AlphaServers.
I'm getting tired of hearing this garbage: please analyze exactly what
server components will cost less (and how much) and compare it with total
server cost before repeating it again.
Enterprise servers aren't something one can build in a garage shop like PCs:
they have strict characterization, validation, and RAS requirements that
aren't compatible with high-volume, low-cost production at either the box or
the individual component level, and those costs persist regardless of what
processors happen to be in the center of it all (and eclipse the cost of
those processors).
The cost of the Alpha processors in a current mid-range or better
AlphaServer is a *small* percentage of the whole. Replace them with
McKinleys and the box price won't change significantly (unless you try to
recoup the cost of developing the McKinley version, in which case the price
will go *up*) - even if you *give the McKinleys away*.
Eventually, when a lot more of the glue has migrated onto the processor chip
(as it already has in POWER4 and will next year in EV7 and Hammer), it *may*
become possible to start producing higher-end server boxes at lower costs
(and where the processors contribute more significantly to the box price).
But IPF won't have such a product before 2005, and until then all that
high-quality glue (and other high-quality box content) is what will
determine the price of all but low-end IPF boxes.
>
> I think there is a great overlooked in examining paradigms. The Wintel
> way is to buy servers .. many of them and structure your application
> accordingly... VMS has never been part of that paradigm. However,
> it will benefit immensely.
That might have been true back in 1997, when IPF was originally supposed to
hit the streets and dazzle the world. But now it's the end of 2001, a
usable IPF member won't appear until sometime next year, and IBM has already
had notable success in teaching customers that *even if* they buy into that
paradigm the most cost-effective, reliable, and hassle-free way to implement
it is to run a bunch Linux servers on a single (or mirrored) z-Series box.
There may be a few places where a server farm still makes sense, but in most
of those an IA32- or Hammer-based farm will make more sense than an IPF
farm. 'Fraid IFP missed the boat on that source of volume - and on most
others as well.
- bill
Ken Farmer
news:cf15391e.01110...@posting.google.com...
> "Peter Kastner" <kas...@aberdeen.com> wrote in message
news:<9s71lb$m...@dispatch.concentric.net>...
> If you check the numbers from Compaq, I think you'll find
> there's been far more spending on VMS development than on
> Tru64. VMS has been getting between $200 and $300
> million per year. Tru64 has probably gotten far more
> marketing dollars (a well publicized $100 million not long
> ago comes to mind), but its development dollars are
> probably less than half those of VMS development.
Come on man...you don't actually think that $100 million figure was real.
:)
Ken
--
Ken Farmer, kfa...@tru64.org
Tru64.org, http://www.tru64.org
Tru64.org Newsletter:
http://www.tru64.org/pages.php?page=Newsletter-Registration
Alan Greig
wrote:
>
> A lot of these products are pretty stupid. They support a broken
> version of clustering, whereby you have this monster server and
> a hotstandby... I can't speak for SAP (never used it) , but I do
> know of a very large application that I was surprised to learn
> works this way.
Yep, that's the way SAP wants you to work as well. OPS isn't supported
and neither is RAC yet. In a typical SAP configuration if you need
redundancy then you either have a duplicated hot standby database
server or you set up the hot standby on a separate application server
and take the performance hit on apps should the main database server
go down. And this is the method which supposedly highly intelligent
CEO's of major IT companies think is the only method, Here's a quote
from Michael Capellas talking to Gartner which has just been filed
with the SEC:
"AS ANYBODY WHO EVER RAN A DATA CENTER KNOWS, IF YOU HAVE A SITE YOU
HAVE A HOT BACKUP. SO YOU WAIT FOR THAT ONE DAY TO TURN IT ON AND YOU
KEEP ALL THAT CAPACITY IN PLACE FOR THAT ONE DAY YOU MAY NEED TO TURN
IT ON, WHAT YOU ACTUALLY WANT TO KNOW IS IF THE APPLICATION WILL
ACTUALLY WORK."
Maybe someone should explain exactly how VMS disaster tolerant
clusters work to Mr Capellas. Elsewhere he tells Gartner that
Microsoft has the best technology and there's no point in Compaq
competing. As an example he says that MS's database products are the
best on the market. If that's not enough he tells us that Alpha was
dropped because Intel has a better product.
Capellas hints at one point that all the negativity has been getting
him down and jokes that he thought he was going to be asked about his
drink problem. I almost feel sorry for Capellas. The more I read, the
more I feel he doesn't really believe in what he's doing at all but
has to mouth the words.
Also amongst the recent filings we find out that Mike Winkler has been
designated VP Operations of the combined company confirming his
continuing influence.
SEC filings for Compaq at
http://quicken.elogic.com/sec_filings.asp?ticker=CPQ
And for HP at
http://quicken.elogic.com/sec_filings.asp?ticker=HWP
--
Alan
Alan Greig
wrote:
>"Keith Parris" <keithparr...@yahoo.com> wrote in message
>news:cf15391e.01110...@posting.google.com...
>> "Peter Kastner" <kas...@aberdeen.com> wrote in message
>news:<9s71lb$m...@dispatch.concentric.net>...
>
>> If you check the numbers from Compaq, I think you'll find
>> there's been far more spending on VMS development than on
>> Tru64. VMS has been getting between $200 and $300
>> million per year. Tru64 has probably gotten far more
>> marketing dollars (a well publicized $100 million not long
>> ago comes to mind), but its development dollars are
>> probably less than half those of VMS development.
>
>
>Come on man...you don't actually think that $100 million figure was real.
I'm puzzled by $300 million VMS annual development. Are there 300
people working for VMS engineering on $1 million a year or something?
Or 50 on $6 million or what. Ok staffing isn't everything but what on
earth has VMS engineering been doing with $ 300 million a year. Or
have we tagged all of the Alpha chip, systems etc design cost onto
VMS?
Anyone clarify?
>
>Ken
--
Alan
Nic Clews
>
> On 6 Nov 2001 10:43:35 -0600, you...@encompasserve.org (Rob Young)
> wrote:
> > A lot of these products are pretty stupid. They support a broken
> > version of clustering, whereby you have this monster server and
> > a hotstandby... I can't speak for SAP (never used it) , but I do
> > know of a very large application that I was surprised to learn
> > works this way.
>
> Yep, that's the way SAP wants you to work as well. OPS isn't supported
> and neither is RAC yet. In a typical SAP configuration if you need
> redundancy then you either have a duplicated hot standby database
> server or you set up the hot standby on a separate application server
> and take the performance hit on apps should the main database server
> go down.
I don't know anything about SAP but what you've said Alan confirms what
I thought I knew, that SAP is just not geared to any fault tolorance,
downtime for backups, redundancy, ...
Why the HELL should anyone want to run it? Vain hope systems remain up?
Surely VMS does not need software written with that methodology in mind,
why should VMS help those who can't help themselves?
If SAP is being bought because its flavour of the month then the buggy
thinking extends to those who purchase, I notice their [SAP] profits are
down this time.
Feel free to educate me about the wonders of SAP, but I think you've got
an uphill task.
--
Regards, Nic Clews CSC Computer Sciences
nclews at csc dot com
Bob Ceculski
> Alan Greig wrote in message <801gut4nsoep7mmu1...@4ax.com>...
> >On Tue, 6 Nov 2001 10:08:23 -0500, "Fred Kleinsorge"
> ><klein...@star.zko.dec.com> wrote:
> >
> >
> >>
> >>Correct. Adding native UNIX capabilities to OpenVMS is progressing
> >>independently of the initial COE product. IMHO the two most critical
> parts
> >>are a native FORK and SELECT capabilities. But the work done for COE has
> >>fixed a number of issues, such as UNIX file system and naming semantics.
> >
> >Now that's something which might interest the Aberdeen Group. And If
> >you could also get them up in one of the JSTARS planes (threatening to
> >drop them over Afghanistan if they don't come round :) that might help
> >as well. Let them see VMS in *real* action.
> >
>
bring back the mica code! it must have worked or cutler would never have
stormed out of dec west and bill gates would never have hired him and
used stolen mica code to design nt ... isn't nt what vms w/windows would
have been like minus the blue screens?
Bob Ceculski
bring back the mica code! it must have worked or cutler would never have
Paul Repacholi
> SGI performed a great deal of their porting effort under the
> impression that IPF was going to be a significant step forward,
> before events proved that this was not the case at all. They're now
> keeping their MIPS options open for the indefinite future, unlike
> Compaq with Alpha.
SGI canned all future MIPS development some years ago, and cleared out
all their engineers. Their future was fully itanic, full steam ahead!!
They have now turned that around, and are reparing the damage.
> And why in the world is HP porting?
> Given the continued viability of PA-RISC, that's an excellent
> question. Perhaps it's because this was all their brain-child,
> starting 12 years ago as the follow-on to PA-RISC, and they still
> believe in it. But they're keeping their PA-RISC options open for
> the indefinite future as well (again, unlike Compaq with Alpha).
HP canned PAs in 96 or so, then had to bring out new chips to cover
the years between the original and eventual ship date for merced. This
included taking HP-PA from 32 to 64 bit with the HPPA 2 arch. So porting
HPUX is just part of the day to day plan they had. itanic is HPPA 3 in
effect.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Paul Repacholi
> True... no more than if someone just purchased GS320s. They
> would be doing incremental upgrades to EV69 if CPU horsepower
> became inadequate or more than likely plugging more into their
> SAN fabric.
> But one of my main points can't be ignored.
> Cross-architecture VMS clusters are common , adding another
> architecture isn't that difficult, nor costly, and I suspect
> Itanium servers will be quite a bit cheaper than AlphaServers.
Oh? Except for the 'details', as usual... One long time poster has
frequently mentioned the problem that if they add another Arch, then
there is the cost of a full FAA re-certification. So they are still
on Vaxes. And notice that the vaunted FAB software was is only just
being ported from Vax to itanic. Now when that finishes, the only
ways to cluster them will be 10Mb ethernet or perhaps FDDI. Tough
luck if you have CI in place.
Alan Greig
wrote:
>Alan Greig wrote:
>> Yep, that's the way SAP wants you to work as well. OPS isn't supported
>> and neither is RAC yet. In a typical SAP configuration if you need
>> redundancy then you either have a duplicated hot standby database
>> server or you set up the hot standby on a separate application server
>> and take the performance hit on apps should the main database server
>> go down.
>
>I don't know anything about SAP but what you've said Alan confirms what
>I thought I knew, that SAP is just not geared to any fault tolorance,
>downtime for backups, redundancy, ...
To the best of my understanding there is no reason SAP can't use OPS
or the enhanced RAC but they do not support or recommend it. The
reasoning given by sales is that "you get no advantage from OPS. It
just slows you down". Supposedly RAC support will be included in
future. So a Compaq sales guy attempting to sell SAP on Tru64 cannot
say that their OS has better cluster support for SAP so you might as
well go for an NT solution. NT isn't too bad (note I said not *too*
bad) in this role because all it has to do is boot then get out of the
way and let Oracle do all the work.
Typically anything larger than the smallest SAP installation will have
multiple servers. A database server, an application server, a web
server etc. You install the hot standby on one of the non database
server nodes and it is possible to configure things so that this
hot-standy will be switched live automatically so you do have some
fault tolerance. However you will then take a hit on the performance
of that server. If you have money to burn just duplicate it and leave
it idle until needed. Downtime for backups isn't required as Oracle
does support online backups although not as neatly as RDB.
But I have to agree that the tolerance and active distributed
clustering capabilities of SAP/Oracle/SQL Server are nowhere near as
good as the capabilities provided by VMS/MANMAN/RDB/DBMS combo despite
there supposedly being 15-20 years of development since MANMAN first
supported this. I've put the question directly to senior SAP
consultants and Compaq SAP sales and they at least honestly answered
that SAP/Oracle can't compete with MANMAN in this area. Turned out the
senior SAP UK consultant was a former VMS MANMAN system manager!
>Why the HELL should anyone want to run it? Vain hope systems remain up?
It looks good on senior management CVs...
Less cynically some vertical industries demand their suppliers run it
so it interfaces easily with their own system.
Even less cynically. SAP isn't actually a bad product but it is huge
and demanding to set up correctly. So much so that you will almost
certainly get it majorly wrong without really top-class outside help.
For a start you need to understand it inside out to know where and how
to simplify screens, procedures etc. Fail to do this and your lowly
stores/goods-inwards staff will find themselves hyperlinking off into
(err) hyperspace and get completely lost. Fail to setup organization
charts correctly and an avalanche of red traffic lights will bury your
company. Fail to set up the "Executive Cockpit Business Warehouse"
correctly and Garbage In Garbage Out Applies. One minute the CEO
thinks the company is 100 million in the black the next 50 million in
the red.,
Oh and don't forget to spend a minimum of $5,000 dollars training per
employee and much more for power users!
>
>Surely VMS does not need software written with that methodology in mind,
>why should VMS help those who can't help themselves?
I can't think of any architectural issues that would prevent current
SAP/R3 and mySAP (web enabled SAP) from taking immediate advantage of
a clustered RDB server.
>
>If SAP is being bought because its flavour of the month then the buggy
>thinking extends to those who purchase, I notice their [SAP] profits are
>down this time.
A big part is because it is flavour of the month but it is also an
extremely comprehensive system with modules for just about anything.
SAP will even suggest employees for promotion
Some of the modules aren't up to scratch yet but they do seem to have
a vision of where they want to go.
>
>Feel free to educate me about the wonders of SAP, but I think you've got
>an uphill task.
I'm not a big SAP fan and my understanding is limited to the official
SAP 101 5 day overview course plus a little hands on but I can see its
attractions as well as its failings.
Btw, at the UK SAP main centre the training system appeared to have
access to live BACS (for non UK this is the banks electronic payment
system) and I did toy with the idea of paying my 'excercise' employee
by BACS instead of cheque :-)
--
Alan
Rob Young
> you...@encompasserve.org (Rob Young) writes:
>
>> True... no more than if someone just purchased GS320s. They
>> would be doing incremental upgrades to EV69 if CPU horsepower
>> became inadequate or more than likely plugging more into their
>> SAN fabric.
>
>> But one of my main points can't be ignored.
>> Cross-architecture VMS clusters are common , adding another
>> architecture isn't that difficult, nor costly, and I suspect
>> Itanium servers will be quite a bit cheaper than AlphaServers.
>
> Oh? Except for the 'details', as usual... One long time poster has
> frequently mentioned the problem that if they add another Arch, then
> there is the cost of a full FAA re-certification. So they are still
> on Vaxes. And notice that the vaunted FAB software was is only just
> being ported from Vax to itanic. Now when that finishes, the only
> ways to cluster them will be 10Mb ethernet or perhaps FDDI. Tough
> luck if you have CI in place.
>
Alpha to Itanium you mean. Their fabs have been running Alphas
for a while now from what I understand.
Rob
Rob Young
>
> Rob Young <you...@encompasserve.org> wrote in message
> news:oYpTLx...@eisner.encompasserve.org...
>
> ...
>
>> But one of my main points can't be ignored. Cross-architecture
>> VMS clusters are common , adding another architecture isn't that
>> difficult, nor costly,
>
> It may not be all that costly for *Compaq* to add the IPF architecture to
> VMS's repertoire, but that cost will pale in comparison with the aggregate
> cost across all ISVs and customers of porting their applications and
> installations to it (unless most don't bother to). If indeed there are
> anything like 400,000 VMS installations, an average porting cost of just a
> few hundred dollars would likely exceed Compaq's costs - and the *real*
> average porting cost is much more likely to be at least a couple of orders
> of magnitude higher.
>
So you wait until your Alphas run out of steam (if ever). All the
migrations I have been involved in were for that reason and that
reason alone. VAX performance had become unbearable. Again, I'm
not talking homegrown in *most* cases but ISVs (Oracle and the like)..
where it is a simple matter of moving the databases. The cost for
ISVs will be mostly trivial as it will involve a recompile and test
phase, more than made up on the back end. ISVs all the time decide
to add/drop architectures. Think of VMS on Itanium as "just another
architecture." Of course, the alternatives are to move to another
platform. My experience there is that the cost involved can be
astronomical and a nice chunk of customers - for all intents and
purposes - are locked into VMS as it is very painful financially
to cut over to a "foreign" OS (you gain nothing but do introduce
several painful issues. I know of one migration VMS to another
OS - same ISV - that was halted after months of struggle. Poorly
run? Nope... just difficulties that were there and recognized.
But when counting the cost... you get a whole lot of rosy scenarios
very often... don't we?)
> and I suspect Itanium servers will be quite
>> a bit cheaper than AlphaServers.
>
> I'm getting tired of hearing this garbage: please analyze exactly what
> server components will cost less (and how much) and compare it with total
> server cost before repeating it again.
>
I guess you didn't even bother looking. I'm not surprised.
Itanium servers are quite a bit cheaper than AlphaServers today,
never mind the future.
Have you priced out 16 GBytes of memory for an AlphaServer lately?
The memory is considerably more expensive for an AlphaServer. I was
looking at 16 GBytes of AlphaServer memory... around $48000* U.S. That
same 16 GBytes of memory for a 4-way Itanium server is $25000 U.S.:
http://configure.us.dell.com/dellstore/config.asp?customer_id=04&order_code=pe7150&keycode=6w300
What about quad processor? If you load that Itanium box up with
CPUs (4MByte L2 - top of the line at 800 MHz) you add a total
of $20K to the cost. That puts a quad Itanium server with 16 GBytes
of RAM, 4 CPUs at $63K U.S. The same config for an ES40 would most
likely be in the neighborhood of $115K U.S. ($48K* for memory, 27K
base system, each processor add 13K. I may be $10K low on the base
system, but what's $10K ?).
Careful on the RAS stuff... see other threads. RAS isn't as big
a deal as it once was. I know of a project that has 20 servers
involved. Failovr servers everywhere. But downtime is not an option
and with lame OSes you need a lot of cheap** servers.
* 8 - 2 GByte modules at $6000K each. Cheaper than going 4 - 4 GByte modules,
see for example:
http://www.google.com/search?q=cache:b2a8v5mqzGc:www.geminidigital.com/specials.html+ms610-FA&hl=en
** cheap = $10-15 K, dual power supplies for your "RAS" feature set there.
> Enterprise servers aren't something one can build in a garage shop like PCs:
> they have strict characterization, validation, and RAS requirements that
> aren't compatible with high-volume, low-cost production at either the box or
> the individual component level, and those costs persist regardless of what
> processors happen to be in the center of it all (and eclipse the cost of
> those processors).
>
> The cost of the Alpha processors in a current mid-range or better
> AlphaServer is a *small* percentage of the whole. Replace them with
> McKinleys and the box price won't change significantly (unless you try to
> recoup the cost of developing the McKinley version, in which case the price
> will go *up*) - even if you *give the McKinleys away*.
>
The cost of making that above system a quad-processor is $19000 ,
quite a bit cheaper than the cost to uplift an ES40 to
quad status. I don't expect that to change much when McKinley shows
up, should actually go down as McKinley is in a smaller process and
L2 comes on CPU. That separate L2 is very costly stuff. You
are off the mark on McKinley pricing.
Itanium servers will continue to be substantially cheaper than
AlphaServers and CPU cost is - and will continue to be - a sizable
factor.
Rob
Bill Todd
...
> I'm puzzled by $300 million VMS annual development. Are there 300
> people working for VMS engineering on $1 million a year or something?
> Or 50 on $6 million or what. Ok staffing isn't everything but what on
> earth has VMS engineering been doing with $ 300 million a year. Or
> have we tagged all of the Alpha chip, systems etc design cost onto
> VMS?
My impression from when last this subject came up is that the number
includes all layered-product development (compilers, etc.), release
engineering, etc. The last number I heard for people actually working on
the OS was about 100 (including management and possibly people largely
performing support functions).
- bill
Bill Todd
> In article <Ha4G7.161142$b47.16...@bin3.nnrp.aus1.giganews.com>, "Bill
Todd" <bill...@metrocast.net> writes:
> >
> > Rob Young <you...@encompasserve.org> wrote in message
> > news:oYpTLx...@eisner.encompasserve.org...
> >
> > ...
> >
> >> But one of my main points can't be ignored. Cross-architecture
> >> VMS clusters are common , adding another architecture isn't that
> >> difficult, nor costly,
> >
> > It may not be all that costly for *Compaq* to add the IPF architecture
to
> > VMS's repertoire, but that cost will pale in comparison with the
aggregate
> > cost across all ISVs and customers of porting their applications and
> > installations to it (unless most don't bother to). If indeed there are
> > anything like 400,000 VMS installations, an average porting cost of just
a
> > few hundred dollars would likely exceed Compaq's costs - and the *real*
> > average porting cost is much more likely to be at least a couple of
orders
> > of magnitude higher.
> >
>
> So you wait until your Alphas run out of steam (if ever).
Sounds like a better argument for choosing a vendor who won't cut off the
development flow to the platform you want than any kind of rationale for the
acceptance of a switch to Itanic.
...
> > and I suspect Itanium servers will be quite
> >> a bit cheaper than AlphaServers.
> >
> > I'm getting tired of hearing this garbage: please analyze exactly what
> > server components will cost less (and how much) and compare it with
total
> > server cost before repeating it again.
> >
>
> I guess you didn't even bother looking. I'm not surprised.
No, you just didn't bother understanding the sense of the comment. And I'm
not surprised either.
>
> Itanium servers are quite a bit cheaper than AlphaServers today,
> never mind the future.
And you definitely get what you pay for. My comment above was related to
comparing apples to apples (i.e., Compaq Alpha servers to Compaq Itanic
servers of similar capabilities).
>
> Have you priced out 16 GBytes of memory for an AlphaServer lately?
> The memory is considerably more expensive for an AlphaServer. I was
> looking at 16 GBytes of AlphaServer memory... around $48000* U.S. That
> same 16 GBytes of memory for a 4-way Itanium server is $25000 U.S.:
This is called charging what the market will bear (Alphas unfortunately now
being a largely captive market not particularly subject to normal supply and
demand curves). Although since there is *no* current market for Itanics,
their memory pricing could be considered somewhat arbitrary.
...
> What about quad processor? If you load that Itanium box up with
> CPUs (4MByte L2 - top of the line at 800 MHz) you add a total
> of $20K to the cost. That puts a quad Itanium server with 16 GBytes
> of RAM, 4 CPUs at $63K U.S. The same config for an ES40 would most
> likely be in the neighborhood of $115K U.S. ($48K* for memory, 27K
> base system, each processor add 13K. I may be $10K low on the base
> system, but what's $10K ?).
Let's rephrase that in terms of capabilities. A quad-processor ES40/45 with
*well* over twice the memory bandwidth and processor performance of a
quad-processor Dell Itanic box costs less than twice as much, even after
being gouged on the memory price. And this is supposed to make the Itanic a
significantly better deal?
- bill
Rob Young
>
>>
>> Itanium servers are quite a bit cheaper than AlphaServers today,
>> never mind the future.
>
> And you definitely get what you pay for. My comment above was related to
> comparing apples to apples (i.e., Compaq Alpha servers to Compaq Itanic
> servers of similar capabilities).
>
Ah.... excellent tactic not unlike our British Champion.
But of course what you write above isn't the case at all
as just in the prior post in reply to what I wrote you state:
> and I suspect Itanium servers will be quite
>> a bit cheaper than AlphaServers.
>
> I'm getting tired of hearing this garbage: please analyze exactly what
> server components will cost less (and how much) and compare it with total
> server cost before repeating it again.
>
There you are quite concerned about component costs.... so I
trot out component costs. Hmmmmm.
Caught in a bind, so you ever so slightly change the argument. It
now becomes a matter of capabilities. So... how do you measure
that? ... bandwidth. Sheesh.
Later,
Rob
JF Mezei
where it is a simple matter of moving the databases. The cost for
> ISVs will be mostly trivial as it will involve a recompile and test
> phase, more than made up on the back end.
Certifying an application is not trivial. Although VMS is now out of the funds
transfer business, this was a good example of how much it costed to come out
with a new architecture that you were willing to garantee would work on your
customer's platform. Customers wouldn't run it unless it was certified and the
vendor would garantee the software wouldn't lose a multi-million dollar transaction.
> platform. My experience there is that the cost involved can be
> astronomical and a nice chunk of customers - for all intents and
> purposes - are locked into VMS as it is very painful financially
> to cut over to a "foreign" OS
The above is true on its own. However, consider that many companies did move
to another OS as the headed the call to abandon VMS in the 1990s. Migrations
have happened. Now, you are asking companies to start a whole platform
migration project that will cost customers some money.
While such a migration will cost much less than a migration to another OS, ON
ITS OWN, you have to consider:
-most customers already have some other platform for their new applications,
so migrating their remaining VMS apps to some flavour of Unix will alllow some
consolidation and save some costs.
-everyone is very aware that Compaq has no intentions of marketing VMS. A
DII-COE commitment may provide support assurances for your existing
configuration, but it doesn't garantee that VMS will gain the applications you
need to stay ahead of the pack. VMS may have a future, but its isn't "bright".
-so, when you force the alpha-ia64 migration upon customers, you give them an
opportunity to compare the costs of other options as well. It is no longer the
issue of comparing status quo with porting to Unix, but rather the cost of
migrating to IA64 vs porting to Unix.
-when customers put a price tag on the lack of bright future for VMS, and the
cost savings of dumping VMS to consolidate on their existing unix
infrastructure, it may well turn out that the price difference of a port to
unix vs migration t IA64 is worth it.
Bill Todd
> In article <22gG7.92517$tb2.7...@bin2.nnrp.aus1.giganews.com>, "Bill
Todd" <bill...@metrocast.net> writes:
> >
>
> >>
> >> Itanium servers are quite a bit cheaper than AlphaServers today,
> >> never mind the future.
> >
> > And you definitely get what you pay for. My comment above was related
to
> > comparing apples to apples (i.e., Compaq Alpha servers to Compaq Itanic
> > servers of similar capabilities).
> >
>
> Ah.... excellent tactic not unlike our British Champion.
Stop being such an asshole, Rob. Or if you persist, at least try to find
something substantive to criticize.
>
> But of course what you write above isn't the case at all
> as just in the prior post in reply to what I wrote you state:
>
> > and I suspect Itanium servers will be quite
> >> a bit cheaper than AlphaServers.
> >
> > I'm getting tired of hearing this garbage: please analyze exactly what
> > server components will cost less (and how much) and compare it with
total
> > server cost before repeating it again.
> >
>
> There you are quite concerned about component costs.... so I
> trot out component costs. Hmmmmm.
>
> Caught in a bind, so you ever so slightly change the argument.
No, you idiot: I'm saying that the comparison at issue (*certainly* the one
at issue as far as using VMS is concerned) is *Compaq* Itanic servers to
AlphaServers of similar capability.
It
> now becomes a matter of capabilities. So... how do you measure
> that? ... bandwidth. Sheesh.
If you want to throw capability aside (though I suspect most customers
aren't that stupid), there's still the small problem that last time I
checked you couldn't buy *any* Itanic platform for anything near the price
of a DS10.
And you certainly haven't been inclined to set aside capabilities in the
past when comparing Alpha systems to, say, SPARC systems with more
processors but less in the way of performance, so why are you so anxious to
this time?
- bill
Rob Young
You are missing a very large picture of this puzzle. ISVs that
support VMS and have the same product running on other OSes vary
in levels of VMS integration. The case I am describing is whereby
the ISV's product has been running native on VMS for years, there
are internal system calls specific to VMS, there are multiple
custom scripts (DCL) making it *very* difficult (read: expensive)
to decouple from VMS. Systems where planned downtime is something you
fight for and it is rarely doled out in increments larger than
4 hours. The expense to go from VMS to another OS is high and the
downsides are easy to forsee... you will introduce instability -
count on it. This same migration VAX to Alpha is transparent...
all the OS calls are there, the scripts run unmodified. Same will
be said for transitioning to VMS-Itanium. Sun lost few customers
SunOS to Solaris and in some ways it was a lot uglier.
> -so, when you force the alpha-ia64 migration upon customers, you give them an
This won't happen, no more than it happened for VAX customers. They
are still riding those VAXes into the ground and for those applications
their migration path is Alpha. It is too costly to cutover those
mission critical apps to foreign OSes.. unless of course you
wish to:
1) Spend a lot more money in the process
2) Introduce instability (at first) into a mission
critical environment
It is much more logical to stay with VMS no matter how you slice it.
I know this is not too hard to believe but I know of someone
with a lot of money and wishes/wants to go to a foreign OS (strategic
direction) but they aren't that stupid. Yes, stupid ... it will cost
them a lot of money and they will introduce a good deal of
short-term instability in a high profile application. Few are that
stupid.
Rob
Rob Young
>
> If you want to throw capability aside (though I suspect most customers
> aren't that stupid), there's still the small problem that last time I
> checked you couldn't buy *any* Itanic platform for anything near the price
> of a DS10.
>
Ummmm.. how about if you want 16 GBytes of memory, have you
made that comparison?
> And you certainly haven't been inclined to set aside capabilities in the
> past when comparing Alpha systems to, say, SPARC systems with more
> processors but less in the way of performance, so why are you so anxious to
> this time?
>
At your request. Why else?
Rob
Bill Todd
...
The problem is, transitioning to another platform also has major upsides
that simply migrating to VMS on Itanic does not. At least it does unless
the ISV is planning on using his/her product as a cash cow in the same
manner that Compaq uses VMS, in which case the ability to bleed captive
customers on a product that may not have any wider audience anyway could
make sense.
For any other ISV (that doesn't already offer its product on other platforms
and thus have even less reason to bother migrating the VMS version), porting
to a vastly more popular platform may well make a great deal more sense than
expending the effort to accommodate the portion of the shrinking VMS
population that may wish to move to Itanic.
- bill
Bill Todd
> In article <ZkhG7.90118$U7.73...@bin1.nnrp.aus1.giganews.com>, "Bill
Todd" <bill...@metrocast.net> writes:
> >
> > If you want to throw capability aside (though I suspect most customers
> > aren't that stupid), there's still the small problem that last time I
> > checked you couldn't buy *any* Itanic platform for anything near the
price
> > of a DS10.
> >
>
> Ummmm.. how about if you want 16 GBytes of memory, have you
> made that comparison?
Unless there's something really special about Alpha memory, that expense is
simple price-gouging and has nothing to do with the *ability* to compete on
price.
>
>
> > And you certainly haven't been inclined to set aside capabilities in the
> > past when comparing Alpha systems to, say, SPARC systems with more
> > processors but less in the way of performance, so why are you so anxious
to
> > this time?
> >
>
> At your request. Why else?
Since my previous contributions to this thread have included thorough
descriptions of Itanic's inability to compete on per-processor performance
with Alpha for *at least* the next 3 years (and its ability to compete after
that point is by no means clear, since it will depend on exactly what the
yet-unspecified new Alpha-team-inspired changes may be), and included
specific observations on Itanic's disadvantages in terms of EV7's on-chip
glue features and the resulting difficulty of competing in both absolute
performance and cost/performance, it really should have been clear that my
discussion of component prices referred to components of similar capability.
After all, if all you want is a 4-processor box without reference to its
capability or quality, you can get IA32-based SMPs (and commodity memory)
for a great deal less than anything we've talked about here - but so what?
- bill
JF Mezei
> You are missing a very large picture of this puzzle. ISVs that
> support VMS and have the same product running on other OSes vary
> in levels of VMS integration.
We're not talking about shrinkwrapped software for what is left of the VMS
marketplace. And even if an ISV does go through the trouble of migrating to
IA64 and doing the testing to certify it, the customers will still need a
fairly elaborate migration plan that will last some time with their own
testing, parralel runs and eventual switching from one to the other.
Remember that IA64 brings nothing of value compared to Alpha as far as the
customers are concerned. Customers are being forced into these unnecessary
expenses just to please Mike Winkler, Andy Grove and Carly.
> the ISV's product has been running native on VMS for years, there
> are internal system calls specific to VMS, there are multiple
> custom scripts (DCL) making it *very* difficult (read: expensive)
> to decouple from VMS.
But since there now exists 3rd party packages on other systems that are the
"industry standard", then all your proprietary stuff is somewhat moot. If the
package on unix offers the same/more functionality than your in-house system,
then you need not concern yourself about porting your in-house scripts in DCL
or other VMS specific utilities.
> fight for and it is rarely doled out in increments larger than
> 4 hours.
But that applies equally to a Alpha-IA64 migration as it would a VMS-UNIX
migration. You need to setup and test the new system in parralel and at one
point, cut over to the new system.
It is true that with VMS clustering, the cutover can be almost transparent
with proper use of clustering.
> The expense to go from VMS to another OS is high and the
> downsides are easy to forsee... you will introduce instability -
> count on it.
But management will be happy to finally dump an unpopular platform and move to
a popular and mainstream solution.
> all the OS calls are there, the scripts run unmodified. Same will
> be said for transitioning to VMS-Itanium.
Only for user mode applications, remember. But consider just changes to the
console. This requires that you develop new procedures and documentation for
the operators. Being able to compile an application transparently is neat, but
it is only a small portion of the whole picture.
You have to consider the security and stability implications of having that
new IA64 box join your existing production cluster , especially if you'll be
playing around with it to test it out, test the applicatiosn etc etc.
In some organisations, it isnb't enough to just plug it in and boot it, you
have to prove to a commitee that this project and the way you intend to
implement it will not affect production.
This is why sometimes keeping your test machine totally separate is easier.
> This won't happen, no more than it happened for VAX customers. They
> are still riding those VAXes into the ground and for those applications
> their migration path is Alpha. It is too costly to cutover those
> mission critical apps to foreign OSes.. unless of course you
Lets see. During the 1990s, how much market share and customers did VMS lose ?
Just look at the exit from messaging where Digital used to be THE leader. The
lack of migration path for Message Router to Alpha was one of the big reasons
for the start of the decline. Some stayed and went with PMDF, and many others
just dumped that architecture and went with a different vendor alltogether.
So while on paper the VAX to ALPHA should have been easy, there were some
details which made it troublesome for many. Those details were not technical,
they were business practices, Digital decisions etc etc.
So while the engineers may do a nice job and allow easy recompiles, it is
still not a given that the transition will be easy for many customers. It all
depends on whether *ALL* products are migrated, even the ones that are
officially "dead".
Consider a shop that depends extensively on display postscript. They are now
frozen at 7.2. Will you post display postscript and VMS 7.2 to IA64 to allow
them to migrate ?
What other middleware products will not make it over to IA64 ?
> It is much more logical to stay with VMS no matter how you slice it.
If there were no second guessing of Compaq's commitment to VMS, I would agree.
But the fact that VMS' future is not exactly certain will force customers to
consider whether it would be wise to take that opportunity to migrate off VMS
once and for all.
> direction) but they aren't that stupid. Yes, stupid ... it will cost
> them a lot of money and they will introduce a good deal of
> short-term instability in a high profile application.
But once a corporation decides to de-emphasize VMS on the long term and builds
new stuff on another platform, then that issue becomes less stupid. But it
also means that that company won't bother with that silly Alpha-IA64
migration, they'll keep their old Alphas because as they move applications to
newer platforms, it gives the Alpha room to grow processing on the remaining applications.
Rob Young
> Rob Young wrote:
>> You are missing a very large picture of this puzzle. ISVs that
>> support VMS and have the same product running on other OSes vary
>> in levels of VMS integration.
>
> We're not talking about shrinkwrapped software for what is left of the VMS
> marketplace.
Ahem... as Fred points out this piddling VMS marketplace that you
refer to is actually quite a bit larger than the NSK market. You
can't come to grips with the size of it , can you? And if it shrunk,
it is still a very sizable corporation if standalone. Don't talk
about "what is left of it", it doesn't elevate your position.
And even if an ISV does go through the trouble of migrating to
> IA64 and doing the testing to certify it, the customers will still need a
> fairly elaborate migration plan that will last some time with their own
> testing, parralel runs and eventual switching from one to the other.
>
Nonsense. Having been involved in quite a few VAX to Alpha
migrations, "elaborate" has never been a keyword.
> Remember that IA64 brings nothing of value compared to Alpha as far as the
> customers are concerned. Customers are being forced into these unnecessary
> expenses just to please Mike Winkler, Andy Grove and Carly.
>
No more than Alpha brings to VAX. If your current VAX configuration
is delivering the goods, why come off it? One of my vehicles has
172000 miles on it, I drove it to New Hampshire last year. I tire
of it, but it has been rock solid for the 11 years I have owned it.
No intention of getting rid of it... same could be said for many
VAX installations today. However, parts may be an issue for the
VAX and me in a few years and I probably would be best to ditch
my vehicle. Easy migration path for me. Maybe not so easy
for all VAX owners, but fairly easy for many.
>> the ISV's product has been running native on VMS for years, there
>> are internal system calls specific to VMS, there are multiple
>> custom scripts (DCL) making it *very* difficult (read: expensive)
>> to decouple from VMS.
>
> But since there now exists 3rd party packages on other systems that are the
> "industry standard", then all your proprietary stuff is somewhat moot. If the
> package on unix offers the same/more functionality than your in-house system,
> then you need not concern yourself about porting your in-house scripts in DCL
> or other VMS specific utilities.
>
Sure. You have to rewrite those non-standard scripts in something
other than DCL. Those native VMS calls can be a very nasty thing
to come away from and require porting and or rotorooting of your
code to get them to Unix. As mentioned before, none of that comes
into play VAX->Alpha.
>> fight for and it is rarely doled out in increments larger than
>> 4 hours.
>
> But that applies equally to a Alpha-IA64 migration as it would a VMS-UNIX
> migration. You need to setup and test the new system in parralel and at one
> point, cut over to the new system.
>
Yes, but as mentioned earlier the exposure is mostly non-existent.
Remember VMS is VMS is VMS. Secondly, to cut those databases over
to Alpha from VAX is very rapid. You will need a *ton* more time
to get them to Unix from VAX. Not a big secret here... plug an Alpha
into the existing VAX cluster and suck them across. Most likely will
require 4-5 times the amount of time to get data to Unix from VAX.
(i.e. vast majority of VAXes are 10Mbit networked).
> It is true that with VMS clustering, the cutover can be almost transparent
> with proper use of clustering.
>
Or in my case VAX to Alpha cluster change out overnight. Piece of
cake.
>> The expense to go from VMS to another OS is high and the
>> downsides are easy to forsee... you will introduce instability -
>> count on it.
>
> But management will be happy to finally dump an unpopular platform and move to
> a popular and mainstream solution.
>
>
>> all the OS calls are there, the scripts run unmodified. Same will
>> be said for transitioning to VMS-Itanium.
>
> Only for user mode applications, remember. But consider just changes to the
> console. This requires that you develop new procedures and documentation for
> the operators. Being able to compile an application transparently is neat, but
> it is only a small portion of the whole picture.
>
No changes. VMS is VMS.
> You have to consider the security and stability implications of having that
> new IA64 box join your existing production cluster , especially if you'll be
> playing around with it to test it out, test the applicatiosn etc etc.
>
> In some organisations, it isnb't enough to just plug it in and boot it, you
> have to prove to a commitee that this project and the way you intend to
> implement it will not affect production.
>
Yes. I didn't say it was free. Thorough testing is a must.
You say that. But I am talking about production databases
-mostly wed to VMS-. Rare? Maybe not so rare as you would guess.
The only migration upside is you have your OS strategy lined up. The
downside is big bucks spent in the cutover and definite instability.
The kind of thing that costs people jobs and the risk most of them
wisely forego.
Rob
Alan Greig
wrote:
>This is called charging what the market will bear (Alphas unfortunately now
>being a largely captive market not particularly subject to normal supply and
>demand curves). Although since there is *no* current market for Itanics,
>their memory pricing could be considered somewhat arbitrary.
Memory chips for the Alpha and Itanium server are probably the same
DIMS anyway! Official Compaq Alpha memory is overpriced to an almost
criminal degree. High quality new third party Alpha memory can be had
for a *tenth* of current Compaq prices if you shop around.
>
--
Alan
Alan Greig
wrote:
>In article <ZkhG7.90118$U7.73...@bin1.nnrp.aus1.giganews.com>, "Bill Todd" <bill...@metrocast.net> writes:
>>
>> If you want to throw capability aside (though I suspect most customers
>> aren't that stupid), there's still the small problem that last time I
>> checked you couldn't buy *any* Itanic platform for anything near the price
>> of a DS10.
>>
>
> Ummmm.. how about if you want 16 GBytes of memory, have you
> made that comparison?
Rob,
Could you explain the physical difference between Alphaserver memory
and Itanium memory and what justifies Compaq's factor of 5-10 price
hike?
--
Alan
Alan Greig
wrote:
>
>Alan Greig <a.g...@virgin.net> wrote in message
>news:kp4iutcjqg80djrof...@4ax.com...
>
>...
>
>> I'm puzzled by $300 million VMS annual development. Are there 300
>> people working for VMS engineering on $1 million a year or something?
>> Or 50 on $6 million or what. Ok staffing isn't everything but what on
>> earth has VMS engineering been doing with $ 300 million a year. Or
>> have we tagged all of the Alpha chip, systems etc design cost onto
>> VMS?
>
>My impression from when last this subject came up is that the number
>includes all layered-product development (compilers, etc.), release
Yes, but even then I think it's inflated. But why on earth should the
compilers and layered products be included in VMS charges when many of
the products are common to Tru64 or even Windows. Did the entire
Visual Fortran for Windows development cost get attached to VMS?
Wouldn't surprise me at this point. In which case VMS revenue was used
to create a product for Windows which was then handed over to Intel.
>engineering, etc. The last number I heard for people actually working on
>the OS was about 100 (including management and possibly people largely
>performing support functions).
>
>- bill
>
>
--
Alan
Nic Clews
> > Ummmm.. how about if you want 16 GBytes of memory, have you
> > made that comparison?
>
> Could you explain the physical difference between Alphaserver memory
> and Itanium memory and what justifies Compaq's factor of 5-10 price
> hike?
There isn't one. While the memory will^H^H^H^H should have been
specifically qualified, memory is memory to any specification.
I would hope that when the Itanium VMS systems hit the streets, we'll be
on "peecee" level hardware costings.
But if Compaq think folks will put up with paying $1500 for a system,
then $2500 for a (say, cluster) licence, they'd better rethink their
scale of charges.
Last night I watched the Money programme (UK BBC2) about the
airline/tourism industry, and on the up and up is Ryan Air, the VMS
division at Cpq should take a leaf from their book, even in the current
climate, this company is making profits where others, even the big
players, are going out of business.
Profit by large volume, not large margin.
(My opinion of course)
Rob Young
> On 7 Nov 2001 15:34:56 -0600, you...@encompasserve.org (Rob Young)
> wrote:
>
>>>
>>> If you want to throw capability aside (though I suspect most customers
>>> aren't that stupid), there's still the small problem that last time I
>>> checked you couldn't buy *any* Itanic platform for anything near the price
>>> of a DS10.
>>>
>>
>> Ummmm.. how about if you want 16 GBytes of memory, have you
>> made that comparison?
>
>
> Could you explain the physical difference between Alphaserver memory
> and Itanium memory and what justifies Compaq's factor of 5-10 price
> hike?
>
No.. and having been down that path numerous times.... it is one
of the few profit centers for large system sales for most vendors.
You can do similar comparison on other large Unix boxes... their
prices may not be as out of line but are certainly higher than
"Wintel" kit.
A few years ago I put together a sizable Alpha configuration $$$ and
wanted very badly to go 3rd party on memory as it would have saved
a ton of money. Things worked out. I still would have liked to
go 3rd party as the $ savings were still substantial but I also
realize that Digital took a beating on the sale. My goal is to save
the client (employer/whatever) money. I also realize Compaq and
others are in the business of making money on hardware sales. There
is a tension there. I don't want to be rude with sales folks but
I also want to be a good steward and spend money wisely.
Which if you think about it . . . VMS on Itanium knocks one leg
out of the argument to knife VMS. I forsee a day when there is
a bid ... a very large bid... perhaps governent... perhaps not...
but it is a VMS + Itanium kit versus Solaris and Sparc kit... when
the smoke clears the all powerful BeanCounters have the final say
and the VMS bid wins as it is $3-4 million cheaper. This Itanium
thing won't be a bad thing.... trust me. Yes, it may be an Alpha
thing at first until Intel gets those switches on chip and the good
Doctor Emer delivers the SMT special sauce.
Rob
Simon Clubley
<T2FM9+...@eisner.encompasserve.org>, Rob Young wrote:
>
> Ah.... excellent tactic not unlike our British Champion.
>
Rob, I would like to point out that at the last count, there were about
60 million of us, and that we are not all clones of Andrew Harrison.
Have you considered using "Sun Champion" instead of "British Champion" ?
Simon.
PS: Andrew seems to have been silent for a long time...
--
Simon Clubley, simon_clubley@remove_me.altavista.co.uk-Earth.UFP
In the task of removing Microsoft from the marketplace, I have discovered a
truly remarkable plan, but this signature is too small to contain it.
Larry Kilgallen
> On 7 Nov 2001 14:13:42 -0600, in article
> <T2FM9+...@eisner.encompasserve.org>, Rob Young wrote:
>>
>>
>
> 60 million of us, and that we are not all clones of Andrew Harrison.
>
> Have you considered using "Sun Champion" instead of "British Champion" ?
I think there are many who work at Sun who are not clones of Andrew Harrison.
JF Mezei
> PS: Andrew seems to have been silent for a long time...
Compaq is no longer a threat to Sun sales. With Compaq shooting itself in the
foot in a very visible way, Sun no longer needs to bother ponting to Compaq's
silly decisions.
dit...@dittman.net
: Peter Kastner wrote:
:> From Aberdeen Group's perspective, here are the facts:
: Thank you for chiming in.
:> 3. We gave HP and Compaq permission to post our research at internal
:> intranet web sites at no charge.
: What I find interesting is that Compaq would proudly post a document not meant
: to be public which paints a poor picture of the future of Compaq's most
: profitable product. If some consulting firm says that customers shouldn't
: trust Compaq because it is about to kill a product, Compaq shouldn't be
: trumpeting around that report.
What I find interesting is a company that is supposed to know what is going on
recommends that Compaq/HP kill their most profitable product.
:> As to the root question, I recommend that concerned VMS users look up their
:> counterparts who own HP 3000's.
: Are HP 3000 users based on a dead chip and with a migration to IA64 too ?
Late last year I had to work with some HP3000/MPE systems. HP was still
actively updating the OS. The newer HP3000 systems (from what I was told
by an HP employee) use a PA-RISC CPU.
--
Eric Dittman
dit...@dittman.net
Check out the DEC Enthusiasts Club at http://www.dittman.net/
dit...@dittman.net
: As to the root question, I recommend that concerned VMS users look up their
: counterparts who own HP 3000's. From our vantage point, HP is not giving
: any more support to its own venerable HP 3000 base than it is to the Compaq
: VMS base...
Why would HP be giving any support to Compaq OpenVMS? Right now the merger
is still in progress and until the merger is complete Compaq is the company
that supports OpenVMS.
Alan Greig
>
>What I find interesting is a company that is supposed to know what is going on
>recommends that Compaq/HP kill their most profitable product.
And they not only agree on that point they then go on to say that it
is normal in the computer industry to sacrifice your profitable bread
and butter products in favour of low margin Windows systems. The
analyst's view appears to be that current industry policy is insane
and as HP/Compaq are among the pack leaders they should be the leaders
in insanely destroying their own products and customer loyalty to them
by using the loyal customer revenue to explicitly piss them off and
drive them towards inferior products.
>
>:> As to the root question, I recommend that concerned VMS users look up their
>:> counterparts who own HP 3000's.
>
>: Are HP 3000 users based on a dead chip and with a migration to IA64 too ?
>
>Late last year I had to work with some HP3000/MPE systems. HP was still
>actively updating the OS. The newer HP3000 systems (from what I was told
>by an HP employee) use a PA-RISC CPU.
HP continues to keep MPE just about up to date enough for current
needs but it has had less work done on it than VMS. HP's plans are to
support MPE on the IA64 but via the IA64's hardware assisted software
emulation of the PA-RISC architecture.
--
Alan
Nic Clews
Don't worry it won't last for long, Sun has found a cul-de-sac which
they'll hit the top of when the Itanium VMS systems start to deliver
performance, and IBM start to peddle their Power5's.
Larry Kilgallen
> Don't worry it won't last for long, Sun has found a cul-de-sac which
> they'll hit the top of when the Itanium VMS systems start to deliver
> performance, and IBM start to peddle their Power5's.
Lagging performance has never seemed to be a barrier to Sun market share.
Fred Kleinsorge
a while.
Not to look a gift horse in the mouth...
Simon Clubley wrote in message ...
Rob Young
But it really is catching up to them. Since Oracle charges per
cpu prices, servers such as IBM's new Regatta are cleaning up
as Regatta not only handily outperforms most (all?) but does
it with less than half the CPUs. IBM sales job is quite easy
up against large Sun boxes. Power4 is a monster. Hope they
are quite busy at the Marvel Mansion.
Rob
Bob Ceculski
if you call blue screens and spending 80% of my time patching security bugs
a major upside, your above comment makes no sense ...
Bob Ceculski
correct, as long as intel massages alpha design for vms into the itanic!
Bob Ceculski
but a port would be better, as emulation kills 40-50% of your cpu!
Bill Gunshannon
Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> writes:
|>
|> 60 million of us, and that we are not all clones of Andrew Harrison.
I'll assume you mean total Brits here and not British members of c.o.v :-)
but anyway....
Are any of our British members familiar with "Telecom Gold Mail"??
Is it still an existing service and if so, is there any interconnect
with INTERNET Email?? I am trying to locate an old friend I haven't
seen in more than a decade and that is the email address on his last
business card.
I know chances are slim, but it's worth a try anyway.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Paul Sture
[snip]
>
> PS: Andrew seems to have been silent for a long time...
>
Not seen since the beginning of October :-)
___
Paul Sture
Switzerland
Paul Sture
> In article <tEBG7.17968$xS6....@www.newsranger.com>,
> Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> writes:
> |>
> |> Rob, I would like to point out that at the last count, there were about
> |> 60 million of us, and that we are not all clones of Andrew Harrison.
>
> I'll assume you mean total Brits here and not British members of c.o.v :-)
> but anyway....
>
> Are any of our British members familiar with "Telecom Gold Mail"??
> Is it still an existing service and if so, is there any interconnect
> with INTERNET Email?? I am trying to locate an old friend I haven't
> seen in more than a decade and that is the email address on his last
> business card.
>
> I know chances are slim, but it's worth a try anyway.
>
___
Paul Sture
Switzerland
Bill Todd
Bob Ceculski <b...@instantwhip.com> wrote in message
news:d7791aa1.01110...@posting.google.com...
Get a grip, Bob. Windows isn't the only vastly more popular alternative out
there, and some of them aren't half bad.
- bill
Bill Todd
Dear me, I seem to have responded too quickly and missed the main point:
ISVs are in business to make money, which they usually can do best on the
most popular platforms even if those platforms are utter crap.
Your posts in general do not reflect much understanding of either the
overall situation or the specific material you respond to. If you were to
think more before you type, they'd be more worth reading.
- bill
Bob Ceculski
so your point is there are only some half good alternatives to vms?
what else is there? unix and linux (gag)? I was on os400 for a month
and that's about all I could take on it? any other ideas?
David Froble
Yep, the products do not have to work well for the ISV to collect the
purchase price. Being able to blame problems on the OS can also be a
benefit, to the ISV, not the user.
> Your posts in general do not reflect much understanding of either the
> overall situation or the specific material you respond to. If you were to
> think more before you type, they'd be more worth reading.
>
> - bill
Just use the shift key occasionally, that may let your brain catch up to
your fingers.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. Fax: 724-529-0596
DFE Ultralights, Inc. E-Mail: da...@tsoft-inc.com
T-Soft, Inc. 170 Grimplin Road Vanderbilt, PA 15486
David Froble
> Hmmm. Now that you mention it. Andrew hasn't been heard from here in quite
> a while.
>
> Not to look a gift horse in the mouth...
Actually, I miss him. At least with Andrew I didn't have to feel bad if
I typed before thinking and flamed him. If I thought that he didn't
deserve it for that instance, I was sure that there was something that
deserved it, so no qualms. When you felt like kicking
someone/something, Andrew was available. :-)
Unfortunately for us VMS bigots, sometimes he had some rather accurate
things to say that we didn't want to hear.
Guess the downturn in the economy must have caused Sun to do away with
their FUDsters. :-)
Dave
Robert Deininger
b...@instantwhip.com (Bob Ceculski) wrote:
> if you call blue screens and spending 80% of my time patching security bugs
^
|
Aha! Bob DOES have a shift key! I almost missed the vital clue, hidden
right in front of my eyes!
> a major upside, your above comment makes no sense ...
;-)
--
Robert Deininger
rdein...@mindspring.com
Art Rice
> Fred Kleinsorge wrote:
>
>> Hmmm. Now that you mention it. Andrew hasn't been heard from here in
>> quite a while.
>>
>> Not to look a gift horse in the mouth...
>
> Actually, I miss him. At least with Andrew I didn't have to feel bad if
> I typed before thinking and flamed him. If I thought that he didn't
> deserve it for that instance, I was sure that there was something that
> deserved it, so no qualms. When you felt like kicking
> someone/something, Andrew was available. :-)
>
> Unfortunately for us VMS bigots, sometimes he had some rather accurate
> things to say that we didn't want to hear.
>
> Guess the downturn in the economy must have caused Sun to do away with
> their FUDsters. :-)
>
> Dave
>
Well, you could pick on us guys from the Tandem camp. But since we share
so many of the same frustrations nowdays...
--
Art Rice
Tandem Admin
Special Data Processing Corp
----------------------------
All opinions are my own and do not reflect
the views of the above mentioned employer.
Dean Woodward
>
> In article <d7791aa1.01110...@posting.google.com>,
> b...@instantwhip.com (Bob Ceculski) wrote:
>
> > if you call blue screens and spending 80% of my time patching security bugs
> ^
> Aha! Bob DOES have a shift key! I almost missed the vital clue, hidden
> right in front of my eyes!
Of course he does; unless, of course, he's remapped a keyboard with '$'
and '_' available unshifted, he'd have a hard time doing much useful
work in VMS.
David Beatty
wrote:
>Fred Kleinsorge wrote:
>
>> Hmmm. Now that you mention it. Andrew hasn't been heard from here in quite
>> a while.
>>
>> Not to look a gift horse in the mouth...
>
>Actually, I miss him. At least with Andrew I didn't have to feel bad if
>I typed before thinking and flamed him. If I thought that he didn't
>deserve it for that instance, I was sure that there was something that
>deserved it, so no qualms. When you felt like kicking
>someone/something, Andrew was available. :-)
>
>Unfortunately for us VMS bigots, sometimes he had some rather accurate
>things to say that we didn't want to hear.
>
>Guess the downturn in the economy must have caused Sun to do away with
>their FUDsters. :-)
>
>Dave
That may be true, but Sun's stock is starting to climb again.
It was around 12 the last time I checked and I think it bottomed-out
at just under nine.
Then again, with the way thingd have been going with Compaq, they
can just as easily shoot themselves in the foot without any help from
the FUDsters at IBM, Sun, et. al.
David R. Beatty
Jan Vorbrueggen
> "No provision of this Final Judgment shall:
>
> 1.Require Microsoft to document, disclose or license to third parties:
> (a) portions of APIs or Documentation or portions or layers of
> Communications Protocols the disclosure of which would compromise the
> security of anti-piracy, anti-virus, software licensing, digital
> rights management, encryption or authentication systems, including
> without limitation, keys, authorization tokens or enforcement
> criteria;
> or (b) any API, interface or other information related to any
> Microsoft product if lawfully directed not to do so by a governmental
> agency of competent jurisdiction."
The two clauses are quite reasonable - all will depend on how they are
administered. (b) is a restatement of what other laws require anyway.
(a) is similar to saying that DEC would not need to publish the detailed
workings of LMF, or how the original DECnet-IV licenses operated - given
the DMCA or even the more reasonable rules in Europe, this is again not
much more than a restatement of legal requirements. (After all, any such
agreement cannot result in Microsoft abdicating all its rights in its
software, can it?)
I disagree that the DRM clause (which would be difficult to differentiate
technically from something implementing anti-piracy or software licensing
restrictions anyway) is going to be a problem. See Dan Walach's article
"Copy Protection is Doomed" in October's Computer for why this is so
(http://www.computer.org/computer/co2001/rxtoc.htm).
Jan
Jan Vorbrueggen
> so your point is there are only some half good alternatives to vms?
> what else is there? unix and linux (gag)? I was on os400 for a month
> and that's about all I could take on it? any other ideas?
Tandem, S/390.
Jan
Nic Clews
The S/390 is the Z series now for big blue.
OS400 does take some getting used to, and it's sooooo long winded for
doing the simplest things, I can understand strugling for a month, but
at least it is vaguely logical when compared to UnIx.
Steve....@yellgroup.com
Or, for more information try www.192.com which will search all electoral
registers for the name you input, and give you back address, phone number
etc.
Steve S
Paul Sture <paul....@bluewin.ch> on 11/09/2001 07:05:29 PM
To: Info...@Mvb.Saic.Com
cc:
From: Paul Sture <paul....@bluewin.ch>, 9 November 2001, 7:05 p.m.
Re: Need help, was: Rob's British Champion
___
Paul Sture
Switzerland
______________________________________________________________________
[Information] -- PostMaster:
This transmission is intended solely for the addressee(s) and may be
confidential. If you are not the named addressee, or if the message has
been addressed to you in error, you must not read, disclose, reproduce,
distribute or use this transmission.
Delivery of this message to any person other than the named addressee is
not intended in any way to waive confidentiality. If you have received
this transmission in error please contact the sender or delete the message.
Thank you.
Yell Limited, Queens Walk, Oxford Road, Reading, Berkshire, RG1 7PT.
Registered in England and Wales, registered number 4205228.
Yellow Pages Sales Limited, Queens Walk, Oxford Road, Reading, Berkshire,
RG1 7PT. Registered in England and Wales, registered number 1403041.
Bill Gunshannon
Steve....@yellgroup.com writes:
|>
|> Or, for more information try www.192.com which will search all electoral
|> registers for the name you input, and give you back address, phone number
|> etc.
|>
|>
|> If you have his location, try Directory Enquiries at www.bt.com.
|>
Both of these seem like good ideas, until I provide the last bit of
data. My friends name is "Smith". "David S, Smith" to be precise.
How many of them do you thnk there might be in England today?? :-)
Thanks for the help, though.
Paul Sture
> In article <OF791CC05C.DDE25F33-ON00256B03.0045DCDC@btyp>,
> Steve....@yellgroup.com writes:
> |>
> |> Or, for more information try www.192.com which will search all electoral
> |> registers for the name you input, and give you back address, phone number
> |> etc.
> |>
> |> Paul Sture <paul....@bluewin.ch> on 11/09/2001 07:05:29 PM wrote:
> |>
> |> If you have his location, try Directory Enquiries at www.bt.com.
> |>
>
> Both of these seem like good ideas, until I provide the last bit of
> data. My friends name is "Smith". "David S, Smith" to be precise.
> How many of them do you thnk there might be in England today?? :-)
>
more I know socially.
___
Paul Sture
Switzerland