Process overrides: General principles

 

The system processes overrides according to some general principles.

• Applied overrides include any that are in effect at the time a file is opened by an application program, when a program that opens a file is compiled, or when certain system commands are used. (See Override of file attributes, Application of overrides when compiling a program, and Effect of overrides on some commands). Thus, any overrides that are to be applied must be specified either before the file is opened by a program or before a program that opens the file is compiled. It is not necessary that overrides must be supplied for every file that is used in a program. Any file name for which no override is supplied is used as the actual file name.

• Override commands that are scoped to the job level remain in effect until they are replaced, deleted, or until the job in which they are specified ends. For more information about deleting overrides, see Deletion of overrides.

• There can be only one active override for a file at each level (job level, activation group level, or call level). If more than one override for the same file exists at the same level, the most recent one is active.

  For an example of how the system processes overrides when more than one override for the same file exists at the same level, see Scenario: Overrides to the same file at the same call level.

• Override commands that are scoped to the job level apply to all programs that are running in the job regardless of the call level or activation group in which the overrides are specified.

• Override commands that are scoped to an activation group level apply to all programs that are running in the activation group regardless of the call level in which the overrides are specified.

• An override command (scoped to the call level) that is entered interactively exists at the call level for the caller of that command processor. For example, an override (scoped to the call level) that is entered on the command entry display cannot be deleted or replaced from a command processor that is called from the command entry display.

• The call level of an override (scoped to the call level) that is coded in a CL program is the call level of the CL program.

• An override (scoped to the call level) outside a program in a batch job takes the call level of the batch job command processor.

• If an override command (scoped to the call level) is run using a call to the QCMDEXC program, the override takes the call level of the program that called the QCMDEXC program. For an example, see CL program overrides.

• Exits (ENDPGM, RETURN, or abnormal exits) from a call operation delete overrides scoped to that call level. However, they do not delete overrides that are issued in that call level when they are scoped to the activation group level or the job level.

  For an example, see Scenario: Effect of exits on overrides.

• The TFRCTL command causes one program to be replaced by another program at the same call level. The program, to which control is transferred, runs at the same call level as the program that contained the TFRCTL command. An override command in a program that transfers control to another program is not deleted during the transfer of control.

  For an example, see Scenario: Effect of TFRCTL on overrides.

• Several overrides (possibly one per call level, one at the activation group level, and one at the job level) to a single file are allowed. They are processed according to the priorities in Process priority of overrides.

  For an example of processing overrides, see How the system processes overrides: scenario.

• You can protect an override from being overridden by overrides at lower call levels, the activation group level, and the job level; specify SECURE(*YES) on the override. For an example, see Securing files against overrides.

 

Parent topic:

How the system processes overrides