WO1994014114A1

WO1994014114A1 - Interception system and method including user interface

Info

Publication number: WO1994014114A1
Application number: PCT/US1993/011506
Authority: WO
Inventors: Donald J. Kennedy
Original assignee: Overlord, Inc.
Priority date: 1992-12-07
Filing date: 1993-11-29
Publication date: 1994-06-23
Also published as: AU5680894A; CA2103297A1; JPH08506912A; EP0679271A1; EP0679271A4; CN1091842A

Abstract

A method of intercepting pre-existing computer instructions in order to modify and/or enhance pre-existing program units (30) and supply user entry points determines, in one or more embodiments, if a reference can be found in a program unit (30). If so located, the corresponding method provides user code entry points (steps 72, 78) before and after the intercepted instruction, perhaps in modified and/or enhanced form, is executed (step 76). Blocks of user supplied code can be provided at the entry points to enhance, upgrade, and/or expand upon the inctercepted instruction, thereby enhancing the pre-existing program unit (30).

Description

INTERCEPTION SYSTEM AND METHOD

INCLUDING USER INTERFACE

Field of the Invention

The invention relates to single and multiprocessor computer systems that supply system services to requesting program units running on or in such systems. More particularly, the invention relates to methods of enhancing or modifying the run-time operation of selected, pre-existing program units. Background of the Invention

Computer systems have, over a period of years, evolved from stand-alone individual processors to various forms of multi-processor systems. Many

computer systems use program units, sometimes referred to simply as "programs".

The program units contain computer

instructions which the computer system can execute in order to perform specific functions. These program units may have been created from other program units. However, in most cases, a human being was involved at some point in the creation of the set of computer instructions being executed.

Program units are intended to meet certain known or projected needs when implemented. However, most program units designed in the past or being

designed in the present will not conform to all future needs.

Prior art systems have approached the need to be flexible to deal with future needs in many ways. In many cases, prior approaches have not been cost

effective and/or do not allow the user many options on their implementation. The evolution and combination of new hardware systems, new operating systems, new program units, new system procedures, new data structures, or new user interfaces may require that the original program units be modified, recompiled, or worse, abandoned due to compatibility and/or cost related problems. Some of the prior art approaches require extensive training on both the use and implementation of these methods. Some users may not be able to afford the time, money, and human resources to implement the prior art approaches.

This need for flexibility in updating or modifying existing programs is especially apparent in multi-processor distributed systems. Several different types of problems have provided the impetus to the drive toward multi-processor systems.

One impetus has been a desire to share

information more effectively among diverse users. An approach to this problem has been to couple a variety of processors, which may or may not be the same, together via a local area network. Such networks enable many different individuals and their associated processors to have access to common information and to have access to one another.

Yet another impetus toward multi-processor environments has been a desire to create highly reliable computer systems out of less reliable components. Such systems are typically used in environments such as banking, transaction processing, or inventory control, wherein reliability is of paramount importance.

One such family of computer systems is

marketed by Tandem of Cupertino, California. Tandem systems can be implemented in stand-alone, multiple processor configurations, or as multiple interconnected nodes. Each node corresponds to one or more multiple processor systems. Where major program systems, which might include dozens of program units, to support multiple remote transaction terminals or inventory control functions are installed and running on a production basis in a multiple processor environment, the above- noted problem of updating and maintaining program units becomes very difficult and expensive to solve. For example, a new operating system might be adopted by the hardware vendor. In such an instance, the system operator might have to install the new operating system to receive continuing support and operating system maintenance.

If the change in operating systems is not transparent to the existing program systems, they may need to be modified or recompiled. This process is not only expensive and time consuming, but in a multi- program, multi-processor environment can result in errors which could cause catastrophic results.

In addition, where the software had been obtained from a third party vendor, the user might not have the source code or documentation necessary to make modifications, expansions, or recompilations. Worse yet, the third party vendor will, in all likelihood, not continue to support or provide new releases to the user.

