Adds an entry to the access control list (ACL) for a database,
 relation, view or view.  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 (ACE).

 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

Additional information available:

More

 You can specify multiple identifiers in the identifier clause when
 combining an identifier with a system-defined identifier.  However,
 you should regard the six system-defined identifiers as mutually
 exclusive.  Do not attempt to use them in combination with each
 other.  You can combine them with other identifiers (UICs and general
 identifiers).  When you specify multiple identifiers, separate them
 with a plus sign (+).

 If you specify multiple identifiers in the identifier clause, you
 define one ACE that determines the access rights that users will
 receive when they hold ALL the identifiers specified in the
 identifier clause.  Users who do not hold all of the identifiers
 specified in the identifier clause will not be governed by the ACE
 that is created.

 For example, the first of the two RDO statements in the following
 example defines a single ACE for users with both the [CLERK,DAVIES]
 and REMOTE identifiers, not one ACE for users with the [CLERK,DAVIES]
 identifier and another ACE for users with the REMOTE identifier.  The
 second statement shows the ACE created in the second position in the
 ACL, as specified in the DEFINE PROTECTION statement:

 DEFINE PROTECTION FOR RELATION A1
 POSITION 2
 IDENTIFIER [CLERKS,DAVIES]+REMOTE
 ACCESS READ+WRITE+MODIFY.
 !
 SHOW PROTECTION FOR RELATION A1
  (IDENTIFIER=[DBS,RICK],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+DEFINE+
    CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR+REFERENCES+SECURITY)
  (IDENTIFIER=[CLERK,DAVIES]+REMOTE,ACCESS=READ+WRITE+MODIFY)
  (IDENTIFIER=[*,*],ACCESS=READ+MODIFY)

 To control which users have the ability to create databases, use the
 RDBVMS$CREATE_DB logical name and system rights identifier.  See the
 "VAX Rdb/VMS Guide to Database Design and Definition" for more
 information on the RDBVMS$CREATE_DB logical name and system rights
 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.

 You must have the Rdb/VMS CONTROL privilege for an object to define
 protection for the object using the DEFINE PROTECTION statement.

 An access control list (ACL) is attached to each database, relation,
 and view.  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 creator of the database and one for all other users.
 Under the Rdb/VMS default protection scheme, the creator of the
 database is given all access rights to the database, including
 CONTROL, which enables the owner to grant CONTROL and any other
 access rights to other users.  All other users of the database are
 given no access rights to the database.  For any relations or views
 created under the Rdb/VMS default protection scheme, the creator of
 the relation or view is given all the access rights to the object,
 including CONTROL, and all other users are given no access rights to
 the relation.

 Rdb/VMS allows you to tailor the default protection for any new
 relations that are created in a database:

 1.  By default, the creator of a relation gets all the access rights
     to the relation, but Rdb/VMS gives no access to any other user:

     RDO> SHOW PROTECTION FOR RELATION RELATION1
         (IDENTIFIER=[DBS,RICK],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+DEFINE+
           CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR+REFERENCES)
         (IDENTIFIER=[*,*],ACCESS=NONE)


 2.  If you want other users to have some access to new relations, you
     can define an identifier called DEFAULT in the system rights
     database.  Then you can define an identifier called DEFAULT for
     your Rdb/VMS database.  The access rights specified in the
     DEFAULT identifier will be granted to all users except the owner
     of any new relations created in the database.  For example:

     RDO> DEFINE PROTECTION FOR DATABASE
     cont> IDENTIFIER DEFAULT
     cont> ACCESS READ+MODIFY.


 3.  You need to detach from the database to make the change in
     protection occur:

     RDO> COMMIT
     RDO> FINISH

 4.  The protection on existing relations in the database is not
     changed, but any new relations that are defined receive the
     protection specified by the DEFAULT identifier.  In this example,
     the creator receives all the access rights to the new relation
     RELATION2 and all other users receive the READ and MODIFY access
     rights specified by the DEFAULT identifier.

     RDO> INVOKE DATABASE FILENAME TEST1
     RDO>
     RDO> DEFINE RELATION RELATION2.
     cont> FIELD1.
     cont> FIELD2.
     cont> END RELATION.
     RDO>
     RDO> SHOW PROTECTION FOR RELATION RELATION2
         (IDENTIFIER=[DBS,RICK],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+DEFINE+
           CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR+REFERENCES)
         (IDENTIFIER=[*,*],ACCESS=READ+MODIFY)



 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 creator deletes the second default entry whose
 identifier is [*,*], all access is denied to all users but the
 creator.

 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.

 You must have the READ database privilege to attach to a database.

 The ADMINISTRATOR, OPERATOR, and SECURITY database privileges are the
 three Rdb/VMS role-oriented privileges.  Users with these privileges
 have the ability to override ACLs for some objects to perform
 database operations.  Similarly, users with certain VMS privileges
 also have the ability to override ACLs for some database objects.
 The Rdb/VMS role-oriented privileges are limited to the database in
 which they are granted, but the VMS privileges span all databases on
 the system.

 Users with the Rdb/VMS or the VMS role-oriented privileges are
 implicitly granted other Rdb/VMS privileges.  When you are granted
 implicit privileges to a database object as a result of an ACL
 override, you operate as if you actually hold the privilege, although
 you are not explicitly granted the privilege and it is not stored in
 the ACL

 Users with the ADMINISTRATOR database privilege or the VMS SYSPRV
 privilege can perform any data definition or data manipulation
 operation on any named object, including the database, regardless of
 the ACL for the object.  The ADMINISTRATOR privilege is the most
 powerful privilege in Rdb/VMS, since it can override most privilege
 checks performed by Rdb/VMS.  Users with the ADMINISTRATOR database
 privilege or the VMS SYSPRV privilege implicitly receive ALL
 privileges for all objects, except the SECURITY and OPERATOR database
 privileges.

 Users with the OPERATOR database privilege or the VMS OPER privilege
 implicitly receive the Rdb/VMS READ, WRITE, MODIFY, and ERASE
 database privileges.

 Users with the SECURITY database privilege or the VMS SECURITY
 privilege implicitly receive the Rdb/VMS READ, WRITE, MODIFY, and
 ERASE database privileges.

 Users with the VMS BYPASS privilege implicitly receive ALL privileges
 except the Rdb/VMS ADMINISTRATOR, OPERATOR, and SECURITY database
 privileges and the CONTROL relation privilege.

 Users with the VMS READALL privilege receive implicit READ and SHOW
 database and relation privileges.

 You must have the DISTRIBTRAN database access right to a database to
 run a two-phase commit transaction on that database.

 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.