How the server processes overrides

In the Integrated Language Environment^®, overrides can be scoped to the call level, the activation-group level (the default), and the job level.

Figure 1 shows a representation of a job running in the Integrated Language Environment.

Figure 1. A job in the Integrated Language Environment^®

In the description that follows, the reference keys refer to the corresponding reference keys in the Figure 1.

A job is a piece of work that the server performs. An interactive job begins when a user signs on and ends when a user signs off. Overrides (A) that are scoped to the job level affect all programs that are running in any activation group within the job. There can be only one active override for a file at the job level. If you specify more than one, the most recent one takes effect. An override that is scoped to the job level remains in effect until one of the following events occurs:

The job ends
The server explicitly deletes the override
Another job level override for the same file replaces the override

This is true regardless of the call level in which the overrides were specified. For example, an override that is issued in call level 3 that is scoped to the job level remains in effect when call level 3 is deleted. Overrides can be scoped to the job level by specifying OVRSCOPE(*JOB) on the override command.

Overrides (B) that are specified in the user default activation group can be scoped to the call level or to the job level. They cannot be scoped to the user default activation group level. However, overrides (C and D) that are specified in a named activation group can be scoped to the call level, activation group level, or the job level. Overrides (C) scoped to a named activation group level remain in effect until the server replaces or deletes the override, or until the server deletes the named activation group.

Overrides (D) that are scoped to the call level within a named activation group remain in effect until they are replaced, deleted, or until the program in which they were issued ends. Overrides can be scoped to the call level by specifying OVRSCOPE(*CALLLVL) on the override command.

Overrides that are scoped to a named activation group level apply only to programs that run in the named activation group. They have no effect on programs that run in other named activation groups or in the user default activation group.

Call levels identify the subordinate relationships between related programs when one program calls another program within a job. Overrides that are scoped to the call level remain in effect from the time they are specified until they are replaced, or deleted, or until the program in which they are specified ends. This is true whether you issue the override in the user default activation group or in a named activation group.

For example:

Figure 2. Call levels within a job

Several commands, such as Work with Job (WRKJOB), Work with Active Jobs (WRKACTJOB), or Display Job (DSPJOB), have options that allow you to display the call stack of an active job. There is a one-to-one relationship between a program that is displayed in the call stack and the call level. The first program name displayed (at the top of the list) on the call stack is the program at call level 1 for that job. Call level 1 is the lowest call level for a job. The second program name displayed is the program at call level 2 for that job. The last program name displayed is the program at the highest call level for that job.

In the example in Figure 2, the Transfer Control (TFRCTL) command to PGMC causes PGMC to replace PGMB from the call stack. A CALL command places another program in the call stack. A RETURN command removes a program from the stack.