When HP loses to Oracle....

[John Smith (who cares if I'm the one @ HP - if here's even still there)]

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

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

[Keith Parris]

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.

[Michael Kraemer]

In article <jqo20f$cbk$1...@usenet01.boi.hp.com>, Keith Parris

<keithparris...@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.

[Phillip Helbig---undress to reply]

In article <ShLzr.21229$FL5....@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.

[Keith Parris]

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

[Keith Parris]

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.

[Richard Maher]

"Keith Parris" <keithparris...@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!

[Rich Jordan]

On Jun 6, 2:04 pm, Keith Parris <keithparris_deletet...@yahoo.com>
wrote:

> 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_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-intel-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-oracle-over-itanium-announcement

[Keith Parris]

On 6/6/2012 3:55 PM, Richard Maher wrote:
> "Keith Parris"<keithparris...@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.

[johnso...@gmail.com]

> 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

[Michael Kraemer]

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...@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.

[Michael Kraemer]

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?

[Michael Kraemer]

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?

[MG]

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

[Richard Maher]

"Keith Parris" <keithparris...@yahoo.com> wrote in message

news:jqom20$av2$1...@usenet01.boi.hp.com...

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
>

[Jan-Erik Soderholm]

> "Keith Parris"<keithparris...@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...@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.

[Richard Maher]

"Jan-Erik Soderholm" <jan-erik....@telia.com> wrote in message
news:jqq9sc$vd5$2...@news.albasani.net...

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

[johnso...@gmail.com]

> 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

[David Froble]

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.

[Michael Kraemer]

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.

[David Froble]

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.

[Keith Parris]

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.

[Fritz Wuehler]

David Froble <da...@tsoft-inc.com> wrote:

> 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.

Understatement of the century. They make Windows look like a good deal.

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

Everyone who's heard of SAP has heard about those.

> 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.

They're good at making money for incompetent idiots at all levels from
coders to managers, too. Their stuff is so bad they have to pay people who
claim to know it 2x normal salaries.

[David Froble]

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.

[JF Mezei]

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.

[JF Mezei]

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.

[JF Mezei]

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.

[JF Mezei]

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]

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.

[David Froble]

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

[Paul Sture]

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...@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

[Mazzini Alessandro]

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...@vaxination.ca> ha scritto nel messaggio
news:4fd2b4ee$0$2322$c3e8da3$c8b7...@news.astraweb.com...

[Stephen Hoffman]

On 2012-06-09 03:55:25 +0000, David Froble said:
>
> 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.

It's a big-box option for folks with apps and app designs that want or
need big-box iron.

Project Moonshot/Redstone (the Calxeda ARM-based servers built using
giblets from the ProLiant parts bin) and Project Odyssey (Intel Xeon
x86-86 server boards sharing giblets from the Superdome 2 parts bin)
aren't (directly) relevent to OpenVMS users, but can be useful for
OpenVMS sites...

Project Odyssey can provide OpenVMS folks with...

+ a mixed-architecture platform for multi-OS big-box apps, including OpenVMS

+ a big-box platform for VAX or Alpha emulation

Superdome 2 boxes with a mix of Odyssey Xeon processor boards and
Itanium boards can provide a high-end mixed-architecture platform for
an incremental port off of OpenVMS. The OpenVMS apps and the Xeon
x86-64 apps {Windows, Linux, Unix, whatever} are operating together in
the box, as part of an incremental application software migration.

The Odyssey Xeon processor boards can preserve (some of) the investment
HP and others have in the Superdome 2 platform. For the sales and
marketing and advertising "process", the Odyssey Xeon boards will give
the marketeers and the buyers some political cover around buying that
Big Itanium Box.

There'll undoubtedly be the usual somewhat gnarly and arcane Microsoft
Windows management tools for the Odyssey Xeon processor boards, of
course. More interesting to the applications (whether used for porting
or not) will (hopefully) be software support within the Project Odyssey
operating system enabling packages for a shared-memory interconnect;
APIs and libraries for QPI-speed or memory-speed communications among
the instances (as Galaxy called them, and similar to the Galaxy SMCI),
and as a foundation for memory-based network connections.

The NSK servers, Project Odyssey Xeon processor boards and the
Moonshot/Redstone servers are all moving the HP "special sauce" (at
least as far as the HP advertising presents it) into the glue chips and
the boxes and the enablement software; with the sx3000 chipset used in
the SD2. Outside of a customized ARM design (and whether HP is using
that for a Moonshot box), the processors used across the products are
commodity parts.

Though only useful for curiosity and the most general guidance, the
Odyssey Xeon processor boards will also allow a direct comparison with
the Itanium processors with the same sx3000 interconnect; with what
Xeon can provide for performance when coupled into a high-scale
multiple-socket configuration.

Moonshot/Redstone isn't likely going to be used a host for emulation
(but then, who really knows what some sites need here?), but the
Redstone server boxes can serve as a front-end box for OpenVMS apps; as
a way to offload certain sorts of application processing. The server
development platform is reportedly due this month, and provides 2,800
servers in a rack. A box which might be a great way to deal with all
that front-end dreck that would otherwise bury an OpenVMS server in
dinky I/O requests, whether as a web server or as a terminal front-end
interface for those still using that design.

[David Froble]

Other then the bit about emulation, none of the above is of any use to me. Others may
have different requirements.

I'm thinking that you missed the point of my post. For me, the essential need is VMS, and
none of the rest described above can do anything to help. That makes it useless junk, at
least to me.

In general, I'm thinking that most of the people who could easily leave VMS have already
done so. If so, then the rest have the same problem I have. What is needed is VMS, and
what is not needed is anything else.

So my question remains, what good is all this junk to those who cannot use it ?????

[Stephen Hoffman]

On 2012-06-09 14:36:24 +0000, David Froble said:
>
> Other then the bit about emulation, none of the above is of any use to
> me. Others may have different requirements.

The folks still using VMS are doing so for various reasons, and their
requirements can differ.

Often vastly, in my experience.

> I'm thinking that you missed the point of my post. For me, the
> essential need is VMS, and none of the rest described above can do
> anything to help. That makes it useless junk, at least to me.

I didn't miss your point. Parts of which were, well, emphatically clear.

