A class is an OS/400 object containing parameters that specify the runtime environment. Some of these parameters relate to the allocation of processor resources to the job. For example, there may be a limit to the number of processes in a class that can be concurrently eligible for execution. This arrangement provides a means to control the amount of interference among processes that compete for the same system resources. This limit, which is usually called the activity level, is associated with a storage pool.

A storage pool, not to be confused with an auxiliary storage pool, is a means of reserving a certain amount of main memory for a subsystem. Logically, the storage pool should be called a memory pool; but remember that IBM doesn’t like to give human characteristics, such as memory, to its computers. Main memory can be divided into as many as 16 storage pools, one of which is always reserved for the machine. A storage pool is a quantity of memory from which the dynamic paging requirements of processes assigned to that storage pool are satisfied. For example, one storage pool could be defined for all interactive jobs and another for all batch jobs. This would ensure that a batch job could not steal a page frame from an interactive job and thus affect the response time for a particular interactive user. Batch jobs could steal pages only from other batch jobs in the batch storage pool. Storage pools are defined in the subsystem description.

The user of the system controls the pool sizes, the number of pools, and the activity levels. In this way, the system can be adjusted to achieve optimum performance for a given user workload. This adjustment can be made manually or automatically as the workload changes, through the use of various performance-tuning tools available on the AS/400.

Original and New Job Structures

The introduction of the ILE process model described in previous sections also changed the structure of a job in the AS/400. We can see the differences by looking at the application resources available for the original job structures and the new job structures, and by noting how these resources can be used. In general, the application resources for a job include shared files, commitment control, and storage.

For the original job structure,

•  Shared files are seen by all application programs in the job.

•  External names are shared at the job level, not at the application level within a job.

•  Commitment control is done for the entire job.

•  Only one activation of a program is allowed in the job.

•  Only one static storage area exists per job.

•  Only one automatic storage area (stack) is allowed per job.

•  Only one dynamic area exists for every language (no sharing).

For the new job structure, based on the ILE process model,

•  Shared files can be seen by all application programs in the job, or each application can define its own file usage.

•  External names are scoped to a single application, meaning each application in a job can have its own name space for externally defined variables.

•  Commitment control can be done on a job basis, or each application can have its own commitment control in effect.

•  Multiple activations of the same program are allowed with the job.

•  Each application has its own storage areas and each is protected.

-  static storage

-  automatic storage (stack)

-  dynamic storage (heap)

With the new job structure, each job, similar to each process, has two or more activations. Each of these activations has its own storage packaging and protection state.

Processes, Tasks, Jobs, Activation Groups, and Threads

The original AS/400 defined three levels of work, as we have just seen. A task is the lowest level below the MI. A process exists at the MI and is built on top of the tasking structure in the SLIC. OS/400 supports a job as a unit of work for the system and the job is built on the MI process model. Most other operating systems deal directly with a process. OS/400 does not. In this respect, a job in OS/400 is analogous to a process in some other operating systems.

The full-function job provides greater levels of resource sharing and security than does the process definition supported by some other operating systems; however, a full-function job takes a long time to create. Consequently, it is very appropriate to describe a job in the AS/400 as being a heavyweight.

Applications written specifically for the AS/400 usually conform to this full-function job structure. That is, AS/400 applications usually execute under a single job. The idea of dynamically creating lots and lots of jobs for a given application is not recommended, because the overhead required to create all of these jobs is extremely high. This, of course, is not how applications are written for some other operating systems.

Operating systems, such as Unix and Windows NT, define a structure where a process can quickly be created, used, and then destroyed. Applications written specifically for these operating systems typically tend to use lots and lots of processes. To achieve good performance with this type of application requires a fairly lightweight process, and this trend has led to a new definition of a process in the industry.

POSIX, for example, defines a process model that breaks a process into two separate components. The first component contains all the resources for a group of cooperating entities. The resources include the virtual memory, the communications ports, and the files that the operating system allocates to the process. Some operating systems even call this part of the process a task.

The second part of a process is the active execution environment, usually called a thread. A process can have one or more concurrently executing threads. The original definition limited a process to only one unit of execution. The newer definition allows multiple units of execution, the threads. A thread is a subprocess that has some of its own private resources as well as the shared resources of the process. Thus, a multithreaded process can have multiple units of execution sharing system resources.