 |
POLYCENTER Software Installation Utility Developer's
Guide
Regardless of whether the user requests help or not, the second
information statement displays the following text for the user
during the configuration phase:
|
The HP Rdb for OpenVMS monitor must be stopped before installation
The HP Rdb for OpenVMS monitor must be stopped before HP Rdb for OpenVMS
may be installed.
Perform the following operation:
$ @SYS$MANAGER:RMONSTOP
Do you want to continue [YES]?
|
Regardless of whether the help display option is set, the confirm
option in the second statement forces the user to respond to the prompt
before continuing.
link
The link statement specifies a second directory entry for a
file or directory.
Syntax
link name from source ;
Parameters
name
Indicates the file specification of the second directory entry.
from source
Indicates the file specification of an existing directory entry for the
file or directory. The parameter string must be a single quoted or
unquoted string. The referenced file or directory must be defined by a
directory or file statement in the same product
description.
Description
The link statement specifies a second directory entry for a
file or directory. The managed object type of the file with the second
directory entry is "link".
The scope and lifetime of the link managed object depend on whether it
is contained in a scope group, as shown in Table 7-6.
If the link statement is not contained in a scope, end
scope pair or it is contained in a scope product group, the link
managed object has product lifetime and product scope.
Managed object conflict is unrecoverable.
See Also directory
file
scope
Examples
| #1 |
file [SYS$EXE]FMS.EXE;
link [SYSEXE]FMS.EXE from [SYS$EXE]FMS.EXE ;
|
The statement in this example specifies that the file [SYSEXE]FMS.EXE
is linked to the file [SYS$EXE]FMS.EXE. Both files, [SYS$EXE]FMS.EXE
and [SYSEXE]FMS.EXE, have the same file ID.
| #2 |
directory [ABC] ;
directory [DEF] ;
link [DEF]ABC.DIR from [000000]ABC.DIR;
|
This example illustrates how to create a second directory entry
[DEF.ABC] for a directory [ABC].
loadable image
The loadable image statement places an image into the system
loadable images table, SYS$LOADABLE_IMAGES:VMS$SYSTEM_IMAGES.DATA, and
also into SYS$UPDATE:VMS$SYSTEM_IMAGES.IDX for compatibility with the
System Management utility (SYSMAN).
Syntax
loadable image image product product
[ step { init |
sysinit } ]
[ message
text ]
[ severity {
fatal | success
| warning } ] ;
Parameters
image
Indicates the file name of the system loadable image. The name you
specify must be defined in the same product description and must have
bootstrap scope and product or assembly lifetime.
product product
Indicates the product mnemonic (as a single quoted or unquoted string
of 1 to 8 characters) that uniquely identifies the loadable image. For
user-written images, this should typically contain the string _LOCAL_.
Options
step init
Indicates that the system load the image during the INIT step of the
booting process.
step sysinit
Indicates that the system load the image during the SYSINIT step of the
booting process. This is the default.
message text
Indicates the message you want displayed using the severity option. The
message must be a single quoted or unquoted string. Case is
significant. By default, the severity option displays the message
"system image load failed."
severity fatal
Indicates that if an error occurs while the image is being loaded, the
system displays the message and bugchecks; if no error occurs,
processing continues.
severity success
Indicates that the system continue processing and not display a message
regardless of whether an error occurs while the image is being loaded.
severity warning
Indicates that if an error occurs while the image is being loaded, the
system displays the message and continues; if no error occurs, the
system continues and does not display the message. This is the default.
Description
The loadable image statement places an image into the system
loadable images table, SYS$LOADABLE_IMAGES:VMS$SYSTEM_IMAGES.DATA, and
also into SYS$UPDATE:VMS$SYSTEM_IMAGES.IDX for compatibility with the
System Management utility (SYSMAN).
The loadable image statement specifies a loadable image module
managed object that has the following characteristics:
- It must be unique within the global scope.
- It has assembly lifetime and global scope.
- It does not recover from managed object conflict.
The loadable image statement also refers to a file managed
object specified using the image parameter.
See Also file
Example
|
loadable image DDIF$RMS_EXTENSION product _LOCAL_
message "DDIF Extension not loaded"
severity warning ;
|
The statement in this example places the user-written image
DDIF$RMS_EXTENSION in the system loadable images table. If an error
occurs while loading this image, the system displays the error message
"DDIF Extension not loaded" and continues.
logical name
The logical name function tests whether a specified logical
name is defined in the default logical name table LNM$SYSTEM_TABLE or
in the table specified by the function.
Function Syntax
< logical name name [ equals
value ] [ table table_name ] >
Parameter
name name
Indicates the logical name string.
Options
equals value
Indicates the equivalence name string of the logical name. If you do
not specify the equivalence name, the presence of the logical name in
the default or specified logical name table is sufficient to make the
function evaluate to TRUE.
table table_name
Indicates the name of the logical name table in which the logical name
is to be searched. If the name of the table is not specified,
LNM$SYSTEM_TABLE becomes the default table name.
Description
The logical name function tests whether the specified logical
name is defined. The value of the function is true if the following
conditions are met:
- No options are specified, and the logical name has been found in
the LNM$SYSTEM_TABLE logical name table. The equivalence name is not
probed in such an instance.
- An equivalence name is specified, no logical table name is listed,
the logical name has been found in the LNM$SYSTEM_TABLE logical name
table, and the equivalence string from the table matches the
equivalence string specified in the function.
- Both options are specified, the logical name has been found in the
user specified table, and the equivalence string from the table matches
the equivalence string specified in the function.
- The equivalence name is not specified and the logical table name is
provided by the user. If the logical name is found in the
user-specified table, the function evaluates as true and the
equivalence name is not probed.
The function evaluates to false in any other case.
The utility evaluates the logical name function immediately
after processing the execute preconfigure statement. This
gives you the opportunity to define a logical name before the
configuration phase. You can use this logical name to affect the
processing of statements within an if group during the
configuration or the execution phase of an installation, configuration,
or reconfiguration operation.
See Also execute preconfigure
if
Example
|
execute preconfigure "@PCSI$SOURCE:[SYSUPD]EXEC_PREC.COM"
uses [SYSUPD]EXEC_PREC.COM interactive ;
if ( < logical name YOUR_ANSWER equals MENU_ITEM_1 > ) ;
file [SYSEXE]FILE1.EXE ;
else if ( < logical name YOUR_ANSWER equals MENU_ITEM_2 > ) ;
file [SYSEXE]FILE2.EXE ;
else if ( < logical name YOUR_ANSWER equals MENU_ITEM_3 > ) ;
file [SYSEXE]FILE3.EXE ;
end if ;
|
The utility limits your configuration options to accept only true or
false values. This example illustrates how to program multiple choice
questions.
The execute preconfigure statement runs commands from the
EXEC_PREC.COM file in an interactive mode. The user is
prompted to select one of three menu items. The answer is stored by the
command procedure as an equivalence name to a logical name YOUR_ANSWER.
The logical name is evaluated immediately after the execute
preconfigure statement and the result is stored internally. During
the execution phase, the logical name function is evaluated
and, based on the result, the if group installs the
appropriate file.
module
The module statement adds or replaces one or more modules in a
command, help, macro, object, or text library file.
Syntax
module file type type
module (module_name[,...])
[
[no] generation generation ]
[
[no] globals ]
[ library
library ]
[ [no] selective search ] ;
Parameters
file
Indicates the relative file specification of the file that contains the
modules.
type type
The library type. Table 7-7 lists the keywords you can specify with
this parameter.
Table 7-7 Library Types for Module Statement
| Keyword |
Library Type |
Default Library File |
|
Command
|
Command definition library
|
[SYSLIB]DCLTABLES.EXE
|
|
Help
|
Help library
|
[SYSHLP]HELPLIB.HLB
|
|
Macro
|
Macro library
|
[SYSLIB]STARLET.MLB
|
|
Object
|
Object library
|
[SYSLIB]STARLET.OLB
|
|
Text
|
Text library
|
[SYSLIB]STARLETSD.TLB
|
module module_name
The list of module names you are specifying.
Options
[no] generation generation
Indicates that the file has an explicit generation number. Specify the
number as an unsigned integer in the range of 0 through 4294967295. See
the Description section for the meaning of this value. By default, the
file does not have an explicit generation number (no generation), which
is equivalent to 0.
[no] globals
Indicates whether the global symbol names of the modules you are
inserting into an object library are included in the global symbol
table. You can use this option with object libraries only. By default,
the global symbols of the module are inserted into the global symbol
table.
library library
Indicates the relative file specification of the library. The file you
specify must be a library of the type you specified with the
type parameter.
[no] selective search
Indicates whether the input modules being inserted into the library are
available for selective searches by the linker (by default, they are
not). You cannot use this option with the command and help libraries.
For more information about selective searches, see the OpenVMS Linker Utility Manual.
Description
The module statement adds or replaces one or more modules in a
command library file, or a single module in a help, macro, object, or
text library file. The module statement adds the module name
to the product database. You do not need to use a register
module statement in addition to a module statement to
register the module name.
Use the module parameter to specify the name of the
module object. For a help, macro, object, or text library, the name
specified with the module parameter should be the same
as the name of the module itself.
The module object has assembly lifetime, and its scope is the same as
the library.
A module inserted into a command, help, object, text, or macro library
can conflict with another module having the same name that is already
resident in the library. Two types of module conflict can occur:
- An interproduct module conflict occurs when two or
more products provide a module with the same name.
- An intraproduct module conflict occurs when two or
more patch or partial kits for a product update the same module.
The utility resolves a module conflict by comparing the generation
numbers of the modules involved.
A generation number is an optional attribute you supply on either the
module or register module statement using the
generation option. A generation number can be any
integer in the range of 0 to 4294967295. If you do not specify a
generation number, its default value is 0.
Table 7-8 Resolving Module Conflict with Generation Numbers
| If the generation numbers |
Then |
|
Are different
|
The module with the largest non-zero number is selected.
|
|
Are the same and are not zero
|
The module from the kit replaces the previously installed module.
|
|
Are zero
|
Unresolvable file conflict, an error is reported to the user. Note that
for
V6.1-V6.2 a module with an explicit generation number
of 0 might be selected over a module with a default value of 0.
|
Generation information is not used for intraproduct conflict detection
when a product is upgraded. In this case, all modules from the old
version are deleted, and new modules from the kit are placed on the
target disk. However, generation information is used during an upgrade
for interproduct conflict detection when any modules from the product
conflict with modules from another product.
See Also file
register module
Examples
| #1 |
module [SYSUPD]CDD.CLD type COMMAND module CDD ;
|
The statement in this example creates the command module CDD in the
default command library [SYSLIB]DCLTABLES.EXE using the file
[SYSUPD]CDD.CLD.
| #2 |
module [SYSUPD]HELP.HLP type HELP module HELP ;
|
The statement in this example creates the help module in the default
help library [SYSHLP]HELPLIB.HLB using the file [SYSUPD]HELP.HLP.
| #3 |
module [SYSUPD]SPI$CONNECT.MAR type MACRO
library [SYSLIB]LIB.MLB module SPI$CONNECT ;
|
The statement in this example creates the macro module SPI$CONNECT in
the macro library [SYSLIB]LIB.MLB using the file
[SYSUPD]SPI$CONNECT.MAR.
| #4 |
module [SYSUPD]COBRTL.OBJ type OBJECT module COBRTL;
|
The statement in this example creates the object module COBRTL in the
default object library [SYSLIB]STARLET.OLB using the file
[SYSUPD]COBRTL.OBJ.
| #5 |
module [SYSUPD]PROTOTYPE_BOOK.TXT type TEXT
library [SYSLIB]LPS$FONT_METRICS.TLB module PROTOTYPE_BOOK;
|
The statement in this example creates the text module PROTOTYPE_BOOK in
the text library [SYSLIB]LPS$FONT_METRICS.TLB using the file
[SYSUPD]PROTOTYPE_BOOK.TXT.
network object
The network object statement uses a command procedure to
create a DECnet network object.
Syntax
network object name with
(parameters,...) ;
Parameters
name
Indicates the name of the network object. The network object name is
passed to the command procedure as P1.
with (parameters,...)
Indicates the list of parameters that are passed to the command
procedure that creates the network object. Each parameter must be a
single quoted string that specifies P2 through P5, in order. See the
Description section for the meaning of the parameters.
Description
The network object statement uses a command procedure
(SYS$UPDATE:PCSI$CREATE_NETWORK_OBJECT.COM) to create network objects.
The command procedure determines whether DECnet Phase IV or
DECnet--Plus is running on the system. If Phase IV is being used, the
command procedure runs the Network Control Program (NCP) utility to
create the network object. Otherwise, it runs the Network Control
Language (NCL) utility.
In the case of DECnet--Plus, the network object created during the
product installation will exist only in memory. It is recommended that
DECnet--Plus objects be supplied in the form of an NCL script with a
file statement and activated with a product startup procedure.
The utility passes the following parameters to the command procedure:
- P1 specifies the name of the network object (using the
name parameter).
- P2 specifies the object number (for DECnet Phase IV systems only).
- P3 specifies the user name associated with the object. If you
specify a user name, it must already exist.
Note
The password of the specified user account is changed when the network
object is created by PCSI$CREATE_NETWORK_OBJECT.COM. The new password
is system generated, and can be viewed with the
NCP> SHOW OBJECT...
command.
|
- P4 specifies optional parameters to use with the NCP command DEFINE
OBJECT for DECnet Phase IV objects.
- P5 specifies optional parameters to use with the NCL command CREATE
SESSION CONTROL APPLICATION for DECnet--Plus objects.
When you remove a product that created network objects, the POLYCENTER
Software Installation utility uses a command procedure
(SYS$UPDATE:PCSI$DELETE_NETWORK_OBJECT.COM) to delete network objects
associated with your product.
Note
In a future version, the utility may create and delete these managed
objects directly without the use of command procedures. If this is the
case, these statements will continue to function, but the command
procedures may not be maintained or shipped with future versions of the
utility.
|
The network object statement specifies a network object
managed object that has the following characteristics:
- Its name is the value of the name parameter. The
name must be unique with respect to all network object names in the
processor scope.
- It has operating lifetime and processor scope.
- Managed object conflict is not recoverable.
See Also file
execute start...stop
Examples
| #1 |
network object k$test with ("number 107", "user KRYPTON") ;
|
In this example, the network object statement creates a
network DECnet Phase IV object named k$test. Its object number is 107
and it will execute as user [KRYPTON].
| #2 |
file [SYSMGR]NETOBJ_TEST.NCL;
file [SYS$STARTUP]PRODUCT_STARTUP.COM ;
execute
start "@sys$startup:product_startup.com"
stop "";
|
In this example, the first file statement supplies the
DECnet--Plus NCL script file. This script can contain NCL directives
that create a DECnet--Plus network object, that is, session control
application. For example, the script file might contain the
following NCL commands:
.
.
.
delete session control application k_test
create session control application k_test
set session control application k_test
.
.
.
|
k_test is the network object name.
The second file statement supplies a command procedure, which
is executed as a result of processing the execute start
statement during the product installation. The startup command
procedure may contain the following DCL command that forces the NCL
script file to be executed:
.
.
.
$ MCR NCL DO NETOBJ_TEST.NCL
.
.
.
|
The startup command procedure can be placed later into the system
startup procedure to execute each time the user's system is rebooted.
|
