C.4 CDD/Repository

CDD/Repository is an optional OpenVMS software product available under a separate license. The CDD/Repository product allows you to maintain shareable data definitions (language-independent structure declarations) that are defined by a data or repository administrator.

Note

CDD/Repository supports both the Common Data Dictionary (Version 3) and CDD/Plus (Version 4) interfaces. Older dictionary versions need to be converted to repository (CDD/Repository) format using a supplied conversion utility. For detailed information about CDD/Repository, see the CDD/Repository documentation.

C.4.1 Using CDD/Repository

CDD/Repository data definitions are organized hierarchically in the same way files are organized in directories and subdirectories. For example, a repository for defining personnel data might have separate directories for each employee type.

Descriptions of data definitions are entered into the dictionary in a special-purpose language called CDO (Common Dictionary Operator, which replaces the older interface called CDDL, Common Data Dictionary Language). 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.

To extract data definitions from CDD/Repository, include the #pragma dictionary preprocessor directive in your DEC C source program. If the data attributes of the data definitions are consistent with DEC C requirements, the data definitions are included in the DEC C program during compilation. See Section 5.4.2 for information about using #pragma dictionary.

CDD/Repository data definitions, in the form of DEC C source code, appear in source program listings if you specify the /SHOW=DICTIONARY qualifier on the CC command line.

The advantage in using CDD/Repository instead of DEC C source for structure declarations is that CDD/Repository record declarations are language-independent and can be used with several supported OpenVMS languages.

C.4.2 Accessing CDD/Repository from DEC C Programs

A repository or data administrator uses CDO to create repositories, define directory structures, and insert record and field definitions into the repository. Many repositories can be linked together to form one logical repository. If the paths are set up correctly, users can access definitions as if they were in a single repository regardless of physical location.

CDO also creates the record paths. Once established, records can be extracted from the repository by means of the #pragma dictionary preprocessor directive in DEC C programs. At compile time, the record definition and its attributes are extracted from the designated repository. Then the compiler converts the extracted record definition into a DEC C structure declaration and includes it in the object module.

The #pragma dictionary preprocessor directive incorporates CDD/Repository data definitions into the DEC C source file during compilation. The #pragma dictionary directive can be embedded in a DEC C structure declaration. See Section 5.4.2 for sample usage of #pragma dictionary.

C.4.3 Support for CDD/Repository Data Types

CDD/Repository supports all OpenVMS data types. DEC C can translate all the OpenVMS data types when they are declared in CDD/Repository records. Data types that do not occur naturally in the DEC C language are handled in the following way:

• DEC C never attempts to approximate a data type that is not supported by the C language.

• Instead of approximating a data type, DEC C uses its own structure data type to represent all types (except for excessively long bit strings) not supported by the C language; specifically, DEC C creates structures of arrays of type char that are large enough to represent the data structure.

• Bit strings (aligned or unaligned) can be up to 32 bits long, as defined by the DEC C language. Bit strings longer than 32 bits are broken into increments of 32-bit strings or smaller so that the structure is correct with respect to size. However, the long bit string cannot be accessed as one unit.

• All row-major arrays are represented as zero-origin arrays of the appropriate size. An informational message is issued if the record description specifies nonzero-origin dimension bounds. The compiler adjusts the upper bound appropriately to maintain the correct number of elements relative to a lower bound of zero. Column-major arrays are converted to one-dimensional arrays containing the same total number of elements.

The compiler applies various consistency checks to the record attributes extracted from CDD/Repository, particularly the field data-type attributes. An error message is issued when a record description does not pass the consistency checks. An informational message is issued when DEC C is confronted with facility-independent attributes that are not supported. An error message is issued when an attribute that is required by DEC C is not present, even if the attribute is optional in CDD/Repository record protocol.

The compiler synthesizes names for unnamed and filler fields. If CDD/Repository does not specify a name and a name is required by the syntax of the DEC C language, the compiler synthesizes the name cc_cdd$_unnamed_nnnnn. When CDD/Repository specifies a filler or a name that DEC C does not support, the compiler synthesizes the name cc_cdd$_filler_#nnnnn, which includes the pound sign character (#). The string nnnnn represents a unique integer. The # is not a valid character in an identifier, so you cannot reference these fields.

Unsupported data types are mapped into DEC C as structures of character arrays of the appropriate size. The declaration of these data types uses the following format:

struct { char Cname [s]; } CDDname;

The CDDname is the name of the member in the CDD/Repository record. Cname is an identifier of the form cc_cdd_$_unsupported_#nnnnn, where nnnnn is a unique integer, and s is the size of the data item, in bytes.

DEC C generates variant_struct or variant_union declarations for unnamed CDD/Repository structures and unions, so you do not have to specify these references.

Table C-2 summarizes the mapping between CDD/Repository data types and DEC C data types.

Table C-2 Mapping Between CDD/Repository and DEC C Data Types