OpenVMS & Poulson: We need facts!

[Olaf Leonhardt]

Hello my Friends
Hello Comunity

I ask Lorraine Bartlett what’s going on with Poulson for OpenVMS. I tell HP often (!!) how important Poulson and a real Roadmap (OpenVMS & Itanium) for my company is.
We spend since years a lot of money for HP’s Itanium and OpenVMS, like a lot of other customers (YOU!!)

So we can not be happy with political answer’s! We are expecting HP to commit to Poulson support for OpenVMS. Otherwise, we will consider this an end-of-life statement from HP.

If you are concerned about this, please send emails like my email below to ask for OpenVMS support on Poulson.

Please send emails like my email below to:

You should also tell people to send their mails to:

Lorraine Bartlett
lorraine...@hp.com
VP BCS Marketing + Strategy

Ric Lewis
ric....@hp.com
VP, BCS Hardware Systems Technology

Dave Donatelli
dave.do...@hp.com
Executive Vice President and General Manager Enterprise Group

I add Lorraines answer on my webside: www.OpenVMS-club.ch

Best regards Olaf


Von: Bartlett, Lorraine [mailto:lorraine...@hp.com]
Gesendet: Donnerstag, 16. Mai 2013 14:35
An: Leonhardt Olaf
Cc: 'nb...@connect-community.org'
Betreff: RE: OpenVMS

Hello Olaf.

I expect to deliver an update on our Project Odyssey roadmap including OpenVMS plans for Poulson by the end of the month.
I’m sorry you are unhappy with HP. We are doing the appropriate business analysis and customer assessment to ensure we make the best decisions.

Lorraine.

From: Leonhardt Olaf [mailto:Olaf.Le...@manor.ch]
Sent: Wednesday, May 15, 2013 6:44 AM
To: Bartlett, Lorraine
Subject: OpenVMS

Dear Lorraine

I am unhappy with your company. At the bootcamp you talk about poulson.
But nobody send me a commitment for poulson and OpenVMS.
We will working the next 10 Years with OpenVMS. But I need urgently a commitment.

Could you do this for me? For me it’s enough we recive Poulson in Q1 or Q2 2014. But a commitment
Is very important.

Best regards
Olaf

Freundliche Grüsse

Olaf Leonhardt
olaf.le...@manor.ch

[Howard S Shubs]

In article <888a5f6f-9c0d-45e6...@googlegroups.com>,

Olaf Leonhardt <leon...@juol.de> wrote:

> So we can not be happy with political answer’s! We are expecting HP to commit
> to Poulson support for OpenVMS. Otherwise, we will consider this an
> end-of-life statement from HP.

Linux is the way of the future! I happen to be available to do porting
work... :-D

[BillPedersen]

I think we should all be concerned that there is as of yet no release date for OpenVMS on Poulson! The hardware was released in November 2012! And here we are SIX MONTHS later with nothing.

This has not been what I would characterize as the "normal" release of hardware and operating system for either HP and definitely not looking at the history of new hardware targeted for VMS customers - one would have expected planning to have finished a year ago and the hardware and software available at nearly the same time.

I strongly suggest that people need to make their voices and plans known to HP! This is not something to be ignored. If you have ANY plans of using Poulson in the next couple years or more let them know!

Bill.

[Phillip Helbig---undress to reply]

In article <ac4fbdf0-fbee-4813...@googlegroups.com>,

BillPedersen <pede...@ccsscorp.com> writes:

> I strongly suggest that people need to make their voices and plans known to
> HP! This is not something to be ignored. If you have ANY plans of using
> Poulson in the next couple years or more let them know!

Let's face it: anyone who had serious plans for using Poulson in the
next couple of years, at least anyone large enough to matter to HP, has
already started moving away due to lack of commitment. A good example
of a self-fulfilling prophecy (don't commit then do the analysis and see
people moving away, so don't commit).

[Carl Karcher]

On Monday, May 20, 2013 12:19:18 PM UTC-5, BillPedersen wrote:

> I strongly suggest that people need to make their voices and plans known to >HP! This is not something to be ignored. If you have ANY plans of using >Poulson in the next couple years or more let them know!

Something else to note is the newer storage products like the StoreServ 7x00 also do not support OpenVMS.

EOL for VMS = EOL for HP products here.

[David Froble]

BillPedersen wrote:
> On Friday, May 17, 2013 4:26:56 PM UTC-4, Olaf Leonhardt wrote:
>> Hello my Friends
>>
>> Hello Comunity
>>
>>
>>

>> I ask Lorraine Bartlett what�s going on with Poulson for OpenVMS. I tell HP often (!!) how important Poulson and a real Roadmap (OpenVMS & Itanium) for my company is.
>>
>> We spend since years a lot of money for HP�s Itanium and OpenVMS, like a lot of other customers (YOU!!)
>>
>>
>>
>> So we can not be happy with political answer�s! We are expecting HP to commit to Poulson support for OpenVMS. Otherwise, we will consider this an end-of-life statement from HP.

>>
>>
>>
>> If you are concerned about this, please send emails like my email below to ask for OpenVMS support on Poulson.
>>
>>
>>
>> Please send emails like my email below to:
>>
>>
>>
>> You should also tell people to send their mails to:
>>
>>
>>
>> Lorraine Bartlett
>>
>> lorraine...@hp.com
>>
>> VP BCS Marketing + Strategy
>>
>>
>>
>> Ric Lewis
>>
>> ric....@hp.com
>>
>> VP, BCS Hardware Systems Technology
>>
>>
>>
>> Dave Donatelli
>>
>> dave.do...@hp.com
>>
>> Executive Vice President and General Manager Enterprise Group
>>
>>
>>
>> I add Lorraines answer on my webside: www.OpenVMS-club.ch
>>
>>
>>
>> Best regards Olaf
>>
>>
>>
>>
>>
>> Von: Bartlett, Lorraine [mailto:lorraine...@hp.com]
>>
>> Gesendet: Donnerstag, 16. Mai 2013 14:35
>>
>> An: Leonhardt Olaf
>>
>> Cc: 'nb...@connect-community.org'
>>
>> Betreff: RE: OpenVMS
>>
>>
>>
>> Hello Olaf.
>>
>>
>>
>> I expect to deliver an update on our Project Odyssey roadmap including OpenVMS plans for Poulson by the end of the month.
>>

>> I�m sorry you are unhappy with HP. We are doing the appropriate business analysis and customer assessment to ensure we make the best decisions.

>>
>>
>>
>> Lorraine.
>>
>>
>>
>> From: Leonhardt Olaf [mailto:Olaf.Le...@manor.ch]
>>
>> Sent: Wednesday, May 15, 2013 6:44 AM
>>
>> To: Bartlett, Lorraine
>>
>> Subject: OpenVMS
>>
>>
>>
>> Dear Lorraine
>>
>>
>>
>> I am unhappy with your company. At the bootcamp you talk about poulson.
>>
>> But nobody send me a commitment for poulson and OpenVMS.
>>
>> We will working the next 10 Years with OpenVMS. But I need urgently a commitment.
>>
>>
>>

>> Could you do this for me? For me it�s enough we recive Poulson in Q1 or Q2 2014. But a commitment

>>
>> Is very important.
>>
>>
>>
>> Best regards
>>
>> Olaf
>>
>>
>>

>> Freundliche Gr�sse

>>
>>
>>
>> Olaf Leonhardt
>>
>> olaf.le...@manor.ch
>
> I think we should all be concerned that there is as of yet no release date for OpenVMS on Poulson! The hardware was released in November 2012! And here we are SIX MONTHS later with nothing.
>
> This has not been what I would characterize as the "normal" release of hardware and operating system for either HP and definitely not looking at the history of new hardware targeted for VMS customers - one would have expected planning to have finished a year ago and the hardware and software available at nearly the same time.
>
> I strongly suggest that people need to make their voices and plans known to HP! This is not something to be ignored. If you have ANY plans of using Poulson in the next couple years or more let them know!
>
> Bill.

The last 5 people in India assigned to this project got better offers ..

[johnso...@gmail.com]

On Monday, May 20, 2013 3:31:27 PM UTC-4, David Froble wrote:

> The last 5 people in India assigned to this project got better offers ..

Are you describing something you know to be true or is that something
you would expect to be true?

EJ

[David Froble]

I know nothing.

I have heard some things, and one of those is that anyone competent in
India is in great demand, and there is a lot of poaching going on. Not
saying it's limited to there, it happens everywhere. But with the
influx of new work in that location, it's reasonable to assume that the
competent people are in very high demand, and are following the money,
ie; often switching jobs.

When VMS was first sent to India, some people were brought to the US for
something like 2 or 6 weeks of training. (Not that that is even a small
fraction of what should have been required.) I wonder how many of the
original people are still in the same job?

I would not be surprised to see the VMS jobs in India being a revolving
door. Not that I'd blame people for doing as well as they can for
themselves. And face it, HP didn't send the jobs there to pay high
wages ....

[keith...@gmail.com]

Jeff Jalbert posted the following on the OracleRdb mailing list:

From: Jeffrey S. Jalbert [mailto:je...@jcc.com]
Sent: Tuesday, May 21, 2013 3:33 PM
To: oraclerdb
Subject: EXT :RE: We need facts!

If you ever expect to upgrade your VMS system(s) to newer and current hardware I think you should take Mr. Leonhardt’s advice and send mail indicating how those plans would be affected by a decision to not support Poulson. I have come to the conclusion that we must act now while there is still a week or two do affect things.

What happens if VMS doesn’t get supported on Poulson? To my mind, that really is the end. VMS will be dead-ended on Tukwila, systems that HP will likely not even continue to sell beyond next year given that Poulson has been shipping since November of 2012. Current high-performance customers would have no place to go and many of them have no capability of waiting for the next generation. Besides, if HP doesn’t support Poulson, who can make business plans on the expectation that HP will support the next chip?

Ms. Bartlett says in her mail to Olaf that a decision will be announced by the end of this month. That leaves precious little time to make your voice heard. The time to act is clearly here.

I sat in the same VMS Boot camp keynote that Mr. Leonhardt was in and that triggered his note. That presentation was given by Ms. Bartlett.

I found a number of points in her presentation very disturbing, although I will admit that some others did not interpret her to be saying the same things I did. Her opening remarks were enough to put my teeth on edge though because she said that she was not there to announce the end of VMS. I remember well that DECUS Symposium in St. Louis when DEC announced the end of the DECsystem 20 product line. That was an awful time for DECsystem users.

What I did hear was that the HP strategy was to depend on the X86 architecture in its rollout. No, there was no mention by her about VMS on X86 but a number of people did mutter something about the number of Alpha emulator packages that would do that. To my mind, though, emulators can take us only so far when we need high-speed serial CPU cycles for the highest performance systems. Rdb folks are all aware of the deadly MPsynch issues and the Lock Manager. Hot standby is another example in Rdb land about the need for high-velocity CPU cycles given that it is single threaded single process.

During her presentation Ms. Bartlett commented that HP had only 2000+ VMS customers worldwide. That is a shockingly low number and I jotted it down just so I could recall it later. In fact, it is so low that one has to wonder whether the books are cooked or if alternatively HP doesn’t know who their customers really are. Many VMS systems and OpenVMS support contracts are sold through the big resellers, I know that we do not see HP sales teams come to our shop. I wonder whether they have folded those resellers as single point customers rather than as proxies for many/hundreds/thousands of customers behind the scenes. If that is true then HP is making decisions on really bad data.

During the questioning, one attendee asked about VMS on Poulson. I believe this was discussed in past VMS roadmap sessions. Her remark was most revealing. I am paraphrasing here: “We are in the process of reviewing whether we will do this.” I believe the audience felt as if they were hearing a retraction of past commitment, I certainly did. I also heard that there was a distinct possibility that they would not. I know others did so also from comments later in the Forum and from a particular denial presentation given by Keith Parris at the end of the week who predicted VMS activity past 2050.

When challenged on that point, Ms. Bartlett indicated that the “port” to Poulson was extremely difficult. That also floored me as I began to wonder whether there was some mysterious feature in the CPU that would make this so fearsome. I remember the days from VAX where a special CPU-dependent module was loaded whenever VMS booted. Unless I am wrong that sort of CPU dependence is history today, but I certainly could be wrong.

I decided that there had to be something special about the packaging of the Poulson chips themselves, perhaps something on the motherboard that would lead to such a state. I know that I would consider hanging any hardware engineer who would create such a situation though, given the short time frames in this market. There must be some really big advantage there, but I know not what that could be. Perhaps it could be left unsupported in the first release? We have had to deal with things like that in the past, after all we have been dealing with VMS since the late 70’s.

With no Poulson support, current high-performance customers have no place to go and many of them have no capability of waiting for the next generation. Besides, if HP doesn’t support Poulson, who can make business plans on the expectation that they will support the next chip? Since most of them are Oracle customers also it would seem to me natural that they would gravitate to platforms which support Oracle more intimately and perhaps even on the platform where Oracle is developed. I do not know. Perhaps some already have DB2 standards. Smaller databases will be attracted by MySQL, and there is also SQL Server out there.

No company should want to walk away from a sizeable revenue stream, especially when it shows revenue all over the place, in new systems of all sizes, in new software licenses and in very lucrative support contracts. That’s almost free money. HP would gain by increasing the volume of systems it is already manufacturing improving scale. It would gain new licenses. It would gain new support. It would support a committed customer base. It seems astounding to me that HP is willing to consider this over the cost of revising/rewriting an I/O driver or whatever it takes to make Poulson systems fully functional.

If you expect to be in the market for new gear I think you should take Mr. Leonhardt’s advice and send mail indicating how those plans would be affected by a decision to not support Poulson. As Mr. Leonhard mentioned, the appropriate contacts for these e-mails are:

Lorraine Bartlett
lorraine...@hp.com
VP BCS Marketing + Strategy

Ric Lewis
ric....@hp.com
VP, BCS Hardware Systems Technology

Dave Donatelli
dave.do...@hp.com
Executive Vice President and General Manager Enterprise Group

Dr. Jeffrey S. Jalbert
JCC Consulting, Inc.
P.O. Box 381
Granville OH 43023

[JF Mezei]

Sorry to barge in but:

> http://h30507.www3.hp.com/t5/Mission-Critical-Computing-Blog/bg-p/199/label-name/integrity%20servers


Go to the very bottom for the April 27th 2011 entry:

HP Integrity Lifecycle.

The graphs discuss ===> END OF SALES <=== for HP-UX and VMS.

OpenVMS 8.4 sales end mid 2015.

In the fine text, it says that VMS is "planned" for Poulson and if it is
ported to Poulson, end of sales will be pushed back to Poulson's end of
sales, end of CY2016. Otherwise end of sales remain at mid CY15.

I suspect that the "i2 server sales" refer to Tukwilla. Upgrades on
those available to 3rd quarter 2015, just after end of sales for VMS.


"OpenVMS 8.4 operating system sales and support are committed to be
aligned with sales of Poulson-based Integrity servers."

Whenever you see such "careful" wording, it means lawyers have been
involved to ensure there is no commitment, allowing HP to not port to
Poulson. If it is "committed", how come the VMS end of sale arrow
doesn't extend until end of sale of Poulson at end of CY 2016 ? Quite
the trustable commitment, isn't it ?




Another blog entry:
> http://h30507.www3.hp.com/t5/Mission-Critical-Computing-Blog/3-reasons-to-upgrade-to-HP-Integrity-during-2013/ba-p/130019#.UZxE1YLxGcc

3 reason to upgrade to HP INtegrity dueing 2013. VMS not mentioned once.




Fast forward to now, and we now get text such as "we're evauating
demand before deciding whether to port to Poulson". Forget "commit", it
isn't even a "planned" anymore. (Reminiscent on how HP handled it
promise to give VAX-VMS and 8.0 upgrade)

