sign in sign up
<<
Home , DIGITAL Command Language, Ingres (database), OpenVMS

Considerations for an OpenVMS Application Migration and Modernisation Strategy Moving OpenVMS applications to , Windows or

OpenVMS: time to plan for the future These issues serve as a prompt for IT leaders OpenVMS, originally called VMS ( to closely examine the functionality of their System), was first released in support of the OpenVMS systems and to seek the right VAX-11/780 in 1977. During the 1980s and early modernisation strategy for their business. This 1990s a VAX/Alpha running VMS paper looks at the available options for migration was quite popular since the was and the benefits that might be achieved through well suited to high speed, real-time applications. modernisation. Even now, OpenVMS continues to drive numerous mission-critical business and operational Factors driving decisions systems. These reliable, high availability There are five key factors to consider when systems have proven their worth to numerous assessing options for an OpenVMS application organisations, including nuclear power plants migration and modernisation strategy. How each and financial services firms. Quite often, these application ranks against these factors will organisations have invested money and decades determine the direction to be taken and the of time to customise their OpenVMS applications target end state. to meet very specific needs. Application Criticality In spite of OpenVMS's attributes, more and more Perhaps the important factor is how IT executives are realising the limitations of their mission-critical the application is to the business. legacy applications in the context of their digital For example, does the application provide transformation strategies. Legacy languages and custom or unique business functionality that hardware are hard to support, maintaining them cannot easily be replaced? The answer to this incurs ever-increasing costs, and the software question will help guide a decision on whether often doesn't integrate well with modern IT the application should be retained, replaced, systems. It's not surprising that today nearly half rewritten or even retired. If the OpenVMS of IT executives view application modernisation as application has been customised to meet the one of their top five priorities. needs of the business and is mission-critical, a migration and modernisation initiative may be the best strategy.

WHITE PAPER OpenVMS Application Migration & Modernisation

OpenVMS: time to plan for the future These issues serve as a prompt for IT leaders OpenVMS, originally called VMS (Virtual Memory to closely examine the functionality of their System), was first released in support of the OpenVMS systems and to seek the right VAX-11/780 in 1977. During the 1980s and early modernisation strategy for their business. This 1990s a VAX/Alpha minicomputer running VMS paper looks at the available options for migration was quite popular since the operating system was and the benefits that might be achieved through well suited to high speed, real-time applications. modernisation. Even now, OpenVMS continues to drive numerous mission-critical business and operational Factors driving decisions systems. These reliable, high availability There are five key factors to consider when systems have proven their worth to numerous assessing options for an OpenVMS application organisations, including nuclear power plants migration and modernisation strategy. How each and financial services firms. Quite often, these application ranks against these factors will help organisations have invested money and decades determine the direction to be taken and the of time to customise their OpenVMS applications target end state. to meet very specific needs. Application Criticality In spite of OpenVMS's attributes, more and more Perhaps the most important factor is how IT executives are realising the limitations of their mission-critical the application is to the business. legacy applications in the context of their digital For example, does the application provide transformation strategies. Legacy languages and custom or unique business functionality that hardware are hard to support, maintaining them cannot easily be replaced? The answer to this incurs ever-increasing costs, and the software question will help guide a decision on whether often doesn't integrate well with modern IT the application should be retained, replaced, systems. It's not surprising that today nearly half rewritten or even retired. If the OpenVMS of IT executives view application modernisation as application has been customised to meet the one of their top five priorities. needs of the business and is mission-critical, a migration and modernisation initiative may be the best strategy.

APPLICATION CRITICALITY

SECURITY & COMPLIANCE IT STRATEGY

INTEROPERABILITY SUSTAINABILITY

2 | OpenVMS Application Migration & Modernisation

