HP OpenVMS Systems Documentation
POLYCENTER Software Installation Utility Developer's Guide
5.5 Extracting Files from the Kit
You can extract one or more files from a product kit using the PRODUCT
EXTRACT and PRODUCT COPY commands. The PRODUCT EXTRACT command is often
used with the PRODUCT LIST command to identify a file or a set of files
With the PRODUCT EXTRACT FILE command, you can obtain a single file by name or a set of files with a wildcard file specification from a product kit. For example:
5.5.2 Extracting the PDF, PTF, or Release Notes
You can extract the PDF, PTF, or release notes file by name. If you do not know their names, use the folowing EXTRACT commands:
Every product kit contains a PDF. A PTF and a file designated as the release notes are optionally present in a kit.
The following example illustrates how to obtain the PDF from a sequential kit:
When you extract the PTF, the following two files are produced:
Use the PRODUCT EXTRACT RELEASE_NOTES command to examine any release notes file that may be present in the kit. This command always places the release notes (named DEFAULT.PCSI$RELEASE_NOTES) in the user's default directory.
5.5.3 Converting a Sequential Kit into Reference Format
You can use the PRODUCT COPY command to extract files from a kit in sequential format and place them in reference format. This differs in a number of ways from extracting all files from a sequential kit into a specific directory using the PRODUCT EXTRACT FILE command. When copying a kit into reference format, the files are placed in a directory tree as they would appear after installation on the user's system. Unlike the installation of a sequential kit, however, temporary files from the kit are placed in the directory tree and files pertaining to all options are extracted.
You can also use the PRODUCT COPY command to convert a reference kit
into sequential format, and for copying a kit while preserving its
After the product kit is installed, you can use the PRODUCT SHOW PRODUCT command to list the products installed on the system. Use the /FULL qualifier for additional information about software references and patches that may have been applied to the products. Additional commands (not shown here) that are useful for obtaining more information about installed products are the PRODUCT SHOW HISTORY /FULL and PRODUCT SHOW OBJECT /FULL commands.
Listed in the Order of Execution
|PRODUCT RECONFIGURE||PRODUCT REMOVE|
|execute ...stop||no||yes 1||no||yes|
|execute upgrade||no||yes 1||no||no|
|file statement using assemble execute||yes||yes||yes 2||no|
|execute login||no 3||no 3||no 3||no|
|execute start...stop||no 3||no 3||no 3||no|
|execute abort||yes 4||yes 4||yes 4||no|
The mode (noninteractive or interactive) in which an execute statement runs determines the following:
By default, an execute statement runs in noninteractive mode. You can specify interactive mode with the interactive option. For example, the following command sets up a command procedure to run in interactive mode when the product is installed:
execute postinstall "@PCSI$DESTINATION:[SYSUPD]CONFIGURE.COM" interactive ;
In both noninteractive and interactive modes, the utility checks the final exit status of a command procedure (or individual DCL command) to determine whether or not the execute statement completed successfully or failed. Although error messages generated by a command procedure are displayed to the user, this does not determine its success or failure. The utility bases this decision solely on the final exit status. It is the kit developer's responsibility to ensure that proper status is conveyed to the utility upon termination of any command procedure incorporated into the kit.
|Noninteractive Mode (default)||Interactive Mode|
|Used when you do not specify the interactive option||Used when you specify the interactive option|
|At the start of processing a PRODUCT command, the utility creates a detached subprocess using the $CREPRC system service. This subprocess is reused to run the commands from all of the execute statements specified to run in noninteractive mode. 1||The utility creates a new subprocess using the LIB$SPAWN run-time library routine for each execute statement whose commands are to run interactively. All the commands specified for the same execute statement are performed, then the subprocess is terminated.|
|Interaction with the user is not possible. The utility communicates with the subprocess through mailboxes. It filters all output from the subprocess, only displaying lines of output to the user that resemble error messages (that is, lines beginning with a percent sign). All other lines of output are discarded.||Communication with the subprocess is performed through the user's terminal connection. The utility does not monitor input to or output from the subprocess. This enables a command procedure to enter into a dialog with the user (that is, display text and solicit responses from the user).|
|The utility obtains exit status from the value of the $STATUS symbol received in response to a SHOW SYMBOL $STATUS command it sends to the subprocess. Status is queried in this manner for each DCL command you specify in the execute statement (for example, "@a.com", "show symbol $status", "@b.com", "show symbol $status",...). If the command refers to a command procedure (for example, "@c.com"), status is checked only when the command procedure exits.||Exit status is obtained from the final status value returned from the LIB$SPAWN routine (the value of the $STATUS symbol from the last DCL command executed). Since a new subprocess is created for the execution of each command procedure (or individual DCL commands) you specify, the same level of status checking is performed for interactive mode as is done for noninteractive mode, although the technique is different.|
You can package command procedure files that run from execute statements in two ways:
file [SYSUPD]EXEC_PREC.COM; execute install "@PCSI$DESTINATION:[SYSUPD]EXEC_PREC.COM";
execute install "@PCSI$SOURCE:EXEC_PREC.COM" uses EXEC_PREC.COM;
Keep the following rules in mind:
Command procedures use these logical names in the context of the
subprocess in which they are run. The logical name environment differs
depending on the execute statement being used. For more
information, see the descriptions for individual execute
statements in Chapter 7.
6.1.4 Execute Statement Summary
Figure 6-1 lists the execute statements and summarizes information about them.
6.1.5 Processing Execute Statements
This section provides flow diagrams for the PRODUCT INSTALL, PRODUCT
RECONFIGURE, and PRODUCT REMOVE commands. There is a separate diagram
for a first time installation of a product and for an upgrade of a
These diagrams illustrate the processing of execute statements in relation to events that occur during the major phases of an operation. Shaded boxes show typical output from these commands to help establish the timeline of events.
The installation and reconfiguration operations are performed in three phases:
In contrast, the remove operation has only an execution phase. Following are brief descriptions of the major phases of an operation.
During the configuration phase, the user selects any options the product might provide and answers any questions that might be asked to complete the configuration process. Informational messages from the kit may be displayed at this time.
During the execution phase, in a new installation, upgrade, or reconfiguration operation, the utility analyzes managed objects supplied by the product for conflicts. The utility uses generation information to resolve these conflicts. Any conflicts that cannot be resolved cause the utility to terminate the operation. In a remove operation, the utility does not perform any conflict detection or conflict resolution.
For all operations, the next step in the execution phase is to place the objects from all participating products in execution order. The utility merges the requirements of all affected products to produce a sequenced list of actions to perform. Note that the order in which the utility performs installation tasks might not correspond to the order in which PDL statements appear in the PDF, even when only one product is participating in an operation.
Finally, the utility modifies the target disk according to the execution order of the objects. Directories are created as required. The utility moves files to their destination directories as new or replacement files and merges library modules into existing libraries. When all actions have been successfully completed, the utility updates the SYS$SYSTEM:*.PCSI$DATABASE files that make up the product database.
During the postprocessing phase, actions such as running a functional test of the product or displaying informational messages to the user are performed. Since the postprocessing phase occurs after the installation or reconfiguration operation has completed and the product database has been updated on disk, any errors that might occur during this phase (such as failure of the functional test) do not affect the state of the product. Also, any error that occurs during the postprocessing phase will not trigger an execute abort statement.
Figure 6-2 INSTALL Operation - Product Is Installed for the First Time
Figure 6-3 INSTALL Operation - Product Is Upgraded
Figure 6-4 RECONFIGURE Operation - Product Is Reconfigured
Figure 6-5 REMOVE Operation - Product Is Removed