Moving away from Itanium [closed]

Question

We currently have a large business-critical application written in COBOL, running on OpenVMS (Integrity/Itanium).

As the months pass, there is more and more speculation about the lifetime of the Itanium architecture. Nothing is said out in the open, of course, but articles like this and this paint a worrying picture. Although I can find nothing official to support this, there are even murmurings in the corridors of our company of HP ditching OpenVMS and HP COBOL along with it.

I cannot believe that we are alone in this.

The way I see it, there are a few options:

1. Emulate some old hardware and run the application on that using a product like CHARON-VAX or CHARON-AXP. The way I see it, the pros are that the process should be relatively painless, especially if the 64-bit (AXP) option is used. Potential cons are a degradation in performance (although this should be offset by faster and faster hardware);
2. Port the HP COBOL-based application to a more modern dialect of COBOL, such as Visual COBOL. The pros, then, are the fact that the porting effort is relatively low (it's still COBOL) and the fact that one can run the application on a Unix or Windows platform. The cons are that although you're porting COBOL, the fact that you're porting to a different operating system could make things tricky (esp. if there are OpenVMS-specific dependencies);
3. Automatically translate the COBOL into a more modern language like Java. This has the obvious benefit of immediately freeing one from all the legacy issues in one fell swoop: hardware support, operating system support, and especially finding administrators and programmers. Apart from this being a big job, an obvious downside is the fact that one will end up with non-idiomatic Java (or whatever target language is ultimately chosen); arguably, this is something that can be ameliorated over time.
4. A rewrite, from the ground up (naturally, using modern technologies). Anyone who has done this knows how expensive and time-consuming it is. I've only included it to make the list complete :)

Note that there is no dependency on a proprietary DBMS; the database is ISAM file-based.

So ... my question is:

What are others faced with the imminent obsolescence of Itanium doing to maintain business continuity when their platform of choice is OpenVMS and COBOL?

UPDATE:

We have had an official assurance from our local HP representative that Integrity/Itanium/OpenVMS will be supported at least up until 2022. I guess this means that this whole issue is less about the platform, and more about the language (COBOL).

Prevent

This is an ugly situation. I would try contacting MicroFocus to find out what kind of migration strategy they are developing for their customers. I believe MicroFocus promoted migration of COBOL applications to Itanium platforms. And because of this, I suspect they will be working as hard as anyone to find a migration path from Itanium to "the next and greatest thing" - whatever that might be. They have as much to loose in this as anybody so find out where their ship is sailing and maybe hitch a ride. – Melesa

It looks as if you will have to seriously consider moving off OpenVMS. You should ask HP if they have a UNIX product that supports HP COBOL. Also, in addition to NealB's suggestion, you should also check with Veryant, they offer two different COBOL compliers (veryant.com) – Syriac

Answer 1

The main problem with this effort will be the portions of the code that are OpenVMS specific. Most applications developed on OpenVMS typically use routines and procedures that are not easily ported to another platform. Rather that worry about specific language compatibility, I would initially focus on the runtime routines and command procedures used by the application.

An alternative approach may be to continue to use the current application while developing a new one or modifying a commercially available application to suit your needs. While the long term status of Itanium is in question, history indicates that OpenVMS will remain viable for some time to come. There are still VAX machines being used today for business critical applications. The fact that OpenVMS and its hardware is stable is the main reason for its longevity.

Dan

Ila

Answer 2

Looks like COBOL is the main dependency that keeps you worried. I undrestand Itanium+OpenVMS in this picture is just a platform.

You're definitely not alone running mission-critical stuff on OpenVMS. HP site has OpenVMS roadmap (both Alpha and Integrity), support currently stretches to 2015. Oracle seems trying to leverage it's SUN asset in different domains recently.

In any case, if your worries are substantial (sure we all worried about COMPAQ, then HP, vax>>alpha>>Itanium transitions in the past), there's time to un-tie the COBOL dependency.

So I would look now into charting out migration path from COBOL onto more portable language of choice (eg. C/C++ ANSII without platform extensions). Perhaps Java isn't the frendliest choice, given Oracle's activity. Re-write, how unpleasant it is, will be more progressive and likely will streamline the whole process. The sooner one starts, the sooner one completes.

Also, in addition to emulators, there're still plenty of second-hand hardware. Ironically, one company I know just now phases-in Integrity platforms to supplant misson-critical Alphas -- I guess, it's "corporate testing requirements"...

Do-nothing is an option as well, though obviously riskier: OpenVMS platforms are proven to be dependable, so alternatively, finding a reliable third-party support company may extend your future hardware contingency.

Musil

Rewriting a large application by hand is usually the route to disaster. Its expensive, hard to do, takes a long time, and the new application "never" catches up with the running application so it can't displace it. If you're lucky you get past all this. What is practical are large-scale automated migrations, of COBOL-for-whatever-ecosystem (your case: OpenVMS) to COBOL-for-different-ecosystem and/or different languages. These are painful, too, but not in the same way. See #3455956 – Geerts

Answer 3

This summer's Rolling Roadmap makes porting off OpenVMS look like an excellent idea.

Given how much COBOL exists in the world finding people to support COBOL will not be a problem for the foreseeable future. As noted above there are COBOL compilers on other platforms. The problem lies in the OpenVMS system service calls and DEC language extensions your application uses. You do not mention where your data is stored, so worst case your COBOL uses RMS. There is a company that provides an implementation of many OpenVMS system services on Linux and the Unixes. Not needing to replace those services while porting to another operating system may reduce the complexity. Check out Sector7.com.

Gangplank

Roadmap = EndoftheRoadmap – Pyrene