Sustainability or public cloud architectures, the growing gulf There are fewer experienced OpenVMS resources between OpenVMS and this future IT direction available in the marketplace than ever before. becomes a liability. This not only creates a potential risk, but impacts Examining these five factors helps an IT decisions about what end state should be organisation assess the relevance and reliance targeted in any migration and modernisation associated with OpenVMS applications. The good initiative. It is important to analyse the existing news is these factors can be addressed, and risks OpenVMS skills that are available to support mitigated, with a well-designed migration and and operate not only the current environment, modernisation plan. but also to what these resources will be accessible in the future. In addition to the human resources, the technical aspects of new releases Re-host, re-architect or both? must be considered. There are many solutions which can be employed when moving OpenVMS applications and data Interoperability to a new platform. These solutions range from The extent to which an OpenVMS application “re-hosting” to a more invasive “re-architecting” of supports external interfaces and adheres the applications. Between these two extremes it to the standards within an organisation for is often beneficial to consider a hybrid approach: interoperability architectures should be re-hosting portions of the application that considered when looking at the desired end state can be easily moved and re-architecting those for a migration or modernisation project. components where a new end state technology In many cases, OpenVMS applications and data or functionality is desired. have become “islands” in an organisation’s IT Re-hosting landscape. Certainly, integration of external Re-hosting (sometimes referred to as “lift and applications with OpenVMS applications is shift”) describes a migration where minimal feasible; however, these mechanisms are changes are made to the underlying technology becoming exceptions in an enterprise integration of the application and . The benefit strategy. Building integration points and of re-hosting is that it minimises changes to maintaining them can become expensive and the application and ensures the preservation prevent organisations from achieving a standard of functionality, business logic and business architecture for application interoperability. processes after the migration. Because of this, Security and Compliance the testing required to verify the migration is Security and compliance requirements represent minimised, and the cost/time for end-user re- another potential risk point in current OpenVMS training is eliminated. applications. As organisations institute company- An example of re-hosting would be recompiling wide security standards and IT governance an application written in (which might controls, OpenVMS applications often fall use DCL for the batch processes and a Record into a security and governance “silo.” While Management Services (RMS) ) into a usually secure within their own right, OpenVMS new Linux or Windows environment using an applications lack the ability to integrate into a Open Systems DCL to support the DCL broader security and control framework within a files and RMS data within an Open modern organisation. Systems system.

IT Strategy The viability of re-hosting depends not only upon Lastly, OpenVMS can no longer be considered having access to a native language in a strategic IT platform for an organisation. the new environment, but also a framework Companies are seeking to standardise their that supports the proprietary aspects of the data centers around virtualised hardware and OpenVMS world. In the above example, support software stacks that can be deployed rapidly for DCL and RMS in the Windows or Linux target at very low cost (“computing pods”), that are platform would be required. capable of being scaled up or down as IT capacity requirements change. OpenVMS applications Fortunately these Compatibility Frameworks are do not lend themselves to this strategy. As readily available in the market. They introduce organisations begin to deploy private and/ a component in the new 3 OpenVMS Application Migration & Modernisation

