WO2000029949A2

WO2000029949A2 - Enhanced virtual executor

Info

Publication number: WO2000029949A2
Application number: PCT/US1999/027154
Authority: WO
Inventors: Jeffrey A. Becker
Original assignee: Johns Hopkins University
Current assignee: Johns Hopkins University
Priority date: 1998-11-18
Filing date: 1999-11-17
Publication date: 2000-05-25
Anticipated expiration: 2001-05-18
Also published as: WO2000029949A3; AU1728900A

Abstract

An Enhanced Virtual Executor for remotely running command-line driven programs simultaneously on multiple computers operating on a network as a distributed processing system. One computer is programed as the program operator and one or more computers are programed as servers which run executable program parts as part of the distributed processing system. When operating as a server, a computer is remotely controlled by the program operator computer running the control routines of the Enhanced Virtual Executor using a script file.

Description

TITLE ENHANCED VIRTUAL EXECUTOR

BACKGROUND OF THE INVENTION

FIELD OF THE INVENTION This invention relates to an Enhanced Virtual Executor (EVE) apparatus and method for remotely running command-line driven programs simultaneously on multiple computers as a distributed Client/Server network program.

DISCUSSION OF THE RELATED ART In recent years, distributed processing systems incorporating a plurality of CPUs with individual local memories have performed distributed parallel processing without using shared memory as contrasted to multiprocessor systems.

In a relatively early example of such a distributed processing system, programs are distributed to and stored in individual processors which execute their portion of a sequence of processing steps. The program is initiated when each processor receives all of the data necessary to execute its share of the program. The system is capable of achieving a sequence of processing steps, but no central control of the overall system is provided for collecting the operational history whereby irregularities may be traced and corrected.

Problems inherent in the early approaches to parallel execution of an application program using a plurality of computers have been partially eliminated by systems which require a programmer to consider conditions such as the number and location of processors, the type or amount of data to be allocated to each processor, and the type of calculations executed in each processor. The programmer writes a program considering all of these varied conditions. When the program is executed on a distributed parallel processing system, an executable module is required on each of the plurality of processors and required data communication between processors must be designated by the programmer. An execution-time library for implementation of the executable modules and the communication of required data must be prepared prior to running the application, creating a large overhead.

Another prior art method for parallel execution of an application program requires a programmer to use a parallel description language for the distributed processing system to describe the program. The described program executes executable modules generated by the language processing system in the distributed processing system. The programmer must designate the system configuration such as: number of processors, the distributed processing system for parallel processing of the application program, and the distributed arrangements of data upon execution. Methods such as these require a table for scheduling but the information in the table can be only determined upon execution. Thus execution-time library processing is complicated and not easily used.

In a more contemporary distributed processing system such as presented in U.S. Patent No. 5,625,832 for "Distributed Processing Control Method and Distributed Processing System" issued to G. Ohsawa et al., communications overhead is reduced. That goal is achieve by using a table in each processor of a distributed processing system for controlling data processing and transfer. This eliminates central control and any possibility of the processors in the network operating on an interrupt basis whereby they function only during time periods when they are not normally used for a primary intended purpose other than as part of a distributed processing system.

U.S. Patent No. 5,506,962 for "Distributed Processing System and Method for Job Execution Using a Plurality of Processors and Including Identification of Replicated Data" issued to M. Orimo et al. is another example of a contemporary system which does not use a primary processor to control the overall functioning of the execution of a distributed process. Because control in the system is not perform by a primary processor, there is no possibility for the processors to run on an interrupt bases whereby they may be temporarily removed from distributed processing tasks to be reinstated at a later time.

SUMMARY OF THE INVENTION

The present invention is an Enhanced Virtual Executor (EVE) for remotely running command-line driven programs simultaneously on multiple networked computers. EVE is a distributed Client/Server network program wherein one or more computers are programed as EVE Servers, which when in the EVE mode, are controlled by a single computer, i.e. EVE Client. The EVE Client controls the process using a script file. The script file provides the command-line to execute the program, specifies the output files to copy, and lists the files required to execute the program. The EVE Client sends all of the files required to execute a program to an EVE Server and then sends a command to the EVE Server instructing it to execute the program. When the program has finished executing, the EVE Client copies the output from the EVE Server and directs the EVE Server to delete all of the transferred and generated files. If additional programs are to be run, the EVE Client continues to find any available EVE Servers on the network and starts executing a next program group on the next available EVE Server until it is finished with the controlling script.

