Itanium - End of life (California court critical of Oracle & HP)

[JC]

Here is a link to the article :-

http://www.xbitlabs.com/news/cpu/display/20120131190525_Court_Oracle_Breached_Contract_with_HP_to_Boost_SPARC_Positions_as_HP_Hided_Itanium_Roadmap.html

[Richard Maher]

"JC" <theco...@gmail.com> wrote in message
news:219c8d0e-5f9e-46c7...@bs8g2000vbb.googlegroups.com...

> Here is a link to the article :-
>
> http://www.xbitlabs.com/news/cpu/display/20120131190525_Court_Oracle_Breached_Contract_with_HP_to_Boost_SPARC_Positions_as_HP_Hided_Itanium_Roadmap.html
>

Ummm, was I the only one who didn't believe Larry's IA64 EOL story?

Regards Absolutely Gutted from Perth

[Bob Koehler]

"Hided"?

OK, that's the URL creator, the author wrote "Hid".

But did he have any grip on reality when he wrote "Kittson+ is the
last IA64". Doesn't Intel have something to say about this?

[JF Mezei]

Richard Maher wrote:

>> http://www.xbitlabs.com/news/cpu/display/20120131190525_Court_Oracle_Breached_Contract_with_HP_to_Boost_SPARC_Positions_as_HP_Hided_Itanium_Roadmap.html


I guess one would have to find the actual court ruling to see the actual
text about the end of life for Itanium.

That article makes it quite clear that the court found HP was hiding the
fact that it did have plans to EOL Itanium at Kittson.


It has always been obvious that Oracle widthdrew its support of that
IA64 thing in order to hurt HP and move customers to Sun.


However, that court ruling apparently confirms Oracle's claim that HP
will EOL IA64 soon.

Meg Whitman basically confirmed this in her first speech as CEO, when
she said that BCS was shrinking and that they wouldn't do anything about
it and instead focus on scaling 8086s to Superdome class machines.

What is interesting in this is the claim that HP is purposefully slowing
down IA64 development to stretch its lifetime. Also reminscent of the
EV7 which was released first at slower speed and then released at its
nominal speed as the final version. (Kittson and Kittson+)


*IF* the court documents really show that Kittson is the last IA64, this
will be an interesting way for HP to announce the EOL for IA64.

Big question now is how HP will react. If those news cause customers to
start to defect at a faster rate, how will HP react ? Would it bring in
Poulson and Kitson out faster to help reduce defection rate, and more
importantly, will it finally spill the beans on the future of HP-UX, VMS
and NSK in a IA64-less world ?


Note that this article (same author) adds some more info:
http://www.xbitlabs.com/news/cpu/display/20120201201109_HP_Paid_Intel_690_Million_to_Keep_Itanium_Alive_Court_Findings.html


Basically confirms that HP has paid $690 million since 2008 to keep IA64
development going (and still has to pay for the chips separatly).

[JF Mezei]

I'd say at this point, the itanic has its wheel house under water with
the captain in it, and the stern way up in the air, with the ship ready
to break in half in the final irreversible path towards the bottom of
the atlantic.

And to think that in the 1990s, it was the 8086 whose life was in
question. That little toy controller sure has gone a long way and will
outlive alpha, Pa-Ric, Itanium, 68k and so many others.

[Phillip Helbig---undress to reply]

In article
<219c8d0e-5f9e-46c7...@bs8g2000vbb.googlegroups.com>, JC
<theco...@gmail.com> writes:

> Here is a link to the article :-
>
> http://www.xbitlabs.com/news/cpu/display/20120131190525_Court_Oracle_Breached_Contract_with_HP_to_Boost_SPARC_Positions_as_HP_Hided_Itanium_Roadmap.html

Hoff has an interesting collection of links:

http://labs.hoffmanlabs.com/node/1802

[Phillip Helbig---undress to reply]

In article <jge7f2$39s$1...@speranza.aioe.org>, "Richard Maher"

Actually, both sides they claim they are winners, but in my view they
are both losers (not to mention the customers). Yes, the court ruled
that Oracle's business practice here was not good and was essentially
spreading woo in order to drive people to Sparc. On the other hand,
documents from HP revealed by the court show a definite EOL for Itanium.

[Phillip Helbig---undress to reply]

In article <wAdhdG...@eisner.encompasserve.org>,

If they did, wouldn't they have? Check out the links on Hoff's page.

[Phillip Helbig---undress to reply]

In article <4f2af6b7$0$23872$c3e8da3$a8a6...@news.astraweb.com>, JF

Mezei <jfmezei...@vaxination.ca> writes:

> Richard Maher wrote:
>
> >> http://www.xbitlabs.com/news/cpu/display/20120131190525_Court_Oracle_Breached_Contract_with_HP_to_Boost_SPARC_Positions_as_HP_Hided_Itanium_Roadmap.html
>
>
> I guess one would have to find the actual court ruling to see the actual
> text about the end of life for Itanium.

See my other post with a pointer to Hoff's page with lots of relevant
links.

> That article makes it quite clear that the court found HP was hiding the
> fact that it did have plans to EOL Itanium at Kittson.

Right.

> It has always been obvious that Oracle widthdrew its support of that
> IA64 thing in order to hurt HP and move customers to Sun.

Right.

> However, that court ruling apparently confirms Oracle's claim that HP
> will EOL IA64 soon.

Right.

> Big question now is how HP will react. If those news cause customers to
> start to defect at a faster rate, how will HP react ? Would it bring in
> Poulson and Kitson out faster to help reduce defection rate, and more
> importantly, will it finally spill the beans on the future of HP-UX, VMS
> and NSK in a IA64-less world ?

For the first time in my life, I think this really means the following:
either HP announce a port to x86 within a year or two, or we will see
VMS die a (slow) death within the next few years: first no faster
hardware, then no more software development. (This is essentially what
happened with VAX, with the BIG difference that VAX customers could move
to ALPHA relatively painlessly.)

[Neil Rieck]

I bet some people are regretting Alphacide now?

NSR

[Neil Rieck]

On Feb 2, 4:31 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article <4f2af6b7$0$23872$c3e8da3$a8a65...@news.astraweb.com>, JF

>
> Mezei <jfmezei.spam...@vaxination.ca> writes:
> > Richard Maher wrote:
>

> > >>http://www.xbitlabs.com/news/cpu/display/20120131190525_Court_Oracle_...

>
> > I guess one would have to find the actual court ruling to see the actual
> > text about the end of life for Itanium.
>
> See my other post with a pointer to Hoff's page with lots of relevant
> links.
>
> > That article makes it quite clear that the court found HP was hiding the
> > fact that it did have plans to EOL Itanium at Kittson.
>
> Right.
>
> > It has always been obvious that Oracle widthdrew its support of that
> > IA64 thing in order to hurt HP and move customers to Sun.
>
> Right.
>
> > However, that court ruling apparently confirms Oracle's claim that HP
> > will EOL IA64 soon.
>
> Right.
>
> > Big question now is how HP will react. If those news cause customers to
> > start to defect at a faster rate, how will HP react ? Would it bring in
> > Poulson and Kitson out faster to help reduce defection rate, and more
> > importantly, will it finally spill the beans on the future of HP-UX, VMS
> > and NSK in a IA64-less world ?
>
> For the first time in my life, I think this really means the following:
> either HP announce a port to x86 within a year or two, or we will see
> VMS die a (slow) death within the next few years: first no faster
> hardware, then no more software development.  (This is essentially what
> happened with VAX, with the BIG difference that VAX customers could move
> to ALPHA relatively painlessly.)

To your point, "they would be wise to announce intentions to port to
x86-64 NOW"

NSR
p.s. If they were really smart, they would say that they started the
port in India two years ago.

[Michael Kraemer]

Phillip Helbig---undress to reply schrieb:

> Actually, both sides they claim they are winners, but in my view they
> are both losers (not to mention the customers). Yes, the court ruled
> that Oracle's business practice here was not good and was essentially
> spreading woo in order to drive people to Sparc. On the other hand,
> documents from HP revealed by the court show a definite EOL for Itanium.

So, apart from having stated the (almost) obvious,
what did the court rule in the end?
Both companies should behave themselves
and not act like in the Kindergarden?
HP/intel are obliged to produce more Itanics after EOL?
Oracle is obliged to produce their DB for Itanics although
it doesn't make sense?

[Neil Rieck]

On Feb 1, 8:09 pm, JC <thecook...@gmail.com> wrote:
> Here is a link to the article :-
>

> http://www.xbitlabs.com/news/cpu/display/20120131190525_Court_Oracle_...

Good generalization here with humorous remarks following:

http://www.theregister.co.uk/2012/01/31/oracle_fraud_claim_rejected/

NSR

[JF Mezei]

Phillip Helbig---undress to reply wrote:

> For the first time in my life, I think this really means the following:
> either HP announce a port to x86 within a year or two, or we will see
> VMS die a (slow) death within the next few years: first no faster
> hardware, then no more software development. (This is essentially what
> happened with VAX, with the BIG difference that VAX customers could move
> to ALPHA relatively painlessly.)

HP will continue to produce IA64 boxes for some time to come, with 2 or
3 speed bumps in the CPU. The VMS roadmap is already devoid of major
developments.

Considering how HP handled the demise of its newly acquired Palm, I
would not be surprised to see VMS open sourced if it is dead-ended at
IA64, but remain proporietary if ported to the 8086.

[JF Mezei]

Michael Kraemer wrote:
>
> So, apart from having stated the (almost) obvious,
> what did the court rule in the end?

