HP OpenVMS Systems Documentation
Content starts here

POLYCENTER Software Installation Utility Developer's Guide

Previous Contents Index

6.1.1 Noninteractive and Interactive Mode

The mode (noninteractive or interactive) in which an EXECUTE statement runs determines the following:

  • The type of subprocess used to run your command procedures (or individual DCL commands)
  • How a command procedure interacts with the user

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.

The following table compares noninteractive and interactive mode.

Table 6-2 Comparison of Noninteractive with Interactive Mode
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 SYS$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.
1The utility may also perform other actions in the same subprocess, such as the updating of libraries using the LIBRARIAN command.

6.1.2 Packaging a Command Procedure

You can package command procedure files that run from EXECUTE statements in two ways:

  • With a separate FILE statement
    For most EXECUTE statements, you can specify a command procedure in a FILE statement. For example: 


    file [SYSUPD]EXEC_PREC.COM;
execute install "@PCSI$DESTINATION:[SYSUPD]EXEC_PREC.COM";

    This causes the utility to copy the command procedure to the target disk and execute it from there. The command procedure remains on the target disk.
    The technique of using a FILE statement cannot be used for the EXECUTE PRECONFIGURE statement because EXECUTE PRECONFIGURE is processed before files are copied to the target disk.
  • With the USES option
    For most EXECUTE statements, you can specify a command procedure with the USES option (instead of using a FILE statement). For example: 


    execute install "@PCSI$SOURCE:[000000]EXEC_PREC.COM"
        uses [000000]EXEC_PREC.COM;

    In this case, the utility extracts the command procedure from the kit and places it in a temporary directory (pointed to by the logical name PCSI$SOURCE) where it is executed. Afterwards, the command procedure is automatically deleted.
    The USES option also lets you list additional files needed by the command procedure. For example, if you link an image during the installation, you can use the USES option to package required object files for the link operation. They are also placed in the temporary directory and deleted after the statement is processed.

Keep the following rules in mind:

  • Do not use a FILE statement and the USES option to specify the same file. Specifying both results in the file being packaged twice in the kit.
  • The USES option is not available for EXECUTE statements that are run when the product is removed (because the product kit is not referenced).
  • Do not use the USES option when the customer may run the command procedure at a later time (for example, a startup command procedure).

The only exception to these rules are the EXECUTE PRE_UNDO and EXECUTE POST_UNDO statements, which require the USES option even though the commands are not run during the product installation.

6.1.3 Logical Names for Subprocess Environments

In preparation for running command procedures (or individual commands) specified in EXECUTE statements, the utility defines up to three logical names:

  • PCSI$SOURCE
  • PCSI$DESTINATION
  • PCSI$SCRATCH

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.

Figure 6-1 EXECUTE Statement Summary

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 product.

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:

  • Configuration
  • Execution
  • Postprocessing

In contrast, the remove operation has only an execution phase. Following are brief descriptions of the major phases of an operation.

Configuration Phase

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.

Execution Phase

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.

Postprocessing Phase

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

Previous Next Contents Index