You're currently being faced with a decision to update your existing
code and increasingly your OpenVMS environment, or to commence a port,
or a rewrite. Or with encouraging HP to invest in areas of OpenVMS.

This also given your comments around application requirements that are
growing out of what OpenVMS presently provides for software features.

An Odyssey-class box is only useful to you if you've decided to port,
and if you need a big-box to port to.

And yes, opening up discussions of a platform port also open up
discussions of the available hardware vendors; most folks will look at
a variety of vendors, once a hardware port is under consideration.

I'm encountering similar issues across various projects, including
cases where a lack of tools or features makes coding for OpenVMS slower
than on other platforms. Which means "glue code". That "glue code" is
upgrading the features and APIs that are available within OpenVMS. And
that's a pernicious cost on the project or product. And the time and
cost of creating my own programming and debugging tools, and libraries.

> In general, I'm thinking that most of the people who could easily leave
> VMS have already done so.

Some. Some are working on incremental or full ports. Some are going
to run their VMS hardware into the ground, and then switch to
emulation. Some have already switched to emulation. And yes, some
folks have or are porting off of OpenVMS, or are migrating their data
over to different tools. This varies.

> If so, then the rest have the same problem I have. What is needed is
> VMS, and what is not needed is anything else.
>
> So my question remains, what good is all this junk to those who cannot
> use it ?????

Maybe of no use. Or maybe an Odyssey-class box would be among the
available choices you do have, if you can't have what you need with VMS
going forward, and are migrating. Though in your particular case and
your phrasing, you've made it emphatically clear that the HP
representatives will be operating at a profound deficit in any
discussions around providing replacement hardware.

And yes, the easiest path for your applications clearly involves
upgrades and enhancements to OpenVMS, and preferably support past any
end to Itanium processor availability. And those matters are going to
involve some investments by and various discussions with the HP BCS
folks. Which probably won't happen here in a newsgroup, given the HP
OpenVMS folks posting here are not those that are making these
decisions. Well, not unless they've gotten themselves some
stratospheric promotions. :-)

[JF Mezei]

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 ?

[John Wallace]

On Jun 9, 5:09 pm, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
wrote:

Why would anyone interested in a Xeon-based "high-scale multiple-
socket configuration" want to wait for Odyssey?

There are already 8socket x86-64 systems on the market. The one from
HPQ is the Proliant DL980 G7 (whose details have been around since
2010 - up to 80 cores and a handful of TB of memory, and quite
possibly more QuickPath bandwidth than a Superdome). It even uses a
Superdome-derived (so HP say) controller to provide a resilient low
latency interconnect between two four-socket "quad building
blocks" (they're not called that officially) to make an 8socket
system. Apparently the Intel glueless interconnect design was sub-
optimal in terms of memory latency in an 8socket system, making it a
bit NUMA-ish. (Yes that may sound familiar).

The DL980 G7 was mentioned earlier today, as was an 8socket system
from SuperMicro, in the "Did any one post this Oracle link already?"
thread, e.g.
http://groups.google.com/group/comp.os.vms/msg/b3051d0275cade43

If folk are for some reason reluctant to do business with HP, then
Dell and IBM do the four socket variant of these systems, which still
probably covers quite a large proportion of the market.

Regardless of hardware capabilities, these boxes would still be better
with a decent enterprise OS. But they're already good enough for lots
of people to bet their businesses on, even with the run of the mill
software already available.

[Jan-Erik Soderholm]

> 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.

[Stephen Hoffman]

On 2012-06-09 17:47:27 +0000, John Wallace said:
>
> Why would anyone interested in a Xeon-based "high-scale multiple-
> socket configuration" want to wait for Odyssey?
>
> There are already 8socket x86-64 systems on the market.

Yes, there are. From various vendors.

HP is aiming at 32 sockets for Project Odyssey.

Obviously at least ten to possibly sixteen or maybe more cores per
socket for that 32-socket configuration seems likely, depending on the
particulars details of the Xeon chip that's current when the Project
Odyssey boxes launch.

Plus whatever RAS features HP might choose to implement, beyond those
of the existing ProLiant configurations.

> ...The one from
> HPQ is the Proliant DL980 G7...

"HP began cascading mission-critical attributes to x86 with the launch
of the HP ProLiant DL980. For example, the PREMA architecture in the
DL980 takes advantage of some of the scalability and reliability
capabilities offered on Integrity servers. HP will continue to cascade
its mission-critical IP over time across hardware, software and
services to deliver the full mission critical experience on x86."

<http://h30507.www3.hp.com/t5/Mission-Critical-Computing-Blog/Got-Questions-About-HP-Project-Odyssey-Single-Platform-Mission/ba-p/103473>


The "PREMA architecture" stuff looks to be the marketing buzz-phrase HP
is using here. There are some additional paragraphs of text around
what HP is incorporating into its "PREMA architecture" marketing
included in the DL980 G7 technical overview:

<http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA3-0643ENW.pdf>

"The machine is...basically two DL580s doubled up and talking across
Intel's "Boxboro" 7500 chipset to make an eight-socket server with 128
memory slots and topping out at 2 TB of main memory."

<http://www.theregister.co.uk/2010/06/22/hp_proliant_blade_rack/page2.html>

Architecturally, some folks refer to the DL980 as two four-socket boxes
working together, too.

> ...Regardless of hardware capabilities, these boxes would still be better

> with a decent enterprise OS.

And I'm sure there are folks here that might have a proposal for that choice.

IIRC, OpenVMS is limited to 64 cores per instance/partition/guest, in
its present implementation. There were bits stored in quadwords for
various related data structures. I don't recall if hyperthreading
lowers that count further, though.

