The Roles of OpenVMS

When Digital designed VAX/VMS in the 1970s, its goal was to create a 32-bit operating system for the new hardware line, the VAX. From the start, it was designed so that many people could use a single VAX/VMS computer at once. The techniques used to accomplish this goal naturally led to a system that could perform a variety of tasks: The system must keep track of many separate, but overlapping, computations and manage access to finite resources in a way transparent to the users. The system had to delay computations momentarily when certain resources were unavailable, such as while waiting for certain memory contents or access to a disk drive. The system had to delay and resume computations in such a way that a programmer did not have to worry about the details of shared access or scheduling while writing a program.

These inherent abilities make OpenVMS suitable for a wide variety of tasks. It can be used as a personal system, a multiuser timesharing system, a batch engine, a network server, or a network client, and it can serve several of these uses at the same time.

Out of this development effort came an operating system with outstanding reliability, despite the complexities involved. It is not unusual for OpenVMS systems to run continuously for months or years, shutting down only because of prolonged power failures or scheduled upgrades. Combined with Open VMS's flexibility, this reliability naturally translates into a system well suited to environments that cannot tolerate system failures. OpenVMS is used extensively by hospitals and other medical facilities, by major stock exchanges and banks around the world, by one of the very largest Internet search engines, and by many Fortune 500 companies for which downtime would mean the loss of hundreds of thousands, or perhaps millions, of dollars per hour. In short, OpenVMS is used extensively where system reliability is crucial.

Users of the OpenVMS operating system enjoy a feature many other systems claim, but few deliver: scalability. The high end of the OpenVMS performance line currently includes systems with multiple CPUs, several gigabytes of physical memory, and terabytes of disk capacity. On the other end of the spectrum are systems the size of two telephone directories stacked atop one another. OpenVMS can effectively manage the resources of a wide variety of machines, which in the next couple of years will certainly include even more impressive hardware models, both large and small.

The following sections highlight some of the various roles OpenVMS currently performs around the world.

As a Desktop System

OpenVMS first appeared on physically large computers, at least by today's standards. In 1977, a computer system 5 feet tall and almost 15 feet long qualified as a "minicomputer." The largest OpenVMS systems today are of roughly comparable physical size, but, of course, they vastly outperform the early VAX machines, while consuming far less electricity and generating far less heat. However, most modern OpenVMS systems are much smaller, many being desktop systems suitable for personal use.

OpenVMS will run successfully (but without much elbow room) on a modest system with 8MB of memory and less than 500MB of disk space. ^[1] Most popular "personal computer" operating systems can no longer come close to this accomplishment.

Today, there are a variety of desktop OpenVMS systems, some with impressive graphics capabilities, disk capacity, and CPU performance.

Later versions of OpenVMS use the Common Desktop Environment (CDE) graphical interface, the same interface found on several other operating systems, including many versions of UNIX. This means that many users who have never used OpenVMS before will nevertheless find a familiar interface, easing their learning experience.

Desktop systems can use all the features of OpenVMS; there is no "client" or "server" version. A desktop system can act as an interactive system, a network client, a network file server, a Web server, a mail server, and a batch engine, all at the same time. The only practical differences between the desktop OpenVMS system and large corporate systems are speed and storage capacity.

A desktop system might also be used as a personal system by one user, while simultaneously serving as a multiuser interactive system for other users.

New OpenVMS systems have traditionally been either too large or too expensive for home users, but for about the past decade, systems small enough to be used in a private home or office have been available on the used market.

A decade ago, this meant a MicroVAX II or VAXstation 2000 system. Today, perhaps it's an AlphaStation or MicroVAX 3000 series system. There is also at least one software-based VAX emulator that runs on Windows PCs. A few years from now, used (or even new) Intel Itanium–based machines should be available at prices affordable for home users.

For the past few years the OpenVMS hobbyist program has been available. Individuals may acquire free software licenses for OpenVMS and several third-party programs. The hobbyist kit contains several programming languages, including C and Java, DECnet and TCP/IP networking, and DCOM, to name only some of its contents. The hobbyist program is available to members of Encompass, a large users group counting many OpenVMS users among its members. Encompass also provides its membership with access to a library of software contributed over the years by other members. (See Appendix B, "Additional Resources.")

As a result, more and more private individuals are able to afford their own OpenVMS systems with which to experiment at will.

As a Multiuser System

Acting as a multiuser interactive system was one of the original purposes of the VAX and OpenVMS. Originally, text terminals connected each user to the system. Today, the concept of a text terminal has expanded to include network terminals, such as Telnet sessions. The ability to act as an X Window System server was added later, allowing other users on the network to run GUI applications on a remote OpenVMS system, while displaying their output on local client systems.

Several users may log into and use an OpenVMS system at the same time. This introduces a number of complicated issues related to the sharing of computer resources. OpenVMS has features that arbitrate access to the CPU(s), disks, files, shared memory, private memory, and other system resources.

As a multiuser system, OpenVMS provides comprehensive support for file and object ownership, protection, and access. Access methods may range from exclusive access by one user to shared write access by many users, with accesses coordinated across the entire cluster, if applicable. (See "As a Clustered System," which follows.)