The court document made public on scribd (as per Hoff's web site), is an
HP submission to the case. It does show a trial date starting on Feb 27.
So I am not sure the court actually ruled on the issue.

> HP/intel are obliged to produce more Itanics after EOL?

I doubt very much that a court could or would order this. But if there
is evidence that HP had in fact already planned the EOL of IA64, then
Itanium's claims of such would not be false and HP could not get damages
from Oracle.

> Oracle is obliged to produce their DB for Itanics although
> it doesn't make sense?

It all depends on what sort of contracts exist between HP and Oracle.
Say HP had a 4 year contract with Oracle, and HP had an EOL of IA64
coming in 5 years. There would be no reason to cancel the 4 year
contract with Oracle since IA64 would continue to be produced during
that period.

[Bob Koehler]

In article <4f2b6891$0$1719$c3e8da3$b135...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>
> Considering how HP handled the demise of its newly acquired Palm, I
> would not be surprised to see VMS open sourced if it is dead-ended at
> IA64, but remain proporietary if ported to the 8086.

I would be very suprized if VMS was open sourced, since HP doesn't
own all the IP. It's no advantage to HP to spend money separating
the IP, nor is it clear the community would have a useable VMS from
the resulting source.

[Mike K.]

On Feb 3, 9:11 am, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:

> In article <4f2b6891$0$1719$c3e8da3$b1356...@news.astraweb.com>, JF Mezei <jfmezei.spam...@vaxination.ca> writes:
>
>
>
> > Considering how HP handled the demise of its newly acquired Palm, I
> > would not be surprised to see VMS open sourced if it is dead-ended at
> > IA64, but remain proporietary if ported to the 8086.
>
>    I would be very suprized if VMS was open sourced, since HP doesn't
>    own all the IP.  It's no advantage to HP to spend money separating
>    the IP, nor is it clear the community would have a useable VMS from
>    the resulting source.

How does HP not own all the IP? I had thought that DEC developed it in-
house. Given that HP bought Compaq which bought DEC, I would assume
that HP has all the rights.

Mike

[JF Mezei]

Bob Koehler wrote:

> I would be very suprized if VMS was open sourced, since HP doesn't
> own all the IP. It's no advantage to HP to spend money separating
> the IP, nor is it clear the community would have a useable VMS from
> the resulting source.

I think there are large parts of VMS that can be opensourced. Perhaps
not enough to allow a complete build of the system, but you could
probably port TPU to another OS for instance.

Also, once you open source VMS and it stops being a commercial offering,
X11/Motif becomes unincumbered with licence fees. (only proprietary OSs
have to pay licence fees for use of X11 and Motif).

[Michael Moroney]

JF Mezei <jfmezei...@vaxination.ca> writes:

>I think there are large parts of VMS that can be opensourced. Perhaps
>not enough to allow a complete build of the system, but you could
>probably port TPU to another OS for instance.

>Also, once you open source VMS and it stops being a commercial offering,
>X11/Motif becomes unincumbered with licence fees. (only proprietary OSs
>have to pay licence fees for use of X11 and Motif).

What other parts of OpenVMS are either owned by others or by HP but used
for something else that they're not about to give away?

You already mentioned the one I know of, X11/Motif. I suspect HP's TCP/IP
has common code used elsewhere. I suppose I should ask only about base
VMS, not layered products like languages.

[Keith Parris]

On 2/2/2012 2:31 PM, Phillip Helbig---undress to reply wrote:
> In article<4f2af6b7$0$23872$c3e8da3$a8a6...@news.astraweb.com>, JF
> Mezei<jfmezei...@vaxination.ca> writes:
>
>> Richard Maher wrote:
>> That article makes it quite clear that the court found HP was hiding the
>> fact that it did have plans to EOL Itanium at Kittson.
>
> Right.

Did you read the documents???

In actuality, the unredacted document gives us the first public glimpse
of the existence of a planned 3rd future generation of Itanium beyond
the current Tukwila and the Poulson and Kittson generations that are on
the public Itanium roadmap.

I don't think this is evidence of an end-of-life for Itanium any more
than the roadmaps for Power or Sparc (or Xeon for that matter), which
have no more future generations than Itanium in their own public roadmaps.

[Subcommandante XDelta]

On 3 Feb 2012 08:11:58 -0600, koe...@eisner.nospam.encompasserve.org

Well there is no shortage of intelligence, erudition, skill and will
amongst the VMS community and surely the third-party IP components
have unambiguous well-formed functional specifications (heck! it's VMS
I&DS after all) and so could potentially be black-box emulated.

Or... the IP owners could be asked nicely. Of course Cherchez Le
Microsoft could buy out the critical path third-party IP owners to
keep VMS in it's box...

Should HP management pour a bucket of cold water on themselves and
wake up and smell the balance sheets and embrace HP's origins,
history, Way, and motto "Invent", re-establish esprit de corp, realise
there is more to corporate life than milking the corporation for short
term profits and leeching long term viability from the enterprises
assets, thence re-engage and re-invest in R&D, etcetera...

Then they could commit to migrating VMS to both the i386 and
i686/AMD64 [right nomenclature?] architectures and tackle the
Microsoft Monster head on, instead of being it's whore.

The possibilities are endless and the potential for profits
substantial in the long term, once they clock on that being, merely,
"the world's biggest PC vendor" is just a deviant phase they are going
through, whilst they have temporarily lost their HP way.

I can't see HP being hard-assed hardcore as IBM in divesting
themselves of the "Microsoft Problem", by jettisoning their PC
division, but they can at least release VMS from it's Itanic
prison/ghetto, VMS has barely survived and Microsoft has thrived at
VMS's expense.

HP ports to i386 for two reasons:

1. To sincerely telegraph and semaphore that they are truly sorry for
the last decade's behaviour.

2. They acknowledge that re-invigorating VMS's mind-share is going to
take some work, particularly if they want it to be rapid amongst the
current generation of young IT college and University students and
professionals both in the Anglosphere nations and elsewhere. VMS/i1386
would run more than adequately on old and recently unloved x32 bit
intel boxes and in concert with the Hobbyist licences provide a cheap
as chips means for the young to gear up rapidly on VMS and quite
possibly reclaim the lost art of writing device drivers.

Port VMS to ARM, port it to SUN/SPARC for amusement, but it's
essential to port it to i686/AMD64 for all the obvious reasons.

http://en.wikipedia.org/wiki/Hewlett-Packard

...focusing on higher-margin "strategic priorities of cloud, solutions
and software with an emphasis on enterprise, commercial and government
markets"...

Imagine VMS/i686 running on the government desktop, with all it's
superb security and auditability, with MS Windows binaries securely
contained within a WINE port or otherwise via VMS/VM (just made that
up, but what the hey!).

The possibilities are endless with VMS/i686...

I may be naive, a sentimental old fool, but there you go.
VMS Liberation Front: In VMS We Trust

[JF Mezei]

Keith Parris wrote:

> In actuality, the unredacted document gives us the first public glimpse
> of the existence of a planned 3rd future generation of Itanium beyond
> the current Tukwila and the Poulson and Kittson generations that are on
> the public Itanium roadmap.

No. The unredacted document is an HP submission. It is not a court
judgement.


Any evidence of HP planning to EOL IA64 would likely be from Oracle
submissions. HP would not self-incriminate itself.

[JF Mezei]

Subcommandante XDelta wrote:

> HP ports to i386 for two reasons:

I didn't know there were 64 bit iterations of the 386.

I don't see any reason for HP to port to non 64 bit 8086s. Current
generation processors are 64 bits. And short of a special project such
as replacing the on board shuttle software with VMS on those hardened
386 computers, I don't see any commercial reasons to port 32 bit version
of VMS which was last seriously updated in the early 1990s.


And besides, with the shuttle gone, there are really no reasons to port
VMS to 386s.

[Arne Vajhøj]

On 2/3/2012 12:53 PM, JF Mezei wrote:
> Bob Koehler wrote:
>
>> I would be very suprized if VMS was open sourced, since HP doesn't
>> own all the IP. It's no advantage to HP to spend money separating
>> the IP, nor is it clear the community would have a useable VMS from
>> the resulting source.
>
>
> I think there are large parts of VMS that can be opensourced. Perhaps
> not enough to allow a complete build of the system, but you could
> probably port TPU to another OS for instance.

Just the effort to separate what can be open licensed and what not
could be cost prohibitive.

> Also, once you open source VMS and it stops being a commercial offering,
> X11/Motif becomes unincumbered with licence fees. (only proprietary OSs
> have to pay licence fees for use of X11 and Motif).

X11 has always been opensource.

Arne

[JF Mezei]

Arne Vajhøj wrote:

> Just the effort to separate what can be open licensed and what not
> could be cost prohibitive.

Apart from Motif, what other stuff part ofthe VMS opearting system would
rely on technologies which HP does not have freedom to open source ?

I can see stuff like VAX Document which wa sold to Touch Technologies.
But those are layered products.

And in ters of source modules, I would assume that any compnents that
are "onwed" by someone other than Digital/HP would have some copyright
clearly marked in the source module.

Someone like Hoff who knows the VMS source code by heart should be able
to recite the name of modules containing "foreign" technologies by heart.

I could see issues with device drivers that use x86 code which is
emulated on the alpha or IA64 to talk to the device. Such code is likely
copyrighted by the maker of the device. But that would be clearly
identified. And since VMS uses old devices, it might not be hard to get
agreement to release those drivers to open source.

[Arne Vajhøj]

On 2/2/2012 11:54 PM, JF Mezei wrote:
> Considering how HP handled the demise of its newly acquired Palm, I
> would not be surprised to see VMS open sourced if it is dead-ended at
> IA64,

Why should they bother?

The interest in coding for VMS is pretty small compared to
the interest in whining over decisions made 10-20-30 years
ago.

Arne

[Arne Vajhøj]

On 2/3/2012 9:44 PM, JF Mezei wrote:
> Arne Vajhøj wrote:
>
>> Just the effort to separate what can be open licensed and what not
>> could be cost prohibitive.
>
> Apart from Motif, what other stuff part ofthe VMS opearting system would
> rely on technologies which HP does not have freedom to open source ?

I have not walked through all the code to look for
external code and checked what is covered by patents and
what they for other reasons may not want to distribute.

A company can not just say that they don't think there is a problem and
release the code. They need to check every piece of code and someone
need to signoff to legal.

It did take SUN about a year to get OpenJDK out as open source.

> I can see stuff like VAX Document which wa sold to Touch Technologies.
> But those are layered products.
>
> And in ters of source modules, I would assume that any compnents that
> are "onwed" by someone other than Digital/HP would have some copyright
> clearly marked in the source module.

Lawyers will not assume. They will want a written statement from
someone having actually read it all.

> Someone like Hoff who knows the VMS source code by heart should be able
> to recite the name of modules containing "foreign" technologies by heart.

Sure.

But I don't think he will publicize that type of information here.

Arne

[Jan-Erik Soderholm]

The main question is not a technical one.
Would the main users of VMS continue to use it if it was OSS ?

[Subcommandante XDelta]

Secondary question: Would the main users of VMS continue to use
OSS/VMS if analogues of Redhat and SUSE from the GNU/Linux World arose
to maintain their own OSS branches of the code tree?

Tertiary Question, if there was an OSS VMS Foundation, would the main
users second one of their best staff, on occasion, for six month
sabbaticals to maintain and develop the VMS code-base?

Many, many, questions can be formulated. a lot better than my
examples. :-)

