One of the first minicomputer systems that I worked with extensively was a Digital Equipment Corporation’s VAX machine. The particular machine that I used, a VAX 11/730, was at the time (1983) an entry-level minicomputer that cost just under $40,000 (that’s just the CPU!) and delivered real-world performance of about 0.15 MIPS.

As a note of comparison, the flagship VAX of the time, the VAX 11/780, delivered about 0.5 MIPS for a little over $180,000. (VAX system benchmarking number are frequently stated in VAX Units of Performance [VUPS], which is a measure of the system’s speed relative to the original 11/780; the 11/730 was about 0.33 VUPS compared to the 11/780’s 1.0 VUPS. Thanks to Brian Foley for providing this clarification.)

At the time I first began using it, the 11/730 was running the VMS 3.3 operating system. VMS (“Virtual Memory System”) was a multi-user timesharing system of extraordinary sophistication for the time.Dave Cutler, the operating system’s designer, went on to Microsoft some years later to design Windows NT (and subsequent NT-derived operating systems). The first version of VMS, version 1.0, had shipped in 1978, so the operating system wasn’t new at the time. The operating system was ported to the Alpha architecture in 1992. Compaq, a computer company that didn’t exist until about 25 years after Digital was founded, purchased DEC in 1998. Compaq and HP merged in 2002. Though VAX hardware isn’t sold anymore, OpenVMS is still supported. Amazingly enough, there’s even development work going on: HP has announced that OpenVMS for Intel’s 64-bit Itanium architecture will be commercially available in 2004!

In any case, I’m not the only person with an interest in this historic hardware. A simulator called SIMH, maintained by Bob Supnik (who had a pivotal role in the original development of a number of Digital’s machines, serving at one time as technical director for the Alpha and VAX groups at DEC), emulates a wide range of old hardware. The VAX architecture is one of the many represented.

HP makes OpenVMS available for non-commercial use through its Hobbyist License program. In order to participate in this program, you must:

• Join Encompass US (or the appropriate user group for your country). There’s a free membership available that will permit you to participate in the OpenVMS hobbyist license program, and some paid membership categories with additional benefits. It’s interesting to note that this is a long-lived user group; the original Digital Equipment Corporation Users Society (DECUS) was formed in 1961! You’ll receive a membership number by email (a process that takes several days based on my experience).
• Get a media kit. I ordered the OpenVMS VAX Hobbyist Kit 3.0 from Montagar Software and had it about a week later. This kit includes OpenVMS 7.3, the most recent (as of this writing) release for the VAX architecture.
• Get software licenses for OpenVMS and the layered products using the license registration page. You’ll be asked for a hardware serial number at one point in the process; since this really isn’t applicable to SIMH, just enter the word NONE. You’ll receive license registration information by email. Note that you have to register separately for the base operating system and the “layered products” that run on top of it. The license keys expire after a year, but you can simply request a new license at the appropriate time to extend the life of the system.

Once you have these items, you can get OpenVMS running atop a Linux platform fairly easily. Note that a dedicated platform is recommended for serious emulation, as the design of this (and most other) emulators ensures that the CPU will be busy essentially 100% of the time. Windows users should also be able to use most of these procedures, making appropriate file naming modifications here and there (you’ll also need to install the winpcap drivers to get Ethernet working). Here’s how I did it on a Linux box running a stock Debian 3.0 release.

But First, a Disclaimer, a Plea for Help, and a Few Acknowledgements…

I’ve been successful in making these procedures work in my environment. I hope you’re able to duplicate my success, but make no guarantees.

I’d note that it’s been over fifteen years since I used a VAX on a daily basis. There are plenty of things that I’ve forgotten in that time, and most likely even more things that I never knew. If anyone spots errors in this documentation or has suggestions for better ways to do things, I’d love to hear from you.

Since writing this document, I’ve gotten helpful feedback from a number of readers; for the most part, the changes they suggested are acknowledged within the text. I’d particularly like to thank Dave Hittner, of the SIMH Ethernet project, for an extensive and helpful set of suggestions that have been incorporated at numerous points within this document. While it wasn’t practical to acknowledge each change individually, please know that his efforts have significantly improved the quality of this documentation.

