1 year.

[Jan-Erik Soderholm]

Right, the 1-year-day from the 1-aug-2014 announcement
from VSI is comming soon. I thought it would be interesting
to sum up some view on the passed year. Here are a few
view on this from me...

The FAQ seems, as far as I can see, to be unchanged since
first published. Has there been no new frequently asked
questions for a whole year?

What is the difference between "About->News" and "Updates"?
Last update on http://vmssoftware.com/news.html is in sep-14.

Generally, the web page could do well with a bit of "polishing".

Facebook. A bit hard to follow. I'm not a FB user myself.
There is no sign on the webpage when there is/was any
update to the FB contents. Checked now and there was a
couple of intersting notes. There are no trace of these
notes on the web site "news" or "update" pages...

Technicaly, it is hard to have any opinion, there havn't been
much info to comment on really. The 1H1 release was of
course nice, though...

I would like to see support for VMS/Alpha (from HP or VSI) to
better match the planned release of VMS/x86 with no "gap"
between them. There have been no signs that VSI would take
over the Alpha support after 31-dec-2016.

[Simon Clubley]

On 2015-07-26, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
> Right, the 1-year-day from the 1-aug-2014 announcement
> from VSI is comming soon. I thought it would be interesting
> to sum up some view on the passed year. Here are a few
> view on this from me...
>

Wow. I can't believe it's a full year since this all kicked off. :-)

> The FAQ seems, as far as I can see, to be unchanged since
> first published. Has there been no new frequently asked
> questions for a whole year?
>
> What is the difference between "About->News" and "Updates"?
> Last update on http://vmssoftware.com/news.html is in sep-14.
>

The information on the home page is more up to date than in News
and it does seem information is dispersed between multiple pages.

> Generally, the web page could do well with a bit of "polishing".
>

I agree. The news on the home page should also be in the News section
or the News section should be removed as having an out of date News
section could be confusing.

BTW, I mistyped the above URL and typed https://vmssoftware.com/news
instead; I got an Index page as a result. Those of you here from VSI
should probably ask your web person to turn off the public Index pages
in case there's WIP things you don't want people to see yet.

> Facebook. A bit hard to follow. I'm not a FB user myself.
> There is no sign on the webpage when there is/was any
> update to the FB contents. Checked now and there was a
> couple of intersting notes. There are no trace of these
> notes on the web site "news" or "update" pages...
>

I browse FB with Javascript disabled. When I look at the VSI page,
I see dates and times under each entry. Is it different for you ?

(The latest entry is 24 July at 06:16, BTW)

I don't see any recent updates to the VMS usage map BTW.

> Technicaly, it is hard to have any opinion, there havn't been
> much info to comment on really. The 1H1 release was of
> course nice, though...
>
> I would like to see support for VMS/Alpha (from HP or VSI) to
> better match the planned release of VMS/x86 with no "gap"
> between them. There have been no signs that VSI would take
> over the Alpha support after 31-dec-2016.
>

I think there are contract and HP structural issues here. IIRC, VSI
don't have the rights to Alpha and I seriously question how motivated
HP will be to extend this cutoff date given what else is happening
within HP.

Simon.

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

[Jan-Erik Soderholm]

Den 2015-07-27 kl. 03:56, skrev Simon Clubley:
> On 2015-07-26, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>> Right, the 1-year-day from the 1-aug-2014 announcement
>> from VSI is comming soon. I thought it would be interesting
>> to sum up some view on the passed year. Here are a few
>> view on this from me...
>>
>
> Wow. I can't believe it's a full year since this all kicked off. :-)
>
>> The FAQ seems, as far as I can see, to be unchanged since
>> first published. Has there been no new frequently asked
>> questions for a whole year?
>>
>> What is the difference between "About->News" and "Updates"?
>> Last update on http://vmssoftware.com/news.html is in sep-14.
>>
>
> The information on the home page is more up to date than in News
> and it does seem information is dispersed between multiple pages.
>
>> Generally, the web page could do well with a bit of "polishing".
>>
>
> I agree. The news on the home page should also be in the News section
> or the News section should be removed as having an out of date News
> section could be confusing.
>
> BTW, I mistyped the above URL and typed https://vmssoftware.com/news
> instead; I got an Index page as a result. Those of you here from VSI
> should probably ask your web person to turn off the public Index pages
> in case there's WIP things you don't want people to see yet.

He he... Following that link one find the old/first roadmap where it
says "These roadmaps are updated approximately every 3 months."
That writing was "lost" in the feb-15 roadmap...
https://vmssoftware.com/news/zzdrafts/VMS_Software_Roadmap_20140731.pdf

>
>> Facebook. A bit hard to follow. I'm not a FB user myself.
>> There is no sign on the webpage when there is/was any
>> update to the FB contents. Checked now and there was a
>> couple of intersting notes. There are no trace of these
>> notes on the web site "news" or "update" pages...
>>
>
> I browse FB with Javascript disabled. When I look at the VSI page,
> I see dates and times under each entry. Is it different for you ?
>

What I ment was that two of the updates (the Oracle info and LP field
test) have to trace in the news/updates pages at vmssoftware.com.

I can see and read the FB all right, when I remember to do that... :-)

> (The latest entry is 24 July at 06:16, BTW)
>
> I don't see any recent updates to the VMS usage map BTW.
>
>> Technicaly, it is hard to have any opinion, there havn't been
>> much info to comment on really. The 1H1 release was of
>> course nice, though...
>>
>> I would like to see support for VMS/Alpha (from HP or VSI) to
>> better match the planned release of VMS/x86 with no "gap"
>> between them. There have been no signs that VSI would take
>> over the Alpha support after 31-dec-2016.
>>
>
> I think there are contract and HP structural issues here. IIRC, VSI
> don't have the rights to Alpha and I seriously question how motivated
> HP will be to extend this cutoff date given what else is happening
> within HP.
>

I fully understand that. But it is a problem for those still on Alpha
that might want to skip the IA64 step.



> Simon.
>

[Keith Parris]

From what I've been told, VSI does indeed have rights to Alpha and VAX
but can't take over support for a given HP version of software until HP
drops all levels of support for that version (even Mature Product
Support without Sustaining Engineering), or else VSI releases their own
version of that software. So if VSI shipped a VAX and/or Alpha version
of OpenVMS they could sell and support those.

The Dec. 2014 HP OpenVMS Roadmap shows HP will offer Mature Product
Support without Sustaining Engineering for HP OpenVMS Alpha 6.2*, 7.3-2,
8.3, and 8.4 through at least the end of 2018. There's no mention of HP
support for Alpha versions 1.0, 1.5, 6.0/6.1, 7.0/7.1*/7.2*/7.3/7.3-1 or
8.2 so presumably VSI could support those Alpha versions now if it chose.

[David Froble]

Keith Parris wrote:
> On 7/26/2015 7:56 PM, Simon Clubley wrote:
>> On 2015-07-26, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>> I would like to see support for VMS/Alpha (from HP or VSI) to
>>> better match the planned release of VMS/x86 with no "gap"
>>> between them. There have been no signs that VSI would take
>>> over the Alpha support after 31-dec-2016.
>>
>> I think there are contract and HP structural issues here. IIRC, VSI
>> don't have the rights to Alpha and I seriously question how motivated
>> HP will be to extend this cutoff date given what else is happening
>> within HP.
>
> From what I've been told, VSI does indeed have rights to Alpha and VAX
> but can't take over support for a given HP version of software until HP
> drops all levels of support for that version (even Mature Product
> Support without Sustaining Engineering), or else VSI releases their own
> version of that software. So if VSI shipped a VAX and/or Alpha version
> of OpenVMS they could sell and support those.

Which of course brings out the "lawyer" in me. :-)

Last VAX release was 7.3. If VSI took the VAX stuff, changed the
release to say V7.3-1, with no other changes, would that be considered a
new and VSI supportable release? Just might be someone out there that
would pay them to do that.

> The Dec. 2014 HP OpenVMS Roadmap shows HP will offer Mature Product
> Support without Sustaining Engineering for HP OpenVMS Alpha 6.2*, 7.3-2,
> 8.3, and 8.4 through at least the end of 2018. There's no mention of HP
> support for Alpha versions 1.0, 1.5, 6.0/6.1, 7.0/7.1*/7.2*/7.3/7.3-1 or
> 8.2 so presumably VSI could support those Alpha versions now if it chose.

I've got to believe that the old versions are pretty much a dead end.
But then, after what I wrote above, who knows? I don't. VSI might.

[Robert A. Brooks]

On 7/27/2015 12:29 PM, David Froble wrote:

> Keith Parris wrote:

>> From what I've been told, VSI does indeed have rights to Alpha and VAX but
>> can't take over support for a given HP version of software until HP drops all
>> levels of support for that version (even Mature Product Support without
>> Sustaining Engineering), or else VSI releases their own version of that
>> software. So if VSI shipped a VAX and/or Alpha version of OpenVMS they could
>> sell and support those.

>> The Dec. 2014 HP OpenVMS Roadmap shows HP will offer Mature Product Support
>> without Sustaining Engineering for HP OpenVMS Alpha 6.2*, 7.3-2, 8.3, and 8.4
>> through at least the end of 2018. There's no mention of HP support for Alpha
>> versions 1.0, 1.5, 6.0/6.1, 7.0/7.1*/7.2*/7.3/7.3-1 or 8.2 so presumably VSI
>> could support those Alpha versions now if it chose.
>
> I've got to believe that the old versions are pretty much a dead end. But then,
> after what I wrote above, who knows? I don't. VSI might.

The likelihood of VSI doing anything with the VAX is 0. The likelihood of VSI
doing anything with the Alpha is pretty much near 0.

Yes, the code between Alpha and IA64 is pretty much the same (object/images
being a major difference). Nonetheless, the time/effort/labour it takes to
build/test/release for Alpha is more than we want to expend now (and most
likely in the future, especially once x86 development really ramps up).

We need to make money, and it isn't going to be done developing software for
hardware that hasn't been updated in a decade. If a customer comes to us with
a need for an Alpha version, is willing to pay for it, and it makes financial
sense, then we'd consider it.

The customers we've been in touch with are interested in IA64 and x86.

--
-- Rob

[Jan-Erik Soderholm]

Yes, of course... :-) I/we do not need any *new* Alpha version, we need
something supported between Alpha and x86. It is not likely that we will
first move/port to IA64. But yes, HP does offer "Mature Product Support
without Sustaining Engineering". Or, one could probably run unsupported
during the wait for x86, not much worse than running an Alpha server,
is it? :-)

Note that I have no knowledge about the cost differences (if any)
between Standard Support (as of today) and "Mature Product Support
without Sustaining Engineering" (from 1-jan-2017).

[Simon Clubley]

On 2015-07-27, Keith Parris <keithparris...@yahoo.com> wrote:
> On 7/26/2015 7:56 PM, Simon Clubley wrote:
>>
>> I think there are contract and HP structural issues here. IIRC, VSI
>> don't have the rights to Alpha and I seriously question how motivated
>> HP will be to extend this cutoff date given what else is happening
>> within HP.
>
> From what I've been told, VSI does indeed have rights to Alpha and VAX
> but can't take over support for a given HP version of software until HP
> drops all levels of support for that version (even Mature Product
> Support without Sustaining Engineering), or else VSI releases their own
> version of that software. So if VSI shipped a VAX and/or Alpha version
> of OpenVMS they could sell and support those.
>

Interesting.

The impression I had got from the discussions over the last year was that
VSI wasn't given the rights to VAX or Alpha as part of the HP contract but
that VSI only had the rights for IA64 and any future ports VSI did.

Thanks for the correction.

[Paul Sture]

On 2015-07-27, David Froble <da...@tsoft-inc.com> wrote:
> Keith Parris wrote:

<snip>

>> The Dec. 2014 HP OpenVMS Roadmap shows HP will offer Mature Product
>> Support without Sustaining Engineering for HP OpenVMS Alpha 6.2*, 7.3-2,
>> 8.3, and 8.4 through at least the end of 2018. There's no mention of HP
>> support for Alpha versions 1.0, 1.5, 6.0/6.1, 7.0/7.1*/7.2*/7.3/7.3-1 or
>> 8.2 so presumably VSI could support those Alpha versions now if it chose.
>
> I've got to believe that the old versions are pretty much a dead end.
> But then, after what I wrote above, who knows? I don't. VSI might.

I inwardly cringed when I saw the earlier Alpha releases there. A
sufficiently rich customer wanting support for those older versions
could be a pain in the neck for VSI by diverting their attention from
moving everyone else forwards.

--
1972 - IBM begins development on its last tape drive (3480) ever because
of the declining cost of disk drives.

[clairg...@gmail.com]

I'll be a little more direct than Rob. We will never do a VAX release.

A year ago I believe I said at the Boot Camp, "We have no plans to do an Alpha release." That has since changed to "We will never do an Alpha release".

I usually have a "never say never" approach to things but these two are as solidly "never" as I can imagine.

VSI was created to move VMS into the future by presenting a line of sight to hardware platforms beyond Itanium. Anything we do not directly supporting Itanium or porting to x86 delays that goal.

[Hans Vlems]

Good, I like a clear, direct statement and your reasoning is sound.
Now only hobbyists run a VAX and there is no money there (and even less at a business that relies on them).
But Jan-Erik raises a point about Alpha. Work on it that won't generate turnover now but will preserve a customer base for you later on.
How about subcontracting work on alpha/vms, test it on limited platforms and supply it with limited wartanty?
Hans

[Hans Vlems]

[Jan-Erik Soderholm]

Since I started all this... :-)

Note that the current VMS on Alpha works perfectly well. There is
no need for any "work" on it or any "new version" and I do not
expect VSI to put any man-hours on it, as far as we are concerned.

The only issue is the support gap between end-of-support pf VMS/Alpha
and a possible VMS/x86 release. Doing an IA64 port just for filling
that gap isn't something we can build a business case around.

The easiest solution would be for HP to prolonge support of
current VMS/Alpha until GA of VMS/x86.

We could also switch to VMS/IA64 (probably not i4) "now", but then
we would probably never switch to VMS/x86.

[David Froble]

clairg...@gmail.com wrote:
> I'll be a little more direct than Rob. We will never do a VAX release.

VAX/VMS V7.3 works. No problems that I'm aware of. So, it's not like
there is any work involved. However, if someone wants to throw money at
a support contract, would it be turned down? Just wondering?

> A year ago I believe I said at the Boot Camp, "We have no plans to do an Alpha release." That has since changed to "We will never do an Alpha release".

Pretty much the same argument for Alpha.

> I usually have a "never say never" approach to things but these two are as solidly "never" as I can imagine.

Never lasts until enough money is on the table ....

> VSI was created to move VMS into the future by presenting a line of sight to hardware platforms beyond Itanium. Anything we do not directly supporting Itanium or porting to x86 delays that goal.