Thus, there continues to be a need to be able to safely upgrade or modify existing programs in a cost effective fashion as the requirements or the environment change. Preferably, this need could be met by system operating personnel without a need to return to the original software vendor or to modify the original provided program units.

In addition, in a multiple processor system, the operating environment is continuously changing. As a result, the mix of resources, available processors, and the like, available each time a program unit or a process is initiated, will be different, depending on what other program units or processes are active at any given time.

Thus, there is continuous problem of resource allocation and management which must be addressed in such systems. One known approach, marketed by the assignee of the present application under the name of "Automatic Network Balancing System" for Tandem

computers, provides resource allocation services and resource management in such environments based on predetermined and fixed allocation methods.

In the known automatic network balancing system, the performance factors which are taken into account to select the best or most appropriate processor to which a process is to be allocated, include

availability or busy state of a given processor, available memory, swap rate, dispatch rate, memory queue length, jobs that are available on the ready list, as well a number of others. The various performance factors are evaluated using a weighing system. The processor which appears to be most appropriate is then selected to run the process.

The known load balancing system has been very successful and can be used to substantially increase performance of Tandem-like systems. Nevertheless, the method of selecting the most appropriate processor to be allocated to carry out a given task does not take into account site or user needs for diversity or

customization between one installation and another.

Thus, there continues to be a need for a more flexible approach which can take into account variations from site to site. Preferably, such an approach could be implemented to allow site specific input to the processor selection process or to expand upon the services provided to a given process which is being executed. Preferably, the implementation will be transparent to the respective process.

Summary of the Invention

This invention is directed to an apparatus and a method of run-time interception of pre-existing computer instructions in program units in order to support user hooks or entry points which can be used to modify and/or enhance the originating and/or receiving program units, at the user's discretion. As a result, the program units can meet the user's present needs and allow modification by the users, on an as needed basis, to support the future needs. Using the present

invention, this can be accomplished without requiring the support and/or guidance and/or expertise of the original authors and/or inventors of the program units being intercepted or any additional physical,

electronics, or mechanical device.

The above result is achieved by intercepting system service calls which are made by executing program units at run time when the program units request that the operating system of the computer system provide a service on their behalf. The interception can take place in the main program units, user library program units, system library program units, or a combination of the program units listed above.

The method also contemplates that the interception of the system service calls and user hooks or entry points would be placed in several types of program units. This gives the users many options as to where the interceptions of the system service calls will take place. Further, it allows the user to implement the invention on a program unit by program unit basis, if desired, or to implement the invention on a system by system basis. In accordance with one aspect of the

invention, an apparatus and a method are provided for altering or translating one or more steps of a preexisting method for carrying out a predetermined function. Site or user defined steps or functions can be incorporated into the process for customization or specialization.

The method can be used, for example, for allocating resources within a multiple processor

computer system. In other aspects of the invention, different types of functions can be implemented beyond those specified in the pre-existing method.

The method includes detecting a step which is a candidate for alteration. The alteration process could include carrying out a different function from that which the step initially requested, or for

translating or expanding upon the step.

A determination is made if a previously defined, user supplied, pre-alteration set of steps is to be executed before carrying out one or more

predetermined altering or translating steps. In

response to this determining step, the group of site or user supplied pre-alteration or pre-translation steps is executed as indicated.

The method then includes executing the one or more predefined altering or translating steps. Such steps could include, in accordance with one aspect of the invention, determining which of a plurality of available resources is to be used to carry out the requested step which is the candidate for alteration.

Alternately, the predefined altering steps could provide enhanced functions not called for in the original candidate steps. Such enhanced functions may have become desirable, so long as they can be provided so as to be transparent to the original candidate step or steps.

The method then makes a determination as to whether or not there are one or more post-alteration, site or user supplied steps. These steps can then be executed as indicated after executing the set of

altering steps.

