Preparing your result...
Loading...
Press Esc to dismiss this message

A method for updating read-only file system artifacts (16-Jul-2009)

Thumbnail
IP.com Prior Art Database Disclosure (Source: IPCOM)
Disclosure Number IPCOM000185218D dated 16-Jul-2009
Originally published in Prior Art Database
Disclosed by: IBM
Country: Undisclosed
Disclosure File: 2 pages / 37.7 KB / English (United States)

Re-using an existing software product installation for multiple instances is an important concept in shared systems like IBM® System z®. All artifacts that make up the product are located either in a read-only installation file system or a readable and writeable configuration file system. Artifacts not meant to be changed during product configuration usually reside on the installation file system that can be shared among multiple instances of the product. This publication describes a method that allows modifying read-only artifacts, without affecting other instances that share the same installation file system.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

A method for updating read-only file system artifacts

Re-using an existing software product installation for multiple instances is an important concept in shared systems like System z. The product installation usually consists of a number of files ("libraries"). For instance, IBM WebSphere ® Application Server uses a read-only file system ("installation file system") for the product files and a readable and writable file system for configuration artifacts ("configuration file system"). The traditional method for reusing the installation file system with multiple product instances is an overlay of each instances' configuration file system and a shared installation file system by means of creating symbolic links in the configuration file system that point to artifacts in the installation file system.

While this is a great system for reuse, it means that all configuration file systems which link to the shared installation file system will share the very same version of libraries as they are laid down in the installation file system. Almost every software vendor provides updates for those product libraries as part of the product maintenance. The existing methods do not allow individual versions of libraries in the configuration file system without copying all libraries to the configuration file system. Sometimes multiple copies of the installation file system are made, each with it's own set of patched and unpatched libraries.

For example, IBM WebSphere Portal uses a tool to patch the product libraries which is called "Portal Update Installer". This tool does not work on System z, because it cannot modify read-only artifacts in the installation file system. Laying down all the libraries in each configuration file system would kill the benefit of a shared system.

The idea for solving this problem is to selectively create copies of libraries from the installation file system in the configuration file system. To accomplish this, the original link in the configuration file system is removed and the library gets copied from the installation file system t...

(Source: IPCOM)
First page image
(Source: IPCOM)