Downgrading from Committed to Planned to now "evaluating demand" is
corporate speak for "the port is already removed from our plans/budgets,
and unless you produce a purchase order for 200 million, we will
continue to state that there is no demand for VMS on Poulson to justify
our decision to not port which we will never announce."



When Capellas wanted to kill VMS in 2000, it was basically accountants
that told him that VMS was the cash cow that kept Compaq afloat and he
couldn't kill it. This is not the case at HP, especially as BCS sales
are tanking and HP still having to pay Intel for that Itanium
contraption. So contrary to Compaq in 2000, this time, it is to HP's
financial advantage to downsize the BCS albatros out of existance as
soon and smoothly as possible.


There are also interesting issues to consider:

Considering the capabilities and size of the indian VMS maintenance
group, would a a patched version of VMS with necessary kernel and other
low level changes to support new hardware result in so many bugs that
incremental support costs would exceed incremental profits from Poulson
sales ?

And with Kittson now just a glorified speed bump of Poulson, would
porting VMS to Poulson imply support on Kittson as well, and commit HP
to support VMS for a much longer time ?


Wake up and smell the coffee. VMS isn't being developped anymore. No new
version planned. Commitment to Kittson dead and buried, commitment to
Poulson likely already dead. End of sales already on powerpoint graphs.
Are people so blind that they can't see this ?

Heck, even Keith Paris made a powerpoint discussing the post VMS future
and he was representing HP.



And it makes business sense for HP to protect itself from upcoming BCS
losses. That is why they cut expenses (scaling back Kittson, no longer
developping VMS, and even HP-UX apparently without plans for a new version).

And if the largest remaining VMS customers can't get the real time of
day from HP about HP's real intentions for VMS what does it mean about
VMS' importance within HP ?


Remember how HP announced plans for all its OS except for VMS when it
announced its takeover of Compaq on Sept 7 2001 ? and we had to wait 9
months for the transaction to close before first mention of VMS' plans
in the famous Scott Stallard memo stating HP would support VMS customers
but expect them to migrate to HP-UX in their own due time.


Throughout the history of HP since it inherited VMS, HP has actually
been quite consistent: They will support the installed base of VMS but
have no desire to improve VMS or try to acquire new customers. Its
public statements (written or oral by execs) have been consistent with
this, always carefully worded to limit vMS to "we'll support pour loyal
installed base as long as they need VMS".

And keeping VMS stable without new development allows HP to collect
maintenance revenues without having to spend much to provide support.


And just like HP did for VAX-VMS, it will not formally announce it has
abandonned plans for VMS upgrades or support for new systems. And it
may quietly take VMS off the order books (end of sales) without anyone
noticing until much later.

It is a real shame that VMS' clustering technology and other features
that are still ahead of current systems are already fogotten by current
crop of IT specialists and CIOs.

I still have much respect for the real VMS engineers who managed to
developed a quality and serious operating system. And their standards
for quality, documentation and efficiency still influence me. despite
the pressure to move to bloatware and no longer think about efficiency.

Back to my cave. You may criticise me as much as you want.

[Michael Kraemer]

In article <kndnl5$7v5$2...@online.de>, hel...@astro.multiCLOTHESvax.de (Phillip
Helbig---undress to reply) writes:
> In article <ac4fbdf0-fbee-4813...@googlegroups.com>,

>
> Let's face it: anyone who had serious plans for using Poulson in the
> next couple of years, at least anyone large enough to matter to HP, has
> already started moving away due to lack of commitment.

Including Deutsche Boerse?

[Simon Clubley]

On 2013-05-21, keith...@gmail.com <keith...@gmail.com> wrote:
> Jeff Jalbert posted the following on the OracleRdb mailing list:
>

> During her presentation Ms. Bartlett commented that HP had only 2000+ VMS
> customers worldwide. That is a shockingly low number and I jotted it down
> just so I could recall it later. In fact, it is so low that one has to wonder

> whether the books are cooked or if alternatively HP doesn?t know who their
> customers really are.
>

In addition, I hope HP isn't assuming 1 customer = 1 system only.

>
> When challenged on that point, Ms. Bartlett indicated that the ?port? to

> Poulson was extremely difficult. That also floored me as I began to wonder
> whether there was some mysterious feature in the CPU that would make this so
> fearsome. I remember the days from VAX where a special CPU-dependent module
> was loaded whenever VMS booted. Unless I am wrong that sort of CPU dependence
> is history today, but I certainly could be wrong.
>

What is been left unspoken here is just _who_ the port is "extremely difficult"
for. Is it extremely difficult by the standards of the previous skilled and
experienced VMS Engineering team, or is it extremely diffcult by the standards
of some new and inexperienced team who might know very little about VMS or
the concepts involved in bringing it up on a new platform ?

I think HP need to state, with specific details, exactly why the port is so
difficult. Then we can judge if it's a new architecture issue that the old
team would have had problems with, or if it is in fact really a inexperienced
team issue.

Simon.

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

[johnso...@gmail.com]

> When challenged on that point, Ms. Bartlett indicated that the “port”
> to Poulson was extremely difficult. That also floored me as I began to
> wonder whether there was some mysterious feature in the CPU that would
> make this so fearsome. I remember the days from VAX where a special
> CPU-dependent module was loaded whenever VMS booted. Unless I am
> wrong that sort of CPU dependence is history today, but I
> certainly could be wrong.

I suspect the challenge here isn't with the chip as such, but with the
need for new drivers for the converged FibreChannel/Ethernet chipset.
I don't have the link handy, but I believe there is a reference to this
convergence buried in some of the March 2013 Nashua presentations.

This is a general industry trend. Ethernet will continue to devour the
FibreChannel side. If 10 Gbe doesn't kill off FC, 40 Gbe will.

If it were just new ethernet drivers, I think that could be tackled.
But I bet this convergence piece is particularly difficult. What follows
is mostly speculation based on a small amount of experience with doing
some kernel mode programming on VMS.

When it comes to writing a new ethernet driver, I believe the core work
that needs to be done is to present a driver that complies with the needs
of VCI, which is the kernel mode API that the network stacks program against.

I think this convergence piece is far more difficult to implement.
I would expect the need for broader kernel level changes in order to
get a unified driver to deal with kernel code for storage and kernel code
for networking. VCI is only for the unification of network access. I don't
think there's such a thing for storage.

Even if they get the driver to work, there's a chance that the system is
either slower than current i2 servers because they have mismanaged the
spinlocks or its less stable, again, because of spinlock mismanagement.

The low number of customers, however its counted, and the challenge at
hand will probably force HP to make a decision and I suspect that the
decision will be - no Poulson.

EJ

[VAXman-]

In article <3786a28d-fa95-4533...@googlegroups.com>, keith...@gmail.com writes:
>Jeff Jalbert posted the following on the OracleRdb mailing list:
>

>From: Jeffrey S. Jalbert [mailto:je...@jcc.com]=20
>Sent: Tuesday, May 21, 2013 3:33 PM
>To: oraclerdb
>Subject: EXT :RE: We need facts!
>

>If you ever expect to upgrade your VMS system(s) to newer and current hardw=
>are I think you should take Mr. Leonhardt=92s advice and send mail indicati=
>ng how those plans would be affected by a decision to not support Poulson. =
> I have come to the conclusion that we must act now while there is still a =

>week or two do affect things.
>

>What happens if VMS doesn=92t get supported on Poulson? To my mind, that r=
>eally is the end. VMS will be dead-ended on Tukwila, systems that HP will l=
>ikely not even continue to sell beyond next year given that Poulson has bee=
>n shipping since November of 2012. Current high-performance customers would=
> have no place to go and many of them have no capability of waiting for the=
> next generation. Besides, if HP doesn=92t support Poulson, who can make b=
>usiness plans on the expectation that HP will support the next chip?=20
>
>Ms. Bartlett says in her mail to Olaf that a decision will be announced by =
>the end of this month. That leaves precious little time to make your voice =

>heard. The time to act is clearly here.
>

>I sat in the same VMS Boot camp keynote that Mr. Leonhardt was in and that =
>triggered his note. That presentation was given by Ms. Bartlett. =20

I too sat in that same keynote and afterwards, I'd attempted, without success,
to get some answers as to what impediments Poulson poses to OpenVMS. Here I'd
thought that Itanium was an architecture. What's changing in Poulson that is
impacting the architecture such that OpenVMS will not run on it? Is it just a
lack of resources within the OpenVMS group? HP have put *lots* of money into
Itanium; why allow one of the few remaining consumers of it to perish?

FWIW, I know of a great many customers that are still on Alpha and that haven't
considered Itanium because they're getting what they need from Alpha. They've
gotten their Alphas from third-party providers but do pay the OpenVMS, as well
as for sundry other bits and pieces, licensing and maintenance fees. It is my
contention that the 2000 customers represents those that have OpenVMS Itanium
and not just OpenVMS! If you ask me, this is pegging the meter!!!

http://tmesis.org/images/bovinexcrementometer.gif

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

Well I speak to machines with the voice of humanity.

[se...@obanion.us]

> Including Deutsche Boerse?

Yes, but because NASDAQ bought OMX and they don't want to buy from a competitor.
They are moving to Linux.

http://www.computerworlduk.com/news/open-source/3272943/nyse-and-deutsche-borse-merger-chiefs-size-up-single-red-hat-linux-trading-platform/

http://blogs.computerworld.com/14637/linux_powers_worlds_fastest_stock_exchange

[Stephen Hoffman]

On 2013-05-22 12:13:12 +0000, johnso...@gmail.com said:

> When it comes to writing a new ethernet driver, I believe the core work
> that needs to be done is to present a driver that complies with the needs
> of VCI, which is the kernel mode API that the network stacks program against.
>
> I think this convergence piece is far more difficult to implement.
> I would expect the need for broader kernel level changes in order toget
> a unified driver to deal with kernel code for storage and kernel code
> for networking. VCI is only for the unification of network access. I
> don't think there's such a thing for storage.

AFAIK, all Fibre Channel host bus adapter devices supported on OpenVMS
use a class-and-port interface to connect into the Fibre-SCSI device
driver stack.

The Fibre/SCSI class driver (DG/DK) deals with the high-level pieces
and user-facing pieces of the I/O, while the port drivers deal with the
lower-level pieces and the hardware.

There's also what's known as an ALTSTART interface into the Fibre/SCSI
device driver stack, and packages and tools with kernel-mode code —
such as LD — use that interface to communicate with the device drivers.
The classic ALTSTART interface — available on a number of device
drivers, whether that was documented or not — is the rough analog to
the VCI interface.

But in any case, both Fibre/SCSI port drivers and the network port
drivers can be quite complex drivers.

Combining storage and networking into a single hardware interface has
been done before, with the DEPVZ and KZPCM adapters and potentially
others. The relative difficulties and likely issues here are dependent
on the interface and operation of the particular hybrid adapter
reportedly involved, too. (Various of the newer-generation adapters
I've worked with intentionally presented hardware interfaces that were
compatible with earlier-generation hardware by default, to ease the
effort of adding software support. Drivers could then be updated to
add support for newer features latent in the newer-generation
interfaces. But YMMV.)

Poulson is the biggest change to the Itanium series architecture, too.
Poulson also adds some out-of-order capabilities and reportedly changes
to the hyperthreading, and I don't know off-hand if there are any areas
of OpenVMS or application code that might be effected by that. That'd
definitely require some kernel folks and some compiler folks "crawling
through" all the details of those changes, specifically around
synchronization, probably also around the details of cache handling.
Whether any of the new error detection and correction features need
handlers would also need some investigation; I'd expect at least a
requirement to add some error-logging support.

Compilers can or will need some tweaks to use what's now available,
too. The existing code generators may (will?) continue to work, but
I'd expect there will be various advantages gained from adding support
for at least some of the changes. This was the general case with code
generation for newer-generation Alpha processors, too.

The OpenVMS ACPI code would likely need tweaks to deal with however the
Poulson boxes are presenting themselves to the host software.

One other related OpenVMS kernel API detail (limit) that I haven't been
able to independently confirm: the OpenVMS scheduler was limited to 64
cores/hyperthreads due to the scheduler's use of quadwords, and I don't
know if that was reworked with V8.4. There were changes implemented to
extend the user-visible portions of some related APIs to allow for
these (potential) kernel-mode changes, particularly with the
deprecation of the SYI$_*_MASK $getsyi itemcodes and the migration to
SYI$_*_BITMAP itemcodes (eg: deprecated SYI$_ACTIVE_CPU_MASK to
SYI$_ACTIVE_CPU_BITMASK) , but I don't know if any kernel-mode changes
were implemented in the scheduler itself. The Alpha V7.0 subset-IDSM
book references only quadwords. If these scheduling changes were not
implemented, then there'd be a few more changes necessary to add
support, or OpenVMS would be limited to four-socket boxes or equivalent
VM guests with Poulson; that'd be the rx2800 i4, BL860c i4, or BL870c
i4, and nothing larger. (Assumption: Four sockets, eight cores per
socket, two hyperthreads per core, one quadword chock-full of bits.)

Then there's the question of whether typical application loads would
perform adequately with more than 64 cores / hyperthreads, or if the
box would end up just "spinning" the extra processing resources behind
some spinlock or mutex. That's happened before as OpenVMS SMP support
has been scaled up, and finding and addressing performance bottlenecks
tends to be an incremental software re-engineering process.

