Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for Updating Configuration Once

IP.com Disclosure Number: IPCOM000114972D
Original Publication Date: 1995-Feb-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 98K

Publishing Venue

IBM

Related People

McBrearty, GF: AUTHOR

Abstract

Disclosed is a proposed change to how updates are created and how they are applied to individual machines. The disclosed proposes that the apply process take into account the configuration changes that have already taken place on a machine and only make those changes that have not already taken place.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method for Updating Configuration Once

      Disclosed is a proposed change to how updates are created and
how they are applied to individual machines.  The disclosed proposes
that the apply process take into account the configuration changes
that have already taken place on a machine and only make those
changes that have not already taken place.

      An update image is a conglomeratino of files within a Backup
Format File (BFF).  Within a BFF are system files to be replaced,
configuration files that contain information about what changes must
be made to the running system, and apply only files that are used
during the apply and are then removed.  Updates work on a collection
of related files known as a subsystem or fileset and they are
normally cumulative in nature, that is they contain all changes to a
subsystem or fileset since the last base line was established.  The
archive file liblpp.a, a file within an update image, contains the
scripts that affect a system's configuration.

      Currently each update that is applied could replace/change the
configuration of a machine using one of these update scripts.  Since
updates are normally cumulative each successive update applied to a
machine would perform the same configuration change as its
predecessor(s).  The update scripts do not take into account the
changes that have already been made to a system.  This means that
every update could replace/change the configuration with an already
existing level.  This poses a problem for reject of applied or
cleanup of failed updates.  The reject and cleanup processes can and
will remove configuration changes that were made by a previously
applied update.  Currently it is difficult if not impossible to
determine if a configuration change has already been made by a
previously applied update.

      This proposal calls for a change to the packaging of updates
and the apply process for updates with respect to changing the
configuration of a running machine.  The packaging of update images
will include information that indicates what level the configuration
change was first introduced.  The apply process will look at the
information contained in the update image and compare it to the level
of the machine.  The level of the machine is stored in the Vital
Product Database (VPD).  From the comparison of the VPD and the
information in the image the update process can determine what subset
of configuration changes need to be performed.  This should save time
because fewer configuration changes will need to be made...