CDD/Plus CDO DEFINE — VMS CDD+_4.1A

Additional information available:

DATABASEDICTIONARYDIRECTORYFIELDGENERIC
KEYPROTECTIONRECORDRMS_DATABASE

DATABASE

 Creates a physical RMS database on disk using an RMS database
 definition.  This command also creates a CDD$DATABASE entity and a
 CDD$FILE entity in the dictionary.

 DEFINE DATABASE ─────> database-name  ───────────>───────────────┐
 ┌───────────────────────────────<────────────────────────────────┘
 └┬┬─────────────────>──────────────┬┬─> 
U
S
I
N
G rms-database-name ─┐
  │├> 
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S) ─┬> typebox (/)typebox (*) text */─┘│                            │
  │└> 
A
U
D
I
T typebox (I)typebox (S)  ──────┘              │                            │
  └────────────────<─────────────────┘                            │
 ┌──────────────────────────────────<─────────────────────────────┘
 └─> 
O
N vms-file-name ───────> .

Additional information available:

database-nametextrms-database-namevms-file-name
Examples

database-name

 The name of the database you are creating.  A CDD$DATABASE entity with
 this name is created in the dictionary.

text

 If entered with the DESCRIPTION clause, the text documents the database
 definition.  If entered with the AUDIT clause, the text becomes a
 history list entry for the database definition.

rms-database-name

 The name of an RMS database definition.  This must be the name of an
 existing CDD$RMS_DATABASE entity in the dictionary.

vms-file-name

 A name that specifies the location on disk of the physical file that
 holds the physical RMS database.  The name must be a character string
 having from 1 through 1024 characters.  A CDD$FILE entity with this
 name is created in the dictionary by this command.

Examples

 The following example defines a physical RMS database, DISG_FILE, on
 disk in the VMS file EMP.DAT using the RMS database definition
 EMPLOYEE_STORAGE.  In this example, EMP.DAT is the CDD$FILE entity,
 DISG_FILE is the CDD$DATABASE entity, and EMPLOYEE_STORAGE is the
 CDD$RMS_DATABASE entity.

 CDO> DEFINE DATABASE DISG_FILE USING EMPLOYEE_STORAGE ON
 cont> USR02:[DISG]EMP.DAT.
 %CDO-I-FILECRE, file usr02:[DISG]EMP.DAT created
 CDO>

 To display the brief definition of the physical RMS database DISG_FILE,
 use the SHOW DATABASE command:

 CDO> SHOW DATABASE DISG_FILE
 Definition of database  DISG_FILE
 |   database uses RMS database EMPLOYEE_STORAGE
 |   |   database uses record EMPLOYEE_REC
 |   |   file definition
 |   |   |   file allocation 200
 |   |   |   file contiguous
 |   |   |   file organization index sequential
 |   |   |   key 0
 |   |   |   |   key changes
 |   |   |   |   key duplicates
 |   |   |   |   segment LAST_NAME IN EMPLOYEE_REC
 |   |   |   key 1
 |   |   |   |   key changes
 |   |   |   |   segment EMP_ID IN EMPLOYEE_REC
 |   database in file DISK1:[SMITH]EMP.DAT
 |   |   fully qualified file DISK1:[SMITH]EMP.DAT;
 CDO>

DICTIONARY

 Creates a physical CDO dictionary.

 DEFINE DICTIONARY ───────> anchor-directory ───────────>.

Additional information available:

anchor-directoryExample

anchor-directory

 The VMS directory or subdirectory in which you are creating the
 dictionary.  Make sure that the anchor directory is empty before you
 create the dictionary.

 If the dictionary is to be used by the public, set protection on the
 anchor directory so that all users of the system have READ, WRITE, and
 EXECUTE privileges.

 If you delete the dictionary using the CDO command DELETE DICTIONARY,
 all the files in the dictionary's anchor directory are deleted,
 including user-created files.  For this reason, DIGITAL recommends that
 you avoid storing user-created files in an anchor directory.

Example

 The following command creates a CDO dictionary in the VMS subdirectory
 DISK1:[BOB.DICT].

 CDO> DEFINE DICTIONARY DISK1:[BOB.DICT].
 CDO>

FIELD

 Creates a field definition in a dictionary.

 DEFINE FIELD ─> field-name ───┐
 ┌─────────────────────────────┘
 └─┬──┬────────────────────────────────────┬──┬──┐
   │  ├─> 
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S) ─┬─> typebox (/)typebox (*) text */ ──┘  │  │
   │  └─> 
A
U
D
I
T typebox (I)typebox (S) ───────┘                   │  │
   └───────────────────────<──────────────────┘  │
 ┌─────────────────────────<─────────────────────┘
 └─┬─┬──────────>──────────┬─┬─> .
   │ └─> field-attributes ─┘ │
   └────────────<────────────┘

Additional information available:

field-nametextfield-attributesExamples

field-name

 The name of the field definition you want to create.

text

 If entered with the DESCRIPTION clause, the text documents the field
 definition.  If entered with the AUDIT clause, the text becomes a
 history list entry for the field definition.

field-attributes

 A list of definitions that indicate what type of data you can store in
 the field and how CDO uses that data.  See the top-level topic
 "field-attr" for a diagram of field attributes.

Examples

 The following command creates the ID_NUMBER field and specifies its
 data type.

 CDO> DEFINE FIELD ID_NUMBER
 cont> DATATYPE IS UNSIGNED LONGWORD.
 CDO>

 The following DEFINE FIELD command creates the DATE_HIRED field in the
 [CORPORATE.PERSONNEL]EMPLOYEES.CONTRACT directory from the default
 directory DISK1:[CORPORATE.PERSONNEL]EMPLOYEES:

 CDO> SET DEFAULT DISK1:[CORPORATE.PERSONNEL]EMPLOYEES
 CDO> DEFINE FIELD CONTRACT.DATE_HIRED
 cont> DATATYPE IS DATE.
 CDO>

 The following command provides validation criteria.  When an attempt is
 made to store a value other than "M" or "F" in the field referred to by
 this definition, the product that compares the field's value to this
 definition returns an error message.

 CDO> DEFINE FIELD SEX
 cont> DATATYPE IS TEXT SIZE IS 1
 cont> VALID IF SEX = "M" OR SEX = "F".
 CDO>

 The following command creates the field definition ZIP_CODE.  The
 DESCRIPTION clause and the AUDIT clause are used in the definition:

 CDO> DEFINE FIELD ZIP_CODE
 cont> DESCRIPTION IS /* A 5 DIGIT POSTAL CODE */
 cont> AUDIT IS /* WILL BE CHANGED TO 9 DIGITS EVENTUALLY */
 cont> DATATYPE IS UNSIGNED LONGWORD
 cont> SIZE IS 5 DIGITS.
 CDO>

 The following command creates an unnamed field definition by using the
 FILLER keyword:

 CDO> DEFINE FIELD BLANKS
 cont> DATATYPE IS TEXT 30 FILLER.

 In the following example, the SHOW FIELD/ALL command displays both the
 user and system-specified attributes for FIELD_B.  Only the datatype
 attribute was specified by the user.

 CDO> SHOW FIELD FIELD_B/ALL
 Definition of field FIELD_B
 |   acl                      (IDENTIFIER=[VCD,MCGUIRE],ACCESS=READ+
 |   WRITE+MODIFY+ERASE+SHOW+DEFINE+CHANGE+DELETE+CONTROL+OPERATOR+ADMINIS
 TRATOR)
 |                            (IDENTIFIER=[*,*],ACCESS=READ+WRITE+MODIFY+E
 RASE+SHOW+OPERATOR+ADMINISTRATOR)
 |   Created time             2-FEB-1988 12:25:00.83
 |   Modified time            2-FEB-1988 12:25:00.83
 |   Owner                    MCGUIRE
 |   Datatype                 signed longword
 |   |   History entered by MCGUIRE ([VCD,MCGUIRE])
 |   |          using CDO V1.0
 |   |          to CREATE definition on  2-FEB-1988 12:24:59.71
 CDO>

GENERIC

 Defines an entity based on an entity protocol.  This command can be
 used when there is no CDO syntax for defining the entity.

 DEFINE GENERIC ──────> protocol-name entity-name ───────────────────────┐
 ┌───────────────────────────<───────────────────────────────────────────┘
 └─┬──┬─────────────────>─────────────────┬─┬──┬─┬──────>───────┬┬─> . ──┐
   │  ├> 
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S) ─┬─>  typebox (/)typebox (*) text */ ─┘ │  │ └> attribute1 ─┘│       │
   │  └> 
