Note: Descriptions are shown in the official language in which they were submitted.
CA 02299850 2004-03-12
SYSTEM AND METHOD FOR THE MANAGEMENT
OF COMPUTER SOFTWARE MAINTENANCE
Field of the Invention
The present invention relates in general to computer software
maintenance and more specifically to a system and method for managing updates
to be
applied to computer software products.
Background of the Invention
Software vendors constantly update their computer software products
to maintain market and customer acceptance. The software updates may add new
features to the computer software product, remove unnecessary filed and/or
correct
existing problems, commonly referred to as bugs. In some cases, software
updates are
released on a regular basis by vendors. As a result, keeping track of the
software
updates can be difficult. Also, many vendors release different versions of the
same
computer software product. Different software updates may therefore be
required for
these different releases.
Presently, software vendors typically use one software program to
create, test and package software updates and a separate software program to
release
and install the software updates. Using separate programs to test and package
software updates and to release and install software updates, results in
software
updates being released to consumers without validating the appropriateness of
the
software updates for individual consumers.
It is therefore an object of the present invention to provide a novel
system and method for managing updates to be applied to computer software
products.
Summary of the Invention
In order to overcome the problems in the prior art, the system and
method of the present invention provide a single software module or tool to
manage
the packaging and tracking of software updates for multiple versions of a
software
application on a service system and to manage the installation, removal and
tracking
CA 02299850 2004-03-12
-2-
of software updates for multiple versions of a software application on a
target system
to maintain system integrity.
By including tools to track the execution of software updates on the
target system, the present invention is able to monitor the updates and
provide
assistance in case an error occurs during execution. If an error occurs,
execution of
the update may be restarted from the error point instead of from the beginning
to
provide automatic recovery from a failed update install.
Furthermore, the system and method of the present invention provide
tools to verify that the software update is applicable to the target system in
order to
maintain system integrity.
According to one aspect of the invention, there is provided a method of
updating computer software running on a target remote computer site using a
system
tool running on a vendor computer site that can be conditioned to a bundling
mode
and an install mode, said method comprising the steps of:
conditioning said system tool to said bundling mode and using said
system tool to create an update for said computer software; and
thereafter conditioning said system tool to said install mode and using
said system tool to apply said update to the computer software running on said
target
remote computer site, during said applying said system tool performing rule-
based
checks to verify the integrity of said update and performing automatic failed
service
recovery when an installation error occurs thereby to inhibit the computer
software
running on said target remote computer site from being compromised by
application
of said update thereto.
According to another aspect of the invention there is provided a
method of updating computer software running on a target remote computer site
using
a system tool running on a vendor computer site that can be conditioned to a
bundling
mode and an install mode, said method comprising the steps of
conditioning said system tool to said bundling mode and using said
system tool to create a service bundle for said computer software, said
service bundle
including one or more update files and control files associated with said
update files
CA 02299850 2004-03-12
-3-
that identify target directories for said update files and the location of
archived files
stored in a service history database maintained by said system tool; and
thereafter conditioning said system tool to said install mode and using
said system tool to apply said service bundle to the computer software running
on said
target remote computer site, during said applying said system tool performing
rule-
based checks to verify the integrity of said service bundle and performing
automatic
failed service recovery when an event failure occurs during installation of
said service
bundle thereby to inhibit the computer software running on said target remote
computer site from being compromised by application of said service bundle
thereto.
In yet another aspect of the invention there is provided a computer
readable medium having a computer program embodied thereon for updating
computer software running on a target remote computer site, said computer
program
for running on a vendor computer site and being conditionable to a bundling
mode
and an install mode, said computer program including:
computer program code for creating an update for said computer
software when said computer program is conditioned to said bundling mode; and
computer program code for applying said update to the computer
software running on said target remote computer site when said computer
program is
conditioned to said install mode, said computer program code for applying
performing
rule-based checks to verify the integrity of said update and performing
automatic
failed service recovery when an installation error occurs thereby to inhibit
the
computer software running on said target remote computer site from being
compromised by application of said update thereto.
In still yet another aspect of the present invention, there is provided a
computer readable medium having a computer program embodied thereon for
updating computer software running on a target remote computer site, said
computer
program for running on a vendor computer site and being conditionable to a
bundling
mode and an install mode, said computer program including:
computer program code for creating a service bundle for said computer
software when said computer program is conditioned to said bundling mode, said
service bundle including one or more update files and control files associated
with
CA 02299850 2004-03-12
-4-
said update files that identify target directories for said update files and
the location of
archived files stored in a service history database maintained by said system
tool; and
computer program code for applying said service bundle to the
computer software running on said target remote computer site when said
computer
program is conditioned to said install mode, said computer program code for
applying
performing rule-based checks to verify the integrity of said service bundle
and
performing automatic failed service recovery when an event failure occurs
during
installation of said service bundle thereby to inhibit the computer software
running on
said target remote computer site from being compromised by application of said
service bundle thereto.
Brief Description of the Detailed Drawings
A preferred embodiment of the present invention will now be described
more fully with reference to the accompanying drawings, in which like numerals
denote like parts throughout, and in which:
Figure 1 is a schematic diagram of a service bundle;
Figure 2 is a flowchart showing a service bundle creation process;
Figure 3 is a flowchart showing a service bundle installation process;
Figure 4 is a flowchart showing a service bundle removal process;
Figure S is a flowchart showing a self service file process;
Figure 6 is a flowchart showing a basic service rules check process;
Figure 7 is a flowchart showing a service file relationship check
process;
Figure 8 is a flowchart showing a loadtime failure recovery process;
Figure 9 is a flowchart showing a recover on pre-service command
failure process;
Figure 10 is a flowchart showing a recover on post service command
failure process;
Figure 11 is a flowchart showing a recover on failed file copy process;
and
CA 02299850 2004-03-12
-5-
Figure 12 is a flowchart showing a recover on failed database
transaction process.
Detailed Description of the Preferred Embodiment
S ~ As mentioned above, software vendors typically release software
updates to customers on a continuing basis to enhance computer software
products.
Generally, the software updates correct existing and/or foreseeable bugs,
enhance
applications and/or add new features. To manage computer software product
updates
in this environment, the present invention provides a system and method for
packaging, tracking, installing and removing computer software updates for a
computer software product having multiple versions. A preferred embodiment of
the
present invention will now be described.
The present invention provides a service system tool to allow computer
software product updates or "service items" to be created, tracked and
packaged on a
vendor's computer site and to allow computer software products on customer
computer sites to be tracked and updated with appropriate service items. The
service
system tool is operable in a bundler mode and in a tool mode. Specifically,
the service
system tool is conditioned to the bundler mode on the vendor's computer site
when it
is desired to create, manage and package service items for installation on
target
customers' computer sites. The service system tool is conditioned to the tool
mode
when it is desired to install and track the service items on target customers'
computer
sites. The service system tool also includes a command line interface to
record
service item installations in a service history database. In the tool mode,
the service
history database includes computer product version information and applied
service
item information. In the bundler mode, the service history database tracks
service
items available to versions of the computer software products.
In the bundler mode, the service system tool creates, manages and
packages service items into service bundles. Turning to Figure 1, a schematic
representation of a service bundle is shown and is generally identified by
reference
numeral 1. As can be seen, service bundle 1 includes a service type
information
section 3, which identifies the type of software update, or updates in the
service items
CA 02299850 2004-03-12
-6-
associated with the service bundle. The service bundle 1 also includes a
service
levellhot fix information section 4. Section 4 includes information concerning
the
service status of the service bundle i.e. Beta version, Alpha version or
released
version. Section 4 also includes information relating to the smallest service
item
within the service bundle.
The service bundle 1 also includes a files/updates section 5 storing
service item files making up the service item. A service control files section
6 stores
control files associated with the service items files. The service control
files are used
to control the operation of the various service types of the service bundle.
The name
of each service control file is based on the service level and a description
of the
service item file. In the present embodiment, the service control files can
include
service map files, service command files, service history database entry files
and
service fix list files.
Service map files list the service item files included in the service
bundle 1 and the target directory for each service item file. During
installation of the
software update, outdated service item files, from previous updates, are
archived and
replaced by the update files. The service map files store the locations of the
archived
files in case the archived files have to be restored due to an error during
the
installation of the software update. This property is intended to maintain
system
integrity.
The service command files aid in the parsing of contents of service
commands and for executing service commands. Examples of service commands
include installation and removal programs used in connection with the service
bundle.
The service history database entry files store pertinent information
concerning updates
in a database entry file. They also store information in a bundler section of
the service
history database during service bundle creation and information in a tool
section of the
service history database during installation of the service bundle. The
service history
database entry files also maintain information relating to the
installation/removal of
service bundles.
Service fix list files list the service item files contained in the service
bundle. The service items are placed in a service fix list during service
bundle
CA 02299850 2004-03-12
creation. The service fix list control file uses the service fix list during
installation or
removal of the service bundle.
The service bundle 1 also includes a name field 7 identifying the
service bundle. The name of the service bundle 1 is created by combining the
service
level information and a description of the service item, to yield a file name
that is
unique for the service bundle. The file extension of the service bundle
indicates
whether the service bundle includes new service items to be installed or
archived
service files to be re-installed. In the preferred embodiment, a .CSB
extension
denotes a service bundle that installs new service item files while a .CSA
extension
denotes a service bundle that re-installs archival service item files.
The service bundle 1 also includes a target directory representing the
location on the vendor computer site where the software update is to be stored
and
executed.
Turning to Figure 2, a flow chart displaying the steps performed during
creation of a service bundle using the service system tool is shown. It will
be
understood that during creation of the service bundle, the system service tool
is
conditioned to the bundler mode. Firstly, at step 10, creation of the service
bundle is
initiated. Afterwards, at step 12, the service type of the service bundle is
selected. If
the service item is to contain service item files relating to more than one
software
update, more than one service type may be selected. Service level and/or hot
fix
information is then selected for the service bundle at step 14 and a basic
packaging
rules check is executed at step 16 to verify that the service level of the
service bundle
matches the service level of the computer software product to which the
service
bundle is to be applied. If the service bundle fails the basic packaging rules
check,
service bundle creation is halted (step 18).
If the service bundle creation passes the basic packaging rules check,
the appropriate service item files making up the service item are selected for
inclusion
in the service bundle and the service bundle is named (step 20). Target
directories for
the service item files are then selected (step 22). Afterwards, a set of
service control
files is created (step 24). If an error occurs during the creation of the
service control
files, service bundle creation is halted (step 26). Otherwise, the service
bundle is
CA 02299850 2004-03-12
_g_
compressed and stored in a zipped file format (step 28). If an error occurs
during
service bundle compression, service bundle creation is halted (step 30). Once
the
zipped service bundle is created, the zipped service bundle is logged and
stored in the
service history database (step 32) and the service bundle creation program is
exited
(step 34).
Once the service bundle has been created and stored in the service
history database, the service bundle may be distributed to the target customer
computer site for installation.
Figure 6 better illustrates the steps performed during the basic
packaging rules check. During the basic packaging rules check, the service
bundle is
first tested for failed service recovery (step 159). The test is performed to
determine if
the service bundle is able to support recovery from errors during the
installation or
removal process. If the service bundle passes this test, the basic packaging
rules
check is exited (step 160). If the service bundle fails the service recovery
test, the
service level of the service bundle is determined (step 162). If a bad service
bundle is
detected, the basic packaging rules check is exited (step 164) and service
bundle
creation is stopped (step 168). Otherwise, the current service level of the
service
bundle is determined from the service history database (step 166). If a
database error
is detected, the basic packaging rules check is exited (step 168) and service
bundle
creation is halted (step 18). If no database error is detected, the service
bundle level is
compared with the service level required by the target customer computer site
(step
170).
This comparison is used to verify that the service item stored in the
service bundle is appropriate for the target customer computer site. If no
match is
found, the basic rules packaging check is exited (step 172) and the service
bundle
creation is halted (step 18). Otherwise, the service bundle is considered to
have basic
packaging rules check and the basic packaging rules check is exited (step
173).
Turning to Figure 3, a flowchart outlining the process for installing the
service bundle on a target customer computer site using the service system
tool is
shown. It will be understood that during this process the service system tool
is
conditioned to the tool mode. Initially, the target customer computer site
accesses the
CA 02299850 2004-03-12
-9-
vendor computer site through a dial-up or Internet connection and initializes
the
installation process (step 35). At this point, the service bundle to be
applied to the
target customer computer site is selected (step 36).
A basic service rules check is then performed (step 38) to verify that
the service bundle is appropriate for the target customer computer site. If
the service
bundle fails the basic service rules check, installation of the service bundle
is halted
(step 40). Otherwise, the service control files are extracted from the service
bundle
(step 42). If the service control files are not correctly extracted,
installation of the
service bundle is halted (step 44). If no errors arise during extraction of
the service
control files, the service control files are checked for self service, or self
executable
files (step 46). In most cases, icons are selected in order to execute a
program but, in
some cases, files are self executing and therefore, no icons need to be
selected. If a
self service file is detected, the file is immediately executed, by a self
service module,
at step 48 as will be described.
If there is no self service file present, the service control files are
parsed (step 50) to determine the service bundle level along with its
contents. If a
failure occurs while parsing the service control files, installation of the
service bundle
is halted (step 52). Otherwise, a service files relationship rules check is
performed
(step 53). If the service files relationship rules check fails, service bundle
installation
is stopped (step 54). Otherwise, outdated service item files, from previous
service
bundles, are replaced with new service item files (step 56). At this point,
the service
bundle changes from a .CSB extension to a .CSA extension. The outdated service
item files that have been replaced are archived in the service map file. This
allows the
previous version of the computer software product to be restored. Information
concerning the location of the archived files and also their original location
is stored
in the service map file. If the archiving process fails, service bundle
installation is
halted (step 58)
Following the file archiving process, pre-apply service commands are
executed (step 60). If a failure occurs, a pre-apply service command failure
recovery
program is executed at step 62 to correct the failure. The pre-apply service
command
failure recover program will be described below. Otherwise, each of the
service item
CA 02299850 2004-03-12
-10-
update files is copied to its target directory (step 64). If a failure occurs,
a file copy
failure recovery program is executed at step 66 to correct the file copy
failure. The
file copy failure recovery program is described below. If the service item
files are
correctly copied, post-apply service commands are executed (step 68). Failure
to
execute the post-apply service commands results in the execution of a post-
apply
service command failure recovery program at step 70 to correct the service
command
error. The post-apply service command recovery program is described below.
Upon successful execution of the post-apply service commands,
service bundle installation is checked to determine if it is a result of a
failed service
recovery (step 72). If it is a result of a failed service recovery,
installation of the
service bundle is complete (step 74). Otherwise, the service history database
is
updated to indicate that the service bundle was successfully applied to the
target
customer computer site on the date/time, at step 76. If an error occurs during
the
service history database update, a database transaction failure recovery
program is
executed at step 78. If the service history database is successfully updated,
installation
of the service bundle is complete (step 80). As will be appreciated, each step
of the
installation process of the service bundle is tracked to ensure integrity. If
an error
occurs during installation, recovery programs are executed as will be
described further
herein.
Figure 4 is a flow chart detailing the steps for removing a service
bundle from a target customer computer site. Once, the removal process has
been
initiated (step 81 ), the service bundle to be removed is selected (step 82).
A basic
service rules check is then performed on the selected service bundle (step
84). If the
service bundle fails the basic service rules check, service bundle removal is
halted
(step 86). Otherwise, the service control files are extracted from the service
bundle
(step 88). Service bundle removal is also terminated if an error occurs during
extraction of the service control files (step 90). If no error occurs, the
service bundle
is checked for self service files (step 92). If a self service file exists,
the service
bundle removal program enters a self service operation module (step 94).
Otherwise,
the service control files are parsed (step 96). If an error occurs during the
service
control file parsing, service bundle removal is stopped (step 98). If no error
occurs, a
CA 02299850 2004-03-12
-11-
service files relationship rules check is performed (step 100). If the service
files
relationship rules check fails, service bundle removal is halted (step 102).
If the service files relationship rules check passes, pre-remove service
commands are executed (step 104). If a failure occurs during command
execution, a
pre-remove service command failure recovery program is executed at step 106.
If no
failure occurs, each of the service item files is copied to its target
directory (step 108).
If a failure occurs, a file copy failure recovery program is executed at step
110.
Otherwise, post-remove service commands are executed (step 112). If the post-
remove service commands cannot be executed, a post-remove service command
failure recovery program is executed at step 114. If the post-remove service
commands are successfully executed, the service bundle execution is monitored
to
determine if it is a result of a failed service recovery occurred (step 116).
If it is a
result of a failed service recovery, the service bundle removal is considered
to be
completed and the process is exited (step 118). Otherwise, the service history
1 S database is updated to indicate that the service bundle was successfully
removed, at
step 120. If an error occurs during the service history database update, a
database
transaction failure recovery program is executed at step 122. If the service
history
database is successfully updated, the service bundle removal process is
completed
(step 124).
Figure 5 is a flow chart showing the steps performed to deal with self
service files. When a self service file is detected, the self service module
is initiated
(step 125). The self service module attempts to obtain service mutex from the
target
customer computer site (step 126). This causes the actions of the service
bundle to be
mutually exclusive and run independently with respect to other computer
applications.
If the self service module is unable to obtain service mutex, execution of the
self
service file is halted (step 128). Otherwise, the target customer computer
site registry
is checked to monitor the progress of the request for service mutex. (step
130). If the
target customer computer site returns a message of nothing to do or
uncorrectable
failure, execution of the self service file is halted (step 132). If service
mutex is
received, the self service file is extracted from the service bundle (step
134). An
CA 02299850 2004-03-12
-12-
extraction failure results in the termination of self service file execution
(step 136).
Otherwise, the service control files are parsed (step 138).
If an error occurs during parsing of the service control files, self
service file execution is halted (step 139). If no error occurs, a service
file
relationships rules check is performed (step 140). Failure to pass the service
file
relationships rules check, results in the termination of self service file
execution (step
142). Upon passing the service file relationships rules check, the outdated
service
files from previous service bundles that are replaced by the self service
files are
archived (step 144). If the file archive process fails, execution of the self
service file
is halted (step 146). Otherwise, at step 148, the self service file is copied
to its target
directory (step 148). If a failure occurs during copying, the file copy
failure recovery
program is executed (step 1 SO). If no copying errors occur, the service
system tool is
launched to complete service operation by installing the service item file
(step 152).
If the service system tool is unable to launch, execution is halted (step
154). Once the
service operation has been completed the service mutex is returned to the
target
customer computer site (step 156) and the self service module is exited (step
157).
In order to monitor and verify integrity, the service system tool utilizes
two separate methodologies. One methodology is based on rules based service
operations and the other is based on automatic failed service recovery. The
implementation of these methodologies causes an integrity check to be
performed at
almost every step during the creation, installation and/or removal of a
service bundle.
The rules based service operations perform checks during all service
operations to ensure that target customer computer site integrity is not
compromised
as a result of the installation or removal of a service bundle. These
operations are
specific to service operation types. The basic packaging rules are implemented
so that
no service bundle is created, which duplicates a service bundle stored in the
service
history database. This is achieved by using a unique service bundle naming
procedure. System integrity is also maintained since the contents of the
service
bundle cannot be changed after the service bundle has been created and logged
in the
service history database.
CA 02299850 2004-03-12
-13-
The steps performed during the service files relationships rules check
are shown in Figure 7. This check is performed to verify that application of
the
service bundle does not cause a regression of a previous service item and/or
to verify
that installation of the service bundle does not cause improper removal of a
pre-
y requisite service item. This check also monitors the actions of files during
installation
of the service bundle.
Once initiated (step 174), a failed service recovery test is performed
(step 174). If this test is passed, the service bundle returns to the function
from which
it exited (step 176). If the test is not passed, the service bundle begins a
loop to search
through the service bundle files for the service map control file (step 178).
Version
information is then read from the target customer computer site and the
service item
files (step 180). If a file read error occurs, the service files relationship
rules check is
exited (step 182). Otherwise, the archived service item files stored on the
target
customer computer site are compared with the service item files stored in the
service
1 S bundle (step 184). If a required software service item file is missing
from the service
bundle, a check is performed to see if the service item file is being
installed or
removed (step 186). If a match is found, the service files relationship rules
check is
exited due to the presence of a regression (step 188). Otherwise, the target
customer
computer site prerequisites are compared with the service item files in the
service
bundle (step 190).
After comparing the target customer computer site prerequisites, if a
prerequisite is missing, a check is performed to see if the missing
prerequisite is being
installed or removed (step 191). If a match is found, the service files
relationship
rules check is exited due to the presence of the missing prerequisite (step
192).
Otherwise, the prerequisites of the service item are compared with the
prerequisites in
the archived service item files (step 194). This step also occurs after the
comparison
between the target customer computer site prerequisites and the service item
files
when no missing prerequisite is located. Prerequisites are used to verify that
the
installation of the service bundle is appropriate for the target customer
computer site.
For instance, if a target customer computer site is running version S of an
application
CA 02299850 2004-03-12
-14-
and the service bundle is providing an update to version 4, then installation
of the
service bundle is not appropriate.
If there are any unmet target customer computer site prerequisites, a
check is performed to see if the missing target customer computer site
prerequisites
S are the ones being applied or removed (step 196). If the result is negative,
the service
files relationship rules check is exited (step 198). Otherwise, other service
item files
that need to be checked are determined (step 200). If more service item files
need to
be checked, the module returns to step 178 to search through the remaining
service
item files listed in the service map control file. Otherwise the service files
relationship rules check is passed and a message is returned to the function
from
which it exited (step 202).
The service system tool also verifies the appropriateness of a service
bundle, as well as, correctness of execution based on the automatic recovery
from
failed service methodology. Examples are shown with respect to Figures 8 to
12.
Figure 8 shows a loadtime recovery process to monitor the service
bundle installation and removal processes for errors. If an error occurs, the
loadtime
recovery process attempts to solve the problem and allow, upon fixing of the
problem,
the service bundle installation or removal to continue from the point where
the error
occurred instead of requiring the process to restart. Once the loadtime
recovery
process is initiated (step 203), a test is performed to check for the presence
of any
other loadtime recovery processes (step 204). If another loadtime recovery
process is
being executed, the present loadtime recovery process is halted (step 206).
Otherwise,
a test for service in progress is performed on the target customer computer
site (step
208). If the loadtime recovery process does not locate any errors, the
loadtime
recovery process is halted since no recovery is necessary (step 210).
Otherwise, a test
is performed to find out what type of recovery is necessary (step 212).
If no recovery appears necessary, the loadtime recovery process is
stopped (step 214). Otherwise, a failed service operation (step 215) and a
failed
service step (step 216) are invoked. The failed service operation (step 21 S)
determines which process was being executed when the error occurred and the
failed
service step (step 216) determines at which step the error occurred. A check
is then
CA 02299850 2004-03-12
-15-
performed to see if the failure is recoverable (step 217). If recovery is not
possible,
the loadtime recovery process is halted and installation or removal of the
service
bundle is restarted (step 218). Otherwise, the loadtime recovery process
locates where
the error occurred (step 219) and executes routines necessary to fix the
error. This
includes, but is not limited to the failed pre-service command recovery
program (step
220), the failed post service command recovery program (step 222), the failed
service
file copy recovery program (step 224) and/or the failed database transaction
recovery
program (step 226). Afterwards, the loadtime recovery process verifies that
the
recovery was successful (step 228).
As described above, during installation or removal of a service bundle,
various failure recovery processes are executed based on event failure. One
such
process is the pre-service command failure recovery as shown in the flowchart
of
Figure 9.
Upon initiation of the command failure recovery process (step 233), the
service bundle is checked to see if the function from which it exited was the
installation process (step 234). If the function is not the installation
process, the post
apply service command is executed at step 236. Otherwise, the post remove
service
command is executed at step 238. After execution of either service command, a
check
is performed to verify that the service command was successfully executed
(step 240).
A message is then returned to the function from which it exited indicating
whether
execution of the service command execution was successful (step 242) or a
failure
(step 244). If the service command execution is successful, the function from
which it
exited continues from the point where the error occurred.
The post-service command failure process is shown in Figure 10.
Once the post-service command failure process is initiated (step 245), the
service
bundle is checked to see if the function from which it exited was the
installation of the
service bundle (step 246). If the function from which it exited is not
installation, the
service bundle is re-instated (step 248). Otherwise, the execution of the
service bundle
returns to the start of the remove service (step 250). Afterwards, a check is
executed
to verify that the service command was successfully executed (step 252). A
message
is then returned to the function from which is exited indicating whether the
service
CA 02299850 2004-03-12
-16-
command execution was successful (step 254) or a failure (step 256). If the
service
command execution is successful, the function from which it exited continues
from
the point where the error occurred.
The service file copy failure recovery process is shown in Figure 11.
Once this recovery process is initiated (step 257), the service bundle is
checked to see
if the function from which it exited was installation of the service bundle
(step 258).
If the function from which it exited is not installation, the service bundle
installation
returns to the apply service (step 260). Otherwise, the execution of the
service bundle
returns to the start of the remove service (step 262). Afterwards, a check is
executed
to verify that the service operation was successfully executed (step 264). A
message
is then returned to the function from which it exited indicating whether the
service
command execution was successful (step 266) or a failure (step 268). If the
service
command execution is successful, the function from which it exited continues
from
the point where the error occurred.
The database transaction failure recovery process is shown in Figure
12. After initiation of the database recovery process (step 269), the service
bundle is
checked to see if the recovery mode was inline (step 270). An inline recovery
process
is a method to write progress and diagnostic information during a service
operation in
a form from which a failing operation can be determined. If the function from
which
it exited is not inline, a partial record is removed from the database (step
272).
Otherwise, the entire transaction is rolled back and restarted (step 274).
After
execution of either database transaction, a check is executed to verify that
database
integrity is restored (step 276). A message is then returned to the function
from which
it exited indicating whether the database integrity has been restored (step
278) or not
restored (step 280).
It will be appreciated that, although only one embodiment of the
invention has been described and illustrated in detail, various changes and
modification may be made. All such changes and modifications may be made
without
departing from the spirit and scope of the invention as defined by the claims
appended
herein.
