With the introduction of multiprocessors, and especially with our desire to incorporate large numbers of processors in SMP configurations, we decided that we needed a more sophisticated mechanism to adjust the priority of the tasks in the system to maximize the overall system performance. A group of researchers at IBM’s Research Division in New York were working on a project they called a delay-cost scheduler. Working together with Research, we were able to create an AS/400 version of this scheduler, which is now incorporated into the SLIC of every AS/400 RISC system. The specifics of the algorithms used in this scheduler are fairly complex and are beyond what I can easily describe here. However, the algorithms of this dynamic priority scheduler allow tasks to execute out of priority-order sequence whenever the system performance will be enhanced and the cost of delaying any particular task will not be significant. The result has been more efficient utilization of the RISC processors, especially for the n-ways.

Now that we have covered the lowest level of task dispatching in an AS/400, we can begin to see how this function supports the higher concept of a process.

MI Processes

A process is a system object at the MI; it is called a process control space. Notice there is no equivalent OS/400 object, as we will see when we look at work management later in this chapter. The responsibility of an MI process is to tie together the resources needed to execute a program, or more accurately, the invocation of a program. Because programs are shared, multiple users can be executing the same program. Of course, each user has his or her own data that the program is using. Because a program needs some place to temporarily store the information or the variables used during its execution, we need to provide a work area for each invocation of a program. This responsibility falls to the MI process.

Before we look at the structure of a process itself, we need to understand the types of storage a program in execution uses. The use of compilers and HLLs significantly affects how programs execute, and a big factor is how the compiler allocates and addresses the program’s variables. An HLL often has some form of declaration statements to identify the type of variables and where the compiler should allocate space for these variables.

To understand what a process must support, we want to look at the three separate areas in which current HLLs allocate their data. They are

•  Static storage area — A compiler uses this type of storage to allocate global variables and constants for the program. The name global is used because any part of the program can access this storage area. For this reason, some systems call this area the global data area.

•  Automatic storage stack — This area is used to allocate local variables. When a program executes a call instruction, the variables associated with the calling procedure must be saved somewhere so they can be restored on a return instruction. These variables are called local, because they have meaning only to the procedure that executed the call. Calls can be nested, meaning one procedure can call another, which can call another, and so on. This means the storage area must automatically grow and shrink on calls and returns, respectively. A stack is used for this automatic storage area. A stack has two parts. It has a contiguous block of memory containing the data, and it has a stack pointer telling where the top of the stack is located in memory. The bottom of the stack is at a fixed address in memory, and the stack pointer contains the high address. On a call, the address in the stack pointer is increased to provide enough storage for the local variables of the calling procedure. On a return, the address in the stack pointer is decreased by the amount of local variable space. In this way, the size of the stack grows and shrinks dynamically. In some systems, this storage area is called the dynamic storage area.

•  Heap storage area — This area is used to allocate dynamic data that does not adhere to a stack structure. A stack is good for storing single variables (scalars) because all entries are the same, usually the size of a single register. A stack does not work well for variable length data, such as arrays of data elements. Data arrays can be stored in a heap. An array in a heap is accessed using an address that points to the beginning of the array, and then using offsets to that address.

Note that all three areas are referred to as storage areas, not memory areas. Any particular system may use a combination of registers, memory, and disk storage to implement these areas, hence the name storage.

Original Process Model

Like the Original Program Model (OPM) discussed in Chapter 4, the original process model was designed to support languages such as RPG, Cobol, and CL. The original model reflected a structure where each process was a single unit of work and the programs executed by the process tended not to be very modular.

A process is implemented as a system object at the MI. In addition to all the control information, the object either contains the storage areas or points to the storage areas the process uses. The three types of storage areas needed by a process were supported by the original process model as follows:

•  Program Static Storage Area (PSSA) — A single copy of a static storage area existed for the entire process.

•  Program Automatic Storage Area (PASA) — This area in the process object contained the call/return stack.

•  Heap Storage — No support existed for heap storage in the original process model. Heap storage had to be managed outside the model separately by each language compiler.

Looking at the internals of the system object for an original MI process, which was also called a process control space, we would see two segments. The base segment contained much of the control information, along with the TDE for the process. The second segment was called the invocation work area (IWA) segment. The primary function of the IWA segment was to hold the call/return stack the process used.

This original process model served the types of applications written for the System/38 and early AS/400 very efficiently. However, the move to more block-structured languages and the desire to incorporate applications written to standards, as POSIX demonstrates, led to the development of the ILE process model.