Ancillary tools such as MONITOR, SHOW CPU, T4 and other integrated or
add-on system-performance and system-monitoring tools would need at
least a cursory look, just to see what happens with more than 64 cores
/ hyperthreads active. If those tools have processor bitmasks stored
in log files, those too can need changes. Any source code with
SYI$_*_MASK warrants a look, too.

Would adding this hardware support be possible? Technically, yes. I'd
definitely expect that adding support for Poulson would be possible.
But would that support be trivial to implement? I'd expect not. Will
application code need changes? Some code might, particularly if the
application code encounters more than 64 hyperthreads and reacts
inappropriately. I'd also wonder whether the changes in the
instruction processing might also trigger some OpenVMS- or
application-level issues, akin to what happened with the invalid Alpha
object code that was being generated a while back. (qv: SRM_CHECK.)
And who knows what other wrinkles might lurk here; there are always
errata.

Put another way, AFAIK adding Poulson support would not be quick, nor
cheap. I have no doubt that HP has a very good idea of what is
involved here, too.

The above is entirely technical speculation, and based solely on
published details.


--
Pure Personal Opinion | HoffmanLabs LLC

[Keith Parris]

On 5/20/2013 1:26 PM, Carl Karcher wrote:
> Something else to note is the newer storage products like the StoreServ 7x00 also do not support OpenVMS.

3PAR _does_ support OpenVMS, on both StoreServ 7000 and 10000. (Note
that 3PAR support is for Integrity, not Alpha; but you could MSCP-Serve
from Integrity to Alpha.)

[Keith Cayemberg]

To my knowledge Eurex and Xetra are in no way based on OMX. So OMX doesn't play any central role at Deutsche Boerse. The Eurex System is a joint in-house OpenVMS-based development of the Swiss Exchange and Deutsche Boerse. The linux parts are peripheral systems to which the customers has access. There was already once a Linux FUD campaign several years ago about Linux systems replacing the OpenVMS systems. Which then proved to be inaccurate and untrue. Also the Xetra System is OpenVMS-based and was developed out of the Eurex code with the help of Accenture. I expect that if a Linux-based system were to replace the core OpenVMS-based software, then the systems would no longer be named Eurex and Xetra. The names of the systems would most likely change since it would require a large project with a great deal of re-coding and testing. Essentially the system would be nearly a complete rewrite.

Cheers!

Keith Cayemberg

[Keith Cayemberg]

Agreed. Based on my independent market research, I also consider such a metric to be grossly underestimating the OpenVMS customer base. I count over 18000 customers, partners and service providers that can be shown (from internet sources) to use OpenVMS-based solutions within the last 10 years. It looks to me that HP has (self-serving?) narrowed its OpenVMS customer base estimate to those that have made purchases within the last year, in addition to the already mentioned possibilities of counting only Integrity customers, and those sold to directly (not through 3rd-party channels). If HP were coming out with significant new OpenVMS functionality and on all the platforms the customer needs/wants to see them (including x86-64) then HP may be surprised how inaccurate their "POTENTIAL" customer base is. Estimating a customer base on recent customers when little new having been released in the last year or two is no accurate basis for a market decision. OpenVMS customers are generally more interested in stability and can think for themselves whether they need a new version. They will usually avoid changes to their environment. That OpenVMS systems tends not be the low hanging fruit for those taking advantage of security issues, often gives OpenVMS customers the possibility to decide whether an upgrade is necessary based on features alone. If you want to sell to the OpenVMS market, you must give the many "potential" customers a convincing reason for each of their specific environments. If HP doesn't put in the real research why their "potential" customers for OpenVMS on Poulson don't migrate from Alpha and VAX, then they will likely not be able to provide convincing arguments for those potential customers.

Cheers!

Keith Cayemberg

[Bill Gunshannon]

In article <kngmt9$i7e$1...@usenet01.boi.hp.com>,

And I am sure the few big businesses that still see value in running
OpenVMS would buy into a hack like that.

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Keith Parris]

On 5/22/2013 10:20 AM, Bill Gunshannon wrote:
> In article <kngmt9$i7e$1...@usenet01.boi.hp.com>,
> Keith Parris <keithparris...@yahoo.com> writes:
>> 3PAR _does_ support OpenVMS, on both StoreServ 7000 and 10000. (Note
>> that 3PAR support is for Integrity, not Alpha; but you could MSCP-Serve
>> from Integrity to Alpha.)
>
> And I am sure the few big businesses that still see value in running
> OpenVMS would buy into a hack like that.

Most of the 'big businesses that still see value in running OpenVMS'
have long-ago migrated from Alpha to Integrity. A few may still need to
do that. MSCP-serving would be a perfectly-viable option during such a
migration. DEC used to sell FDDI Storage Servers which were based on
Alpha systems MSCP-serving storage over FDDI to other Alphas and to
VAXes. And still today we recommend enabling MSCP-serving as a backup
path to SAN storage in case an HBA or SAN failure occurs.

[Phillip Helbig---undress to reply]

In article <77250577-2bdf-4b06...@googlegroups.com>,

se...@obanion.us writes:

> Yes, but because NASDAQ bought OMX and they don't want to buy from a
> competitor.

Deutsche B�rse has always developed its own software, rather than buying
exchange software from somewhere. So (I'm guessing here) the reason
is "don't buy from OMX because we have never bought from anyone", not
"don't buy from a competitor".

> They are moving to Linux.
>
> http://www.computerworlduk.com/news/open-source/3272943/nyse-and-deutsche-borse-merger-chiefs-size-up-single-red-hat-linux-trading-platform/

There were merger talks between Deutsche B�rse and NYSE, but since the
EU ruled that this won't be allowed, Deutsche B�rse and NYSE are still
competitors and thus the article above speculates on a future which has
now been ruled out.

[Phillip Helbig---undress to reply]

In article <cb053c3b-72ce-4c1b...@googlegroups.com>,

Keith Cayemberg <keith.c...@arcor.de> writes:

> To my knowledge Eurex and Xetra are in no way based on OMX.

Right. OMX runs, or did run, on VMS, and Eurex and Xetra run on VMS.
They are all software for stock exchanges. That's the end of the
similarity.

> So OMX doesn't
> play any central role at Deutsche Boerse.

None at all, and never did.

> The Eurex System is a joint in-house OpenVMS-based development of the
> Swiss Exchange and Deutsche Boerse.

Right, but in preparation for the planned (now disallowed) merger with
NYSE, the Swiss part was bought out.

> The linux parts are peripheral systems to which the customers has access.
> There was already once a Linux FUD campaign several years ago about Linux
> systems replacing the OpenVMS systems. Which then proved to be inaccurate
> and untrue.

I remember an article a few years back which said, in no uncertain
terms, that the XETRA back-end, even then, ALREADY ran on RedHat Linux.
Complete and utter bullshit. Don't believe everything you read, boys
and girls.

> Also the Xetra System is OpenVMS-based and was developed out of the
> Eurex code with the help of Accenture.

Right.

> I expect that if a Linux-based system were to replace the core
> OpenVMS-based software, then the systems would no longer be named
> Eurex and Xetra.

This is essentially a marketing decision. Whether marketing decisions
are good and reflect deep-down changes is anyone's guess. (OpenVMS
anyone?)

More recently, some new Linux-based systems have been introduced, on the
back-end as well. Don't read FUD or stuff from people who obviously
don't know what they're talking about; take it from the horse's mouth:

http://www.eurexchange.com/exchange-en/technology/new-trading-architecture/

What the primary reasons for this are, I don't know, but I suspect that
"faster hardware" is a factor.

There are still many VMS-based systems, some (but not all) using Rdb; my
guess is that they will stay around for quite a while.

Disclaimer: I post here as a hobbyist, from the VMS cluster in my cellar
at home. My day (sometimes night) job at Deutsche B�rse involves
application support for Rdb-based in-house-written applications, on VMS
of course (all Itanium for several years now). I haven't even seen most
of the hardware they run on. :-)

Eurex and Xetra are relatively well known, but the Deutsche B�rse Group
(including ClearStream) has always had quite a wide range of hardware
and software.

[Michael Kraemer]

In article <84a32c71-5a66-4da1...@googlegroups.com>, Keith

Cayemberg <keith.c...@arcor.de> writes:
>
> Agreed. Based on my independent market research,

based on which metric?
Why should we believe you more than HP?

> I also consider such a met=
> ric to be grossly underestimating the OpenVMS customer base. I count over 1=
> 8000 customers, partners and service providers that can be shown (from inte=
> rnet sources)

You believe everything "internet sources" tell you?

> to use OpenVMS-based solutions within the last 10 years.

pretty long time that.
Most of that info probably would be obsolete by now, if it ever was true.

> It l=
> ooks to me that HP has (self-serving?) narrowed its OpenVMS customer base e=

> stimate to those that have made purchases within the last year,

makes perfect sense for HP.
Why should they care about customers not making purchases
on a regular basis?

[se...@obanion.us]

>
>
> > So OMX doesn't
>
> > play any central role at Deutsche Boerse.
>
>
>
> None at all, and never did.
>

That's what they told me during an in-person interview with them last year.

[Keith Parris]

On 5/21/2013 8:10 PM, keith...@gmail.com wrote:
> Jeff Jalbert posted the following on the OracleRdb mailing list:
>

> During the questioning, one attendee asked about VMS on Poulson.
> I believe this was discussed in past VMS roadmap sessions. Her

> remark was most revealing. I am paraphrasing here: �We are in
> the process of reviewing whether we will do this.� I believe the

> audience felt as if they were hearing a retraction of past
> commitment, I certainly did. I also heard that there was a
> distinct possibility that they would not. I know others did so
> also from comments later in the Forum and from a particular
> denial presentation given by Keith Parris at the end of the week
> who predicted VMS activity past 2050.

"denial presentation"???

I wouldn't be surprised to see someone still running OpenVMS in 2050,
but what I discussed was guesses about things like how long
support might last, given all the public information that is
available today, and past history.

The latest date I had in my presentation was 2032.
My presentation (with speaker notes) is posted at
https://www.dropbox.com/sh/77vbsdlg8w5ejt0/BCXgXHReTb

> When challenged on that point, Ms. Bartlett indicated that the

> �port� to Poulson was extremely difficult. That also floored me

> as I began to wonder whether there was some mysterious feature
> in the CPU that would make this so fearsome. I remember the
> days from VAX where a special CPU-dependent module was loaded
> whenever VMS booted. Unless I am wrong that sort of CPU
> dependence is history today, but I certainly could be wrong.
>
> I decided that there had to be something special about the
> packaging of the Poulson chips themselves, perhaps something
> on the motherboard that would lead to such a state.

Poulson has new instructions added. That implies compiler
changes. It has 128 registers in the Register Stack Engine
compared with 96 before. i4 Blades have a LAN-on-Motherboard
interface that does Converged Networking, with both Ethernet
and Fibre Channel traffic going through the same chip, so the
inteface is different and needs a completely new driver.
As is evident from presentations on RealWordTech the core design
for Poulson is very different, so timing may be different and
expose latent race conditions. VMS presently supports 32 cores
with hyperthreads, or 64 "CPUs" total, and a BL890c i4 has eight
8-core CPUs for 64 cores and 128 hyperthreads. This is just a
sample.

And of course the standard of quality for OpenVMS is high, so
this implies a lot of qualification and testing work, not only
for OpenVMS itself, but also the layered products.

[Keith Parris]

On 5/22/2013 5:37 AM, Simon Clubley wrote:
> What is been left unspoken here is just _who_ the port is "extremely difficult"
> for. Is it extremely difficult by the standards of the previous skilled and

> experienced VMS Engineering team, or is it extremely difficult by the standards

> of some new and inexperienced team who might know very little about VMS or
> the concepts involved in bringing it up on a new platform ?

You are mistaken in maligning the capabilities of OpenVMS Engineering.
The same engineers who did the Tukwila support are perfectly capable of
handling Poulson. They know what to do and they know how to do it.

[David Froble]

Yeah, what Keith wrote ....

I think we have only one customer still using an Alpha, and they are in
the process of upgrading. There is another that kept their last Alpha,
as a backup, which will never be used. But hey, they got the space, so
why not?

I was a fan of the Alpha, and I'm still not a fan of the itanic. But if
the turtle gets an F-15 with plenty of fuel (read as process shrinks and
gobs of memory) the rabbit is toast. And that never was about speed
anyway, just finishing ....

A major part of the speed improvements for our customers is the caching
of just about all the often used data in memory, not the CPU
capabilities. Gobs of memory ....

[David Froble]

JF Mezei wrote:
> Sorry to barge in but:

Ah, yes, just like old times ...

:-)

>> http://h30507.www3.hp.com/t5/Mission-Critical-Computing-Blog/bg-p/199/label-name/integrity%20servers
>
>
> Go to the very bottom for the April 27th 2011 entry:
>
> HP Integrity Lifecycle.
>
> The graphs discuss ===> END OF SALES <=== for HP-UX and VMS.
>
> OpenVMS 8.4 sales end mid 2015.
>
> In the fine text, it says that VMS is "planned" for Poulson and if it is
> ported to Poulson, end of sales will be pushed back to Poulson's end of
> sales, end of CY2016. Otherwise end of sales remain at mid CY15.
>
> I suspect that the "i2 server sales" refer to Tukwilla. Upgrades on
> those available to 3rd quarter 2015, just after end of sales for VMS.
>
>
> "OpenVMS 8.4 operating system sales and support are committed to be
> aligned with sales of Poulson-based Integrity servers."
>
> Whenever you see such "careful" wording, it means lawyers have been
> involved to ensure there is no commitment, allowing HP to not port to
> Poulson. If it is "committed", how come the VMS end of sale arrow
> doesn't extend until end of sale of Poulson at end of CY 2016 ? Quite
> the trustable commitment, isn't it ?

It's called "Wiesel words"

This is one of my concerns. Still running V8.3

> And with Kittson now just a glorified speed bump of Poulson, would
> porting VMS to Poulson imply support on Kittson as well, and commit HP
> to support VMS for a much longer time ?
>
>
> Wake up and smell the coffee. VMS isn't being developped anymore. No new
> version planned. Commitment to Kittson dead and buried, commitment to
> Poulson likely already dead. End of sales already on powerpoint graphs.
> Are people so blind that they can't see this ?

Not blind, just hoping for some unlikely common sense. With many of the
people who might have been able to actually do things no longer
involved, I don't see much future for VMS at HP. That's not to say
there is no future.