In accordance with yet another aspect of the invention, the method can be used for the purpose of allocating resources within a multiple node, multiple processor system. Each of the nodes can include one or more computer processors. The nodes can be physically displaced from one another, and can be coupled together via communication lines.

This aspect includes the steps of:

carrying out a sequence of steps in a predetermined process;

detecting a step in the sequence which is to be carried out and which is a candidate for translation;

intercepting the detected step and determining if a previously defined, user supplied, pre-translation set of steps exists;

interrupting the sequence and executing the user supplied pre-translation set of steps as indicated;

translating the candidate step into a predetermined sequence of one or more predetermined translated steps;

subsequent to the translation step, determining if a previously defined, user supplied, post-translation set of steps exists;

executing the user supplied, post-translation set of steps as indicated; and

returning to the sequence of steps immediately after the detected step, thereby continuing the process. In yet another aspect of the invention, the method can be used for the purpose of resource

allocation for the purpose of not only optimizing processing throughput, but also for the purpose of creating redundant databases automatically in spaced apart locations for purposes of other functions, such as disaster recovery, for instance.

These and other aspects and attributes of the present invention will be discussed subsequently with reference to the following drawings and accompanying specification.

Brief Description Of The Drawing

Figure 1 is a schematic diagram of a multiple node, multiple processor network;

Figure 2 is a schematic diagram of an environment in which a program unit might be executed;

Figure 3 is a flow diagram of a method in accordance with the present invention; and

Figure 4 is a flow diagram of an alternate method in accordance with the present invention.

Detailed Description of the Preferred Embodiment

While this invention is susceptible of

embodiment in many different forms, there is shown in the drawing, and will be described herein in detail, specific embodiments thereof with the understanding that the present disclosure is to be considered as an

exemplification of the principles of the invention and is not intended to limit the invention to the specific embodiments illustrated.

The present method makes it possible for a program user or a system operator to update and modify pre-existing programs without requiring the recompiling of the source codes of the respective program unit(s). This is accomplished by intercepting selected calls or references to procedures, program units, or variables that can be external or internal to a pre-existing executing program unit. One type of interceptable instruction is an operating system service call.

On interception, the operating system will look for the called procedure in a library linked to the executing program unit, if such exists. In the absence of a program related library, or in the absence of a match with the called procedure in the executing program unit, the operating system will then attempt to find the called procedure or program unit in its system library.

Where a match is found in either the program library or the system library, that procedure or program unit is then executed. If there is no match, an

indication of a run-time error should be returned to the calling program unit.

The present method makes available "user hooks" in the respective library procedures or program units. The phrase "user hooks" as used herein refers to intentionally created entry points or steps wherein a user or system operator can insert one or more computer instructions (blocks of code) for the purpose of

transparently updating or modifying the executing program unit. Hence, the user has greater control over its computer system(s) and is able to make modifications or enhancements outside of the executing program unit. This avoids any need to modify or recompile that program unit.

Another advantage of the present method is that it can be used where the program library is

incorporated into the program unit itself. The user hooks provide a way for a user or operator to create a bridge between various versions or releases of software packages, as well as program units. Figure 1 illustrates schematically a multiple processor computer network 10. The network 10 includes a plurality of nodes 12 through 18.

Each of the nodes 12 through 18 can include one or more computer systems. Representative examples include Tandem-type multiple processor computer systems which might include up to 16 processor modules.

It will be understood that a node, such as node 12, could be implemented as a stand-alone, single processor computer system. Neither the number of processors, nor the architecture thereof, nor the presence or absence of communication links are a

limitation of the present invention. The present invention can be advantageously practiced in conjunction with a single, stand-alone system.

Each of the nodes 12 through 18 can communicate with at least one other node via

communication channels, such as the channels 20a through 20e. The network 10 can be geographically disbursed with the nodes 12 through 18 coupled, at least in part, via long distance communication links or other

communications methods.