To be available for use as a Server in the EVE system, a computer must be running the EVE Server program. Once the EVE Server program is installed, it runs in the background and does not require user interaction at the Server computer. However, the operator of a computer which has the EVE Server program can interrupt the Server program to stop the EVE Client from sending any programs for execution. A scheduler is available to allow each EVE Server to set interrupt time periods. If the EVE Server program is started when the computer is started, it will always be running but can easily be scheduled to be interrupted during the normal work hours of the person to whom the computer is assigned. The EVE Server program has a security option that allows the user to select which EVE Clients can access the Server. The screen of the EVE Client computer contains information regarding the status of each of the EVE Server computers and a log of messages that are sent to and from each of the EVE Servers. The EVE Server computer screen includes a log of messages sent to and from the EVE Client. These features allow optimum use of computers on the network by using them to run programs during non-peak hours and weekends.

OBJECTIVES OF THE INVENTION

A primary objective of the invention is to provide an apparatus and method for running command-line-driven programs on multiple computers located on the same network or system of networks by simultaneously distributing computational processes over the computers via the network and controlling the processes by an Enhanced Virtual Executor (EVE).

It is a primary purpose of the present invention to provide a distributed processing system incorporating a control processor and a plurality of server processors for accomplishing executable parts of a distributed program wherein each server processor may be scheduled internally as to its availability, time and date wise, to function as part of a distributed system.

Another objective is to provide a means for a single computer to execute a program with the aid of one or more computers on the same network or system of networks.

A still further objective of the invention is to provide a means for stopping a program from executing on one computer functioning as part of a distributed computational system and continuing on another computer within the system.

Another objective of the present invention is to provide a distributed processing system wherein programs are always run on the highest "rated" computer available. A further objective of the invention is to provide a distributed processing system for a network of computers wherein network/Server problems are easily identified and corrected.

An objective of the present invention is to provide a distributed processing system for a network of computers wherein interaction or intervention is not required by operators at Server stations.

A further objective of the invention is to provide an Enhanced Virtual Executor for a distributed processing system which provides a means for monitoring the status of all Server computer stations.

A further objective of the invention is to provide an Enhanced Virtual Executor for a distributed processing system of computers on a common network which is based on a Windows operating system.

A still further objective of the invention is to provide an Enhanced Virtual Executor for a distributed processing system of computers on a common network which is based on a UNIX operating system.

Another objective of the invention is to provide an enhanced virtual executor for a distributed processing system of computers on a common network which incorporates an integral scheduler.

These objectives, together with other objectives and advantages which will be subsequently apparent, reside in the details of the apparatus, method and operation as more fully described and claimed hereinafter, reference being had to the accompanying drawings forming a part hereof, wherein like reference designators refer to like parts throughout.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 depicts a network of personal computers interconnected on a network and functioning as an Enhanced Virtual Executor according to the present invention.

Figure 2 is a logic flow diagram depicting the initiation of the EVE Client program, i.e. the control program.

Figure 3 is a logic flow diagram depicting the scan routine performed by the EVE Client program on start-up.

Figure 4 is a logic flow diagram depicting the main execute loop of the EVE Client program.

Figure 5 is a logic flow diagram depicting the "start run" routine on an EVE Server.

Figure 6 is a logic flow diagram illustrating the routine for moving a "RUN" to a different EVE Server.

Figure 7 depicts a logic flow used to check for results from an EVE Server.

Figure 8 is a logic flow diagram of the EVE Server "command check" routine.

Figure 9 is the logic flow diagram depicting the processes accomplished in response to the "LOGIN" command at any EVE Server.

Figures 10A and B represent the logic flow diagram of the "EXECUTE" command as performed by an EVE Server.

Figure 11 is a logic flow diagram illustrating the functions performed in response to the "RUNNING" command. Figure 12 is a logic flow diagram illustrating the functions performed in response to the "DER." command.

Figure 13 is a logic flow diagram illustrating the functions performed in response to the "SENDFE E" command.

Figure 14 is a logic flow diagram illustrating the functions performed in response to the "GETFILE" the command.

