Planning for OpenVMS x86-64

It has been five years since VMS Software, Inc. (VSI) announced that it was in the process of porting OpenVMS to Intel's x86-64 processors. The fruits of this effort will be soon available. Initially there will be an Early Adopters Kit (EAK) referred to as Version 9.1. The production-quality release will be Version 9.2. Now is the appropriate time for ISVs, OEMs, and end-users to give thought to the process of porting and qualifying their software and applications on OpenVMS x86-64.

Those operating in an OpenVMScluster environment should note that OpenVMSclusters including OpenVMS x86-64 nodes must have all members running a VSI version of OpenVMS, preferably 8.4-2, on the other Alpha and IA-64 nodes. Thus, if one is currently running one or more OpenVMSclusters, it is worth planning the upgrade to 8.4-2 as soon as possible.

It is important to note that the native data formats for IA-64 and x86-64 are identical (IEEE floating point), so data format problems are unlikely. Those converting from Alpha, who have not yet converted to IEEE floating point will need to exercise caution when comparing results. For this reason, I have generally recommended that users switch from VAX floating point formats to IEEE floating point formats, as appropriate, on their existing Alpha before porting to IA-64 or x86-64.

Code written in MACRO-32, C/C++, BASIC, FORTRAN, COBOL, and other compiled higher-level languages may include both conditional compilation sections that are architecture-dependent and executable code which checks architecture/CPU-type. Both need to be modified to provide the correct alternatives for x86-64. At the same time, it is advisable to include an error alternative in the event the architecture identifier/CPU-type does not match an expected value. Doing this future-proofs the codebase. When compiling/running on a future, as yet unspecified architecture, code should produce an error, rather than fail silently. This is also the time to separate processor type from data type. If code relies on processor type, check processor type. If the dependency is on floating point format, conditionalize it on the floating point format. This type of modification was discussed in my 2006 HP Technology Forum presentation Strategies for Migration from Alpha and VAX to HP Integrity (slides at http://www.rlgsc.com/hptechnologyforum/2006/1504.html). The whitepaper corresponding to the that presentation was published in Volume 10 of the OpenVMS Technical Journal.

Locally-developed DCL scripts, should be audited for architecture-dependent code of any form. This can take the form of conditional branches based upon an architecture identifier retrieved in DCL using the F$GETSYI lexical function or RTL equivalent.

Checking that your locally-developed application is working correctly is an ongoing issue. For this reason, before starting any effort at porting, it is good practice to develop automated tests which process a wide variety of data through your application, producing files which can be compared digitally. Such testing scripts are an important tool in ongoing verification of functionality. Including realistic performance-benchmarking scripts and datasets is another aspect of the testing process. Such tests are crucial when maintaining a multi-architecture application. Each change should be automatically checked using such test after each modification on each architecture.

In today's capital-sensitive environment, over-provisioning is a serious and costly error. The widespread use of server farms, with and without virtual machines, creates new alternatives. Moving to OpenVMS x86-64 means a number of changes in compilers, toolsets, as well as hardware, networking, and storage. Extrapolating from present Alpha and IA-64 configurations is not possible.

OpenVMS x86-64 running in a virtual machine environment does offer some advantages in the migration process. Running an virtual OpenVMS x86-64 instance using VirtualBox, KVM, or other VSI-approved virtual machine on a laptop or desktop is inexpensive. Such a virtualized instance on a low-performance laptop or desktop does not have the I/O bandwidth of a real server configuration for benchmarking; yet it is quite adequate as a proof-of-concept for editing, compiling, and testing code. Such a virtual instance can also be a member of an LAN-based OpenVMScluster, which would permit access to data and source files on an existing OpenVMScluster.

A multi-stage strategy of prototype, benchmark, and production is a low-risk approach. When OpenVMS x86-64 becomes available in a form which is usable in your environment, with the necessary compilers, tools, and other required elements, create a small test instance using a supported virtual machine on a laptop or desktop system. A system provisioned on a server farm may also be suitable, but the standalone workstation (mobile or desktop) is generally a simpler case. The goal of this initial instance is providing an environment to verify that the applications software required can be used on OpenVMS x86-64. This includes compiling, linking, and running tests on packaged and locally-developed software.

The next stage is to create a server-based OpenVMS x86-64 instance, using either dedicated hardware or provisioned computing and storage assets from the server farm. By contrast with the first instance, this configuration is for running performance benchmarks. The results of these performance benchmarks will allow the development of provisioning requirements for a full production configuration, whether using dedicated or server farm assets. Also, since most Alpha and all IA-64 systems are on dedicated hardware, systems running on server farm virtualized CPUs and storage may behave differently.

Of course, these three stages are not necessarily totally separate. In a large or complex environment, different aspects of the workload may be in different stages at any given instant, as described in the previously mentioned Technical Journal article. In this regard, mixed-architecture OpenVMSclusters are a great benefit, as they allow workload to be migrated to the new architecture while maintaining interoperability and access to shared data. Configuring worker (non-voting) members of the OpenVMScluster can aid in this process, as well as providing a mechanism to add processing power as needed.

Migrating to OpenVMS x86-64 can be accomplished with little or no disruption and low risk when good management practices are followed.

References

R. Gezelter (2006) Strategies for Migration from Alpha and VAX to HP Integrity OpenVMS Technical Journal, Volume 10. Preprint at http://www.rlgsc.com/publications/vmstechjournal/migrationstrategies.pdf
R. Gezelter (“”, Strategies for Migration from Alpha and VAX to HP Integrity Slides at http://www.rlgsc.com/hptechnologyforum/2006/1504.html

URLs for referencing this entry

Long:	http://www.rlgsc.com/blog/openvms-consultant/planning-for-openvms-x86-64.html
Short:	http://rlgsc.com/r/20200130.html