Using one XFD for multiple tables

Problem:

In this scenario, the use of a single XFD is desired rather than many XFDs, one for each of several different tables. The table names have the pattern "???MYHIS" where each "?" represents a variable character in the table name. However, putting "*MYHIS=[abcmyhis.xfd]" in the ACUFH configuration file (mfdbc.conf) does not work. What values should be in the SELECT for the ASSIGN TO and the $XFD FILE= directive in the FD for this to work properly?

Resolution:

The following is a step-by-step explanation:

1. The program has a SELECT for a file ABCMYHIS, with a variable assigned, something like this:

   SELECT ABCMYHIS ASSIGN TO WS-ABCMYHIS-NAME ...

2. Immediately before the FD, there is an XFD FILE directive, which is required because of the variable ASSIGN:

   $XFD FILE= ABCMYHIS
    FD ABCMYHIS.
    01  ABCMYHIS-RECORD...

   This causes the compiler to create an XFD file named abcmyhis.xfd. This is the only effect of the XFD FILE directive.

3. In the ACUFH configuration file (mfdbc.conf, named in the A_CONFIG environment variable), there is an XFD_MAP entry like this:

   XFD_MAP    *MYHIS = abcmyhis

   This means that any time a program tries to access a file with an ASSIGN that matches "*MYHIS", the interface will use the XFD file named abcmyhis.xfd.

4. During program execution, a value is given to the ASSIGN name and the file is opened:

   MOVE “DEFMYHIS” TO WS-ABCMYHIS-NAME.
   OPEN I-O ABCMYHIS.

   Since the current ASSIGN name (DEFMYHIS) matches the pattern in XFD_MAP, the file abcmyhis.xfd is used to describe the table layout. The Oracle table “DEFMYHIS” will be accessed (this is taken from the current ASSIGN name).

5. At another point in the program, if you MOVE a different value to the ASSIGN name:

   MOVE “GHIMYHIS” TO WS-ABCMYHIS-NAME.
   OPEN I-O ABCMYHIS.

   "GHIMYHIS" also matches the pattern in XFD_MAP, so again abcmyhis.xfd is used, but the Oracle table accessed will be GHIMYHIS.

For additional information on the XFD_MAP and other configuration variables, please refer to the Database Connectors User’s Guide Reference section.

Incident Number: 2287499