environment, but the reduction in overall migration A common re-architecting requirement is to cost more than pays for the licensing fees. transform the in the OpenVMS application to a more modern code In addition to the Compatibility Framework base. An example would be transforming Pascal accelerating the speed of a migration, most re- to , or Fortran to C#. There are commercial tools hosting solutions include tools to automate the available to automate this . However, adaptation of code and data often required for it should be noted that when moving from a use with the target compiler or operating system. procedural language (e.g. Fortran or COBOL) Continuing with the above example, in moving there are varying degrees of how much the VMS Fortran to an Open Systems Fortran, there conversion is able to achieve a true Object will likely be some differences in the syntax in use Oriented (OO) end state. Typically, the more compared to the syntax supported by the new a “pure” OO code base is desired, the less compiler. The proper re-hosting solution provides automated the conversion will be – increasing automated tools to adapt the code so that it will testing time and project costs. work with the new compiler. This speeds up the process and delivers predictable and consistent Hybrid solutions results compared to trying to perform this work Given the status of most OpenVMS applications, manually. In addition to the speed of migration, a many organisations adopt a hybrid approach: re- proven migration toolset decreases the cost and hosting components that can be easily supported risk by reducing the number of human resources in the new environment, and re-architecting and amount of testing required. aspects for which a re-hosting solution is not readily available, or where functional/technology Therefore re-hosting typically provides a faster, modernisation delivers added benefits to the lower cost and less risky option for OpenVMS business. application and data migrations. Rehosting is not moving to an emulated hardware solution. This Breaking down the problem approach typically uses a software/hardware emulation of VAX or Alpha sitting on top of either OS layer bare metal or Windows or Linux. In all cases it Linux or Windows? still uses OpenVMS as the operating system and Migrating OpenVMS applications can be seen therefore does not address the inherent reasons as an opportunity to move to the standard to move away from OpenVMS. infrastructure platform of the organisation. The Re-architecting options to move to Unix, Linux or Windows are Re-hosting is not always the best solution. In all available and technically viable. The choice of some instances the OpenVMS technologies which platform best suits the organisation may simply cannot be supported in the target be driven by your available internal skill sets environment. Or, it may be desirable to change and software standards, such as your preferred an underlying technology to a more modern end development environment and target database, state, or to add/change functionality. and, of course, cost.

There are varying levels of automation tools If applications are being re-hosted using a depending upon the re-architecting required. Compatibility Framework, then re-training of For example, when using DECforms, there is OpenVMS and operators can be not a re-hosting, no-change option for moving minimised by choosing to preserve some of the to Windows or Linux – so the the technical interfaces used in the OpenVMS user interface will need to be re-architected. If environment. the goal is to preserve the look and feel However, re-hosting should always provide a of DECforms, there are tools that will migrate native implementation in the target environment the forms and associated escape routines in a in order to benefit from the economic and relatively automated manner. However, if the goal governance advantages of system standardisation. is to convert DECforms to a browser or graphical client, this will require some amount of manual Data layer re-engineering. Migrating OpenVMS data provides an opportunity to move to the organisation’s standard database 4 | OpenVMS Application Migration & Modernisation technology. The desire may be to move the the I/O statements and the program logic will OpenVMS proprietary RMS data to a Relational remain unchanged. Database Management System (RDBMS). However, A potential shortcoming is that the data may be Compatibility Frameworks offer Open Systems difficult to access from other applications and native implementations of RMS, whether indexed industry standard query tools. However, there are or sequential files. Using a native indexed filing now ODBC and JDBC gateway products available system to replace RMS might be an attractive for migrated RMS data that provide relational alternative that reduces costs and minimises database querying and integration solutions. the need to add performance overhead when compared to moving the data to a RDBMS. The benefit of the second approach can be realised when integrating the migrated RMS application and data with other applications and RMS is probably the most common file moving all computing to a common database management system used on OpenVMS. It is an standard. Re-architecting RMS data to a RDBMS integral part of OpenVMS system software and its is entirely possible. The key issue is minimising procedures run in executive mode. RMS supports the amount of application code re-engineering the following four types of record level access: required to access the (as opposed to the indexed, record level RMS files). >> Sequential Access A comprehensive migration vendor toolset should >> Relative Record Number Access provide mechanisms for migrating RMS to a RDBMS and managing the impact this creates on >> Record File Address Access the application code.

>> Indexed Access Depending on the application’s programming language, vendor solutions may generate And, the following record types: intermediate I/O libraries that provide static >> Fixed length SQL calls and map data I/O back to a call level interface, replacing the RMS I/O statements in >> Variable length the programs. Other options are more like “black >> Variable record length with fixed length control box” solutions, providing optimised dynamic SQL blocks I/O and again mapping to calls replacing the RMS statements in the program. Lastly, programs can Stream files (records separated by termination be re-architected to use embedded SQL. This can characters) be a large undertaking, but will provide a “native” implementation which may be more sustainable >> STREAM: Records terminated by CRLF in the future. The embedded SQL option will also >> STREAM_CR: Records terminated by CR depend on the availability of SQL pre-compiler support for the application’s programming > STREAM_LF: Records terminated by LF > language. If the goal is to migrate RMS files along with the If the desire is to migrate RMS data to another application programs that use them, there are application’s database for archive purposes only, really only two viable migration options: and the impact on the associated application’s >> Move the RMS data to a Compatibility code is not a concern, there are data movement/ Framework that provides equivalent RMS file modernisation tools available to extract and load handler functionality in the target operating the RMS data into another database structure. environment. These tools may need access to application code or books in order to help determine the RMS >> Re-architect the data into a native relational data definitions for the extract. database such as Oracle or SQL .

