|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
 |
 |
HP OpenVMS systems documentation |
|
| Previous | Contents | Index |
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.
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.
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.
Table 7-5 File Managed Object Scope and Lifetime Type of Scope Group Lifetime Scope Product 1 Product Product Global Assembly Global Bootstrap Operating Bootstrap Processor Operating Processor
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:
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:
| #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 ;
|
Previous Next Contents Index