....will HP finally announce the EOL of Itanic?

https://www.zdnet.com/blog/howlett/hp-superdome-dead-as-a-dodo/4194?tag=nl.e539 

On 6/6/2012 10:10 AM, John Smith (who cares if I'm the one @ HP - if 
here's even still there) wrote:
> ...will HP finally announce the EOL of Itanic?
>
> https://www.zdnet.com/blog/howlett/hp-superdome-dead-as-a-dodo/4194?tag=nl.e539

It's a little early to predict the outcome of the trial, I'd say.

Press reports say �Intel executive Kirk Skaugen � testified that the 
amended agreement between Intel and HP gave it access to the Itanium 
microprocessor through 2022, and that HP could extend it even longer.� 
-- 
http://www.ocpol.com/hp-seeks-pretrial-ruling-in-itanium-lawsuit-against-oracle-spun1_1059.html

So that means Itanium chips are available to HP through at least 2022, 
and HP has the option to extend availability even longer.

That's twice as long as the 5-year chip roadmaps from the competition.

In article <jqo20f$cbk$1@usenet01.boi.hp.com>, Keith Parris
<keithparris_deletethis@yahoo.com> writes:
> 
> It's a little early to predict the outcome of the trial, I'd say.
> 
> Press reports say �Intel executive Kirk Skaugen � testified that the 
> amended agreement between Intel and HP gave it access to the Itanium 
> microprocessor through 2022, and that HP could extend it even longer.� 
> -- 
>
http://www.ocpol.com/hp-seeks-pretrial-ruling-in-itanium-lawsuit-against-oracle-
-spun1_1059.html
> 
> So that means Itanium chips are available to HP through at least 2022, 
> and HP has the option to extend availability even longer.
> 
> That's twice as long as the 5-year chip roadmaps from the competition.
> 

Availability of what? Current Itanics?
Try to build a competitive system with them ten years down the road.

In article <ShLzr.21229$FL5.19664@newsfe03.iad>, "John Smith \(who cares
if I'm the one @ HP - if here's even still there\)" <a@nonymous.com>
writes: 

> ....will HP finally announce the EOL of Itanic?
> 
> https://www.zdnet.com/blog/howlett/hp-superdome-dead-as-a-dodo/4194?tag=nl.e539 

zdnet?  This is where the "Xetra runs on Linux" stuff came from,
debunked here a few days ago.  COMPLETELY AND UTTERLY WRONG.  You're
probably better off believing the opposite of what these clowns write. 

On 6/6/2012 11:49 AM, Phillip Helbig---undress to reply wrote:
> zdnet?  This is where the "Xetra runs on Linux" stuff came from,

Here's are some other reports of the testimony of Intel's Kirk Skaugen 
that Intel is under contract to develop Itanium until at least 2022:

PC World: 
http://www.pcworld.com/article/252636/hp_seeks_pretrial_ruling_in_itanium_lawsuit_against_oracle.html

"Intel executive Kirk Skaugen is said to have testified that the amended 
agreement between Intel and HP gave it access to the Itanium 
microprocessor through 2022, and that HP could extend it even longer."

http://www.ocpol.com/hp-seeks-pretrial-ruling-in-itanium-lawsuit-against-oracle-spun1_1059.html

The Inquirer: 
http://www.theinquirer.net/inquirer/news/2170327/hp-force-intel-develop-itanium-2022

On 6/6/2012 11:16 AM, Michael Kraemer wrote:
> In article<jqo20f$cbk$1@usenet01.boi.hp.com>, Keith Parris
> <keithparris_deletethis@yahoo.com>  writes:
>> So that means Itanium chips are available to HP through at least 2022,
>> and HP has the option to extend availability even longer.
>>
>> That's twice as long as the 5-year chip roadmaps from the competition.
>
> Availability of what? Current Itanics?
> Try to build a competitive system with them ten years down the road.

The current Itanium chip is Tukwila, in 65 nm process and with 4 cores. 
Poulson is due out in systems in 2012, in 32 nm process with 8 cores.

The Intel public roadmap shows Poulson and Kittson generations. 
Documents released by Oracle also speak of a Kittson22, beyond the 
public roadmap.

