1 – COLLECTION
Format
DEFINE COLLECTION collection-name
[ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ] .
1.1 – Parameters
1.1.1 – collection-name
Specifies the collection you are creating.
1.1.2 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the collection; within the AUDIT clause,
it is a history list entry. Valid delimiters are /* */ or double
quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
1.2 – Description
The DEFINE COLLECTION command creates a collection. A collection
allows you to view and manipulate a group of related elements
that make up a particular system or subsystem.
Because a collection is a controlled element, you use the DEFINE
COLLECTION command to create the initial version of a collection.
Use the RESERVE and REPLACE commands to create new versions.
Before you issue the DEFINE COLLECTION command, you must create
and set a context. The SHOW CONTEXT command indicates whether you
have completed these steps.
Because all elements in a collection hierarchy are children
of the top collection, you can issue commands that affect the
entire hierarchy with the /DESCENDANTS or /CLOSURE qualifiers.
Because most elements in a collection hierarchy are also children
of smaller subcollections beneath the top collection, you can
also issue commands that affect only one subcollection and its
children.
To create a collection hierarchy, issue the DEFINE COLLECTION
command immediately after the SET CONTEXT command. SET CONTEXT
implicitly sets the collection you define as the top collection
in the hierarchy, provided that you did not set a top collection
within the DEFINE CONTEXT command.
To extend the hierarchy beneath the top collection, you issue the
following commands:
1. DEFINE COLLECTION to create the collections that participate
in the hierarchy. This command attaches all collections in the
first level beneath the top collection.
2. DETACH FROM COMPOSITE to detach those collections destined for
lower levels in the hierarchy from the first level beneath the
top collection.
3. RESERVE and ATTACH TO COMPOSITE to reserve collections in each
successive level and attach their immediate children.
4. REPLACE to store in a partition the elements you have created.
1.3 – Examples
1.CDO> DEFINE COLLECTION REGIONAL_SALES.
In this example, the DEFINE COLLECTION command creates the
REGIONAL_SALES collection.
2.CDO> DEFINE PARTITION FIRST_BASELEVEL. 1
CDO> DEFINE CONTEXT DEVELOPMENT_CONTEXT
cont> BASE_PARTITION FIRST_BASELEVEL.
CDO> SET CONTEXT DEVELOPMENT_CONTEXT
CDO> DEFINE COLLECTION COMPILER_C. 2
CDO> RESERVE COLLECTION COMPILER_C
CDO> DEFINE COLLECTION FRONT_END. 3
CDO> DEFINE COLLECTION BACK_END.
CDO> DEFINE COLLECTION PARSER.
CDO> DEFINE FILE_ELEMENT MCS_BINARY PARSER_TABLES
cont> STORETYPE EXTERNAL
cont> MCS_STOREDIN IS "CDD$DISK:[SMITH]PARSER_TABLES.DAT".
cont> END FILE_ELEMENT MCS_BINARY PARSER_TABLES.
CDO> DETACH COLLECTION PARSER FROM COMPILER_C 4
CDO> DETACH FILE_ELEMENT PARSER_TABLES FROM
cont> COMPILER_C
CDO> RESERVE COLLECTION FRONT_END
CDO> ATTACH COLLECTION PARSER TO FRONT_END 5
CDO> RESERVE COLLECTION PARSER
CDO> ATTACH FILE_ELEMENT PARSER_TABLES TO PARSER
CDO> REPLACE COLLECTION /CLOSURE=TO_TOP PARSER
The successive DEFINE COLLECTION commands in this example
participate in the creation of a collection hierarchy.
1 DEFINE PARTITION, DEFINE CONTEXT, and SET CONTEXT commands
allow you to control elements.
2 DEFINE COLLECTION command creates the collection; this
command also sets COMPILER_C as the top collection because
the current context, DEVELOPMENT_CONTEXT, does not have a
top collection defined.
3 DEFINE COLLECTION commands create subcollections FRONT_END,
BACK_END, and PARSER and file element PARSER_TABLES under
collection COMPILER_C.
4 DETACH commands detach PARSER and PARSE_TABLES from
collection COMPILER_C.
5 ATTACH commands attach PARSER under subcollection FRONT_END
and PARSE_TABLES under subcollection PARSER.
2 – CONTEXT
Format
DEFINE CONTEXT context-name
[ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ]
BASE_PARTITION IS partition-name
[ TOP IS collection-name ]
[ {SPECIFIC_VERSION } ]
[ DEFAULT_ATTACHMENT IS {LATEST_CHECKIN } ] .
[ {LATEST } ]
[ { } ]
2.1 – Parameters
2.1.1 – context-name
Specifies the context you are creating.
2.1.2 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the context; within the AUDIT clause,
it is a history list entry. Valid delimiters are /* */ or double
quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
2.1.3 – partition-name
Specifies the base partition of the partition hierarchy.
2.1.4 – collection-name
Specifies the top collection of the collection hierarchy.
2.2 – Description
The DEFINE CONTEXT command creates a context. A context allows
you to restrict or expand your view of the system and set the
characteristics associated with your work environment.
The BASE_PARTITION clause sets the base partition property to
the partition name you specify. Use the DEFINE PARTITION command
to create this partition prior to issuing the DEFINE CONTEXT
command.
The TOP clause sets the top collection property to the collection
name you specify. Include this clause only when you are
redefining the top collection property for an existing context.
See the DEFINE COLLECTION command for more information on setting
this property for a new context.
The DEFAULT_ATTACHMENT clause defines the default attachment
property for the context. This property refers to the default
behavior that occurs when you issue the UPDATE command. Choose
one of the following keywords:
DEFAULT_
ATTACHMENT
Keyword Behavior
LATEST Detaches the version currently attached and
attaches the lastest version, whether checked in
or ghost.
LATEST_CHECKIN Detaches the version currently attached and
attaches the version most recently checked in.
SPECIFIC_ Does not detach the version currently attached.
VERSION
If you do not specify the DEFAULT_ATTACHMENT clause, CDO creates
the context with LATEST default attachment, by default.
2.3 – Examples
CDO> DEFINE CONTEXT SALES
cont> BASE_PARTITION IS FIRST_QUARTER
cont> DEFAULT_ATTACHMENT IS LATEST_CHECKIN.
In this example, the DEFINE CONTEXT command creates the SALES
context. The BASE_PARTITION clause sets the base partition
property to the previously defined FIRST_QUARTER partition. The
keyword LATEST_CHECKIN in the DEFAULT_ATTACHMENT clause sets
the default attachment property for the context to the version
most recently checked in.
See the DEFINE COLLECTION command for more information on
setting the top collection property for a context.
3 – DATABASE
Format
DEFINE DATABASE database-name
[ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ]
USING rms-database-name ON file-name [ qualifier ] .
3.1 – Parameters
3.1.1 – database-name
Specifies the database element you are creating.
3.1.2 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the database; within the AUDIT clause,
it is a history list entry. Valid delimiters are /* */ or double
quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
3.1.3 – rms-database-name
Specifies an existing logical RMS database element. It must be
the name of an existing CDD$RMS_DATABASE element.
3.1.4 – file-name
Specifies the location on disk of the physical OpenVMS file that
holds the physical RMS database. It is a character string having
from 1 to 1024 characters.
3.2 – Qualifiers
3.2.1 /EXISTING_FILE
Specifies that an RMS file exists and does not need to be
created.
3.3 – Description
The DEFINE DATABASE command creates a physical RMS database on
disk using an RMS database element. If the command completes
successfully, DEFINE DATABASE creates a CDD$DATABASE element
(with the database name you specified) and a CDD$FILE element
(with the OpenVMS file name you specified) in your directory.
If the RMS database element is a controlled element, you use
the DEFINE DATABASE command to create the initial version of a
database. Use the RESERVE and REPLACE commands to create new
versions.
If the RMS database element is an uncontrolled element, you
use the DEFINE DATABASE command to create both initial and new
versions.
If you supply a database name that is already used for a database
element in your specified directory, you will create a new
version of the existing database definition.
This command allows you to create many different physical RMS
databases using the same logical RMS database element. You can
specify a different location on disk for each database with an
OpenVMS file name.
As of Oracle CDD/Repository Version 6.1, the DEFINE DATABASE
command supports unsigned numeric and ADT fields as keys in RMS
databases.
If the database name does not specify a full path name, CDO
creates the database definition in your current default
directory. CDO attempts to translate the database name you supply
to determine if it is a valid logical name. If it is a logical
name and CDO cannot translate the logical name to a valid path
name, the operation fails.
3.4 – Examples
1.CDO> DEFINE DATABASE DISG_FILE USING EMPLOYEE_STORAGE
cont> ON DISK1:[DISG]EMP.DAT.
In this example, the DEFINE DATABASE command creates the
physical DISG_FILE RMS database in the OpenVMS EMP.DAT file on
disk, using the logical EMPLOYEE_STORAGE RMS database element.
2.CDO> DEFINE DATABASE EMPLOYEES
cont> AUDIT IS /* INFORMATION ON CURRENT "EMPLOYEES" */
cont> USING EMPLOYEE_DATABANK ON DISK2:[SMITH]MORE_EMP.DATA.
In this example, the DEFINE DATABASE command creates the
physical EMPLOYEES RMS database on disk in the OpenVMS
MORE_EMP.DATA file, using the EMPLOYEE_DATABANK RMS database
element.
4 – DICTIONARY
See the DEFINE REPOSITORY command.
5 – DIRECTORY
Format
DEFINE DIRECTORY directory-name .
5.1 – Parameters
5.1.1 – directory-name
Specifies the directory you are creating.
5.2 – Description
The DEFINE DIRECTORY command creates a CDO repository directory.
DEFINE DIRECTORY evaluates the directory name you supply to
determine if it is a logical name. If the directory name is a
logical name, CDO translates it. If the translation is not a
valid name for a directory, CDO does not create the directory.
CDO automatically creates any directories in the path name of the
directory-name parameter that do not already exist.
5.3 – Examples
1.CDO> DEFINE DIRECTORY NODE::DISK1:[BOB.DICT]TOP.
In this example, the DEFINE DIRECTORY command creates
a directory called TOP under the repository anchor
NODE::DISK1:[BOB.DICT].
Or, you can define the directory TOP by setting default to
the repository anchor DISK1:[BOB.DICT] then issuing the DEFINE
DIRECTORY command.
2.CDO> DEFINE DIRECTORY DISK1:[BOB.DICT]PERSONNEL.EMPLOYEES.BENEFITS.
In this example, the DEFINE DIRECTORY command creates the
BENEFITS directory three levels below the CDO repository anchor
DISK1:[BOB.DICT].
Oracle CDD/Repository will create the intermediate directories
if they do not already exist.
6 – FIELD
Format
DEFINE FIELD field-name
[ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ]
[ field-property ] ... .
6.1 – Parameters
6.1.1 – field-name
Specifies the field element you are creating.
6.1.2 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the field element; within the AUDIT
clause, it is a history list entry. Valid delimiters are /* */
or double quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
6.1.3 – field-property
Adds a property to the field element. See fld-properties for the
field properties CDO provides.
6.2 – Description
The DEFINE FIELD command creates a field element.
If the field element is controlled, you use the DEFINE FIELD
command to create the initial version of the element. Use the
RESERVE and REPLACE commands to create new versions.
If the field element is uncontrolled, use the DEFINE FIELD
command to create both initial and new versions.
You can create a field element in a directory other than your
default directory by specifying the appropriate path name.
If you supply a field name that is already used for a field
element in your default directory, CDO creates a new version
of the existing field definition.
The DEFINE FIELD command evaluates the field name you supply to
determine if it is a logical name. If the field name is a logical
name, CDO translates it. In some cases, the translation of the
logical name for the field name may not be a valid name for a
field definition, and CDO will not create the field definition.
For example, if you have defined JOE as a logical name that
translates to MYNODE::[RICHIE], CDO translates the symbol JOE.
The following DEFINE FIELD command fails because MYNODE::[RICHIE]
is not a valid field name:
CDO> DEFINE FIELD JOE.
%CDO-F-ERRDEFINE, error defining object
-CDD-F-NOTADIC, Does not contain an Oracle CDD/Plus dictionary:
MYNODE::
If this error occurs, deassign the logical name with the same
name as the object, and perform the operation again. To avoid
this logical name conflict, use unique names that represent the
type of entity you are naming.
6.3 – Examples
1.CDO> DEFINE FIELD POSTAL_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.
In this example, the DEFINE FIELD command creates the POSTAL_
CODE field element.
2.CDO> DEFINE FIELD SEX
cont> DATATYPE IS TEXT SIZE IS 1
cont> VALID IF SEX = "M" OR SEX = "F".
In this example, the DEFINE FIELD command creates the SEX field
element. The VALID IF field property returns an error if you
attempt to store a value other than M or F in the field that
refers to this element.
7 – FILE_ELEMENT
Format
DEFINE FILE_ELEMENT type-name element-name
[ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ]
[ STORETYPE INTERNAL ]
[ STORETYPE EXTERNAL MCS_STOREDIN IS quoted-string ]
[ ]
[ MCS_IMPORTED FROM quoted-string ]
[ {n } ]
[ property-name IS {quoted-string } ] ... .
[ { } ]
END [ FILE_ELEMENT ] type-name [ element-name ] .
7.1 – Parameters
7.1.1 – type-name
Specifies the type (MCS_BINARY or an MCS_BINARY subtype) of the
file element you are creating. See the Oracle CDD/Repository
Information Model Volume I for more information on these types.
7.1.2 – element-name
Specifies the file element you are creating.
7.1.3 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the file element; within the AUDIT
clause, it is a history list entry. Valid delimiters are /* */
or double quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
7.1.4 – quoted-string
Sets the value (a string enclosed in quotation marks) for the
property you are specifying.
7.1.5 – property-name
Specifies the property whose value you are setting.
7.1.6 – n
Sets the numeric value for a property.
7.2 – Description
The DEFINE FILE_ELEMENT command creates a file element.
Before you issue the DEFINE FILE_ELEMENT command, you must define
and set a context. The SHOW CONTEXT command indicates whether you
have completed these steps.
You control file element definitions as soon as you define them.
To do this, issue the following commands before you define a file
element:
1. DEFINE PARTITION, which creates a partition
2. DEFINE CONTEXT, which associates this partition with a
specific context
3. SET CONTEXT, which identifies this context as the current
context and implicitly controls all subsequent definitions
Since a file element is a controlled element, the DEFINE FILE_
ELEMENT command creates the initial version of the file element.
The RESERVE and REPLACE commands create new versions.
The STORETYPE clause indicates whether or not the file is stored
internally (in Oracle CDD/Repository) or externally. If you do
not specify STORETYPE, the default is external.
If you add, change, or delete a property from the file element,
the property you specify must be a defined or inherited property
for the file element's type. See the Oracle CDD/Repository
Information Model, Volume I for a list of these properties.
Errors occur if you do not specify the MCS_STOREDIN property for
a file element whose STORETYPE is EXTERNAL. CDO requires this
property for external files.
7.3 – Examples
CDO> DEFINE FILE_ELEMENT MCS_BINARY PARSER_TABLES
cont> STORETYPE EXTERNAL
cont> MCS_STOREDIN IS "CDD$DISK:[SMITH]PARSER_TABLES.DAT".
cont> END FILE_ELEMENT MCS_BINARY PARSER_TABLES.
In this example, the DEFINE FILE_ELEMENT command includes a
STORETYPE EXTERNAL clause. CDO creates an external file element
PARSER_TABLES stored in CDD$DISK:[SMITH]PARSER_TABLES.DAT.
8 – GENERIC Command
Format
DEFINE GENERIC type-name element-name
[ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ]
[ {n } ]
[ property-name IS {quoted-string } ] ... .
[ { } ]
[RELATIONSHIPS. ]
[ {RELATIONSHIP relationship-name } ]
[ { } ]
[ { relationship-mbr-options } ]
[ { [ {n }] } ]
[ { [property-name IS {quoted-string}] ... . } ... ]
[ { [ { }] } ]
[ { } ]
[ { END relationship-name RELATIONSHIP . } ]
[ END RELATIONSHIPS . ]
[ ]
END [ GENERIC type-name element-name ] .
8.1 – Parameters
8.1.1 – type-name
Specifies the type of the generic element you are defining.
8.1.2 – element-name
Specifies the generic element you are defining.
8.1.3 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the generic element; within the AUDIT
clause, it is a history list entry. Valid delimiters are /* */ or
double quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
8.1.4 – property-name
Specifies a property.
8.1.5 – n
Sets the numeric value for a property.
8.1.6 – quoted-string
Sets the value (a string enclosed in quotation marks) for a
property.
8.1.7 – relationship-name
Specifies the relationship that you are defining for the generic
element. The type must be a subtype of RELATION.
8.1.8 – relationship-mbr-options
Allows you to specify a relationship member. This member can be
an existing element in a repository, or it can be an element you
create within the DEFINE GENERIC command. See DEFINE
GENERIC_Relationship_Member_Options command for more information.
8.2 – Description
The DEFINE GENERIC command creates a generic element definition.
You can create generic elements that are based on types supplied
by Oracle CDD/Repository or on user-supplied (extended) types. If
you do most of your work with extended types, it is recommended
that you work through the Oracle CDD/Repository callable
interface. The CDO GENERIC commands are useful to modify and
display on a spot basis, but extensibility is not supported
through CDO.
If the generic element is a controlled versioned element, you use
the DEFINE GENERIC command to create initial versions. Use the
RESERVE and REPLACE commands to create new versions.
If the generic element is an uncontrolled versioned element,
use the DEFINE GENERIC command to create both initial and new
versions.
By default, CDO automatically assigns a directory name that is
the same as the element name of the generic element that you
define. However, you can assign a processing name to a generic
element that is different from its directory name.
When you define a property for a generic element, the property
you specify must be a defined or inherited property for the
element's type. Any values you specify for the property must
be compatible with the data type indicated in the property type
definition. Likewise, any relationship member you specify must
be compatible with the relationship name's type. See the Oracle
CDD/Repository Information Model Volume I for more information on
valid properties and members.
When you work with extended types, include the MCS_processingName
property in your type definition. If you omit one of these
properties, your type definition does not allow you to specify
a processing name for generic elements based on it. Without a
processing name, you cannot use the CHANGE GENERIC command to add
or delete properties and relationships for a generic element.
CAUTION
Specify the MCS_processingName property, not the
CDD$PROCESSING_NAME property, when you work with extended
types. Otherwise, you experience performance degradation in
the Oracle CDD/Repository callable interface.
8.3 – Examples
1.CDO> DEFINE GENERIC CDD$SOURCE_MODULE INPUT_MODULE_COB
cont> MCS_PROCESSINGNAME "INPUT_MODULE_COB".
cont> END CDD$SOURCE_MODULE INPUT_MODULE_COB.
In this example, the DEFINE GENERIC command creates a
generic element named INPUT_MODULE_COB based on the type
CDD$SOURCE_MODULE supplied by Oracle CDD/Repository.
2.CDO> DEFINE GENERIC CDD$SOURCE_MODULE OUTPUT_MODULE_COB
cont> MCS_PROCESSINGNAME "OUTPUT_MODULE_COB".
cont> END CDD$SOURCE_MODULE OUTPUT_MODULE_COB.
In this example, the DEFINE GENERIC command creates a generic
element named OUTPUT_MODULE_COB based on the product-supplied
CDD$SOURCE_MODULE element type.
3.CDO> DEFINE GENERIC BOOK CDO_REFERENCE_MANUAL
cont> MCS_PROCESSINGNAME IS "CDO_REFERENCE_MANUAL"
cont> LIBRARY_NUMBER IS "AA-KL45A-TE".
cont> END BOOK CDO_REFERENCE_MANUAL.
In this example, the DEFINE GENERIC command creates a generic
element named CDO_REFERENCE_MANUAL based on the user-supplied
type BOOK.
9 – GENERIC Relationship Member Options
Format
{relationship-mbr-name }
{GENERIC }
{ [ ]}
{ [[ DESCRIPTION IS /*text*/ ] ]}
{ [ ]}
{ [ [ {n }] ]}
{ [ [property-name IS {quoted-string }] ... . ]}
{ [ [ { }] ]}
{ [ ]}
{ [[ ]]}
{ [[RELATIONSHIPS . ]]}
{ [[ {RELATIONSHIP relationship-name } ]]}
{ type-name [[ { } ]]}
{ [[ { relationship-mbr-options } ]]}
{ [[ { [ {n }] } ]]}
{ [[ { [property-name IS {quoted-string}] ... .} ...]]}
{ [[ { [ { }] } ]]}
{ [[ { } ]]}
{ [[ {END relationship-name RELATIONSHIP. } ]]}
{ [[ ]]}
{ [[ END RELATIONSHIPS. ]]}
{ [[ ]]}
{ [ ]}
{ }
{END [ GENERIC type-name ] . }
9.1 – Parameters
9.1.1 – relationship-mbr-name
Specifies an existing element that can be a valid member of the
relationship type that you use.
9.1.2 – type-name
Specifies the type of the generic element member you are
defining. The type must be compatible with the relationship type.
9.1.3 – text
Documents the generic element that you are creating as a
relationship member. Within the DESCRIPTION clause, this is
information documenting the member definition. Valid delimiters
are /* */ or double quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION
clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
9.1.4 – property-name
Specifies a property.
9.1.5 – n
Sets the numeric value for a property.
9.1.6 – quoted-string
Sets the value (a string enclosed in quotation marks) for the
property you are specifying.
9.1.7 – relationship-name
Specifies the relationship type you are defining for the generic
element member. The type must be a subtype of RELATION.
9.1.8 – relationship-mbr-options
Specifies a relationship member. This member can be an existing
element in a repository, or it can be an element you create with
the DEFINE GENERIC Relationship Member Options clause.
9.2 – Description
The Relationship Mbr Options clause allows you to specify a
relationship member. This member can be an existing element in
the repository, or it can be an element you create within the
DEFINE GENERIC Relationship Member Options clause.
To specify an existing element as a relationship member, include
only the element's name in the Relationship Member Options
clause. To define a new element as a relationship member, specify
the Generic clause within the Relationship Member Options clause.
The Generic clause does not create directory names for
relationship members. Without a directory name, you cannot
display elements with the DIRECTORY command or include element
definitions in other definitions.
To display relationship members, issue the SHOW GENERIC command
with the /FULL qualifier. To provide a directory name for a
relationship member, issue the ENTER command.
If you use the Generic clause, you can nest a series of
relationship members.
9.3 – Examples
1.CDO> DEFINE GENERIC CDD$EXECUTABLE_IMAGE MY_PROGRAM_EXE
cont> MCS_PROCESSINGNAME "MY_PROGRAM_EXE".
cont> RELATIONSHIPS.
cont> RELATIONSHIP CDD$IMAGE_DERIVED_FROM
cont> GENERIC CDD$COMPILED_MODULE
cont> MCS_PROCESSINGNAME "INPUT_MODULE_OBJ".
cont> RELATIONSHIPS.
cont> RELATIONSHIP CDD$COMPILED_DERIVED_FROM
cont> INPUT_MODULE_COB.
cont> END CDD$COMPILED_DERIVED_FROM RELATIONSHIP.
cont> END RELATIONSHIPS.
cont> END CDD$COMPILED_MODULE INPUT_MODULE_OBJ.
cont> END CDD$IMAGE_DERIVED_FROM RELATIONSHIP.
cont> RELATIONSHIP CDD$IMAGE_DERIVED_FROM
cont> GENERIC CDD$COMPILED_MODULE
cont> MCS_PROCESSINGNAME "OUTPUT_MODULE_OBJ".
cont> RELATIONSHIPS.
cont> RELATIONSHIP CDD$COMPILED_DERIVED_FROM
cont> OUTPUT_MODULE_COB.
cont> END CDD$COMPILED_DERIVED_FROM RELATIONSHIP.
cont> END RELATIONSHIPS.
cont> END CDD$COMPILED_MODULE OUTPUT_MODULE_OBJ.
cont> END CDD$IMAGE_DERIVED_FROM RELATIONSHIP.
cont> END RELATIONSHIPS.
cont> END CDD$EXECUTABLE_IMAGE MY_PROGRAM_EXE.
In this example, the following steps are performed:
a. Defines the generic entity MY_PROGRAM_EXE.
b. Specifies the processing name MY_PROGRAM_EXE for the
CDD$PROCESSING_NAME attribute.
c. Defines the list of relationships that the definition MY_
PROGRAM_EXE includes.
d. Specifies a relationship type CDD$IMAGE_DERIVED_FROM,
supplied by Oracle CDD/Repository, that the definition MY_
PROGRAM_EXE owns.
e. The GENERIC clause creates a generic entity as a
relationship member of the CDD$IMAGE_DERIVED_FROM
relationship, based on the CDD$COMPILED_MODULE entity type.
f. Specifies the processing name INPUT_MODULE for the attribute
type CDD$PROCESSING_NAME, supplied by Oracle CDD/Repository.
g. Begins the list of relationships that the generic entity
definition INPUT_MODULE_OBJ includes.
h. Specifies the relationship type CDD$COMPILED_DERIVED_
FROM, which is supplied by Oracle CDD/Repository, as a
relationship owned by the generic entity INPUT_MODULE_OBJ.
This relationship type specifies the generic entity INPUT_
MODULE_COB (based on the entity type CDD$SOURCE_MODULE) as
its relationship member.
i. Ends the relationship definition of CDD$COMPILED_DERIVED_
FROM.
j. Ends the list of relationships the generic entity definition
INPUT_MODULE_OBJ owns.
k. Ends the definition of the generic entity INPUT_MODULE_OBJ.
l. Ends the CDD$IMAGE_DERIVED_FROM relationship definition that
MY_PROGRAM_EXE owns.
m. Specifies a relationship type CDD$IMAGE_DERIVED_FROM,
supplied by Oracle CDD/Repository, that the generic entity
definition MY_PROGRAM_EXE owns.
n. The GENERIC clause creates a generic entity as a
relationship member of the CDD$IMAGE_DERIVED_FROM
relationship, based on the CDD$COMPILED_MODULE entity type.
o. Specifies the processing name OUTPUT_MODULE_OBJ for the
attribute type CDD$PROCESSING_NAME, which is supplied by
Oracle CDD/Repository.
p. Begins the list of relationships that the new generic entity
definition OUTPUT_MODULE_OBJ includes.
q. Specifies the relationship type CDD$COMPILED_DERIVED_FROM,
supplied by Oracle CDD/Repository, as a relationship owned
by the generic entity OUTPUT_MODULE_OBJ. This relationship
type specifies the generic entity OUTPUT_MODULE_COB (based
on the entity type CDD$SOURCE_MODULE as its relationship
member.
r. Ends the relationship definition of CDD$COMPILED_DERIVED_
FROM.
s. Ends the list of relationships that the generic entity
definition OUTPUT_MODULE_OBJ owns.
t. Ends the definition of the generic entity definition OUTPUT_
MODULE_OBJ.
u. Ends the CDD$IMAGE_DERIVED_FROM relationship definition that
MY_PROGRAM_EXE owns.
v. Ends the list of relationships the generic entity MY_
PROGRAM_EXE owns.
w. Ends the definition of the generic entity MY_PROGRAM_EXE.
Because the GENERIC clause of the DEFINE GENERIC command
creates the INPUT_OBJ and OUTPUT_OBJ generic entities, these
entities do not have directory names. You can view their
definitions only with the SHOW GENERIC/FULL command, which
displays their owner (MY_PROGRAM_EXE entity).
2.CDO> SHOW GENERIC CDD$EXECUTABLE_IMAGE/FULL MY_PROGRAM_EXE
Definition of MY_PROGRAM_EXE (Type : CDD$EXECUTABLE_IMAGE)
| Contains CDD$IMAGE_DERIVED_FROM
| | INPUT_MODULE_OBJ (Type : CDD$COMPILED_MODULE)
| | | Contains CDD$COMPILED_DERIVED_FROM
| | | | INPUT_MODULE_COB (Type : CDD$SOURCE_MODULE)
| Contains CDD$IMAGE_DERIVED_FROM
| | OUTPUT_MODULE_OBJ (Type : CDD$COMPILED_MODULE)
| | | Contains CDD$COMPILED_DERIVED_FROM
| | | | OUTPUT_MODULE_COB (Type : CDD$SOURCE_MODULE)
In this example, the DEFINE GENERIC command creates the
generic element definition MY_PROGRAM_EXE, based on the
type CDD$EXECUTABLE_IMAGE. The first relationship defined
is the CDD$IMAGE_DERIVED_FROM relation, supplied by Oracle
CDD/Repository, which in turn owns the CDD$COMPILED_DERIVED_
FROM relation, also supplied by Oracle CDD/Repository. The
second relationship defined is a CDD$IMAGE_DERIVED_FROM
relation, which in turn owns another CDD$COMPILED_DERIVED_
FROM relation.
The first relationship links the executable image and its
compiled modules. The second relationship links the compiled
modules and the source module.
3.CDO> DEFINE GENERIC BOOK CDD_PLUS_REFERENCE_MANUAL
cont> MCS_processingName IS "CDD_PLUS_REFERENCE_MANUAL"
cont> LIBRARY_NUMBER IS "AA-KL45A-TE".
cont> END BOOK CDD_PLUS_REFERENCE_MANUAL.
This example creates an entity named CDD_PLUS_REFERENCE_MANUAL
based on the BOOK protocol.
4.CDO> DEFINE GENERIC LIBRARY ORACLE_LIBRARY
cont> MCS_processingName IS "ORACLE_LIBRARY"
cont> ADDRESS IS "NASHUA, NH".
cont> RELATIONSHIPS.
cont> RELATIONSHIP BOOK_IN_LIBRARY CDD_PLUS_REFERENCE_MANUAL
cont> END BOOK_IN_LIBRARY RELATIONSHIP.
cont> END RELATIONSHIPS.
cont> END LIBRARY ORACLE_LIBRARY.
This example creates an entity named ORACLE_LIBRARY based on
the LIBRARY protocol.
5.CDO> DEFINE GENERIC LIBRARY ORACLE_LIBRARY
cont> MCS_processingName IS "ORACLE_LIBRARY".
cont> RELATIONSHIPS.
cont> RELATIONSHIP BOOK_IN_LIBRARY CDO_REFERENCE_MANUAL.
cont> END BOOK_IN_LIBRARY RELATIONSHIP.
cont> RELATIONSHIPS.
cont> GENERIC BOOK USER_GUIDE
cont> MCS_processingName IS "USER_GUIDE".
cont> END RELATIONSHIPS.
cont> END LIBRARY ORACLE_LIBRARY.
This command creates a relationship member using the DEFINE
GENERIC command.
6.CDO> DEFINE GENERIC LIBRARY ORACLE_LIBRARY
cont> MCS_processingName IS "ORACLE_LIBRARY"
cont> ADDRESS IS "NASHUA, NH".
cont> RELATIONSHIPS.
cont> RELATIONSHIP BOOK_IN_LIBRARY
cont> GENERIC BOOK
cont> MCS_processingName IS "USER_GUIDE"
cont> END RELATIONSHIPS.
cont> END LIBRARY ORACLE_LIBRARY.
This example uses the DEFINE GENERIC command to define the
relationship member USER_GUIDE. Note that the keyword DEFINE
and the relationship member's entity name have been omitted.
7.CDO> DEFINE GENERIC LIBRARY ORACLE_LIBRARY
cont> MCS_processingName IS "ORACLE_LIBRARY"
cont> ADDRESS IS "NASHUA, NH".
cont> RELATIONSHIPS.
cont> RELATIONSHIP BOOK_IN_LIBRARY
cont> GENERIC BOOK
cont> MCS_processingName IS "USER_GUIDE"
cont> LIBRARY_NUMBER IS 1.
cont> END GENERIC.
cont> END BOOK_IN_LIBRARY RELATIONSHIP.
cont> END RELATIONSHIPS.
cont> END LIBRARY ORACLE_LIBRARY.
This example uses the DEFINE GENERIC command to define the
relationship member USER_GUIDE. Note that the keyword DEFINE
and the relationship member's entity name have been omitted.
8.CDO> SHOW GENERIC LIBRARY ORACLE_LIBRARY
To view the definition of the relationship member created with
the DEFINE GENERIC command in the previous example, you need to
use the SHOW GENERIC command for its owner, ORACLE_LIBRARY.
9.CDO> DEFINE GENERIC CDD$RDB_DATABASE PERSONNEL DESCRIPTION IS
cont> "DEFINE RDB_DATABASE PERSONNEL, CONTAINING RECORD EMPLOYEE_REC"
cont> CDD$PROCESSING_NAME IS "PERSONNEL".
cont> RELATIONSHIPS.
cont> RELATIONSHIP CDD$RDB_DATA_AGGREGATE
cont> GENERIC CDD$DATA_AGGREGATE DESCRIPTION IS
cont> "DEFINE DATA AGGREGATE EMPLOYEE_REC CONTAINING FIRST_NAME,"
cont> "LAST_NAME, EMP_ID"
cont> CDD$PROCESSING_NAME IS "EMPLOYEE_REC".
cont> RELATIONSHIPS.
cont> RELATIONSHIP CDD$DATA_AGGREGATE_CONTAINS
cont> GENERIC CDD$DATA_ELEMENT DESCRIPTION IS
cont> "DEFINE DATA ELEMENT FIRST_NAME = FIELD FIRST_NAME"
cont> CDD$PROCESSING_NAME IS "FIRST_NAME"
cont> CDD$DATA_ELEMENT_DATATYPE 14
cont> CDD$DATA_ELEMENT_LENGTH 10.
cont> END CDD$DATA_ELEMENT FIRST_NAME.
cont> CDD$DATA_SEQUENCE_NUMBER IS 1.
cont> END CDD$DATA_AGGREGATE_CONTAINS RELATIONSHIP.
cont> RELATIONSHIP CDD$DATA_AGGREGATE_CONTAINS
cont> GENERIC CDD$DATA_ELEMENT DESCRIPTION IS
cont> "DEFINE DATA ELEMENT LAST_NAME = FIELD LAST_NAME"
cont> CDD$PROCESSING_NAME IS "LAST_NAME"
cont> CDD$DATA_ELEMENT_DATATYPE 14
cont> CDD$DATA_ELEMENT_LENGTH 15.
cont> END CDD$DATA_ELEMENT LAST_NAME.
cont> CDD$DATA_SEQUENCE_NUMBER IS 2.
cont> END CDD$DATA_AGGREGATE_CONTAINS RELATIONSHIP.
cont> RELATIONSHIP CDD$DATA_AGGREGATE_CONTAINS
cont> GENERIC CDD$DATA_ELEMENT DESCRIPTION IS
cont> "DEFINE DATA ELEMENT EMP_ID = FIELD EMP_ID"
cont> CDD$PROCESSING_NAME IS "EMP_ID"
cont> CDD$DATA_ELEMENT_DATATYPE 4.
cont> END CDD$DATA_ELEMENT EMP_ID.
cont> CDD$DATA_SEQUENCE_NUMBER IS 3.
cont> END CDD$DATA_AGGREGATE_CONTAINS RELATIONSHIP.
cont> END RELATIONSHIPS.
cont> END CDD$DATA_AGGREGATE EMPLOYEE_REC.
cont> END CDD$RDB_DATA_AGGREGATE RELATIONSHIP.
cont>END RELATIONSHIPS.
cont>END CDD$RDB_DATABASE PERSONNEL.
This example defines an Oracle Rdb database PERSONNEL and
creates a CDD$RDB_DATABASE entity PERSONNEL in the CDO
repository. This database contains one record EMPLOYEE_REC,
which in turn contains three fields that were defined by
nesting the GENERIC clauses: FIRST_NAME, LAST_NAME, and EMP_
ID. (It is recommended that you define Oracle Rdb databases in
the CDO repository through the SQL. See Oracle Rdb7 Guide to
Database Design and Definition for more information on how to
use CDO with Oracle Rdb databases.)
10 CDO> SHOW GENERIC CDD$RDB_DATABASE/AUDIT=ALL PERSONNEL
Definition of PERSONNEL (Type : CDD$RDB_DATABASE)
| | History entered by SMITH ([CDD,SMITH])
| | using CDO V1.0
| | to CREATE definition on 15-DEC-1987 10:31:11.59
| Contains CDD$RDB_DATA_AGGREGATE
| | EMPLOYEE_REC (Type : CDD$DATA_AGGREGATE)
| | | Contains CDD$DATA_AGGREGATE_CONTAINS
| | | | FIRST_NAME (Type : CDD$DATA_ELEMENT)
| | | Contains CDD$DATA_AGGREGATE_CONTAINS
| | | | LAST_NAME (Type : CDD$DATA_ELEMENT)
| | | Contains CDD$DATA_AGGREGATE_CONTAINS
| | | | EMP_ID (Type : CDD$DATA_ELEMENT)
CDO>
This example displays the history list of every element owned
by the PERSONNEL database by using the SHOW GENERIC command.
10 – KEY
Format
DEFINE KEY [ qualifier ] ... key-name key-equivalence
10.1 – Parameters
10.1.1 – key-name
Specifies the key you are defining.
10.1.2 – key-equivalence
Specifies the character string you want processed when you press
the key. Enclose the string in quotation marks to preserve spaces
and lowercase characters.
10.2 – Qualifiers
10.2.1 /ECHO
Format options:
/ECHO (default)
/NOECHO
Specifies whether CDO displays the equivalence string on your
terminal screen after you press a key. The default is ECHO, which
displays the equivalence string.
You cannot use the /NOECHO qualifier with the /NOTERMINATE
qualifier.
10.2.2 /IF_STATE
Format options:
/IF_STATE=state-name
/NOIF_STATE (default)
Specifies the state that must be in effect for a key definition
to work. If you omit the /IF_STATE qualifier or use the /NOIF_
STATE qualifier, CDO uses the current state. The state name is
an alphanumeric string. The /SET_STATE qualifier or the SET KEY
command establishes the state.
10.2.3 /LOCK_STATE
Format options:
/LOCK_STATE
/NOLOCK_STATE (default)
Specifies whether the state set by the /SET_STATE qualifier
remains in effect until a user explicitly changes it. 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 the /LOCK_STATE qualifier, you must also specify
the /SET_STATE qualifier.
10.2.4 /PROTECTED
Format options:
/PROTECTED
/NOPROTECTED (default)
Specifies whether CDO protects a key against later redefinition.
The default is no protection against redefinition.
10.2.5 /SET_STATE
Format options:
/SET_STATE=state-name
/NOSET_STATE (default)
Specifies a new state for CDO to set when you press a key; by
default, CDO resets the current locked state. If you have not
included this qualifier in a key definition, you can use the SET
KEY command to change the current state. The state name can be
any alphanumeric string.
10.2.6 /TERMINATE
Format options:
/TERMINATE
/NOTERMINATE (default)
Specifies whether CDO immediately processes the key definition
when you press the key (equivalent to typing the string and
pressing the Return key).
The default is NOTERMINATE, which allows you to press other keys
before CDO processes the definition. The /NOTERMINATE qualifier
allows you to create key definitions that insert text into
command lines, after prompts, or into other text that you are
typing.
You cannot use the /NOTERMINATE qualifier with the /NOECHO
qualifier.
10.3 – Description
The DEFINE KEY command assigns definitions to the peripheral keys
on certain terminals. These definitions can direct CDO to perform
one of the following actions:
o Execute a CDO command
o Append a qualifier to a CDO command
o Append a text string to a CDO or system-level command
When you define a key to insert a text string, use the
/NOTERMINATE qualifier so that you can continue typing more data
after CDO inserts the string.
You should take advantage of the echo feature in most instances.
With /ECHO set, CDO displays the key definition on the screen
each time you press the key.
You can use the /SET_STATE qualifier to increase the number of
key definitions available on your terminal keyboard. You can
assign the same key any number of definitions, as long as you
associate each definition with a different state. State names can
contain alphanumeric characters, dollar signs, and underscores.
See the SET KEY command for information on changing keypad
states.
Redefineable Key Names and Terminal Designations lists the keys
you can define on the keyboards of different terminals.
Table 1-3 Redefineable Key Names and Terminal Designations
Key Name VT100-series VT200- and VT300-series
PF1 PF1 PF1
PF2 PF2 PF2
PF3 PF3 PF3
PF4 PF4 PF4
KP0, KP1, ..., 0, 1, ..., 9 0, 1, ..., 9
KP9
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, ..., - F6, F7, ..., F20
F20
10.4 – Examples
CDO> DEFINE KEY /TERMINATE PF3 "SHOW DEFAULT"
In this example, the DEFINE KEY command assigns the CDO SHOW
DEFAULT command to the PF3 key. CDO executes the SHOW DEFAULT
command when you press the PF3 key.
11 – PARTITION
Format
DEFINE PARTITION partition-name
[ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ]
[ PARENT_PARTITION IS parent-partition-name ]
[ LOOKASIDE_PARTITION IS look-partition-name ,... ]...
[ ]
[ AUTOPURGE ]
[ NOAUTOPURGE ] .
[ ]
11.1 – Parameters
11.1.1 – partition-name
Specifies the partition you are creating.
11.1.2 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the partition; within the AUDIT clause,
it is a history list entry. Valid delimiters are /* */ or double
quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
11.1.3 – parent-partition-name
Specifies the parent partition, which must currently exist.
11.1.4 – look-partition-name
Specifies a related partition that is visible through this
partition. The related partition must currently exist.
11.2 – Description
The DEFINE PARTITION command creates a partition. Partitions are
the means by which you control elements.
When you control an element, you identify the partition, which is
called the base partition, in which a public, immutable copy of
this element resides. CDO provides two ways to control elements,
as follows:
o On an element-by-element basis, with the CONSTRAIN command.
CDO controls the element that appears within the command.
o Through a context with the DEFINE CONTEXT and SET CONTEXT
commands. Once you set the context, CDO controls all
subsequent elements until the context is changed.
Once an element has been controlled, you use the RESERVE and
REPLACE commands to create subsequent versions. This reservation
system prevents uncontrolled changes to elements.
You can link partitions together to control change in various
stages of a project. Each partition then represents a higher
level of approval, or completion, in the overall partition
hierarchy. The PROMOTE command moves elements higher within the
hierarchy.
The PARENT_PARTITION clause in the DEFINE PARTITION command
creates a partition hierarchy by linking partitions in a parent-
child relationship. The first, or root, partition does not have
a parent partition. The second partition in the hierarchy has
the first partition as its parent, and so on down the hierarchy.
This clause can be specified only once during the lifetime of
the partition, in either the DEFINE PARTITION or CHANGE PARTITION
command.
The LOOKASIDE_PARTITION clause makes the contents of another
partition visible, provided that you have read privileges for
the partition. You can read, but you cannot reserve, replace, or
change the contents.
The AUTOPURGE keyword ensures that CDO automatically purges
intermediate versions of elements in the partition when you
promote the latest version. The NOAUTOPURGE keyword prevents
this automatic purging.
11.3 – Examples
CDO> DEFINE PARTITION FINAL_RELEASE AUTOPURGE. 1
CDO> DEFINE PARTITION FIELDTEST_RELEASE 2
cont> PARENT_PARTITION IS FINAL_RELEASE AUTOPURGE.
CDO> DEFINE PARTITION SECOND_BASELEVEL
cont> PARENT_PARTITION IS FIELDTEST_RELEASE AUTOPURGE.
CDO> DEFINE PARTITION FIRST_BASELEVEL
cont> PARENT_PARTITION IS SECOND_BASELEVEL AUTOPURGE.
CDO> DEFINE PARTITION FRONT_END
cont> PARENT_PARTITION IS FIRST_BASELEVEL AUTOPURGE.
CDO> DEFINE PARTITION BACK_END 3
cont> PARENT_PARTITION IS FIRST_BASELEVEL
cont> LOOKASIDE_PARTITION IS FRONT_END AUTOPURGE.
CDO> CHANGE PARTITION FRONT_END 4
cont> LOOKASIDE_PARTITION IS BACK_END.
.
.
.
CDO> DEFINE CONTEXT BILL_CONTEXT 5
cont> BASE_PARTITION IS FRONT_END.
CDO> DEFINE CONTEXT BETSY_CONTEXT
cont> BASE_PARTITION IS BACK_END.
CDO> DEFINE CONTEXT QA_CONTEXT
cont> BASE_PARTITION IS FIELDTEST_RELEASE.
In this example, successive DEFINE PARTITION commands create a
partition hierarchy.
1 The root partition is FINAL_RELEASE.
2 Each successive partition in the hierarchy is the child of
the previous partition.
3 A partition hierarchy can include multiple children of a
previous partition; LOOKASIDE_PARTITION makes the contents
of FRONT_END visible to BACK_END.
4 The CHANGE PARTITION command makes the contents of BACK_END
visible to FRONT_END.
5 The base partition, or lowest visible partition, is set for
three different contexts.
12 – PROTECTION
Format
DEFINE PROTECTION FOR
{ DIRECTORY }
{ FIELD }
{ RECORD } element-name ,...
{ }
{ GENERIC type-name }
[ POSITION n ]
[ AFTER id1+ ... ] IDENTIFIER id2+... ACCESS
[ ]
right+ ... .
{ REPOSITORY anchor-name }
DEFINE PROTECTION FOR { GENERIC MCS_CONTEXT context-name }
{ }
[ POSITION n ] IDENTIFIER id2
{ ACCESS }
{ DEFAULT_ACCESS } right+ ... .
{ }
12.1 – Parameters
12.1.1 – type-name
Specifies the type of the generic element whose ACE you are
defining.
12.1.2 – element-name
Specifies the element whose ACE you are defining. You can use
wildcard characters in this name.
12.1.3 – n
Specifies the relative position (a positive integer) in the ACL
of the ACE you are defining. If you omit the position or the
identifier, the ACE you are defining becomes the first ACE in the
ACL.
12.1.4 – id1
Specifies the identifier or identifiers of the existing ACE that
will immediately precede the ACE you are defining.
12.1.5 – id2
Specifies the identifier or identifiers of those users whose
access to the element or repository you are defining in this ACE.
12.1.6 – right
Specifies the access rights CDO grants to the users you specified
in id2.
12.1.7 – anchor-name
Specifies the anchor directory of the repository whose ACE you
are defining.
12.1.8 – context-name
Specifies the context.
12.2 – Description
The DEFINE PROTECTION command adds an access control list
entry (ACE) to the access control list (ACL) of an element or
repository. When you specify FOR GENERIC MCS_CONTEXT or FOR
REPOSITORY, this command can also add an ACE to a default access
control list. To define protection, you need CONTROL access.
The ACEs in an ACL determine which users can access the element
or repository and what operations each user can perform. An ACE
consists of the following two parts:
o One or more identifiers that specifies a user or set of users:
UIC, general, and system-defined
o A set of access rights: READ, WRITE, EXECUTE, and DELETE
The POSITION clause specifies the relative position CDO assigns
your ACE in the ACL. ACEs are numbered in ascending order
starting with number one. If you specify a number that is larger
than the number of ACEs in the ACL, the ACE you are creating
becomes the last entry in the ACL.
The AFTER clause specifies the identifiers of an existing ACE
that will immediately precede the ACE that you are defining.
The IDENTIFIER clause specifies the identifiers of the user or
users whose access to the element or repository you are defining
in this ACE. If an ACE contains more than one identifier, a
user's process must hold all the identifiers specified in the
ACE to receive the access rights granted by the ACE.
The ACCESS clause specifies the rights that the ACE provides.
This clause is especially useful when you need to restrict access
to a context or to a repository. For example, by modifying this
clause, you can restrict access to a single user for OpenVMS
BACKUP or VERIFY operations.
The DEFAULT_ACCESS clause is only valid for contexts (specified
as GENERIC MCS_CONTEXT) or repositories. The clause specifies
the default access rights for each new element you create.
If a context is set, the new element receives default access
rights defined for this context. If a context is not set, the
new element receives the default access rights defined for the
repository.
For complete information on defining protection, see Using Oracle
CDD/Repository on OpenVMS Systems.
12.3 – Examples
1.CDO> DEFINE PROTECTION RECORD PERSONNEL
cont> POSITION 2
cont> IDENTIFIER [JONES,DICT]+LOCAL+INTERACTIVE
cont> ACCESS READ+WRITE+DELETE.
In this example, the DEFINE PROTECTION command creates a new
second ACE for the PERSONNEL record. The former second ACE
becomes the new third ACE.
2.CDO> DEFINE PROTECTION FOR RECORD PERSONNEL
cont> AFTER [JONES,DICT]+LOCAL+INTERACTIVE
cont> IDENTIFIER [CDD,SMITH] ACCESS READ.
In this example, the DEFINE PROTECTION command inserts a new
ACE with the identifier [CDD,SMITH] after the ACE with the
[JONES,DICT]+LOCAL+INTERACTIVE identifiers.
3.CDO> DEFINE PROTECTION FOR RECORD BENEFITS.*;* POSITION 4
cont> IDENTIFIER [PERSONNEL,*] ACCESS SHOW.
In this example, the DEFINE PROTECTION command creates a fourth
ACE for all current records in the BENEFITS directory. This ACE
does not become the default protection for definitions that are
subsequently created.
4.CDO> DEFINE PROTECTION FOR RECORD PERSONNEL
cont> IDENTIFIER [*,*] ACCESS NONE.
In this example, the DEFINE PROTECTION command creates an ACE
that denies all access rights to all users. CDO places this
ACE first in the ACL, because the user did not specify either a
POSITION clause or an AFTER clause in the command. As a result,
everyone (including the user who issued the command) is denied
all access to the definition.
Only the owner can regain access to the definition by using
either the DELETE PROTECTION or CHANGE PROTECTION command to
remove or change the ACE.
5.CDO> DEFINE PROTECTION FOR REPOSITORY PERSONNEL
cont> POSITION 2 IDENTIFIER [SYSTEM]
cont> ACCESS READ+WRITE+DELETE+CONTROL.
In this example, the DEFINE PROTECTION command creates an
ACE in the second position that grants the SYSTEM user
READ+WRITE+DELETE+CONTROL access.
6.CDO> DEFINE PROTECTION FOR REPOSITORY PERSONNEL
cont> POSITION 2 IDENTIFIER [*,*]
cont> DEFAULT_ACCESS READ+WRITE.
CDO> DEFINE FIELD NEW_FIELD DATATYPE TEXT SIZE 5.
In this example, the DEFINE PROTECTION command defines
the default access rights for the PERSONNEL repository to
READ+WRITE. If a context has not been set, CDO will grant the
newly created field, NEW_FIELD, with access rights that are
equivalent to the repository's default access rights.
7.CDO> DEFINE PROTECTION FOR REPOSITORY CDD$REPOSITORY2
cont> POSITION 2 IDENTIFIER [*,*]
cont> ACCESS NONE.
In this example, the DEFINE PROTECTION command defines the
access rights for the repository using a logical name for the
repository name.
12.4 – Protecting the Repository Anchor
Oracle CDD/Repository places a security ACL on repository anchors
when a new repository is created, when a repository is moved,
or when the location of the repository is changed with the CDO
command VERIFY/LOCATION/FIX.
The ACL is as follows:
(IDENTIFIER=CDD$SYSTEM,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=[*,*],ACCESS=READ+EXECUTE)
(IDENTIFIER=CDD$SYSTEM,OPTIONS=DEFAULT+NOPROPAGATE,ACCESS=READ
+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=[*,*],OPTIONS=DEFAULT+NOPROPAGATE,ACCESS=NONE)
To add these ACLs to existing repository anchors on your system,
you can use either one of the following methods:
o OpenVMS SET ACL/ACL command
o ACL Editor
In addition to this default protection, you should add UIC-based
protection with either of the following commands:
o OpenVMS SET PROTECTION command
o OpenVMS CREATE/DIRECTORY/PROTECTION command
For more information about setting OpenVMS protection on a
repository's OpenVMS anchor directory, see the OpenVMS Examples
at the end of this section.
12.4.1 – Examples
Example 1:
$ SET ACL/ACL=(IDENTIFIER=CDD$SYSTEM, -
_$ ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) [SMITH]DIC.DIR(1)
$ SET ACL/ACL=(IDENTIFIER=[*,*],ACCESS=READ) [SMITH]DIC.DIR(1)
Protect your repository anchor directory with an ACL containing
the ACEs shown in the previous example. With these ACEs, only
repository files can be created in a repository anchor directory.
In this example, the SET ACL/ACL command, creates an ACL for the
OpenVMS anchor directory of the [SMITH.DIC] repository:
Example 2:
$ SET ACL/EDIT [SMITH]DIC.DIR(1)
$ EDIT/ACL [SMITH]DIC.DIR(1)
You might find it easier to use the ACL Editor to create an
ACL for an OpenVMS anchor directory by using either one of the
following DCL commands:
Example 3:
$ SHOW ACL [SMITH]DIC.DIR(1)
element type: file, element name: CDD$DISK:[SMITH]DIC.DIR(1),
on 27-FEB-1989 09:54:40.62
(IDENTIFIER=CDD$SYSTEM,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=[*,*],ACCESS=READ)
To display the ACL you just created, use the DCL SHOW ACL
command:
Example 4:
$ SET PROTECTION=(S:RWED,,,) [SMITH]DIC.DIR(1)
You should also add UIC-based protection to your repository's
OpenVMS anchor directory. In this example, the DCL SET PROTECTION
command creates UIC-based protection for the OpenVMS anchor
directory [SMITH.DIC].
13 – RECORD Command
Format
DEFINE RECORD record-name
[ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ]
[ record-property ] ...
[ constraint-clause ] ... .
{ included-name-clause }
{ local-field-clause }
{ structure-name-clause } ... .
{ }
{ variants-clause }
END [ record-name ] RECORD .
13.1 – Parameters
13.1.1 – record-name
Specifies the record element you are creating.
13.1.2 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the record element; within the AUDIT
clause, it is a history list entry. Valid delimiters are /* */ or
double quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
13.1.3 – record-property
Adds a property to the record element. See rec-properties for the
record properties CDO provides.
13.1.4 – constraint-clause
Specifies a condition that affects adding or modifying data to
the database table (CDO record). CDO provides syntax for record
constraints, including specification of NOT NULL, PRIMARY KEY,
FOREIGN KEY, UNIQUE, and CHECK (arbitrary search condition
constraint) for fields and records. See the DEFINE
RECORD_Constraint command for more information.
13.1.5 – included-name-clause
Allows you to include existing field definitions and record
definitions within record elements. See the DEFINE
RECORD_Included_Name command for more information.
13.1.6 – local-field-clause
Allows you to create local field definitions within record
elements. Describes the attributes of the local field. See the
DEFINE RECORD_Local_Field command for more information.
13.1.7 – structure-name-clause
Creates structure definitions within record elements. See the
DEFINE RECORD_Structure_Name command for more information.
13.1.8 – variants-clause
Creates variants definitions within record elements. See the
DEFINE RECORD_Variants command for more information.
13.2 – Description
The DEFINE RECORD command creates a record element.
If you supply a record name that is already used for a record
element in your default directory, CDO creates a new version of
the existing record definition.
The DEFINE RECORD command evaluates the record name you supply
to determine if it is a logical name. If the record name is a
logical name, CDD translates it. In some cases, the translation
of the logical name for the record may not be a valid name
for a record definition, and CDO will not create the record
definition. For example, if you have defined JOE as a logical
name that translates to MYNODE::[RICHIE], CDD translates the
symbol JOE. The following DEFINE RECORD command fails because
MYNODE::[RICHIE] is not a valid name:
CDO> DEFINE RECORD JOE.
%CDO-F-ERRDEFINE, error defining object
-CDD-F-NOTADIC, Does not contain a CDO dictionary:
MYNODE::
If this error occurs, deassign the logical name with the same
name as the object, and perform the operation again. To avoid
this logical name conflict, use unique names that represent the
type of entity you are naming.
13.3 – Examples
CDO> DEFINE RECORD EDUCATION_RECORD.
cont> BADGE_NUMBER.
cont> BACHELOR_DEGREE.
cont> MASTER_DEGREE.
cont> DOCTORATE_DEGREE.
cont> END RECORD.
In this example, the DEFINE RECORD command creates the
EDUCATION_RECORD record definition from four existing field
definitions.
14 – RECORD Constraint
Format
CONSTRAINT constr-name
[UNIQUE field-name, ... ]
[PRIMARY KEY field-name, ... ]
[FOREIGN KEY field-name, ... REFERENCES record-name field-name, ...]
[CHECK (expression) ]
[DEFERRABLE ]
[NOT DEFERRABLE]
14.1 – Parameters
14.1.1 – constr-name
Specifies the name of the constraint.
14.1.2 – field-name
Specifies the name of the field to be used in a key or a field
that is unique.
14.1.3 – record-name
Specifies the name of the record.
14.1.4 – expression
Specifies a Boolean expression. See Expressions for more
information.
14.2 – Description
Use to specify a condition that affects adding or modifying
data to the database table (CDO record). CDO provides syntax for
record constraints, including specification of NOT NULL, PRIMARY
KEY, FOREIGN KEY, UNIQUE, and CHECK (arbitrary search condition
constraint) for fields and records.
14.3 – Examples
CDO> DEFINE RECORD PARTS
cont> CONSTRAINT PARTS_PMK PRIMARY KEY PART_ID
cont> CONSTRAINT PARTS_UNQ UNIQUE PART_NO
cont> CONSTRAINT PART_CST CHECK
cont> ANY P IN PARTS WITH (PART_ID IN PARTS = PART_ID_USED_IN IN PARTS)
cont> CONSTRAINT PART_FRK
cont> FOREIGN KEY PART_NO REFERENCES PARTS PART_ID.
cont> PART_NO.
cont> PART_ID.
cont> PART_ID_USED_IN.
cont> PART_QUANT.
cont> END.
CDO> SHOW RECORD PARTS/FULL
Definition of record PARTS
| Contains field PART_NO
| | Datatype signed word
| Contains field PART_ID
| | Datatype signed longword
| Contains field PART_ID_USED_IN
| | Based on ID_DOM
| | | Datatype signed longword
| Contains field PART_QUANT
| | Datatype signed word
| Constraint PARTS_PMK primary key PART_ID NOT DEFERRABLE
| Constraint PARTS_UNQ unique PART_NO NOT DEFERRABLE
| Constraint PART_CST (ANY (P IN PARTS WITH (PART_ID IN PARTS EQ
PART_ID_USED_IN IN PARTS))) NOT DEFERRABLE
| Constraint PART_FRK foreign key PART_NO references PARTS PART_ID NOT
DEFERRABLE
This example uses the CDO DEFINE RECORD command syntax to
establish constraints on the PARTS record.
NOTE
For the purposes of this example, it is assumed that the
field definitions referred to in the record definitions have
already been defined in the repository.
This example assumes the PART_ID to be the primary key and
the PART_NO to be a unique value across all possible parts.
By not specifying whether the constraints are deferrable,
the default evaluation time is accepted. In CDO, the default
evaluation time for constraints is NOT DEFERRABLE. Constraints
are evaluated at statement time.
Using CDO, the record PARTS is defined with the following
attributes:
o Primary key PARTS_PMK
o Unique constraint PARTS_UNQ
o Check constraint PART_CST
o Foreign key constraint PART_FRK
15 – RECORD Included Name
Format
[ BASED ON field-name ]
[ ]
[ {BIT } ]
[ {BYTE } ]
[ ALIGNED ON {WORD } BOUNDARY ]
[ {LONGWORD } ]
name [ {QUADWORD } ] .
[ {OCTAWORD } ]
[ ]
[ CONSTRAINT constr-name NOT NULL [DEFERRABLE ] ]
[ [NOT DEFERRABLE ] ]
[ ]
15.1 – Parameters
15.1.1 – name
Specifies the existing field or record definition you want to
include in the record element you are creating. The named field
or record definition must already exist in the repository.
15.1.2 – field-name
Specifies the name of the field to be used in a key or a field
that is unique.
15.1.3 – constr-name
Specifies the name of the constraint for the local field
definition you are changing. See the DEFINE RECORD_Command for
more information on constraints.
15.2 – Description
The Included Name clause allows you to specify global field
definitions and record definitions within record elements.
If you do not specify a directory name as part of the included
name, CDO looks for the record or field definition in your
current default directory.
To improve performance, some languages and language processors
have alignment restrictions for data definitions. The ALIGNED
clause aligns a field or record definition on a specified
boundary relative to the beginning of the record you are
defining. Each field or record, except BIT fields, begins by
default on the first byte following the last field. BIT fields
begin on the bit immediately following the last field.
The ALIGNED clause aligns fields or records within a record
relative to the start of the record, not relative to virtual
memory locations.
For example, if you specify LONGWORD alignment for a field,
that field does not necessarily begin on a longword boundary in
memory. Rather, the field begins some multiple of 32 bits beyond
the start of the record. To correctly use the aligned clause, you
must know the memory alignment techniques of the language you use
with CDO.
15.3 – Examples
1.CDO> DEFINE RECORD FULL_NAME.
cont> LAST_NAME ALIGNED ON WORD.
cont> FIRST_NAME ALIGNED ON WORD.
cont> MIDDLE_INITIAL ALIGNED ON WORD.
cont> END RECORD.
In this example, the DEFINE RECORD command creates the FULL_
NAME record element in your default directory using existing
field definitions. The keyword ALIGNED starts each field
definition on a word boundary.
2.CDO> DEFINE RECORD CONTRACT.HOME_ADDRESS.
cont> STREET_ADDRESS.
cont> CITY.
cont> STATE.
cont> POSTAL_CODE.
cont> END RECORD.
In this example, the DEFINE RECORD command creates the HOME_
ADDRESS record element using field definitions from your
default directory. Because you specify a path name, HOME_
ADDRESS is created in the EMPLOYEES directory.
3.CDO> SET DEFAULT DISK1:[JONES.DICT]PERSONNEL
CDO> DEFINE RECORD CONTRACT.WORKER_REC.
cont> FULL_NAME.
cont> CONTRACT.DATE_HIRED.
cont> CONTRACT.HOURLY_WAGE.
cont> CONTRACT.COMPLETION_DATE.
cont> END RECORD.
In this example, the DEFINE RECORD command creates the WORKER_
REC record element in the PERSONNEL directory using field
definitions from the default PERSONNEL directory and the
CONTRACT directory.
16 – RECORD Local Field
local-field-name
[ DESCRIPTION IS /*text*/ ]
[ field-property ]
[ NOfield-property ] ...
[ ]
[ {BIT } ]
[ {BYTE } ]
[ ALIGNED ON {WORD } BOUNDARY ]
[ {LONGWORD } ]
[ {QUADWORD } ]
[ {OCTAWORD } ] .
[ NOALIGNED ]
[ [ ] ]
[ CONSTRAINT constr-name NOT NULL [DEFERRABLE ] ]
[ [NOT DEFERRABLE ] ]
[ ]
16.1 – Parameters
16.1.1 – local-field-name
Specifies the name of the locally defined field.
16.1.2 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the record element; within the AUDIT
clause, it is a history list entry. Valid delimiters are /* */ or
double quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
16.1.3 – field-property
Defines the characteristics of the data you store in field
elements. See fld-properties for more information.
16.1.4 – constr-name
Specifies the name of the constraint for the local field
definition you are creating or changing. See the DEFINE
RECORD_Command for more information on constraints.
16.2 – Description
The Local Field Clause allows you to specify local field
definitions and record definitions within record elements.
To improve performance, some languages and language processors
have alignment restrictions for data definitions. The ALIGNED
clause aligns a field or record definition on a specified
boundary relative to the beginning of the record you are
defining.
Each field or record, except BIT fields, begins by default on the
first byte following the last field. BIT fields begin on the bit
immediately following the last field.
The ALIGNED clause aligns fields or records within a record
relative to the start of the record, not relative to virtual
memory locations.
For example, if you specify LONGWORD alignment for a field,
that field does not necessarily begin on a longword boundary in
memory. Rather, the field begins some multiple of 32 bits beyond
the start of the record. To correctly use the aligned clause, you
must know the memory alignment techniques of the language you use
with CDO.
16.3 – Examples
CDO> DEFINE RECORD PRODUCE.
cont> UPC_CODE DATATYPE LONGWORD NOT NULL DEFERRABLE.
cont> WEIGHT CONSTRAINT WNOTNULL NOT NULL.
cont> PRICE CONSTRAINT PNOTNULL NOT NULL DEFERRABLE.
cont> QUANTITY CONSTRAINT QNOTNULL NOT NULL NOT DEFERRABLE.
cont> END.
In this example, UPC_CODE is a local field.
17 – RECORD Structure Name
Format
structure-name STRUCTURE
[ DESCRIPTION IS /*text*/ ] [record-property] ...
[ {BIT } ]
[ {BYTE } ]
[ {WORD } ]
[ ALIGNED ON { } BOUNDARY ] .
[ {LONGWORD } ]
[ {QUADWORD } ]
[ {OCTAWORD } ]
[ { } ]
[ included-name-clause ]
[ local-field-clause ]
[ structure-name-clause ] ...
[ ]
[ variants-clause ]
END [ structure-name ] STRUCTURE .
17.1 – Parameters
17.1.1 – structure-name
Specifies the structure you are defining.
17.1.2 – text
Documents the structure definition. Valid delimiters are /* */ or
double quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION
clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
17.1.3 – record-property
Adds a property to the structure definition. See rec-properties
for a list of the valid record properties.
17.1.4 – included-name-clause
Includes existing field and record definitions within record
elements. See DEFINE RECORD_Included_Name command for more
information.
17.1.5 – local-field-clause
Specifies the locally defined field. See DEFINE
RECORD_Local_Field command for more information.
17.1.6 – structure-name-clause
Creates structure definitions within record elements. This
section describes structure definitions.
17.1.7 – variants-clause
Creates variants definitions within record elements. See DEFINE
RECORD_Variants command for more information.
17.2 – Description
The Structure Name Clause allows you to define a structure within
a record element.
A structure definition can include both field definitions and
record definitions.
17.3 – Examples
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.
In this example, the OCCURS...DEPENDING clause in the
DEPENDENTS structure specifies that the structure occurs 1 to
10 times based on the value of the NUMBER_OF_DEPENDENTS field
definition in the HOUSEHOLD record element at runtime.
18 – RECORD Variants
Format
VARIANTS.
{ }
{VARIANT [EXPRESSION IS cond-expr] . }
{ [included-name-clause ] }
{ [local-field-clause ] } ...
{ [structure-name-clause] ... END VARIANT . }
{ [variants-clause ] }
{ }
END VARIANTS .
18.1 – Parameters
18.1.1 – cond-expr
Specifies an expression that represents the relationship between
two value expressions. The value of a conditional expression is
true, false, or null.
18.1.2 – included-name-clause
Includes existing field and record definitions within record
elements. See DEFINE RECORD_Included_Name command for more
information.
18.1.3 – local-field-clause
Specifies the locally defined field. See DEFINE RECORD_Local_Field
command for more information.
18.1.4 – structure-name-clause
Creates structure definitions within record elements. See DEFINE
RECORD_Structure command for more information.
18.1.5 – variants-clause
Creates variants definitions within record elements.
18.2 – Description
The Variants Clause syntax identifies a set of overlays that can
be used by a COBOL REDEFINES statement or by other languages.
Each variants definition can contain two or more fields, records,
structures, variants, or any combination of these definitions.
Be sure that the variants definitions you define conform to the
requirements of the language or language processor that accesses
the record element. For example, you must include a structure
definition for each variants clause contained in a CDO record if
you are developing a new application that will use a 3GL language
and DIGITAL DATATRIEVE.
You can specify a different data type for each definition in a
variants definition.
You can create any number of variants definitions within a record
element.
You can create any number of definitions within a variants
definition.
If you use an expression with one variant, you must use an
expression with every other variant in the variants definition.
In variant expressions, you can refer to a tag variable (field
definition) whose runtime value determines which variant in a
variants definition maps to the record element. The tag variable
cannot be part of an array.
At runtime, the product using CDO tests the value of each
Boolean expression in the variants definition to determine which
definition is the current variants definition. The variants with
a Boolean expression that evaluates to true is chosen.
The values that you test for in the expressions of a variants
definition must conform to the following rules:
o The values being tested must be valid values for the data type
of the tag variable. For example, if the data type for the tag
variable is text, the value you test for must be a string.
o The range of values being tested in one expression must not
overlap the range of values in any other expression.
Each variants definition begins on the same byte in the record,
subject to individual alignment options. The length of the
longest definition in a variants definition determines the
overall length of the variants definition.
18.3 – Examples
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.
In this example, the DEFINE RECORD command creates the PRODUCT_
INVENTORY record element, which contains a variants definition
consisting of three structure definitions. Each structure
definition uses an expression whose value is compared to
the value of the tag variable (FIELD_ID field definition) at
runtime to determine which structure definition maps to the
record element.
19 – REPOSITORY
Format
DEFINE REPOSITORY anchor-name [ ALTERNATE_ROOT dir-name ] .
19.1 – Parameters
19.1.1 – anchor-name
Specifies the OpenVMS directory in which you are creating the
repository. The directory must be empty. If you specify a
directory that does not exist, CDO creates one for you in your
default directory and places the repository files there. Do not
modify or delete the files created by Oracle CDD/Repository;
otherwise, you will corrupt your repository.
If you plan to provide remote access to your repository with
the ALTERNATE_ROOT parameter, the device associated with the
anchor name cannot be mounted through the VAX Distributed File
Service (DFS). Using the ALTERNATE_ROOT parameter lets you move
binary files to a top-level directory, which reduces the depth of
directories created. It also allows you to move binary files to
another disk, reducing I/O contention on the anchor disk.
19.1.2 – dir-name
Specifies your top OpenVMS file directory. (Use a logical name,
instead of a full node name.) The device associated with the
directory can be mounted through DFS.
19.2 – Description
The DEFINE REPOSITORY command creates a physical CDO repository.
Specify the OpenVMS directory where you want the repository to
reside.
You can charge disk resources for your repository to a resource
identifier by setting this identifier as the owner of the files
DEFINE REPOSITORY creates. First, issue the DEFINE REPOSITORY
command, which sets the creator as the file owner. Then,
issue the CHANGE PROTECTION command. This operation requires
privileges.
OpenVMS utilities, including the OpenVMS BACKUP utility, cannot
directly access repository files unless you invoke them from an
account with system privileges.
RESTRICTION
Do not store any files in the OpenVMS directory that
contains the repository, except the files created by Oracle
CDD/Repository. Otherwise, if you decide to delete the
repository later, Oracle CDD/Repository deletes all files
in this directory.
Do not create a repository in your top level directory
[000000].
Once a repository is defined using the ALTERNATE_ROOT
parameter, the alternate root cannot be changed or moved.
Changing the alternate root means that your binary files
are no longer under the repository anchor. When you back up
the repository, you must synchronize the backup of all the
repository files.
19.3 – Remote Access
You can issue DEFINE REPOSITORY on a local (host) machine, but
not on a remote (client) machine.
To make your repository available to remote users, perform the
following steps:
1. Ask your system manager to make the ALTERNATE_ROOT directory
a DFS access point. This action makes the directory and
subdirectories known to a DFS server.
2. Issue the DEFINE REPOSITORY command, including an ALTERNATE_
ROOT parameter. This action permanently associates the
file directories with the anchor directory. You should not
explicitly refer to the file directories again. For example:
DEFINE REPOSITORY DEV1:[PROJECT.CDD]
ALTERNATE_ROOT DEV2:[PROJECT.FILES]
For backup purposes, you can choose to move your anchor
directory to the DFS disk where you store your file
directories. In this case, you specify the same logical name
for both anchor and ALTERNATE_ROOT directories. For example:
DEFINE REPOSITORY DEV1:[PROJECT.CDD]
ALTERNATE_ROOT DEV1:[PROJECT.FILES]
To access a repository from a host machine, perform the following
steps:
1. Ask your system manager to make the DFS access point available
on your system. During the DFS mount, the manager identifies
the access point by the ALTERNATE_ROOT logical name. For
example, if the DEFINE REPOSITORY command issued at the host
machine referred to ALTERNATE_ROOT DEV1:[PROJECT.FILES], the
manager refers to DEV1.
2. Issue a SET DEFAULT command that includes the full node name
of the anchor directory. For example:
SET DEFAULT A_NODE::DEV1:[PROJECT.CDD]
3. Review the default protection you receive on file directories.
DFS does not support remote specification of file ACLs. You
must make any modifications on the host system.
19.4 – Repository Templates
When you install Oracle CDD/Repository on your system,
the installation procedure creates a template repository
(CDD$TEMPLATE) and a repository database directory
(CDD$TEMPLATEDB). CDD$TEMPLATE contains the CDD$PROTOCOL
directory, which stores all the type definitions Oracle
CDD/Repository uses to create metadata.
The DEFINE REPOSITORY command creates several files in the
specified OpenVMS anchor directory. Oracle CDD/Repository keeps
directory information in these files in the anchor directory;
Oracle CDD/Repository does not store directory information with
the CDO definitions in the Oracle Rdb database.
Oracle CDD/Repository creates all new CDO repositories from
CDD$TEMPLATE and CDD$TEMPLATEDB. If, after defining customized
types in a repository, you want to include these types in all
subsequent repositories that you create, you must make them part
of the template.
To do this, execute the following command procedure:
$ @SYS$LIBRARY:CDD_BUILD_TEMPLATE.COM -
_$ repository-anchor-dir repository-db-anchor-dir
Use the repository-anchor-dir parameter to specify the repository
that contains definitions of your customized types. Use the
repository-db-anchor-dir parameter to specify the empty directory
that will hold database files.
Then, rename the CDD$TEMPLATE and CDD$TEMPLATEDB logicals to the
parameter names you specified.
After you have assigned the logical name CDD$TEMPLATE to a
repository, the protocols in that repository's CDD$PROTOCOLS
directory will be distributed to any new CDO repository you
create. If you have extended the types supplied by Oracle
CDD/Repository or if you have created your own types in a
repository, you may want to assign the logical name CDD$TEMPLATE
to that repository so that these types will be copied into
the CDD$PROTOCOLS directory of any subsequent repositories you
create. If CDD$TEMPLATE is not defined, each new repository you
create will contain only types supplied by Oracle CDD/Repository.
If you no longer want to use the templates supplied by Oracle
CDD/Repository and want to use only the customized template
that you created, delete the original CDD$TEMPLATE and
CDD$TEMPLATEDB directories. Modify the following lines the
SYS$STARTUP:CDDSTRTUP.COM command procedure to point to the new
location of the template:
$ DEFINE/NOLOG/SYSTEM/EXEC CDD$TEMPLATE device:[CDD$TEMPLATE]
$ DEFINE/NOLOG/SYSTEM/EXEC CDD$TEMPLATEDB device:[CDD$TEMPLATEDB]
19.5 – Examples
CDO> DEFINE REPOSITORY DISK1:[BOB.DICT].
In this example, the DEFINE REPOSITORY command creates a CDO
repository in a subdirectory called [BOB.DICT]:
20 – RMS_DATABASE
Format
DEFINE RMS_DATABASE rms-database-name
[DESCRIPTION IS /*text*/] [AUDIT IS /*text*/] .
RECORD record-name .
FILE_DEFINITION [file-definition-property] ... .
[AREAS . {AREA numeric-literal [area-property] ... } ... . END AREAS .]
[KEYS . {KEY numeric-literal [key-property] ... } ... . END KEYS .]
END [ [rms-database-name] RMS_DATABASE ] .
20.1 – Parameters
20.1.1 – rms-database-name
Specifies the logical RMS database element you are creating.
20.1.2 – text
Adds information. Within the DESCRIPTION clause, this is
information documenting the database definition; within the AUDIT
clause, it is a history list entry. Valid delimiters are /* */ or
double quotation marks (" ").
You can use Japanese to document comments in the DESCRIPTION or
AUDIT clause for a field. To do this, use the SET CHARACTER_SET
command, and set the character_set of the session to DEC_KANJI.
20.1.3 – record-name
Specifies an existing record element.
20.1.4 – file-definition-property
Defines the file and record services for a logical RMS database
definition. See File_Area_Key_Properties for the file definition
properties CDO provides.
20.1.5 – area-property
Defines the area properties for a logical RMS database element.
See File_Area_Key_Properties for the area properties CDO
provides.
20.1.6 – numeric-literal
Defines the number of characters or bytes in the field. See
Expressions for more information on numeric literals.
20.1.7 – key-property
Defines the key properties for a logical RMS database element.
See File_Area_Key_Properties for the key properties CDO provides.
20.2 – Description
The DEFINE RMS_DATABASE command creates a logical RMS database
element in a CDO repository.
A logical RMS database consists of only one record and file
definition. However, one logical RMS database definition can
be owned by many physical RMS databases, where each physical RMS
database owns a different CDD$FILE element. To create a physical
RMS database on a disk with the characteristics specified by the
DEFINE RMS_DATABASE command, issue the DEFINE DATABASE command.
To create a valid logical RMS database element, you must specify
at least one record element and a file definition property with a
SEQUENTIAL file organization option.
20.3 – Examples
1.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.
This example has three steps. It shows you how a corporation
can create a logical RMS database definition that can be used
by all of its divisions to maintain employee information in a
physical RMS database.
The data administrator creates the EMPLOYEE_STORAGE RMS
database element in the central corporate repository, using
the DEFINE RMS_DATABASE command.
2.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> 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> DEFINE DATABASE DISG_FILE USING EMPLOYEE_STORAGE
cont> ON DISK1:[DISG]EMP.DAT.
CDO> DEFINE DATABASE SSG_FILE USING EMPLOYEE_STORAGE
cont> ON DISK2:[SSG]EMP.DAT.
CDO> DEFINE DATABASE DBS_FILE USING EMPLOYEE_STORAGE
cont> ON DISK3:[DBS]EMP.DAT.
Each division creates its own employee information database on
disk using the DEFINE DATABASE command and the same logical RMS
database element, EMPLOYEE_STORAGE, from the central corporate
repository.