Figure 15 depicts the logic functions performed during any EVE Server data input.

Figure 16 is a logic flow diagram illustrating the functions performed in response to the "CANCEL" command.

Figure 17 is a logic flow diagram illustrating the functions performed in response to the "CLEANUP" command.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The Enhanced Virtual Executor (EVE) is a software program that provides the capability to run command-line-driven computer programs remotely and simultaneously on multiple computers via a network such as illustrated by Figure 1. The EVE system distributes computational processes over many computers and thereby significantly reduces the time required to perform large analyses.

Each computer that is to be used as an element of the EVE system requires an installed operating system such as Windows 95/98, Windows NT 4.0, UNIX or variants of Windows or UNIX and must have a network card with a suitable protocol loaded. The following presentation of the invention assumes the Enhanced Virtual Executor is running in a Windows environment as part of a TCP/IP protocol local area network to simplify the discussion. This is not to be considered limiting, the executor can be run on any computer using any operating system on any network.

The Enhanced Virtual Executor is comprised of two main elements, a Client, which is the master control program and a Server, which is the slave control program on each computer in the system and which receives primary directions from the Client. EVE Servers are run on multiple computers that passively listen for a connection from an EVE Client. The EVE Client then connects to all of the available EVE Servers to control the scheduling for the distributed computing tasks. The entire process is controlled by the EVE Client and requires no user interaction from the EVE Servers. It begins when the EVE Client is activated, see Figure 2. The Client loads a list of Servers which then wait for a command.

To load a list of Servers, the Client loops through each potential Server as illustrated by the logic depicted in figure 3. As the Client loops through each Server, it sends a "RUNNING" command to the Server. If the Server is available, the Client sends a "LOGIN" command to the Server. If the login is okay, the Server is enabled and initialize. If the login fails, the server is disabled and the Server is not added to the list of available Servers at the Client. If the Server was not available to receive the "RUNNING" command or the Server was disabled or enabled and initialize, the Client performs a similar loop through the next computer on the network. When all available computers on the network have been interrogated, a list of available Servers is loaded in the Client.

In this manner, multiple EVE Servers run on multiple computers, while one EVE

Client runs on a single computer controlling the process. The EVE Client sends all off the files required to run a program to one or more of the Servers identified by the list of Servers loaded in Figure 1. The Client then tells the EVE Server(s) to execute the program. When the program has finished running, the EVE Client copies the output from the EVE Server(s) and directs the EVE Server(s) to delete all of the unneeded files. The EVE Client continues to find any available EVE Servers and starts executing the next program group on each of them until it is finished with its script. This process is summarized by the logic diagram of Figure 4.

In Figure 4 the main execute loop for the EVE Client program is presented with designators indicating the interactive sub-routines which are illustrated in more detail in Figures 5 through 7. For instance, at the "Start Execute Loop" the control program steps to "Get Next Run" and then scans for Servers if instructed by the user of the Client, or if a predetermined time has elapsed. If the decision is made to scan for Servers, the routine logically presented by Figure 3 is run. If the system elects not to scan for Servers or at the completion of the scan for Servers routine, the EVE Client program checks the results of the scan for EVE Servers according to Figure 3 as illustrated in the check for results logic flow diagram of Figure 7. If the results are not ready, the program returns in the scan for Servers routine. If the results are ready, a determination is made as to whether or not the program finished running. If the program has not finished running, a unique temporary output path is established. If the program has finished running, a default output path is set. When an output path is set, the "DIR" command is sent to the EVE Server and the "GETFILE" command is used to retrieve the files from the EVE Server. The EVE Client program then sends the "CLEANUP" command to the EVE Server, resets network and run data and saves the results to a log file, after saving the results, it returns to the main program loop of Figure 4.

If the EVE Client is ready to perform a next run, it locates the next available EVE Server. If it is not ready for the next run, it makes a determination as to whether or not it is waiting for results. If it is not waiting for results, the program advances to the "EVE Client disconnect from all Servers" as illustrated in Figure 4. If the EVE Client program is waiting for results, it advances is to the "check for moving run to a different Server" routine of Figure 6. In performing this routine, a determination is made of the status of the runs remaining. If all remaining runs are not running on a Server, the program returns to the main execute loop. If the remaining runs are running on Servers, the EVE Client program checks the EVE Servers list to find the available Server with the highest rating. It next finds the Server with the lowest rating that is running a resumable Run. It then makes a determination as to whether or not to send a current run to an available Server. If the determination is negative, the program returns to the primary loop. If an election is made to send the run to a Server, the "CANCEL" command is sent to the Server running at the lowest rate and the program returns to the primary main execute loop of the EVE Client program.

