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.
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:
Examples of XFD names
| COBOL code: | File name: |
| ASSIGN TO "usr/ar/customer.dat"
| customer.xfd |
| SELECT TESTFILE, ASSIGN TO DISK
| testfile.xfd |
| ASSIGN TO "-D SYS$LIB:HELP"
| help.xfd |
| ASSIGN TO FILENAME
| (you specify) |
At run time, it is possible to use a single XFD for files that have different names. For example, suppose a site has customer files that have identical structures but different names (CUST0001, CUST0002, CUST0003, etc.). It's not necessary to have a separate XFD for each file, so long as their record definitions are the same.
The individual files can all be mapped to the same XFD via a runtime configuration variable called XFD_MAP. The following paragraphs describe how it works.
Suppose your COBOL application has a SELECT with a variable ASSIGN name, such as customer-file. This variable assumes different values (such as CUST0001 and CUST0002) during program execution.
Before compiling the application, you would use the FILE directive to provide a base name for the XFD. Suppose you provide "CUST" as the base. The compiler would then generate an XFD named "cust.xfd". (The compiler always converts XFD names to lower case.)
To ensure that all customer files, each having a unique name, will use this same XFD, you make this entry in your runtime configuration file:
XFD_MAP CUST* = CUST
The asterisk ("*") in the example is a wildcard that matches any number of characters. Note that the extension ".xfd" should not be included in the map. This statement would cause the XFD "cust.xfd" to be used for all files whose names begin with "CUST".
The XFD_MAP variable has this syntax:
XFD_MAP [pattern = base-xfd-name] ...
where pattern consists of any valid filename characters and may include "*" or "?". These two characters have special meanings in the pattern:
| * | matches any number of characters |
| ? | matches a single occurrence of any character |
| CUST???? | matches CUST0001 and CUSTOMER;
does not match CUST001 or CUST00001 |
| CUST* | matches all of the above |
| CUST*1 | matches CUST001 and CUST0001 and CUST00001;
does not match CUSTOMER |
| *OMER | matches CUSTOMER;
does not match CUST001 or CUST0001 |
XFD values can be replaced or be added to the end of existing XFD map values by setting the XFD_MAP_RESETS configuration variable. This configuration variable determines whether setting the XFD_MAP adds to or replaces the existing value. When this variable is set to "0" (off, false, no), setting the XFD_MAP adds new value patterns to the end of the existing value. When it is set to "1" (on, true, yes), setting the XFD_MAP replaces the existing value with a new value. The default value is "1" (on, true, yes).
This variable may be useful if you need to include multiple XFD_MAP lines in a configuration file, and want to avoid setting and resetting the variable. When multiple lines exist, all patterns are used in the order they are listed.