PRIOR FOREIGN APPLICATION

This application claims priority from European patent application number 99126198.3, filed Dec. 30, 1999, which is hereby incorporated herein by reference in its entirety.

1. Technical Field

The invention relates to a system and a method for request based installation, customization and activation of software packages or products on a large computer system operated by a system control program.

2. Background Art

Large multi-user computer systems such as, for example, IBM OS/390, are sensitive about introduction of new software programs or services. These computer systems are used for many different applications. The same software programs/packages may need to be set up differently depending on what other software is installed and what applications they will be used for.

A straight forward and highly productive approach as used on workstations, where endusers usually install software packages themselves using an automated install process, is not feasible in large multi-user environments. This is mainly because typically thousands of endusers share such systems. Any failure during the installation process can jeopardize the availability or performance of the system, thereby impacting other users, or adversely impacting the protection of sensitive information belonging to the enterprise. Usually, dedicated technical staff is responsible for coordinating the use, administration and maintenance of such systems. Examples are installing and servicing of new software packages, authorizing access to sensitive or proprietary data, providing services and access from networks, organizing placement of databases, etc. Furthermore, many enterprises have multiple compute center sites. Often, the software setup process has to be repeated on each of those sites, because of slight variations in the computing environments.

Simpler software setup procedures are wanted in such complex environments. Such procedures should also enable and ensure enterprise specific responsibilities and policies.

Tools and processes available for workstations are not usable for this purpose. On workstations the process provides a simple dialog to give the enduser the ability to customize the software package or product and then executes a script to install and register the product. A typical example is the program ‘InstallShield Professional 2000 International’, distributed by InstallShield (R) Software Corporation, Chicago, Ill., USA. This program consists of a set of tools to be used by software package owners to condition the program packages and to facilitate the installation process by generating the dialogs and the installation script. Scripts are series of commands or a program usually written in the batch execution command language of the particular operating system to perform the actual installation and registration. This known program does not comprise provisions for IT staff to control and coordinate these actions. Such provisions are not supposed to be needed on workstations which are normally dedicated to one user.

SUMMARY OF THE INVENTION

It is an object of the invention to provide an improved software setup procedure for large computer systems.

It is also an object of the invention to provide a system and a method for a request based installation, customization and activation of software packages or products on a large computer system.

It is a further object of the invention to provide a system and a method which enables and ensures enterprise specific responsibilities and policies in connection with a request based installation, customization and activation of software packages or products on a large computer system.

The system according to the invention, as defined in the claims, comprises a setup infrastructure for coordinating the loading, customization, binding and activation of the program package or product to be installed. A plurality of exploiter plug-ins, each connected to one of said system resources, are used by the setup infrastructure means for creating a product definition, for providing customization dialogs and for supporting the initialization and modification of the program package or product to be installed. A plurality of supporter plug-ins are provided, each connected to selected ones of said system resources for supporting the binding procedure by providing bind services to the setup infrastructure. The supporter plug-ins are used by the exploiter plug-ins to establish binding to at least some of the program packages or products already installed, where the binding parameters needed by the exploiter plug-ins are indicated to the supporter plug-ins by Bind-Requests.

According to another aspect of the invention package adapter plug-ins are provided which identify various data formats, one of said third type plug-ins is assigned to a program product to be installed for indicating to the setup infrastructure the specific package formats as used by said program.

According to another aspect of the invention a management directory is connected to the setup infrastructure for storing all data associated with a particular software package or product and references to portions of said software package or product in a system library. These references are used by the setup infrastructure for accessing said data in a system library wherein said software package or product is stored.

Furthermore, according to the invention a method is provided, as defined in the claims, for request based installation, customization and activation of software packages or products on a large computer system.

Due to the declarative nature of bind requests and the capability to have a set of SI-supporters, the setup task will be much more complete. Support will not only exist to set system parameters, but there will also be supporters for areas like security, TCP/IP, etc. Therefore a program product can be taken into use after the request based software setup is complete without additional manual interaction.

Since properties are stored in the management directory, the plug-ins of the first type can provide intelligent customization dialogs. These dialogs can work with various sources of parameter values: defaults provided by the plug-ins of the first type, customization data from previous releases, primed data from the target system and customization data of other products. This can be used to achieve increased ease of use by offering a guided mode relying on defaults, further an intelligent migration support from an older to a newer program product release, an intelligent checking of prerequisites and corequisites, and an intelligent and ease of use customization by understanding the context in which a product will be used.