> Heck, even Keith Paris made a powerpoint discussing the post VMS future
> and he was representing HP.
>
>
>
> And it makes business sense for HP to protect itself from upcoming BCS
> losses. That is why they cut expenses (scaling back Kittson, no longer
> developping VMS, and even HP-UX apparently without plans for a new version).
>
> And if the largest remaining VMS customers can't get the real time of
> day from HP about HP's real intentions for VMS what does it mean about
> VMS' importance within HP ?
>
>
> Remember how HP announced plans for all its OS except for VMS when it
> announced its takeover of Compaq on Sept 7 2001 ? and we had to wait 9
> months for the transaction to close before first mention of VMS' plans
> in the famous Scott Stallard memo stating HP would support VMS customers
> but expect them to migrate to HP-UX in their own due time.

:-) :-)

Yeah, and just look at how well that would have turned out, with HP-UX
also on the ropes ....

> Throughout the history of HP since it inherited VMS, HP has actually
> been quite consistent: They will support the installed base of VMS but
> have no desire to improve VMS or try to acquire new customers. Its
> public statements (written or oral by execs) have been consistent with
> this, always carefully worded to limit vMS to "we'll support pour loyal
> installed base as long as they need VMS".
>
> And keeping VMS stable without new development allows HP to collect
> maintenance revenues without having to spend much to provide support.

This is one of the problems. As long as HP can milk the maintenance
revenues, they won't give the OS to someone else who just might be able
to do something with it, which includes open sourcing it. Would be
better if all customers dropped maintenance from HP, and those who need
it purchase it elsewhere.

> And just like HP did for VAX-VMS, it will not formally announce it has
> abandonned plans for VMS upgrades or support for new systems. And it
> may quietly take VMS off the order books (end of sales) without anyone
> noticing until much later.
>
> It is a real shame that VMS' clustering technology and other features
> that are still ahead of current systems are already fogotten by current
> crop of IT specialists and CIOs.
>
> I still have much respect for the real VMS engineers who managed to
> developed a quality and serious operating system. And their standards
> for quality, documentation and efficiency still influence me. despite
> the pressure to move to bloatware and no longer think about efficiency.
>
> Back to my cave. You may criticise me as much as you want.

No JF, your time has come. Lead us in our anti-HP compaign :-)

I'm just hoping that if things do go as they seem headed, that every VMS
customer bans HP from their list of acceptable vendors. HP should get
just what they are asking for.

The above should include ink and toner, hit them where it will hurt ....

:-)

[David Froble]

Just from what you've written here Keith, isn't there cause for HP to
say "too hard, not worth doing" ???

Just wondering?

[David Froble]

Keith Cayemberg wrote:

> Agreed. Based on my independent market research, I also consider such
> a metric to be grossly underestimating the OpenVMS customer base. I
> count over 18000 customers, partners and service providers that can
> be shown (from internet sources) to use OpenVMS-based solutions
> within the last 10 years. It looks to me that HP has (self-serving?)
> narrowed its OpenVMS customer base estimate to those that have made
> purchases within the last year,

Sort of "what have you done for me lately", and ignoring "what might you
do for me in the future", huh?

> in addition to the already mentioned
> possibilities of counting only Integrity customers, and those sold to
> directly (not through 3rd-party channels).

I guess this gets into the perception of VMS as a product, or just
something to sell hardware.

> If HP were coming out with
> significant new OpenVMS functionality and on all the platforms the
> customer needs/wants to see them (including x86-64) then HP may be
> surprised how inaccurate their "POTENTIAL" customer base is.

I've given up on something such as "vision" existing at HP.

> Estimating a customer base on recent customers when little new having
> been released in the last year or two is no accurate basis for a
> market decision. OpenVMS customers are generally more interested in
> stability and can think for themselves whether they need a new
> version. They will usually avoid changes to their environment. That
> OpenVMS systems tends not be the low hanging fruit for those taking
> advantage of security issues, often gives OpenVMS customers the
> possibility to decide whether an upgrade is necessary based on
> features alone. If you want to sell to the OpenVMS market, you must
> give the many "potential" customers a convincing reason for each of
> their specific environments. If HP doesn't put in the real research
> why their "potential" customers for OpenVMS on Poulson don't migrate
> from Alpha and VAX, then they will likely not be able to provide
> convincing arguments for those potential customers.

I think the reasons are rather simple. Many of those VAX and Alpha
systems are totally adequate for their intended purpose. If it ain't
broke, don't fix it.

Actually, due to the unavailability of devices from the time frame of
those old systems, they sooner or later will "break". This is where the
emulators have an opportunity. At least for those applications where
their performance is adequate.

You've got to figure that for many applications, given the use of
emulators, older versions of VMS are totally adequate. While they do
lack some of Steve's "modern tools and capabilities", much of that could
be layered on top of the older versions. Done properly, most added
software should be version agnostic.

It is for many a new way to look at things, and some will not accept
such a concept. I really don't understand why, when that's exactly what
they have with Linux, software without an "owner".

[Simon Clubley]

It's a pity then that I have seen no evidence of competence over the last
~6 weeks while interacting with VMS Engineering via a UK based HP VMS
support person. The issue in question is the queue manager problem I raised
here and the response has been even more pathetic than the response I had
last year while trying to get a SFTP issue fixed.

Everyone in comp.os.vms understood the problem right away and asked
insightful and very useful probing questions while trying to come up
with reasons for it.

VMS Engineering, by contrast, sent generic type responses which didn't
even address the problem as reported and their questions made me realise
they didn't even understand the problem. Even now, and after multiple
attempts by myself and the local HP support person to explain the problem
again to them, I am still not sure they understand.

Furthermore, even when you ask them specific and targetted questions
about the queue manager behaviour, you either get generic responses back
which don't answer the questions (the questions appear to be ignored)
or you don't even get anything back.

So Keith, please tell me again about how great these people are because
right now they come across to me as not knowing anything about the job
they are supposed to be doing.

Thanks,

[John Wallace]

On May 22, 11:12 pm, Keith Parris <keithparris_deletet...@yahoo.com>
wrote:

> On 5/21/2013 8:10 PM, keithwh...@gmail.com wrote:
>
> > Jeff Jalbert posted the following on the OracleRdb mailing list:
>
> > During the questioning, one attendee asked about VMS on Poulson.
> > I believe this was discussed in past VMS roadmap sessions.  Her

> > remark was most revealing.  I am paraphrasing here:  “We are in
> > the process of reviewing whether we will do this.”  I believe the

> >  audience felt as if they were hearing a retraction of past
> > commitment, I certainly did.  I also heard that there was a
> > distinct possibility that they would not.  I know others did so
> > also from comments later in the Forum and from a particular
> > denial presentation given by Keith Parris at the end of the week
> > who predicted VMS activity past 2050.
>
> "denial presentation"???
>
> I wouldn't be surprised to see someone still running OpenVMS in 2050,
> but what I discussed was guesses about things like how long
> support might last, given all the public information that is
> available today, and past history.
>
> The latest date I had in my presentation was 2032.

> My presentation (with speaker notes) is posted athttps://www.dropbox.com/sh/77vbsdlg8w5ejt0/BCXgXHReTb

>
> > When challenged on that point, Ms. Bartlett indicated that the

> > “port” to Poulson was extremely difficult.  That also floored me

> > as I began to wonder whether there was some mysterious feature
> > in the CPU that would make this so fearsome.  I remember the
> > days from VAX where a special CPU-dependent module was loaded
> > whenever VMS booted.  Unless I am wrong that sort of CPU
> > dependence is history today, but I certainly could be wrong.
>
>  > I decided that there had to be something special about the
>  > packaging of the Poulson chips themselves, perhaps something
>  > on the motherboard that would lead to such a state.
>
> Poulson has new instructions added. That implies compiler
> changes. It has 128 registers in the Register Stack Engine
> compared with 96 before. i4 Blades have a LAN-on-Motherboard
> interface that does Converged Networking, with both Ethernet
> and Fibre Channel traffic going through the same chip, so the
> inteface is different and needs a completely new driver.
> As is evident from presentations on RealWordTech the core design
> for Poulson is very different, so timing may be different and
> expose latent race conditions. VMS presently supports 32 cores
> with hyperthreads, or 64 "CPUs" total, and a BL890c i4 has eight
> 8-core CPUs for 64 cores and 128 hyperthreads. This is just a
> sample.
>
> And of course the standard of quality for OpenVMS is high, so
> this implies a lot of qualification and testing work, not only
> for OpenVMS itself, but also the layered products.

Compilers are supposed to hide the hardware details from the software
designer. New instructions in the instruction set doesn't normally
require a new compiler, unless there is a specific need to use the new
capabilities. Same with registers: more registers shouldn't *require*
a new compiler (unless a decision has been made to implement them in
an fashion which breaks existing code, which would surely be insane?).

The converged networking adapter may be a bit more more of a
challenge, but my immediate thought was "have multiple adapters, with
dedicated adapters for SAN traffic and separate dedicated adapters for
classic network traffic (etc)" (just like in the days of 10Mbit when
some folk used separate adapters for SCS vs DECnet for performance
reasons).

I'm struggling to understand what kind of commercially important
workload might benefit from more than 64 logical CPUs in a single
system image/SMP setup (the SSI/SMP bit matters). Maybe these
workloads do exist, but (a) if your workload doesn't need that kind of
SSI/SMP, then surely your VMS doesn't need to be extended to handle 65
or more processors either? (b) if there really are commercially
interesting numbers of opportunities with that kind of workload, Intel
and AMD's AMD64 products will get there soon too.

Of course if the 'port' to Poulson is sufficiently difficult, maybe
the port might as well be to some flavour of AMD64 system instead,
though last time I checked, AMD64 boxes didn't yet deliver quite the
same ultramassive SSI/SMP hardware capabilities as Poulson apparently
will.

[David Froble]

John Wallace wrote:
> On May 22, 11:12 pm, Keith Parris <keithparris_deletet...@yahoo.com>
> wrote:
>> On 5/21/2013 8:10 PM, keithwh...@gmail.com wrote:
>>
>>> Jeff Jalbert posted the following on the OracleRdb mailing list:
>>> During the questioning, one attendee asked about VMS on Poulson.
>>> I believe this was discussed in past VMS roadmap sessions. Her

>>> remark was most revealing. I am paraphrasing here: �We are in
>>> the process of reviewing whether we will do this.� I believe the

>>> audience felt as if they were hearing a retraction of past
>>> commitment, I certainly did. I also heard that there was a
>>> distinct possibility that they would not. I know others did so
>>> also from comments later in the Forum and from a particular
>>> denial presentation given by Keith Parris at the end of the week
>>> who predicted VMS activity past 2050.
>> "denial presentation"???
>>
>> I wouldn't be surprised to see someone still running OpenVMS in 2050,
>> but what I discussed was guesses about things like how long
>> support might last, given all the public information that is
>> available today, and past history.
>>
>> The latest date I had in my presentation was 2032.
>> My presentation (with speaker notes) is posted athttps://www.dropbox.com/sh/77vbsdlg8w5ejt0/BCXgXHReTb
>>
>>> When challenged on that point, Ms. Bartlett indicated that the

>>> �port� to Poulson was extremely difficult. That also floored me

As we've already seen, x86 is seeing pressure on the low end from ARM
type processors. But, at the high end, if x86 isn't quite up to the
capabilities of Poulson, I'm willing to bet (as you mentioned) that
there will be many more improvements to x86 while Poulson remains
unchanged ....

A port to x86 does seem to be the most reasonable thing. It would
remove "special" hardware from the issues. Where appropriate, for new
devices, perhaps some Linux code could be used as a starting point new
VMS drivers.

Now I got to ask, "what have I been drinking / smoking", all that Linux
stuff is most likely written in C.

[Richard B. Gilbert]

The support people come in all degrees of capabilities. If you are very
lucky, you get somebody who knows that he is out of his depth and will
get one of the developers to look at it.

If you give a GOOD Problem Description your problem will probably be
handed to the best man, or woman, for working the problem.

I have worked with a lot of DEC/Compaq/etc/etc people and most of them
were very good!

[David Froble]

Yes, but too many of them have been sent out to get on with their life's
work ....

[Michael S]

I don't understand what you are talking about.
8-socket/80-core/160-thread Xeon systems are offered by all major
server vendors since 2011Q2. They replaced 8-socket/64-core/128-thread
systems that were available full year before that.

Those are servers made by big vendors. If you are ready to consider
smaller guys then SGI will be glad to propose you their enormous
UV-2000 with up to Xeon 2048 cores in a single SMP system.

[johnso...@gmail.com]

On Thursday, May 23, 2013 6:43:04 PM UTC-4, David Froble wrote:

> As we've already seen, x86 is seeing pressure on the low end from ARM
> type processors. But, at the high end, if x86 isn't quite up to the
> capabilities of Poulson, I'm willing to bet (as you mentioned) that
> there will be many more improvements to x86 while Poulson remains
> unchanged ....

I think just the opposite is true.

For example, there are x86 CPUs with faster QPI links. I see Sandy Bridge
chips with 8 GT/s, but Poulson is at 6 GT/s. As for total cores in a box,
there are x86 motherboards such as this. I see support for 8 x86 CPUS with
the potential of 10 cores per cpu. That's an 80 core box.

http://www.supermicro.com/products/motherboard/Xeon7000/7500/X8OBN-F.cfm

Also, there is the Intel Phi coprocessor card which features *60* x86
cores each one capable of running 4 threads. List price? Under 3000 USD.

You can put together a box that would have four Intel Phi cards in it
that would communicate via the PCI-Express (v2) bus. Imagine a VMS cluster
where the interconnect was the speed of the PCI-E bus.

The x86 world zoomed past Itanium a while ago.

EJ

[Phillip Helbig---undress to reply]

In article
<7353205d-ecad-4364...@o2g2000yqb.googlegroups.com>, John

Wallace <johnwa...@gmail.com> writes:

> I'm struggling to understand what kind of commercially important
> workload might benefit from more than 64 logical CPUs in a single
> system image/SMP setup (the SSI/SMP bit matters). Maybe these
> workloads do exist, but (a) if your workload doesn't need that kind of
> SSI/SMP, then surely your VMS doesn't need to be extended to handle 65
> or more processors either?

I think the concern is not so much "VMS won't run on the latest,
greatest hardware" but rather "if VMS isn't supported on the latest,
greatest hardware, that's probably a sign that HP is finally winding it
down". Thus, even someone still on ALPHA might be concerned about the
lack of Poulson support.