A
U
D
I
T typebox (I)typebox (S) ───────┘                  │  └────────<────────┘       │
   └───────────────────<────────────────────┘                            │
 ┌───────────────────────────<───────────────────────────────────────────┘
 └┬──────────────────────────>────────────────────────────────────────────┐
  └> 
R
E
L
A
T
I
O
N
S
H
I
P
S. ─┐                                                    │
 ┌───────────────────┘                                                    │
 └┬─┬─────────────────────────>─────────────────────────────────────────┐ │
  │ └> 
R
E
L
A
T
I
O
N
S
H
I
P relationship-name relationship-mbr-options ───────┐ │ │
  │ ┌─────────────────────────────────<───────────────────────────────┘ │ │
  │ └┬─┬──────>───────┬┬─> . ─> 
E
N
D relationship-name RELATIONSHIP. ─┬┐ │ │
  │  │ └> attribute2 ─┘│                                             ││ │ │
  │  └────────<────────┘                                             ││ │ │
  └───────────────────────────<──────────────────────────────────────┘│ │ │
 ┌────────────────────────────────<───────────────────────────────────┴─┴─┘
 └┬───────────>──────────┬> 
E
N
D ─┬──────────────────>─────────────────┬> .
  └> 
E
N
D 
R
E
L
A
T
I
O
N
S
H
I
P
S. ─┘       └> typebox (G)typebox (E)typebox (N)typebox (E)typebox (R)typebox (I)typebox (C) protocol-name entity-name─┘


 attribute=

 ───> attribute-name IS ─────┬─> n ──────────────┬─────────────>
                             └─> quoted-string ──┘

Additional information available:

protocol-nameentity-nametextattribute-namen
quoted-stringrelationship-namerelationship-mbr-optionsExample

protocol-name

 The name of the protocol that the entity you are defining is based on.

entity-name

 The name of the entity you are defining.

text

 If entered with the DESCRIPTION clause, the text documents the generic
 entity definition.  If entered with the AUDIT clause, the text becomes
 a history list entry for the generic entity definition.

attribute-name

 The name of the attribute you want to include in this definition.  The
 attribute-name you provide in the first attribute clause must be an
 instance of an attribute protocol that is specified in the
 protocol-name protocol.  The attribute-name you provide in the second
 attribute clause must be an instance of an attribute protocol that is
 specified in the relationship-name protocol.

n

 The value that you want recorded in this attribute.  Replace n with the
 appropriate number if the attribute requires a numerical value.

quoted-string

 The value that you want recorded in this attribute.  You enter a string
 if the attribute requires a string.  You must enclose the string in
 quotation marks.

relationship-name

 The relationship you want to include in the entity definition.  The
 relationship must be specified as a legal member in the entity protocol
 on which this entity definition is based.

relationship-mbr-options

 Allow you to specify a relationship member.  This member can be either
 an entity that exists in a CDO dictionary, or it can be defined using
 the GENERIC clause.

 relationship-mbr-options=

 ─┬─> relationship-mbr-name  ───>
  │
  └─> 
G
E
N
E
R
I
C ──> protocol-name ─┬─────────────────>─────────────────┬───┐
                                 └> 
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S) ───>  typebox (/)typebox (*) text */ ─┘   │
 ┌───────────────────────────────────────────────────────────────────────┘
 └──┬─┬──────>───────┬┬─> . ────────┬──────────>─────────────────────────┐
    │ └> attribute1 ─┘│             └> 
R
E
L
A
T
I
O
N
S
H
I
P
S. ─┐                 │
    └────────<────────┘                                │                 │
 ┌────────────────────────────<────────────────────────┘                 │
 └┬─┬─────────────────────────>─────────────────────────────────────────┐│
  │ └> 
R
E
L
A
T
I
O
N
S
H
I
P relationship-name  relationship-mbr-options  ─┐     ││
  │ ┌─────────────────────────<───────────────────────────────────┘     ││
  │ └┬─┬──────>───────┬┬─> . ─> 
E
N
D relationship-name RELATIONSHIP. ─┬┐ ││
  │  │ └> attribute2 ─┘│                                             ││ ││
  │  └────────<────────┘                                             ││ ││
  └───────────────────────────<──────────────────────────────────────┘│ ││
 ┌────────────────────────────────<───────────────────────────────────┴─┴┘
 └┬───────────>──────────┬─ 
E
N
D ─┬──────────────────>──────┬───>.
  └> 
E
N
D 
R
E
L
A
T
I
O
N
S
H
I
P
S. ─┘       └> typebox (G)typebox (E)typebox (N)typebox (E)typebox (R)typebox (I)typebox (C) protocol-name ─┘

 attribute=

 ───> attribute-name IS ─────┬─> n ──────────────┬─────────────>
                             └─> quoted-string ──┘

Additional information available:

relationship-mbr-nameprotocol-nameentity-nametextattribute-name
nquoted-stringrelationship-namerelationship-mbr-optionsExamples

relationship-mbr-name

 The name of an existing entity that can be a legal member of the
 relationship you use.

protocol-name

 The name of the protocol on which the entity you are defining is based.

entity-name

 The name of the entity you are defining.

text

 If entered with the DESCRIPTION clause, the text documents the generic
 entity definition for the relationship member.

attribute-name

 The name of the attribute you want to include in this definition.  The
 attribute must be an instance of an attribute protocol specified in the
 entity protocol on which this entity definition is based.

n

 The value that you want recorded in this attribute.  Replace n with the
 appropriate number if the attribute requires a numerical value.

quoted-string

 The value that you want recorded in this attribute.  You enter a string
 if the attribute requires a string.  You must enclose the string in
 quotation marks.

relationship-name

 The relationship you want to include in the entity definition.  The
 relationship must be specified as a legal member in the entity protocol
 on which this entity definition is based.

relationship-mbr-options

 The name of an entity, if you are using an existing entity, or a
 definition of a new member using the GENERIC clause.

Examples

 The following example shows you how to keep track of definitions for
 executable images and source modules in the CDO dictionary using the
 GENERIC clause.  To do this, you define the executable image using the
 definitions of the source modules INPUT_MODULE and OUTPUT_MODULE that
 you previously defined with the DEFINE GENERIC command:

 CDO>  DEFINE GENERIC CDD$EXECUTABLE_IMAGE MY_PROGRAM
 cont> CDD$PROCESSING_NAME 'MY_PROGRAM'.
 cont> RELATIONSHIPS.
 cont>   RELATIONSHIP CDD$IMAGE_DERIVED_FROM
 cont>     GENERIC CDD$COMPILED_MODULE
 cont>     CDD$PROCESSING_NAME 'INPUT_MODULE'.
 cont>       RELATIONSHIPS.
 cont>         RELATIONSHIP CDD$COMPILED_DERIVED_FROM INPUT_MODULE.
 cont>         END CDD$COMPILED_DERIVED_FROM RELATIONSHIP.
 cont>       END RELATIONSHIPS.
 cont>     END CDD$COMPILED_MODULE INPUT_MODULE.
 cont>   END CDD$IMAGE_DERIVED_FROM RELATIONSHIP.
 cont>   RELATIONSHIP CDD$IMAGE_DERIVED_FROM
 cont>     GENERIC CDD$COMPILED_MODULE
 cont>     CDD$PROCESSING_NAME 'OUTPUT_MODULE'.
 cont>       RELATIONSHIPS.
 cont>         RELATIONSHIP CDD$COMPILED_DERIVED_FROM OUTPUT_MODULE.
 cont>         END CDD$COMPILED_DERIVED_FROM RELATIONSHIP.
 cont>       END RELATIONSHIPS.
 cont>     END CDD$COMPILED_MODULE OUTPUT_MODULE.
 cont>   END CDD$IMAGE_DERIVED_FROM RELATIONSHIP.
 cont> END RELATIONSHIPS.
 cont> END CDD$EXECUTABLE_IMAGE MY_PROGRAM.
 CDO>

 Because the generic definitions of INPUT and OUTPUT modules are nested,
 they do not have have directory entries.  You must use SHOW
 GENERIC/FULL to show their definitions within the generic entity
 MY_PROGRAM:

 CDO> SHOW GENERIC CDD$EXECUTABLE_IMAGE/FULL MY_PROGRAM
 Definition of MY_PROGRAM  (Type : CDD$EXECUTABLE_IMAGE)
 |   Contains CDD$IMAGE_DERIVED_FROM
 |   |   INPUT_MODULE               (Type : CDD$COMPILED_MODULE)
 |   |   |   Contains CDD$COMPILED_DERIVED_FROM
 |   |   |   |   INPUT_MODULE              (Type : CDD$SOURCE_MODULE)
 |   Contains CDD$IMAGE_DERIVED_FROM
 |   |   OUTPUT_MODULE              (Type : CDD$COMPILED_MODULE)
 |   |   |   Contains CDD$COMPILED_DERIVED_FROM
 |   |   |   |   OUTPUT_MODULE             (Type : CDD$SOURCE_MODULE)
 CDO>

