HP OpenVMS Systems Documentation

POLYCENTER Software Installation Utility Developer's Guide

To create managed objects using PDL statements, you can specify the names and properties of the managed objects that are necessary for your product. At installation time, the POLYCENTER Software Installation utility uses your product description file (PDF) to create the managed objects for your product and records information about these objects in the product database.

For example, you use the DIRECTORY, FILE, and MODULE statements to specify directory, file, and library module managed objects, as shown in the following example:

directory [SYSTEST.FORTRAN] ;
file [SYSTEST]FORT$IVP.COM ;
file [SYSHLP]TNT030.RELEASE_NOTES release notes ;
file [SYSHLP]HELPLIB.HLB generation 40069227 release merge ;
module [000000]CPQC.CLD type command module CC ;

When the POLYCENTER Software Installation utility removes a software product, it uses the data in the product database to delete managed objects from the system.

Use the PRODUCT SHOW OBJECT command to display the names of objects installed on a system. For example:

$ PRODUCT SHOW OBJECT *COPY*
----------------------------------------------- ----------------- -----
OBJECT NAME                                     OBJECT TYPE       STATUS
----------------------------------------------- ----------------- -----
[SYSEXE]COPY.EXE                                 file              OK
[SYSHLP.EXAMPLES.DECW.UTILS]COPYRIGHT.H          file              OK
COPY                                             module            OK

Occasionally, your product will supply a managed object that conflicts with another managed object. For example, if you supply a file called FOO.TXT and a file by that name was also provided (in the same directory) by another product, a conflict occurs. The existing file will be overwritten under the following circumstances:

• If it was provided by an earlier instance of your product.
• If it was not created by the PRODUCT command. (It is not a managed object in the product database.)

However, if the file is a managed object identified in the product database, and is owned by some other product, it might not be appropriate to replace it.

The following two types of managed object conflict can occur:

• An interproduct conflict occurs when two or more products provide an object with the same name in the same directory. (Files with the same name can coexist in different directories.)
• An intraproduct conflict occurs when two or more patch or partial kits for a product update the same object.

When the utility detects conflict, it displays an informational message. The following statements detect managed object conflict and display informational messages:

• ACCOUNT
• DIRECTORY
• FILE
• LINK
• LOADABLE IMAGE
• MODULE
• NETWORK OBJECT
• REGISTER MODULE
• RIGHTS IDENTIFIER

In some cases, the POLYCENTER Software Installation utility allows you to anticipate and resolve conflict before it occurs. The following statements provide some level of conflict resolution:

• FILE
• MODULE
• REGISTER MODULE

Managed object conflict is resolved differently, depending on what type of object is involved. The description of these statements in Chapter 7 indicates how each one resolves managed object conflict.

For example, some statements provide a generation option (using the GENERATION keyword) that lets you assign a generation number to an object. During installation, if the utility attempts to create an object that already exists, it compares the generation numbers of the objects, selecting the object with the highest generation number.

When two or more products provide the same file or module, the one with the highest generation number must implement a superset of the capabilities found in the objects having lower generation numbers. This is required so that all products installed that use this object will continue to function properly.

When one of these products is removed, the POLYCENTER Software Installation utility retains the object with the highest generation number and reassigns the ownership of the object to the product remaining on the system.

Thus, when products update one or more objects in common (indirectly modify each other), removal of one product might result in not restoring the other product to its former state. This is because the objects with the highest generation numbers are left on the system.

For example, the product description files for products TEST1 and TEST2 are as follows:

product CPQ AXPVMS TEST1 V1.0 full;
    file [SYSEXE]TEST.EXE generation 100;
end product;

product CPQ AXPVMS TEST2 V1.0 full;
    file [SYSEXE]TEST.EXE generation 200;
end product;

If you first install product TEST1 and then install TEST2, the TEST.EXE file with generation number 200 will supersede the previously installed file TEST.EXE with generation number 100. However, if you subsequently remove product TEST2, the utility will retain generation 200 of file TEST.EXE and list product TEST1 as its owner. It is assumed that the file having the higher generation number is a functional superset of the file with the lower generation number; therefore, product TEST1 will continue to work properly. To restore product TEST1 to its original state, you will need to reinstall it. This will remove all the installed files associated with the product and replace them with files from the kit.

2.6.4 Managed Object Replacement and Merging

As described in Section 2.6.2, managed objects occasionally have characteristics that conflict with each other. The POLYCENTER Software Installation utility handles this situation differently depending on the kit type:

• When upgrading a product using a full operating system or platform kit, the utility deletes the existing object and replaces it with the object and characteristics provided by the new version of the product.
• When upgrading a product using a partial kit or modifying a product using a patch or mandatory update kit, the utility preserves the characteristics of existing objects. For example, the security environment you establish for your product is preserved when you install a partial, patch, or mandatory update kit.

If you want to provide new characteristics for a managed object in a partial, patch, or mandatory update kit, use the REMOVE statement to delete the existing object and then respecify the object with the desired characteristics.

For more information about kit types, see Table 2-2.

2.6.5 Managed Object Scope and Lifetime

The scope of a managed object defines the degree of sharing that the managed object permits. For example, some objects are available only to certain processes, and some can be shared by all processes. The utility usually ensures that managed objects have the correct scope.

Occasionally, you might need to use the SCOPE statement to give a managed object a scope other than its default. For more information about specifying the scope of a managed object, see the description of the SCOPE statement in Chapter 7.

2.7 Creating an Integrated Platform (Product Suite)

In addition to packaging individual products, the POLYCENTER Software Installation utility gives you the means to assemble integrated platforms. An integrated platform is a combination of several products, such as a suite of complementary management products that you might bundle together.

Functionally, a platform is the same as a full kit, except that it has the designation "PLATFORM". A platform is intended to reference other products, but it can also supply files.

Figure 2-2 shows an example of an integrated platform.

Figure 2-2 Integrated Platform Example

To package a platform, you create a platform PDF and platform PTF. In addition to other statements, the platform PDF contains SOFTWARE statements that specify the products that make up the platform. The individual products have their own PDFs and PTFs (independent of the platform PDF and PTF). For more information about platform PDFs, see Section 3.5.3.