Adds an entry to the access control list (ACL) for a database,
 relation, or field.  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 ───────────────┤
           └───> 
F
I
E
L
D ─> field-name IN relation-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

relation-nameview-namefield-name

 The name of the Rdb/VMS relation for which you want to insert an ACL
 entry.

 A user with MODIFY rights on the relation automatically gets the same
 rights on all fields in the relation.  However, you can restrict
 MODIFY rights by defining them only on specific fields you want users
 to be able to modify and thus remove the right from the relation
 entry.

 The name of the Rdb/VMS view for which you want to insert an ACL
 entry.

 The name of the local field in a specified relation for which you
 want to insert an ACL entry.

 Rights on a field are determined by the rights defined on the field
 combined with those specified for the specific relation ACL.

 Only MODIFY rights can be granted to fields.  All other rights are
 not applicable.

 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

     You cannot specify more than one UIC identifier in a DEFINE
     PROTECTION statement.

  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.

 Granting or revoking a privilege takes effect after the user detaches
 and attaches to the database again.

 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.

 Other users are allowed to be attached to the database when you issue
 the DEFINE PROTECTION statement.

 Example 1

 The following example grants access rights to a single user:

 RDO>  DEFINE PROTECTION FOR DATABASE
 cont> POSITION 3
 cont> IDENTIFIER [CLERKS,DAVIES]
 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 [ANALYSTS,JOHNSON]
 cont>      IDENTIFIER [ANALYSTS,*]
 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 [ANALYSTS,JOHNSON].

  o  Identifies the set of users ([ANALYSTS,*]) 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 JOHNSON in group ANALYSTS,
     Rdb/VMS will grant the privileges listed in the earlier entry.
     All other users in group ANALYSTS will fall through to the entry
     identified by [ANALYSTS,*].  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.



 Example 3

 The following example grants access rights on the specific field to a
 group of users:

 RDO>  DEFINE PROTECTION FOR FIELD SALARY_AMOUNT IN SALARY_HISTORY
 cont>      AFTER [MANAGERS,SMITH]
 cont>      IDENTIFIER [MANAGERS,*]
 cont>      ACCESS MODIFY.

 The following examples show how to specify the identifiers in a
 DEFINE PROTECTION statement.


 Example 4

 In this example, all users with the UIC matching [25,*] and running a
 batch job are granted the access rights listed.

 RDO>  DEFINE PROTECTION FOR DATABASE
 cont> POSITION 4
 cont> IDENTIFIER [25,*]+BATCH
 cont> ACCESS READ+DEFINE+CHANGE+DELETE.


 Example 5

 All users associated with the general identifier DATAENTRY and using
 RDO interactively are granted update access rights.

 RDO>  DEFINE PROTECTION FOR DATABASE
 cont> POSITION 5
 cont> IDENTIFIER DATAENTRY+INTERACTIVE
 cont> ACCESS READ+WRITE+MODIFY+STORE.


 Example 6

 User JONES gets the specified access rights.

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