Example

 In the following example, the DEFINE GENERIC command is used to define
 the source modules INPUT_MODULE and OUTPUT_MODULE for an executable
 image:

 CDO>  DEFINE GENERIC CDD$SOURCE_MODULE INPUT_MODULE
 cont>    CDD$PROCESSING_NAME 'INPUT_MODULE'.
 cont> END CDD$SOURCE_MODULE INPUT_MODULE.

 CDO>  DEFINE GENERIC CDD$SOURCE_MODULE OUTPUT_MODULE
 cont>    CDD$PROCESSING_NAME 'OUTPUT_MODULE'.
 cont> END CDD$SOURCE_MODULE OUTPUT_MODULE.
 CDO>

KEY

 Equates a key on the terminal keyboard to a character string.

 DEFINE KEY ──┬──┬─────────────>───────────┬──┬───> key-name ──┐
              │  ├> typebox (/)
E
C
H
O ─────────────────┤  │                │
              │  ├> typebox (/)
N
O
E
C
H
O ───────────────┤  │                │
              │  ├> typebox (/)
I
F
S
T
A
T
Etypebox (=)state-name ──┤  │                │
              │  ├> typebox (/)
N
O
I
F
S
T
A
T
E ───────────┤  │                │
              │  ├> typebox (/)
L
O
C
K
S
T
A
T
E ───────────┤  │                │
              │  ├> typebox (/)
N
O
L
O
C
K
S
T
A
T
E ─────────┤  │                │
              │  ├> typebox (/)
P
R
O
T
E
C
T
E
D ────────────┤  │                │
              │  ├> typebox (/)
N
O
P
R
O
T
E
C
T
E
D ──────────┤  │                │
              │  ├> typebox (/)
S
E
T
S
T
A
T
Etypebox (=)state-name ─┤  │                │
              │  ├> typebox (/)
N
O
S
E
T
S
T
A
T
E ──────────┤  │                │
              │  ├> typebox (/)
T
E
R
M
I
N
A
T
E ────────────┤  │                │
              │  └> typebox (/)
N
O
T
E
R
M
I
N
A
T
E ──────────┘  │                │
              └────────────────<──────────────┘                │
  ┌────────────────────────<───────────────────────────────────┘
  └───> key-equivalence ──────────────────────>

Additional information available:

key-namekey-equivalenceQualifiersExamples

key-name

 Specifies the name of the key that you are defining.

 The following table lists the key names and their designations on the
 keyboards of the VT200 and VT100 types of terminals.  On VT100-type
 terminals, you can define the LEFT and RIGHT arrow keys as well as all
 the keys on the numeric keypad.  On keyboards for VT200-series
 terminals, three types of keys can be defined :  (1) keys on the
 numeric keypad, (2) keys on the editing keypad (except the UP and DOWN
 arrow keys), and (3) keys on the function key row across the top of the
 terminal.  (Note that you cannot define function keys F1 through F5.)

 Key-name             VT200-series  VT100-type

 PF1                    PF1          PF1
 PF2                    PF2          PF2
 PF3                    PF3          PF3
 PF4                    PF4          PF4
 KP0, KP1, ..., KP9   0, 1, ..., 9   0, 1, ..., 9
 PERIOD                  .            .
 COMMA                   ,            ,
 MINUS                   -            -
 ENTER                 Enter        ENTER
 LEFT                    <-           <-
 RIGHT                   ->           ->
 E1                     Find          -
 E2                   Insert Here     -
 E3                     Remove        -
 E4                     Select        -
 E5                   Prev Screen     -
 E6                   Next Screen     -
 HELP                    Help         -
 DO                       Do          -
 F6, F7, ..., F20   F6, F7, ..., F20  -

key-equivalence

 The character string to be processed when you press the key.  Enclose
 the string in quotation marks to preserve spaces and lowercase
 characters.

Qualifiers

Additional information available:

/ECHO/IF_STATE/LOCK_STATE/PROTECTED/SET_STATE
/TERMINATE

/ECHO

 /ECHO (default)
 /NOECHO

 Controls whether or not the equivalence string is displayed on your
 screen after the key has been pressed.  The default is /ECHO, which
 displays the string equating to the key's definition.

 You cannot use /NOECHO with the /NOTERMINATE qualifier.

/IF_STATE=state-name

 /IF_STATE=state-name
 /NOIF_STATE

 Specifies the state that must be in effect for the key definition to
 work.  The /NOIF_STATE has the same meaning as /IF_STATE=current_state.
 The state name is an alphanumeric string.  States are established with
 the /SET_STATE qualifier or the SET KEY command.

/LOCK_STATE

 /LOCK_STATE
 /NOLOCK_STATE (default)

 Controls whether or not the state set by the /SET_STATE qualifier
 remains in effect until explicitly changed.  (By default, the
 /SET_STATE qualifier is in effect only for the next definable key you
 press or the next read-terminating character that you type.)

 If you specify /LOCK_STATE, you must also specify the /SET_STATE
 qualifier.

/PROTECTED

 /PROTECTED
 /NOPROTECTED (default)

 Controls whether or not a key is protected against later redefinition.
 The default is that the key is not protected against redefinition.

/SET_STATE=state-name

 /SET_STATE=state-name
 /NOSET_STATE (default)

 Specifies a new state to be set when the key is pressed.  (By default,
 the current locked state is reset when the key is pressed.) If you have
 not included this qualifier with a key definition, you can use the SET
 KEY command to change the current state.  The state name can be any
 alphanumeric string.

/TERMINATE

 /TERMINATE
 /NOTERMINATE (default)

 Controls whether or not the key definition is to be processed
 immediately when the key is pressed (equivalent to typing the string
 and pressing RETURN).

 The default is /NOTERMINATE, so you can press other keys before the
 definition is processed.  This allows you to create key definitions
 that insert text into command lines, after prompts, or into other text
 that you are typing.

Examples

 The following DEFINE KEY command defines the PF3 key on the keypad to
 perform the SHOW DEFAULT command:

 CDO> DEFINE KEY/TERMINATE PF3 "SHOW DEFAULT"
 CDO>


 The following command defines the NEXT SCREEN key on a VT200-series
 terminal keypad to perform the DIRECTORY command:

 CDO> DEFINE KEY E6 "DIRECTORY"
 CDO>

 The first of the following two DEFINE KEY commands defines the PF1 key
 to be the string SHOW.  The state is set to GOLD for the subsequent
 key.  The /NOTERMINATE qualifier instructs the system not to process
 the string when the key is pressed.  The second DEFINE KEY command
 defines the use of the PF1 key when the keypad is in the GOLD state.
 When the keypad is in the GOLD state, pressing PF1 causes the current
 read to be terminated.

 If you press the PF1 key twice, the system displays and processes the
 SHOW DEFAULT command.

 Note the space before the word DEFAULT in the second DEFINE KEY
 command.  If the space is omitted, the system fails to recognize
 DEFAULT as the keyword for the SHOW command.

 CDO> DEFINE KEY/SET_STATE=GOLD/NOTERMINATE/ECHO PF1 "SHOW "
 CDO> DEFINE KEY/TERMINATE/IF_STATE=GOLD/ECHO PF1 " DEFAULT"
 CDO>


 The following two examples both define the PF1 key to be "ONE" for
 state ONE.  However, using the first two commands to define the PF1 key
 is somewhat error-prone, in that it is possible to forget which state
 you are in and to define a key for a state other than you intended.
 You can eliminate this possibility for error by specifying the state in
 the same command as the key definition, as shown in the third command.
 This is the preferred method for defining keys.

 CDO> SET KEY/STATE=ONE
 CDO> DEFINE KEY PF1 "ONE"

 CDO> DEFINE KEY/IF_STATE=ONE PF1 "ONE"
 CDO>