Upon returning to the main execute loop of Figure 4, the program gets the next run by returning to "Next Run Ready?". If the next run is ready, the program gets the next Server. A determination is made as to whether or not the next Server is ready. If it is not ready, the program cycles to check for results from the EVE Servers routine of Figure 7 and proceeds as previously discussed. At the completion of that routine, the EVE Client program scans the network for EVE Servers according to the routine illustrated by Figure 3. At the completion of the Figure 3 routine, the system returns to "Next Server Ready?" of Figure 4. If a next Server is ready, the EVE Client program main execute loop starts the run on a selected EVE Server according to the logic routine depicted in Figure 5.

When a run is started on any EVE Server, the EVE Client program proceeds according to the logic illustrated in Figure 5. A determination is made as to the validity of the data. If the data is invalid, the system returns to the main execute loop. If the data is valid, a determination is made as to whether or not the network is connected. If the network is not connected, the program returns to the main execute loop of the EVE Client program. If the network is connected, the Client sends a "CLEANUP" command to the Server. The EVE Client program then makes the determination as to whether or not the Server returned an indication of a valid CPU. If it failed to indicate a valid CPU, the program resets run and Server selection data and returns to the main execute loop. If a valid CPU was detected, the EVE Client program determines if the run is a carry over from a previous Server. If it is, the temporary path files are copied to the EVE Server using the "SENDFILE" command. After a "SENDFILE" command, the integrity of the copied files is checked. If the run is not from a previous Server, the files from the default path are copied to the EVE Server using the "SENDFELE" command. Once a "SENDFILE" command has been sent, a determination is made as to whether or not the files have been properly copied. If files are okay, the run and

J O- Server data selection is reset and the system returns to the main execute loop. If files were copied properly, an "EXECUTE" command is sent to the Server and the system returns to the EVE Client program main execute loop of Figure 4.

Upon returning to the main execute loop of Figure 4, the program proceeds to the check results routine of Figure 7. Upon completion of that routine, the main execute loop makes the determination as to whether or not more runs are to be accomplished. If no more runs are required, the EVE Client is disconnected from the EVE Servers. If additional runs are required, the program cycles back to "Get Next Run" at the top of Figure 4. To be used by a Client, EVE Server programs must be running on one or more computers. Running an EVE Server does not require any user interaction at the Server after it has been installed. The EVE Server is run by the EVE Client which uses a script file to provide the command-line to execute the program, the output files to copy, and all the files required to run the program. A script file includes data and instructions according to the following format:

EVE Client script file format (Default.eve) [#] optional comment

group 1 group 2

group N

There must be at least one blank line between each group, and no blank line within a group.

group X

[*][?] command-line output file(s) file 1 file 2

file N * - Resumable EVE flag is supported by the executable [optional]

? - Done EVE flag is supported by the executable [optional] command-line - the command-line to execute on the EVE Server output File(s) - output file(s) to copy from the EVE Server separated by semicolons (wild cards * and ? may be used) file X src dest src -name of the source file to copy (relative paths will start at the XFER subdirectory under the EVE Client program) dest - name of the destination file to copy (paths will always be relative to the ROOT subdirectory under the EVE Server program)

Note: The files (file 1-N) are all of the files required to run the command-line, which may include executable Files.

The EVE Client also requires a Server list file named IPAddr.ini, containing the IP addresses or computer names of all possible EVE Servers. A Server list file includes data according to the following format:

EVE Sever List Format (IPAddr.ini) [#] optional comment server I server 2

server N

server X ipaddr/name description [enabled] [rating]

ipaddr/name - ip address or computer name of a server description - description to display in the Client main screen (must be in quotes) enabled set the default state of the server (1 = enabled, 0 = disabled) [optional] rating user defined rating for the server (higher rated servers are used first) [optional]

The Enhanced Virtual Executor can take advantage of multiple processors on an EVE

Server, i.e. if the Server program is on a multiple processor computer, a different run is sent to each available processor as if it were a different Server. An EVE Server can set the maximum number of its processors that are to be shared. The default number is the same as the number of processors in the computer. To take advantage of a multiprocessor computer by running the processors in parallel, the computer must use an operating system which supports multiple processors.

Each EVE Server has a user-defined rating that the Client uses to determine where to send runs. The Client sends a run to the first available processor with the highest rating to ensure the fastest possible execution time. This selection is made using the logic illustrated in Figure 6.

An executable routine supports the EVE stop flag to allow interaction with the EVE Client program. The EVE Client program creates an EVE.stop.flg file in the EVE Server destination directory to notify the application running on the EVE Server that it should stop executing. To support the stop flag, an application checks for the existence of an EVE stop, fig file, if it finds the file, it exits.

In addition to the stop flag, the EVE Client program supports a done flag. The EVE Server checks for an EVE_done.flg file in the EVE Server destination directory to verify that the application terminated properly. If an application supports this flag, the EVE Client is assured that the program executed properly and did not terminated due to a problem such as insufficient memory. To support the done flag, an application creates an

EVE_done.flg when it is terminated under normal conditions (including when it stopped by the stop flag). To take full advantage of the Enhanced Virtual Executor, an application should be able to stop executing, save its current settings and be capable of resuming from where it stopped executing. This allows runs that are stopped by the scheduler to be finished on another Server. The EVE Client program checks to determine if a run is resumable, and if a Server with a higher rating is available, it will stop the run and send it to the Server with the higher rating as provided in Figure 6.

In a typical EVE Client monitor screen, when the Enhanced Virtual Executor is being run as a windows application, the top of the screen contains listings of the status of the Servers. This upper section of the display area includes a name column for each EVE Server, a status column indicating its status (executing, not connected, etc.), and columns for the number of CPUs in the Server computer, number of connects and the speed rating. The bottom of the image area contains a log of messages that are sent to and from each of the EVE Servers. The status list can be sorted by any column by clicking on the column heading and reversed by clicking on the column heading again.

The name and rating column information is read in from the IPAddr.ini file (see the EVE Sever List Format). The Status column displays the status of each Server. The CPU column shows many processors are being used out of the total number of available processors. The Connect column displays the number of times the Client has connected to that Server. A large number of connections to a Server is a sign of a bad network connection, or a problem with running an executable program on that Server.

To load an EVE script file, the user at the EVE Client computer advances to the Run Manager screen in a windows or equivalent environment and clicks on the Import button. Multiple EVE script files can be imported, and they can be imported while EVE is executing runs. The Run Manager screen is used to show the status of each run. It can be used to disable a run to prevent it from being sent to a Server. The Run Manager checks for the existence of the files to be copied to the Server and notifies the user of any missing files. If the Enhanced Virtual Executor is being run in a non-windows environment, the forgoing housekeeping chores are preformed by equivalent routines. The Run Manager list contains six columns, each of which can be sorted by clicking on the column heading, and reversed by clicking on the column heading again. The columns comprising this list are: 1) The Name column, it contains the number of the run as it was imported. 2) The Status column, it displays the status of that run. 3) The Computer column, it shows the name of the last Server that the run was sent to with the processor number in parentheses. 4) The Start and 5) End columns, which indicate the time the run started executing and stopped executing on the current Server. 6) The Time column, it contains the total cumulative times the run was executing on all Servers used to process that run.

By double clicking on a run or right clicking on a run and selecting Properties, the user can view the details of an individual run on the Run Details screen. This screen shows the run number, resumable support, support for the Done flag, the command line, the output files to copy from the Server, and the files to copy to the Server.

Computers which contain the software to enable them to function as the EVE Servers have a small icon in the system tray. Clicking on this icon brings out the EVE Server screen. This screen is normally hidden, but when brought up it displays a log of messages that were sent to and from the EVE Client.

The EVE Server has three categories of options that include General, Schedule,and