Figure 2 illustrates schematically a program unit 30 which is to be executed on a processor 32. As is conventional, the program unit 30 communicates with the processor 32 via an operating system 34. The operating system 34 provides a variety of services to the executing program unit.

The program unit 30 and operating system 34 would normally be stored in one or more storage devices or units of the processor 32. The details of such storage and the process wherein the operating system 34 initiates executing of the program unit 30 on the processor 32 are known and are not a limitation of the present invention. As has long been recognized, one aspect of an operating system is to enhance the efficiency of

utilization of the processor 32 as well as to improve the speed and ease of creation of programs such as the program unit 30. In this regard, the operating system 34 provides a variety of predefined commands, so-called "System Service Calls" (SSC), which carry out certain predefined functions when requested by a calling program unit.

Representative system service calls include a command to carry out a "read" function. A "read" request, based on supplied parameters, could request a read from a disk drive or other types of magnetic storage, or could request a read from a terminal or other devices.

Alternately, the operating system might support a system service call, such as a "write" to a storage unit or a device. A "write" request could send data or programs to communication lines, printers, or the like. A more extensive list of system service calls of a type supported by Tandem's GUARDIAN Operating

System is attached hereto as Exhibit A.

In accordance with the present invention, there is interposed between the program unit 30 and the operating system 34 a functional layer 36 which includes the "user hooks" or entry points. At these points, an operator, a user, or a site can expand upon or modify external references or calls intercepted by the

operating system.

Once an instruction has been intercepted, a first user hook is then checked or executed. This entry point can include an initial block of user or operator supplied code. This initial or "prior" block is to be executed before any modification and/or enhancement of the function which is the subject of the intercepted instruction is carried out.

The intercepted call or service request may then be executed as required. This execution, as described below, can be modified and/or enhanced, or expanded upon in a predetermined fashion.

Then, a second user hook or entry point may be checked or executed to determine whether or not there is any post-translation, user, or site specific code which is to be executed. If so, that code is executed.

Finally, appropriate parameters and/or data may be returned to the program unit 30 which had previously made the service request or call.

In accordance with the present invention, the interception process is carried out in one embodiment using a hierarchy that is very often imposed by the operating system between program library calls and system library calls. As a first step in carrying out the call or the functional request, if a program library 30a is associated with the program unit 30, the

operating system 34 checks the program library 30a first to determine if the intercepted external reference or call is present in the program library.

By providing counterparts in the library 30a to some or all of the system service calls or functions of the operating system 34 before the operating system intercepts requests for such services from the program unit, the corresponding procedure in the program (not the system) library will be executed. This provides a vehicle to modify or expand such requests in a predetermined fashion.

Hence, by associating with the program library structure 30a, a plurality of modified operating system calls, when the program 30 executes a particular service call, service can be provided in accordance with that request. In addition, on a substantially transparent basis to the executing program unit, the service can be enhanced and/or modified, or completely changed in a predetermined fashion. If and when the appropriate parameters and/or data are then returned to the program unit 30, that program can then continue executing subsequent instructions.

It will be understood that the library 30a is not required to practice the present method. An

equivalent structure can be implemented in the operating system 34 as discussed subsequently or in the program unit 30 itself.

Example 1 illustrates the process.

Subsequently referred to line numbers are listed along the left-hand margin of Example 1.

In Example 1, a read operation present in the program unit 30 could be intercepted and/or modified or translated on a substantially transparent basis in the interface layer 36. Line 40 of Example 1, defines the procedure to be executed as a "read" function with n parameters associated therewith.

The read process begins in a line 42. Line 44 represents a first user hook or entry point. A call is made to a procedure which includes one or more

previously specified site specific or operator specific instructions which are not normally part of the "read" procedure. Subsequent to the execution of the procedure of line 44, the actual "read" procedure can be carried out as indicated schematically in line 46.

It should be noted that the actual read procedure which could be carried out could be a read procedure which is expanded and/or substantially