PROTECTION

 Adds an access control list entry (ACE) to the access control list
 (ACL) for a CDO definition or a dictionary directory.

 An ACL is created at the same time as a dictionary object or directory.
 The ACEs in an ACL determine which users can access the definition and
 what operations each user can perform.

 Use the DEFINE PROTECTION command to add more ACEs to an ACL.  When the
 command executes, CDO creates a new ACE in the position you indicate.
 This ACE grants the specified rights to those users whose identifiers
 match the one in the ACE.  All rights not specified in the ACE are
 denied (except that the creator of a definition is always granted
 CONTROL access to the definition).

 DEFINE PROTECTION FOR ──┬> 
D
I
R
E
C
T
O
R
Y ────────────────┬──────────┐
                         ├> 
F
I
E
L
D ────────────────────┤          │
                         ├> 
R
E
C
O
R
D ───────────────────┤          │
                         └> 
G
E
N
E
R
I
C ─> protocol-name ─┘          │
 ┌────────────────────────────<──────────────────────────────────┘
 └┬> object-name ─┬─┬─────────>──────────┬─> 
I
D
E
N
T
I
F
I
E
R ─┬> id2 ─┬─┐
  └────── , <─────┘ ├> 
P
O
S
I
T
I
O
N n ───────┤               └── typebox (+) <─┘ │
                    └> 
A
F
T
E
R ─┬─> id1 ─┬─┘                         │
                              └─── typebox (+) <─┘                           │
 ┌────────────────────────────<────────────────────────────────────┘
 └─> 
A
C
C
E
S
S ─┬─> right ─┬───────────> .
             └──── typebox (+) <──┘

Additional information available:

protocol-nameobject-namenid1id2right
IdentifiersAccess RightsExamples

protocol-name

 The name of the protocol that the generic entity whose ACE you are
 defining is based on.

object-name

 The name of the dictionary object or directory for which you are
 creating the ACE.

n

 An unsigned integer greater than zero.  This number specifies the
 position in the ACL where you want to place the ACE.  If you choose a
 number larger than the number of ACEs in the ACL, the new ACE becomes
 the last ACE in the ACL.

id1

 The identifier or identifiers of the existing ACE that you want to
 immediately precede this ACE.

id2

 The identifier or identifiers of those users whose access to the object
 is being defined in this ACE.

right

 The access rights that are granted to the users specified in id2.

Identifiers

 The identifiers are standard VMS identifiers.  There are three types:

  o  UIC

  o  General

  o  System-defined


 You can specify more than one identifier by combining them with plus
 signs (+).  Such identifiers are called "multiple identifiers." They
 identify only those users who are common to all the groups defined by
 the individual identifiers.  Users who do not match all the identifiers
 are not controlled by that entry.

 For example, the multiple identifier SECRETARIES+INTERACTIVE specifies
 only members of the group defined by the general identifier SECRETARIES
 that are interactive processes.  It does not identify members of the
 SECRETARIES group that are not interactive processses.

 The following three subtopics briefly describe the three types of
 identifiers.

Additional information available:

UIC IdentifiersGeneral IdentifiersSystem-Defined Identifiers

UIC Identifiers

 UIC identifiers are user identification codes (UICs) that uniquely
 identify each user on the system.  The UIC can be in either numeric or
 alphanumeric format.  The following are all valid UIC identifiers that
 could identify the same user:

 [SALES, M_JONES]
 M_JONES
 [360,12]

 You can use the * wildcard character as part of a UIC identifier.  For
 example, if you want to specify all users in a group, you can enter
 [360,*] as the identifier.

 You cannot use more than one UIC identifier in a multiple identifier.

General Identifiers

 General identifiers are defined by the VMS system manager in the system
 rights database to identify groups of users on the system.  The
 following are possible general identifiers:

 DATAENTRY
 SECRETARIES
 MANAGERS

System-Defined Identifiers

 System-defined identifiers are automatically defined by the system when
 the rights database is created at system installation time.
 System-defined identifiers are assigned depending on the type of login
 you execute.  The following are all valid system-defined identifiers:

 BATCH
 NETWORK
 INTERACTIVE
 LOCAL
 DIALUP
 REMOTE

Access Rights

 Each dictionary definition has an ACL associated with it.  The access
 rights that CDO users can be granted to a definition include:  SHOW,
 DEFINE, CHANGE, DELETE, and CONTROL.  The following table lists the
 access allowed to a definition for each of these right:

 CDO Access Right         Access Permitted

 [NO]SHOW          Read and copy this definition
 [NO]DEFINE        Create new versions of this definition
 [NO]CHANGE        Change this definition
 [NO]DELETE        Delete or purge this definition
 [NO]CONTROL       Define, change, and delete ACLs

 Reserved for future use
 [NO]OPERATOR
 [NO]ADMINISTRATOR

 Three additional terms make listing access rights easier:  ALL, NOALL,
 and NONE.  You can enable or disable all rights with ALL or NOALL
 respectively.  For example, to grant a user all access rights except
 CONTROL, you can specify ACCESS=ALL+NOCONTROL, rather than list each
 right separately.  Similarly, ACCESS=NOALL+SHOW grants a user only SHOW
 access, while ACCESS=NONE denies all access to a user.

 Before access to a dictionary object is granted or denied, CDO checks
 the protection defined for the object's protocol.  The access rights in
 an object's protocol indicate which access rights can be confirmed for
 the object.  Protocol access rights for an object include:  READ,
 WRITE, MODIFY, and ERASE access.  If the object's protocol includes
 READ, this means that SHOW access to the object is confirmed.
 Similarly, if the access right MODIFY is removed from the object's
 protocol, CHANGE access to the object is not confirmed; even if the
 object's ACL shows that a user has CHANGE privilege, the object cannot
 be changed unless the object's protocol confirms the access.

 The following table shows which access right must be present in an
 object's protocol to confirm the related functional access to an
 object:

 Protocol Access Right                 Purpose

 READ                   Required to confirm SHOW access to the object
 WRITE                  Required to confirm DEFINE access to the object
 MODIFY                 Required to confirm CHANGE access to the object
 ERASE                  Required to confirm DELETE access to the object

 The field and record protocols include READ, WRITE, MODIFY, and ERASE
 access by default.  This means that a user with CONTROL access can
 grant SHOW, DEFINE, CHANGE, and DELETE access to field definitions and
 record definitions and these access rights will be confirmed.

Examples

 The following command creates the second ACE for the PERSONNEL record.
 The current second ACE becomes the third ACE and all subsequent ACEs'
 position numbers are incremented by one:

 CDO> DEFINE PROTECTION RECORD PERSONNEL
 cont> POSITION 2
 cont> IDENTIFIER [JONES,DICT]+LOCAL+INTERACTIVE
 cont> ACCESS READ+WRITE+DELETE.
 CDO>

 The following command inserts a new ACE with the identifier [VCD,SMITH]
 after the ACE with the [JONES,DICT]+LOCAL+INTERACTIVE identifiers:

 CDO> DEFINE PROTECTION FOR RECORD PERSONNEL
 cont> AFTER [JONES,DICT]+LOCAL+INTERACTIVE
 cont> IDENTIFIER [VCD,SMITH] ACCESS READ.
 CDO>

 You can use wildcards to define the protection for all of the existing
 definitions in a particular directory.  The following command defines
 the fourth ACE for all current records in the BENEFITS directory.  Note
 that it does not become the default protection for definitions that are
 subsequently created.

 CDO> DEFINE PROTECTION FOR RECORD BENEFITS.*;* POSITION 4
 cont> IDENTIFIER [PERSONNEL.*] ACCESS SHOW.
 CDO>

 If you define an ACE and do not specify the POSITION clause or the
 AFTER clause, CDO places the ACE first in the ACL.  The following ACE
 denies all access rights to all users.  Such an ACE is often placed
 last in an ACL.  In this case, everyone (including the person who
 issued the command) is denied all access to the definition.  The only
 way to permit access to this definition again is to use either the
 DELETE PROTECTION or CHANGE PROTECTION command to remove or change the
 ACE:

 CDO> DEFINE PROTECTION FOR RECORD PERSONNEL
 cont> IDENTIFIER [*,*] ACCESS NONE.
 CDO>

RECORD

 Creates CDO record definitions.

 DEFINE RECORD ──> record-name ───┐
 ┌────────────────────────────────┘
 └─┬──┬──────────────────>────────────────┬──┬────┐
   │  ├─> 
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S) ─┬─> typebox (/)typebox (*) text */ ─┘  │    │
   │  └─> 