Toward David Froble's concerns, if you're not interested in porting off
of OpenVMS (and assuming OpenVMS isn't itself ported), and you're not
looking for a 32-socket Big Box to use for hardware emulation, then
Project Odyssey (or a ProLiant DL-whatever Gen-whatever box) probably
won't be particularly interesting to you.

And no, I'm not looking to supplant HP's marketing group here.
Discussing that possibility would be entirely "PREMA-ture", of course.

[David Froble]

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 ....

[Howard S Shubs]

In article <jqvn1a$af7$1...@dont-email.me>,

David Froble <da...@tsoft-inc.com> wrote:

> So my question remains, what good is all this junk to those who cannot use it
> ?????

Perhaps people in your position need to learn Linux and start porting.

--
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

[JF Mezei]

John Wallace wrote:

> Why would anyone interested in a Xeon-based "high-scale multiple-
> socket configuration" want to wait for Odyssey?

because you will be able to populate that superdome with some IA64
blades to run your legacy VMS or HPUX code, and some 8086 blades to run
your new software as your port from the old to the new.

As your requirements for IA64 go down, you pull those blades out and
replace with 8086 blades.

Whether the economics of this will work for most customers or just a few
with specific needs remains to be seen. It might be more cost efficient
to keep your existig VMS systems and just buy standard 8086 servers that
are separate.


Once HP fesses up to its plans to EOL IA64 and HP-UX/VMS/NSK, then it is
very likely to also announce some porting help and varous retention
deals to help existing customers stay with HP. Those deals wil involve
some seriously reduced pricing on the new superdomes.

[JF Mezei]

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.

[David Froble]

Howard S Shubs wrote:
> In article <jqvn1a$af7$1...@dont-email.me>,
> David Froble <da...@tsoft-inc.com> wrote:
>
>> So my question remains, what good is all this junk to those who cannot use it
>> ?????
>
> Perhaps people in your position need to learn Linux and start porting.
>

Perhaps people in my position should say "screw it" and take a long vacation ..

[JF Mezei]

Howard S Shubs wrote:

> Perhaps people in your position need to learn Linux and start porting.
>

That is the sad conclusion I have come to some time ago. And thanks to
Oracle, I suspect it is becoming more and more obvious to the VMS community.


Consider this: if HP had plans to port its OS to x86, it would have done
so ASAP so that it could shorten the costly contract with Intel to keep
IA64 on life support.

But if you are planning to EOL the OS when Itanium is ended, then you
want to stretch the life of all that ecosystem as long as possible and
not tell anyone that that ecosystem's future has been decided and it
involves and EOL soon. This allows naive customers to continue to pay HP
lots of money and delays the migration to other vendors when they find
out they have been screwd and lied to by HP.

HP has steadfastedly denied it would port its OS to x86. And Tukwila,
Poulson and Kittson will all ave arrived very late in order to stretch
the remaining life of IA64.

Howver, with the rapidly declining BCS sales, HP may be forced to
rethink its plans. If the OS aren't ported, then HP will have to help
customers migrate to Linux. And the sooned HP announces this, the more
customers it can retain.

[Howard S Shubs]

In article <4fd42319$0$1580$c3e8da3$92d0...@news.astraweb.com>,

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

> Howard S Shubs wrote:
>
> > Perhaps people in your position need to learn Linux and start porting.
>
> That is the sad conclusion I have come to some time ago. And thanks to
> Oracle, I suspect it is becoming more and more obvious to the VMS community.

Alternatively, if HP made "OpenVMS" actually open, as in open source, I
think we'd all just team up to port it and have done. I expect several
participants in this group are up for it. I know *I* am. and we'd
probably have no shortage of experienced former VMS team members who
were interested.

> Howver, with the rapidly declining BCS sales, HP may be forced to
> rethink its plans. If the OS aren't ported, then HP will have to help
> customers migrate to Linux. And the sooned HP announces this, the more
> customers it can retain.

I have a friend who used to be all about VMS all the time. He can no
longer find work reliably with VMS. If he can't, and I can't, don't be
too surprised if you can't. Which means it doesn't matter much what HP
does. I found my level of caring degraded drastically recently.

If they won't open source VMS, VMS ends up in the dust bin containing
all sorts of other no-longer-supported OSs. I find it sad, as I really
adored the os, but I'm not in a position to do anything about it, and
jobs really aren't there for it anyway. So to stay in IT, it's time to
find a new "home" OS. Right now, that's looking like Linux. I just
wish the programming tools there were closer in efficiency to VMS. :-/

And the web. Don't forget the web. I wish the web had debugging tools,
period. Last I looked, it only had the oldest kind of crude debugging
tools. I've been missing the debugging tools from VMS for years.

[Howard S Shubs]

In article <jr17lj$le2$1...@dont-email.me>,
David Froble <da...@tsoft-inc.com> wrote:

> Howard S Shubs wrote:

> > Perhaps people in your position need to learn Linux and start porting.

> Perhaps people in my position should say "screw it" and take a long vacation

Wouldn't that be nice.

[Howard S Shubs]

In article <jr0mal$97e$1...@dont-email.me>,

David Froble <da...@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.

[Richard Maher]

"Howard S Shubs" <how...@shubs.net> wrote in message
news:howard-D5DA5B....@news.giganews.com...

> In article <4fd42319$0$1580$c3e8da3$92d0...@news.astraweb.com>,
> JF Mezei <jfmezei...@vaxination.ca> wrote:
>
>> Howard S Shubs wrote:
>>

>
> I have a friend who used to be all about VMS all the time. He can no
> longer find work reliably with VMS. If he can't, and I can't, don't be
> too surprised if you can't.

Who can?

> Which means it doesn't matter much what HP
> does. I found my level of caring degraded drastically recently.
>
> If they won't open source VMS, VMS ends up in the dust bin containing
> all sorts of other no-longer-supported OSs. I find it sad, as I really
> adored the os, but I'm not in a position to do anything about it, and
> jobs really aren't there for it anyway. So to stay in IT, it's time to
> find a new "home" OS. Right now, that's looking like Linux. I just
> wish the programming tools there were closer in efficiency to VMS. :-/

For too many years VMS was run as a gravy train for the inner-circle, and
still is :-(

There was/is a lot of filth in VMS that won't let a single cent/penny go
outside their vested interest regardless of merit.

>
> And the web. Don't forget the web. I wish the web had debugging tools,
> period.

Browsers now have fantastic debigging tools! With the likes of Javascript,
HTML5, XHR2 etc debugging the server is up to you and the language/framework
used. The client is sorted. (Have you noticed that even with the
reponse-format/type blob options with XHR2 and the pitiful Websockets,
nothing comes close to a native full-duplex connection-oriented binary
Socket?)

Cheers Richard Maher

[John Wallace]

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'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.

[Jan-Erik Soderholm]

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.

[ChrisQ]

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

[Stephen Hoffman]

On 2012-06-10 04:24:29 +0000, JF Mezei said:

> 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.

The existing OpenVMS system bootstrap output - the text chunder that
even a normal OpenVMS bootstrap generates - is very rough, murky,
overly text-heavy and arcane, whether you compare it to an OS X
bootstrap or a Linux bootstrap. But I digress.

The majority of rack-n-stack servers sold today are designed to run
headless and lights-out, and where USB and video are only rarely
connected. If these I/O devices are ever connected.

The more interesting (and more complex) portions of a port lurk witin
the memory management model and implementation, the interrupts and
interlocking, and the rest of the underpinnings of the kernel.

Getting the operating system code loaded and the basic I/O is
comparatively easy (within the context of an OS port), and something
that the firmware increasingly deals with on behalf of the OS. Whether
via iLO using tftp or xmodem or whatever normal or inevitably abnormal
and screw-ball stuff that a particular box happens to implement. And
whether UEFI/EFI or BIOS, serial or USB, remote management, video/RDP,
all of these are surmountable.

Apparent technical feasibility aside, OpenVMS isn't going to get ported
without also providing a way for HP to recoup the investment, and with
sufficient profit, and in comparison with the other investments that
are available to a corporation the size of HP. Whether enough folks
would buy enough ProLiant-specific OpenVMS servers, software and
related products.

And then there are the considerations around whether and which
third-party vendors would port their products. Whether those vendors
expect to see sufficient profits from that investment. Whether the
applications that the OpenVMS customers need would be available.

[VAXman-]

In article <jr2ec7$hqv$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>On 2012-06-10 04:24:29 +0000, JF Mezei said:
>
>> 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.
>
>The existing OpenVMS system bootstrap output - the text chunder that
>even a normal OpenVMS bootstrap generates - is very rough, murky,
>overly text-heavy and arcane, whether you compare it to an OS X
>bootstrap or a Linux bootstrap. But I digress.

I'd beg to differ.

Disabling of 'splash' and 'silent' during Linux bootstrapping will exude
far more text-heavy, arcane "chunder" than one would see during a normal
VMS bootstrap.

I boot my Linux laptops with no splash and no silent because I prefer to
see things happening instead of some image screen and some dumb spinning
or a Battlestar Galactica Cyclon scanning graphic; especially, if there's
a 'fsck' being done/forced after X number of reboots. My Linux servers
don't have graphics and thus, I see Proustian novels of textual "chunder"
when they boot.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[Stephen Hoffman]

You're far too experienced here, Brian. (Not that that's a bad thing.)

I'd rather have less output for a less-experienced operator, at least
until I get errors.

And for myself, too, for that matter.

Just shut up and boot.

But if the boot should fail, general information that is suitable for
the system operator around the failure.

And certainly for the technician (whether a more experienced operator
or a specialist), access to the logs from the failure, and to a
verbose-bootstrap mode.

Spotting an error in the usual chunder of a OpenVMS startup log either
means implementing specific scanning tools, or more work than I'd
prefer to expend reviewing the startup, or (as often happens) simply
ignoring the chunder (and any potential errors) until something (else)
is noticed.

Computers are getting simpler to operate and to maintain, and where
problems are forwarded to specialists (via syslog or crashdump logs or
otherwise), and that UI trend is only going to accellerate. If you
want to compete (you know, revenue and all) displaying thousands of
lines of verbal chunder to the typical end-user isn't beneficial. And
you're not the usual end-user, Brian.

[MG]

On 10-6-2012 18:09, VAXman- @SendSpamHere.ORG wrote:
> I'd beg to differ.
>
> Disabling of 'splash' and 'silent' during Linux bootstrapping will exude
> far more text-heavy, arcane "chunder" than one would see during a normal
> VMS bootstrap.

That's my experience also.

- MG

[JF Mezei]

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.

[JF Mezei]

Stephen Hoffman wrote:

> Apparent technical feasibility aside, OpenVMS isn't going to get ported
> without also providing a way for HP to recoup the investment,

Correct. However, consider the possibility that ending IA64 sooner may
save HP enough money to port its operatings systems to x86.

Forget kittson and kittson+, and just do a poulson+ (like EV7z). Save a
bundle of money which can be used to port VMS and HP-UX and NSK. This
would enable HP to retain more customers than its current path of
forcing them to port to Linux instead of migrate fro IA64 to x86 on the
same OS.

[Stephen Hoffman]

Um, so we're on a race to implement the most impenetrable,
unmaintainable, infathomable and possible worst of all possible user
interfaces imaginable? If that's the goal, tthen that's easy. Set
startups for maximum verbose! Have Dark Helmet set the chunder
generators for insane speed!

But slightly more seriously, the VMS startup user interface is crap, in
simplest terms. It was sufficient in the 1970s and 1980s (I might
hesitate to use "good" here), but the startup implementation hasn't
adapted to the needs of the current users.

The SYSMAN startup was an attempt to address part of this mess, but
OpenVMS Engineering and the layered product teams and the third-party
folks never managed to deal with the dependencies that resulted. (And
the SYSMAN startup can still generate too much chunder.)

[JF Mezei]

Stephen Hoffman wrote:

> You're far too experienced here, Brian. (Not that that's a bad thing.)