Since properties and bind requests can be exported and imported, and since bind requests contain references instead of copied values, installations can be replicated with minimal human interaction on the receiving side. This capability of replicating reference installation saves redundant effort for setup.

Due to the possibility of policy-based procedures, the customer's organization of authority for critical areas (security administration, database administration, network administration, etc.) are respected. If the customer changes his organization, the request based software setup can easily be adapted.

Since bind requests model a state of the system and since the plug-ins of the second type are strictly separated from the role of the first type plug-ins, the unbind of requests can be handled in a clean way: During reconfiguration, if old requests are replaced by other new requests, the plug-ins of the second type can verify that no other exploiter depends on the old request and eliminate its effects in the system resources so that no garbage will be left over. The same is true when removing a product from a system. The supporter can verify that no other exploiter depends on requests of the product to be removed, and then eliminate its effects in the system resources. Also in this case no garbage will be left over.

Due to its dynamic plug-in capabilities, the solution according to the invention is applicable as well to heterogeneous environments including computer systems of different manufacturers.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention is described with reference to drawings and to an application example. The drawings show:

FIG. 1

a flow diagram of a typical install process as executed on workstations;

FIG. 2

a general block diagram of an implementation of the invention;

FIG. 3

a functional representation of the setup infrastructure as shown in

FIG. 2

;

FIG. 4

a functional flow diagram of the setup process; and

FIG. 5

a data flow diagram of the bind request processing in the process of FIG.

4

.

BEST MODE FOR CARRYING OUT THE INVENTION

FIG. 1

relates to the prior art and shows how a typical program product install process is executed with a known workstation

8

being operated by a system control program

10

which includes a program installation, customization and bind component

11

and using a program source

12

, a dialog support

13

and a directory

14

. As indicated by connections

15

and

16

a program product is loaded from program source

12

into the workstation

8

. The dialog support

13

provides via connection

17

program customizing information which is stored in a directory

14

through connection

18

. By means of address information contained in the directory and by using the customizing information the program product is bound to the system control program of the workstation as indicated by the connections

19

.

It can be seen that the known install process is executed as one entity. The install process knows what has to be done and how this should be done. The install process actually changes the system according to implied rules, and is acting like a black box.

The request based processing according to the invention uses a different paradigm. It separates the ‘what is needed’ from ‘how’ and ‘when’. The customization process indicates via Bind Requests what is needed to get successfully installed. The activities involved in the process are coordinated by an infrastructure component which is part of the operating system and called herein setup infrastructure or abbreviated SI.

Definition of Terms

In this disclosure ‘setup’ is defined as the process to automate the installation, customization and activation of software packages or individual program products.

A ‘program package’ and ‘program product’ when used separately are herein synonyms, when used jointly these terms relate to a package containing multiple programs products as well as a single program product. Program products may be operating system components, utility programs or application programs.

‘System resources’ designates hardware and software components of the computer system comprising program packages and individual program products already installed on the computer system and in use.

An ‘image’ is a software entity which can be subject of an initial program load (IPL) operation and which usually comprises a plurality of program products.

‘IP’: Internet Protocol.

‘LDAP’: Lightweight Directory Access Protocol. A programming protocol adopted by the IETF (Internet Engineering Task Force) to access directories.

‘X.500’ defines the organization and working of directories according to the ISO OSI Directory Standard (CCITT Recommendation X.500). It is recommended by the International Telegraph and Telephone Consultative Committee.

‘CIM’: Common Information Model. A data model describing the parts a computer system consists of. CIM was defined by the Distributed Management Task Force (DMTF).

‘DMTF’: Distributed Management Task Force, a non-profit organization defining computer management related standards.

‘DB2’: A relational data base product of the IBM Corporation.

‘SMPE’: System Modification Program Extended. A system management program that is part of IBM's OS/390 Operating System.

‘File packs’: Collection of files to be installed. A term used mainly on Unix type systems.

‘Tar’: Tape archiver. A program used in Unix type systems for loading and unloading files.

‘Jar’: Java archive. A file format used by the Java language to bundle individual files.

The Principles of Operation

The setup process according to the invention can be divided into four phases:

1. The physical install process for loading down a program product without modifications from a source which may be a local or remote program library;

2. the dialog section for enabling customization options to be specified;

3. the bind process for applying customization options to the system resources and the program product; and