Actually, it isn't the OS that might be a candidate for new stuff. For
instance, the new and improved TCP/IP that I'm led to believe you're
working on. Now, that just might be very useful to people on Alpha,
itanic, as well as x86.

All of my customers sure could use a better TCP/IP than what's available
today. They are all on itanic, so Alpha isn't an issue for them. The
system I use to work on their stuff is an Alpha, and yeah, I got a VAX
too. If for instance TCP/IP could be built for Alpha, even if not
supported, it might be very helpful to have.

Same argument for other new and improved stuff.

[Hans Vlems]

You are right about the IP stack, that needs work irrespective of the underlying hardware. May I add cluster support for vax/vms 7.3 and axp/vms 8.4 so that these systems remain compatible with ia64 and x64 until x64/vms is say, a year old?

[David Froble]

Hans Vlems wrote:
> You are right about the IP stack, that needs work irrespective of the underlying hardware. May I add cluster support for vax/vms 7.3 and axp/vms 8.4 so that these systems remain compatible with ia64 and x64 until x64/vms is say, a year old?

If there is anybody in a position to actually know if there is such a
demand, I'd think it would be VSI. Now, there may be some VAXs still
running, but, do the people using them really care about support?
That's the real question. I sure would not waste time and effort on a
market that doesn't exist.

Same argument for Alpha, however, we're aware of some still using Alpha.
Do they want or need support? Good question. If the systems are
running, why the need for support?

Anything that gets in the way of getting VMS on HW that is still being
developed and seems to have a future would be, in my opinion, not good.

[clairg...@gmail.com]

On Monday, July 27, 2015 at 5:18:33 PM UTC-4, David Froble wrote:
> clairg...@gmail.com wrote:
> > I'll be a little more direct than Rob. We will never do a VAX release.
>
> VAX/VMS V7.3 works. No problems that I'm aware of. So, it's not like
> there is any work involved. However, if someone wants to throw money at
> a support contract, would it be turned down?

Yes

>Just wondering?
>
> > A year ago I believe I said at the Boot Camp, "We have no plans to do an Alpha release." That has since changed to "We will never do an Alpha release".
>
> Pretty much the same argument for Alpha.

I'm doing everything I can to make it the same answer for Alpha.

>
> > I usually have a "never say never" approach to things but these two are as solidly "never" as I can imagine.
>
> Never lasts until enough money is on the table ....

I generally agree but in this case I don't think so. If people want to turn VSI into a support organization this is the way to do it. If VSI is to move VMS forward to future platforms with updated software we need to focus and, in my opinion, getting into the Alpha world would totally undermine that.

[Jan-Erik Soderholm]

Agree. VSI should probably do as little as possible with VAX and
Alpha with the goal beeing "nothing". :-)

I was just pointing out that there is a "support gap" for those that
(for any reason) would like to go direcly from Alpha to x86.

I'm not saying that that is VSI fault or that I expect VSI
to "fill that gap", but for *us* it is still a gap... :-)

We'll probably sort that out during the autumn and decide
how to act in regard to the hardware platform during 2016.

Jan-Erik.

[Hans Vlems]

Op dinsdag 28 juli 2015 12:36:26 UTC+2 schreef clairg...@gmail.com:

> On Monday, July 27, 2015 at 5:18:33 PM UTC-4, David Froble wrote:
> > clairg...@gmail.com wrote:
> > > I'll be a little more direct than Rob. We will never do a VAX release.
> >
> > VAX/VMS V7.3 works. No problems that I'm aware of. So, it's not like
> > there is any work involved. However, if someone wants to throw money at
> > a support contract, would it be turned down?
>
> Yes
>
> >Just wondering?
> >
> > > A year ago I believe I said at the Boot Camp, "We have no plans to do an Alpha release." That has since changed to "We will never do an Alpha release".
> >
> > Pretty much the same argument for Alpha.
>
> I'm doing everything I can to make it the same answer for Alpha.
> >
> > > I usually have a "never say never" approach to things but these two are as solidly "never" as I can imagine.
> >
> > Never lasts until enough money is on the table ....
>
> I generally agree but in this case I don't think so. If people want to turn VSI into a support organization this is the way to do it. If VSI is to move VMS forward to future platforms with updated software we need to focus and, in my opinion, getting into the Alpha world would totally undermine that.
>

That is right, if you're not careful VSI will become a maintenance organisation.
Which is what we had basically for the past 15 years and didn't like.
You've convinced me, not that it'll help you, I'm a poor hobbyist !

[Keith Parris]

On 7/27/2015 1:40 PM, Jan-Erik Soderholm wrote:
> Note that the current VMS on Alpha works perfectly well. There is
> no need for any "work" on it or any "new version" and I do not
> expect VSI to put any man-hours on it, as far as we are concerned.
>
> The only issue is the support gap between end-of-support pf VMS/Alpha
> and a possible VMS/x86 release. Doing an IA64 port just for filling
> that gap isn't something we can build a business case around.
>

> The easiest solution would be for HP to prolong support of

> current VMS/Alpha until GA of VMS/x86.