> Of course if the 'port' to Poulson is sufficiently difficult, maybe
> the port might as well be to some flavour of AMD64 system instead,
> though last time I checked, AMD64 boxes didn't yet deliver quite the
> same ultramassive SSI/SMP hardware capabilities as Poulson apparently
> will.

OK, the next Itanium processor will blow AMD64 out of the water.
Haven't we heard that before? And did it come to pass?

[John Wallace]

I was confining my note yesterday to alternatives already available
from HP (and I should probably have made that much clearer). As you
and EJ point out, it's quite easy to argue that AMD64 capabilities are
now ahead of Poulson; this shouldn't really surprise anyone (but I'm
sufficiently out of date with HP's own x86 systems that a quick check
of Proliant Gen 8 yesterday didn't find the evidence I needed, so I
chose cautious words).

The reason for this limitation should hopefully be obvious - under CPQ
and HP, VMS boxes and Proliants were under different and potentially
competing stovepipes, even if they were both in the same company.
Afaik recent reshuffling inside HP has changed that.

So it's good to see it confirmed that AMD64 has already got to Poulson-
class levels of capability, and that these capabilities are not unique
to IA64 (if they ever really were).

Personally I still don't yet see what commercially interesting
workloads need >64 logical CPUs in an SMP box, but that doesn't
matter. Obviously some AMD64 chip and system builders have seen the
need, and apparently the AMD64 products are there to fulfill that
need. But these AMD64 boxes are not available with VMS as an option
for the OS. What applications are people using them for, with what
OS?

Have a good weekend.

[Jan-Erik Soderholm]

Phillip Helbig---undress to reply wrote 2013-05-24 11:01:
> In article
> <7353205d-ecad-4364...@o2g2000yqb.googlegroups.com>, John
> Wallace <johnwa...@gmail.com> writes:
>
>> I'm struggling to understand what kind of commercially important
>> workload might benefit from more than 64 logical CPUs in a single
>> system image/SMP setup (the SSI/SMP bit matters). Maybe these
>> workloads do exist, but (a) if your workload doesn't need that kind of
>> SSI/SMP, then surely your VMS doesn't need to be extended to handle 65
>> or more processors either?
>
> I think the concern is not so much "VMS won't run on the latest,
> greatest hardware" but rather "if VMS isn't supported on the latest,
> greatest hardware, that's probably a sign that HP is finally winding it
> down". Thus, even someone still on ALPHA might be concerned about the
> lack of Poulson support.

Exactly!

We will probably *never* run on IA64 (of any type or modell).
Still, there is an interest in seeing VMS survive, of course.

We are "running the factory" using 5-10% CPU using a "single core"
666 MHz DS20e.

Aren't these 64, 128 or whatever core systems a bit like a
"Mercedes SLS AMG" or an "Audi R8". Very few customers but they are
used to sell more normal modells to the masses.

Jan-Erik.

[Michael S]

Gen8 is limited to 32 cores.
The big machine is called DL980 G7.

> The reason for this limitation should hopefully be obvious - under CPQ
> and HP, VMS boxes and Proliants were under different and potentially
> competing stovepipes, even if they were both in the same company.
> Afaik recent reshuffling inside HP has changed that.
>
> So it's good to see it confirmed that AMD64 has already got to Poulson-
> class levels of capability, and that these capabilities are not unique
> to IA64 (if they ever really were).
>
> Personally I still don't yet see what commercially interesting
> workloads need >64 logical CPUs in an SMP box, but that doesn't
> matter.
> Obviously some AMD64 chip and system builders have seen the
> need, and apparently the AMD64 products are there to fulfill that
> need.

Not only AMD64.
Biggest IBM Power box - 32 sockets/256 cores/1024 threads.
Biggest Fujitsu SPARC box - 64 sockets/1024 cores/2048 threads.
Biggest Oracle SPARC box - 32 sockets/192 cores/1536 threads.

> But these AMD64 boxes are not available with VMS as an option
> for the OS.

And that's o.k.
But existing Poulson boxes not available with VMS does not sound o.k.
Although it's not exactly surprising. IIRC, Tukwila-based Superdome2
also unavailable with VMS.

> What applications are people using them for,

I only know which benchmarks are used by OEMs to brag about their
wonderful big SMPs - OLTP, SAP, to less extent data mining. I don't
know what is typically run by real-word end users.

> with what OS?

The same OSes as dual-quad socket servers - Windows, Linux, Solaris,
AIX, HP-UX. Typically sitting on top of hypervosor.

>
> Have a good weekend.

[johnso...@gmail.com]

On Thursday, May 23, 2013 10:40:00 PM UTC-4, johnso...@gmail.com wrote:

> The x86 world zoomed past Itanium a while ago.

I forgot to add in that PCI Express 3 is already available on some x86
motherboards. I don't think that's made an appearance yet on the Itanium
side as I suspect that will be stuck at v2 until the bitter end.

EJ

[Simon Clubley]

On 2013-05-23, Richard B. Gilbert <rgilb...@comcast.net> wrote:
>
> The support people come in all degrees of capabilities. If you are very
> lucky, you get somebody who knows that he is out of his depth and will
> get one of the developers to look at it.
>
> If you give a GOOD Problem Description your problem will probably be
> handed to the best man, or woman, for working the problem.
>

As mentioned previously, the problem description was a version of the
one I posted here, which everyone in comp.os.vms understood immediately.

VMS Engineering also claim to have read the followup questions and responses
posted in comp.os.vms, but none of this has helped in getting answers out of
VMS Engineering which actually match the questions been asked.

> I have worked with a lot of DEC/Compaq/etc/etc people and most of them
> were very good!

Sadly, most of those people are no longer employed by HP.

There's still a selection of front line support people employed here in
the UK and mainland Europe who are still as good as always. Unfortunately,
as soon as they need to escalate to the new VMS Engineering team, that's
when my support experiences turn uniformly negative. :-(

[Bill Gunshannon]

In article <5L-dnculjrZJPgPM...@giganews.com>,

I believe the general consensus here is that the operative word is "were".

[Stephen Hoffman]

On 2013-05-24 09:03:07 +0000, John Wallace said:

> I was confining my note yesterday to alternatives already available
> from HP (and I should probably have made that much clearer). As you
> and EJ point out, it's quite easy to argue that AMD64 capabilities are
> now ahead of Poulson; this shouldn't really surprise anyone (but I'm
> sufficiently out of date with HP's own x86 systems that a quick check
> of Proliant Gen 8 yesterday didn't find the evidence I needed, so I
> chose cautious words).

One of HP's upcoming big x86-64 boxes is code-named Project Kraken, and
approaching release:

<http://www8.hp.com/us/en/hp-news/press-release.html?id=1411830>

With the HP BCS group strategy expressly targeting enterprise x86-64
servers, I'd expect more of these big boxes are in progress, too.

FWIW.


--
Pure Personal Opinion | HoffmanLabs LLC

[Scott Dorsey]

Michael Kraemer <M.Kr...@gsi.de> wrote:
>In article <84a32c71-5a66-4da1...@googlegroups.com>, Keith
>Cayemberg <keith.c...@arcor.de> writes:
>>
>> Agreed. Based on my independent market research,
>
>based on which metric?
>Why should we believe you more than HP?

Because I believe HP about as well as a a politician.

>> It l=
>> ooks to me that HP has (self-serving?) narrowed its OpenVMS customer base e=
>> stimate to those that have made purchases within the last year,
>
>makes perfect sense for HP.
>Why should they care about customers not making purchases
>on a regular basis?

Why isn't HP trying to expand the customer base? When was the last time
HP actually signed up a new VMS customer? Do they even know how?
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Michael Kraemer]

Scott Dorsey schrieb:

> Michael Kraemer <M.Kr...@gsi.de> wrote:
>
>>In article <84a32c71-5a66-4da1...@googlegroups.com>, Keith
>>Cayemberg <keith.c...@arcor.de> writes:
>>
>>>Agreed. Based on my independent market research,
>>
>>based on which metric?
>>Why should we believe you more than HP?
>
>
> Because I believe HP about as well as a a politician.

Are fanboys more credible than politicians?
Apart from that, this is business, not politics.

>
> Why isn't HP trying to expand the customer base?

How do you know they didn't - and failed due to no demand?

> When was the last time
> HP actually signed up a new VMS customer?

See for example

http://www.openvms.org/stories.php?story=05/01/18/4417386
"Q:
are you looking for *NEW* customers, too?"

and the corresponding answer.

> Do they even know how?

If you have the silver bullet,
why don't you tell them?

[Bill Gunshannon]

In article <knu43e$20f$1...@solani.org>,

Michael Kraemer <M.Kr...@gsi.de> writes:
> Scott Dorsey schrieb:
>> Michael Kraemer <M.Kr...@gsi.de> wrote:
>>
>>>In article <84a32c71-5a66-4da1...@googlegroups.com>, Keith
>>>Cayemberg <keith.c...@arcor.de> writes:
>>>
>>>>Agreed. Based on my independent market research,
>>>
>>>based on which metric?
>>>Why should we believe you more than HP?
>>
>>
>> Because I believe HP about as well as a a politician.
>
> Are fanboys more credible than politicians?
> Apart from that, this is business, not politics.

Seems more likepolitics than business to me. If it truly were
business they would be trying to grow their marketshare.

>
>>
>> Why isn't HP trying to expand the customer base?
>
> How do you know they didn't - and failed due to no demand?

Lack of advertising. It's really hard to sell a secret.

>
>> When was the last time
>> HP actually signed up a new VMS customer?
>
> See for example
>
> http://www.openvms.org/stories.php?story=05/01/18/4417386

8 years old. Are you saying they haven't had a sale in 8 years?

> "Q:
> are you looking for *NEW* customers, too?"

See above. Looks like that was the question he asked.

>
> and the corresponding answer.

Is???

>
>> Do they even know how?
>
> If you have the silver bullet,
> why don't you tell them?

People here have repeatedly told them what the "silver bullet"
is. Advertising, marketing, support for systems business actually
want to run. It has also, repeatedly, fallen on deaf ears.

[Scott Dorsey]

Michael Kraemer <M.Kr...@gsi.de> wrote:
>Scott Dorsey schrieb:

>> Why isn't HP trying to expand the customer base?
>
>How do you know they didn't - and failed due to no demand?

Marketing is about creating demand. IBM is doing very well promoting large
systems into a newer market.

>If you have the silver bullet

>why don't you tell them?

1. Brand VMS as a system for web backends. Sell it as a database engine.
Provide good hooks between web applications and existing VMS database
stuff.

2. Sell it on maintainability.

3. Hire IBM's marketing team.

[Phillip Helbig---undress to reply]

In article <ko018k$7o$1...@panix2.panix.com>, klu...@panix.com (Scott

Dorsey) writes:

> 1. Brand VMS as a system for web backends.

Yes, works fine for that.

> Sell it as a database engine.

Yes; what else can run Rdb?

> Provide good hooks between web applications and existing VMS database
> stuff.

Even without them, it is not difficult to run a web server on VMS which
interacts with Rdb.

[Scott Dorsey]

You know these things. I know these things. The people who read Datamation
don't know these things. The people at HP marketing either don't know these
things or actively have been told not to say them.

Mind you, I can't blame HP for wanting to kill a product line that they don't
understand and don't know how to sell or want to sell. What I wonder is why
they ever picked it up in the first place.

[Bill Gunshannon]

In article <ko0v6f$hb6$1...@panix2.panix.com>,

klu...@panix.com (Scott Dorsey) writes:
> Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de> wrote:
>>In article <ko018k$7o$1...@panix2.panix.com>, klu...@panix.com (Scott
>>Dorsey) writes:
>>
>>> 1. Brand VMS as a system for web backends.
>>
>>Yes, works fine for that.
>>
>>> Sell it as a database engine.
>>
>>Yes; what else can run Rdb?
>>
>>> Provide good hooks between web applications and existing VMS database
>>> stuff.
>>
>>Even without them, it is not difficult to run a web server on VMS which
>>interacts with Rdb.
>
> You know these things. I know these things. The people who read Datamation
> don't know these things. The people at HP marketing either don't know these
> things or actively have been told not to say them.
>
> Mind you, I can't blame HP for wanting to kill a product line that they don't
> understand and don't know how to sell or want to sell. What I wonder is why
> they ever picked it up in the first place.

When HP bought COMPAQ weren't they really just trying to absorb one of
their PC competitiors? Probably were basicly unaware of the BCS line
and never really cared.

[Scott Dorsey]

Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>In article <ko0v6f$hb6$1...@panix2.panix.com>,

>>
>> Mind you, I can't blame HP for wanting to kill a product line that they don't
>> understand and don't know how to sell or want to sell. What I wonder is why
>> they ever picked it up in the first place.
>
>When HP bought COMPAQ weren't they really just trying to absorb one of
>their PC competitiors? Probably were basicly unaware of the BCS line
>and never really cared.

BINGO! Give that man a prize!

[johnso...@gmail.com]

> > 1. Brand VMS as a system for web backends.
>
> Yes, works fine for that.

While it does work, everyone needs to remember that the TCP/IP stacks for
OpenVMS are quite a bit slower than their Linux counterparts. The latency
is consistently higher and the bandwidth is consistently lower.

EJ

[Michael Kraemer]

Bill Gunshannon schrieb:

> Seems more likepolitics than business to me. If it truly were
> business they would be trying to grow their marketshare.

It's the bottom line which counts.
Are you trying to tell me that otherwise greedy managers
refuse potential bonuses (boni?) just
because they don't "like" VMS?
If it were easy money to pick up,
they'd pick it up. The truth most probably
is that it isn't easy money.

> Lack of advertising. It's really hard to sell a secret.

It's not a secret. Just no demand.


> 8 years old.

yet most of what is written there is still valid.
Except that the situation is even worse now.

> Are you saying they haven't had a sale in 8 years?

I don't know, but I guess they only sell
to a dwindling legacy customer base.

>
>>and the corresponding answer.
>
>
> Is???

... written plain to see:
"What we find today is that it is difficult to convince new customers to
adopt an operating environment that they do not view as an industry
standard."

> People here have repeatedly told them what the "silver bullet"
> is. Advertising, marketing, support for systems business actually
> want to run. It has also, repeatedly, fallen on deaf ears.

Preaching to the choir.
Didn't pan out the last twenty years.
Would the DoD have bought more VMS gear
based on ads in, say, "Stars and Stripes"?

[Michael Kraemer]

Scott Dorsey schrieb:

>
> Marketing is about creating demand.

No it's not.
You can't create what's not already there.
Successfull marketeers (like BG and even more so S.Jobs)
"smell" in advance what customers might want
one or two years down the line.
When the time is ripe,
they have the right products available.

