Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
HP.com home

HP OpenVMS Systems Documentation

Content starts here

Compaq COBOL
User Manual


Previous Contents Index

C.5.4 Compiling from Within LSE

To compile a completed COBOL program, issue the following command at the LSE prompt:



LSE> COMPILE

To compile a COBOL program that contains placeholders and design comments, include the following qualifiers with the previous command:



LSE> COMPILE $/ANALYSIS_DATA

The /ANALYSIS_DATA qualifier causes the compiler to generate a data analysis file containing source code analysis information and to provide this information to the SCA library.

LSE provides several commands to help you review errors and examine your source code:

Command Key Binding Function
     

C.6 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.6.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.6.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.6.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.6.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.6.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

<>


Previous Next Contents Index

 

Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2012 Hewlett-Packard Development Company, L.P.