We hear VSI is targeting 2018 for OpenVMS on x86. The HP OpenVMS Roadmap
(http://www.hp.com/go/openvms/roadmap on a good day) shows Standard
Support for OpenVMS Alpha through the end of 2016, followed by Mature
Product Support without Sustaining Engineering (MPS w/o SE) until at
least the end of 2018. Is your concern about not having the Standard
Support level of support for the years 2017 and 2018? (Standard Support
would include fixes from OpenVMS Engineering for any new bugs identified
during that time. MPS w/o SE allows access to existing patch kits and
continued tech support via telephone/e-mail/chat, etc.)

Since you said "the current VMS on Alpha works perfectly well" and
"there is no need for any 'work' on it or any 'new version'" I'm
wondering if you really need the Standard Support level, or if MPS w/o
SE would actually meet your needs.

There were versions of the HP OpenVMS Roadmap which showed the end of
Standard Support at the end of 2016 but did not yet show the MPS w/o SE
extending through at least the end of 2018 (these came out in August
2012 and May 2013). Maybe one of those was the last Roadmap you looked
at? (The most-recent update to the Roadmap occurred in December 2014.)

[Keith Parris]

On 7/27/2015 3:21 PM, David Froble wrote:
> VAX/VMS V7.3 works. No problems that I'm aware of. So, it's not like
> there is any work involved. However, if someone wants to throw money at
> a support contract, would it be turned down? Just wondering?

According to the OpenVMS Software Support Chart at
http://h71000.www7.hp.com/openvms/openvms_supportchart.html, HP
continues to provide support for some versions of OpenVMS VAX at the
level of Mature Product Support without Sustaining Engineering. So VSI
could offer support only for the versions HP no longer supports or ship
a new version of OpenVMS VAX; they aren't allowed to sell support
services for HP software versions that HP still supports.

> Pretty much the same argument for Alpha.

Same answer for Alpha as well.

> Never lasts until enough money is on the table ....

In addition to money, contractual limitations can be a factor.

[Keith Parris]

On 7/28/2015 4:36 AM, clairg...@gmail.com wrote:
> If people want to turn VSI into a support organization this
> is the way to do it. If VSI is to move VMS forward to future
> platforms with updated software we need to focus

Profit margins on services like support are significantly greater than
those on software license sales, and an organization that integrates the
two and values both will have more money to devote to R&D and thus a
greater chance of long-term financial success.

[David Froble]

I've been reading the posts on this issue, and trying to get some kind
of handle on them.

Moving into the future is good, and necessary. I won't dispute that.
What I will question is what good is it if you don't drag the customers
along?

Like it or not, your ongoing revenue stream will depend on recurring
support fees. If anyone today thinks there is money is selling
Operating Systems, I think I'll decline investing in such a venture.
The competition will beat you into the ground.

So yeah, move ahead, but then use that effort to build a recurring
revenue stream.

So, yeah, what Keith wrote ....

[David Froble]

Keith,

The following was my original question, which I don't think was directly
addressed.

"Last VAX release was 7.3. If VSI took the VAX stuff, changed the
release to say V7.3-1, with no other changes, would that be considered a
new and VSI supportable release?"

Now, I'm not saying VSI should do this, and Clair indicated that it
ain't gonna happen, but the question as asked still stands and I'm
curious about the answer.

[clairg...@gmail.com]

On Monday, July 27, 2015 at 5:56:52 PM UTC-4, Hans Vlems wrote:
> You are right about the IP stack, that needs work irrespective of the underlying hardware. May I add cluster support for vax/vms 7.3 and axp/vms 8.4 so that these systems remain compatible with ia64 and x64 until x64/vms is say, a year old?

The plan is for x86 VMS to be added to an existing VMS cluster.

[clairg...@gmail.com]

Notice how this discussion bounces back and forth between shipping a new release and supporting an old release (once HP no long does). On the one hand they are two very different animals but on the other they are extremely similar in what it takes resource-wise technically to do them....with one exception, namely supporting s release "without engineering support" to use the HP terminology. I never liked that description because I never thought of it as support but that is probably just my engineer's bias, I guess. Supporting an old release without providing any code fixes or enhancements but being able to look at the code and provide whatever advise possible is not out of the realm of possibility. Of course, there would have to be customers for whom this would be an acceptable support model.

[Robert A. Brooks]

On 7/28/2015 4:49 PM, David Froble wrote:

> The following was my original question, which I don't think was directly addressed.
>
> "Last VAX release was 7.3. If VSI took the VAX stuff, changed the release to
> say V7.3-1, with no other changes, would that be considered a new and VSI
> supportable release?"

If we built it from scratch, and rebranded it, yes we could ship and suppor it.

That goes for Alpha V8.4 as well; we would be within our rights to have built
an Alpha V8.4-1H1 release.

As has been stated with extreme clarity here, it's not going to happen.

--
-- Rob

[Neil Rieck]

Okay so today (2015-07-28) I was visiting HP's patch maintenance site looking for a few OpenVMS things for my new rx2800-i2. Anyone who has ever used the patch tool will remember a drop down selector where you pick your OS version (Itanium before Alpha; 8.4 before 8.3, etc.). Today I noticed the drop-down selector was defaulting to "8.4-1h1"

Proof that VSI is making a difference in the OpenVMS ecosystem

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

[David Froble]

clairg...@gmail.com wrote:

> Notice how this discussion bounces back and forth between shipping a
> new release and supporting an old release (once HP no long does). On
> the one hand they are two very different animals but on the other
> they are extremely similar in what it takes resource-wise technically
> to do them....with one exception, namely supporting s release
> "without engineering support" to use the HP terminology. I never
> liked that description because I never thought of it as support but
> that is probably just my engineer's bias, I guess. Supporting an old
> release without providing any code fixes or enhancements but being
> able to look at the code and provide whatever advise possible is not
> out of the realm of possibility. Of course, there would have to be
> customers for whom this would be an acceptable support model.

Yes, you have put your finger squarely on what's happening. I'm
guessing both sides of the discussion might mean more to you than to
most others.

As for that "without engineering support", I'm 100% with you on that.
What good is it if there really is a bug and nobody will fix it? Other
than telling somebody that they are out of luck, it's rather useless,
strictly from a support perspective.

Now, Dave might say, "hey, it's 2 instructions, change them". While I
understand Clair saying "all that testing and validation on every piece
of hardware we can find ....", it's not the world I live in, and I
cannot "feel" it. Understand, yes. Feel, no. It's your world, and you
probably cannot think of any such changes without feeling the weight of
all the testing and validation.

Put that way, it's probably reasonable to say that if anyone does have
some problem, and VMS on x86 is available, fixing the problem there and
getting that customer onto VMS on x86 would be the best solution.

Please understand, what I feel is important, is to create a future for
VMS, and VSI and x86 is as far as anyone can see is the path to that
future. I'm supportive of your efforts, and anything I can do to help,
I'll do.

That said, you're most likely going to continue to hear outrageous
things from some of us. Guess we have too much idle time. Just grin at
us and continue doing what needs to be done.

Dave

[David Froble]

Robert A. Brooks wrote:
> On 7/28/2015 4:49 PM, David Froble wrote:
>
>> The following was my original question, which I don't think was
>> directly addressed.
>>
>> "Last VAX release was 7.3. If VSI took the VAX stuff, changed the
>> release to
>> say V7.3-1, with no other changes, would that be considered a new and VSI
>> supportable release?"
>
> If we built it from scratch, and rebranded it, yes we could ship and
> suppor it.
>
> That goes for Alpha V8.4 as well; we would be within our rights to have
> built
> an Alpha V8.4-1H1 release.

Thank you, that answered the question, and I think for many people.

> As has been stated with extreme clarity here, it's not going to happen.
>

And I can understand why. I doubt I can "feel" the reasons, but I've
figuratively seen people's eyes get real big when the topic of
validating a new release is mentioned.

Don't always take us so seriously. Many of us are just excited about
what you're doing.

[Phillip Helbig (undress to reply)]

In article <mp5n74$glp$1...@dont-email.me>, "Robert A. Brooks"

<FIRST...@vmssoftware.com> writes:

> The likelihood of VSI doing anything with the VAX is 0. The likelihood of VSI
> doing anything with the Alpha is pretty much near 0.

Except that they said that they would support ALPHA and x86 in a mixed
cluster.

[Phillip Helbig (undress to reply)]

In article <88d3af1f-80dc-4d6c...@googlegroups.com>,

clairg...@gmail.com writes:

> I'll be a little more direct than Rob. We will never do a VAX release.

Good.

> A year ago I believe I said at the Boot Camp, "We have no plans to do
> an Alpha release." That has since changed to "We will never do an Alpha
> release".

Also good. Presumably, supporting Alpha and x86 in the same cluster
will not need an extra Alpha release. So, I guess I can stay at 8.4 on
Alpha until I do a rolling migration to x86.

[Phillip Helbig (undress to reply)]

In article <1227dc75-ea4e-44cf...@googlegroups.com>,

Nice to hear this confirmed. I think it was mentioned even during the
first conference call. OK, it looks like I can avoid Itanium
altogether. I've been on Alpha for almost 20 years, 3 more shouldn't be
a problem.

[Richard Maher]

On 7/29/2015 8:02 AM, clairg...@gmail.com wrote:

> Stuff that doesn't wrap

Look I and many others don't care about VAX Alpha OR *IA64* a long as HP
"supports" VMS (security patches, bug-fixes) but if we have to wait
another 2-3 years for what we have now then attrition rate has to go up :-(

What are you going to do with TCP/IP? IPsec? I like what I heard about
Java but what are you doing? Are you re-committing to Apache or buying
out Mark Daniel? How to catch up the 10 years of VMS atrophy and
bit-rot? Globalization strategy?

If you (quite sensibly) just going for a first cut like-for-like then
why the generous time frame? Sacrifice some control for throughput with
all those low-cost VMS Engineers on the sub-continent?

NB: Don't waste any money on that browser crap they keep bleating for
either!

[Hans Vlems]

Phillip, that is the reason I asked. My guess is that there are a lot more alpha's running in production than HP knew. HP's reasoning : no support contract then obviously decommissioned. Which may be wrong and eventually help VSI when those sites upgrade to x86/VMS.

[IanD]

We are stuck on Alpha

The business has no plans of moving to Itanium. I doubt they can wait for x86 either going by the recent chatter unless there was a financial incentive to do so

Once this VMS platform closes, VMS will have exited this organisation and I seriously doubt it will get a look in again

In telco land as I would imagine in most market segments, letting a customer walk rather than spending money on retaining them costs something like about 2.5x's as much as on-boarding a new customer from scratch, that's a lot of money actually when you take into account all the costs involved (including advertising etc) and often they simply do not return once they have walked. Retaining the existing customer base I think is very important

So how to retain existing Alpha and dare I say Vax customers so they keep VMS in the organisation with the potential to build upon it later?

Offer a free x86 version on which they can run their encapsulated Vax or Alpha system in perhaps? (they would of course still pay for their existing Alpha licenses etc)

This would at least keep an VMS presence in the enterprise and as they are willing/able, functionality could be ported over to the newer x86 version, over time. Small palatable costs are easier to swallow than big expensive ones when it comes to budgeting and approvals

The alternative is what is most likely going to happen where I work, the system will be migrated to a linux platform and the book will be closed on OpenVMS period.
Emulators are expensive over time, so they are seen as stop-gap measures to mitigate old hardware risks

A good salesperson knows that getting/keeping that 'foot in the door' is vital for being able to lever future sales

How to lever those Vax and Alpha shops out there over to the new x86 vision rather than have them walk (probably for good) is very important IMO

[David Froble]

IanD wrote:
> On Tuesday, July 28, 2015 at 5:10:49 AM UTC+10, Hans Vlems wrote:
>> Good, I like a clear, direct statement and your reasoning is sound.
>> Now only hobbyists run a VAX and there is no money there (and even less at a business that relies on them).
>> But Jan-Erik raises a point about Alpha. Work on it that won't generate turnover now but will preserve a customer base for you later on.
>> How about subcontracting work on alpha/vms, test it on limited platforms and supply it with limited wartanty?
>> Hans
>
> We are stuck on Alpha

Is that a business decision or a technical decision?

All of our customers are using itanics. It was a good business
decision, and a good technical decision. They do what the businesses
need. Personally, I'm not a fan of IA-64, for multiple reasons. But,
when advising customers, the task is to give them advice that is best
for them.

> The business has no plans of moving to Itanium.

What is the reason for that? Something not available?

> I doubt they can wait
> for x86 either going by the recent chatter unless there was a
> financial incentive to do so

So, are the Alpha(s) not doing the job satisfactorily? What can they
not wait for?

> Once this VMS platform closes, VMS will have exited this organisation
> and I seriously doubt it will get a look in again

I have to wonder, it the VMS advantage is as minor for the business as
you seem to indicate, and if there are forces pushing for alternative
solutions, I'm wondering why VMS is still in use?

You've made some claims here, and in the past, that as far as I can see
have no details. Without some details, how can anyone understand
whatever points you're trying to make? Without some details, how can
anyone make any suggestions to possibly help you make a case for
continuing usage of VMS in your organization? Can't solve a problem, if
one doesn't know what the problem is ....

> In telco land as I would imagine in most market segments, letting a
> customer walk rather than spending money on retaining them costs
> something like about 2.5x's as much as on-boarding a new customer
> from scratch, that's a lot of money actually when you take into
> account all the costs involved (including advertising etc) and often
> they simply do not return once they have walked. Retaining the
> existing customer base I think is very important

All true ....

> So how to retain existing Alpha and dare I say Vax customers so they
> keep VMS in the organisation with the potential to build upon it
> later?

While I'm not a fan of the itanic, it most definitely has been a valid
platform for VMS for some time now. And, it has been less expensive
than the VAXs and Alphas before it.

> Offer a free x86 version on which they can run their encapsulated Vax
> or Alpha system in perhaps? (they would of course still pay for their
> existing Alpha licenses etc)

Do you mean something such as SimH? It exists. It's free.

> This would at least keep an VMS presence in the enterprise and as
> they are willing/able, functionality could be ported over to the
> newer x86 version, over time. Small palatable costs are easier to
> swallow than big expensive ones when it comes to budgeting and
> approvals

My experience in porting from VAX to Alpha, AND from Alpha to the itanic
has been that it's rather easy and inexpensive. I'm not really sure
what you might be asking for?

> The alternative is what is most likely going to happen where I work,
> the system will be migrated to a linux platform and the book will be
> closed on OpenVMS period. Emulators are expensive over time, so they
> are seen as stop-gap measures to mitigate old hardware risks

If you have applications running on VMS, the easiest and least expensive
path is to continue using VMS. Any migration will be much harder and
more expensive. I'm not claiming that everyone will agree with that.
It will depend upon their agenda. If someone wants off VMS, or just
wants Linux, then they will find arguments to support that desire. Nor
do the arguments need to be valid. They just need to get management to
go far enough along so that turning back would be just as expensive as
continuing, and of course there is ego, and the unwillingness to admit
mistakes.

I feel quite sure that if accurate and honest estimates for each path,
remain on VMS or migrate to something else, remaining on VMS will be
much less expensive.

> A good salesperson knows that getting/keeping that 'foot in the door'
> is vital for being able to lever future sales

Apparently the foot is already in the door, if you're already using VMS.

> How to lever those Vax and Alpha shops out there over to the new x86
> vision rather than have them walk (probably for good) is very
> important IMO

AS I've written, there are valid options. If for some reason someone
refuses to accept them, then I doubt there is anything that could change
their mind(s).

[Hans Vlems]

Well, this is not an uncommon situation. Even at sites that were DEC only and used at one point in time many VAX and/or Alpha systems you might see these numbers reduced to a handful. And these systems are managed by one or two enthusiasts, for reasons few others in that company understand or care for.
They won't migrate to Itanium because it is expensive and targeted at the "enterprise". So eventually VMS will be replaced and the site lost as a customer, likely never to return.
An affordable x86 package with decent license fees might retain them.
Provided that the x86 system is generic, not hardware with a required built-in blessing from VSI and that the current platform survives until x86/VMS comes along. They've been running the current hardware for one, possibly two decades. No way they'll upgrade to keep their VMS based solution running, they buy an entirely new one.

[Hans Vlems]

[IanD]

Rather than do a point by point response...

Basically the organisation likes VMS from a stability point of view

The application has not been touched in over 10 years and there are issues around the source code but I am not at liberty to say what exactly or to make further references to the customer base in case someone data matches certain things and identifies more information than I want to reveal :-)

Then you have the diminishing skills of the folk who are meant to look after the application but being VMS adverse, this too is a loosing downward spiral

If the code could be lifted and put on an Itanium without the need to recompile, the business would have opted for that long ago - hence why I asked somewhere else about what exactly does a dynamic static translator perform - can it solve this issue for us going ahead?

The customer base was once the ants pants as far as the particular industry was concerned but times have changed, they represent a drag on profits now and what they were initially required to do in terms of rapid expansion is no longer required, so they are not a focus anymore hence why the application has languished for so many years

So if I have been terse with my answers, it is with reason in that I do not want the industry identified nor do I wish to disclose too much for concern that the organisation may possibly suffer customer concern if data matching can link the various parts together etc

The alpha is doing the job fine, the problem is the hardware is old, going out of support and the application is no longer supported and the source code is, err, well, in a 'special' category of it's own

Yes, I have spoken with people on the business side to let them know there at least is now a pathway forward as far as VMS is concerned but the above problems are driving their decision to get off VMS

Let's just say that a certain organisation, who makes it profit on body count based in a certain country where IT wages are cheap and quality is sometimes lacking, want a linux system because that way they can rid themselves of the expensive VMS skilled folk and look after whatever new system comes in with the same resource base they currently have, i.e. linux folk. They do not care if this new system match is not the best for their customer nor if the new system will perform any better or be less stable.

It has now got to the stage where the application folk are looking like shall we say, fools in lots of regards as their lack of VMS understanding see's things breaking and falling over with the blame being put back on 'an old system and an old application'. Thus I am fighting fires on different fronts, so to speak, including fire coming from my own camp!

I was thinking of looking at ways to extract the rdb queries by putting debug flags on but this is only part of the equation to working out the application functionality internally. The application itself was developed with corba and my skills in that area are next to none

Can anyone help provide guidance on how / who, to contact so that one can 'function rip' an application that was developed with corba / c++ I believe many years ago and work out a way to develop a new solution on VMS when the source code is, shall we say, somewhat hard to acquire?

Solve this issue and VMS will remain in the workplace, otherwise it's pending doom is already here :-(

[Stephen Hoffman]

On 2015-08-06 15:53:37 +0000, IanD said:

> Can anyone help provide guidance on how / who, to contact so that one
> can 'function rip' an application that was developed with corba / c++ I
> believe many years ago and work out a way to develop a new solution on
> VMS when the source code is, shall we say, somewhat hard to acquire?
> Solve this issue and VMS will remain in the workplace, otherwise it's
> pending doom is already here :-(

While you might like VMS, this certainly appears to a dead-end
near-end-of-life application based on your comments, and it's either
going to get reversed and ported, or — more likely — it'll eventually
and incrementally be replaced on a different platform, or very much
more likely it'll be discontinued after the remaining contractual
and/or financial justifications expire.

Usual approach here would have been binary translation, but that was
apparently nixed. Which usually means that one or more prerequisite
products are unavailable, or the code was otherwise untranslatable
<http://labs.hoffmanlabs.com/node/641>. Quite possibly CORBA itself,
though I've not confirmed that — the associated ObjectBroker product
was apparently sold off to BEA, and that's now all at Oracle, and I
don't see very much published on ObjectBroker and CORBA now.

As for reverse-engineering, I'm not aware of any publicly-available
tools akin to Hopper, Snowman or Capstone Engine for OpenVMS, either.
There are no publicly-available modern disassemblers, and that will
produce something approaching C code from a binary.

There are some publicly-available tools — srm_check — that'll produce
Alpha assembler, but then you're left with assembler.

Or maybe you extend Capstone Engine, or work with somebody else that
can extend it to OpenVMS Alpha on your behalf? Or see if somebody has
some privately-available reverse-engineering tools?

Disassembly and reverse-engineering in general tends to be expensive,
and will usually produce code that's usually not particularly
maintainable.

With any of these tools, this expenditure produces OpenVMS code that's
(still) using CORBA, and that's not exactly a platform seeing a whole
lot of usage. (See <http://queue.acm.org/detail.cfm?id=1142044>, but
I digress.)

The other approach that's used here is an incremental migration or
incremental replacement, and that maps the functions and incrementally
rewrites features or hunks of the environment, and preferably targeting
a platform and language and tools that can be supported in your
environment. I know of various OpenVMS sites that are pursuing this
approach; incremental ports.

Given the drag-on-profits and lost-source-code environment that you've
described, this old Alpha configuration will likely continue to rattle
along near the bottom of the corporate priority and funding list,
possibly getting transferred to Alpha emulation, at least until the
project is spun off, sold off, or killed. Or — unlikely, but still
theoretically possible — ported or rewritten.

Then there are the discussions of how second-guessing management
priorities and funding usually work out for the employees involved, and
the usual discussions around the life and business cycles of products
and applications and sometimes careers, too.


--
Pure Personal Opinion | HoffmanLabs LLC

[Jan-Erik Soderholm]

> debug flags on...

There is/was also DEC Trace (or whatever Oracle calls it today) that
can "trace" operations against an Rdb database. I think it saves the
BLR (Binary Language Representation) format and there are separate
BLR to SQL translators around.

But DEC Trace was/is not a free tool.

> but this is only part of the equation to working out the
> application functionality internally.

Hm, look it up in the docs, maybe? :-)

Jan-Erik.

[terry+go...@tmk.com]

On Wednesday, July 29, 2015 at 8:13:16 PM UTC-4, IanD wrote:
> The business has no plans of moving to Itanium. I doubt they can wait for x86 either going by the recent chatter unless there was a financial incentive to do so
>
> Once this VMS platform closes, VMS will have exited this organisation and I seriously doubt it will get a look in again

I looked at migrating to Itanium (as a business, not a hobbyist) some years ago, and brought in some RX2620s to test with. Now, that may not have been the "best" 2RU Itanium to use for an evaluation, but they were (relatively) inexpensive.

I found them to be boat anchors, space heaters, and generally unpleasant to deal with at the hardware / EFI console level.

A single RX2620 consumed 1/3 of the power used by a cabinet full of Cisco routers / switches, several x86 servers of various vintages, and a small amount of other stuff. It was also impossible to rack / unrack normally due to it being longer than the cabinet-to-cabinet aisle spacing in the facility (mostly due to the Itanium needing a deeper cabinet than anything else in that cabinet). By comparison, a Dell PowerEdge R710 (similar vintage) with 12x the memory, 6x the disk space (at 15K RPM no less) with controller-based RAID / battery backup / cache, and 8 more physical cores consumes about 220W during operation, with peaks to 240W max.

We had repeated problems with the iLO (iLO2?) becoming unreachable and then coming back, and they were swapped out several times until we found out "they just do that". A firmware fix for that may be available if it is installed in an x86 box to do the update. There is (was?) no fix available for the big SSL vulnerability of some time ago (as opposed to the more recent ones) on Itanium, though (again) if I moved the card to an x86 system, a fix was downloadable. Even with a support contract from HP, all we ever got (after multiple tries) was "Huh?".

The EFI console and the combination of different command structures for different pieces of the system (iLO vs. MP vs. ...) seem like someone went out of their way to do things in the most obscure way. And I'm used to UEFI on x86.

This may all have been fixed in new Itanium systems (somehow, knowing HP, I doubt it), but why would someone purchase that hardware, migration of licenses, etc. for an architecture that is essentially dead, as a stopgap on the way to x86? Or, for that matter, to move to one dead-end architecture (Itanium) from another (Alpha) if the goal is to move away to "something else" once support costs get out-of-hand.

And we've heard that most of "the heavy lifting" to make porting of user-side code (applications, compilers / tools, etc.) easier was done going from VAX to Alpha and that Alpha / Itanium share the same source code pool, while VAX was left doing its own thing. If moving from Alpha -> x86 is the same amount of work as Alpha -> Itanium -> x86, why briefly pass through Itanium along the way? A customer would probably be better served by obtaining the latest compilers / tools and making sure they have the source to all of their applications and that they can be compiled with the latest compilers / tools and that the resulting executables work properly. For extra credit, they can check to make sure the needed compilers / tools exist on Itanium (even though they won't migrate to it). It is probably a reasonable generalization to assume that something that didn't make it to Itanium probably won't be available on x86. I'm not sure what percentage of those things that exist for Itanium will make it to x86, but I'd expect it to be pretty large. The point being that if the application depends on Product X and X isn't available on Itanium, it might make more sense to either re-engineer the application to no longer depend on X, or to migrate the application to some other platform. The former can be done on Alpha as part of the "make sure source is available and can be built" - no need to go to Itanium and no need to wait for VMS on x86 to ship.