A
U
D
I
T typebox (I)typebox (S) ───────┘                  │    │
   └─────────────────────<───────────────────┘    │
 ┌──────────────────────────────<─────────────────┘
 └┬─┬──────────>───────────┬─┬> . ─┬─┬────────────>───────────┬─┬───┐
  │ └─> record-attributes ─┘ │     │ ├> included-name-clause ─┤ │   │
  └────────────<─────────────┘     │ ├> structure-clause ─────┤ │   │
                                   │ └> variant-clause ───────┘ │   │
                                   └──────────────<─────────────┘   │
   ┌───────────────────────────────<────────────────────────────────┘
   └─>
E
N
D ─┬────────>───────┬───> 
R
E
C
O
R
D ────> .
           └─> record-name ─┘

Additional information available:

record-nametextrecord-attributesincluded-name-clausestructure-clause
variant-clauseExample

record-name

 The name of the record definition you want to create.

text

 If entered with the DESCRIPTION clause, the text documents the record
 definition.  If entered with the AUDIT clause, the text becomes a
 history list entry for the record definition.

record-attributes

 A list of definitions that indicate what type of data you can store in
 the record and how CDO uses that data.  See the top-level topic
 "record-attr" for information on record attributes.

included-name-clause

 Used to include existing field definitions and record definitions
 within record definitions.

 included-name-clause=

 ───────────> name  ─┬───────────────────┬────> . ────────────────>
                     └─> aligned-clause ─┘

 aligned-clause=

 ───────────> 
A
L
I
G
N
E
D typebox (O)typebox (N) ─┬> 
B
I
T  ────────┬───> typebox (B)typebox (O)typebox (U)typebox (N)typebox (D)typebox (A)typebox (R)typebox (Y) ────────>
                          ├> 
B
Y
T
E  ───────┤
                          ├> 
W
O
R
D  ───────┤
                          ├> 
L
O
N
G
W
O
R
D ────┤
                          ├> 
Q
U
A
D
W
O
R
D ────┤
                          └> 
O
C
T
A
W
O
R
D ────┘

Additional information available:

nameExamples

name

 The name of the field definition or record definition you want to
 include in the record you are creating.  The named field definition or
 record definition must already exist in the dictionary.

Examples

 The following command creates the record definition FULL_NAME in your
 default directory using the field definitions LAST_NAME, FIRST_NAME,
 and MIDDLE_INITIAL from your default directory:

 CDO> DEFINE RECORD FULL_NAME.
 cont>   LAST_NAME.
 cont>   FIRST_NAME.
 cont>   MIDDLE_INITIAL.
 cont> END RECORD.
 CDO>

 The following DEFINE RECORD command creates a record definition
 HOME_ADDRESS in the [CORPORATE.PERSONNEL]EMPLOYEES.CONTRACT directory
 using the field definitions STREET_ADDRESS, CITY, STATE, and ZIP_CODE
 from the default directory:

 CDO> SET DEFAULT DISK1:[CORPORATE.PERSONNEL]EMPLOYEES
 CDO> DEFINE RECORD CONTRACT.HOME_ADDRESS.
 cont>   STREET_ADDRESS.
 cont>   CITY.
 cont>   STATE.
 cont>   ZIP_CODE.
 cont> END RECORD.
 CDO>

 The following DEFINE RECORD command creates a record definition
 WORKER_REC in the [CORPORATE.PERSONNEL]EMPLOYEES.CONTRACT directory
 using the record definition FULL_NAME from the default directory and
 the field definitions DATE_HIRED, HOURLY_WAGE, and COMPLETION_DATE from
 the CONTRACT directory:

 CDO> SET DEFAULT DISK1:[CORPORATE.PERSONNEL]EMPLOYEES
 CDO> DEFINE RECORD CONTRACT.WORKER_REC.
 cont>   FULL_NAME.
 cont>   CONTRACT.DATE_HIRED.
 cont>   CONTRACT.HOURLY_WAGE.
 cont>   CONTRACT.COMPLETION_DATE.
 cont> END RECORD.
 CDO>

 The following group of examples show how to create equivalent CDO
 definitions for a COBOL record containing level 88 definitions.  The
 following example shows the COBOL syntax for a record containing level
 88 definitions:

 01  COB88.
     03  C              USAGE IS COMP PIC 9(4).
     88  C_ONE          VALUE 1.
     88  C_FIVE_TEN     VALUES ARE 5 THRU 10.
     88  C_OTHER        VALUES ARE 2 THRU 4
                                   11 THRU 20.

 The following examples show the equivalent CDO syntax for the COBOL
 record in the previous example.  Each individual field that will be
 used in the record COB88 is defined, then the record itself is defined:

 CDO> DEFINE FIELD C
 cont> DATATYPE SIGNED WORD.

 CDO> DEFINE FIELD C_ONE
 cont> COMPUTED BY IF C EQ 1 THEN 1 ELSE 0.

 CDO> DEFINE FIELD C_FIVE_TEN
 cont> NAME FOR COBOL IS C_5_10
 cont> COMPUTED BY IF C GE 5 AND C LE 10 THEN 1 ELSE 0.

 CDO> DEFINE FIELD C_OTHER
 cont> COMPUTED BY IF (C GE 2 AND C LE 4) OR (C GE 11 AND C LE 20)
 cont> THEN 1 ELSE 0.

 CDO> DEFINE RECORD COB88.
 cont>  C.
 cont>  C_ONE.
 cont>  C_FIVE_TEN.
 cont>  C_OTHER.
 cont> END RECORD.
 CDO>

structure-clause

 Used to create structure definitions within record definitions.  A
 structure definition can include field definitions or record
 definitions or both.  You can use an OCCURS...DEPENDING clause within a
 structure definition to specify how many times field definitions,
 record definitions, or both will occur based on the value of another
 field definition in the same record definition as the structure
 definition.

 structure-clause=

 ─> structure-name ─> 
S
T
R
U
C
T
U
R
E ─┬─────────────>───────────────┬────┐
                                 └> 
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S) typebox (/)typebox (*) text */ ─┘    │
 ┌────────────────────────────────<─────────────────────────────────┘
 └─┬┬───────────>─────────┬─┬─> . ─┬─┬────────────>───────────┬─┬───┐
   │├> record-attributes ─┤ │      │ ├> included-name-clause ─┤ │   │
   │└> aligned clause ────┘ │      │ ├> structure-clause ─────┤ │   │
   └────────────────────────┘      │ └> variant-clause ───────┘ │   │
                                   └──────────────<─────────────┘   │
 ┌────────────────────────────<─────────────────────────────────────┘
 └> 
E
N
D ─┬─────────>────────┬──> 
S
T
R
U
C
T
U
R
E ─────> . ────>
         └> structure-name ─┘

Additional information available:

structure-nametextrecord-attributesaligned-clause
included-name-clausestructure-clausevariant-clauseExample

structure-name

 The name of the structure you are defining.

text

 Documents the structure definition.

record-attributes

 A list of definitions that indicate what type of data you can store in
 the structure and how CDO uses that data.  See the top-level topic
 "record-attr" for information on record attributes.

aligned-clause

 Aligns a field or record definition on a specified starting boundary
 relative to the start of the record you are defining.  For more
 information on the ALIGNED clause, see the subtopic
 "included-name-clause" under the "DEFINE RECORD" help topic.

included-name-clause

 Used to include existing field and record definitions within record
 definitions.

structure-clause

 Used to create structure definitions within record definitions.  This
 section describes structure definitions.

variant-clause

 Used to create variants definitions within record definitions.

Example

 In this example, the OCCURS...DEPENDING clause in the structure
 DEPENDENTS specifies that the structure DEPENDENTS will occur 1 to 10
 times based on the run-time value of field NUMBER_OF_DEPENDENTS in
 record HOUSEHOLD.

 CDO> DEFINE RECORD HOUSEHOLD.
 cont>   ANNUAL_INCOME.
 cont>   ADDRESS.
 cont>   NUMBER_OF_DEPENDENTS.
 cont>     DEPENDENTS STRUCTURE OCCURS 1 TO 10 TIMES
 cont>     DEPENDING ON NUMBER_OF_DEPENDENTS IN HOUSEHOLD.
 cont>       NAME.
 cont>       AGE.
 cont>       SEX.
 cont>     END DEPENDENTS STRUCTURE.
 cont> END HOUSEHOLD RECORD.
 CDO>

