| Previous | Contents | Index |
Oracle CDD/Repository is an optional software product available under a separate license. The Oracle CDD/Repository product lets you maintain shareable data definitions, such as record and field definitions. Oracle CDD/Repository data definitions are organized hierarchically in much the same way that files are organized in directories and subdirectories. For example, a repository for defining personnel data might have separate directories for each employee type.
Often, it is the job of a repository or data administrator to create repositories, define directory structures, and insert record and field definitions into the repository. In large organizations, many repositories can be linked together to form one logical repository. Once the repositories are established, the data definitions can be used throughout the organization by database administrators and application developers. If the paths are set up correctly, users can access definitions as if they were in a single repository.
Descriptions of data definitions are entered into the repository in a special-purpose language called Common Dictionary Operator (CDO). (Oracle CDD/Repository also supports both the Common Data Dictionary (Version 3) and CDD/Plus (Version 4) interfaces for use by existing databases and applications.) Oracle CDD/Repository converts the data descriptions to an internal form---making them independent of the language used to access them---and inserts them into the repository.
When you compile a COBOL program, Oracle CDD/Repository data definitions can be accessed by means of the COPY FROM DICTIONARY statement. If the attributes of the data definitions are consistent with Compaq COBOL requirements, the data definitions are included in the COBOL program. Oracle CDD/Repository data definitions, in the form of COBOL source code, can appear in source program listings if you specify the /LIST and /COPY_LIST qualifiers on the COBOL command line.
Oracle CDD/Repository can also store information about the structure of a program, such as the compiled modules that go into making an object module, or the record and field definitions that are used by COBOL programs. If, for example, a record definition needs to change, you can analyze the impact that change will have on the various programs that use it. When the definition is changed, Oracle CDD/Repository notifies the modules that the record definition is out of date, and the program can be recompiled.
To take advantage of dependency recording, you must:
The following example shows how you can use CDO to create a number of fields representing name and address information:
DEFINE FIELD NAME
DATATYPE IS TEXT
SIZE IS 25 CHARACTERS.
DEFINE FIELD COMPANY_NAME
DATATYPE IS TEXT
SIZE IS 25 CHARACTERS.
DEFINE FIELD STREET
DATATYPE IS TEXT
SIZE IS 20 CHARACTERS.
DEFINE FIELD CITY
DATATYPE IS TEXT
SIZE IS 20 CHARACTERS.
DEFINE FIELD STATE
DATATYPE IS TEXT
SIZE IS 2 CHARACTERS.
DEFINE FIELD ZIP
DATATYPE IS TEXT
SIZE IS 5 CHARACTERS.
|
The fields can then be used to create records. The following example creates two records --- one for customer address information and one for employee address information:
DEFINE RECORD CUSTOMER_ADDRESS_RECORD.
NAME.
COMPANY_NAME.
STREET.
STATE.
ZIP.
END RECORD.
DEFINE RECORD EMPLOYEE_ADDRESS_RECORD.
NAME.
STREET.
STATE.
ZIP.
END RECORD.
|
You access repository data definitions from a COBOL program using the COPY FROM DICTIONARY statement. At compile time, the record definition and its attributes are extracted from the designated repository. Then the compiler converts the extracted definition into a COBOL declaration. For example, the following COBOL statements access the customer and employee address records defined earlier. These definitions have been placed in the repository directory DEVICE:[VMS_DIRECTORY]SALES.
IDENTIFICATION DIVISION. PROGRAM-ID. MASTER-FILE. DATA DIVISION. WORKING-STORAGE SECTION. COPY "DEVICE:[VMS_DIRECTORY]SALES.CUSTOMER_ADDRESS_RECORD" FROM DICTIONARY. COPY "DEVICE:[VMS_DIRECTORY]SALES.EMPLOYEE_ADDRESS_RECORD" FROM DICTIONARY. . . . |
If you compile this program with the /LIST and /COPY_LIST qualifiers, the source listing includes the data definition translated into a COBOL declaration, as shown in the following example:
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. MASTER-FILE.
3 DATA DIVISION.
4 WORKING-STORAGE SECTION.
5 COPY "DEVICE:[VMS_DIRECTORY]SALES.CUSTOMER_ADDRESS_RECORD" FROM DICTIONARY.
L 6 *
L 7 *DEVICE:[VMS_DIRECTORY].SALES.CUSTOMER_ADDRESS_RECORD
L 8 *
L 9 01 CUSTOMER_ADDRESS_RECORD.
L 10 02 NAME PIC X(25).
L 11 02 COMPANY_NAME PIC X(25).
L 12 02 STREET PIC X(20).
L 13 02 CITY PIC X(20).
L 14 02 STATE PIC X(2).
L 15 02 ZIP PIC X(5).
16 COPY "NODE::DEVICE:[VMS_DIRECTORY]SALES.EMPLOYEE_ADDRESS_RECORD" FROM DICTIONARY.
L 17 *
L 18 *DEVICE:[VMS_DIRECTORY].SALES.EMPLOYEE_ADDRESS_RECORD
L 19 *
L 20 01 EMPLOYEE_ADDRESS_RECORD.
L 21 02 NAME PIC X(25).
L 22 02 STREET PIC X(20).
L 23 02 CITY PIC X(20).
L 24 02 STATE PIC X(2).
L 25 02 ZIP PIC X(5).
.
.
.
|
For more information on the COPY FROM DICTIONARY statement, refer to
the Compaq COBOL Reference Manual. For more information on the /LIST and /COPY_LIST
command qualifiers, invoke the online help facility for COBOL at the
operating system prompt.
C.5.3 Recording Dependencies
When you compile a program with the /DEPENDENCY_DATA qualifier, the compiler creates the following repository objects to represent the compiled modules, the resulting object module, and the relationships between them:
The /DEPENDENCY_DATA qualifier can also direct the compiler to create relationships between the compiled module object and other objects in the repository:
For example, recall the program that used COPY FROM DICTIONARY to include the customer and employee address record definitions:
IDENTIFICATION DIVISION. PROGRAM-ID. MASTER-FILE. DATA DIVISION. WORKING-STORAGE SECTION. COPY "DEVICE:[VMS_DIRECTORY]SALES.CUSTOMER_ADDRESS_RECORD" FROM DICTIONARY. COPY "DEVICE:[VMS_DIRECTORY]SALES.EMPLOYEE_ADDRESS_RECORD" FROM DICTIONARY. . . . |
When this program is compiled with the /DEPENDENCY_DATA qualifier, the following objects are created in the repository:
In addition, the record definitions are included in the compiled module.
The COPY FROM DICTIONARY statement is used when you want to create a relationship between a compiled module and a record or field definition. The RECORD statement is used when you need to create a relationship between a compiled module and some other kind of repository object --- one that you do not want copied into the compiled module. For example, suppose you need to create a relationship between the MASTER_FILE compiled module object and a text file object, such as a functional specification. This relationship would indicate that the compiled module is derived from the functional specification. For example:
IDENTIFICATION DIVISION.
PROGRAM-ID. MASTER-FILE.
.
.
.
PROCEDURE DIVISION.
A0100.
.
.
.
RECORD DEPENDENCY "DEVICE:[VMS_DIRECTORY]SALES.SPECIFICATION"
TYPE IS "CDD$COMPILED_DERIVED_FROM" IN DICTIONARY.
.
.
.
|
When this program is compiled with the /DEPENDENCY_DATA qualifier, the compiler creates the following objects and relationships:
For more information on the RECORD statement, refer to the
Compaq COBOL Reference Manual. For more information on the /DEPENDENCY_DATA qualifier,
invoke the online help facility for COBOL at the operating system
prompt.
C.5.4 Data Types
Oracle CDD/Repository supports some data types that are not native to Compaq COBOL. If a data definition contains a field declared with an unsupported data type, Compaq COBOL issues a fatal diagnostic. The Compaq COBOL compiler does not attempt to approximate a data type that it does not support.
Table C-1 shows how Oracle CDD/Repository data types are translated into COBOL data types. It also states the level of support Compaq COBOL provides for Oracle CDD/Repository data types.
| Data Type | VAX | Alpha |
|---|---|---|
| UNSPECIFIED | U | U |
| SIGNED BYTE | W | W |
| UNSIGNED BYTE | W | W |
| SIGNED WORD | S | S |
| UNSIGNED WORD | W | W |
| SIGNED LONGWORD | S | S |
| UNSIGNED LONGWORD | S | S |
| SIGNED QUADWORD | S | S |
| UNSIGNED QUADWORD | W | W |
| SIGNED OCTAWORD | W | W |
| UNSIGNED OCTAWORD | W | W |
| F_FLOATING | S | S |
| F_FLOATING COMPLEX | W | W |
| D_FLOATING | S | S |
| D_FLOATING COMPLEX | W | W |
| G_FLOATING | W | S |
| G_FLOATING COMPLEX | W | W |
| H_FLOATING | W | W |
| H_FLOATING COMPLEX | W | W |
| UNSIGNED NUMERIC | S | S |
| LEFT OVERPUNCHED NUMERIC | S | S |
| LEFT SEPARATE NUMERIC | S | S |
| RIGHT OVERPUNCHED NUMERIC | S | S |
| RIGHT SEPARATE NUMERIC | S | S |
| PACKED DECIMAL | S | S |
| ZONED NUMERIC | W | W |
| BIT | W | W |
| DATE | W | W |
| TEXT | S | S |
| VARYING STRING | W | W |
| POINTER | S | S |
| VIRTUAL FIELD | W | W |
| SEGMENTED STRING | W | W |
| REAL | U | S |
| ALPHABETIC | U | S |
S --Fully supported
W---The data type is translated into a supported type and a diagnostic message is issued.
U---The data type is unsupported and a fatal diagnostic message is issued.
C.5.5 For More Information
For more information about Oracle CDD/Repository, refer to the following
manuals:
| Document | Description |
|---|---|
| Oracle CDD/Repository Architecture Manual | Describes the concepts and capabilities of the Oracle CDD/Repository object-oriented architecture. |
| Using Oracle CDD/Repository on OpenVMS Systems | Provides tutorial information for Oracle CDD/Repository users |
| Oracle CDD/Repository CDO Reference Manual | Provides reference information for the Common Dictionary Operator (CDO) utility |
| Oracle CDD/Repository Callable Interface Manual | Explains how to use the ATIS callable interface |
|
Oracle CDD/Repository Information Model Volume I,
CDD/Repository Information Model Volume II |
Contain reference information on the ATIS and Oracle CDD/Repository type hierarchy |
<>
Compaq COBOL has built-in porting assistance that recognizes foreign COBOL extensions and helps you migrate programs from other systems. Porting assistance is always enabled for some foreign extensions. However, for those features that use new reserved words, this feature is selectively enabled at compile time by qualifiers and flags on the COBOL command line.
Porting assistance provides the following features:
Compaq COBOL porting assistance can help you port programs from other COBOL implementations to Compaq COBOL. It does so by recognizing and reporting occurrences of known extensions from other COBOL implementations that are not implemented in Compaq COBOL (hence "foreign" extensions).
Some porting assistance is always present. Foreign extensions that do not need new reserved words are always recognized and diagnosed as foreign extensions (or, in a few cases, implemented as new features of Compaq COBOL).
The default is for full porting assistance to be turned off, but you can enable it at compile time by adding the foreign extensions option to the COBOL command. The option can be negated by a NO prefix. It can be used in combination with other options, and is independent of those options. See Table 1_2, Compaq COBOL Command Flags on Tru64 UNIX and Table 1-4, COBOL Command Qualifiers for option syntax and defaults.
You enable full porting assistance by adding the foreign extensions option to the compile command as follows:
On OpenVMS
/RESERVED_WORDS=FOREIGN_EXTENSIONS |
On Tru64 UNIX
-rsv foreign_extensions |
Without full porting assistance enabled, if you compile program source code that was written for a compiler other than Compaq COBOL, extensions that are not directly supported by Compaq COBOL are flagged with terse messages and the compile fails. Porting assistance will provide you with better diagnostics and more information that can assist you in recoding the indicated operations with Compaq COBOL syntax.
When full porting assistance is on, the compiler recognizes each occurrence of certain extensions from other COBOL implementations (shown in Table D-1), and outputs a diagnostic that identifies that foreign extension.
For example, your program might contain the following line:
EXAMINE Y REPLACING ALL "A" BY "Z". |
In the absence of the porting assistance, the compiler will output this message:
Invalid statement syntax |
The previous message is accurate, but does not lead you to a resolution.
If you enable porting assistance, you will receive a message that is much more helpful, as follows:
Foreign extensions, EXAMINE statement, not implemented Invalid statement syntax |
The previous message clearly identifies the foreign statement (in this case, EXAMINE), so that you can replace it with the equivalent Compaq COBOL statement.
When full porting assistance is on, the reserved words shown in Table D-1 are added to those shown in the Reserved Words appendix in the Compaq COBOL Reference Manual.
| ADDRESS | CHANGED | CORE-INDEX | DBCS |
| DISP | DISPLAY-1 | EJECT | ENTRY |
| EXAMINE | EXHIBIT | GOBACK | ID |
| KANJI | NAMED | NOTE | OTHERWISE |
| PASSWORD | POSITIONING | RECORDING | RECORD-OVERFLOW |
| RELOAD | REMARKS | REORG-CRITERIA | RETURNING |
| SERVICE | SKIP1 | SKIP2 | SKIP3 |
| TRACE | TRANSFORM |
Ordinarily, the compiler simply treats a declaration of any of these words as a fatal error. The porting assistance option can issue a meaningful diagnostic message that can guide you to appropriate recoding.
Full porting assistance is placed under control of the foreign extensions option, rather than running at all times. Although the porting assistance is useful for porting many programs with foreign extensions, it is not useful with all programs, because the new reserved words may conflict with declared names and produce fatal diagnostic messages for programs that have successfully compiled before.
| Previous | Next | Contents | Index |