POLYCENTER Software Installation Utility Developer's
Guide
The source file name consists of a relative directory specification,
file name, and file type of a file in the materials directory path.
File version number is not used because the file with the highest
version is packaged. Use this option when the input file for the
package operation has a different relative file specification than the
output file your kit installs on the user's system. By default, the
name of the input file for the package operation is the same as the
output file created in the execution environment when the kit is
installed.
[NO] WRITE
Indicates that you expect users to modify the file during system
operation. If you specify this option during a version upgrade, if the
file already exists, it remains the active version. For example, the
OpenVMS operating system PDF uses this option for [SYSMGR]SYSLOGIN.COM.
The default is no write. You cannot use this option with the ARCHIVE or
RELEASE MERGE options.
Description
The FILE statement creates a file object on the target disk. You
specify a file managed object with either the name parameter
or the SOURCE option. The file must be supplied as product material,
unless the ASSEMBLE EXECUTE option is used to dynamically create the
file. The LINK and LOADABLE IMAGE statements can also specify
references to a file-managed object.
File Conflict
Two types of file conflict can occur:
- An interproduct file conflict occurs when two or
more products provide a file with the same name in the same directory.
(Files with the same name can co-exist in different directories.)
- An intraproduct file conflict occurs when two or
more patch or partial kits for a product update the same file.
For
example, OpenVMS provides the file DUDRIVER.EXE. If you install two
different remedial kits for a particular version of OpenVMS that both
update this file, an intraproduct file conflict results.
Intraproduct file conflict detection and resolution was introduced
in the version of the utility that shipped with OpenVMS Alpha Version
7.1-2 and OpenVMS VAX Version 7.2. This enhancement allows patch and
partial kits to be installed "out-of-order" while providing the most
up-to-date files. Prior to this change, files from patch or partial
kits always superseded the previously installed files.
The utility resolves a file conflict by comparing the generation
numbers of the files involved.
Do not confuse generation numbers with file versions. A generation
number is an optional attribute you supply on a file statement using
the GENERATION option. A generation number can be any integer in the
range of 0 to 4294967295. For example:
file [SYSEXE]ABC.EXE generation 100;
|
If you do not specify a generation number, its default value is 0.
Table 7-4 shows how the utility resolves a file coflict.
Table 7-4 Resolving File Conflict with Generation Numbers
| If the generation numbers |
Then |
|
Are different
|
The file with the largest non-zero number is selected.
|
|
Are the same and are not zero
|
V6.1-V6.2: The file from the kit replaces the
previously installed file.
V7.0-V7.2: The previously installed file is retained.
V7.3: The file from the kit replaces the previously
installed file.
|
|
Are zero
|
Unresolvable file conflict, an error is reported to the user. Note that
in
V7.1, file conflict is not detected and the file from
the kit is selected. This behavior was corrected in OpenVMS Alpha
Version 7.1-2 and OpenVMS VAX Version 7.2.
|
Generation information is not used for intraproduct conflict detection
when a product is upgraded. In this case, all files from the old
version are deleted, and new files from the kit are placed on the
target disk. However, generation information is used during an upgrade
for interproduct conflict detection when any files from the product
conflict with files from another product.
Logical Names
The ASSEMBLE EXECUTE option causes the utility to define logical names
for use by the subprocess that executes the specified commands. The
commands should use these logical names to reference files, as follows:
- PCSI$SOURCE is a root directory specification under the user's
login directory. It is used for temporary placement of the files
specified by the ASSEMBLE USES option. This logical name is defined for
the subprocess in which product-supplied commands execute. It is not
the same PCSI$SOURCE logical name that can be defined by a user, in the
user's process, pointing to the location of a product kit.
- PCSI$DESTINATION is a root directory specification under the user's
login directory used as a staging area. The commands specified in the
ASSEMBLE EXECUTE option are responsible for creating a file in this
directory tree whose name matches the one specified in the file name
parameter. After the commands are executed, the utility moves the file
to the product's destination directory for the current scope. This
logical name is defined for the subprocess in which product-supplied
commands execute. It is not the same PCSI$DESTINATION logical name
pointing to the target disk that can be defined by a user in the user's
process.
- PCSI$SCRATCH is a subdirectory under the user's login directory
that can be used by commands for temporary working space. This
directory and any files placed in it are automatically deleted at the
end of the operation.
Scope and Lifetime
The scope and lifetime of the file managed object depend on whether it
is contained within a SCOPE, END SCOPE pair as shown in Table 7-5.
1If the file option is ASSEMBLE EXECUTE, the file managed
object has assembly lifetime and product scope.
Access Control Managed Object
You can include an ACCESS CONTROL option in a FILE statement to control
access to a file managed object. Each access control entry (ACE) you
specify creates an ACE managed object with the following
characteristics:
- It is unnamed.
- It has operating lifetime. It has the same scope as the file
managed object.
- The system resolves managed object conflict by managed object
collection.
Image Library Managed Object
For a FILE statement that provides a shareable image, you can specify
the IMAGE LIBRARY option to direct the utility to insert the file's
symbols into the system shareable image symbol table library. This
action creates an image library module object with the following
characteristics:
- It must be unique within the global scope.
- It has assembly lifetime and global scope.
- Managed object conflict is not recoverable.
See Also DIRECTORY
EXECUTE ABORT
EXECUTE INSTALL...REMOVE
EXECUTE POSTINSTALL
EXECUTE START...STOP
EXECUTE TEST
EXECUTE UPGRADE
LINK
LOADABLE IMAGE
MODULE
SCOPE
Examples
| #1 |
file [SYSMGR]PROD01.DAT
access control ("(IDENTIFIER=[TEST],ACCESS=READ)",
"(IDENTIFIER=[PROD_USER],ACCESS=READ+WRITE)",
"(IDENTIFIER=*,ACCESS=NONE)") write;
|
The FILE statement in this example specifies that the file PROD01.DAT
cannot be accessed by any user account other than TEST, which is
allowed to read it, and PROD_USER, which is allowed to read and write
the file.
| #2 |
file [SYSLIB]FDVSHR.EXE image library ;
|
The FILE statement in this example specifies that the symbols for the
shareable image [SYSLIB]FDVSHR.EXE are inserted into the system
shareable image symbol table library.
| #3 |
file [SYSMGR]DECW$STARTUP.COM protection public ;
|
The FILE statement in this example creates the file
[SYSMGR]DECW$STARTUP.COM, giving users read and execute access.
| #4 |
file [SYSMGR]DECW$SYLOGIN.COM protection public
source [SYSMGR]DECW$SYLOGIN.TEMPLATE ;
|
The FILE statement in this example creates the file
[SYSMGR]DECW$SYLOGIN.COM in the execution environment using the
contents of the file [SYSMGR]DECW$SYLOGIN.TEMPLATE from product
material packaged in the kit. You do not have to specify the source
file with a separate FILE statement. The PACKAGE command always
requires a /MATERIAL qualifier.
| #5 |
file [SYSMGR]DECW$SYSTARTUP.COM generation 56 archive ;
|
|
