Browse Prior Art Database

Design of the Commit Install Plan Process for a Network Installation Program

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

Publishing Venue

IBM

Related People

Bunce, JL: AUTHOR [+3]

Abstract

Disclosed is a design for committing an install plan object for execution by the administrator on the target workstations in the plan. The burdens on network administrators have been rapidly growing both in volume and in 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. This process for committing install plans 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.

Design of the Commit Install Plan Process for a Network Installation
Program

      Disclosed is a design for committing an install plan object for
execution by the administrator on the target workstations in the
plan.  The burdens on network administrators have been rapidly
growing both in volume and in 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.  This process for committing install plans can be used with
any network planning, installation, and configuration program.

      An install plan object in a network installation program would
be composed of one to many application-in-plan objects and one group
in plan object which contains one to many workstation-in-plan
objects.  An install plan object would define what applications an
administrator wants to install or configure on a group of
workstations.  Each object would have further subobjects that are
used in the commit process and these objects will be described below.

The following would be the process for committing an install plan:
  1.  Create a log file to record errors, warnings, and status
       messages encountered during the commit process.
  2.  Validate the install plan.  This includes such checks as
insuring
       that response files specified in the plan physically exist on
a
       local or LAN drive and that code servers were defined for
       applications so that their images could be obtained from the
code
       servers during the installation or configuration process.
    This stage of the process prevents errors from occurring
   later in the commit process that could have been caught earlier
   with the initial plan information.  It also centralizes the
   validation checks at one stage in the process.
  3.  Apply customization files.  Administrators can create
       customization file objects and associate them at an
application
       in plan or group-in-plan level.  Customization files allow
       administrators to specify multiple response file keyword
values
       for workstations in a spreadsheet-like format.  These files
allow
       administrators to modify several response files at one time
       without the administrator having to manually edit each one.
    This stage of the process generates instance response files
   for all class response files that may remain for workstation
   application in plan objects.  This generation involves copying
   the class response file to another file with a unique file name.
   A response file can be at a class or an instance state.  Response
   files that are initially brought over to the plan are at a class
   state.  After an administrator edits a response file under a plan
   object, its state can change from class to instance.  Once
   instance response file...