[Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1 Marketing Brochures

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of David Froble via Info-vax
> Sent: 22-Sep-16 11:24 PM
> To: info-vax at rbnsn.com
> Cc: David Froble <davef at tsoft-inc.com>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
> 
> IanD wrote:
> > On Monday, September 19, 2016 at 9:41:03 PM UTC+10,
> clairg... at gmail.com wrote:
> >> RE: Alpha
> >>
> >> Alpha is a very difficult issue for us. We have people coming to
> us
> >> looking for Alpha support but the only way we can provide it at
> this time is for the customer to upgrade to a VSI release.
> >> If you have been running on 7.3-2 for 10+ years do you really
> want to disturb that environment?
> >>

[snip..]

> >
> > The current folk doing the port know zero about OpenVMS and
> they are trying to move it all to linux.
> >

A huge part of the TCO is Oracle licensing costs which are double for Alpha/IA64 due to Oracles anti-competition tax called their Processor Core Factor which for Alpha/IA64 is 1.0. When charging $25-$50K per core, this is a huge factor (add 50% per core if using RAC).

The good news is that when OpenVMS X86-64/Oracle is available, the Processor Core factor will be 0.5 - same as Linux. Hence, OpenVMS on Alpha/IA64 customers should be able to cut their Oracle license costs by 50%.

Also remember that there is a potential to reduce OpenVMS license costs in a migration because Alpha is core (cpu) based licenses, while I2/I4 systems are socket based.

> > If someone had said to the business 12 months ago, here's how
> we could move you off that old hardware and you could retain
> your existing application functionality because it's a port on the
> same OS / code base, I think they might have jumped at it.
> >
> > The only winner in what's happening where I work will be
> Oracle and
> > whomever does the development work and OpenVMS will
> vanish as a
> > presence here probably forever :-(
> >
> > There will be no future OpenVMS licensing agreements being
> renewed
> > here and that is a crying shame, it's the loss of a presence that's
> > going to hurt OpenVMS going forward
> 

The way I like to position these options as minimizing business risk with strategy options called "upgrade-n-integrate" vs. "rip-n-replace". The former is usually by far the lowest risk to the business while the latter usually is not only higher risk, but often orders of magnitude greater cost.

See note above about Oracle license costs 50% reduction on OpenVMS X86-64.

> So, prepare a short presentation, and submit it to the powers
> that be.  You could point out the "safety" in not losing the current
> working app.  Costs would need to be pointed out, including
> getting the sources, and building them first on itanic, and later on
> x86.  Not going to be cheap, but perhaps much cheaper than a
> from scratch re-write.  Once you got the sources, you would not
> face that problem again, and you'd have future flexibility.
> 
> That re-write from scratch is going to have some problems, and
> may never reach what you now have.  It's a bottomless money
> pit.
> 

I know of one Cust that tried literally for 8 years to move a large complex mission critical OpenVMS environment to UNIX (HP-UX). HP was helping them all the way, but they just kept having issues. After numerous different attempts, the business folks essentially told the IT dept "enough!". Last I heard they now have a couple IA64 nodes in their 8 node OpenVMS A-A homogeneous Alpha ES45 cluster.

> Never know, might work, and if it doesn't how are you worse off
> than now?
> 

Agree - the way to attack FUD from internal Linux groups is with discussions with senior management on lower business risk and lower costs. Fight fire with fire.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com