OpenVMS vs. Unix

"Unix on DEC hardware" built the Internet.

popular hardware from DEC (Digital Equipment Corporation)

comment: some form of UNIX ran on every one of these technologies (much to the chagrin of Ken Olsen). Linux was ported to both Alpha and Itanium

Software technologies that led to the Internet.

Internet Traffic Map for 1995

Internet Diagrams (to see the dominance of PDP hardware)

Other Links

Internet Reality Check (then and now)

 VMS vs. Unix Comparison Table

  VMS (Unix's younger brother) Unix (VMS's older brother)
historical
overview
  1. VMS was first released 1977-10-25 for the 32-bit VAX-11/780 manufactured by Digital Equipment Corporation a.k.a. DEC (VAX-11 meant PDP-11 compatibility)
  2. Rewritten in 1992 for the 64-bit Alpha AXP manufactured by Digital Equipment Corporation then renamed OpenVMS
  3. DEC was purchased by Compaq in 1998.
  4. As of 2001, Compaq still supports OpenVMS on both VAX and Alpha hardware platforms but no new VAX hardware was manufactured after 2000-09-30.
  5. On 2001-06-25 Compaq announced they will port OpenVMS to Intel's Itanium (IA64) processor.
  6. Compaq merged with HP on 2002-09-03 but will still be called HP
  7. On 2003-01-31 OpenVMS engineering achieved "first boot" on Itanium (their definition of this phrase requires boot up, log in, enter a DCL directory command, receive the correct response without a crash)
  8. OpenVMS: Timeline
  9. On 2015-06-31 HP announced they were outsourcing OpenVMS to VSI (VMS Software Inc.) who committed to supporting OpenVMS on future Itaniums as well as a port to x86-64
  1. First written using "PDP assembler" in 1969 by AT&T's Bell Labs for the 18-bit PDP-7 and 16-bit PDP-11 minicomputers (both manufactured by Digital Equipment Corporation)
  2. Rewritten using "C" in 1972 ("C" originally was, and still is, a language built for portability. This is the main reason why Unix is usually the first OS ported to any new computer hardware architecture)
  3. Only ran on DEC machines for the first 8 years of its existence (so contrary to popular myth, the DEC community didn't hate Unix; although DEC founder Ken Olsen did as well as VMS developer Dave Cutler)
  4. Ported to Interdata 8/32 and IBM 360 in 1977
  5. Ported to VAX in 1978 (mostly by Bill Joy)
  6. TCP/IP added to VAX Unix in 1980
  7. Since Unix was free to Universities, this OS was probably responsible for a large number of PDP + VAX sales.
  8. Unix: Timeline
name
  1. Name means Virtual Memory System
    Seems suspiciously similar to MVS (Multiple Virtual Storage) from IBM
  1. Named because it was initially meant to be a single (uni = one) user version of the Multics operating system
  2. It wouldn't be a single user OS for very long
online
help
  1. Extensive understandable on-line help in English. Other languages include: Thai, Hanzi (Chinese), Hanyu (Chinese), Hangul (Korean)
  2. Hebrew is supported in certain layered products like Motif and All-In-One.
    Note: there may be more languages I don't know about.
  1. On-line help (in the form of "man" pages) are difficult to understand even if English is your first language and you're a techie
popularity much less popular than Unix because...
 
  1. of high license fees by DEC (many industry professionals commented that DEC's choice of '$' for the standard DCL prompt was not an accident)
    • license fees improved when Compaq purchased DEC but OpenVMS marketing by Compaq was almost non-existent. However, Compaq did see fit to allow the start up of the OpenVMS hobbyist group as well as loosen up the OpenVMS Educational Program
    • marketing has improved since HP took over Compaq. In 2003, HP claimed the OpenVMS business was growing 10-12% per year.
  2. initially DEC (Ken Olsen) refused to put TCP/IP on OpenVMS (this was first done by 3rd party vendors like SRI, TGV, Wollongong, and Process Software). DEC engineers had ported TCP/IP libraries from BSD into ULTRIX calling it UCX (Unix Communications eXtensions). After Compaq purchased DEC, UCX morphed into a product called "TCPIP Services for OpenVMS". Process Software now is the provider of two OpenVMS stacks, TCPware and MultiNet.
very popular because...
 
  1. AT&T licensed it to universities for free (or almost free if you were outside the USA) which introduced a whole generation of future IT workers to it
  2. Universities had access to the source code which was used to teach computer system design to engineering students
  3. Universities, working with DARPA, developed TCP/IP networking for it which is the basis of today's Internet
  4. Universities, like Berkeley, modified it and then re-licensed it to corporations for tiny fees because schools are for learning, not profit. Berkeley's main contributions were: "socket programming", "TCP/IP Networking", and "BSD" (Berkeley Standard Distribution)
  5. In the case of free Unix today, companies make money by selling support agreements with Unix installations
  6. During the breakup of the Bell System (1982-1984), AT&T tried to regain control of Unix then announced their intention to charge universities for access to the source code. This triggered a lot of forking which (ultimately) led to the marriage of GNU (everything rewritten except the kernel) and Linux (the kernel). The duo are now being continually improved by the brightest minds in the world.
built-in
text
editing
  1. EDT
    (command: $edit/edt)
  2. EVE (Extensible VMS Editor) has no width limit
    (command: $edit/tpu)
  3. TECO
    (command: $edit/teco)
  1. ed
    (very primitive line editor at the same level as TECO which was first used by DEC on early PDP machines)
  2. vi
    (a video screen version of 'ed')
  3. vim
    (vi improved)
  4. xedit
    available from x-windows, CDE, KDE (Linux), or Gnome
  5. nano
  6. pico
files
  1. Can have multiple (up to 32k) versions of the same file name (which makes possible the easy introduction of new program executables without a reboot)
  2. Directories are kept sorted (good for directory searches but adds overhead to file creation/deletion)
  3. Built-in RMS (Record Management System) provides native support for stream (non-record), sequential, relative and indexed files. (Indexed files can contain up to 255 keys but you rarely encounter more than 4)
  4. Advanced lock queuing via the "Distributed Lock Manager" (works across clusters) ensures every process gets access to shared resources without spin locking
  1. Directories easily span storage devices (or host machines with NFS)
  2. No built in support for relative or indexed files
  3. No advanced lock management (access to shared resources is usually by spin locking)
  4. MFS (memory file system) allows a fully functional file system to exist in memory. Very cool.
  5. AdvFS (advanced file system) is only currently available on Tru64 but should appear on HP-UX by 2004 (oops, this port was cancelled)
command
interpreters /
command
shells
  1. DCL (Digital Control Language) which is a command line/batch interface with a name that is suspiciously similar to IBM's JCL (Job Control Language)
More than 20 shells which drop into 4 flavors:
  1. Bourne Shell
  2. C Shell
  3. Korn Shell
  4. BASH (Bourne Again Shell) which is very popular on Linux systems
Command
Shell
Syntax
Observations
  1. DCL's philosophy assumes the user is tired, hasn't had enough coffee, and is making mistakes. Every command is "syntax checked" and the whole line is bounced if a single error is detected. (this is humble and much more desirable, especially in a business environment where data losses cannot be tolerated)
  2. command line options are prefixed with a forward slash ("/") like so
    $edit /tpu
  3. A <space> is considered command punctuation while a <comma> is considered a list separator.

Examples:

  1. Suppose you want to delete all files with an extension of "junk" but you accidentally enter (notice the space between the asterisk and the period)
    $ del * .junk;*

    This command will return a syntax error and immediately stop.

  2. Suppose you want to delete all files with an extension of "junk" or "log", and you want interactive confirmation on every delete, and you want to log your actions
    $ del/confirm/log *.junk;*,*.log;*

    Note: a semi-colon is the version specifier so ";*" means all versions

  3. Suppose you wish to delete all multiple versions of a file with the extension of ".log" but you wish to keep the 3 most recent versions
    $ purge/log/keep=3 *.log

    This command will allow you to execute the same command recursively into the current directory including subdirectories
    $ purge/log/keep=3 [...]*.log

  1. Unix shells assume the user is not tired and intends everything that is typed. (this is very dangerous but is also very fast)
  2. command line options are prefixed by one or two dashes.
    • Two dashes ("--"): always represents a single word-based switch
    • One dash ("-"): usually represents one or more single letter switches
      • the "-exec" switch associated with "find" is one of many exceptions
      • the "-march" switch associated with "gcc" is another
    Examples:
        this bad command "tar -help" sends four switches to tar
        is good command "tar --help" sends one switch to tar
  3. A <space> is considered a list separator

Example:

  1. Suppose you want to delete all files with an extension of "junk" but you accidentally enter the following command (notice the space between the asterisk and the period)
    # rm * .junk
    This command will first delete all files then (jumping to the next item in the list) will delete all files named ".junk". If you happened to insert a "-r" switch after the "rm" command, all the directories under your current position will be recursively deleted. If you were in the root directory, you could wipe your whole disk!
batch
processing
  1. An extensive batch processing engine is built in (supported by DCL)
  2. DCL scripts can be run interactively or submitted to a batch queue
  3. By default, batch queues are visible to everyone on the system (great for system management)
  1. Crude batch processing via the CRON interface
  2. You need access to the CRONTAB of specific users in order to view/debug queuing parameters (bad for system management)
  3. OpenVMS style batch processing support is available from 3rd party vendors (this is changing for Tru64)
spooled
devices
  1. Adding spooled devices (like printers) is almost child's play
  2. By default, print queues are visible to everyone on the system (great for system management)
  1. Adding spooled devices is very difficult without GUI tools
variables /
logical
names
  1. Variables (DCL symbols) can be declared as global or local. Global symbols allow a process to share data with their respective sub-processes
  2. "logical names" come in four flavors: process, job, group, system, cluster. A system level logical name can be used like a system-wide variable to share information between unrelated programs and a reboot isn't required to make changes take effect
  1. Exported variables allow shells to share information with their sub-shells
  2. To the best of my knowledge, no "logical name" concept exists anywhere in the Unix world
system
tuning
  1. System parameters are changed via the SYSGEN tool
  2. The system gathers running statistics and saves them in a feedback file to be used by the sys$update:AUTOGEN tool
 (more information coming)
resource
management
  1. All OpenVMS processes (system and user) are forced to engage in quota-based resource management. A process may want to spawn forever or request use of the whole page-file but will not be allowed to do so.
  1. While it is true that Unix didn't have quota-based resource management for quite some time, this feature began to appear in the mid to late 1990s
run
levels
only two levels
 
  1. limited boot (via conversational boot)
    then dropping into SYSBOOT to set SYSGEN parameter STARTUP_P1 = "MIN"
    then typing CONTINUE
  2. full boot:
    the starting system executes DCL script:
        sys$manager:SYSTARTUP_VMS.COM
Five-Six commonly used Unix levels:

0 = firmware
1 = single user
2 = multi-user (no networking)
3 = multi-user with networking
4 = see "man init" for info on your Unix
5 = multi-user with graphics
6 = see "man init" for info on your Unix
S = see "man init" for info on your Unix

For example, when the system is at level 1 the administrator enters "init 2" or "init 3" to open the system to other users.

startup
scripts
  1. sys$manager:SYSTARTUP_VMS.COM
various startup (S) scripts in "level directories"
e.g. executing "init 3" would access scripts in directory "rc3.d"
shutdown
scripts
  1. sys$manager:SYSHUTDWN.COM
various shutdown (K) scripts in "level directories"
e.g. executing "init 0" would access scripts in directory "rc0.d" before jumping to firmware level
future will only become more popular if...
 
  1. HP drops the price. Remember that Open Source operating systems like Linux are acquired for free. (For example, check out products like: Gentoo, Debian, and CentOS to only name three of many)
  2. The marketplace realizes that the price of Alpha and Itanium hardware has already dropped significantly compared to VAX
  3. OpenVMS is ported to other processor platforms like Intel's x86-64 family.
    This is not as ridiculous as you would first think. Both AMD and Intel have added 64-bit extensions to IA-32 which industry insiders refer to as x86-64 (a.k.a. AMD64, Intel 64, EM64T)
     

bastions of hardcore OpenVMS popularity:

  1. Semiconductor Manufacturing
  2. Medical (HMOs etc.)
  3. Military
  4. Intelligence Community (NSA etc.)
  5. Telephony
  6. Nuclear
  7. Banking Industry
  8. Investment, Securities, and Clearing
  9. Lottery
  10. Automobile/Automotive Parts Manufacturing
  11. Steel and Aluminum Production
  12. Chemical Industry
  13. Pulp, Paper, Packaging and Forest Products Industry
  14. Glass Industry
  15. Pharmaceuticals
  16. Textile Industry

Click here for more details.

already is popular in various flavors... 
  1.  OSF/1 was a clean version of UNIX produced (initially) by seven companies under a collaboration known as the Open Software Foundation. The big three included IBM, DEC and HP
  2. AIX (derived from OSF/1) by IBM
  3. Tru64 (derived from OSF/1) by DEC. Compaq, HP
    • for some reason we'll never understand, DEC kept changing the name of this product which served to confuse the marketplace. See this list
    • Starts off as Digital OSF/1 for MIPS
    • Alpha versions included:
      • Digital OSF/1 version 3.x
      • Digital Unix version 4.x (a.k.a. DUNIX)
      • Tru64 Unix version 5.x
    • In 1998, DEC was purchased by Compaq and is now called the "Digital Equipment Corporation" division of Compaq
    • In 2002, Compaq merged with HP were HP-UX was king. HP did little to market Tru64 so stopped development and marketing of it in 2004
  4. HP-UX by Hewlett-Packard (HP)
  5. ULTRIX (by Digital Equipment Corporation a.k.a. DEC) is officially unsupported as of 1999.12.31. This OS ran on MIPS based processors manufactured by DEC.
  6. Linux is available free of charge under GPL (general public license) and is distributed and supported by companies like Red Hat and SUSE just to name two of many. See linux.org and distrowatch.com for more info
    Note: contrary to popular belief, there is no actual operating system named Linux. Linux is really just a different Unix kernel with BSD (or GNU) applications tacked on. Read this 'extreme tech' article for more info.
  7. Solaris and SunOS by Sun Microsystems
    • Oracle purchased Sun in 2009-2010
  8. BSD (Berkley Standard Distribution)
  9. SCO Unix by the Santa Cruz Operation
  10. QNX by QSSL (co-founded by Gordon Bell and Dan Dodge of Ottawa)
    • this is not the Gordon Bell of VAX/VMS fame)
    • on April 2010, Blackberry maker RIM announced the purchase of the QNX product line
  11. BeOS by Be Inc (which they claim isn't based on Unix but was only influenced by it. However, It supports grep, awk, Bash shell, etc. and is free)
  12. Mac OS X by Apple
miscellaneous
info
  1. Easier to cluster OpenVMS machines; easier to load balance them (they've been doing it since the early 1980's using the LAT protocol)
    During a 2003-06-xx seminar I witnessed a demonstration where OpenVMS was running in a three-way cluster composed of different hardware architectures (VAX, Alpha, Itanium)
  2. Multiple instances of OpenVMS operating systems can run together on the same hardware platform in something known as a galaxy configuration. Different operating system versions are allowed which means that systems may be upgraded with more rigorous testing.
  3. The POSIX interface in OpenVMS allows Unix programs to run with little, or no, modification. One popular example of this is CSWS (a.k.a. Compaq Secure Web Server, a.k.a. Apache web server)
  4. Many programs written in "C" for Unix can run on OpenVMS with little more work than a simple recompile and link. This is due to the HP OpenVMS Unix Portability Initiative
    This allows valuable products from groups like www.apache.org and www.isc.org to make their way effortlessly into the OpenVMS community.
  1. Most Unix clusters only use a failover strategy (so one node is usually doing nothing but waiting). However, Tru64 incorporates TruCluster technology which was derived from OpenVMS. All nodes in the cluster participate in load sharing based upon their individual system capabilities (smaller hosts would participate less)
  2. Contrary to popular belief, there is no actual operating system named Unix. Unix is a generic name which means that "Unix style operating systems" appear to have many similarities. They also have many differences. One cool variation is GNU which is a method to get around Unix copyright problems.
  3. Contrary to popular belief, there is no actual operating system named Linux. This OS is really just a different kernel merged with BSD (or GNU) applications tacked on.
    https://www.extremetech.com/computing/52018-the-bsds-sophisticated-powerful-and-mostly-free
  4. SCO does not own Unix but they do own the source code for the AT&T flavor of Unix. Click www.opengroup.org for more details.

 Performance Comparison

Although I've never seen a benchmark comparing OpenVMS to any flavor of Unix, I perceive that the Unix machines, in general, are somewhat faster doing certain tasks. But a recent IEEE article by retired Intel chip designer Bob Caldwell explains why faster isn't always best. He explains that many times the fastest things in the world are also fragile. Take thoroughbred race horses for instance, their muscles are strong enough and the bones are thin enough to do just one thing; win a short race. They're also high strung, succumb to higher rates of disease, and have a shorter useful life. From my perspective Unix systems are fast and fragile like thoroughbreds while OpenVMS systems seem more like a dependable Clydesdale.

On the flip side, Unix has no built-in support for relative or indexed file types (see RMS in the "file systems" line above). This means that to do any decent record storage you've only got three options:

  1. design a proprietary indexed record system in the computer language of your choice
  2. install a 3rd party indexed record system (like C-ISAM, Berkeley DB, ICOBOL, etc.)
  3. install a 3rd party database like Oracle ($$$) or MySQL (free) or MariaDB (free)

Also, it is my experience that many Unix systems need to be rebooted at least once a month just to recover from memory leaks (although this has changed for the better since 2004). On the other hand, I have personally seen many OpenVMS system stay up for years and we only knocked them down when dealing with environmental concerns like moving an associated electrical panel. 

Side Bar:
When I was a younger, I was only concerned with speed and performance. For example, it seemed to make sense to compile UCSD Pascal with many "run-time checks" disabled just to reduce a program's flat-out execution time by a few seconds. (The generation of programmers after me made similar arguments with languages like C and C++)

Now that I'm a little older and hopefully wiser, I can see that my previous view of computing was somewhat reckless. I now know that my younger vision was similar to that of an Indy-500 racer (very high speeds; many crashes; many break downs) while my current view is closed to that of a Chevy (reliable; fuel-efficient; safer).

That said, my Alpha Server DS20e is so fast that I can write safer software in VMS-BASIC and VMS-C, but still can have it run full tilt on a break-neck hardware platform.

 Computer Déjà Vu

I attended my first official VMS course ("VMS Commands and Procedures") in 1987 at Digital Equipment Corporation in Toronto, Ontario. We were using VMS 4.2 at that time and I was really impressed with how easy it was to create and manage batch queues, print queues, and do tape and disk backups. On the last day our instructor gave us a little sales pitch about continuing development efforts in clustering, volume shadowing, etc. which were going to appear in VMS 5.0 which left us impressed.

Ten years later in 1997, I had my first official DUNIX course ("Digital Unix System Admin") at Global Knowledge in Ottawa, Ontario, and to my surprise, the place was filled with ex-instructors from DECs training facility in Kanata. Most of the students in our class were contented OpenVMS administrators whose companies were moving to DUNIX. I remember students asking questions like "when will OpenVMS feature so-and-so be available in DUNIX?" and the instructor would always respond with "That feature is expected in DUNIX 5.x". At that time it occurred to me that DUNIX 4.x was probably equivalent to VMS 4.x (with a ten year gap between them) and the engineers at Digital were putting their VMS "know how" into DUNIX.

Since then, DUNIX version 4.x was improved then released as Tru64 version 5.x and, DEC was purchased by Compaq. I've played with many Unix flavors but Tru64 is the best I've seen to date. The Advanced File System (AdvFs) and the Logical Storage Manager (LSM) are two features that I hadn't seen on any other flavor of Unix.

 VMS and Unix Learn From Each Other

Future:

Local Links

 External Links

ARPA has a network of Supercomputers
(text from picture above)
ARPA has a network of Supercomputers
There are two dozen huge computer systems in the Advanced Research Projects Agency network. Over half of them are DECsystem-10s. Our Supercomputer. MIT has two. So does Utah. Then there's Harvard, BBN, Carnegie, Case, SRI, Stanford and Rand. Which should give you some idea of how popular our DECsystem-10 really is. In the ARPA network, DEC-system-10's are doing state-of-the-art research into global climate dynamics, econometric studies, resource management, computer sciences, and much more. Everyone shares their computer and expertise with everyone else. Everyone comes out ahead. Additional DECsystem-10's will be part of ARPA's mammoth ILLIAC IV number crunching complex now being installed at NASA Ames Research Centre in California. They'll handle all communications while at the same time managing up to a trillion bits of file storage. Once ILLIAC IV is in gear, ARPA members will be able to do in hours jobs so big that they wouldn't even attempt to do them now.   ARPA is one of the biggest brain trusts ever assembled. If half of its members have a DECsystem-10, you really ought to know about it. Write for the literature that explains why 62 of the leading universities and research institutions in the country have selected DECsystem-10's. (Hint: It does computation and timesharing at half the cost of other systems -- without sacrificing throughput) DECsystem-10 Education Group. Digital Equipment Corporation, 146 Main St., Maynard, Mass. 01754. (617) 897-5111.
 

Back to Home
Neil Rieck
Waterloo, Ontario, Canada.