As far as "no new releases for legacy architectures", as long as there is cluster interoperability at the continuing (as opposed to migration) level, that seems to be fine.

However, it is certainly possible that some issues may come up during development of the x86 port that would be easier to fix on "the other end". That could be either a remedial kit (which it seems would need to be provided by HP, no matter who develops it) or a new software release.

And what about some of the hypothetical whiz-bang new features that might appear on VMS x86? For example, a new filesystem that takes advantage of larger-capacity disks, SSDs, etc. VAX got at least partial ODS-5 support. With a "no new versions" policy, it seems unlikely that Alpha would have any knowledge of the hypothetical new filesystem. So customers would need to use lowest-common-denominator settings in order to have interoperability. How many customers would then convert to the new filesystem once the old Alpha / VAX systems have left the cluster, with the necessary re-qualification of applications, etc.? What about the case of a lone Alpha remaining in the cluster "forever" in order to handle some low-usage legacy application? Will that mean that some new features can't be used on the x86 nodes?

[David Froble]

IanD wrote:

> Rather than do a point by point response...
>
> Basically the organisation likes VMS from a stability point of view

If that is the case, then if they want to make a good decision, they
will look for a way to stay on VMS. If they are not going to attempt to
make good decisions, ....

> The application has not been touched in over 10 years and there are
> issues around the source code but I am not at liberty to say what
> exactly or to make further references to the customer base in case
> someone data matches certain things and identifies more information
> than I want to reveal :-)

Without details, suggestions are not very likely ....

But in general, if application sources are not available, then someone
has made a bad decision. At a minimum, if an application is purchased,
some sort of escrow should have been set up. I guess it's way too late
to talk the barn door if the horses are miles away.

> Then you have the diminishing skills of the folk who are meant to
> look after the application but being VMS adverse, this too is a
> loosing downward spiral

This I do not buy. For example, my son works at a nuclear power
station. They trained him for what he must know, they pay him a decent
salary, and they have a reactor operator. Application design and
programming is no different, other than a person needs to have an
apptitude for the work. If you want VMS capable people, hire them,
train them, pay them, and you have what you need.

> If the code could be lifted and put on an Itanium without the need to
> recompile, the business would have opted for that long ago - hence
> why I asked somewhere else about what exactly does a dynamic static
> translator perform - can it solve this issue for us going ahead?

This sounds like if the application is still required, then it's going
to get re-written, regardless of the platform. If they like VMS, then
why not re-write for VMS? Probably less effort than any other option.

> The customer base was once the ants pants as far as the particular
> industry was concerned but times have changed, they represent a drag
> on profits now and what they were initially required to do in terms
> of rapid expansion is no longer required, so they are not a focus
> anymore hence why the application has languished for so many years
>
> So if I have been terse with my answers, it is with reason in that I
> do not want the industry identified nor do I wish to disclose too
> much for concern that the organisation may possibly suffer customer
> concern if data matching can link the various parts together etc

Well, you've been successful, none of the above means a thing to me.

> The alpha is doing the job fine, the problem is the hardware is old,
> going out of support and the application is no longer supported and
> the source code is, err, well, in a 'special' category of it's own

Sounds like a good fit for an Alpha emulator.

> Yes, I have spoken with people on the business side to let them know
> there at least is now a pathway forward as far as VMS is concerned
> but the above problems are driving their decision to get off VMS

And getting off VMS is going to solve their problem(s) in what way?
This is what I don't understand. At least with say an Alpha emulator,
you can continue to run the apps. If there is going to be a re-write,
why is VMS so much worse than any other option? I say it would be the
best option.

> Let's just say that a certain organisation, who makes it profit on
> body count based in a certain country where IT wages are cheap and
> quality is sometimes lacking, want a linux system because that way
> they can rid themselves of the expensive VMS skilled folk and look
> after whatever new system comes in with the same resource base they
> currently have, i.e. linux folk. They do not care if this new system
> match is not the best for their customer nor if the new system will
> perform any better or be less stable.

Well in that case, tell me what the business is, so I can avoid it.

[IanD]

On Friday, August 7, 2015 at 9:43:49 AM UTC+10, David Froble wrote:
> IanD wrote:
>
> > Rather than do a point by point response...
> >
> > Basically the organisation likes VMS from a stability point of view
>
> If that is the case, then if they want to make a good decision, they
> will look for a way to stay on VMS. If they are not going to attempt to
> make good decisions, ....
>

ok, this time I will comment in-line

what I am dealing with here is an outsourcing organisation of which I am employed by. Hence I am treading carefully not to bite the hand that feeds me!

> > The application has not been touched in over 10 years and there are
> > issues around the source code but I am not at liberty to say what
> > exactly or to make further references to the customer base in case
> > someone data matches certain things and identifies more information
> > than I want to reveal :-)
>
> Without details, suggestions are not very likely ....
>

and as stated, details i cannot give for reason of confidentiality and the potential that our client could be data matched

> But in general, if application sources are not available, then someone
> has made a bad decision. At a minimum, if an application is purchased,
> some sort of escrow should have been set up. I guess it's way too late
> to talk the barn door if the horses are miles away.
>

they did. It is an application that was supported from a different country but behind the scenes actually written by another very large IT company. The very large IT company has issues with the source code, that's all I can say

The situation possibly came about because at one point in time this application was run around the globe as a standard offering. wind the clock forward and each geographical region went their own way but stayed under the name banner only. The application in this region basically became grandfathered and whatever level of support that existed through other countries has folded and gone over time - yes, lousy decisions made all along - no different really in some ways to relying on a third party application I think

> > Then you have the diminishing skills of the folk who are meant to
> > look after the application but being VMS adverse, this too is a
> > loosing downward spiral
>
> This I do not buy. For example, my son works at a nuclear power
> station. They trained him for what he must know, they pay him a decent
> salary, and they have a reactor operator. Application design and
> programming is no different, other than a person needs to have an
> apptitude for the work. If you want VMS capable people, hire them,
> train them, pay them, and you have what you need.
>

that's ok if you don't buy it, I'm not selling anything :-)

you have made an assumption that all companies are like what your son works for, prepared to invest in training and knowledge appreciation of the workforce. No such luck with this place. they have an agenda to run with minimum costs. Quality doesn't factor into it. The system/application can continually be blammed (and is blamed) for failing. the real issue of lack of skill remains hidden from the eyes of the client, so as to push the client to pay for the system/application to be replaced - it's really that simple. I personally think it's fraudulent behaviour which is why I will have no part in it other than to have to suffer the consequences

If only all workplaces did the right thing or were prepared to pay for quality when it was required...

> > If the code could be lifted and put on an Itanium without the need to
> > recompile, the business would have opted for that long ago - hence
> > why I asked somewhere else about what exactly does a dynamic static
> > translator perform - can it solve this issue for us going ahead?
>
> This sounds like if the application is still required, then it's going
> to get re-written, regardless of the platform. If they like VMS, then
> why not re-write for VMS? Probably less effort than any other option.
>

the application was deemed to not be needed for the past 8 years and should have been abolished by now but I suspect the client doesn't want the customer base to get up and walk to the opposition. The client run a certain type of business that attracts customers. they also resell their services to other entities who have a different shop front. the client would dearly love these shop fronts operating under a different name to slowly fade away and the clients to come to them directly - however, it's a fine line they tread - push too hard and all those customers out there could walk to the opposition instead...

> > The customer base was once the ants pants as far as the particular
> > industry was concerned but times have changed, they represent a drag
> > on profits now and what they were initially required to do in terms
> > of rapid expansion is no longer required, so they are not a focus
> > anymore hence why the application has languished for so many years
> >
> > So if I have been terse with my answers, it is with reason in that I
> > do not want the industry identified nor do I wish to disclose too
> > much for concern that the organisation may possibly suffer customer
> > concern if data matching can link the various parts together etc
>
> Well, you've been successful, none of the above means a thing to me.
>
> > The alpha is doing the job fine, the problem is the hardware is old,
> > going out of support and the application is no longer supported and
> > the source code is, err, well, in a 'special' category of it's own
>
> Sounds like a good fit for an Alpha emulator.
>

Yes, one member of the cluster is on Charon, the other, an ES class machine cannot be put on Charon, it simply cannot be emulated as yet because no Intel box exists that is fast enough to keep up at this stage - hence we are stuck on the existing alpha hardware for now

> > Yes, I have spoken with people on the business side to let them know
> > there at least is now a pathway forward as far as VMS is concerned
> > but the above problems are driving their decision to get off VMS
>
> And getting off VMS is going to solve their problem(s) in what way?
> This is what I don't understand. At least with say an Alpha emulator,
> you can continue to run the apps. If there is going to be a re-write,
> why is VMS so much worse than any other option? I say it would be the
> best option.
>

It won't but it will ramp up the profits of the outsourcer if they can look after any new system on Linux as they can do so with the same resource base

> > Let's just say that a certain organisation, who makes it profit on
> > body count based in a certain country where IT wages are cheap and
> > quality is sometimes lacking, want a linux system because that way
> > they can rid themselves of the expensive VMS skilled folk and look
> > after whatever new system comes in with the same resource base they
> > currently have, i.e. linux folk. They do not care if this new system
> > match is not the best for their customer nor if the new system will
> > perform any better or be less stable.
>
> Well in that case, tell me what the business is, so I can avoid it.
>

Wish I could but then I'd be out of a job. It's not by choice that i am here. The VMS market where I am is very small, one takes what they can get

> > It has now got to the stage where the application folk are looking
> > like shall we say, fools in lots of regards as their lack of VMS
> > understanding see's things breaking and falling over with the blame
> > being put back on 'an old system and an old application'. Thus I am
> > fighting fires on different fronts, so to speak, including fire
> > coming from my own camp!
> >
> > I was thinking of looking at ways to extract the rdb queries by
> > putting debug flags on but this is only part of the equation to
> > working out the application functionality internally. The application
> > itself was developed with corba and my skills in that area are next
> > to none
> >
> > Can anyone help provide guidance on how / who, to contact so that one
> > can 'function rip' an application that was developed with corba / c++
> > I believe many years ago and work out a way to develop a new solution
> > on VMS when the source code is, shall we say, somewhat hard to
> > acquire?
> >
> > Solve this issue and VMS will remain in the workplace, otherwise it's
> > pending doom is already here :-(

and there-in tells the story of why VMS is dying a slow death here :-(

[Craig A. Berry]

On 8/6/15 6:37 PM, terry+go...@tmk.com wrote:

A bunch of irrelevant whining about long-discontinued Integrity systems
snipped.

> but why would someone purchase that hardware, migration
> of licenses, etc. for an architecture that is essentially dead, as a
> stopgap on the way to x86?

Maybe because they want something that is massively more powerful and
reliable and maintainable than the ancient Alpha hardware they are on
now? If they are paying for hardware support on Alpha, an Integrity
replacement purchased today will probably pay for itself in lower
support costs before VMS is available on x86. Especially if power
consumption is taken into account.

[terry+go...@tmk.com]

On Thursday, August 6, 2015 at 10:27:42 PM UTC-4, Craig A. Berry wrote:
> A bunch of irrelevant whining about long-discontinued Integrity systems
> snipped.

Thank you for your carefully, well-thought-out rebuttal to my post 8-}

Given that HP was unable to provide support for a system that was on a support contract with them, I'm not sure anything newer (or older) would fare better.

And since HP won't provide a loaner (or even remote access) to prove the situation has changed (even if it would mean the sale of a half dozen of those systems if successful), my newest experience is with the RX2620.

Having said that (I deleted a much longer reply) I'll now depart. Enjoy your self-reinforcing echo chamber.

[Simon Clubley]

On 2015-08-06, David Froble <da...@tsoft-inc.com> wrote:

> IanD wrote:
>
>> Then you have the diminishing skills of the folk who are meant to
>> look after the application but being VMS adverse, this too is a
>> loosing downward spiral
>
> This I do not buy. For example, my son works at a nuclear power
> station. They trained him for what he must know, they pay him a decent
> salary, and they have a reactor operator. Application design and
> programming is no different, other than a person needs to have an
> apptitude for the work. If you want VMS capable people, hire them,
> train them, pay them, and you have what you need.
>

That's how things used to work. It's not how things work in the
general case now.

My CV shows a continuing history of adapting to and learning new things
which simply didn't exist at one time; by any reasonable definition
I have demonstrated my ongoing ability to adapt to new situations.

However, around here, unless you match a set of the specific frameworks
of the month/year (with experience) you don't even get considered for
many jobs regardless of the demonstrated aptitude you may have.

The sad thing is that learning a specific framework isn't even the biggest
task in many cases; it's learning the application specific codebase at
your new employer that's likely the major timesink for any new employees.

So yes, I can _easily_ believe IanD when he says he has issues in
this area.

Simon.

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

[David Froble]

Simon Clubley wrote:
> On 2015-08-06, David Froble <da...@tsoft-inc.com> wrote:
>> IanD wrote:
>>
>>> Then you have the diminishing skills of the folk who are meant to
>>> look after the application but being VMS adverse, this too is a
>>> loosing downward spiral
>> This I do not buy. For example, my son works at a nuclear power
>> station. They trained him for what he must know, they pay him a decent
>> salary, and they have a reactor operator. Application design and
>> programming is no different, other than a person needs to have an
>> apptitude for the work. If you want VMS capable people, hire them,
>> train them, pay them, and you have what you need.
>>
>
> That's how things used to work. It's not how things work in the
> general case now.

I'd question whether today's "general case" actually works.

In the medical field there can be "quacks". I don't know what the name
for them is in DP, but I've seen many.

> My CV shows a continuing history of adapting to and learning new things
> which simply didn't exist at one time; by any reasonable definition
> I have demonstrated my ongoing ability to adapt to new situations.

This is normal. Things advance. New things appear. A competent
software person must advance or be left behind. However, some of what
might be called "advances" in DP today are in my opinion most definitely
not "advances".

> However, around here, unless you match a set of the specific frameworks
> of the month/year (with experience) you don't even get considered for
> many jobs regardless of the demonstrated aptitude you may have.

The last "job" I had was in 1982. Since then I've run my own company.
Yes, the company works for customers. It's close to the same thing, but
different in many ways.

I've felt for some time now that it is not the people who are the
problem, it's the management that is a problem. The peter principal is
alive and well in management. That's the environment. I don't really
have an idea how to improve things. But when necessary, I won't
participate.

> The sad thing is that learning a specific framework isn't even the biggest
> task in many cases; it's learning the application specific codebase at
> your new employer that's likely the major timesink for any new employees.

Agree 100%. I've always maintained that before I can design software to
run a company, I first must be capable of running the company without
the computer(s).

> So yes, I can _easily_ believe IanD when he says he has issues in
> this area.

Yes, see above about "management" ....

Excellent example ....

One of my customers in the past was the marketing part of a
manufacturer. I had provided extensive software for order processing,
inventory management, accounting, forecasting, and such. Things were
working quite well. (Pats self on back.)

In time, someone from one of the "big 4-6-8 or whatever accounting
firms" ended up with the parent company. He thought the entire company
should be using the same software, and thought that the manufacturing
software in use at the parent company should be used in the marketing
company. He managed to push this concept, and what my company had
provided was deprecated, then done away with.

Ok, things happen, and I moved on.

Now, this idiot managed to spend in 7 or 8 digits in an attempt to get
the manufacturing software to work in the marketing and sales
environment. Never did get there. Whenever an employee mentioned the
prior software that worked well, he / she got "the ax". Could not tell
the idiot anything, he was in charge, and therefore he "must be ""right""".

I was told that there was 3 re-writes of the forecasting, and it never
did the job.

End of story, that company no longer exists ....

[David Froble]

terry+go...@tmk.com wrote:
> On Thursday, August 6, 2015 at 10:27:42 PM UTC-4, Craig A. Berry wrote:
>> A bunch of irrelevant whining about long-discontinued Integrity systems
>> snipped.
>
> Thank you for your carefully, well-thought-out rebuttal to my post 8-}