Download and Build the Emulator

First, download a copy of SIMH. The version I used for this documentation is version 2.10-4. Find a location for this software (I used /home/software) and make a directory for it.

Next, unpack the software. Be careful; unlike most Unix tarballs, this .zip file expands in the context of the current directory rather than creating a named subdirectory underneath. So, be sure you’re currently in the location where the software should be unpacked; otherwise, if you’re not careful, you can wind up with a mess.

Now, build the VAX portion of the emulator. The build process puts things in a directory called BIN, and will fail if it doesn’t already exist. In order to use Ethernet support, you also need to includeUSE_NETWORK in the build command, as follows:

At this point, you’ve got the basic VAX emulator constructed. The application and its data need a home; I chose /usr/local/vax/bin and /usr/local/vax/data.

At this point, copy the VAX emulator binary into its new location:

The processor boot ROM (from the KA655 processor found in a MicroVAX 3900) is included with the SIMH package. Copy this into the data directory.

In addition to the boot ROM, you’ll need a couple of other files to get started. The file cd.iso contains an image of the OpenVMS Hobbyist CD-ROM. Create this using dd or your favorite ISO image extraction application. If you’re using the dd command under Linux, the following command should create the required image (presuming your CD-ROM is named /dev/cdrom; substitute a different name if needed):

In addition, you’ll need an initialization file to set up the emulator unless you like typing the commands yourself. The commands below assume that these two files reside in a directory called/home/software/simh-data.

The contents of vax.ini should initially be as follows. Edit file paths as appropriate, of course.

The emulator looks in its startup directory for the initialization file by default. I don’t like having binaries and data in the same place, so I added a symbolic link:

Install the OpenVMS Operating System

At this point, the emulator can be started! You do need to do this as superuser (root), since the Ethernet emulation depends on it. More on this detail later.

At this point, boot from the virtual CD-ROM, entering the date and time when asked.

At this point, you’re running a small “standalone” operating system that’s used for backing up and restoring data. Use the command that follows to restore the VMS “save set” from CD-ROM to the first hard disk.

At this point, VMS has been copied to your virtual hard disk. Since you have no more save sets to restore at this time, stop the simulation by pressing control-E. Then reboot the virtual machine to continue the installation process.

Once again, the virtual VAX boots:

At this point, we’ll be booting from the DUA0 device in the future, so we’ll set up the default boot device. If this isn’t done, the system attempts to boot from device XQA0, which isn’t the behavior we’re after. The boot command that follows tells the system to boot from the default device we just set. Installation proceeds from this point; my answers to the installation questions are highlighted below.

At this point, it’s time to register a license key for VMS. Refer to the email you received in response to your license request to obtain the information that’s entered below.

Then exit the license management tool by using option 99 on the menu. You’ll be prompted for information about your time zone next; enter the data requested.

Following that, the system will do some autoconfiguration and will then shut down. The messages tell you that the system will automatically reboot, but this isn’t the case due to the way the simulator and virtual CPU are currently configured.

At this point, the virtual CPU is halted and the simulator is back in control. For now, tell it to boot once again (we’ll set the system up for automatic boot later). You’ll get a whole bunch of messages in response as the final phase of the system installation/initial boot runs.

Configuring OpenVMS

Congratulations! You’re ready to log in for the first time.

Bask in the glow of the long-lost DCL “$ ” prompt for a moment. Some Unix shells may also use the dollar-sign prompt, but it’s just really not the same.

On with configuration: let’s initialize two additional disks. These disks, like the virtual DUA0, are configured as RA92 disks in the vax.ini file that the simulator uses. It’s possible, of course, to use other disk types or to use only the system disk if you’d rather.

Since you’ll want to do this every time the system boots, you should put these commands in the sys$manager:systartup_vms.com site-specific startup file. Those familiar with VMS editors know that there are many shortcuts (search capabilities, the ability to scroll by pages, etc.) that can save time in the editing process. Explanation of those capabilities is far beyond the scope of this document, however; you should be able to stumble your way through editing files using this basic process:

Scroll down within the file until you find a place to insert these MOUNT commands, then edit the file appropriately. Use Control-Z to save and exit.

Now, let’s add a user to the system. Here’s how I added myself. Several notes on this:

• I’m putting user directories on the DUA1 disk. If you’re not, make appropriate changes.
• Every VMS user has to have an octal group and user code (known together as the user identification code, or UIC). I’ve used 200 for the group and 201 for the user code. UICs (the pairs) should be unique.
• User accounts are initially disabled, so it’s necessary to indicate that the account should be unlocked with /flag=nodisuser.
• This user has full system privileges, though they’re not on by default. Omit the /priv=all section if you just want a normal user.

This will generate a couple of security audit alarms (you’re receiving these because you’re currently logged in at the system’s console). Then exit the user authorization facility application and create the user’s directory. Once you’re done with that, log out of the SYSTEM account.

Now log back in with your newly-created identity. From here, we’ll install TCP/IP.

TCP/IP requires more system resources than are available by default, so we need to edit a file called modparams.dat in order to reserve the appropriate resources.

Add these lines to the file:

Once this is done, we use the AUTOGEN facility to update the system:

Once again, use the simulator to restart the virtual machine.

Once the machine restarts, log in again. There’s one more parameter to be updated; another reboot will be required.

(For the more-experienced: yes, it is possible to do both AUTOGEN and SYSGEN with only one reboot cycle. I thought it better not to combine the processes for the sake of clarity and generality.)

Note: If you intend to run DECNET Phase IV at some point, you’ll also want to set the SCSSYSTEMID parameter by multiplying the DECNET area number by 1024, then adding the DECNET node number. So, to prepare to be node number 3 in DECNET area 2, multiply the area number (2) by 1024, add the node number (3), to get 2051. The command SET SYSSYSTEMID 2051 within the SYSGEN session above would be required to support DECNET. If you’re not familiar with DECNET, or have no immediate plans to run it, you may safely ignore this step.

Installing TCP/IP

Boot the machine once again, then log in again; we’ll install TCP/IP from here.

The /over=id qualifier on the mount command tells the operating system to ignore the volume label. This is really important if you don’t know the label for the CD-ROM already. It’s inconsistent with the/SYSTEM qualifier, however, so the CD-ROM will be visible only to you and will be dismounted automatically when you log out.

Change directories to the TCP/IP installation kit.

Before installing, register and activate the license. The UCX license from your layered product email will give you what you need. Note the use of the hyphen command-line continuation characters here.

Now, launch the installer.

Now, configure TCP/IP…

The most basic options are under option 1: core environment. These are the familiar TCP/IP configuration values; alter as appropriate for your network.

It’s worth a little digression at this point to talk about how the Ethernet adapter for the VAX is emulated in SIMH. Experts will notice some significant oversimplification in this section; if you’re one of those folks, I hope you’ll agree that the simplifications don’t distort the underlying message much.

Under normal circumstances, an Ethernet card sends data to the operating system on which it’s running when it receives packets destined for its particular MAC (media access control) address. This is a hardware identifier that’s supposed to be unique to each Ethernet card, so you usually don’t have to worry about it. It also sends data to the operating system when it receives packets destined for the special MAC address FF-FF-FF-FF-FF-FF (the “broadcast” address). It ignores everything else. This keeps load on the system reasonable, since it can ignore packets on the network that don’t concern it.

In order to sort out what packets should go to the VAX emulation, and which packets should go to the emulator machine on which it runs, it’s necessary to have the Ethernet card respond to a second MAC address in addition to its native address. Some cards can be given a list of addresses, but it’s certainly not universal. So, the SIMH simulator puts the network adapter in the colorfully-named promiscuous mode, in which the Ethernet card sends every packet it sees on to the host operating system and its application (in this case Linux and SIMH). The operating system reacts to the packets destined for the hardware MAC address on the Ethernet card, as always. But the SIMH application also gets the packets, and it can choose to react to any of them. Since it’s looking for an alternate MAC address, the server on which the emulator runs and the VAX emulator itself appear to be completely separate.