> IBM is doing very well promoting large
> systems into a newer market.

This market is rather static at the bottom line.
IBM also tries not to sell just single pieces
of hardware, OS, software, but rather complete "solutions".
For example, you need to dig somewhat deeper into
their web pages to learn that Watson is built on Power7 and Unix.

>
>>If you have the silver bullet
>>why don't you tell them?
>
>
> 1. Brand VMS as a system for web backends. Sell it as a database engine.
> Provide good hooks between web applications and existing VMS database
> stuff.

Yet another web server and database, how innovative.
A better mousetrap?
Didn't pan out the last twenty years, why should it now.

> 2. Sell it on maintainability.

Current web servers are not maintainable?

> 3. Hire IBM's marketing team.

I don't see what's so special about them
(ask ex-OS/2 customers for example).
They simply give the customers what they're asking (and paying) for.
Provided there's enough money on return, of course.

[Simon Clubley]

On 2013-05-29, Michael Kraemer <M.Kr...@gsi.de> wrote:
> Scott Dorsey schrieb:
>>

>> 1. Brand VMS as a system for web backends. Sell it as a database engine.
>> Provide good hooks between web applications and existing VMS database
>> stuff.
>
> Yet another web server and database, how innovative.
> A better mousetrap?
> Didn't pan out the last twenty years, why should it now.
>
>> 2. Sell it on maintainability.
>
> Current web servers are not maintainable?
>

While Michael does come across as been uniformly negative, he is right
about this.

Trying to sell VMS as a web backend to new customers is about as viable
as trying to sell a RSX based embedded solution to a new customer.

There is a whole ecosystem of backend tools for Unix webservers and
databases. How exactly do you duplicate that ecosystem for VMS ?

Even if you can match the existing ecosystem, then what angle do you use
to persuade people to buy this new thing called "VMS" ?

You have to demonstrate a _massive_ advantage with the VMS system in order
to persuade people within a organisation they can justify taking the risk
to try it.

What is that massive advantage and how do you phrase it in such a way
that a person within a organisation can be sure their boss would agree
with them ?

Bland hand-waving statements are not enough; you need specific targeted
examples with the data to back them up.

[Bill Gunshannon]

In article <ko4619$q7r$1...@solani.org>,

Michael Kraemer <M.Kr...@gsi.de> writes:
> Bill Gunshannon schrieb:
>
>> Seems more likepolitics than business to me. If it truly were
>> business they would be trying to grow their marketshare.
>
> It's the bottom line which counts.
> Are you trying to tell me that otherwise greedy managers
> refuse potential bonuses (boni?) just
> because they don't "like" VMS?
> If it were easy money to pick up,
> they'd pick it up. The truth most probably
> is that it isn't easy money.
>

Well, the real problem is not selling VMS doesn't seem to affect their
bonuses. And like most people, they are very unlikely to anything
more than the minimum to keep those bonuses coming in.

>
>> Lack of advertising. It's really hard to sell a secret.
>
> It's not a secret. Just no demand.

How can one demand something one is totally unaware of? There
was this very old proverb about not putting you lamp under a
basket.

>
>
>> 8 years old.
>
> yet most of what is written there is still valid.
> Except that the situation is even worse now.

Valid in what way? The question was "show me a recent VMS sale"
and you offered an 8 year old article. In the IT world that is
ancient history.

>
>> Are you saying they haven't had a sale in 8 years?
>
> I don't know, but I guess they only sell
> to a dwindling legacy customer base.

Now that's truly self-fulfilling. Don't seek out new customers and
then tell people "the market is dwindling".

>
>
>>
>>>and the corresponding answer.
>>
>>
>> Is???
>
> ... written plain to see:
> "What we find today is that it is difficult to convince new customers to
> adopt an operating environment that they do not view as an industry
> standard."
>

And yet, IBM and UNISYS have been doing it consistantly for their entire
lives. What's wrong with this picture?

>
>> People here have repeatedly told them what the "silver bullet"
>> is. Advertising, marketing, support for systems business actually
>> want to run. It has also, repeatedly, fallen on deaf ears.
>
> Preaching to the choir.
> Didn't pan out the last twenty years.
> Would the DoD have bought more VMS gear
> based on ads in, say, "Stars and Stripes"?

That would be like advertising Lamborghinis in the National Enquirer.
The decision makers at DOD don't even get Stars and Stripes it is not
and never has been available in the US. Add tot hat that most of
these decision makers are civilians, not military at all. What do
people read around the beltway?

One has to target advertising. One has to be sure they are talking
to the people who will actually make the decision. My experience
(based on some of the managers I have had the "pleasure" to work for)
is that they are very easily influenced. You just need to do a better
job of selling than Michael Dell.

But, and here is the kicker, you have to want to sell the product in
the first place.

[Scott Dorsey]

Michael Kraemer <M.Kr...@gsi.de> wrote:
>Bill Gunshannon schrieb:

>
>> Lack of advertising. It's really hard to sell a secret.
>
>It's not a secret. Just no demand.

Marketing is about creating demand where it does not currently exist.
Mind you, there is only so much that marketing can do, but if nobody knows
that it's a viable product, or even worse they know it's a viable product
but think HP could be killing it any minute, they aren't going to demand it.

I would not recommend VMS for a new installation right now either. Not for
any technical reasons, but because I can't trust HP.

[Bob Gezelter]

EJ,

The statement "The TCP/IP stack is slower..." is not a meaningful statement. A statement without a benchmark cannot be discussed.

If there is a specific test that is running slow, it needs to be examined. In one classic case, working through the benchmark (of a DECnet COPY or an FTP), the "performance" problem ascribed to the network transfer was actually attributable to the file extend size on the target volume.

Rather than benchmarking the "network", the benchmark was actually benchmarking the ability of FILES-11 to extend files in small increments. While somewhat entertaining, this "performance" problem was easily corrected by a small change to the the process' RMS parameters.

What precise test is being referenced?

- Bob Gezelter, http://www.rlgsc.com

[Stephen Hoffman]

On 2013-05-30 13:26:39 +0000, Bob Gezelter said:

> The statement "The TCP/IP stack is slower..." is not a meaningful
> statement. A statement without a benchmark cannot be discussed.
>
> If there is a specific test that is running slow, it needs to be
> examined. In one classic case, working through the benchmark (of a
> DECnet COPY or an FTP), the "performance" problem ascribed to the
> network transfer was actually attributable to the file extend size on
> the target volume.
> Rather than benchmarking the "network", the benchmark was actually
> benchmarking the ability of FILES-11 to extend files in small
> increments. While somewhat entertaining, this "performance" problem was
> easily corrected by a small change to the the process' RMS parameters.
>
> What precise test is being referenced?

See EJ's comments in this thread
<https://groups.google.com/d/msg/comp.os.vms/wu7afPpr0G0/ofKyMX-RPqwJ>
and particularly this posting
<https://groups.google.com/d/msg/comp.os.vms/wu7afPpr0G0/bZtiEIwZZMoJ>
and probably a few others.

On the discussion of I/O performance, there were threads some time ago
from folks including David Mathog that compared file system
performance, including via David's "mybenchmark" tool. Here are those
discussions:
<https://groups.google.com/d/msg/comp.os.vms/pykD0i4xGTQ/cm6v6JXcCT8J>,
<https://groups.google.com/d/msg/comp.os.vms/6zKrNyxXkTA/n-rzPDEjDkUJ>

[johnso...@gmail.com]

On Thursday, May 30, 2013 9:26:39 AM UTC-4, Bob Gezelter wrote:

> What precise test is being referenced?

I will post some programs when I can. They are brain dead simple.

For me, the most illuminating examples can be found by exploring UDP,
and not TCP. TCP has too many knobs, dark corners, specific secret
optimizations, etc etc, that make analysis very difficult.

I hope to get to this before the end of next week. I hope others will
join in the conversation.

EJ

[Bob Gezelter]

EJ,

I appreciated the details you posted in the other thread.

From your research, it would appear that the problem is correctable not foundational.

[Bob Gezelter]

The following was sent to Lorraine Bartlett, Ric Lewis, and Dave Donatelli (with a cc to Meg Whitman):

Dear Lorraine, Ric, and Dave,

I am writing to you as an OpenVMS community member (since 1977), a businessman, and as an HP stockholder. While I am happy to discuss the technical issues, this letter only addresses the core business issues.

It is important that OpenVMS provide support for Poulson and future Itanium processors. This preserves OpenVMS viability on current generation processors. More importantly, it reassures customers that HP stands behind OpenVMS, as well-stated in Lorraine Bartlett’s 2010 letter (attached).

OpenVMS remains the Gold standard in clustering, availability, security and many other areas. Short-term sales do not adequately reflect the importance of OpenVMS, particularly when a newer generation of hardware has been imminent for an extended period of time.

Many large and small businesses rely on OpenVMS as a technological foundation. While some very large accounts are serviced by HP directly, many accounts large and small obtain their hardware and software through HP channel partners. Individual customers have often invested substantial capital in their OpenVMS-based applications. These investments are critical to their businesses, representing man-decades, man-centuries, and in some cases, man-millenia of effort. Actions which imply a need to re-engineer these software environments justifiably arouse extreme anxiety.

A decision to forgo Poulson CPU support would thus call into question HP’s support of its OpenVMS customers, and by logical extension, raise the question of whether HP is a reliable choice as a provider of foundational IT technologies.

HP should support OpenVMS on Poulson and future Itanium processors, providing reassurance to its customers that HP is a reliable partner for foundational IT technologies.

Sincerely yours,



ROBERT GEZELTER



The PDF of the letter can be found at: http://www.rlgsc.com/openvms/OpenVMS-Poulson-2013-05-29.pdf

[johnso...@gmail.com]

On Friday, May 31, 2013 10:29:53 AM UTC-4, Bob Gezelter wrote:

> From your research, it would appear that the problem is correctable...

Yes, but that perspective should come with the reminder that its been
like this for many years. I have not seen or heard anything from anyone
that suggests a change is forthcoming from any IP stack vendor in the VMS
world.


EJ

[David Froble]

Bob Gezelter wrote:

> A decision to forgo Poulson CPU support would thus call into question
> HP’s support of its OpenVMS customers, and by logical extension,
> raise the question of whether HP is a reliable choice as a provider
> of foundational IT technologies.
>
> HP should support OpenVMS on Poulson and future Itanium processors,
> providing reassurance to its customers that HP is a reliable partner
> for foundational IT technologies.

Do you really think they're smart enough to "get it", even though you've
"shoved their noses into it" ??

It astounds me that any of "them" think that they can retain customers
that they've "shafted" so badly.

Or maybe they just want to concentrate on selling ink ...

[Keith Parris]

On 5/17/2013 2:26 PM, Olaf Leonhardt wrote:
> I ask Lorraine Bartlett what�s going on with Poulson for OpenVMS.

HP has released a new OpenVMS Roadmap at
http://hp.com/go/openvms/roadmap/ dated May 2013.

It omits any mention of Poulson support.