"Keith Parris" <keithparris_deletethis@yahoo.com> wrote in message 
news:jqo20f$cbk$1@usenet01.boi.hp.com...
> On 6/6/2012 10:10 AM, John Smith (who cares if I'm the one @ HP - if 
> here's even still there) wrote:
>> ...will HP finally announce the EOL of Itanic?
>>
>> https://www.zdnet.com/blog/howlett/hp-superdome-dead-as-a-dodo/4194?tag=nl.e539
>
> It's a little early to predict the outcome of the trial, I'd say.
>
> Press reports say �Intel executive Kirk Skaugen � testified that the 
> amended agreement between Intel and HP gave it access to the Itanium 
> microprocessor through 2022, and that HP could extend it even longer.� -- 
> http://www.ocpol.com/hp-seeks-pretrial-ruling-in-itanium-lawsuit-against-oracle-spun1_1059.html
>
> So that means Itanium chips are available to HP through at least 2022, and 
> HP has the option to extend availability even longer.
>
> That's twice as long as the 5-year chip roadmaps from the competition.
>

Excellent - We'll be able to run outdated, featureless versions of Oracle on 
VMS till 2022. Thanks Keith! 

On Jun 6, 2:04=A0pm, Keith Parris <keithparris_deletet...@yahoo.com>
wrote:
> On 6/6/2012 11:49 AM, Phillip Helbig---undress to reply wrote:
>
> > zdnet? =A0This is where the "Xetra runs on Linux" stuff came from,
>
> Here's are some other reports of the testimony of Intel's Kirk Skaugen
> that Intel is under contract to develop Itanium until at least 2022:
>
> PC World:http://www.pcworld.com/article/252636/hp_seeks_pretrial_ruling_i=
n_ita...
>
> "Intel executive Kirk Skaugen is said to have testified that the amended
> agreement between Intel and HP gave it access to the Itanium
> microprocessor through 2022, and that HP could extend it even longer."
>
> http://www.ocpol.com/hp-seeks-pretrial-ruling-in-itanium-lawsuit-agai...
>
> The Inquirer:http://www.theinquirer.net/inquirer/news/2170327/hp-force-in=
tel-devel...

At trial, mention by HP against Oracle concerning an apparent
agreement from Oracle to support Itaniums that it broke with its
announcements. No time to peruse so submitted cold.  Reported they
want either a court order forcing Oracle to resume "support" plus
penalties, or major ($4B+) compensatory damages.

http://www.bbc.com/news/technology-18329969
http://www.businessweek.com/news/2012-06-05/hp-s-livermore-was-furious-at-o=
racle-over-itanium-announcement

On 6/6/2012 3:55 PM, Richard Maher wrote:
> "Keith Parris"<keithparris_deletethis@yahoo.com>  wrote in message
> news:jqo20f$cbk$1@usenet01.boi.hp.com...
>> So that means Itanium chips are available to HP through at least 2022, and
>> HP has the option to extend availability even longer.
>
> Excellent - We'll be able to run outdated, featureless versions of Oracle on
> VMS till 2022. Thanks Keith!

And HP always officially supports hardware for a minimum of 5 years 
after last sale. That takes you out to at least 2027. HP often provides 
support for even longer.

I expect the Open Source movement will have delivered a well-deserved 
cleaning to Oracle's clock, so to speak, long before then.

If you run (and pay the exorbitant prices for) Oracle today, you should 
seriously look at EnterpriseDB, PostgreSQL and the other alternatives.

> If you run (and pay the exorbitant prices for)
> Oracle today, you should seriously look at 
> EnterpriseDB, PostgreSQL and the other
> alternatives. 

I'll second that!  But if you get away from 
oracle, then chances are good that you got 
away from VMS, HP and Itanium too. 

HP would be better off selling things like VMS
and buying big data startups. But I bet Oracle
beats them to it. 

EJ

Keith Parris schrieb:
> On 6/6/2012 11:16 AM, Michael Kraemer wrote:
> 
>> In article<jqo20f$cbk$1@usenet01.boi.hp.com>, Keith Parris
>> <keithparris_deletethis@yahoo.com>  writes:
>>
>>> So that means Itanium chips are available to HP through at least 2022,
>>> and HP has the option to extend availability even longer.
>>>
>>> That's twice as long as the 5-year chip roadmaps from the competition.
>>
>>
>> Availability of what? Current Itanics?
>> Try to build a competitive system with them ten years down the road.
> 
> 
> The current Itanium chip is Tukwila, in 65 nm process and with 4 cores. 

According to those reports that intel rep gave the typical answer
of a politician caught in the act:
just admit/concede what's obvious anyway.
Of course it's not a big deal to vaguely
promise "access" to Itanic chips:
Produce a few extra Tukwilas, put them on the shelf and undust
them whenever HP want some.
But somehow I doubt that this is the kind of "committment"
people here (and Oracle) want to hear.

> Poulson is due out in systems in 2012, in 32 nm process with 8 cores.
> 
> The Intel public roadmap shows Poulson and Kittson generations. 
> Documents released by Oracle also speak of a Kittson22, beyond the 
> public roadmap.

Roadmaps just don't mean a damn, especially when coming from HP/intel.
Iirc Tukwila originally was due 2006/2007 and appeared 2010,
Poulson due 2009 and may (or may not) appear this year.
Instead of always promising new roadmaps, just fulfill the old ones.

Or how about an intel/HP guy standing up saying:
"point taken, we'll spent another $2B next quarter to make sure
the chip appears just in time and ahead of the Power
and x86 competition".
Actions speak more than words.
Referring to roadmaps in this situation is just - lame.

Keith Parris schrieb:

> And HP always officially supports hardware for a minimum of 5 years 
> after last sale. That takes you out to at least 2027. HP often provides 
> support for even longer.

Will HP ever get it?
People aren't asking for mere "support" of legacy Itanics,
they want shiny new ones, in due time and with
enough horse power to "blow x86 and Power out of the water".
Unless intel/HP are willing/able to deliver,
Oracle rightfully stop their development.
Why should they code for a lame chip?

> I expect the Open Source movement will have delivered a well-deserved 
> cleaning to Oracle's clock, so to speak, long before then.

Sounds a bit like "I'll call my big brother, he'll bash you".
What has the Open Source movement to do with intel/HPs
inability to deliver performant hardware in due time?

> If you run (and pay the exorbitant prices for) Oracle today, you should 
> seriously look at EnterpriseDB, PostgreSQL and the other alternatives.
> 

Rich Jordan schrieb:

> At trial, mention by HP against Oracle concerning an apparent
> agreement from Oracle to support Itaniums that it broke with its
> announcements. No time to peruse so submitted cold.  Reported they
> want either a court order forcing Oracle to resume "support" plus
> penalties, or major ($4B+) compensatory damages.

Well, if this means "support" of the same kind intel/HP offer
for their hardware, that shouldn't be much of a problem.
Promise availability of a dated Oracle 11-something for Itanics
for the next 10 years, publish some roadmaps that may or
may not be kept, generously deliver minor upgrades three or four
years after due time. Meanwhile, x86, Power, Sparc, etc
get Oracle-12, -13 and so forth in regular intervals.
Is this what HP wants Oracle to force into?

On 7-6-2012 1:36, Michael Kraemer wrote:
             ^^^^
> [...]


On 7-6-2012 1:50, Michael Kraemer wrote:
             ^^^^
> [...]

On 7-6-2012 2:45, Michael Kraemer wrote:
             ^^^^
> [...]

(In need of a new hobby?)


> Why should they code for a lame chip?

Why do you care?  The status quo seems to suit you just
fine, as it's good for some nocturnal (s)trolling around
on the Usenet, isn't it?

  - MG

"Keith Parris" <keithparris_deletethis@yahoo.com> wrote in message 
news:jqom20$av2$1@usenet01.boi.hp.com...
> On 6/6/2012 3:55 PM, Richard Maher wrote:
>> "Keith Parris"<keithparris_deletethis@yahoo.com>  wrote in message
>> news:jqo20f$cbk$1@usenet01.boi.hp.com...
>>> So that means Itanium chips are available to HP through at least 2022, 
>>> and
>>> HP has the option to extend availability even longer.
>>
>> Excellent - We'll be able to run outdated, featureless versions of Oracle 
>> on
>> VMS till 2022. Thanks Keith!
>
> And HP always officially supports hardware for a minimum of 5 years after 
> last sale. That takes you out to at least 2027. HP often provides support 
> for even longer.
>
> I expect the Open Source movement will have delivered a well-deserved 
> cleaning to Oracle's clock, so to speak, long before then.
>
> If you run (and pay the exorbitant prices for) Oracle today, you should 
> seriously look at EnterpriseDB, PostgreSQL and the other alternatives.

Well done Kerry/Keith, "If you pay exorbidant prices for VMS you should 
seriously look at Linux" with current versions of Oracle SAP, etc. Makes 
perfect sense :-( Please say you're not still on the HP/VMS Payroll!

Regards Richard Maher
> 

> "Keith Parris"<keithparris_deletethis@yahoo.com>  wrote in message
> news:jqom20$av2$1@usenet01.boi.hp.com...
>> On 6/6/2012 3:55 PM, Richard Maher wrote:
>>> "Keith Parris"<keithparris_deletethis@yahoo.com>   wrote in message
>>> news:jqo20f$cbk$1@usenet01.boi.hp.com...
>>>> So that means Itanium chips are available to HP through at least 2022,
>>>> and
>>>> HP has the option to extend availability even longer.
>>>
>>> Excellent - We'll be able to run outdated, featureless versions of Oracle
>>> on
>>> VMS till 2022. Thanks Keith!
>>
>> And HP always officially supports hardware for a minimum of 5 years after
>> last sale. That takes you out to at least 2027. HP often provides support
>> for even longer.
>>
>> I expect the Open Source movement will have delivered a well-deserved
>> cleaning to Oracle's clock, so to speak, long before then.
>>
>> If you run (and pay the exorbitant prices for) Oracle today, you should
>> seriously look at EnterpriseDB, PostgreSQL and the other alternatives.
>

VMS without Rdb isn't the VMS I love.
Rdb in itself is one of the major pros for VMS...

Jan-Erik.

"Jan-Erik Soderholm" <jan-erik.soderholm@telia.com> wrote in message 
news:jqq9sc$vd5$2@news.albasani.net...
>> "Keith Parris"<keithparris_deletethis@yahoo.com>  wrote in message
>> news:jqom20$av2$1@usenet01.boi.hp.com...
>>> On 6/6/2012 3:55 PM, Richard Maher wrote:
>>>> "Keith Parris"<keithparris_deletethis@yahoo.com>   wrote in message
>>>> news:jqo20f$cbk$1@usenet01.boi.hp.com...
>>>>> So that means Itanium chips are available to HP through at least 2022,
>>>>> and
>>>>> HP has the option to extend availability even longer.
>>>>
>>>> Excellent - We'll be able to run outdated, featureless versions of 
>>>> Oracle
>>>> on
>>>> VMS till 2022. Thanks Keith!
>>>
>>> And HP always officially supports hardware for a minimum of 5 years 
>>> after
>>> last sale. That takes you out to at least 2027. HP often provides 
>>> support
>>> for even longer.
>>>
>>> I expect the Open Source movement will have delivered a well-deserved
>>> cleaning to Oracle's clock, so to speak, long before then.
>>>
>>> If you run (and pay the exorbitant prices for) Oracle today, you should
>>> seriously look at EnterpriseDB, PostgreSQL and the other alternatives.
>>
>
> VMS without Rdb isn't the VMS I love.
> Rdb in itself is one of the major pros for VMS...

Yes and clustering, and reliability, and everything else most VMS customers 
willingly pay a premium for. Oracle 11g was also something they expect(ed)
>
> Jan-Erik.

Cheers Richard Maher 

> It's a little early to predict the outcome=20
> of the trial, I'd say.=20


There's a range of outcomes for HP.=A0
Most of them don't look good to me.=A0

The court could rule in Oracles favor=A0
and just throw out the lawsuit. That
seems likely as I highly doubt there=A0
is any real contract binding Oracle
to HP. If HP had asked for such a=A0
commitment it would have more=A0
openly=A0exposed their weakness and
HP would be smart enough to see
that and not put that in a contract.=A0

In a way, Oracle doesn't need that
outcome. At least not yet. Oracle
gets a ton of value by dragging this
case on and on. =A0The longer it takes
the more damage there is to the
"franchise" value of it all. HP is
really stuck. They can't sell it until
the case is done. HP's strategic
decision making with this asset=A0
is tied up until the end. Also oracle
is forcing HP to spend relationship
karma with Intel. HP can't drag=A0
intel too much in this mess.=A0

Which takes me to the next thought.=A0
Oracle can actually wring more
upside out of it if they "lose" this
round in the court. They will gladly=A0
appeal the outcome and pull HP back
into it again and waste more of=A0
their time.=A0

If HP wins some form of damages
I'm sure that will be appealed and
delayed. And even then this would
be a hollow victory. =A0HP is stuck
with a busted asset and the big bully
didn't have to fix it. =A0

Or Oracle could be told to play nice=A0
But we all know this game. Promise=A0
roadmaps, give the next "release"
a higher version number, fall behind
but still deliver eventually and you
can just get by. =A0We've seen this
movie before and we know how it
ends.=A0

The court sure as heck won't get=A0
in the game of mandating items
of delivery. So I don't think that
outcome is likely. =A0At best HP
gets some cash. But that implies
a breach of contract which seems
super unlikely as Oracle seems
like a place that wouldnt agree
to such terms.=A0

In any outcome, I don't see how=A0
HP walks away with anything of
real shareholder value.=A0

EJ

johnson.eric@gmail.com wrote:
>> It's a little early to predict the outcome 
>> of the trial, I'd say. 
> 
> 
> There's a range of outcomes for HP. 
> Most of them don't look good to me. 
> 
> The court could rule in Oracles favor 
> and just throw out the lawsuit. That
> seems likely as I highly doubt there 
> is any real contract binding Oracle
> to HP. If HP had asked for such a 
> commitment it would have more 
> openly exposed their weakness and
> HP would be smart enough to see
> that and not put that in a contract. 
> 
> In a way, Oracle doesn't need that
> outcome. At least not yet. Oracle
> gets a ton of value by dragging this
> case on and on.  The longer it takes
> the more damage there is to the
> "franchise" value of it all. HP is
> really stuck. They can't sell it until
> the case is done. HP's strategic
> decision making with this asset 
> is tied up until the end. Also oracle
> is forcing HP to spend relationship
> karma with Intel. HP can't drag 
> intel too much in this mess. 
> 
> Which takes me to the next thought. 
> Oracle can actually wring more
> upside out of it if they "lose" this
> round in the court. They will gladly 
> appeal the outcome and pull HP back
> into it again and waste more of 
> their time. 
> 
> If HP wins some form of damages
> I'm sure that will be appealed and
> delayed. And even then this would
> be a hollow victory.  HP is stuck
> with a busted asset and the big bully
> didn't have to fix it.  
> 
> Or Oracle could be told to play nice 
> But we all know this game. Promise 
> roadmaps, give the next "release"
> a higher version number, fall behind
> but still deliver eventually and you
> can just get by.  We've seen this
> movie before and we know how it
> ends. 
> 
> The court sure as heck won't get 
> in the game of mandating items
> of delivery. So I don't think that
> outcome is likely.  At best HP
> gets some cash. But that implies
> a breach of contract which seems
> super unlikely as Oracle seems
> like a place that wouldnt agree
> to such terms. 
> 
> In any outcome, I don't see how 
> HP walks away with anything of
> real shareholder value. 
> 
> EJ

Yeah, it's real hard to imagine any up-side for HP.  Win or lose, they lose where it 
counts.  If some customers value the Oracle software above anything else, then they will 
not be running HP gear.

Actually, I can imagine one possible thing that could be good for HP, if HP was smart 
enough to realize it, which I doubt they are.  Oracle would give HP RDB to have the suit 
settled.  HP could then get their customers to use RDB instead of Oracle.  Of course 
they'd have to make sure that the product had everything customers need, but that takes 
development dollars, and we sort of got an idea what HP thinks of that idea.

David Froble schrieb:

> Yeah, it's real hard to imagine any up-side for HP.  Win or lose, they 
> lose where it counts.  If some customers value the Oracle software above 
> anything else, then they will not be running HP gear.

Often enough the Oracle DB and the rest of IT (e.g. SAP)
are so entangled,
that customers will prefer to dump the underlying platform
and switch to an OS on which the DB is still supported.
This also precludes Open Source as being the saviour.
Oracle and SAP are the raison d'etre for BCS's gear.
Maybe this is the reason why HP tries so desperately to "win" the case.

Michael Kraemer wrote:
> David Froble schrieb:
> 
>> Yeah, it's real hard to imagine any up-side for HP.  Win or lose, they 
>> lose where it counts.  If some customers value the Oracle software 
>> above anything else, then they will not be running HP gear.
> 
> Often enough the Oracle DB and the rest of IT (e.g. SAP)
> are so entangled,
> that customers will prefer to dump the underlying platform
> and switch to an OS on which the DB is still supported.
> This also precludes Open Source as being the saviour.
> Oracle and SAP are the raison d'etre for BCS's gear.
> Maybe this is the reason why HP tries so desperately to "win" the case.
> 

Don't get me started on SAP.  Totally worthless and stupid software.  Ugly.

But sooner or later, when someone who knows how to run a company retires or dies, some 
beancounter is put in charge, and he runs to his buddies at the big accounting firms for 
advice, and their advice is to put in SAP so that they can sell their very high priced 
"SAP consultants" to the company and suck up all their money.

I've heard many stories of SAP failures and almost ruining a company.

The purpose of SAP is not to help run your business, the purpose of SAP is to suck as much 
money from your company as possible.

On 6/7/2012 5:35 PM, David Froble wrot
> If some customers value the Oracle software above
> anything else, then they will not be running HP gear.

They aren't forced to go to AIX or Solaris. They could always choose to 
run Oracle on HP Proliant hardware under Linux.

Keith Parris wrote:
> On 6/7/2012 5:35 PM, David Froble wrot
>> If some customers value the Oracle software above
>> anything else, then they will not be running HP gear.
> 
> They aren't forced to go to AIX or Solaris. They could always choose to 
> run Oracle on HP Proliant hardware under Linux.

Well, yes Keith, there are total idiots in this world.

Maybe some masochists that enjoy pain and suffering.

But a few of us still have 1/4 a brain, and if you bend me over and buttf..k me, I'm 
perhaps not going to give you more chances.

I'm still here because my software won't run anywhere else.  If HP would cause my software 
to become totally worthless and unusable, and if I have to start over, don't you think I'm 
going to attempt to avoid the same thing happening again?  Perhaps there aren't 100% 
guarantees anywhere, but the way HP is currently screwing up continuously, and the antics 
of the board, and their sharply declining revenue in BCS, I think most people taking a 
fresh look might consider HP a rather poor choice.  If they have screwed their customers 
(even if inherited from DEC) once (or more), then shouldn't I expect them to do it again?

Let's try it this way Keith.  Say it was your (rather substantial) money that was to fund 
a new product, which might decide whether you're going to live well, or in the poor house. 
  Say that you're starting with a totally clean sheet of paper.  Now tell me where IBM 
would be on your list of prospective vendors, and where HP would be on your list of 
prospective vendors?

You're a good company man Keith.  I applaud your loyalty.  But some things just aren't 
reasonable and / or feasible.  One of the reasons VMS is claimed to be dying is because 
it's not being fed.

Where is IPSEC in HP TCP/IP on VMS?
Where is a decent version of SSL on VMS?
Where are the many things that are appearing in other environments but not VMS?

You know this could be a long list, but why bother, the list isn't the issue. The issue is 
HP's commitment to a future for VMS.

Keith Parris wrote:

> Press reports say �Intel executive Kirk Skaugen � testified that the 
> amended agreement between Intel and HP gave it access to the Itanium 
> microprocessor through 2022, and that HP could extend it even longer.� 


Shareholders will not tolerate HP continue to sink moey into that IA64
thing when customers are leaving it in droves.

The fact that HP agreed to slow down development to space the remaining
2 generations means that IA64 will not be competitive with each of those
2 generations.

Your boss, Whitman admitted to press analysts that there was nothing
that could be done to fix BCS and that HP was pinning its hopes on the
new project Odyssey that will run Linux and Windows.

So HP has realised that with IA64 sales dropping like a brick, they
probably have to accelerate Oddyssey to market as fast as they can to be
able to offer a migration to the deffecting customers.

Phillip Helbig---undress to reply wrote:

> zdnet?  This is where the "Xetra runs on Linux" stuff came from,
> debunked here a few days ago.  COMPLETELY AND UTTERLY WRONG.  You're
> probably better off believing the opposite of what these clowns write. 


But what the media says is important because it shapes the opinions of
CIOs and CEOs and CFOs who make the iportant platform decisions.

Keith Parris wrote:

> "Intel executive Kirk Skaugen is said to have testified that the amended 
> agreement between Intel and HP gave it access to the Itanium 
> microprocessor through 2022, and that HP could extend it even longer."


Why didn't HP publicly brag about IA64 being garanteed until at least
2022 ?????

"access to Itanium" does not mean "continued devevelopment and production".

It could simply be access to the IP in case HP wanted to become a chip
company again.

What is important what the contract says about development and chip
production.


Legal contract generally do not use vague words such as "access to
Itanium" unless there is a paragrpah afterwards which defines what
"access to Itanium" means.

If HP is to send 600 million bucks to Intel, you can bet that the
contract will have very precise wording.

David Froble wrote:

> Yeah, it's real hard to imagine any up-side for HP.  Win or lose, they lose where it 
> counts.  If some customers value the Oracle software above anything else, then they will 
> not be running HP gear.


I think the damage has already been done. The image of Itanium is
stained especially since HP didn't/couldn't do much to counter Oracle's
attacks because it knew very well that Oracle was right.

The image of HP-UX is stained because of the lack of Oracle.  My guess
is that if Oracle is forced to come back, HP-UX will get the same amount
of Oracle as VMS does... just the DB engine and no apps.

JF Mezei wrote:
> Keith Parris wrote:
> 
>> Press reports say �Intel executive Kirk Skaugen � testified that the 
>> amended agreement between Intel and HP gave it access to the Itanium 
>> microprocessor through 2022, and that HP could extend it even longer.� 
> 
> 
> Shareholders will not tolerate HP continue to sink moey into that IA64
> thing when customers are leaving it in droves.
> 
> The fact that HP agreed to slow down development to space the remaining
> 2 generations means that IA64 will not be competitive with each of those
> 2 generations.
> 
> Your boss, Whitman admitted to press analysts that there was nothing
> that could be done to fix BCS and that HP was pinning its hopes on the
> new project Odyssey that will run Linux and Windows.
> 
> So HP has realised that with IA64 sales dropping like a brick, they
> probably have to accelerate Oddyssey to market as fast as they can to be
> able to offer a migration to the deffecting customers.
> 

Ya know, I really do not understand this Odyssey thingy.  In the past, anyone who could 
easily leave VMS, and could accept the new environment, whatever it was, is most likely 
already gone.  Some, I don't know how many, cannot move to weendoze or any Unix/Linux.  So 
for them, what the hell good is round 2, or 3, or whatever, of trying to get these people 
to move to something that will not do the job for them, for whatever reasons.

As I've wrote before, the applications I'm working with will not move off VMS.  No way, no 
how.  So, if there is no future for VMS, then there is no future for my applications, and 
that will mean starting over from scratch.  Without some overwhelming reason, and I doubt 
there will be one, does anyone with a fraction of a brain think that I'm going to come 
near the entity that caused me all my problems with a thousand mile pole?

So JF, while you claim to see fleeing customers, I see customers that given half a chance 
will be the most loyal HP has.  Not because they like HP, but because they NEED VMS.  The 
question then is, will HP blow off their potentially best customers?

My perspective is, give the customers a chance, such as VMS on x86 and continuing 
development, and HP will have customers as long as x86 is a viable CPU.  Even then, 
anything that replaces x86 will most likely have an easy upgrade path, if it wants to be 
successful.

Thing is, whether HP has the people who could actually do the job, is a rather big question.

JF Mezei wrote:
> Phillip Helbig---undress to reply wrote:
> 
>> zdnet?  This is where the "Xetra runs on Linux" stuff came from,
>> debunked here a few days ago.  COMPLETELY AND UTTERLY WRONG.  You're
>> probably better off believing the opposite of what these clowns write. 
> 
> 
> But what the media says is important because it shapes the opinions of
> CIOs and CEOs and CFOs who make the iportant platform decisions.
> 

And isn't that a particularly stupid thing ....

On Wed, 06 Jun 2012 16:40:35 -0600, Keith Parris wrote:

> On 6/6/2012 3:55 PM, Richard Maher wrote:
>> "Keith Parris"<keithparris_deletethis@yahoo.com>  wrote in message
>> news:jqo20f$cbk$1@usenet01.boi.hp.com...
>>> So that means Itanium chips are available to HP through at least 2022,
>>> and HP has the option to extend availability even longer.
>>
>> Excellent - We'll be able to run outdated, featureless versions of
>> Oracle on VMS till 2022. Thanks Keith!
> 
> And HP always officially supports hardware for a minimum of 5 years
> after last sale. That takes you out to at least 2027. HP often provides
> support for even longer.

Are you sure you meant 2027 rather than 2017?

 
> I expect the Open Source movement will have delivered a well-deserved
> cleaning to Oracle's clock, so to speak, long before then.
> 
> If you run (and pay the exorbitant prices for) Oracle today, you should
> seriously look at EnterpriseDB, PostgreSQL and the other alternatives.

But what for the desktop?  The majority of the open source movement seems 
to be involved in giving us increasingly unfriendly gizmos and "cool 
effect" without regard to functionality.

-- 
Paul Sture

Aehm, I think that at least for hp-ux, there are alternatives to Oracle... 
as in quicker , less resource intensive , and with the same performance if 
not higher...


"JF Mezei" <jfmezei.spamnot@vaxination.ca> ha scritto nel messaggio 
news:4fd2b4ee$0$2322$c3e8da3$c8b7d2e6@news.astraweb.com...
> David Froble wrote:
>
>> Yeah, it's real hard to imagine any up-side for HP.  Win or lose, they 
>> lose where it
>> counts.  If some customers value the Oracle software above anything else, 
>> then they will
>> not be running HP gear.
>
>
> I think the damage has already been done. The image of Itanium is
> stained especially since HP didn't/couldn't do much to counter Oracle's
> attacks because it knew very well that Oracle was right.
>
> The image of HP-UX is stained because of the lack of Oracle.  My guess
> is that if Oracle is forced to come back, HP-UX will get the same amount
> of Oracle as VMS does... just the DB engine and no apps. 

David Froble wrote:

> So JF, while you claim to see fleeing customers, I see customers that given half a chance 
> will be the most loyal HP has.  

HP's management are printer and wintel oriented. They don't like this
loyalty to an OS because they are stuck with these products they don't
want. They also see the server market as commodity running either wintel
or linux. And let's face it, there are more applications available on
Linux than on VMS.

Hey, HP won't cause your VMS machine to suddently stop. You can buy the
last IA64 produced and run on it for a decade or two, like people have
done for VAX.

As sales and BCS revenues continue to drop, the cost of continued IA64
development have or will become greater than revenues.

Continued IA64 production of Kittson for a decade is akin to producing
VAXes based on 1992 technology today.

> My perspective is, give the customers a chance, such as VMS on x86 and continuing 
> development,

That would be the nice thing to do as HP terminates IA64. But HP did
have a pilot to test portability to x86 and it stopped it because costs
were too great. What is not sure is whether this was just based on
porting HP-UX or whether each of the OS had its own separate evaluation.

I would think that porting VMS to x86 would be simpler than HP-UX, in
part due to endianness compatibility.

The bean counters at HP look at revenue potential and costs of porting
and say "no way Jos�"


> Thing is, whether HP has the people who could actually do the job, is a rather big question.

Hoff could port VMS in a couple of days :-)  But without FredK, writung
the video drivers would b tough.


I'd be interested in knowing how hard it would reall be to port the very
early stages of VMS. Since one can get EFI based 8086, wouldn't the
early modules susch as the initial loader and sysboot be much easier to
port than the port from vax to alpha and alpha to ia64 which didn't have
a common boot firmware ?

JF Mezei wrote 2012-06-09 18:13:
> David Froble wrote:
>
>> So JF, while you claim to see fleeing customers, I see customers that given half a chance
>> will be the most loyal HP has.
>
> HP's management are printer and wintel oriented. They don't like this
> loyalty to an OS because they are stuck with these products they don't
> want. They also see the server market as commodity running either wintel
> or linux. And let's face it, there are more applications available on
> Linux than on VMS.
>
> Hey, HP won't cause your VMS machine to suddently stop. You can buy the
> last IA64 produced and run on it for a decade or two, like people have
> done for VAX.
>
> As sales and BCS revenues continue to drop, the cost of continued IA64
> development have or will become greater than revenues.
>
> Continued IA64 production of Kittson for a decade is akin to producing
> VAXes based on 1992 technology today.
>
>> My perspective is, give the customers a chance, such as VMS on x86 and continuing
>> development,
>
> That would be the nice thing to do as HP terminates IA64. But HP did
> have a pilot to test portability to x86 and it stopped it because costs
> were too great. What is not sure is whether this was just based on
> porting HP-UX or whether each of the OS had its own separate evaluation.
>
> I would think that porting VMS to x86 would be simpler than HP-UX, in
> part due to endianness compatibility.
>
> The bean counters at HP look at revenue potential and costs of porting
> and say "no way Jos�"
>
>
>> Thing is, whether HP has the people who could actually do the job, is a rather big question.
>
> Hoff could port VMS in a couple of days :-)  But without FredK, writung
> the video drivers...

Which very few real (not hobbyist) users realy need anyway.
Few VMS professional apps uses native graphics. And any
new graphic interfaces are better built using browsers
running on any of the common/popular desktop environments.

Jan-Erik Soderholm wrote:
> JF Mezei wrote 2012-06-09 18:13:
>> David Froble wrote:
>>
>>> So JF, while you claim to see fleeing customers, I see customers that 
>>> given half a chance
>>> will be the most loyal HP has.
>>
>> HP's management are printer and wintel oriented. They don't like this
>> loyalty to an OS because they are stuck with these products they don't
>> want. They also see the server market as commodity running either wintel
>> or linux. And let's face it, there are more applications available on
>> Linux than on VMS.
>>
>> Hey, HP won't cause your VMS machine to suddently stop. You can buy the
>> last IA64 produced and run on it for a decade or two, like people have
>> done for VAX.
>>
>> As sales and BCS revenues continue to drop, the cost of continued IA64
>> development have or will become greater than revenues.
>>
>> Continued IA64 production of Kittson for a decade is akin to producing
>> VAXes based on 1992 technology today.
>>
>>> My perspective is, give the customers a chance, such as VMS on x86 
>>> and continuing
>>> development,
>>
>> That would be the nice thing to do as HP terminates IA64. But HP did
>> have a pilot to test portability to x86 and it stopped it because costs
>> were too great. What is not sure is whether this was just based on
>> porting HP-UX or whether each of the OS had its own separate evaluation.
>>
>> I would think that porting VMS to x86 would be simpler than HP-UX, in
>> part due to endianness compatibility.
>>
>> The bean counters at HP look at revenue potential and costs of porting
>> and say "no way Jos�"
>>
>>
>>> Thing is, whether HP has the people who could actually do the job, is 
>>> a rather big question.
>>
>> Hoff could port VMS in a couple of days :-)  But without FredK, writung
>> the video drivers...
> 
> Which very few real (not hobbyist) users realy need anyway.
> Few VMS professional apps uses native graphics. And any
> new graphic interfaces are better built using browsers
> running on any of the common/popular desktop environments.
> 

