Competence Center for VAX/VMS migration: what do YOU want

[Didier Morandi_2]

THIS MESSAGE FOR VAX/VMS USERS

I'm working these days as a consultant on the setup of an European Competence Center to help VAX/VMS Users to migrate to OpenVMS/I64.

What resources do you expect to find in such activity?

From previous analysis, I already decided to propose the following items:

a) advisory, or better say Change Management i.e. psychological help to assist users in the process of taking such decision. The "ostrich behaviour" is not a professional one.

b) numerous platforms to port software on and perform actual migration of code, locally in a lab or remotely via the Internet (Telnet, DECNet over IP, VPN, etc.)

c) software engineers availability for technical discussions and/or on site consulting

d) marketing/sales people availability for discussions on licenses and such

e) CHARON-VAX, CHARON-Alpha booth for those who would prefer that solution

f) coffee/tea/red wine corner

What else?
Thanks,

D.
--
Didier MORANDI - Expert informaticien - VMS / SAP
13 chemin du Gué, 1213 Petit-Lancy (GE) Suisse
Tél. : +33(0)6 7983 6418 ~ www.didiermorandi.com

[Antoniov. · Accepted solution]

Didier,
I say hardware compatibility list. Some vax have customer-designed cards which make unpraticable migration of software.
In most common case, migration of server means reingenering of workstation and network. Network engineers are needed.

Antonio Vigliotti

P.S.
At f) level, add some biscuit :-)

[Ian Miller.]

TCO information to show that it saves money to transfer to a more modern VMS system.

f) + beer :-)

[Willem Grooters]

What is your focus? Should be small and medium size businesses, I guess. VAX, but don't forget Alpha. Some companies have old ones and they could well benefit from this centre as well.

I guess the company I work for would surely be interested in all but b), depending on location, that would be supplied by HP (in the Netherlands anyway).

Antonio,
Agreed on netwerk people though that would not be the biggest issue. I think that hardware engineers are required as well, since you may need to do hardware replacement as well (Unibus devices, for instance).

[Uwe Zessin]

Software compatibility lists and migration possibilities, because many VAX-based software has been EOLed.

f) ice

[Antoniov.]

Didier,
in your signature I see VMS / SAP.
Just for curiosisty, what does it mean, SAP ERP software?

Antonio Vigliotti

[Didier Morandi_2]

Re Willem: my focus is all Customers Problem solving.

re Antonio: Yes, I specialized on SAP CRM during the no-VMS slots part of my life (2000-2004)

[Jan van den Ende]

Didier,


would that not make you into _THE_ perfect man to advocate SAP availability on VMS?

Somehow it MUST be possible to convinse those SAPpers that VMS (and especially clustered) would be a WONDERFUL platform for such stuff!


... but the idea is appealing...

f) I Igree with Ian!

Proost.

Have one on me.

jpe

[Kris Clippeleyr]

Re: Uwe


Software compatibility lists and migration possibilities, because many VAX-based software has been EOLed.

I couldn't agree more. But not only VAX-based software has been EOLed. There's a bunch of Alpha software too that is not yet ( will never get ) ported to Itanium.
Maybe an idea to have ISV representatives occasionally on site.

Kris (aka Qkcl)

[Uwe Zessin]

Yes, but I'd like to reserve that for the 'Competency Center for Alpha migration' ;-)

[Didier Morandi_2]

You won all. Let's call it "HP OpenVMS/I64 Migration Center" or better "Private Institute for HP OpenVMS/I64 Migration", or...?

D.

[Willem Grooters]

..or...
OpenVMS/I64 M(gration) E(xperts)?

"Private Institute" is Ok, as long as we have backing by HP, and as long as HP will recognize the expertise of (some of) their customers. That may be the hardest nut to crack.

Willem

[Antoniov.]

If vax applications are EOLed, why people don't change their system?

a) advisory, or better say Change Management i.e. psychological help to assist users in the process of taking such decision.

It's the most importart part of migration process.

Antonio Vigliotti

[Uwe Zessin]

Antonio,
any change costs money and has risks. And many managers don't like to hear the truth. They rather close their eyes, put the fingers in the ears and sing: "la-la-la, everything is great!"

[Jan van den Ende]

