Description: Announcing PROJECT - a program to help manage project access

    Announcing an *important* new tool: PROJECT.  PROJECT is intended to aid
    anyone working on a project to manage that project more efficiently.
    Before I explain PROJECT, however, I'd like to give you a little
    background.
 
    Here at Smiths Industries, projects are implemented on the Engineering
    VMScluster by using logical names, disk quotas, and things called ACLs
    and identifiers.  When a project requests disk space, the VMS system
    manager creates a disk logical name for that project and defines it to
    be the physical device where the project files will reside.  Next, the
    system manager creates something called a "resource identifier".  This
    resource identifier is an entity that can own files, just like a
    person's account. Additionally, the identifier can be assigned or
    "granted" to a person.
 
    Once the identifier is created, a quota on the project disk is given to
    it and the project directory is created.  Then, the VMS system manager
    creates an "access control list", or ACL, that allows access to the
    project files by anyone whose account has the identifier granted to it.
    Finally, the identifier is granted to everyone who will need access.
 
    Up until now, when someone began to work on a project, it was the
    responsibility of the project engineer or project manager to contact one
    of the VMS system managers and request that the new person be granted
    the project identifier, thus enabling access to the project files.
    Likewise, when a person moved on to another project, it was the duty of
    the project manager or project engineer to contact one of the VMS system
    managers and request that the project identifier be "revoked" from that
    person's account; that is, break the linkage between the person's
    account and the project identifier, thus disabling access to the project
    files.
 
    That's the end of the history lesson.  Now for the introduction to
    PROJECT.
 
    The process I've described above has been quite workable, but there are
    some major drawbacks to it that make it less efficient than it could be:
 
    1. People who begin to work on a project must contact the project
       engineer or project manager, and they may not know who that person
       is.
 
    2. Project managers or project engineers must contact a VMS system
       manager in order to enable or disable access for a person.
 
    3. Project managers and project engineers can't keep track of who
       currently has access to the project files.
 
    4. People working on a project can't find out who else is working on the
       project.
 
    PROJECT is an effort to address these deficiencies.  By using PROJECT,
    project managers will be able to enable and disable project file access
    without the need to contact a VMS system manager.  People working on a
    project will be able to determine on their own who controls access to
    project files and which other engineers have access.  PROJECT will even
    allow people to construct electronic mail distribution lists so that
    they can send mail to everyone working on a project.
 
    The format of the PROJECT command is straightforward.  It consists of
    the verb "PROJECT" followed by an action to be performed, such as
    "GRANT" or "REVOKE", the project identifier, and the username of the
    person on whose account the action is to be performed.  The PROJECT
    command can also be entered alone, which will cause the program to
    prompt for multiple commands, in a fashion similar to VMS Mail.  Some
    examples of PROJECT command are:
 
    $ project grant sfdr_sw tillman
    $ project
    PROJECT> revoke scns_sw ruse
    PROJECT> list scns_sw
    PROJECT> exit
    $ project list scns_sw_admin
 
    The first line above tells PROJECT to grant the identifier SFDR_SW to
    username TILLMAN, thus enabling access for TILLMAN to the SFDR Software
    files.  The second line tells PROJECT to begin prompting for commands.
    The third line revokes the SCNS_SW identifier from username RUSE, thus
    disabling access for RUSE to the SCNS Software files.  The fourth line
    tells PROJECT to show all usernames holding the SCNS_SW identifier.  The
    fifth line exits the PROJECT program.  The sixth line tells project to
    display the list of all people who hold the SFDR_SW_ADMIN identifier.
 
    This last example is noteworthy.  In order to make PROJECT work, the VMS
    system management staff created a new set of identifiers, all of which
    end in "_ADMIN".  We then granted each of these identifiers to the
    people responsible for managing the project represented by the
    identifier formed by dropping the "_ADMIN" string.  Thus, for example,
    the administrators for the SFDR_SW project all hold the SFDR_SW_ADMIN
    identifier.  So, if you want to get access to the SFDR_SW project, you
    can use PROJECT to show you who holds the SFDR_SW_ADMIN identifier.  You
    can then contact one of these people and they can give you access.  No
    need to find a VMS system manager.
 
    Naturally, if you prefer to contact a VMS system manager, be our guest.
    Use of the PROJECT command is not mandatory.  We'll be glad to help you
    gain access, as we've been doing all along.  Just keep in mind that
    we'll still require one of the project administrators to authorize your
    access by contacting one of us. We want to make sure that the project
    administrators are aware of who has access to the project data.
 
    While there is no hard copy documentation for PROJECT, help is available
    at the DCL prompt by entering HELP PROJECT.  Additionally, once you
    start PROJECT, help is available at the PROJECT> prompt.  I've tried to
    make the help clear and comprehensive.  Questions and suggestions,
    however, are always welcome.  Contact me at tillman_brian@si.com