The OpenVMS operating system is the current version of the VMS system
originally developed in the late 1970's by Digital Equipment Corporation for
the VAX line of minicomputers.  Digital (or DEC) was eventually bought by
Compaq computer corporation, which then merged with Hewlett Packard, which
maintains OpenVMS for VAX, Alpha, and Intel ia64 based computers.

OpenVMS shares many common characteristics with Unix, but was designed with
a very different philosophy and retains a highly distinctive flavor.  Many
Unix users do not like VMS, and the converse is also true.  However, VMS is
very reliable and maintains a strong presence in financial and other
transaction processing environments, or any environment that demands high
availability with next to no downtime and scalable systems.

More information on it can be found at:

http://h71000.www7.hp.com/
http://www.openvms.org/

31 responses total.

Heh, count me as one of the many "Unix users [who] do not like VMS."  
During the 1980s and much of the 1990s the instructional mainframe at my 
university ran VMS, alas, so I was forced to deal with it.

There were a few things to like, I suppose. It had a pretty decent full 
screen text editor.  The file versioning was useful.  But I always felt 
that the command line interface (DCL) was setting up barriers rather 
than being a facilitator like the Unix shell.  Ugly, ugly syntax, for 
one thing.  And the plethora of file types interfered with communication 
between applications.

I've had nothing to do with VMS since my university finally dumped it in 
the late 1990s, so I don't know how it's evolved since then.  Does 
OpenVMS at least have a better command line interface than DCL?

No. "OpenVMS" is just "VMS with a POSIX compliant subsystem." On the gripping
hand, you can now have files with a filename of more than 39 characters, in
Unicode, nested further than eight directories. However, these features are
only available on ODS-5 volumes (system volumes, and all hard disk volumes
on systems without ODS-5 support, are still ODS-2. ODS-3 and -4 are reserved
for CD-ROMS)

For the interested, there is a public-access cluster with an analogue to the
grex "bbs" program available called the "Death Row VMS cluster". More
information is available at http://deathrow.vistech.net

Whoa; what's with the VMessy message you get on leaving "bbs"?

I thought it added a little bit of flavor.

Regarding #1; What, other than the syntax, didn't you like about DCL?  What
about the syntax didn't you like (I could hazzard a couple of guesses...).
I found it pretty regular once I got used to it, but it can be a bit
mystifying at first.  If you come to VMS with expectations from Unix, you're
lost.  If you approach it as it's own system, it can be quite elegant.

It's been almost 15 years since I stopped using VMS and DCL.  Memories of 
details have faded, so I can't easily pull up specifics.  I just remember 
my overall impression.  I do recall that I felt that DCL was overly 
verbose, with unnecessarily complex punctuation rules.

I wouldn't say I was "mystified" -- I wrote a fair number of DCL scripts 
back then and was definitely able to accomplish useful tasks with it.

Fair enough; I just wondered if someone had snuck (yes, snuck) DECnet
clustering on here. I like it, though.

DCL can certainly be approached on its own terms and/or "gotten used to,"
however, whilst I could probably think of a couple of Unix misfeatures if I
concentrated, SET DEFAULT's way of handling default directories is a
misfeature that jumps out at you.

