1 CDO_Commands CDO commands allow you to define, modify, delete, display, and manipulate some elements in the repository. These elements are contexts, collections, partitions, and data definitions. CDO command descriptions do not define terms and concepts described in the Oracle CDD/Repository Architecture Manual and the Using Oracle CDD/Repository on OpenVMS Systems. 2 @_At_Sign Format @file-spec 3 Parameters 4 file-spec Specifies the CDO command file to execute. File-spec can be a fully qualified path name, a relative path name, or a logical name. The default file type is .CDO. 3 Description The @ (at sign) command reads and executes the CDO commands contained in the specified file as if you had entered these commands at the terminal. The file can contain any valid CDO commands, including other @ commands. By default, CDO does not echo commands and comments in your file to the standard output location. You can override this default by including the SET VERIFY command as the first command in your file. By default, CDO exits the file when it encounters an error. You can override this default by including the ON command in your file. When CDO executes an EXIT command in the file, or reaches the end of the file, control returns to the command stream that invoked the file. That command stream can be the terminal or a previous file containing CDO commands. You can issue the @ command at the CDO prompt (CDO>). After the CDO commands execute, the CDO prompt returns. You can issue the @ command as a foreign command at the system level. You can append the @ command to the REPOSITORY OPERATOR command. You can also include the REPOSITORY OPERATOR @ command in an OpenVMS command procedure. To execute a CDO command procedure with a default file type of .CDO, you do not need to specify the file type. If the file type for a CDO command procedure is not .CDO, you must specify the file type to execute the command procedure. After the CDO commands execute, the system prompt returns. If you intend to use your file as an initialization file, you need not issue the @ command. Instead, name your file CDO$INIT.CDO and place it in the directory from which you invoke CDO. CDO then automatically executes this file at the start of each CDO session. You can also define CDO$INIT as a logical name specifying a device, directory, and file name. If you use such a logical name, the file does not need to be in your default directory when you invoke CDO. 3 Examples 1.$ DEFINE CDO$INIT SYS$LOGIN:CDO$INIT.CDO $ SET VERIFY $ SET DEFAULT USER$DISK:[BOB.DICT] $ SHOW DEFAULT CDO> DIRECTORY In this example, the CDO$INIT.CDO initialization file sets your default repository directory. Oracle CDD/Repository automatically executes the initialization file when you invoke CDO from the OpenVMS directory that contains it. 2.CDO> @START CDO> SET DEFAULT USER$DISK:[BOB.DICT] CDO> DIRECTORY Directory USER$DISK:[BOB.DICT] CDDPLUS DIRECTORY CDO> The START.CDO command procedure in this example places you in the [BOB.DICT] directory, then lists the definitions in that directory. The SET VERIFY command in the previous example instructs CDO to display each subsequent command on the terminal screen before execution. 3.CDO> @EMPLOYEES.PROCEDURE In this example, the @ (at sign) command executes the CDO commands in the EMPLOYEES.PROCEDURE command procedure. 4.CDO> @CDDNODE::SYS$DISK:[SMITH.REP]CHANGE.PROCEDURE In this example, the file specification incorporates a fully qualified path name and a user-supplied file type. The @ (at sign) command executes the CHANGE.PROCEDURE file. 5.CDO> @START In this example, the file specification incorporates a file name and the default file type (.CDO). The @ (at sign) command executes the START.CDO file. 6.$ DEFINE CDO$INIT SYS$LOGIN:CDO$INIT.CDO $ TYPE SYS$LOGIN:CDO$INIT.CDO $ SET VERIFY $ SET DEFAULT device:[CDDPLUS]MYDIR $ SHOW DEFAULT $ REPOSITORY OPERATOR In this example, when CDO is invoked, SYS$LOGIN:CDO$INIT.CDO is executed immediately before the CDO prompt is displayed. 2 ATTACH_command Format ATTACH process-name 3 Parameters 4 process-name Specifies the process to which control passes. The process must be an existing process. If the process name contains blanks, lowercase characters, or other special characters, enclose the name in double quotation marks (" "). 3 Description The ATTACH command passes control from the current process to a parent process or a subprocess. 3 Examples 1.CDO> ATTACH JIM SMITH $ In this example, the ATTACH command passes control from the current parent process at the CDO prompt to the JIM SMITH subprocess at the system prompt. 2.CDO> ATTACH "Jim Smith" $ In this example, the ATTACH command passes control from the current parent process at the CDO prompt to the Jim Smith process at the system prompt. The process name is entered in lowercase characters, which requires double quotation marks. 3.CDO> SPAWN $ SHOW DEFAULT USER1:[SMITH] $ ATTACH Smith CDO> SHOW DEFAULT USER1:[SMITH.REP] CDO> ATTACH Smith_1 $SHOW DEFAULT %DCL-S-RETURNED, control returned to process SMITH_1 In this example, the SPAWN command creates a subprocess, and the ATTACH commands pass control back and forth between the spawned subprocess and the parent process. 4.CDO> SPAWN RUN SYS$SYSTEM:SQL$ SQL> SQL> COMMIT SQL> $ATTACH SMITH CDO> CDO> ATTACH SMITH_2 %DCL-S-RETURNED, control returned to process SMITH_2 SQL> In this example, the SPAWN command creates a subprocess to invoke SQL and a secondary subprocess that runs SQL. When you are in CDO and want to reattach to your SQL subprocess, you can avoid subprocess quotas by attaching to the secondary subprocess. 2 ATTACH_TO_COMPOSITE Format { COLLECTION } { FIELD } ATTACH { FILE_ELEMENT type-name } [ qualifier ] element-name ,... { GENERIC type-name } { } { RECORD } TO composite-name [ AUDIT IS /*text*/ ] 3 Parameters 4 type-name Specifies the type of file or generic element to which you are attaching. 4 element-name Specifies the element to which you are attaching. You can substitute an asterisk (*) wildcard character for this parameter. 4 composite-name Specifies the collection, field, record, file, or generic element to which you are attaching. 4 text Adds information to the history list entry. Valid delimiters are /* */ or double quotation marks (" "). You can use Japanese to document comments in the 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 Qualifiers 4 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text identifying each element as the element is attached. 3 Description The ATTACH TO COMPOSITE command attaches a controlled element to the composite you specify. The element then becomes a child of the composite to which you are attaching. Before you issue the ATTACH TO COMPOSITE command, you must have set a context and reserved a composite. The SHOW CONTEXT and SHOW RESERVATIONS commands indicate whether these conditions exist. You can use the ATTACH TO COMPOSITE command in conjunction with the DEFINE, RESERVE, REPLACE, and DETACH commands to link collections in collection hierarchies. See the DEFINE COLLECTION command for an example of a collection hierarchy. You can also use the DETACH FROM COMPOSITE and ATTACH TO COMPOSITE commands to move between lines of descent. See the Oracle CDD/Repository Architecture Manual for more information on lines of descent. 3 Examples 1.CDO> DEFINE PARTITION FIRST_QUARTER AUTOPURGE. CDO> DEFINE CONTEXT SALES cont> BASE_PARTITION FIRST_QUARTER. CDO> SET CONTEXT SALES CDO> DEFINE COLLECTION SALES_EACH_PRODUCT. CDO> CONSTRAIN FIELD PART_NUMBER CDO> RESERVE COLLECTION SALES_EACH_PRODUCT CDO> ATTACH FIELD PART_NUMBER TO SALES_EACH_PRODUCT CDO> REPLACE COLLECTION SALES_EACH_PRODUCT In this example, the ATTACH TO COMPOSITE command attaches the PART_NUMBER field to the SALES_EACH_PRODUCT collection. 2.CDO> RESERVE COLLECTION EMPLOYEE_RECORDS CDO> DETACH FIELD FIRST_NAME(2:BRANCH:2) FROM EMPLOYEE_RECORDS CDO> ATTACH FIELD FIRST_NAME(2) TO EMPLOYEE_RECORDS CDO> REPLACE COLLECTION EMPLOYEE_RECORDS In this example, the ATTACH TO COMPOSITE command attaches a version in the main line of descent, FIRST_NAME(2), to the EMPLOYEE_RECORDS collection. This allows you to create further versions in the main line, instead of in the branch line where you had been working. 2 CHANGE 3 COLLECTION Format CHANGE COLLECTION collection-name [ DESCRIPTION IS /*text*/ ] [ NODESCRIPTION ] [ AUDIT IS /*text*/ ] . [ ] 4 Parameters 5 collection-name Specifies the collection you are modifying. 5 text Modifies 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. 4 Description The CHANGE COLLECTION command modifies a collection by performing a change in place. CDO changes the values you specify, and other values remain the same. Before you can issue the CHANGE COLLECTION command, you must issue the RESERVE COLLECTION command to reserve the collection. The SHOW COLLECTION or SHOW RESERVATIONS command indicates whether a condition is reserved. The RESERVE command creates a new version of the element. Since a collection is a controlled element, CDO freezes previous versions and allows you to modify only the highest visible version. 4 Examples 1.CDO> SET CONTEXT CDO> DEFINE COLLECTION REGIONAL_SALES cont> DESCRIPTION IS "COLLECTION IS REGION_5". CDO> RESERVE COLLECTION REGIONAL_SALES CDO> CHANGE COLLECTION REGIONAL_SALES cont> DESCRIPTION IS "COLLECTION DIRECTORY IS WEST_COAST". CDO> REPLACE COLLECTION REGIONAL_SALES In this example, the CHANGE COLLECTION command modifies the description clause of the REGIONAL_SALES collection. 2.CDO> RESERVE COLLECTION COMPILER_C CDO> CHANGE COLLECTION COMPILER_C cont> NODESCRIPTION cont> AUDIT IS "PHASE REVIEW". CDO> REPLACE COLLECTION COMPILER_C In this example, the CHANGE COLLECTION command removes the description clause and adds audit text. 3 CONTEXT Format CHANGE CONTEXT context-name [ DESCRIPTION IS /*text*/ ] [ NODESCRIPTION ] [ AUDIT IS /*text*/ ] [ ] [ TOP IS collection-name ] [ NOTOP ] [ ] [ {SPECIFIC_VERSION } ] [ DEFAULT_ATTACHMENT IS {LATEST_CHECKIN } ] . [ {LATEST } ] [ { } ] 4 Parameters 5 context-name Specifies the context you are modifying. 5 text Modifies 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. 5 collection-name Specifies a new collection as the top collection for the context. 4 Description The CHANGE CONTEXT command modifies a context by performing a change in place. CDO changes the values you specify, and other values remain the same. Because a context is a nonversioned element, CDO does not accept a branch designation or a version number in the context name. The TOP clause redefines the top collection property for the context. An error occurs if you attempt to redefine the top collection while you have any element reserved to your context. The SHOW CONTEXT or SHOW RESERVATIONS command indicates whether this condition exists. The NOTOP keyword sets the top collection property to a null value. The DEFAULT_ATTACHMENT clause redefines 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 SPECIFIC_ Does not detach the currently attached version. VERSION LATEST_CHECKIN Detaches the currently attached version and attaches the most recently checked in version. LATEST Detaches the currently attached version and attaches the lastest version, whether it is checked in or is a ghost. The LATEST keyword is the default. 4 Examples CDO> CHANGE CONTEXT DEVELOPMENT_CONTEXT cont> DESCRIPTION IS "ARCHIVING THIS CONTEXT" cont> "VERSION 5.0 DEVELOPMENT COMPLETED" cont> NOTOP cont> DEFAULT_ATTACHMENT IS SPECIFIC_VERSION. In this example, the CHANGE CONTEXT command modifies the DEFAULT_ATTACHMENT clause, the description text, and the TOP clause in the DEVELOPMENT_CONTEXT context. 3 DATABASE Format CHANGE DATABASE rms-database-name [ DESCRIPTION IS /*text*/ ] [ NODESCRIPTION ] [ AUDIT IS /*text*/ ] [ ] [ ON file-name ] . 4 Parameters 5 rms-database-name Specifies the physical RMS database you are modifying. 5 text Modifies 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. 5 file-name Specifies a new disk location for the physical RMS database. This OpenVMS file name is a character string having from 1 to 1024 characters. 4 Description The CHANGE DATABASE command modifies a physical RMS database element by performing a change in place. CDO changes the values you specify, and other values remain the same. If an RMS database element is controlled, CDO freezes previous versions and allows you to modify only the highest visible version. If an RMS database is uncontrolled, CDO modifies the highest version unless you specify another version number. If an RMS database element is controlled, you must reserve the database before you can issue the CHANGE DATABASE command. The SHOW DATABASE or SHOW RESERVATIONS command indicates whether this condition exists. The ON clause moves a physical RMS database to a new location on disk. When you specify the ON clause, CDO issues a notice asking you to confirm that you want to move the database. This notice cannot be suppressed. If the CHANGE DATABASE command succeeds, Oracle CDD/Repository moves the physical file on disk and updates the pointer to the physical file in the repository. If the CHANGE DATABASE command fails, Oracle CDD/Repository does not move the database. 4 Examples 1.CDO> CHANGE DATABASE DISG_FILE cont> DESCRIPTION "INFORMATION ON DIS SECTION EMPLOYEES" cont> "PERSONNEL CONTACT IS JIM SMITH" cont> AUDIT "JIM SMITH ACCEPTS THIS ACCOUNT 06/30/90". In this example, the CHANGE DATABASE command modifies the description clause and adds an AUDIT clause to the DISG_FILE database. 2.CDO> CHANGE DATABASE DISG_FILE cont> ON DISK1:[SMITH.PERSONNEL]EMP.DAT. In this example, the CHANGE DATABASE command moves the DISG_ FILE database to a new location. 3 FIELD Format CHANGE FIELD field-name [ DESCRIPTION IS /*text*/ ] [ NODESCRIPTION ] [ AUDIT IS /*text*/ ] [ ] [ field-property ] [ NOfield-property ] ... . [ ] 4 Parameters 5 field-name Specifies the field element you are modifying. 5 text Modifies information. Within the DESCRIPTION clause, this is information documenting the field; 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. 5 field-property Changes the value of an existing property, or adds a new property, in the field element. You specify removal with the NO keyword. See fld-properties for the field properties CDO provides. 4 Description The CHANGE FIELD command modifies a field element by performing a change in place. CDO changes the values you specify, and other values remain the same. If a field element is controlled, CDO freezes previous versions and allows you to modify only the highest visible version. If a field element is uncontrolled, CDO modifies the highest version unless you specify another version number. If a field element is controlled, you must reserve the field before you can issue the CHANGE FIELD command. The SHOW FIELD or SHOW RESERVATIONS command indicates whether this condition exists. When you change a field element that an Oracle Rdb database uses, you may need to integrate the database with the repository. CDO automatically sends a notice with the name of the database when this is necessary. 4 Examples 1.CDO> CHANGE FIELD POSTAL_CODE cont> DESCRIPTION "A 5 DIGIT POSTAL_CODE: NOTE AUDIT" cont> AUDIT "CHANGED TO 9 DIGIT POSTAL_CODE 6/30/90". In this example, the CHANGE FIELD command modifies the description clause and adds an audit clause to the POSTAL_ CODE field element. 2.CDO> CHANGE FIELD TOTAL cont> NOINITIAL_VALUE. In this example, the CHANGE FIELD command removes the INITIAL_ VALUE field property with the NO keyword. 3 FILE_ELEMENT Format CHANGE FILE_ELEMENT type-name element-name [ DESCRIPTION IS /*text*/ ] [ NODESCRIPTION ] [ AUDIT IS /*text*/ ] [ ] [ {n } ] [ property-name IS {quoted-string } ] ... . [ { } ] [ NOproperty-name ] END [ FILE_ELEMENT element-name ] [ type-name ] . 4 Parameters 5 type-name Specifies the type (MCS_BINARY or an MCS_BINARY subtype) of the file element you are modifying. See the Oracle CDD/Repository Information Model for more information on these types. 5 element-name Specifies the file element you are modifying. 5 text Modifies 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. 5 property-name Specifies the property you are adding, changing, or removing. You specify removal with the NO keyword. 5 n Modifies the value (numerical) set for a property. 5 quoted-string Modifies the value (a string enclosed in quotation marks) set for a property. 4 Description The CHANGE FILE_ELEMENT command modifies a file element by performing a change in place. CDO changes the values you specify, and other values remain the same. Because a file element is a controlled element, CDO freezes previous versions and allows you to modify only the highest visible version. Before you can issue the CHANGE FILE_ELEMENT command, you must reserve the file element with the RESERVE FILE_ELEMENT command. 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 for a list of these properties. Errors occur if you attempt to delete the MCS_STOREDIN property from a file element whose STORETYPE is EXTERNAL. CDO requires this property for external files. 4 Examples CDO> RESERVE FILE_ELEMENT MCS_BINARY PARSER_TABLES CDO> CHANGE FILE_ELEMENT MCS_BINARY PARSER_TABLES cont> DESCRIPTION IS "PARSER TABLES FOR VERSION 5.0". cont> END MCS_BINARY. CDO> REPLACE FILE_ELEMENT MCS_BINARY PARSER_TABLES In this example, the CHANGE FILE_ELEMENT command adds description text to the file element PARSER_TABLES. 3 GENERIC Format CHANGE GENERIC type-name element-name [ DESCRIPTION IS /*text*/ ] [ NODESCRIPTION ] [ AUDIT IS /*text*/ ] [ ] [ {n } ] [ property-name IS {quoted-string } ] ... . [ { } ] [ NOproperty-name ] [ DEFINE relationship-name relationship-mbr [ {n } ] [ property-name IS {quoted-string } ] ... . [ { } ] [ NOproperty-name ] END relationship-name DEFINE . ] ... [ DELETE relationship-name relationship-mbr . ] ... END [ element-name ] type-name . 4 Parameters 5 type-name Specifies the type of the generic element you are modifying. This type cannot be MCS_BINARY, a subtype of MCS_BINARY, MCS_ COLLECTION, MCS_CONTEXT, or MCS_PARTITION. See the Oracle CDD/Repository Information Model Volume I for more information. 5 element-name Specifies the generic element you are modifying. 5 text Modifies 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. 5 property-name Specifies the property you are adding, changing, or removing. You specify removal with the NO keyword. 5 n Modifies the value (numerical) set for a property. 5 quoted-string Modifies the value (a string enclosed in quotation marks) set for a property. 5 relationship-name Specifies the relationship type that you are defining or deleting in the generic element. The type must be a subtype of RELATION. 5 relationship-mbr Specifies the generic element that you are defining or deleting as a member of the relationship type. The element must exist in the repository; otherwise, an error occurs. 4 Description The CHANGE GENERIC command modifies a generic element by performing a change in place. CDO changes the values you specify, and other values remain the same. If a generic element is a controlled versioned element, CDO freezes previous versions and allows you to modify only the highest visible version. If a generic element is an uncontrolled versioned element, CDO modifies the highest version unless you specify another version number. If a generic element is controlled, you must reserve the element before you can issue the CHANGE GENERIC command. The SHOW GENERIC or SHOW RESERVATIONS command indicates whether this condition exists. You can modify generic elements that are based on types supplied through Oracle CDD/Repository or on user-supplied (extended) types. If you do most of your work with extended types, Oracle recommends that you should 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 you add, change, or delete a property from the generic element, the property you specify must be a defined or inherited property for the element's type. 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 types. If the generic element you are modifying is based on an extended type and errors occur when you attempt to add or delete a relationship, you may not have specified the processing name property as a required property for your type. The property takes a quoted string value. 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. The type on which the generic element definition is based determines whether an attribute is required or optional in instances of the type. If the type definition specifies that the CDD$DESCRIPTION attribute can be used in instances of the type, you can add documentation text to the generic entity definition or remove existing documentation text. You can display text entered with the DESCRIPTION clause by using the SHOW GENERIC command with the /BRIEF or /FULL qualifiers. If the type definition specifies that the CDD$HISTORY_LIST relationship can be used in instances of the type, you can add explanatory history list entries to the generic entity definition. You can display history list entries for generic entity definitions by using the SHOW GENERIC command with the /AUDIT or /ALL qualifiers. 4 Examples 1.CDO> CHANGE GENERIC CDD$EXECUTABLE_IMAGE MY_PROGRAM cont> MCS_PROCESSINGNAME "OUR_PROGRAM". cont> END MY_PROGRAM CDD$EXECUTABLE_IMAGE. In this example, the CHANGE GENERIC command modifies the MCS$PROCESSING_NAME (MCS_processingName property) of the generic element MY_PROGRAM. MY_PROGRAM is based on the type CDD$EXECUTABLE_IMAGE, which is supplied by Oracle CDD/Repository. 2.CDO> CHANGE GENERIC BOOK CDO_REFERENCE_MANUAL cont> LIBRARY_NUMBER IS "AA-KL45A-TF". cont> END BOOK CDO_REFERENCE_MANUAL. In this example, the CHANGE GENERIC command modifies the LIBRARY_NUMBER of the CDO_REFERENCE_MANUAL generic element. CDO_REFERENCE_MANUAL is based on the user-supplied type BOOK. 3 PARTITION Format CHANGE PARTITION partition-name [ DESCRIPTION IS /*text*/ ] [ NODESCRIPTION ] [ AUDIT IS /*text*/ ] [ ] [ LOOKASIDE_PARTITION IS look-partition-name ,... ] [ NOLOOKASIDE_PARTITION ] [ ] [ PARENT_PARTITION IS parent-partition-name ] [ AUTOPURGE ] [ NOAUTOPURGE ] . [ ] 4 Parameters 5 partition-name Specifies the partition you are modifying. 5 text Modifies 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. 5 look-partition-name Modifies the list of partitions that is visible through this partition. Each partition must be an existing partition. 5 parent-partition-name Modifies the partition hierarchy by naming a parent (owner) for an existing parent (owner) partition. 4 Description The CHANGE PARTITION command modifies a partition by performing a change in place. CDO changes the values you specify, and other values remain the same. Because a partition is a nonversioned element, CDO does not accept a branch designation or a version number in the partition name. The LOOKASIDE_PARTITION clause modifies the list of partitions whose contents are visible through the partition you are modifying. The PARENT_PARTITION clause modifies the partition hierarchy by naming an owner for an existing parent (owner) partition. This clause can be specified only once during the lifetime of the partition, in either the DEFINE PARTITION or CHANGE PARTITION command. The AUTOPURGE and NOAUTOPURGE keywords redefine the autopurge property for the partition. The value of this property indicates whether or not CDO automatically purges intermediate versions of elements in the partition when you promote the latest version. 4 Examples 1.CDO> DEFINE PARTITION FIRST_BASELEVEL AUTOPURGE. CDO> DEFINE PARTITION FRONT_END cont> PARENT_PARTITION IS FIRST_BASELEVEL AUTOPURGE. CDO> DEFINE PARTITION BACK_END cont> PARENT_PARTITION IS FIRST_BASELEVEL cont> LOOKASIDE_PARTITION IS FRONT_END AUTOPURGE. CDO> CHANGE PARTITION FRONT_END cont> LOOKASIDE_PARTITION IS BACK_END. In this example, the CHANGE PARTITION command adds a LOOKASIDE_ PARTITION clause to the FRONT_END partition element. You add this clause in a CHANGE PARTITION command, rather than in the initial DEFINE PARTITION command, because the partition named in a LOOKASIDE_PARTITION clause must be an existing partition. 2.CDO> DEFINE PARTITION FINAL_REPORT AUTOPURGE. CDO> DEFINE PARTITION PUBLICATION_RELEASE AUTOPURGE. CDO> CHANGE PARTITION FINAL_REPORT cont> PARENT_PARTITION IS PUBLICATION_RELEASE. In this example, the CHANGE PARTITION command adds a PARENT_ PARTITION clause to the FINAL_REPORT partition element. 3.CDO> DEFINE PARTITION FIRST_TESTBASELEVEL AUTOPURGE. CDO> CHANGE PARTITION FIRST_TESTBASELEVEL cont> AUDIT IS "LET'S PROMOTE ALL TEST VERSIONS" NOAUTOPURGE. In this example, the CHANGE PARTITION command adds an AUDIT clause and modifies the AUTOPURGE keyword. 3 PROTECTION Format { DIRECTORY } { FIELD } CHANGE PROTECTION FOR { RECORD } element-name ,... { } { GENERIC type-name } [ POSITION n ] [ id1+... ] ACCESS right+ ... . [ ] { REPOSITORY anchor-name } CHANGE PROTECTION FOR { GENERIC MCS_CONTEXT context-name } { } [ POSITION n ] { ACCESS } { DEFAULT_ACCESS } right+ ... . { } 4 Parameters 5 type-name Specifies the type of the generic element whose ACE you are modifying. 5 element-name Specifies the element whose ACE you are modifying. You can use wildcard characters in this name. 5 n Specifies the relative position (a positive integer) in the ACL of the ACE you are modifying. If you omit this parameter and also the id1 parameter, CDO changes the first ACE by default. 5 id Specifies the identifier of the ACE you are modifying. If you omit this parameter and also the n parameter, CDO changes the first ACE by default. 5 right Specifies the access rights you are granting to the users specified in the ACE. 5 anchor-name Specifies the anchor directory for the repository whose ACE you are modifying. 5 context-name Specifies the context for which you are modifying protections. 4 Description The CHANGE PROTECTION command modifies access rights for an access control list entry (ACE) in an access control list (ACL) for an element. When you specify FOR GENERIC MCS_CONTEXT or FOR REPOSITORY, this command can also add an ACE to a default access control list. CHANGE PROTECTION affects a change in place. CDO changes the values you specify, and other values remain the same. You must have CONTROL access rights to change protection for an element or a repository. The POSITION clause identifies the ACE you are changing by its relative position within the ACL. For example, POSITION 3 indicates the third ACE in the ACL. If you specify a number greater than the number of existing ACEs, CDO changes the last ACE in the ACL. The id parameter specifies the user or users affected by the ACE you are changing. The clause consists of one or more UIC, general, or system-specified identifiers. If you specify more than one identifier, a user's process must hold all the identifiers before CDO grants the access rights indicated in the ACE. The ACCESS clause specifies access rights provided by the ACE. See the DEFINE PROTECTION command for more information on access rights. The ACCESS 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. 4 Examples 1.CDO> CHANGE PROTECTION FOR RECORD cont> PAYROLL, PROMOTION [JONES]+INTERACTIVE cont> ACCESS CONTROL+READ. In this example, the CHANGE PROTECTION command affects the access rights for the PAYROLL and PROMOTION record elements. CDO locates the ACE containing [JONES]+INTERACTIVE identifiers and adds additional CONTROL and READ access rights. 2.CDO> CHANGE PROTECTION FOR FIELD cont> EMP_DATE POSITION 3 ACCESS NOALL+READ. In this example, the CHANGE PROTECTION command affects the access rights for the EMP_DATE field element. CDO locates the third ACE in the field's ACL and removes all access rights except READ access. 3.CDO> CHANGE PROTECTION FOR RECORD SALARY ACCESS NONE. In this example, the CHANGE PROTECTION command changes the first ACE in the ACL for the SALARY record element. After the command executes, the users whose identifiers match the identifiers in the first ACE will not have access to the SALARY record element. 4.CDO> CHANGE PROTECTION FOR REPOSITORY PERSONNEL cont> POSITION 3 DEFAULT_ACCESS READ+NOWRITE+CONTROL. CDO> DEFINE FIELD NEW_FIELD DATATYPE TEXT SIZE 5. In this example, the CHANGE PROTECTION command changes the default access rights for the PERSONNEL repository to READ+NOWRITE+CONTROL. If a context has not been set, CDO will then grant the newly created field, NEW_FIELD, with access rights that are equivalent to these repository default access rights. 3 RECORD_Command Format CHANGE RECORD record-name [ DESCRIPTION IS /*text*/ ] [ NODESCRIPTION ] [AUDIT IS /*text*/] [ ] [ constraint-clause ] [ DELETE CONSTRAINT constr-name ] [ record-property ] ... . [ ] [ NOrecord-property ] [ DELETE name . ] ... [ included-name-change-clause ] [ local-field-clause ] [ record-change-clause ] ... [ structure-change-clause ] [ ] [ variants-change-clause ] END [ record-name ] RECORD . 4 Parameters 5 record-name Specifies the record element you are modifying. 5 text Modifies information. Within the DESCRIPTION clause, this is information documenting the record; 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. 5 constraint-clause Adds a condition, known as a constraint, that affects adding or modifying data in a database table (record). Supported constraint types are NOT NULL, PRIMARY KEY, FOREIGN KEY, UNIQUE, and CHECK. Each constraint can be named and supplied with evaluation attributes DEFERRABLE or NOT DEFERRABLE. The default evaluation time for constraints in CDO is NOT DEFERRABLE (the constraint is evaluated at statement time). For more information, see the DEFINE RECORD_Constraint command. 5 constr-name Specifies the name of a constraint. 5 record-property Changes the value of an existing property or adds a new property in record, structure, variants, and variant definitions within a record element. You specify removal with the NO keyword. See rec-properties for the record properties CDO provides. 5 name Specifies the name of a record, structure, or field that you want to delete from the record. 5 included-name-change-clause Allows you to change existing field and record definitions within record elements. For more information, see the CHANGE RECORD_Included_Name_Change command. 5 local-field-clause Specifies the definition of the locally defined field. For more information, see the DEFINE RECORD_Local_Field command. 5 record-change-clause Adds field, record, structure, variants, and variant definitions within an existing record definition. For more information, see the CHANGE RECORD_Record_Change command. 5 structure-change-clause Allows you to change a structure definition within a record element. For more information, see the CHANGE RECORD_Structure_Change command. 5 variants-change-clause Allows you to change a variant definition, which is a set of two or more definitions that map to the same portion of a record element. For more information, see the CHANGE RECORD_Variants_Change command. 4 Description The CHANGE RECORD command modifies a record element by performing a change in place. CDO changes the values you specify, and other values remain the same. If a record element is controlled, CDO freezes previous versions and allows you to modify only the highest visible version. If a record element is uncontrolled, CDO modifies the highest version unless you specify another version number. If a record element is controlled, you must reserve the record element before you can issue the CHANGE RECORD command. The SHOW RECORD or SHOW RESERVATIONS command indicates whether this condition exists. When you change a record element that an Oracle Rdb database uses, you may need to integrate the database with the repository. CDO automatically sends a notice with the name of the database when this possibility occurs. To remove a field, record, or structure definition from a record element, if the definition is not contained within a variant or structure definition, specify the DELETE keyword, followed by the appropriate name or clause for the type of definition you are removing. To remove a definition from within a variant definition, use the NOVARIANTS and VARIANT keyword, followed by the DELETE clause. To remove a definition from within a structure definition, specify the CHANGE RECORD Structure Change Clause. Specify the DELETE keyword, followed by the name of the definition you are removing. If you are deleting a constraint, you must delete the constraint before you delete the field; they cannot be deleted simultaneously using the CHANGE RECORD command. To update the change in the database, you must integrate each change separately. 4 Examples 1.CDO> CHANGE RECORD SUPPLIER_REC cont> ROW_MAJOR ARRAY 1:20. cont> END RECORD. This example uses the CHANGE RECORD command to add an array clause to a record called SUPPLIER_REC. 2.CDO> CHANGE RECORD EMPLOYEE_WORK_SCHEDULE cont> NONAME COBOL. cont> END RECORD. In this example, the CHANGE RECORD command uses the NO keyword to remove the NAME FOR COBOL record property from the EMPLOYEE_ WORK_SCHEDULE record definition. 3.CDO> CHANGE RECORD EMP_ADDRESS. cont> DELETE DEPT_CODE. cont> END RECORD. In this example, the CHANGE RECORD command deletes the DEPT_ CODE field definition. 4.CDO> CHANGE RECORD EMP_ADDRESS. cont> DEFINE EMP_NAME. cont> END EMP_NAME DEFINE. cont> END RECORD. In this example, the CHANGE RECORD command adds the EMP_NAME record definition to the EMP_ADDRESS record element. 5.CDO> CHANGE RECORD EMPLOYEE_REC cont> /* Adding new fields WAGE_STATUS and CLASS_CODE */. cont> DEFINE WAGE_STATUS. cont> END DEFINE. cont> DEFINE CLASS_CODE. cont> END DEFINE. cont> END EMPLOYEE-REC RECORD. To include an additional field in a record definition, use the CHANGE command with the DEFINE record property. The included field becomes the last field in the record definition. This example adds the fields WAGE_STATUS and CLASS_CODE to the record definition EMPLOYEE_REC. 3 RECORD_Included_Name_Change Format global-field-name [ {BIT } ] [ {BYTE } ] [ ALIGNED ON {WORD } BOUNDARY ] [ {LONGWORD } ] [ {QUADWORD } ] [ {OCTAWORD } ] . [ NOALIGNED ] [ [ ] ] [ CONSTRAINT constr-name NOT NULL [DEFERRABLE ] ] [ [NOT DEFERRABLE ] ] [ ] 4 Parameters 5 global-field-name Specifies the global field whose alignment you are creating or modifying. 5 constr-name Specifies a constraint for the field. 4 Description The Included Name Change Clause modifies or cancels the alignment of field or record definitions within a record element. To modify or cancel the alignment of field or record definitions within a structure definition, specify the Structure Change Clause, then the Included Name Change Clause. To modify or cancel the alignment of field or record definitions within a variant definition, specify the Variants Change Clause, then the Included Name Change Clause. To indicate the position of the variant, insert as many VARIANT and END VARIANT keywords as necessary, so each preceding variant is referenced. NOTE When the CHANGE RECORD command is used to change a variants or variant definition or an entity inside a variants or variant definition, you must use the Variants Change Clause to refer to each variants or variant definition that precedes the entity you are changing. 4 Examples 1.CDO> CHANGE RECORD PRODUCT_INVENTORY. cont> PART_NUMBER ALIGNED ON BYTE BOUNDARY. cont> END PRODUCT_INVENTORY RECORD. In this example, the ALIGNED keyword in the CHANGE RECORD command realigns the PART_NUMBER field definition within the PRODUCT_INVENTORY record definition. 2.CDO> CHANGE RECORD PRODUCT_INVENTORY. cont> HOME_APPLIANCES NOALIGNED. cont> END PRODUCT_INVENTORY RECORD. In this example, the NOALIGNED keyword in the CHANGE RECORD command cancels the explicit alignment of the HOME_APPLIANCES record definition within the PRODUCT_INVENTORY record definition. 3 RECORD_Record_Change Format { included-name-clause } { local-field-clause } DEFINE { structure-name-clause } END [ name ] DEFINE . { } { variants-clause } 4 Parameters 5 included-name-clause Includes existing field and record definitions in a record element. See DEFINE RECORD_Included_Name command for more information. 5 local-field-clause Adds the definition of a local field. See DEFINE RECORD_Local_Field command for more information. 5 structure-name-clause Adds a structure definition within a record element. For more information, see the DEFINE RECORD_Structure_Name command. 5 variants-clause Specifies a variants definition that you want to change. For more information, see the DEFINE RECORD_Variants command. 5 name Specifies the definition you are adding or removing within a record element. 4 Description Adds field, record, structure, variants, and variant definitions within an existing record definition. You cannot remove a variant definition from a record with the Record Change Clause. Use the Variants Change Clause instead. If you want to add a definition to a record element, but you do not want the definition to be added within an existing structure or variant definition, specify the DEFINE keyword, followed by the appropriate clause for the type of definition you are adding: o To add a field or record definition, use the Included Name Clause or the Local Field Clause. o To create a structure definition, use the Structure Clause. o To create a variants definition, use the Variants Clause. Any definition you add becomes the last definition in the record you are changing. If you want to remove a field, record, or structure definition from a record element, and these are not contained within a structure or variant definition, specify the DELETE keyword, followed by the appropriate clause for the type of definition you are removing. To add a definition within a structure definition, specify the Structure Change Clause. This clause contains an embedded Record Change Clause where you specify the DEFINE keyword, followed by the appropriate clause for the definition you are adding. To remove a definition from within a structure definition, specify the Structure Change Clause. Specify the DELETE keyword, followed by the name of the definition you are removing. To add a definition within a variant definition, specify the Variants Change Clause. This clause contains an embedded Record Change Clause where you specify the DEFINE keyword, followed by the appropriate clause for the definition you are adding. To indicate the position of the variant, insert as many VARIANT and END VARIANT keywords as necessary, so each preceding variant is referenced. To remove a definition within a variant definition, use the NOVARIANTS or the NOVARIANT keyword of the Variants Change Clause. NOTE When the CHANGE RECORD command is used to change a variants or variant definition or an entity inside a variants or variant definition, you must use the Variants Change Clause to refer to each variants or variant definition that precedes the entity you are changing. 4 Examples 1.CDO> CHANGE RECORD EMP_ADDRESS. cont> DEFINE EMP_NAME. cont> END EMP_NAME DEFINE. cont> END RECORD. With the Record Change Clause, the CHANGE RECORD command adds the EMP_NAME record definition to the EMP_ADDRESS record definition. 2.CDO> CHANGE RECORD EMP_ADDRESS. cont> DELETE DEPT_CODE. cont> END RECORD. With the Record Change Clause, the CHANGE RECORD command deletes the DEPT_CODE field definition. 3.CDO> DEFINE RECORD COMPANY_INVENTORY. cont> STOCK STRUCTURE. cont> DESCRIPTION IS /* RECORD_IDENTIFIER determines field type: */ cont> /* S = In-stock record */ cont> /* B = Back-order record */ cont> /* O = Out-of-stock record. */ cont> RECORD_IDENTIFIER. cont> VARIANTS. 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 "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 "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 STOCK STRUCTURE. cont> END COMPANY_INVENTORY RECORD. CDO> CDO> CHANGE RECORD COMPANY_INVENTORY. cont> STOCK STRUCTURE. cont> RECORD_IDENTIFIER. cont> VARIANTS. cont> VARIANT EXPRESSION IS "S". cont> IN_STOCK STRUCTURE. cont> DELETE STATUS_CODE. cont> END IN_STOCK STRUCTURE. cont> END VARIANT. cont> VARIANT EXPRESSION IS "B". cont> BACK_ORDER STRUCTURE. cont> PRODUCT_NO. cont> DATE_ORDERED. cont> DEFINE DATE_PROMISED cont> END DATE_PROMISED DEFINE. cont> END BACK_ORDER STRUCTURE. cont> END VARIANT. cont> VARIANT EXPRESSION IS "O". cont> OUT_OF_STOCK STRUCTURE. cont> END OUT_OF_STOCK STRUCTURE. cont> END VARIANT. cont> END VARIANTS. cont> END STOCK STRUCTURE. cont> END COMPANY_INVENTORY RECORD. This example shows how to use the Record Change Clause to define or delete entities within a structure or variant definition. The first part of the example shows the COMPANY_INVENTORY record definition. The second part of the example shows how you would use the appropriate syntax and the Record Change Clause to add and remove definitions within a structure and variant. The STATUS_CODE field is removed from the IN_STOCK structure and the DATE_PROMISED field is added to the BACK_ORDER structure. 3 RECORD_Structure_Change Format structure-name STRUCTURE [ DESCRIPTION IS /*text*/ ] [ NODESCRIPTION ] [ ] [ record-property ] [ NOrecord-property ] ... . [ ] [ DELETE name . ] ... [ included-name-change-clause ] [ local-field-clause ] [ record-change-clause ] ... [ structure-change-clause ] [ ] [ variants-change-clause ] END [ structure-name ] STRUCTURE . 4 Parameters 5 structure-name Specifies the structure definition you are changing. 5 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. 5 record-property Changes the value of an existing property, or adds a new property, in the structure definition. You specify removal with the NO keyword. See rec-properties for the record properties CDO provides. 5 name Specifies the name of a record, structure, or field that you want to delete from the record. 5 included-name-change-clause Changes the alignment of a field or record definition within a structure definition. See CHANGE RECORD_Included_Name_Change command for more information. 5 local-field-clause Changes the definition of a local field. See DEFINE RECORD_Local_Field command for more information. 5 record-change-clause Adds field, record, structure, variants, and variant definitions within a structure definition. Removes field, record, and structure definitions from within a structure definition. See CHANGE RECORD_Record_Change command for more information. 5 structure-change-clause Changes a structure definition within a structure definition. (This section describes the Structure Change Clause.) 5 variants-change-clause Specifies a variant definition that you want to change or remove from a structure definition. See CHANGE RECORD_Variants_Change command for more information. 4 Description The Structure Change Clause adds or modifies field, record, structure, and variant definitions within a structure definition. It removes field, record, and structure definitions. You cannot remove a variant definition from a structure definition with the Structure Change Clause. Use the Variants Change Clause instead. To add a definition within a structure definition, specify the Structure Change Clause, which contains an embedded Record Change Clause. Use the DEFINE keyword of the Record Change Clause, followed by the appropriate clause for the definition you are adding. For example, to add a field or record definition to the structure definition, specify the Included Name Clause or Local Field Clause. To add a structure definition, specify the Structure Change Clause. To add a variants definition, specify the Variants Change Clause. The definition you add becomes the last definition in the structure definition. To remove a definition from within a structure definition, specify the Structure Change Clause and the DELETE keyword of the embedded Record Change Clause, followed by the definition name. NOTE When you use the CHANGE RECORD command to change a variants or variant definition or an entity inside a variants or variant definition, you must use the Variants Change Clause to refer to each variants or variant definition that precedes the entity you are changing. 4 Examples CDO> CHANGE RECORD HOUSEHOLD. cont> DELETE ADDRESS. cont> DEPENDENTS STRUCTURE OCCURS 1 TO 4 TIMES cont> DEPENDING ON NUMBER_OF_DEPENDENTS IN HOUSEHOLD. cont> END DEPENDENTS STRUCTURE. cont> END HOUSEHOLD RECORD. In this example, the CHANGE RECORD command removes the ADDRESS field definition and changes the OCCURS...DEPENDING clause in the HOUSEHOLD record definition. 3 RECORD_Variant_Change Format { [[ EXPRESSION IS cond-expr ] ] } { [[ ] . ] } { [[ NOEXPRESSION ] ] } { [[ DELETE name . ] ... ] } { [[ included-name-change-clause ] ] } { [[ ] ] } { VARIANT [[ local-field-clause ] ] END VARIANT . } { [[ ] ] } { [[ record-change-clause ] ... ] } { [[ ] ] } { [[ structure-change-clause ] ] } { [[ variants-change-clause ] ] } { [ ] } 4 Parameters 5 cond-expr Specifies an expression that represents the relationship between two value expressions. The value of a conditional expression is true, false, or null. If one definition uses an expression, each definition in the variant definition must have an expression. Each expression in the Variant Change Clause must be unique. For more information on conditional expressions, see Expressions. 5 name Specifies the name of a record, structure, or field that you want to delete from the record. 5 included-name-change-clause Changes the attribute of a field or record definition within a record element. See CHANGE RECORD_Record_Change command for more information. 5 local-field-clause Changes the definition of a local field. See DEFINE RECORD_Local_Field command for more information. 5 record-change-clause Adds field, record, structure, and variant definitions within a structure definition. Removes field, record, and structure definitions from within a structure definition. See CHANGE RECORD_Record_Change command for more information. 5 structure-change-clause Changes a structure definition within a record element. See CHANGE RECORD_Structure_Change command for more information. 5 variants-change-clause Specifies a variants definition that you want to change or remove from a record definition. 4 Description The Variant Change Clause modifies or removes a variant definition within a variants definition. When you change or add a variant definition to a record definition, you must tell CDO its position. To indicate the position of a variant definition to CDO, you use the VARIANT and END VARIANT keywords, so each preceding variant is referenced. If you specify a conditional expression, the expression must be valid for the layered product that uses your definition. If one definition uses an expression, each definition in the variant definition must use an expression. Each expression in the Variant Change Clause must be unique. To add a definition to a variants or variant definition, use the Variant Change Clause to specify the variants or variant you want to modify. Then use the DEFINE keyword of the Record Change Clause and the appropriate clause for the type of entity definition you are adding. NOTE You must include a structure definition for each variant contained in a CDO record if developing a new application that will use a 3GL language and DIGITAL DATATRIEVE. For example, to add a field or record definition to the variants or variant definition, use the Included Name Change Clause. To create a structure definition in the variants or variant definition, use the Structure Clause. To create another variant or variant definition in the variants or variant definition, use the Variant Change Clause. To remove a field, record, or structure definition from a variants or variant definition, use the Variant Change Clause or the Variants Change Clause to specify the variants or variant definition you are changing. Then remove the field, record, or structure definition by specifying the DELETE keyword of the Record Change Clause and the definition name. To remove a variant definition, use the NOVARIANT keyword of the Variants Change Clause to specify the definitions you are removing. When you add a new definition it becomes the last definition in a variant definition. 4 Examples CDO> CHANGE RECORD EMPLOYEE_RECORD. cont> VARIANTS. cont> VARIANT. cont> END VARIANT. cont> VARIANT. cont> END VARIANT. cont> VARIANT. cont> DELETE RATE. cont> END VARIANT. cont> END VARIANTS. cont> END EMPLOYEE_REC RECORD. In this example, the keyword DELETE in the CHANGE RECORD command removes the RATE field definition from the EMPLOYEE_RECORD record definition. The CHANGE RECORD command does not affect the other two definitions in the variant definition. To indicate that the RATE field definition is in the third variant definition, you must use the Variants Change Clause as shown in this example. The keywords VARIANT and END VARIANT serve as placeholders for those variant definitions that you do not want to change. 3 RECORD_Variants_Change Format { {variant-change-clause } } { VARIANTS. {NOVARIANT. } ... END VARIANTS . } { { } } { NOVARIANTS. } 4 Parameters 5 variant-change-clause Specifies a variant definition that you want to change or remove from a record definition. See the CHANGE RECORD_Variant_Change command for more information. 4 Description The Variants Change Clause modifies or removes a variants definition within a record definition. The NOVARIANTS clause removes a group of variant definitions from a record definition. The NOVARIANT clause removes a specific variant definition from a record definition. To remove a variants definition, use the NOVARIANTS keyword of the Variants Change Clause to specify the definitions you are removing. NOTE When the CHANGE RECORD command is used to change a variants or variant definition or an entity inside a variants or variant definition, you must use the Variants Change Clause to refer to each variants or variant definition that precedes the entity you are changing. 4 Examples CDO> CHANGE RECORD EMPLOYEE_RECORD. cont> VARIANTS. cont> VARIANT. cont> END VARIANT. cont> VARIANT. cont> END VARIANT. cont> VARIANT. cont> DELETE RATE. cont> END VARIANT. cont> END VARIANTS. cont> END EMPLOYEE_REC RECORD. In this example, the keyword DELETE in the CHANGE RECORD command removes the RATE field definition from the EMPLOYEE_RECORD record definition. The CHANGE RECORD command does not affect the other two definitions in the variant definition. To indicate that the RATE field definition is in the third variant definition, you must use the Variants Change Clause as shown in this example. The keywords VARIANT and END VARIANT serve as placeholders for those variant definitions that you do not want to change. 2 CLEAR_NOTICES Format CLEAR NOTICES [ qualifier ] element-name ,... 3 Parameters 4 element-name Specifies the element whose notices you are removing. You can use wildcard characters in the element name. 3 Qualifiers 4 /CURRENT Clears notices at the element you specify. /CURRENT is the default qualifier. 4 /DOWN Clears notices at elements owned by the element. 4 /UP Clears notices at elements that own the element. 3 Description The CLEAR NOTICES command removes notices that CDO has sent to an element. Use the SHOW NOTICES command to confirm that CDO has cleared notices. 3 Examples CDO> CLEAR NOTICES DEPT5 In this example, the CLEAR NOTICES command removes notices for the DEPT5 database definition. 2 CLOSE_FILE_ELEMENT Format CLOSE FILE_ELEMENT type-name element-name 3 Parameters 4 type-name Specifies the type (MCS_BINARY or MCS_BINARY subtype) of the file element you are closing. See the Oracle CDD/Repository Information Model Volume I for more information on these types. 4 element-name Specifies the file element you are closing. You can substitute an asterisk (*) wildcard character for this parameter. 3 Description The CLOSE FILE_ELEMENT command closes an internal file that you have previously opened. See the OPEN FILE_ELEMENT command for more information on opening a file. Since a file element is a versioned element, CLOSE FILE_ELEMENT closes the highest visible version unless you specify another version number. 3 Examples CDO> CLOSE FILE_ELEMENT MCS_BINARY cont> PARSER_TABLES In this example, CDO closes the binary file named PARSER_ TABLES. 2 COMMIT Format COMMIT 3 Description The COMMIT command ends a transaction and makes permanent any changes you made during that transaction. This command also releases all locks and closes all open streams. It affects all databases participating in the currently open transaction. See the START_TRANSACTION command description for restrictions that apply when using START_TRANSACTION . . . COMMIT stream of commands. 3 Restrictions o When you delete a record, local fields within that record are marked for deletion at the end of the transaction, provided that they remain unused at the end of the transaction. Using CDO, there is no way to reuse those local fields. But, it is possible to use them through the Oracle CDD/Repository APIs. Therefore, the local fields cannot be automatically deleted at the same point in the transaction as the record. You must either delete the record and field in separate transactions (outside the START_TRANSACTION . . . COMMIT stream of commands) or, to accomplish this in one transaction, use the ENTER command to enter the local field, delete the record, delete the local field, and then delete the global field. o Usually, if Oracle CDD/Repository issues any errors between the START_TRANSACTION and COMMIT commands, it forces you to roll back the transaction. In some cases, such as in the CHANGE or DELETE commands, Oracle CDD/Repository allows you to commit the transaction. The general rules are: - If you receive an Oracle CDD/Repository error of E or F severity, such as a CDD-E-NODNOTFND message, you must abort the transaction. - If you receive a CDO error of E or F severity, such as a CDO-E-NOTFOUND message, you can continue to operate in the current transaction. 3 Examples CDO> START_TRANSACTION. CDO> DEFINE RECORD REC2. cont> FLD1. END RECORD. CDO> COMMIT CDO> SHOW RECORD REC2 Definition of record REC2 | Contains field FLD1 . . . In this example, the COMMIT command ends a session started with the START_TRANSACTION command. When you use the START_ TRANSACTION and COMMIT commands, the overhead that is associated with these commands is incurred once in the repository and once in the database, rather than once for each CDO command between the START_TRANSACTION and COMMIT commands. The repository is already attached to the database and has already loaded the type definitions. 2 CONSTRAIN Format { FIELD } CONSTRAIN { RECORD } [qualifier] ... element-name ,... { GENERIC type-name } { } [ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ] 3 Parameters 4 type-name Specifies the type of the generic element you are constraining. 4 element-name Specifies the element you are constraining. You can substitute an asterisk (*) wildcard character for this parameter. 4 text Documents the element within the DESCRIPTION clause. Adds information to the history list entry within the AUDIT clause. 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 Qualifiers 4 /CLOSURE Format options: /CLOSURE=TO_BOTTOM /NOCLOSURE (default) Specifies whether CDO constrains additional elements. Using the /CLOSURE=TO_BOTTOM qualifier constrains all children of an element that are uncontrolled. 4 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text identifying each element as the element is constrained. 3 Description The CONSTRAIN command moves an uncontrolled element to a base partition, the first level of approval. An uncontrolled element can be one of the following: o A field, record, or generic element that you created with Oracle CDD/Repository Version 4.0 or later o A field, record, or generic element that you created with Oracle CDD/Repository, outside a context Since fields, records, and generic elements are versioned elements, the CONSTRAIN command constrains the highest visible version unless you specify another version number. Before you issue the CONSTRAIN command, you must create a partition and a context for the uncontrolled element and issue the SET CONTEXT command to this context. The element you are constraining must be a versioned element. When you constrain one version of an element, CDO constrains all versions of the element. An error occurs if you attempt to constrain an element that is reserved. The SHOW RESERVATIONS command indicates whether this condition exists. An error occurs if you attempt to constrain an element that is a parent of an uncontrolled element. Constrain the parent and children simultaneously by issuing the CONSTRAIN command with the /CLOSURE=TO_BOTTOM qualifier. After you constrain an element, you issue the ATTACH TO COMPOSITE command to explicitly attach the element to a collection, field, record, file, or generic element. NOTE The CONSTRAIN command is irreversible. A controlled element cannot be changed to an uncontrolled element. All subsequent versions of the element are controlled. To create subsequent versions, issue the RESERVE command rather than the DEFINE command. 3 Examples CDO> DEFINE CONTEXT SUBSCRIPTIONS BASE_PARTITION FOURTH_QUARTER. CDO> SET CONTEXT SUBSCRIPTIONS CDO> DEFINE COLLECTION MAIL_LABEL. CDO> CONSTRAIN FIELD * In this example, the CONSTRAIN command controls all fields in the current default directory. See the ATTACH_TO_COMPOSITE command for commands to attach the constrained fields to this collection. 2 CONVERT Format { source-name ,... destination-name } CONVERT { /REPOSITORY repository-anchor-name } { } 3 Parameters 4 source-name Specifies the Oracle Dictionary Management Utility (DMU) definition you are converting. The Oracle Dictionary Management Utility (DMU) definition must be a definition of type CDD$RECORD. You can use either a full or relative DMU path name with the CONVERT command. You can also substitute an asterisk (*) wildcard character for this parameter. 4 destination-name Specifies the name that you select for the converted definition in the CDO repository. If you specify more than one DMU definition in the source name, the destination name must have a wildcard character in its name. 4 repository-anchor-name Specifies the device and directory specification of the repository to be upgraded using the CONVERT/REPOSITORY command. 3 Qualifiers 4 /REPOSITORY Specifies that the repository should be upgraded. 3 Description The CONVERT command copies a DMU format definition from the DMU side of the dictionary to the CDO side of the dictionary. The CONVERT command leaves the definition in the DMU side of the dictionary. The CONVERT/REPOSITORY command allows you to perform a minor upgrade (from a Version 5.n repository to a later Version 5.n, a Version 6.1, or a Version 7.0 repository). Using this command requires SYSPRV or BYPASS privilege. Be sure you have an adequate backup of the repository before issuing this command. NOTE The CONVERT command is not the same as the CONVERT/REPOSITORY command, which allows you to perform a minor upgrade of a repository. For details on upgrading repositories using the CONVERT/REPOSITORY command, see the Upgrade_Procedure topic in DCL level help or the instructions for upgrading a dictionary or repository provided in Using Oracle CDD/Repository on OpenVMS Systems. Unless you specify a different path name, the CONVERT command copies a DMU definition into your default CDO directory. When you convert a DMU definition, unless you specify the version number, CDO converts the highest version of the definition. An error occurs if you specify a destination name that is the name of an existing definition in the CDO destination directory. If you convert an Oracle Dictionary Management Utility (DMU) record definition that consists of a single field description statement, CDO converts the record definition to a CDO field definition. When you convert an Oracle Dictionary Management Utility (DMU) format definition that includes a description clause for the definition and another description clause for a structure within the definition, only the structure description clause appears in the CDO format definition. If you have a version of DIGITAL DATATRIEVE prior to Version 5.0 installed on your system, and you are converting a DMU definition that contains a VALID FOR DATATRIEVE IF field attribute or a COMPUTED BY DATATRIEVE field attribute clause, CDO omits these clauses from the resulting CDO definition. If the DMU record that you are converting has a different processing name from the DMU directory name, then the resulting CDO record definition retains the old processing name. However, if both the processing and directory names are the same for the DMU definition, then the resulting CDO record definition retains the same name for both the processing and directory names. When you convert an Oracle Dictionary Management Utility (DMU) definition, CDO creates a default ACL for it. See Using Oracle CDD/Repository on OpenVMS Systems for more information on default protection. To display or manipulate a converted field within a record description with a CDO command, you must assign it a directory name. Use the ENTER command to assign this name. When you convert an Oracle Dictionary Management Utility (DMU) definition to a CDO definition, CDO converts the DMU access rights to CDO access rights. However, because DMU protection is different from CDO protection, there is no CDO equivalent for some DMU access rights. Therefore, CDO must convert some DMU rights to the closest CDO access right. Conversion of Oracle Dictionary Management Utility (DMU) Access Rights to CDO Access Rights shows how CDO converts DMU access rights to the closest CDO equivalent. DMU access rights that are not listed in the table are not translated because no equivalent CDO access right is appropriate. Table 1-1 Conversion of Oracle Dictionary Management Utility (DMU) Access Rights to CDO Access Rights Oracle Dictionary Management Utility (DMU) Access Right Equivalent CDO Access Right CONTROL CONTROL DELETE DELETE Local or global DTR MODIFY MODIFY (confirms that CHANGE access can be granted) DTR READ READ (confirms that SHOW access can be granted) DTR WRITE WRITE (confirms that DEFINE access can be granted) SEE SHOW UPDATE CHANGE + DEFINE 3 Examples 1.CDO> CONVERT CDD$TOP.PERSONNEL.BADGE_NUMBER BADGE_NUMBER In this example, the CONVERT command converts the DMU BADGE_ NUMBER record definition (and any embedded field definitions) to a CDO BADGE_NUMBER record definition in your default CDO directory. 2.CDO> CONVERT CDD$TOP.SHIPMENTS.CUSTOMER_RECORD, cont> CDD$TOP.SHIPMENTS.INVENTORY_RECORD * In this example, CDO converts the DMU record definitions CUSTOMER_RECORD and INVENTORY_RECORD into your CDO directory. Because the asterisk (*) wildcard character was used in the destination-name, the DMU record definitions keep the same names after the conversion. 3.DEFINE RECORD CDD$TOP.HARBORMASTER.YACHTS DESCRIPTION IS /* This record contains the manufacturer, model, and dock number of each yacht in the harbor, along with the owner's name. */. YACHTS STRUCTURE. MANUFACTURER DATATYPE IS TEXT SIZE IS 30 CHARACTERS. MODEL DATATYPE IS TEXT SIZE IS 30 CHARACTERS. DOCK_NUMBER DATATYPE IS TEXT SIZE IS 2 CHARACTERS. NAME STRUCTURE. LAST_NAME DATATYPE IS TEXT SIZE IS 15 CHARACTERS. FIRST_NAME DATATYPE IS TEXT SIZE IS 10 CHARACTERS. MIDDLE_INITIAL DATATYPE IS TEXT SIZE IS 1 CHARACTER. END NAME STRUCTURE. END YACHTS STRUCTURE. END YACHTS RECORD. In this example, YACHTS is the name of a DMU record definition and also of the STRUCTURE field description statement within the record definition. 4.CDO> CONVERT YACHTS YACHTS_NEW CDO> SHOW RECORD/FULL YACHTS_NEW Definition of record YACHTS_NEW | Contains field MANUFACTURER | | Datatype text size is 30 characters | Contains field MODEL | | Datatype text size is 30 characters | Contains field DOCK_NUMBER | | Datatype text size is 2 characters | Contains record NAME | | Contains field LAST_NAME | | | Datatype text size is 15 characters | | Contains field FIRST_NAME | | | Datatype text size is 10 characters | | Contains field MIDDLE_INITIAL | | | Datatype text size is 1 characters CDO> When you convert the DMU record definition YACHTS to the CDO record definition YACHTS_NEW, the resulting CDO record definition has YACHTS_NEW for its directory name and processing name. 2 COPY Format COPY source-name ,... destination-name 3 Parameters 4 source-name Specifies the element you are copying. The source name can be a path name, directory name, or a name with wildcard characters. Oracle CDD/Repository does not support passwords in name strings. When you issue the COPY command, do not include your password in the name string because a CDO-E-KWSYNTAX error will occur. 4 destination-name Specifies the destination to which the element will be copied. The destination name can be a path name, directory name, or a name with one wildcard character. 3 Description The COPY command copies an element and the relationships it owns within the same directory, from one CDO directory to another, or from one physical repository to another. If the element is a versioned element, and you do not specify a version number, CDO copies all versions of the element. The COPY command preserves relationships. If you copy both a parent and child, CDO copies the relationship between them. If you copy the parent, CDO copies the relationship from the new parent to the child. CDO also maintains the previous relationship. If you copy the child, CDO does not copy the relationship. If you substitute a wildcard character for a destination name, CDO copies the element into your current default CDO directory and keeps the same name. If you specify only a directory name for the destination name, CDO copies the element into that CDO directory and keeps the same element name. If you specify both a directory name and a new processing name for the destination name, CDO copies the element into that directory and gives the element the name you specified. Oracle CDD/Repository does not support passwords in name strings. When you issue the COPY command and include your password, you get an error message similar to the following: %CDO-E-KWSYNTAX, syntax error in command line at or near password"::DISK$[CDDPLUS]some.user Rules for Using Wildcard Characters With the COPY Command lists the rules for using wildcard characters with the COPY command. Table 1-2 Rules for Using Wildcard Characters With the COPY Command If Source Name Includes Destination Name Can Include More One Than One No Wildcard Asterisk Asterisk Ellipsis Characters Asterisk (*) Yes No Yes No More Than Yes No Yes No One Asterisk Percent (%) Yes No Yes No Ellipsis Yes No Yes No (...) No Wildcard Yes No Yes Yes Characters In addition to the information in the table, the following rules also apply to the use of wildcard characters in the COPY command: o If you use a wildcard character in the source name, you must use a wildcard character in the destination name. o You can only use one wildcard character in a destination name. o You can only use one ellipsis ( . . . ) in a source or destination name. o You can only use multiple asterisk (*) wildcard characters in the source name. o You can only use percent sign (%) wildcard characters in the source name. 3 Examples 1.CDO> COPY DISK1:[JONES.DICT]PERSONNEL.LAST_NAME cont> DISK2:[BOB.SHOP]WORKERS.LAST_NAME This example uses the full path name to copy the LAST_NAME field element from the DISK1:[JONES.DICT]PERSONNEL directory to the DISK2:[BOB.SHOP]WORKERS directory. 2.CDO> COPY CORPORATE.LAST_NAME, FIRST_NAME cont> DISK1:[JONES.DICT]PERSONNEL.* In this example, the COPY command with the asterisk (*) wildcard character copies the LAST_NAME and FIRST_NAME field elements into the [JONES.DICT]PERSONNEL directory. 3.CDO> COPY CORPORATE.ADDRESS cont> [JONES.DICT]PERSONNEL.EMPLOYEE_ADDRESS In this example, the COPY command copies the ADDRESS record element into the [JONES.DICT]PERSONNEL directory and gives it a new name, EMPLOYEE_ADDRESS. 4.CDO> COPY DISK1:[CORPORATE.DICT]CORP_DEFS... cont> DISK1:[SMITH.DICT]DEVELOPMENT... This example uses the ellipsis (...) to copy an entire subhierarchy from the CORPORATE repository (starting with the CORP_DEFS directory) into the DEVELOPMENT directory of Smith's repository. 2 DEFINE 3 COLLECTION Format DEFINE COLLECTION collection-name [ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ] . 4 Parameters 5 collection-name Specifies the collection you are creating. 5 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. 4 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. 4 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. 3 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 } ] [ { } ] 4 Parameters 5 context-name Specifies the context you are creating. 5 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. 5 partition-name Specifies the base partition of the partition hierarchy. 5 collection-name Specifies the top collection of the collection hierarchy. 4 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. 4 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 ] . 4 Parameters 5 database-name Specifies the database element you are creating. 5 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. 5 rms-database-name Specifies an existing logical RMS database element. It must be the name of an existing CDD$RMS_DATABASE element. 5 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. 4 Qualifiers 5 /EXISTING_FILE Specifies that an RMS file exists and does not need to be created. 4 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. 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. 3 DICTIONARY See the DEFINE REPOSITORY command. 3 DIRECTORY Format DEFINE DIRECTORY directory-name . 4 Parameters 5 directory-name Specifies the directory you are creating. 4 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. 4 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. 3 FIELD Format DEFINE FIELD field-name [ DESCRIPTION IS /*text*/ ] [ AUDIT IS /*text*/ ] [ field-property ] ... . 4 Parameters 5 field-name Specifies the field element you are creating. 5 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. 5 field-property Adds a property to the field element. See fld-properties for the field properties CDO provides. 4 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. 4 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. 3 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 ] . 4 Parameters 5 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. 5 element-name Specifies the file element you are creating. 5 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. 5 quoted-string Sets the value (a string enclosed in quotation marks) for the property you are specifying. 5 property-name Specifies the property whose value you are setting. 5 n Sets the numeric value for a property. 4 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. 4 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. 3 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 ] . 4 Parameters 5 type-name Specifies the type of the generic element you are defining. 5 element-name Specifies the generic element you are defining. 5 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. 5 property-name Specifies a property. 5 n Sets the numeric value for a property. 5 quoted-string Sets the value (a string enclosed in quotation marks) for a property. 5 relationship-name Specifies the relationship that you are defining for the generic element. The type must be a subtype of RELATION. 5 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. 4 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. 4 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. 3 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 ] . } 4 Parameters 5 relationship-mbr-name Specifies an existing element that can be a valid member of the relationship type that you use. 5 type-name Specifies the type of the generic element member you are defining. The type must be compatible with the relationship type. 5 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. 5 property-name Specifies a property. 5 n Sets the numeric value for a property. 5 quoted-string Sets the value (a string enclosed in quotation marks) for the property you are specifying. 5 relationship-name Specifies the relationship type you are defining for the generic element member. The type must be a subtype of RELATION. 5 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. 4 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. 4 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. 3 KEY Format DEFINE KEY [ qualifier ] ... key-name key-equivalence 4 Parameters 5 key-name Specifies the key you are defining. 5 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. 4 Qualifiers 5 /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. 5 /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. 5 /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. 5 /PROTECTED Format options: /PROTECTED /NOPROTECTED (default) Specifies whether CDO protects a key against later redefinition. The default is no protection against redefinition. 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. 5 /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. 4 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 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. 3 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 ] . [ ] 4 Parameters 5 partition-name Specifies the partition you are creating. 5 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. 5 parent-partition-name Specifies the parent partition, which must currently exist. 5 look-partition-name Specifies a related partition that is visible through this partition. The related partition must currently exist. 4 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. 4 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. 3 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+ ... . { } 4 Parameters 5 type-name Specifies the type of the generic element whose ACE you are defining. 5 element-name Specifies the element whose ACE you are defining. You can use wildcard characters in this name. 5 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. 5 id1 Specifies the identifier or identifiers of the existing ACE that will immediately precede the ACE you are defining. 5 id2 Specifies the identifier or identifiers of those users whose access to the element or repository you are defining in this ACE. 5 right Specifies the access rights CDO grants to the users you specified in id2. 5 anchor-name Specifies the anchor directory of the repository whose ACE you are defining. 5 context-name Specifies the context. 4 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. 4 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. 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. 5 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]. 3 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 . 4 Parameters 5 record-name Specifies the record element you are creating. 5 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. 5 record-property Adds a property to the record element. See rec-properties for the record properties CDO provides. 5 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. 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. 5 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. 5 structure-name-clause Creates structure definitions within record elements. See the DEFINE RECORD_Structure_Name command for more information. 5 variants-clause Creates variants definitions within record elements. See the DEFINE RECORD_Variants command for more information. 4 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. 4 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. 3 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] 4 Parameters 5 constr-name Specifies the name of the constraint. 5 field-name Specifies the name of the field to be used in a key or a field that is unique. 5 record-name Specifies the name of the record. 5 expression Specifies a Boolean expression. See Expressions for more information. 4 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. 4 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 3 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 ] ] [ ] 4 Parameters 5 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. 5 field-name Specifies the name of the field to be used in a key or a field that is unique. 5 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. 4 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. 4 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. 3 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 ] ] [ ] 4 Parameters 5 local-field-name Specifies the name of the locally defined field. 5 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. 5 field-property Defines the characteristics of the data you store in field elements. See fld-properties for more information. 5 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. 4 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. 4 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. 3 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 . 4 Parameters 5 structure-name Specifies the structure you are defining. 5 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. 5 record-property Adds a property to the structure definition. See rec-properties for a list of the valid record properties. 5 included-name-clause Includes existing field and record definitions within record elements. See DEFINE RECORD_Included_Name command for more information. 5 local-field-clause Specifies the locally defined field. See DEFINE RECORD_Local_Field command for more information. 5 structure-name-clause Creates structure definitions within record elements. This section describes structure definitions. 5 variants-clause Creates variants definitions within record elements. See DEFINE RECORD_Variants command for more information. 4 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. 4 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. 3 RECORD_Variants Format VARIANTS. { } {VARIANT [EXPRESSION IS cond-expr] . } { [included-name-clause ] } { [local-field-clause ] } ... { [structure-name-clause] ... END VARIANT . } { [variants-clause ] } { } END VARIANTS . 4 Parameters 5 cond-expr Specifies an expression that represents the relationship between two value expressions. The value of a conditional expression is true, false, or null. 5 included-name-clause Includes existing field and record definitions within record elements. See DEFINE RECORD_Included_Name command for more information. 5 local-field-clause Specifies the locally defined field. See DEFINE RECORD_Local_Field command for more information. 5 structure-name-clause Creates structure definitions within record elements. See DEFINE RECORD_Structure command for more information. 5 variants-clause Creates variants definitions within record elements. 4 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. 4 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. 3 REPOSITORY Format DEFINE REPOSITORY anchor-name [ ALTERNATE_ROOT dir-name ] . 4 Parameters 5 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. 5 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. 4 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. 4 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. 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] 4 Examples CDO> DEFINE REPOSITORY DISK1:[BOB.DICT]. In this example, the DEFINE REPOSITORY command creates a CDO repository in a subdirectory called [BOB.DICT]: 3 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 ] . 4 Parameters 5 rms-database-name Specifies the logical RMS database element you are creating. 5 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. 5 record-name Specifies an existing record element. 5 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. 5 area-property Defines the area properties for a logical RMS database element. See File_Area_Key_Properties for the area properties CDO provides. 5 numeric-literal Defines the number of characters or bytes in the field. See Expressions for more information on numeric literals. 5 key-property Defines the key properties for a logical RMS database element. See File_Area_Key_Properties for the key properties CDO provides. 4 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. 4 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. 2 DELETE 3 COLLECTION Format DELETE COLLECTION [ qualifier ] ... collection-name ,... . 4 Parameters 5 collection-name Specifies the collection you are deleting. 4 Qualifiers 5 /DESCENDANTS Format options: /DESCENDANTS /NODESCENDANTS (default) Specifies whether CDO deletes members. When you specify the /DESCENDANTS qualifier, CDO deletes all members that are not also members of additional elements outside the area defined by your top collection. 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the collection is deleted. 4 Description The DELETE COLLECTION command deletes a collection and, optionally, all members of the collection. Because a collection is a controlled element, CDO freezes previous versions and allows you to delete only the highest visible version. If a collection is a member, you must delete its owners before you delete the collection. If the collection's immediate owner is a member of another element, you must trace the relationships back until you reach the element that has no owners and delete elements one by one, in sequence of ownership. If you attempt to delete a collection that owns a version in a different branch, the version must be the latest version in that branch. Otherwise, an error will occur. See the Oracle CDD/Repository Architecture Manual for complete information on branch lines of descent. 4 Examples 1.CDO> DELETE COLLECTION A_COLLECTION. In this example, the DELETE COLLECTION command deletes a collection that is not a member. 2.CDO> DELETE COLLECTION REGIONAL_SALES. CDO> DELETE COLLECTION DISTRICT_SALES. CDO> DELETE COLLECTION LOCAL_AREA_SALES. In this example, the DELETE COLLECTION command deletes a collection, a subcollection, and a further subcollection in sequence of ownership. 3.CDO> DELETE COLLECTION COMPILER_C(3). CDO> DELETE COLLECTION COMPILER_C(2:UPDATE_BRANCH:2). CDO> DELETE COLLECTION COMPILER(2:UPDATE_BRANCH:1). CDO> DELETE COLLECTION COMPILER_C(2). CDO> DELETE COLLECTION COMPILER(1). In this example, successive DELETE COLLECTION commands delete the main line and branch line versions of a collection in sequence of ownership. The branch line originates from version 2 and merges back in version 3. 3 CONTEXT Format DELETE CONTEXT [ qualifier ] ... context-name ,... . 4 Parameters 5 context-name Specifies the context you are deleting. 4 Qualifiers 5 /PARENTS Format options: /PARENTS /NOPARENTS (default) Specifies whether CDO deletes parents. If you have defined a top collection for the context, CDO cannot delete a parent that is also a parent of an element outside this collection or collection hierarchy. 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the context is deleted. 4 Description The DELETE CONTEXT command deletes a context. Because a context is a nonversioned element, CDO does not accept a branch designation or a version number in the context name. If a context is a child, you must delete its immediate parent before you delete the context. If the context's immediate parent is a child of another element, you must trace the relationships back until you reach the element that has no parents. If you delete your current context, CDO sets a null value for the current context before deleting the context. An error occurs if you attempt to delete a context that has opened files or reserved elements. The SHOW CONTEXT or SHOW RESERVATIONS command indicates whether this condition exists. 4 Examples CDO> DELETE CONTEXT A_CONTEXT. In this example, the DELETE CONTEXT command deletes the A_ CONTEXT context. 3 DATABASE Format DELETE DATABASE [ qualifier ] rms-database-name . 4 Parameters 5 rms-database-name Specifies the physical RMS database element you are deleting. You can substitute an asterisk (*) wildcard character for this parameter. 4 Qualifiers 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the physical RMS database element is deleted. 4 Description The DELETE DATABASE command deletes the physical RMS database (CDD$FILE) from disk and its CDD$DATABASE element from the repository. When you issue the DELETE DATABASE command, CDO prompts you to confirm that you want to proceed. You cannot suppress this prompt. If you respond Yes at the prompt, CDO deletes the highest visible version of CDD$FILE and, if you have not specified another version number, the highest visible version of CDD$DATABASE. If CDO cannot delete the physical RMS file from disk, the DELETE DATABASE command fails, and the CDD$DATABASE and CDD$FILE elements remain in the repository. 4 Examples CDO> DELETE DATABASE /LOG EMP_FILE(1) In this example, the DELETE DATABASE command with the /LOG qualifier confirms that CDO deleted the RMS file from disk and the RMS database element EMP_FILE from the repository. 3 DICTIONARY See the DELETE REPOSITORY command. 3 DIRECTORY Format DELETE DIRECTORY [ qualifier ] directory-name ,... . 4 Parameters 5 directory-name Specifies the repository directory you are deleting. 4 Qualifiers 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the directory is deleted. 4 Description The DELETE DIRECTORY command deletes a CDO directory. Unless you change directory protection, only the owner of a CDO directory or the system manager can delete a directory. You can delete only empty directories. CDO deletes only the last directory in a fully qualified path name. For example, if you specify a directory name of [SMITH.DICT]CORPORATE.PERSONNEL.SALARIED, CDO deletes only the SALARIED directory. 4 Examples CDO> DELETE DIRECTORY /LOG PROSPECTS. %CDO-I-DIRDEL, directory PROSPECTS deleted In this example, the DELETE DIRECTORY command with the /LOG qualifier confirms that CDO deleted the PROSPECTS directory. 3 FIELD Format DELETE FIELD [ qualifier ] ... field-name ,... . 4 Parameters 5 field-name Specifies the field element you are deleting. You can substitute an asterisk (*) wildcard character for this parameter. 4 Qualifiers 5 /DESCENDANTS Format options: /DESCENDANTS /NODESCENDANTS (default) Specifies whether CDO deletes children. When you specify the /DESCENDANTS qualifier, and your field element is controlled, CDO deletes all children that are not also children of additional elements outside the area defined by your top collection. If the field is uncontrolled, CDO deletes all children that are not also children of any other elements. 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the field element is deleted. 4 Description The DELETE FIELD command deletes a field element from a repository. If a field element is controlled, CDO freezes previous versions and allows you to delete only the highest visible version. If a field element is uncontrolled, CDO deletes the highest version unless you specify another version number. You cannot delete a field that is a child. Delete the parent first, or include the /DESCENDANTS qualifier to delete parents and children at the same time. 4 Examples CDO> DELETE FIELD /DESCENDANTS ORDER_NUMBER. In this example, the DELETE FIELD command with the /DESCENDANTS qualifier deletes the ORDER_NUMBER field element and its children. 3 FILE_ELEMENT Format DELETE FILE_ELEMENT type-name [qualifier] ... element-name ,... . 4 Parameters 5 type-name Specifies the type (MCS_BINARY or MCS_BINARY subtype) of the file element you are deleting. See the Oracle CDD/Repository Information Model Volume I for information on these types. 5 element-name Specifies the file element you are deleting. You can substitute an asterisk (*) wildcard character for this parameter. 4 Qualifiers 5 /DESCENDANTS Format options: /DESCENDANTS /NODESCENDANTS (default) Specifies whether CDO deletes children. When you specify the /DESCENDANTS qualifier, CDO deletes all children that are not also children of additional elements outside the area defined by your top collection. 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the file element is deleted. 4 Description The DELETE FILE_ELEMENT command deletes a file element and, optionally, all children of the file element to the bottom of the collection hierarchy. Because a file element is a controlled element, CDO freezes all previous versions and allows you to delete only the highest visible version. CDO cannot delete the following versions in a branch line: o A version that is owned by a version in a different branch o A version that owns an intermediate version in a different branch See the Oracle CDD/Repository Architecture Manual for information on branch lines of descent. 4 Examples 1.CDO> DELETE FILE_ELEMENT MCS_BINARY PARSER_TABLES. In this example, the DELETE FILE_ELEMENT command deletes a file element definition that is based on the MCS_BINARY type. 2.CDO> DELETE FILE_ELEMENT MCS_BINARY PARSER_TABLES(3). CDO> DELETE FILE_ELEMENT MCS_BINARY PARSER_TABLES(2:UPDATE_BRANCH:2). CDO> DELETE FILE_ELEMENT MCS_BINARY PARSER_TABLES(3:UPDATE_BRANCH:1). CDO> DELETE FILE_ELEMENT MCS_BINARY PARSER_TABLES(2). CDO> DELETE FILE_ELEMENT MCS_BINARY PARSER_TABLES(1). In this example, successive DELETE FILE_ELEMENT commands delete the main line and the branch line versions of a file element in sequence of ownership. The branch line originates from version 2 and merges back in version 3. 3 GENERIC Format DELETE GENERIC type-name [qualifier] ... element-name ,... . 4 Parameters 5 type-name Specifies the type of the generic element you are deleting. This type cannot be MCS_BINARY, an MCS_BINARY subtype, MCS_COLLECTION, MCS_CONTEXT, or MCS_PARTITION. 5 element-name Specifies the generic element you are deleting. 4 Qualifiers 5 /DESCENDANTS Format options: /DESCENDANTS /NODESCENDANTS (default) Specifies whether CDO deletes children. When you specify the /DESCENDANTS qualifier, and your generic element is controlled, CDO deletes all children that are not also children of additional elements outside the area defined by your top collection. If the generic element is uncontrolled, CDO deletes all children that are not also children of other elements. 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the generic element is deleted. 4 Description The DELETE GENERIC command deletes a generic element. This element can be based on a type supplied by Oracle CDD/Repository or a user-supplied type. If a generic element is a controlled versioned element, CDO freezes previous versions and allows you to modify only the highest visible version. If a generic element is an uncontrolled versioned element, CDO deletes the highest version unless you specify another version number. If you use SQL (structured query language) to delete an Oracle Rdb database file, the corresponding CDD$DATABASE element may remain in Oracle CDD/Repository. You can use the DELETE GENERIC command to delete this element. 4 Examples 1.CDO> DELETE GENERIC CDD$DATABASE DEPT1. In this example, the DELETE GENERIC command deletes the DEPT1 generic element from the repository. 2.CDO> DELETE GENERIC CDD$SOURCE_MODULE cont> /DESCENDANTS /LOG COBOL_SOURCE. In this example, the DELETE GENERIC command with the /LOG and /DESCENDANTS qualifiers confirms that CDO has deleted the COBOL_SOURCE generic element and children. 3 HISTORY Format { FIELD } DELETE HISTORY [ qualifier ] FOR { RECORD } { GENERIC type-name } { } element-name ,... . 4 Parameters 5 type-name Specifies the type of the file or generic element definition whose history entries you are deleting. 5 element-name Specifies the element whose history entries you are deleting. You can use wildcard characters in this parameter. 4 Qualifiers 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the history entries have been deleted. 4 Description The DELETE HISTORY command deletes the history entries for a CDO element. Note that the DELETE HISTORY command deletes the entire history list for a given entity. This is not a PURGE HISTORY command. 4 Examples CDO> DELETE HISTORY FOR RECORD CAR_POOL. In this example, the DELETE HISTORY command deletes the history entries for the CAR_POOL record element. 3 PARTITION Format DELETE PARTITION [ qualifier ] ... partition-name ,... . 4 Parameters 5 partition-name Specifies the partition you are deleting. 4 Qualifiers 5 /PARENTS Format options: /PARENTS /NOPARENTS (default) Specifies whether CDO deletes parents. CDO cannot delete a parent that is also a parent of an element outside the partition or partition hierarchy. When CDO cannot delete any parents, you receive an informational notice. When CDO can delete some parents, you do not receive a notice. 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the partition is deleted. 4 Description The DELETE PARTITION command deletes a partition and, optionally, all the partition's children to the bottom, or root, of the partition hierachy. Since a partition is a nonversioned element, CDO does not accept a branch designation or a version number in partition names. If a partition is a child, you must delete its parent or parents before you delete the partition. If the partition's immediate parent is a child of another element, you must trace the relationships back until you reach the element that has no parents. An error occurs if you attempt to delete a partition that contains elements. Promote or delete elements from a partition prior to issuing the DELETE PARTITION command. 4 Examples 1.CDO> DELETE PARTITION /PARENTS FRONT_END. In this example, the DELETE PARTITION command with the /PARENTS qualifier deletes all the parent partitions of FRONT_END. 2.CDO> DELETE PARTITION /LOG REPORTS. %CDO-I-ENTDEL, entity CDD$DISK:[SMITH.PART]REPORTS deleted In this example, the DELETE PARTITION command with the /LOG qualifier confirms that CDO deleted the partition REPORTS. 3 PROTECTION Format DELETE PROTECTION [ qualifier ] FOR { DIRECTORY } { FIELD } { RECORD } element-name ,... { } { GENERIC type-name } [ POSITION n ] [ id+ ... ] [ ACCESS ] . [ ] DELETE PROTECTION [ qualifier ] FOR { REPOSITORY anchor-name } [ POSITION n ] [ ACCESS ] [ DEFAULT_ACCESS ] . [ ] 4 Parameters 5 type-name Specifies the type of file or generic element definition whose ACE or ACL you are deleting. 5 element-name Specifies the element whose ACE or ACL you are deleting. You can use wildcard characters in this parameter. 5 n Specifies the relative position of the ACE in the ACL that you are deleting. 5 id Specifies the identifiers for the ACE you are deleting. 5 anchor-name Specifies the repository anchor directory whose ACE or ACL you are deleting. 4 Qualifiers 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the ACE or ACL is deleted. 4 Description The DELETE PROTECTION command deletes an access control list entry (ACE) or the entire access control list (ACL) for a CDO element or repository. You need CONTROL access to delete protection. The POSITION clause tells CDO the relative position of the ACE to delete. ACEs are numbered starting with one. You can also delete a particular element ACE by specifying the identifier or identifiers contained in that ACE. If you omit the identifiers and the POSITION clause, CDO deletes the entire ACL. After the DELETE PROTECTION command executes, CDO resequences the remaining ACEs in the ACL. The default access type for all cases is ACCESS. 4 Examples 1.CDO> DELETE PROTECTION FOR RECORD CAR_POOL POSITION 5. In this example, the DELETE PROTECTION command deletes the fifth ACE in the ACL for the CAR_POOL record element. 2.CDO> DELETE PROTECTION FOR RECORD CAR_POOL [23,56]. In this example, the DELETE PROTECTION command deletes the ACE with the identifier [23,56] for the CAR_POOL record element. 3 RECORD Format DELETE RECORD [ qualifier ] ... record-name ,... . 4 Parameters 5 record-name Specifies the record element you are deleting. 4 Qualifiers 5 /DESCENDANTS Format options: /DESCENDANTS /NODESCENDANTS (default) Specifies whether CDO deletes children. When you specify the /DESCENDANTS qualifier, and your record element is controlled, CDO deletes all children that are not also children of additional elements outside the area defined by your top collection. If the record element is uncontrolled, CDO deletes all children that are not also children of other elements. 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the record element is deleted. 4 Description The DELETE RECORD command deletes a record element from a CDO repository. If the record element is controlled, CDO freezes previous versions and allows you to delete only the highest visible version. If the record element is uncontrolled, CDO deletes the highest version unless you specify another version number. 4 Examples CDO> DELETE RECORD /DESCENDANTS CUSTOMER_ORDERS. In this example, the DELETE RECORD command with the /DESCENDANTS qualifier deletes the CUSTOMER_ORDERS record element and children. 3 REPOSITORY Format DELETE REPOSITORY [ qualifier ] repository-name ,... . 4 Parameters 5 repository-name Specifies the anchor directory of the repository you are deleting. 4 Qualifiers 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the repository is deleted. 4 Description The DELETE REPOSITORY command deletes all the elements in a repository, any relationships between elements in the repository or elements in other repositories, and the repository itself. Unless you change repository protection, only the owner of a repository or the system manager can delete a CDO repository. You cannot delete a repository if it contains an element that is used by another element in a different repository. CAUTION Before you delete a repository, be sure your elements do not have relationships to other elements in other repositories. Check to make sure you have not stored user-created files in the repository. 4 Examples CDO> DELETE REPOSITORY DISK1:[BOB.DICT]. In this example, the DELETE REPOSITORY command deletes the DISK1:[BOB.DICT] repository. 3 RMS_DATABASE Format DELETE RMS_DATABASE [ qualifier ] rms-database-name . 4 Parameters 5 rms-database-name Specifies a logical RMS database element. 4 Qualifiers 5 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the RMS database element is deleted. 4 Description The DELETE RMS_DATABASE command deletes a logical RMS database element from the repository. If the RMS database element is controlled, CDO freezes previous versions and allows you to delete only the highest visible version. If the RMS database element is uncontrolled, CDO deletes the highest visible version unless you specify another version number. Before you can issue the DELETE RMS_DATABASE command, you must have deleted the associated physical RMS database element with the DELETE DATABASE command. 4 Examples 1.CDO> DELETE DATABASE DISG_FILE(2). . . . CDO> DELETE RMS_DATABASE /LOG EMPLOYEE_STORAGE. In this example, the DELETE DATABASE command prompts you to confirm that you intend to delete the physical RMS database file from disk. CDO confirms this deletion. The DELETE RMS_ DATABASE command with the /LOG qualifier confirms that CDO has deleted the logical RMS database element EMPLOYEE_STORAGE. 2.CDO> DELETE RMS_DATABASE EMPLOYEE_STORAGE. %CDD-E-INUSE, element is the member of a relationship; it cannot be deleted CDO> DELETE DATABASE DISG_FILE(2). 1 deleting file DISK1:[SMITH]EMP.DAT; proceed? [Y/N]) (N)Y 2 %CDO-I-FILEDEL, file DISK1:[SMITH]EMP.DAT; deleted CDO> DELETE RMS_DATABASE /LOG EMPLOYEE_STORAGE. 3 This example shows the result when you try to delete a logical RMS database definition from the repository while a physical RMS database (on disk) is using it. When you delete the physical database (EMP.DAT), you can then delete the logical database. 1 Delete the physical RMS database definition from the repository. 2 Type Y in acknowledgement that CDO deletes the physical RMS file from disk. 3 Delete the logical RMS database definition from the repository. The /LOG qualifier provides a confirmation of deletion. 2 DETACH_FROM_COMPOSITE Format { COLLECTION } { FIELD } DETACH { RECORD } { FILE_ELEMENT type-name } { } { GENERIC type-name } [qualifier] element-name ,... FROM composite-name [ AUDIT IS /*text*/ ] 3 Parameters 4 type-name Specifies the type of the element you are detaching. 4 element-name Specifies the name of the element from which you are detaching. You can substitute an asterisk (*) wildcard character for this parameter. 4 composite-name Specifies the name of the composite from which you are detaching. 4 text Adds information to the history list entry. Valid delimiters are /* */ or double quotation marks (" "). You can use Japanese to document comments in the 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 Qualifiers 4 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text identifying each element as the element is detached. 3 Description The DETACH FROM COMPOSITE command detaches an element from a composite. The element must be a controlled element that is not currently reserved. It also must be currently attached to the composite. Before you issue the DETACH FROM COMPOSITE command, you must have a context set and your composite reserved. The SHOW CONTEXT and SHOW RESERVATIONS commands indicate whether these conditions exist. You can use the DETACH FROM COMPOSITE command in conjunction with the DEFINE, RESERVE, REPLACE, and ATTACH TO COMPOSITE commands to link collections into collection hierarchies. See the DEFINE COLLECTION command for an example of a collection hierarchy. You can also use the DETACH FROM COMPOSITE and ATTACH TO COMPOSITE commands to move between lines of descent. See the Oracle CDD/Repository Architecture Manual for more information. 3 Examples 1.CDO> RESERVE COLLECTION SALES_EACH_PRODUCT CDO> ATTACH FIELD PART_NUMBER TO SALES_EACH_PRODUCT CDO> REPLACE COLLECTION SALES_EACH_PRODUCT . . . CDO> RESERVE COLLECTION SALES_EACH_PRODUCT CDO> DETACH FIELD PART_NUMBER FROM SALES_EACH_PRODUCT CDO> REPLACE COLLECTION SALES_EACH_PRODUCT In this example, the DETACH command detaches an element from a collection. 2.CDO> RESERVE COLLECTION EMPLOYEE_RECORDS CDO> DETACH FIELD FIRST_NAME(2:BRANCH:2) FROM EMPLOYEE_RECORDS CDO> ATTACH FIELD FIRST_NAME(2) TO EMPLOYEE_RECORDS CDO> REPLACE COLLECTION EMPLOYEE_RECORDS In this example, the DETACH FROM COMPOSITE command detaches a version in the branch line of descent, FIRST_NAME(2:BRANCH:2), from the EMPLOYEE_RECORDS collection. After you attach a version in the main line, FIRST_NAME(2), to EMPLOYEE_RECORDS you can create new versions in the main line, instead of in the branch line where you had been working. 2 DIRECTORY Format DIRECTORY [ qualifier ] ... [ element-name ] ,... 3 Parameters 4 element-name Specifies the element or elements to be listed. This name can specify a CDO element, a CDO directory, or a logical name. 3 Qualifiers 4 /BEFORE Format options: /BEFORE=time /NOBEFORE (default) Selects only those elements dated before the specified time. If you do not specify a time with the /BEFORE qualifier, CDO uses /BEFORE=TODAY qualifier as the value. 4 /BRIEF Format option: /BRIEF (default) Displays the element names and their types. This is the default display. 4 /FORMAT Format options: /FORMAT /NOFORMAT (default) Displays the text specifying whether the element is in CDO or DMU format (in a CDO repository or a DMU dictionary). 4 /FULL Displays the name, type, parent, approximate size, and access control information (protection) for each repository element. If an element appears under an alternate name in a distributed repository, these names appear also. 4 /SINCE Format options: /SINCE=time /NOSINCE (default) Displays only those elements dated at or after the specified time. If you do not specify a time with the /SINCE qualifier, CDO uses /SINCE=TODAY as the value. 4 /TYPE Format options: /TYPE=(type-name,...) /NOTYPE (default) Displays only elements of the specified type or types. You cannot use wildcard characters in the type name. 3 Description The DIRECTORY command lists an element or elements in one or more repository directories. RESTRICTION If you have a context set, CDO limits the display to those elements that are visible to your context. If you do not have a context set, this restriction does not apply. CDO only displays the names of those elements to which you have READ access. With the /BEFORE and /SINCE qualifiers, you can specify any of the following for a time: o Absolute time o Combination of absolute and delta times o A keyword such as TODAY or YESTERDAY See the OpenVMS documentation for more information about specifying times. 3 Examples 1.CDO> DIRECTORY /SINCE=YESTERDAY In this example, the DIRECTORY command will display the names, versions, and types of all elements CDO has created since 00:00 (midnight) of the previous day in the current default directory. 2.CDO> DIRECTORY /FULL DISK1:[JONES.DICT]REVIEW.* Directory DISK1:[JONES.DICT]REVIEW FIRST_NAME(1) FIELD Created: 8-MAY-1995 13:33:28.95 Revised: 8-MAY-1995 13:33:32.99 Owner: [VDD,JONES] Access Cntrl List: (IDENTIFIER=[VDD,JONES],ACCESS=READ+WRITE+MODIFY+ ERASE+SHOW+DEFINE+CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR) (IDENTIFIER=[VDD,CDDCDD],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+DEFINE+ CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR) (IDENTIFIER=[*,*],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+OPERATOR+ADMIN) Size: 2277 dictionary_format: CDO format FULL_ADDRESS(1) RECORD Created: 8-MAY-1995 14:09:51.19 Revised: 8-MAY-1995 14:09:51.19 Owner: [VDD,JONES] Access Cntrl List: (IDENTIFIER=[VDD,JONES],ACCESS=READ+WRITE+MODIFY+ ERASE+SHOW+DEFINE+CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR) (IDENTIFIER=[VDD,CDDCDD],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+DEFINE+ CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR) (IDENTIFIER=[*,*],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+OPERATOR+ ADMIN) Size: 1337 dictionary_format: CDO format . . . In this example, the DIRECTORY command with the /FULL qualifier will display the name, type, parent, and protection information for elements in the REVIEW directory and in any distributed repositories. 2 EDIT Format { FIELD } EDIT { RECORD } [ element-name ] { } 3 Parameters 4 element-name Specifies the field or record element you are creating. 3 Description The EDIT command invokes the CDO editor, which allows you to create uncontrolled field and record definitions. If you do not specify an element name, CDO prompts you for one after you enter the editor. See Using Oracle CDD/Repository on OpenVMS Systems for more information on the CDO editor. 3 Examples CDO> EDIT FIELD In this example, the EDIT command invokes the CDO editor to create an uncontrolled field element. 2 ENTER Format { FIELD } ENTER { RECORD } name1 [ qualifier ] { GENERIC type-name } { } { {DATABASE } } { FROM {RECORD } name2 } { {GENERIC type-name } } { { } } { FOR name3 } 3 Parameters 4 type-name Specifies the type of a generic element. 4 name1 Specifies the processing name of the field, record, or generic element. You can use an asterisk (*) wildcard character to indicate all element names or a specific element name. Afer the ENTER command executes, CDO creates a directory name that is the same as the processing name. 4 name2 Specifies the database, record, or generic element that owns name1. 4 name3 Specifies an additional directory name you are designating for the field, record, or generic element. 3 Qualifiers 4 /RDB_METADATA Format options: /RDB_METADATA /NORDB_METADATA (default) Specifies whether CDO enters a directory name for Oracle Rdb system relations. The /NORDB_METADATA qualifier is the default. This qualifier is synonymous with the SHOW /[NO]SYSTEM qualifier. 3 Description The ENTER command assigns a directory name or an additional directory name to a field, record, or generic element. The FROM clause assigns a directory name to an element that does not have a directory name. For example, field and record elements within an Oracle Rdb database definition may not have directory names. Without a directory name, the DIRECTORY command cannot display an element, and you cannot include the element as part of other elements. For example, you would not be able to include a field element without a directory name in an Oracle Rdb global field definition. The FOR clause assigns an additional directory name to an element that has a directory name. This functionality allows you to give an element different names on a local node and a remote node. You must issue the ENTER command with the FOR clause for an element before you can reserve that element in a distributed environment. See Using Oracle CDD/Repository on OpenVMS Systems for information on reserving elements in a distributed environment. CDO enters directory names in your currect default directory. The ENTER command fails if an element in that directory has a directory name that is the same as the processing name you specify. RESTRICTION The ENTER command does not apply a default ACL to the object being entered. Therefore, if the object did not have an ACL prior to being entered, it will not have one after being entered in the directory system. Setting the desired ACLs is left to the discretion of the user. You cannot issue the ENTER command to enter fields or records within a variant of CDO record definitions that were converted from DMU definitions. Field definitions and record definitions that exist only within the context of a variant cannot be given directory names. Use this command to assign directory names to field definitions or structure definitions within record definitions converted from DMU. When an object (such as a field definition) has a directory name, that object can be included in other definitions (for example, field definitions with directory names can be used as Oracle Rdb global fields). 3 Examples 1.CDO> ENTER FIELD PART_NUMBER FROM DATABASE PARTS In this example, the ENTER command enters a PART_NUMBER directory name for the PART_NUMBER field element from the database element PARTS. 2.CDO> ENTER FIELD SALARY_CLASS FOR WAGE_CLASS In this example, the ENTER command assigns SALARY_CLASS as an alternative directory name for the WAGE_CLASS field element. 3.CDO> ENTER GENERIC MCS_COLLECTION CORP_DATA_DEFS con> FOR CORPORATE:CORP_DATA_DEFS CDO> RESERVE GENERIC MCS_COLLECTION CORP_DATA_DEFS In this example, the ENTER command assigns the alternative directory name CORP_DATA_DEFS on a local node for the collection CORPORATE:CORP_DATA_DEFS. 2 EXIT Format EXIT 3 Description The EXIT command ends a CDO session. You can also exit from CDO by pressing Ctrl/Z. 3 Examples CDO> EXIT $ In this example, the EXIT command exits you from CDO and returns you to the OpenVMS DCL prompt. 2 EXTRACT Format { FIELD } EXTRACT { RECORD } element-name ,... [ qualifier ] { } 3 Parameters 4 element-name Specifies the field or record element that you want to display in the DEFINE command format or ANSI C language format. You can use wildcard characters in this parameter. 3 Qualifiers 4 /LANGUAGE Format options: /LANGUAGE=CC /LANGUAGE=CDO (default) Use the /LANGUAGE qualifier to generate data defintions in one of two formats; either the default DEFINE command format or the ANSI-standard syntax for the C programming language. Valid options are: o CC Specifies that the EXTRACT command converts the record to ANSI C language syntax. Each record that is converted to ANSI- standard syntax will include a comment statement that lists the original Oracle CDD/Repository data type information for each field in the record. For example: char field1; /*Text*/ o CDO Specifies that the EXTRACT command displays one or more repository elements in the format of the DEFINE command. The CDO option is the default. 3 Description The EXTRACT command displays one or more repository elements in the specified format. You can choose the DEFINE command format or the ANSI-standard syntax for the C programming language. By displaying an element in the DEFINE command format, the EXTRACT command makes it easier for you to create new versions of an uncontrolled element. By displaying an element in the ANSI C programming language format, you can use the definition when building applications. You can capture the output of the EXTRACT command in a file by issuing the SET OUTPUT command as the preceding command. For the DEFINE command, edit and execute the command file with the @ command. For the ANSI C programming language format, edit the output file to remove the EXTRACT command and then include the file in an application. If a field has character set attributes, you can display them using the SHOW and EXTRACT commands; in addition, you can use the SHOW command to display size information of a field in both character-based size and octet-based size. See the description of SET CHARACTER_SET command and the DATATYPE_Field_Property help topic found under the fld-properties topic for more information. 3 Examples 1.CDO> DEFINE RECORD FULL_NAME. cont> FIRST_NAME. cont> MIDDLE. cont> LAST_NAME. cont> END RECORD. . . . CDO> DEFINE RECORD HOME_ADDRESS. cont> STREET_ADDRESS. cont> CITY. cont> STATE. cont> POSTAL_CODE. cont> END RECORD. . . . CDO> DEFINE FIELD BADGE DATATYPE IS UNSIGNED LONGWORD SIZE IS 5 DIGITS. CDO> DEFINE RECORD EMPLOYEE_REC_ONE. cont> FULL_NAME. cont> HOME_ADDRESS. cont> BADGE. cont> END RECORD. This example shows the definition of records used in the following examples. 2.CDO> EXTRACT RECORD EMPLOYEE_REC_ONE /LANGUAGE=CC struct employee_rec_one { struct { char first_name[20]; /* Text */ char middle; /* Text */ char last_name[20]; /* Text */ } full_name; struct { char street_address[30]; /* Text */ char city[20]; /* Text */ char state[2]; /* Text */ unsigned long postal_code; /* Unsigned Longword */ } home_address; unsigned long badge; /* Unsigned Longword */ }; This example shows the EXTRACT command specifying the /LANGUAGE=CC qualifier. 3.CDO> EXTRACT RECORD EMPLOYEE_REC_ONE /LANGUAGE=CDO Define record CDDRTEST:[CDDR_TEST.userid.TEST_REP]MY_DIR.EMPLOYEE_REC_ONE . CDDRTEST:[CDDR_TEST.userid.TEST_REP]MY_DIR.FULL_NAME(1). CDDRTEST:[CDDR_TEST.userid.TEST_REP]MY_DIR.HOME_ADDRESS(1). CDDRTEST:[CDDR_TEST.userid.TEST_REP]MY_DIR.BADGE(1) . End record. This example shows the EXTRACT command specifying the default /LANGUAGE=CDO qualifier. 2 FETCH Format FETCH FILE_ELEMENT type-name element-name TO file-name 3 Parameters 4 type-name Specifies the type of file element you are fetching. Valid types are MCS_BINARY or one of the binary subtypes. The binary subtypes are: o MCS_ANALYSIS_DATA_FILE o MCS_BINARY_TOOL o MCS_C_SOURCE_FILE o MCS_DIAGNOSTIC_FILE o MCS_EXECUTABLE_FILE o MCS_LISTING_FILE o MCS_LOG_FILE o MCS_OBJECT_FILE o MCS_TEXT o MCS_TEXT_TOOL 4 element-name Specifies the file element you are fetching. 4 file-name Specifies the name of an OpenVMS file that will be created by the FETCH command. You may include a device and directory with the name. 3 Description The FETCH command copies the contents of a file element to the OpenVMS file specified on the command line. You must use the SET CONTEXT command to define a current context before using the FETCH command. The OpenVMS file created by the FETCH command is available for both read and write access. It has no further connection to the file element from which it was copied or to the repository. You are responsible for maintaining the OpenVMS file. 3 Examples CDO> DEFINE PARTITION FIRST_BASELEVEL. CDO> DEFINE CONTEXT DEVELOPMENT_CONTEXT cont> BASE_PARTITION FIRST_BASELEVEL. CDO> SET CONTEXT DEVELOPMENT_CONTEXT CDO> DEFINE COLLECTION CLIENT. CDO> RESERVE COLLECTION CLIENT CDO> DEFINE FILE_ELEMENT MCS_TEXT_TOOL CLIENT_BUILD cont> STORETYPE INTERNAL. END. CDO> RESERVE FILE_ELEMENT MCS_TEXT_TOOL CLIENT_BUILD CDO> FETCH FILE_ELEMENT MCS_TEXT_TOOL CLIENT_BUILD(1) cont> TO BLD$:BUILD_CLIENT.COM CDO> REPLACE FILE_ELEMENT MCS_TEXT_TOOL CLIENT_BUILD In certain circumstances, you may want to use the FETCH command instead of the OPEN and CLOSE commands. This example shows how to use the FETCH command to access the contents of an earlier version of a file element that is currently reserved. 2 HELP Format HELP [ topic [ subtopic ] ... ] 3 Parameters 4 topic Specifies the topic about which you are requesting information. If you specify an incomplete topic name, CDO displays information on all topics starting with that string. If you specify wildcard characters, CDO displays information on all matching strings. If you do not specify a topic, CDO displays a list of all available topics, followed by a request for a topic. 4 subtopic Provides more information, such as parameters and qualifiers, associated with this command. A subtopic can also be a description and examples of a command. 3 Description The HELP command provides help on CDO commands and concepts. Type Ctrl/Z to exit from help and return to the CDO prompt. 3 Examples CDO> HELP DEFINE COLLECTION In this example, the HELP command requests information on the DEFINE COLLECTION command. 2 MERGE Format { FIELD } { RECORD } MERGE { FILE_ELEMENT type-name } destination-name WITH source-name { } { GENERIC type-name } 3 Parameters 4 type-name Specifies the type of the file or generic element you are merging. 4 destination-name Specifies the name of the merged version. 4 source-name Specifies the name of the branch line version to be merged. 3 Description The MERGE command creates a merge relationship between a branch line version and a new version on the originating line of descent. Both versions must be controlled. If the versions are of type MCS_TEXT, CDO also performs a physical merge that incorporates the highest versions on both lines of descent. If the versions are of another type, you must perform the physical merge yourself with an editor appropriate to your system. If you are familiar with the Oracle CDD/Repository callable interface, you can write a method to perform the physical merging. When you issue the MERGE command, your collection must include the version on the originating line, rather than the version on the branch line. If your collection includes the branch line version, issue the DETACH FROM COMPOSITE and ATTACH TO COMPOSITE commands to attach to the highest version on the originating line. You must reserve this version before you issue the MERGE command. 3 Examples CDO> RESERVE FILE_ELEMENT MCS_TEXT JULY_REPORT(2) CDO> MERGE FILE_ELEMENT MCS_TEXT JULY_REPORT(3) cont> WITH JULY_REPORT(1:DRAFT:2) CDO> REPLACE FILE_ELEMENT MCS_TEXT JULY_REPORT(3) In this example, the MERGE command creates a relationship between JULY_REPORT(1:DRAFT:2) on the branch line and JULY_ REPORT(3) on the main line. Because JULY_REPORT is of MCS_TEXT type, the MERGE command also physically merges the contents of JULY_REPORT(1:DRAFT:2) and JULY_REPORT(2) in JULY_REPORT(3). 2 MOVE_REPOSITORY Format MOVE REPOSITORY [ qualifier ] anchor-name1 TO anchor-name2 . 3 Parameters 4 anchor-name1 Specifies the full path name of the anchor directory that contains the repository files you are moving. 4 anchor-name2 Specifies the full path name of the anchor directory to which you are moving the repository files. This must be an empty directory. 3 Qualifiers 4 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the repository files are successfully moved to the new directory. 3 Description The MOVE REPOSITORY command physically moves repository files from one system directory to another system directory. If the MOVE REPOSITORY command is successful, the repository files no longer exist in the original directory. As part of a successful MOVE REPOSITORY command, CDO updates all references to this repository from other repositories to point to the new location. If CDO cannot update any of the references, the MOVE REPOSITORY command fails. 3 Examples CDO> MOVE REPOSITORY DISK1:[SMITH.DICT] TO cont> DISK1:[TAYLOR.REP]. In this example, the MOVE REPOSITORY command moves the repository contents to a different anchor directory. 2 ON Format { WARNING } { CONTINUE } ON { ERROR } THEN { } { SEVERE_ERROR} { STOP } { } 3 Description The ON command specifies an action for CDO to perform when it encounters an error condition during the execution of a command procedure. The following keywords allow you to specify error conditions of increasing severity: o WARNING o ERROR o SEVERE_ERROR Error Handling if Action is CONTINUE describes error handling when you specify CONTINUE. Table 1-4 Error Handling if Action is CONTINUE Error Condition Specified Action Taken on Error WARNING Command procedure continues on warnings only; it stops for errors or severe errors. ERROR Command procedure continues on warnings and errors; it stops for severe errors only. SEVERE_ERROR Command procedure continues on warnings, errors, and severe errors. Error Handling if Action is STOP describes error handling when you specify STOP. Table 1-5 Error Handling if Action is STOP Error Condition Specified Action Taken on Error WARNING Command procedure stops on warnings, errors, or severe errors. ERROR Command procedure stops on errors or severe errors; it continues on warnings only. SEVERE_ERROR Command procedure stops on severe errors; it continues on warnings and errors. By default, errors cause CDO to stop execution if you do not specify an ON command within a command procedure. When CDO stops a command procedure, it returns you to the CDO prompt. If you nest command procedures and the ON command is executed, CDO returns you to the CDO prompt, instead of the previous command procedure. 3 Examples CDO> @MY_PROCEDURE SET VERIFY ON SEVERE_ERROR THEN CONTINUE DEFINE FIELD INVALID FIELD NAME DEFINE FIELD INVALID FIELD NAME ^ %CDO-E-KWSYNTAX, syntax error in command line at or near FIELD DATATYPE IS TEXT IS 7. ^ %CDO-E-KWSYNTAX, syntax error incommand line at or near DATATYPE DEFINE FIELD CORRECT_NAME_FIELD DATATYPE IS TEXT SIZE IS 7. @RECORD.CDO DEFINE RECORD VALID_RECORD. CORRECT_NAME_FIELD. END RECORD. CDO> In this example, the command procedure specifies ON SEVERE_ ERROR THEN CONTINUE. Because the command procedure encounters only an ERROR condition, it continues to execute and defines the CORRECT_NAME_FIELD field element and the VALID_RECORD record element. 2 OPEN_FILE_ELEMENT Format OPEN FILE_ELEMENT type-name element-name 3 Parameters 4 type-name Specifies the type (MCS_BINARY or MCS_BINARY subtype) of the file element you are opening. See the Oracle CDD/Repository Information Model Volume I for information on these types. 4 element-name Specifies the file element you are opening. You can substitute an asterisk (*) wildcard character for this parameter. 3 Description The OPEN command opens an existing internal file. Before you issue the OPEN command, you will most likely want to reserve your file. Reserving the file allows you read/write access. If you do not reserve the file, you have read-only access. Once you have issued the OPEN command, exit from CDO. Set default to the repository files directory that contains the file, and use the commands appropriate for your system to examine or edit it. After you have finished with the file, return to CDO and issue the CLOSE FILE_ELEMENT command at the CDO prompt. 3 Examples CDO> RESERVE FILE_ELEMENT MCS_TEXT JULY_REPORT CDO> OPEN FILE_ELEMENT MCS_TEXT JULY_REPORT CDO> EXIT In this example, CDO opens the text file named JULY_REPORT for editing. 2 PROMOTE Format { COLLECTION } { FIELD } PROMOTE { RECORD } [ qualifier ] element-name ,... { FILE_ELEMENT type-name } { } { GENERIC type-name } [ AUDIT IS /*text*/ ] 3 Parameters 4 type-name Specifies the type of the file or generic element you are promoting. 4 element-name Specifies the element you are promoting. 4 text Adds information to the history list entry. Valid delimiters are /* */ or double quotation marks (" "). You can use Japanese to document comments in the 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 Qualifiers 4 /CLOSURE Format options: /CLOSURE=TO_BOTTOM /NOCLOSURE (default) Specifies whether CDO promotes additional elements. Specifying the /CLOSURE=TO_BOTTOM qualifier promotes all children of an element that reside in the same partition. 3 Description The PROMOTE command moves a controlled element to the next-higher approval level. You cannot promote an element more than one approval level at a time. You cannot promote more than one version of an element at a time. If you do not include a version number, PROMOTE promotes the highest visible version. An error occurs if you attempt to promote an element that is reserved. The SHOW RESERVATIONS command indicates whether this condition exists. An error occurs if you attempt to promote an element that is a parent of another element in the same partition. An error occurs if you attempt to promote an element that is a parent of another element in a partition that is not on the path between the destination partition and the root partition. An error occurs if you attempt to promote an element from the root partition. The root partition is the highest partition in the partition hierarchy. When you promote a version to higher levels of approval, the value of the autopurge property determines whether CDO deletes intermediate versions of the element in the source partition. You set the autopurge property for a partition in the DEFINE PARTITION command. When you promote a version to higher levels of approval, you can still access previous versions at lower levels. However, you must explicitly promote any changes you make to the element at lower levels to see this change reflected in the higher level versions. 3 Examples CDO> PROMOTE RECORD /CLOSURE=TO_BOTTOM SUBSCRIBER In this example, the PROMOTE command promotes the record SUBSCRIBER and all children. 2 PURGE Format { ALL } { FIELD } PURGE { RECORD } [ qualifier ] ... element-name ,... . { } { GENERIC type-name } 3 Parameters 4 type-name Specifies the type of the generic element you are purging. 4 element-name Specifies the element that you are purging. You can use wildcard characters in this parameter. 3 Qualifiers 4 /DESCENDANTS Format options: /DESCENDANTS /NODESCENDANTS (default) Specifies whether CDO also purges children. When you specify the /DESCENDANTS qualifier, and your element is controlled, CDO deletes all children that are not also children of additional elements outside the area defined by your top collection. If the element is uncontrolled, CDO deletes all children that are not also children of any other elements. 4 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text confirming that the element was purged. 3 Description The PURGE command deletes all but the first and last version of an element. You cannot delete the first version, and intermediate versions are not purged if a branch line descends from them, or if they are children in a dependency relationship. You can only purge one line of descent at a time. Purge branch lines before main lines. You must specify a name of an element, or if you are using the PURGE ALL command, use the asterisk (*) wildcard character. 3 Examples 1.CDO> PURGE RECORD REGION.INVENTORY.PART. In this example, the PURGE command deletes all but the first and highest numbered versions of the REGION.INVENTORY.PART record element. 2.CDO> PURGE ALL GREF*. In this example, the PURGE command deletes all but the first and highest versions of each element that begins with the letters GREF. 3.CDO> PURGE FIELD FIRST_NAME. . . . CDO> PURGE RECORD /DESCENDANTS FULL_NAME. In this example, the first PURGE command fails because the FIRST_NAME field element is a child of the FULL_NAME record element. By purging the descendants of FULL_NAME, you can accomplish the desired purge. 2 Remote_Access For information about Remote_Access, go to the DEFINE REPOSITORY help topic. 2 REMOVE Format { FIELD } REMOVE { RECORD } directory-name ,... { GENERIC type-name } { } 3 Parameters 4 type-name Specifies the type of the generic element. 4 directory-name Specifies the directory name you are removing. 3 Description The REMOVE command allows you to remove a directory name for an element that has multiple directory names in a CDO repository or repositories. REMOVE affects all versions of an element. If you issued the ENTER command to reserve elements in a distributed environment, you must issue the REMOVE command after replacing these elements. The REMOVE command deletes the directory name you entered for your element, so other distributed users cannot access or change it by mistake. See the Using Oracle CDD/Repository on OpenVMS Systems for information on reserving elements in a distributed environment. If the name you specify is the only directory name for an element or the element does not have a parent, CDO records an error and does not remove the directory name. 3 Examples 1.CDO> REMOVE FIELD POSTAL_CODE In this example, the REMOVE command deletes the POSTAL_CODE alternate directory name from the repository. 2.CDO> REPLACE COLLECTION CORP_DATA_DEFS CDO> REMOVE COLLECTION CORP_DATA_DEFS In this example, the REMOVE command deletes the CORP_DATA_DEFS alternate directory name on a local node. 2 REPLACE Format {COLLECTION } {FIELD } REPLACE {RECORD } [qualifier] ... element-name ,... {FILE_ELEMENT type-name} {GENERIC type-name } [AUDIT IS /*text*/] 3 Parameters 4 type-name Specifies the type of the file or generic element you are replacing. 4 element-name Specifies the element you are replacing. You can substitute an asterisk (*) wildcard character for this parameter unless you are working in the CDD$METADATA collection, where all wildcards are not allowed. 4 text Adds information to the history list entry. Valid delimiters are /* */ or double quotation marks (" "). You can use Japanese to document comments in the 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 Qualifiers 4 /BRANCH Format options: /BRANCH=branchname /NOBRANCH (default) Specifies whether CDO creates a version on a new branch line or on an existing line of descent. The BRANCH option you specify in the REPLACE command overrides any BRANCH option you specified in the RESERVE command. 4 /CLOSURE Format options: /CLOSURE=keyword /NOCLOSURE (default) Specifies whether CDO replaces additional elements. A CLOSURE operation fails if any element is a child of an element outside the area defined by the CLOSURE keyword. The /CLOSURE qualifier takes one of the following keywords: CLOSURE Keyword Behavior TO_BOTH Replaces the element specified and all parents and children. TO_BOTTOM Replaces the element specified and all children. TO_TOP Replaces the element specified and all parents. If you specify TO_BOTH or TO_TOP, CDO ignores parents of the top collection. 4 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text identifying each element as the element is replaced. 3 Description The REPLACE command checks in a version of an element that you previously checked out with the RESERVE command. You must have a context set to issue the REPLACE command. The REPLACE command converts the ghost copy reserved to your context into a new version stored in a base partition. This new version is accessible to anyone whose context is set to that base partition. To create subsequent versions of a controlled element, use the RESERVE and REPLACE commands, rather than the DEFINE command. An error occurs if you issue the /BRANCH qualifier with a branch name already in use. If you issue the REPLACE command with branch information specified in the element name, do not include a /CLOSURE qualifier. The /CLOSURE qualifier will add this branch name to the name of every element you replace. If you are issuing the REPLACE command in a distributed environment, you must issue the REMOVE command after issuing the RESERVE command. If you decide to discard the changes you have made to your working copy, use the UNRESERVE command to cancel your reservation and destroy your copy. If you decide to merge a branch line that you have created back into the main line of descent, use the MERGE command. 3 Examples 1.CDO> RESERVE FIELD /CLOSURE=TO_TOP FIRST_NAME CDO> CHANGE FIELD FIRST_NAME cont> DESCRIPTION IS "SPELL OUT THOSE INITIALS!" In this example, the REPLACE command replaces the FIRST_NAME field element and all parents to the top of the collection hierarchy. 2.CDO> RESERVE FIELD /CLOSURE=TO_TOP /BRANCH=AUDITOR PRODUCT_NUMBER CDO> CHANGE FIELD PRODUCT_NUMBER(1:AUDITOR:1) cont> AUDIT IS "THESE VERSIONS SUBMITTED FOR AUDIT". CDO> REPLACE FIELD PRODUCT_NUMBER(1:AUDITOR:1) CDO> REPLACE RECORD /CLOSURE=TO_TOP PRODUCTS In this example, the initial REPLACE command replaces the branch version of the PRODUCT_NUMBER field element; a second REPLACE command replaces those elements on the path from PRODUCT to the top collection. 3.CDO> RESERVE FIELD /CLOSURE=TO_TOP PRODUCT_NUMBER(1:AUDITOR:1) CDO> CHANGE FIELD PRODUCT_NUMBER(1:AUDITOR:2) cont> AUDIT IS "SEVEN OBSOLETE PRODUCT NUMBERS". CDO> REPLACE FIELD PRODUCT_NUMBER(1:AUDITOR:2) CDO> REPLACE RECORD /CLOSURE=TO_TOP PRODUCTS In this example, the REPLACE command replaces the new second version in the AUDITOR branch line. 4.CDO> REPLACE FIELD /BRANCH=QA PRODUCT_NUMBER(1:AUDITOR:2) By substituting this command for REPLACE FIELD PRODUCT_ NUMBER(1:AUDITOR:2) in the previous example, you can change the branch name from AUDITOR to QA. 5.CDO> REPLACE FIELD /BRANCH PRODUCT_NUMBER(1:AUDITOR:2) By substituting this command for REPLACE FIELD PRODUCT_ NUMBER(1:AUDITOR:2) in the third example, you can reverse the creation of the branch line and replace PRODUCT_NUMBER on the main line. 2 Repository_Templates For information about Repository_Templates, go to the DEFINE REPOSITORY help topic. 2 RESERVE Format {COLLECTION } {FIELD } RESERVE {RECORD } [qualifier] ... element-name ,... {FILE_ELEMENT type-name} {GENERIC type-name } [AUDIT IS /*text*/] 3 Parameters 4 type-name Specifies the type of the file or generic element you are reserving. 4 element-name Specifies the element you are reserving. You can substitute an asterisk (*) wildcard character for this parameter. If the element is uncontrolled, you must reserve the highest version. 4 text Adds information to the history list entry. Valid delimiters are /* */ or double quotation marks (" "). You can use Japanese to document comments in the 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 Qualifiers 4 /BRANCH Format options: /BRANCH=branchname /NOBRANCH (default) Specifies whether CDO creates a version on a new branch line or on an existing line of descent. The element must be controlled to use the /BRANCH qualifier. 4 /CLOSURE Format options: /CLOSURE=keyword /NOCLOSURE (default) Specifies whether CDO reserves additional elements. A CLOSURE operation fails if any element is a child of an element outside the area defined by the CLOSURE keyword. CLOSURE takes one of the following keywords: CLOSURE Keyword Behavior TO_BOTH Reserves the element specified and all owners and members. TO_BOTTOM Reserves the element specified and all members. TO_CLOSURE Reserves the element specified, all owners, and any element under the top collection that depends on the element specified. TO_TOP Reserves the element specified and all owners. In most cases, you can specify the TO_BOTH, TO_TOP, or TO_BOTTOM keywords. The TO_CLOSURE keyword is useful when you are working with the source and derived files common in system building applications. If you specify TO_BOTH, TO_CLOSURE, or TO_TOP, CDO ignores owners of the top collection. 4 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text identifying each element as the element is reserved. 4 /OUTPUT Format options: /OUTPUT (default) /NOOUTPUT The /NOOUTPUT qualifier lets you reserve a FILE_ELEMENT of type MCS_BINARY without copying the file into the current context directory. This capability is useful for using the repository to manage binary files that are superseded each time they are reserved. It lets you reserve the file element without incurrring the processing time to create the binary file in the context directory. If you use the /NOOUTPUT qualifier in a RESERVE command, you must update the context directory with the latest binary file to be replaced. If you do not update the current context directory with a new file, the REPLACE command will fail. When the REPLACE command fails, CDO displays an error message containing the full directory specification of the reserved file that CDO was attempting to replace. Refer to this error message and place a new copy of the specified file in the context directory. If you reserve a file with the /NOOUTPUT qualifier, CDO does not create the file in the context directory. If you manually place a file in the context directory and then issue the UNRESERVE command, the reserved file is unreserved and any copies of the file in the context directory are deleted. This occurs even if you manually superseded any files in the context directory. NOTE If you use the VERIFY/FIX command on a repository, any files reserved with the /NOOUTPUT qualifier are created in the context directory, because the VERIFY command cannot find reserved files. This performance cost has always been associated with the VERIFY/FIX command when it cannot find reserved files. 3 Description The RESERVE command checks out a version of a controlled element. A controlled element is one of the following: o An element you created using Oracle CDD/Repository inside a context o An element you have controlled with the CONSTRAIN command You must have a context set to issue the RESERVE command. If you are issuing the RESERVE command in a distributed environment, you must issue the ENTER command before issuing the RESERVE command. The RESERVE command creates a copy of the immutable version that is stored in the base partition associated with your context. This copy is called a ghost; it is reserved to your context and you can modify it. In general, the ghost has a version number that is one number higher than that of the original version in the partition. For example, if you reserve PRODUCT(1), the ghost of this version is called PRODUCT(2). If, however, you specify the creation of a parallel line of development (or branch), the ghost becomes the first version in that branch line. For example, if you reserve PRODUCT(2) with a /BRANCH=AUDITOR qualifier, the ghost copy of this version is called PRODUCT(2:AUDITOR:1). If you specify the /BRANCH qualifier, you can reserve any version of a controlled element in a line of descent that is available for reservation. If an element is uncontrolled, an error occurs if you attempt to reserve any version but the latest version in a line of descent. An error occurs if you issue the /BRANCH qualifier with a branch name already in use. An error occurs if you attempt to reserve a child without previously reserving its owners. Use the /CLOSURE qualifier to reserve as many elements as necessary. An error occurs if you attempt to reserve a version of an uncontrolled element that has already been reserved. An element can have only one outstanding reservation. When you finish modifying your working copy of a version, you use the REPLACE command to check in the new version to the partition or the repository. If you decide to discard the changes you have made to your working copy, use the UNRESERVE command to cancel your reservation and destroy your copy. If you decide to merge a branch line that you have created back into the main line of descent, use the MERGE command. When reserve is invoked with a branch name specified, the new ghost version is created with a name that incorporates the branch name and is properly linked to the element from which the branch line originates. If the target of a reserve notice is involved in one or more correspondence relationships, those relationships may be propagated to the new version. 3 Examples 1.CDO> RESERVE FIELD /CLOSURE=TO_TOP FIRST_NAME In this example, the RESERVE command with the /CLOSURE=TO_TOP qualifier reserves the FIRST_NAME field element and all owners to the top collection. 2.CDO> RESERVE FIELD /CLOSURE=TO_TOP /BRANCH=AUDITOR PRODUCT_NUMBER In this example, the RESERVE command with the /CLOSURE=TO_TOP qualifier reserves all elements on the path between the top collection and field PRODUCT_NUMBER; the /BRANCH qualifier creates a branch line AUDITOR descending from PRODUCT_NUMBER. 3.CDO> RESERVE FIELD /CLOSURE=TO_TOP PRODUCT_NUMBER(1:AUDITOR:1) In this example, the RESERVE command reserves the first version in the AUDITOR branch line. 4.SYSTEM collection SOURCE_FILES collection FIRST_FILE.C SECOND_FILE.C INC.H DERIVED_FILES collection FIRST_FILE.OBJ SECOND_FILE.OBJ IMAGE_FILE.EXE In this example, the code shows a collection hierarchy with SYSTEM defined as the top collection. The dependencies in SYSTEM are as follows: o IMAGE_FILE.EXE depends on FIRST_FILE.OBJ and SECOND_ FILE.OBJ. o FIRST_FILE.OBJ depends on FIRST_FILE.C and INC.H. o SECOND_FILE.OBJ depends on SECOND_FILE.C and INC.H. 5.CDO> RESERVE FILE_ELEMENT MCS_BINARY /CLOSURE=TO_CLOSURE INC.H In this example, the RESERVE command reserves the following elements: o Element INC.H o Owners of the element specified, SOURCE_FILES and SYSTEM o Elements that directly or indirectly depend on the element, FIRST_FILE.OBJ, SECOND_FILE.OBJ, IMAGE_FILE.EXE 6.CDO> RESERVE FILE_ELEMENT MCS_BINARY /NOOUTPUT "/ISAM_FILE.DAT" In this example, ISAM_FILE.DAT is reserved using the /NOOUTPUT qualifier, but the file is not copied into the current context directory. 2 ROLLBACK Format ROLLBACK 3 Description The ROLLBACK command terminates a transaction and undoes all changes that have been made to the database since the program's most recent START_TRANSACTION command. The ROLLBACK command also releases all locks, closes all open streams, and releases all readied relations. It affects all databases participating in the currently open transaction. The ROLLBACK command implicitly performs the END_STREAM statement. 3 Restrictions o When you delete a record, local fields within that record are marked for deletion at the end of the transaction, provided that they remain unused at the end of the transaction. Using CDO, there is no way to reuse those local fields. It is possible to use local fields through the Oracle CDD/Repository APIs. Therefore, the local fields cannot be automatically deleted at the same point in the transaction as the record. You must either delete the record and field in separate transactions (outside the START_TRANSACTION . . . COMMIT stream of commands) or, to accomplish this in one transaction, use the ENTER command to enter the local field, delete the record, delete the local field, and then delete the global field. o Usually, if Oracle CDD/Repository issues any errors between the START_TRANSACTION and COMMIT commands, it forces you to roll back the transaction. In some cases, such as in the CHANGE or DELETE commands, Oracle CDD/Repository allows you to commit the transaction. The general rules are: - If you receive an Oracle CDD/Repository error of E or F severity, such as a CDD-E-NODNOTFND message, you must abort the transaction. - If you receive a CDO error of E or F severity, such as CDO-E-NOTFOUND, you can continue to operate in the current transaction. 3 Examples CDO> START_TRANSACTION CDO> DEFINE RECORD REC2. cont> FLD1. END RECORD. . . . CDO> SHOW RECORD REC2 Definition of record REC2 | Contains field FLD1 CDO> ROLLBACK CDO> SHOW RECORD REC2 %CDO-E-ERRSHOW, error displaying an object -CDO-E-NOTFOUND, entity REC2 not found in dictionary In this example, a record is defined within a transaction, but because the transaction is terminated using the ROLLBACK command, the record is not defined. 2 SET 3 CHARACTER_SET Format SET CHARACTER_SET character-set 4 Parameters 5 character-set Specifies the type of characters to be used during the current CDO session. Valid Character Set Names lists the valid character set names. Table 1-6 Valid Character Set Names Character Character Set Type Set Description MCS DEC_MCS A set of international alphanumeric characters Kanji+ASCII DEC_KANJI Japanese characters as defined by the JIS X0208:1990 standard, Narrow Katakana characters, as defined by the JIS X0201:1976 standard, and ASCII characters 4 Description Specifies the valid characters that you can use for an element name, the initial value field property, and in comments. You must set the character-set parameter to DEC_KANJI when you use Japanese with Oracle CDD/Repository. If you omit the SET CHARACTER SET command, Oracle CDD/Repository references the equivalence name of the CDD$CHARACTER_SET logical as the character set for the session. If this logical is not assigned, the default character set is DEC_MCS. RESTRICTION DEC_KANJI is not available through the CDO editor. Oracle CDD/Repository accepts a maximum field and record name length of 31 octets (31 characters for ASCII/MCS characters; 15 characters for Kanji and Narrow Katakana). Oracle CDD/Repository accepts the following characters as the field and record name when the character-set parameter is DEC_ KANJI: o Kanji (Japanese characters as defined by the JIS X0208:1990 standard) o Katakana (Japanese phonetic alphabet, Narrow Katakana, as defined by the JIS X0201:1976 standard) o ASCII characters (A-Z, a-z, _, $) 4 Examples CDO> SET CHARACTER_SET DEC_KANJI In this example, the character-set parameter is DEC_KANJI to support Japanese characters during the CDO session. 3 CONTEXT Format SET CONTEXT [ context-name ] [ AUDIT IS /*text*/ ] 4 Parameters 5 context-name Specifies the context you are setting. If you omit this parameter, CDO sets the current context to null. 5 text Adds information to the history list entry. Valid delimiters are /* */ or double quotation marks (" "). You can use Japanese to document comments in the 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. 4 Description The SET CONTEXT command defines a context as the current context and implicitly controls all versioned elements that you define while the context is set. A context is a nonversioned element. Do not include a version number in the context name. If the top collection associated with the context is undefined, the SET CONTEXT command takes the element named in the next command as the top collection for the context. An error occurs if the next command is not a DEFINE COLLECTION command. The context set remains the current context until you issue another SET CONTEXT command, you delete the context, or you end the CDO session. As an alternative to the SET CONTEXT command, you can define the CDD$CONTEXT logical name. Once set, this context becomes the current context each time you access the repository. For example: $ DEFINE CDD$CONTEXT "cdd$disk:[smith.rep]test_context" 4 Examples CDO> DEFINE PARTITION FIRST_BASELEVEL. CDO> DEFINE CONTEXT DEVELOPMENT_CONTEXT. cont> BASE_PARTITION FIRST_BASELEVEL. CDO> SET CONTEXT DEVELOPMENT_CONTEXT CDO> DEFINE COLLECTION COMPILER_C. 1 CDO> RESERVE COLLECTION COMPILER_C CDO> DEFINE COLLECTION FRONT_END. CDO> DEFINE COLLECTION BACK_END. CDO> REPLACE COLLECTION COMPILER_C. CDO> SET CONTEXT 2 CDO> DEFINE RECORD ISSUES. In this example, the SET CONTEXT command sets the current context and implicitly defines a collection as the top collection. Subsequent definitions will be implicitly controlled. 1 The DEFINE COLLECTION command sets the top collection for the current context. All definitions made within the current context are attached to the top collection. FRONT_END and BACK_END are attached to COMPILER_C. 2 The SET CONTEXT command sets the current context to a null value. ISSUES is uncontrolled and unattached because it is defined outside a context. 3 DEFAULT Format SET DEFAULT path-name 4 Parameters 5 path-name Specifies a default repository directory. You cannot use wildcard characters in this parameter. 4 Description The SET DEFAULT command establishes the default repository directory for the current CDO session. You can use a logical name that translates to a search list as the path name in the SET DEFAULT command. After setting the default repository area, commands that directly affect elements, such as CHANGE, DEFINE, or DELETE, only operate on the first occurrence of the element in the search list. However, the DIRECTORY command searches through all the repository areas specified in the search list. 4 Examples CDO> SET DEFAULT DISK:1[SMITH.DATA]REVIEW In this example, the SET DEFAULT command sets the default directory to the REVIEW directory in the DISK1:[SMITH.DATA] anchor repository. 3 KEY Format SET KEY qualifier 4 Qualifiers 5 /STATE=key-state Specifies the key state to be set. 4 Description The SET KEY command sets the current key state. See the DEFINE KEY command description for information on the key states. 4 Examples CDO> SET KEY/STATE=ONE In this example, the SET KEY command sets the key state to ONE. 3 OUTPUT Format SET OUTPUT [ file-spec ] 4 Parameters 5 file-spec Specifies the file to which CDO sends the output from CDO commands. 4 Description The SET OUTPUT command defines where CDO sends the output from CDO during a session. If you specify a file with the SET OUTPUT command, CDO sends output to the default output location (SYS$OUTPUT) for your current process and to the specified file. If you specify SET OUTPUT without a file specification, CDO sends output only to the default output location. The SET OUTPUT command stays in effect until you change it with another SET OUTPUT command. 4 Examples CDO> SET OUTPUT In this example, the SET OUTPUT command captures the output from a CDO session and sends it to the default output location for your process. 3 VERIFY Format { VERIFY } SET { NOVERIFY } { } 4 Description The SET VERIFY command causes CDO to display all commands in a command procedure before executing them. The initial setting is off (NOVERIFY). To override this default, you can issue the SET VERIFY command at the CDO prompt before you process the command procedure. SET VERIFY then remains in effect until you issue a SET NOVERIFY command. Alternatively, you can insert the SET VERIFY command as the first command within your command procedure. SET VERIFY then remains in effect until the command procedure finishes executing. 4 Examples CDO> SET VERIFY CDO> @ON.CDO In this example, the SET VERIFY command causes CDO to display all commands in the ON.CDO command procedure as they execute. 2 SHOW 3 ALL Format SHOW ALL [ qualifier ] 4 Qualifiers 5 /ALL Displays system-specified properties, such as time of creation, and user-specified properties, such as data type, for each element in the directory and for all children. 5 /AUDIT Displays history list entries for each element. AUDIT=ALL displays history list entries for each element and all children. 5 /BRIEF_(default) Displays user-specified properties for each element, and provides the names of direct children. 5 /FULL Displays the user-specified properties for the element and for all children. 4 Description The SHOW ALL command displays a complete or partial list of properties for all visible elements in the default directory. If you have your default directory set to a directory in the compatibility repository, the SHOW ALL command displays DMU record definitions of the CDD$RECORD type, but cannot display other definitions that may be stored in your DMU repository. Some examples of DMU definitions that CDO cannot display include the following: o ACMS application, menu, task group, and task definitions o DATATRIEVE domain, plot, table and view definitions, and procedures o DBMS schema, subschemas, security schemas, and storage schemas o Oracle Rdb relation, constraint, index, view, and field definitions o TDMS form, request, and request library definitions When you display definitions from the compatibility repository, CDO displays DMU definitions in CDO format. You must have read access to an element for CDO to display information on that element. CDO displays type definitions only if your default directory is set to the CDD$PROTOCOLS directory. 4 Examples CDO> SHOW ALL In this example, because no qualifier is specified, the SHOW command displays default BRIEF information. This information includes the user-specified properties for each element and the names of direct children. 3 CHARACTER_SET Format SHOW CHARACTER_SET 4 Description Displays the character set of the current CDO session. You must set the character-set parameter to DEC_KANJI to use Japanese characters with Oracle CDD/Repository. Use the SET CHARACTER_SET command to specify the character set for a CDO session. If the setting has not been specified using the SET CHARACTER_SET command, Oracle CDD/Repository references the equivalence name of the CDD$CHARACTER_SET logical name. If this logical name is not assigned, the default character set is DEC_MCS. 4 Examples CDO> SHOW CHARACTER_SET Session Character_set is DEC_MCS In this example the current character set setting is DEC_MCS, which supports a set of international alphanumeric characters. 3 COLLECTION Format SHOW COLLECTION [ qualifier ] collection-name ,... 4 Parameters 5 collection-name Specifies the collection whose properties you are displaying. 4 Qualifiers 5 /ALL Displays system-specified properties, such as time of creation, and user-specified properties, such as description, for the collection and for all children. 5 /AUDIT Displays history list entries for the collection. 5 /BRIEF_(default) Displays user-specified properties for the collection. 5 /FULL Displays user-specified properties for the collection and for all children. 4 Description The SHOW COLLECTION command displays a complete or partial list of properties for the collection or collections specified. If you do not specify a version number for the collection, CDO displays the properties of the highest visible version. 4 Examples CDO> SHOW COLLECTION MAMMALS In this example, because no qualifier is specified, the SHOW COLLECTION command displays default BRIEF information. This information includes the user-specified properties for the MAMMALS collection and the names of direct children. 3 CONTEXT Format SHOW CONTEXT [ qualifier ] [ context-name ] ,... 4 Parameters 5 context-name Specifies the context whose properties you are displaying. If you omit this parameter, CDO displays the name of the current context. 4 Qualifiers 5 /ALL Displays system-specified properties, such as time of creation, and user-specified properties, such as description, for the context and for all children. 5 /AUDIT Displays history list entries for the context. 5 /BRIEF_(default) Displays user-specified properties for the context, and provides the names of direct children. 5 /FULL Displays user-specified properties for the context and for all children. 4 Description The SHOW CONTEXT command displays a complete or partial list of properties for the context or contexts you specify. Because a context is a nonversioned element, CDO does not accept a branch designation or a version number in the context name. 4 Examples CDO> SHOW CONTEXT ANIMAL_KINGDOM In this example, because no qualifier is specified, the SHOW CONTEXT command displays default BRIEF information. This information includes the user-specified properties for the ANIMAL_KINGDOM context and the names of direct children. 3 DATABASE Format SHOW DATABASE [ qualifier ] [ database-name ] 4 Parameters 5 database-name Specifies the physical database whose properties you are displaying. By default, if you do not specify a full path name for the database, CDO displays all physical database elements in your default directory. 4 Qualifiers 5 /ALL For an RMS database, displays the database name and description, record definition, file organization, fully qualified path name, and system-specified properties. For an Oracle Rdb database, displays the database name, file name, and fully qualified path name, as well as the system- specified properties. 5 /AUDIT Displays the history list entries for the database definition. The /AUDIT=ALL qualifier displays the history list for all elements owned by the database. 5 /BRIEF_(default) For an RMS database, displays the database name and description, record name, fully qualified path name, and file organization properties. For an Oracle Rdb database, displays the database name, file name, and fully qualified path name. 5 /FULL For an RMS database, displays the database name and description, record definition properties, file organization properties, and fully qualified path name. For an Oracle Rdb database, displays the database name, file name, and fully qualified path name. 4 Description The SHOW DATABASE command displays a complete or partial list of properties for the database elements specified. If you do not specify a version number for a database element, CDO displays the highest visible version. When you use the SHOW DATABASE command to display an Oracle Rdb database element, CDO shows only the database name, file name, and the fully qualified path name. Use the SHOW GENERIC command with the /FULL qualifier or use SQL (structured query language) to view the complete definition of an Oracle Rdb database. 4 Examples CDO> SHOW DATABASE DEPT5 In this example, because no qualifier is specified, the SHOW DATABASE command displays default BRIEF information. This information includes the DEPT5 Oracle Rdb database name, file name, and fully qualified path name. 3 DEFAULT Format SHOW DEFAULT 4 Description The SHOW DEFAULT command displays the current default CDO repository directory. If you set your default directory to a logical name that translates to a search list and you issue the SHOW DEFAULT command, CDO displays the names of the repository areas in the same order as they appear in the search list. 4 Examples 1.CDO> SET DEFAULT MY_DICT CDO> SHOW DEFAULT In this example, the SHOW DEFAULT command displays the names of the local and remote repository areas specified by the logical name MY_DICT. 2.CDO> SHOW DEFAULT In this example, the SHOW DEFAULT command displays the current default CDO directory. 3 FIELD Format SHOW FIELD [ qualifier ] ... [ field-name ] ,... [ FROM DATABASE database-name ] 4 Parameters 5 field-name Specifies the field element whose properties you are displaying. When you use the FROM DATABASE clause, specify only one field name for each SHOW FIELD command. Specify an asterisk (*) wildcard character for the entire field- name parameter only. If you use a wildcard character as part of the field-name parameter, an error occurs. 5 database-name Specifies the Oracle Rdb database that contains the field. CDO requires this parameter for fields from an Oracle Rdb database. CDO accepts wildcard characters in the database name. 4 Qualifiers 5 /ALL Displays system-specified properties, such as time of creation, and user-specified properties, such as description, for the field name and for all children. 5 /AUDIT Displays history list entries for the field name. The /AUDIT=ALL qualifier displays the history list entries for the field name and for all children. Do not use this qualifier if the field name you specify is from an Oracle Rdb database definition. 5 /BRIEF_(default) Displays user-specified properties for the field name, and provides the names of direct children. 5 /FULL Displays user-specified properties for the field name and for all children. 5 /SYSTEM Format options: /SYSTEM /NOSYSTEM (default) Specifies whether CDO displays Oracle Rdb system relations. 5 /RDB_METADATA Format options: /RDB_METADATA /NORDB_METADATA (default) Specifies whether CDO displays Oracle Rdb system relations. This qualifier is synonymous with the /SYSTEM qualifier. 4 Description The SHOW FIELD command displays a complete or partial list of properties for the field names you specify, provided you have read privileges. If you do not specify a full path name (or the FROM DATABASE clause) for the field name, CDO searches your current default directory for the field name. If you do not specify a field name, CDO displays the properties of all field names in your default directory. If you do not specify a version number for a field name, CDO displays the properties of the highest visible version. NOTE If you make incompatible changes to the CDD$DATA_ELEMENT type, supplied by Oracle CDD/Repository, the SHOW FIELD command may not display those properties whose data types you have modified. If a field has character set attributes, you can display them using the SHOW and EXTRACT commands; in addition, you can use the SHOW command to display size information of a field in both character-based size and octet-based size. See the descriptions of SET CHARACTER_SET command and the DATATYPE_Field_Property help topic found under the fld-properties topic for more information. 4 Examples 1.CDO> SHOW FIELD CORPORATE_ZIPCODE FROM DATABASE DEPT3 In this example, because no qualifier is specified, the SHOW FIELD command displays default BRIEF information. This information includes the user-specified properties for the CORPORATE_ZIPCODE field name and the names of direct children. 2.CDO> DEFINE FIELD FULL_NAME cont> DATATYPE TEXT CHARACTER_SET KANJI cont> SIZE 2 CHARACTERS. CDO> SHOW FIELD FULL_NAME Definition of field FULL_NAME | Datatype text size is 2 characters (4 Octets) | Character_set KANJI This example defines and shows the field FULL_NAME. 3 FILE_ELEMENT Format SHOW FILE_ELEMENT type-name [ qualifier ] element-name ,... 4 Parameters 5 type-name Specifies the type (MCS_BINARY or MCS_BINARY subtype) of the file element you are displaying. See the Oracle CDD/Repository Information Model for information on these types. 5 element-name Specifies the file element whose properties you are displaying. 4 Qualifiers 5 /ALL Displays system-specified properties, such as time of creation, and user-specified properties, such as description, for the file element and for all children. 5 /AUDIT Displays history list entries for the file element. 5 /BRIEF_(default) Displays user-specified properties for the file element, and provides the names of direct children. 5 /FULL Displays user-specified properties for the file element and for all children. 4 Description The SHOW FILE_ELEMENT command displays a complete or partial list of properties for the file element or elements you specify. If you do not specify a version number for a file element, CDO displays the properties of the highest visible version. 4 Examples CDO> SHOW FILE_ELEMENT MCS_TEXT CAT In this example, because no qualifier is specified, the SHOW command displays default BRIEF information. This information includes the user-specified properties for the CAT file element and the names of direct children. 3 GENERIC Format SHOW GENERIC type-name [ qualifier ] [ element-name ] ,... [ FROM DATABASE database-name ] 4 Parameters 5 type-name Specifies the type of the generic element whose properties you are displaying. This type cannot be MCS_BINARY, a subtype of MCS_ BINARY, MCS_COLLECTION, MCS_CONTEXT, or MCS_PARTITION. See the Oracle CDD/Repository Information Model for information on these types. 5 element-name Specifies the generic element whose properties you are displaying. When you use the FROM DATABASE clause, specify only one element name for each SHOW GENERIC command. Specify an asterisk (*) wildcard character for the entire element-name parameter only. If you use a wildcard character as part of the element-name, an error occurs. 5 database-name Specifies the Oracle Rdb database that contains the element. CDO requires this parameter for elements from an Oracle Rdb database. You can include wildcard characters in the database name. 4 Qualifiers 5 /ALL Displays system-specified properties, such as time of creation, and user-specified properties, such as description, for the generic element and for all children. 5 /AUDIT Displays history list entries for the generic element. The /AUDIT=ALL qualifier displays the history list for all children. CDO displays history list entries only if you specified the CDD$HISTORY_LIST relationship as part of this generic element's type definition. 5 /BRIEF_(default) Displays user-specified properties for the generic element, and provides the names of direct children. 5 /FULL Displays user-specified properties for the generic element and for all children. CDO displays description text only if you specified the CDD$DESCRIPTION property as part of this generic element's type definition. 4 Description The SHOW GENERIC command displays a complete or partial list of properties for the generic element or elements you specify. If you specify the type name but not an element name, the SHOW GENERIC command displays all elements of the specified type in your default directory, provided that you have privilege to display them. You must have read access to all components of the generic element for CDO to display those components. If you do not specify a version number for a generic element, CDO displays the highest visible version. You can display a field definition by specifying CDD$DATA_ELEMENT as the type name and the name of the field definition as the element name. You can display a record definition by specifying CDD$DATA_ AGGREGATE as the type name and the name of the record definition as the element name. You can display indexes or constraints in an Oracle Rdb database element by specifying CDD$INDEX or CDD$CONSTRAINT as the type name and the name of the index or constraint as the element name. Remember to include the FROM DATABASE clause. 4 Examples CDO> SHOW GENERIC BOOK REFERENCE_MANUAL In this example, because no qualifier is specified, the SHOW command displays default BRIEF information. This information includes user-specified properties for the REFERENCE_MANUAL element and the names of direct children. 3 KEY Format SHOW KEY [ qualifier ] ... [ key-name ] 4 Parameters 5 key-name Specifies the key whose properties you are displaying. 4 Qualifiers 5 /ALL Displays all key definitions in a key state. You cannot use the /ALL qualifier if you specify one or more key names. 5 /BRIEF_(default) Displays the key definition and state. 5 /DIRECTORY Format options: /DIRECTORY /NODIRECTORY (default) Displays the names of all states for which you have defined keys. If you specify the /DIRECTORY qualifier, you cannot specify any other SHOW KEY qualifiers. 5 /FULL Format options: /FULL /NOFULL (default) Displays all qualifiers for the key definition you specify. Specifying the /NOFULL qualifier gives the same results as the /BRIEF qualifier. 5 /STATE Format options: /STATE=key-state /NOSTATE (default) Displays key definitions for the state you specify. The /NOSTATE qualifier displays key definitions for the current state. 4 Description The SHOW KEY command displays a complete or partial list of properties for the key you specify. If you do not specify a key name, CDO displays the definition for all keys. You use the DEFINE KEY command to create key definitions. 4 Examples CDO> SHOW KEY PF3 In this example, because no qualifier is specified, the SHOW command displays default BRIEF information. This information includes the key definition and state for the PF3 key. 3 NOTICES Format SHOW NOTICES element-name ,... 4 Parameters 5 element-name Specifies the element whose notices you are displaying. 4 Description The SHOW NOTICES command displays the notices at the element or elements you specify. CDO sends notices to elements when you: o Change an element and the change affects other elements. For example, if you change the name of a field element in a database, the database element may need to be integrated. o Change an element and the change affects the parent. For example, if you delete the name of a record element in a database, the database element needs to be integrated. o Create a new version of an element. For example, if you create a new record element that appears in a program, the program needs to be recompiled. If you issue the SHOW NOTICES command for an element that does not have notices, CDO informs you that the element does not have notices. You can display new version notices by using the SHOW NOTICES command at any of the member's parents that have a CDD$NOTICE_ ACTION property value of SUCCESS or SIGNAL. You can display notices that the CHANGE command generates by using the SHOW NOTICES command at any of the member's parents that have a CDD$NOTICE_ACTION property value of SIGNAL. CDO sends notices when you either change a member of a relationship with the CHANGE command or you define a new version of the member. The three types of notices that definitions receive and the meanings of these notices are: o CDD$K_POSSIBLY_INVALID A definition used by this definition has changed. This change might affect this definition. This notice indicates the name of the definition that changed. o CDD$K_INVALID A definition used by this definition changed or was removed from the repository. This definition is invalid. If a changed definition initiated the notice, the notice supplies the name of the definition. If a deleted definition initiated the notice, the notice does not supply a definition name. o CDD$K_NEW_VERSION A new version of a definition used by this definition was created. The notice supplies the name of the definition that has the new version. o CDD$K_CHILD_USAGE A relationship from one of the definitions used by this element to one of its children was changed. The notice indicates the owner of the changed relationship. You cannot generate this type of notice using CDO. Only programs using the Oracle CDD/Repository callable interface can cause this notice. You can, however, read this type of notice using CDO. 4 Examples 1.CDO> SHOW NOTICES EMPLOYEE_REC . . . CDO> CLEAR NOTICES EMPLOYEE_REC In this example, the SHOW NOTICES command displays notices sent to the EMPLOYEE_REC record. You can clear any notices by issuing the CLEAR NOTICES command. 2.CDO> CHANGE FIELD FLD_A cont> DATATYPE IS SIGNED LONGWORD. %CDO-I-DBMBR, database DISK1:[SMITH.DICT]MY_RDB_DB(1) may need to be integrated CDO> SHOW NOTICES MY_RDB_DB DISK1:[SMITH.DICT]MY_RDB_DB(1) is possibly invalid, triggered by entity DISK1:[SMITH.DICT]FLD_A(1) CDO> In this example, CDO sends a notice that a database might require integration as a consequence of the CHANGE command. You can use the SHOW NOTICES command to display this notice at the MY_RDB_DB database definition. 3.CDO> DEFINE FIELD FLD_B cont> DATATYPE SIGNED LONGWORD. CDO> SHOW NOTICES REC_B DISK1:[SMITH.DICT]RDB_REC_B(1) uses an entity which has new versions, triggered by CDD$DATA_ELEMENT DISK1:[SMITH.DICT]FLD_B(1) CDO> SHOW NOTICES MY_RDB_DB DISK1:[SMITH.DICT]MY_RDB_DB(1) uses an entity which has new versions, triggered by CDD$DATA_ELEMENT DISK1:[SMITH.DICT]FLD_B(1) DISK1:[SMITH.DICT]MY_RDB_DB(1) is possibly invalid, triggered by CDD$DATA_ELEMENT DISK1:[SMITH.DICT]FLD_A(1) When you create a new version of the FLD_B field definition by using the DEFINE FIELD command, CDO sends new version notices to the parents of FLD_B. The following set of examples shows this sequence of events: 1. The DEFINE FIELD command creates a new version of the FLD_B field definition. 2. The first SHOW NOTICES command shows that FLD_B's immediate parent, REC_B record definition received the new version notice when CDO created the new version of FLD_B. 3. The second SHOW NOTICES command shows two notices at the MY_RDB_DB CDD$DATABASE definition. The CHANGE command sends one notice on behalf of the FLD_A field definition from the previous example, and the DEFINE FIELD command sends a new version notice on behalf of the new version of the FLD_B field definition. 4.CDO> CLEAR NOTICES MY_RDB_DB CDO> SHOW NOTICES MY_RDB_DB %CDO-I-NONOTICES, DISK1:[SMITH.DICT]MY_RDB_DB(1) has no notices To clear the notices at MY_RDB_DB, use the CLEAR NOTICES command. To verify that you cleared the notices at MY_RDB_DB, use the SHOW NOTICES command. If you ask to see the notices at a definition without notices, CDO responds that there are no notices. 3 PARTITION Format SHOW PARTITION [ qualifier ] partition-name ,... 4 Parameters 5 partition-name Specifies the partition whose properties you are displaying. 4 Qualifiers 5 /ALL Displays system-specified properties, such as time of creation, and user-specified properties, such as description, for the partition and for all children. 5 /AUDIT Displays history list entries for the partition. 5 /BRIEF_(default) Displays user-specified properties for the partition, and provides the names of direct children. /BRIEF is the default qualifier. 5 /FULL Displays user-specified properties for the partition and for all children. 4 Description The SHOW PARTITION command displays a complete or partial list of properties for the partition or partitions specified. Because a partition is a nonversioned element, CDO does not accept a branch designation or a version number in partition names. 4 Examples CDO> SHOW PARTITION INITIAL_PROPOSAL In this example, because no qualifier is specified, the SHOW PARTITION command displays default BRIEF information. This information includes the user-specified properties for the INITIAL_PROPOSAL partition and the names of direct children. 3 PRIVILEGES Format { DIRECTORY } SHOW PRIVILEGES FOR { FIELD } element-name ,... { RECORD } { } SHOW PRIVILEGES FOR GENERIC type-name SHOW PRIVILEGES FOR REPOSITORY anchor-name 4 Parameters 5 element-name Specifies the element whose access rights you are displaying. 5 type-name Specifies the type of the generic element. 5 anchor-name Specifies the anchor directory of the repository for which you want to display privileges. 4 Description The SHOW PRIVILEGES command displays the access rights for the elements you specify. To display your privileges for a type, use the SHOW PROTOCOL command. 4 Examples CDO> SHOW PRIVILEGES FOR FIELD CURRENT_SALARY In this example, the SHOW PRIVILEGES command displays your access rights to the CURRENT_SALARY field element. 3 PROTECTION Format { DIRECTORY } { FIELD } SHOW PROTECTION FOR { RECORD } element-name ,... { } { GENERIC type-name } SHOW PROTECTION FOR REPOSITORY anchor-name 4 Parameters 5 type-name Specifies the type of the generic element. 5 element-name Specifies the element whose ACL you are displaying. 5 anchor-name Specifies the repository anchor whose ACL you are displaying. 4 Description The SHOW PROTECTION command displays the access control list (ACL) for the element you specify. When you specify FOR GENERIC MCS_CONTEXT or FOR REPOSITORY, SHOW PROTECTION also displays the default access control list. To display the access control list for a type, you can also use the SHOW PROTOCOL command. 4 Examples 1.CDO> SHOW PROTECTION FOR FIELD CURRENT_SALARY In this example, the SHOW PROTECTION command displays the access control list for the CURRENT_SALARY field definition. 2.CDO> SHOW PROTECTION FOR REPOSITORY CDD$REPOSITORY2 In this example, Oracle CDD/Repository translates the logical name for the repository. 3 PROTOCOL Format SHOW PROTOCOL [ qualifier ] type-name ,... 4 Parameters 5 type-name Specifies the type whose properties you are displaying. 4 Qualifiers 5 /ALL Displays all the possible relationships the type can own, as well as the access control list for the type. 5 /AUDIT Displays the history list entries for the type. Specifying the /AUDIT=ALL qualifier displays the history list for all the relationships that the type owns. 5 /FULL Displays all the possible relationships this type can own. 5 /BRIEF_(default) Displays the relationships most commonly owned by this type. /BRIEF is the default qualifier. 4 Description The SHOW PROTOCOL command displays a complete or partial list of properties for the type or types you specify. CDO looks for types in the CDD$PROTOCOLS directory below your current default anchor. It is not necessary to set default to the CDD$PROTOCOLS directory to display types. CDO uses relationships to pass notices among repository definitions. Every relationship protocol in the repository has the CDD$NOTICE_ACTION property, whose value controls the passing of notices. You can use the CDO SHOW PROTOCOL command to display the value of the CDD$NOTICE_ACTION property. The CDD$NOTICE_ACTION property can have one of three values: o SUCCESS When you change a member of the relationship with the CHANGE command and the CDD$NOTICE_ACTION property value is SUCCESS, CDO does not send notices to the owner of the relationship. Instead, CDO sends notices to the owner's parents, provided that the parents are members of a relationship with the CDD$NOTICE_ACTION attribute value of SIGNAL. CDO continues to send these notices until the member you are changing has no more parents or until CDO encounters the CDD$NOTICE_ACTION property value BLOCK. When you define a new version of a member and the CDD$NOTICE_ ACTION attribute value is SUCCESS, CDO sends notices to both the owner of the relationship and the owner's parents, until CDO encounters the CDD$NOTICE_ACTION property value of BLOCK or until there are no more parents. o SIGNAL When you change the member with the CHANGE command or when you define a new version of the member and the CDD$NOTICE_ACTION attribute value is SIGNAL, CDO sends a notice to both the owner and the parents of a relationship. When you define a new version of a member, CDO also sends notices to the parents until CDO encounters the CDD$NOTICE_ ACTION property value of BLOCK or until there are no more parents. o BLOCK When the CDD$NOTICE_ACTION property value is BLOCK, CDO does not forward a notice from the member to the owner. CDO blocks the notice regardless of whether you are changing the member with the CHANGE command or defining new versions of the member. 4 Examples 1.CDO> SHOW PROTOCOL CDD$DATA_AGGREGATE_CONTAINS In this example, because no qualifier is specified, the SHOW PROTOCOL command displays default BRIEF information. This information includes the user-specified properties for the CDD$DATA_AGGREGATE_CONTAINS type and the names of direct children. 2.CDO> SHOW PROTOCOL CDD$DATABASE_SCHEMA Definition of protocol CDD$DATABASE_SCHEMA (Type :MCS_RELATION_TYPE) | MCS_rdbRelation CDD$$O_DATABASE_REL | MCS_groupingRelation NO_GROUPING | MCS_noticeAction SIGNAL | CDD$OBJECT_KIND CDD$RELATIONSHIP | MCS_protocolMajor 1 | MCS_protocolMinor 0 | MCS_tag 2818865 | MCS_createdDate 14-MAR-1994 09:13:32.42 | CDD$MODIFIED_TIME 14-MAR-1994 09:13:32.42 | MCS_instantiable 1 | MCS_pattern | MCS_status 0 | MCS_freezeTime 14-MAR-1994 09:13:32.42 | MCS_controlled 1 | MCS_allowConcurrent 1 | MCS_HAS_PROPERTY | | MCS_attachment (Type : MCS_PROPERTY_TYPE) | | MCS_inherited (Type : MCS_PROPERTY_TYPE) | | CDD$PROTOCOL_TAG (Type : MCS_PROPERTY_TYPE) | | MCS_containsDatabases (Type : MCS_PROPERTY_TYPE) | | MCS_relOwner (Type : MCS_PROPERTY_TYPE) | | MCS_relMember (Type : MCS_PROPERTY_TYPE) | | MCS_databaseElement (Type : MCS_PROPERTY_TYPE) | | MCS_elementType (Type : MCS_PROPERTY_TYPE) | | MCS_allElementTypes (Type : MCS_PROPERTY_TYPE) | MCS_HAS_RELATION | | CDD$DATABASE (Type : MCS_ELEMENT_TYPE) | | CDD$DATABASE (Type : MCS_ELEMENT_TYPE) | MCS_RELATION_MEMBER | | CDD$DATA_AGGREGATE (Type : MCS_ELEMENT_TYPE) | | CDD$RDB_DATABASE (Type : MCS_ELEMENT_TYPE) | | DBM$SCHEMA (Type : MCS_ELEMENT_TYPE) | | CDD$RMS_DATABASE (Type : MCS_ELEMENT_TYPE) | | CDD$DATA_AGGREGATE (Type : MCS_ELEMENT_TYPE) | | CDD$RDB_DATABASE (Type : MCS_ELEMENT_TYPE) | | DBM$SCHEMA (Type : MCS_ELEMENT_TYPE) | | CDD$RMS_DATABASE (Type : MCS_ELEMENT_TYPE) | MCS_OBJECT_VALIDATION | | CDD$RELATION_VAL (Type : MCS_VALIDATION) | | CDD$ELEMENT_VAL (Type : MCS_VALIDATION) In this example, the SHOW PROTOCOL command displays the CDD$NOTICE_ACTION property of SIGNAL for the CDD$DATABASE_ SCHEMA relationship. 3 RECORD Format SHOW RECORD [ qualifier ] ... [ record-name ] ,... [ FROM DATABASE database-name ] 4 Parameters 5 record-name Specifies the record, relationship, or view whose properties you are displaying. When you use the FROM DATABASE clause, specify only one record name for each SHOW RECORD command. Specify an asterisk (*) wildcard character for the entire record-name parameter only. If you use a wildcard character as part of the record name, an error occurs. 5 database-name Specifies the Oracle Rdb database that contains the record. CDO requires this parameter for records from an Oracle Rdb database. You can include wildcard characters in the database name. 4 Qualifiers 5 /ALL Displays system-specified properties, such as time of creation, and user-specified properties, such as description, for the record element and for all children. 5 /AUDIT Displays history list entries for the record element. Specifying the /AUDIT=ALL qualifier displays the history list entries for the record element and for all children. Do not use this qualifier if the record you specify is from an Oracle Rdb database definition. 5 /BRIEF_(default) Displays user-specified properties for the record element, and provides the names of direct children. /BRIEF is the default qualifier. 5 /FULL Displays user-specified properties for the record element and for all children. 5 /SYSTEM Format options: /SYSTEM /NOSYSTEM (default) Specifies whether CDO displays Oracle Rdb system relations. 5 /RDB_METADATA Format options: /RDB_METADATA /NORDB_METADATA (default) Specifies whether CDO displays Oracle Rdb system relations. This qualifier is synonymous with the /SYSTEM qualifier. 4 Description The SHOW RECORD command displays a complete or partial list of properties for the record elements you specify, provided you have read privilege. If you do not specify a full path name (or the FROM DATABASE clause), CDO searches your current default directory for the record name. If you do not specify a record name, CDO displays the properties of all record elements in your default directory. If you do not specify a version number for a record element, CDO displays the properties of the highest visible version. If you do not have read privilege for a record and for each component part of that record, CDO will not display the record name or properties. 4 Examples CDO> SHOW RECORD ADDRESS_RECORD cont> FROM DATABASE SUBSCRIPTIONS In this example, because no qualifier is specified, the SHOW RECORD command displays default BRIEF information. This information includes the user-specified properties for the ADDRESS_RECORD record element and the names of direct children. 3 REPOSITORIES Format SHOW REPOSITORIES [ qualifier ] 4 Qualifiers 5 /FULL Displays the elements within other repositories being referenced by your repository. 4 Description The SHOW REPOSITORIES command scans your repository for dependencies on elements in other repositories. The command displays the name of these other repositories and, if you specify the /FULL qualifier, the names of the elements. 4 Example CDO> SHOW REPOSITORIES In this example, because no qualifier is specified, the SHOW REPOSITORIES command displays the names of the repositories that your repository references. 3 RESERVATIONS Format SHOW RESERVATIONS [ qualifier ] 4 Qualifiers 5 /ALL Displays all the reserved elements, their types, and the contexts reserving them throughout the repository. 5 /BRIEF_(default) Displays reserved elements and their types in your current context. /BRIEF is the default qualifier. 4 Description The SHOW RESERVATIONS command displays the reserved elements for your current context or for the entire repository. An error occurs if a context has not been set. 4 Examples CDO> SET CONTEXT PERSONNEL CDO> RESERVE COLLECTION OFFICERS CDO> SHOW RESERVATIONS . . . CDO> REPLACE COLLECTION OFFICERS CDO> SHOW RESERVATIONS . . . In this example, the first SHOW RESERVATIONS command displays the reserved elements, their types, and the reserving context. The second SHOW RESERVATIONS command displays an informational notice indicating that no elements are reserved. 3 RMS_DATABASE Format SHOW RMS_DATABASE [ qualifier ] [ rms-database-name ] 4 Parameters 5 rms-database-name Specifies the logical RMS database element whose properties you are displaying. If you do not specify an RMS database name, CDO displays all the RMS database definitions in the repository. 4 Qualifiers 5 /ALL Displays system-specified properties, such as time of creation, and user-specified properties, such as description, for the RMS database element and all children. 5 /AUDIT Displays history list entries for the RMS database element. Specifying the /AUDIT=ALL qualifier displays the history list for the database element and for all children. 5 /BRIEF_(default) Displays the file organization properties for the RMS database element. /BRIEF is the default qualifier. 5 /FULL Displays the file organization properties, the record definition, and the description for the logical RMS database element. 4 Description The SHOW RMS_DATABASE command displays a complete or partial list of properties for the RMS database element you specify. If you do not specify a version number for an RMS database element, CDO displays the highest visible version. When you use SHOW RMS_DATABASE or SHOW RMS_DATABASE/FULL to display an RMS database element with a NULL_VALUE property, CDO displays the null value as a decimal value. 4 Examples CDO> SHOW RMS_DATABASE EMPLOYEE_STORAGE In this example, because no qualifier is specified, the SHOW RMS_DATABASE command displays default BRIEF information. This information includes the user-specified properties for the EMPLOYEE_STORAGE RMS database definition and the names of direct children. 3 UNUSED Format SHOW UNUSED [ qualifier ] ... element-name ,... 4 Parameters 5 element-name Specifies the element whose relationships you are investigating. 4 Qualifiers 5 /TYPE Format option: /TYPE=[ ( type-name ) ] ,... endcondition> Displays only owners or members of the type you specify. This type must be the keyword RECORD or FIELD or a type name that is valid for this command. Valid types include instances of ELEMENT_TYPE or RELATIONSHIP_TYPE; they do not include instances of PROPERTY_TYPE. 5 /BRIEF_(default) Displays the immediate owners and members of the element. /BRIEF is the default qualifier. 5 /FULL Displays all owners and members of the element. 4 Description The SHOW UNUSED command determines whether an element has owners or members. The element must have a directory name. If the element does not have owners or members, the name and type of the element is displayed. If the element has owners or members, CDO sends an informational notice. If you receive an informational notice, issue the SHOW USES and SHOW USED_BY commands to identify these owners or members. 4 Examples 1.CDO> SHOW UNUSED EMPLOYEE_DB In this example, because no qualifier is specified, the SHOW UNUSED command displays default BRIEF information. This information includes the names of immediate owners or members of the EMPLOYEE_DB database element. 2.CDO> SHOW UNUSED /FULL FIELD_A(2) In this example, the SHOW UNUSED command with the /FULL qualifier displays all owners or members of the FIELD_A(2) field element. 3.CDO> SHOW UNUSED /FULL /TYPE=(FIELD) EMPLOYEE_REC In this example, the SHOW UNUSED command with the /FULL and /TYPE qualifiers displays all owners or members of EMPLOYEE_REC that are fields. 3 USED_BY Format SHOW USED_BY [ qualifier ] ... element-name ,... 4 Parameters 5 element-name Specifies the element whose children you are displaying. 4 Qualifiers 5 /TYPE Format option: /TYPE=[ ( type-name ) ] ,... Displays only children of the type you specify. This type must be the keyword RECORD or FIELD or a type name that is valid for this command. Valid types include instances of ELEMENT_TYPE or RELATIONSHIP_TYPE; they do not include instances of PROPERTY_ TYPE. 5 /BRIEF_(default) Displays the name, type, and relationship type of immediate children. /BRIEF is the default qualifier. 5 /FULL Displays the name, type, and relationship type of all children. 4 Description The SHOW USED_BY command displays the children of the element you specify. The display includes the properties of children and the values associated with these properties. The SHOW USED_BY command lists children if they have either directory or processing names. CDO looks first for the directory name and displays it if one exists. If a directory name does not exist, CDO then looks for and displays the processing name. A definition can only exist in the repository without a directory or processing name if it has a relationship to an owner that has a directory name. CDO displays a name unspecified message in this case. To display Oracle Rdb database definitions, specify the name of the database as the element-name parameter and use the /FULL qualifier. Because CDO displays the full path name of each repository element, you can use the SHOW USED_BY command to determine where each instance of a particular element occurs and how it relates to other elements. 4 Examples 1.CDO> SHOW USED_BY EMPLOYEE_DB In this example, because no qualifier is specified, the SHOW USED_BY command displays the default information (/BRIEF). This information includes the names of immediate children of the EMPLOYEE_DB database element. 2.CDO> SHOW USED_BY /FULL FIELD_A(2) In this example, the SHOW USED_BY command with the /FULL qualifier displays all children of the FIELD_A(2) field element. 3.CDO> SHOW USED_BY /FULL /TYPE=(FIELD) EMPLOYEE_REC In this example, the SHOW USED_BY command with the /FULL and /TYPE qualifiers displays all children of EMPLOYEE_REC that are fields. 3 USES Format SHOW USES [ qualifier ] ... element-name ,... 4 Parameters 5 element-name Specifies the element whose owners you are displaying. 4 Qualifiers 5 /TYPE Format option: /TYPE=[ ( type-name ) ] ,... Displays only owners of the type you specify. This type must be the keyword RECORD or FIELD or a type name that is valid for this command. Valid types include instances of ELEMENT_TYPE or RELATIONSHIP_TYPE; they do not include instances of PROPERTY_TYPE. 5 /BRIEF_(default) Displays the name, type, and relationship type of immediate owners. /BRIEF is the default qualifier. 5 /FULL Displays the name, type, and relationship type of all owners. 4 Description The SHOW USES command displays the owners of the element you specify. The display includes the properties of owners and the values associated with these properties. The SHOW USES command lists owners if they have either directory names or processing names. CDO looks first for the directory name and displays it if one exists. If a directory name does not exist, CDO then looks for and displays the processing name. An element can only exist in the repository without a directory or processing name if it has a relationship to an owner with a directory name. CDO displays a name unspecified message in this case. You can use the SHOW USES command to display the names of elements that receive new version messages if you create a new version of the element you specify. 4 Examples 1.CDO> SHOW USES EMPLOYEE_DB In this example, because no qualifier is specified, the SHOW USES command displays the default information (/BRIEF). This information includes the names of immediate owners of the EMPLOYEE_DB database element. 2.CDO> SHOW USES /FULL FIELD_A(2) In this example, the SHOW USES command with the /FULL qualifier displays all owners of the FIELD_A(2) field element. 3.CDO> SHOW USES /FULL /TYPE=(RECORD) EMPLOYEE_NAME In this example, the SHOW USES command with the /FULL and /TYPE qualifiers displays all owners of EMPLOYEE_NAME that are records. 3 VERSION Format SHOW VERSION 4 Description The SHOW VERSION command displays the following information about one or more respositories that you have invoked and to which the CDO session is currently attached: o Version number of Oracle CDD/Repository that is installed on your system o Major and minor version numbers of each repository o Fully qualified name of each repository o Version numbers of Oracle CDD/Repository with which each repository is compatible If you issue the SHOW VERSION command and you have not invoked a repository during the CDO session, CDO displays only the version of Oracle CDD/Repository that is currently installed. Commands such as DEFINE FIELD or SHOW FIELD will invoke a repository; however, the SET DEFAULT or SHOW DEFAULT commands will not. If you issue a DIRECTORY command and the repository contains elements, the session will invoke a repository. 4 Examples 1.CDO> SHOW DEFAULT CDO> SHOW VERSION Installed version of Oracle CDD/Repository is V7.0.1 In this example, the SHOW DEFAULT command does not invoke a repository. Therefore, the SHOW VERSION command displays only the version of Oracle CDD/Repository that is currently installed. 2.CDO> SHOW FIELD Definition of field A1 | Datatype text size is 1 characters | Row_major array 1:4 Definition of field A1_KEY | Datatype text size is 1 characters . . . CDO> SHOW VERSION Installed version of Oracle CDD/Repository is V7.0.1 Attached to repository CDD$R0:[SMITH.REPOS3] Repository Version V6.1 / V7.0.1 Internal Major Version 26 Internal Minor Version 3 In this example, the SHOW FIELD command invokes a repository. Consequently, the SHOW VERSION command displays information about the repository to which it is attached. 3 WHAT_IF Format SHOW WHAT_IF [ qualifier ] ... element-name ,... 4 Parameters 5 element-name Specifies the element you are considering changing. 4 Qualifiers 5 /TYPE Format option: /TYPE=[ ( type-name ) ] ,... Displays those owners of the type you specify that could possibly receive an invalid notice if you perform a change in location with the CHANGE command. This type must be the keyword RECORD or FIELD or a type name that is valid for this command. Valid types include instances of ELEMENT_TYPE or RELATIONSHIP_TYPE; they do not include instances of PROPERTY_TYPE. 5 /BRIEF_(default) Displays the name, type, and relationship type of immediate owners that receive a possibly invalid notice if you perform a change in location with the CHANGE command. /BRIEF is the default qualifier. 5 /FULL Displays the name, type, and relationship type of all owners that receive a possibly invalid notice if you perform a change in location with the CHANGE command. 4 Description The SHOW WHAT_IF command displays the owners that are affected if the element you specify is modified by the CHANGE command. For the owners to be displayed, the relationship between owner and member must have an associated CDD$NOTICE_ACTION property value of SIGNAL. Owners with this property value generally represent an object outside the repository, such as a database. Each owner receives a possibly invalid warning if you issue the CHANGE command for the specified element. To determine the CDD$NOTICE_ACTION property value of a relationship, use the SHOW PROTOCOL command. The SHOW WHAT_IF command lists owners if they have either directory or processing names. CDO looks first for the directory name and displays it if one exists. If a directory name does not exist, CDO then looks for and displays the processing name. An element can only exist in the repository without either a directory or processing name if it has a relationship to an element that has a directory name. CDO displays the name unspecified message in this case. 4 Examples 1.CDO> SHOW WHAT_IF EMPLOYEE_DB In this example, because no qualifier is specified, the SHOW WHAT_IF command displays the default information (/BRIEF). This information includes the names of immediate owners that receive a possibly invalid notice if you issue the CHANGE command for EMPLOYEE_DB. 2.CDO> SHOW WHAT_IF /FULL FIELD_A(2) In this example, the SHOW WHAT_IF command with the /FULL qualifier displays all owners that receive a possibly invalid notice if you issue the CHANGE command for FIELD_A(2). 3.CDO> SHOW WHAT_IF /FULL /TYPE=(CDD$DATABASE) EMPLOYEE_REC In this example, the SHOW WHAT_IF command with the /FULL and /TYPE qualifiers displays all owners of the CDD$DATABASE type that receive a possibly invalid notice if you issue the CHANGE command for EMPLOYEE_REC. 2 SPAWN Format SPAWN [ qualifier ] ... [ command-string ] 3 Parameters 4 command-string Specifies an OpenVMS DCL command you want to perform in the context of the subprocess the SPAWN command creates. After the subprocess executes this command string, DCL returns control to your CDO process. A command string cannot exceed 132 characters. 3 Qualifiers 4 /INPUT=file-spec Specifies an OpenVMS file containing one or more DCL commands that DCL executes in the spawned subprocess. Once DCL finishes processing your input file, DCL terminates the subprocess and returns you to the CDO prompt. 4 /OUTPUT=file-spec Requests that the output from the subprocess be written to the OpenVMS file you specify. 4 /WAIT Format options: /WAIT (default) /NOWAIT Specifies whether the system waits until DCL completes a subprocess before allowing more commands to be issued in the parent process (the process in which you are running CDO). The /WAIT qualifier does not return you to the parent process until the command string you specify completes execution, or you log out of the created subprocess. You can also use the ATTACH command to return to the parent process. The /NOWAIT qualifier allows you to issue new commands while a subprocess is running. Use the /NOWAIT qualifier interactively. This directs output from the subprocess to a file so only one process at a time uses your terminal. Otherwise, the only way to distinguish one process from another is by the prompt. The CDO prompt indicates the parent process; the DCL prompt (normally a dollar sign) indicates the subprocess. If you specify the /NOWAIT qualifier and your input device is a terminal, control characters such as Ctrl/T or Ctrl/Y affect all subprocesses sharing the input device. For example, Ctrl/Y interrupts all such subprocesses. 3 Description The SPAWN command creates a subprocess of the current CDO process. 3 Examples 1.CDO> SPAWN SHOW TIME 17-FEB-1997 16:28:29 CDO> In this example, the SPAWN command creates a subprocess to execute the DCL command SHOW TIME. After the SHOW TIME command completes executing, DCL returns control to the parent CDO process. 2.CDO> SPAWN $ LOGOUT CDO> In this example, the SPAWN command creates a subprocess at the DCL prompt. To return to the CDO process, type LOGOUT at the DCL prompt. 3.CDO> SPAWN RUN SQL$ SQL> In this example, the SPAWN command creates a subprocess to run interactive SQL. 2 START_TRANSACTION Format START_TRANSACTION 3 Description The START_TRANSACTION command initiates a group of commands that Oracle CDD/Repository executes as a unit. A transaction ends with a COMMIT or ROLLBACK command. The COMMIT command causes all commands to execute, while the ROLLBACK command causes no commands to execute. 3 Restrictions o When you delete a record, local fields within that record are marked for deletion at the end of the transaction, provided that they remain unused at the end of the transaction. Using CDO, there is no way to reuse those local fields. It is possible to use local fields through the Oracle CDD/Repository APIs. Therefore, the local fields cannot be automatically deleted at the same point in the transaction as the record. You must either delete the record and field in separate transactions (outside the START_TRANSACTION . . . COMMIT stream of commands) or, to accomplish this in one transaction, use ENTER to enter the local field, delete the record, delete the local field, and then delete the global field. o Usually, if Oracle CDD/Repository issues any errors between the START_TRANSACTION and COMMIT commands, it forces you to roll back the transaction. In some cases, such as in the CHANGE or DELETE commands, Oracle CDD/Repository allows you to commit the transaction. The general rules are: - If you receive an Oracle CDD/Repository error of E or F severity, such as a CDD-E-NODNOTFND message, you must abort the transaction. - If you receive a CDO error of E or F severity, such as CDO-E-NOTFOUND, you can continue to operate in the current transaction. 3 Examples CDO> START_TRANSACTION. CDO> DEFINE RECORD REC2. cont> FLD1. END RECORD. CDO> COMMIT CDO> SHOW RECORD REC2 Definition of record REC2 | Contains field FLD1 . . . In this example, the COMMIT command ends a session started with the START_TRANSACTION command. When you use the START_ TRANSACTION and COMMIT commands, the overhead that is associated with these commands is incurred once in the repository and once in the database, rather than once for each CDO command between the START_TRANSACTION and COMMIT commands. The repository is already attached to the database and has already loaded the type definitions. The objects REC2 and FLD1 are retrieved from memory instead of from disk. 2 UNRESERVE Format {COLLECTION } {FIELD } UNRESERVE {RECORD } [qualifier] ... element-name ,... {FILE_ELEMENT type-name} {GENERIC type-name } [AUDIT IS /*text*/] 3 Parameters 4 type-name Specifies the type of the file or generic element you are unreserving. 4 element-name Specifies the element you are unreserving. You can substitute an asterisk (*) wildcard character for this parameter. 4 text Adds information to the history list entry. Valid delimiters are /* */ or double quotation marks (" "). You can use Japanese to document comments in the 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 Qualifiers 4 /CLOSURE Format options: /CLOSURE=keyword /NOCLOSURE (default) Specifies whether CDO unreserves additional elements. An unreserve operation fails if any element is a child of an element outside the area defined by the /CLOSURE qualifier. The /CLOSURE qualifier takes one of the following keywords: CLOSURE Keyword Behavior TO_BOTH Unreserves the element specified and all parents and children. TO_BOTTOM Unreserves the element specified and all children. TO_TOP Unreserves the element specified and all parents. If you specify TO_BOTH or TO_TOP, CDO ignores parents above the top collection. 4 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO displays text identifying each element as the element is unreserved. 3 Description The UNRESERVE command cancels the reservation previously placed on a version of an element. This operation deletes the ghost version of the element and discards any changes you made while you reserved the version. 3 Examples CDO> RESERVE COLLECTION /CLOSURE=TO_BOTTOM PRODUCT_INVENTORY CDO> DEFINE FIELD PRODUCT_NUMBER cont> DATATYPE BIT SIZE 5. CDO> DEFINE FIELD PRODUCT_DESCRIPTION cont> DATATYPE TEXT SIZE 50. CDO> UNRESERVE COLLECTION /CLOSURE=TO_BOTTOM PRODUCT_INVENTORY In this example, the UNRESERVE command cancels the PRODUCT_ INVENTORY reservation and deletes the two fields that were defined. 2 UPDATE Format UPDATE COMPOSITE [ qualifier ] composite-name [ AUDIT IS /*text*/ ] 3 Parameters 4 composite-name Specifies the collection, record, or field you are updating. 4 text Adds information to the history list entry. Valid delimiters are /* */ or double quotation marks (" "). You can use Japanese to document comments in the 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 Qualifiers 4 /CLOSURE Format options: /CLOSURE=TO_BOTTOM /NOCLOSURE (default) Specifies whether CDO updates additional elements. Specifying the /CLOSURE=TO_BOTTOM qualifier updates all children of a reserved element, unless the element is a child of an element outside the area defined by the CLOSURE keyword. 3 Description The UPDATE command allows you to attach more recent versions of elements to your own collections, records, or fields. In this way, you can access the work of others in your working group. Before you issue the UPDATE command, you must reserve the elements you wish to update. The SHOW RESERVATIONS command indicates whether this condition exists. When you issue the UPDATE command, the action that occurs depends on the keyword you specified in the DEFAULT_ATTACHMENT clause of the DEFINE CONTEXT or the CHANGE CONTEXT command for your current context. The following table lists the keywords and behaviors associated with them: DEFAULT_ ATTACHMENT Keyword Behavior LATEST Detaches the version currently attached and attaches the latest version, whether checked in or ghost. This keyword is the default attachment method. LATEST_CHECKIN Detaches the version currently attached and attaches the version most recently checked in. SPECIFIC_ Does not detach the version currently attached. VERSION The UPDATE command cannot attach a ghost version created with another context. The UPDATE command also cannot attach a checked- in version unless you have write privilege for the partition where the version resides. 3 Examples 1.CDO> DEFINE CONTEXT BUILD_SYSTEM_CONTEXT cont> BASE_PARTITION IS FIRST_BASELEVEL TOP IS COMPILER_C cont> DEFAULT_ATTACHMENT IS LATEST_CHECKIN. . . . CDO> UPDATE COLLECTION COMPILER_C In this example, the UPDATE command refers to the DEFAULT_ ATTACHMENT keyword (LATEST_CHECKIN) for the version to attach. UPDATE then detaches the currently attached version of the COMPILER_C collection and attaches the version most recently replaced. 2.CDO> DEFINE CONTEXT WRITE_CONTEXT cont> BASE_PARTITION IS FIRST_DRAFT TOP IS REFERENCE_MANUAL cont> DEFAULT_ATTACHMENT IS SPECIFIC_VERSION. . . . CDO> CHANGE CONTEXT WRITER_CONTEXT cont> DESCRIPTION IS "CHANGING DEFAULT_ATTACHMENT" cont> "TO PICK UP AL'S CHAPTERS" cont> DEFAULT_ATTACHMENT IS LATEST. CDO> UPDATE COLLECTION REFERENCE_MANUAL In this example, the UPDATE command refers to the DEFAULT_ ATTACHMENT keyword (LATEST) for the version to attach. UPDATE then detaches the currently attached version of the REFERENCE_ MANUAL collection and attaches the latest version, whether checked in or ghost. 2 VERIFY Format VERIFY [ qualifier ] ... anchor-name ,... 3 Parameters 4 anchor-name Specifies the anchor of the repository you are verifying. 3 Qualifiers 4 /ALL Performs all the verification options, except for the REBUILD_ DIRECTORY and COMPRESS options. The /ALL qualifier includes the /NOFIX qualifier by default. If you want to use the /FIX qualifier as the default to the VERIFY /ALL command, define the CDD$VERIFY_ALL_FIX logical name to be any value. Define the CDD$VERIFY_ALL_FIX logical name at the process level or higher. If you specify the VERIFY/ALL command without specifying a /FIX or /NOFIX qualifier, and if you have not defined the CDD$VERIFY_ ALL_FIX logical name, an informational error message, CDO-I- VF_ALL_NOFIX, will display and the VERIFY command will continue using the default /NOFIX qualifier. 4 /COMPRESS Format options: /COMPRESS /NOCOMPRESS (default) Specifies whether CDO compresses the CDD$DATABASE.SNP file to its original size at the time you created the repository. If you specify the /COMPRESS qualifier, you cannot include any other qualifier in your command. 4 /DIRECTORY Format options: /DIRECTORY /NODIRECTORY (default) Specifies whether CDO checks all directory names against a stored definition. When you also specify the /FIX qualifier, the /DIRECTORY qualifier removes directory names that do not refer to any stored definition. 4 /EXTERNAL_REFERENCES Format options: /EXTERNAL_REFERENCES /NOEXTERNAL_REFERENCES (default) Specifies whether CDO checks all relationships where either the owner or member is outside the repository you specified. When you also specify the /FIX qualifier, the /EXTERNAL_ REFERENCES qualifier fixes the errors it detects. 4 /FIX Format options: /FIX /NOFIX (default) Specifies whether CDO corrects errors found by the other qualifiers you specify. 4 /LOCATION Format options: /LOCATION /NOLOCATION (default) Specifies whether CDO checks that the repository is in the correct directory and is correctly referenced by other repositories on the system. When you also specify the /FIX qualifier, the /LOCATION qualifier fixes the errors it detects. 4 /LOG Format options: /LOG /NOLOG (default) Specifies whether CDO sends informational and error text to the default output location for your system. Specifying the /NOLOG qualifier displays only error text. 4 /ORPHANS Format options: /ORPHANS /NOORPHANS (default) Specifies whether CDO searches for definitions with no directory names and no owners. The /ORPHANS qualifier also checks relationships to ensure that they have valid owners and members. When you also specify the /FIX qualifier, it places homeless definitions in a directory called CDD$ORPHANS. CDO creates directory names for them while the VERIFY command executes. The /FIX qualifier deletes relationships without valid owners and members. CAUTION If you specify the /ORPHANS qualifier and the /LOG qualifier, CDO generates text for every element that is not an orphan. This could potentially be a very large number. 4 /REBUILD_DIRECTORY Format options: /REBUILD_DIRECTORY /NOREBUILD_DIRECTORY (default) Specifies whether CDO checks that the repository is in the correct directory and is correctly referenced by other repositories on the system, then deletes and re-creates all directory entries for the repository anchor you specify. If there are no directories to delete and re-create, the /REBUILD_ DIRECTORY qualifier builds a directory for the repository. Use the /REBUILD_DIRECTORY qualifier to recover a corrupted repository system only when corruption is so severe that all other qualifiers fail. The /REBUILD_DIRECTORY qualifier requires SYSPRV or BYPASS privilege. NOTE Use system backup utilities to back up your repository before using the /FIX qualifier or the /REBUILD_DIRECTORY qualifier. See Using Oracle CDD/Repository on OpenVMS Systems for information on performing a backup operation. 3 Description The VERIFY command determines whether a repository is structurally correct. This command requires read access. If you include the /FIX qualifier, you may also need write access. The /FIX qualifier requires SYSPRV or BYPASS privilege. The /COMPRESS and /REBUILD_DIRECTORY qualifiers correct the errors they encounter; all other qualifiers require the /FIX qualifier to correct errors. The /ALL qualifier corrects any errors it finds if the logical name CDD$VERIFY_ALL_FIX has been defined. The /COMPRESS qualifier requires the following: o You must have SYSPRV privilege. Otherwise, CDO displays a no privilege error. o You must issue the VERIFY command with the /COMPRESS qualifier as the first CDO command in a CDO session. Otherwise, CDO reports a conflict error with other users. o You must be the only user of the repository when you issue the VERIFY/COMPRESS command. Otherwise, CDO reports an Oracle Rdb lock conflict error. If you are working with remote repositories, issue the VERIFY /EXTERNAL_REFERENCES command by itself before you issue the VERIFY/EXTERNAL_REFERENCES command with the /FIX qualifier. If a remote device is not mounted, the VERIFY/EXTERNAL_REFERENCES command returns an error that the /FIX qualifier attempts to correct. Until a device is mounted, the command cannot complete. Use the VERIFY/LOCATION command if you issued the OpenVMS DCL COPY command to copy a repository or change the name of your anchor directory. Use the /LOCATION qualifier with the /EXTERNAL_REFERENCES qualifier if you have other repositories that reference the repository you are verifying. 3 Examples CDO> VERIFY /LOCATION /FIX [SMITH.REP] In this example, the VERIFY /LOCATION /FIX command checks that the [SMITH.REP] repository is in the correct directory and is correctly referenced by other repositories on the system. This command also corrects any errors detected.