OVRDBF is often used for ‘redirection’. A program can be compiled over a specific file description. You can execute OVRDBF to cause the program to open a different file description than the one that was used for the compile.

Example usage — Many commands have an option to output to an *OUTFILE. The outfile will be based upon a file description that IBM supplies in QSYS. The DSPUSRPRF command is one of those. Its help text says that the outfile will be based on the file named QADSPUPO in QSYS if you ask for *OBJOWN.

You can use QADSPUPO as the name of the file in your program when you compile. And when you run, you have the DSPUSRPRF command send its output to a different file name, perhaps in QTEMP, and then you execute OVRDBF QADSPUPO to redirect your program to open the new file instead of QADSPUPO.

The result is that the format of QADSPUPO is used to compile the program, and the format of your new file matches when your program opens it. You don’t need to have a copy of the new file when you compile because it’s going to match correctly when you open the file.

Other uses of OVRDBF include changing some attributes of the file at run-time, including even changing the device type in some cases.

One attribute that is often overridden is the SHARE() attribute. By default, files are created as SHARE(*NO). The ‘sharing’ refers to the ODP (Open Data Path) that gets created when a file is opened in a program. See What is Open Data path in OVRDBF? for some discussion.

Tom

OVRDBF cmd, with respect to your question will override another file over a file. Overide scope will determine the accessibility of the overriden file to other programs.

Override scope can be –
Activation group
Job
Call level

Based on the scope defined the file may be accessible.