CA1302578C - Device for managing software configurations in parallel in a network - Google Patents
Device for managing software configurations in parallel in a networkInfo
- Publication number
- CA1302578C CA1302578C CA000568569A CA568569A CA1302578C CA 1302578 C CA1302578 C CA 1302578C CA 000568569 A CA000568569 A CA 000568569A CA 568569 A CA568569 A CA 568569A CA 1302578 C CA1302578 C CA 1302578C
- Authority
- CA
- Canada
- Prior art keywords
- processors
- components
- processor
- compilation
- compiled
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
Abstract
DEVICE FOR MANAGING SOFTWARE CONFIGURATIONS
IN PARALLEL IN A NETWORK
Abstract of the Disclosure A software configuration management system that uses a network computing environment to build large software systems in parallel. A configuration manager assigns the compilation of buildable components of a software system to different processors in the network. Buildable components are assigned in order, according to dependencies between components, independent components taking precedence.
Processors are chosen according to the amount of idle time during a sampled time segment. A display provides processor compilation status messages for each compilation discrete from status messages of other compilations. A continuously updated overall status report of the system being built is simultaneously displayed with, but segregated from, the compilation status messages.
IN PARALLEL IN A NETWORK
Abstract of the Disclosure A software configuration management system that uses a network computing environment to build large software systems in parallel. A configuration manager assigns the compilation of buildable components of a software system to different processors in the network. Buildable components are assigned in order, according to dependencies between components, independent components taking precedence.
Processors are chosen according to the amount of idle time during a sampled time segment. A display provides processor compilation status messages for each compilation discrete from status messages of other compilations. A continuously updated overall status report of the system being built is simultaneously displayed with, but segregated from, the compilation status messages.
Description
DEVICE FOR MANAGING SOFTWARE CONFIG~RATIONS
IN PARALLEL IN A NETWORK
Background of the Invention Developments in computer hardware have steadily increased the share of computing resources availa~le to an individual user. In the beginning, computers were single user resources. Batch systems were then developed to take better advantage of the central processing unit (CPU). Next came time-sharing systems, which allowed large numbers of users to interact with a single CPU. More recently, systems in which each workstation has its own CPU have evolved from time-sharing systems to let users continue to share files without sharing a single CPU.
Current workstations have overcome the problems of distributed file systems with transparent network file systems that allow users to access both local and remote files in a uniform way.
Further development brought l~igh performance workstations, with bit map graphic displays, and high speed local area networks. Ini~ially, most workstations were used for computer aided design applications (i.e. CAD/CAM, MCAD, etc.). However, as t~e price of workstations fell and the amount of software increased, a new market wa~ created called Computer Aided Software Engineering (CASE). Various CASE tools have various software control and management capabilities. In one kind of CASE tool, components of a software system are individually ~l3~5~3 designed and the software system is constructe~ from its components. The larger the constructed system is, however, the longer is the amount of time required to build the system. Thus, the required build time greatly impairs productivity since the user must wait for the CASE tool, and for some systems he must wait overnight.
Summary of the Invention In the present invention, a collection of loosely connected CPU's form a network computing environment. The network makes it easy to develop software systems by utilizing the computing resources throughout the network in parallel . Individual components within a system are distributed to processors best suited for the task and processed there in parallel, thereby accomplishing more in a given amount of time.
In one embodiment of the invention, a software configuration manager determines which components of a system are to be compiled, and assigns each such buildable component to a different processor to compile such that independent components are compiled in parallel by different processors. In accordance with one aspect of the present invention, the configuration manager determines which components of a system are to be built by reviewing a common pool of previously compiled or derived components.
In accordance with another aspect of the invention, the configuration manager defines a user ~25~8 specified processor as a reference node for all processors compiling components of one system.
Likewise the configuration manager defines a user-specified file system within the network as a reference file system for the processors in the network. Further, a compiler stored in a file system of one processor may be invoked by other processors of the network to compile a component.
In one feature of the present invention, the configuration manager includes a build scheduler.
For each system being built, the build scheduler orders the buildable components according to their dependencies on each other, starting with the most independent components. The build scheduler then chooses and assigns available processors to compile the buildable components in the order of more independent to less independent.
In another feature of the present invention, a user specifies an ordered list, from most powerful to least powerful, of a subset of the processors. The build scheduler chooses from the list the most powerful processor with sufficient idle time to compile the next buildable component. The build scheduler computes the idle time of each listed 25 processor as the ratio of the difference between current idle time and a base idle time to the difference between current real time and a base real time. Further, the build scheduler computes an initial base real time and an initial base idle time 30 before any buildable component of the system is compiled. Thereafter, the build scheduler obtains a ~3~
current real time and a current idle time for each listed proeessor prior to choosing the processor to compile a component. Preferably, the build scheduler obtains current real times and current idle times for eaeh processor one at a time in deereasing proeessor list order.
In another feature of the present invention, a display of compilation status messages for each eompilation is generated only upon termination of the compilation and is shown as a separate set of messages from that of other compilations. In a preferred embodiment, each compilation has a separate output file associated with it. Further, the display provides, separate from the compilation status messages, an indication of the current overall status of the system being built. The current overall status is continuously updated by the completion and eommencement of compilations by the various processors. The indications of the current overall status include the number of compilations which are pending, suecessful, unsuccessful, and in progress, and the total number of compilations required to build the system.
In another feature of the present invention, the 25 compiler used for a compilation may be in a file system of a processor which is not performing ~he compilation. Hence, processors of the network access remote files systems to perform the compilations necessary to build a system.
~3~ 8 - 4a -In accordance with a particular embodiment of the inven-tion, there is provided apparatus for managing computer software comprising:
a plurality of processors loosely s connected in a network; and configuration management means, executable on at least one of the processors, for building from a configuration model a desired software system having a multiplicity of components including 10 independent components, the configuration management means determining which components are to be compiled and assigning each such to-be-compiled component to a processor to compile the component, the configuration management means assigning the 15 independent components to different processors such that components in the desired software system which are independent of each other are automatically compiled in parallel by different processors;
the components of the desired software system being of user designated versions.
In accordance with a further embodiment of the invention there is provided apparatus for managing computer software comprising:
a plurality of processors capable of 25 processing compilations of software components, one of said processors having a compiler within a certain local file system, the one processor being defined as a reference processor for the other processors, such that each of the other processors 30 makes reference to the certain local file system of the one processor to compile a respective component, the processors compiling respective components in parallel while making reference to the certain local file system of the reference processor.
B
- 4b -In accordance with a still further embodiment of the invention there is provided apparatus for managing computer software comprising:
a plurality of processors, each processor having access to files of the other processors;
configuration management means for automatically compiling components of a software system in parallel utilizing the processors, said configuration management means having:
means for evaluating idle status of the processors, the evaluating means providing an idle status evaluation;
a scheduler for selecting a processor for a compilation based on the idle status evaluation 5 and means for specifying to the selected processor a processor from whose files a compiler is to be used for the compilation.
In accordance with a different aspect 0 there is provided a computer display comprising:
a first screen section displaying compilation status messages from different processors compiling in parallel different modules of a desired software system for parallel building 25 of the system, compilation status messages of each compilation by each processor being disp].a~ved independently of messages of other compilationsi and a second screen section displaying a summary of a current overall status of the parallel 30 building of the system including status of compilations associated with the processors, the first and second screen sections being displayed simultaneously.
Also in accordance with the invention 35 there is provided a method of building a software system using computer means comprising the steps of:
B
- 4c -providing a plurality of processors loosely connected in a network; and executing confi~uration management means on one of the processors, the configuration s management means building from a configuration model a software system having a multiplicity of components including independent components, the configuration management means determining which components of the software system are to be 10 currently compiled and assigning each to-be-compiled component to a processor for compiling, the configuration management means assigning independent components to different processors such that components of the software system are automatically 15 compiled in parallel by different processors, versions of each component being user specified in the configuration model.
Further, in accordance with the invention, there is provided, in a digital processing system, a 20 method of building a software system having a multiplicity of components, the steps comprising:
providing a p].urality of processors coupled to form a network;
providing a compiler in local memory of 25 one of the processors, the other processors having access to the compileri and executing configuration management means on one of the processors, the configuration management means assigning different components of 30 the software system to different processors of the network to compile the components referring to the compiler of the one processor, the processors compiling respectively assigned components in parallel.
3s Still further in accordance with the invention there is provided, in a network of ~L3~
- 4d -computer processors, a method of displaying through one processor a multiplicity of compilation s-tatus messages from different processors in the ne-twork comprising the steps of:
s using computer means, collecting the messages of each compilation of each processor separately from that of other compilations, the processors compiling, in parallel, modules of a software system; and using a display driver of the one processor, displaying the messages of a compilation only on termination of that compilation B
~3~
Brief Description of the Drawinqs The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of a preferred embodiment of the invention, as lllustrated in the accompanying drawings. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
Figure 1 is a schematic of a CASE tool employed by the present invention Figure 2 is a schematic of a network of computers embodying the present invention.
Figures 3a and 3b are schematics of the tree and linear structure used to order buildable ccmponents of a system compiled by the present invention.
Figure 4 is a flow chart of the allocation of a processor of the network in the present invention.
Figure 5 is an illustration of a screen of compilation status messages and overall system status 20 displayed hy the present invention.
Figure 6 is a flow chart of the major program module used to implement the present invention.
Description of the Preferred Embodiment In a typical CASE tool of the source code control and configuration management type, an automated configuration manager builds a software system from its components. In order to correctly build a system, the configuration manager must 30 understand the dependencies between components of the system and the translation rules needed to translate a source component into an object module or executable image. An incremental configuration manager has knowledge of previously built components s (compiled or derived objects) and only rebuilds those components for which there is no suitable derived object.
Some existing tools are the UNI ~ tool MAKE with source code provided by SCCS or RSC;
10 MMS/CMS on VAX/VM~; and ALS, the ADA~Language system. These tools fail to satisfy some important requirements when used for programming or building in the large. They do not allow many users to build different versions of the same system at the same 15 time, sharing common derived objects whenever possible. They also do not allow a single user to build a system using many CPU's concurrently.
The present invention employs a CASE tool which overcomes these problems of prior art devices building in the large. The CASE tool employed in the present invention is describerd and disclosed in "The DOMAIN Software Engineering Environment for Large Scale Software Development Efforts", by D. B Leblang, R. P.
Chase, Jr., and G. D. McLean, Jr., Proceedings of the IEEE Conference on Workstations, San Jose, CA, November 1985; and U.S. Patent No. 4,809,170, issued February 28, 1989, and assigned to the assignee of the presen~ application.
B
.~.... .. . . .
~3~7~
. .
An overview of that CASE tool folllows and is illustrated in Fig. 1.
A user selects a system model 12 and configuration thread 10 to describe the system he 5 desires to build. System model 12 serves as a blueprint for the construction of the new system.
The system model 12 descri~es the components 14 of the system, their dependencies on each other, and describes any files used by the components 14. The 10 system model 12 contains enough information for CASE
tool 16, as utilized in the present invention, to decide which components 14 can be built in parallel (i.e. at the same time on different processcrs~.
The configuration thread 10 specifies which version of each of the components 1~ should be used to build the system. The configuration thread 10 also specifies the options that should be used during translation of each component 14. The combination of the s~stem model 12 and the 20 configuration thread 10 provides a desired version description 18 of the particular system being built.
After a user selects a system model 12 and configuration ~hread 10 a Configuration Manager (CM) module of the CASE -tool 16 uses the desired version 25 description 18 to search a derived object pool 20 which contains components previously compiled for other system builds by translator or compiler 22.
Each derived object (compiled component) in the derived object pool 20 is tagged with the version ~` , ...
57~
description, translator version and options that ~ere used to produce it. The CM searches derived object pool 20 for objects matching any component of the desired version description 1~. When a match is found, the associated derived objects are re-used in the building of the current system. When a match is not found for the component of the current system, then the component is generated (built~ according to the desired version description 18.
The generation of components of a system is accomplished through the translator or compiler 22 in a step called a process. For each process, a version mapping table 24 corresponding to the desired version description 18 is created for the translator 22 because the translator does not communicate with, nor have access to the desired version description 18.
The translator 22 may also access other files or a source library 26, while referring to the version mapping table 24, to build or compile the described version of a component. The resulting derived objects, also known as binaries or compiled components, are tagged as previously mentioned and placed in derived object pool 20.
The derived object pool 20 may simultaneously contain several derived objects for the same buildable component. The version description distinguishes the derived obJects from each other.
The CM deletes objects from the pool 20 as they fall into disuse according to a user-specified limit on the ~umber of derived objects per component. Pool ~3~
objects are deleted on a least-recently-used basis as new objects are created. If a deleted derived object is subsequently needed, the CM re-derives it from its constituent element versions recorded by a history manager (~M) module.
HM provides source code control within the CASE
tool 16. Using HM commands, users create source elements with unique names. ~sers create a new version of a source element by having the HM reserve the element during the desired modification and then subsequently replace the new version of the element.
When a new version of a source element is made, the ~IM records only the changes made to the preceding version. Thus, HM creates a chain of changes made between se~uential versions of the source element.
This enables the HM to store more versions of source elements in an allotted space. The HM also supports multiple lines of development or variant branches within an element. Further, any version of a source element is directly readable from the HM source library, as will be discussed.
As shown in Fig. 2, CASE tool 16 is utilized in the present invention within a network of loosely connected CPU's or workstations 28 and 29. Various workstations can utilize the CASE tool to concurrently build different systems or different versions of the same system. The derived objects pool 20 of the CASE tool Configuration Manager 42, CM, is shared by all CPU's within the network. Thus, processors working on different components of the ~31~578 system use the same derived object pool and share common derived objects. Further, the CM ~2 manages the derived object pool 20 in a way which allows multiple concurrent writers. Thus, many processors may write to pool 20 at the same time without creating inconsistent views of the pool.
The source libraries 26, which are controlled by the HM, are also shared among processors 28 and 29 of the network. Network-wide, transparent access to arbitrary versions of source elements in the source libraries 26 is provided by the underlying file system. This, in turn, enables software applications, such as compilers and test formatters, to read any version of a source element directly from the source library. By default, the latest version of an element is read. However, the per-process version map 24 of Fig. 1, generated by the CASE tool 16, can indicate an alternate version of the desired source element. The per-process nature of the version maps 24 enables simultaneous building of different versions of a system from the single set of sources. This ability to simultaneously access difrerent versions of source elements is critical to the ability to build different configurations or system components in parallel.
For purposes of illustration in Fig. 2, the CASE
tool 16 is invoked on one workstation 28. After the user of workstation 28 defines a system model and configuration thread, a desired version description 30 is formed as previously mentioned. The CM 42 ~3~32~ii7~1 determines which system components are to be built (compiled) by looXing in the derived object pool 20 for binaries which match the desired version description of each c,omponent. Once the CM 42 has determined which components of the system are to be built, the CM forms a translation script for each buildable component from translation rules in the system model. The translation script aids in the building of the component and provides directions for placing translator/compiler results in the derived object pool.
The CM 42 then utilizes a parallel build scheduler 30 within CASE tool 16 which commits builds to remote processors from workstation 28, as illustrated by the arrows extending from tool 16.
Build scheduler 30 chooses a component from the buildable set, chooses a processor from an available set of processors, and assigns the building of the chosen component to the chosen processor. To accomplish this, the build scheduler 30 initially reads the dependency information of the components from a tree structure of the system model which defines a partial-ordering for building components in the model. The build scheduler 30 then creates from the system model tree an optimized ordering of only the buildable components and records the ordering in a linear scheduling structure. The linear scheduling structure is a condensed and flattened version of the system model tree structure, and employs a ready list of the buildable components with back pointers from ~L3~Z5~1~
each sub-component to its parent components. The tree structure of the system model is illustrated in Figure 3a and an illustration of a corresponding linear scheduling structure of buildable components is provided in Figure 3b.
In Figure 3a, components x.h and y.h are shown as subcomponents to the lexer.c component.
Subcomponents x.h and ~.h are shown as the bottom leaves of one branch of the whole system model tree and are independent from each other. Thus, x.h and y.h may be built in parallel without affecting the overall outcome of the system my_program. However, lexer.c depends on both x.h and y.h and thus cannot be built in parallel with either subcomponent.
Similarly, 2.h is a sub-component of parser.c.
Assume for example that all of the illustrated components, except the 2.h component, are to be built. The build scheduler 30 would then create the linear scheduling structure illustrated in Figure 3b.
The build scheduler 30 also initially creates an ordered list of user speciîied processors (i.e., workstations~, the names and ordering of which the user provides the CASE tool 16 in a file within the network. In a preferred embodiment, the list is as long as the user desires, but only twenty processors are concurrently used to build any onc system.
Preferably the list is ordered in a preference of more powerful to least based on the number of million instructions per second the processor executes. For the compilation of each component, the build scheduler 30 chooses the most powerful listed ~3~
processor available with a sufficient amount of idle time, as will be defined. This maximizes performance of the network and parallel building scheme, and minimi~es the amount of interference with other users of the network on their workstations.
As illustrated by -the flow chart oE Fig. 4, for each buildable component, the build scheduler 30 starts at the beginning of the list of processors and determines if the first named processor is available and 90% or more idle. If it is, then the build scheduler assigns that processor the task of compiling the next component on the ordered list of buildable components. The processor is then marked as unavailable, and the build scheduler continues in the same manner beginning at the top of the list of processors for the next buildable component. By starting at the top of the list each time, the build scheduler 30 will grab the most powerful processor as it becomes available. If the processor is not 90% or more idle, then the build scheduler 30 determines if the next available processor on the list is 90% or more idle, and so on. If the build scheduler exhausts the list of processors, then the build scheduler starts at the top of the list and determines if any processor is available and 60% or more idle, then 30% and so on after each exhaustion of the list~
Idle time, I, is defined by:
I _ N - N
- o R - R
~2~8 where N is current null process time of a processor and No is a base null process time of the processor, is the current real time, and Ro is the real time at which the base null process time was obtained.
During the initialization stage of the build scheduler, the build scheduler samples each of the listed processors for a null processing time which is the amount of time that no process was using the CPU
during a certain time segment. The real times of the sampling of each listed processor is also obtained and recorded with the respective null process times.
When the build scheduler subsequently determines which processor is best suited for compiling a component, a current null process time and a current real time is obtained for each processor as the scheduler proceeds down the processor list. The last obtained null process time and real time becomes the base null process time and base real time during a subsequent evaluation for idle time of a processor.
This ensures that the next sampling of idle time is over a most recent time period of activity instead of over a time period of activity which was already sampled and has a known idle time. In the pre~erred embodiment, the samplings of idle time are minimally about 10 seconds apart from each other.
After assigning the "best" processor to compile one component, the next buildable component is similarly assigned to the next determined "best"
available processor and so forth such that components are compiled in parallel on different processors of 2~
the network. In order for each duly chosen processor to compile the respectively assigned component, the CM creates a new process or task on each chosen processor. This includes providing the translation script and a version map of each component to the respective processor. The version map specifies to the processor the desired versions of source elements for that component. Each processor is capable of accessing a file system or compiler of another processor in order to compile the desired version of the assigned component.
Further, a common root is established for all processors. Otherwise, various inconsistencies would arise where the buildable components depend on local files and the various processors have different local file systems. The present invention solves this problem by extending the UNI ~ chroot(2) facility to allow the root of a local file system to resolve to the root of a remote file system. The common roo-t is specified by the user in a separate command at the time of the initialization of the build scheduler 30.
Any one file system or workstation in the network may be designated as a reference for the compiling of all the various components on the several different processors.
An additional complication results from the fact that CASE tool 16 records the version of all sources and tools that are used in a translation of a component. Since the sources and tools used are from the reference workstation, CASE tool 16 sets its own root to the reference workstation prior to determining the versions of the source elements.
Once a chosen remote processor begins executing ~3~2~
the respective translation script in the specially prepared process environment, the CM similarly starts additional processes on other processors. Output compilation status messages from each processor are directed to different respective temporary files.
The CM services these messages and records the completion status ~f the processor after determining if the build failed or succeeded. Once a process has terminated, the CM copies the output messages from the respective temporary file, changes the indication of the availability of the processor, and displays the output messages locally to the workstation 28 which invoked the CASE tool. The completion status is also displayed. Further, a continuously updated graphics display of the current status of the overall parallel build of the system is provided separate from the display of output messages.
An illustration of these displays is provided in Fig. 5. On the left hand section 34 of the screen 32, the user reads output compilation status messages of each processor, one set of messages from one processor at a time. On the right hand section 36 of the screen 32, the user reads an overall status report of the parallel building of the requested system. The overall status report includes, the total number of builds (compilations) required to build the system, the number of builds pending, the number of builds successfully and unsuccessfully completed, and the number of builds in progress.
If the various output messages were directly ~3~2S78 displayed at workstation 28 as the processors compiled components in parallel, the screen would display the output messages in a tangled, mixed-up order. That is, the messages of one processor would be intermixed with that o~ the other processors.
Further, the overall status report is totally separated from the other messages for ease in reading by the user.
Further, the CM periodically polls each remote processor to determine that it has not abnormally terminated. In a case of abnormal termination of the remote build process or compilation, the CM recovers with an error messa~e indicating that the build was lost and frees the processor for another assignment.
This ensures a more efficient use of the processors in the network instead of waiting indefinitely for the remote process to send a completion message.
The following describes the computer subroutine 44 used to implement the above discussed concurrent building of system components for one system. A
block diagram of the subroutine 44 is provided in Figure 6.
Upon entry to the subroutine 44, the build scheduler initializes the list of buildable components and the ordered list of user-specified processors. The buildable components are ordered in a linear scheduling structure according to dependency as previously described in Figures 3a and 3b.
Initial samples of a base null process time and a 30 base real time are obtained for the listed processors ~3~S~8 as previously described. Also, upon entry to ~he subroutine, a user-specified reference file system is established.
A main loop 38 comprises a startup loop 40, which starts as many builds (compilations) as possible under the constraints of:
(1) the implementation maximum number of concurrent builds;
(2) the number of available processors;
~3) the user-defined limit on the numher of concurrent builds; and (4) the dependency of some builds on the successful completion of other builds.
Before starting a new build, startup loop ~0 checks executing builds for completion. If the build was abnormally terminated, then the rest o~ the builds not yet completed are aborted and a fail message is displayed. If the build terminated normally, then subroutine "finish build" is invoked as will be described.
If no builds are completed, then the starting of another new build is attempted. An examination is made for any buildable component remaining from a previous call to the "build scheduler," a routine which schedules the builds in order of dependency.
If there is no outstanding buildable component, then the build scheduli~g routine is invoked to obtain the next buildable component.
If there are no more buildable components that can be obtained by the build scheduling routine and all builds have been completed (i.e. the last build 25~78 was scheduled and no builds are executing), then finalization is accomplished by the subroutine "Done"
as will be discussed. If no other builds can be assigned right now due to dependencies of the builds, then startup loop 40 is exited to main loop 38 where main subroutine 44 waits for a build to complete.
Once a buildable component has been obtained, the subroutine described in Figure 4 is invoked to allocate the best processor or build slot available.
If no slot is available, then an error check is made.
If no builds are being executed, then the finding of no build slot available is an error which is handled by the "Fail" subroutine. Otherwise, the finding of no build slot available right now is legitimate and startup loop 40 is exited to main loop 38 to wait for a build to complete.
If a build slot is found, then a new build is started. If the build was started without error and is presently executing, then the startup loop is begun again to attempt to start a new build.
However, if the build that was started without error has no translation script, then it may be completed immediately. Thus, subroutine "finish build" is invoked.
If a build could not be started due to an error, then the build slot is released and the build scheduler is updated. If this was the last build of the system, then subroutine "Fail" is invoked.
Otherwise, startup loop 40 is repeated to try to start another build.
~.3~)~S~
An alternative in the case of a build not being able to be started, is to exit the startup loop and see if a build has finished. This would perhaps avoid another false start if the problem with starting the build involved the unavailability of resources due to builds which have been completed but not yet "cleaned up" (i.e., finalized). ~owever, in the previously described embodiment of Fig. 2, such a problem should not arise.
The startup loop 40 is repeated continually as described above until either a build with no translation script is started (which means that the build can be finished immediately), or the last build that can currently be executed is started. That build is the last possible build to execute due to either all processors being in use or no other component of the system beiny "independent" enough to currently be built. If the build has no translation rule, then the build is completed via the "finish build" subroutine. If the build has a translation script, then the main subroutine 44 waits for a build to complete in main loop 3~. Once a build has completed, error checking is provided for abnormal termination of the build. If the build was abnormally terminated, then the subroutine "Fail'i is invoked. If the build was normally terminated, then subroutine "finish buildl' is invoked. "Finish build"
finalizes output messages concerning the success or failure of the build and updates the build scheduler.
If the compilation was successful, then "finish build" places the completed build in the common derived objects pool along with the version description used in the build. IX the compilation was unsuccessful, then "finish build" withholds the build from the pool.
If that build was the last build for the system and all other builds have come to completion, then the "Done" subroutine is invoked. Otherwise, the main loop 38 of subroutine 4~ is begun again and retraced along with inner startup loop 40.
Subroutine "Done" first tests the status of the listed last component to be built. If the status indicates that the component must still be built, then the build command invoking this main subroutine 44 failed. Significant error statistics are outputted to a display and the build scheduler is terminated. This ends subroutine 4~.
Subroutine "Fail" similarly ends the main subroutine 44 by outputting any significant error statistics to a display and terminating the build scheduler. However, before ending the subroutine 44, "Fail" terminates all builds which may be executing and clears their respective files of status messages.
While the invention has been particularly shown and described with reference to a preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
IN PARALLEL IN A NETWORK
Background of the Invention Developments in computer hardware have steadily increased the share of computing resources availa~le to an individual user. In the beginning, computers were single user resources. Batch systems were then developed to take better advantage of the central processing unit (CPU). Next came time-sharing systems, which allowed large numbers of users to interact with a single CPU. More recently, systems in which each workstation has its own CPU have evolved from time-sharing systems to let users continue to share files without sharing a single CPU.
Current workstations have overcome the problems of distributed file systems with transparent network file systems that allow users to access both local and remote files in a uniform way.
Further development brought l~igh performance workstations, with bit map graphic displays, and high speed local area networks. Ini~ially, most workstations were used for computer aided design applications (i.e. CAD/CAM, MCAD, etc.). However, as t~e price of workstations fell and the amount of software increased, a new market wa~ created called Computer Aided Software Engineering (CASE). Various CASE tools have various software control and management capabilities. In one kind of CASE tool, components of a software system are individually ~l3~5~3 designed and the software system is constructe~ from its components. The larger the constructed system is, however, the longer is the amount of time required to build the system. Thus, the required build time greatly impairs productivity since the user must wait for the CASE tool, and for some systems he must wait overnight.
Summary of the Invention In the present invention, a collection of loosely connected CPU's form a network computing environment. The network makes it easy to develop software systems by utilizing the computing resources throughout the network in parallel . Individual components within a system are distributed to processors best suited for the task and processed there in parallel, thereby accomplishing more in a given amount of time.
In one embodiment of the invention, a software configuration manager determines which components of a system are to be compiled, and assigns each such buildable component to a different processor to compile such that independent components are compiled in parallel by different processors. In accordance with one aspect of the present invention, the configuration manager determines which components of a system are to be built by reviewing a common pool of previously compiled or derived components.
In accordance with another aspect of the invention, the configuration manager defines a user ~25~8 specified processor as a reference node for all processors compiling components of one system.
Likewise the configuration manager defines a user-specified file system within the network as a reference file system for the processors in the network. Further, a compiler stored in a file system of one processor may be invoked by other processors of the network to compile a component.
In one feature of the present invention, the configuration manager includes a build scheduler.
For each system being built, the build scheduler orders the buildable components according to their dependencies on each other, starting with the most independent components. The build scheduler then chooses and assigns available processors to compile the buildable components in the order of more independent to less independent.
In another feature of the present invention, a user specifies an ordered list, from most powerful to least powerful, of a subset of the processors. The build scheduler chooses from the list the most powerful processor with sufficient idle time to compile the next buildable component. The build scheduler computes the idle time of each listed 25 processor as the ratio of the difference between current idle time and a base idle time to the difference between current real time and a base real time. Further, the build scheduler computes an initial base real time and an initial base idle time 30 before any buildable component of the system is compiled. Thereafter, the build scheduler obtains a ~3~
current real time and a current idle time for each listed proeessor prior to choosing the processor to compile a component. Preferably, the build scheduler obtains current real times and current idle times for eaeh processor one at a time in deereasing proeessor list order.
In another feature of the present invention, a display of compilation status messages for each eompilation is generated only upon termination of the compilation and is shown as a separate set of messages from that of other compilations. In a preferred embodiment, each compilation has a separate output file associated with it. Further, the display provides, separate from the compilation status messages, an indication of the current overall status of the system being built. The current overall status is continuously updated by the completion and eommencement of compilations by the various processors. The indications of the current overall status include the number of compilations which are pending, suecessful, unsuccessful, and in progress, and the total number of compilations required to build the system.
In another feature of the present invention, the 25 compiler used for a compilation may be in a file system of a processor which is not performing ~he compilation. Hence, processors of the network access remote files systems to perform the compilations necessary to build a system.
~3~ 8 - 4a -In accordance with a particular embodiment of the inven-tion, there is provided apparatus for managing computer software comprising:
a plurality of processors loosely s connected in a network; and configuration management means, executable on at least one of the processors, for building from a configuration model a desired software system having a multiplicity of components including 10 independent components, the configuration management means determining which components are to be compiled and assigning each such to-be-compiled component to a processor to compile the component, the configuration management means assigning the 15 independent components to different processors such that components in the desired software system which are independent of each other are automatically compiled in parallel by different processors;
the components of the desired software system being of user designated versions.
In accordance with a further embodiment of the invention there is provided apparatus for managing computer software comprising:
a plurality of processors capable of 25 processing compilations of software components, one of said processors having a compiler within a certain local file system, the one processor being defined as a reference processor for the other processors, such that each of the other processors 30 makes reference to the certain local file system of the one processor to compile a respective component, the processors compiling respective components in parallel while making reference to the certain local file system of the reference processor.
B
- 4b -In accordance with a still further embodiment of the invention there is provided apparatus for managing computer software comprising:
a plurality of processors, each processor having access to files of the other processors;
configuration management means for automatically compiling components of a software system in parallel utilizing the processors, said configuration management means having:
means for evaluating idle status of the processors, the evaluating means providing an idle status evaluation;
a scheduler for selecting a processor for a compilation based on the idle status evaluation 5 and means for specifying to the selected processor a processor from whose files a compiler is to be used for the compilation.
In accordance with a different aspect 0 there is provided a computer display comprising:
a first screen section displaying compilation status messages from different processors compiling in parallel different modules of a desired software system for parallel building 25 of the system, compilation status messages of each compilation by each processor being disp].a~ved independently of messages of other compilationsi and a second screen section displaying a summary of a current overall status of the parallel 30 building of the system including status of compilations associated with the processors, the first and second screen sections being displayed simultaneously.
Also in accordance with the invention 35 there is provided a method of building a software system using computer means comprising the steps of:
B
- 4c -providing a plurality of processors loosely connected in a network; and executing confi~uration management means on one of the processors, the configuration s management means building from a configuration model a software system having a multiplicity of components including independent components, the configuration management means determining which components of the software system are to be 10 currently compiled and assigning each to-be-compiled component to a processor for compiling, the configuration management means assigning independent components to different processors such that components of the software system are automatically 15 compiled in parallel by different processors, versions of each component being user specified in the configuration model.
Further, in accordance with the invention, there is provided, in a digital processing system, a 20 method of building a software system having a multiplicity of components, the steps comprising:
providing a p].urality of processors coupled to form a network;
providing a compiler in local memory of 25 one of the processors, the other processors having access to the compileri and executing configuration management means on one of the processors, the configuration management means assigning different components of 30 the software system to different processors of the network to compile the components referring to the compiler of the one processor, the processors compiling respectively assigned components in parallel.
3s Still further in accordance with the invention there is provided, in a network of ~L3~
- 4d -computer processors, a method of displaying through one processor a multiplicity of compilation s-tatus messages from different processors in the ne-twork comprising the steps of:
s using computer means, collecting the messages of each compilation of each processor separately from that of other compilations, the processors compiling, in parallel, modules of a software system; and using a display driver of the one processor, displaying the messages of a compilation only on termination of that compilation B
~3~
Brief Description of the Drawinqs The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of a preferred embodiment of the invention, as lllustrated in the accompanying drawings. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
Figure 1 is a schematic of a CASE tool employed by the present invention Figure 2 is a schematic of a network of computers embodying the present invention.
Figures 3a and 3b are schematics of the tree and linear structure used to order buildable ccmponents of a system compiled by the present invention.
Figure 4 is a flow chart of the allocation of a processor of the network in the present invention.
Figure 5 is an illustration of a screen of compilation status messages and overall system status 20 displayed hy the present invention.
Figure 6 is a flow chart of the major program module used to implement the present invention.
Description of the Preferred Embodiment In a typical CASE tool of the source code control and configuration management type, an automated configuration manager builds a software system from its components. In order to correctly build a system, the configuration manager must 30 understand the dependencies between components of the system and the translation rules needed to translate a source component into an object module or executable image. An incremental configuration manager has knowledge of previously built components s (compiled or derived objects) and only rebuilds those components for which there is no suitable derived object.
Some existing tools are the UNI ~ tool MAKE with source code provided by SCCS or RSC;
10 MMS/CMS on VAX/VM~; and ALS, the ADA~Language system. These tools fail to satisfy some important requirements when used for programming or building in the large. They do not allow many users to build different versions of the same system at the same 15 time, sharing common derived objects whenever possible. They also do not allow a single user to build a system using many CPU's concurrently.
The present invention employs a CASE tool which overcomes these problems of prior art devices building in the large. The CASE tool employed in the present invention is describerd and disclosed in "The DOMAIN Software Engineering Environment for Large Scale Software Development Efforts", by D. B Leblang, R. P.
Chase, Jr., and G. D. McLean, Jr., Proceedings of the IEEE Conference on Workstations, San Jose, CA, November 1985; and U.S. Patent No. 4,809,170, issued February 28, 1989, and assigned to the assignee of the presen~ application.
B
.~.... .. . . .
~3~7~
. .
An overview of that CASE tool folllows and is illustrated in Fig. 1.
A user selects a system model 12 and configuration thread 10 to describe the system he 5 desires to build. System model 12 serves as a blueprint for the construction of the new system.
The system model 12 descri~es the components 14 of the system, their dependencies on each other, and describes any files used by the components 14. The 10 system model 12 contains enough information for CASE
tool 16, as utilized in the present invention, to decide which components 14 can be built in parallel (i.e. at the same time on different processcrs~.
The configuration thread 10 specifies which version of each of the components 1~ should be used to build the system. The configuration thread 10 also specifies the options that should be used during translation of each component 14. The combination of the s~stem model 12 and the 20 configuration thread 10 provides a desired version description 18 of the particular system being built.
After a user selects a system model 12 and configuration ~hread 10 a Configuration Manager (CM) module of the CASE -tool 16 uses the desired version 25 description 18 to search a derived object pool 20 which contains components previously compiled for other system builds by translator or compiler 22.
Each derived object (compiled component) in the derived object pool 20 is tagged with the version ~` , ...
57~
description, translator version and options that ~ere used to produce it. The CM searches derived object pool 20 for objects matching any component of the desired version description 1~. When a match is found, the associated derived objects are re-used in the building of the current system. When a match is not found for the component of the current system, then the component is generated (built~ according to the desired version description 18.
The generation of components of a system is accomplished through the translator or compiler 22 in a step called a process. For each process, a version mapping table 24 corresponding to the desired version description 18 is created for the translator 22 because the translator does not communicate with, nor have access to the desired version description 18.
The translator 22 may also access other files or a source library 26, while referring to the version mapping table 24, to build or compile the described version of a component. The resulting derived objects, also known as binaries or compiled components, are tagged as previously mentioned and placed in derived object pool 20.
The derived object pool 20 may simultaneously contain several derived objects for the same buildable component. The version description distinguishes the derived obJects from each other.
The CM deletes objects from the pool 20 as they fall into disuse according to a user-specified limit on the ~umber of derived objects per component. Pool ~3~
objects are deleted on a least-recently-used basis as new objects are created. If a deleted derived object is subsequently needed, the CM re-derives it from its constituent element versions recorded by a history manager (~M) module.
HM provides source code control within the CASE
tool 16. Using HM commands, users create source elements with unique names. ~sers create a new version of a source element by having the HM reserve the element during the desired modification and then subsequently replace the new version of the element.
When a new version of a source element is made, the ~IM records only the changes made to the preceding version. Thus, HM creates a chain of changes made between se~uential versions of the source element.
This enables the HM to store more versions of source elements in an allotted space. The HM also supports multiple lines of development or variant branches within an element. Further, any version of a source element is directly readable from the HM source library, as will be discussed.
As shown in Fig. 2, CASE tool 16 is utilized in the present invention within a network of loosely connected CPU's or workstations 28 and 29. Various workstations can utilize the CASE tool to concurrently build different systems or different versions of the same system. The derived objects pool 20 of the CASE tool Configuration Manager 42, CM, is shared by all CPU's within the network. Thus, processors working on different components of the ~31~578 system use the same derived object pool and share common derived objects. Further, the CM ~2 manages the derived object pool 20 in a way which allows multiple concurrent writers. Thus, many processors may write to pool 20 at the same time without creating inconsistent views of the pool.
The source libraries 26, which are controlled by the HM, are also shared among processors 28 and 29 of the network. Network-wide, transparent access to arbitrary versions of source elements in the source libraries 26 is provided by the underlying file system. This, in turn, enables software applications, such as compilers and test formatters, to read any version of a source element directly from the source library. By default, the latest version of an element is read. However, the per-process version map 24 of Fig. 1, generated by the CASE tool 16, can indicate an alternate version of the desired source element. The per-process nature of the version maps 24 enables simultaneous building of different versions of a system from the single set of sources. This ability to simultaneously access difrerent versions of source elements is critical to the ability to build different configurations or system components in parallel.
For purposes of illustration in Fig. 2, the CASE
tool 16 is invoked on one workstation 28. After the user of workstation 28 defines a system model and configuration thread, a desired version description 30 is formed as previously mentioned. The CM 42 ~3~32~ii7~1 determines which system components are to be built (compiled) by looXing in the derived object pool 20 for binaries which match the desired version description of each c,omponent. Once the CM 42 has determined which components of the system are to be built, the CM forms a translation script for each buildable component from translation rules in the system model. The translation script aids in the building of the component and provides directions for placing translator/compiler results in the derived object pool.
The CM 42 then utilizes a parallel build scheduler 30 within CASE tool 16 which commits builds to remote processors from workstation 28, as illustrated by the arrows extending from tool 16.
Build scheduler 30 chooses a component from the buildable set, chooses a processor from an available set of processors, and assigns the building of the chosen component to the chosen processor. To accomplish this, the build scheduler 30 initially reads the dependency information of the components from a tree structure of the system model which defines a partial-ordering for building components in the model. The build scheduler 30 then creates from the system model tree an optimized ordering of only the buildable components and records the ordering in a linear scheduling structure. The linear scheduling structure is a condensed and flattened version of the system model tree structure, and employs a ready list of the buildable components with back pointers from ~L3~Z5~1~
each sub-component to its parent components. The tree structure of the system model is illustrated in Figure 3a and an illustration of a corresponding linear scheduling structure of buildable components is provided in Figure 3b.
In Figure 3a, components x.h and y.h are shown as subcomponents to the lexer.c component.
Subcomponents x.h and ~.h are shown as the bottom leaves of one branch of the whole system model tree and are independent from each other. Thus, x.h and y.h may be built in parallel without affecting the overall outcome of the system my_program. However, lexer.c depends on both x.h and y.h and thus cannot be built in parallel with either subcomponent.
Similarly, 2.h is a sub-component of parser.c.
Assume for example that all of the illustrated components, except the 2.h component, are to be built. The build scheduler 30 would then create the linear scheduling structure illustrated in Figure 3b.
The build scheduler 30 also initially creates an ordered list of user speciîied processors (i.e., workstations~, the names and ordering of which the user provides the CASE tool 16 in a file within the network. In a preferred embodiment, the list is as long as the user desires, but only twenty processors are concurrently used to build any onc system.
Preferably the list is ordered in a preference of more powerful to least based on the number of million instructions per second the processor executes. For the compilation of each component, the build scheduler 30 chooses the most powerful listed ~3~
processor available with a sufficient amount of idle time, as will be defined. This maximizes performance of the network and parallel building scheme, and minimi~es the amount of interference with other users of the network on their workstations.
As illustrated by -the flow chart oE Fig. 4, for each buildable component, the build scheduler 30 starts at the beginning of the list of processors and determines if the first named processor is available and 90% or more idle. If it is, then the build scheduler assigns that processor the task of compiling the next component on the ordered list of buildable components. The processor is then marked as unavailable, and the build scheduler continues in the same manner beginning at the top of the list of processors for the next buildable component. By starting at the top of the list each time, the build scheduler 30 will grab the most powerful processor as it becomes available. If the processor is not 90% or more idle, then the build scheduler 30 determines if the next available processor on the list is 90% or more idle, and so on. If the build scheduler exhausts the list of processors, then the build scheduler starts at the top of the list and determines if any processor is available and 60% or more idle, then 30% and so on after each exhaustion of the list~
Idle time, I, is defined by:
I _ N - N
- o R - R
~2~8 where N is current null process time of a processor and No is a base null process time of the processor, is the current real time, and Ro is the real time at which the base null process time was obtained.
During the initialization stage of the build scheduler, the build scheduler samples each of the listed processors for a null processing time which is the amount of time that no process was using the CPU
during a certain time segment. The real times of the sampling of each listed processor is also obtained and recorded with the respective null process times.
When the build scheduler subsequently determines which processor is best suited for compiling a component, a current null process time and a current real time is obtained for each processor as the scheduler proceeds down the processor list. The last obtained null process time and real time becomes the base null process time and base real time during a subsequent evaluation for idle time of a processor.
This ensures that the next sampling of idle time is over a most recent time period of activity instead of over a time period of activity which was already sampled and has a known idle time. In the pre~erred embodiment, the samplings of idle time are minimally about 10 seconds apart from each other.
After assigning the "best" processor to compile one component, the next buildable component is similarly assigned to the next determined "best"
available processor and so forth such that components are compiled in parallel on different processors of 2~
the network. In order for each duly chosen processor to compile the respectively assigned component, the CM creates a new process or task on each chosen processor. This includes providing the translation script and a version map of each component to the respective processor. The version map specifies to the processor the desired versions of source elements for that component. Each processor is capable of accessing a file system or compiler of another processor in order to compile the desired version of the assigned component.
Further, a common root is established for all processors. Otherwise, various inconsistencies would arise where the buildable components depend on local files and the various processors have different local file systems. The present invention solves this problem by extending the UNI ~ chroot(2) facility to allow the root of a local file system to resolve to the root of a remote file system. The common roo-t is specified by the user in a separate command at the time of the initialization of the build scheduler 30.
Any one file system or workstation in the network may be designated as a reference for the compiling of all the various components on the several different processors.
An additional complication results from the fact that CASE tool 16 records the version of all sources and tools that are used in a translation of a component. Since the sources and tools used are from the reference workstation, CASE tool 16 sets its own root to the reference workstation prior to determining the versions of the source elements.
Once a chosen remote processor begins executing ~3~2~
the respective translation script in the specially prepared process environment, the CM similarly starts additional processes on other processors. Output compilation status messages from each processor are directed to different respective temporary files.
The CM services these messages and records the completion status ~f the processor after determining if the build failed or succeeded. Once a process has terminated, the CM copies the output messages from the respective temporary file, changes the indication of the availability of the processor, and displays the output messages locally to the workstation 28 which invoked the CASE tool. The completion status is also displayed. Further, a continuously updated graphics display of the current status of the overall parallel build of the system is provided separate from the display of output messages.
An illustration of these displays is provided in Fig. 5. On the left hand section 34 of the screen 32, the user reads output compilation status messages of each processor, one set of messages from one processor at a time. On the right hand section 36 of the screen 32, the user reads an overall status report of the parallel building of the requested system. The overall status report includes, the total number of builds (compilations) required to build the system, the number of builds pending, the number of builds successfully and unsuccessfully completed, and the number of builds in progress.
If the various output messages were directly ~3~2S78 displayed at workstation 28 as the processors compiled components in parallel, the screen would display the output messages in a tangled, mixed-up order. That is, the messages of one processor would be intermixed with that o~ the other processors.
Further, the overall status report is totally separated from the other messages for ease in reading by the user.
Further, the CM periodically polls each remote processor to determine that it has not abnormally terminated. In a case of abnormal termination of the remote build process or compilation, the CM recovers with an error messa~e indicating that the build was lost and frees the processor for another assignment.
This ensures a more efficient use of the processors in the network instead of waiting indefinitely for the remote process to send a completion message.
The following describes the computer subroutine 44 used to implement the above discussed concurrent building of system components for one system. A
block diagram of the subroutine 44 is provided in Figure 6.
Upon entry to the subroutine 44, the build scheduler initializes the list of buildable components and the ordered list of user-specified processors. The buildable components are ordered in a linear scheduling structure according to dependency as previously described in Figures 3a and 3b.
Initial samples of a base null process time and a 30 base real time are obtained for the listed processors ~3~S~8 as previously described. Also, upon entry to ~he subroutine, a user-specified reference file system is established.
A main loop 38 comprises a startup loop 40, which starts as many builds (compilations) as possible under the constraints of:
(1) the implementation maximum number of concurrent builds;
(2) the number of available processors;
~3) the user-defined limit on the numher of concurrent builds; and (4) the dependency of some builds on the successful completion of other builds.
Before starting a new build, startup loop ~0 checks executing builds for completion. If the build was abnormally terminated, then the rest o~ the builds not yet completed are aborted and a fail message is displayed. If the build terminated normally, then subroutine "finish build" is invoked as will be described.
If no builds are completed, then the starting of another new build is attempted. An examination is made for any buildable component remaining from a previous call to the "build scheduler," a routine which schedules the builds in order of dependency.
If there is no outstanding buildable component, then the build scheduli~g routine is invoked to obtain the next buildable component.
If there are no more buildable components that can be obtained by the build scheduling routine and all builds have been completed (i.e. the last build 25~78 was scheduled and no builds are executing), then finalization is accomplished by the subroutine "Done"
as will be discussed. If no other builds can be assigned right now due to dependencies of the builds, then startup loop 40 is exited to main loop 38 where main subroutine 44 waits for a build to complete.
Once a buildable component has been obtained, the subroutine described in Figure 4 is invoked to allocate the best processor or build slot available.
If no slot is available, then an error check is made.
If no builds are being executed, then the finding of no build slot available is an error which is handled by the "Fail" subroutine. Otherwise, the finding of no build slot available right now is legitimate and startup loop 40 is exited to main loop 38 to wait for a build to complete.
If a build slot is found, then a new build is started. If the build was started without error and is presently executing, then the startup loop is begun again to attempt to start a new build.
However, if the build that was started without error has no translation script, then it may be completed immediately. Thus, subroutine "finish build" is invoked.
If a build could not be started due to an error, then the build slot is released and the build scheduler is updated. If this was the last build of the system, then subroutine "Fail" is invoked.
Otherwise, startup loop 40 is repeated to try to start another build.
~.3~)~S~
An alternative in the case of a build not being able to be started, is to exit the startup loop and see if a build has finished. This would perhaps avoid another false start if the problem with starting the build involved the unavailability of resources due to builds which have been completed but not yet "cleaned up" (i.e., finalized). ~owever, in the previously described embodiment of Fig. 2, such a problem should not arise.
The startup loop 40 is repeated continually as described above until either a build with no translation script is started (which means that the build can be finished immediately), or the last build that can currently be executed is started. That build is the last possible build to execute due to either all processors being in use or no other component of the system beiny "independent" enough to currently be built. If the build has no translation rule, then the build is completed via the "finish build" subroutine. If the build has a translation script, then the main subroutine 44 waits for a build to complete in main loop 3~. Once a build has completed, error checking is provided for abnormal termination of the build. If the build was abnormally terminated, then the subroutine "Fail'i is invoked. If the build was normally terminated, then subroutine "finish buildl' is invoked. "Finish build"
finalizes output messages concerning the success or failure of the build and updates the build scheduler.
If the compilation was successful, then "finish build" places the completed build in the common derived objects pool along with the version description used in the build. IX the compilation was unsuccessful, then "finish build" withholds the build from the pool.
If that build was the last build for the system and all other builds have come to completion, then the "Done" subroutine is invoked. Otherwise, the main loop 38 of subroutine 4~ is begun again and retraced along with inner startup loop 40.
Subroutine "Done" first tests the status of the listed last component to be built. If the status indicates that the component must still be built, then the build command invoking this main subroutine 44 failed. Significant error statistics are outputted to a display and the build scheduler is terminated. This ends subroutine 4~.
Subroutine "Fail" similarly ends the main subroutine 44 by outputting any significant error statistics to a display and terminating the build scheduler. However, before ending the subroutine 44, "Fail" terminates all builds which may be executing and clears their respective files of status messages.
While the invention has been particularly shown and described with reference to a preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (31)
1. Apparatus for managing computer software comprising:
a plurality of processors loosely connected in a network; and configuration management means, executable on at least one of the processors, for building from a configuration model a desired software system having a multiplicity of components including independent components, the configuration management means determining which components are to be compiled and assigning each such to-be-compiled component to a processor to compile the component, the configuration management means assigning the independent components to different processors such that components in the desired software system which are independent of each other are automatically compiled in parallel by different processors;
the components of the desired software system being of user designated versions.
a plurality of processors loosely connected in a network; and configuration management means, executable on at least one of the processors, for building from a configuration model a desired software system having a multiplicity of components including independent components, the configuration management means determining which components are to be compiled and assigning each such to-be-compiled component to a processor to compile the component, the configuration management means assigning the independent components to different processors such that components in the desired software system which are independent of each other are automatically compiled in parallel by different processors;
the components of the desired software system being of user designated versions.
2. Apparatus as claimed in Claim 1 further comprising a common pool of compiled components, the configuration management means determining which components of the system have corresponding compiled components in the common pool such that components of the system without corresponding compiled components in the common pool are determined to be components to-be-compiled by processors of the network.
3. Apparatus as claimed in Claim 1 wherein:
each processor has a local file system; and the configuration management means comprises means for establishing the file system of a user specified processor within the network as a reference file system to be resolved to by the other processors for compiling respective assigned components.
each processor has a local file system; and the configuration management means comprises means for establishing the file system of a user specified processor within the network as a reference file system to be resolved to by the other processors for compiling respective assigned components.
4. Apparatus as claimed in Claim 1 wherein the configuration management means builds from different configuration models, different software systems and includes a build scheduler which for each system:
orders the to-be-compiled components according to their dependencies on each other, independent components taking precedence over dependent components; and chooses and assigns available processors to compile, in order, the to-be-compiled components.
orders the to-be-compiled components according to their dependencies on each other, independent components taking precedence over dependent components; and chooses and assigns available processors to compile, in order, the to-be-compiled components.
5. Apparatus as claimed in Claim 4 further comprising a user specified list of a subset of the processors, the list ordered from most powerful to least powerful processor, the build scheduler choosing from the list the most powerful available processor with sufficient idle time and assigning that processor to compile a component.
6. Apparatus as claimed in Claim 5 wherein the build scheduler computes the idle time of each listed processor as a ratio of the difference between current idle time and base idle time to the difference between current real time and a base real time.
7. Apparatus as claimed in Claim 6 wherein for each listed processor the build scheduler computes an initial base real time and an initial base idle time before any to-be-compiled component of the system is compiled and thereafter obtains a sample of a current real time and current idle time of each listed processor when choosing a processor to compile a component.
8. Apparatus as claimed in Claim 6 wherein the build scheduler obtains an initial base real time and an initial base idle time for all the listed processors at one time and obtains subsequent samples of current real time and current idle time for the processors, one processor at a time in decreasing list order.
9. Apparatus as claimed in Claim 1 further comprising:
a user specified list of a subset of the processors; and a build scheduler which chooses from the list the most powerful processor with sufficient idle time and assigning that processor to compile a component.
a user specified list of a subset of the processors; and a build scheduler which chooses from the list the most powerful processor with sufficient idle time and assigning that processor to compile a component.
10. Apparatus as claimed in Claim 1 further comprising display means which separates compilation status messages relative to each of the compilations carried out by different processors and only displays status messages from a particular compilation on termination of the compilation.
11. Apparatus as claimed in Claim 10 wherein the display means includes a separate output file associated with each compilation.
12. Apparatus as claimed in Claim 10 wherein said display means further displays an indication of a current overall status of the system being built, said current status indication being displayed separately from the compilation status messages and continuously being updated by the completion and commencement of compilations by the processors.
13. Apparatus as claimed in claim 12 wherein the indication of the current overall status includes indications of a number of pending compilations, a number of unsuccessful compilations, a number of successfully completed compilations, a number of compilations in progress and a total number of compilations required to build the system.
14. Apparatus as claimed in Claim 1 wherein a compiler stored in a file system of one processor is invoked by other processors of the network.
15. Apparatus for managing computer software comprising:
a plurality of processors capable of processing compilations of software components, one of said processors having a compiler within a certain local file system, the one processor being defined as a reference processor for the other processors, such that each of the other processors makes reference to the certain local file system of the one processor to compile a respective component, the processors compiling respective components in parallel while making reference to the certain local file system of the reference processor.
a plurality of processors capable of processing compilations of software components, one of said processors having a compiler within a certain local file system, the one processor being defined as a reference processor for the other processors, such that each of the other processors makes reference to the certain local file system of the one processor to compile a respective component, the processors compiling respective components in parallel while making reference to the certain local file system of the reference processor.
16. Apparatus as claimed in Claim 15 wherein said processors compile in parallel different components of a system.
17. Apparatus for managing computer software comprising:
a plurality of processors, each processor having access to files of the other processors;
configuration management means for automatically compiling components of a software system in parallel utilizing the processors, said configuration management means having:
means for evaluating idle status of the processors, the evaluating means providing an idle status evaluation;
a scheduler for selecting a processor for a compilation based on the idle status evaluation; and means for specifying to the selected processor a processor from whose files a compiler is to be used for the compilation.
a plurality of processors, each processor having access to files of the other processors;
configuration management means for automatically compiling components of a software system in parallel utilizing the processors, said configuration management means having:
means for evaluating idle status of the processors, the evaluating means providing an idle status evaluation;
a scheduler for selecting a processor for a compilation based on the idle status evaluation; and means for specifying to the selected processor a processor from whose files a compiler is to be used for the compilation.
18. Apparatus as claimed in Claim 17 wherein said means for evaluating idle status includes a compiling member which determines idle status from a ratio of the difference between current idle time and a base idle time to the difference between current real time and a base real time.
19. Apparatus as claimed in Claim 17 wherein the scheduler of the configuration management means selects a processor further based on power of the processors.
20. Apparatus as claimed in Claim 17 wherein the scheduler of the configuration management means selects a processor in such a manner that the most powerful processor recently made available is selected.
21. Apparatus as claimed in Claim 17 further comprising display means which separates compilation status messages relative to each of the compilations carried out by different processors and only displays status messages from a particular compilation on termination of the compilation.
22. A computer display comprising:
a first screen section displaying compilation status messages from different processors compiling in parallel different modules of a desired software system for parallel building of the system, compilation status messages of each compilation by each processor being displayed independently of messages of other compilations; and a second screen section displaying a summary of a current overall status of the parallel building of the system including status of compilations associated with the processors, the first and second screen sections being displayed simultaneously.
a first screen section displaying compilation status messages from different processors compiling in parallel different modules of a desired software system for parallel building of the system, compilation status messages of each compilation by each processor being displayed independently of messages of other compilations; and a second screen section displaying a summary of a current overall status of the parallel building of the system including status of compilations associated with the processors, the first and second screen sections being displayed simultaneously.
23. A computer display as claimed in Claim 22 wherein the first screen section only displays compilation status messages of a particular compilation upon termination of that compilation.
24. A computer display as claimed in claim 22 wherein the second screen section is continuously updated.
25. Method of building a software system using computer means comprising the steps of:
providing a plurality of processors loosely connected in a network; and executing configuration management means on one of the processors, the configuration management means building from a configuration model a software system having a multiplicity of components including independent components, the configuration management means determining which components of the software system are to be currently compiled and assigning each to-be-compiled component to a processor for compiling, the configuration management means assigning independent components to different processors such that components of the sotware system are automatically compiled in parallel by different processors, versions of each component being user specified in the configuration model.
providing a plurality of processors loosely connected in a network; and executing configuration management means on one of the processors, the configuration management means building from a configuration model a software system having a multiplicity of components including independent components, the configuration management means determining which components of the software system are to be currently compiled and assigning each to-be-compiled component to a processor for compiling, the configuration management means assigning independent components to different processors such that components of the sotware system are automatically compiled in parallel by different processors, versions of each component being user specified in the configuration model.
26. A method as claimed in Claim 25 wherein the step of the configuration management means determining which components are to be compiled includes:
matching compiled components from a common pool of previously derived components with components of the system, unmatched components of the system being established as the components to be currently compiled.
matching compiled components from a common pool of previously derived components with components of the system, unmatched components of the system being established as the components to be currently compiled.
27. A method as claimed in Claim 25 wherein the steps of the configuration management means determining and assigning includes:
ordering the to-be-compiled components according to their dependencies on each other, independent components taking precedence; and choosing and assigning available processors to compile, in order, the to-be-compiled components.
ordering the to-be-compiled components according to their dependencies on each other, independent components taking precedence; and choosing and assigning available processors to compile, in order, the to-be-compiled components.
28. A method as claimed in Claim 27 wherein the step of choosing and assigning an available processor includes:
ordering a list of a subset of the processors, the list ordered form most powerful to least powerful processor; and choosing from the list the most powerful available processor with sufficient idle time; and assigning the chosen processor to compile the next to-be-compiled component.
ordering a list of a subset of the processors, the list ordered form most powerful to least powerful processor; and choosing from the list the most powerful available processor with sufficient idle time; and assigning the chosen processor to compile the next to-be-compiled component.
29. A method as claimed in Claim 25 further comprising the step of defining one processor as a reference processor for the other processors.
30. In a digital processing system, a method of building a software system having a multiplicity of components, the steps comprising:
providing a plurality of processors coupled to form a network;
providing a compiler in local memory of one of the processors, the other processors having access to the complier; and executing configuration management means on one of the processors, the configuration management means assigning different components of the software system to different processors of the network to compile the components referring to the compiler of the one processor, the processors compiling respectively assigned components in parallel.
providing a plurality of processors coupled to form a network;
providing a compiler in local memory of one of the processors, the other processors having access to the complier; and executing configuration management means on one of the processors, the configuration management means assigning different components of the software system to different processors of the network to compile the components referring to the compiler of the one processor, the processors compiling respectively assigned components in parallel.
31. In a network of computer processors, a method of displaying through one processor a multiplicity of compilation status messages from different processors in the network comprising the steps of:
using computer means, collecting the messages of each compilation of each processor separately from that of other compilations, the processors compiling, in parallel, modules of a software system; and using a display driver of the one processor, displaying the messages of a compilation only on termination of that compilation.
using computer means, collecting the messages of each compilation of each processor separately from that of other compilations, the processors compiling, in parallel, modules of a software system; and using a display driver of the one processor, displaying the messages of a compilation only on termination of that compilation.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US07/058,330 US4951192A (en) | 1987-06-04 | 1987-06-04 | Device for managing software configurations in parallel in a network |
| US058,330 | 1987-06-04 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA1302578C true CA1302578C (en) | 1992-06-02 |
Family
ID=22016154
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA000568569A Expired - Lifetime CA1302578C (en) | 1987-06-04 | 1988-06-03 | Device for managing software configurations in parallel in a network |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US4951192A (en) |
| CA (1) | CA1302578C (en) |
Families Citing this family (86)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5212792A (en) * | 1989-06-01 | 1993-05-18 | Hewlett-Packard Company | Method and apparatus for controlling execution of tools in a computer-aided software engineering system |
| US5301327A (en) * | 1989-06-30 | 1994-04-05 | Digital Equipment Corporation | Virtual memory management for source-code development system |
| US5182806A (en) * | 1989-06-30 | 1993-01-26 | Digital Equipment Corporation | Incremental compiler for source-code development system |
| US5313387A (en) * | 1989-06-30 | 1994-05-17 | Digital Equipment Corporation | Re-execution of edit-compile-run cycles for changed lines of source code, with storage of associated data in buffers |
| US5201050A (en) * | 1989-06-30 | 1993-04-06 | Digital Equipment Corporation | Line-skip compiler for source-code development system |
| US5193191A (en) * | 1989-06-30 | 1993-03-09 | Digital Equipment Corporation | Incremental linking in source-code development system |
| US5325531A (en) * | 1989-06-30 | 1994-06-28 | Digital Equipment Corporation | Compiler using clean lines table with entries indicating unchanged text lines for incrementally compiling only changed source text lines |
| US5170465A (en) * | 1989-06-30 | 1992-12-08 | Digital Equipment Corporation | Incremental-scanning compiler for source-code development system |
| AU6046390A (en) * | 1989-07-05 | 1991-02-06 | Ramer And Associates, Inc. | Interaction network system with electronic organizational actors |
| WO1991004537A1 (en) * | 1989-09-11 | 1991-04-04 | Poqet Computer Corporation | Virtual network architecture and loader |
| US5063523A (en) * | 1989-11-16 | 1991-11-05 | Racal Data Communications Inc. | Network management system with event rule handling |
| US5179702A (en) | 1989-12-29 | 1993-01-12 | Supercomputer Systems Limited Partnership | System and method for controlling a highly parallel multiprocessor using an anarchy based scheduler for parallel execution thread scheduling |
| US5237680A (en) * | 1990-09-27 | 1993-08-17 | Sun Microsystems, Inc. | Method for incremental rename propagation between hierarchical file name spaces |
| US5175432A (en) * | 1990-10-31 | 1992-12-29 | Gruman Aerospace Corporation | Infrared detector module test system |
| JP2760363B2 (en) * | 1990-11-14 | 1998-05-28 | 株式会社ピーエフユー | Initialization processing device |
| US5428783A (en) * | 1990-11-28 | 1995-06-27 | Motorola, Inc. | Lan based loosely coupled large grain parallel processing method |
| EP0496494A3 (en) * | 1991-01-22 | 1993-05-12 | International Business Machines Corporation | Software maintenance system |
| US5579509A (en) * | 1991-02-08 | 1996-11-26 | International Business Machines Corporation | Apparatus and method for verifying compatibility of system components |
| EP0501613A3 (en) * | 1991-02-28 | 1993-09-01 | Hewlett-Packard Company | Heterogeneous software configuration management apparatus |
| US6601095B1 (en) | 1991-04-18 | 2003-07-29 | International Business Machines Corporation | Method and apparatus for remote administration of programmable workstations in a data processing system |
| JP2665089B2 (en) * | 1991-09-26 | 1997-10-22 | 三菱電機株式会社 | Compilation method in distributed environment |
| JP3329841B2 (en) * | 1991-10-18 | 2002-09-30 | 株式会社日立製作所 | Network system and its software management method |
| US5278986A (en) * | 1991-12-13 | 1994-01-11 | Thinking Machines Corporation | System and method for compiling a source code supporting data parallel variables |
| US5587935A (en) * | 1991-12-23 | 1996-12-24 | International Business Machines Corporation | Integrated software development system including group decision support subsystem, application development subsystem, and bridge subsystem therebetween |
| US5349682A (en) * | 1992-01-31 | 1994-09-20 | Parallel Pcs, Inc. | Dynamic fault-tolerant parallel processing system for performing an application function with increased efficiency using heterogeneous processors |
| CA2061298C (en) * | 1992-02-17 | 1996-12-03 | Douglas J. Mortson | Method for detecting critical failures during the building of complex computer programs from source code parts |
| AU3944793A (en) * | 1992-03-31 | 1993-11-08 | Aggregate Computing, Inc. | An integrated remote execution system for a heterogenous computer network environment |
| FR2692701B1 (en) * | 1992-06-18 | 1994-09-30 | Aerospatiale | Method for controlling the configuration of a complex installation and device for implementing this method. |
| US5890166A (en) * | 1992-07-16 | 1999-03-30 | International Business Machines Corporation | Versioned-database management system in which tasks are associated with promote groups which comprise a set of parts whose changes are to be promoted |
| GB9215320D0 (en) * | 1992-07-18 | 1992-09-02 | Int Computers Ltd | Configuration mechanism for a computer system |
| US5649200A (en) * | 1993-01-08 | 1997-07-15 | Atria Software, Inc. | Dynamic rule-based version control system |
| US5574898A (en) * | 1993-01-08 | 1996-11-12 | Atria Software, Inc. | Dynamic software version auditor which monitors a process to provide a list of objects that are accessed |
| WO1994025913A2 (en) * | 1993-04-30 | 1994-11-10 | Novadigm, Inc. | Method and apparatus for enterprise desktop management |
| US5748961A (en) * | 1993-07-12 | 1998-05-05 | Digital Equipment Corporation | Efficient method and apparatus for compiling and linking modules of computer code in a large software system |
| US5500881A (en) * | 1993-07-12 | 1996-03-19 | Digital Equipment Corporation | Language scoping for modular, flexible, concise, configuration descriptions |
| AU681433B2 (en) * | 1993-08-03 | 1997-08-28 | Sun Microsystems, Inc. | Flexible multi-platform partitioning for computer applications |
| US5604863A (en) * | 1993-11-01 | 1997-02-18 | International Business Machines Corporation | Method for coordinating executing programs in a data processing system |
| JPH07239776A (en) * | 1994-02-28 | 1995-09-12 | Nec Corp | Software system management device |
| JP3444671B2 (en) * | 1994-11-08 | 2003-09-08 | 富士通株式会社 | Parallel code conversion processing method and system |
| US5625804A (en) * | 1995-04-17 | 1997-04-29 | International Business Machines Corporation | Data conversion in a multiprocessing system usable while maintaining system operations |
| US5815415A (en) * | 1996-01-19 | 1998-09-29 | Bentley Systems, Incorporated | Computer system for portable persistent modeling |
| FR2745649B1 (en) * | 1996-03-01 | 1998-04-30 | Bull Sa | SYSTEM FOR CONFIGURING PRECONFIGURED SOFTWARE ON NETWORK OPEN SYSTEMS IN A DISTRIBUTED ENVIRONMENT AND METHOD IMPLEMENTED BY SUCH A SYSTEM |
| US6063128A (en) * | 1996-03-06 | 2000-05-16 | Bentley Systems, Incorporated | Object-oriented computerized modeling system |
| US6304885B1 (en) * | 1996-05-01 | 2001-10-16 | The United States Of America As Represented By The Secretary Of The Navy | Digital data retrieving, organizing and display system |
| US5950209A (en) * | 1996-10-02 | 1999-09-07 | Alcatel Usa Sourcing, L.P. | Software release control system and method |
| US5960196A (en) * | 1996-12-18 | 1999-09-28 | Alcatel Usa Sourcing, L.P. | Software release metric reporting system and method |
| US5903897A (en) * | 1996-12-18 | 1999-05-11 | Alcatel Usa Sourcing, L.P. | Software documentation release control system |
| EP0859314A3 (en) * | 1996-12-18 | 2001-12-19 | Sun Microsystems, Inc. | Distributed make methods, apparatus, and computer program products |
| US6029169A (en) * | 1997-05-01 | 2000-02-22 | Stratum Technologies Corporation | Universal software structure for representing model structures |
| US6401114B1 (en) * | 1997-05-01 | 2002-06-04 | Stratum Technologies Corporation | Method and apparatus for dynamic programming across a computer network |
| US7162519B2 (en) | 1998-05-01 | 2007-01-09 | Stratum Technologies Corporation | Structure and method for providing customized web pages-therefor |
| US6990458B2 (en) * | 1997-08-28 | 2006-01-24 | Csg Systems, Inc. | System and method for computer-aided technician dispatch and communication |
| US6195795B1 (en) | 1997-12-19 | 2001-02-27 | Alcatel Usa Sourcing, L.P. | Apparatus and method for automatic software release notification |
| US6192518B1 (en) | 1998-01-22 | 2001-02-20 | Mis Only, Inc. | Method for distributing software over network links via electronic mail |
| US7013305B2 (en) | 2001-10-01 | 2006-03-14 | International Business Machines Corporation | Managing the state of coupling facility structures, detecting by one or more systems coupled to the coupling facility, the suspended state of the duplexed command, detecting being independent of message exchange |
| US6295535B1 (en) | 1998-11-13 | 2001-09-25 | Board Of Trustees Operating Michigan State University | Method and system for creating designs using internet-based agents |
| US7055128B2 (en) * | 2000-12-04 | 2006-05-30 | Microsoft Corporation | System and method to communicate, collect and distribute generated shared files |
| US8135815B2 (en) * | 2001-03-27 | 2012-03-13 | Redseal Systems, Inc. | Method and apparatus for network wide policy-based analysis of configurations of devices |
| US7111288B2 (en) * | 2001-07-12 | 2006-09-19 | International Business Machines Corporation | Method and system for minimizing the cycle time when compiling a program in a processing system |
| US7322025B2 (en) * | 2001-07-17 | 2008-01-22 | Tata Consultancy Services Limited | Method and apparatus for versioning and configuration management of object models |
| EP2256622A1 (en) * | 2002-02-07 | 2010-12-01 | Sap Ag | Method and apparatus for parallel distributed compilation |
| US7069541B2 (en) * | 2002-03-01 | 2006-06-27 | Bellsouth Intellectual Property Corporation | System and method for a web-based application development and deployment tracking tool |
| US8166185B2 (en) * | 2002-03-05 | 2012-04-24 | Hewlett-Packard Development Company, L.P. | System and method for enterprise software distribution |
| US7133894B2 (en) * | 2002-03-12 | 2006-11-07 | International Business Machines Corporation | Method, apparatus, and program for synchronous remote builds |
| US6983449B2 (en) | 2002-03-15 | 2006-01-03 | Electronic Data Systems Corporation | System and method for configuring software for distribution |
| US7590618B2 (en) * | 2002-03-25 | 2009-09-15 | Hewlett-Packard Development Company, L.P. | System and method for providing location profile data for network nodes |
| US7003630B1 (en) | 2002-06-27 | 2006-02-21 | Mips Technologies, Inc. | Mechanism for proxy management of multiprocessor storage hierarchies |
| US7017025B1 (en) | 2002-06-27 | 2006-03-21 | Mips Technologies, Inc. | Mechanism for proxy management of multiprocessor virtual memory |
| US7962590B1 (en) | 2002-07-17 | 2011-06-14 | International Business Machines Corporation | Automated discovery of a multitier compute infrastructure |
| US7243306B1 (en) | 2002-07-17 | 2007-07-10 | International Business Machines Corporation | Service descriptor for a multitier compute infrastructure |
| US7210143B2 (en) * | 2002-07-17 | 2007-04-24 | International Business Machines Corporation | Deployment of applications in a multitier compute infrastructure |
| US7337184B1 (en) * | 2002-07-17 | 2008-02-26 | International Business Machines Corporation | Topology mapping of a multitier compute infrastructure |
| US7168064B2 (en) * | 2003-03-25 | 2007-01-23 | Electric Cloud, Inc. | System and method for supplementing program builds with file usage information |
| EP1465069B1 (en) * | 2003-04-01 | 2017-01-25 | Sap Se | Method and computer system for activation of source files |
| US7509244B1 (en) | 2004-12-22 | 2009-03-24 | The Mathworks, Inc. | Distributed model compilation |
| KR100871563B1 (en) * | 2007-02-14 | 2008-12-02 | 삼성전자주식회사 | Apparatus and method for developing software based on component |
| JP2011501839A (en) * | 2007-10-04 | 2011-01-13 | グローバル インフィニプール ゲーエムベーハー | Method for accessing a data entity and its version |
| US8515727B2 (en) * | 2008-03-19 | 2013-08-20 | International Business Machines Corporation | Automatic logic model build process with autonomous quality checking |
| US9069644B2 (en) | 2009-04-10 | 2015-06-30 | Electric Cloud, Inc. | Architecture and method for versioning registry entries in a distributed program build |
| US8949824B2 (en) | 2012-09-28 | 2015-02-03 | Wal-Mart Stores, Inc. | Systems and methods for installing, managing, and provisioning applications |
| US9235491B2 (en) | 2012-09-28 | 2016-01-12 | Wal-Mart Stores, Inc. | Systems and methods for installing, managing, and provisioning applications |
| US9128792B2 (en) | 2012-09-28 | 2015-09-08 | Wal-Mart Stores, Inc. | Systems and methods for installing, managing, and provisioning applications |
| US9317269B2 (en) | 2012-09-28 | 2016-04-19 | Wal-Mart Stores, Inc. | Systems and methods for installing, managing, and provisioning applications |
| US9058330B2 (en) | 2012-10-17 | 2015-06-16 | Wal-Mart Stores, Inc. | Verification of complex multi-application and multi-node deployments |
| US20150046903A1 (en) * | 2013-08-06 | 2015-02-12 | International Business Machines Incorporated | Predicting immediate build targets |
| US20160019210A1 (en) | 2014-07-21 | 2016-01-21 | Dropbox, Inc. | Sharing unmanaged content using a content management system |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4590557A (en) * | 1983-09-12 | 1986-05-20 | Pitney Bowes Inc. | Method and apparatus for controlling software configurations in data processing systems |
| US4558413A (en) * | 1983-11-21 | 1985-12-10 | Xerox Corporation | Software version management system |
| US4809170A (en) * | 1987-04-22 | 1989-02-28 | Apollo Computer, Inc. | Computer device for aiding in the development of software system |
-
1987
- 1987-06-04 US US07/058,330 patent/US4951192A/en not_active Expired - Lifetime
-
1988
- 1988-06-03 CA CA000568569A patent/CA1302578C/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US4951192A (en) | 1990-08-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA1302578C (en) | Device for managing software configurations in parallel in a network | |
| EP0422945B1 (en) | Parallel processing trace data manipulation | |
| EP0406602B1 (en) | Method and apparatus for debugging parallel programs by serialization | |
| US5768594A (en) | Methods and means for scheduling parallel processors | |
| US5428729A (en) | System and method for computer aided software engineering | |
| US7379888B1 (en) | System and method for generating a schedule based on resource assignments | |
| US5381534A (en) | System for automatically generating efficient application - customized client/server operating environment for heterogeneous network computers and operating systems | |
| US5872970A (en) | Integrated cross-platform batch management system | |
| EP0352050A2 (en) | Single-keyed indexed file for TP queue repository | |
| EP0501613A2 (en) | Heterogeneous software configuration management apparatus | |
| KR20020079849A (en) | System and method for rapid completion of data processing tasks distributed on a network | |
| JP2000235511A (en) | Performance analysis method for application program and system/device used for performance analysis for application program | |
| US7146602B2 (en) | Builder tool and interface for system supporting multiple virtual machines | |
| JPH0810440B2 (en) | Application event collection method | |
| CN111125444A (en) | Big data task scheduling management method, device, equipment and storage medium | |
| JP2001051860A (en) | Multithread processor and multithread processing method, and computer-readable recording medium stored with multithread program | |
| Leblang et al. | Parallel software configuration management in a network environment | |
| CN112365157A (en) | Intelligent dispatching method, device, equipment and storage medium | |
| GB2320111A (en) | Data processing system and method for software development/configuration | |
| Bramley et al. | The linear system analyzer | |
| JPH09114693A (en) | Program development supporting device and program execution device | |
| US6934947B1 (en) | Visual tool for developing real time task management code | |
| CN112363819A (en) | Big data task dynamic scheduling method and device and computing equipment | |
| US6725188B1 (en) | Method of cleanup after termination of a process under a simulated operating system | |
| RU2685018C1 (en) | Program multi-sequencing method in the computer system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MKLA | Lapsed |