The benefit of the first approach is that it maintains the RMS I/O statements in the migrated Oracle Rdb is a RDBMS specifically for OpenVMS. application, so there is no need to re-engineer Rdb was originally created by Digital Equipment

5 OpenVMS Application Migration & Modernisation

Company (DEC) in 1984 and was intended to be Obviously, if Oracle on OpenVMS is being used for data storage and retrieval by high-level used, then migrating to Oracle on a new target languages. In 1994, DEC sold the Rdb division platform will probably be the easiest migration to where it was rebranded option. This should not limit thinking, however; Oracle Rdb. It currently runs on OpenVMS for there is no reason why a migration to a different VAX, Alpha and HP Integrity Servers. target relational database that is currently being employed in an organisation cannot be While there is no corresponding version of Oracle accomplished. Rdb on Unix, Linux or Windows, the obvious target end state for an Rdb migration is another Automated tools for such database conversions relational database (e.g. Oracle or Microsoft SQL may be limited, but an experienced vendor should Server). While there are some changes needed to be able to understand the required conversion schema definitions, the conversion and migration and may be able to develop automated tools. are relatively straightforward given the right vendor tools. Application program layer

The majority of the Rdb SQL syntax is fully The overall OpenVMS modernisation/migration supported by other RDBMS without change. project – whether it involves re-hosting, re- However, there are a small number of changes to architecting, or a hybrid combination – is the SQL, including stored procedures, that will be primarily driven by the requirements of the required in order to get it to execute on the target application program layer. In particular, the driver RDBMS. Automated tools are valuable when is what programming language the applications making these changes, in order to save time/ are currently written in and what programming effort and ensure accuracy. language is desired as the end state for the future. There is a wide variety of mostly 3GL There are two ways to combine SQL with languages supported on OpenVMS, the most OpenVMS host language programs. You can common being: create a separate module for SQL language statements (SQLMODs) or you can enter them HP COBOL directly in the host language program and use HP COBOL is a common programming language a SQL precompiler. Changes will be required found on OpenVMS for business applications to these interface methods in the associated and is one of the easiest to re-host to Unix, Linux program code to use available on the target or Windows. There is a range of Open Systems platform. Rdb access commands can be different COBOL that provide a “landing site” from standard ANSI-embedded SQL statements for applications written in HP COBOL. However, and the existing code structures will require moving HP COBOL to an Open Systems COBOL adaptation in order to compile and function with involves more than simple recompiling, as there the new RDBMS. Vendor migration tools should will be differences in supported syntax and less help with this process. tolerance for non-compliant syntax. In addition, OpenVMS COBOL code will be Other and data sources dependent on facilities of the OpenVMS In addition to RMS and Rdb, there are other environment. Aspects such as file and screen databases in use on the OpenVMS operating I/O will be alien to a new compiler and any system (e.g. Oracle and ). There are also OpenVMS system service calls will not be natively proprietary legacy database systems (e.g. supported. These issues can be resolved with CODASYL DBMS and Adabas). The migration a Compatibility Framework that supports these options for these less common databases depend functions in the new operating system and very much on whether they are supported avoids changes to the application program code. in the target operating system environment. Alternatively, these intrinsic functions can be re- The process for migrating any proprietary, engineered to functions supported by the target hierarchical, or network structured databases to COBOL compiler. However, this re-engineering will a RDBMS is similar – but usually more complex – take longer, adding to the cost, and be more risky. than converting RMS to a relational structure.

