Browse Prior Art Database

Designs for Uncommitting an Install Plan Object

IP.com Disclosure Number: IPCOM000115939D
Original Publication Date: 1995-Jul-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 144K

Publishing Venue

IBM

Related People

Bunce, JL: AUTHOR [+2]

Abstract

Disclosed are two designs for allowing install plans of applications and workstations to be uncommitted for modification and/or reexecution. The burdens on network administrators have been rapidly growing in volume and complexity. Chief among them is the need for administrators to easily plan and execute the installation and configuration of software products on a group of workstations on a LAN. These designs for uncommitting an install plan can be used with any network planning, installation, and configuration program.

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

Designs for Uncommitting an Install Plan Object

      Disclosed are two designs for allowing install plans of
applications and workstations to be uncommitted for modification
and/or reexecution.  The burdens on network administrators have been
rapidly growing in volume and complexity.  Chief among them is the
need for administrators to easily plan and execute the installation
and configuration of software products on a group of workstations on
a LAN.  These designs for uncommitting an install plan can be used
with any network planning, installation, and configuration program.

      Using a network installation program, administrators can
construct install plans which indicate the applications that are to
be installed or configured on a group of workstations.  Once all the
applications, workstations, and other associated objects and their
attributes are specified, administrators can commit the install plan.
When an install plan passes through the commit portal, all the files
that are needed to install or configure the applications on the
workstations are created.  Typically, once the plan successfully
passes through the commit portal and the application actions are
being performed, the network installation program would delete the
install plan.  If administrators wanted to reuse a similar install
plan,
they would have to recreate the plan with the same types of objects.

      A better way of allowing the administrator to rerun the same or
similar plans would be to allow an uncommit of the plan.  There are
two possible scenarios for uncommitting a plan.  The plan could be
uncommitted back to the point where the objects were first added to
the plan or to the point just before the plan entered the commit
portal.  Both paths have their benefits and detractions, but a
network installation program could implement one or both routes to
allow the administrator the flexibility to reexecute a plan with less
recreation effort.

(1)  Uncommit to original objects

      The design implementation of the first route, uncommitting to
the point where the objects were first added to the plan, would mean
that the install plan object would have to keep a list of the
workstations, applications, their actions (such as install or
configure), and any other objects that may be associated with the
plan (such as customization files).  These instance lists would be
stored as attributes and in a hierarchical fashion where parent-child
object relationships existed.

      In the work area of the network installation program, the
administrator would have multiple applications and groups of
workstations defined.  The administrator would use these objects as
building blocks to create install plans.  Providing the workstations,
applications, and other associated objects are still defined in the
network install product when the administrator uncommits a particular
plan, the network installation program would reinstate the plan by
walking throu...