BINGO!  We have a winner.

I have nothing against DECwindows.  But a successful user interface must be something that 
the casual user is somewhat familiar with.  Anything else causes a need for training, and 
training doesn't produce revenue.  I think it's a safe bet to say that DECwindows is not a 
successful user interface.

I've always appreciated VMS for what I could do with it, not for a user interface, and I'm 
old enough to appreciate a command line interface.

It seems that whenever Nvidia or AMD/ATI or whoever comes out with a new video chipset, 
there is the need for compatable drivers.  These companies write the drivers for weendoze 
or they won't sell their products.  There is no economic reality for writing drivers for VMS.

I don't know anything about video drivers.  Therefore I don't know if it's feasable to 
define a generic video interface that all operating systems could support, and all video 
devices would conform to.  I'm going to guess that as new capabilities are developed, the 
generic video interface would quickly become outdated.  Also, with the competition, if a 
company saw a way to get just a bit more performance, regard of any standards, they'd do 
so.  It's a competitive world out there.

DEC used ATI, and probably other video card vendors.  You can bet they asked for the 
company to provide VMS drivers.  You can also bet they didn't like the answer they got. 
(Probably wild laughter)

When it comes to video hardware, the hardware seems to chance faster then the software can 
change.  Think about that for a while ....

David Froble wrote:

> BINGO!  We have a winner.

How many servers today in the x86 space still come with a serial port
that is usable for console work ?  Porting VMS without any video drivers
would restrict VMS to one of two servers designed to have serial line
consoles and no graphics.

FredK had provided here some very good explanations of the type of
reverse engineering work he had to do to write video drivers on VMS,
including a basic x86 emulator to execute code provided by the video
card (since it expects to be attached to an x86 box)

His expertise in the field was important and unique enough that he was
retained by HP despite the cuts. Alas, he passed away.

> I have nothing against DECwindows.

This is about providing basic console fnctionality on the screen
attached to the server (either physical, virtualised via stuff like VNC
or via KVM switches).  When VMS boots, it needs to be able to write to
the console and eventually load its own driver for it. If you want to
login in VT220 mode on the console, it needs a video driver to emulate
character cell on the console.

DECwindows is about running an application o VMS and targetting the
window onto another machine which has a display. This in iself does not
need a video driver on VMS.

In article <jr0mal$97e$1@dont-email.me>,
 David Froble <davef@tsoft-inc.com> wrote:

> I have nothing against DECwindows.

I do.  It's worthless.  Always was, and it hasn't improved any that I've 
heard.


> But a successful user interface must be something that the casual 
> user is somewhat familiar with.  Anything else causes a need for 
> training, and training doesn't produce revenue.  I think it's a safe 
> bet to say that DECwindows is not a successful user interface.

Agreed.


> It seems that whenever Nvidia or AMD/ATI or whoever comes out with a new 
> video chipset, 
> there is the need for compatable drivers.  These companies write the drivers 
> for weendoze 
> or they won't sell their products.  There is no economic reality for writing 
> drivers for VMS.

Of course not.  The OS developer should write any such.


> I don't know anything about video drivers.  Therefore I don't know if 
> it's feasable to define a generic video interface that all operating 
> systems could support, and all video devices would conform to.

My understanding is that it's long since been done by each of ATI and 
Nvidea, for their chipsets.  Newer chipsets use supersets of older 
chipsets' commands.  It's just that if you want the newer benefits, you 
have to update your drivers.


> When it comes to video hardware, the hardware seems to chance faster 
> then the software can change.  Think about that for a while ....

If HP, or whomever, adopted the standard Linux front ends, they'd be all 
set.  Those front ends have already been tuned to be Windows-like, for 
instance.

Heck, I'm going to be available as of 18 June.  If anyone's interested 
in pursuing this, let's talk.

-- 
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective

On Jun 10, 5:24=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> David Froble wrote:
> > BINGO! =A0We have a winner.
>
> How many servers today in the x86 space still come with a serial port
> that is usable for console work ? =A0Porting VMS without any video driver=
s
> would restrict VMS to one of two servers designed to have serial line
> consoles and no graphics.
>
> FredK had provided here some very good explanations of the type of
> reverse engineering work he had to do to write video drivers on VMS,
> including a basic x86 emulator to execute code provided by the video
> card (since it expects to be attached to an x86 box)
>
> His expertise in the field was important and unique enough that he was
> retained by HP despite the cuts. Alas, he passed away.
>
> > I have nothing against DECwindows.
>
> This is about providing basic console fnctionality on the screen
> attached to the server (either physical, virtualised via stuff like VNC
> or via KVM switches). =A0When VMS boots, it needs to be able to write to
> the console and eventually load its own driver for it. If you want to
> login in VT220 mode on the console, it needs a video driver to emulate
> character cell on the console.
>
> DECwindows is about running an application o VMS and targetting the
> window onto another machine which has a display. This in iself does not
> need a video driver on VMS.

A note on terminology: DECwindows doesn't touch the hardware. When the
term DECwindows is used correctly it is more like a desktop, in the
same area as CDE, KDE, GNOME, etc.

The bit that does the device independent drawing of pictures and
handling of kbd/mouse events (optionally with a network in the middle)
is the industry standard (and open source?) X11. DECwindows sits atop
X11.

Between X11 and the hardware is a layer which includes hardware-
specific device drivers.

If you've got X11 working, CDE, KDE, LXDE, etc, come (almost) for
free, nothing has to be rewritten from scratch, just maybe recompiled
and tested (though I believe modern software practices often leave the
testing part to the customer).

Now, back to your main question I want to address: "How many servers
today in the x86 space still come with a serial port
that is usable for console work "

I have read that the next generation of server OSes from MS will be
designed for running headless (ie no local kbd/mouse/monitor on the
server). This actually sounds quite sensible - why do you need a kbd/
mouse/monitor on 99% of your servers, e.g. if 99% of them are virtual?
And once you have the headless capability for the 99%, maybe the rest
don't need them either?

I don't imagine it'll be a serial console, nor do imagine it will be
an open industry-standard protocol used by MS either, but the
principle will have been established that servers can run headless
once the OS is up.

Now, what about before the OS is up, or while the OS is unusable/
corrupt or just not installed?

Who's heard of Intel vPro technologies on desktops, laptops, or
servers? (Or Intel AMT, another name for the same kind of thing).

If you deal with sensible corporate IT environments, who understand
the need for remote management even WITHOUT the OS, you might have
heard of it in the last few years. One of its features is support for
remote access to BIOS facilities, even including serial line support
of some kind (but mostly via a network that works even when the OS is
unavailable). My five year old HPQ dc7700p desktop at home has some of
this built in, as does the Dell kit at work. (Making the dc7700p NIC
work at all with Windows was an interesting exercise but that's
another story for another day). A vaguely similar offering from AMD
appears to be called SIMFIRE and is based around open royalty free
standards (DASH?) whereas vPro is Intel proprietary.

I know very little about UEFI, some Apple users may well know more,
but it'd be insane if it didn't support vPro-style capabilities in a
generic way. E.g. as described in:
http://h30565.www3.hp.com/t5/Feature-Articles/The-30-year-long-Reign-of-BIO=
S-is-Over-Why-UEFI-Will-Rock-Your/ba-p/198
(featuring extensive comments from someone well known round here).

So your decent business desktop, laptop, and server has had headless
capabilities for several years, and will continue to do so.

How hard can it be for VMS hardware and low level software to match
the important bits of that kind of capability?

I'm not sure the lack of a serial console or of low level graphics
drivers is exactly going to be a showstopper for VMS, when even
Windows-system builders are acknowledging these things may not matter
much in the bigger picture.