6 | OpenVMS Application Migration & Modernisation

Whichever approach is decided upon, vendor tools This provides the benefit of re-architecting the can provide a high level of automation for the code application into a form that can be supported changes required for the new COBOL compiler. by more commonly available resources. These projects typically require extensive regression HP Fortran testing when compared to a re-hosting to the HP Fortran is used in a significant number of same programming language using an Open manufacturing, process control and banking Systems compiler. applications running on OpenVMS. There are Fortran compilers available on Unix, Linux and Whether re-hosting to a Fortran end state or Windows, so re-hosting to a Fortran end state is migrating to a new language, vendor tools can feasible. The migration process and requirements provide a high level of automation for any code are similar to migrating COBOL. changes required.

As with COBOL, adaptation of the code may be HP Pascal required to comply with the new compiler. A Unlike COBOL or Fortran, there is not the same Compatibility Framework will avoid the need to support for Pascal in modern operating systems, re-engineer programs for file and screen I/O, as so applications written in Pascal almost always well as other OpenVMS intrinsics. require transformation to another programming language. Conversions to C, C++, Microsoft C#, One option for migrating a Fortran code base and Java are all feasible. However, depending on is to convert it to a programming language the nature of your code base and the application that offers similar capabilities. Most Fortran functionality required, certain of these end state conversions target C or C++ as the end state. options make more technical sense than others.

Transformation Tools

REVIEW / REPLACE

DATA MIGRATION

APPLICATION LOGIC

OPERATION ENVIRONMENT

INTERFACES

PLATFORM

Advanced Compatibility Framework

7 OpenVMS Application Migration & Modernisation

Pascal provides better program structure controls Operation environment than many procedural coding environments, DCL but Pascal applications are not truly Object Digital Command Language (DCL) is used to Oriented (OO). Converting procedural code to OO control processes in the OpenVMS environment. languages usually requires a trade-off between The migration of DCL command files is similar to how pure an OO end state is desired versus the migrating application program code. There are speed and cost of conversion. In some cases, it is two choices available for the migration of DCL: just not realistic to use automated conversion and code generation tools to take a procedural 3GL >> Keep the DCL virtually as is and run it in an code base to a “true” OO end state. However, if Open Systems DCL “shell” provided by a there is a willingness to compromise, automated Compatibility Framework. conversion of Pascal to a modern programming >> Transform the DCL to a native Linux or language, particularly to C or C++, is quite feasible. Windows . HP Basic (Basic Plus, Basic Plus 2) In practice, most users choose to keep DCL and HP Basic is a reasonably common language in the run it in a vendor-provided shell on the target OpenVMS community. It is used in commercial, system. This has the merits of speed, low cost manufacturing and banking applications. Although and low risk – avoiding the need for significant there are Open Systems BASIC compilers and regression testing and re-training associated with interpreters, they do not offer a high degree transforming the code to native target script. of syntax compatibility with HP Basic. HP Basic Good DCL shells are capable of switching to native applications are therefore candidates for scripting languages as existing DCL modules are transformation to a more modern programming enhanced or modified. This allows the user to language. Specific tools are available to convert move to a native environment over time, rather Basic to C++, Microsoft C# and Java. There are also than in one major transformation. DCL shells general tools which can be tailored to convert HP are typically more concise than native scripting Basic to other target programming languages. solutions, while transforming DCL to native script Other OpenVMS programming languages will invariably result in generating multiple lines of In additional to the languages listed above, script code for each line of DCL code. OpenVMS supports other programming languages, such as Ada. In general, the same key User Interface (UI) layer factors discussed above will apply when assessing How the migration and modernisation of an the migration options for such languages. OpenVMS application’s UI is handled depends on the mechanism currently in use for developing The first consideration is whether there are and maintaining the screens and the tolerance for suitable compilers for the current language that, cost/risk involved in a migration. Generally, the with the help of a Compatibility Framework, options are: create a pathway to migrate with minimal changes to the code. The second consideration is how >> Maintain the existing UI through the use of a much ongoing maintenance and development Compatibility Framework. work will be required for the application in the future. If a considerable amount of development >> Transform the UI to an alternative technology is anticipated to keep the application current using automated tools. with business requirements, then transforming >> Re-architect the UI into a modern look and feel the application code to a modern development using modern technologies. environment is probably the best approach.

The more the application code is changed during FMS the migration process, the more regression HP FMS (Forms Management System) is a common testing will be required before “going live” UI development and management environment and increased risk will be introduced into the found on OpenVMS. Usually running on “green migration project. This applies even if automation screen” VT100 terminals or , FMS tools are being utilised during the re-hosting or provides an asynchronous character-based re-architecting process. interface for online OpenVMS applications.

8 | OpenVMS Application Migration & Modernisation

As well as providing an API to develop forms DECforms for a UI, FMS allows programmers to embed HP DECforms is a software product for the subroutines into forms for field validation and development and deployment of a forms- processing purposes. Compatibility Frameworks based UI for interactive applications running on can provide a means of preserving the FMS API OpenVMS. Not only does DECforms give the look in a Unix, Linux or Windows environment. This and feel of a forms interface, it also supplies a avoids re-engineering the UI components of robust set of dialog management and validation an application, reducing the time and cost of a functions to control the UI at application runtime. migration and the need to retrain users after the application is migrated. IFDL (Independent Form Description Language) is used to define the DECforms used by an SMG application. Most migrations transform IFDL SMG is an OpenVMS screen management . code into an alternative language with its own UI Like FMS it provides support for a character capabilities. For example, one common approach based VT user interface. SMG is similar to the is to transform the IFDL into COBOL routines that ncurses (new curses) library supported under provide a similar UI. This is a sensible approach flavors of UNIX. SMG provides the means to if the core application code is written in COBOL. manage screen I/O independent of terminal Alternatives exist to convert IFDL into other 3GL hardware. However, unlike FMS, SMG doesn’t use languages such as Fortran. a Form definition for the screen I/O and doesn’t Alternatively, DECforms can be transformed into provide a means of embedding logic into the a modern UI such as ASP, JSP or HTML. However, screen layout. the existing API may not always be preserved and Most OpenVMS migration frameworks on Unix changes to the application code may be required. offer an SMG emulation. Providing the same green This type of transformation will almost always screen character-based interface. Migrating SMG require some retraining of users. screens to Windows will require the use of a VT100 ACMS terminal and capability to ACMS is a transaction processing (TP) monitor that reproduce the green screen look and feel. runs on OpenVMS. It is intended for businesses Because SMG uses inline commands in the that require high performance, security, data application programs and doesn’t offer a layer integrity and both centralised and distributed of abstraction from the application programs, it processing. Providing similar TP capabilities is much harder to modernise SMG screens to a for migrated applications can be an important native (GUI). Any attempt issue for organisations using this product. While to do this will inevitably require significant ACMS provides several mechanisms for external restructuring and change to the application code. Windows and Unix applications to communicate However, some degree of a GUI can be provided back to it , there is no ACMS product that runs for SMG screens using screen scraping solutions. on Open Systems. Migrating an ACMS application requires replacement of its TP functionality

9 OpenVMS Application Migration & Modernisation

