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]