Files which are "executable" normally include executable images (.EXE files - programs which have been compiled and linked) and indirect command procedures (.COM files - DCL procedures).
In order to run an executable image (.EXE file), the user process needs "E" (Execute) access to the file, but not necessarily "R" (Read) access (see the discussion of File Protections further on in this document). The image activator looks for Execute access, not Read access.
Note that not all .EXE files are RUNnable programs. Sharable images and data section files may also have a .EXE extension.
In order to "run" a DCL procedure, the user process needs "R" (Read) access. "E" (Execute) access is meaningless in this case, since the file is being read by DCL (like an interpreter). It is not being "run" (loaded and run by the image activator). The VMS documentation is a bit nebulous and contradictory on this topic.
Directories are simply files on VMS. The "root" directory of a disk volume always begins at a specific block location. Others can begin anywhere. The "root" directory is also sometimes referred to as the Master File Directory (MFD).
Directories have a special format not usually found for other files: variable length records which are not allowed to span block boundaries. There is also a file attribute flag in the file header which identifies the file as a directory.
Directories always have a .DIR extension. They are created using the CREATE/DIRECTORY command (or the associated $QIO call(s)), but can be deleted using the DELETE command. However, directories must be empty before they can be DELETEd. Only the lowest version of a directory file is used by the system. Normally, this is ";1". In cases where the only (or lowest) version of a directory file is not ";1", the behavior of the system can be unpredictable.
Files on VMS (usually) always have at least one entry in a directory. That is to say that at least one directory will contain an entry for any given file on a disk. The file's directory entry will appear in a directory on the same disk where the file begins. (In multi-disk volume-sets, a file can be "split" across more than one disk.)
An "alias" for a file is nothing more than another directory entry for a file which already has at least one. This is roughly equivalent to a UN*X "soft" link. Newer versions of VMS track the number (but not the location!) of aliases (directory entries) for files.
Even directories can have aliases. Most notably, this is found to be true of the VMS$COMMON directory on a system disk. For each system root on the disk, VMS$COMMON will have an alias of SYSCOMMON. For example:
[000000]VMS$COMMON.DIR
System root: [SYS0]
Alias: [SYS0.SYSCOMMON]
There is no utility supplied with VMS to locate all the aliases for a file. This is because files and directory entries are considered to be separate items - a file can exist without a directory entry, but a directory entry which points to a non-existant file is generally considered a corruption.
VMS File Protections are similar to UN*X "permissions". There are protections pertaining to System Class users (known as the "superuser" in UN*X), the owner of the file, users in the same UIC group as the owner of the file, and all other users in the "world".
As relates to File Protections, then, users fall into four "classes":
Unlike UN*X, VMS has a "System" class of user - those users whose UIC group is less than or equal to a value specified in a system parameter. This value can vary from system to system. System class users who lack the required over-riding privilege are subject to the System protections for files and other system-wide objects. See the discussion of Privileges further on in this document.
VMS has four types of protection for files:
Write ("W") access allows the user to open the file for writing. No read access is granted unless Read access is also allowed.
Execute ("E") access allows the user to run an executable image or to traverse a portion of a directory tree. For executable images, Execute access allows only that the image activator may load and run the program; no other Read access is granted unless the associated access is also allowed. For directories, the user may look up files in that directory, but may not view most file characteristics (with the DIRECTORY command) unless Read access to the target file is also granted. (Remember - to invoke DCL procedures, Read access is needed, not Execute, in most cases.)
Delete ("D") access allows the user to delete file. Note that Write access to the file's directory is usually also needed. No other access is granted unless accompanied by that specific access permission.
The protection of a file is usually displayed similar to the following example:
(RWD,RWD,RW,R)
The protections are listed in order by class. The above example is interpreted like so:
(SYSTEM:RWD,OWNER:RWD,GROUP:RW,WORLD:R)
or
(S:RWD,O:RWD,G:RW,W:R)
This is the specification syntax you would use to change a file's protection using SET SECURITY (or SET FILE/PROTECTION in older versions of VMS).
Access Control Lists provide another, more flexibile way to control access to files and other resources. A full discussion of ACLs is beyond the scope of this web page. Only a brief summary is given here.
Where normal file protections are driven by the UIC, ACL protections are driven by "rights identifiers" which are held by a user or by the user process.
For example, the following ACE (Access Control Entry) grants read and write access to any user holding the RECEIVABLES identifier, regardless of their UIC:
(IDENT=RECEIVABLES,ACCESS=READ+WRITE)
For any user or user process holding the RECEIVABLES identifier, the user is allowed read and write access.
VMS employs a means of granting "privilege" to allow users to perform certain actions. There is no direct parallel to this in the UN*X world, except for the difference between the "superuser" (usually "root") and all other users. A full discussion of privileges is beyond the scope of this web page. Only a brief summary is given here.
Some examples include the OPER privilege which is needed to perform certain actions pertaining to batch and print jobs as well as certain system management functions like MOUNTing or DISMOUNTing disks and tapes. The LOG_IO or PHY_IO privileges are needed to perform certain logical and physical I/O operations, respectively. Typically, this pertains to setting up and using disks and tapes. Some privileges are necessary to operate within a work-group. Others allow the user to define system-wide logical names or group-level logical names, perform security related functions, create or delete permanent mailboxes, etc.
For many applications, additional privileges within the specific application must also be granted. See your application documentation for further details.
See the VMS documentation or the on-line help for more information about the topics discussed briefly here.
Home Page Operating Systems Products Specialties Freeware
OpenVMS Page Bulletin Board Contact Us About Us
Tradenames, trademarks, service marks, etc. appearing on this page are the property of their registered owners.
"DJE Systems" is a service mark of David J. Dachtera, doing business
as DJE Systems.
This page Copyright ©1998-2004 by David J. Dachtera, All Rights
Reserved.