Method and system of process identification by user defined process variables6286025Abstract A method and system is provided for attaching user defined information to a process object in a data processing system. The method comprises creating a process control block corresponding to an invoked process. The control block has system defined process variables that are assigned values by the operating system. The method further comprises defining a user defined process variable in the process control block, and assigning a value to the user defined process variable. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
UID PID PPID STIME TTY TIME COMMAND
smith 1941 1 17:02:37 console 0:01 sh
smith 1990 1941 17:10:11 console 1:00 startdbm
smith 2001 1990 17:12:00 console 0:10 db_agent
smith 2005 1990 17:12:05 console 0:05 db_agent
smith 2007 1990 17:12:10 console 0:11 db_agent
As seen in Table 1, each process is assigned a user ID (UID) corresponding to the user originating the process. In this example, each of the five processes shown have a user ID of "smith". In the second column, each process invoked by the system is assigned a unique processor ID number (PID) that uniquely identifies that process. The Parent Process ID (PPID) indicates the process, by its process ID, which spawned that particular process. STIME indicates the start time of the process. The next three columns indicate the default display used by the process, the total processing time, and the initiating command for the process, respectively. As can be seen from Table 1, the only unique identifier for any particular process is its PID. Unfortunately, processor IDs are created at run time, making it difficult for the owner process (the process which corresponds to the process control block) and other processes to interact with the process control block and the owner process, and to manage their performance. This becomes particularly difficult in the case of operating system process service functions, such as process monitor, process management, process synchronization, and process communication, as explained herein above. Referring again to FIG. 2, when a process is invoked, in accordance with the present invention, operating system 110 creates a process control block in a process control memory location 140. For example, when process 120 is invoked, operating system 110 will create process control block 150. Likewise, operating system 110 will create process control block 160 when process 130 is invoked. Process control block 150 contains nine fields 161-169, as seen in FIG. 3A. For every process invoked, certain fields have been predefined to be specific system defined process variables, as is known in the art. For example, process control block 150 is automatically created with system defined process variables UID, PID, PPID, STIME, TTY, TIME, and COMMAND, which are entered in fields 161, 162, 163, 166, 167, 168, and 169, respectively. In addition, operating system 110 has assigned values to the system defined process variables (located below the corresponding variable as seen in control block 150), which are representative of owner process 120. According to a preferred embodiment of the present invention, two additional fields are included in the process control block that have not been defined with any process variables or corresponding assigned values. While fields 161-163 and 166-169 contain system defined process variables, the user definable fields 164 and 165 are never defined or assigned values by the operating system. When a user definable field is defined, it becomes a User Defined Process Variable. Although the preferred embodiment is described as having only these two user defined fields, it should be understood that the present invention may be practiced by providing any number of user definable process control block fields, for example, through a linked list of fields. When process 120 begins to execute, it will immediately access its corresponding process control block 150 to define and assign values for its User Defined Process Variables. Referring to FIG. 3B, it can be seen that process 120 has defined the process variable for field 164 to be "PROC_NAME", and has defined the process variable for field 165 to be "GROUP_NAME". Thus, as shown in the example of FIG. 3B, the User Defined Process Variable 164 has been defined by process 120 to be a "PROC_NAME" type variable. Further, "PROC_NAME" has been assigned a value of "shell-1" in field 164. The User Defined Process Variable "GROUP_NAME" has been assigned a value of "sys" in field 165. A User Defined Process Variable is defined by giving the variable a process variable name consisting of ASCII text, chosen by the application developer, that is used to identify a particular variable. The process also assigns a value to the User Defined Process Variable in the same field. The process variable value consists of any form of data. In a preferred embodiment, the process variables can only be created and written by the process control block's owner process, which is the process which the control block corresponds. However, it can be read by other processes. These process variables may either be hard-coded into the code of the process, or determined at run time based on input received directly from the user, either with or without being prompted to do so by the owner process. In other words, each User Defined Process Variable is not an environment variable to the operating system Instead, it is a variable that belongs to each process. A User Defined Process Variable is a process resource and a system defined process variable is a system wide resource. As an alternative example, consider process control block 160 in FIG. 3C. Here, process 130 has defined two User Defined Process Variables. A User Defined Process Variable named "READY" has been assigned a value of "False" in field 170. Process 130 has defined the User Defined Process Variable as "GROUP_NAME" in field 171, just as was done by process 120, and assigned the "GROUP_NAME" process variable a value of "dbm", which indicates that both process 130 and 120 belong to the same group. In an alternative preferred embodiment of the present invention, a second process defines and assigns the User Defined Process Variable in the process control block for an owner process. For example, this parent process may have spawned the child process, which is the owner process of the process variable. After the operating system has created a process control block corresponding to the child process, including defining and assigning values for the system defined process variables, the parent process is allowed to define and assign values for the User Defined Process Variables, which are then entered in the control block by the owner process. This allows the parent process to define and set process variables before the child process begins execution. In essence, the parent process becomes the user, with respect to the owner process. It should be understood that, although not desirable from a system management point of view, a parent process could be allowed to enter the variables into the control block directly, without assistance or permission from the owner process. As can be seen, the User Defined Process Variables enhance system management by acting as process attributes which may be referenced by the operating system. User Defined Process Variables are managed by the operating system and stored in the kernel memory of the computer system after the owner process has defined and assigned a value for each of the User Defined Process Variables. Following are examples of how the User Defined Process Variables of the present invention may be used to enhance and improve the operation of the operating system and the performance of various processes in a data processing system: Process Monitor Assuming that each process has defined and assigned values to the process variables "PROC_NAME" and "GROUP NAME", the process status of the operating system can be displayed as shown in Table 2:
TABLE 2
PROC.sub.-- GROUP.sub.--
UID PID PPID NAME NAME STIME TTY TIME
COMMAND
smith 1941 1 shell-1 sys 17:02:37 console 0:01
sh
smith 1990 1941 dbm-mon dbm 17:10:11 console 1:00
startdbm
smith 2001 1990 agent-1 dbm 17:12:00 console 0:10
db_agent
smith 2005 1990 agent-2 dbm 17:12:05 console 0:05
db_agent
smith 2007 1990 agent-3 dbm 17:12:10 console 0:11
db_agent
As seen in Table 2, each process has a unique user defined "PROC_NAME" value, even though each has the same user ID. This example assumes that the "db_agent" process has the capability of generating unique values for the "PROC_NAME" defined variable. This could be done by querying a user for a value, or otherwise generating a unique name as is known in the art. If the "PROC_NAME" were simply hard coded into the "db_agent" process, the "PROC_NAME" for each of processes 2001, 2005, and 2007 would be identical. For example, the command for showing the status of processes in the system can be modified to complement the present invention by displaying the process status of a particular process by specifying that processes' "PROC_NAME" value. For example, command: monproc uid=smith PROC_NAME=agent-1 the resulting output that will be displayed on a user's terminal as a result of this command will be: process status:
PROC.sub.-- GROUP.sub.--
UID PID PPID NAME NAME STIME TTY TIME
COMMAND
smith 2001 1990 agent-1 dbm 17:12:00 console 0:10
db_agent
As another example, the process status of a group of processes can be displayed by referencing the application group (GROUP_NAME) value in the following "monproc" command. command: monproc uid=smith GROUP_NAME=dbm This command will display all processes that have process attributes as defined in the "monproc" command line. So, specifically, each process having a user ID equal to "smith" and a "GROUP_NAME" equal to "dbm" will be displayed to the user as follows: process status:
PROC.sub.-- GROUP.sub.--
UID PID PPID NAME NAME STIME TTY TIME
COMMAND
smith 1990 1941 dbm-mon dbm 17:10:11 console 1:00
startdbm
smith 2001 1990 agent-1 dbm 17:12:00 console 0:10
db_agent
smith 2005 1990 agent-2 dbm 17:12:05 console 0:05
db_agent
smith 2007 1990 agent-3 dbm 17:12:10 console 0:11
db_agent
Modification of known process monitor applications or the creation of new applications to access the User Defined Process Variables in the process control block can easily be accomplished by those skilled in the art, and therefore, is not described in detail herein. Process Management By introducing a group process attribute, for example, by introducing a "GROUP_NAME" User Defined Process Variable, process management applications are much easier developed. For example, a group of application processes can be killed with one command or a single operating system service call. Without this process group concept, each process has to be identified individually by searching its process ID in the process status display. Then, each would be killed one by one. As can seen in the following example, the present invention substantially simplifies process management features, such as process termination. As an example, if a process named "killproc" is used as a process management tool to terminate processes currently executing in the system, a command to execute would specify attributes that identify processes to be terminated. For example, command: killproc uid=smith GROUP_NAME=dbm would execute "killproc", and kill all processes having a user ID equal to "smith" and that belong to the group "dbm". Another application of the "GROUP_NAME" process variable in process management is when a signal is to be broadcast to a group of processes. The present invention allows the signal to be broadcast to a group of processes using a single command, rather than having to broadcast individually to each process. For example, command: sigproc USERSIG1 uid=smith GROUP_NAME=dbm would execute a process named "sigproc" which would transmit a user defined signal "USERSIG1" to every process in the "dbm" group. Process Synchronization The User Defined Process Variables can be used as indicators to coordinate process activities. For example, the monitor process can define a process variable named "READY" and the other agent processes that are managed by the monitor process will wait until the value of the "READY" process variable reaches a "TRUE" state. For example, assuming that the process ID of the monitor process is "1992", the command, command: waitproc pid=1992 Ready=TRUE would execute a process named "waitproc" that would not allow the spawning process to continue executing until "ready" equals true in the monitor process. In this example, the monitor process has defined a User Defined Process Variable of "Ready", and first assigns this variable a value of "FALSE". Then, after some predetermined event, the monitor process will assign the "Ready" process variable a value of "TRUE". At that time, the spawning process will resume execution. Process Communication The User Defined Process Variables can be used to communicate information among processes. For example, one process, which has a process ID of 1992, can define a User Defined Process Variable named "COUNT" and the other processes can read the value of "COUNT" as that value is assigned by the owner process. The above examples can be implemented with system programming interfaces (SPI) so that they can be called from computer programs. For single user operating systems, such as OS/2.RTM., "UID" can be omitted in the above examples. An Application Programming Interface (API) is provided by the operating system to allow processes and users to utilize the User Defined Process Variables of the present invention. In a preferred embodiment of the present invention, the API is defined with C Programming Syntax, as is shown below, but it will be appreciated by those skilled in the art that the API can be programmed in the programmer's preferred programming language. The following four functions are provided by the API according to a preferred embodiment of the present invention: 1) Create Process Variables int Create_Proc Var(char * proc_var_name) where proc_var_name: the process variable name Only the owner process of the process variables can create process variables. Referring to FIG. 4, there is shown a flow diagram of the Create Process Variables API. The process begins at step 200, and proceeds to step 210, where the process control block is searched for a "free" or "empty" process variable field. If a free process variable field is found at step 220, the process proceeds to step 230, where the user or user process is allowed to define a user defined processor variable for the free process variable field found at step 220. If the field is successfully defined, a "return ok" is returned to the owner process, and the API ends. If no free process variable field is found at decision block 220, a "Return Error" is returned to the owner process at step 240, and the API ends. 2) Set Process Variable Values int Set_Proc_Var_Value(char * proc_var_name, char * proc_var_value) where proc_var_name: the process variable name proc_var_value: the process variable value Only the owner process of the process variables can set the values of their process variables. Referring to FIG. 5, there is shown a flow diagram of the API for setting, or assigning, process variable values. The process starts at step 300 and proceeds to step 310, where the process control block is searched for a particular defined process variable which matches "proc_var_name". If the process variable is found at decision block 320, the process proceeds to step 330, where the process variable "proc_var_value" is assigned to the process variable field found. At step 340 a "Return OK" status is returned to the owner process, and the API ends. If a field is not found at decision block 320, a "Return Error" is returned to the owner process, as shown at step 350, and the API ends. 3) Read Process Variable Values int Read_proc_Var_Value(int proc_id, char* proc_var_name, char * proc_var_value) where proc_id: the process ID. (note that if this API is called by the owner process variable, set proc_id=0) proc_var_name: the process variable name. proc_var_value: the return process variable value. Any process can read the process variable values of the other processes. Referring to FIG. 6, there is shown a flow diagram of the Read Process Variable Value API. The process begins at step 400 and proceeds to step 405, where a process control block is located by its processor ID. It, at decision block 410, no process ID is found having the requested process ID, a "Return Error" status message is returned to the owner process at step 415, and the API ends. If the process ID is located, a search is made of the process control block for a process variable having the name indicated by "proc_var_name", as shown at step 420. If the process variable is found, at step 425, the process variable value of that process variable is read, at step 430. Then, a "Return OK" status message is sent to the owner process, and the API ends. If no process variable is found at decision block 425, a "Return Error" is returned to the owner process, and the API ends. 4) Find Process Identification by Process Variables typedef struct proc_var_array( char * proc_var_name; char * Proc_var_value; ) proc_var_def; int Find_Proc_ID_By_Proc_Var(int proc_var_num, proc_var_def proc_var_array[], int * proc_num, int * proc_id_array[]) where proc_var_num: the number of process variables in the process variable array, proc_var_array. proc_num: the number of process IDs in the process ID array, proc_id array. proc_id_array: the process ID array returned in the process ID array, proc_id_array. proc_var_array: array of the process variable definition including name and value. The input process variable values are specified by the proc_var_array variable. The process IDs of those processes that have process variable values that match the input process variable values are returned in the proc_id_array variable. Any process can call this API. Referring to FIG. 7, a flow diagram of the Find Process Identification by Process Variables API is shown. The process begins at step 500 and proceeds to step 505, where each process control block in the operating system is read. If no control block is found, at step 510, the API ends. If a process control block is found, each process variable name is identified at step 515. If every process variable name matches the "proc_var_array", at step 520, the process proceeds to step 525. If the process variable name is not found, the process returns to step 505. At step 525, each process variable found has its value checked against "proc_var_value", as defined in "proc_var_array". If no value is matched, the process returns to step 505. If each value is matched, the process ID for the owner process of the process control block is recorded and returned to the initiator of the API in the "process ID array", at step 530. The process then returns to step 505. The computer programming required to create the operating system process service functions used as examples for implementing the present invention are well within the capability of those skilled in the art. In addition, the procedures for implementing the Application Programming Interface is simply accomplished by computer programming as will be appreciated by those skilled in the art. Although the API and examples were described using C Programming Syntax, it should be understood that analogous programming languages could be used to implement the present invention, and that analogous command lines and definitions could be used, as will be appreciated by those skilled in the art. In summary, the present invention provides an improvement to operating system processor functions by providing a User Defined Process Variable mechanism, whereby an application can attach information to a process object. User Defined Process Variables can be retrieved by the operating system and by other application programs, and can be applied in many process services, including process monitor, process management, process synchronization, and process communication. User Defined Process Variables are very easy to use for multiple process management services, they have a low overhead in the base operating system, and they provide flexibility to application developers that has been previously unavailable. While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||