variant-clause

 Used to create variants definitions within record definitions.

 The VARIANT clause allows you to define a variants structure, which is
 a set of two or more entity definitions that map to the same portion of
 a record definition.  The VARIANT clause syntax identifies a set of
 overlays that can be used by a COBOL REDEFINES statement or by other
 languages.  Each variant can contain one or more fields, records,
 structures, variants, or any combination of these definitions.

 variant-clause=

 ─> 
V
A
R
I
A
N
T
S. ─┬─> 
V
A
R
I
A
N
T ─┬──────────────>─────────────┬─> . ──┐
               │            └> 
E
X
P
R
E
S
S
I
O
N typebox (I)typebox (S) cond-expr ──┘       │
               │ ┌─────────────────────────<─────────────────────┘
               │ └┬─┬────────────>───────────┬─┬─> 
E
N
D 
V
A
R
I
A
N
T. ───┬──┐
               │  │ ├> included-name-clause ─┤ │                   │  │
               │  │ ├> structure-clause ─────┤ │                   │  │
               │  │ └> variant-clause ───────┘ │                   │  │
               │  └──────────────<─────────────┘                   │  │
               └─────────────────────────<─────────────────────────┘  │
                 ┌──────────────────────<─────────────────────────────┘
                 └──> 
E
N
D 
V
A
R
I
A
N
T
S. ────────────────────────────────>

Additional information available:

cond-exprincluded-name-clausestructure-clausevariant-clause
Examples

cond-expr

 Must be a valid conditional expression for the product that uses the
 definition.  If one variant has an expression, each variant in the
 variants must have an expression.  Each variant's expression in the
 variants must be unique.  For more information on conditional
 expressions, see the subtopic "conditional_expr" under the top-level
 topic "expressions".

included-name-clause

 Used to include existing field and record definitions within record
 definitions.

structure-clause

 Used to create structure definitions within record definitions.

variant-clause

 Used to create variants definitions within record definitions.

Examples

 The following example shows the record PERSONNEL_RECORD, which contains
 several field definitions and a variants containing two variant
 definitions:

 CDO> DEFINE RECORD PERSONNEL_RECORD.
 cont>   FULL_NAME.
 cont>   BADGE_NO.
 cont>   DEPENDENTS.
 cont>   STATUS.
 cont>   START_DATE.
 cont> VARIANTS.
 cont>   VARIANT.
 cont>     RETIRED.
 cont>   END VARIANT.
 cont>   VARIANT.
 cont>     DISMISSED.
 cont>   END VARIANT.
 cont> END VARIANTS.
 cont> END RECORD.
 CDO>

 The following example shows the record PRODUCT_INVENTORY, which
 contains a variants with three variant definitions.  Each individual
 variant has an expression.  At run-time, the value of field FIELD_ID
 equals one of the four variant expressions and determines which
 individual variant maps to the record definition.

 CDO> DEFINE RECORD PRODUCT_INVENTORY.
 cont> FIELD_ID.
 cont>   VARIANTS.
 cont>     VARIANT EXPRESSION IS
 cont>     FIELD_ID IN PRODUCT_INVENTORY EQ "S".
 cont>       IN_STOCK STRUCTURE.
 cont>         PRODUCT_NO.
 cont>         DATE_ORDERED.
 cont>         STATUS_CODE.
 cont>         QUANTITY.
 cont>         LOCATION.
 cont>         UNIT_PRICE.
 cont>       END IN_STOCK STRUCTURE.
 cont>     END VARIANT.
 cont>     VARIANT EXPRESSION IS
 cont>     FIELD_ID IN PRODUCT_INVENTORY EQ "B".
 cont>       BACK_ORDER STRUCTURE.
 cont>         PRODUCT_NO.
 cont>         DATE_ORDERED.
 cont>         STATUS_CODE.
 cont>         QUANTITY.
 cont>         SUPPLIER.
 cont>         UNIT_PRICE.
 cont>       END BACK_ORDER STRUCTURE.
 cont>     END VARIANT.
 cont>     VARIANT EXPRESSION IS
 cont>     FIELD_ID IN PRODUCT_INVENTORY EQ "O".
 cont>       OUT_OF_STOCK STRUCTURE.
 cont>         PRODUCT_NO.
 cont>         DATE_LAST_SOLD.
 cont>       END OUT_OF_STOCK STRUCTURE.
 cont>     END VARIANT.
 cont>   END VARIANTS.
 cont> END RECORD.
 CDO>

Example

 The following command creates a record definition called
 EDUCATION_RECORD:

 CDO> DEFINE RECORD EDUCATION_RECORD.
 cont>   BADGE_NUMBER.
 cont>   BACHELOR_DEGREE.
 cont>   MASTER_DEGREE.
 cont>   DOCTORATE_DEGREE.
 cont> END RECORD.
 CDO>

RMS_DATABASE

 Creates a logical RMS database definition.

 DEFINE_RMSDATABASE ────────>  rms-database-name   ───────────────────┐
 ┌─────────────────────────────────<───────────────────────────────────┘
 └───┬┬─────────────────────>─────────────────┬──┬───> . ──────────────┐
     │├> 
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S)  ─┬───>  typebox (/)typebox (*) text */ ──┘  │                     │
     │└> 
A
U
D
I
T typebox (I)typebox (S)  ───────┘                      │                     │
     └──────────────────────<────────────────────┘                     │
 ┌──────────────────────────────────<──────────────────────────────────┘
 └> 
R
E
C
O
R
D record-name.────────────>  file-definition-clause  ─────────┐
 ┌──────────────────────────────────<──────────────────────────────────┘
 └─┬──────────────>────────────┬───────┬──────────────>────────────┬───┐
   └> area-definition-clause ──┘       └> keys-definition-clause ──┘   │
 ┌──────────────────────────────────<──────────────────────────────────┘
 └────> 
E
N
D ───┬────────────>────────┬─────┬─────────>──────┬────────> .
               └> rms-database-name ─┘     └> 
R
M
S
D
A
T
A
B
A
S
E ─┘

Additional information available:

rms-database-nametextrecord-namefile-definition-clausearea-definition-clause
keys-definition-clauseExamples

rms-database-name

 The name of the RMS database description.

text

 Documents the database definition.  If entered with the AUDIT clause,
 the text becomes a history list entry for the RMS database definition.

record-name

 The name of an existing record definition in the dictionary.

file-definition-clause

 Defines the file and record services within the RMS database
 definition.

 file-definition-clause=

 ─> 
F
I
L
E
D
E
F
I
N
I
T
I
O
N ─┬─┬───────────────>───────────────┬─┬─> .
                     │ └─> file-definition-attributes ─┘ │
                     └─────────────────<─────────────────┘

Additional information available:

file-definition-attributesExamples

file-definition-attributes

 Specify the particular file service for an RMS database definition.
 See the top-level topic "file-def-attr" for a description and diagram.

Examples

 The following example shows a file definition clause for an RMS
 database definition:

 CDO> DEFINE RMS_DATABASE EMPLOYEE_STORAGE.
 cont> RECORD EMPLOYEE_REC.
 cont>     FILE_DEFINITION
 cont>        ALLOCATION 200
 cont>        FILE_PROCESSING_OPTIONS CONTIGUOUS
 cont>        ORGANIZATION INDEXED.
               .
               .
               .
 cont> END EMPLOYEE_STORAGE RMS_DATABASE.
 CDO>

 The following example shows the file definition clause for the RMS
 database definition EMPLOYEE_INFORMATION:

 CDO>  DEFINE RMS_DATABASE EMPLOYEE_INFORMATION
 cont>  AUDIT /* STORAGE FOR EMPLOYEE INFORMATION */.
              .
              .
              .
 cont>       FILE_DEFINITION
 cont>           GLOBAL_BUFFER_COUNT 5
 cont>           ORGANIZATION INDEXED
 cont>           ACCESS BLOCK_IO, RECORD_IO.
              .
              .
              .
 cont>  END EMPLOYEE_INFORMATION RMS_DATABASE.
 CDO>

area-definition-clause

 Defines the area attributes within the RMS database definition.

 area-definition-clause=

 ─> 
A
R
E
A
S. ─┬─> 
A
R
E
A numeric-literal ─┬───────────>─────────┬─┬─> . ─┐
            │                         └┬> area-attributes ─┬┘ │      │
            │                          └──────────<────────┘  │      │
            └────────────────────────<────────────────────────┘      │
 ┌─────────────────────────────────────<─────────────────────────────┘
 └─>  
E
N
D.

Additional information available:

numeric-literalarea-attributesExamples

numeric-literal

 A positive integer that is the name of the area.  See the reference
 manual for VAX Record Management Services in the VAX/VMS documentation
 set for valid values.