I am nowhere near Mr VAXman's the kernel hacking expertise, and I choose
to have my macs boot with "-v" (verbose) so I do get to see what goes
on. It has save me a few times where the boot would get stuck and I knew
exactly where it got stuck.

However, I cannot do this for my headless server because Apple disabled
the use of the serial port for console. If that server ever has
problems, I have to physically plug a monitor and keyboard to see what
happens.

The various remote screen access technologies VNC or Apple's own don't
work that early in the boot cycle since it requires software running.

[Stephen Hoffman]

On 2012-06-10 19:16:52 +0000, JF Mezei said:

> Stephen Hoffman wrote:
>
>> You're far too experienced here, Brian. (Not that that's a bad thing.)
>
>
> I am nowhere near Mr VAXman's the kernel hacking expertise, and I choose
> to have my macs boot with "-v" (verbose) so I do get to see what goes
> on. It has save me a few times where the boot would get stuck and I knew
> exactly where it got stuck.

So? If you want technician-level access and logs, have at.

I don't find the VMS startup implementation at all suitable for use by
inexperienced users.

Nor do I find a verbose bootstrap on an OS X box generally appropriate
for such users, either.

> However, I cannot do this for my headless server because Apple disabled
> the use of the serial port for console. If that server ever has
> problems, I have to physically plug a monitor and keyboard to see what
> happens.
>
> The various remote screen access technologies VNC or Apple's own don't
> work that early in the boot cycle since it requires software running.

The Apple Xserve LOM features are far more limited than those of an HP
iLO series management processor.

The LOM provides rudimentary access into the BMC, power, status and a
few other details are available.

In addition to the HP iLO (and iLO 2, iLO 3, iLO 4) implementation,
various IBM servers use RSA and RSA II, Dell has DRAC available, and
other vendors have their equivalents. Versions of iLO and DRAC can
redirect media devices; you can use a local disk as if it were attached
to the server. Video, as well. HP calls this feature stuff vKVM
<http://h71000.www7.hp.com/openvms/journal/v15/vkvm_ovms.pdf>.
(Versions of the IBM RSA boards probably also have these features, but
I'm not as familar with the IBM servers.)

With iLO and other management processors, a web interface is typically
available, and iLO offers telnet or (at extra cost) ssh connections
into the three consoles; the iLO MP console, the BMC, and the EFI level.

With an HP server lacking iLO, you're limited to serial access to the
BMC and EFI.

With Xserve, the front panel hardware diagnostics and the hardware
diagnostics DVD do a good job, based on the Xserve repairs I've worked.
Different solution.

Console I/O is not going to be an issue with any hypothetical port of
OpenVMS. This given the simple expedient of "buy boxes with a
management processor" being an option for the initial port. Or more
recently, "acquire decent virtual machine to host the port".

The ability to bulk load or bulk unload memory using firmware or a
management processor or a VM is a very useful capability when doing
low-level work, too. But I digress.

But if the x86-64 port of OpenVMS is your goal, then consider helping
HP figure out how they can make (more) money with the port (than with
their available alternative investments), and (for now) spend less time
worrying about the technical details of the port. Or figure out how
you can buy or otherwise "spin off" OpenVMS from HP. Etc.

[Richard B. Gilbert]

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".

[glen herrmannsfeldt]

Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:

(snip)

> With an HP server lacking iLO, you're limited to serial access to the
> BMC and EFI.

Which reminds me, I have an RX2600 that I bought without management,
installed VMS using the serial port console, then added a
managment card. VMS doesn't know about the managment, and so
still wants to use the serial port.

Can I tell VMS to use the management board without reinstalling?

-- glen

[Stephen Hoffman]

On 2012-06-10 21:26:30 +0000, glen herrmannsfeldt said:

> ...an RX2600 that I bought without management,

> installed VMS using the serial port console, then added a
> managment card. VMS doesn't know about the managment, and so
> still wants to use the serial port.
>
> Can I tell VMS to use the management board without reinstalling?

Mayhap <http://labs.hoffmanlabs.com/node/1132> helps?

[David Froble]

I can understand that when you flip the switch you just want the light bulb to start
producing light. You don't really need to have a running commentary of the power up sequence.

I've implemented some verbose switch settings in services that I've implemented. It's
just another parameter. I've also implemented the re-setting of the switch when something
unexpected occurs. It's like "don't show me anything unless I need to see it".

Regardless, as I've mentioned before "I'm old enough" that I'm used to seeing the boot
sequence on a computer, and I don't know if I could get used to a "quiet boot". I'd
probably think something went amiss.

[David Froble]

Oh, come on Steve, that's an opinion, and we all are entitles to have some. No guarantee
that others will agree with personal opinions, but isn't that what "viva le difference"
(or however it's spelled) all about.

I'm perfectly happy with the serial interface VMS bootstrap dialogue. It's simple. It
works. It doesn't need anything more than a serial character cell terminal or emulator.

[johnso...@gmail.com]

On Sunday, June 10, 2012 3:51:46 PM UTC-4, Stephen Hoffman wrote:

> But if the x86-64 port of OpenVMS is your goal, then consider helping
> HP figure out how they can make (more) money with the port (than with
> their available alternative investments), and (for now) spend less time
> worrying about the technical details of the port. Or figure out how
> you can buy or otherwise "spin off" OpenVMS from HP. Etc.

I suspect the OpenVMS ecosystem is too small and diffuse to sustain yet
another migration. The % of folks who stayed on Alpha seems pretty high.
As much as I think a port to x86 is the right technological move for the
ailing operating system, I just can't see it making a profit for HP that
would justify the needed management focus.

The choices for VMS based systems that still have their best years ahead
of it are pretty thin.

EJ

[Stephen Hoffman]

On 2012-06-10 21:36:59 +0000, David Froble said:
>
>
> Regardless, as I've mentioned before "I'm old enough" that I'm used to
> seeing the boot sequence on a computer, and I don't know if I could get
> used to a "quiet boot". I'd probably think something went amiss.

Trust me: you can.

It's very easy to get to the "Boot chunder? {Expletive} Something
must have blown up. {Expletive}" stage.

It's even nicer when the stuff blows up and then either spares or fixes
itself, or blows up and points you at the errant hardware with a nice
flashing "fix me" indicator.

Software is vastly tougher to get and keep simple, but it's usually
possible. (Enterprise software tends to be particularly bad in this
regard, but I digress.) Having an on-line updating mechanism is
something that should be familiar to most anyone reading here, but
OpenVMS still lacks that. No built-in hardware or software
error-reporting mechanisms to catch and (optionally) ship the dump
files off to your local IT, to VAXman or JF, or to HP, either. Which
means that nobody knows what the most common errors might be, nor what
versions are in use, nor is there an easy way to determine what's
current, etc.

But again, it's all about the revenue potential... If the revenue
isn't there, then updates come only when somebody's own particular
"itch" needs scratching. If then.

[Simon Clubley]

On 2012-06-10, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2012-06-10 18:48:21 +0000, MG said:
>
>> On 10-6-2012 18:09, VAXman- @SendSpamHere.ORG wrote:
>>> I'd beg to differ.
>>>
>>> Disabling of 'splash' and 'silent' during Linux bootstrapping will exude
>>> far more text-heavy, arcane "chunder" than one would see during a normal
>>> VMS bootstrap.
>>
>> That's my experience also.
>
> Um, so we're on a race to implement the most impenetrable,
> unmaintainable, infathomable and possible worst of all possible user
> interfaces imaginable? If that's the goal, tthen that's easy. Set
> startups for maximum verbose! Have Dark Helmet set the chunder
> generators for insane speed!
>

Go and install OpenBSD. By the time you get through it's fdisk section,
you will have a new candidate for the worse user interface ever
created. :-)

That's coming from someone who prefers to use the Linux command line
partition tools instead of the GUI tools...

BTW, the console problem is easy enough to fix without needing a GUI
to do VMS work as you can just do what Linux does and implement a VT100
emulator in the console driver.

As a test, I'm using it to compose this message in TPU in EDT keypad mode
and although line drawing characters are missing, it works just fine,
including the keypad, which makes it better than many of the open source
so called terminal emulators. :-)