Security. The General options are used to run the EVE Server every time the computer is started. Another option allows the user to add a Shortcut to the EVE Server program on their computer's desktop. A third option is used to save a log file called EVE_SRV.log to help track problems that may occur. The EVE Server saves the previous log file to EVE SRV.lol that will prevent loosing important information if the Server is restarted after having a problem. Both log files can be downloaded by an EVE Client to help in diagnosing problems. The last General option sets the maximum number of CPUs that the EVE Server will use from its compliment of CPUs. The default number is the same as the number of processors in the computer. This number can be reduced to allow other processes to run simultaneously without interfering with the Enhanced Virtual Executor, thus allowing a person to run programs on a computer simultaneously with an EVE application.

In addition to the preceding, the operator of an EVE Server has the ability to select schedule and security options. The Schedule options are used to determine when to stop the EVE Client from sending programs for execution. If a program recognizes the EVE stop flag, the program will stop executing at the scheduled time. If the program is resumable, it will be resumed on another Server, otherwise the partial results will be copied back to the Client. If run when a computer starts, the EVE Server will always be running and can be scheduled to be paused during work hours.

The Security options are used to configure which EVE Clients are allowed to connect to the EVE Server. The default is to allow any EVE Client to connect, but a user can define a restricted list of Clients that are allowed to connect.

Once the EVE Server program is loaded on a computer and the appropriate protocols assigned, the unit is ready to assume an operational status within the EVE system. The EVE Server program runs in the background until contacted by the EVE Client. When this occurs, the EVE Server command check routine of Figure 8 begins.

When an input command from the EVE Client is received, it initiates the routine of Figure 9. The Server options are check and if it is determined that the Server is available, access is allowed. If access is not allowed, the EVE Server sends a

"NOT OK" response to the EVE Client. If access is allowed but the Server is busy, it sends a "NOT OK" responds to the EVE client. If a Server is not busy, a determination is made as to whether or not it is still running an old executable routine. If it is, a "NOT OK" response is sent to the EVE Client. If it is not running and old executable routine, it determines if an old version of the Client is trying to connect. If an old Client is trying to connect, a "NOT OK" responses sent to the EVE Client. If an old Client is not connecting, a new connection is created and an "OK" response is sent to the EVE Client and the routine of Figure 8 steps from login to "execute". If the logic of Figure 9 resulted in an "OK" command, execution begins according to the logic illustrated in Figures 10A and B. The execute program routine starts and it is immediately queried to determine if it was properly started. If it wasn't, and error message is sent to the EVE Client. If it was properly started and an execute loop is running, an "OK" responses sent to the EVE Client. If the execute loop is not running, the execute loop is started and an "OK" response is sent to the EVE Client. When the "OK" response is sent to the EVE Client, the execute loop begins looping through each CPU as illustrated in Figure 10B.

The loop through each CPU begins with a determination as to the status of the program. If a program complete indication is present, a determination is made as to whether or not the CPU is busy copying files. If it is, the validity of the network is determined. If the network is valid and a Server "exit" is detected, the EVE Server exits the program. If a Server "exit" is not detected, the question of whether or not the CPU is busy copying files is repeated. If the CPU is not busy copying files, a "results are ready" message is sent to the EVE Client and the loop steps on to determine it the network connection is valid. If the network connection is not valid as determined in this step or any preceding such step in this routine, a stop program execution occurs and the network connection is reset. When the network connection is reset, loop execution advances by determining if the Server used an exit option. However, if the network connection was considered valid and a cancellation command was received from the Client, a stop program execution is effected. If it was determined that the Server did not command and exit and a program is still running, the loop is repeated. If the program is not still running, the execute loop is exited.

The "RUNNING" command, Figure 11, is periodically called by the Client to check the status of the Server. The Server then responds with a list of CPUs that are currently executing programs.

If the "DIR" command is present in Figure 8, a file path and pattern are obtained and an error check is made in Figure 12. If there are no errors, the results are sent to the EVE Client. If there is an error, the files, excluding EVE flag files, are counted and the file names are saved and sent to the EVE Client. If the "DER." command is not present, Figure 8 advances to the "SENDFILE" step.

The "SENDFILE" command is initiated, as shown in Figure 13, by determining if the data connection is busy. If it is, an error message is sent to the EVE Client. If it is not, an existing target directory is sought. If an existing target directory cannot be found, an error message is sent to the EVE Client. If a target directory exists, the "data to receive file" is initialize and the file length is determined. If the file length is 0, a "send OK message" is sent to the EVE Client. If the file length is not 0, a message is sent to the EVE Client to start sending file data.