area-attributes

 Specify the particular type of space allocation on disk for an RMS
 database definition.  See the top-level topic "area-attributes" for a
 description and diagram.

Examples

 The following example shows the area definition clause for the RMS
 database definition EMPLOYEE_STORAGE:

 CDO> DEFINE RMS_DATABASE EMPLOYEE_STORAGE.
 cont>       .
 cont>       .
 cont>       .
 cont>     AREAS.
 cont>         AREA 0
 cont>             ALLOCATE 10
 cont>             BUCKET_SIZE 5
 cont>             EXTENSION 7.
 cont>         AREA 1
 cont>             ALLOCATE 15
 cont>             BUCKET_SIZE 3
 cont>             EXTENSION 11.
 cont>         AREA 2
 cont>             ALLOCATE 20
 cont>             BUCKET_SIZE 7.
 cont>     END.
 cont>       .
 cont>       .
 cont>       .
 cont> END EMPLOYEE_STORAGE RMS_DATABASE.
 CDO>

 The following example shows the area definition clause for the RMS
 database definition EMPLOYEE_INFORMATION:

 CDO> DEFINE RMS_DATABASE EMPLOYEE_INFORMATION
 cont>    AUDIT /* STORAGE FOR EMPLOYEE INFORMATION */.
 cont>      .
 cont>      .
 cont>      .
 cont>        AREAS.
 cont>            AREA 0
 cont>                EXTENSION 70
 cont>                ALLOCATE 150
 cont>                BUCKET_SIZE 10
 cont>                BEST_TRY_CONTIGUOUS.
 cont>            AREA 1
 cont>                EXTENSION 70
 cont>                ALLOCATE 150
 cont>                BUCKET_SIZE 10
 cont>                BEST_TRY_CONTIGUOUS.
 cont>            AREA 2
 cont>                EXTENSION 70
 cont>                ALLOCATE 150
 cont>                BUCKET_SIZE 10
 cont>                BEST_TRY_CONTIGUOUS.
 cont>            AREA 3
 cont>                EXTENSION 70
 cont>                ALLOCATE 150
 cont>                BUCKET_SIZE 10
 cont>                BEST_TRY_CONTIGUOUS.
 cont>        END AREAS.
 cont>      .
 cont>      .
 cont>      .
 cont> END EMPLOYEE_INFORMATION RMS_DATABASE.
 CDO>

keys-definition-clause

 Defines the keys of an indexed file within the RMS database definition.

 keys-definition-clause=

 ─> 
K
E
Y
S. ─┬─> 
K
E
Y numeric-literal ─┬──────────>─────────┬─┬> . ─┐
           │                        └┬> key-attributes ─┬┘ │     │
           │                         └─────────<────────┘  │     │
           └───────────────────────<───────────────────────┘     │
 ┌────────────────────────────────────<──────────────────────────┘
 └─>  
E
N
D.

Additional information available:

numeric-literalkey-attributesExamples

numeric-literal

 A positive integer.  See the reference manual for VAX Record Management
 Services in the VAX/VMS documentation set for valid values.

key-attributes

 Define the characteristics of a key in an indexed file.  See the
 top-level topic "key-attributes" for a description and diagram.

Examples

 The following example shows the keys definition clause for the RMS
 database definition EMPLOYEE_STORAGE:

 CDO> DEFINE RMS_DATABASE EMPLOYEE_STORAGE.
 cont>     .
 cont>     .
 cont>     .
 cont>     KEYS.
 cont>       KEY 0
 cont>           CHANGES
 cont>           DUPLICATES
 cont>           SEGMENT LAST_NAME.
 cont>      KEY 1
 cont>           CHANGES
 cont>           SEGMENT EMP_ID.
 cont>     END.
 cont>     .
 cont>     .
 cont>     .
 cont> END EMPLOYEE_STORAGE RMS_DATABASE.
 CDO>

 The following example shows the keys definition clause for the RMS
 database definition EMPLOYEE_INFORMATION:

 CDO>  DEFINE RMS_DATABASE EMPLOYEE_INFORMATION
 cont> AUDIT /* STORAGE FOR EMPLOYEE INFORMATION */.
 cont>       .
 cont>       .
 cont>       .
 cont>       KEYS
 cont>          KEY 0
 cont>             DUPLICATES
 cont>             DATA_AREA
 cont>             INDEX_AREA 1
 cont>             LEVEL1_INDEX_AREA 1
 cont>             SEGMENT LAST_NAME.
 cont>          KEY 1
 cont>             DATA_AREA 2
 cont>             INDEX_AREA 2
 cont>             LEVEL1_INDEX_AREA 2
 cont>             SEGMENT EMP_ID.
 cont>       END KEYS.
 cont> END EMPLOYEE_INFORMATION RMS_DATABASE.
 CDO>