4. the activation process for making the customized product executable.

1 The Bind Process

In a clustered environment a plurality of computer systems can be grouped together forming a system cluster which is essentially a group of individual computers working together in a coordinated fashion to run a plurality of program systems. An example of a cluster system is an OS/390 Sysplex. From a setup point of view the individual program systems are called Images. As defined above, an Image is a software entity that can be subject of an initial program load (IPL) operation and that usually comprises a plurality of program products. The bind process binds a newly installed product or package to an existing Image. This means that the physical install process is done once for the whole cluster. The Bind and Activate phase will tie the new function to the individual images of the cluster. This is done either serially initiated by the system administrator one after the other, or in one operation to all Images. During the Bind process the system administrator defines which Image to bind to.

During Bind processing the libraries involved optionally will be replicated in order to minimize single points of failures. If this option is not chosen, the program libraries will be shared between Images.

The Bind concept can also be useful for single systems which are not part of a cluster. Normally enterprises have multiple Images for the purpose of test, production, backup and development. Also in this case selective Bind processing is an advantage.

A Bind Request describes a state of a system resource to be reached when the request is processed. The process handling is idempotent, meaning that when the resource already is in the requested state, the request will be ignored. Bind requests are always kept and associated with the software package that introduced them; because of the idempotency property they can be re-executed any time to facilitate partial or full recovery after a system crash without any further qualification. Bind processing can be controlled by policies that are defined to ensure that enterprise rules and regulations will be adhered to.

As part of the Bind process, the Product Instantiation program is called to enable the product to be installed to modify itself according to the customization properties.

2 The Setup Infrastructure

A preferred implementation of the invention as shown in the general block diagram of

FIG. 2

comprises a setup infrastructure

20

which is part of an operating system used to control a large computer system

21

of which in

FIG. 2

only the program library disks are represented. The large computer system

21

comprises a plurality of system resources including a plurality of processors and a plurality of program packages and individual program products installed in the system and activated to run on the system. These program packages and individual program products may be utility programs such as data base administration programs, communication controller or security packages. At least some of the program packages and individual program products have interdependencies among each other. Additional program packages or individual programs are loaded into the system

21

from a program source

22

. For these additional program packages or individual programs interdependencies have to be established to at least some of the program packages and products already installed in the system

21

. Three types of plug-ins

23

,

24

hand

26

are connected to the setup infrastructure

20

which are used by the setup infrastructure

20

to coordinate the software install process as described below in more detail. The setup infrastructure

20

is also connected to a management directory

27

which is used to store data of a program package or program product during the install process and thereafter. The management directory

27

thus contains data of the program packages and individual program products which were previously installed and contains references to code portions of these program packages and individual program products as included in the program library of system

21

.

The setup infrastructure

20

does not have specific knowledge on how to change and modify the system resources, nor does it know about program package formats, and it does not know in advance about program packages to install. The setup infrastructure

20

relies on the three types of plug-ins

23

,

24

and

26

which provide the required information for the installation process.

System resources providing bind support plug-ins

23

are called SI-Supporter plug-ins or short SI-Supporters. Software packages that use the Setup Infrastructure to get installed are represented by plug-ins

24

called SI-exploiter plug-ins or short SI-exploiters. The SI-Exploiters contain a package description and product description, customization dialogs and instantiation support serving to modify these components. The plug-ins

23

and

24

represented in

FIG. 2

as multiple blocks are in practice code portions which are stored in the system library of system

21

and accessed by the setup infrastructure

20

to perform the required services during the installation, customization and activation of software packages or products.

FIG. 3

shows a more functional representation of the setup infrastructure

20

and the related components. The setup infrastructure

20

provides generic services including install, customize, bind and activate services. An SI-Exploiter belongs to a certain program product or a certain package of program products to be installed and includes the following parts:

Product Definitions

31

which are a series of statements used to describe a particular SI-Exploiter product;

Customization Dialog

32

which is represented by a dialog program used to request interactively the actual values of customization data, i.e. the customization properties;

Product Instantiation

33

which is a program used to modify the SI-Exploiter product according to the customization dialog properties.

In addition, SI-Supporters are shipped as part of an SI-Exploiter.

FIG. 3

indicates some product examples such as WEB server, WEB browser, Transaction (TX) server, OS/390 components etc. Accordingly, there exist SI-Exploiters of program products or packages of program products already installed in the system libraries

35

which are part of the system

1