_________________________________________
The VMS Liberation Front: In VMS We Trust

[JF Mezei]

Jan-Erik Soderholm wrote:

> The main question is not a technical one.
> Would the main users of VMS continue to use it if it was OSS ?

No. But portions of VMS would be ported to other operating systems and
survive there.

One possibility would be for an outfit such as OMX to take the open
source, port it to the 8086 and provide its enterprise grade stock
exchange solutions on industry standard business servers.

The other optio is that only NSK will be ported to 8086 and will inherit
all the markets that need reliable computing.

[Phillip Helbig---undress to reply]

In article <POeiEh...@eisner.encompasserve.org>,

koe...@eisner.nospam.encompasserve.org (Bob Koehler) writes:

> In article <4f2b6891$0$1719$c3e8da3$b135...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
> >
> > Considering how HP handled the demise of its newly acquired Palm, I
> > would not be surprised to see VMS open sourced if it is dead-ended at
> > IA64, but remain proporietary if ported to the 8086.
>
> I would be very suprized if VMS was open sourced, since HP doesn't
> own all the IP.

Who does?

[Neil Rieck]

Alternatives:

1) OpenVMS runs on some emulator running on x86-64.

2) port HP-UX to x86-64 then run OpenVMS as a virtual instance.

3) port OpenVMS to x86-64.

I haven't communicated with any OpenVMS customers in the USA, but the
informal consensus in Canada and Europe seems to be that "HP's failure
to announce option 3 will be interpreted as HP's signal that OpenVMS
has no future".

In my shop, we are currently running OpenVMS-8.4 on a AS-DS20e (with a
paid-up s/w support contract) and were very close to convincing the
bean counters that an Itanium replacement should be purchased. Turns
out the bean-counters were more abreast of this fiasco than I was and
that Itanium option is pretty much evaporated. (BTW, there are lots of
other VMS boxes at my employers company).

Comment: right now I'm recalling and interview with ex-board member
Tom Perkins who quit in disgust around the time of the HP wire-tapping/
pretexting scandal initiated by chairwoman Patrica Dunn. Seems to me
that if the board was in any way involved in keeping the EOL of
Itanium secret, then the whole board needs to be fired and someone
should get hold of Tom Perkins. ARE ANY INSTITUTIONAL SHAREHOLDERS
READING THIS?

Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/OpenVMS.html

[Arne Vajhøj]

On 2/4/2012 4:51 AM, JF Mezei wrote:
> Jan-Erik Soderholm wrote:
>> The main question is not a technical one.
>> Would the main users of VMS continue to use it if it was OSS ?
>
> No. But portions of VMS would be ported to other operating systems and
> survive there.

The most interesting parts are probably already taken.

> One possibility would be for an outfit such as OMX to take the open
> source, port it to the 8086 and provide its enterprise grade stock
> exchange solutions on industry standard business servers.

It would be a lot cheaper for them to port their app
to another OS than to port the OS.

Arne

[Richard Maher]

"Keith Parris" <keithparris...@yahoo.com> wrote in message
news:jghish$m4d$1...@usenet01.boi.hp.com...

"The court found HP's attempt to hide aspects of Itanium's roadmap and
end-of-life plan to partners and own employees (by not revealing that
Kittson+ is the last IA64)."

Who to believe? Keith Parris Fanboi and Vested Interest -vs- The superior
Court of the state of California. Umm?

I'm sure the usual suspects will make a lot of consultancy dollars
de-sandbagging Kittson at those customers siily enough to still upgrade
after these revelations :-(

I just don't know how HP's share-price can still be on the up! They scrap
their tablet OS and pretty much pull out of the client market then they
abandon all investment in the HPC server market.

Just what is going on at that company???

Regards Richard Maher

[Arne Vajhøj]

On 2/4/2012 8:42 PM, Richard Maher wrote:
> I just don't know how HP's share-price can still be on the up! They scrap
> their tablet OS and pretty much pull out of the client market then they
> abandon all investment in the HPC server market.
>
> Just what is going on at that company???

They changed their mind about dropping out of the
PC market.

How big do you think Itanium servers are compared
to x86-64 servers, PC's, printers, printer consumables,
consulting?

Arne

[JF Mezei]

Arne Vajhøj wrote:

> It would be a lot cheaper for them to port their app
> to another OS than to port the OS.

If this is the sentiment, then there is no point in porting VMS beyond IA64.

However, for HP, they need to consider how many VMS customers they would
lose to Sun/IBM/Dell if the kill off VMS, especially if Oracle remains
unfriendly with HP.

Upper management have been give certain assumptions of what percentage
of BCS customers will remain with HP after IA64 and HP-UX/VMS are
killed. and this is likely going to be a major driver of decisions on
whether to port VMS or not.

[JF Mezei]

Richard Maher wrote:

> I just don't know how HP's share-price can still be on the up! They scrap
> their tablet OS and pretty much pull out of the client market then they
> abandon all investment in the HPC server market.

HP did not abandon investment in HPC server market, they have embarked
on an ambitious programme to scale the 8086 all the way up to the
superdome class machines.


Lets face it, they recognized that IA64 wasn't going to give HP a
performance advantage, and since it had remained a low production
proprietary chip, would continue to straddle HP with high costs compared
to industry standard chips.

[Craig A. Berry]

Richard Maher wrote:
> "Keith Parris" <keithparris...@yahoo.com> wrote in message
> news:jghish$m4d$1...@usenet01.boi.hp.com...
>> On 2/2/2012 2:31 PM, Phillip Helbig---undress to reply wrote:
>>> In article<4f2af6b7$0$23872$c3e8da3$a8a6...@news.astraweb.com>, JF
>>> Mezei<jfmezei...@vaxination.ca> writes:
>>>
>>>> Richard Maher wrote:
>>>> That article makes it quite clear that the court found HP was hiding the
>>>> fact that it did have plans to EOL Itanium at Kittson.
>>> Right.
>> Did you read the documents???

The documents are multiplying and there will likely be a lot more as the
trial progresses since the judge has denied motions by both Oracle and
HP to seal documents. Many of them are readily accessible on the case
home page of the Superior Court of California, County of Santa Clara web
site:

<http://www.scefiling.org/cases/casehome.jsp?caseId=650>

>> In actuality, the unredacted document gives us the first public glimpse of
>> the existence of a planned 3rd future generation of Itanium beyond the
>> current Tukwila and the Poulson and Kittson generations that are on the
>> public Itanium roadmap.
>>
>> I don't think this is evidence of an end-of-life for Itanium any more than
>> the roadmaps for Power or Sparc (or Xeon for that matter), which have no
>> more future generations than Itanium in their own public roadmaps.
>
> "The court found HP's attempt to hide aspects of Itanium's roadmap and
> end-of-life plan to partners and own employees (by not revealing that
> Kittson+ is the last IA64)."

The only document so far released that I can find saying anything like
that is not a court finding but rather Oracle's cross-complaint alleging
fraud:

<http://www.scefiling.org/filingdocs/14198/46188/endorse_74225_AmendedxCrossxComplaint.pdf>

and as I understand it the fraud claim has been denied. Maybe there is
another ruling that has been issued but not yet published.

Even if Oracle's allegations are true, as far as I can tell it just
means that Intel, not HP, planned EOL for Itanium but that HP prevented
it from happening by getting out its checkbook -- again. Given that
they've supported the development of Itanium before, it seems
unsurprising that they'd do it again. I suppose the details will be
embarrassing to HP, but the details of what the spend on SPARC
development would probably be embarrassing to Oracle.

Personally I think VMS customers should be more concerned about the
nearly-nonexistent VMS roadmap than about the mud being slung by Oracle.

[John Wallace]

Low volume high costs is of course exactly the logic that was used to
justify Alpha's termination in favour of what was then touted to be
"industry standard 64bit" (IA64) because (at that time) Intel were
telling everyone that a 64bit x86 wasn't going to happen.

Then AMD introduced AMD64, and its success in volume in comparison
with IA64 once again showed that outside their 8086-derived Windows-
supported comfort zone, Intel haven't had a clue for years. Today
AMD64 and its Intel clone is where it's at, apart from the tiny (but
relatively profitable in principle vs Proliant?) market sector that
needs ultra-massive-memory ultra-massive-SMP systems where IA64 still
just about competes.

Thanks be to GQ Bob, and his successors.

[Neil Rieck]

Adding to your points, remember that ~ 10 years ago, Carly & Curly
killed Alpha then attempted to convince everyone that Itanium was the
future. But unlike the Steve Jobs "reality distortion field", the
Carly & Curly "Jedi hand wave" was not able to overcome the laws of
physics (ie. just because moving from CISC to RISC provided
improvements in computing power higher than Moore's Law didn't mean
that the same result would happen again shifting from RISC to EPIC /
VLIW technology)

(many engineers have quietly admitted that top Itanium processing
speeds came from advancements in other areas like geometry shrinks,
DDR3 memory, CSI/QPI, multi-core, which all would have happened in
Alpha which led the pack)

Now we all know that PA-RISC was killed "after" Alpha, so the bong-
inhaling people in HP's upper management as well as HP's board still
believed in the EPIC / VLIW fantasy at that time. But sometime between
killing PA-RISC and the revelations from this recent court case,
people at HP realized Itanium was never going to live up to anyone's
expectations.