Simon.

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

[Simon Clubley]

On 2012-06-10, JF Mezei <jfmezei...@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.

[JF Mezei]

johnso...@gmail.com wrote:

> As much as I think a port to x86 is the right technological move for the
> ailing operating system, I just can't see it making a profit for HP that
> would justify the needed management focus.

Perhaps you need to look at it from a different point of view: a port to
8086 might result in smaller losses than forcing VMS to hit the
cul-de-sac. The later will cause a big loss of customers and some
lenghtened and costly IA64 life support to pretend it isn't dead.

Someone whould hire Karl Urban (since DeForest Kelley has passed away)
to point to IA64 and say "It's dead Jim" :-) Maybe HP would get the
message. There is no point in pretending it is alive anymore, everyone
knows it is on life support and that HP still says it has no porting
intentions for its operating systems.

HP may have built lifeboats but as long as they remain hidden away with
no clear guidance for HP customers to use those lifeboats to leave the
sinking Itanic, they will use other company's lifeboats.


HP needs to make it easier to move from legacy BCS to new BCS platforms
than it is to move to other vendor's platforms. As long as HP refuses to
admit IA64 is dead and delays announcing plans to help customers move to
Linux, HP will continue to bleed BCS at 20% rate.


Since HP has known this day would come for years, if it doesn't have
plans already, then it is truly incompetent.

At least when the Curly announced he had murdered Alpha, he did announce
the "Alpha Retain Trust" programme. Not sure how effective or helpful it
was, but it was at least some admission that they needed to help
customers weather this terrible news and give them a lot of financial
breaks because of that stupid decision.

[JF Mezei]

Stephen Hoffman wrote:

> regard, but I digress.) Having an on-line updating mechanism is
> something that should be familiar to most anyone reading here, but
> OpenVMS still lacks that. No built-in hardware or software
> error-reporting mechanisms to catch and (optionally) ship the dump
> files off to your local IT, to VAXman or JF, or to HP, either.

Considering the limited development budgets for VMS in the last 10
years, with much of it spent porting to IA64, it is no surprise that VMS
lacks such software update mechanism.

Then again, with HP's business practices that prevent access to patches,
such upgrade mechanism might not work anyways.

[JF Mezei]

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)

[Stephen Hoffman]

On 2012-06-11 00:17:22 +0000, Simon Clubley said:

> On 2012-06-10, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>> On 2012-06-10 18:48:21 +0000, MG said:
>>
>>> On 10-6-2012 18:09, VAXman- @SendSpamHere.ORG wrote:
>>>> I'd beg to differ.
>>>>
>>>> Disabling of 'splash' and 'silent' during Linux bootstrapping will exude
>>>> far more text-heavy, arcane "chunder" than one would see during a normal
>>>> VMS bootstrap.
>>>
>>> That's my experience also.
>>
>> Um, so we're on a race to implement the most impenetrable,
>> unmaintainable, infathomable and possible worst of all possible user
>> interfaces imaginable? If that's the goal, tthen that's easy. Set
>> startups for maximum verbose! Have Dark Helmet set the chunder
>> generators for insane speed!
>>
>
> Go and install OpenBSD. By the time you get through it's fdisk section,
> you will have a new candidate for the worse user interface ever
> created. :-)

Achieving a truly pessimal UI design is a never-ending quest.

Computers are supposed to work, and we geeks then all spend our time
and effort generating chunder for debugging, and which unfortunately
often gets left displayed when the computer is working correctly.

Windows XP and its sequence of dialogs when you connect a USB flash
drive. Better to have a case of inserting the USB disk, and it's ready
to use. Or you get a dialog (only) when something stuffs up.

Loquacious startups are an unnecessary load on the end-users.

>
> BTW, the console problem is easy enough to fix without needing a GUI
> to do VMS work as you can just do what Linux does and implement a VT100
> emulator in the console driver.

VMS has VT52 in some of its console drivers, but the concern that JF
made was low-level access specifically for a port. During the earliest
parts of an operating system port, there isn't a (functional) console
driver. Well, not in the olden days - back when VMS was ported to
Itanium, for instance - where now there'd likely be a virtual machine
or some console firmware that would provide at least some of that sort
of access in more recent systems.

[Howard S Shubs]

In article <jr1mke$b7k$1...@speranza.aioe.org>,
"Richard Maher" <mahe...@hotspamnotmail.com> wrote:

> Browsers now have fantastic debigging tools! With the likes of Javascript,
> HTML5, XHR2 etc debugging the server is up to you and the language/framework
> used. The client is sorted. (Have you noticed that even with the
> reponse-format/type blob options with XHR2 and the pitiful Websockets,
> nothing comes close to a native full-duplex connection-oriented binary
> Socket?)

Just goes to show how much I have yet to learn.

--
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

[johnso...@gmail.com]

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

> Perhaps you need to look at it from a different point of view: a port to
> 8086 might result in smaller losses than forcing VMS to hit the
> cul-de-sac. The later will cause a big loss of customers and some
> lenghtened and costly IA64 life support to pretend it isn't dead.

Perhaps. But in a way, it doesn't matter whether that's true or not because
HP is stuck holding the Itanium bag. HP's lawsuit with Oracle requires them
to stay the Itanium course until that's resolved. I'd like to think Oracle
is smart enough to see this and intends to drag this thing out for as long
as possible.

At this point, HP's best move would be to bail on the lawsuit, sell the
VMS properties on someone like Computer Associates, and refocus
on acquiring startups. VMS can't get any real love until its a big fish
in a small pond.