John Wallace wrote 2012-06-10 11:56:
> On Jun 10, 5:24 am, JF Mezei<jfmezei.spam...@vaxination.ca>  wrote:
>> David Froble wrote:
>>> BINGO!  We have a winner.
>>
>> How many servers today in the x86 space still come with a serial port
>> that is usable for console work ?  Porting VMS without any video drivers
>> would restrict VMS to one of two servers designed to have serial line
>> consoles and no graphics.
>>
>> FredK had provided here some very good explanations of the type of
>> reverse engineering work he had to do to write video drivers on VMS,
>> including a basic x86 emulator to execute code provided by the video
>> card (since it expects to be attached to an x86 box)
>>
>> His expertise in the field was important and unique enough that he was
>> retained by HP despite the cuts. Alas, he passed away.
>>
>>> I have nothing against DECwindows.
>>
>> This is about providing basic console fnctionality on the screen
>> attached to the server (either physical, virtualised via stuff like VNC
>> or via KVM switches).  When VMS boots, it needs to be able to write to
>> the console and eventually load its own driver for it. If you want to
>> login in VT220 mode on the console, it needs a video driver to emulate
>> character cell on the console.
>>
>> DECwindows is about running an application o VMS and targetting the
>> window onto another machine which has a display. This in iself does not
>> need a video driver on VMS.
>
> A note on terminology: DECwindows doesn't touch the hardware. When the
> term DECwindows is used correctly it is more like a desktop, in the
> same area as CDE, KDE, GNOME, etc.
>
> The bit that does the device independent drawing of pictures and
> handling of kbd/mouse events (optionally with a network in the middle)
> is the industry standard (and open source?) X11. DECwindows sits atop
> X11.
>
> Between X11 and the hardware is a layer which includes hardware-
> specific device drivers.
>
> If you've got X11 working, CDE, KDE, LXDE, etc, come (almost) for
> free, nothing has to be rewritten from scratch, just maybe recompiled
> and tested (though I believe modern software practices often leave the
> testing part to the customer).
>
> Now, back to your main question I want to address: "How many servers
> today in the x86 space still come with a serial port
> that is usable for console work "
>
> I have read that the next generation of server OSes from MS will be
> designed for running headless (ie no local kbd/mouse/monitor on the
> server). This actually sounds quite sensible - why do you need a kbd/
> mouse/monitor on 99% of your servers, e.g. if 99% of them are virtual?
> And once you have the headless capability for the 99%, maybe the rest
> don't need them either?
>
> I don't imagine it'll be a serial console, nor do imagine it will be
> an open industry-standard protocol used by MS either, but the
> principle will have been established that servers can run headless
> once the OS is up.
>
> Now, what about before the OS is up, or while the OS is unusable/
> corrupt or just not installed?
>
> Who's heard of Intel vPro technologies on desktops, laptops, or
> servers? (Or Intel AMT, another name for the same kind of thing).
>
> If you deal with sensible corporate IT environments, who understand
> the need for remote management even WITHOUT the OS, you might have
> heard of it in the last few years. One of its features is support for
> remote access to BIOS facilities, even including serial line support
> of some kind (but mostly via a network that works even when the OS is
> unavailable). My five year old HPQ dc7700p desktop at home has some of
> this built in, as does the Dell kit at work. (Making the dc7700p NIC
> work at all with Windows was an interesting exercise but that's
> another story for another day). A vaguely similar offering from AMD
> appears to be called SIMFIRE and is based around open royalty free
> standards (DASH?) whereas vPro is Intel proprietary.
>
> I know very little about UEFI, some Apple users may well know more,
> but it'd be insane if it didn't support vPro-style capabilities in a
> generic way. E.g. as described in:
> http://h30565.www3.hp.com/t5/Feature-Articles/The-30-year-long-Reign-of-BIOS-is-Over-Why-UEFI-Will-Rock-Your/ba-p/198
> (featuring extensive comments from someone well known round here).
>
> So your decent business desktop, laptop, and server has had headless
> capabilities for several years, and will continue to do so.
>
> How hard can it be for VMS hardware and low level software to match
> the important bits of that kind of capability?
>

I thought modern VMS-aware servers (later Alphas and Itaniums) has some
kind of network interface builtin that include a serial emulation
for the "console". Or, in other words, VMS as such doesn't need
anything new to run on these headless, serialport-less servers.
 From VMS point of view it's still done through OPA0:

OK. I might not be able to do as I have done the last 20 years
with VMS (fire up Reflection and hook up a serial cable to the
console) the next 20 years with VMS. But that is just fine... :-)

Jan-Erik.


> I'm not sure the lack of a serial console or of low level graphics
> drivers is exactly going to be a showstopper for VMS, when even
> Windows-system builders are acknowledging these things may not matter
> much in the bigger picture.

On 06/10/12 10:27, Jan-Erik Soderholm wrote:

> I thought modern VMS-aware servers (later Alphas and Itaniums) has some
> kind of network interface builtin that include a serial emulation
> for the "console". Or, in other words, VMS as such doesn't need
> anything new to run on these headless, serialport-less servers.
>  From VMS point of view it's still done through OPA0:
>
> OK. I might not be able to do as I have done the last 20 years
> with VMS (fire up Reflection and hook up a serial cable to the
> console) the next 20 years with VMS. But that is just fine... :-)
>
> Jan-Erik.
>

Sun machines have had ilom via serial port or network for years. So do
proliants from what I can see at bios level, though have never used it
on x86 machines...

Regards,

Chris

Howard S Shubs wrote:

>> I have nothing against DECwindows.
> 
> I do.  It's worthless.  Always was, and it hasn't improved any that I've 
> heard.


Linux is based on X windows and offers a modern interface.  And OS-X
still supports X-windows over its own GUI.

DECwindows may be crap, but that is simply because active development
stopped in the early 1990s.

However, Decwindows TPU is still my favourite editor and I miss it. Hoff
had pointed me to "nedit" that can run on OS-X and this is what I use,
and it is usable, but I would still prefer TPU.

On 6/8/2012 11:55 PM, David Froble wrote:
> JF Mezei wrote:
>> Keith Parris wrote:
>>
>>> Press reports say �Intel executive Kirk Skaugen � testified that the
>>> amended agreement between Intel and HP gave it access to the Itanium
>>> microprocessor through 2022, and that HP could extend it even longer.�
>>
>>
>> Shareholders will not tolerate HP continue to sink moey into that IA64
>> thing when customers are leaving it in droves.
>>
>> The fact that HP agreed to slow down development to space the remaining
>> 2 generations means that IA64 will not be competitive with each of those
>> 2 generations.
>>
>> Your boss, Whitman admitted to press analysts that there was nothing
>> that could be done to fix BCS and that HP was pinning its hopes on the
>> new project Odyssey that will run Linux and Windows.
>>
>> So HP has realised that with IA64 sales dropping like a brick, they
>> probably have to accelerate Oddyssey to market as fast as they can to be
>> able to offer a migration to the deffecting customers.
>>
>
> Ya know, I really do not understand this Odyssey thingy. In the past,
> anyone who could easily leave VMS, and could accept the new environment,
> whatever it was, is most likely already gone. Some, I don't know how
> many, cannot move to weendoze or any Unix/Linux. So for them, what the
> hell good is round 2, or 3, or whatever, of trying to get these people
> to move to something that will not do the job for them, for whatever
> reasons.
>
> As I've wrote before, the applications I'm working with will not move
> off VMS. No way, no how. So, if there is no future for VMS, then there
> is no future for my applications, and that will mean starting over from
> scratch. Without some overwhelming reason, and I doubt there will be
> one, does anyone with a fraction of a brain think that I'm going to come
> near the entity that caused me all my problems with a thousand mile pole?
>
> So JF, while you claim to see fleeing customers, I see customers that
> given half a chance will be the most loyal HP has. Not because they like
> HP, but because they NEED VMS. The question then is, will HP blow off
> their potentially best customers?
>
> My perspective is, give the customers a chance, such as VMS on x86 and
> continuing development, and HP will have customers as long as x86 is a
> viable CPU. Even then, anything that replaces x86 will most likely have
> an easy upgrade path, if it wants to be successful.
>
> Thing is, whether HP has the people who could actually do the job, is a
> rather big question.

The handwriting has been on the wall for the last fifteen or twenty 
years!  People say "No!  This cannot be!"  The VMS community has fought 
a valiant rear guard action!  It hasn't changed much of anything!
VMS and VMS based applications are still around but there is damned 
little new development going on.  Those of us who know and love VMS
are getting older.  I came on board in 1984.  Prior to that my 
background was largely IBM System 360/370 and IBM System/7.
I retired in 2004, not because I wanted to retire but because the PC & 
Windows made everybody a "computer expert".

On 2012-06-10, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>
> However, Decwindows TPU is still my favourite editor and I miss it. Hoff
> had pointed me to "nedit" that can run on OS-X and this is what I use,
> and it is usable, but I would still prefer TPU.

Is it the TPU language or the EDT keypad and multiple windows you want ?

If it's the latter, try looking at emacs as it has a EDT keypad mode which
works just fine for me on a daily basis when run from a suitably equipped
terminal emulator.

When I've used it in the past in GUI mode, I don't remember any real
problems with it, although you do have to go through a keypad configuration
stage in GUI mode.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Simon Clubley wrote:
>
> If it's the latter, try looking at emacs as it has a EDT keypad mode which
> works just fine for me on a daily basis when run from a suitably equipped
> terminal emulator.


From what I was told, EMACS is a character cell editor that you can run
in an xterm. It isn't GUI.

TPU is GUI. I can type "edit" in a decterm window and a TPU window pops
up on my mac. And I can have separate editors all with their won
windows. With the proper x windows cut/paste etc and proper GUI
scrolling mechanism. You can drag the scroll bar to get to bottom of
document for instance (can't do that on a character cell running in an
xterm or decterm)

On Sunday, June 10, 2012 9:10:49 PM UTC-4, JF Mezei wrote:

> From what I was told, EMACS is a character cell editor that you can run
> in an xterm. It isn't GUI.

emacs can run in its own x-window and does offer additional graphical
support including a variety of font decoration options, multiple
window frames, menus, icons in a ribbon bar, embedded images, etc.

Most of these features don't shine until the more recent versions of
emacs which aren't available on VMS.  I believe v21 is the last one
that was built on VMS.  v24 is currently in a beta release.

emacswiki.org is a great resource for all things emacs.  

EJ

JF Mezei schrieb:

> From what I was told, EMACS is a character cell editor that you can run
> in an xterm. It isn't GUI.

Emacs comes with a GUI which is functionally similar to nedit.
The latter however isn't so bloated as Emacs, relies only
on libc and Motif and thus can relatively easy be backported
even to legacy OS's such as the one discussed in this group.
Btw, does nedit exist for VAX/VMS?

Michael Kraemer wrote:

> JF Mezei schrieb:
>> From what I was told, EMACS is a character cell editor that you can run
>> in an xterm. It isn't GUI.
> 
> Emacs comes with a GUI which is functionally similar to nedit.
> The latter however isn't so bloated as Emacs, relies only
> on libc and Motif and thus can relatively easy be backported
> even to legacy OS's such as the one discussed in this group.
> Btw, does nedit exist for VAX/VMS?