OpenVMS includes a 32-bit (VAX) or 64-bit (Alpha and Itanium) virtual memory management system that supports both paging and swapping. This means that the system can divide its memory into small units called pages and allocate them to users depending on their needs. When there is insufficient physical memory to meet demands, some memory contents can be automatically moved to disk, freeing memory. The process of moving things in and out of memory occurs automatically, with no need for users or even programmers to be concerned with the details.

In addition to pageable virtual memory, OpenVMS includes both paged and nonpaged dynamic memory pools. Uses of the pools range from transient storage for I/O requests to semi permanent data structures describing disks and other devices.

OpenVMS uses the process as its basic unit of scheduling, and threads are supported. You may think of each simultaneous user as a separate process. Each process has its own memory, which cannot be directly accessed from another process. In addition, some memory is shared among all processes—the area in which OpenVMS and system-wide data reside on the running system. This means that each user process has separate memory, but things that are shared (e.g., OpenVMS itself) need not be duplicated for each user.

Note 

explanations for the terms used in the preceding paragraphs may be found in Part 2, "A Technical Introduction."

As a Clustered System

Joining computer systems together to form clusters became a popular trend in the computer industry several years ago. Several operating systems now have some type of clustering capability, but OpenVMS started the trend with Digital introducing VAXcluster systems in the mid-1980s. ^[2] Most other clustering strategies have directly resulted from study and imitation of the OpenVMS clustering technology.

Clustering is a technology for coupling separate computers together to form, in some ways, a single computing entity. This is a technique for increasing total computing capacity, while avoiding some of the problems with using totally separate computers.

A cluster is more tightly integrated than a traditional network, but not as tightly as a single computer with multiple CPUs. For example, OpenVMS clusters can allow users to share disks and files among all nodes (cluster systems) with record-level granularity, but they cannot yet migrate a process from one node to another. All systems in a cluster can use a shared copy of the User Authorization database, so that any authorized user can log into any node in the cluster.

Clustered systems can share disks, whether the disk is connected directly to one computer or to a dedicated storage controller. For most purposes, a user may log into any node in the cluster and never see any differences compared with any other node. If so configured by the system manager, the user environment looks exactly the same: All of the user's programs and data are there, and all of the same printers are available no matter which node is used. On the other hand, the system manager may decide to assign different responsibilities to different nodes and elect to have certain programs or devices available only on selected nodes.

Since clustered systems can share devices, such as disks and printers, different nodes in a cluster can help one another execute work more quickly. For example, a user may submit a batch job (or a print job) to a generic, clusterwide queue. Whichever node in the cluster has the necessary resources available can assume responsibility for that job. The user may not know or care which node actually performs the work.

As a Network Server

Network servers can take many forms: a file server offering file, disk, and printer services; a company wide mail hub; an Internet Web server; an FTP site; or a system offering other network services. OpenVMS includes two kinds of networking: DECnet, a proprietary networking product originally developed by Digital, and TCP/IP, the networking scheme of the Internet. Third-party implementations of TCP/IP networking are also available for OpenVMS. Using one or both of these network types, OpenVMS systems can offer all of the network services mentioned above and more (many TCP/IP functions have roughly equivalent DECnet counterparts.) These services include file services; disk services; NFS and FTP for file access and transfer; DNS for Internet name resolution; SMTP, POP3, and IMAP for remote e-mail delivery; Telnet for remote access; SSH, SCP, and other related components for secure access; LPD for network printer access; and many more.

As an added benefit, OpenVMS has some fundamental differences from other systems that make it much less vulnerable to popular "buffer overflow" network attacks. Even if the OpenVMS system is using the very same network software as the other systems, the OpenVMS design catches the underlying problem and prevents many common attacks from working as intended.

As a Back-End System

Back-end systems have much in common with some types of network servers. They sit alone in a closet or computer room, often with no interactive users logged in, their only task to answer requests from other computers. Perhaps a company sets up a large database system residing on an OpenVMS system in a central computer room. Each user of the database has a personal computer on his or her desk running a front-end application. This application serves as the user interface, through which the user examines and modifies the database. User requests for database access are passed from the front-end personal computers to the back-end OpenVMS system, which manages the database.

There are many possible advantages of such a two-tiered approach. The personal computers do not have to hold large portions of the database. This allows smaller disk and memory requirements for the front-end machines, lowering cost. In addition, the OpenVMS server can concentrate all its resources on managing the database, relieved of the need to manage a graphical interface for each user. Each user can enjoy the quick response of a local, dedicated machine that also runs other office applications along side the database software.

OpenVMS runs both TCP/IP and DECnet, comes with a file system designed for access by multiple parties, can be clustered, and comes with a distributed resource lock manager. These aspects make it suitable for use with the multitiered approach just described.

Summary

The outstanding design of OpenVMS includes features suitable to any or all of the roles described above. In many ways, OpenVMS was a more advanced system 20 years ago than many cutting-edge operating systems are today. Rather than remaining static, OpenVMS has continued to improve for the past two decades, incorporating features that make it an excellent choice for the most sophisticated modern applications.

^[1]The early versions of VAX/VMS ran just fine on systems with 0.25MB of memory and 1 MIPS of CPU performance, often serving dozens of users, multiple disk and tape drives, and several printers simultaneously.

^[2]One hardware vendor had previously marketed a "clustered" system, but the technology does not satisfy the modern definition of a "cluster."