(For the uninitiated: if you change to a non-existent directory in Unix, "cd
<non_exist_dir>", the cd command will tell you right away. The equivalent
command in VMS, merely replaces filenames that don't have an absolute path
(one that descends from the root) with the contents of the variable set up
by SET DEFAULT; thus if you SET DEFAULT to a non-existent directory, it will
wait to trap you until you try to reference a file in that directory. Of
course, "non-existent directory" in both VMS and Unix could just be a
directory whose name has been misspelt.

I readily admit that I was mystified by DCL when I was first exposed to it.
But then I began to see that it was quite powerful; in some ways, more so
than the Unix shell (it's more of a "real" programming language than just
about any shell I've ever used).  I've seen some DCL command procedures that
were pretty involved.

Regarding #7; I'll grant you that the behavior of SET DEFAULT is weird and
counter-intuitive (and downright annoying if you're used to cd).  I know
it's cheating, but we always installed a CD command that did The Right Thing
(tm).

File versioning was absolutely useful, as Remmers points out.  It certainly
saved my hide a few times; it was also nice that it was built into the
filesystem.  Application programs don't need to know anything about it to
get its benefits.  Compare to Unix where the best you might get is some sort
of versioning library that must be linked into any application that wants
file versioning functionality.  Ugh.

But some of the real elegance of VMS comes through in the programming
interfaces, that were (and are) quite rich.  Things like the AST interface
that do away with the need for hacks like select(); the standardized calling
conventions that make it possible to link together modules written in
different languages and have things Just Work; the comprehensive standard
library.  The process model is different, but interesting: there is not a
bijection betwen processes and running programs as there is under Unix.
Instead, a process is persistent and program images are run up and run down
within the context of a single process.  This makes it easy for programs to
access services provided by shared libraries at very little cost.  It also
allows them to share context with the shell and do other neat things like
that (this is reminiscent of TOPS-20, where you could type the name of a
program and use shell completion to specify the program's parameters and
qualifies; the shell could do it because it could load the target program
image into the same process space as the shell itself, and then get the
possible parameters directly from the program in question.  Try doing THAT
under Unix....

Dan, 

When you mean "there is not a bijection between processes and running programs
are tehre is under unix" are you talking about Unix fork()/exec() model vs
the VMS spawn (which sort of combines both of these operations in one step)
?

No, I mean that every process is running exactly one program at any given
time.  In VMS, you can run more than one program in a process, whereas in Unix
you can't (I suppose you could have something like a multithreaded interpreter
that would give the appearance of running more than one program at once, but
then the "program" is the interpreter, not the thing its interpreting).

 I haven't read a lot about the details but when I first heard about
 Apple's "Time Machine" features in their new OS VMS's file versioning
 features were what I thought of.  

I haven't followed this; is it like file versioning, or snapshots?  If the
latter, then it's more like the Plan 9 file server.

unliuck

 re #12:  I don't actually know how it's implemented.  

 It's half funny, half sad that there are OS features that were 
 available 20 years ago when I started college that have yet to
 make it into mainstream desktop operating systems or are only
 just now doing so.

I think it's sad that OS features that existed 40 years ago haven't made it
into the ones that existed 20 years ago, and certainly haven't made it into
the ones that are mainstream now.  :-)

Perhaps said features were deemed unneeded, or more probably, said
features were covered by patents and couldn't make it into mainstream ones.

Not in all cases.  For instance, the Multics security model is something
that's often pointed out as desired but has yet to make an appearance in a
system postdating Multics.  As far as I am aware, it is not covered by any
patents.

Perhaps you could post more on the wonders of the Multics Security Model?

In a magical land, to the Northeast of Michigan, called "MIT," the wonders
of Multics were created....

But seriously.  I think I'd do a poor job.  I can, however, let the Multics
security model speak for itself.  This site:

http://www.multicians.org/

is a wonderful resource for information on Multics.  As on puruses that site,
one sees a *lot* of familiar names from the Unix world.

Not to be picky, but MIT is due east of central Michigan.

(Okay.  Noted.  But it might be one or two miles North....  [Or, for that
matter, South...]  :-))

So more on the VMS front....

A couple of years ago, I bought a surplus Digital-branded Alpha-based
workstation for the express purpose of running OpenVMS; it was a
600MHz DEC Personal Workstation 600au with 256MB of RAM.  I also
bought two 9GB SCSI drives to use in the system.  Then the Alpha
sat in my apartment for a couple of years collecting dust.

Recently, I finally got around to getting VMS media.  Specifically,
I got a CD for OpenVMS 8.3 for Alpha that includes some layered
prodcuts (mainly compilers, DECnet and clustering, etc).

Finally, on Saturday, I pulled the machine out and started playing
with it.  It powered on fine, but the video did not work.  I reseated
the video board, and then it came up, but would not retain changes
in the SRM console (actually, even worse, it came up with AlphaBIOS
and the change to use SRM would not stick after a power-cycle).
AlphaBIOS is for booting Windows NT, while SRM is for Unix and VMS.

I concluded that the CMOS battery was dead, and decided that a bit
more TLC was needed.  So I cracked the case and took most of the
contents out, blew things out with compressed air and wiped off
most of the dust bunnies, reseated the RAM and all of the mainboard
connectors, etc.  I observed that the CMOS battery was a common
watch battery, so I went down to the local supermarket and bought
a replacement which I brought home and placed into the system.  I
put everything back together and powered up the machine and reset
the CMOS settings from AlphaBIOS to SRM and set the OS type to
OpenVMS and then power-cycled again.  This time, everything came
up as expected.

I applied for OpenVMS hobbyist license from http://www.openvmshobbyist.org/
These arrived in my email inbox a couple of minutes later.  I booted
off of the CD-ROM and installed VMS onto the original 4GB Seagate
disk.  That was fun, and gave me some refresher experience with
doing a VMS install, but ultimately, I wanted more disk.  So I
brought the system down and exchanged the origianl disk with the
two IBM drives installed VMS onto those (using a few lessons I'd
learned from the first installation; like, make sure you enter
licenses for a few critical products when prompted *during the
installation*.  Namely, the OPENVMS-ALPHA, DW-MOTIF, and UCX-related
PAKs.  Also, set the DEC$IGNORE_WORKSTATION logical symbol to TRUE
in SYLOGICALS.COM before rebooting).

Ah, everything worked; I now have a working OpenVMS 8.3 system
sitting in my living room.  I've installed and configured TCP/IP,
DECnet Phase IV and Phase V, and all of the layered products that
came with the distribution media, including FORTRAN, Pascal, C,
C++, COBOL, the language environments, and a few other odds and
ends.

VMS, for me, is a very comfortable environment that I like a lot.
And after using Unix and Mac machines all day, it's refreshing to
have an opportunity to work with something diferent (this is another
reason that I also really like working with TOPS-20, among others).

Very cool.

I had an alphaserver for a while, but 6 inches of flame shot out of the
power supply at me the first time I tried to power it up.  After a few
years of searching for a non $700 power supply I gave up and ebayed the
core components.

 :(

I was very sad.

Wonder if it would fire up (excuse the pun) today

Long Live OpenVMS!

Deathrows sentence has been carried out. R.I.P.

But there are stil public OpenVMS systems up and running, if not very active
these days.

   - polarhome.com
   - museo.freaknet.org/en/

Any users of Polarhome ALPHA here? There's a new toy. See
the Polarhome web forum.

Polarhome looks great.  I haven't seen this until now, thank you.
I need to dig out my old XLNT scripts and check out the VMS area.

Welcome aboard!

One can also get an account on a real VAX-11/785 running VMS
over at the Living Computer Museum.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss