The OpenVMS Management Station is a powerful, Microsoft Windows based management tool for system managers and others who perform account management tasks on OpenVMS systems. OpenVMS Management Station software provides a comprehensive user interface to OpenVMS account management across multiple systems. You can manage multiple systems from a single source.

OpenVMS Management Station software coexists with all of the existing OpenVMS system management utilities. Figure 2.1 shows a sample OpenVMS Management Station screen.

These steps require that you use DCL, the Authorize utility, and the DISKQUOTA component of the SYSMAN utility. OpenVMS Management Station provides an easy-to-use interface to this process.

Documentation for the OpenVMS Management Station

The Microsoft Windows help files completely describe features, functions, instructions, and examples of using the OpenVMS Management Station. The OpenVMS Management Station Overview and Release Notes document provides an over view of OpenVMS Management Station and describes how to get started using the software.

You perform many system management tasks by entering DCL (DIGITAL Command Language) commands. For example, enter the DCL command MOUNT to make disks and tapes available to the system. Most of the DCL commands used by system managers require special privileges (such as OPER privilege).

command-name[/qualifier[, ...]] [parameter[, ...]] [/qualifier[, ...]]

Because a command can be continued on more than one line, the term command string is used to define the entire command. A command string is the complete specification of a command, including the command name, command qualifiers, parameters, and parameter qualifiers.

For complete descriptions of each DCL command, refer to online DCL help or the VSI OpenVMS DCL Dictionary. If you are not familiar with DCL command syntax, refer to the VSI OpenVMS User's Manual.

At times, you might need to interpret a system message, for example, to find out how to recover from a warning or failure. The Help Message utility allows you and system users to quickly access online descriptions of system messages from the DCL prompt.

For more information about the Help Message utility, refer to the OpenVMS System Messages: Companion Guide for Help Message Users. In addition, the OpenVMS System Messages and Recovery Procedures Reference Manual provides detailed descriptions of system messages.

You can use command procedures to efficiently perform routine tasks. A command procedure is a file containing DCL commands and, optionally, data used by those DCL commands. When you execute a command procedure, the system reads the file and executes the commands it contains. This eliminates the need for you to enter each command interactively. You can create command procedures to automate some of the routine system management tasks specific to your site.

$ SET DEFAULT [PERRY.WORK]
$ DIRECTORY
$ EXIT

When you execute this command procedure with the command @GO_WORK, you set your default directory to [PERRY.WORK] and display a list of files in that directory.

With complex command procedures, you can use DCL instead of a high-level programming language. For more information about creating command procedures, refer to the VSI OpenVMS User's Manual.

$ SET NOON
$! Resubmit this procedure to run again tomorrow.
$!
$ SUBMIT/KEEP/NOPRINT/QUEUE=SYS$BATCH/AFTER="TOMORROW+1:00"/USER=SYSTEM -   SYS$MANAGER:SYSTEM-DAILY.COM;
$!
$! Purge the log files
$ PURGE/KEEP=7 SYS$MANAGER:SYSTEM-DAILY.LOG
$!
$! Analyze public disks
$!
$ ANALYZE/DISK/LIST=SYS$MANAGER:WORK1.LIS;  WORK1:
$ ANALYZE/DISK/LIST=SYS$MANAGER:WORK2.LIS;  WORK2:
$!
$! Print listings
$!
$ PRINT/QUEUE=SYS$PRINT SYS$MANAGER:WORK1.LIS; , SYS$MANAGER:WORK2.LIS;
$ EXIT

With the operating system, VSI supplies a number of system management utilities to help perform system management tasks. A system management utility is a program that performs a set of related operations. For example, the Mount utility (MOUNT) makes disks and tapes available to the system, and the Backup utility (BACKUP) saves and restores files.

Most system management utilities require special privileges. Generally, you run these utilities from the SYSTEM account, which has all privileges by default. Section 2.2 describes logging in to the SYSTEM account.

RUN SYS$SYSTEM:utility_name

$ ANALYZE/DISK_STRUCTURE

You can use this command procedure as is, or modify it to serve your own site-specific needs. If you modify this procedure, VSI recommends you first copy the procedure to another directory (for example, SYS$MANAGER), so that an original version of MGRMENU.COM is always available in the SYS$EXAMPLES directory.

$ @SYS$EXAMPLES:MGRMENU

SYSMAN centralizes system management, so that you, as system manager, can manage nodes or clusters from one location. Rather than logging in to individual nodes and repeating a set of management tasks, SYSMAN enables you to define your management environment to be a particular node, a group of nodes, or an OpenVMS Cluster environment. With a management environment defined, you can perform traditional system management tasks from your local node; SYSMAN executes these tasks on all nodes in the target environment.

SMI-E-RIGHTSLIM, Rights limit exceeded.

The SMISERVER process must be running on a remote node for SYSMAN commands to execute on that node. SMISERVER is the detached process responsible for executing SYSMAN commands on remote nodes.

Any node that is part of an OpenVMS Cluster system normally starts the SMISERVER process in the system startup procedure SYS$SYSTEM:STARTUP.COM. (The system parameter CLUSTER on the node must have a value of 1 or more.)

To start the SMISERVER process on a workstation that is not part of an OpenVMS Cluster system, include the following command line in the site-specific startup command procedure SYSTARTUP_VMS.COM:

$ @SYS$SYSTEM:STARTUP SMISERVER 

For more information about SYSTARTUP_VMS.COM, see Section 5.2.7.

You can also enter this command interactively to restart the SMISERVER process without rebooting the system.

When you use SYSMAN, you must define the management environment you will be working in. The management environment is the node or nodes on which subsequent commands will execute.

By default, the management environment is the local node (the node from which you execute SYSMAN). To execute commands on one or more other nodes, you can redefine the management environment to be any of the following:

Refer to Figure 2.2 during the following discussion of management environments.

You can use NODE21 as the management environment, or you can define the environment to be any node, group of nodes, or cluster shown in Figure 2.2.

If you execute SYSMAN from NODE21, then NODE21 is the local node; it is the management environment when SYSMAN starts. All other nodes are remote nodes.

To define the management environment, use the SYSMAN command SET ENVIRONMENT. Whenever you redefine an environment, SYSMAN displays the new context. You can always verify the current environment with the SHOW ENVIRONMENT command.

When you are not working on your local node or within your own cluster, your environment is a nonlocal environment. SYSMAN makes this distinction for security reasons; when you are defining a nonlocal environment, such as a different cluster, SYSMAN prompts for a password. SYSMAN also prompts for a password when you attempt to manage a system under a different user name. You can change your user name by using the /USERNAME qualifier with SET ENVIRONMENT.

A SYSMAN environment remains in effect until you change it or exit from SYSMAN.

$ CREATE/NAME_TABLE/PARENT=LNM$SYSTEM_DIRECTORY SYSMAN$NODE_TABLE
$ DEFINE CI_NODES SYS2, SYS8/TABLE=SYSMAN$NODE_TABLE
$ DEFINE C NODE21, NODE22, NODE23/TABLE=SYSMAN$NODE_TABLE
$ DEFINE PASCAL NODE23, NODE18, CI_NODES/TABLE=SYSMAN$NODE_TABLE
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/NODE=(C, PASCAL)
Remote Password:

%SYSMAN-I-ENV, current command environment:
        Individual nodes: NODE21, NODE22, NODE23, NODE18, SYS2, SYS8
        At least one node is not in the local cluster.
        Username SYSTEM       will be used on nonlocal nodes.

SYSMAN> SET ENVIRONMENT/CLUSTER
%SYSMAN-I-ENV, Current Command Environment:
        Clusterwide on local cluster
        Username ALEXIS   will be used on nonlocal nodes

SYSMAN> SET ENVIRONMENT/CLUSTER/NODE=NODE24
Remote Password:
%SYSMAN-I-ENV, Current Command Environment:
        Clusterwide on remote node NODE24
        Username ALEXIS   will be used on nonlocal nodes

When you use SYSMAN across OpenVMS Cluster systems, SYSMAN establishes a profile that contains your rights, privileges, and defaults, and verifies that you are an authorized user. If you encounter privilege problems when using SYSMAN, it helps to know how SYSMAN determines your profile.

SYSMAN looks for three possible scenarios when determining your profile:

The profile does not include symbolic names, logical names, preset terminal characteristics, or key definitions established through a login command procedure. The only environment that has the attributes defined in a login command procedure is the local node from which you are executing SYSMAN.

This profile is in effect until you change it with SET PROFILE, reset the environment (which may change your profile automatically), or exit from SYSMAN.

The SET PROFILE command temporarily changes the attributes of your current local process. However, when you exit from SYSMAN, all attributes are restored to the values that were current when SYSMAN was invoked.

SYSMAN> SET PROFILE/PRIVILEGES=SYSPRV
SYSMAN> SHOW PROFILE
%SYSMAN-I-DEFDIR, Default directory on node NODE21  -- WORK1:[MAEW]
%SYSMAN-I-DEFPRIV, Process privileges on node NODE21 --
        TMPMBX
        OPER
        NETMBX
        SYSPRV

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET PROFILE/DEFAULT=DMA1:[SMITH.COM]

Use the SET PROFILE/VERIFY command to turn on DCL verification, which displays DCL command lines and data lines as they execute.

SYSMAN can execute DCL commands using the DO command. By default, SYSMAN DCL verification is turned off.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET PROFILE/VERIFY

The SYSMAN command DO executes DCL command procedures and SYSMAN command procedures on all nodes in an OpenVMS Cluster environment. In an OpenVMS Cluster environment or in any environment with multiple nodes, you enter a set of commands once, and SYSMAN executes the commands sequentially on every node in the environment. SYSMAN displays the name of each node as it executes commands, or an error message if the command fails.

If a node does not respond within a given timeout period, SYSMAN displays a message before proceeding to the next node in the environment. You can specify a timeout period with the SET TIMEOUT command.

Each DO command executes as an independent subprocess, so no process context is retained between DO commands. For this reason, you must express all DCL commands in a single command string, and you cannot run a procedure that requires input.

In an OpenVMS Cluster environment, SYSMAN executes DO commands sequentially on all nodes in the cluster. After a command completes or times out on one node, SYSMAN sends it to the next node in the environment. Any node that is unable to execute a command returns an error message.

For more information about using the DO command to manage an OpenVMS Cluster system, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems. You can also refer to the VSI OpenVMS System Management Utilities Reference Manual for a complete description of the SYSMAN command DO.

Example

In the following example, SYSMAN runs the INSTALL utility and makes a file known on all nodes in the cluster when you enter the commands from the local node:

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> SET PROFILE/PRIVILEGE=CMKRNL
SYSMAN> DO INSTALL ADD/OPEN/SHARED WORK4:[CENTRAL]STATSHR
.
.
.
%SYSMAN-I-OUTPUT, Command execution on node NODE21
%SYSMAN-I-OUTPUT, Command execution on node NODE22

The SYSMAN execute procedure (@) command executes SYSMAN command procedures on each node in the environment.

Example

The following example creates and executes a SYSMAN command procedure to display the current date and system time for each OpenVMS Cluster node:

$ CREATE TIME.COM
SET ENVIRONMENT/CLUSTER
CONFIGURATION SHOW TIME[Ctrl/Z]
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> @TIME
%SYSMAN-I-ENV, Current command environment:
            Clusterwide on local cluster
            Username SYSTEM   will be used on nonlocal nodes
System time on node NODE21: 19-JUN-1996 13:32:19.45
System time on node NODE22: 19-JUN-1996 13:32:27.79
System time on node NODE23: 19-JUN-1996 13:32:58.66
SYSMAN>

You can create an initialization file that is used each time you invoke SYSMAN. In the initialization file, you can perform tasks such as defining keys and setting up your environment.

The default file specification for the SYSMAN initialization file is SYS$LOGIN:SYSMANINI.INI. If you want your SYSMAN initialization file to have a different file specification, you must define the logical name SYSMANINI to point to the location of the file. The following is a sample initialization file that defines several keys:

$ TYPE SYSMANINI.INI
DEFINE/KEY/TERMINATE KP0 "SET ENVIRONMENT/CLUSTER/NODE=(NODE21, NODE22)"
DEFINE/KEY/TERMINATE KP1 "CONFIGURATION SHOW TIME"
DEFINE/KEY/TERMINATE KP2 "SHOW PROFILE"
   ...

Figure 2.3 illustrates the function of OPCOM.

OPCOM Components

OPCOM Defaults

OPCOM Requirements

The OPCOM process starts automatically during system startup, unless it is disabled. You might need to start OPCOM interactively if a software problem causes the process to fail and prevents OPCOM from restarting automatically.

$ @SYS$SYSTEM:STARTUP OPCOM

If a software problem causes OPCOM to fail, contact your VSI support representative. Be sure to keep the process dump file named SYS$SYSTEM:OPCOM.DMP. (When OPCOM fails, it creates this file.)

REPLY [/qualifier...] ["message-text"]

$ REPLY/ALL/BELL "Please log off"

For more information, refer to the VSI OpenVMS DCL Dictionary.

Examples

$ REPLY/ALL/BELL/NODE=WLDWND "Please log off"

$ REPLY/BELL/TERMINAL=TTC1: "Your file has completed printing"

By default, OPCOM enables OPA0: as an operator terminal except on workstations in clusters (unless the workstation is the first system into the cluster). OPCOM determines whether a system is a workstation by testing the system for a graphics device. Specifically, this test is:

F$DEVICE (“*”, “WORKSTATION”, “DECW_OUTPUT”)

%%%%%%%%%%% OPCOM 18-MAY-2000 13:28:33.12 %%%%%%%%%%%
“BADCLASS” is not a valid class name in OPC$OPA0_CLASSES

The logicals take effect the next time you boot the system.

Normally, the console terminal (with the device name OPA0:) is automatically an operator terminal except for workstations in an OpenVMS Cluster environment. However, you can designate any terminal as an operator terminal. You can also disable a previously designated operator terminal.

Enabling Operator Terminals

$ REPLY/ENABLE
$
%%%%%%%%%%%  OPCOM  13-JUL-2000 11:30:30.56  %%%%%%%%%%%
Operator _BHAK$FTA20: has been enabled, username SYSTEM

To designate an operator's terminal in batch or in startup command procedures, SYS$COMMAND must be assigned to a valid terminal device.

REPLY/ENABLE=(keyword[, ...])

$ REPLY/ENABLE=(PRINTER, OPER3)

Disabling Operator Terminals

A terminal that you designate as an operator's terminal remains enabled even when the operator logs out. To return the terminal to normal (nonoperator) status, enter the REPLY/DISABLE command from the terminal.

Example

$ REPLY/ENABLE=(PRINTER, DISKS, TAPES, CENTRAL)
$
%%%%%%%%%%%  OPCOM  13-JUL-2000 11:37:09.52  %%%%%%%%%%%
Operator TTA3 has been enabled, username SYSTEM

$
%%%%%%%%%%%  OPCOM  13-JUL-2000 11:37:09.53  %%%%%%%%%%%
Operator status for operator TTA3
CENTRAL, PRINTER, DISKS, TAPES
$ REPLY/DISABLE=TAPES
%%%%%%%%%%%  OPCOM  13-JUL-2000 11:37:09.53  %%%%%%%%%%%
Operator status for operator TTA3
CENTRAL, PRINTER, DISKS
$ REPLY/DISABLE
%%%%%%%%%%%  OPCOM  13-JUL-2000 11:38:50.68  %%%%%%%%%%%
Operator TTA3 has been disabled, username SYSTEM

Example

$ PRINT/COPIES=2/QUEUE=LQ_PRINT  REPORT.OUT/FORM=LETTER
Job REPORT (queue LQA1, entry 401) pending
$ REQUEST/REPLY/TO=PRINTER -
_$ "Have queued job 401 as FORM=LETTER;   can you print it?"
%OPCOM-S-OPRNOTIF, operator notified, waiting...10:42:16.10
%OPCOM-S-OPREPLY, AFTER 11:00
19-APR-2000 10:25:32.40, request 3 completed by operator OPA0

An operator working with magnetic tapes would also use additional REPLY qualifiers specific to magnetic tape operations. For more information, see Section 9.9.2.4. For detailed information about the REPLY command and its qualifiers, refer to the VSI OpenVMS DCL Dictionary.

Example

%%%%%%%%%%  OPCOM, 19-APR-2000 10:20:50.39  %%%%%%%%%%%
           request 5 from user ROBINSON
           Please mount volume GRAPHIC_FILES in device _DUA11:
           Shelf 4 - slot B
$ REPLY/TO=5 "SUBSTITUTE  DUA4"

At some point, you might want to create a new system disk. For example, suppose that your existing system disk is an RA81 disk. If you purchase a larger RA90 disk and want to use it as your system disk, you could use the VMSKITBLD BUILD option to build a new system disk on the RA90 disk.

If you want to build your operating system on another disk and you are not concerned about losing the current contents of the target disk, use the BUILD option as described in the following procedure.

How to Perform This Task

Example

* Enter mounted SOURCE disk name (ddcu:): SYS$SYSDEVICE:
* Enter SOURCE disk top level system directory [default = SYS0]:
* Enter TARGET disk name (ddcu:): DUA0:
* Enter the TARGET disk's label [default = VAXVMSRL5]:
* Enter TARGET disk top level system directory [default = SYS0]:
    The target disk will be initialized.
* Target disk, _DUA0:, ready to be initialized? (Y/N): Y
    Target disk, _DUA0:, has been initialized.
%MOUNT-I-MOUNTED, VAXVMSRL5   mounted on _DUA0:
    Creating system specific directories ...
    Creating cluster common directories ...
    Creating SYSGEN files ...
%SYSGEN-I-CREATED, _DUA0:SWAPFILE.SYS; 1 created
%SYSGEN-I-CREATED, _DUA0:PAGEFILE.SYS; 1 created
%SYSGEN-I-CREATED, _DUA0:SYSDUMP.DMP; 1 created
    Copying files from source disk ...
    Copying DECwindows file from source disk ...
    Writing a boot block ...
    System disk complete.
$

SYSBOOT> USE DEFAULT

SYSBOOT> SET STARTUP_P1 "MIN"
SYSBOOT> CONTINUE
.
.
.
$ SET DEFAULT SYS$COMMON:[SYSEXE]
$ RUN AUTHORIZE
UAF> CREATE/RIGHTS
UAF> CREATE/PROXY
UAF> EXIT
$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT CHECK_FEEDBACK
.
.
.

You can use VMSKITBLD to copy the operating system files to a target disk without deleting the files already existing on the target disk. For example, if you accidentally delete a large number of system files from a system disk, you can use VMSKITBLD to copy the system files from another system disk.

To do this, the operating system must be running and the source disk that you intend to copy from must be mounted.

When you use the COPY option of VMSKITBLD.COM, the user-modified files (including SYSUAF.DAT and site-specific command files) are notcopied from the source disk; VMSKITBLD uses the unaltered TEMPLATE versions of these files. In addition, the procedure does not create the system-specific files SWAPFILE.SYS, PAGEFILE.SYS, or SYSDUMP.DMP.

Before VMSKITBLD copies each new system file, it deletes the older version of the file from the target disk.

How to Perform This Task

Example

* Enter mounted SOURCE disk name (ddcu:): SYS$SYSDEVICE:
* Enter SOURCE top level system directory [default = SYS0]:
* Enter TARGET disk name (ddcu:): DUA0:
* Enter TARGET disk top level system directory [default = SYS0]: SYSA
%DCL-I-ALLOC, _DUA0: allocated
%MOUNT-I-MOUNTED, VAXVMSRL5 mounted on _DUA0:
    Copying files from source disk ...
    Copying DECwindows files from source disk ...
    Writing a boot block ...
    System disk complete.
$

Use the ADD option to create an alternate system root directory on a target system disk. You might use this option to create a test environment where you can test software without interfering with the current version of the system.

The ADD option creates only new specific root directories. The current common directory is linked to the new root.

How to Perform This Task

Example

* Enter mounted SOURCE disk name (ddcu:): SYS$SYSDEVICE:
* Enter SOURCE top level system directory [default = SYS0]:
* Enter TARGET disk name (ddcu:): SHEMP$DUA5:
* Enter TARGET disk top level system directory [default = SYS0]:
%DCL-I-ALLOC, _SHEMP$DUA5: allocated
%MOUNT-I-MOUNTED, VAXVMSRL5   mounted on _SHEMP$DUA5:
    Creating system specific directories ...
    Creating SYSGEN files ...
%SYSGEN-I-CREATED, _SHEMP$DUA5:SWAPFILE.SYS; 1 created
%SYSGEN-I-CREATED, _SHEMP$DUA5:PAGEFILE.SYS; 1 created
%SYSGEN-I-CREATED, _SHEMP$DUA5:SYSDUMP.DMP; 1 created
    System disk complete.
$ 

SYSBOOT> USE DEFAULT
SYSBOOT> SET STARTUP_P1 "MIN"
SYSBOOT> CONTINUE
.
.
.
$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT CHECK_FEEDBACK
.
.
.

A license refers to the authorization you have to use a product. The License Management Facility (LMF) enables you to register, manage, and track software licenses on line.

A Product Authorization Key (PAK) contains information that is provided for many VSI products. The data provided in the PAK allows you to register a software license in the license database on a system.

For more information about loading licenses, refer to the VSI OpenVMS License Management Utility Guide.

The /NO_SHARE qualifier for the LICENSE MODIFY command lets you add the NO_SHARE option to a PAK registered in a license database (LDB). NO_SHARE PAKs are assigned to a single node in an OpenVMS Cluster system. A NO_SHARE PAK cannot be shared with other OpenVMS Cluster nodes.

This qualifier remedies problems that occasionally occur when you attempt to use the PAK of a software product for which you already have other PAKs in your LDB. The PAK does not combine with the other PAKs for the same software product, resulting in LICENSE-W-NOCOMB warnings. Often, the license is not loaded on the nodes on which you want it loaded.

Products are stored in a save set, which is a specially formatted file that contains a group of files. Installation and upgrade procedures move the files from the save set to your system disk.

The product-list parameter lists the products that you want to install. You can use this parameter when you install layered products or update the operating system. (When you perform an upgrade procedure, you can list only one product, VMSvvu.)

facvvu

If you are installing from a distribution kit, the list of products on your distribution media is included with the bill of materials for the distribution kit. If the list is not available, you can obtain one by using the DIRECTORY command; the distribution media then finds and displays the products that are included.

How to Perform This Task

To obtain the product list, enter commands in the following format:

MOUNT/OVERRIDE=ID device: DIRECTORY device:[0,0]

where device is the drive that holds the distribution media.

DIRECTORY node::device:[directory]

Examples

You specify each option by entering the appropriate option letter after the keyword OPTIONS in the command that starts VMSINSTAL.COM. The OPTIONS keyword is optional. However, if you have an option list, you must enter OPTIONS before it. If you enter an option list without the OPTIONS keyword, VMSINSTAL.COM displays an informational error message and the installation ends. (The option-list parameter lists the options requested.)

How to Perform This Task

If you specify more than one option, separate the options with commas. Do not separate the options with spaces.

Example

$ @VMSINSTAL.COM NEWAID021 MTA0: OPTIONS A,N

The VMSINSTAL.COM command procedure includes a BACKUP command that copies the save sets to the destination directory. You can verify, log, and confirm the copy operation by specifying BACKUP qualifiers with the VMSINSTAL.COM Get Save Set option. See Section 3.5.3 for more information.

When the product is installed, back up the updated system disk. For instructions, see Section 11.17.

The Autoanswer option makes it easier to reinstall a product by providing responses to VMSINSTAL.COM questions and prompts during the reinstallation. You use the Autoanswer option most often to reinstall products after an upgrade.

If you specify the Autoanswer option when you install a product initially, an answer file is created in the form product.ANS in the SYS$UPDATE directory, where product is the product name parameter that you provide when you start VMSINSTAL.COM.

The answer file contains a record of your responses to questions and prompts from VMSINSTAL.COM. For example, if you install the product NEWAID010 with the Autoanswer option, VMSINSTAL.COM creates an answer file called NEWAID010.ANS.

When you reinstall the product and specify the Autoanswer option (typically after upgrading your operating system), VMSINSTAL.COM reads the answer file instead of asking you questions.

If you want to create a new answer file when you reinstall a product, you must first delete the existing answer file.

Example

$ SYS$UPDATE:VMSINSTAL.COM NEW$PRODUCT010 CSA1: OPTIONS A

$ TYPE SYS$COMMON:[SYSUPD]NEW$PRODUCT010.ANS;1
* Do you want to install the entire kit [Y]? \
* Are these selections correct [Y]? \
* Does this product have an authorization key registered and loaded? \Y
* Will you allow a system shutdown after this product is installed [YES]? \
* How many minutes for system shutdown [0]: \
* Do you want to do an automatic system reboot [YES]? \
$

You can use the Alternate Working Device option to specify an alternate working device for the temporary working directory (defined as the logical name VMI$KWD). This option allows you to perform an installation with fewer free blocks on the system disk than are otherwise required.

SYS$SPECIFIC:[SYSUPD.facvvu]

Table 3.1 explains the format of facvvu.

How to Perform This Task

AWD=dev:[dir]

Specifying a directory is optional. If you do not specify a directory, VMSINSTAL.COM creates the working directory on the specified device with the following directory specification: [000000. facvvu]. If you specify a directory, VMSINSTAL.COM creates the working directory as a subdirectory within the directory that you specify (for example, [WORK. facvvu]). If the directory that you specify does not exist, VMSINSTAL.COM does not create it.

Example

$ @SYS$UPDATE:VMSINSTAL.COM NEWAID010 CSA1: OPTIONS AWD=DUA2:[INSTALL]

Installing products either from a distribution tape or from console media directly onto your system disk is time-consuming. The Get Save Set option saves you time by allowing you to copy product save sets and store them temporarily while you do other work; you can then perform an update more quickly at a time that is convenient for you.

You might consider dedicating a user disk on a node that other licensed system users can access. You can store product save sets on this dedicated user disk to give other licensed system users fast access to the product save-set directory.

@SYS$UPDATE:VMSINSTAL.COM product-list source OPTIONS G device:[directory]

$ @SYS$UPDATE:VMSINSTAL.COM NEWAID010 CSA1: OPTIONS G USER1:[PRODUCTS]

$ @SYS$UPDATE:VMSINSTAL.COM NEWAID010 CSA1: OPTIONS G,N USER1:[PRODUCTS]

facvvu.x

@SYS$UPDATE:VMSINSTAL product-list device:[directory]

$ @SYS$UPDATE:VMSINSTAL NEWAID010 USER1:[PRODUCTS]

$ @SYS$UPDATE:VMSINSTAL TEST042 DUA0:[KITS] OPTIONS G DUB0:[KITS] -
_$ "VERIFY/LOG/CONFIRM"

The File Log option logs all file activity to the terminal during installation. File activity as any action that alters the disposition of a file, such as creating a new file, updating a library, or deleting a file.

The release notes file receives the file name facvvu. release_notes, where facvvu represents the product name code, version, and update numbers (see Table 3.1); for example, NEWAID010.RELEASE_NOTES.

How to Perform This Task

Release notes included with this kit are always copied to SYS$HELP.

Additional Release Notes Options:
     1. Display release notes
     2. Print release notes
     3. Both 1 and 2
     4. None of the above.
 *Select option [2]:
 *Queue name [SYS$PRINT]:
 *Do you want to continue the installation [N]:

%VMSINSTAL.COM-W-NOFILE, New File facvvu.RELEASE_NOTES does not exist.
%VMSINSTAL.COM-W-NORELNOTE, unable to locate release notes.
*Do you want to continue the installation [N]:

You can use the Alternate Root option to install the product on a system disk other than that of the running system. You might use this option to test a layered product without disturbing the running system

$ PURGE/LOG SYS$SYSROOT:[*...]*.*

The following files are used by the POLYCENTER Software Installation utility:

Software products compliant with the POLYCENTER Software Installation utility are distributed in one of three formats:

A software product kit packaged in sequential copy format has a container file named in the following format:

producer-base-product-version-kit_type.PCSI

A software product kit packaged in reference copy format has a product description file in the root directory named in the following format:

producer-base-product-version-kit_type.PCSI$DESCRIPTION

Each subfield is separated by a hyphen and is defined as follows:

You can create a PCF before or during an installation. You can also create more than one PCF for each product, thereby helping you to customize software installations for unique hardware situations or for different usage patterns within a group.

If a PCF is present and it contains a response for a configuration choice, the default for that choice comes from the PCF. The PCF specifies whether the choice can be changed or whether it is required.

If a PCF is not present or does not contain a response for a configuration choice, the default choice comes from one of two places:

$ PRODUCT CONFIGURE CHESSMASTER

$ PRODUCT CONFIGURE VMS/SOURCE=SYS$SYSDEVICE:[VMS$COMMON]/LOG -
_$ /CONFIGURATION=(OUTPUT=MYPCF)[Return]
The following product has been selected:
DEC AXPVMS VMS V7.1 [Available]
Do you want to continue [YES] [Return]
Configuration phase starting ...
You will be asked to choose options, if any, for each selected product and for
any products that may be installed to satisfy software dependency requirements.
*** DEC AXPVMS VMS V7.1: OpenVMS Operating System
Copyright © 1996 Digital Equipment Corporation
    Digital Equipment Corporation
    Do you want the defaults for all options? [YES] N [Return] (1)
    Accounting Log Report Generator Utility [YES] [F17] (2)
%PCSIUI-I-DEFER, that item has been deferred; please set the default value
    Accounting Log Report Generator Utility [YES] [F17] (3)
%PCSIUI-I-UNDEFER, that item is no longer deferred; please set the value
    Accounting Log Report Generator Utility [YES] [F17] (3)
%PCSIUI-I-DEFER, that item has been deferred; please set the default value.
    Accounting Log Report Generator Utility [YES] [Return] (4)
    Access Control List Utilities [YES] [F18] (5)
%PCSIUI-I-UNWRITE, that item will not be written to configuration file;
please set the value.
    Access Control List Utilities [YES] [Return] (6)
    Print and Batch Queue Utilities [YES] NO (7)
    DECdtm Distributed Transaction Manager [YES] [Return] (8)
    Do you want the defaults for all suboptions? [YES] NO
.
.
.
    Programming Support [YES] [Return]
    Do you want the defaults for all suboptions? [YES] NO

.
.
.
    Do you want to review the options ?[NO] [Return] (9)
%PCSI-I-WRICON, writing configuration file
    SYS$SYSDEVICE:[VMS$COMMON]MYPCF.PCSI$CONFIGURATION;1 (10)
%PCSIUI-I-SUCCONFIG, CONFIGURE operation completed successfully
$

$ PRODUCT CONFIGURE -
_$ /CONFIGURATION=(INPUT=PRODUCTA_REV1.DAT,OUTPUT=PRODUCTA_REV2.DAT) -
_$ PRODUCTA

The POLYCENTER Software Installation utility automatically stores information about product installation, configuration choices, and objects, such as files and directories, that make up the product in the product database. The product database is useful for recalling information about products installed on your system and for detecting and tracking product dependencies.

$ PRODUCT REGISTER PRODUCT TOOLCHEST

$ @SYS$UPDATE:PCSI$REGISTER_PRODUCT.COM

You can use recovery data sets in the following circumstances:

A recovery data set is, in a sense, an extension of the POLYCENTER Software Installation utility product database. A recovery data set consists of the following types of files:

A recovery data set is, in other words, a combination of the directories and files that are replaced by newer ones when a patch kit is installed. Recovery data set files are saved in a designated directory for possible future use. The data files that describe the replaced files and directories and their contexts are also saved.

Recovery data sets are stored in the following directory tree on the same system disk as the product database files, where nnn is the recovery data set number:

[PCSI$UNDO_nnn]

The two major uses of recovery data sets are discussed in the next two sections.

$ PRODUCT INSTALL/RECOVERY_MODE

$ PRODUCT INSTALL/SAVE_RECOVERY_DATA

$ PRODUCT INSTALL (without the /SAVE_RECOVERY_DATA qualifier)
$ PRODUCT RECONFIGURE
$ PRODUCT REGISTER PRODUCT
$ PRODUCT REMOVE

Before installing software, follow these steps:

$ DEFINE PCSI$SOURCE DISK1:[KITS]
$ DEFINE PCSI$DESTINATION DISK2:[APPLICATIONS]

To read a product's release notes, extract the notes to a file. For example, use either of the following commands to copy the CMS product release notes to a text file:

$ PRODUCT EXTRACT RELEASE_NOTES CMS/FILE=CMS_RELNOTES.TXT
$ PRODUCT EXTRACT RELEASE_NOTES CMS/SOURCE=WORK_DISK:[KITS]/FILE=CMS_RELNOTES.TXT

If you do not specify a file name, the release notes are written to a file in the current directory. The name specified in the kit is used. It is not necessary to install a software product before you use the POLYCENTER Software Installation utility to extract its release notes.

To start an installation, enter the PRODUCT INSTALL command. For example:

$  PRODUCT INSTALL CMS

To install more than one product at a time, enter a list of product names separated by commas. You can use asterisk (*) wildcard characters in the product names. For example:

$  PRODUCT INSTALL CMS/VERSION=3.4,LSE,COB*/VERSION=5.0

Table 3.6 lists some of the features you can control with command qualifiers. A complete list is in the VSI OpenVMS System Management Utilities Reference Manual and in online help.

$ PRODUCT INSTALL/CONFIGURATION=INPUT=DEC-VAXVMS-CMS.PCSI$CONFIGURATION -
_$ CMS/VERSION=3.4

$ PRODUCT INSTALL/CONFIGURATION=OUTPUT=CMSV3.DAT CMS/VERSION=3.0

During an installation, you can request a full description of product options or an explanation to any single question. You can also accept the default value to any single question or to an entire subset of questions.

$ PRODUCT INSTALL UCX
   .
   .
   .
Optional example files may be installed... [YES] [Help]
The example files include client server programming examples.
Block Size -      Total:    507  Optional:      0  Required:    507
Global Pages -    Total:      0  Optional:      0  Required:    0
Global Sections - Total:      0  Optional:      0  Required:    0
Optional example files may be installed... [YES]
   .
   .
   .

Do you want the defaults for all options? [YES]

After you respond to questions about product options, the POLYCENTER Software Installation utility can display a summary of your answers. For example:

Do you want to review the options? [YES]
DEC TCP/IP Services for OpenVMS
    Optional example files may be installed...: NO
    Optional NFS files may be installed...: NO
    Optional applications may be installed...: YES

The POLYCENTER Software Installation utility then asks:

Are you satisfied with these options? [YES]

If you are not, answer NO to this question. You can then either enter your answers again or exit the installation procedure:

Do you want to change any options? [YES] NO

%PCSIUI-I-USERABORT, operation terminated by user

By answering NO to this question, you can end the installation procedure. The product is not installed; your system remains unchanged.

To run the POLYCENTER Software Installation utility as a batch job, include PRODUCT commands in a command procedure file and then submit the file to a batch queue. In the command procedure, include the /CONFIGURATION qualifier to specify an existing PCF so the POLYCENTER Software Installation utility can respond to questions about product options and configuration choices. If you do not specify /CONFIGURATION, the defaults are used.

Example 3.2 shows how a product might be installed using a command procedure. The example sets and restores VERIFY, and times the installation.

$ SAVE_PROC_VERIFY = F$ENVIRONMENT("VERIFY_PROCEDURE")
$ SAVE_IMAGE_VERIFY = F$ENVIRONMENT("VERIFY_IMAGE")
$ SET VERIFY
$ ON ERROR THEN GOTO ERROR_EXIT
$ START_TIME = F$TIME()
$ WRITE SYS$OUTPUT "START TIME -- ''START_TIME'"
$ PRODUCT INSTALL CHESSMASTER -
    /CONFIGURATION=PRODUCER -
    /HELP -
    /LOG
$ERROR_EXIT:
$ END_TIME = F$TIME()
$ TEMP = F$VERIFY(SAVE_PROC_VERIFY,SAVE_IMAGE_VERIFY)
$ WRITE SYS$OUTPUT "  --------------------------------"
$ WRITE SYS$OUTPUT "  END TIME -- ''END_TIME'"
$ WRITE SYS$OUTPUT "  START TIME -- ''START_TIME'"
$ WRITE SYS$OUTPUT "  --------------------------------"
$ EXIT

A patch kit is not like common software products that you can easily remove from the system using the PRODUCT REMOVE command after the product is installed. In most cases, a patch kit is simply a subset of the full product you apply it to and usually does not force a change in the version number of the product.

Because of these characteristics, the POLYCENTER Software Installation utility treats patch kits in a special way. If you want to be able to uninstall a patch kit that turns out to be defective, for example, you first need to install the patch kit with the /SAVE_RECOVERY_DATA qualifier. This qualifier forces all the files and modules that the installation modifies or replaces to be saved in a specially designated area on the system disk. These files include the product database of the utility and special data files that describe the saved environment. Together, they form a recovery data set.

Later, if you decide to uninstall the patch kit using the PRODUCT UNDO PATCH command, the patch kit objects are deleted and the saved recovery data set is used to reinstate the displaced files along with the database.

After you install a product, you can change the configuration choices made during the installation. This is called reconfiguration. You choose the options you want; the POLYCENTER Software Installation utility makes all the necessary changes.

To change the configuration choices for an installed product, use the PRODUCT RECONFIGURE command. The product kit must be present in the user's default directory or specified by the /SOURCE qualifier or by the PCSI$SOURCE logical name.

To record a changed volume label in the product database, enter the PRODUCT REGISTER VOLUME command. You will be prompted for the old volume label and the name of the device where the volume is mounted.

This command replaces all occurrences of the old volume label with the new volume label. (The POLYCENTER Software Installation utility reads the new label from the disk.)

Note that PRODUCT REGISTER VOLUME changes the information in the product database only; it does not change the label on the volume. To rename a volume, use the DCL command SET VOLUME. Then use PRODUCT REGISTER VOLUME to record the new name.

You can also use the PRODUCT REGISTER VOLUME command to record a change in the physical or logical device name.

You can use the POLYCENTER Software Installation utility to copy product distribution kits from one location to another. If you transfer a kit from tape to disk, you can change the format from a sequential copy to a reference copy.

To copy a software kit from one location to another, use the PRODUCT COPY command. Specify the current location with the /SOURCE qualifier and the new location with the /DESTINATION qualifier. For example:

$ PRODUCT COPY/SOURCE=WORK_DISK:[KITS]/DESTINATION=LOCAL_DISK:[KIT_INSTALL] CMS

You can convert a software kit from reference format (on disk or CD-ROM) to sequential format, from sequential format to reference format, or from sequential format to compressed format by using the /FORMAT qualifier with PRODUCT COPY.

For example, to convert CMS from sequential format to reference format, enter the following command:

$ PRODUCT COPY/FORMAT=REFERENCE/SOURCE=MUA1:/DESTINATION=LOCAL_DISK:[KIT_INSTALL] -
_$ CMS

All of the information stored by the product database (PDB) can be accessed by using the SHOW OBJECT, SHOW PRODUCT, and SHOW HISTORY commands. This section describes how to use these commands to retrieve information from the PDB.

You can access certain information in the patch recovery data set by using the SHOW RECOVERY_DATA command. Table 3-10 lists questions that this command can answer.

You might discover that you are running low on free system disk space and, at the same time, have a stable software product environment after installation of a number of patches. To increase the size of the free disk space, you might want to consider deleting some patch recovery data that you do not expect to use. The PRODUCT DELETE RECOVERY_DATA command allows you to do this. Table 3-11 lists options that are available with this command.

When you use the POLYCENTER Software Installation utility to remove an installed product, all of the files, accounts, and other objects that were created for the product when it was installed are removed from your system and from the product database.

To remove an installed product, enter PRODUCT REMOVE. For example:

$ PRODUCT REMOVE CMS

To uninstall patch kits, you can use the PRODUCT UNDO PATCH command. However, this command works only if you have installed the kits with the /SAVE_RECOVERY_DATA qualifier. Also, the saved recovery data must be available on the system, which is possible only if, after installing the patch kits, you did not perform another operation that deleted the patch recovery data. Operations that automatically destroy recovery data sets are the following:

PRODUCT DELETE RECOVERY_DATA

PRODUCT INSTALL (without the /SAVE_RECOVERY_DATA qualifier)

PRODUCT RECONFIGURE

PRODUCT REMOVE

PRODUCT REGISTER PRODUCT

After using the PRODUCT SHOW RECOVERY_DATA command to verify that patch recovery data is available, you can perform the uninstall operation using the PRODUCT UNDO PATCH command. This command allows for some flexibility:

To speed up the time between system power-on and user login, you can now defer a portion of memory testing on AlphaServer 4100 computers. When you choose this option, the console tests a minimum amount of memory and leaves the rest for the operating system to test.

Although you should not modify STARTUP.COM, sometimes you may want to control site-independent startup when booting your system. For information, see Section 4.5.

For information about site-specific startup command procedures, see Section 5.2.

In a conversational boot operation, you can show and modify values for individual parameters?. The system modifies the values both in memory and in the system parameter file.

How to Perform This Task

Example

SYSBOOT> SHOW UAFALTERNATE

Parameter Name            Current    Default     Min.    Max.    Unit
Dynamic
--------------            -------    -------    -------  -------   ----
UAFALTERNATE                    0          0         0         1   Boolean
SYSBOOT> SET UAFALTERNATE 1
SYSBOOT> CONTINUE

In programming research and development environments where you must alter operating conditions for experimentation, testing, and debugging, you might want to temporarily boot your system using system parameter values stored in a parameter file other than the default parameter file. The conversational boot operation lets you reset active values using a different parameter file.

How to Perform This Task

Example

SYSBOOT> USE ALTPARAMS.DAT
SYSBOOT> CONTINUE

If the current values stored in the parameter file have been incorrectly modified, these incorrect values might cause the system to become unbootable. With a conversational boot operation, you can reset the active values for all system parameters to the default value.

Note that in most cases, VSI recommends that you use AUTOGEN to modify system parameters. In special cases, however, you can use a conversational boot to modify a parameter value temporarily. To change a parameter value permanently, you must edit MODPARAMS.DAT and run AUTOGEN. For instructions, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

How to Perform This Task

Example

SYSBOOT> USE DEFAULT
SYSBOOT> SET WRITESYSPARAMS 0
SYSBOOT> SET STARTUP_P1 "MIN"
SYSBOOT> CONTINUE
Username: SYSTEM
Password:
$ EDIT SYS$SYSTEM:MODPARAMS.DAT



[Insert the following line in MODPARAMS.DAT:]
MIN_NPAGEDYN = 2999808



$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT

If the system does not complete the startup procedures or does not allow you to log in, bypass the startup and login procedures. The startup and login procedures provided by VSI should always work. However, if you introduce an error when modifying the startup or login procedures, you can accidentally lock yourself out of the system. The following instructions tell you what to do in such a situation.

How to Perform This Task

Example

SYSBOOT> SET/STARTUP OPA0:
SYSBOOT> SET WRITESYSPARAMS 0
SYSBOOT> CONTINUE
$ SET NOON
$ SET DEFAULT SYS$SYSROOT:[SYSEXE]
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> PARAMETERS USE CURRENT
SYSMAN> PARAMETERS SET/STARTUP SYS$SYSTEM:STARTUP.COM
SYSMAN> PARAMETERS WRITE CURRENT
SYSMAN> EXIT
$ @SYS$SYSTEM:STARTUP

Setting the system parameter UAFALTERNATE defines the logical name SYSUAF to refer to the file SYS$SYSTEM:SYSUAFALT.DAT. If this file is found during a normal login, the system uses it to validate the account and prompts you for the user name and password.

If it cannot find this file, the system assumes that the UAF is corrupt and accepts any user name and any two passwords to log you in to the system from the system console. Logins are prohibited from all other terminal lines.

How to Perform This Task

Example

SYSBOOT> SET UAFALTERNATE 1
SYSBOOT> SET WINDOW_SYSTEM 0
SYSBOOT> CONTINUE
Username: [Return]
Password: [Return]
Password: [Return]
$ DEFINE/SYSTEM/EXECUTIVE_MODE SYSUAF SYS$SYSTEM:SYSUAF.DAT
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
AUTHORIZE> MODIFY SYSTEM/PASSWORD=FGLFTUTU
AUTHORIZE> EXIT
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> PARAMETERS USE CURRENT
SYSMAN> PARAMETERS SET WINDOW_SYSTEM 1
SYSMAN> PARAMETERS SET UAFALTERNATE 0
SYSMAN> PARAMETERS WRITE CURRENT
SYSMAN> EXIT
$ @SYS$SYSTEM:SHUTDOWN

The default system startup procedure is SYS$SYSTEM:STARTUP.COM. VSI recommends you do not modify STARTUP.COM. However, in special environments, you might want the system to perform special startup commands. The conversational boot lets you specify that the system temporarily use an alternate startup procedure.

You can also perform site-specific startup events by adding commands to the site-specific startup command procedures. For more information, see Section 5.2.

How to Perform This Task

To make your alternate site-independent startup procedure the default startup procedure, see Section 4.5.2.

Example

SYSBOOT> SHOW/STARTUP
Startup command file = SYS$SYSTEM:STARTUP.COM
SYSBOOT> SET/STARTUP SYS$SYSTEM:XSTARTUP.COM
SYSBOOT> SHOW/STARTUP
Startup command file = SYS$SYSTEM:XSTARTUP.COM
SYSBOOT> CONTINUE