HPlogo Process Management Programmer's Guide: 900 Series HP 3000 Computer Systems > Chapter 1 Processes and Process Management

Organization of Processes

» 

Technical documentation

Complete book in PDF
» Feedback

 » Table of Contents

The MPE family of operating systems is process-oriented in that the operating system deals almost exclusively with processes. Because MPE/iX 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/iX is a directed rooted tree structure whose nodes correspond to processes. 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/iX and the ancestor of all other processes created on MPE/iX).

System Processes

PROGEN, the Progenitor, is the first process created during the initialization phase of MPE/iX. 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/iX, 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/iX, 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/iX operating system.

The Command Interpreter Process

The CI is a process that provides you with interactive access to the MPE/iX operating system. A CI (or the Root CI) is created for each session logged on to MPE/iX. 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.

Figure 1-1 Example 1-1. Attempting to Create Multiple Child Process from Your CI


   : 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/iX enables you to improve the performance of your program when you use system intrinsics that take advantage of MPE/iX 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.

Feedback to webmaster