There are three consequences to this approach, however:

• The emulator must be run as root. For security reasons, Linux won’t permit just any application to put the Ethernet adapter in promiscuous mode, as it allows snooping on network traffic to and from the Linux machine in addition to the traffic of any other machine on the same Ethernet segment. The security risk posed by this fact isn’t huge, but it is real. To take advantage of this fact, an attacker would have to be able to cause the emulator to malfunction in a way that gives it undesired access to the underlying Linux machine. Since this would generally involve simultaneous successful attacks on both the emulated machine (the VAX) and the Linux server on which it runs, it’s unlikely. But the risk isn’t zero, either; the cautious (or paranoid) administrator will likely run the VAX emulation on its own dedicated machine.
• CPU and/or interrupt loading on the Linux server may become a problem if the Ethernet is very busy. This is because every packet received by the Ethernet card must be examined by the operating system, rather than only those packets bearing the adapter’s MAC address or the broadcast address. This is often much less of a big deal that it would appear, however, since the emulator machine is frequently connected to an Ethernet switch. The Ethernet switch will pass through packets destined for either the broadcast address or any of the MAC addresses to which the connected Ethernet adapter responds. The net effect is that all traffic not needed by the server or the emulation running on it is filtered out, just as would be the case if the Ethernet were not in promiscuous mode. For users running their servers connected to a hub rather than a switch, however, this may pose a performance problem.
• It’s likely you’ll have problems getting the emulator and the environment in which it runs (say, Linux) to communicate with each other on the same machine. The reason for this is simple: the Ethernet card sends a packet out onto the network under one MAC address looking for a MAC address that’s actually also served by the same card. By design, Ethernet cards don’t receive their own traffic, so the result is that the packet disappears, well, into the ether. If this is a problem, the simplest solution is to put a second Ethernet card into the machine and dedicate it to SIMH; communication between the emulator and its host environment will then take place via the network just as if the emulator were running on a physically separate machine.

Once the core environment is configured, configure client and server components. I recommend enabling FTP and TELNET services as both client and server applications. Configuring the clients for these applications will also enable the servers, as the listing below indicates.

Once finished, you can proceed to start up the TCP/IP service.

At this point, it should be possible to telnet to the VAX. At some point, you’ll want to edit the command @sys$startup:tcpip$startup into the sys$manager:systartup_vms.com startup command file.

Other Tasks

I also recommend decompressing the system libraries for performance reasons. Use the command:

to accomplish this.

Installing languages is fairly straightforward. Several popular languages (C, Pascal, FORTRAN, and Basic) are included on the Hobbyist CD. License keys should have been emailed to you (same email containing the UCX key for TCP/IP). I’d recommend installing the licenses first based on instructions in the email. Remember that licenses have to be installed, then loaded (if they’re just installed, they won’t be active until the next boot). The installation process for each language is quite similar; here’s an example of the command used to install the C compiler, assuming the CD is mounted on the drive DUA3:

FORTRAN would be installed with:

Pascal installs with:

…and Basic installs with the command:

Additional Linux Integration Tasks

Once the OpenVMS operating system is installed and configured, there are a few other things that can be done with the SIMH installation to streamline operations. Here’s a copy of the vax.ini file that I use operationally:

The beginning of this file is identical to the vax.ini that we used during the configuration of OpenVMS. Some changes have been made near the end, however. Let’s examine these in detail.

First, the line:

is used to deposit the value 0 in the BDR register. This register contains the boot jumper/switch flag used by the VAX console ROM code. If bit 7 is high (i.e. if we’d instead said “dep bdr 80”), the ROM will print the VAX console prompt (>>>) instead of autobooting. For those who remember the VAX 11/7xx series machines, setting BDR to 0 is the equivalent of setting the key switch to the DISABLE position; setting BDR to 80 [hex] is like turning the key switch to its ENABLE position. As an alternative, Dave Hittner points out that the VAX console command “set halt n” will allow this value to be set from within the VAX console environment, and that this is the standard way of accomplishing this in a non-emulated environment. Some research on the Internet suggests that the “set halt 2” command will enable auto-boot and “set halt 3” will disable it.

