The File System (also known as FMS) is the set of routines that maintain permanent files and catalogs for both TSS and batch. (Temporary files are maintained in a different way.) To ask for services from the FMS system, you use the ACCESS command in TSS (see "expl access") and the $FILSYS card in batch (see "expl cc filsys").
This explain file will deal briefly with the various services provided by the file system and ways in which you might use these services profitably.
The FMS permission structure dictates which users are allowed access to particular files and catalogs. The structure also specifies what actions these users are allowed to perform (for example, are they allowed to write on a file or are they only allowed to read it).
Permissions are of two types: specific and general. General permissions apply to all users; for example, if a file has general read permission, any user on the system may read it. Specific permissions apply to individual users; for example, a file might have general read permissions plus specific write permissions for user "prabbit". Thus anyone could read the file but only "prabbit" could write to it.
General and specific permissions are attached to a file or a catalog when it is created. If you create a file using the FRED text editor, it will be given general read permissions AUTOMATICALLY unless you specify FRED's O-R option. Thus if you don't want a FRED file to be publically available, you must specify O-R. In most other situations where files are created, the files will not have any general or specific permissions unless you ask for them in some way.
The CLIS command can tell you what general and specific permissions are currently attached to a file or catalog. The output of CLIS has the form
file ds7 s rwaemplcr <other stuff> specific permissions prabbit rwaemplcr
The first line starts with the name of the file, the device it's stored on (in this case ds7), whether it's sequential or random (the "s" here indicates sequential), and after that come the GENERAL permissions. The permissions are always listed in the order given; the individual letters have the following meanings.
Some permissions imply others automatically; for example, read permission automatically brings with it execute permission, and write permission automatically brings with it read and execute permissions.
The CLIS output shows what permissions are included; for example,
cata dx5 r e specific permissions prabbit rwae fbaggins rwaemplcr
This indicates that "cata" has general read/execute permissions; "prabbit" has specific read/write/append/execute and "fbaggins" has all possible specific permissions.
If a file or catalog has no general permissions, CLIS will print the word "none" where the general permissions are usually listed.
The ACCESS command is used to create or change the permissions on files and catalogs. For further information see
The file system organizes files into catalogs. Every user on the system has a master catalog entry whose name is the same as his userid. Underneath this catalog may be any number of files or subcatalogs. Every subcatalog may have subcatalogs of its own. Thus you obtain a type of tree structure:
master catalog / \ subcatalogs files / \ subcatalogs files
If user nbrazil has a file named "world" under a subcatalog called "of" under a catalog named "well", the file would be accessed using the PATHNAME "nbrazil/well/of/world".
Catalogs and subcatalogs should be used to organize your files. For example, you may put the source code for all your B programs under a catalog called B. Within this catalog there may be subcatalogs to organize the source files for various programs. By choosing descriptive names for your files and catalogs, you can obtain pathnames that give a great deal of information about your files; for example, a pathname like
dquixote/b/source/proga/manifests
obviously indicates B source code manifests for a program named "proga". This pathname is obviously longer than a name like "dquixote/x", but the small amount of extra typing is more than compensated for by the amount of information conveyed.
Files usually inherit permissions from the catalogs in which they are found. Thus if a catalog has general read permission, all the files under that catalog will also be available to the general public, whether or not they have explicit permissions associated with them individually. (This is why EXPL is available to all users -- the "expl" account has general read permission and therefore it is unnecessary to put read permissions on each individual explain file.)
Because files inherit permissions from catalogs, you should exercise a little caution in putting general permissions on catalogs.
In addition to normal permissions, you may put a lock on any file or catalog. The two most important types of locks are security locks and write locks.
If a file or catalog has a security lock on it, it can only be accessed by someone with lock permission (see above). Thus if a catalog has general read permission, you can keep files under it private by putting security locks on them.
A write lock on a file prevents everyone from writing to the file. There is no way to remove a write lock. Thus a write lock is a very effective way of making sure that a file isn't accidentally ruined by overwriting.
For further information on locks, see "expl access efso" (extended file system options).
Passwords may be placed on any file or catalog using ACCESS. Once this has been done, people will only be allowed to access the file or catalog if they have the appropriate permissions and if they can supply the proper password. If there is a password on a file that is under a catalog that also has a password, you will have to supply the passwords for both the catalog and the file.
Passwords should be regarded as a last resort measure, since they are generally more bother than they're worth. In almost all cases, you can use general and specific permissions to get the kind of security you want without needing passwords.
Copyright © 1996, Thinkage Ltd.