 |
Description  |
|
|
FIELD OF THE INVENTION
The invention relates to a process for ensuring compatibility between
components of a computer processing system, particularly for ensuring the
integrity of a system configuration, even if enhancements to one system
component render it incompatible with another component.
BACKGROUND OF THE INVENTION
Modern industrial manufacturing techniques make use of a known practice of
manufacturing products made of many separate components, the components
manufactured individually and later assembled into a finished article.
This practice permits one component of the article to be modified without
substantially altering the entire manufacturing process, and capitalizes
on the efficiencies of compartmentalization.
Using such component manufacturing practices, modifications made to a
single component to enhance its performance or implement innovative
technology not previously available, facilitate continuing product
development without compromising production output of an existing product.
These component manufacturing practices permeate the information and
computer processing industries.
Specifically, with the advent of the computer age, such "component" designs
proved essential in developing commercial automated computing systems,
which necessarily underwent hardware and software enhancements to
capitalize on new, previously undeveloped hardware and software
technology. But for the ability of the computer industry to apply these
traditional component development practices for larger, complex systems,
the rapid, widespread success of the modern computer system would likely
not have occurred. Throughout the design, development and implementation
of computer systems, maintenance of an operational, yet dynamic, system
configuration is instrumental in successfully developing and maintaining a
system of integrated data processing components, e.g., central processors,
printers, software applications and peripherals. Thus, effective
configuration management of these components and their operational
relationships between components becomes a vital requirement of the data
processing industry.
Early configuration management requirements were satisfied by crude, often
error-prone methods. In these early systems, to manage, for example,
untested software applications, system engineers generally establish
multiple, isolated and separate environments (sometimes on separate disk
storage units of a central processor), which are essentially complete,
stand alone versions of an entire system application. Enhanced system
applications, which often include necessary data "files", are migrated to
one or more of these separate "environments", depending on a development
step next required. When all components are migrated to an environment and
sufficiently tested, a new software "baseline" using a particular
environment is established. The "baseline" usually is a result of
physically copying relevant data files. The baseline copy is then
installed on other existing or new computer systems. Software versions and
releases developed by this conventional process are often manually copied
by a system operator from tape to disk, or other storage media in file
sets from a defined baseline.
Unfortunately, because the design, implementation and testing phases of
component development are typically of such long duration, by the time a
software release is delivered to a production environment, system changes,
occurring during component development necessitate that subsequent changes
be manually migrated, independent of a baseline release. As one might
expect, as the number of changes increases, complexity of managing the
release installation increases proportionally. What should be a simple
environment migration (copying of data files) instead, is an involved,
labor intensive process to ensure the integrity of a system configuration.
In conventional configuration management, manual installation of modified
components to a stabilized configuration demands specialized user
knowledge of the configuration. For example, if a software change, applied
to a stabilized configuration corrects a problem affecting system
operating parameters, the change would not take effect until the processor
had been "rebooted." In addition, a component modification, intended to
correct one problem, may introduce other errors if improperly installed.
Without knowledge of the environment and system configuration, an operator
cannot ensure the integrity of a configuration.
Conventional configuration management methods also maintain little
historical data on an operating system configuration. Using such methods,
debugging errors is difficult. The system does not maintain data
establishing which system configuration existed at point of system
failure, often making error identification, isolation, recreation and
resolution difficult or impossible.
Information system professionals have made numerous attempts to improve and
streamline software configuration management. One such effort includes a
software tool capable of automated installation or removal of software
components from any defined configuration. Although this automated system
addresses many of the drawbacks in previous configuration management
methods, it is limited to providing a set of written manual instructions
and procedures for one of three types of actions: 1) replace a resident
file version with a new file version; 2) add new files to the system; and
3) entirely remove resident files from the system, without replacing them
with new versions. (See Murtha, Amy J., "The Development of a
Configuration Control Tool," Electronic Systems Group, Westinghouse
Electric Corporation (August 1991). This automated configuration
management system, although facilitating configuration management,
functionally only installs and de-installs software files. The system is a
file manager and is capable of identifying a file version and acting on a
file version based on an SWC ("software change"). The system only
maintains information about a specific file related to an SWC and provides
no functional information about relationships of the files to other system
components (e.g., hardware and operating software).
Other efforts to address problems associated with conventional
configuration management have focused on procedures and mechanisms for
isolating software development environments. One such proposal, Software
Configuration Environment ("SCE") maintenance, involves establishing a set
of individual environments, procedures and tools for a specific
configuration. In this system, for each product release, one
self-contained environment is created per phase and the different phases
placed in a horizontal pipeline. Each environment is designed to be a
self-contained set of files under control of a Source Code Control Systems
(SCCS). See Banerjee, B., "Implementation of a Software Configuration
Environment," Switching Systems Division, Rockwell International
Corporation (July 1990).
In this system, each product release is designed to be composed of all
entities in the corresponding pipeline and each new release is an
extension of a previous release. Additionally, two, interconnected
databases track user level change requests and problem reports and
maintain records of resulting fixes in documents and code.
This configuration management design merely maintains information about an
environment dedicated to a specific version or release. It affords no
assistance in identifying, validating and verifying integrity of the
system's configuration for non-determinative updates to components in a
computer processing system. Although it contains information tracking
requests for changes to system functions or to correct processing errors
in the application logic, once changes are made in one of the many
individual environments, a complete new version of all entities in the
horizontal pipeline is required. System operators cannot determine whether
a new release will result in a product release incompatible with resident
software or hardware until after the new release has been dynamically
tested by users in that environment. Such a result exposes system
developers to allegations of poor testing and development practices and
often equates to significant computer downtime.
Although the disclosed software configuration environment eliminates some
of the above-mentioned draw backs, it requires that system operators have
a detailed knowledge of the functional application to organize and bundle
the system packages. In addition, no method for ensuring that all system
components are contained in a particular system configuration is provided.
Nor does the disclosed procedure address configuration management of
non-determinative replacement, substitution, addition or removal of a
component subset of a system configuration. It manages the configuration
as a whole unit. In non-determinative configuration management, as is true
of conventional methods discussed above, if a change to a single system
component requires installation or replacement of a complete copy of the
resident software, system maintenance costs rise higher proportionately.
The introduction of networks and decentralized processing environments adds
a significant level of complexity to managing system configurations across
distributed systems. In distributed architectures, system components are
not confined to a single, isolated processing environment. Compatibility
of system components and integrity of the environment require verifying
compatibility and ensuring integrity across multiple environments running
on various processing platforms.
Work station technology, networks and client-server architectures introduce
additional complexities in configuration management. The cooperative
nature of these distributed system architectures, having multiple remote
locations with each location operating independently of another location
and having separate system configurations, presented skilled artisans with
complex, unresolved configuration management issues.
In an attempt to address these new issues in configuration management,
presented by the more contemporary distributed computer processing
systems, Dean et al. developed a procedure for classifying areas subject
to and amenable to automated computer support. In their distributed
system, configuration and structure of the distributed system modeled is
described by defining structures, relations and components of a
distributed system.
Conceptually, one approach to configuration management in the distributed
process environment records and maintains information about a specific
distributed configuration, without enforcing rigid configuration control
policies. Once the information is recorded, a consistency checker might
examine the recorded information to highlight system irregularities. See
Dean et al., "Cooperation and Configuration Within Distributed Systems
Management," Computing Department, Lancaster University (March 1992).
Such a configuration management system fails to provide a method for
maintaining a system environment subject to non-determinative changes in
configuration. The disclosed method lacks a process for establishing
predetermined dependencies prior to performing any maintenance operation.
In the disclosed system, configuration and dependency information is
merely recorded and subsequently examined. Before or after system
maintenance, integrity of the configuration is not validated.
Another attempt to resolve many of the problems inherent in contemporary
heterogeneous platforms addressed disadvantages of multi-dimensional
platforms. See Perin, "Configuration & Software Distribution in
Maintenance Environments on Heterogeneous Platforms," Olivetti Information
Services (August 1991). Perin describes a procedure for maintaining a
system operating at various user locations in which the systems have quite
different configurations. The procedure establishes a centralized system
for identifying, resolving and implementing modifications to an existing
application or hardware system. The discussed procedure utilizes
conventional methods for managing a defined configuration. Separate
established environments contain isolated operating environments for
maintenance, testing and release of updated software versions and
releases.
Each environment provides a specific set of support functions depending on
an intended use for an environment: e.g., 1) developing and testing, 2)
testing only or 3) releasing. This procedure provides only for
identifying, documenting and resolving errors in a production system.
Perin does not discuss a procedure for maintaining the integrity of a
system configuration to prevent errors introduced into a user environment
during interface of a remote application with a central processor or
upgrading/downgrading of a remote location, independent of a shared
location.
In yet another configuration management alternative, Maymon discusses a
systematic set of modeling tools used in conjunction with object-oriented
modeling techniques to identify and classify subscriber service objects
managed by a management information base (MIB), operating under a network
switching element (NSE). See Mayman, "An Information Model for
Configuration Management of Switching Network Elements, Using OSI Tools,"
Bellcore (March 1991). The memory administration information model
presented and discussed in Maymon is a conceptual illustration of
groupings of various data elements within the service MIB of the NSE.
Mayman discusses a managed object class as an identified grouping of
managed objects which share certain characteristics, each class containing
a number of attributes whose values define the service profile of each
managed object. Composite managed objects result from containment
(aggregation) of superior and subordinate managed object classes.
The disclosed tools and techniques define objects required to provide a
customer a subscribed-for telecommunication service. The system is limited
to defining objects required to provide subscriber services. A disclosed
operating system retrieves attribute and other relevant information about
the managed objects. The disclosed system is a roadmap for the objects
managed by an operating system. If an object managed by the operating
system changes, the information model also changes. The disclosed system
is not capable of dynamically verifying and ensuring that an object is or
is not required to provide a specific service.
SUMMARY OF THE INVENTION
Thus, to overcome the limitations of conventional methods, the inventive
process provides a universal process for ensuring the compatibility of
components in a system, particularly in systems having many components
which undergo non-determinative enhancement. In the inventive process,
system components are first defined. After defining relevant system
components, compatibility relationships between two or more system
components are identified. From these identified compatibility
relationships, inter-relationships between at least two compatibility
relationships are determined.
The compatibility relationships and inter-relationships may be assigned a
dedicated control field, thus uniquely identifying each relationship and
inter-relationship identified. Once the relationships and
inter-relationships are identified, validating integrity of the
compatibility relationship and/or inter-relationship and, based on a
validating result, and maintaining integrity of the compatibility
relationships and inter-relationships defined, ensure compatibility of
system components in a system configuration.
Maintaining integrity of the compatibility may include taking one or more
corrective actions to re-establish the integrity of the compatibility
relationship or inter-relationship.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a State Diagram in an embodiment of a configuration management
system according to the invention.
FIG. 2 is a representative high-level process flow diagram for a full
software upgrade function.
FIG. 3 is a schematic representation of the system architecture for a data
processing system using an exemplary configuration management system.
FIG. 4 is a data flow diagram for the configuration management (CM)
application, represented in FIG. 2.
FIG. 5 is a data flow diagram for the CM application for a partial software
upgrade.
FIG. 6 is a representative high-level process flow diagram for a language
upgrade to the data processing system illustrated in FIG. 3.
FIG. 7 is a data flow diagram for the CM application for a language upgrade
.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
The present invention addresses and eliminates the drawbacks of
conventional configuration management methods for automated computing
systems by defining components of the system subject to redesign,
modification, removal or replacement in a system to which
non-determinative modifications occur. Representative system components
may include hardware, software applications and user languages. Once the
relevant components are defined, relationships between two or more
computing system components are identified. An exemplary relationship
might include, but is not limited to, identified compatibility between a
software application controlling printing of landscape document images and
a particular printer model which provides landscape printing. In this
example, the defined components are a 1) software application, and 2)
printer. A functional relationship requires that the software application
operate a specified landscape option.
Identifying relationships necessarily results in relationships between two
or more relationships or between a relationship and one or more
components, hereinafter referred to as inter-relationships. Determining
inter-relationships in the process according to the invention completes a
configuration definition. The defined configuration is a basis for
dynamically managing a system configuration.
Managing the configuration includes validating integrity of a relationship
or inter-relationship and based on a validating result, maintaining
integrity of a defined configuration, having relationships and
inter-relationships, and thus ensuring compatibility of system components
in the configuration. Configuration maintenance may include, but is not
limited to, notifying appropriate system operators of a relationship or
inter-relationship inconsistency or taking corrective action to
re-establish integrity of the configuration. A representative corrective
action may include restoring a specified component to a previous condition
or status, upon system detection of an error in a pre-determined
relationship.
Ensuring integrity of the defined system configuration may occur at
various, pre-selected times. For example, verifying and maintaining
defined configuration relationships and inter-relationships may occur when
a new system component is installed. Adding a new fixed disk drive
requiring enhanced-function operating software exposes a defined system
configuration to a potential operating error if the relationship of the
components are not verified. Thus, verifying and maintaining the integrity
of the configuration is necessary after upgrading the disk drive.
Subsequent verification and maintenance checkpoints may be required
depending on the significance of the relationship to be validated and
impact to the system if a relationship becomes corrupted between
checkpoints. Other exemplary opportunities for verification of
configuration integrity include 1) after an initial installation of a
complete system, 2) installation of one or more components in a system, 3)
a partial or complete downgrade of one or more system components (e.g.,
such as a hardware device or software application) to a previous version
of a system component, or 4) a partial or complete upgrade of one or more
system components to a later component version.
The process according to the invention is particularly useful when
non-determinative changes occur to one or more components in the system,
especially when the defined configuration includes components of different
versions, and even more so when the components defined to the
configuration are different releases.
Many problems of conventional configuration management systems arise
because insufficient information is maintained about a defined
configuration during operation. The present invention overcomes this
drawback of conventional methods, by optionally maintaining status
information about the state of a defined configuration during specific
periods, between pre-determined checkpoints. In a preferred method for
recording such information, maintenance of configuration integrity
includes writing data to a computer log. Such information may preferably
be utilized in subsequent integrity validations to eliminate redundant
validation processing.
A preferred embodiment of the inventive method is useful in eliminating
incompatibilities between resident software on the computer system and
migration software. This preferred method comprises defining resident
software and migrational software components used in the computer system,
identifying compatibility relationships between a first resident software
and at least one of a second resident software or migrational software and
determining compatibility relationships between at least one compatibility
inter-relationship and at least one resident software, migrational
software or another compatibility relationship. A dedicated control field
is assigned to each compatibility inter-relationship or compatibility
relationship and stored. Storing the dedicated control field permits
subsequent automated retrieval of the control field for use in periodic
integrity validation. Then, prior to performing a computer operation,
e.g., a hardware reconfiguration, software upgrade or user language
redefinition, the integrity of the computer system is validated by
identifying system incompatibilities.
Finally, incompatibilities identified in the integrity validation are
eliminated. Although alternatives exist for identifying incompatibilities,
a preferred method reads migrational software and resident software
identification data, verifies compatibility between resident software and
migrational software by comparing current configuration data against the
dedicated control field, and upon verification, updates current
configuration data for the migrational software, now "new" resident
software, in the computer system. Preferable computer operations are not
limited to migrational software installation, but may include a software
upgrade or downgrade.
Integrity validation in which incompatibilities are identified may occur
subsequent to performing a computer operation, and in response to an
identified incompatibility, integrity of the original configuration may be
maintained by restoring prior resident software to a previous, verified
configuration.
An embodiment of the present invention is illustrated by the following
non-limiting examples:
EXAMPLE 1
In an example of a configuration management system, a commercially
available computerized document production facility has a variety of
devices and applications, combined in multiple configurations over a range
of version levels with a variety of enabled features. In order to ensure
proper combination of the hardware, software and other components of the
document production system, the configuration management system
coordinates proper combination of components, including the version and
release levels, against enabled system feature sets.
In this example, the document production facility consists of components as
represented in FIG. 3. The system core is comprised of a central processor
unit (CPU) A. The central processor contains permanent disk storage
devices containing operational and other system parameter data, such as
data stored in Programmable Read Only Memory Storage (PROMS) J and K.
Other data, e.g. boot-up data and operating system logs are stored on disk
storage devices in the central processor.
The document production system application, running on the processor
invokes one of numerous application modules D stored on devices in the
processor. A document scanner G scans external data from documents.
Scanned data remains in disk storage managed by the processor. Printing
devices E and F are components of the document production facility and may
be invoked by specific functions performed by the processor or application
modules. Designated application modules D, stored on central processor A
provide a user interface H for interfacing with system users.
A tape device B provides for loading and backup of software applications,
loading of font data, backup of system information from the processor or
loading from a tape I, containing data or software L, to the processor or
storage devices.
In the configuration management system for this document production
facility, a configuration management state diagram is illustrated by FIG.
1. Prior to an initial installation of the document production system 101,
the system parameter files, e.g., J and K, are built, 100. During initial
installation, 101, configuration of an electronic sub-system occurs. Upon
completion of an initial installation, software applications and default
document production facility languages are defined to the system, 102.
From a language tape, using tape 1 (FIG. 3), primary and secondary
languages are initially loaded onto the central processor, 103.
The installed document production facility becomes the current
configuration, having established hardware components, a particular
software version and release for installed applications and designated
user languages, and is designated as such, 104. Upon obtaining an
initially configured system, system PROMS are updated and retain current
configuration information for subsequent use in validating integrity of
the system configuration, 106.
During the operational life cycle of the illustrated configuration
management system, modifications to application software, designated user
languages or system hardware necessarily result in system upgrades and
downgrades. In the application, CM (configuration management, 200)
functions as a controlling module, performing one of vario | | |