EJ

[johnso...@gmail.com]

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

[Michael Kraemer]

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]

JF Mezei schrieb:

> Perhaps you need to look at it from a different point of view: a port to
> 8086 might result in smaller losses than forcing VMS to hit the
> cul-de-sac. The later will cause a big loss of customers and some
> lenghtened and costly IA64 life support to pretend it isn't dead.

What losses?
The Oracle/HP documents teach us that VMS generates less than
$100M revenue, with an estimated profit of less than $10M.
These $10M are all HP has to lose, at the maximum.
Even if no more Itanics are being made after the current
generation, customers stranded on the Itanic will continue
to pay support $$$, just as they do now for VMS/Alpha and
even VAX/VMS, which is far more outdated than Itanic.
Can't be any better for HP: zero development costs,
a few support engineer's salaries, but steadily flowing income,
that's easy money to collect.

> HP may have built lifeboats but as long as they remain hidden away with
> no clear guidance for HP customers to use those lifeboats to leave the
> sinking Itanic, they will use other company's lifeboats.

HP's "Odyssey" announcement made it pretty clear what the lifeboats
are.

[Joseph Huber]

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

[VAXman-]

In article <jr2rm3$bbp$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>On 2012-06-10 18:48:21 +0000, MG said:
>

>Um, so we're on a race to implement the most impenetrable,
>unmaintainable, infathomable and possible worst of all possible user
>interfaces imaginable? If that's the goal, tthen that's easy. Set
>startups for maximum verbose! Have Dark Helmet set the chunder
>generators for insane speed!

That was not the intent of my comment WRT "chunder" being emanated during
system startups. I was merely pointing out that being suppressed and or
hidden by a graphic screen doesn't correlate to VMS being more verbose in
the text-heavy, arcane "chunder " department. The startup logorrhea can
be suppressed in VMS startups too.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[MG]

On 10-6-2012 21:14, Stephen Hoffman wrote:
> But slightly more seriously, the VMS startup user interface is crap[.]

No, sorry, I disagree.

- MG

[MG]

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

[ChrisQ]

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

[ChrisQ]

On 06/11/12 01:37, johnso...@gmail.com wrote:

> At this point, HP's best move would be to bail on the lawsuit, sell the
> VMS properties on someone like Computer Associates, and refocus
> on acquiring startups. VMS can't get any real love until its a big fish
> in a small pond.
>
> EJ

Probably right, but a better way to save bcs and the customers would be to
spin off bcs into a separate company, inject serious capital and grow a
development team to design and build innovative, competitive product.
Technical leadership, honest marketing and quality are all that's needed.
The product will sell itself. Vms could have a place in all this as well.

Hp did it with Agilent and it is still the most respected and technically
advanced measurements company in the world. They have not been tainted at
all by the trouble at hp, afaics...

Regards,

Chris

[John Wallace]

On Jun 11, 1:21 pm, ChrisQ <m...@devnull.com> wrote:

Wise words re the spinoff and Agilent. But Agilent is a company which
has technical people designing products which are bought by technical
people. Most of the IT sector hasn't been like that for a long time,
especially so in software.

[Stephen Hoffman]

Ok... So convince me that the OpenVMS startup user interface is not a
crap design for end-users.

[Stephen Hoffman]

On 2012-06-11 11:50:41 +0000, MG said:

> 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?

Because even the grizzled fossil-vintage OpenVMS users can and have
learned things even from folks that don't use VMS.

Different approaches, and different tools and different experiences are
used in different contexts.

We can definitely learn from the new OpenVMS users -- new users are an
absolute gold-mine of feedback for incorporation into UIs and
documentation, too.

And the greyhairs around here can learn from each other, of course.

One problem with ignoring somebody is that even a complete fool can
come up with a good idea once in a while. The fool might not realize
it, of course. And JF is no fool.

>
> 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?

Based on that, you'd probably really like VWS. That's even lighter,
faster, and the pieces and parts are yet smaller.

As for X, I'd like to have newer X11 and newer X-related APIs, as
porting stuff over is headed in the wrong direction.

> Binaries also tend to be very compact (compared to Qt, GTK+ and the
> other common frameworks).

Have you built an X interface application on VMS? Try it sometime. If
you don't have BX or VUIT around, it's a real a slog.

[Bob Koehler]

In article <jquhff$ike$1...@dont-email.me>, David Froble <da...@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?

[Bob Koehler]

In article <4fd4ebf8$0$6903$e4fe...@news2.news.xs4all.nl>, MG <marc...@SPAMxs4all.nl> writes:
> On 10-6-2012 18:09, VAXman- @SendSpamHere.ORG wrote:
>> I'd beg to differ.
>>
>> Disabling of 'splash' and 'silent' during Linux bootstrapping will exude
>> far more text-heavy, arcane "chunder" than one would see during a normal
>> VMS bootstrap.
>
> That's my experience also.
>

I can remember when I went through AUTOEXEC.BAT on my MS-DOS systems
redirecting all the advertizing banners to NUL. It looked better and
I think it started faster.

Then we installed something that barfed up a banner from CONFIG.SYS,
where you couldn't redirect.

[Bob Koehler]

In article <4fd54599$0$3988$c3e8da3$b23f...@news.astraweb.com>, JF Mezei <jfmezei...@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.

[John Smith (who cares if I'm the one @ HP - if here's even still there)]

"Keith Parris" <keithparris...@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.

[John Smith (who cares if I'm the one @ HP - if here's even still there)]

