Apply overrides when compiling a program

Overrides can be applied at the time a program is being compiled for either of two purposes: to select the source file, or to provide external data definitions for the compiler to use in defining the record formats to be used on I/O operations.

Overrides to the source file are handled just like any other override. They can select another file, another member of a database file, another label for diskette or tape, or change other file attributes.

You can also apply overrides to files that are used within the program being compiled, if they are being used as externally described files in the program. These files are not opened at compile time, and thus the overrides are not applied in the normal manner. These overrides are used at compile time only to determine the file name and library that will be used to define the record formats and fields for the program to use I/O operations. Any other file attributes specified on the override are ignored at compile time. It is necessary that these file overrides be active at compile time only if the file name specified in the source for the program is not the file name that contains the record formats that the application needs.

The file name that is opened when the compiled program is run is determined by the file name that the program source refers to, changed by whatever overrides are in effect at the time the program runs. The file name used at compile time is not kept. The record formats in the file that is actually opened must be compatible with those that were used when the program was compiled. Obviously, the easiest way to assure that records are compatible is to have the same overrides active at run time that were active at compile time. If your program uses externally described data and a different field level file is used at run time, it is typically necessary to specify LVLCHK(*NO) on the override. See Redirect files for details.

The following example shows how overrides work when compiling a program:

Figure 1. An example over overrides when compiling a program. The following example shows how overrides work when compiling a program.

Override 1    OVRDBF FILE(RPGSRC) +
                      TOFILE(SRCPGMS) MBR(INVN42)
Override 2    OVRPRTF FILE(OUTPUT) TOFILE(REPORTS)
                  CALL PGM(A)

                         Program A
Override 3           OVRPRTF FILE(LISTOUT) +
                              TOFILE(OUTPUT)
Override 4           OVRDBF FILE(RPGSRC) WAITFILE(30)
                         CRTRPGPGM PGM(INVENTORY) +
                              SRCFILE(RPGSRC)
                          RETURN

Override 5    OVRPRTF FILE(LISTOUT) +
                       TOFILE(REPORTS) LPI(8)
                  CALL PGM(INVENTORY)

The program INVENTORY opens the printer file REPORTS in place of printer file LISTOUT and creates output at 8 lines per inch.

The program INVENTORY is created (compiled) from the member INVN42 in the database file SRCPGMS. Override 4, which is applied first, overrides an optional file attribute. Override 1, which is applied last, causes the file RPGSRC to be overridden with the database file SRCPGMS, member INVN42.

The program INVENTORY is created with the printer formats from the file REPORTS. Assume that the source for the program INVENTORY, which is taken from file SRCPGMS and member INVN42, contains an open to the printer file LISTOUT. Override 3, which is applied first, causes the file LISTOUT to be overridden with OUTPUT. Override 2, which is applied last, overrides OUTPUT with REPORTS. Other attributes can be specified here, but it is not necessary because only the record formats are used at compile time.

At run time, override 3 is no longer active, because program A has ended. Therefore override 2 has no effect on LISTOUT. However, override 5, which is active at run time, replaces LISTOUT with REPORTS and specifies 8 lines per inch. Because the same file is used for compilation and run-time, you can leave level checking on.

Related reference
Effect of overrides on some commands