Abstract:
A system and method for scheduling and managing computer applications is provided. In one embodiment, an event processor dispatches messages to run a job to an agent module residing on a local or remote node. The agent module, upon receiving the messages, spawns processes to run the job, returning status notifications of the running job to the event processor.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
   This application claims the benefit of U.S. Provisional Patent Application No. 60/486,589 entitled MODIFIED AUTO REMOTE AGENT FOR JOB SCHEDULING AND MANAGEMENT APPLICATIONS filed on Jul. 11, 2003, the entire disclosure of which is incorporated herein by reference. 

   TECHNICAL FIELD 
   This application relates generally to computer systems, and more particularly to scheduling and managing computer processes. 
   BACKGROUND 
   Remote agents running on remote machines typically require or depend on the database vendor client software on the remote nodes. Further dependence on a specific operating system service burdens many database system management procedures. Accordingly, an agent that does not depend on specific database vendor client software or specific operating systems to improve job scheduling and management application is desirable. 
   SUMMARY 
   System and method for automatic remote agent used for job scheduling and managing application processes are provided. In one aspect, the method includes receiving a message from an event processor to initiate a job on a node. The agent spawns a child process on the node to run the job. Upon completion of the job, whether successfully terminated or an error occurred, the child process exits. The agent receives the status associated with the job from the child process and sends the status, for example, so that a database of jobs can be updated. 
   The system in one aspect includes an event processor operable to retrieve one or more jobs from a database. The one or more jobs are scheduled to be run on a node whether remote or local. An agent module residing on the node receives the one or more jobs from the event processor. The agent module creates a child process to run the job on the node. The agent module receives status of the job from the child process. 
   Further features as well as the structure and operation of various embodiments are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is a block diagram illustrating the components of the present disclosure in one embodiment. 
       FIG. 2  is a block diagram illustrating the components of the present disclosure in detail in one embodiment. 
       FIG. 3  is a flow diagram illustrating the method of the present disclosure in one embodiment. 
   

   DETAILED DESCRIPTION 
   The present disclosure provides a modified remote agent such as the auto_remote used, for instance, with job scheduling and management applications such as the Unicenter AutoSys Job Management application.  FIG. 1  is a block diagram illustrating the components of the present disclosure in one embodiment. The modified remote agent of the present disclosure in one embodiment includes two processes, for example, ar 0   104  and arx  106 , that do not rely on operating system services such as the inet_d service, and that do not use database vendor client software on the node running the modified remote agent. Briefly, inet_d refers to a daemon program that listens for connection requests or messages for selected ports and starts server programs to perform the services associated with those ports. 
   In this embodiment, the ar 0  process  104  receives messages from the event processor  102 , forks an arx process  106  and passes an event processor message to the arx process  106 . The arx process  106  then forks and exec&#39;s the child fork into the client job  108  to be run on the remote node. The parent arx process  106  passes a running event notification to the ar 0  process  104  and the ar 0   104  passes that event directly back to the event processor  102 . The Event processor  102  may pass the results to a database system  110 . In another aspect, the ar 0  process  104  may directly communicate or pass the results to a database system  110 . In one embodiment, event processor  102 , ar 0 ,  104 , arx  106  and job  108  are thread processes. 
   When the client job  108  terminates, the arx  106  catches the exit code of the child process  108 , creates and passes a termination event to the ar 0  process  104  at which point the arx process  106  terminates and the ar 0   104  passes that termination event back to the event processor  102 . Ar 0   104  also then terminates. 
   In this ways, the event processor need not contact the operating system inet_d service to fork and exec the child fork into the pre-existing auto remote agent. Thus, an embodiment of the present disclosure removes the operating system service from this process and uses the ar 0  process instead. By not using inet_d, various security issues are alleviated. 
   The present application also handles events generated by the auto remote. The pre-existing auto remote would use the database vendor client software to gain a database connection and insert the running and termination events into the job scheduling and management application&#39;s database. Job scheduling and management applications access this information from the database. However, these raw events were unprocessed and needed to be extracted from the database for processing by the event processor. An embodiments of the present application utilize the arx  106  and ar 0   104  to pass the events directly to the event processor  102  for processing. The intermediate step has been bypassed. In the present application, there is no need to gain the database connection by the remote agent, and the intermediate insertion and retrieval into the database are not needed. 
   In one embodiment, the present application provides a remote agent that does not require the database vendor client software on the remote nodes. For example, Sybase™ and Oracle™ could be supported databases upon whose reliance the present application seeks to rid on the remote nodes. 
     FIG. 2  is a block diagram illustrating the components of the present disclosure in detail in one embodiment. Event processor  202  receives or retrieves events, for example, from a database server  208 . The event processor  202  dispatches the event to an event handler  210 , for example, using its dispatcher component  204 . The event handler  210  passes the event to an ar 0  process  212 . The ar 0   212 , in this embodiment, may act as an inetd proxy. Ar 0   212  may be started when a system starts. 
   Ar 0   212  then spawns an arx  214 , for example, using a fork system call. Arx  214  acks start_rem_job, acknowledging that it is running a job, and for instance, puts the running event into a database, for example, a job scheduling database table that holds events. The event handler  210  sends to the database  208 , marks, and processes STARTING event notification. The event handler  210  also sends encrypted jobs associated with the event to ar 0   212 . Ar 0   212  dispatches encrypted jobs to appropriate arx  214 . Arx  214  forks and executes the job  216 . Arx  214  sends RUNNING event to a recv events thread  206  of the event processor  202 . 
   Recv events thread  206  sends the same event to the dispatcher  204 , which sends the event to the event handler  210 . Event handler  210  marks, puts the RUNNING event in event table, and processes RUNNING, for example, prepares for submission to database. Then the event handler  210  acks ar 0   212 . Arx  214  catches signal, for example, SIGCLD, from the child process, arx job  216 , upon termination of the arx job  216 . Arx  214  then sends TERM event to recv events thread  206  of the event processor  202 . Arx  214  may send the TERM event to database  208  or a server process of the event processor  202 . 
   In one embodiment, arx  214  is an auto_remote which runs inetd-less and/or, database-less. 
     FIG. 3  is a flow diagram illustrating the method of the present disclosure in one embodiment. At  302 , ar 0  receives a message to start a job. The message, for example, may be from an event processor thread. Ar 0  may reside on a local or remote node from the thread that sent the message. At  304 , ar 0  forks a process and runs arx. Ar 0  also sends a running status message back to the message sender, for instance, an event processor thread. Optionally, the ar 0  may send a message to an event processor server or to a database that holds event state information. At  306 , arx executes a job associated with the message. When the job completes, ar 0  receives exit status of the job and sends the status to the thread that sent the message at  308 . 
   The system and method of the present disclosure may be implemented and run on a general-purpose computer. For example, the system and method may be implemented as set of computer instructions to be stored on computer memory units and executed on the computer processor. The embodiments described above are illustrative examples and it should not be construed that the present invention is limited to these particular embodiments. Thus, various changes and modifications may be effected by one skilled in the art without departing from the spirit or scope of the invention as defined in the appended claims.