There ARE factories with plants running for ~ 15 years, with another 10 - 15 years expected. Such plants were BUILT TOGETHER with the software that runs it (typically on Vax, VMS or ELN, typically with dedicated, custom-designed periferals).
If ONE part of that plant (and the Vax IS such a part) breaks and can not be repaired/replaced, then THE WHOLE PLANT has to be decommissioned. A HUGE de-investment!

That means, IF there are no more spares, then there MUST be provided a replacement WITH THE SAME FUNCTIONALITY.

Discontinuing / not porting some products on the replacement hardware (I64, but also some on Alpha) is NOT the way to keep such customers happy!

Why do you think refurbished Vaxen are still so heavy in demand?
Why do you think Charon is often a better option than Alpha or I64?

-- I know, they are "only" legacy systems, but
"Legacy system" = "Stuff that works"

@ Uwe:

I have also heard that song. It is taught in Management Schools & Management Training, in MANY languages!

fwiw,

Proost.

Have one on me.

jpe

[Willem Grooters]

You will, I expect, run into a very different kind of problems when migrating this type of systems. One day, spare parts will become a BIG problem....There the challenge starts, if you don't want, or are unable to adjust/change the hard- and software

A lot of this hardware might be site-specific, eventually locally designed and assembled. Irreplacable, in fact.

If you replace the hardware (VAX) by another platform ((Intel or Alpha) + Charon) you need to replace the interfacing hardware (Unibus?) as well. Does anyone know of a GOOD replacement, that can be used WITHOUT ANY adjustment? nemonix may have such a replacement (PCI -> UNIBUS?).

In a lot of these environments, timing is crucial. Adding an extra hardware layer may cause timing problems. Using faster software may imply trouble as well - in the same area: timing. Not just in software, in hardware as well. So that's where the assistance of hardware engineers becomes crucial.

Migrating these environments is not a matter of days, weeks or month. It may take years.
Not just the technical part of the job. Validating and certifying the changed environment will take a lot of effort.

[Antoniov.]

Uwe, Jan,
you are right, some managers are afraid of changing and prefer still use old devices.
However, if they don't decide old software can't be migrated.

Antonio Vigliotti

[Ian Miller.]

for "Stuff that works" see http://www.xdelta.co.uk

Is hp co-operating and providing support for this center?

[Didier Morandi_2]

All,

Read this: http://www.didiermorandi.com/products.htm
and visit that: http://www.logical-co.com/

D.

[Craig A Berry]

Put up some success stories as soon as you have any.

I would also suggest putting together some matrices that allow people to easily look up aspects of their current software and hardware environment and see what they need to do to get to Itanium. Much of the material of this nature on the HP web site assumes Alpha to Itanium and it's not always clear what (if anything) would be different for VAX to Itanium. Digging up all the old VAX to Alpha materials you can find and cross referencing it with some of the current Alpha to Itanium material might help some people make the leap.

[Jan van den Ende]

Sue pointed this out:

http://www.osdata.com/

I have not read all yet, but so far, I think it is fit for reading, AND for LETTING it be read!

Proost.

Have one on me.

jpe

[comarow]

I would insist on duplicate test environment so that they could try out their applications on a test system.

[Wim Van den Wyngaert]

I would like to see success (or failure) stories for techs. E.g. a log book of what had to be done to move a proprietory application from VAX to I64. Including what went wrong and how long it took.

So, not the manager telling his colored view on the move ("it took just 100 days", while he forgot to mention that other teams had to work 1000 days extra).

Wim

[Robert Gezelter]

Didier,

A lot of very good things have been said by others.

Some useful things:

- HP (and partner) resources available
- that VAX/Alpha/Integrity pre-conversion is one of the most important parts. Having been through the conversion process three times PDP-11, VAX, and now, Alpha, I can say that the worst problems are caused by programs that are "marginally valid", they just happen to function adequately most of the time. These situations are the root cause of many of the timing problems with devices and such. I have been seeing these in the old days, even when switching between different model PDP-11 systems.
- that migration is a straightforward process, but that the quahlification process is critical.
- timing is everything. It is not necessarily to be on the leading edge (the "bleeding" edge, as some say), but being current is important. Being too far behind raises the costs significantly, and obviates your ability to control schedules, which also dramatically increases costs.

I have been speaking positively about the technical aspects of converting to Integrity since the initial announcement in 2001 (see http://www.rlgsc.com/cets/2001/1620.html).

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

[Ian Miller.]

have you seen
http://h71000.www7.hp.com/openvms/integrity/transition/index.html