In article <[log in to unmask]>, "Clayton L. Hines" <[log in to unmask]> w
rites:
> James Taylor wrote:
>
>> Why are Miami's DEC Alphas running OpenVMS instead of UNIX?
>
> You know, after Kent shared the news with me that there is actually a
> group working on writing a free VMS, I had one question for him:
>
> Why?
>
> I don't know if the crowd we were in took it the right way -- I wasn't
> trying to depreciate his livelihood, as I am sure you would not do
> yourself, although some people might construe it that way.  Rather, I was
> actually interested in the answer -- why the heck is VMS around in the
> first place?
>
> I am pretty familiar with UNIX (and will stand beside find, grep, the
> pipe, and all the other how-could-you-live-without-them essentials of
> UNIX until the bitter end, may it never come), but aside from /PAGE,
> /ALL, and my LOGIN.COM, I know very little about the workings of VMS.
> Yes, on my VMS account, I have ls, rm, and cp aliased to DIR, DEL, and
> COPY.
>
> I've heard that VMS has a number of strong points where UNIX is lacking
> -- VMS has multiple levels of security, where UNIX has only root and
> peons, is the one I've heard most often
 
Correct.  Instead of just 2 security levels like Unix, VMS has 39 different
privileges that can be assigned to users (or applications) in any
combination.  These range from TMPMBX which allows users to create
mailboxes (similar to UNIX pipes) to BYPASS which allows a user to bypass
all security on the system.  This allows the system administrator to give
particular users/managers of the system only the access they need to do
their job.  In addition, it gets rid of the hassles of needing to let a
dozen people know the root (SYSTEM) password.  Instead, I can empower those
users with the access they need.
 
You can see what privileges your account has with the command:
    $ SHOW PROCESS/PRIVILEGES
All users have 2 privileges by default.  These are TMPMBX (discussed above)
and NETMBX (allows users to create mailboxes that connect processes across
the network - not just on the same system).
 
In addition, VMS allows a user to turn on and off their privileges.  That's
why you very rarely see me logged onto the SYSTEM account on MiaVX1.
Instead, I turn the privileges in my account on and off instead of logging
into and out of the SYSTEM account.
 
> -- but I, like yourself, am
> anxious to hear a real defense of its cryptic directory syntax (now do I
> use square braces here, or a colon?), its confusing file names
 
Actually, it's not that difficult, it's just different.  The formal syntax
for a absolute VMS path is:
 
    node"username password"::device:[directory]filename.extensions;version
 
Keep in mind, though that you only need to specify the parts that are
different from your current directory.  Here's what each of the parts mean:
 
node"username password":: - Many people don't know this, but you can specify
a DECnet (or OSI) nodename as part of the filename.  VMS was one of the
earliest networked file systems.  Unfortunately, it was based on DECnet
(OSI was added later) and so it doesn't get much use.  This can be quite
useful, though.  For exmaple, the command:
    $ EDIT CWRU"KACOVERT TESTING"::SYS_USERS:[ACS.KACOVERT]TEST.TXT
would allow me to edit a file residing on Case Western's VMS systems
(assuming I had an account there called KACOVERT and my password was
TESTING - BTW, no I don't have an account there).  You can even get rid of
the username and password part if a "proxy" has been setup for you on the
remote system.  There is no need for NFS mounting or FTPing the file or
anything!  You can even do something like:
    $ CD CWRU"KACOVERT TESTING"::SYS_USERS:[ACS.KACOVERT]
If you leave out the node portion of the file specification, VMS assumes
that the file resides on the current system.
 
device: - Unlike Unix, VMS doesn't have a "root" directory.  Instead each
device has a root directory.  Therefore, you have to specify which device
your file resides on.  These devices can either be physical disks, logical
disks, tape drives, CD-ROMs, etc.  If you don't specify a device, VMS
assumes the current device as shown in the SHOW DEFAULT command.
 
[directory] - this is the directory where your file resides.  You can also
specify a relative path here.  A minus sign (-) represents the directory
above the current directory (like .. in Unix or DOS).  For example,
    [-.SUBDIR]TEST.TXT
would access the file called TEST.TXT that in SUBDIR subdirectory which
located in the directory above our current directory.  If you don't specify
a directory, VMS assumes the current directory as shown in the SHOW DEFAULT
command.
 
filename - pretty self explanatory.  Filenames can be up to 39 characters
long and can include the characters A-Z, 0-9, -, and _.
 
.extension - similar requirements to the filename.  Extensions can be up to
39 characters long and can include the characters A-Z, 0-9, -, and _.
 
;version - this is the version of the file.  If you don't specify a version,
VMS assumes the latest version of a file.  There are also special version
numbers you can specify here.  For example, ;0 (or just ;), the system will
use the latest version of the file.  If you specify a negative number, the
system will use older versions of the file (for example, -1 would be the
version before the current version, -2 would be 2 versions before the
current version, etc.).  If you specify -0, the system will use the oldest
version of the file available.
 
> (well I didn't need the explicit version number to CREATE the $&*# file!)
 
I agree.  VMS requires a version number when you delete a file.  I'm not
sure why this requirement exists, though.
 
Another "weird" requirement of VMS is that all directories are created
without giving the owner delete permissions.  I do know how this
originated, though.  VMS 1.0 would let you delete a directory without
getting rid of all of the files in the directory first.  Therefore, the
designers removed delete permissions on directories so that users wouldn't
"accidentally" delete a directory full of files (and therefore lose access
to those files).  Unfortunately, when they added the code to prevent a user
from deleting a non-empty directory, they didn't give the user delete
permissions on a directory.  The latest version of VMS is 7.0 (7.1 is just
around the corner) and it still requires the user to give themselves
permission to delete their own directories!!!  MCIS hopes to release a
RMDIR (and a MKDIR) command by fall that should make deleting (and
creating) directories on VMS easier.
 
> , and
> its tiny user base (where's comp.os.vms.* ?).
 
The latest figures I've heard from DEC indicate that about 10 million
people use VMS on a daily basis (if memory serves correctly).  This isn't
exactly a small number.  There is a comp.os.vms newsgroup.  In fact, there
is an entire news hierarchy devoted to VMS (check out the VMSNET
hierarchy).
 
> Kent, our problem is not the vast superiority of UNIX over VMS, nor is it
> even our distaste at VMS's callous disregard for case, for how could we
> know that we are justified in our opinions?  No, our problem is that we
> are ignorant.
>
> Can you remove the polarized lenses of UNIX before us, and let the light
> of truth fall on our eyes?
 
There is so much stuff, I don't know where to start (have you seen the wall
of VMS OS manuals in my office?).  If people have specific questions, like
those listed above, please post them to the mu.comp.os.openvms newsgroup.
I would be more than willing to answer them.
 
I've often thought about writing a "OpenVMS Tip of the Week" series of
articles in news where I would cover some little understood section of the
OS every week.  Unfortunately, time has not lent itself to this, yet.
 
--
                                     Kent Covert, Software Coordinator
                                     Miami Computing and Information Services
                                     Miami University, Oxford, OH
                                     [log in to unmask]