Chapter 17: The Process

Part 1 defined the process as the basic unit of scheduling; a separate task which can be scheduled by OpenVMS, independently of other tasks.

This chapter will expand upon that definition, explaining some of the internal structure of a process. Later sections will explain how the virtual memory and scheduling mechanisms of OpenVMS act upon a process.

Expanded Definition of Process

Earlier in this book, a process was described as a separate task that could be executed by OpenVMS. This is true, but incomplete. Because many things can qualify as "tasks to be scheduled", the following paragraphs detail what a process actually is.

OpenVMS maintains a list of processes that exist at any given time. When you, a user, log in, a process is created for you. When you log out, it is destroyed. Each batch job executes as its own process, and many DECnet network operations execute as separate processes.

A CPU executes one process at a time. If your system has one CPU, only one process may actually be executing at a given time. This is probably the easiest way for a new user to envision a process. If you and user HOWARD are logged in at the same time, you each have a separate process. When HOWARD's process is executing, yours is not. When the CPU switches its attention from HOWARD's process to yours, it must take several steps: It must first save the state of HOWARD's process so that it may be resumed later. Then, it must select the next process to execute, perhaps yours. Finally, it must load your process, and begin executing it at exactly the point at which it stopped before. This sequence of events is known as a context switch: HOWARD's context is saved and yours is loaded. Context switches typically happen several times per second, giving the illusion that the CPU is executing HOWARD's work and your work at the same time.

A process has its own memory context. The concept of a memory context is essential to the idea of a process. One way to envision a context is to consider it to be a snapshot of the process, which can be saved while the CPU works on other things.

The concept of a process context includes more than just a snapshot of its structure, however. Under OpenVMS, each process has its own memory, separate from the memory of other processes, which cannot be directly accessed by another process. To clarify: The private memory space of one process is not merely protected from access by other processes; it conceptually does not exist from the viewpoint of the other process. This is one aspect that can help to drive home the idea of separate contexts.

Under OpenVMS, main memory starts at address zero. Each byte is numbered up to a maximum address (again using the 32-bit definition) of 4,294,967,296 (FFFFFFFF in hex format). This represents a range of 4GB that can be addressed in the context of a process (a given machine may have more or less than 4GB of physical memory—more on that topic is presented under "Virtual Memory").

OpenVMS constructs processes so that the first 2GB of each process's memory-addressing space is separate from that of all other processes. For example, two different processes can each access "memory address 1,000," but each refers to a separate place in physical memory. Process A has its own memory address 1,000, as does Process B. This memory location and the entire first 2GB of each processs's memory is effectively nonexistent in the context of any other process. OpenVMS arranges the allocation of physical memory so that each process can address its own 2GB of private memory.

Memory addresses 2,147,483,648 (80000000) through 4,294,967,296 (FFFFFFFF), though, are a different story. Those addresses are shared among all processes, so each process has 2GB of private virtual memory plus 2GB of memory shared by all processes. OpenVMS itself resides in the shared area, so that each process may use system routines from within its own context.

The two features just described represent the essence of a process; therefore, the ability to be scheduled for execution by a CPU combined with a unique memory context is a good working definition of a process.

A user may actually own several processes at once. An application may create a temporary child process (a subprocess) to perform some task, or a GUI application with several windows may create a separate subprocess to control each window. Alternatively, the user may issue a command that creates another process (e.g., SPAWN, RUN/DETACH, or SET HOST).

Batch jobs also execute in separate processes which themselves may create subprocesses. There are also detached processes, processes that may be semipermanent and are owned by no other process.

Use the DCL command SHOW SYSTEM to see a list of processes currently running on your system.