:-)

> Given that HP was unable to provide support for a system that was on a support contract with them, I'm not sure anything newer (or older) would fare better.
>
> And since HP won't provide a loaner (or even remote access) to prove the situation has changed (even if it would mean the sale of a half dozen of those systems if successful), my newest experience is with the RX2620.
>
> Having said that (I deleted a much longer reply) I'll now depart. Enjoy your self-reinforcing echo chamber.

I'll admit to not liking the itanic, and even more not liking dealing
with HP.

Regardless, my job is to support my customers. There is no alternative
to VMS for the customers, and with the process shrinks and massive
amounts of memory, my customers did better using itanics than sticking
with old Alphas.

We did what we needed to do to support the customers. And now there is
a future for VMS, and therefore a future on the existing applications
for the customers.

Anything else was going to be a huge financial hit for the customers,
and possibly business problems that could have put some customers out of
business.

[already...@yahoo.com]

Something similar to IA-32 Execution Layer would be an ideal solution for your case. Unfortunately, such product does not exist at two layers: VMS is not supported as a host OS and Alpha AXP is not supported as a target instruction set.
https://en.wikipedia.org/wiki/IA-32_Execution_Layer

Building something like that does not sound like a task that VSI can't contemplate, esp. if they will be able to hire few good people that were once involved with IA32EL. Whether investing in something like that is a good business proposition on not is another matter.
As you demonstrated, those with lower performance requirement are served just fine by full-machine emulation on x86 boxen (Sharon-AXP), so, may be, the market for high-performance same-OS application-level binary translation is too small for VSI to bother.

[Craig A. Berry]

On 8/6/15 10:17 PM, terry+go...@tmk.com wrote:
> On Thursday, August 6, 2015 at 10:27:42 PM UTC-4, Craig A. Berry wrote:
>> A bunch of irrelevant whining about long-discontinued Integrity systems
>> snipped.
>
> Thank you for your carefully, well-thought-out rebuttal to my post 8-}

Sorry I was dismissive, but rx2620? Seriously? It is certainly true that
Itanics sucked by every measure compared to Alpha until about five years
after Alpha development was stopped. But that was 10 years ago.

I believe it was Rob Brooks of VSI who said in this forum awhile back
that the rx2660 was a big step forward hardware-wise. I have an rx2600
at home and we have rx2660 at the office and can confirm that the rx2660
is a lot nicer. The on-board RAID controller sucks but can be upgraded.
Of course it came out in 2007 and is two generations back now, so it's
getting a bit long in the tooth.

> Given that HP was unable to provide support for a system that was on
> a support contract with them, I'm not sure anything newer (or older)
> would fare better.

That's a serious problem and I have certainly seen HP techs floundering
while trying to do the simplest things with Integrity servers. Whether
it would be any better with ProLiant I don't know, but I suspect it
would be worse with Alpha and getting more so as HP winds down Alpha
support. At least with recent-generation equipment they can eventually
get someone on the phone somewhere within HP who knows how it works
(such as that installing a storage controller that requires a PCIe
expansion card only actually works if you install the PCIe expansion card).

> And since HP won't provide a loaner (or even remote access) to prove
> the situation has changed (even if it would mean the sale of a half
> dozen of those systems if successful), my newest experience is with
> the RX2620.

Dealing directly with HP for purchasing of anything less than racks and
racks full of systems is not likely to lead to anywhere good. Ask a
reseller to sell you one with a 60-day return policy or rent one for a
couple months. IslandCo has rx2660s starting at 999 USD and rx2800 i2s
at 6,795. I believe these are refurbs but certainly adequate to test the
waters. If you want half a dozen systems, you should look into blades.

[Stephen Hoffman]

On 2015-08-07 14:23:35 +0000, already...@yahoo.com said:

> Something similar to IA-32 Execution Layer would be an ideal solution
> for your case.

Until somebody sorts out the revenues and particularly the profits,
discussions of developing new technologies — particularly given
DECmigrate has been around for many years — or plans to port to a
platform that does not yet exist... seems moot.

Building a justification is no small effort, and this particular effort
will be difficult for those seeking to keep OpenVMS around given
there's what is perceived by management as a more competitive
application already available internally.

Yes, VSI has already stated they'll be providing translation akin to
DECmigrate. But translation seems quite unlikely to sway management
perceptions here, in isolation.

[already...@yahoo.com]

On Saturday, August 8, 2015 at 6:11:55 PM UTC+3, Stephen Hoffman wrote:
> On 2015-08-07 14:23:35 +0000, already...@yahoo.com said:
>
> > Something similar to IA-32 Execution Layer would be an ideal solution
> > for your case.
>
> Until somebody sorts out the revenues and particularly the profits,

> discussions of developing new technologies -- particularly given
> DECmigrate has been around for many years -- or plans to port to a

> platform that does not yet exist... seems moot.
>

I meant Itanium host, not x86. So, platform exists.

[Stephen Hoffman]

On 2015-08-08 18:47:08 +0000, already...@yahoo.com said:

> On Saturday, August 8, 2015 at 6:11:55 PM UTC+3, Stephen Hoffman wrote:
>> On 2015-08-07 14:23:35 +0000, already...@yahoo.com said:
>>
>>> Something similar to IA-32 Execution Layer would be an ideal solution
>>> for your case.
>>
>> Until somebody sorts out the revenues and particularly the profits,
>> discussions of developing new technologies -- particularly given
>> DECmigrate has been around for many years -- or plans to port to a
>> platform that does not yet exist... seems moot.
>
> I meant Itanium host, not x86. So, platform exists.

Here's a more detailed description of the IA-32 Execution Layer that
already5chosen is referring to:
<http://www.microarch.org/micro36/html/pdf/goldenberg-IA32ExecutionLayer.pdf>

Which in aggregate, looks rather like what the "DECmigrate" application
migration tools can already provide:
<http://h71000.www7.hp.com/openvms/products/omsva/omsais.html>

Quick DECmigrate overview:
<http://labs.hoffmanlabs.com/node/641>

[already...@yahoo.com]

On Saturday, August 8, 2015 at 10:34:59 PM UTC+3, Stephen Hoffman wrote:
> On 2015-08-08 18:47:08 +0000, already...@yahoo.com said:
>
> > On Saturday, August 8, 2015 at 6:11:55 PM UTC+3, Stephen Hoffman wrote:
> >> On 2015-08-07 14:23:35 +0000, already...@yahoo.com said:
> >>
> >>> Something similar to IA-32 Execution Layer would be an ideal solution
> >>> for your case.
> >>
> >> Until somebody sorts out the revenues and particularly the profits,
> >> discussions of developing new technologies -- particularly given
> >> DECmigrate has been around for many years -- or plans to port to a
> >> platform that does not yet exist... seems moot.
> >
> > I meant Itanium host, not x86. So, platform exists.
>
> Here's a more detailed description of the IA-32 Execution Layer that
> already5chosen is referring to:
> <http://www.microarch.org/micro36/html/pdf/goldenberg-IA32ExecutionLayer.pdf>
>
> Which in aggregate, looks rather like what the "DECmigrate" application
> migration tools can already provide:
> <http://h71000.www7.hp.com/openvms/products/omsva/omsais.html>
>

Yes, more or less. Except that AEST appears to be a static translator, so performance and coverage are unlikely to be as good as dynamic triple-phase binary translation of IA32EL. In particular, I don't understand how AEST will handle applications that generate executable code on the fly.

> Quick DECmigrate overview:
> <http://labs.hoffmanlabs.com/node/641>
>
>

Sounds like you are not particularly fond of AEST. Is it because of bad 1st-hand experience, or just out of principles?

Anyway, the situation, described by IanD, asks for "last resort" solutions.
If I was him? I'd definitely try AEST.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Keith Parris
> Sent: 28-Jul-15 11:40 AM
> To: info...@info-vax.com
> Subject: Re: [New Info-vax] 1 year.
>
> On 7/28/2015 4:36 AM, clairg...@gmail.com wrote:
> > If people want to turn VSI into a support organization this
> > is the way to do it. If VSI is to move VMS forward to future
> > platforms with updated software we need to focus
>
> Profit margins on services like support are significantly greater than
> those on software license sales, and an organization that integrates the
> two and values both will have more money to devote to R&D and thus a
> greater chance of long-term financial success.

Keith,

I would suggest some slight modifications of your statement:

Yes, support is a significant part of today's and future revenue streams.

However, this support revenue stream degrades significantly if you are
supporting non-std, no longer vendor supported products like VAX,
Alpha.

Profitable support / consulting revenues are based on standardized
product offerings (as much as possible) and/or system integration
where the skill level requirement is high and can justify higher hourly
consulting rates.

The HW support vendor like HP TS field services can (and do) justify
charging the Cust much more per month for out of date HW. I
remember one Cust paying $1000's per year on support of each of their
many old RZ drives, but its difficult to do that for the OS SW support
running on the same out of date HW.

A better support model is what Red Hat has adopted:
- over time, drop as many non-X86 platforms as possible (non-X86=
non-std = high costs)
- drop/reduce one time license costs that show up as capital costs.
these have high Cust visibility and require senior Cust exec approvals
- adopt monthly support cost license model which is a OPEX expense
that only needs low level Operations Mgr approval as part of his/her
support budget.
- provides the perception (marketing) that Linux is cheap (few people
talk about the monthly support costs that enterprises pay)

Monthly OS support cost could be based on tier, SLA level, number of
Instances and/or other criteria. The yearly support costs could also be
Invoiced as a single invoice in advance, but again, that simply shows up
on the Cust side as part of their OPEX support costs.

Regards,

Kerry Main
Back to the Future IT Inc.
.. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com

[johnwa...@yahoo.co.uk]

If you want an example of what DEC historically had done with on-the-fly
binary translation go read more about FX!32, which was a rather handy
tool for running Win32/x86 applications on an NT/Alpha box, by a mixture
of static and dynamic translation. It's actually mentioned in the IA32EL
paper, though not in much detail. Wikipedia has an FX!32 article, and
more importantly, has references.

[Stephen Hoffman]

On 2015-08-08 19:54:35 +0000, already...@yahoo.com said:

> Yes, more or less. Except that AEST appears to be a static translator,

Incremental translation and instruction emulation are necessarily
performed. Details are in the previously-linked documentation.

Using application translation for the environment that IanD has
described is likely more expensive, with no improvements in their
current results and quite possibly with a reductions in stability or
availability or maintainability. It's unclear why emulation would be
acceptable to responsible managers here, either. Particularly given it
hasn't already been deemed acceptable some time over the past decade or
so.

This particular translation case also involves moving to a platform
where Kittson as the last Itanium processor being discussed for OpenVMS
itself, and where VSI has already picked the follow-on architecture
with OpenVMS porting to x86-64.

Management wants to migrate and has a replacement environment and wants
this particular environment gone, so — in the absence of a viable
financial justification to the contrary, and quite possibly even with
such a justification — that's the target here. Build a financial case
to stay with OpenVMS. Or get going on the migration.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman
> Sent: 08-Aug-15 6:39 PM
> To: info...@info-vax.com
> Subject: Re: [New Info-vax] 1 year.
>

Would building an Alpha HW emulator on OpenVMS/X86-64 not be a
more preferred option? Future VAX HW emulators???

From a Customer perspective, standardize on one X86-64 platform and
move older environments to new platform with zero (or low) impact?

Latest OpenVMS running on V9.x/X86-64 and older env's running on
same server running OpenVMS Alpha .. similar to VMware.

Course, the mix would depend on performance requirements.

Big benefit would be to get all those Alpha/VAX systems on new HW
(HP ProLiants?) and under monthly service support contracts to VSI.

Would certainly help monthly revenue stream.

There is also quite a bit of experience with building HW emulators via
other vendors, so perhaps, one could be contracted separately to do
this?

Kerry

[Hans Vlems]

Side question : does simh provide alpha simulation? If not, what may be the reason?
Hans

[already...@yahoo.com]

> > this particular environment gone, so -- in the absence of a viable

> > financial justification to the contrary, and quite possibly even with

> > such a justification -- that's the target here. Build a financial case

> > to stay with OpenVMS. Or get going on the migration.
> >
>
> Would building an Alpha HW emulator on OpenVMS/X86-64 not be a
> more preferred option?

I see no advantages over existing Stromasys products and numerous disadvantages.
The biggest one - OpenVMS/X86-64 does not exist.
The second biggest - when it finally exists, drivers availability will always remain far behind Windows Server. Running host VMS OS in para-virtualization mode under VMWare or under its Winduws or Linux counterparts can partially alleviate the issue, but only partially and at cost of making already slow solution even slower.

On the other hand, application-level binary translation demonstrated very good performance. IA32EL claimed, on average, 50-60% of native (i.e. the same sources recompiled for Itanium) performance for apps that spend almost no time in syscalls. Applications that spend more time in syscalls and native libraries calls will fare even better.