Yes, Nedit for VMS was at least on VMS Freeware V7, Probably also on V8,
but I can't see it in the index of the HP freeware site.
The version I have on my system is 5.5, and the last stable version on 
www.nedit.org (http://sourceforge.net/projects/nedit/) is also 5.5.
As far I can see, it doesn't need modifications for VMS.

-- 

Remove NOREPLY. from Email address.
Joseph Huber, http://www.huber-joseph.de

On 10-6-2012 21:06, JF Mezei wrote:
> DECwindows may be crap, but that is simply because active development
> stopped in the early 1990s.

Why should I care what you think, didn't you say you stopped using VMS
months ago?

I actually tend to really like it, also the pre-CDE environment.  It
is really fast and does the job, what more could I possibly want?
Binaries also tend to be very compact (compared to Qt, GTK+ and the
other common frameworks).

  - MG

On 06/11/12 08:44, Joseph Huber wrote:

>
> Yes, Nedit for VMS was at least on VMS Freeware V7, Probably also on V8,
> but I can't see it in the index of the HP freeware site.
> The version I have on my system is 5.5, and the last stable version on
> www.nedit.org (http://sourceforge.net/projects/nedit/) is also 5.5.
> As far I can see, it doesn't need modifications for VMS.
>

I used nedit for many years and it was the first usable open source editor
to have column style cut and paste, which is so very usefull, not to mention
the tabbed open file list. Very good editor and even available on cygwin...

regards,

Chris

In article <jquhff$ike$1@dont-email.me>, David Froble <davef@tsoft-inc.com> writes:
> 
> Ya know, I really do not understand this Odyssey thingy.  In the past, anyone who could 
> easily leave VMS, and could accept the new environment, whatever it was, is most likely 
> already gone.  Some, I don't know how many, cannot move to weendoze or any Unix/Linux.  So 
> for them, what the hell good is round 2, or 3, or whatever, of trying to get these people 
> to move to something that will not do the job for them, for whatever reasons.

   HP has bought into DEC's concept that VMS is for servers, running
   critical applications in the background.  Just about all such
   applications can be ported to just about any platform that can
   demonstrate acceptable uptime.  Even if it means buying twice as may
   processors when the processors cost 1/10 as much.

   HP has also bought into DEC's Stealth Marketing campaign, but at
   least its because they aren't really interested in selling the stuff.

   It's amaizing to see how much influence DEC still has, long after
   it's gone.
   
   The applications that can't run on a Windows, UNIX, or Linux kernel
   can run on other kernels.  And will.  And that's a small number of
   customers that HP will loose.

   Now just how would that get the attention of a huge paper and ink
   company?

In article <4fd54599$0$3988$c3e8da3$b23f186d@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> From what I was told, EMACS is a character cell editor that you can run
> in an xterm. It isn't GUI.

   You can bring up an emacs window on all supported OS without a
   terminal window.  emacs isn't a GUI, but it can use them.

   On the other hand, emacs doesn't know it's an editor.  It thinks
   it's a complete programmer's user interface, with editing, file 
   management, email, compiling, testing, ...
 
> TPU is GUI. I can type "edit" in a decterm window and a TPU window pops
> up on my mac.

   TPU is not a GUI, but it can use one.  And, of course, it does not require 
   a DECterm to start, nor does it require a GUI to do editing.

"Keith Parris" <keithparris_deletethis@yahoo.com> wrote in message 
news:jqt341$bl3$1@usenet01.boi.hp.com...
> On 6/7/2012 5:35 PM, David Froble wrot
>> If some customers value the Oracle software above
>> anything else, then they will not be running HP gear.
>
> They aren't forced to go to AIX or Solaris. They could always choose to 
> run Oracle on HP Proliant hardware under Linux.

Or on Dell or IBM or Lenovo or AMD/SeaMicro x86 servers....... 
etc....etc....

No need to stay with HP. 

Bob Koehler wrote:

>    TPU is not a GUI, but it can use one. 


EDIT/TPU/INTERFACE=DECWINDOWS would disagree with the above.

In article <4fd6d049$0$2341$c3e8da3$88b277c5@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> Bob Koehler wrote:
> 
>>    TPU is not a GUI, but it can use one. 
> 
> 
> EDIT/TPU/INTERFACE=DECWINDOWS would disagree with the above.

   Nope.  I use that all the time.  There is a difference between
   _is_ a GUI, and _uses_ a GUI.

   The fact that TPU runs just fine on a character cell terminal pretty
   much proves it is not a GUI.  The fact that it has implemented
   GUI features like scroll bars and menus that are only available
   when using the DECWindws interface proves that it can use a GUI.

On 2012-06-13 20:21:34 +0000, Bob Koehler said:

> In article <tveja9-tu7.ln1@mint-hp.chingola.ch>, Paul Sture 
> <paul.nospam@sture.ch> writes:
> 
>> SYSUAF.DAT and RIGHTSLIST.DAT have been a candidate for a database which
>> maintains consistency between the two of them (yes for backups too) ever
>> since the rightslist stuff was introduced in VMS V4.0, for example.
> 
>    SYSUAF.DAT and RIGHTSLIST.DAT don't need the hot backup, nor
>    reporting tools that you get with a proper DBMS.

Tried getting a backup off of these and the other core authorization 
files, particularly when they get active and when the mail servers and 
whatever else is flying around are holding locks?

Some managers do live by their reports, so that's certainly another 
reason to have an easy way to create those, and not have to reimplement 
all that dreck.  There are more than a few SYSUAF-reporting and 
account-aging tools that have been written over the years, too.

>    The issues with them getting inconsistent is inherint in the UAF
>    utility, and the use of separate storage.  Both contributions could
>    show up in a utility and with storage selection the if the data were
>    stored in a DBMS.

Do I think VMS would switch to a database?  Nope.  I don't.  (VMS 
hasn't particularly integrated LDAP beyond the password, and that's far 
older.   But I digress.)  The use of SYSUAF and RIGHTSLIST was an 
example, using constructs I thought would be understandable to those 
that might not realize why having an embedded database can have 
benefits.

Why did I point to the authorization files?  Because it's that it's a 
pain in the rump to keep implementing and reimplementing all this stuff 
over and over again.  And the usual results of reimplementing the 
wheel, to.  Hot backups, reports, transactions either don't get 
implemented, or get implemented with support costs and bugs.

Features and bugs that the databases solved decades ago.

Certainly most anything here is quite possible if you're willing to 
re-code your apps to embed what a database provides for you, and then 
maintain it, debug it, support it and upgrade it.     And yes, apps 
would need to be coded to use the database.  The question is how much 
else you have to code, maintain and support.

Bob Koehler wrote:

>    The fact that TPU runs just fine on a character cell terminal pretty
>    much proves it is not a GUI.  The fact that it has implemented
>    GUI features like scroll bars and menus that are only available
>    when using the DECWindws interface proves that it can use a GUI.


But this is different from EDT for instance which can also run in a FGUI
environment. It runs in a DECterm or Xterm windows but runs as a
character cell interface.

TPU can run as a X windows application complete with clipboard, mouse
etc support. It runs in its own window with its own fonts, and does not
depend on a terminal emulation window.

In article <4fd90c19$0$4219$c3e8da3$12bcf670@news.astraweb.com>, JF
Mezei <jfmezei.spamnot@vaxination.ca> writes: 

> Bob Koehler wrote:
> 
> >    The fact that TPU runs just fine on a character cell terminal pretty
> >    much proves it is not a GUI.  The fact that it has implemented
> >    GUI features like scroll bars and menus that are only available
> >    when using the DECWindws interface proves that it can use a GUI.
> 
> 
> But this is different from EDT for instance which can also run in a FGUI
> environment. It runs in a DECterm or Xterm windows but runs as a
> character cell interface.
> 
> TPU can run as a X windows application complete with clipboard, mouse
> etc support. It runs in its own window with its own fonts, and does not
> depend on a terminal emulation window.

Right, but it can also run in a window like EDT.

In article <4fd90c19$0$4219$c3e8da3$12bcf670@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> But this is different from EDT for instance which can also run in a FGUI
> environment. It runs in a DECterm or Xterm windows but runs as a
> character cell interface.
> 
> TPU can run as a X windows application complete with clipboard, mouse
> etc support. It runs in its own window with its own fonts, and does not
> depend on a terminal emulation window.

   Which is exactly my point.

In article <jravau$i58$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes:
> 
> Tried getting a backup off of these and the other core authorization 
> files, particularly when they get active and when the mail servers and 
> whatever else is flying around are holding locks?

   Nope.  Never been a problem.

On 2012-06-14 08:56:38 +0000, Jan-Erik Soderholm said:

> Michael Kraemer wrote 2012-06-14 10:17:
>> Jan-Erik Soderholm schrieb:
>> 
>>> So the point is that Rdb is not affected by the Oracle/HP debacle
>>> in any major way.
>> 
>> Huh?
>> If Rdb is frozen at some level
> 
> Only the numbers on paper ("7.3"), the software as such.

Paraphrasing from my notes from the HP-Oracle NYC Con-Call back on 19-Jul-2011:

The terminal Rdb version is 7.3, and its release date was officially 
March 2011. This implies that March 2016 is the end for Premier Support 
for Rdb, and 2019 is the end for Extended Support. (The Rdb 7.3 release 
was limited-access and reportedly only to one customer.  Rdb 7.3 was 
then expected to go into wider availability circa December, 2011.)
The Oracle Rdb folks did indicate they might decide to continue 
releasing new features as updates of Rdb 7.3, but would not bump the 
release number to comply with the corporate support statements. Whether 
and how long that might last wasn't stated.
The original notes are here: <http://labs.hoffmanlabs.com/node/1726>
I'd tend to assume that Rdb updates will continue only through 2016 or 
possibly through 2019, based on what I recall of the phrasing from the 
con-call.
For the official, current answer, check directly with Oracle.  They may 
well have updated their official position since the con-call, or I 
might have mishead or misinterpreted their statements.

Stephen Hoffman wrote 2012-06-14 15:54:
> On 2012-06-14 08:56:38 +0000, Jan-Erik Soderholm said:
>
>> Michael Kraemer wrote 2012-06-14 10:17:
>>> Jan-Erik Soderholm schrieb:
>>>
>>>> So the point is that Rdb is not affected by the Oracle/HP debacle
>>>> in any major way.
>>>
>>> Huh?
>>> If Rdb is frozen at some level
>>
>> Only the numbers on paper ("7.3"), the software as such.
>
> Paraphrasing from my notes from the HP-Oracle NYC Con-Call back on
> 19-Jul-2011:
>
> The terminal Rdb version is 7.3, and its release date was officially March
> 2011. This implies that March 2016 is the end for Premier Support for Rdb,
> and 2019 is the end for Extended Support. (The Rdb 7.3 release was
> limited-access and reportedly only to one customer. Rdb 7.3 was then
> expected to go into wider availability circa December, 2011.)

OK, that didn't happen.
7.2.5.1 was released in March 2012 (IA64 and Alpha).


> The Oracle Rdb folks did indicate they might decide to continue releasing
> new features as updates of Rdb 7.3, but would not bump the release number
> to comply with the corporate support statements. Whether and how long that
> might last wasn't stated.

 From when I listened to Kevin Duffy at the Rdb forum sep-2011, the message
was that they might push the dates for premier/extended support forward
with each new "point" release of Rdb (even if it's still called 7.3).

Anyway, 2016 and 2019 is quite a while away. Time will tell... :-)

But the message was that there is a difference between IA64 development
in general and OpenVMS development specificaly.

Jan-Erik.



> The original notes are here: <http://labs.hoffmanlabs.com/node/1726>
> I'd tend to assume that Rdb updates will continue only through 2016 or
> possibly through 2019, based on what I recall of the phrasing from the
> con-call.
> For the official, current answer, check directly with Oracle. They may well
> have updated their official position since the con-call, or I might have
> mishead or misinterpreted their statements.
>

Jan-Erik Soderholm wrote 2012-06-14 16:10:
> Stephen Hoffman wrote 2012-06-14 15:54:
>> On 2012-06-14 08:56:38 +0000, Jan-Erik Soderholm said:
>>
>>> Michael Kraemer wrote 2012-06-14 10:17:
>>>> Jan-Erik Soderholm schrieb:
>>>>
>>>>> So the point is that Rdb is not affected by the Oracle/HP debacle
>>>>> in any major way.
>>>>
>>>> Huh?
>>>> If Rdb is frozen at some level
>>>
>>> Only the numbers on paper ("7.3"), the software as such.
>>
>> Paraphrasing from my notes from the HP-Oracle NYC Con-Call back on
>> 19-Jul-2011:
>>
>> The terminal Rdb version is 7.3, and its release date was officially March
>> 2011. This implies that March 2016 is the end for Premier Support for Rdb,
>> and 2019 is the end for Extended Support. (The Rdb 7.3 release was
>> limited-access and reportedly only to one customer. Rdb 7.3 was then
>> expected to go into wider availability circa December, 2011.)
>
> OK, that didn't happen.
> 7.2.5.1 was released in March 2012 (IA64 and Alpha).
>
>
>> The Oracle Rdb folks did indicate they might decide to continue releasing
>> new features as updates of Rdb 7.3, but would not bump the release number
>> to comply with the corporate support statements. Whether and how long that
>> might last wasn't stated.
>
>  From when I listened to Kevin Duffy at the Rdb forum sep-2011, the message
> was that they might push the dates for premier/extended support forward
> with each new "point" release of Rdb (even if it's still called 7.3).
>

Also check the dates on :

http://www.oracle.com/technetwork/products/rdb/learnmore/orardb-lifesupport-092356.html

or in :

http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf

Note the differences in intervalls between "General Availability"
and the end dates for the support options. The dates for 7.1 and
7.2 has been pushed forward from the initial dates. If we apply
the intervalls for 7.2 on the 7.3 "General Availability" date
we get "Premier Support Ends" in Aug-2019 and "Extended Support
Ends" in Aug-1922. So what Kevin Duffy said about the dates for
the 7.3 release seems to have been applied to the 7.1 and 7.2
release also.

On Thursday, June 14, 2012 10:52:25 AM UTC-4, Jan-Erik Soderholm wrote:
> Jan-Erik Soderholm wrote 2012-06-14 16:10:
> > Stephen Hoffman wrote 2012-06-14 15:54:
> >> On 2012-06-14 08:56:38 +0000, Jan-Erik Soderholm said:
> >>
> >>> Michael Kraemer wrote 2012-06-14 10:17:
> >>>> Jan-Erik Soderholm schrieb:
> >>>>
> >>>>> So the point is that Rdb is not affected by the Oracle/HP debacle
> >>>>> in any major way.
> >>>>
> >>>> Huh?
> >>>> If Rdb is frozen at some level
> >>>
> >>> Only the numbers on paper ("7.3"), the software as such.
> >>
> >> Paraphrasing from my notes from the HP-Oracle NYC Con-Call back on
> >> 19-Jul-2011:
> >>
> >> The terminal Rdb version is 7.3, and its release date was officially March
> >> 2011. This implies that March 2016 is the end for Premier Support for Rdb,
> >> and 2019 is the end for Extended Support. (The Rdb 7.3 release was
> >> limited-access and reportedly only to one customer. Rdb 7.3 was then
> >> expected to go into wider availability circa December, 2011.)
> >
> >
> >> The Oracle Rdb folks did indicate they might decide to continue releasing
> >> new features as updates of Rdb 7.3, but would not bump the release number
> >> to comply with the corporate support statements. Whether and how long that
> >> might last wasn't stated.
> >
> >  From when I listened to Kevin Duffy at the Rdb forum sep-2011, the message
> > was that they might push the dates for premier/extended support forward
> > with each new "point" release of Rdb (even if it's still called 7.3).
> >
> 

Here is the latest I have.  It is from the Technical Update Days in Dallas just last month.  Kevin Duffy gave a talk and this is the presentation:
http://www.ccsscorp.com/Oracle%20Product%20Update%20-%20Dallas%20TUD%20Public.pdf

Since the presentation is so large I have hosted it on my web site so people can download it if they are interested.

Bill.

BillPedersen wrote:
> On Thursday, June 14, 2012 10:52:25 AM UTC-4, Jan-Erik Soderholm wrote:
>> Jan-Erik Soderholm wrote 2012-06-14 16:10:
>>> Stephen Hoffman wrote 2012-06-14 15:54:
>>>> On 2012-06-14 08:56:38 +0000, Jan-Erik Soderholm said:
>>>>
>>>>> Michael Kraemer wrote 2012-06-14 10:17:
>>>>>> Jan-Erik Soderholm schrieb:
>>>>>>
>>>>>>> So the point is that Rdb is not affected by the Oracle/HP debacle
>>>>>>> in any major way.
>>>>>>
>>>>>> Huh?
>>>>>> If Rdb is frozen at some level
>>>>>
>>>>> Only the numbers on paper ("7.3"), the software as such.
>>>>
>>>> Paraphrasing from my notes from the HP-Oracle NYC Con-Call back on
>>>> 19-Jul-2011:
>>>>
>>>> The terminal Rdb version is 7.3, and its release date was officially March
>>>> 2011. This implies that March 2016 is the end for Premier Support for Rdb,
>>>> and 2019 is the end for Extended Support. (The Rdb 7.3 release was
>>>> limited-access and reportedly only to one customer. Rdb 7.3 was then
>>>> expected to go into wider availability circa December, 2011.)
>>>
>>>
>>>> The Oracle Rdb folks did indicate they might decide to continue releasing
>>>> new features as updates of Rdb 7.3, but would not bump the release number
>>>> to comply with the corporate support statements. Whether and how long that
>>>> might last wasn't stated.
>>>
>>>   From when I listened to Kevin Duffy at the Rdb forum sep-2011, the message
>>> was that they might push the dates for premier/extended support forward
>>> with each new "point" release of Rdb (even if it's still called 7.3).
>>>
>>
>
> Here is the latest I have.  It is from the Technical Update Days in Dallas just last month.  Kevin Duffy gave a talk and this is the presentation:
> http://www.ccsscorp.com/Oracle%20Product%20Update%20-%20Dallas%20TUD%20Public.pdf
>
> Since the presentation is so large I have hosted it on my web site so people can download it if they are interested.
>
> Bill.
>

Page 12 is interesting. It says that RDB 7.4 and 8.0 (!!) will not be 
supported on Itanium. Perhaps Oracle knows that VMS will be ported to 
another CPU????

On Thursday, June 14, 2012 1:57:05 PM UTC-4, Dirk Munk wrote:
> BillPedersen wrote:
> > On Thursday, June 14, 2012 10:52:25 AM UTC-4, Jan-Erik Soderholm wrote:
> >> Jan-Erik Soderholm wrote 2012-06-14 16:10:
> >>> Stephen Hoffman wrote 2012-06-14 15:54:
> >>>> On 2012-06-14 08:56:38 +0000, Jan-Erik Soderholm said:
> >>>>
> >>>>> Michael Kraemer wrote 2012-06-14 10:17:
> >>>>>> Jan-Erik Soderholm schrieb:
> >>>>>>
> Page 12 is interesting. It says that RDB 7.4 and 8.0 (!!) will not be 
> supported on Itanium. Perhaps Oracle knows that VMS will be ported to 
> another CPU????

While that might be interesting I find it doubtful and take the more rational view that it means the budget associated with those two specific "future versions" has been reassigned.

Bill.

Dirk Munk wrote 2012-06-14 19:57:
> BillPedersen wrote:
>> On Thursday, June 14, 2012 10:52:25 AM UTC-4, Jan-Erik Soderholm wrote:
>>> Jan-Erik Soderholm wrote 2012-06-14 16:10:
>>>> Stephen Hoffman wrote 2012-06-14 15:54:
>>>>> On 2012-06-14 08:56:38 +0000, Jan-Erik Soderholm said:
>>>>>
>>>>>> Michael Kraemer wrote 2012-06-14 10:17:
>>>>>>> Jan-Erik Soderholm schrieb:
>>>>>>>
>>>>>>>> So the point is that Rdb is not affected by the Oracle/HP debacle
>>>>>>>> in any major way.
>>>>>>>
>>>>>>> Huh?
>>>>>>> If Rdb is frozen at some level
>>>>>>
>>>>>> Only the numbers on paper ("7.3"), the software as such.
>>>>>
>>>>> Paraphrasing from my notes from the HP-Oracle NYC Con-Call back on
>>>>> 19-Jul-2011:
>>>>>
>>>>> The terminal Rdb version is 7.3, and its release date was officially
>>>>> March
>>>>> 2011. This implies that March 2016 is the end for Premier Support for
>>>>> Rdb,
>>>>> and 2019 is the end for Extended Support. (The Rdb 7.3 release was
>>>>> limited-access and reportedly only to one customer. Rdb 7.3 was then
>>>>> expected to go into wider availability circa December, 2011.)
>>>>
>>>>
>>>>> The Oracle Rdb folks did indicate they might decide to continue releasing
>>>>> new features as updates of Rdb 7.3, but would not bump the release number
>>>>> to comply with the corporate support statements. Whether and how long
>>>>> that
>>>>> might last wasn't stated.
>>>>
>>>> From when I listened to Kevin Duffy at the Rdb forum sep-2011, the message
>>>> was that they might push the dates for premier/extended support forward
>>>> with each new "point" release of Rdb (even if it's still called 7.3).
>>>>
>>>
>>
>> Here is the latest I have. It is from the Technical Update Days in Dallas
>> just last month. Kevin Duffy gave a talk and this is the presentation:
>> http://www.ccsscorp.com/Oracle%20Product%20Update%20-%20Dallas%20TUD%20Public.pdf
>>
>>
>> Since the presentation is so large I have hosted it on my web site so
>> people can download it if they are interested.
>>
>> Bill.
>>
>
> Page 12 is interesting. It says that RDB 7.4 and 8.0 (!!)

*or*, not "and"...

> will not be
> supported on Itanium. Perhaps Oracle knows that VMS will be ported to
> another CPU????
>

It says that there will not be any Rdb 7.4 (or 8.0) on *Itanium*.

It does *not* say that there will be a Rdb 7.4 (or 8.0) on any
other platform either.

But, OTOH, it does *not* say that there will *not* be a Rdb 7.4
(or 8.0) on Alpha... :-)

BillPedersen schrieb:

> 
> Here is the latest I have.  It is from the Technical Update Days in Dallas just last month.  Kevin Duffy gave a talk and this is the presentation:
> http://www.ccsscorp.com/Oracle%20Product%20Update%20-%20Dallas%20TUD%20Public.pdf
> 

This presentation says, as already mentioned, that Rdb on IA64
is just as frozen
as everything else running on HP's Itanium servers.
Which makes sense, because if Mr. Ellison has an axe to grind
with the Itanic platform, why should the Rdb ecosystem get off better
than the DB one?
Which brings up the question what will happen with the Alpha versions?
Are they already "dead"?

Michael Kraemer wrote 2012-06-14 22:41:
> BillPedersen schrieb:
>
>>
>> Here is the latest I have. It is from the Technical Update Days in Dallas
>> just last month. Kevin Duffy gave a talk and this is the presentation:
>> http://www.ccsscorp.com/Oracle%20Product%20Update%20-%20Dallas%20TUD%20Public.pdf
>>
>>
>
> This presentation says,

On page 53:

"Oracle on OpenVMS continues because Oracle
Database & Oracle Rdb business is healthy &
valuable"

> as already mentioned, that Rdb on IA64
> is just as frozen
> as everything else running on HP's Itanium servers.

Quite weird interpetation of that...

In article <jrcqfh$71b$1@dont-email.me>, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> writes: 

> >>> So the point is that Rdb is not affected by the Oracle/HP debacle
> >>> in any major way.
> >> 
> >> Huh?
> >> If Rdb is frozen at some level
> > 
> > Only the numbers on paper ("7.3"), the software as such.
> 
> Paraphrasing from my notes from the HP-Oracle NYC Con-Call back on 19-Jul-2011:
> 
> The terminal Rdb version is 7.3, and its release date was officially 
> March 2011. This implies that March 2016 is the end for Premier Support 
> for Rdb, and 2019 is the end for Extended Support. (The Rdb 7.3 release 
> was limited-access and reportedly only to one customer.  Rdb 7.3 was 
> then expected to go into wider availability circa December, 2011.)
> The Oracle Rdb folks did indicate they might decide to continue 
> releasing new features as updates of Rdb 7.3, but would not bump the 
> release number to comply with the corporate support statements. Whether 
> and how long that might last wasn't stated.

Right.

> The original notes are here: <http://labs.hoffmanlabs.com/node/1726>
> I'd tend to assume that Rdb updates will continue only through 2016 or 
> possibly through 2019, based on what I recall of the phrasing from the 
> con-call.
> For the official, current answer, check directly with Oracle.  They may 
> well have updated their official position since the con-call, or I 
> might have mishead or misinterpreted their statements.

If Jan-Erik is right and this is a strategy to circumvent the high-level 
order to "stop development on Itanium" by abiding by the letter but not 
the spirit of the law, it won't be in any publicly available official 
announcement.

On Friday, June 15, 2012 2:59:23 AM UTC-4, Phillip Helbig---undress to repl=
y wrote:
> In article <jrcqfh$71b$1@dont-email.me>, Stephen Hoffman
> >=20
> > Paraphrasing from my notes from the HP-Oracle NYC Con-Call back on 19-J=
ul-2011:
> > The Oracle Rdb folks did indicate they might decide to continue=20
> > releasing new features as updates of Rdb 7.3, but would not bump the=20
> > release number to comply with the corporate support statements. Whether=
=20
> > and how long that might last wasn't stated.
>=20
> Right.
>=20
> > The original notes are here: <http://labs.hoffmanlabs.com/node/1726>
> > I'd tend to assume that Rdb updates will continue only through 2016 or=
=20
> > possibly through 2019, based on what I recall of the phrasing from the=
=20
> > con-call.
>=20
> If Jan-Erik is right and this is a strategy to circumvent the high-level=
=20
> order to "stop development on Itanium" by abiding by the letter but not=
=20
> the spirit of the law, it won't be in any publicly available official=20
> announcement.

In talking with Kevin Duffy, Rdb was "caught up" in the corporate mandate b=
efore anyone making such a decision realized the issue of "it only runs on =
VMS" and there are no significant/reasonable alternatives.  He is very will=
ing to talk to folks about what they are working on and trying to move forw=
ard with that.

He does not expect to freeze Rdb but has some very specific and targeted im=
provements - encryption support, performance which he expects to show the b=
usiness case for continued implementation.  They are, as identified in the =
presentation in testing.

Oracle Classic - that is frozen on IA64.  Oracle Client software is another=
 story.  The business case here is that the "logic" resides on the VMS syst=
em and so having the ability to access Oracle Classic on some other platfor=
m is not much different - since Oracle runs in a client/server mode even on=
 one host - other than performance.  So the business case here is the abili=
ty to sell databases on other than IA64 environments and yet support custom=
ers - long standing important customers - who still have their business log=
ic and applications firmly tied to VMS.

How long will it continue?  I do not know.

I do know that Kevin had been on the road for several months before I saw h=
im in May talking with customers and expected to be continuing that process=
..  It was not that he was telling people that Oracle on VMS was dead but th=
at the Rdb Product Family would continue and that Oracle Client would conti=
nue.

Take it with whatever grain of salt (you pick the type) you want.  If Kevin=
 can keep the business argument together to keep providing improvements bec=
ause the business is profitable then he will most likely be able to do so -=
 at least on VMS.

My take on this presentation and discussions.

Bill.

BillPedersen wrote:
> On Friday, June 15, 2012 2:59:23 AM UTC-4, Phillip Helbig---undress to reply wrote:
>> In article <jrcqfh$71b$1@dont-email.me>, Stephen Hoffman
>>> Paraphrasing from my notes from the HP-Oracle NYC Con-Call back on 19-Jul-2011:
>>> The Oracle Rdb folks did indicate they might decide to continue 
>>> releasing new features as updates of Rdb 7.3, but would not bump the 
>>> release number to comply with the corporate support statements. Whether 
>>> and how long that might last wasn't stated.
>> Right.
>>
>>> The original notes are here: <http://labs.hoffmanlabs.com/node/1726>
>>> I'd tend to assume that Rdb updates will continue only through 2016 or 
>>> possibly through 2019, based on what I recall of the phrasing from the 
>>> con-call.
>> If Jan-Erik is right and this is a strategy to circumvent the high-level 
>> order to "stop development on Itanium" by abiding by the letter but not 
>> the spirit of the law, it won't be in any publicly available official 
>> announcement.
> 
> In talking with Kevin Duffy, Rdb was "caught up" in the corporate mandate before anyone making such a decision realized the issue of "it only runs on VMS" and there are no significant/reasonable alternatives.  He is very willing to talk to folks about what they are working on and trying to move forward with that.
> 
> He does not expect to freeze Rdb but has some very specific and targeted improvements - encryption support, performance which he expects to show the business case for continued implementation.  They are, as identified in the presentation in testing.
> 
> Oracle Classic - that is frozen on IA64.  Oracle Client software is another story.  The business case here is that the "logic" resides on the VMS system and so having the ability to access Oracle Classic on some other platform is not much different - since Oracle runs in a client/server mode even on one host - other than performance.  So the business case here is the ability to sell databases on other than IA64 environments and yet support customers - long standing important customers - who still have their business logic and applications firmly tied to VMS.
> 
> How long will it continue?  I do not know.
> 
> I do know that Kevin had been on the road for several months before I saw him in May talking with customers and expected to be continuing that process.  It was not that he was telling people that Oracle on VMS was dead but that the Rdb Product Family would continue and that Oracle Client would continue.
> 
> Take it with whatever grain of salt (you pick the type) you want.  If Kevin can keep the business argument together to keep providing improvements because the business is profitable then he will most likely be able to do so - at least on VMS.
> 
> My take on this presentation and discussions.
> 
> Bill.

Ya know, from what I'm reading, no matter how you try to spin things, you're bent over, 
and Larry is behind you.  If he doesn't care who he hurts in his fight with HP, just be 
prepared to be one of those hurt.

I'm not close to anything Oracle does, so anything I say is just speculation.  Therefore, 
I cannot know whether the money means anything to Larry.  I'd assume it does, but I could 
be wrong.

A bit of history.  One of the so called news programs on NBC ran a program about Chevy or 
GMC trucks that supposedly had fuel tanks that would explode when in a collision. 
However, try as they might, they could not get a fuel tank to explode when in a collision. 
  No problem, they knew how to fix that.  Pyrotechnics!  Only problem, the explosion went 
off before the collision.  Experts reviewing the film caught this.  So there is NBC caught 
with their pants down, but as such arrogant people are, all they had to say was "we stand 
by our story".  I mean, after all, who has any use for reality, huh?

This was not the first time a TV network did a hatchet job in their programming.  However, 
this time they bit off a bit more than they could chew.  The target was GM, who had 
multi-million advertising on NBC.  GM pulled the entire advertising budget.  The 
paramedics were very busy at NBC, what with all the heart attacks the executives suffered. 
  (Just kidding.)  For one of the few times in network TV, a network abandoned their "we 
stand by our story" and instead issued a retraction.  As always, money talks.

And so I'd ask, is there any RDB user organizations?  What percentage of RDB users are in 
these organizations?  If perhaps they united and issued a statement to Oracle that since 
RDB seems to have been included in Larry's fight with HP, and there will be no new major 
versions, that they are all going to drop their support contracts.

Might work, might not work.  Who can tell with Larry.

BillPedersen wrote:

> In talking with Kevin Duffy, Rdb was "caught up" in the corporate mandate before anyone making such a decision realized the issue of "it only runs on VMS" and there are no significant/reasonable alternatives.  He is very willing to talk to folks about what they are working on and trying to move forward with that.



Considering that Oracle documents shows that HP expected that customers
would find out about the EOL of IA74, HP-UX and VMS in 2012,  the fate
of all sftware development in those ecosystems will be in question once
this becomes more "official".

The VMS roadmap is down to just a .point release. My guess is that HP
may expect to issues a new version or patched version for Poulson and
then one for Kittson.

So even if VMS is to be officially "developped" for another couple of
years, it will be mostly just maintenance and support for the new
hardware that is still in the pipeline.

Once the news is out, Oracle will likely be working on some strategy
(and porting tools)  to convert RDB customers to Oracle customers.

On Friday, June 8, 2012 5:50:55 PM UTC-4, David Froble wrote:
> Keith Parris wrote:
> > On 6/7/2012 5:35 PM, David Froble wrot
> >> If some customers value the Oracle software above
> >> anything else, then they will not be running HP gear.
> > 
> > They aren't forced to go to AIX or Solaris. They could always choose to 
> > run Oracle on HP Proliant hardware under Linux.
> 
> Well, yes Keith, there are total idiots in this world.
> 
> Maybe some masochists that enjoy pain and suffering.
> 
> But a few of us still have 1/4 a brain, and if you bend me over and buttf..k me, I'm 
> perhaps not going to give you more chances.
> 
> I'm still here because my software won't run anywhere else.  If HP would cause my software 
> to become totally worthless and unusable, and if I have to start over, don't you think I'm 
> going to attempt to avoid the same thing happening again?  Perhaps there aren't 100% 
> guarantees anywhere, but the way HP is currently screwing up continuously, and the antics 
> of the board, and their sharply declining revenue in BCS, I think most people taking a 
> fresh look might consider HP a rather poor choice.  If they have screwed their customers 
> (even if inherited from DEC) once (or more), then shouldn't I expect them to do it again?
> 
> Let's try it this way Keith.  Say it was your (rather substantial) money that was to fund 
> a new product, which might decide whether you're going to live well, or in the poor house. 
>   Say that you're starting with a totally clean sheet of paper.  Now tell me where IBM 
> would be on your list of prospective vendors, and where HP would be on your list of 
> prospective vendors?
> 
> You're a good company man Keith.  I applaud your loyalty.  But some things just aren't 
> reasonable and / or feasible.  One of the reasons VMS is claimed to be dying is because 
> it's not being fed.
> 
> Where is IPSEC in HP TCP/IP on VMS?
> Where is a decent version of SSL on VMS?
> Where are the many things that are appearing in other environments but not VMS?
> 
> You know this could be a long list, but why bother, the list isn't the issue. The issue is 
> HP's commitment to a future for VMS.

try TCPware :)