You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
The attributes specified on the Override with Printer <strong>File</strong> (OVRPRTF) commands<br />
are ignored (even though they might have been allowed on the OVRDKTF<br />
commands). Refer to “Redirecting files” on page 64 for more information on the<br />
effect of overrides that change the file type.<br />
Processing overrides: General principles<br />
The system processes overrides according to the following general principles:<br />
v Overrides applied include any that are in effect at the time a file is opened by an<br />
application program, when a program that opens a file is compiled, or when<br />
certain system commands are used. (See “Overriding file attributes” on page 38,<br />
“Applying overrides when compiling a program” on page 53, and “Effect of<br />
overrides on some commands” on page 35). Thus, any overrides that are to be<br />
applied must be specified either before the file is opened by a program or before<br />
a program that opens the file is compiled. It is not necessary that overrides must<br />
be supplied for every file that is used in a program. Any file name for which no<br />
override is supplied is used as the actual file name.<br />
v Override commands that are scoped to the job level remain in effect until they<br />
are replaced, deleted, or until the job in which they are specified ends. For more<br />
information on deleting overrides, see “Deleting overrides” on page 54.<br />
v There can be only one active override for a file at each level (job level, activation<br />
group level, or call level). If more than one override for the same file exists at<br />
the same level, the most recent one is active.<br />
For an example of how the system processes overrides when more than one<br />
override for the same file exists at the same level, see “Overrides to the same file<br />
at the same call level: scenario 1” on page 49.<br />
v Override commands that are scoped to the job level apply to all programs that<br />
are running in the job regardless of the call level or activation group in which<br />
the overrides are specified.<br />
v Override commands that are scoped to an activation group level apply to all<br />
programs that are running in the activation group regardless of the call level in<br />
which the overrides are specified.<br />
v An override command (scoped to the call level) that is entered interactively<br />
exists at the call level for the caller of that command processor. For example, an<br />
override (scoped to the call level) that is entered on the command entry display<br />
cannot be deleted or replaced from a command processor that is called from the<br />
command entry display.<br />
v The call level of an override (scoped to the call level) that is coded in a CL<br />
program is the call level of the CL program.<br />
v An override (scoped to the call level) outside a program in a batch job takes the<br />
call level of the batch job command processor.<br />
v If an override command (scoped to the call level) is run using a call to the<br />
QCMDEXC program, the override takes the call level of the program that called<br />
the QCMDEXC program. For an example, see “CL program overrides” on<br />
page 50.<br />
v Exits (ENDPGM, RETURN, or abnormal exits) from a call operation delete<br />
overrides scoped to that call level. However, they do not delete overrides that<br />
are issued in that call level when they are scoped to the activation group level or<br />
the job level.<br />
For an example, see “Effect of exits on overrides: scenario” on page 48.<br />
v The TFRCTL command causes one program to be replaced by another program<br />
at the same call level. The program, to which control is transferred, runs at the<br />
Chapter 3. Using overrides 47
Change language