Standard Support dates for OpenVMS are unchanged from prior commitments:
at least 2020 (with 2 years' advance notice) for OpenVMS Integrity and
at least 2016 (with 2 years' advance notice) for OpenVMS Alpha. Then
after Standard Support there is typically some period of Extended
Engineering Support or Mature Product Support, with or without
Sustaining Engineering.

HP server hardware is typically supported for at least 5 years after
last sale, whenever that occurs.

[Phillip Helbig---undress to reply]

In article <kolh52$sq9$1...@usenet01.boi.hp.com>, Keith Parris

<keithparris...@yahoo.com> writes:

> HP has released a new OpenVMS Roadmap at
> http://hp.com/go/openvms/roadmap/ dated May 2013.
>
> It omits any mention of Poulson support.

We know that these are "rolling" road maps and are not commitments, but
rather plans subject to change. Indeed, in the past, they have changed,
but usually for the worst. So, while this is not a firm commitment NOT
to support VMS on Poulson, in practice it is probably the beginning of
the end for VMS.

[johnso...@gmail.com]

On Wednesday, June 5, 2013 2:17:44 AM UTC-4, Phillip Helbig---undress to reply wrote:

> We know that these are "rolling" road maps and are not commitments, but
> rather plans subject to change. Indeed, in the past, they have changed,
> but usually for the worst. So, while this is not a firm commitment NOT
> to support VMS on Poulson, in practice it is probably the beginning of
> the end for VMS.

I am unable to name an instance of something that was on the roadmap, then
elided from it, and then completed anyway.

EJ

[Simon Clubley]

On 2013-06-05, Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de> wrote:
> In article <kolh52$sq9$1...@usenet01.boi.hp.com>, Keith Parris
><keithparris...@yahoo.com> writes:
>
>> HP has released a new OpenVMS Roadmap at
>> http://hp.com/go/openvms/roadmap/ dated May 2013.
>>
>> It omits any mention of Poulson support.
>

So either the VMS internals proved to be too rigid and inflexible to
change in a reasonable amount of time or the current VMS Engineering
outfit turned out to be incapable of understanding VMS enough to modify
it's internals in any significant way. I wonder which one it was ?

> We know that these are "rolling" road maps and are not commitments, but
> rather plans subject to change. Indeed, in the past, they have changed,
> but usually for the worst. So, while this is not a firm commitment NOT
> to support VMS on Poulson, in practice it is probably the beginning of
> the end for VMS.
>

I agree, but personally I think VMS has been in life support mode since
the old VMS Engineering team was replaced.

[David Froble]

Simon Clubley wrote:
> On 2013-06-05, Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de> wrote:
>> In article <kolh52$sq9$1...@usenet01.boi.hp.com>, Keith Parris
>> <keithparris...@yahoo.com> writes:
>>
>>> HP has released a new OpenVMS Roadmap at
>>> http://hp.com/go/openvms/roadmap/ dated May 2013.
>>>
>>> It omits any mention of Poulson support.
>
> So either the VMS internals proved to be too rigid and inflexible to
> change in a reasonable amount of time or the current VMS Engineering
> outfit turned out to be incapable of understanding VMS enough to modify
> it's internals in any significant way. I wonder which one it was ?
>
>> We know that these are "rolling" road maps and are not commitments, but
>> rather plans subject to change. Indeed, in the past, they have changed,
>> but usually for the worst. So, while this is not a firm commitment NOT
>> to support VMS on Poulson, in practice it is probably the beginning of
>> the end for VMS.
>>
>
> I agree, but personally I think VMS has been in life support mode since
> the old VMS Engineering team was replaced.
>
> Simon.
>

Simon, I think you've answered your own question. The old team could do
just about anything, if assigned the job. I think "new team" is being
too kind ....

[Keith Parris]

On 6/4/2013 2:02 PM, Keith Parris wrote:
> HP has released a new OpenVMS Roadmap at
> http://hp.com/go/openvms/roadmap/ dated May 2013.
>
> It omits any mention of Poulson support.

HP has released the following customer letter:
---
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado, 80528
United States

Ric Lewis
VP and General Manager
Enterprise Servers Business
T +1 970 898 3463
ric....@hp.com

June 2013
Mission-critical Roadmap Update for HP OpenVMS Customers

For over 35 years, the HP OpenVMS operating environment has served as
a mission-critical platform upon which you have built your IT
infrastructure. We deeply appreciate our long partnership and also
the loyalty you have shown HP during this time. We are committed
to providing you updates and support for the V8.4 OpenVMS operating
environment through at least December 31, 2020.

Deploying OpenVMS on Integrity i2 servers provides significant
performance and cost savings over prior Alpha and Integrity versions.
Please read how two customers have improved their OpenVMS environments
with Integrity i2 ("Tukwila") servers:

o AccuWeather, U.S.
http://h20195.www2.hp.com/V2/GetPDF.aspx%2F4AA4-2153ENW.pdf
"AccuWeather improved runtime performance by
20 percent by upgrading its OpenVMS environment with HP
Converged Infrastructure including HP Integrity blades".

o Sberbank, Russia
http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA3-6327ENW.pdf
"The HP Integrity server blades reduce our space
needs by 20% and our power requirements by 15% annually."

To maintain and grow your mission-critical OpenVMS environment, we have
extended sales of the Integrity i2 servers for OpenVMS through at least
December 31, 2015 and sales of Integrity i2 server upgrades for OpenVMS
through at least December 31, 2016. We will also extend Integrity i2
server hardware support through at least December 31, 2020.

Additionally we will continue legacy support for OpenVMS:

o OpenVMS V7.3-2 on Alpha: prior version support through
December 31, 2015.
o OpenVMS V8.3 on Alpha: standard support through
December 31, 2015.
o OpenVMS V8.4 on Alpha: standard support through at least
December 31, 2016.
o OpenVMS V8.3/V8.3-1H1 on Integrity: standard support through
December 31, 2015.

With the changes to extend sales and support of the HP Integrity i2
servers with OpenVMS, we will not offer OpenVMS no HP Integrity i4
("Poulson") servers. Please review the updated OpenVMS roadmap:
http://h71000.www7.hp.com/openvms/pdf/openvms_roadmaps.pdf

HP is committed to your business and success. We will continue to
provide a high level of support to you through the lifetime of your
OpenVMS environment. We have a full portfolio of servers, software, and
solutions, including support for transitions to NonStop, HP-UX, Linux,
and Windows environments. Your local HP representative can help you
make the right choices for your OpenVMS environment and address any
questions you may have.

Thank you for your business. We look forward to continuing our
partnership and to being your partner of choice for mission-critical
computing requirements.

Regards,

Ric Lewis
Vice President and General Manager, Enterprise Servers Business


The information contained in this letter, and HP's plans, are subject
to change without notice. The only warranties for HP products and
services are set forth in the express warranty statements accompanying
such products and services. Nothing herein should be construed as
constituting an additional representation or warranty or binding
commitment upon HP. HP shall not be liable based upon technical or
editorial errors or omissions contained herein.

[Phillip Helbig---undress to reply]

In article <kona11$8b4$1...@dont-email.me>, Simon Clubley

<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> So either the VMS internals proved to be too rigid and inflexible to
> change in a reasonable amount of time or the current VMS Engineering
> outfit turned out to be incapable of understanding VMS enough to modify
> it's internals in any significant way. I wonder which one it was ?

A few years ago, I would have expected JF to chime in and cite this as
evidence that VMS will be ported to x86. But even he has given up.

[Phillip Helbig---undress to reply]

In article <koo4an$n5i$1...@usenet01.boi.hp.com>, Keith Parris

<keithparris...@yahoo.com> writes:

> For over 35 years, the HP OpenVMS operating environment has served as
> a mission-critical platform upon which you have built your IT
> infrastructure. We deeply appreciate our long partnership and also
> the loyalty you have shown HP during this time. We are committed
> to providing you updates and support for the V8.4 OpenVMS operating
> environment through at least December 31, 2020.

Even in the DEC days, there was the "unix is the future" garbage. Then
various migration stuff. In the past, it was retracted, but, I fear, no
more. This is the end.

Do they really think that loyal VMS customers, when forced to move off
of VMS, will stay with HP? Why should they?

[VAXman-]

In article <koo4an$n5i$1...@usenet01.boi.hp.com>, Keith Parris <keithparris...@yahoo.com> writes:

_
vice /vis/ Noun., Immoral or wicked behavior.

Manager? Or Assassin? Or son of Bob Palmer?

>The information contained in this letter, and HP's plans, are subject
>to change without notice. The only warranties for HP products and
>services are set forth in the express warranty statements accompanying
>such products and services. Nothing herein should be construed as
>constituting an additional representation or warranty or binding
>commitment upon HP. HP shall not be liable based upon technical or
>editorial errors or omissions contained herein.

HOPELESSLY PATHETIC? HOPELESSLY LOST!!!

Why bother plowing further monies in to Itanium? It's clear that HP will
eventually see the end of other operating systems on Itanium and then the
IA64 will just be yet another arthitecture that time has forgotten. I'll
proudly stand atop of and spit upon the grave of HP when it too has become
a relic of the history books.

FWIW, just today, I was on-site at a company deploying Integrity servers.
This company is actively working to replace all of their existing Alphas.
A discussion of i4, obviously, came up and the concensus is was HP simply
do not want to deal with sales of a few boxes here and a few boxes there.
Hopelessly Pathetic would rather enjoy off-the-shelf sales of gazillions
of units of ink than to provide "Enterprise Servers" for "Business."

HOPELESSLY PATHETIC? What a laugh. What a cry. What a crying shame.

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

Well I speak to machines with the voice of humanity.

[Richard Maher]

>
> With the changes to extend sales and support of the HP Integrity i2

> servers with OpenVMS, we will not offer OpenVMS no[sic] HP Integrity i4

> ("Poulson") servers. Please review the updated OpenVMS roadmap:
> http://h71000.www7.hp.com/openvms/pdf/openvms_roadmaps.pdf
>

I guess Olaf's got his answer :-(

[Brad Hamilton]

On 2013-06-05, Phillip Helbig---undress to reply
<hel...@astro.multiCLOTHESvax.de> wrote:

If he was still "here", he would declare victory and go home.

Which he did.

[Simon Clubley]

I am currently going through some very negative experiences with the
new team, but I was trying to keep a open mind. :-)

BTW, those negative experiences relate to the queue manager behaviour.
It's getting on for a couple of months and I still don't have any sensible
answers. They either completely misunderstand the problem (or appear to)
and when you ask them simple and specific targeted questions, the questions
are usually ignored in favour of some general comments which don't answer
the question asked. :-(

I cannot decide if they really don't understand the problem, or are just
pretending they don't in the hope I will get frustrated and go away.
After seriously blowing up at them a week or two ago after the latest
set of inane answers, the UK based HP VMS support person claims they now
appear to suddenly understand the problem.

I have now found out over the last month that queue manager updates _are_
buffered in memory for a while, but I _still_ don't have any answers for
how long and if flushing to disk is also tied to significant events such
as job start/end. Absolutely pathetic. :-(

It's horrifying that these are the people you would rely on if, say, a
VMS TCP/IP component falls victim to a zero day attack, and stops normal
operations.

Simon.

PS: Sorry for the above rant; it's turned out to be a long winded way of
saying I still cannot tell if it's the VMS internals or the new team
which are at fault here. :-)

[Simon Clubley]

On 2013-06-05, Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de> wrote:

If they (or VMS) cannot handle a variant within a supported architecture,
then what makes you think they can add support for a whole new architecture
to the existing VMS code base ? :-)

You may still see VMS on x86 if the FreeVMS people make any real headway.
I do think the microkernel based approach is the correct one for FreeVMS;
if done correctly, this would lead to a clean and easy to maintain codebase
while still implementing the required VMS specific functionality.

[David Froble]

Well, several things ....

As to your queue manager problem, sometimes there are unexplained
un-reproducable events that you just have to move beyond and get on with
life. This may be one of them. It appears that you already found out
that there is some buffering. Maybe let it go at that. Thing is, how
many dollars do you spend to recover a dime?

It may have been a timing thing that will never be reproduced, or
totally explained. The important things are:

1) will it happen again

2) procedures that could be a problem if duplicated should have checks
to prevent such from happening

3) get some battery backup


As for VMS, well, I can be accused of being the external optimist.
Maybe VMS is dead-ended on IA-64. That does not mean that it HAS to be
dead. For one thing, a port to x86 would be an extremely viable new
direction. Not saying that will happen.

Other ports could be possible. Power? Some new CPU that doesn't exist
today, but comes out next month and kills every other CPU in existence
with price and performance. Alpha is resurrected with new technology
that blows everything else away, is cheaper, etc ...

Is there any future for VMS in India? I doubt it. I doubt there is any
culture of loyalty to VMS there such as there is with the "old team",
the IT people in India appear to be very mobile from what I hear, and OS
internals most likely respond best to dedicated people, both to the
product, and in longevity on the job.

(I'm good at "run-on" sentences.)

So, since I've gotten "far out" already, why stop now?

Why do you / your customer purchase support from HP? For one thing,
they're big enough to sue. So, if they fail you, sue the shit out of
them. Sue for so much, they no longer view VMS as a "cash cow". Settle
with one of the terms being that they open source / place in the public
domain VMS. Right now, one of the biggest, maybe the biggest, hurdle to
support, development, and port to x86 of VMS by other than HP is HP. As
long as they are milking the cash cow, they don't give a damn about VMS,
and don't care about any potential harm they are doing to VMS, and
prevent others from doing any good.

:-)

[Scott Dorsey]

Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de> wrote:

>In article <koo4an$n5i$1...@usenet01.boi.hp.com>, Keith Parris
><keithparris...@yahoo.com> writes:
>
>> For over 35 years, the HP OpenVMS operating environment has served as
>> a mission-critical platform upon which you have built your IT
>> infrastructure. We deeply appreciate our long partnership and also
>> the loyalty you have shown HP during this time. We are committed
>> to providing you updates and support for the V8.4 OpenVMS operating
>> environment through at least December 31, 2020.
>
>Even in the DEC days, there was the "unix is the future" garbage. Then
>various migration stuff. In the past, it was retracted, but, I fear, no
>more. This is the end.

DEC always had a very mixed relationship with Unix. There were groups
inside the company that were for it, there were groups inside the company
that were against it, there were other groups that thought Windows NT on
the Alpha was going to be the future. There was no single vision.

>Do they really think that loyal VMS customers, when forced to move off
>of VMS, will stay with HP? Why should they?

HP on the other hand, has a single vision, and it's not one that includes
formerly loyal VMS customers.

I do have to agree that the itanium is a total dead end, though, and I
am not surprised that the project to port is gone away. I do think that
if someone at HP had any vision a decade ago that we'd have x86 VMS by
now, but I don't think that's got a chance either because I don't think
HP cares about a mere handful of a couple thousand customers when they have
much larger markets to sell to.

[David Froble]

Nor can HP (hopelessly pathetic) put out anything without at least one
typo that was not caught by proof reading.

[Howard S Shubs]

In article <koohq2$g25$1...@dont-email.me>,

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> PS: Sorry for the above rant; it's turned out to be a long winded way of
> saying I still cannot tell if it's the VMS internals or the new team
> which are at fault here. :-)

How much does it matter?

[David Froble]

Well, I have to ask, do they really have "much larger markets" to sell
to? Remember, thousands are made up of multiple hundreds, hundreds are
made up of multiple dozens, and dozens are made up of individuals. Just
how many customers can any company piss off and still be able to count
on "much larger markets" ???

The Titanic was too big to sink ....

HP is too big to go under ....

Don't make me have to dig up more such beliefs that turned out to be
false ....

As for those VMS customers, however many there are, can there be any
more captive customers? Anyone who could easily have left VMS is long gone.

[Bill Gunshannon]

In article <kooia4$g25$2...@dont-email.me>,

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> On 2013-06-05, Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de> wrote:
>> In article <kona11$8b4$1...@dont-email.me>, Simon Clubley
>><clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>> So either the VMS internals proved to be too rigid and inflexible to
>>> change in a reasonable amount of time or the current VMS Engineering
>>> outfit turned out to be incapable of understanding VMS enough to modify
>>> it's internals in any significant way. I wonder which one it was ?
>>
>> A few years ago, I would have expected JF to chime in and cite this as
>> evidence that VMS will be ported to x86. But even he has given up.
>>
>
> If they (or VMS) cannot handle a variant within a supported architecture,
> then what makes you think they can add support for a whole new architecture
> to the existing VMS code base ? :-)
>
> You may still see VMS on x86 if the FreeVMS people make any real headway.
> I do think the microkernel based approach is the correct one for FreeVMS;
> if done correctly, this would lead to a clean and easy to maintain codebase
> while still implementing the required VMS specific functionality.

Which will not be VMS. If it is truly VMS that you want then there is
only one source. Nothing else will be VMS. Period. If all you really
want is a VMS API then grab a BSD and start writting. It will be just
as much VMS as whatever the FreeVMS guys are doing.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Phillip Helbig---undress to reply]

In article <kooia4$g25$2...@dont-email.me>, Simon Clubley

<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> You may still see VMS on x86 if the FreeVMS people make any real headway.

But isn't this even less realistic than any of the other pipe dreams
sometimes touted here? How many people spent how many years developing
VMS? What are the resources of FreeVMS?

[Phillip Helbig---undress to reply]

In article <kools2$4e0$1...@dont-email.me>, David Froble

<da...@tsoft-inc.com> writes:

> Other ports could be possible. Power? Some new CPU that doesn't exist
> today, but comes out next month and kills every other CPU in existence
> with price and performance. Alpha is resurrected with new technology
> that blows everything else away, is cheaper, etc ...

Dream on. If the reason is lack of a business case, that applies to
other architectures as well. If the reason is that a port to a new
Itanium variant is too difficult, then that must apply even more so to a
completely different architecture.

> Why do you / your customer purchase support from HP?

Most people because they think that support from the manufacturer is
better than from a third party.

