)
Figure 9.6 Work Management Concepts
| Previous | Table of Contents | Next |
When the interrupt-handler routine is finished, it executes another special PowerPC instruction. This instruction, called Return From Interrupt (rfi), restores the processor to the state it had before the interrupt occurred. The selected bits in SRR 1 are first placed into the corresponding bits in the MSR. Then the next instruction is fetched, under control of the new MSR value, from the address in SRR 0. If this instruction enables any pending exceptions, the interrupt associated with the highest priority pending exception is generated before the first instruction in the context established by the completion of this rfi instruction.
The two PowerPC instructions just described, sc and rfi, allow the processor to call an interrupt handler when an interrupt occurs and to return to normal instruction processing when the interrupt has been handled. Within the AS/400, we wanted a similar mechanism to allow one SLIC routine to call another. For example, we wanted the FLEH to call the SLEH very efficiently. To accomplish this, we defined two new instructions for the PowerPC architecture. They are called System Call Vectored (scv) and Return From System Call Vectored (rfscv).
The scv instruction is similar to the sc instruction, with a few important differences. Instead of transferring control to only one location, the scv instruction identifies one of 128 locations. A separate SLIC routine can begin at each of these 128 locations. Thus, the scv instruction can be used to efficiently pass control between SLIC routines. Another difference is the scv instruction does not modify the settings of the MSR bits. This means, for example, a called routine can use virtual addresses. With virtual addressing, SLIC routines can be written to be pageable. Still another difference is that the scv instruction does not use the SRR 0 and the SRR 1 registers to save the machine status. Instead, it uses two processor registers that can be accessed with nonprivileged instructions. The rfscv instruction provides the return operation for the scv.
The preceding sections show the difficulties of having a full-fledged process structure. A tremendous amount of functionality is provided with any modern process structure, but that functionality also can mean a tremendous amount of complexity if the user has to manage the structure. In keeping with the philosophies of technology independence and integration, the AS/400 manages this complex structure for the user through OS/400’s work-management component. A user deals with the definition of a job, which more closely matches a business application for the system. OS/400 and the underlying machine do the rest.
There is a downside to building a full job structure on top of the process model. There is much more flexibility if the characteristics of the process can be tuned to match the characteristics of any particular application; this tuning enables enhanced performance of an application that does not need all the function the job structure provides. A lightweight process, or a subprocess, which is usually called a thread, is becoming a fundamental building block for many new operating systems. Applications written to this thread model do not use a full-function job structure, and consequently they can achieve higher performance when it comes to switching from one program to another.
At this point, it is important to note that, at the hardware level, the AS/400 has one of the most efficient tasking structures in the industry. In a commercial application, a large percentage of the processing, often as high as 80 or 90 percent, is performed in the operating system rather than in the application. The applications request services from the operating system instead of performing the services themselves. In an AS/400, those services are primarily performed in SLIC, and SLIC uses the highly efficient tasking structure. In a later section, we look at how the AS/400 supports native threads process to accommodate applications written for other operating systems.
The management of the flow of work submitted to the AS/400 is provided by OS/400’s work-management component. A job is the unit of work submitted by the user. To review an earlier discussion, work management recognizes several types of jobs, including the traditional interactive and batch jobs.
The process discussed in the preceding sections describes the unit of work submitted by work management to the underlying machine. An MI process object has no counterpart in OS/400. A job is not an OS/400 object. Neither are routing steps or subsystems, which we discuss shortly. Work management deals with processes directly. A job can be executed within a single process, or it can be executed within a series of processes whose initiation is managed by one or more controlling processes. From a user standpoint, each new process initiation on behalf of a job is called a routing step.
Work management views the total system as the hierarchy of domains shown in Figure 9.6. The lowest level in this hierarchy is the routing step. The next higher level is the job. A job is processed by one or more consecutive routing steps. Jobs are contained in subsystems, each of which contains similar types of jobs, such as all interactive jobs. Subsystems control certain resources of the system, as we will see shortly. Finally, the highest level in the hierarchy is the system itself. Associated with the system are certain system values and network attributes that are used for the entire system. An example would be the name of the system in a network of systems.
Figure 9.6 Work Management Concepts
An AS/400 subsystem is a single, predefined operating environment. All the jobs in a subsystem should be of the same type (e.g., batch) and share certain system resources. Because the configuration of a subsystem and determination of which jobs run in which subsystem are entirely under the control of each AS/400 installation, there is no guarantee all jobs in a subsystem are of the same type. An OS/400 object, known as a subsystem description, is associated with each subsystem. The subsystem description contains general information about the resources allocated to the subsystem, and it points to other OS/400 objects that provide more information about the jobs in the subsystem. The OS/400 object types pointed to by a subsystem description include job descriptions, classes, and programs.
A job description is an OS/400 object that identifies attributes and resources associated with a job. Identified are such things as
| Previous | Table of Contents | Next |
){kind=link}