|
HP OpenVMS systems documentation |
Previous | Contents | Index |
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.
The link statement specifies a second directory entry for a file or directory.
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.
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".See Also directoryThe scope and lifetime of the link managed object depend on whether it is contained in a scope group, as shown in Table 7-6.
Table 7-6 Link Managed Object Scope and Lifetime Type of Scope Group Lifetime Scope Product Product Product Global Assembly Global Bootstrap Operating Bootstrap Processor Operating Processor 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.
#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].
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).
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_.
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.
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).See Also fileThe 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.
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.
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.
name name
Indicates the logical name string.
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.
See Also execute preconfigureThe 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.
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.
The module statement adds or replaces one or more modules in a command, help, macro, object, or text library file.
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.
[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.
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.See Also fileUse 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.
#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.
The network object statement uses a command procedure to create a DECnet network object.
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.
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.See Also fileIn 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.
#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:
k_test is the network object name.
. . . delete session control application k_test create session control application k_test set session control application k_test . . .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.
Previous | Next | Contents | Index |