# Compaq COBOL
User Manual

Previous | Contents | Index

# C.5 Using Oracle CDD/Repository (OpenVMS)

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:

- Enable dependency recording by compiling your program with the /DEPENDENCY_DATA qualifier.
- Direct the COBOL compiler to a repository or a compatibility dictionary in which to store the dependency information.

## C.5.1 Creating Record and Field Definitions

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.

## C.5.2 Accessing Oracle CDD/Repository Definitions from Compaq COBOL Programs

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:

- A compiled module object is created for each separately compiled program. The name of the object is the PROGRAM-ID name with hyphens translated to underscores. Compiled module objects are put in the repository pointed to by the logical name CDD$DEFAULT, or in the compatibility dictionary if CDD$DEFAULT is not defined.
- For each object file generated by the compilation, the compiler creates a temporary file object. Each compiled module object contains a pointer to a file object, and several compiled module objects can point to the same file object. At the end of the compilation, the file object does not actually exist in the repository. However, information relating the compiled module object and the object file does exist in the repository.

The /DEPENDENCY_DATA qualifier can also direct the compiler to create relationships between the compiled module object and other objects in the repository:

- If the source file contains a COPY FROM DICTIONARY statement, the compiler creates a CDD$COMPILED_DEPENDS_ON relationship between the compiled module object and the record or field definition that is being copied. It also copies the repository object into the compiled module.
- If the source file contains a RECORD statement, the compiler creates a relationship between the compiled module object and the specified repository object, but it does not copy the repository object into the compiled module. The relationship can be either CDD$COMPILED_DEPENDS_ON or CDD$COMPILED_DERIVED_FROM. The default relationship type is CDD$COMPILED_DEPENDS_ON.

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:

- A compiled module object called MASTER_FILE
- A temporary file object representing the object file produced by the compilation
- A relationship between the MASTER_FILE compiled module object and the object file
- A relationship between the MASTER_FILE object and the CUSTOMER_ADDRESS_RECORD definition
- A relationship between the MASTER_FILE object and the EMPLOYEE_ADDRESS_RECORD definition

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:

- A compiled module object called MASTER_FILE
- A temporary file object representing the object file produced by the compilation
- A relationship between the MASTER_FILE compiled module object and the object file
- A relationship between the MASTER_FILE object and the repository object called SPECIFICATION, which represents the functional specification text file

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.

Table C-1 Oracle CDD/Repository Data Types: Level of Support in Compaq COBOL on OpenVMS
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

<>

# Appendix D
Porting to Compaq COBOL from Other Compilers (Alpha)

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:

- The ability to detect syntax from other COBOL implementations
- The process of applying foreign reserved words (in other words, from other COBOL implementations) in the presence of foreign COBOL extension syntax
- Messages to help you recode those program steps that use the foreign extensions
- Support for selected syntax synonyms used in other COBOL implementations

# D.1 Porting Assistance

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.

Table D-1 Recognized Foreign Reserved Words
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