>
> Future VAX HW emulators???
>
> From a Customer perspective, standardize on one X86-64 platform and
> move older environments to new platform with zero (or low) impact?
>
> Latest OpenVMS running on V9.x/X86-64 and older env's running on
> same server running OpenVMS Alpha .. similar to VMware.
>
> Course, the mix would depend on performance requirements.
>
> Big benefit would be to get all those Alpha/VAX systems on new HW
> (HP ProLiants?) and under monthly service support contracts to VSI.
>
> Would certainly help monthly revenue stream.
>
> There is also quite a bit of experience with building HW emulators via
> other vendors, so perhaps, one could be contracted separately to do
> this?

Yes, Stromasys emulators work, but they are far from speed demons.

>
> Kerry

[li...@openmailbox.org]

On Sun, 9 Aug 2015 00:34:27 -0700 (PDT)
Hans Vlems via Info-vax <info...@rbnsn.com> wrote:

> Side question : does simh provide alpha simulation?

No, and they don't seem very enthusiastic about supporting Alpha in the
future.

> If not, what may be the reason?

They've done a great job of supporting 32 bit and smaller machines. They
seem to feel supporting a 64 bit guest on 32 bit hosts would be too much
of a performance hit to be worth doing.

I don't think they would stop somebody from contributing an Alpha machine
to the SIMH code repository. As far as the guys already working on SIMH
nobody seemed interested in taking this on.

I prefer SIMH over other emulators when possible because it is more
portable than the others I know about that are either Linux or
Windows-centric. SIMH actually builds and runs on many POSIX OS and works
perfectly fine on a non-x86 host, too.

--
Please DO NOT COPY ME on mailing list replies. I read the mailing list.
RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8 ACAA 557C 4B36 98E4 4D49

[Kerry Main]

Stromasys exists today, but they are not cheap - typically 4+ digits.

> On the other hand, application-level binary translation demonstrated
> very good performance. IA32EL claimed, on average, 50-60% of native
> (i.e. the same sources recompiled for Itanium) performance for apps
> that spend almost no time in syscalls. Applications that spend more time
> in syscalls and native libraries calls will fare even better.
>

I am all for this if it can be done in a timely, and cost effective timeframe,
but from what I understand, application level binary translation is
also many numerous of magnitude more complex to build/support.

I also recall binary translation was/is primarily targeted on user mode
applications, so it would reduce the number of potential use cases.

> >
> > Future VAX HW emulators???
> >
> > From a Customer perspective, standardize on one X86-64 platform and
> > move older environments to new platform with zero (or low) impact?
> >
> > Latest OpenVMS running on V9.x/X86-64 and older env's running on
> > same server running OpenVMS Alpha .. similar to VMware.
> >
> > Course, the mix would depend on performance requirements.
> >
> > Big benefit would be to get all those Alpha/VAX systems on new HW
> > (HP ProLiants?) and under monthly service support contracts to VSI.
> >
> > Would certainly help monthly revenue stream.
> >
> > There is also quite a bit of experience with building HW emulators via
> > other vendors, so perhaps, one could be contracted separately to do
> > this?
>
> Yes, Stromasys emulators work, but they are far from speed demons.
>

True, but from what I have seen, most existing VAX/Alpha environments
are running less than 30% in peak times anyway. As long as the perf was
"as good", then it would be "good enough".

Yes, there are big Alpha and likely some bigger VAX env's but these are
the exception - not the norm.

The draw for Custs moving to Alpha/VAX HW emulators on OpenVMS/
X86-64 would be a move to current HW with minimal/no changes to their
App environment e.g. OpenVMS V8.4. Same draw as what VMware has
when they support older versions of Windows/Linux on their most
current versions of VMware.

The draw for VSI would be to get additional monthly support revenue.

Yes, some VAX/Alpha systems have HW and/or timing dependencies
that may make them ineligible for this use case.

Kerry

[Stephen Hoffman]

Short of adding paravirtualization or some other features, there's no
obvious advantage over the existing emulators. Unless you're
consolidating onto OpenVMS, and — at present — that's not common. In
IanD's case, they're not consolidating onto OpenVMS. Probably three
years before this is even an option, too.

> From a Customer perspective, standardize on one X86-64 platform and
> move older environments to new platform with zero (or low) impact?

Customers already have this option, and with standardization. Often
with the emulation running on a platform that they're using elsewhere.
Whether that's RHEL or otherwise.

> Latest OpenVMS running on V9.x/X86-64 and older env's running on same
> server running OpenVMS Alpha .. similar to VMware.

Ayup, but it's also probably three to five years out. This
configuration involves getting OpenVMS ported and stable, then getting
the emulators working — whether with paravirtualization support or not
— and stable, and then getting the hardware and emulation installed and
configured and the applications re-hosted over onto the emulation.

Obviously VMware is a virtual machine and does not include an emulator,
which means a locally-installed copy of RHEL or otherwise, or one of
those "bare metal" emulators that are pre-packaged with a Linux distro,
and now you're dealing with something little different than what's
available now — that OpenVMS x86-64 can coexist as another guest is
largely irrelevant here. Unless you're running the emulation on
OpenVMS x86-64, with paravirtualization or otherwise, and that's
entirely slideware at best.

> Course, the mix would depend on performance requirements.

Also on what sorts of speed-ups are possible with the next generation
or three of hardware and of software, too.

> Big benefit would be to get all those Alpha/VAX systems on new HW (HP
> ProLiants?) and under monthly service support contracts to VSI.

Or SuperMicro, or one of the other vendors. But various of these
long-time old-release environments won't be under HP or VSI support,
though — it's common for these sites to drop off support, and nobody's
figured out a good way to extract some revenue doing per-call software
support, in the absence of an annual support contract. It's also been
problematic getting servers onto support contracts.

But it's been my experience that folks that have a migration and
consolidation plan to a different application product and that are
making statements such as IanD has posted here are not usually
interested in expending more than minimally necessary on the old
configuration. Not without a financial case, and sometimes not even
then. Emulation becomes an option when the existing hardware becomes
more costly to maintain and to run than the cost of the switch over to
emulation. This when some non-trivial part of the application source
code is missing and which means that anything short of translation or
emulation can be viewed as cost-prohibitive, and particularly when
there's already a viable target to migrate folks available here.

[Stephen Hoffman]

On 2015-08-09 07:34:27 +0000, Hans Vlems said:

> Side question : does simh provide alpha simulation?

There was work on Alpha emulation started a while back, but it's not
very active based on a quick look at the copyright dates.

Most of the comments appear to be cleanup related to other work
elsewhere in simh — one of the recent Alpha changes looked to be some
pretty printing performed in the Alpha code.

<https://github.com/simh/simh/tree/master/alpha>

> If not, what may be the reason?

Because nobody's decided to spend the time necessary to write and debug
and then give away an Alpha emulator based on simh?

Related: <http://labs.hoffmanlabs.com/node/70>

[already...@yahoo.com]

I never did either, but from common knowledge it seems the opposite is true. Emulating just a CPU sounds far easier than emulating the whole machine, with all quirks of peripheral devices. And in this particular case you don't even have to emulate the full Alpha ISA, all system-only stuff can be omitted.
The only aspect that is harder is a much higher performance bar that you are aiming at.

> I also recall binary translation was/is primarily targeted on user mode
> applications, so it would reduce the number of potential use cases.
>

Not by much. There are far fewer shops with their own kernel drivers than those that has their own applications. Among those that have kernel drivers significant part (majority?) is for hardware that is connected through buses that no longer exist in modern servers, so they are screwed regardless. Of those that are not relaying on obsolete buses, I hope that majority didn't lose a source code and with source code available porting drivers from Alpha to Itanium does not have to be difficult - after all drivers tend to be much smaller and simpler than applications and are written by more conservative developers.

> > >
> > > Future VAX HW emulators???
> > >
> > > From a Customer perspective, standardize on one X86-64 platform and
> > > move older environments to new platform with zero (or low) impact?
> > >
> > > Latest OpenVMS running on V9.x/X86-64 and older env's running on
> > > same server running OpenVMS Alpha .. similar to VMware.
> > >
> > > Course, the mix would depend on performance requirements.
> > >
> > > Big benefit would be to get all those Alpha/VAX systems on new HW
> > > (HP ProLiants?) and under monthly service support contracts to VSI.
> > >
> > > Would certainly help monthly revenue stream.
> > >
> > > There is also quite a bit of experience with building HW emulators via
> > > other vendors, so perhaps, one could be contracted separately to do
> > > this?
> >
> > Yes, Stromasys emulators work, but they are far from speed demons.
> >
>
> True, but from what I have seen, most existing VAX/Alpha environments
> are running less than 30% in peak times anyway. As long as the perf was
> "as good", then it would be "good enough".
>
> Yes, there are big Alpha and likely some bigger VAX env's but these are
> the exception - not the norm.
>

I don't believe that there are still Vaxen in production that meet two criteria below at the same time:
a) does not run real-time jobs (for real-time no sort of emulation will work) b) are so big that they present performance challenge for Charon-Vax on modern Intel hardware.

Alpha is very different story.

>
> The draw for Custs moving to Alpha/VAX HW emulators on OpenVMS/
> X86-64 would be a move to current HW with minimal/no changes to their
> App environment e.g. OpenVMS V8.4. Same draw as what VMware has
> when they support older versions of Windows/Linux on their most
> current versions of VMware.
>

I'd guess, that sort of mentality (do no changes anything, including not applying fixes to known OS bugs and vulnerabilities) is the reason behind negative reaction of Mr. Hoffman.

And you still didn't present a single reason for a move to (non-existing) HW emulator hosted on VMS vs existing, proven and working emulators hosted on Windows.

[IanD]

>
> Yes, Stromasys emulators work, but they are far from speed demons.
>
> >
> > Kerry

And this sadly, is our issue too

According to recent feedback by Charon product sellers, our ES80 cannot be emulated on Charon because the HP Intel box will simply not keep up to match the ES80's performance

On top of this, we are hitting maximum cpu on the ES80 and need to purchase another 2P drawer and extra ram but we have hit a snag.

Let's just say feedback is that a certain company who could supply this type of hardware and support it are saying they will not, unofficially of course. Read that which-ever way you want about them cutting ties with anything lower than Itanium. I thought the ES80's and GS1280's were some of the last Alphas made?

I fully understand that it was the businesses fault for letting themselves get into this predicament and had they had access to the source code I dare say we would have been running on Itanium by now, but we don't and I am betting our predicament is shared by a lot of organisations out there

How do you get back into an organisation once ousted from it?

Shame the whole OpenVMS X86-64 process wasn't started 2 years ago, VMS might have had a chance where I am

No tangible VMS path forward = no VMS future for us :-(

[IanD]

On Sunday, August 9, 2015 at 11:22:07 PM UTC+10, Stephen Hoffman wrote:
> On 2015-08-09 03:28:56 +0000, Kerry Main said:

<snip>

>
> But it's been my experience that folks that have a migration and
> consolidation plan to a different application product and that are
> making statements such as IanD has posted here are not usually
> interested in expending more than minimally necessary on the old
> configuration. Not without a financial case, and sometimes not even
> then. Emulation becomes an option when the existing hardware becomes
> more costly to maintain and to run than the cost of the switch over to
> emulation. This when some non-trivial part of the application source
> code is missing and which means that anything short of translation or
> emulation can be viewed as cost-prohibitive, and particularly when
> there's already a viable target to migrate folks available here.
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

and yet again I see your experience of real world dealings popping up in your comments :-)
I wish your timelines were a little nicer but I have a suspicion they are probably not to far from the mark

Yes, for us, the application supports a class of customers that are not the future, so minimal amounts of spending is the normal here, that is how the whole application got to be in the state it is in, it was all meant to slowly vanish and die away by now

To stay on VMS would mean an application rewrite and the so called architects who think linux is the future for everything and the solution to everything will never support a rewrite to VMS - it simply does not offer the business any advantages that wins them business or supports their business any more than does a linux solution, or so the architects tell them. They do not care about TCO, why should they, the business has outsourced all their IT to an IT company that runs it mostly offshore at bargain prices and they certainly don't want to support VMS either because they find it extremely difficult to get VMS resources as it is

Emulators are fine for most not wanting to move up the architectural path but some of us are stuck in no-man's land with aging hardware that is too fast for an emulator at this stage, and with HP dropping support all over the place for anything that even hints of an Alpha smell, migrating away is our only near term option

[Stephen Hoffman]

On 2015-08-09 13:57:37 +0000, already...@yahoo.com said:

> On Sunday, August 9, 2015 at 4:05:05 PM UTC+3, Kerry Main wrote:
>>> -----Original Message-----
>>> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
>>> already...@yahoo.com
>>> Sent: 09-Aug-15 5:28 AM
>>> To: info...@info-vax.com
>>> Subject: Re: [New Info-vax] 1 year.
>>>
>>

>> I am all for this if it can be done in a timely, and cost effective
>> timeframe, but from what I understand, application level binary
>> translation is also many numerous of magnitude more complex to
>> build/support.
>
> I never did either, but from common knowledge it seems the opposite is
> true. Emulating just a CPU sounds far easier than emulating the whole
> machine, with all quirks of peripheral devices. And in this particular
> case you don't even have to emulate the full Alpha ISA, all system-only
> stuff can be omitted.
> The only aspect that is harder is a much higher performance bar that
> you are aiming at.

For cases such as what IanD is referencing, which is least-changes for
the end-user? Translation, or emulation? Translation involves
purchasing an Itanium and the rest of the baggage that entails, and
then translating the individual hunks of the existing environment.
(I'd not expect to see anything approaching Rosetta here, either. Not
for Alpha to Itanium.) Emulation means creating a disk image of the
old environment and transferring it and the licenses over to the new
environment, and then using logical names to redirect device references
where necessary. Neither approach is risk free, of course.

>> I also recall binary translation was/is primarily targeted on user mode
>> applications, so it would reduce the number of potential use cases.
>
> Not by much. There are far fewer shops with their own kernel drivers
> than those that has their own applications.

For simple and isolated application cases, you're quite correct:
inner-mode code is rare. But with the usual sorts of "accreted"
configurations arising from a decade or two of usage, it's common to
find user-written system services and other inner-mode code around —
whether to manage privileges or otherwise — and various layered
products and third-party dependencies also have inner-mode code. I've
found $cmkrnl calls lurking in some surprising places.

But for an existing site that wants off of OpenVMS and has a parallel,
target application environment already operational, translation and
emulation are unlikely choices. Not without some very viable
justification. Translation is not likely that justification.

>> The draw for Custs moving to Alpha/VAX HW emulators on OpenVMS/X86-64
>> would be a move to current HW with minimal/no changes to their App
>> environment e.g. OpenVMS V8.4. Same draw as what VMware has when they
>> support older versions of Windows/Linux on their most current versions
>> of VMware.
>
> I'd guess, that sort of mentality (do no changes anything, including
> not applying fixes to known OS bugs and vulnerabilities) is the reason
> behind negative reaction of Mr. Hoffman.