different from the originally contemplated and specified read procedure in the calling program unit 30. Thus, a bridging function can be provided, if necessary, between different program versions and/or releases.

40 PROC READ (1, 2 n)

42 BEGIN

44 CALL PRIOR (1, 2 .... n)

46 JUMP TO READ FUNCTION VIA 0/S LOGICAL ADDRESS 48 CALL POST (1, 2 n)

50 END

PROC PRIOR (1, 2 n)

BEGIN USER INSTRUCTIONS CAN BE

INSERTED AT THIS POINT IF DESIRED

END

PROC POST (1, 2 .... n)

BEGIN USER INSTRUCTIONS CAN BE

INSERTED AT THIS POINT IF DESIRED

END

EXAMPLE 1

Line 48 is a second user hook or entry point. A procedure is called which includes one or more site specific or operator specific instructions which may be carried out after the read function is carried out. The end of the procedure is indicated in line 50.

It will be understood that the location, number, or function of the user hooks are not a

limitation of the present invention. In addition, the present invention contemplates the use of multi-levels of entry points, such as in the program unit, the program library, or the system library.

Upon a return from the read procedure of

Example 1 to the program unit 30, that program will continue execution which can be based on returned parameters or data, if any, which resulted from the read procedure initiated therein. Hence, information

actually supplied to the program unit 30 could come from a completely different location and/or source than that originally contemplated by the program unit 30 and this change could be completely transparent thereto.

Figure 3 illustrates a flow diagram of an embodiment of the method of the present invention. The process of Figure 3 will be explained below in

combination with the text of Example 1. In the

embodiment of Figure 3, the program library 30a has been previously linked to the program unit 30 and is

available at run time. Using the above-noted hierarchal approach, the operating system 34 checks the library 30a first when the program unit 30 calls an external

function or service, or tries to initiate execution of an external procedure.

The library 30a has been previously loaded with procedures corresponding to at least some of the external references for the program 30. The names of some of the previously loaded library procedures must be the same as the names of system service calls that are to be expanded upon and/or modified. (Usually, this is regarded as an error to be carefully avoided!)

In addition, it is necessary to be able to acquire, usually via the operating system, the logical address (es) of the respective system service call(s) in the operating system's library to be intercepted. The respective library procedure requires this information to be able to call that service function without using the name thereof.

For instance, in Example 1, a "read" system service call is to be intercepted and/or modified. The program library, as a result, includes a PROC READ. In line 46, to call the actual read in the operating system library, a: JUMP TO LOGICAL ADDRESS OF SSC READ must be executed to prevent PROC READ from calling itself.

Referring to Figure 3, the execution of the program unit 30 has been previously initiated. Step 62 represents execution of the program unit 30 until an external request of some sort is made or until the program unit 30 is completed, at which point it

terminates in a step 64.

In the event that the program unit 30 makes an external request, such as a request for a "read" or "write" for example, the operating system 34, in step 68, first checks the program library 30a, if any, to determine whether or not this function or procedure is found therein. If the called function, procedure, or external reference is located by the operating system 34 in the library 30a, for example, the "read" procedure of Example 1, that procedure is initiated.

In a step 72, the first user hook or entry point is encountered. This corresponds to the call at line 44 of Example 1. If there exists operator or site specific procedures and/or code, such steps should be executed. This corresponds to carrying out the

procedure of line 44 of Example 1.

In a step 76, the system service call or other function, called by program unit 30, is carried out, corresponding to carrying out the "read" function of line 46 of Example 1. The executed procedure from the operating system that is executed may be different from that contemplated by the creator of the program unit 30.

In a step 78, the second or "post" user hook or entry point is encountered. This corresponds to carrying out the procedure of line 48 of Example 1.

Then, there is a return to execution of the program unit 30 in a step 80. While executing user hook

instructions, alternate return paths, such as step 80a or step 80b could be provided by the user.

