Organization of Processes [ Process Management Programmer's Guide ] MPE/iX 5.0 Documentation
Process Management Programmer's Guide
Organization of Processes
The MPE family of operating systems is process-oriented in that the
operating system deals almost exclusively with processes. Because MPE XL
provides a multiprogramming environment, many processes can share the CPU
and other system resources to maximize system utilization, thus
increasing system performance.
The organization of processes in MPE XL is a directed rooted tree
structure whose nodes correspond to processes (see Figure 1-3). An arrow
from one process P2 to another process (P3) means that P2, the parent
process, is the creator of P3, the child process. The parent/child
relationship between processes provides control from top to bottom
throughout the process structure. In most cases, the parent process is
responsible for what happens to a child process, including creation,
deletion, and other special actions.
A process may have the capability to create one or more child processes.
A process cannot exist without a parent process (the one exception being
PROGEN, the first process created by MPE XL and the ancestor of all other
processes created on MPE XL).
Figure 1-3. MPE XL Process Structure
System Processes
PROGEN, the Progenitor, is the first process created during the
initialization phase of MPE XL. PROGEN creates child processes from a set
of data specified at system configuration time. These child processes
are system processes that provide parallel functions on behalf of the
operating system. The system processes that perform operating system
functions can each have their own structure of descendants (children,
grandchildren, and so forth).
The SESSION and JOB Processes
In MPE XL, a session is associated with an interactive access to the
system, while a job is associated with a batch access. If PROGEN can be
considered to be the ancestor of all processes in MPE XL, then the system
process SESSION is the common ancestor of all interactive sessions in the
system. When you press a [[RETURN]] on an unowned terminal, a message is
sent to SESSION. SESSION directs a JSMAIN process to allocate and
initialize session resources for the new session. JSMAIN then creates
and activates a Command Interpreter (CI) process, commonly referred to as
the Root CI.
The system process JOB is the common ancestor of all jobs on the system.
An attempt to start a job results in a message being sent to JOB. JOB
directs a JSMAIN process to accomplish its task of establishing the
environment for running batch jobs in the MPE XL operating system.
The Command Interpreter Process
The CI is a process that provides you with interactive access to the MPE
XL operating system. A CI (or the Root CI) is created for each session
logged on to MPE XL. Your CI reads the commands you enter on the keyboard
as data, places the data on its stack, and acts upon the data
accordingly. For example, when you enter the following command:
:RUN EDITOR.PUB.SYS
you are directing your CI to create a child process to execute the code
found in the program file EDITOR.PUB.SYS. Your CI is suspended until it
is reactivated by the child process (when you exit EDITOR or enter BREAK
mode).
Your CI is limited to having one child process at a time. Following the
example given in Example 1-1 , if you are in EDITOR (the child process of
your Root CI) and press the BREAK key, EDITOR is suspended and your Root
CI is reactivated (indicated by the colon prompt appearing on your
terminal). If you try to create a second child process with the command
:RUN MYPROG.PUB.MYACCT, you are prompted with ABORT? (YES/NO) and must
direct your CI either to abort EDITOR or to ignore the command.
If you respond with NO to the ABORT? (YES/NO) prompt, your CI will ignore
your command to create a second process. If you respond YES with ABORT?
(YES/NO) prompt, your CI first deletes from the system the process
executing the EDITOR program, then the system proceeds to create the
process that executes MYPROG.
________________________________________________________________________
| |
| :RUN EDITOR.PUB.SYS |
| HP32201A.07.17 EDIT/3000 WED, SEP 24, 1987 12:55 PM|
| Æ HEWLETT-PACKARD CO. 1985 |
| \ [[BREAK]] |
| :RUN MYPROG.PUB.MYACCT |
| ABORT? (YES/NO) NO |
| COMMAND NOT ALLOWED IN BREAK. (CIWARN 986) |
| : RUN MYPROG.PUB.MYACCT |
| ABORT? (YES/NO) YES |
| |
| PROGRAM ABORTED PER USER REQUEST. (CIERR 989) |
| : RUN MYPROG.PUB.MYACCT |
| . |
| . |
| . |
________________________________________________________________________
As illustrated in Example 1-1, you are restricted to creating only one
child process at a time while in the CI. Processes that you create from
your Root CI are normally restricted from creating child processes
because of the great amount of system overhead required to manage each
process. If you take advantage of the special capability to create
multiple child processes, you must take great care that the benefits
gained by creating multiple processes to perform a set of tasks
(increased program performance and throughput) are not offset by the
liabilities caused by the additional processes contending for the CPU and
other system resources (decreased system performance and response time).
User Processes
MPE XL enables you to improve the performance of your program when you
use system intrinsics that take advantage of MPE XL process management
capabilities. You can develop a large and/or complex program that
creates multiple active processes to perform a set of tasks. The
concurrent accomplishment of tasks (versus serial accomplishment) can
greatly increase your program's performance and throughput.
MPE/iX 5.0 Documentation