Adds an entry to the access control list (ACL) for a database or
 relation.  To define protection for a database, you must first invoke
 the database.

 Example:

      RDO>  DEFINE PROTECTION FOR DATABASE
      cont>   POSITION 3
      cont>   IDENTIFIER [25,235]
      cont>   ACCESS "READ+WRITE+MODIFY+ERASE".

Additional information available:

FormatMoreExamples

 DEFINE PROTECTION FOR ──┬──> 
D
A
T
A
B
A
S
E ──────────────>──────┬─┐
                         ├──> 
R
E
L
A
T
I
O
N ──> relation-name ───┤ │
                         └──> 
V
I
E
W ──────> view-name ───────┘ │
        ┌───────<───────────────────────────────────<─────────┘
        └──┬──────────────────────────────┬─┐
           ├─> 
A
F
T
E
R ───> identifier ─────┤ │
           └─> 
P
O
S
I
T
I
O
N ──> n ────────────┘ │
         ┌───────────────<──────────────────┘
         └───> 
I
D
E
N
T
I
F
I
E
R ──┬──> identifier ──┬─┐
                            └──<──── typebox (+) <──────┘ │
         ┌────────────────────<─────────────────┘
         └───> 
A
C
C
E
S
S ───┬───>─────────────────┬──────────> .
                         └─┬─> access-right ─┬─┘
                           └─<────── typebox (+) <─────┘

Additional information available:

AFTERPOSITIONIDENTIFIERACCESS

 Locates the new ACL entry relative to an existing entry.  When you
 specify an identifier, Rdb/VMS searches the access control list for
 an existing entry that matches.  It then inserts the new entry after
 the existing one.  If you use the AFTER clause, you cannot use the
 POSITION clause.

 Locates a new ACL entry relative to its position in the list.  Use an
 unsigned integer greater than zero to specify the position in the
 access control list where Rdb/VMS places a newly created entry.  If
 you use the POSITION clause, you cannot use the AFTER clause.

 When this statement executes, Rdb/VMS automatically reassigns
 sequence numbers to entries in the ACL, starting with number one.

 Identifies the user or users for whom an entry is being added.  You
 can specify any valid VMS identifier in the identifier clause:

  o  UIC identifier
  o  General identifier
  o  System-defined identifier

 Grants or denies access rights to the user identified in an ACL
 entry.  For more information on access rights, ask for HELP on
 Access_rights.

 Specify only those access rights that you want to grant access to.

 An access control list (ACL) is attached to each database and
 relation.  This list defines which users can access the database
 element and what operations each user can perform.  Thus each entry
 in the access control list consists of two items of information:


  o  An identifier that specifies a user or set of users.

  o  A set of access rights.  These rights specify what operations the
     user or users can perform on the database or relation.


 When you first create a database, Rdb/VMS creates two ACL entries,
 one for the owner of the database and one for all other users.  The
 owner is given all access rights, including CONTROL.  All other users
 are given every access right except CONTROL.  If you, the owner of
 the database, want to use the Rdb/VMS protection mechanism, your
 first step should be to set stricter protection on the database
 immediately.

 Rdb/VMS determines the rights for a user by matching the user's user
 identification code (UIC) with the identifier in each ACL entry.  The
 first time Rdb/VMS finds a match, it grants the user the rights in
 that entry.  If there is no match, Rdb/VMS grants no rights.
 Therefore, if the owner deletes the second default entry whose
 identifier is [*,*], all access is denied to all users but the owner.

 Use the DEFINE PROTECTION statement to add more entries to the list.
 When the statement executes, Rdb/VMS creates a new entry in the
 position specified.  This entry grants the specified rights to the
 user or group of users determined by the identifier.  All rights not
 specified in the statement are denied.

 For a particular user, Rdb/VMS grants an access right to a relation
 only if that right is granted in the ACL for both the database and
 the relation.  That is, a user has WRITE privilege to the EMPLOYEES
 relation only if that user has WRITE privilege to both the PERSONNEL
 database and the EMPLOYEES relation.  This means that protection at
 the database level should grant to each user or group of users all
 the privileges they may need for any relation.  You can then deny
 these privileges at the relation level.

 To define protection for a database, you must first invoke the
 database.  You must execute the DEFINE PROTECTION statement in a
 READ_WRITE transaction.  If you issue this statement when there is no
 active transaction, Rdb/VMS starts a READ_WRITE transaction
 implicitly.

 Example 1

 The following example grants access rights to a single user:

 RDO>  DEFINE PROTECTION FOR DATABASE
 cont> POSITION 3
 cont> IDENTIFIER [ADMIN,JONES]
 cont> ACCESS "READ+WRITE+MODIFY+ERASE".

 This statement performs the following actions:

  o  Specifies the location of the entry within the access control
     list.  The new entry is in the third position and all subsequent
     entries are moved to the next higher position.

  o  Uses an identifier to designate the user who is granted access
     rights.

  o  Grants the specified access rights.  Rdb/VMS denies all other
     rights.



 Example 2

 The following example grants access rights to a group of users:

 RDO>  DEFINE PROTECTION FOR RELATION SALARY_HISTORY
 cont>      AFTER [PROGRAMMERS,CLARK]
 cont>      IDENTIFIER [PROGRAMMERS,*]
 cont>      ACCESS
 cont>      "READ+WRITE+MODIFY+ERASE -
 cont>      +DEFINE+CHANGE+DELETE".

 This statement performs the following actions:

  o  Names the relation SALARY_HISTORY.  The new ACL entry will be
     applied to this relation.

  o  Uses the AFTER clause to specify the location of the entry within
     the ACL.  In this case, the new ACL entry appears after the entry
     for user identifier [PROGRAMMERS,CLARK].

  o  Identifies the set of users ([PROGRAMMERS,*]) who are granted the
     listed access rights.  In this case, the new identifier has the
     same group identifier as the identifier that precedes it in the
     list.  This means that for user CLARK in group PROGRAMMERS,
     Rdb/VMS will grant the privileges listed in the earlier entry.
     All other users in group PROGRAMMERS will fall through to the
     entry identified by [PROGRAMMERS,*].  Rdb/VMS grants these other
     members of group PROGRAMMERS the rights listed in this statement.
     In this way, the system gives general rights to a group and more
     specific rights to a single member of the group.