If the "SENDFILE" is not initiated, Figure 8 advances to "GETFILE" and the EVE Server proceeds according to the logic illustrated in Figure 14. If a file does not exist, and error message is sent to the EVE Client. If a file exists, the system is initialize to receive the file. File length is determined and if it is 0, a send OK message is sent to the EVE Client. If the file length is not 0, a message is sent to the EVE Client requesting data transfer.

Data transfer between the EVE Client and Server is accomplished according to Figure 15. If the "Data from EVE Client" is not initiated, the length of file is again checked. If the file length equals 0, the program returns to the "GETFILE" step of Figure 8. If the file length does not equals 0, a determination is made as to the number of data blocks to send, this information is sent and the program returns to the beginning of the data transfer with EVE Client routine. When the "Get Data from EVE Client" is initiated, "Get Data" begins. If a file has not been opened, a new file is open. If a file was opened or when a new file is opened, the data is saved to the open file. If the file is not copied, the "data transfer with EVE Client" is reinitiated. When the file is copied, a completion message is transmitted to the EVE Client.

When the "GETFILE" routine is not successful, the EVE Server advances to the "CANCEL" step of Figure 8 and then progresses to the routines of Figure 16. If the CPU is canceled, the global cancel flag is set and a send OK message is transmitted to the EVE

Claims

Client. If the CPU has not been canceled and is running, the program is stop from executing. If the CPU is not running or the stop executing command has been initiated, the system checks to see if data is being sent to the CPU. If it is, the CPU information is reset. If it isn't or after the CPU information is reset, a send OK message is transmitted to the EVE Client.

If the "CANCEL" routine is not initiated in Figure 8, the program moves on to the "CLEANUP" step. If "CLEANUP" is not initiated, the operations recycle to the input command from the EVE Client. If "CLEANUP" is initiated, a determination is made as to whether or not a new program is being started. If a new program is not being started, all files are deleted, the CPU information is reset and an OK message is sent to the EVE Client as indicated in Figure 17. If a new program is being started, the system is checked the determining if any CPU is waiting to start. If a CPU is waiting to start, and error messages sent to the EVE Client. If there are no CPUs waiting to start, a check is made to determine if any CPUs are waiting to finish. If a CPU is waiting to finish, and error message is sent to the EVE Client. If no CPU is waiting to finish, a check is made to determine if all CPUs are being used. If they are, and error messages sent to the EVE Client. If they are not, a search is made to find an available CPU. If an available CPU is not found, an error message is sent to the EVE Client. If a CPU is found, all files are deleted and a send OK message is transmitted to the Client.

The foregoing is considered as illustrative only of the principles of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction shown and described, and accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope of the invention and the appended claims and their equivalents.

What is claimed is: Claim 1. A method for operating a distributed processing system by way of an enhanced virtual executor, including the steps of: installing a master control program on a first computer on a network; converting at least a second computer on said network into a server by installing a server program thereon which is responsive to said master control program; by a control means at said second computer, designating times when a processor of said second computer will be available to function as part of said distributed processing system; identifying said servers on said network; determining the availability of CPUs in said servers for running distributed programs; maintaining a list in said first computer of said servers and available CPUs; downloading executable program parts to be run on said distributed processing system from said first computer onto at least one of said servers having one of said available CPUs; and executing said program parts.

Claim 2. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 1 , including the additional steps of: determining the speed of said CPUs in said servers; and directing said downloading of executable program parts to said available CPUs with the fastest runtime.

Claim 3. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 1, including the additional steps of: determining the priority rating of said servers; and directing said downloading of executable program parts to said available servers with the highest priority rating.

Claim 4. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 2, including the additional steps of: interrupting said execution of program parts in a first of said servers which is no longer available for distributed processing and transferring said program parts and the execution thereof to an available second one of said servers.

Claim 5. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 4, including the additional steps of: storing data created by said interrupted execution of said program parts in said first computer first server; and resuming execution of said interrupted program parts in said first server when said first server becomes available before said interrupted program parts are run by said second server.