of FIG.

2

. The stored packages may include, for example, workload management programs, security packages, automation packages, networking packages, system control programs, etc. SI-Supporters

23

of the program products already installed as well as of program products to be installed support the bind phase of the install process.

Each SI-Supporters includes a Bind Support service program which provides bind services

34

that SI-Exploiters can use to get installed and registered properly. SI-Exploiters indicate to SI-Supporters via the customization dialog what they need by means of Bind-Requests. An SI-Exploiter can be an SI-Supporter as well. In this case the SI-Supporter services are available for other SI-Exploiters to use. SI-Supporters are SI-Exploiters as well, they play two roles: the SI-Supporter role for other SI-Exploiters and the SI-Exploiter role to get installed itself.

In general, there may exist many (i.e. hundreds) SI-Exploiters and much fewer (i.e. dozens) SI-Supporters. Examples of SI-Supporters are: system parameter support (PARMLIB), security packages (RACF), transaction monitors (CICS, IMS), data base administrators, workload management support (WLM), etc. These SI-Supporters help SI-Exploiters to setup the correct run-time environments.

Bind Requests are usually defined generically and are void of any specific supporter implementation detail. Because of this fact and because of the strict separation of exploitation and supporting roles, one can easily replace SI-Supporters with new software levels or equivalent competitive products without impacting SI-Exploiters. For example, considering bind support for directory services, an SI-Exploiter can define a new directory schema using the AddSchema bind request. For this example two different, mutually exclusive implementations of directory services are considered, one using a relational, the other a hierarchical database as backup store. Both will offer their own AddSchema bind support implementation, an exploiter will not notice the difference.

The software packages are described by using e.g. XML (Extended Markup Language) vocabulary itemizing the pieces it includes and defining requisite products it depends on.

Part of the product description are specifications of the customization dialogs and an indication whether it introduces SI-Supporter plug-ins as well.

A third type of plug-ins which are called Package Adapters plug-ins

26

or short Package Adapters (PA) define and understand specific package formats (FIGS.

2

and

3

). There exists a PA for each data format which installable program products may have. Examples of such data formats are SMPE, File Packs, TAR, or Java Jars. The Package Adapters

26

will transform their private data model to the data model defined by setup infrastructure

20

and store this transformed data into the management directory

27

. The setup infrastructure

20

includes a default Package Adapter which is used for the program load operation when the data format of the program to be installed is not yet known to the setup infrastructure

20

.

3 The Management Directory

An important part of the system described is the management directory

27

which is the storage of data and references as used by the setup infrastructure

20

for performing the install process. The management directory

27

may be an X.500 based directory that is accessed by using the LDAP protocol. The Data Model used by directory

27

is a CIM compliant data model proposed by DMTF. This data model is defined as an hierarchical structure which enables grouping of related data. For instance, all data that is associated with a particular software package or product is defined as subordinate data.

4 Product Definitions

An example of product definitions is shown below:

Package: e-business suite ....

Product: Web Server ....

File: abc Name: ws1.file Size: 15 MB ....

....

File: klm Name: wsX.file Size: 100 KB ....

CustDialog: WSdialogs ....

ProdInst: WS instantiation ....

BindSupport: AddWebApp ...

Properties: (default properties)

Product: Web Browser

File: uvw Name: wb1.file Size: 3 MB ....

File: xyz Name: wb2.file Size: 10 KB ....

CustDialog: WBdialogs ....

ProdInst: WB instantiation ....

Properties: (default properties)

The terms used in these Product Definitions have the following meanings:

‘Package’:

Identifying the beginning of a package

containing one or more program products.

‘Product’:

Identifying the beginning of product

definitions in a ‘Package’.

‘File’:

A reference to a file that is part of a

product. Multiple files can be part of a

product. The actual file itself is somewhere

else on the package media.

‘CustDialog’:

Identifies the Customization Dialog program,

it contains a reference to the file in which

the actual program can be found.

‘ProdInst’:

Identifies the product instantiation program,

it contains a reference to the file in which

the actual program can be found.

‘BindSupport’:

Identifies that a product contains Bind

support as well; it contains a reference to

the file in which the actual program can be

found.

‘Properties’:

Customization data for a program.

The product definition will be read during the install phase and placed into the management directory

27

. During the remaining setup phases, the product definition will be augmented with additional data and additional entries will be added to the definitions in the management directory

27

.

