02/08/84  Process Overseers

The process overseer is the last program called by the system when a
user's process starts up.  It has the responsibility of setting up
special features of the enviroment, if any, and finding and executing
a start_up exec_com.

There are two currently installed process overseers, process_overseer_
and project_start_up_.  The default is process_overseer_.


The process_overseer_ sets up a handler for the mme2 condition so that
debug breakpoints will result in debug being entered.  It then calls
command_query_ to allow the ".." escape by default in the process.  It
looks for a start_up.ec and, if it finds one, uses "exec_com
Start_upPath" as the initial command line, and calls the listener.


The project_start_up_ executes a project start_up in addition to the
user's start_up.  It establishes a condition handler that logs the
user out if any error happens during the exec_com, and sets the
working directory to the project directory.  It restores the working
directory after the project start up is finished, and then goes on
identically to process_overseer_.

If the project start_up (>udd>Project_id>project_start_up.ec) is not
found, the user's process is terminated.


Normally the process overseer is called by a support procedure called
an "init_admin" that sets up a conventional Multics user enviroment.
There are three init_admins: user_init_admin_, absentee_init_admin_,
and daemon_init_admin_ for interactive, absentee, and daemon processes
respectively.  A process overseer can also be called directly as the
first procedure in the user ring, in which case it is responsible for
setting up the entire user enviroment.  Such a procedure is called a
",direct" process overseer.


Project administrators of delegated projects can specify the process
overseer for their users in the PMF.  System administrators are
responsible for undelegated projects.  Users with the v_init_proc
attribute can specify their process overseer for a particular process
with the -po option to the login command.  They can provide an
alternate version for all of their processes by putting it in their
home directory, however it must have the same name as the overseer
specified in the PMF.  See the section entitled "Providing a private
process overseer" for more details.


Specifying process overseers in the PMF: A process overseer is
specified in the PMF with the initproc keyword.  The standard PMF of a
newly delegated project contains the statement:

   Initproc:  process_overseer_;

This causes the users in the project to get process_overseer_ for
their process overseer unless there is an initproc keyword in their
entry.  Thus to make project_start_up_ the default, change
"process_overseer_" to "project_start_up_" in the Initproc keyword.


To give a particular user a different process overseer than the one
specified by the Initproc keyword, set up that user's entry to look
like this:

   personid: JEHoover;
	   initproc: some_special_overseer_;
	   {any other keywords}


To specify that a process overseer is a ,direct overseer, append the
string ",direct" to the end of the name.  For example:

   Initproc: weird_enviroment_,direct;


Supplying a private process overseer: There are three ways to get an
unusual process overseer.  First, the -po option can be supplied to
the login command.  This is recommended for debugging.  For example:

   l Athos Musketeer -po >udd>M>Athos>new_po>richelieu_overseer_

The overseer is found by the normal search rules, so that the pathname
may be specified as a path relative to the homedir.  For example, the
example above could have been typed as:

   l Athos Musketeer -po new_po>richelieu_overseer_

To get a ,direct overseer, add ",direct" to the pathname. Example:

   l Richelieu Cardinal -po intrigue>espionage_overseer_,direct


The second technique is to put the overseer in the home directory.  It
must have the same name as the one specified in the PMF.  If you are
coding your own process overseer, you can add extra names to the
entrypoint and the to the segment itself, or you can just give it the
same name.  To use an existing overseer without changing it, create a
transfer vector.  In pl1 it might look like:

   process_overseer_: project_start_up_: proc (pit_ptr);

   dcl pit_ptr ptr;
   dcl different_overseer_ ext entry (ptr);

   call different_overseer_ (pit_ptr);
   return;
   end;


This would substutite different_overseer_ for either process_overseer_
or project_start_up_.  Of course, the names on the entrypoint will
depend on what you want to replace.  A transfer vector for a ,direct
overseer would be similiar but would lack the argument.


Writing a process overseer: The easiest way to write a special process
overseer is to copy one of the installed ones and modify it to taste.
To get a copy of process_overseer_.pl1 in your working directory,
execute the following command:

   library_fetch process_overseer_.pl1


For ,direct overseers the init_admin_'s are the logical models,
however the real work of these programs is done by a parallel set of
programs that they call: the real_init_admin's.  Thus to see how the
default interactive enviroment is set up, type:

   library_fetch (user_init_admin_.alm user_real_init_admin_.pl1)


Start_up exec coms: Most process overseers that put the user in
something like the normal enviroment execute a start_up exec com.  In
general, this exec_com is found by searching in three places: the
homedir, >udd>Project_id, and >sc1 (in that order) for a segment named
start_up.ec.



                                          -----------------------------------------------------------


Historical Background

This edition of the Multics software materials and documentation is provided and donated
to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. 
as a contribution to computer science knowledge.  
This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology,
Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL
and BULL HN Information Systems Inc. to the development of this operating system. 
Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970),
renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership
of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture 
for managing computer hardware properly and for executing programs. Many subsequent operating systems 
incorporated Multics principles.
Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., 
as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. .

                                          -----------------------------------------------------------

Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without
fee is hereby granted,provided that the below copyright notice and historical background appear in all copies
and that both the copyright notice and historical background and this permission notice appear in supporting
documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining
to distribution of the programs without specific prior written permission.
    Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc.
    Copyright 2006 by BULL HN Information Systems Inc.
    Copyright 2006 by Bull SAS
    All Rights Reserved