I'd suggest experimenting with both, if you've not already done so.

Platform emulation tends to be the lowest-cost and least-bad and
least-changes approach, for cases involving substantially-lost source
code and/or unavailable or allocated-elsewhere staffing and/or
insufficient revenue stream, or are otherwise are not in a position to
port your code natively. Yes, translation does work and is viable for
some cases and particularly for cases where you have most of the source
code but not all of it. But it's also almost inherently more work on
the end-user.

Unfortunately, few operating system vendors have the time and budget
for translation tools of the scale of and the transparency of Rosetta,
for that matter.

For a case such as IanD is reporting, spending anything here that's not
strictly necessary usually requires some form of justification.
Justifying a move to Itanium will not be easy.

Short of paravirtualization — calls through from the emulated OpenVMS
environment into the native OpenVMS environment — there's no obvious
advantage of hosting OpenVMS on OpenVMS, outside of having one less
operating system involved. And in various cases such as the one IanD
is referencing — which is what my remarks here are targeting — the
folks involved would clearly rather have fewer instances of OpenVMS
around, and are using other operating system(s) as their preferred
environment.

It's the revenues and the expenses and the opinions of the senior
managers that drive these choices, and then the technology and staffing
and tools that supports those goals. Or that does not support those
goals. Removing redundancies and reducing the numbers of operating
systems and platforms is a common preference. This usually means fewer
data centers, fewer software and fewer hardware permutations, reduced
staffing and reduced staffing requirements, increased automation,
lower-priced staffing and lower-priced software, etc. Many managers
are measured on fixed costs, and on reducing fixed costs, and on
maintaining service level goals. On getting folks off of a platform or
an application that's become visible, and that's viewed as undesirable
or legacy. for whatever reason Managers are less often measured on
the details of whether some particular emulation uses IA-32 execution
layer or some other form of translation or emulation.

[Stephen Hoffman]

On 2015-08-09 14:42:59 +0000, IanD said:

> On Sunday, August 9, 2015 at 11:22:07 PM UTC+10, Stephen Hoffman wrote:
>
>> But it's been my experience that folks that have a migration and
>> consolidation plan to a different application product and that are
>> making statements such as IanD has posted here are not usually
>> interested in expending more than minimally necessary on the old
>> configuration. Not without a financial case, and sometimes not even
>> then. Emulation becomes an option when the existing hardware becomes
>> more costly to maintain and to run than the cost of the switch over to
>> emulation. This when some non-trivial part of the application source
>> code is missing and which means that anything short of translation or
>> emulation can be viewed as cost-prohibitive, and particularly when
>> there's already a viable target to migrate folks available here.
>

> and yet again I see your experience of real world dealings popping up
> in your comments :-)
> I wish your timelines were a little nicer but I have a suspicion they
> are probably not to far from the mark

Folks that skipped last platform port aren't usually the most
aggressive at porting to the follow-on platform, either.

> Yes, for us, the application supports a class of customers that are not
> the future, so minimal amounts of spending is the normal here, that is
> how the whole application got to be in the state it is in, it was all
> meant to slowly vanish and die away by now

Quite typical in legacy support. I get calls from and variously work
with folks in this situation, too. Requirements for much work beyond
bringing some necessary service online or up to more current — updated
encryption and TLS requirements are among the most popular choices —
and resolving software or hardware errors or a server-down are rare for
these sites.

> To stay on VMS would mean an application rewrite and the so called
> architects who think linux is the future for everything and the
> solution to everything will never support a rewrite to VMS - it simply
> does not offer the business any advantages that wins them business or
> supports their business any more than does a linux solution, or so the
> architects tell them.

Ayup; the systemd and BSD platforms are the likely targets for most new
server deployments, for those working outside of the Microsoft
ecosystem.

> They do not care about TCO, why should they, the business has
> outsourced all their IT to an IT company that runs it mostly offshore
> at bargain prices and they certainly don't want to support VMS either
> because they find it extremely difficult to get VMS resources as it is

If by "extremely difficult" you mean "more expensive than they'd like",
yes. There are and can be OpenVMS folks around. That particular part
of the job market is simply skewed away from what hiring managers
prefer, at present. The managers don't want to pay to train their own
folks, and the folks that are trained and experienced can command a
premium.

As for outsourcing, IT is not perceived as a differentiator by many
organizations. Or it is not a differentiator. Whether it can become
a differentiator? That takes insight and budget and time and effort.
And marketing and luck and nerve. Etc.

Discussions of TCO can be an incremental benefit and a nice-to-have for
an installed-base sale, but TCO is only one factor in the aggregate
costs and efforts involved for a new deployment or for a platform
migration. Like benchmarks, TCO also depends heavily on what was
measured, too. Programming on some other platforms with
well-integrated IDEs and deployment tools and integration is just
easier and faster than on OpenVMS, for instance. That's before
commencing my usual grumbling around the state of languages and
frameworks and services.

> Emulators are fine for most not wanting to move up the architectural
> path but some of us are stuck in no-man's land with aging hardware that
> is too fast for an emulator at this stage, and with HP dropping support
> all over the place for anything that even hints of an Alpha smell,
> migrating away is our only near term option

Or doing what some folks in this case do, and that's rolling out spares
and preparing for self-maintenance. This unfortunately doesn't really
fit — organizationally, managerially or financially — with what you're
describing for the existing application environment. Probably the
best outcome would be a spin-off or sell-off, if that's an option and
if there's a buyer. But given the reported goal to incrementally
migrate these folks to a different environment, that'd arguably just
create a competitor.

[already...@yahoo.com]

You are ignoring the data, provided by IanD. It's ES80, heavily loaded. There is no practical chance that it will meet performance requirements on Charon-AXP.
So, I'd call Charon-AXP risk free, that is, free of risk of working :(

With AEST, on the other hand, there is a significant risk that it wouldn't work at all and a less significant risk that it will work, but wouldn't meet performance requirement, but still, with determined effort, there is a good chance that everything will work and will free them of concerns for the next 5-7 years at least.

As to HW, with Poulson now officially supported, fast hardware (e.g. rx2800 i4) should be relatively affordable. Naturally, I have no idea how affordable.

>
> >> I also recall binary translation was/is primarily targeted on user mode
> >> applications, so it would reduce the number of potential use cases.
> >
> > Not by much. There are far fewer shops with their own kernel drivers
> > than those that has their own applications.
>
> For simple and isolated application cases, you're quite correct:
> inner-mode code is rare. But with the usual sorts of "accreted"
> configurations arising from a decade or two of usage, it's common to

> find user-written system services and other inner-mode code around --
> whether to manage privileges or otherwise -- and various layered

> Short of paravirtualization -- calls through from the emulated OpenVMS
> environment into the native OpenVMS environment -- there's no obvious

> advantage of hosting OpenVMS on OpenVMS, outside of having one less
> operating system involved. And in various cases such as the one IanD

> is referencing -- which is what my remarks here are targeting -- the

[Stephen Hoffman]

Please re-read the thread. I do not expect these folks to change their
hardware, though they might go to emulation if/when that's appropriate
for them.

As for comparing emulation, I do not expect emulation to have the same
performance going forward. Whether that's due to improved hardware
performance or better emulation, improvements are likely. It may also
be due to reductions in the current server load, given the goal of
migrating folks off of OpenVMS and onto the preferred platform and
application.

As I've commented, translation is likely a non-starter for management
here. That for reasons of finances and risk aversion, and for
generally wanting to migrate off of OpenVMS. There are a number of
senior managers around that can't justify adding or that don't want
OpenVMS around, and for very good reasons. To convince senior
management otherwise and to convince them into performing a port is no
small effort, and it takes more than a little preparation. (This is
part of why sales reps really earn their pay, too.)

Barring access to something analogous to the transparency of Rosetta
for Alpha to Itanium migrations — and there's precious little incentive
here for VSI to invest substantially in getting folks from Alpha over
to Itanium, particularly when the VSI could be investing in creating
the technology necessary to get folks over onto x86-64, and on the
OpenVMS x86-64 port itself. For now, the existing migration tools —
"DECmigrate" — are it. As for existing OpenVMS Alpha end-user sites
that might be interested in porting to newer OpenVMS and newer hardware
and aren't approaching performance or other constraints, why move to
Itanium now, if they can keep the existing boxes going until x86-64 is
available?

In short, this particular customer is very likely either gone and/or
the application headed for deprecation, or they're not moving to
Itanium.

What might eventually draw similar sites into these sorts of upgrades
are competitive prices, x86-64 hardware and VM support, features and
updates, and more experience with VSI over time. That, and — for the
sites that are missing some of the source code — the translator (to
x86-64) that VSI has discussed.

> With AEST, on the other hand, there is a significant risk that it
> wouldn't work at all and a less significant risk that it will work, but
> wouldn't meet performance requirement, but still, with determined
> effort, there is a good chance that everything will work and will free
> them of concerns for the next 5-7 years at least.

Buying some spare parts and doing some incremental upgrades —
particularly updating the rotating-rust storage — can likely keep an
AlphaServer ES80 configuration going for five to seven years, too.
I've dealt with much older Alpha systems that are (or recently were)
still in service.

But it wouldn't surprise me to learn the customer has plans to be off
of OpenVMS in five to seven years. (Now whether they can get there?)

> As to HW, with Poulson now officially supported, fast hardware (e.g.
> rx2800 i4) should be relatively affordable.

For an ES80-class box? An i4 box or an i2 box will likely work. If
time permitted, I'd be tempted to prototype a top-end rx2660 — a
quad-core 1.66 GHz configuration with 32 GB and fast I/O — to see if
that might manage reasonably competitive performance with an
AlphaServer ES80. This performance in aggregate and given the faster
interconnects involved here, and not based solely on raw processor
performance.


But none of this addresses the root issues here, unfortunately.

> Naturally, I have no idea how affordable.

Always ask about and always calculate the affordability of the
available solutions. This having gone through these cases more than a
few times. Once the cost of the port and of the translation have been
calculated, and the willingness of the end-customer take on the risk
has been investigated, then — for cases such as this one — compare that
with the costs of spare parts and running the current hardware into the
ground, and getting folks to move to the long-term preferred platform.
Then there's the cost of overcoming management's perception that
OpenVMS is not an appropriate long-term solution for them here. Which
won't come cheaply, nor quickly.

Now what happens with service and support costs and power and cooling
and the rest? Unclear. It might drive a decision to Itanium, or it
might drive the decision to finish moving off of the existing
environment. But without the costs and without knowledge of the
managers' requirements and goals and concerns — if they think that
OpenVMS is expensive and problematic, then you're starting out in an
extremely deep hole to sell them another OpenVMS box — any discussions
of an Itanium translation tool or of a port will get about as far as
discussions involving an Illudium Q-36 Explosive Space Modulator.

VSI is (hopefully) focused on the immediate and short-term work on
Itanium for Kittson and for a new features release or two, and with the
layered products, and particularly with establishing a revenue stream,
and then concentrating on the x86-64 port. That work targets existing
Itanium customers and upgrades, while the combination of the x86-64
port and various other factors might — might — eventually start to
reverse the recent trends and draw in new application deployments and
new customers. Remember that as recently as a year ago, we had no path
other than porting off of OpenVMS, and platform-migration discussions
were part of even HP OpenVMS presentations. Without a viable path
forward, additional customers will do what IanD is observing at that
site.

TL;DR: These folks have OpenVMS, and they have experience with it and
with outsourcing and staffing, and they also have experience with other
platforms. There's undoubtedly much more involved here than presenting
the ease of application translation. These migrations usually aren't
centrally about some particular aspect of technology. Translation,
emulation, or otherwise. It's usually some combination of the overall
strategies and goals and the revenue trends for the organization, and
about the product and vendor perceptions. Yes, the product and vendor
perceptions can be fact-based, and sometimes not. Understand the
customer and why they're migrating away, and you might have an
opportunity or maybe even a sale. Walk in with a discussion of
translation or emulation, and you may well miss out.

[terry+go...@tmk.com]

On Sunday, August 9, 2015 at 10:25:12 AM UTC-4, IanD wrote:
> According to recent feedback by Charon product sellers, our ES80 cannot be emulated on Charon because the HP Intel box will simply not keep up to match the ES80's performance