Examples

 The following example shows how to create an RMS database definition in
 the dictionary for a company that wants a standardized way for its
 departments to maintain a database of current employees.

 First, the company defines a record, EMPLOYEE_REC, in the dictionary.
 Next, an RMS database definition called EMPLOYEE_STORAGE is created
 using the DEFINE RMS_DATABASE command.  Each department then uses the
 DEFINE DATABASE command to create their own physical RMS database on
 disk.

 CDO> DEFINE FIELD LAST_NAME DATATYPE TEXT 30.
 CDO> DEFINE FIELD FIRST_NAME DATATYPE TEXT 20.
 CDO> DEFINE FIELD EMP_ID DATATYPE UNSIGNED LONGWORD.
 CDO> DEFINE RECORD EMPLOYEE_REC.
 cont>   LAST_NAME.
 cont>   FIRST_NAME.
 cont>   EMP_ID.
 cont> END.
 CDO>

 CDO> DEFINE RMS_DATABASE EMPLOYEE_STORAGE.
 cont>  RECORD EMPLOYEE_REC.
 cont>     FILE_DEFINITION
 cont>       ALLOCATION 200
 cont>       FILE_PROCESSING_OPTIONS CONTIGUOUS
 cont>       ORGANIZATION INDEXED.
 cont>     AREAS
 cont>       AREA 0
 cont>           ALLOCATE 10
 cont>            BUCKET_SIZE 5
 cont>            EXTENSION 7.
 cont>        AREA 1
 cont>            ALLOCATE 15
 cont>             BUCKET_SIZE 3
 cont>             EXTENSION 11.
 cont>         AREA 2
 cont>             ALLOCATE 20
 cont>             BUCKET_SIZE 7.
 cont>     END.
 cont>     KEYS.
 cont>         KEY 0
 cont>             CHANGES
 cont>             DUPLICATES
 cont>             SEGMENT LAST_NAME IN EMPLOYEE_REC.
 cont>        KEY 1
 cont>             CHANGES
 cont>             SEGMENT EMP_ID IN EMPLOYEE_REC.
 cont>     END.
 cont> END.
 CDO>

 CDO> DEFINE DATABASE DISG_FILE USING EMPLOYEE_STORAGE
 cont> ON USR02:[DISG]EMP.DAT.

 CDO> DEFINE DATABASE SSG_FILE USING EMPLOYEE_STORAGE ON
 cont> USR05:[SSG]EMP.DAT.

 CDO> DEFINE DATABASE DBS_FILE USING EMPLOYEE_STORAGE ON
 cont> USR04:[DBS]EMP.DAT.
 CDO>

 The following example shows an RMS database definition that uses the
 record EMPLOYEE_DATA and specifies 3 areas and 2 keys (LAST_NAME and
 EMP_ID):

 CDO>  DEFINE RMS_DATABASE EMPLOYEE_INFORMATION
 cont> AUDIT /* STORAGE FOR EMPLOYEE INFORMATION */.
 cont>    RECORD EMPLOYEE_DATA.
 cont>       FILE_DEFINITION
 cont>           GLOBAL_BUFFER_COUNT 5
 cont>           ORGANIZATION INDEXED
 cont>           ACCESS BLOCK_IO, RECORD_IO.
 cont>       AREAS.
 cont>           AREA 0
 cont>              EXTENSION 70
 cont>              ALLOCATE 150
 cont>              BUCKET_SIZE 10
 cont>              BEST_TRY_CONTIGUOUS.
 cont>           AREA 1
 cont>              EXTENSION 70
 cont>              ALLOCATE 150
 cont>              BUCKET_SIZE 10
 cont>              BEST_TRY_CONTIGUOUS.
 cont>           AREA 2
 cont>               EXTENSION 70
 cont>               ALLOCATE 150
 cont>               BUCKET_SIZE 10
 cont>               BEST_TRY_CONTIGUOUS.
 cont>           AREA 3
 cont>               EXTENSION 70
 cont>               ALLOCATE 150
 cont>               BUCKET_SIZE 10
 cont>               BEST_TRY_CONTIGUOUS.
 cont>       END AREAS.
 cont>       KEYS
 cont>          KEY 0
 cont>             DUPLICATES
 cont>             DATA_AREA
 cont>             INDEX_AREA 1
 cont>             LEVEL1_INDEX_AREA 1
 cont>             SEGMENT LAST_NAME EMPLOYEE_DATA.
 cont>          KEY 1
 cont>             DATA_AREA 2
 cont>             INDEX_AREA 2
 cont>             LEVEL1_INDEX_AREA 2
 cont>             SEGMENT EMP_ID EMPLOYEE_DATA.
 cont>       END KEYS.
 cont> END EMPLOYEE_INFORMATION RMS_DATABASE.
 CDO>

 Use the DIRECTORY command to verify that the RMS database definition
 EMPLOYEE_STORAGE is in the dictionary:

 CDO> DIR
  Directory USR02:[MCGUIRE.DICT]
 CDD$PROTOCOLS                                   DIRECTORY
 EMPLOYEE_DATA;1                                 RECORD
 EMPLOYEE_INFORMATION;1                          CDD$RMS_DATABASE
 EMPLOYEE_REC;1                                  RECORD
 EMPLOYEE_STORAGE;1                              CDD$RMS_DATABASE
 EMP_ID;1                                        FIELD
 FIRST_NAME;1                                    FIELD
 LAST_NAME;1                                     FIELD
 CDO>

 Use the SHOW RMS_DATABASE command to show the brief definition of
 EMPLOYEE_INFORMATION:

 CDO> SHOW RMS_DATABASE EMPLOYEE_INFORMATION
 Definition of RMS database  EMPLOYEE_INFORMATION
 |   database uses record EMPLOYEE_DATA
 |   file definition
 |   |   file global buffer count 5
 |   |   file organization index sequential
 |   |   key 0
 |   |   |   key duplicates
 |   |   |   key data area 0
 |   |   |   key index area 1
 |   |   |   key level1 index area 1
 |   |   |   segment LAST_NAME IN EMPLOYEE_REC
 |   |   key 1
 |   |   |   key data area 2
 |   |   |   key index area 2
 |   |   |   key level1 index area 2
 |   |   |   segment EMP_ID IN EMPLOYEE_REC
 |   |   storage area 0
 |   |   |   area allocation 150
 |   |   |   area bucket size 10
 |   |   |   area contiguous best try
 |   |   |   area extension 70
 |   |   storage area 1
 |   |   |   area allocation 150
 |   |   |   area bucket size 10
 |   |   |   area contiguous best try
 |   |   |   area extension 70
 |   |   storage area 2
 |   |   |   area allocation 150
 |   |   |   area bucket size 10
 |   |   |   area contiguous best try
 |   |   |   area extension 70
 |   |   storage area 3
 |   |   |   area allocation 150
 |   |   |   area bucket size 10
 |   |   |   area contiguous best try
 |   |   |   area extension 70
 CDO>

 The RMS_DATABASE definitions created from the following two commands
 are the basis of the examples shown in the top-level topics
 "area-attributes", "file-def-attr", and "key-attributes" and any
 subtopics of those topics.

 The following command creates the RMS_DATABASE definition
 EMPLOYEE_INFO:
 CDO>  DEFINE RMS_DATABASE EMPLOYEE_INFO DESCRIPTION IS "INFORMATION"
 cont> "ON CURRENT EMPLOYEE".
 cont>      RECORD EMPLOYEE_REC.
 cont>      FILE_DEFINITION
 cont>          ORGANIZATION INDEXED
 cont>          CHANNEL_ACCESS_MODE SUPER
 cont>          CARRIAGE_CONTROL CARRIAGE_RETURN
 cont>          ACCESS  RECORD_IO
 cont>          FILE_PROCESSING_OPTIONS BEST_TRY_CONTIGUOUS
 cont>          FORMAT VARIABLE
 cont>          SHARING GET, USER_INTERLOCK.
 cont>      AREAS.
 cont>          AREA 0
 cont>              ALLOCATE 1000
 cont>              BUCKET_SIZE 10
 cont>              EXTENSION 100
 cont>              CONTIGUOUS.
 cont>          AREA 1
 cont>              ALLOCATE 1000
 cont>              BUCKET_SIZE 1
 cont>              EXTENSION 100
 cont>              BEST_TRY_CONTIGUOUS.
 cont>          AREA 2
 cont>              ALLOCATE 1000
 cont>              BUCKET_SIZE 1
 cont>              EXTENSION 100
 cont>              BEST_TRY_CONTIGUOUS.
 cont>      END AREAS.
 cont>      KEYS.
 cont>          KEY 0
 cont>              DATA_AREA 0
 cont>              INDEX_AREA 0
 cont>              SEGMENT EMP_ID IN EMPLOYEE_REC.
 cont>          KEY 1
 cont>              DUPLICATES
 cont>              DATA_AREA 1
 cont>              INDEX_AREA 2
 cont>              SEGMENT LAST_NAME IN EMPLOYEE_REC.
 cont>      END KEYS.
 cont> END EMPLOYEE_INFO RMS_DATABASE.
 CDO>

 The following command creates the RMS database definition
 MORE_EMPLOYEE_INFO:

 CDO>  DEFINE RMS_DATABASE MORE_EMPLOYEE_INFO DESCRIPTION IS "DATA"
 cont> "ON CURRENT EMPLOYEES ".
 cont>      RECORD EMPLOYEE_REC.
 cont>      FILE_DEFINITION
 cont>          ORGANIZATION INDEXED
 cont>          FOP CREATE_IF, DEFERRED_WRITE
 cont>          ACCESS GET
 cont>          SHARING GET
 cont>          BLOCK_SPAN
 cont>          FORMAT FIXED.
 cont>      AREAS.
 cont>          AREA 0
 cont>              ALLOCATE 1000
 cont>              BUCKET_SIZE 10
 cont>              EXTENSION 100
 cont>              CONTIGUOUS.
 cont>          AREA 1
 cont>              ALLOCATE 1000
 cont>              BUCKET_SIZE 1
 cont>              EXTENSION 100
 cont>              BEST_TRY_CONTIGUOUS
 cont>              POSITION NONE.
 cont>          AREA 2
 cont>              ALLOCATE 1000
 cont>              BUCKET_SIZE 1
 cont>              EXTENSION 100
 cont>              BEST_TRY_CONTIGUOUS.
 cont>      END AREAS.
 cont>      KEYS.
 cont>          KEY 0
 cont>              DATA_AREA 0
 cont>              INDEX_AREA 0
 cont>              SEGMENT EMP_ID IN EMPLOYEE_REC.
 cont>          KEY 1
 cont>              DUPLICATES
 cont>              CHANGES
 cont>              DATA_AREA 1
 cont>              INDEX_AREA 2
 cont>              SEGMENT LAST_NAME IN EMPLOYEE_REC.
 cont>      END KEYS.
 cont> END MORE_EMPLOYEE_INFO RMS_DATABASE.
 CDO>

Museum

Related Articles

CDD/Plus CDO DEFINE — VMS CDD+_4.1A

DATABASE

database-name

text

rms-database-name

vms-file-name

Examples

DICTIONARY

anchor-directory

Example

DIRECTORY

directory-name

Examples

FIELD

field-name

text

field-attributes

Examples

GENERIC

protocol-name

entity-name

text

attribute-name

n

quoted-string

relationship-name

relationship-mbr-options

relationship-mbr-name

protocol-name

entity-name

text

attribute-name

n

quoted-string

relationship-name

relationship-mbr-options

Examples

Example

KEY

key-name

key-equivalence

Qualifiers

/ECHO

/IF_STATE=state-name

/LOCK_STATE

/PROTECTED

/SET_STATE=state-name

/TERMINATE

Examples

PROTECTION

protocol-name

object-name

n

id1

id2

right

Identifiers

UIC Identifiers

General Identifiers

System-Defined Identifiers

Access Rights

Examples

RECORD

record-name

text

record-attributes

included-name-clause

name

Examples

structure-clause

structure-name

text

record-attributes

aligned-clause

included-name-clause

structure-clause

variant-clause

Example