The hierarchy shown above is an example of two product definitions combined in one software package. Both products are SI-Exploiters, the first one is an SI-Supporter as well because it introduces bind support services which in this case serve the registration of new Web Server applications.

A part of the entries include references of attribute values stored in the system

21

. For instance, a bind request for adding a dataset name to a search path should not have the dataset name as value but a reference to the entry and attribute that defines the actual dataset name. This bind request may have the following format:

BindReq: AddToSearchPath (dsn: &Product: Web Server.Dataset: klm.Name).

In this case the actual value will be determined at bind time. The reason for this is to enable detection of users of values. In case the administrator has to change the actual dataset name, the setup infrastructure

20

can determine which other entries are depending on that value and, in such case, re-schedule the bind processing.

The Process

As shown in the functional flow diagram of

FIG. 4

the setup process

40

is subdivided into the four major phases install

41

, customize

42

, bind

43

and activate

44

which are invoked separately. At any point in time the effects of one phase can be undone.

1 The Install phase

The install phase

41

selects the appropriate Package Adapter

45

which will process the product definitions

46

and place them in the management directory

27

. At this point, the setup infrastructure

20

knows all about the program product which may be part of a program package, and it can use a standard dialog to determine where the libraries of the program product should be placed in the system

21

. The standard dialog should also be able to determine that all *install* requisites are able to be satisfied and to drive the appropriate installation program. During this phase the setup infrastructure

20

will register where to find the customization dialogs and the product instantiation program and whether the program product introduces a new SI-Supporter

23

.

Once the requisites have been verified and the install program has been invoked, the product definitions will be augmented with information about the status and where the libraries of the program product have been placed in the system

21

. For the example cited above the following status is achieved considering only the Web Server product:

Product: Web Server ....

Status: installed

File: abc Name: ws1.file Size: 15 MB Volume: APPVOL

....

....

File: klm Name: wsX.file Size: 100 KB Volume: APPVOL

....

CustDialog: WSdialogs ....

ProdInst: WS instantiation ....

BindSupport: AddWebApp ....

Properties: (default properties)

Herein ‘Status’ indicates the Setup status of a program product.

2 The Customize Phase

During the customize phase

42

the setup infrastructure

20

invokes the customization dialogs

47

of the selected products via the management directory

27

from the system

21

. The dialogs are written using a specialized XML vocabulary. The dialogs will offer the administrator the possibility to modify default settings and will then generate appropriate bind requests which are placed in the management directory

27

as well.

Because of the use of the management directory

27

the amount of information required to be specified by the human administrator of the system has been reduced. For example, DB2 customization currently requires the data set name for Language Environment libraries. After the install phase is extending to the Language Environment, this information is available in the management directory

27

and does not need to be requested by the administrator. Other information, like an IP HOSTNAME, can now automatically be satisfied, thereby further reducing the input required during customization.

The product status will be updated, the modified properties and the Bind-Requests will be added. For the example cited above the following status is thus achieved:

Product: Web Server ....

Status: customized

File: abc Name: ws1.file Size: 15 MB Volume: APPVOL ....

....

File: klm Name: wsX.file Size: 100 KB Volume: APPVOL ....

CustDialog: WSdialogs ....

ProdInst: WS instantiation ....

BindSupport: AddWebApp ...

Properties: (default and customization properties)

BindReq: Security (add authorized program wbserv) open

BindReq: DataBase (add table xyz, size 20M) open

BindReq: ExecProperty (automatic restart) open

Herein ‘BindReq’ means an entry, generated by the Customization Dialog program requesting specific bind support service.

3 The Bind Phase

As described before, binding is the process of tying a program package or product to an image. After the system administrator has indicated which image to bind to by setting up the appropriate bind requests, setup infrastructure

20

will examine these bind requests and invoke the corresponding bind service routines

48

in the management directory

27

. The invoked bind service routines

48

will examine the bind requests and perform the requested functions.

The bind service routines

48

also know how to activate the requests. Depending on the changes requested, there will be situations where a new IPL of the image is needed or where the image must be instructed to use new configuration files without re-IPL.

The Bind phase

43

also calls a Product Instantiation program

49

which enables the program product to be installed to modify itself according to the customization properties.

FIG. 5

shows the data flow of the bind request processing in form of the transfer of data to and from the management directory

27

. During the customization dialog

51

a Job name which, for example, may be BBOSR and belongs to a WEB Server

50

, is registered into the management directory

27