At this point HP had two paths forward:
1) Admit they made a mistake then shift directions to another CPU
technology
2) Continuing to pay millions of dollars to Intel (calling it
development money rather than a bribe) then lie to customers telling
them that Itanium still had a long term future.

It is obvious to everyone now that they went with path #2 and we
wouldn't know about it if Hurd hadn't been fired by HP then hired by
Oracle. Many people will think path #1 (admitting a mistake) would be
impossible. But this choice wouldn't have been much different than
what had been done after the EOL announcement of Alpha where engineers
continued to produce chips like EV7z while promising to support Alpha
systems until 2011, or later, depending upon customer demand.

We were all told that Compaq couldn't continue to make Alpha chips
because they were losing dollars on every unit. In hind sight, I
wonder just how much money was transferred from HP to Intel, and what
HP actually paid for each Itanium chip. Perhaps making their own Alpha
chips at Hudson Mass was a mistake but that problem could have been
correct by shifting chip manufacturing to Intel or IBM. I wonder if
any of them will ever write a book fessing up about the mistake to
kill Alpha.

[Paul Sture]

On Sun, 05 Feb 2012 09:42:57 +0800, Richard Maher wrote:

> I just don't know how HP's share-price can still be on the up! They
> scrap their tablet OS and pretty much pull out of the client market then
> they abandon all investment in the HPC server market.
>
> Just what is going on at that company???

At the moment I'm seeing a lot of "cash back" offers on HP kit, and a
couple of weeks ago a local dealer was offering two HP Xeon class systems
for the price of one. Getting rid of old stock perhaps?



--
Paul Sture

[FrankS]

On Feb 5, 7:43 am, Neil Rieck <n.ri...@sympatico.ca> wrote:
> 2) Continuing to pay millions of dollars to Intel (calling it
> development money rather than a bribe) then lie to customers telling
> them that Itanium still had a long term future.

True story: A couple of years ago I needed a particular switch which
was out of production. I spoke with the manufacturer and they still
had all the tooling available to make the switch, but there was simply
not enough demand to keep it on the shelves ready to ship. I really
needed that switch, and I knew a bunch of other people that wanted a
spare of the same, so I arranged for a batch to be produced. It
required an up-front fee, plus the cost of each switch, with a minimum
order quantity.

This sort of thing happens all the time. If you're making a product
that requires a part which can only be sourced from a single vendor,
and that vendor no longer produces the part in the normal course of
their business, then you can still contract with the vendor to custom-
build the part for you. There are costs associated with building the
part which you will be required to pay, and then you pass that
additional cost on to the purchaser(s) of your completed product.

Why is it that everyone is making such a big deal out of HP's paying
Intel to continue building Itanium chips? If the Itanium server,
software, and consulting market is a big enough revenue generator for
HP then the cost of paying for the Itanium development team can be
seen as a drop in the bucket. It's no different than outsourcing any
other development that can't be done in-house.

I strongly suspect that HP is probably paying a number of outside
vendors to produce other parts for the Integrity servers that are not
built in-house, and for which those vendors have no other customers
for the same items. Yet, I don't see people huffing and puffing about
HP's paying for the build of, say, the Integrity chassis or plastic
bezels. These are just custom-produced parts and the Itanium CPU can
just be seen as a falling into the same category.

Big freakin' whoop.

[Michael Moroney]

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:

>On 2/4/2012 4:51 AM, JF Mezei wrote:
>> Jan-Erik Soderholm wrote:
>>> The main question is not a technical one.
>>> Would the main users of VMS continue to use it if it was OSS ?
>>
>> No. But portions of VMS would be ported to other operating systems and
>> survive there.

>The most interesting parts are probably already taken.

The most interesting part (IMO), clustering, hasn't been taken yet.
Even HP didn't use it for HP/UX clustering.

A long time ago the rumor was that Microsoft obtained a license to the
clustering technology. Either it was always false, or M$ still hasn't
been able to figure it out, or they obtained the rights to bury it.

[Arne Vajhøj]

On 2/4/2012 11:59 PM, JF Mezei wrote:
> Richard Maher wrote:
>> I just don't know how HP's share-price can still be on the up! They scrap
>> their tablet OS and pretty much pull out of the client market then they
>> abandon all investment in the HPC server market.
>
> HP did not abandon investment in HPC server market, they have embarked
> on an ambitious programme to scale the 8086 all the way up to the
> superdome class machines.

????

HPC = super computers

x86-64 has already completely beaten Itanium and everyone else
in that area.

Top500 today is almost all x86-64 and Linux.

HP has a decent market share of that market.

Arne

[Arne Vajhøj]

On 2/4/2012 11:52 PM, JF Mezei wrote:
> Arne Vajhøj wrote:
>
>> It would be a lot cheaper for them to port their app
>> to another OS than to port the OS.
>
> If this is the sentiment, then there is no point in porting VMS beyond IA64.
>
> However, for HP, they need to consider how many VMS customers they would
> lose to Sun/IBM/Dell if the kill off VMS, especially if Oracle remains
> unfriendly with HP.

It would still be cheaper for HP to port the OS than for
1000 users to each port the app.

Just don't expect a single user to take on the cost.

Arne

[JF Mezei]

Craig A. Berry wrote:

> Even if Oracle's allegations are true, as far as I can tell it just
> means that Intel, not HP, planned EOL for Itanium but that HP prevented
> it from happening by getting out its checkbook -- again.

One needs to go back to 2004 when La Carly and Intel announced a series
of measures for IA64. One was the end of IA64 workstations,
announcement that 8086 would get CSI and go 64 bits, and the end of HP's
development of IA64 by shifting chip engineers over to Intel and sending
a whole big wad of cash to Intel (in the billions as I recall).

In essence, HP outsourced development of IA64 to Intel by paying it
large sums of money to develop it at a rate that HP was willing to pay for.

As well IA64 was relegated from all purpose commodity "industry
standard" chip to a high performance computing enterprse server chip.

> Given that
> they've supported the development of Itanium before, it seems
> unsurprising that they'd do it again.

Once it becomes public how much HP has been spending to avoid admitting
IA64 is a commercial failure and that it is a liability to HP not only
because of lack of stellar performance but more importanly huge costs,
HP will be under a lot of pressure form shareholders to get rid of this
albatrosss.

Whitman has already announced that Superdomes are moving to 8086s. My
guess is that their plan was to wait for Superdome 8086s with
performance superior to that of IA64 equivalent before announcing that
since AI64 gives no performance advantage, customers should begin to
move to 8086s and that new chips for IA64 will end in 2 years and that
IA64 based systems will stop shipping in 5 years (or whatever time frame)

The Oracle issue may just force HP to admit to the planned EOL for IA64
earlier than planned. Or worse, it may push HP to commit to more IA64
development just to prove Oracle wrong. Somehow, I doubt Whitman would
go for that. Admitting IA64 was a mistake would not reflect badly on her
since she wasn't responsible for it.

> Personally I think VMS customers should be more concerned about the
> nearly-nonexistent VMS roadmap than about the mud being slung by Oracle.

There is to be no single smoking gun piece of evidence that proves IA64
is to be EOLed. But it is when you put all the small pieces together,
including the seerely reduced roadmap for VMS that a clear picture emerges.

[Richard B. Gilbert]

Hey JF! Please proof read before posting or use a spelling checker! I
think the "Vassar" spell checker may still be available.

[JF Mezei]

http://www.scefiling.org/filingdocs/194/46062/endorse_74100_203163_order.pdf
seems to provide a good summary of the legal battle.

This appears to hinge on the Hurd agreement where HP would drop the
lawsuit because Oracle hired Hurd in exchange for Oracle renewing its
commitment to a good relationship with HP which includes continued IA64
development.

Oracle argues that HP decieved Oracle by hiding serious issues. Not
only is there the issue of the future of IA64, but also the hiring by HP
of Apotheker (ex SAP) and Ray Lane (ex Oracle) with intentions to seer
HP into enterprise software and thus compete head to head against Oracle
instead of being complimentary vendors.

HP widtheld the information that IA64 is still alive solely due to
payments of roughly $88 millioN/year by HP to Intel and that Intel has
no intentions to continue developing the chip by itself.






However the following document is far more interesting:

http://www.scefiling.org/filingdocs/14198/46188/endorse_74225_AmendedxCrossxComplaint.pdf

provides Oracle's accusations and is pretty damning.


So it appears that my 2004 speculation was right. As you may recall,
Intel announced not only 64 bit 8086s but also the use of CSI for the
8086 as well by 2007. This was late and arrived end of 2008. My
specualtion was that once the 8087 has CSI and 64 bits, there would be
no advantage left to IA64 and it could be abandonned.

Turns out that Intel did want to abandon IA64 by 2008 and that HP signed
another contract to keep it on life support. Based on text in the first
document this was to the tune of $88million/year.