In this example, if the called procedure or service request is not found in the library 30a, and if it is in the system library, then, in a step 70, the requested service or procedure is carried out, perhaps in combination with other services of the operating system 34. Any necessary parameters and/or data are returned to the program unit 30 which continues

executing in step 62a.

As can be observed from the process of Figure 3, as a result of the site specific user supplied pre- translation and/or pre-modification steps, the first user hook, such as the process 44, along with the post- translation or post-modification steps, such as the process 48, it is relatively easy for an operator and/or a user to provide extensions, translations, and/or modifications to the original function being requested by the program unit 30. These are all outside of the program unit 30 and are substantially transparent to it.

Figure 4 illustrates an alternate embodiment of the present invention. In the embodiment of Figure 4, the program unit 30 need not have a library 30a associated therewith.

However, the names of the procedures or system service calls in the operating system library have been previously altered to distinguish them from the called procedure or "system service call" to be intercepted. With this change, the actual operating system call, under the new name, can subsequently be made. One of these procedures could correspond to the "open"

procedure. Renaming pertinent system service routines in the system library, such as "open to "sopen", as illustrated in Figure 4, step 34b, can be done when the operating system is compiled and linked together. In addition, corresponding procedures, as illustrated in Figure 4, step 72a, must be loaded into the system library with the original names of the system service calls to be intercepted.

If the respective system library procedures of the operating system had been previously modified and expanded upon as described above, it would be possible to carry out a corresponding user specified "prior" procedure as identified on line 44 of Example 1 in step 72a, analogous to the step 72 previously discussed.

After executing corresponding and/or similar system service calls in step 76a, the user defined instructions represented by the "post" procedure of Example 1 can be executed in a plurality of steps 78a. Subsequently, the operating system 34 returns appropriate parameters and/or data, if any, to the program unit 30, which then continues executing in a step 62a.

Using the previously described method, either the embodiment of Figure 3 or that of Figure 4, makes it possible for a user and/or operator to upgrade,

maintain, and/or modify program units, such as the unit 30, to deal with both a changing environment and also changing functional requirements, now and in the future. It is also possible to modify and/or upgrade system service calls so as to provide substantially different and/or enhanced functions not previously available to the corresponding program units, such as the program unit 30, as well as operating system 34.

The above-described instruction interceptions are carried out at run-time, and are substantially transparent to the executing program unit. Source code for the program unit is not required to practice the present method.

By making the "user hooks" or entry points available, as described above, both before and after executing the corresponding system service calls, for example, users and/or operators will be able to more effectively manage, maintain, and upgrade their program units in a very cost effective fashion. Further, because the present method is substantially external to the respective program unit, there should be no impact to third party vendor or maintenance relationships.

Additional representative examples of ways in which the methods of Figures 3 and/or 4 could be used include improved resource allocation in a multi-processor environment by including provision for user specific and/or operator specific modification to resource allocation routines. Redundant write operations can be provided when carrying out the write function to provide multiple, substantially transparent, sets of data which can be used for verification, disaster recovery functions or the like.

Thus, in accordance with the present invention a user interface is provided to, on a substantially

transparent basis, modify requests made by an executing program unit for a variety of purposes. This modification process takes place substantially outside of the program unit. It can be substantially outside of the associated operating system but can be readily modified by the operator and/or the user for purposes of customization.

The present invention has been discussed in terms of translating and/or modifying instructions at run time in a program unit, such as the exemplary program unit 30. It will be understood that the present methods can be used with any type of program unit, such as an application, a utility, or the like. Hence, the present method could also be used to translate and/or modify instructions in programs that may be routinely thought of as part of the operating system.

It will also be understood that the embodiments of Figures 3 and/or 4 could be combined. In addition, it is also within the spirit and scope of the present invention to alternately merge some of the procedures of the program library with the associated main program unit.

Example 2 is a further illustration of the method hereof in source code form.

From the foregoing, it will be observed that numerous variations and modifications may be effected without departing from the spirit and scope of the