I have no idea how it benchmarks against Charon, but you might want to take a look at AlphaVM (http://www.emuvm.com). I find the lead developer very knowledgeable and great to work with - I had him port the product to FreeBSD for me when I purchased it (I did not consider either Windows or Linux a "step up" from a hardware Alpha).

I'm emulating a DS10, so I'm using a relatively lightweight Dell PowerEdge. But he has achieved some amazing numbers, particularly on the newer Intel CPUs. The benchmarks page there is a little dated, so I'd ask for the latest numbers if this is of interested.

[IanD]

On Monday, August 10, 2015 at 4:58:25 AM UTC+10, Stephen Hoffman wrote:
> On 2015-08-09 16:31:23 +0000, already...@yahoo.com said:
>

<snip>

> >>
> >> For cases such as what IanD is referencing, which is least-changes for
> >> the end-user? Translation, or emulation? Translation involves
> >> purchasing an Itanium and the rest of the baggage that entails, and
> >> then translating the individual hunks of the existing environment. (I'd
> >> not expect to see anything approaching Rosetta here, either. Not for
> >> Alpha to Itanium.) Emulation means creating a disk image of the old
> >> environment and transferring it and the licenses over to the new
> >> environment, and then using logical names to redirect device references
> >> where necessary. Neither approach is risk free, of course.
> >

If only we had access to the source code *sigh*

> > You are ignoring the data, provided by IanD. It's ES80, heavily loaded.
> > There is no practical chance that it will meet performance requirements
> > on Charon-AXP.
> > So, I'd call Charon-AXP risk free, that is, free of risk of working :(
>

Only in the past few days literally, the suppliers of Charon in this region have said they have something to match the performance of the ES80 now. This has been a long long time coming. I can only take their word for it

> Please re-read the thread. I do not expect these folks to change their
> hardware, though they might go to emulation if/when that's appropriate
> for them.
>

If this place had done that years ago and moved the code base along, then yeah, but to jump now and stay with VMS isn't in the pipeline :-(

I tried but a swag of forces acting in the opposite direction have overwhelmed my attempts at keeping VMS is this place

Latest and greatest I hear as of a few hours ago is that they will try and move the functionality to an existing Oracle package with some tweaks to pick up the bit Oracles does not do now. Why they wish to lock themselves into an Oracle based solution is not my call nor my recommendation for that matter

> As for comparing emulation, I do not expect emulation to have the same
> performance going forward. Whether that's due to improved hardware
> performance or better emulation, improvements are likely. It may also
> be due to reductions in the current server load, given the goal of
> migrating folks off of OpenVMS and onto the preferred platform and
> application.
>

Emulation has worked because IO made such a huge improvement. CPU too but not to the same extent.

For example, we emulated a DS10 with 1 cpu on a Charon instance and we immediately had issues. The throughput was certainly better but CPU suddenly went from 40% under the old system to 100% anytime more than 1 process ran a compute intensive task. The IO was simply so quick compared to the old DS10 physical system that under Charon it wasn't the limiting factor anymore, CPU was (and still is, too cheap to add another CPU which is simply a license change under Charon)

And this Charon system didn't use flash storage, just scsi yet it is so much quicker

Another solution we have uses flash storage on Charon but you are still limited with clock for clock likeness in emulation and the Intel server has to dedicate one cpu per VMS plus a couple more to look after Charon itself

> As I've commented, translation is likely a non-starter for management
> here. That for reasons of finances and risk aversion, and for
> generally wanting to migrate off of OpenVMS. There are a number of
> senior managers around that can't justify adding or that don't want
> OpenVMS around, and for very good reasons. To convince senior
> management otherwise and to convince them into performing a port is no
> small effort, and it takes more than a little preparation. (This is
> part of why sales reps really earn their pay, too.)
>
> Barring access to something analogous to the transparency of Rosetta

> for Alpha to Itanium migrations -- and there's precious little incentive

> here for VSI to invest substantially in getting folks from Alpha over
> to Itanium, particularly when the VSI could be investing in creating
> the technology necessary to get folks over onto x86-64, and on the

> OpenVMS x86-64 port itself. For now, the existing migration tools --
> "DECmigrate" -- are it. As for existing OpenVMS Alpha end-user sites

> that might be interested in porting to newer OpenVMS and newer hardware
> and aren't approaching performance or other constraints, why move to
> Itanium now, if they can keep the existing boxes going until x86-64 is
> available?
>

Yes, Itanium for us is a no go, they would have moved there a long time ago if it was a solution to them

> In short, this particular customer is very likely either gone and/or
> the application headed for deprecation, or they're not moving to
> Itanium.
>

100% correct

> What might eventually draw similar sites into these sorts of upgrades
> are competitive prices, x86-64 hardware and VM support, features and

> updates, and more experience with VSI over time. That, and -- for the
> sites that are missing some of the source code -- the translator (to

> x86-64) that VSI has discussed.
>

That was my hope in keeping VMS in this workplace but it's going to be too late to save VMS in this site and it's untested at this stage anyhow

Pie in the sky is not food on the plate so to speak

> > With AEST, on the other hand, there is a significant risk that it
> > wouldn't work at all and a less significant risk that it will work, but
> > wouldn't meet performance requirement, but still, with determined
> > effort, there is a good chance that everything will work and will free
> > them of concerns for the next 5-7 years at least.
>

> Buying some spare parts and doing some incremental upgrades --
> particularly updating the rotating-rust storage -- can likely keep an

> AlphaServer ES80 configuration going for five to seven years, too.
> I've dealt with much older Alpha systems that are (or recently were)
> still in service.
>

A viable solution but a certain organisation (because I'm not going to say it publicly here) I 'heard' do not want to sell Alpha parts and/or support systems that have reseller parts included in them

So any change of an old Alpha server lingering on on borrowed time / secondhand parts just received a kick in the teeth - but this is my 'opinion' only of course...

> But it wouldn't surprise me to learn the customer has plans to be off
> of OpenVMS in five to seven years. (Now whether they can get there?)
>

Much shorted time frame than that now - 12 months maximum :-(

> > As to HW, with Poulson now officially supported, fast hardware (e.g.
> > rx2800 i4) should be relatively affordable.
>
> For an ES80-class box? An i4 box or an i2 box will likely work. If

> time permitted, I'd be tempted to prototype a top-end rx2660 -- a
> quad-core 1.66 GHz configuration with 32 GB and fast I/O -- to see if

> that might manage reasonably competitive performance with an
> AlphaServer ES80. This performance in aggregate and given the faster
> interconnects involved here, and not based solely on raw processor
> performance.
>
>
> But none of this addresses the root issues here, unfortunately.
>
> > Naturally, I have no idea how affordable.
>
> Always ask about and always calculate the affordability of the
> available solutions. This having gone through these cases more than a
> few times. Once the cost of the port and of the translation have been
> calculated, and the willingness of the end-customer take on the risk

> has been investigated, then -- for cases such as this one -- compare that

> with the costs of spare parts and running the current hardware into the
> ground, and getting folks to move to the long-term preferred platform.
> Then there's the cost of overcoming management's perception that
> OpenVMS is not an appropriate long-term solution for them here. Which
> won't come cheaply, nor quickly.
>

200% agree here

You have a stack of yuppies who have been coming out of universities for a while now pushing what they know, linux linux linux to the point where they are in positions of influence in organizations and influencing decisions

hmmm, I seem to remember Digital doing this many years ago with Vax... History repeating itself?

> Now what happens with service and support costs and power and cooling
> and the rest? Unclear. It might drive a decision to Itanium, or it
> might drive the decision to finish moving off of the existing
> environment. But without the costs and without knowledge of the

> managers' requirements and goals and concerns -- if they think that

> OpenVMS is expensive and problematic, then you're starting out in an

> extremely deep hole to sell them another OpenVMS box -- any discussions

> of an Itanium translation tool or of a port will get about as far as
> discussions involving an Illudium Q-36 Explosive Space Modulator.
>

lol, can we get two of these or i assume that one is all one ever needs to run the universe on ;-)

> VSI is (hopefully) focused on the immediate and short-term work on
> Itanium for Kittson and for a new features release or two, and with the
> layered products, and particularly with establishing a revenue stream,
> and then concentrating on the x86-64 port. That work targets existing
> Itanium customers and upgrades, while the combination of the x86-64

> port and various other factors might -- might -- eventually start to

> reverse the recent trends and draw in new application deployments and
> new customers. Remember that as recently as a year ago, we had no path
> other than porting off of OpenVMS, and platform-migration discussions
> were part of even HP OpenVMS presentations. Without a viable path
> forward, additional customers will do what IanD is observing at that
> site.
>

Sad but true, sad but true

One just hoped that amidst all the excitement and rar rar, that there might have been a pathway forward for organisation using VMS like we are, to support an application that is long past it's use by date but still works but alas, now has nowhere to go

Bit frustrating to see the new kids frolicking in the new green pastures across the bridge having escaped the troll by crossing over another bridge...

> TL;DR: These folks have OpenVMS, and they have experience with it and
> with outsourcing and staffing, and they also have experience with other
> platforms. There's undoubtedly much more involved here than presenting
> the ease of application translation. These migrations usually aren't
> centrally about some particular aspect of technology. Translation,
> emulation, or otherwise. It's usually some combination of the overall
> strategies and goals and the revenue trends for the organization, and
> about the product and vendor perceptions. Yes, the product and vendor
> perceptions can be fact-based, and sometimes not. Understand the
> customer and why they're migrating away, and you might have an
> opportunity or maybe even a sale. Walk in with a discussion of
> translation or emulation, and you may well miss out.
>
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

Totally understand, VSI need to focus on what's necessary to get VMS viable again for them

Just like revenue leakage in any business, there is sadly VMS leakage in terms of systems out there who are stuck in old business pathways, destined for replacement rather than refurbishment :-(

It comes down to the issue of certification

They looked at other emulators but in a production environment certifications count

For example, Charon is VMware certified (versus some of the others that say they run on VMware)

They are highly risk adverse because they are not just responsible to their own internal customer base so any solution must tick all sorts of certifications and/or testing regimes. The other emulators simply didn't tick all the necessary boxes despite some of them probably being quicker

[David Froble]

IanD wrote:

> It comes down to the issue of certification

Certification is whatever someone says it is. That can be something used to
advance someone's agenda.

The issue should be "does it work?"

> They looked at other emulators but in a production environment certifications
> count
>
> For example, Charon is VMware certified (versus some of the others that say
> they run on VMware)

I got to ask, what does that "certification" buy you? If what you will get in
the end is "oops, sorry", that's not too helpful.

[Jan-Erik Soderholm]

Den 2015-08-18 kl. 17:27, skrev David Froble:
> IanD wrote:
>
>> It comes down to the issue of certification
>
> Certification is whatever someone says it is. That can be something used
> to advance someone's agenda.
>
> The issue should be "does it work?"
>
>> They looked at other emulators but in a production environment
>> certifications
>> count
>>
>> For example, Charon is VMware certified (versus some of the others that say
>> they run on VMware)
>
> I got to ask, what does that "certification" buy you?

Usualy it means that you actualy get help if there are problems.
"Certified" usualy goes hand-in-hand with "supported".

[Keith Parris]

On 8/9/2015 8:25 AM, IanD wrote:
> According to recent feedback by Charon product sellers, our
> ES80 cannot be emulated on Charon because the HP Intel box will
> simply not keep up to match the ES80's performance
>
> On top of this, we are hitting maximum cpu on the ES80 and need
> to purchase another 2P drawer and extra ram but we have hit a snag.
>
> Let's just say feedback is that a certain company who could supply
> this type of hardware and support it are saying they will not

While no one can sell you a new Alphaserver or new 2P CPU drawer or new
Alphaserver RAM today, HP Financial Services with their HP Renew
Program would, I'm sure, be very happy to sell you all the factory-
remanufactured Alpha hardware you might wish to buy. See
http://www.hp.com/united-states/renew/faq.html . And HP Technology
Services is still able to provide HW and SW services for Alpha.

I've worked with a customer who purchased 2 complete 32P GS1280 systems
via this route, years and years after the last-sale dates for new
hardware.

[IanD]

It's not just, "does it work", it's does it work and if it doesn't, is there a legal case where the underlining platform you sat your customers business on certified for what it is intended to do or was it not

It's not me who requires certification, it's those bean counters who are forking out the dollars who insist on it so as to reduce legal risk

Everything comes down to legal mitigation that's why certification and/or certified service agents get their dime

When a business decides to provide services to third parties who in turn string their business off the offering, you can guarantee if something goes tits up that their lawyers are lined up in battle formation looking for any loop-hole or nit-picked legality on which to base their case so as to reclaim cost - that is why certification is required because it reduces the chance of litigation should something go wrong as it provides one less peg for the layers to pin their claims to.
If a customer losses potentially millions per day through downtime, I am certain calls from lawyers will quickly follow with compensation letters in hand

Hey, I didn't make nor endorse this legal world, I just have to live in it

I'm old school, a written document with an understanding over a handshake used to be deemed good enough, but these days, people will lie through their teeth about any and everything when money is involved, the greater the dollar involved the greater the lies, so doing everything in one's power to ensure a compensation claim cannot be stapled to one's arse is a good thing, if that involves certification of systems, then so be it

On Wednesday, August 19, 2015 at 1:48:18 AM UTC+10, Jan-Erik Soderholm wrote:
> Den 2015-08-18 kl. 17:27, skrev David Froble:

>
> Usualy it means that you actualy get help if there are problems.
> "Certified" usualy goes hand-in-hand with "supported".
>
>

+1

On Friday, September 4, 2015 at 7:01:14 AM UTC+10, Keith Parris wrote:

> On 8/9/2015 8:25 AM, IanD wrote:
> > According to recent feedback by Charon product sellers, our
> > ES80 cannot be emulated on Charon because the HP Intel box will
> > simply not keep up to match the ES80's performance
> >

> > On top of this, we are hitting maximum cpu on the ES80 and need
> > to purchase another 2P drawer and extra ram but we have hit a snag.
> >
> > Let's just say feedback is that a certain company who could supply
> > this type of hardware and support it are saying they will not
>
> While no one can sell you a new Alphaserver or new 2P CPU drawer or new
> Alphaserver RAM today, HP Financial Services with their HP Renew
> Program would, I'm sure, be very happy to sell you all the factory-
> remanufactured Alpha hardware you might wish to buy. See
> http://www.hp.com/united-states/renew/faq.html . And HP Technology
> Services is still able to provide HW and SW services for Alpha.
>
> I've worked with a customer who purchased 2 complete 32P GS1280 systems
> via this route, years and years after the last-sale dates for new
> hardware.

We have sourced a 2P drawer from a re-seller, who incidentally sells refurbished parts to HP, lol

Some fun and games is being had over support but I'm sure we will eventually get there

I suggested getting a GS1280 and ramping it up to switch over to if they wanted to burn money rather than touch the ES80

The same re-seller has a couple of GS1280's they are willing to sell

[David Froble]

IanD wrote:
> On Wednesday, August 19, 2015 at 1:24:23 AM UTC+10, David Froble wrote:
>> IanD wrote:
>>
>>> It comes down to the issue of certification
>> Certification is whatever someone says it is. That can be something used to
>> advance someone's agenda.
>>
>> The issue should be "does it work?"
>>
>>> They looked at other emulators but in a production environment certifications
>>> count
>>>
>>> For example, Charon is VMware certified (versus some of the others that say
>>> they run on VMware)
>> I got to ask, what does that "certification" buy you? If what you will get in
>> the end is "oops, sorry", that's not too helpful.
>>
>>> They are highly risk adverse because they are not just responsible to their
>>> own internal customer base so any solution must tick all sorts of
>>> certifications and/or testing regimes. The other emulators simply didn't tick
>>> all the necessary boxes despite some of them probably being quicker
>
> It's not just, "does it work", it's does it work and if it doesn't, is there
> a
legal case where the underlining platform you sat your customers business on
certified for what it is intended to do or was it not
>
> It's not me who requires certification, it's those bean counters who are
forking out the dollars who insist on it so as to reduce legal risk

The legal risk would be for those who "certified" that something would perform
per some claim. If it doesn't, then those who claimed it would are holding the bag.

> Everything comes down to legal mitigation that's why certification and/or
certified service agents get their dime
>
> When a business decides to provide services to third parties who in turn
string their business off the offering, you can guarantee if something goes tits
up that their lawyers are lined up in battle formation looking for any loop-hole
or nit-picked legality on which to base their case so as to reclaim cost - that
is why certification is required because it reduces the chance of litigation
should something go wrong as it provides one less peg for the layers to pin
their claims to.
> If a customer losses potentially millions per day through downtime, I am
certain calls from lawyers will quickly follow with compensation letters in hand
>
> Hey, I didn't make nor endorse this legal world, I just have to live in it

Yeah, and sometimes it sucks ....

> I'm old school, a written document with an understanding over a handshake
> used
to be deemed good enough, but these days, people will lie through their teeth
about any and everything when money is involved, the greater the dollar involved
the greater the lies, so doing everything in one's power to ensure a
compensation claim cannot be stapled to one's arse is a good thing, if that
involves certification of systems, then so be it

If there is someone stupid enough to make claims.