paragraph 9: (line 18 of page number 3 (page 4 in PDF):

"First, HP-UX was (ans is) HP's only proprietary operating system for
its servers, and HP uses it only for its Itanium-based servers.


later on: In othr words, HP had backed itself into a corner,
overselling its Itanium solutions and under-selling its Xeon solutions
to that point that Intel,s decision to dease Itanium production was life
threathening. As HP's Senior Vice President and General Manager in
charge of its Business Critical Systems unit put it, HP was
"strategically screwed".


HP therefore made a bold play: see it it could entice Intel to continue
to manufacture Itaium chips y paying it hundreds of millions of dollars
to continue producing Itanium chips for a period of time -- but
*secretely* -- so that HO ciuld also pass off to the owrld that nothing
had changed, the Itanium processor was still alive and well and INtel's
commitment to it had not wavered.



The march 2008 agreement between Intel and HP : $440 million to prolong
IA64 for 3 more generations. Tukwila in 2009, Poulson in 2011 and
Kittson in 2012. UNDER THAT AGREEENT KITTSON WOULD BE THE LAST ITANIUM
CHIP, WHICH INTEL AGREED TO PRODUCED THROUGH 2014. (emphasis mine)


This did not cover the cost of the chips which HP still had to purchase.

Oracle's beef is that HP kept this agreement secret even to its own
sales force in orde rto maintain the illusion that IA64 was healthy. So
when Oracle signed the Hurd agreement, it was under the false illusion
that IA64 was far healtier with longer life time than was planned in
reality. Hence the wilfull deception by HP.


One of the graphs obtained by Oracle from HP inludes curves showing
revenue growth/decline. This includes the Alphaserver e3000 and H 9000
end of life slope, Integrity end of life slope startng in FY 2012 when
the market would realise the IA64 end of life, and one most intereing
curve: "Includes aggressive growth with Superdome X86 and HP-UX/x86"

The 8086 Superdomes have already been annonced.

But before you rejoice at the though of VMS and NSK also ported to the 8086:

Paragraph 17: Instead, in 2010, HP extended the "Itanium collaboration
Agreement" and the fraud on consumers and Oracle. It did so when it
decided, contrary to its original plan, not to continue the effort to
post HP-UX to the Xeon platform by the time Intel ceased producing Itanium.



October 1020: HP extends the agreement with Intel to the tune of 250
million dollars for 3 more years of Itanium production and stretch the
roadmap by changing the date Kittson is to released, and introducing
K22+, a Kittson speed bump to be introduced 2 years later. This should
allow BCS to survive until 2017.

This deal includes Intel's request to stop deveopping IA64 chipsets, so
Kittson will be socket compatible with Xeons since this will save Intel
lots of money.

[JF Mezei]

Richard B. Gilbert wrote:

> Hey JF! Please proof read before posting or use a spelling checker! I
> think the "Vassar" spell checker may still be available.

Sorry, the documents are scanned, so I cannot cut/paste and must type
while reading them on a different screen :-(

[ChrisQ]

On 02/05/12 14:40, Michael Moroney wrote:
> =?ISO-8859-1?Q?Arne_Vajh=F8j?=<ar...@vajhoej.dk> writes:
>
>> On 2/4/2012 4:51 AM, JF Mezei wrote:
>>> Jan-Erik Soderholm wrote:
>>>> The main question is not a technical one.
>>>> Would the main users of VMS continue to use it if it was OSS ?
>>>
>>> No. But portions of VMS would be ported to other operating systems and
>>> survive there.
>
>> The most interesting parts are probably already taken.
>
> The most interesting part (IMO), clustering, hasn't been taken yet.
> Even HP didn't use it for HP/UX clustering.
>

They probably couldn't use it as is, since much of it would been
written in bliss ?. Clustering is a set of techniques and algorithms and
other vendors have had "clustering" for years, including Sun and most likely
IBM and others. Whether you think it is as good as vms clustering is
beside the point. The question being: What problem was vms clustering
originally intended to solve and have competitors something equivalent or
nearly so ?. It's no good waving hands in the air and saying it's better,
if 90%+ of the problem can be solved by other means and with progress, more
cost effectively.

I'll bet hp had a very good look at vms clustering, noted the best points,
discarded the rest and added their own sauce for HP/UX. That's called
incremental development from an original good idea...

Regards,

Chris

[JF Mezei]

It would be ironic if, while the port of HP=UX to the 8086 proved to be
too much of a challenge, Hoff and friends had managed to show VMS could
affordably be ported to 64 bit EFI based 8086 servers.

HP would then have VMS as its primary proprietary operating system for
its high end servers while HP-UX would be the one dead ended with the
death of IA64.


for those who skipped my previous messages because they were too long ,
read this:

http://www.scefiling.org/filingdocs/14198/46188/endorse_74225_AmendedxCrossxComplaint.pdf


This details very well how HP intended to proceed with IA-64 and HP-UX.

[JF Mezei]

ChrisQ wrote:

> I'll bet hp had a very good look at vms clustering, noted the best points,
> discarded the rest and added their own sauce for HP/UX. That's called
> incremental development from an original good idea...

Nop. HP looked at porting Tru64 clustering to HP-UX. This was part of a
promise when HP announced its Unix roadmap when it acquired Compaq.

HP then changed it mind and decided to do provide clusrering via Veritas
file servers/software instead of its own.

[Arne Vajhøj]

On 2/5/2012 5:20 PM, JF Mezei wrote:
> It would be ironic if, while the port of HP=UX to the 8086 proved to be
> too much of a challenge, Hoff and friends had managed to show VMS could
> affordably be ported to 64 bit EFI based 8086 servers.

And it sound so plausible that it would be easier to port
Macro-32 and Bliss to a new CPU architecture than C ?!?!

Arne

[ChrisQ]

Wasn't aware of that, but an outsourced solution was probably cheaper than
taking the long term view in terms of developing original solutions.

Is veritas as good as vms clustering, or is it just smoke and mirrors
from sales ?...

Regards,

Chris

[JF Mezei]

Arne Vajhøj wrote:

> And it sound so plausible that it would be easier to port
> Macro-32 and Bliss to a new CPU architecture than C ?!?!

Endianness.

Consider HP is paying close to 90 million per year just to keep the
semblance that IA64 is still being developped

Take one year of those payments, give that money to Hoff and he will
have ported VMS in a couple of afternoons. :-)


In fact, it would not surprise me if the dismissal of the VMS
engineering team occured when HP decided to EOL its proprietary OS after
the evaluatio of porting efforts for HP-UX proved too expenive/complex
and HP decided to write off the 3 operating systems and send the to
maintenance mode in India.

[JF Mezei]

In a court filing, it is interesting that Oracle would have written that
HP-UX is the only OS running on IA64. (or something akin to this) when
you consider that Oracle has products on VMS and probably on NSK as well.

Perhaos the deal to continue support with HP was only for HP-UX and
Oracle didn't commit to continued development on VMS/NSK so those two OS
need not be mentioned in the court filings.


I doubt that Oracle would have casually forgotten to mention VMS and NSK
in the court documents.

Perhaps VMS and NSK are being ported beyond IA64, or perhaps their EOL
will come before that of IA64. So I get a feeling that VMS and NSK will
be treated different from HP-UX at the IA64 funeral.

[Arne Vajhøj]

On 2/5/2012 6:56 PM, JF Mezei wrote:
> Arne Vajhøj wrote:
>> And it sound so plausible that it would be easier to port
>> Macro-32 and Bliss to a new CPU architecture than C ?!?!
>
> Endianness.

Getting a big-endian Unix to run on little-endian is
doable.

> Take one year of those payments, give that money to Hoff and he will
> have ported VMS in a couple of afternoons. :-)

I don't think Hoff would signup for that.

Arne

[Subcommandante XDelta]

On Sun, 05 Feb 2012 20:01:28 -0500, Arne Vajhøj <ar...@vajhoej.dk>
wrote:

Whom else then, off the couch? - so to speak.

HP's essentially jumped Vernon, unless they've had an 11th hour 59th
minute Damascean Conversion on the VMS Roadmap - but has the Hoff
jumped Vernon as well?

A mildly heretical question, but none the less put out there.

[Arne Vajhøj]

On 2/5/2012 8:28 PM, Subcommandante XDelta wrote:
> On Sun, 05 Feb 2012 20:01:28 -0500, Arne Vajhøj<ar...@vajhoej.dk>
> wrote:
>> On 2/5/2012 6:56 PM, JF Mezei wrote:
>>> Arne Vajhøj wrote:
>>>> And it sound so plausible that it would be easier to port
>>>> Macro-32 and Bliss to a new CPU architecture than C ?!?!
>>>
>>> Endianness.
>>
>> Getting a big-endian Unix to run on little-endian is
>> doable.
>>
>>> Take one year of those payments, give that money to Hoff and he will
>>> have ported VMS in a couple of afternoons. :-)
>>
>> I don't think Hoff would signup for that.
>

> Whom else then, off the couch? - so to speak.

You will need a team.

OS experts, compiler experts, VMS experts, x86-64 experts.

Expensive.

Something in the magnitude of 5 million hours ~ 500 million dollars.

Arne

[Subcommandante XDelta]

On Sun, 05 Feb 2012 17:20:31 -0500, JF Mezei
<jfmezei...@vaxination.ca> wrote:

>
>
>It would be ironic if, while the port of HP=UX to the 8086 proved to be
>too much of a challenge, Hoff and friends had managed to show VMS could
>affordably be ported to 64 bit EFI based 8086 servers.

Is this documented publically? Or as an internal briefing document
that could fall off an 11/780 backplane?

[Subcommandante XDelta]

On Sun, 05 Feb 2012 20:45:11 -0500, Arne Vajhøj <ar...@vajhoej.dk>
wrote:
:

>>>> Take one year of those payments, give that money to Hoff and he will
>>>> have ported VMS in a couple of afternoons. :-)
>>>
>>> I don't think Hoff would signup for that.
>>
>> Whom else then, off the couch? - so to speak.
>
>You will need a team.
>
>OS experts, compiler experts, VMS experts, x86-64 experts.
>
>Expensive.
>
>Something in the magnitude of 5 million hours ~ 500 million dollars.
>
>Arne

Aw, heck, it's worth it. How many men and men weeks would that be
roughly?

If HP-UX, NSK and VMS aren't getting it in the neck, at least there'd
be some commonalities and economies of scale, one would imagine.

Taking a slight tangent, if Intel can get away with blue bloody CISC
murder and continue to do so, a VAX64 chip family with an even
crispier, crunchier, more orthogonal, more heavenly, instruction set
than VAX32 (which was the very model of a modern major (CISC)
architecture) is conceivable.

How much would it cost, using back of the envelope metrics, to design
and fabricate that according to the latest techniques?

How many hours would it take to port GNU/Linux to the new
architecture?

(Not really inciting an A V. B debate)

Comcomitantly, if HP disentangled the VMS Source Code of IP snarls and
released it in the public domain, presumably an OSS/VMS Foundation
could port it to VAX64, and presumably it would still take several
million hours, but would it be do-able as a rather-extensive community
project?

Just tapping about in the dark, looking for that unitary photon of
hope.

On yet another tangent, even if 32bit is considered twee and old
fashioned, how much would it cost, give or take a ball-park to rebirth
VAX32 using the latest fabrication and design techniques?

[Craig A. Berry]

JF Mezei wrote:

> for those who skipped my previous messages because they were too long ,
> read this:
>
> http://www.scefiling.org/filingdocs/14198/46188/endorse_74225_AmendedxCrossxComplaint.pdf
>
>
> This details very well how HP intended to proceed with IA-64 and HP-UX.

What it details are Oracle's allegations. As I said when I made you
aware of this document, it is Oracle's fraud complaint, the one which
was apparently rejected by the court (I say apparently because I haven't
found the ruling and have only seen news reports saying the claim was
rejected). Probably some of it is true. Certainly some of it is not
true, not only the claim of fraud that the court turned down, but also,
as various people have noticed, the claim that HP-UX is HP's only
proprietary operating system running on Itanium, or the claim that
Microsoft Windows is an example of a non-proprietary operating system.
It's a shoddy and shrill document, likely put together in a hurry by
lawyers who barely understood the technical matters before them but had
orders to make as much mud stick as possible. I can't imagine anyone
basing technical or business decisions on this document without
independent corroboration.

Of course the HP brief reads like a marketing piece. Even if the rosy
picture it paints turns out to be true, there will likely be folks that
aren't entirely happy with how HP fertilized the rose garden. As various
people keep saying, no one wins in this case except IBM.

[JF Mezei]

The real question is whether HP willfully decimated VMS engineering to
make te decision to EOL VMS at same time as IA64 irreversible.

Without the pool of expertise of the original VMS engineering team, the
number of experienced VMS guys in India is not large enough to drive a
port to the 64 bit 8086. Maybe I am wrong on this, but I don't think so.

HP would have such a empty roadmap for VMS if it had enough talent on
payroll to make continued improvements to VMS.

[JF Mezei]

Craig A. Berry wrote:

> What it details are Oracle's allegations.

Oracle definitely didn't spare the punches on that one.

Yes, they are Oracle *allegations*, but they are rather credible.
Especially that graph showing decline of alpha, HP900 and 33000, decline
of itanium, and expected rise of HP-UX on x86

And then consider that HP is really building an 8086 based Superdome and
Whitman has announced that the 8086 Superdome is the future of BCS while
there is nothing that can be done to stop the decline of Itanium portion
of BCS. She said that publicly in an analyst conference not long after
she took over.

Remmeber that under Hurd, much of software engineering was decimated,
not just for VMS. It is quite possible that HP simply no longer has the
epxpertise in large enough number to port its 3 OS to the 8086 like it
did in the first years of this century when they were ported to IA64.

Oracle's allegations are very damning to HP. Should they not reflect
reality, HP could counter sue Oracle for billions of damages.

I have to assume that Oracle has enough evidence to present to support
its accusations about HP's secret contracts with Intel about life
support for IA64. They couldn't have launched those very severe
accusations without supporting evidence.



As some who has observed how Digital, Compaq and HP have behaved with
regards to VMS and IA64, I can say that Oracke's allegations fit in the
puzzle very nicely and they explain so well the way HP has behaved about
VMS and IA64 in the last 5-6 years. And it explains why some of their
employees would have a canned response to any discussion about IA64 or
notion of porting the OS to the 8086.

If those employees read those documents, I would expect them to be
rather miffed at their employer who knowigly lied to them to hide the
trie intentions of HP with regards to IA64.

[Arne Vajhøj]

On 2/5/2012 10:27 PM, Subcommandante XDelta wrote:
> On Sun, 05 Feb 2012 20:45:11 -0500, Arne Vajhøj<ar...@vajhoej.dk>
> wrote:
> :
>>>>> Take one year of those payments, give that money to Hoff and he will
>>>>> have ported VMS in a couple of afternoons. :-)
>>>>
>>>> I don't think Hoff would signup for that.
>>>
>>> Whom else then, off the couch? - so to speak.
>>
>> You will need a team.
>>
>> OS experts, compiler experts, VMS experts, x86-64 experts.
>>
>> Expensive.
>>
>> Something in the magnitude of 5 million hours ~ 500 million dollars.
>

> Aw, heck, it's worth it. How many men and men weeks would that be
> roughly?

I assume you have some software that can divide by 40.

> If HP-UX, NSK and VMS aren't getting it in the neck, at least there'd
> be some commonalities and economies of scale, one would imagine.

A little, but not much.

Different languages/compilers, different OS.

> Taking a slight tangent, if Intel can get away with blue bloody CISC
> murder and continue to do so, a VAX64 chip family with an even
> crispier, crunchier, more orthogonal, more heavenly, instruction set
> than VAX32 (which was the very model of a modern major (CISC)
> architecture) is conceivable.
>
> How much would it cost, using back of the envelope metrics, to design
> and fabricate that according to the latest techniques?

No idea.

> How many hours would it take to port GNU/Linux to the new
> architecture?

Some effort, but it is already ported to so many OS'es
(and use a HLL), so it will be fewer hours. And most likely
it will not be paid hours.

> Comcomitantly, if HP disentangled the VMS Source Code of IP snarls and
> released it in the public domain, presumably an OSS/VMS Foundation
> could port it to VAX64, and presumably it would still take several
> million hours, but would it be do-able as a rather-extensive community
> project?

If there was sufficiently many interested developers: yes.

Which is most likely not the case for VMS.

(based on the experience when someone is asking for
another one to take over maintenance of some VMS freeware)

> On yet another tangent, even if 32bit is considered twee and old
> fashioned, how much would it cost, give or take a ball-park to rebirth
> VAX32 using the latest fabrication and design techniques?

No idea.

Arne

[Arne Vajhøj]

On 2/5/2012 10:36 PM, JF Mezei wrote:
> The real question is whether HP willfully decimated VMS engineering to
> make te decision to EOL VMS at same time as IA64 irreversible.

Does not make any sense.

If HP do not want a port they simply don't fund the port.

Arne

[Arne Vajhøj]

On 2/5/2012 10:53 PM, JF Mezei wrote:
> Craig A. Berry wrote:
>> What it details are Oracle's allegations.
>
> Oracle definitely didn't spare the punches on that one.

Larry Ellison is not known to be a sheep.

Arne

[Howard S Shubs]

In article <doaui75h320uhcf6a...@4ax.com>,

Subcommandante XDelta <v...@star.enet.dec.com> wrote:

> On Sun, 05 Feb 2012 20:01:28 -0500, Arne Vajhøj <ar...@vajhoej.dk>
> wrote:
>
> >On 2/5/2012 6:56 PM, JF Mezei wrote:
> >> Take one year of those payments, give that money to Hoff and he will
> >> have ported VMS in a couple of afternoons. :-)
> >
> >I don't think Hoff would signup for that.
> >
> >Arne
>
> Whom else then, off the couch? - so to speak.

I'd like to be involved in such a project, meself.

--
May all your good dreams and fine wishes come true! - The Wizard
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods

[John Wallace]

On Feb 6, 3:27 am, Subcommandante XDelta <v...@star.enet.dec.com>
wrote:
> On Sun, 05 Feb 2012 20:45:11 -0500, Arne Vajhøj <a...@vajhoej.dk>

WHether it be 32bit or 64bit, I wouldn't suggest fabricating it unless
the demand was a LOT bigger than I'd expect. There are different
approaches that might suit 'testing the water' initially.

Lots of people seem quite happy with pure software emulations in a
modern x86 box. Would one of those with an official seal of approval
and a proper global support infrastructure offer much that isn't
already available?

If emulation in software (even using the technology the industry
laughably calls a 'bare metal' HYPErvisor) isn't for you, then the
next simplest approach is probably to use the amazing technology now
available in a modern FPGA, probably with the system-level
interface(s) built in by the FPGA vendor to reduce the overall effort
required. It doesn't eliminate the core CPU design and validation and
support work, but it does in principle eliminate the system/bus
interface work and should make the actual silicon-related work someone
else's problem.

You can (at least in principle) already do this kind of thing with
modern ARM processors: ARM sell you the design details to put in a
suitable modern FPGA:
http://www.arm.com/products/processors/cortex-m/cortex-m1.php

Doing it with VAX (with the whole job done so the end user can buy a
system not a chip) instead of ARM 'just' needs folk to do the VAX-
specific stuff and the system integration (and the validation and...),
if you assume the FPGA people have done their stuff right. Oh, and a
few lawyers and such, assuming the VAX intellectual property doesn't
belong to you.

