Interesting...  I program on Unix and OpenVMS and I can name at least
10 things (maybe more) that VMS does much better than Unix.  VMS is
still being developed (we're using V8.2 now) and is still one of the
best operating systems ever built.  Besides, there isn't really one
version of Unix, so something might work on Linux but fail on Solaris,
etc.  Here is a simple list from the top of my head:

1.  Signals.  Signals are done correctly under VMS, and are idiotic
under Unix.  Long ago, signals weren't even queued if you were in a
single handler, and even today signals don't specify a specific
unique event.  For instance when SIGALRM goes off, it doesn't tell
you specifically which timer went off, so you can't write a library
function that might trap sigalrm because it would catch everyone elses
alarms that might be using the library.  All events in VMS (timers,
processes deaths, IO, locking, etc.) not only identify a unique
specific event but all waited actions in VMS allow you to do this
asynchronously.   Difficult to explain unless you have programmed at
this level, but VMS did it much/much better than Unix.
2.  Error Handling.  VMS has a message facility that uniquely
identifies each and every error, warning, etc. that could occur
anywhere in the operating system.  So when instead of returning -1, or
zero, or some other value from a routine, and then having to check
errno (which isn't unique enough), you just check the status value.
This status value can then be used to look-up the error message and
print it out.  All status values in the operating system are unique
even for each facility and you can create your own status values and
use the message facility for your own routines.  Given any status
value, you can often find and fix the problem very quickly.  Just
opening a file for example, you might get a "protection violation",
"file not found", "volume not found", "not enough quota",
"insufficient virtual memory", etc..  All error messages are stored
in message files for internationalization.  Unix error handling
doesn't come close to this.
3.  Exception/Condition Handling.  Exception handling is built into the
VMS calling standard.  This exception handling is used by C++
throw/catch, but in VMS it's much more flexible and used extensively
into the operating system.  For example, in VMS condition handing, you
can trap a condition, fix-up the problem, and even re-try the
instruction or continue with the next instruction.  An example of this,
might be to fault the page into memory, fix-up the virtual address
translation buffer, and re-try the instruction.  Or trap an alignment
fault, perform the operation, and then continue with the next
instruction in the stream.  Condition Handling can be used for much
more than this but this will give you some ideas.
4.  RMS - VMS contains a record management system that includes Unix
stream LF files, Unix type binary files, but also many other types of
files.  For example, relative files, and indexed files with
multiple-keys and key types.  Yes, you can do this in Unix with
packages like C-tree but having it built into the operating system
allows record level locking to work across the cluster.  Try to do that
in Unix.
5.  All facilities are callable and there is a calling standard for all
languages.  For example, the sort utility is callable and has a record
interface, the message facility is callable, command line parsing is
callable, multiple languages are all callable to each other, so a cobol
routine can call a C routine, even in a sharable image (DLL) without a
problem, even if the compilers came from different companies, because
everyone uses the exact same VMS calling standard and it spells out
exceptions, parameter passing, stack dumps, etc. in great detail.
6.  Command line parsing.  Each program in Unix does it's own command
line parsing, so you have parameters like "-r" in one application
and "-R" in another and there doesn't seem to be much of a
standard.  Applications in VMS call a collection of routines (cli$) for
command language interpreter that tells your application what
parameters qualifies, etc. were passed on the command line.  You can
even change the parameters for internationalization and not even change
the application at all.  I've written a ton of Unix applications and
each time I wish there were a better way of command line parsing on
unix.  And yes, I know about getopt() and popt routines but they
don't even compare.
7.  Networking.  Networking is built-in to the file-name standard, so
there is no need to fire up FTP just to copy a file, or NSF.  In fact,
programs can open files across the network by must specifying the node
name and access string.
8.  ASTs.  No need to do threading when trying to do asynchronous
things.  All waited actions on VMS allow an AST routine.  Makes
programming multi-user networking applications much easier than using
threads.  I know, I write Unix threaded programs all the time and run
them on VMS, but programs that use ASTs are much simpler to debug and
work with, but Unix doesn't have ASTs.  NT does.
9.  Clustering done right.  Cluster wide file systems, cluster wide
shared files, cluster wide logicals, cluster wide devices, etc...  Unix
can't get there easily because of it's brain dead file systems and
stream files where you don't know what a record is to lock...
10.  Modes.  Not only do you have Kernel mode and User mode, but you
also have Supervisor and Exec mode.  Have you ever wanted to do
something in Unix and not be in user-mode, but also not necessarily be
a part of the kernel in kernel mode...  The shell normally runs in
supervisor and RMS normally runs in exec, so a program can't crash
through the environment table or channels open tables like they can in
unix.
11.  Security.  There is extensive security on VMS, but even simple
things like all IO having a MAX length argument that prevents buffer
overwriting.  fgets() was a security hole just waiting to happen, and
unix was littered with such bugs because they didn't think about it
originally.

I'm sure I could come up with a few more examples off the top of my
head, and that's enough to make some unix people roll their eyes in
the back of their heads, because they think Unix is god because
that's all they really know well.  I know both very well and VMS is
still one of the best operating systems ever made and was well ahead of
it's time in many areas.  Don't get me wrong, Unix is good for what
it does, and I applaud Ken Thompson and Dennnis Ritchie and Douglas
Mcllrow, and then Stallman and Linus for hacking together something
that eventually became free and set a whole new industry in motion
because I program Unix/Linux just about every day.  But VMS had its
roots in many other operating systems where experience was learned
before its development, including RT-11, RSTS, and TOPS; that gave VMS
a very good background in good operating system design from the very
start.  VMS is still being used today and still being developed.  In
fact the later versions run on Itaniums and support ELF images and
other industry standards; my hope is that it will get ported to
standard PC hardware someday.  I still often do my unix development on
VMS, test it and debug it, and then host it on Linux or Solaris, but we
also run soft real-time very large and complex systems on VMS.  I also
hope that FreeVMS on IA32 will be successful and eventually preserve a
free open source version of VMS for PC hardware for decades to come:
see http://www.systella.fr/~bertrand/FreeVMS/indexGB.html if you want
to get involved in an attempt to rewrite and preserve a great operating
system.