OpenVMS: Navigating the Crossroads
Blog //09-02-2021

OpenVMS: Navigating the Crossroads

by Rob Anderson, Vice President of Marketing and Product for Application Modernization

The resources needed to maintain OpenVMS applications are diminishing, and several big tech partners are already parting ways with the system. This blog navigates the potential avenues one might take towards modernising OpenVMS systems.

As of 2021, OpenVMS continues to drive numerous mission-critical business and operational systems across the planet. Originally created by DEC back in 1977 as VMS (Virtual Memory System), the reliable, high availability operating system has proven its worth to a diverse array of organisations for many years. But the resources needed to maintain these applications are disappearing.

Developers are reaching retirement age and leaving the industry, meaning that essential maintenance is becoming increasingly time-consuming and expensive. On top of this, several big tech partners have started discontinuing support for OpenVMS.

The end of the road

OpenVMS started life on DEC VAX servers, then moved to DEC/HP Alpha servers, but neither of these platforms are supported any more. HP then ported OpenVMS to the Integrity server to replace the Alpha and powered its last OpenVMS platform with Intel’s Itanium chip. However, Intel announced in 2019 that it was discontinuing its Itanium 9700-series processers (the last in the Itanium series), with final shipments of these taking place later this year.

On top of this, there have been more end-of-support announcements made in the recent months. HPE ended standard support for OpenVMS V8.4 in December 2020, along with last orders for the Itanium i6 servers. HPE are also ending support for the final generation of its Itanium CPUs in 2025, with support for the i2 server having ended just over a week ago. If this wasn’t enough, Oracle has also joined the list, announcing that it is discontinuing the 11g database, including client components, affecting customers who use the Oracle database or Oracle database client software on OpenVMS.

With so much uncertainty and lack of support from big tech partners, it’s important to consider the future of your business-critical applications. Is it time to take a new direction and assess options for migrating OpenVMS applications?

There are several pathways to consider with OpenVMS Migration – you can find these detailed in our whitepaper; ’Considerations for an OpenVMS Application Migration and Modernisation Strategy’. This blog explores the two solutions that are most likely to be employed in a modernisation project, as well as outlining the steps we take to mitigate risk in OpenVMS migration projects.

Same driver, new car

Rehosting (sometimes referred to as ‘lift and shift’ or ‘replatforming’) describes a migration where minimal changes are made to the underlying technology of the application and database. The biggest benefit of rehosting is that it limits changes to the application itself and ensures the preservation of functionality, business logic and business processes after the migration. Because of this, the testing required to verify the migration is minimised, and the cost / time for end-user retraining is eliminated.

Rehosting is not moving to an emulated hardware solution. This approach typically uses a software / hardware emulation of VAX or Alpha sitting on top of either bare metal or Windows / Linux, whereas rehosting allows the migrated application to run natively on the target platform. This removes the performance overhead often associated with an emulator and allows the migrated application to take full advantage of modern features available in the new operating environment.

The feasibility of rehosting depends not only upon having access to a native language compiler in the new environment, but also a framework that underpins the proprietary aspects of the OpenVMS world.  Fortunately, these Compatibility Frameworks are readily available in the market. They introduce a software licence component in the new environment, but the reduction in overall migration cost more than pays for the licensing fees – ultimately making it more cost-sustainable.

Taking the hybrid road

It’s important to note that rehosting isn’t always the best solution. In some instances, the OpenVMS technologies simply cannot be supported in the target environment. But this doesn’t always mean that you would have to re-engineer your entire system to experience the benefits of modernisation.

Many organisations adopt a hybrid approach: rehosting the components that could be easily supported in the modernised environment, and using automation to re-architect aspects for which a rehosting solution is not the best option, or where functional / technology modernisation delivers added benefits to the business. For example, you may take your migration as an opportunity to modernise your database - RMS files and RDB tables can be migrated directly to Oracle or Microsoft SQL Server.

Mitigating risk

Whilst it’s important to modernise ageing applications at the earliest opportunity possible, the process still demands both care and patience. We believe that there are three crucial factors that are essential to a successful migration project:

  • Discovery is a critical phase in any successful migration in that it determines the composition, size and complexity of the current OpenVMS environment. Making a detailed inventory of application components creates a template upon which migration solutions can be applied to each piece. Once this is in place, work can begin on analysing the source code.
  • With a complete picture of the application set that will be migrated, the next step is planning the migration process. The key in this phase is to ensure that the migration addresses every aspect of the application. Planning the migration completely is the single most important aspect for risk mitigation.
  • Testing is also critical since most migrations require at least some modification to code and data structures. Pyramid testing is generally considered the best approach, as it employs various methods to test out both critical and non-critical functions, using automation to prioritise groups into different levels based on program criticality.

If you’re interested in learning more, our whitepaper further details the available options for migrating and modernising applications currently running on OpenVMS, and highlights the benefits that your organisation can achieve through modernisation.

Further resources

Blog Application Modernisation Application Modernisation and Migration Application Modernisation Strategy Application Re-architected and Reintegration Application Understanding OpenVMS
Rob Anderson

Rob Anderson

PUBLISHED BY

Vice President of Marketing and Product for Application Modernization

Rob Anderson is Vice President of Marketing and Product for Application Modernization. He has spent the better part of the past decade developing, marketing, and selling mainframe modernization solutions, and has had a front-row seat in the transformation of the industry and its surrounding ecosystem.

Read published articles