among the customization properties

52

of the product. As part of registering the product definitions, corresponding the SI-Exploiters produce Bind-Requests which are also stored in the management directory

27

. The Bind-Requests may refer to at least one SI supporter

54

which are invoked by the setup infrastructure

20

to be registered into the management directory

27

. By means of the product definitions bind support

55

indicates that the product offers bind support for other program products. In the example shown, there are SI-Supporters registered in the directory

27

for database, security, networking and WEB application packages. These SI-Supporters are made available to the product instantiation

59

and to the bind/unbind services

58

.

After successful processing of the bind requests the updated product definitions of the above example will look as follows:

Product: Web Server ....

Status: bound

File: abc Name: ws1.file Size: 15 MB

Volume: APPVOL ....

....

File: klm Name: wsX.file Size: 100 KB Volume: APPVOL ....

CustDialog: WSdialogs ....

ProdInst: WS instantiation ....

BindSupport: AddWebApp ...

Properties: (default and customization properties)

BindReq: Security (add authorized program wbserv) done

BindReq: DataBase (add table xyz, . . . size: 20M) done

BindReq: ExecProperty (automatic restart) done

Activate: Command (Set SearchPath klm, ... ) open

Herein ‘Activate’ means an entry, generated by the Bind support services for indicating specific actions needed to activate the program product being installed.

4 The Activation Phase

As the last step, the system administrator can ask setup infrastructure

20

to activate the WebServer of the above example. SI

20

will process the activate request as added to the management directory by the bind phase. The updated product definitions of the example will then look as follows:

Product: WebServer ....

Status: activated

File: abc Name: ws1.file Size: 15 MB Volume: APPVOL ....*....

File: klm Name: wsX.file Size: 100 KB Volume: APPVOL ....

CustDialog: WSdialogs ....

ProdInst: WS instantiation ....

BindSupport: AddWebApp ...

Properties: (default and customization properties)

BindReq: Security (add authorized program wbserv) done

BindReq: DataBase (add table xyz, size 20M) done

BindReq: ExecProperty (automatic restart) done

Activate: Command (Set SearchPath klm,...) done

Although the bind request and the activation request have been executed, all data associated with the product are kept in the management directory

27

and not removed.

Policies

An enterprise can use policies defining how bind requests are to be processed. It is possible to block particular bind requests until approval by a particular person. The approver can modify the bind request according to the enterprise rules. Examples are naming of entities or sizes of databases, execution privileges, etc. The approver can release the requests after modification or inspection. Bind processing will continue only when blocked requests are released by registered approvers.

Policy definitions are placed in the management directory

27

such as, for example:

Policies:

BindProcesssing:

Security: block Approver: (name)

DataBase: block Approver: (name)

ExecProperty: Inform: (name)

Support for Product Removal

Because all details about program products are kept in the management directory

27

, removal of program products from the system

21

is fully supported. The phases described above, except customization, will be executed in reverse.

‘Deactivate’ will undo the activation phase.

‘Unbind’ will undo the bind phase. The Unbind process understands the removal context and will reverse all Bind Requests associated with the product, whereby

‘use counts’ of system resource settings will be observed.

‘De-install’ will undo the install phase, thereby cleaning up all remnants of the product.

Support for Reference Systems and Export Function

Since all data pertaining to products is kept in the management directory

27

, the setup infrastructure

20

is able to export a completely customized program product or collections of program products. The setup infrastructure

20

will produce sets of files and the updated product description which contains all customization data. These sets of files can be shipped to other locations or systems. The export function will produce a software package that can be processed by the default package adapter

26

. Today, customers use various techniques to deploy software packages throughout their enterprises. The export function of the system and method according to the invention provides a structured means for customers to:

‘replicate’ a product or system when building a copy for maintenance;

‘replicate’ a product or system for a secondary test or production image;

‘replicate’ a product or system to a remote site. This enables large enterprises to consolidate parts of their IT staff into a central location. In this location products will be installed, customized and tested. When tests have proven the quality to be acceptable, the product can be exported and subsequently imported at remote sites.

‘promote’ a test image to production. It also enables vendors to deliver products in new, more efficient packages.

During the export process it can be defined whether customization will be allowed or restricted at the receiving location.

While the invention is described with reference to a preferred embodiment of the invention, modifications of this embodiment or other implementations of the invention are within the scope of the invention as defined in the claims.

The present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.

Additionally, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.

The diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.