In terms of costs, you'd probably be paying a few hundred dollars per
FPGA for the chips, which of itself doesn't seem unreasonable or
uneconomic (how much is an IA64 or an AMD64?). If volumes went through
the roof (which they wouldn't) there are typically ways and means of
spending money to re-implement the same design in a lower cost per
chip process. But there are costs to that work.

FPGAs today are a lot cleverer than they were ten years ago, but VAXes
aren't all that complicated in modern terms, especially non-SMP VAXes.
This approach *could* have been tried maybe ten years ago. If it was
tried, it didn't catch on. Whether circumstances are sufficiently
different now that it might work is anybody's guess.

FPGA Alpha? Not so sure. The story was that Alpha performance relied
in part on co-design between chip internals and silicon fabrication
details. You lose that co-design capability with an FPGA, where
someone else has already laid out the silicon and all the 'Alpha'
designer could do would be to change the way the pieces connect
together.

Off you go.

[Subcommandante XDelta]

On Sun, 05 Feb 2012 23:16:48 -0500, Arne Vajhøj <ar...@vajhoej.dk>
wrote:
:
:

>> How many hours would it take to port GNU/Linux to the new
>> architecture?
>
>Some effort, but it is already ported to so many OS'es
>(and use a HLL), so it will be fewer hours. And most likely
>it will not be paid hours.
>
>> Comcomitantly, if HP disentangled the VMS Source Code of IP snarls and
>> released it in the public domain, presumably an OSS/VMS Foundation
>> could port it to VAX64, and presumably it would still take several
>> million hours, but would it be do-able as a rather-extensive community
>> project?
>
>If there was sufficiently many interested developers: yes.
>
>Which is most likely not the case for VMS.
>
>(based on the experience when someone is asking for
>another one to take over maintenance of some VMS freeware)

Ouch. :-(

But if an OSS/VMS became possible, who knows who may come out of the
woodwork? - the 35th anniversary of VMS beckons.

Burial or Rebirth?

[Paul Sture]

On Mon, 06 Feb 2012 14:27:00 +1100, Subcommandante XDelta wrote:

> How many hours would it take to port GNU/Linux to the new architecture?

There's the crunch. There's a whole wealth of software out there which
sits on top of GNU/Linux and is but an apt-get or yum away for many
people.

--
Paul Sture
(currently running FreeBSD or variants thereof on both big and little
endian platforms)

[Bob Koehler]

In article <4f2c1f06$0$27928$c3e8da3$f017...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
> Bob Koehler wrote:
>
> I think there are large parts of VMS that can be opensourced. Perhaps
> not enough to allow a complete build of the system, but you could
> probably port TPU to another OS for instance.

Only if you write the underlying compiler for the other OS. IIRC
the TPU engine is written in BLISS.

But a/Soft already addressed that market, writing a portable TPU
from scratch which is API and TPU source compatable with the TPU
on VMS.

[Bob Koehler]

In article <jgm4dg$4rf$1...@pcls6.std.com>, mor...@world.std.spaamtrap.com (Michael Moroney) writes:
>
> The most interesting part (IMO), clustering, hasn't been taken yet.
> Even HP didn't use it for HP/UX clustering.

Some of the more critical underlying technology is already available
on other platforms. For example, IBM donated a distributed lock
manager to Linux.

[Bob Koehler]

In article <4f2f00b0$0$9438$c3e8da3$9b4f...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:
>
>
> It would be ironic if, while the port of HP=UX to the 8086 proved to be
> too much of a challenge, Hoff and friends had managed to show VMS could
> affordably be ported to 64 bit EFI based 8086 servers.
>

Why would HP spend funds on porting HP-UX when they can sell Linux
systems into the same market?

From past history, seeing how HP dropped it's MPE systems, 68K based
UNIX workstations, and Tru64 UNIX clustering without regrets, I
just see them telling thier current HP-UX customers that Linux has
everything they need.

[Bob Koehler]

In article <4f2f0dbd$0$285$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
> On 2/5/2012 5:20 PM, JF Mezei wrote:

>> It would be ironic if, while the port of HP=UX to the 8086 proved to be
>> too much of a challenge, Hoff and friends had managed to show VMS could
>> affordably be ported to 64 bit EFI based 8086 servers.
>

> And it sound so plausible that it would be easier to port
> Macro-32 and Bliss to a new CPU architecture than C ?!?!

There was some work being done on a gnu BLISS compiler. It seems to
be quite stalled.

[Bob Koehler]

In article <0gEXq.3842$rN2...@newsfe03.ams2>, ChrisQ <me...@devnull.com> writes:
>
> Is veritas as good as vms clustering, or is it just smoke and mirrors
> from sales ?...

Depends on what you're doing with it. It's much better for sales
than stealth marketing ever was. You won't get all the underlying
technology, so you may have to redesign applications.

[Bob Koehler]

In article <4f2f174d$0$23793$c3e8da3$a8a6...@news.astraweb.com>, JF Mezei <jfmezei...@vaxination.ca> writes:

> Arne Vajhøj wrote:
>
>> And it sound so plausible that it would be easier to port
>> Macro-32 and Bliss to a new CPU architecture than C ?!?!
>
>

> Endianness.

Macro-32 was invented for VAXen, which are little-endian just like
the x386, and most RISC chips are bi-endian, so how would endiannes
be an issue?

[John Wallace]

On Feb 6, 3:10 pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:

> In article <0gEXq.3842$rN2....@newsfe03.ams2>, ChrisQ <m...@devnull.com> writes:
>
> > Is veritas as good as vms clustering, or is it just smoke and mirrors
> > from sales ?...
>
>    Depends on what you're doing with it.  It's much better for sales
>    than stealth marketing ever was.  You won't get all the underlying
>    technology, so you may have to redesign applications.

" You won't get all the underlying technology, so you may have to
redesign applications."

Exactly. IBM may have contributed an open source distributed lock
manager, on which a distributed file system could be built, but UNIX/
Linux needs a DLM and a DFS like a fish needs a bicycle (to coin a
phrase).

VMS had the DLM architected in from the start, as did sensible stuff
built sensibly on VMS, so that things "just worked", even across
cluster nodes in due course. But any code intended to be 'portable'
typically had to be capable of coping with the lowest common
denominator, hence lock files and other such UNIXy delights for low
performance stuff, and various other mechanisms for stuff requiring
reasonable performance..

Another indicator that the world mostly doesn't care about this stuff
is the invisibility of (Tandem's and then Compaq's?) NonStopClusters
for SCO UNIX, which takes the "everything is a file" concept about as
far as it can be taken with a UNIX, and builds resilience and
scalability on top of it. But most folk won't have heard of it.
http://en.wikipedia.org/wiki/UnixWare_NonStop_Clusters

Wrt endianness: I didn't understand JF's comment either. IA64 is
capable of doing both kinds, given the right software.

[Keith Parris]

On 2/5/2012 4:27 PM, ChrisQ wrote:
> Is veritas as good as vms clustering, or is it just smoke and mirrors
> from sales ?...

Veritas provided a cluster-wide file system.

In addition to a cluster-wide file system, TruClusters also had a
connection manager and quorum scheme, a distributed lock manager, and
the ability to boot multiple systems from the same system disk (shared
root).

[VAXman-]

...and WEENDOZE provides Minesweeper and virus collection. No wonder it
is the preferred business platform while robust operating systems are on
the verge of being only a minor footnote in some future history book.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[Phillip Helbig---undress to reply]

In article <ffDXq.27180$M05....@newsfe20.ams2>, ChrisQ
<me...@devnull.com> writes:

> They probably couldn't use it as is, since much of it would been
> written in bliss ?.

Bliss was ported when Rdb (also written in Bliss) ran on some non-VMS
system, so that is not a big show stopper.

> Clustering is a set of techniques and algorithms and
> other vendors have had "clustering" for years, including Sun and most likely
> IBM and others. Whether you think it is as good as vms clustering is
> beside the point. The question being: What problem was vms clustering
> originally intended to solve and have competitors something equivalent or
> nearly so ?. It's no good waving hands in the air and saying it's better,
> if 90%+ of the problem can be solved by other means and with progress, more
> cost effectively.

Is there anything else, though, which offers all the benefits of
clustering? Ditto for HBVS. Even more for both together (more than the
sum of the parts).

[JF Mezei]

Bob Koehler wrote:
> Endianness.
>
> Macro-32 was invented for VAXen, which are little-endian just like
> the x386, and most RISC chips are bi-endian, so how would endiannes
> be an issue?

HP-UX is big-endian. The 8086 isn't. So they would have to convert to
little endian when porting HP-UX to the 8086.


Note that Apple pulled that off rather well going from big endian
PowerPc version of OS-X to little endian on the 8086 with Rosetta.

So it depends on how well the source is written and if all endianness
assumptions in the code can easily be identified.

[JF Mezei]

With regards to clustering. In the case of VMS, one major advantage is
that all the technologies are embedded deep into the operating systems,
activated very easly in the boot sequence.


It makes for far more integrated and robust solution, especially when
dealing with disaster tolerance where the OS itself ensures data
integrity via the quorum sheme.

[Jose Baars]

On Feb 6, 12:27 am, ChrisQ <m...@devnull.com> wrote:

> On 02/05/12 22:24, JF Mezei wrote:
>
> > ChrisQ wrote:

> Is veritas as good as vms clustering, or is it just smoke and mirrors
> from sales ?...
>

Judging from the occasional cursing of my Unix colleagues about it,
the latter.

[JF Mezei]

back in the late 1980s, performance was a big issue because companies
could use all the cpu they could get.

in today's business environment, is that still the case ?

In the next 5 years, will the non-stellar performance of IA64's CPU
force customers to migrate to other platfors, or are have the true
performance bottlenecks shifted from CPU/RAM over to network and file
system ?


While it is a given that customers have all but been given the formal
order to begin planning a port from VMS, NSK and HP-UX, will there be
many customers for whom the timing of the port will be quickened due to
Poulson and Kittson not being fast enough for their needs, or will those
speed bumps be more than enough to tide customers over until their
migration is complete ?

Also, as customer begin to migrate application by application, won't
that free up available capacity on the older I64 to handle growth to the
apps that have not yet been ported ?



Considering that the EOL of Itanium is currently at the "hamfful
speculation" stage beause those court documents are pretty damning and
credible but HP hasn't yet admitted to it, how long do corporate
customers give HP to come clean on the real plans and admit to the EOL ?

It seems to me that at this point in time, it would be very important
for customers to know if NSK and VMS and HP-UX will be ported to x86 or
not.

If HP refuses to spill the beans and confirm the EOL of IA64, HP-UX ,
NSK and VMS and continue to claim all is well with the legacy BCS
ecosystem, how will customers react ? Will they believe HP or will they
believe the court documents ?


or is it still possible for HP to review its decision to not port beyond
IA64 and announce it will port HP-UX, VMS and NSK to x86 ?

[Michael Kraemer]

ChrisQ schrieb:

> Wasn't aware of that, but an outsourced solution was probably cheaper than
> taking the long term view in terms of developing original solutions.

>
> Is veritas as good as vms clustering, or is it just smoke and mirrors
> from sales ?...

HP has a long standing relation with Veritas.
They already developed HP-UX's LVM way back in the 1990s.
So it probably was simply more cost effective to
go with Veritas for the clustering enhancements.
Tru64 would have been a totally different beast.

[Keith Parris]

On 2/6/2012 3:29 PM, JF Mezei wrote:
> back in the late 1980s, performance was a big issue because companies
> could use all the cpu they could get.
>
> in today's business environment, is that still the case ?

Some customers need all the CPU they can get, but for most OpenVMS
customers, plenty of CPU power is available, at economical prices.

> In the next 5 years, will the non-stellar performance of IA64's CPU

> force customers to migrate to other platforms, or are have the true

> performance bottlenecks shifted from CPU/RAM over to network and file
> system ?

Itanium's performance seems to be just fine for OpenVMS customers today.
Itanium boxes today tend to be at least twice as fast as the fastest
Alphas. OpenVMS customers love the i2 Blades.

> While it is a given that customers have all but been given the formal
> order to begin planning a port from VMS, NSK and HP-UX,

Your opinion.

> will there be
> many customers for whom the timing of the port will be quickened due to
> Poulson and Kittson not being fast enough for their needs, or will those
> speed bumps be more than enough to tide customers over until their
> migration is complete ?

I talked with a customer who just upgraded their GS-1280s from 16 CPUs
each to 32 CPUs each. Didn't Alpha "die" back in 2007 or 2008?

Tukwila chips are quad-core today, in a 65 nm process; Poulson will be
8-core, and skipping the 45 nm process, be in 32 nm process (thus
potentially much faster) and available in 2012. And Kittson will come
out after that, followed by the successor to Kittson. Each generation
released recently seems to be at least twice the performance of the
last. So I don't expect customers to migrate away from Itanium because
of insufficient performance.

[Michael Kraemer]

Arne Vajhøj schrieb:

> On 2/5/2012 6:56 PM, JF Mezei wrote:
>

>> Arne Vajhøj wrote:
>>
>>> And it sound so plausible that it would be easier to port
>>> Macro-32 and Bliss to a new CPU architecture than C ?!?!
>>
>>
>> Endianness.
>
>

> Getting a big-endian Unix to run on little-endian is
> doable.

Most probably.
Solaris for example runs on Sparc and x86, i.e. opposite endians.
Or, even more extreme,
around 1995 there was a (little-endian) Solaris on PPC,
i.e. an originally big-endian OS running in the "wrong"
mode on an originally big-endian hardware.

However, layered apps and data might cause problems if they aren't
endian-aware or endian-neutral.

[Jan-Erik Soderholm]

JF Mezei wrote 2012-02-06 23:29:
> back in the late 1980s, performance was a big issue because companies
> could use all the cpu they could get.
>
> in today's business environment, is that still the case ?
>

We run a factory/production management system on a 666 MHz
single CPU, single core AlphaServer DS20e. 130 VT-term users
logged in daytime. A bunch of barcode scanners, PLCs and label
printers connected. Runs at a mean of 5-10% CPU. 4 GB mem of
which 2 GB is used by XQP and 0.5 GB by Rdb Glob-buffers.

The smallest Itanium today is 2 CPU @ 4 core each (right?). At
something around 1.5 Ghz, if I'm not wrong. That is aprox 20
times the raw CPU performance of our current server.

What is it that needs all this raw CPU horsepower ?
A lot of Java? :-) Or any other lousy written code?

*I* don't know.

Jan-Erik.

[JF Mezei]

Keith Parris wrote:

>> While it is a given that customers have all but been given the formal
>> order to begin planning a port from VMS, NSK and HP-UX,
>
> Your opinion.

Have you read the court documents ? You won't be happy to learn that HP
made damned sure that people like you were kept out of the loop so that
you would have an easier job of pushing IA64s.

And cosidering that BCS is losing business at about 20% annually, it
would seem that the customer base has already lost confidence in HP. And
reading those court documents where HP decided to wilfully deceive its
own employees and customers into thinking IA64 was healthy while
planning its demise is going to be a hard job to fix for Whitman.

And if Whitman decides to ignore the issue and continue the deception,
this may really backfire and quicken customer defections.


As a new CEO who has not had her hands into those contracts, she is in
the best posistion now to come out and fess up and regain trust of
customers who would then be more likely to migrate from one EOLed
product to another HP product.

The cat is out of the bag in a way that hurts HP's credibility. That
needs to be fixed.

> Tukwila chips are quad-core today, in a 65 nm process; Poulson will be
> 8-core, and skipping the 45 nm process, be in 32 nm process (thus
> potentially much faster) and available in 2012. And Kittson will come
> out after that, followed by the successor to Kittson.

According to the court documents, Kittson will be like EV7. First batch
of chips not rated at full speed, and then sell a Kittson+ with the full
speed enabled.

And claiming a doubling of speed when you double the number of cores
basically means that the core itself isn't really improving.

Besides, since HP refused to have Tukwilla tested independently, how can
one really know the performance improvement ?

[Keith Parris]

My theory is that the value of a feature isn't recognized until you are
advanced enough that you're ready to utilize that feature. A baby must
learn to move, roll, crawl, stand, walk, and then run, in that order.
You can't go directly from crawling to running without the intervening
training stages.

As I see it, Serviceguard is about at the state TruCluster ASE was,
before the "real" TruClusters were introduced.

When a given application can only run on one node at a time in your
cluster, it's hard to see the value of a distributed lock manager. But
at that stage, you might see some value in a cluster-wide file system.
(Oracle RAC can run on multiple nodes and access the same database in a
shared manner, but it cheats by using TruCluster technology purchased
from DEC which in turn was derived from VMS Clusters.)

When your root file system can corrupt itself upon a crash, rendering
the system unbootable, as could that of HP-UX, it's hard to see the
value of the shared system root feature, where you would then have maybe
16 systems that could possibly trash your root file system if they
crashed. In that case, shared system root might even be seen as an
undesirable feature.

[GreyCloud]

VAXman- @SendSpamHere.ORG wrote:
> In article <jgp6b7$i4n$1...@usenet01.boi.hp.com>, Keith Parris <keithparris...@yahoo.com> writes:
>> On 2/5/2012 4:27 PM, ChrisQ wrote:
>>> Is veritas as good as vms clustering, or is it just smoke and mirrors
>>> from sales ?...
>> Veritas provided a cluster-wide file system.
>>
>> In addition to a cluster-wide file system, TruClusters also had a
>> connection manager and quorum scheme, a distributed lock manager, and
>> the ability to boot multiple systems from the same system disk (shared
>> root).
>
> ...and WEENDOZE provides Minesweeper and virus collection. No wonder it
> is the preferred business platform while robust operating systems are on
> the verge of being only a minor footnote in some future history book.

I really wish that HP would face reality as technology is making chips
faster and smaller. Most of the hype now is in mobile devices.
As this technology improves, the older oses are being marginalized.

[MG]

On 7-2-2012 0:30, GreyCloud wrote:
> I really wish that HP would face reality as technology is making chips
> faster and smaller. Most of the hype now is in mobile devices.
> As this technology improves, the older oses are being marginalized.

How should I interpret this: You yourself would consider running
mission critical, disaster-proof, applications off one or more
smartphones...?

Also, what do you mean by "older OSes": Aren't both iOS and Android
derivatives of the UNIX operating system from 1969?

- MG

[Arne Vajhøj]

Android is Linux not Unix.

If you login and work interactively in a shell the difference is
not big, but the kernel is different. And Android is the
Linux kernel and not all the user mode stuff.

Arne

[Arne Vajhøj]

On 2/6/2012 3:39 PM, Phillip Helbig---undress to reply wrote:
> In article<ffDXq.27180$M05....@newsfe20.ams2>, ChrisQ
> <me...@devnull.com> writes:
>> They probably couldn't use it as is, since much of it would been
>> written in bliss ?.
>
> Bliss was ported when Rdb (also written in Bliss) ran on some non-VMS
> system, so that is not a big show stopper.

Bliss did run on x86.

But we would need it to run on x86-64.

And there is still Macro-32.

Arne

[Arne Vajhøj]

On 2/6/2012 3:39 PM, Phillip Helbig---undress to reply wrote:

Almost any OS, any database and any app server offer
clustering today.

> Ditto for HBVS.

Hardware mirror is more popular than software mirror, but it
is widely available as separate module and it is an integrated
part of modern file systems.

Arne

[Arne Vajhøj]

DLM and quorum is standard technology today.

Sometimes build into the OS kernel.

Sometimes in user mode.

(and it is far from obvious that having it in kernel
mode instead of user mode is important)

Arne

[Arne Vajhøj]

On 2/6/2012 5:29 PM, JF Mezei wrote:
> back in the late 1980s, performance was a big issue because companies
> could use all the cpu they could get.
>
> in today's business environment, is that still the case ?

Depends a lot on what business you are in.

If you have an app that basically doing what the same app
did in the 1980s, then it is most likely not CPU bound.

But people have found new ways to burn CPU cycles.

Arne

[Arne Vajhøj]

On 2/6/2012 5:55 PM, Keith Parris wrote:
> On 2/6/2012 3:29 PM, JF Mezei wrote:
>> back in the late 1980s, performance was a big issue because companies
>> could use all the cpu they could get.
>>
>> in today's business environment, is that still the case ?
>
> Some customers need all the CPU they can get, but for most OpenVMS
> customers, plenty of CPU power is available, at economical prices.

> So I don't expect customers to migrate away from Itanium because
> of insufficient performance.

I think you are right.

VMS apps are typical older apps that is not getting totally
rewritten. That is in general pretty bad, but in the CPU power
context it is actuyally good. The need for CPU power will only
grow natural with the company revenue. And Itanium can handle
that for many years to come.

Arne

[Arne Vajhøj]

On 2/6/2012 6:00 PM, Jan-Erik Soderholm wrote:
> JF Mezei wrote 2012-02-06 23:29:
>> back in the late 1980s, performance was a big issue because companies
>> could use all the cpu they could get.
>>
>> in today's business environment, is that still the case ?
>
> We run a factory/production management system on a 666 MHz
> single CPU, single core AlphaServer DS20e. 130 VT-term users
> logged in daytime. A bunch of barcode scanners, PLCs and label
> printers connected. Runs at a mean of 5-10% CPU. 4 GB mem of
> which 2 GB is used by XQP and 0.5 GB by Rdb Glob-buffers.
>
> The smallest Itanium today is 2 CPU @ 4 core each (right?). At
> something around 1.5 Ghz, if I'm not wrong. That is aprox 20
> times the raw CPU performance of our current server.
>
> What is it that needs all this raw CPU horsepower ?

Not everybody is running your type of app.

#1 system on the Top500 list has 705024 CPU cores.

Google is expected to have around 1 million servers.

Some people do need power.

> A lot of Java? :-) Or any other lousy written code?
>
> *I* don't know.

The idea that JIT was slower than AOT was generally dropped
in the late 1990's.

Arne