Guardian Programmer's Guide

Creating and Managing Processes
Guardian Programmer’s Guide — 421922-014
16 - 11
Relationship With Other Processes
You can set the process access ID equal to the owner ID of the object file instead of to
the process access ID of the creator process. Doing so gives the new process the
access permissions of the file owner instead of the creator. The owner of the object file
must set up this feature, however, either by using the FUP SECURE PROGID
command or programmatically by using a call to the SETMODE procedure.
An example of the use of this feature might be in setting up a password file. Each user
needs to have the ability to set a password, but the password file and the program file
containing the code that updates the password file would typically be owned by the
super ID user. By securing the program file with FUP SECURE PROGID, the super ID
user gives every user the ability to change a password.
Stop Mode
Normally, the user that can stop a process is the user that started the process (creator
access ID), the user’s group manager, or the super ID user. However, you can change
this stop mode in a program using the SETSTOP procedure to enforce various levels
of security against stopping your process.
Stop mode can be set to restrict the ability to stop your process to one of the following:
•
Any process on the system
•
A process with process access ID equal to that of the super ID user, the group
manager of the target process, or the target process itself
•
No process at all, except that your process can delete itself
Relationship With Other Processes
In many Guardian applications, the relationships among processes are critical to the
operation of the application. For a process to manage the processes it has created,
the creator process needs to be kept informed when one of its offspring is deleted.
Similarly, a process that manages a batch job needs to be kept informed about the
status of processes within the job.
So that process-deletion messages can be sent to the appropriate process, the system
keeps track of relationships between processes. The method the system uses to keep
track of these relationships depends on whether the process is named or unnamed
and on whether you have a single process or two processes running as a process pair.
Figure 16-2 shows the relationships between a process and named and unnamed
processes that the process has created.
Relationship With a Named Process
Figure 16-2 shows process $A creating two named processes: a single named process
$B and a named process pair $C.
Process $A is known as the ancestor of process $B. The relationship between $A
and $B is recorded in the destination control table (DCT). If $B is deleted, then the