Claim 6. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 3, including the additional steps of: interrupting said execution of program parts in a first of said servers which is no longer available for distributed processing and transferring said program parts and the execution thereof to an available second one of said servers.

Claim 7. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 6, including the additional steps of: storing data created by said interrupted execution of said program parts in said first computer first server; and resuming execution of said interrupted program parts in said first server when said first server becomes available before said interrupted program parts are run by said second server.

Claim 8. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 2, including the additional steps of: interrupting said execution of program parts in a first of said servers and transferring said program parts and the execution thereof to one of said servers having a CPU with a faster runtime.

Claim 9. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 3, including the additional steps of: interrupting said execution of program parts in a first of said servers and transferring said program parts and the execution thereof to one of said servers having a CPU with a higher priority rating.

Claim 10. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 4, including the additional steps of: after said program parts have been executed, storing the data created by executing said program parts within the memory of said server which executed said program parts; downloading said stored data into said first computer; and deleting unnecessary data relative to said distributed program from said server after it completes downloading said stored data to said first computer.

Claim 11. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 6, including the additional steps of: after said program parts have been executed, storing the data created by executing said program parts within the memory of said server which executed said program parts; downloading said stored data into said first computer; and deleting unnecessary data relative to said distributed program from said server after it completes downloading said stored data to said first computer.

Claim 12 .A distributed processing system, comprising: a plurality of computers, each running on an operating system; a network for interconnecting said plurality of computers; a first one of said computers including an enhanced virtual executor program; a server comprised of a second one of said computers with a server program installed thereon which is responsive to said enhanced virtual executor program; means at said server for designating times when a processor of said server will be available to function as part of said distributed processing system; means within said enhanced virtual executor program for enabling said first computer to identify said servers on said network; means for determining the availability of CPUs in said servers for running distributed programs; means for maintaining a data table in said first computer containing the identity of said servers and CPUs available therein; means for downloading executable program parts to be run on said distributed processing system from said first computer onto at least one of said servers having one of said available

CPUs; and means for executing said program parts.

Claim 13. A distributed processing system as defined by Claim 12, comprising: means for determining the speed of said CPUs in said servers; and means for directing said downloading of executable program parts to said available CPUs with the fastest runtime.

Claim 14. A distributed processing system as defined by Claim 12, comprising: means for determining the priority rating of said servers; and means for directing said downloading of executable program parts to said available server with the highest priority.

Claim 15. A distributed processing system as defined by Claim 13, comprising: means for interrupting the execution of program parts in a first of said servers and transferring said program parts and the execution thereof to a second one of said servers.

Claim 16. A distributed processing system as defined by Claim 13, comprising: means for interrupting the execution of program parts in a first of said servers and transferring said program parts and the execution thereof to one of said servers having a CPU with a faster runtime.

Claim 17. A distributed processing system as defined by Claim 14, comprising: means for interrupting the execution of program parts in a first of said servers and transferring said program parts and the execution thereof to one of said servers having a higher priority.

Claim 18. A distributed processing system as defined by Claim 12, wherein said operating system is selected from the group consisting of Windows, UNIX, LINEX, and Apple operating systems.

Claim 19. A method for operating a distributed processing system by way of an enhanced virtual executor, including the steps of: installing a master control program on a first computer on a network; converting at least a second computer on said network into a server by installing a server program thereon which is responsive to said master control program; by a control means at said second computer, designating times when a processor of said second computer will be available to function as part of said distributed processing system; identifying said servers on said network; determining the availability of CPUs in said servers for running distributed programs; maintaining a list in said first computer of said servers and available CPUs; downloading executable program parts to be run on said distributed processing system from said first computer onto at least one of said servers having one of said available

CPUs; determining the speed of said CPUs in said servers; determining the priority ratings of said servers; directing said downloading of executable program parts to said available servers with the fastest runtimes and highest priority ratings; interrupting said execution of program parts in a first of said servers which is no longer available for distributed processing and transferring said program parts and the execution thereof to an available second one of said servers; parts are run by said second server; executing said program parts; and storing data created by executing said program parts within said first computer.

Claim 20. A method for operating a distributed processing system by way of an enhanced virtual executor as defined by Claim 19, including the additional step of deleting unnecessary data relative to said distributed program from said server after it completes downloading said stored data to said first computer.