with another engine. Oracle’s has been Using automated tools to adapt the code commonly used to provide a TP environment for components to work with a new third party migrated ACMS applications. product will reduce risk and cost compared to making these changes manually. Another route is to re-architect the DECforms interface and re-engineer the TP to a client-server The need for third party utilities that have been or web architecture. This effectively removes the frequently used by programmers or operators need for a pure TP function and replaces it with may disappear due to capabilities found in the combination of application and database the new development or operating system functionality, or an application server to ensure environment. transaction integrity. Experienced OpenVMS migration consultants have Oracle Forms already built most of the “from-to” mapping for Oracle Forms represents the other significant UI the more commonly found third party products. technology found in OpenVMS. Because it is also Partnering with such a vendor at the planning found in other legacy application environments, stages in a project can save time and effort. there are several vendors who specialise in providing migration solutions for Oracle Forms OpenVMS clustering applications. These solutions, in conjunction with OpenVMS was one of the first operating systems specific OpenVMS application migration offerings to support clustered environments. Originally from specialised vendors, can provide a complete called VAXcluster, and now known as VMScluster, migration solution for OpenVMS Oracle Forms the capability was introduced in 1984. Clustering applications. was initially used to expand the scalability and load balancing of an application. As hardware Third party products performance improved, clustering today is used When considering a migration, it is important more to provide high availability and rollover to consider any third party products used in capabilities. conjunction with applications on OpenVMS. Third party products can be divided into two groups: 1) Many organisations still use VMScluster today. those that interact with applications at run-time This does not prevent migration to another (e.g. Attunity data access solutions) and 2) those platform and operating system. There are that provide operator and utilities clustering solutions for Linux, Unix and Windows (e.g. HP’s Datatrieve). The reason for making this environments (e.g. Red Hat Cluster Suite, VMWare distinction is that it is possible to employ different and Veritas Cluster Server). With improvements strategies based upon which group each product in computing power and virtualisation of servers, falls into. clustering for performance and load balancing purposes is less of a requirement, and clustering As a starting point, an inventory of all third in modern systems is mostly designed to improve party products should be created – categorising application availability. Products such as HP them according to how they are used, and then Serviceguard, Sun Cluster and Microsoft Cluster mapping them to target solutions that meet Server are good examples of high availability the organisation’s functional needs in the new clustering solutions. environment. Recognising why clustering is used with If a third party product is providing run-time OpenVMS applications helps to determine if functionality to an application (e.g. a sort utility), it will be required in the migration target end then the impact of changing the API when moving state. For example, if clustering is being done to an Open Systems replacement product should for performance purposes, it may make sense be considered. The simplest solution is to try to to design a non-clustered, virtualised server map to an Open Systems version of the same environment for the target end state. However, if product whenever this is an option. high availability is a critical requirement, then an add-on cluster support product may be ideal for use with the target operating system.

10 | OpenVMS Application Migration & Modernisation

Other interfaces Knowing the size of each component provides Another important consideration is the external metrics that are vital to accurately estimating interfaces supported in the OpenVMS environment. the scope and cost of the migration project. In There may be TCP/IP connections into the addition to knowing the quantities, understanding system, or external file transfer tasks providing the interactions and complexities also provides external data that are processed by the OpenVMS valuable scoping information. application. Similar interfaces to the application Application Understanding (AU) tools are available must be planned for in the target environment. to automate a large portion of this phase of the Where possible, the new interfaces should avoid the project. The best migration solution vendors offer need to modify the external applications in order to these AU tools as part of their solution set. work with the migrated application. Once the application component inventory is in Significant overhead can be added if customers place, work can begin on analysing the source or business partners also need to revise their code to discover any potential migration issues. applications due to changing interfaces after a AU discovery tools frequently automate this migration. process as well.

Mitigating risk Planning So far, this paper has focused on the specifics With a complete picture of the application set of migrating each component making up an that will be migrated, the next step is to plan OpenVMS application set: the core of the the migration process. The key in this phase is migration project. However, there are other major to ensure that the migration addresses every factors in a migration – discovery, planning and aspect of the application. Planning the migration testing – which are critical to success. completely is the single most important aspect for risk mitigation. Discovery Discovery is a critical step in any successful Testing migration in that it determines the composition, Testing is also critical. Most migrations require size and complexity of the current OpenVMS some modification to code and data structures. environment. Making an inventory of application In re-architecting projects, entire code bases can components creates a template upon which be transformed into new languages. Therefore, migration solutions can be applied to each piece. every migration should include the classic testing

