[Info-vax] 1 year.

[Stephen Hoffman]

On 2015-08-09 16:31:23 +0000, already5chosen at yahoo.com said:

> On Sunday, August 9, 2015 at 6:07:11 PM UTC+3, Stephen Hoffman wrote:
>> On 2015-08-09 13:57:37 +0000, already5chosen at 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-bounces at info-vax.com] On Behalf Of
>>>>> already5chosen at yahoo.com
>>>>> Sent: 09-Aug-15 5:28 AM
>>>>> To: info-vax at 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.
> 
> 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 :(

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.


-- 
Pure Personal Opinion | HoffmanLabs LLC