Why OpenVMS?

I have been asked Why choose OpenVMS?

It is a question worth asking. While the precise answer depends upon the context, the overall answer is:

OpenVMS provides a robust platform and framework for constructing and operating software.

The benefits of OpenVMS accrue throughout the system lifecycle; not merely during development. Testing, production, enhancement, and other phases of the system lifecycle all benefit. Costs and risks are reduced over the system lifetime.

This is an important business issue, not a mere technical nicety. A well structured OpenVMS system evolves far more smoothly than one on other platforms. This is manifest when clusters maintain continuous application availability over decades while both hardware and software evolve. Cluster availability can persist across CPU upgrades, CPU architecture changes, system updates, and changes in storage, networks, and individual applications. Users can remain completely unaware that any transitions have occurred.

This defies the conventional wisdom that all operating systems are the same: that what is true for Windows® and Unix®-derived operating systems must be true for all operating systems. It has become fashionable to assert that operating systems do not matter; that we are in a post-operating system world. Often this is accompanied by a comment that Frameworks and virtual machines are what matters. This is disingenuous.

All three terms are poorly-defined; there is substantial overlap between them. Thus, the combined statements say little. Framework is a relatively recent coinage; even Wikipedia only has citations to the 1990's. Virtual machine has been used since the early 1960's; but to label it as outside an operating system is to engage in classification gamesmanship.

Frameworks are important. However, stating that OpenVMS does not have frameworks is incorrect. Base OpenVMS includes what others would call several independent, mutually reinforcing frameworks, but does not label them as such. This should come as no surprise. The term framework was not in general use when VAX/VMS was originally architected in 1977.

OpenVMS integral frameworks include logical names, input-output, and lock management. Each covers a different aspect of the programming environment. Those frameworks that complement each other are orthogonal, yet are carefully integrated into a whole. Unlike other operating systems, OpenVMS uses common inner components across outer interfaces, a feature that other systems do not use.

The frameworks mentioned earlier are complementary. They intersect, but do not overlap. They are generally independent of each other. Underlying all of these are the Asynchronous System Trap (AST) mechanisms and security/protection components that are themselves classifiable as frameworks, yet are more fundamental elements of OpenVMS. Indeed, ASTs date even further back, and are a basic mechanism for extending the underlying API, a feature deemed crucial for a framework.

These frameworks make the true power of OpenVMS architecture implicitly available to ordinary application programs. The majority of applications have no need for awareness of clusters beyond the implicit guarantees provided by cluster-wide locking. While locks may be managed directly, they are most frequently used implicitly as an underlying technology by Record Management Services, referred to by its acronym, RMS.

OpenVMS demonstrates that fundamental interfaces need not be totally encapsulated by outer interfaces. AST generation and security are directly accessible to programs, as they are used by other OpenVMS facilities. These fundamental interfaces are directly visible, as well as being accessible through the RMS, input/output, lock management, and timer services.

The concept of a virtual machine was put forward by IBM's Cambridge Research Laboratory in response to a request from the then Advanced Research Projects Agency, known by its acronym ARPA for implementing a computing utility. The system that became MULTICS (an intellectual progenitor of OpenVMS) was the competing proposal from a team at the Massachusetts Institute of Technology.

When ARPA funded the MIT proposal, IBM decided to pursue its virtual machine concept internally, eventually giving rise to VM/370.

OpenVMS continues the user virtualization concept. Virtual machines are a different, complementary architectural concept. Used in combination, user virtualization combined with virtual machines opens up new opportunities for agile and efficient IT operations, an approach included in my recent presentation Evolving OpenVMS Environments: An Exercise in Continuous Computing. However, expounding on that point is a digression that I will reserve for a future installment.

This non-overlapping intersection between virtualized hardware and virtualized environments has very pragmatic implications. For example, a client was recently faced with an apparent hardware failure in an aged disk array. A straightforward solution was possible due to the inherent device independent nature of OpenVMS input/output in the user-virtualization context.

The problem was resolved by creating a logical disk on another storage device commensurate in size with the failed disk array. I then created a logical name to redirect all references to the failed disk array to the newly created logical disk. The application was then back on-stream.

If I had wanted to, I could have defined the logical name for a single group, user, process, or application as described in Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters which was published in the February 2004 OpenVMS Technical Journal.

This is a very high level perspective. Admittedly, there is a wealth of finer detail in the overall picture, but the finer detail does not detract from the basic facts.

Seen in this context, the lower costs of OpenVMS documented in Total Cost of Ownership for Entry-Level and Mid-Range Clusters (available through the HP OpenVMS www site at http://h71000.www7.hp.com/openvms/whitepapers/tco_clusters/TCO_WP_Feb04.pdf) are not a fluke, but a straightforward consequence of a logical, well thought out architecture.

OEMs and ISVs must ship products to large numbers of customer sites, including medium to large-scale enterprise, with multitudes of systems. The same is true of corporate IT departments, who must often function as captive ISVs or OEMs. As a result, operational costs quickly become the majority of overall IT expenditures.

The easiest way to reduce costs is to reduce operational complexity. The user-environment virtualization provided by OpenVMS, together with the underlying frameworks inherent to OpenVMS provides a foundation that reduces complexity. This reduction in complexity preempts many potential problems. The fastest response to a problem is to prevent the problem from ever occurring. To paraphrase an old movie, If the phone ever rings, we have failed.

I am also able to take comfort that a properly designed system can scale, from a small desktop supporting a single user to an enterprise-class environment supporting hundreds or thousands of users, with no changes to the application. OpenVMS uniquely offers this unparalleled seamless application scalability fro a single user desktop to an enterprise environment with thousands of users, each with their own performance, operational, and security requirements.

Unlike virtual machines, each instance of which must be managed separately, and OpenVMS cluster can be managed as a single entity, with a significant savings in costs.

Whether you are a developer or an end user, the economics, flexibility, and reliability of OpenVMS are impressive.

Windows® is a trademark of Microsoft Corporation
Unix® is a trademark of The Open Group

URLs for referencing this entry

Long:	http://www.rlgsc.com/blog/openvms-consultant/why-openvms.html
Short:	http://rlgsc.com/r/20091103.html