[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here

POLYCENTER Software Installation Utility Developer's Guide


Previous Contents Index

1.3.5 Step 5: Package the Software Components

Package the software components to create a .PCSI file. This step is fully described in Chapter 5. Use the PRODUCT PACKAGE command and its qualifiers. The PRODUCT PACKAGE command determines if the PDF and PTF are syntactically correct and verifies that all listed product material files can be found.

1.3.6 Step 6: Test and Debug the Installable Kit

When a kit has been successfully produced, use the PRODUCT INSTALL, PRODUCT SHOW, and PRODUCT REMOVE commands to verify the installation and removal of the product. Check for correct file placement and protection, test user input, review message text, modify configuration options, verify that execution environment requirements are satisfied, and so forth.

Test your installable kit to make sure that it properly handles any software version dependencies.


Chapter 2
Basic Concepts

This chapter defines key terms and concepts. Read this chapter before creating your installable kit.

This chapter describes the following topics:

If you are familiar with the POLYCENTER Software Installation utility terms and concepts, you can start with Chapter 3.

2.1 The Product Database

The product database (PDB) refers to a set of interrelated files located in SYS$SYSDEVICE:[VMS$COMMON] with a .PCSI$DATABASE file extension. The POLYCENTER Software Installation utility automatically creates the PDB the first time a product is installed or registered on the system, such as when the OpenVMS operating system is installed. Once created, the utility updates the database as operations are performed to install, reconfigure, register, or remove products.

The PDB is the single source of information about operations performed on products using the POLYCENTER Software Installation utility. This information includes a history of operations performed, which products are installed, which files and other managed objects are owned by each product, software dependencies among products, and so forth.

The PDB consists of three permanent files:

  • PCSI$FILE_SYSTEM.PCSI$DATABASE
  • PCSI$PROCESSOR.PCSI$DATABASE
  • PCSI$ROOT.PCSI$DATABASE

A product-specific database file is created each time a product kit is installed or registered, and deleted when the product is removed. For example, the layered product TNT V3.0 for OpenVMS VAX might have a database file named DEC-VAXVMS-TNT-V0300.PCSI$DATABASE.

Note

The format and content of the database files are controlled by the POLYCENTER Software Installation utility. If an OpenVMS system manager uses the POLYCENTER Software Installation utility to install your product, the utility will expect the database files to exist from that point on.

Caution your product's users not to delete these files or the POLYCENTER Software Installation utility will not be able to detect and manage your product. The complete set of database files must be intact for the utility to access the information in the database.

2.1.1 Querying the Product Database

As a software provider, you can use PDL statements to query the product database to dynamically determine the version of an installed product. The following example illustrates how installation choices are made based on the installed version of OpenVMS on an Alpha system:


    if (<software DEC AXPVMS VMS version minimum V6.2> AND
        <software DEC AXPVMS VMS version below A6.3>) ;
        file [SYSEXE]TNT$SERVER.EXE generation 5
             source [000000]TNT$SERVER_V62.EXE ;
        file [SYSEXE]TNT$UTILITY.EXE generation 1
             source [000000]TNT$UTILITY_V62.EXE ;
        file [SYSTEST.TNT]TNT$SERVER_IVP.EXE generation 5
             source [000000]TNT$SERVER_IVP_V62.EXE ;
    end if;

    if (<software DEC AXPVMS VMS version minimum V7.0> AND
        <software DEC AXPVMS VMS version below A7.1>) ;
        file [SYSEXE]TNT$SERVER.EXE generation 5
             source [000000]TNT$SERVER_V70.EXE ;
        file [SYSEXE]TNT$UTILITY.EXE generation 1
             source [000000]TNT$UTILITY_V70.EXE ;
        file [SYSTEST.TNT]TNT$SERVER_IVP.EXE generation 5
             source [000000]TNT$SERVER_IVP_V70.EXE ;
    end if;

OpenVMS users can use the DCL command PRODUCT SHOW either to query the product database to show what products are installed and the dependencies between them, to list the files and other objects that make up each product, or to show the history of installation and upgrade activity.

If your installation procedure or the OpenVMS user removes a product, information about the files and objects associated with the product are removed from the database. However, the history of the product's activity from installation to removal is retained in the database.

2.2 Software Product Kit Formats

When you create a software product kit, you must also choose a distribution format. You may choose one of three distribution formats:

  • Sequential format. In this format, the PDF, PTF, kit-specific command procedures, and all files that comprise the product are packaged into a single container file that is identified by a .PCSI file type. You can ship a sequential kit on either a random-access device, such as a CD-ROM, or on a sequential access device, such as magnetic tape. Most layered products and patch kits are distributed in this format. Use the PRODUCT PACKAGE /FORMAT=SEQENTIAL command to generate a kit in sequential format.
  • Compressed format. This format is a variant of sequential format in which a compression technique is used to reduce the size of the kit. To create a kit in compressed format, first package the product in sequential format using the PRODUCT PACKAGE /FORMAT=SEQUENTIAL command. Next, use the PRODUCT COPY /FORMAT=COMPRESSED command to create a compressed kit from the sequential kit. The resulting container file has a file type of .PCSI$COMPRESSED. The PRODUCT INSTALL command and all other PRODUCT commands that read software product kits automatically decompress records from a compressed kit as they are needed.
  • Reference format. In this format, the PDF, PTF, kit-specific command procedures, and all files that comprise the product are placed in a directory tree on a random-access device. The directory tree mirrors the directory structure of the product on the user's disk after installation. The top-level directory contains the PDF and PTF. The PDF has a file type of .PCSI$DESCRIPTION and it is used to identify the kit. Use the PRODUCT PACKAGE /FORMAT=REFERENCE command to generate a kit in reference format. You can also use the PRODUCT COPY /FORMAT=REFERENCE command to expand a kit in either sequential or compressed format to one in reference format where all extracted files are placed in a directory tree.
    The OpenVMS operating system product is packaged in reference format. This format is used because the operating system is distributed in bootable form on a CD-ROM or DVD--ROM where all of its files must be directly accessible to the file system. While layered products and patch kits can be distributed in reference format, this is rarely done because it is much simpler to ship a kit in the form of a single container file in either sequential or compressed format.

Figure 2-1 shows how the package operation uses the PDF, PTF, and product material to create a product kit in reference or sequential format. Subsequently, the copy operation can be used to transform a sequential kit into a kit in compressed format.

Figure 2-1 Package Operation


2.3 Software Product Kit Naming Conventions

The POLYCENTER Software Installation utility adheres to the following file-naming conventions when either creating a software product kit or processing PDF and PTF files.

2.3.1 Sequential Format

A software product kit created in sequential format is a single file whose name is in the following format:


producer-base-product-version-kittype.PCSI

For example:


DEC-AXPVMS-DWMOTIF-V0102-6-1.PCSI

Note that the file name is constructed of components delimited by hyphens (-). The version component is further divided into subfields and includes an additional hyphen as explained in Section 2.3.5.


Previous Next Contents Index