invention. It is to be understood that no limitation with respect to the specific apparatus illustrated herein is intended or should be inferred. It is, of course, intended to cover by the appended claims all such modifications as fall within the scope of the claims.

EXHIBIT A

PARTIAL LIST OF TANDEM'S GUARDIAN

OPERATING SYSTEM CALLS

(WITHOUT PARAMETERS)

ALTER

ALTER PRIORITY APS DATA GETPARAM

CONTROL

CREATE

DEFINEADO

DEFINEINFO MEASURINFO

NEWPROCESS

OPEN FILE

PRINTINFO

PRINTREAD READ

WRITE

Claims

WHAT IS CLAIMED IS:

1. An apparatus for translating one or more steps of a pre-existing method for carrying out a predetermined function, wherein user defined steps can be incorporated therein, comprising:

circuitry for detecting a step from the pre-existing method which is a candidate for a

translation; and

circuitry for determining if a previously defined, user supplied, pre-translation set of steps is to be executed before executing any predetermined translation steps, and in response to the determining steps, executing the set of pre-translation steps where indicated.

2. An apparatus according to claim 1 further including means for determining if a previously defined, user supplied, post-translation set of steps is to be executed after executing any predetermined translation steps, and in response thereto, executing the post steps where indicated.

3. A process of translating one or more steps of a pre-existing method for carrying out a predetermined function, wherein user defined steps can be incorporated therein, in accordance with the

apparatus of claim 1, comprising:

detecting a step from the pre-existing method which is a candidate for a translation; and

determining if a previously defined, user supplied, pre-translation set of steps is to be executed before executing any predetermined translation steps, and in response to the determining step, executing the set of pre-translation steps where indicated.

4. The process of claim 3 further including the step of:

determining if a previously defined, user supplied, post-translation set of steps is to be

executed after executing any predetermined translation steps, and in response thereto, executing the post steps where indicated.

5. A method of executing a predefined set of steps, including altering one or more of the steps in a predetermined fashion wherein user defined steps can be incorporated therein, in accordance with the apparatus of claim 1, comprising:

detecting a step which is a candidate for alteration;

executing the altering steps; and

determining if a previously defined, user supplied, post-alteration set of steps is to be executed after executing the set of post-alteration steps where indicated.

6. The method of claim 5 further including, after the detecting step, the step of:

determining if a previously defined, user supplied, pre-alteration set of steps is to be executed before executing any predetermined altering steps, and in response to the determining step, executing the set of pre-alteration steps where indicated.

7. A method of intercepting and modifying pre-existing instructions at run time in a computer program being executed in an apparatus as in claim 1, comprising:

intercepting a selected instruction and determining if it is a candidate for modification; determining if an alterable, previously defined, pre-modification set of instructions is to be executed, and in response thereto, executing the pre- modification set of instructions, if any; and

modifying or executing the intercepted

instruction.

8. The method of claim 7 further including the step of:

determining if an alterable, previously defined, post-modification set of instructions is to be executed, and in response thereto, executing the post- modification set of instructions, if any.

9. A method of allocating resources within a multiple node, multiple processor system, wherein at least some of the nodes are spaced apart and are

interconnected by communication links, wherein one or more of the processors includes an apparatus as in claim 1, the method comprising:

carrying out a sequence of steps in a predetermined process in. a selected processor at one of the nodes;

detecting a step in the sequence which is to be carried out and which is a candidate for run-time modification;

intercepting the detected step and evaluating if a previously defined, operator supplied, pre- modification set of steps exists;

interrupting the sequence and executing the operator supplied pre-modification set of steps as indicated;

modifying the candidate step using a predetermined sequence of one or more predetermined modifier steps; subsequent to the modifying step, evaluating if a previously defined, operator supplied, post- modification set of steps exists;

executing the operator supplied, post- modification set of steps as indicated; and

returning to the sequence of steps immediately after the detected step, thereby continuing the process.