Talk:Files-11

Good job on a really tough subject! Here are some comments on a quick read of the article.

I think that the use of the term system disk' (in the ODS-2 sentance and in the Disk organization and naming section/image) is confusing; do you mean the bootable volume or a publicly mounted (/SYSTEM) volume?

I was speaking specifically of the boot device (SYSDEVICE). Is there a more specific/better name for that? — Kate | Talk 05:27, 2004 Aug 11 (UTC)

System disk means the boot disk. Disks mounted with /SYSTEM are called "public volumes" by the documentation. Alan E. Feldman 2006-SEP-3 05:46 UTC

File security: protection and ACLs

I believe that the two security protection mechanisms available in VMS are properly designated as UIC based and ACL based. ACL based security has precedence over UIC based security (UIC mechanism is only evaluated only if no ACE in the ACL is matched); privileges are always evaluated as a final step. The VMS security model is generic and covers a variety of object classes such as: file, device, queue, logical name table, volume, global section

ACL based also include the CONTROL permission which doesn't appear in your 4 permissions list (the Owner category of UIC based mechanism implicity has Control also).

UIC (User Identification Code) is a two number pair [group,member] and a UIC is assigned to each user account as well as each object classownership.

UIC based security is controled by four categories: System, Owner, Group, World. Each category has a permission mask associated with it containing any/all of the following protection codes: Read, Write, Execute, Delete (the owner category implicitly also has Control).

Upon attempted access, the UIC of the accessor is compared to the UIC of the object to determine the matching category. The match is as follows:

• Owner - accessor's group and member codes .EQ. object's group and member codes.
• System - accessor's group code .LE. sysgen parameter MAXSYSGROUP (typically %O10)
• Group - accessor's group code .EQ. object's group (member codes differ)
• World - accessor's group and member codes .NE. object's group and member codes.

and access to the object is granted as allowed the matched permission mask.

To explain UIC based protection maybe a venn diagram would help. I vaguely recall one being used in the documentation prior to the addition of ACL security in VMS v4.

Now add the wrinkle of privileges to the UIC scheme, four privileges of interest here: BYPASS, SYSPRV, GRPPRV, READALL.

If the accessor holds (ignore the topic of the different privilege masks):

• BYPASS - accessor has no access restrictions (accessor is granted Read, Write, Execute, and Control and Control access to object)
• SYSPRV - accessor can access the object via the SYSTEM permission mask
• GRPPRV - accessor can access the object via the SYSTEM permission mask if the accessor's group code .EQ. the object's group code.
• READALL - accessor has Read access to the object.

Thanks! I've tried to integrate most of this (I think correctly :-). I've also created a (red) link to OpenVMS security, which hopefully can be used to explain the more general nature of ACLs (and other things) in some detail. This article is rather more detailed than the rest of the VMS coverage right now, so it's difficult to refer to other things, but hopefully that'll change... — Kate | Talk 05:27, 2004 Aug 11 (UTC)

Logical Names

I think we should add some stuff to the Logical Names section: the fact that logical names reside in different tables and the default search order for tables, and perhaps also the access modes (which, AFAIK, are not explained clearly ANYWHERE). Also, you _can_ define disk logical names without /TRANS=CONCEALED. For example, you can have DEFINE SYS SYS$SYSDEVICE: and you can then use SYS instead of SYS$SYSDEVICE to refer to the system disk. --Alan E. Feldman 2006-SEP-03 05:46 UTC

Description of INDEXF.SYS contents is missing stuff

This section is missing...

Index file bit map --- The index file bit map controls the allocation of file headers and thus the number of files on the volume. The bit map contains a bit for each file header allowed on the volume. If the value of a bit for a given file header is 0, a file can be created with this file header. If the value is 1, the file header is already in use.

Alternate boot block

Alternate index file header

This info is available in the Guide to OpenVMS File Applications:

   http://h71000.www7.hp.com/doc/731FINAL/4506/4506pro_001.html#75_indexfile

Alan E. Feldman 2006/12/15 6:00 UTC —The preceding unsigned comment was added by 71.127.196.17 (talk) 06:00, 15 December 2006 (UTC).

Historical inaccuracy

ODS-1 is described alternately as a flat file system, or a two level file system. This is all incorrect. There is no reason why ODS-1 volumes can't have an arbitrary deep hierachy of directories. It's in fact the file lookup routines in FCS that implement the two level directory limit, by not doing any recursive lookups. Also, directories are not really named [group.user]. First of all, the separator is a comma, and not a period. And secondly, the directory is named ggguuu.DIR in the file system. It's the file name parsing, which don't have anything to do with Files-11 that use the [ggg,uuu] format. RSX-11M+ also allows named directories. The syntax is just [name], and the directory name is then name.DIR. It isn't that hard to add subdirectories in 11M+. You just have to adjust the filename parsers, and correct the directory find routine to be able to do recursive lookups (I've done this).

 /Johnny Billquist (bqt@softjar.se)  —Preceding unsigned comment added by 212.112.174.82 (talk) 16:52, 2 April 2008 (UTC) 

And TOPS-20 had hierarchical directories, of course, and other PDP-11 operating systems (like, yaknow, UNIX) also did. This article deserves a "written like an advertisement" sticker. 108.20.128.4 (talk) 22:54, 20 January 2019 (UTC)