Departure from Itanium

Question

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

As the months pass, more and more reflection on the Itanium architecture's lifetime. Of course, nothing is said in the public domain, but articles such as this and this paint a disturbing picture. Although I cannot find anything official to support this, there is even a murmur in the corridors of our HP company, which has OpenVMS and HP COBOL.

I can’t believe that we are alone in this.

As I see it, there are several options:

• Emulate some old hardware and run the application on it using a product such as CHARON-VAX or CHARON-AXP . As I see it, professionals argue that the process should be relatively painless, especially if you use the 64-bit (AXP) option. Potential disadvantages are a decrease in productivity (although this should be offset by faster and faster equipment);
• Port your HP COBOL-based application to a more modern COBOL dialect, such as Visual COBOL . At the same time, the pluses are the fact that the porting efforts are relatively low (this is still COBOL) and the fact that you can run the application on a Unix or Windows platform. The downside is that although you are porting COBOL, the fact that you are porting to another operating system can make things complicated (especially if there are dependencies on OpenVMS);
• Automatically translate COBOL into a more modern language such as Java. This provides the obvious benefit of immediately releasing one of all the obsolete issues in one fell swoop: hardware support, operating system support, and especially the search for administrators and programmers. Besides the fact that this is a lot of work, the obvious drawback is the fact that in the end you will have non-idiomatic Java (or, ultimately, the chosen language). perhaps this is something that can be improved over time.
• Rewrite from scratch (naturally, using modern technology). Anyone who has done this knows how expensive and time consuming it is. I included it only to complete the list :)

Please note that there is no dependence on your own DBMS; file-based ISAM database.

So ... my question is:

What are others facing Itanium's inevitable obsolescence in order to maintain business continuity when OpenVMS and COBOL are their platform of choice?

UPDATE:

Our HP spokesman had an official guarantee that Integrity / Itanium / OpenVMS would be supported until at least 2022. I think this means that the whole question is less about the platform and more about the language (COBOL).

Answer 1

The main problem with this effort is the parts of the code that are specific to OpenVMS. Most applications developed on OpenVMS usually use procedures and procedures that are not easily ported to another platform. Rather, worrying about specific language compatibility, I would first focus on the execution and command procedures used by the application.

An alternative approach would be to continue using the current application while developing a new one or to modify a commercially available application to suit your needs. Although Itanium's long-term status is in question, history indicates that OpenVMS will remain viable for some time. VAX machines for business-critical applications are still in use today. The fact that OpenVMS and its hardware are stable is the main reason for its longevity.

Dan

Answer 2

It seems that COBOL is the main addiction that makes you worry. I undrestand Itanium + OpenVMS in this figure - it's just a platform.

At OpenVMS, you are definitely not alone in doing critical things. The HP website has an open OpenVMS card (both Alpha and Integrity), support is currently stretched until 2015. Oracle seems to be trying recently to use its SUN asset across domains.

In any case, if your worries are significant (I’m sure that we all worried about COMPAQ, then HP, vax → alpha → Itanium goes over in the past), there is time to undo the COBOL dependency.

So, now I will consider the migration path from COBOL to a more convenient language (for example, C / C ++ ANSII without platform extensions). Java may not be the preferred choice given Oracle's activity. Repeated recording, as it is unpleasant, will be more progressive and, most likely, will simplify the whole process. The sooner it starts, the sooner it will end.

In addition, there are still a lot of used equipment in addition to emulators. Ironically, one company that I only know now is on Integrity platforms, to supplant critical versions for Alpha - I think these are “corporate testing requirements” ...

Do-nothing is also an option, although obviously more risky: OpenVMS platforms have proven to be reliable, so alternatively looking for a reliable third-party support company can extend your future hardware.

Answer 3

This summer, the Rolling Roadmap makes OpenVMS porting a great idea.

Given how many COBOL exist in the world, finding people to support COBOL will not be a problem in the foreseeable future. As noted above, other platforms have COBOL compilers. The problem is the OpenVMS system service calls and the DEC language extensions used by your application. You do not specify where your data is stored, so in the worst case, your COBOL uses RMS. There is a company that provides the implementation of many OpenVMS system services on Linux and Unix. You do not need to replace these services when migrating to another operating system; this can reduce complexity. Check out Sector7.com.