


There are several elements of COBOL that require special handling when data dictionaries are built. These include multiple record definitions, REDEFINES, FILLER, and OCCURS. This section describes how ACUCOBOL-GT handles each of these situations.
Databases generally do not support the notion of multiple definitions for the same column. (In a similar sense, when you are editing a data file, it makes sense to see and change only one view of the data, rather than multiple views.) As the following paragraphs explain, whenever a COBOL program gives more than one definition for the same data, the compiler makes a choice about which definition to use in the data dictionary. Then it disregards the rest.
KEY IS phrase
Fields named in KEY IS phrases of SELECT statements are included as fields in the XFD. Other fields that occupy the same areas as the key fields (by either explicit or implicit redefinition) are not included by name, but are mapped to the key field column names by the data dictionary.
REDEFINES clause
Fields contained in a redefining item occupy the same positions as the fields being redefined. The compiler needs to select only one of the field definitions to use. The default rule that it follows is to use the fields in the item being redefined as column names; fields that appear subordinate to a REDEFINES clause are mapped to column names by the data dictionary.
Multiple record definitions
This same rule extends to multiple record definitions. In COBOL, multiple record definitions are essentially redefinitions of the entire record area. This leads to the same complication that is encountered with REDEFINES: multiple definitions for the same data. So the compiler needs to select one definition to use.
Because the multiple record types can be different sizes, the compiler needs to use the largest one, so that it can cover all of the fields adequately. Thus, the compiler's rule is to use the fields in the largest record defined for the file. If more than one record is of the "largest" size, the compiler uses the first one.
Group items
FILLER data items
In a COBOL FD, FILLER data items are essentially place holders. FILLER items are not uniquely named and thus cannot be uniquely referenced. For this reason, they are not placed into the Acucorp data dictionary. The dictionary maintains the correct mapping of the other fields, and no COBOL record positional information is lost.
Sometimes you need to include a FILLER data item, such as when it occurs as part of a key. In such a case, you could include it under a USE GROUP directive or give it a name of its own with the NAME directive, described in section 5.3.3.5.
OCCURS clauses
An OCCURS clause always requires special handling, because the Acu4GL runtime system must assign a unique name to each database column. The runtime accomplishes this by appending sequential index numbers to the item named in the OCCURS.
For example, if the following were part of a file's description:
03 employee-table occurs 20 times.
05 employee-number pic 9(3)
then these column names would be created in the database table:
employee_number_1
employee_number_2
.
.
.
employee_number_10
employee_number_11
.
.
employee_number_20
The alfred record editor shows only the names of the fields, without subscripts or indexes.
Summary of dictionary fields
Fields defined with an OCCURS clause are assigned unique sequential names. Fields without names are disregarded.
When multiple fields occupy the same area, the compiler chooses only one of them unless you have a WHEN directive to distinguish them. To choose:
The compiler preserves fields mentioned in KEY IS phrases.
It discards group items unless USE GROUP is specified.
It discards REDEFINES.
It uses the largest record if there are multiple record definitions.
Identical field names
In COBOL you distinguish fields with identical names by qualification. For example, there are two fields named RATE in the following code, but they can be qualified by their group items. Thus, you would reference RATE OF TERMS-CODE and RATE OF AR-CODE in your program:
01 record-area.
03 terms-code.
05 rate pic s9v999.
05 days pic 9(3).
05 descript pic x(15).
03 ar-code.
05 rate pic s9v999.
05 days pic 9(3).
05 descript pic x(15).
However, database systems consider duplicate names an error. Thus, if more than one field in a particular file has the same name, the data dictionary will not be generated for that file.
The solution to this situation is to add a NAME directive (see section 5.3.3.5) that associates an alternate name with one or both of the conflicting fields.
Long field names
The compiler determines whether field names are unique within the first 18 characters. This is because some RDBMSs truncate longer field names to 18 characters. (In the case of the OCCURS clause described above, the truncation is to the original name, not the appended index numbers.) If the field names are not unique within 18 characters, the XFD file is generated, but a warning message is issued.
You can, instead of allowing default truncation, use the NAME directive to give a shorter alias to a field with a long name. Note that within the COBOL application you will continue to use the original name. The NAME directive affects only the data dictionary.
Naming the XFD
The compiler needs to give a name to each XFD file (data dictionary) that is built. It attempts to build the name from your COBOL code, although there are some instances where the name in the code is nonspecific, and you must provide a name.
Each XFD name is built from a starting name that is derived (if possible) from the SELECT statement in your COBOL code. The following paragraphs explain how that occurs.
ASSIGN name is a variable
If the SELECT for the file has a variable ASSIGN name (ASSIGN TO filename), then you must specify a starting name for the XFD file via a FILE directive in your code. This process is described in section 5.3.3.4.
ASSIGN name is a constant
If the SELECT for the file has a constant ASSIGN name (such as ASSIGN TO "COMPFILE"), then that name is used as the starting name for the XFD name.
ASSIGN name is generic
If the ASSIGN phrase refers to a generic device (such as ASSIGN TO "DISK"), then the compiler uses the SELECT name as the starting name.
Forming the final XFD name
From the starting name, the final name is formed as follows:
1. The compiler removes any extensions from the starting name.
2. It constructs a "universal" base name by stripping out directory information that fits any of the formats used by the operating systems that run ACUCOBOL-GT.
3. It converts the base name to lower case.
4. It appends the letters ".xfd" to the base name.
Examples of XFD names
COBOL code: File name: ASSIGN TO "usr/ar/customers.dat" customer.xfd
SELECT TESTFILE, ASSIGN TO DISK testfile.xfd
ASSIGN TO "-D SYS$LIB:HELP" help.xfd
ASSIGN TO FILENAME (you specify)