> For one thing,
> they're big enough to sue. So, if they fail you, sue the shit out of
> them. Sue for so much, they no longer view VMS as a "cash cow". Settle
> with one of the terms being that they open source / place in the public
> domain VMS. Right now, one of the biggest, maybe the biggest, hurdle to
> support, development, and port to x86 of VMS by other than HP is HP. As
> long as they are milking the cash cow, they don't give a damn about VMS,
> and don't care about any potential harm they are doing to VMS, and
> prevent others from doing any good.
>
> :-)

The smiley means you realize that the above paragraph is pure bullshit,
of course.

[Anton Shterenlikht]

> we will not offer OpenVMS no HP Integrity i4 ("Poulson") servers.

http://www.theregister.co.uk/2013/05/23/hp_q2_f2013_numbers/

Two quotes:

"HP continues to be adversely impacted by the decline
in Itanium-based Integrity and Superdome 2 server sales,
which fell 37 per cent in the quarter to a mere $266m.
Industry Standard Servers - that means ProLiant rack,
tower, and blade servers and the BladeSystem, SL6500,
and now Moonshot enclosures -
took a 12 per cent revenue hit to $2.81bn."

"The Printing Group was a bright spot on the profit front,
with operating earnings of $958m, up 18.6 per cent against
a revenue decrease of eight-tenths of a point to $6.08bn.
Ink saved HP's cookies once again,
with supplies up 1.5 per cent to $4.12bn.
Printing hardware sold to businesses
brought in another $1.4bn (down 5.5 per cent)
and consumer printing gear brought in
another $561m (down 5.4 per cent)."

Anton

[Jan-Erik Soderholm]

David Froble wrote 2013-06-06 02:49:

> Simon Clubley wrote:
>> PS: Sorry for the above rant; it's turned out to be a long winded way of
>> saying I still cannot tell if it's the VMS internals or the new team
>> which are at fault here. :-)
>>
>

> As to your queue manager problem, sometimes there are unexplained
> un-reproducable events that you just have to move beyond and get on with
> life. This may be one of them. It appears that you already found out that
> there is some buffering. Maybe let it go at that.

I must agree with David here.
Why chase a once-in-a-lifetime incident?
As far as I understand it, it only happend once, right?
If it did happen at all as described, which at least *I*
can't know for sure, of course.

I'm not sure this is usable as an argument against the
"new team" at this stage. I/we also need to see the
actual mail conversations (or here the phone calls)
to be able to judge in a fair way.

Single sided descriptions of events are always hard to judge.

Jan-Erik.

[johnso...@gmail.com]

On Wednesday, June 5, 2013 3:42:10 PM UTC-4, Keith Parris wrote:

> To maintain and grow your mission-critical OpenVMS environment, we have
> extended sales of the Integrity i2 servers for OpenVMS through at least
> December 31, 2015 and sales of Integrity i2 server upgrades for OpenVMS
> through at least December 31, 2016. We will also extend Integrity i2
> server hardware support through at least December 31, 2020.

It seems like the distinction between purchasing new vs. an upgrade is
a little arbitrary. Obviously, from a sales stand point, I can appreciate
the desire to make sure those who have yet to upgrade to an i2 can
still have a seat at the table even if they are very late. But on the flip side,
they are the same parts, and if there's only a handful left, you'd correctly
sell them when a client is willing to pay.

I suspect the real situation is - while supplies last is the more truthful
statement and you probably have supplies for a couple of years based on
previous sales patterns.

EJ

[Johnny Billquist]

On 2013-06-05 14:13, Simon Clubley wrote:
> On 2013-06-05, Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de> wrote:
>> In article <kolh52$sq9$1...@usenet01.boi.hp.com>, Keith Parris
>> <keithparris...@yahoo.com> writes:
>>
>>> HP has released a new OpenVMS Roadmap at
>>> http://hp.com/go/openvms/roadmap/ dated May 2013.
>>>
>>> It omits any mention of Poulson support.
>>
>
> So either the VMS internals proved to be too rigid and inflexible to
> change in a reasonable amount of time or the current VMS Engineering
> outfit turned out to be incapable of understanding VMS enough to modify
> it's internals in any significant way. I wonder which one it was ?

I think it's neither. It's simply a case of not wanting to put any more
money into something they already decided to terminate.
No matter how simple it is, it is still a lot of money to put into it.
Software to be written. Tests to be done on various new hardware. More
documentation to write. Distributions to produce... The list goes on...
All that translates to invested money. Will they make that money back?
Doubtful. Anyone on VMS and Itanium will be paying almost the same
anyway. They will buy new machines at about the same rate even without
Poulson. People still on Alpha are the same story.
Let's not forget that we've now essentially seen the EOL statement for
VMS. New investments will be few from now on. Poulson would be a new
investment.
If VMS presented a roadmap that had extended beyond 8.4 then Poulson
might have been motivated. As things stand, it is not.

From now on, we'll only be seeing new lows in the commitment to VMS
from HP. Basically do as little as they can get away with.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Simon Clubley]

On 2013-06-06, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
> David Froble wrote 2013-06-06 02:49:
>
>> Simon Clubley wrote:
>>> PS: Sorry for the above rant; it's turned out to be a long winded way of
>>> saying I still cannot tell if it's the VMS internals or the new team
>>> which are at fault here. :-)
>>>
>>
>> As to your queue manager problem, sometimes there are unexplained
>> un-reproducable events that you just have to move beyond and get on with
>> life. This may be one of them. It appears that you already found out that
>> there is some buffering. Maybe let it go at that.
>
> I must agree with David here.
> Why chase a once-in-a-lifetime incident?
> As far as I understand it, it only happend once, right?
> If it did happen at all as described, which at least *I*
> can't know for sure, of course.
>

Because these events are simply not supposed to happen in VMS and in the
old days people spent a lot of effort to find them and eliminate them
because VMS was held to a higher standard than other OS options.

If transactions are not been committed to disk as a atomic operation, and
hence vulnerable to been lost in a power failure, then that goes against
the very design criteria that VMS was built against and at one time, the
regulars here in comp.os.vms also held VMS to those standards.

> I'm not sure this is usable as an argument against the
> "new team" at this stage. I/we also need to see the
> actual mail conversations (or here the phone calls)
> to be able to judge in a fair way.
>

I do understand what you are saying. I suppose I am getting frustrated
because I expect a higher standard of support for a enterprise OS and
because I've been through similar issues a number of times back in the
old VMS Engineering days, and what's currently taken a couple of months
without clear answers, only took a couple of weeks or so back in those
days and I got a clear definitive resolution as well.

I'm also worried that if they cannot answer this, then what happens when
VMS gets a Internet facing zero day exploit and you are relying on them
to quickly provide a reliable emergency patch for that or some other
similar emergency situation.

Simon.

[Simon Clubley]

Now that EOL has come, I suppose not much really, but it would have been
nice to know, just for completeness. :-)

Simon.

PS: Of course, Johnny's take on this in another response is equally possible
in that HP may simply have decided to stop spending any more money on VMS.

[Simon Clubley]

Linux was once a little hobbyist project and is now the dominant definition
of what a Unix style system is.

However, sadly I do agree, but for other reasons. If FreeVMS had started
10 years or so earlier, it could have captured the imagination of people who
could help. However, we now have Enterprise capable Linux instead so the
time in which FreeVMS could have made a difference has long passed.

[VAXman-]

In article <kooocr$h9u$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>Scott Dorsey wrote:
>> Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de> wrote:
>
>>> Do they really think that loyal VMS customers, when forced to move off
>>> of VMS, will stay with HP? Why should they?
>>
>> HP on the other hand, has a single vision, and it's not one that includes
>> formerly loyal VMS customers.
>>
>> I do have to agree that the itanium is a total dead end, though, and I
>> am not surprised that the project to port is gone away. I do think that
>> if someone at HP had any vision a decade ago that we'd have x86 VMS by
>> now, but I don't think that's got a chance either because I don't think
>> HP cares about a mere handful of a couple thousand customers when they have
>> much larger markets to sell to.
>> --scott
>>
>
>Well, I have to ask, do they really have "much larger markets" to sell
>to? Remember, thousands are made up of multiple hundreds, hundreds are
>made up of multiple dozens, and dozens are made up of individuals. Just
>how many customers can any company piss off and still be able to count
>on "much larger markets" ???
>
>The Titanic was too big to sink ....
>
>HP is too big to go under ....

Let them die.

Well, one thing is probably certain, HP do not have a union presence in
bed with the Politique, so the likelihood of a bail out is questionable.

[VAXman-]

In article <b1adjd...@mid.individual.net>, bi...@server1.cs.uofs.edu (Bill Gunshannon) writes:
>In article <kooia4$g25$2...@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> On 2013-06-05, Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de> wrote:
>>> In article <kona11$8b4$1...@dont-email.me>, Simon Clubley
>>><clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>> So either the VMS internals proved to be too rigid and inflexible to
>>>> change in a reasonable amount of time or the current VMS Engineering
>>>> outfit turned out to be incapable of understanding VMS enough to modify
>>>> it's internals in any significant way. I wonder which one it was ?
>>>
>>> A few years ago, I would have expected JF to chime in and cite this as
>>> evidence that VMS will be ported to x86. But even he has given up.
>>>
>>
>> If they (or VMS) cannot handle a variant within a supported architecture,
>> then what makes you think they can add support for a whole new architecture
>> to the existing VMS code base ? :-)
>>
>> You may still see VMS on x86 if the FreeVMS people make any real headway.
>> I do think the microkernel based approach is the correct one for FreeVMS;
>> if done correctly, this would lead to a clean and easy to maintain codebase
>> while still implementing the required VMS specific functionality.
>
>Which will not be VMS. If it is truly VMS that you want then there is
>only one source. Nothing else will be VMS. Period. If all you really
>want is a VMS API then grab a BSD and start writting. It will be just
>as much VMS as whatever the FreeVMS guys are doing.

Sad but true. DCL is to VMS what bash is to unix/linux. There's so much
more to VMS than just a CLI and some APIs.

[Simon Clubley]

On 2013-06-05, Keith Parris <keithparris...@yahoo.com> wrote:
> On 6/4/2013 2:02 PM, Keith Parris wrote:
>> HP has released a new OpenVMS Roadmap at
>> http://hp.com/go/openvms/roadmap/ dated May 2013.
>>
>> It omits any mention of Poulson support.
>
> HP has released the following customer letter:

Keith,

Do you have a link to the letter on a official HP website please ?

I've had a look on the HP VMS website and could not see it.

[I need to refer to something posted on a official HP resource instead of
something posted in Usenet.]

Thanks,

[David Froble]

Phillip Helbig---undress to reply wrote:
> In article <kools2$4e0$1...@dont-email.me>, David Froble
> <da...@tsoft-inc.com> writes:
>
>> Other ports could be possible. Power? Some new CPU that doesn't exist
>> today, but comes out next month and kills every other CPU in existence
>> with price and performance. Alpha is resurrected with new technology
>> that blows everything else away, is cheaper, etc ...
>
> Dream on. If the reason is lack of a business case, that applies to
> other architectures as well. If the reason is that a port to a new
> Itanium variant is too difficult, then that must apply even more so to a
> completely different architecture.
>
>> Why do you / your customer purchase support from HP?
>
> Most people because they think that support from the manufacturer is
> better than from a third party.

Well, in this case, perhaps they are wrong ???

>> For one thing,
>> they're big enough to sue. So, if they fail you, sue the shit out of
>> them. Sue for so much, they no longer view VMS as a "cash cow". Settle
>> with one of the terms being that they open source / place in the public
>> domain VMS. Right now, one of the biggest, maybe the biggest, hurdle to
>> support, development, and port to x86 of VMS by other than HP is HP. As
>> long as they are milking the cash cow, they don't give a damn about VMS,
>> and don't care about any potential harm they are doing to VMS, and
>> prevent others from doing any good.
>>
>> :-)
>
> The smiley means you realize that the above paragraph is pure bullshit,
> of course.
>

Actually, no, I do NOT realize that ....

Tell me, what would you call

1) get rid of the competent VMS developers

2) move the product to India, with jobs being a revolving door, and
people not staying in a job long enough to learn it, if they are competent

3) realize that they don't have the expertize to implement VMS on the
next generation of IA-64 and therefore tell customers they (HP) will
just continue to sell them the old hardware

4) hang onto ownership of VMS to milk the cash cow and prevent others
from doing what they (HP) themselves don't have the will or expertise to
do themselves

So, tell me, what would YOU call all that ???

[David Froble]

Simon Clubley wrote:
> On 2013-06-06, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>> David Froble wrote 2013-06-06 02:49:
>>
>>> Simon Clubley wrote:
>>>> PS: Sorry for the above rant; it's turned out to be a long winded way of
>>>> saying I still cannot tell if it's the VMS internals or the new team
>>>> which are at fault here. :-)
>>>>
>>> As to your queue manager problem, sometimes there are unexplained
>>> un-reproducable events that you just have to move beyond and get on with
>>> life. This may be one of them. It appears that you already found out that
>>> there is some buffering. Maybe let it go at that.
>> I must agree with David here.
>> Why chase a once-in-a-lifetime incident?
>> As far as I understand it, it only happend once, right?
>> If it did happen at all as described, which at least *I*
>> can't know for sure, of course.
>>
>
> Because these events are simply not supposed to happen in VMS and in the
> old days people spent a lot of effort to find them and eliminate them
> because VMS was held to a higher standard than other OS options.

Regardless, things did happen in the old days. I think maybe the
difference is that then the engineers could realize it, and now the make
believe engineers don't even know enough to admit it. And yes, many
users have held VMS to that higher standard, and don't want to lose that
higher standard. weendoze anyone ???

> If transactions are not been committed to disk as a atomic operation, and
> hence vulnerable to been lost in a power failure, then that goes against
> the very design criteria that VMS was built against and at one time, the
> regulars here in comp.os.vms also held VMS to those standards.
>
>> I'm not sure this is usable as an argument against the
>> "new team" at this stage. I/we also need to see the
>> actual mail conversations (or here the phone calls)
>> to be able to judge in a fair way.
>>
>
> I do understand what you are saying. I suppose I am getting frustrated
> because I expect a higher standard of support for a enterprise OS and
> because I've been through similar issues a number of times back in the
> old VMS Engineering days, and what's currently taken a couple of months
> without clear answers, only took a couple of weeks or so back in those
> days and I got a clear definitive resolution as well.
>
> I'm also worried that if they cannot answer this, then what happens when
> VMS gets a Internet facing zero day exploit and you are relying on them
> to quickly provide a reliable emergency patch for that or some other
> similar emergency situation.
>
> Simon.
>

A valid worry. Though, I think you're already getting a taste of what
you'd get then ....