The line:

is related. It controls what happens on a CPU halt event. Control can go either to the VAX console ROM (which will then either display a console prompt or reboot depending on the value in BDR, described above), or to the simulator’s command mode.

The combination of the BDR and the console halt mode settings above will cause the automatic reboot mode to work correctly.

As it turns out, the simulator still gets control in this configuration when the VAX CPU is commanded to shut down but not reboot. That said, let’s examine the final two command lines in the file:

; Now start the emulator
boot cpu
;
; Exit the simulator
exit

The “boot cpu” command is fairly obvious; it causes the VAX to start up (and, in the case of this command file, autoboot).

The “exit” command that follows will be executed when the simulation halts for some reason; this is most likely the result of a non-reboot shutdown. The important thing here, though, is that it causes the SIMH VAX emulator process to exit.

This seems kind of pointless until one thinks about running the VAX emulator unattended. Consider this shell script:

The file /usr/local/bin/vax_enabled is a symbolic link to either /bin/true or /bin/false. If it’s a symlink to /bin/true, then the script will loop forever. One can cause the VAX process to stop gracefully, however, by first linking /usr/local/bin/vax_enabled to /bin/false, then shutting down the VAX without automatic restart. When control passes back to the simulator, it’ll exit (because of the “exit” command in its initialization script) and will not be restarted.

There’s one other subtlety to be found in this file. Note that input, output, and error output are redirected to /dev/tty8. On a typical Linux machine, this is an unused virtual console that can be accessed with the Alt-F8 keysequence (or Control-Alt-F8 if X is running). The significance of this is substantial: since the virtual machine now has a source of input and output, it can be run unattended (from, say, a machine startup shell script). Console I/O remains possible, however, from the physical console of the Linux machine.

After the original publication of this article, Stan Quayle wrote and suggested that the screen utility is a much more flexible choice than redirecting the input and output to/from /dev/tty8. The command:

will start up the VAX emulator with a 2000-line scrollback buffer, but detached from any physical terminal. To connect to this virtualized console, the command

may be used. Type Control-A, followed by D in order to disconnect. The shell script approach may still be helpful in cases where you’d like to re-invoke the VAX automatically after a crash/shutdown; if you choose to do this, don’t redirect I/O to/from /dev/tty8; you can then invoke this script using screen (substitute the script’s name in place of /usr/local/vax/bin/vax in the screen startup command above).

Final Words

The VAX/VMS environment remains an interesting one; I hope that being able to work in an old, familiar environment once again brings back a few good memories. A couple of final observations:

• This project really serves as an impressive reminder of the progress that’s been made in computing hardware in the last couple of decades. The computer on which I’m running the emulator would cost no more than $350 if purchased new, and it vastly outperforms the half-million-dollar machines of twenty years ago, even when handicapped by the fact that it’s running old software atop an emulation platform. This is an impressive and humbling feat.
• It’s similarly impressive to see the longevity and flexibility of well-designed, well-engineered software. I’m not sure that the field of computer science has been particularly well-served by recent practice in commercial software development, in which software has become a primary rather than an ancillary product. Since software has become a commodity to be bought and sold (rather than an enabler for hardware products), long-lasting design has become nearly antithetical to the ongoing revenue stream desired by software marketeers.
• Sharing and collaboration made this endeavor possible. The emulator and the server environment (Linux) on which I’m running it were both made possible by the community-mindedness of their creators. HP/Compaq/DEC deserve special credit for making the operating system available at no charge to the hobbyist community, as well; I think it took a real understanding of the historical importance of VMS (and no small amount of courage) to do this.

And, in closing, one more request for feedback: if you find errors, have suggestions, or desire clarification on this document, please don’t hesitate to get in touch with me. Similarly, if you find these directions helpful, I’d love to hear how you’re using the tools.