"Howard S Shubs" <how...@shubs.net> wrote in message
news:howard-D5DA5B....@news.giganews.com...
> In article <4fd42319$0$1580$c3e8da3$92d0...@news.astraweb.com>,
> JF Mezei <jfmezei...@vaxination.ca> wrote:
>
>> Howard S Shubs wrote:
>>
>> > Perhaps people in your position need to learn Linux and start porting.
>>
>> That is the sad conclusion I have come to some time ago. And thanks to
>> Oracle, I suspect it is becoming more and more obvious to the VMS
>> community.
>
> Alternatively, if HP made "OpenVMS" actually open, as in open source, I
> think we'd all just team up to port it and have done. I expect several
> participants in this group are up for it. I know *I* am. and we'd
> probably have no shortage of experienced former VMS team members who
> were interested.
>
>
>> Howver, with the rapidly declining BCS sales, HP may be forced to
>> rethink its plans. If the OS aren't ported, then HP will have to help
>> customers migrate to Linux. And the sooned HP announces this, the more
>> customers it can retain.
>
> I have a friend who used to be all about VMS all the time. He can no
> longer find work reliably with VMS. If he can't, and I can't, don't be
> too surprised if you can't. Which means it doesn't matter much what HP
> does. I found my level of caring degraded drastically recently.
>
> If they won't open source VMS, VMS ends up in the dust bin containing
> all sorts of other no-longer-supported OSs. I find it sad, as I really
> adored the os, but I'm not in a position to do anything about it, and
> jobs really aren't there for it anyway. So to stay in IT, it's time to
> find a new "home" OS. Right now, that's looking like Linux. I just
> wish the programming tools there were closer in efficiency to VMS. :-/
>
> And the web. Don't forget the web. I wish the web had debugging tools,
> period. Last I looked, it only had the oldest kind of crude debugging
> tools. I've been missing the debugging tools from VMS for years.

I'm absolutely positive (NOT) that tens of thousands of script-kiddies would
just love to port/write dreck code into VMS for free.

What would be useful is if HP paid former VMS o/s engineers to do the work,
ie. give Hoff a wheelbarrow full of cash to pick and choose/manage the best
VMS engineers to write/port the missing bits properly, and then to spend
additional money adding new features.

Of course, without a real commercially acceptable RDBMS available, why
bother. Do you think Oracle would supply RdB much longer if HP open-sourced
VMS?

[Stephen Hoffman]

On 2012-06-11 16:10:00 +0000, John Smith \(who cares if I'm the one @

HP - if here's even still there\) said:
> What would be useful is if HP paid former VMS o/s engineers to do the
> work, ie. give Hoff a wheelbarrow full of cash to pick and
> choose/manage the best VMS engineers to write/port the missing bits
> properly, and then to spend additional money adding new features.
>
> Of course, without a real commercially acceptable RDBMS available, why
> bother. Do you think Oracle would supply RdB much longer if HP
> open-sourced VMS?

A port? Assuming a BCS spin-off or a purchase or a resurgence of
interest in OpenVMS development within HP (or whatever), it'd require a
whole lot of engineering. While AFAIK, there is nothing here that is
technically infeasible, the x86-64 port would perturb several core
subsystems and various kernel-code, and possibly in a big way.

The port would freeze much of the environment for several years, and
the competition is not slowed,

My longstanding preference for VMS would have included an integrated
database years ago (whether the then-current "embedded" Rdb run-time,
or otherwise), as various of the problems the VMS tools have with files
and online backups of core files and some other related problems are
problems that were solved by databases generations ago.

Assuming the requisite fleet of trucks stuffed with cash can be found,
PostgreSQL and SQLite would be in the kit, or available for the kit.
(Details depending on the packaging and component licensing, etc.)

Moving the other features of OpenVMS forward (OpenSSL SSL/TLS, IPsec,
C99 & C11, replacing the CDSA framework, iSCSI, integrating LDAP, etc)
would require multiple additional truck-sized distributions of cash.

A Mach kernel and more scalable multiprocessing would perturb things more.

How much the results of the port still look like VMS (or how far it's
diverged and how much more effort a VMS application port might be), and
particularly how competitive the resulting operating system is with
whatever is then-current Windows, Linux, z/OS, z/VM, etc...

It's just a trade-off based on what you have available for spare
truckloads of cash, with what you'll get for software, against what
sales and support contracts you'll be able to acquire for the effort.

[Bob Koehler]

In article <jr57rc$lt7$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>
> My longstanding preference for VMS would have included an integrated
> database years ago (whether the then-current "embedded" Rdb run-time,
> or otherwise), as various of the problems the VMS tools have with files
> and online backups of core files and some other related problems are
> problems that were solved by databases generations ago.

Not me. If there is a DBMS involved, it is an application I don't want
to work on. So I don't want to pay for it.

>

[Howard S Shubs]

In article <jr4qkc$ocj$1...@dont-email.me>,

OpenVMS console is not for end users. It's for system managers.

[Stephen Hoffman]

Punched cards FTW! :-)

[Stephen Hoffman]

On 2012-06-11 17:23:04 +0000, Howard S Shubs said:

> In article <jr4qkc$ocj$1...@dont-email.me>,
> Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
>> On 2012-06-11 11:44:03 +0000, MG said:
>>
>>> On 10-6-2012 21:14, Stephen Hoffman wrote:
>>>> But slightly more seriously, the VMS startup user interface is crap[.]
>>>
>>> No, sorry, I disagree.
>>
>> Ok... So convince me that the OpenVMS startup user interface is not a
>> crap design for end-users.
>
> OpenVMS console is not for end users. It's for system managers.

It's not even good enough for them. Not these days. It's certainly
not with what system administrators (as many are now called) expect.
Not if you want to hit enough volume in the market. It's much too
arcane. Too much hand work to manage it. Too easy to screw up. And
it's just too easy to miss errors or diagnostics within the blizzard of
chunder that's usually produced. There are other issues, too.

For us grey-hairs, yes, the existing console design is familiar, and it
works well enough, and we know were various of the foibles are.

But we're not the folks that are increasingly administering (managing)
these boxes.

[ChrisQ]

On 06/11/12 12:37, John Wallace wrote:

> Wise words re the spinoff and Agilent. But Agilent is a company which
> has technical people designing products which are bought by technical
> people. Most of the IT sector hasn't been like that for a long time,
> especially so in software.

I'm not involved in big business computing and you may be right, but tech
specialists must have input, otherwise the suits can't make appropriate
choices. What turns on techies ?. Cool, innovative products that stand
out from the crowd, are high performing and reliable.

I think the real problem is that hp are now too big to manage effectively
and need to be broken up so that the various identities know what market
they are serving. Consumer electronics needs a completely different approach
to professional computing and customer expectations are very different. How
can a single board have the depth of knowledge, big picture etc, to manage
that and deliver an appropriate long term strategy for each ?...

Regards,

Chris

[Jan-Erik Soderholm]

A big "pro" for VMS is the availability of Rdb. It's just sooo much
easier to work with compared with the bunch of indexed RMS files
we also have on your system...