HP OpenVMS Systems Documentation

POLYCENTER Software Installation Utility Developer's Guide

The SCOPE statement establishes the scope of one or more managed objects. The SCOPE and END SCOPE statements form a scope group.

Syntax

[ PDL-statements ]

END SCOPE ;

Option

PDL-statements

Any product description language statement or a group of statements described in this reference section, except the PRODUCT and END PRODUCT statements.

Required Terminator

Description

The SCOPE statement establishes the scope of one or more managed objects. 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; whereas others are shared by all processes.

The SCOPE and END SCOPE statements form a SCOPE group. The type of scope indicated in the SCOPE statement pertains to all objects within the SCOPE group. You can nest SCOPE groups.

Note In almost all cases, the POLYCENTER Software Installation utility defaults establish the correct scope for each type of managed object. Because using SCOPE statements unnecessarily or incorrectly can cause problems, we recommend that you use explicit SCOPE statements only when you are sure product scope is not sufficient, as explained here or stated in the description of certain PDL statements.

The different types of scope that a managed object can have are as follows:

• Global scope is the largest scope in which a single POLYCENTER Software Installation utility operation can have an effect. A single file that must be shared by every process in the computing facility must exist in global scope. Modules in system object libraries are examples of managed objects that must be in global scope. Writable databases might be in global scope.
  When placing file or modules in global scope, see Section 2.6 and the descriptions of the FILE and MODULE statements regarding conflict resolution and the GENERATION option.
• Bootstrap scope managed objects function during system bootstrap when operating system facilities are unable to locate and use larger scopes. Drivers and loadable images that must be present before startup executes are examples of files that should be in the bootstrap scope.
  Use bootstrap scope for products that use device drivers, especially those drivers that must be read by the primitive file system. Because files in bootstrap scope are read by the primitive file system, they are read when not synchronized with the file system on other cluster members that might access the same disk. Therefore, those files must retain stable positions as long as the disk is in use by any system and must not be manipulated by online disk defragmentation operations, including those that use the MOVEFILE primitive.
• Product scope managed objects are product specific. Most managed objects for a product reside in product scope. Product scope is the default scope for most objects; therefore, it is not necessary to specify product scope. Product scope managed objects for different products can be stored together or separately.
• Processor scope managed objects exist in all processes executing on a single computer. For example, a logical name might exist in processor scope.

When you update your product with a partial, patch, or mandatory update kit, you can either explicitly state the scope of the file managed objects you are updating or let the utility determine the scope of the file managed objects:

• You can use the SCOPE statement to ensure that the utility looks in a specific scope for the file managed object you want to update.
• If you do not use the SCOPE statement, the utility searches the execution environment for a file managed object with the same name. If the utility finds the object, it replaces the object; if the utility does not find the file managed object, it provides a new file in product scope.

If you use the PATCH statement, the object you are updating must have been provided by your product. If you use the MODULE statement, the object you are updating either must have been provided by your product or must be in global or bootstrap scope.

Example

scope bootstrap ;
    file [SYSEXE]SYSBOOT.EXE ;
    file [SYSEXE]VMB.EXE ;
    bootstrap block [SYSEXE]VMB.EXE image [SYSEXE]BOOTBLOCK.EXE ;
end scope;
      

The statements in this example specify that the files VMB.EXE and SYSBOOT.EXE must be placed on every bootstrap disk.

The SOFTWARE statement signals a software dependency on the specified product: the specified product must be installed prior to, or concurrently with, the installation of the product that contains the SOFTWARE statement. Upon successful installation, the SOFTWARE statement causes a permanent software reference to be recorded in the product database.

The SOFTWARE function tests for the presence of the specified product, including any version constraints that you may impose.

In contrast to the SOFTWARE statement, the SOFTWARE function does not create a permanent software reference to the specified product in the product database. The SOFTWARE function also does not cause the referenced product to be implicitly installed.

Note Take note of the distinction between the SOFTWARE statement and the SOFTWARE function. The statement and function serve different purposes and are not interchangeable. See the Description section for a full discussion of the differences.

Statement Syntax

Function Syntax

[ { INSTALLED BEFORE | INSTALLED AFTER | KIT ACCESSIBLE} ] > )

Parameters

producer

Indicates the legal owner of the software product. This parameter must be a single quoted or unquoted string.

base

Indicates the base hardware/software system on which the product is intended to be installed. This parameter must be a single quoted or unquoted string. By convention, the string AXPVMS denotes an OpenVMS Alpha product, VAXVMS denotes an OpenVMS VAX product, and VMS denotes a product applicable for either OpenVMS Alpha or VAX.

name

Indicates the name of the product. This parameter must be a single quoted or unquoted string. The combination of producer, base, and name parameters must be unique among products installed on the system.

Options

[NO] COMPONENT

Indicates that if the product is copied (using the PRODUCT COPY command), the component products will be copied along with the product. The default is NO COMPONENT (the product does not need to be present during a copy operation).

INSTALLED AFTER

Directs the utility to test whether the specified software product will be installed on the system at the conclusion of the current operation. This option is available only for the SOFTWARE function. You cannot use this option with either the INSTALLED BEFORE or KIT ACCESSIBLE option. This option is the default when neither the INSTALLED BEFORE nor the KIT ACCESSIBLE option is used.

INSTALLED BEFORE

Directs the utility to test whether the specified software product was installed on the system before the current operation began. This option is available only for the SOFTWARE function. You cannot use this option with either the INSTALLED AFTER or KIT ACCESSIBLE option.

Take special note of the fact that INSTALLED BEFORE is not the default. When neither the INSTALLED BEFORE nor the INSTALLED AFTER option is used, the default is INSTALLED AFTER. Therefore, if you want to determine if a product is already installed, you must use the INSTALLED BEFORE option.

KIT ACCESSIBLE

Directs the utility to test whether the specified software product kit, either in sequential or reference format, is present in the source directory. This option is available only for the SOFTWARE function. You cannot use this option with either the INSTALLED AFTER or INSTALLED BEFORE option. By default, availability of the kit is not tested.

VERSION ABOVE version

Establishes a lower version limit. The version identifier must be a single quoted or unquoted string. Use this option to specify that the product version must be greater than (but not equal to) the specified version. You cannot use this option with either the VERSION MINIMUM or VERSION REQUIRED option. By default, there is no lower version limit.

VERSION BELOW version

Establishes an upper version limit. The version identifier must be a single quoted or unquoted string. Use this option to specify that the product version must be less than (but not equal to) the specified version. You cannot use this option with either the VERSION MAXIMUM or VERSION REQUIRED option. By default, there is no upper version limit.

VERSION MAXIMUM version

Establishes an upper version limit. The version identifier must be a single quoted or unquoted string. Use this option to specify that the product version must be less than or equal to the specified version. You cannot use this option with either the VERSION BELOW or VERSION REQUIRED option. By default, there is no upper version limit.

VERSION MINIMUM version

Establishes a lower version limit. The version identifier must be a single quoted or unquoted string. Use this option to specify that the product version must be greater than or equal to the specified version. You cannot use this option with either the VERSION ABOVE or VERSION REQUIRED option. By default, there is no lower version limit.

VERSION REQUIRED version

Establishes a required version. The version identifier must be a single quoted or unquoted string. Use this option to specify that the product version must be equal to the specified version. You cannot use this option with either the VERSION ABOVE, VERSION BELOW, VERSION MAXIMUM, or VERSION MINIMUM option. By default, there is no required version constraint.

Description

---

Previous

Next

Contents

Index