Migration Project Pyramid Test Plan

11 OpenVMS Application Migration & Modernisation

methods: regression testing, systems testing, 70% higher than modern application platforms. user acceptance testing and, in some cases, Labor costs are typically higher as skilled resources parallel testing. become increasingly scarce. The cost of application maintenance and development is higher when the The application migration testing pyramid costs of building interoperability with other systems approach and the lack of economies of scale compared to A testing plan should be created based on the modern platforms are factored in. With higher strategy being adopted. If using a Compatibility costs and higher risks, migrating and modernising Framework and automated migration tools, which OpenVMS applications should dramatically lower preserve much of the logic flow of the application, the TCO associated with their functionality. it should be possible to create a “pyramid testing” plan. This recognises that the migration is not the Avoiding catastrophes same as a pure development project. Most, if not all, IT organisations have special disaster recovery provisions for their OpenVMS Thanks to the predictable outcome of automated environment. As hardware platforms cease to tools, pyramid testing validates the migration be supported, surviving catastrophic hardware process rather than testing each program that failures will become increasingly more difficult is migrated (i.e. if the migration works for a and expensive to address. After the stockpile representative subset of programs, it can be of spare parts for Alpha and Integrity platforms assumed that it works for all programs). Pyramid has dwindled, the next step may be shopping for testing still requires a reasonably comprehensive parts on eBay or similar sources. Clearly, this is approach, but prioritises groups into different an unacceptable level of operational risk for most levels based on program criticality. organisations.

Delivering benefits Sustainability for the future OpenVMS migration and modernisation projects The outcome of a well-planned and executed have great potential to deliver benefits to a migration and modernisation initiative is to move business while future-proofing applications – OpenVMS applications to a maintainable, low avoiding the need to undertake migrations again at risk, and low cost end state that is viable for the a later date. In general, the benefits can be seen as: future. A well executed plan may have multiple steps that meet short-term migration needs but Lowering the Total Cost of Ownership (TCO) also deliver long-term benefits. While it may not be obvious on the surface, the reality is the TCO of OpenVMS applications is 50-

12 | Optional Series Title OpenVMS Application Migration & Modernisation

Application modernisation is a “team sport” Just as no two companies are identical, the Most IT organisations have limited experience options, challenges, and requirements of with complex legacy application migration undertaking a migration and modernisation and modernisations. Few organisations have project demand a customised solution that spare resources with specialised skills sitting leverages an organisation’s existing resources while around who can dedicate themselves to such optimising both technical and business results. a project and still keep up with day-to-day If there is only one key takeaway from this responsibilities. Rarely are the specialised tools discussion, it should be that migrations are and methodologies to deliver a highly automated complex. They are most successful in their migration available in-house. For these reasons, deployment when a methodical, fact-based most organisations seek specialist vendors to approach is utilised to assess the functional assist – and sometimes to take full responsibility – value and technical complexity of the current for delivering a successful project. OpenVMS environment to arrive at the right It would be simplistic to think that the vendor is strategic direction for the organisation. only providing software tools and technology. Specialised tools are available to automate large Migration and modernisation projects are portions of this assessment and experienced complex. A successful vendor must demonstrate migration vendors exist to assist in planning and that is has a proven and repeatable methodology executing the project. The result will be a project – in addition to the right skills, sufficient resources that avoids major operational risks and delivers and specialised technologies to ensure success. business benefits with a considerable return on investment. In Summary The goal of this paper was to look at the available options for migrating and modernising applications currently running in the OpenVMS environment – and to highlight the benefits that can be achieved through modernisation. Factors in deciding upon the right course of action were discussed, and certain details regarding the migration of specific components were highlighted.

More information w oneadvanced.com/us t 770 933 1965 e [email protected]

3200 Windy Hill Road, Suite 230 West, Atlanta, GA 30339

OneAdvanced, Inc. is a wholly owned subsidiary of Advanced Computer Software Group Limited. Advanced recognises the trademarks of other companies and their respective products in this document.