System Manager’s Manual, Volume 1: Essentials

Document Number: DO-DSYMV1-01A
Publication Date: May 2024
Operating System and Version:
VSI OpenVMS x86-64 Version 9.2-1 or higher;
VSI OpenVMS IA-64 Version 8.4-1H1 or higher
VSI OpenVMS Alpha Version 8.4-2L1 or higher

Preface

1. About VSI

VMS Software, Inc. (VSI) is an independent software company licensed by Hewlett Packard Enterprise to develop and support the OpenVMS operating system.

2. Intended Audience

This guide is intended for VSI OpenVMS system managers.

4. Related Documents

  • VSI OpenVMS System Management Utilities Reference Manual

  • VSI OpenVMS User's Manual

  • The current version of the Upgrade and Installation Manual for your system

  • VSI OpenVMS Guide to System Security

  • Guide to OpenVMS Performance Management

  • VSI OpenVMS Cluster Systems Manual and Guidelines for OpenVMS Cluster Configurations

  • VSI TCP/IP Services for OpenVMS Installation and Configuration

  • VSI TCP/IP Services for OpenVMS Management

  • VSI TCP/IP Services for OpenVMS Management Command Reference

  • VSI TCP/IP Services for OpenVMS Tuning and Troubleshooting

  • VSI DECnet-Plus for OpenVMS Installation and Configuration

  • VSI DECnet-Plus Planning Guide

  • DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration Guide

  • VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide

5. VSI Encourages Your Comments

You may send comments or suggestions regarding this manual or any VSI document by sending electronic mail to the following Internet address: . Users who have VSI OpenVMS support contracts through VSI can contact for help with this product.

6. OpenVMS Documentation

The full VSI OpenVMS documentation set can be found on the VMS Software Documentation webpage at https://docs.vmssoftware.com.

7. Typographical Conventions

The following conventions may be used in this manual:
ConventionMeaning

Ctrl/x

A sequence such as Ctrl/x indicates that you must hold down the key labeled Ctrl while you press another key or a pointing device button.

PF1 x

A sequence such as PF1 x indicates that you must first press and release the key labeled PF1 and then press and release another key or a pointing device button.

...
A horizontal ellipsis in examples indicates one of the following possibilities:
  • Additional optional arguments in a statement have been omitted.

  • The preceding item or items can be repeated one or more times.

  • Additional parameters, values, or other information can be entered.

.
.
.

A vertical ellipsis indicates the omission of items from a code example or command format; the items are omitted because they are not important to the topic being discussed.

( )

In command format descriptions, parentheses indicate that you must enclose the options in parentheses if you choose more than one.

[ ]

In command format descriptions, brackets indicate optional choices. You can choose one or more items or no items. Do not type the brackets on the command line. However, you must include the brackets in the syntax for OpenVMS directory specifications and for a substring specification in an assignment statement.

[ |]

In command format descriptions, vertical bars separate choices within brackets or braces. Within brackets, the choices are options; within braces, at least one choice is required. Do not type the vertical bars on the command line.

{ }

In command format descriptions, braces indicate required choices; you must choose at least one of the items listed. Do not type the braces on the command line.

bold text

This typeface represents the introduction of a new term. It also represents the name of an argument, an attribute, or a reason.

italic text

Italic text indicates important information, complete titles of manuals, or variables. Variables include information that varies in system output (Internal error number), in command lines (/PRODUCER= name), and in command parameters in text (where dd represents the predefined code for the device type).

UPPERCASE TEXT

Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege.

Monospace type

Monospace type indicates code examples and interactive screen displays.

In the C programming language, monospace type in text identifies the following elements: keywords, the names of independently compiled external functions and files, syntax summaries, and references to variables or identifiers introduced in an example.

-

A hyphen at the end of a command format description, command line, or code line indicates that the command or statement continues on the following line.

numbers

All numbers in text are assumed to be decimal unless otherwise noted. Nondecimal radixes—binary, octal, or hexadecimal—are explicitly indicated.

Chapter 1. Overview of This Manual

Together, the two parts of this manual explain tasks and concepts related to managing a VSI OpenVMS system. This chapter describes this manual and how to use it.

The VSI OpenVMS System Manager's Manual explains system management tasks for new and experienced system managers. However, before performing these tasks, you should be familiar with the following items:
  • User-level tasks such as creating and editing files and command procedures. For more information, refer to the VSI OpenVMS System Manager's Manual.

  • DIGITAL Command Language (DCL) commands. For more information, refer to the VSI OpenVMS DCL Dictionary.

Information Provided in This Chapter

This chapter describes the following tasks:

Task

Section

Using the VSI OpenVMS System Manager's Manual

Section 1.1

Finding information about managing complex environments

Section 1.3

Finding information about managing small systems

Section 1.4

This chapter explains the following concept:

Concept

Section

How this manual relates to other system management documentation

Section 1.2

1.1. Using the VSI OpenVMS System Manager's Manual

The VSI OpenVMS System Manager's Manual is made up of two parts:
  • This book, VSI OpenVMS System Manager's Manual, Volume 1: Essentials.

  • A second book, VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

Use these two books to get step-by-step instructions for general system management tasks.

The first page of each chapter in these books provides two tables to help you find information within the chapter.

The Task Table

The first table lists the major tasks described in the chapter. If you need to perform a task quickly, go directly to the section that explains that task. For example, in this chapter the task table lists the following tasks:

Task

Section

Using the VSI OpenVMS System Manager's Manual

Section 1.1

Finding information about managing complex environments

Section 1.3

Finding information about managing small systems

Section 1.4

The Concept Table

The second table lists the major concepts explained in the chapter. If you want to learn more about an underlying concept, go to the appropriate concept section. For example, the concept table in this chapter lists the following concept:

Concept

Section

How this manual relates to other system management documentation

Section 1.2

1.2. How This Manual Relates to Other System Management Documentation

This manual is intended to be used as a companion to other OpenVMS system management manuals. The Preface of this manual lists the books you should be prepared to use along with the VSI OpenVMS System Manager's Manual.

1.3. Finding Information About Managing Complex Environments

If you are managing large or complex configurations, you will need additional specialized information. Table 1.1 lists some typical environments and OpenVMS manuals containing specialized information for managing those environments.
Table 1.1. Documentation for Managing Complex Environments

Task

Manual

Networked environments

VSI TCP/IP Services for OpenVMS Management VSI DECnet-Plus for OpenVMS Network Management Guide

OpenVMS Cluster environments

VSI OpenVMS Cluster Systems Manual and Guidelines for OpenVMS Cluster Configurations

Migrating from VAX to Alpha environment

Migrating an Environment from OpenVMS VAX to OpenVMS Alpha ?

Performance management

OpenVMS Performance Management Manual

System security

VSI OpenVMS Guide to System Security

1.4. Finding Information About Managing Small Systems

If you are managing a small standalone system – for example, a desktop workstation – you probably need to perform only basic system management tasks.

Table 1.2 lists the tasks you are likely to perform, and where to find instructions for performing these tasks.
Table 1.2. Documentation for Managing Small Standalone Systems

Task

Chapter, Section, or Other Manual

Installing and upgrading the operating system

The current Installation and Upgrade Manual

Installing layered products

Section 3.1

Loading software licenses

Section 3.2.2

Booting the system

Section 4.1.3.1

Shutting down the system

Section 4.8.1

?Using VMSTAILOR to remove files from the system disk

Section 5.1

Modifying site-specific startup command procedures

Section 5.2

Modifying login command procedures

Section 5.3

Setting up user accounts

Chapter 7

Backing up workstation disks

Section 11.15.7

Backing up and restoring the system disk

Section 11.17

Starting the queue manager and creating the queue database

Section 13.5

Setting up and starting simple queues

Section 14.1.1

Setting system parameters with AUTOGEN

VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems

Tuning the system

VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems

Chapter 2. Using OpenVMS System Management Utilities and Tools

This chapter provides general information about system management utilities and tools that are provided with the VSI OpenVMS Operating System.

Procedures for using utilities and tools to perform specific tasks are provided in the respective chapters that describe those tasks. For example, this chapter contains a general description of the System Management utility (SYSMAN). Section 9.12.2 describes how to use SYSMAN to manage disk quotas. VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems describes how to use SYSMAN to manage system parameters.

To use system management tools, you can also refer to the following documentation:
  • Online help for online information about commands and qualifiers for DCL and system management utilities

  • The VSI OpenVMS System Management Utilities Reference Manual for detailed information about commands and qualifiers for system management utilities

  • The VSI OpenVMS DCL Dictionary for detailed information about DCL commands and qualifiers

Information Provided in This Chapter

This chapter describes the following tasks:

Task

Section

Logging in to the SYSTEM account

Section 2.2

Using SYSMAN to centralize system management

Section 2.3

Using OPCOM to communicate with system users

Section 2.4

Using VMSKITBLD.COM to modify a system disk

Section 2.5

This chapter explains the following concepts:

Concept

Section

OpenVMS system management tools

Section 2.1

DCL commands for system management

Section 2.1.2

System messages

Section 2.1.3

DCL command procedures for system management

Section 2.1.4

System management utilities

Section 2.1.5

MGRMENU.COM command procedure

Section 2.1.6

System Management utility (SYSMAN)

Section 2.3.1

Understanding a SYSMAN management environment

Section 2.3.3

Understanding a SYSMAN profile

Section 2.3.5

Understanding OPCOM

Section 2.4.1

2.1. Understanding OpenVMS System Management Tools

VSI supplies the following software tools to monitor and control system operations and resources:

Tool

For More Information

OpenVMS Management Station

Section 2.1.1

DIGITAL Command Language (DCL) commands; for example, COPY and MOUNT

Section 2.1.2

System messages

Section 2.1.3

Command procedures; for example, AUTOGEN.COM and STARTUP.COM

Section 2.1.4

System management utilities; for example, the Authorize utility (AUTHORIZE) and the Backup utility (BACKUP)

Section 2.1.5

MGRMENU.COM command procedure

Section 2.1.6

OPCOM

Section 2.4

2.1.1. OpenVMS Management Station

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.

Figure 2.1. Sample OpenVMS Management Station Screen
Sample OpenVMS Management Station Screen
OpenVMS Management Station addresses the problem of having to use multiple utilities to manage accounts. For example, creating an account usually involves the following steps:
  1. Add a UAF entry

  2. Grant rights identifiers

  3. Create a directory

  4. Create disk quotas

  5. Grant network proxies

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.

The OpenVMS Management Station consists of two components:
  • The client. This is Microsoft Windows based software that you install on a PC and use to perform management operations.

  • The server. This software must be installed on all OpenVMS systems to be managed. You do not interact directly with the server, the client does that.

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.

Information about installing the OpenVMS Management Station on your Alpha or I64 computer and your PC is located in the following manual:
  • VSI OpenVMS Version 8.2 Upgrade and Installation Manual

2.1.1.1. Managing Resources

OpenVMS Management Station allows you to organize the systems you need to manage in ways that are meaningful to you and your environment, and allows you to manage user accounts on those systems.

You can easily manage user accounts across multiple OpenVMS systems, depending on your needs. The systems might be some of the clusters in a network, all of the systems on one floor of a building, a mix of clusters and nonclustered nodes, and so forth.

You can use OpenVMS Management Station to manage OpenVMS user accounts in a convenient, easy manner. For example, when creating an account on multiple systems, OpenVMS Management Station can add a user authorization file (UAF) entry, grant rights identifiers, create an OpenVMS directory, set a disk quota, set up OpenVMS Mail characteristics, and so forth, for each instance of the account.

OpenVMS Management Station manages the following OpenVMS resources:
  • The SYSUAF.DAT user authorization file

  • The RIGHTSLIST.DAT user rights file

  • The network proxy database

  • Account login-directory trees

  • User account disk quotas

  • The OpenVMS Mail VMSMAIL_PROFILE.DATA file

2.1.1.2. Managing Operations

The OpenVMS Management Station supports the following account management operations:
  • Creating user accounts

  • Modifying user accounts (any aspect)

  • Deleting user accounts

  • Renaming user accounts

  • Displaying user account attributes

2.1.2. DCL Commands

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).

The general format of a DCL command is as follows:
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.

2.1.3. System Messages

When you enter commands in DCL or in utilities, the system returns messages to help you understand the result of each command. System messages can indicate the following information:
  • Successful completion of a command

  • Information about the effect of the command

  • Warning about the effect of the command

  • Failure to successfully complete the command

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.

2.1.4. DCL Command Procedures

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.

A simple command procedure can contain a sequence of commands that you use frequently. For example, you could include the following commands in a command procedure called GO_WORK.COM:
$ 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.

2.1.4.1. Executing Command Procedures in Batch Mode

You can execute command procedures in batch modeby submitting the procedure to a batch queue. When resources are available, the system creates a batch process to execute the commands in the procedure. Usually, processes running in batch mode execute at a lower process priority to avoid competing with interactive users for system resources.

You might execute a command procedure in batch mode for the following reasons:
  • To automate a task

  • To process work at a lower scheduling priority, so as not to compete with interactive users for system resources

  • To perform a task during off hours, such as at night or on weekends

  • To allow an operation to continue without having a terminal logged in, thereby increasing the security of the system

A batch-oriented command procedure can include a command to resubmit itself to a batch queue, thereby repetitively performing the task with no user intervention. For example, you might create a batch-oriented command procedure to run the Analyze/Disk_Structure utility (ANALYZE/DISK_STRUCTURE) to report disk errors. If you include a command to resubmit the procedure to a batch queue, the procedure will automatically execute when scheduled, unless errors cause the procedure to fail. The following example is a simple command procedure, named SYSTEM-DAILY.COM:
$ 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

2.1.4.2. Using VSI-Supplied Command Procedures for System Management

VSI provides several command procedures for managing a system. Table 2.1 lists some commonly used command procedures.
Table 2.1. System Management Command Procedures

Command Procedure

Function

SYS$SYSTEM:STARTUP.COM

The system uses this command procedure to automatically perform certain tasks that are required to start up an OpenVMS system. This procedure is executed when the system boots. Do not modify this command procedure.

SYS$STARTUP:SYSTARTUP_VMS.COM

STARTUP.COM executes this procedure when the system boots. Add commands to this procedure to perform site-specific tasks each time the system boots.

SYS$SYSTEM:SHUTDOWN.COM

Use to shut down the system in an orderly fashion.

SYS$UPDATE:AUTOGEN.COM

Use to automatically set system parameters and page, swap, and dump file sizes to values appropriate for the system configuration and work load.

SYS$UPDATE:VMSINSTAL.COM

Use to install software on a running system.

2.1.5. System Management Utilities

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.

You invoke some utilities using the following command format:
RUN SYS$SYSTEM:utility_name
To invoke other utilities, such as MOUNT and ANALYZE/DISK_STRUCTURE, enter a DCL command. For example:
$ ANALYZE/DISK_STRUCTURE
Table 2.2 lists the system management utilities and their purposes. This manual describes how to use most of these utilities. For detailed information about utility commands and qualifiers, refer to the VSI OpenVMS System Management Utilities Reference Manual.
Table 2.2. System Management Utilities and Tools

Utility

Purpose

Accounting utility (ACCOUNTING)

To produce reports of resource use.

ACL editor (access control list editor)

To create and maintain ACLs.

Analyze/Disk_Structure utility (ANALYZE/DISK_STRUCTURE)

To check the validity of Files–11 Structure Levels 1, 2, and 5 disk volumes, and to report errors and inconsistencies. Also used to repair these inconsistencies.

Audit Analysis utility (ANALYZE/AUDIT)

To produce reports and summaries of security events from the system security audit log file. Use this utility to interpret the large amounts of auditing information that the system might generate.

Authorize utility (AUTHORIZE)

To add and modify records in the existing user authorization and network authorization files, or to create new files. Also used to add and modify records in the rights database.

Backup utility (BACKUP)

To copy or save files and disk volumes. Also used to restore saved files and volumes.

Bad Block Locator utility (BAD)

To analyze block-addressable devices and record the location of blocks that cannot reliably store data.

?Crash Log Utility Extractor (CLUE)

On VAX systems, to obtain information about crash dumps.

?On Alpha and I64 systems, some commands in the System Dump Analyzer facility (SDA) contain CLUE functionality.

DECevent Event Management utility

To produce ASCII reports derived from entries in system event log files.

Error Log utility (ERROR LOG)

To report the contents of a system error log file.

Exchange utility (EXCHANGE)

To transfer data to and from mass storage volumes that are written in formats other than standard formats recognized by the operating system.

Help Message utility (MSGHLP)

To quickly access information about system messages returned by DCL commands.

Install utility (INSTALL)

To improve performance or enhance privileges of images.

LAT Control Program utility (LATCP)

To set up and control the LAT software on OpenVMS host systems. LAT software allows you to connect terminals and printers to multiple remote systems.

Log Manager Control Program utility (LMCP)

To create and manage the transaction logs used by DECdtm services.

Multipurpose Internet Mail Extension utility (MIME)

To read and compose MIME-encoded mail messages on OpenVMS system.

Monitor utility (MONITOR)

To monitor systemwide performance.

Mount utility (MOUNT)

To make a disk or magnetic tape volume available for processing.

Network Control Program (NCP)

To set up, control, monitor, and test a DECnet network.

Network Control Language (NCL)

To set up, control, monitor, and test a DECnet-Plus network.

Operator Communication Manager (OPCOM) tool

To communicate with system users.

System Generation utility (SYSGEN)

To create and install page, swap, and dump files and to manage system parameters.

?On VAX systems, to load and connect device drivers.

System Management utility (SYSMAN)

To centralize system management. Allows you to perform system management tasks simultaneously on one or more nodes.

?On Alpha and I64 systems, to load and connect device drivers.

TCP/IP Services management control interfaces

To configure and manage TCP/IP Services.

This manual does not describe the following utilities in detail:

Utility

For More Information

Bad Block Locator utility (BAD)

OpenVMS Bad Block Locator Utility Manual, Online help

Exchange utility (EXCHANGE)

OpenVMS Exchange Utility Manual, Online help

LASTCP and LADCP utilities

InfoServer Client for OpenVMS LASTCP and LADCP Utilities Manual

Network Control Program utility (NCP)

VSI OpenVMS DECnet Network Management Utilities, Online help

Network Control Language utility (NCL)

VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide

TCP/IP Services management control interfaces

VSI TCP/IP Services for OpenVMS Management

2.1.6. MGRMENU.COM Command Procedure

To help you perform basic system management tasks, VSI provides a command procedure named SYS$EXAMPLES:MGRMENU.COM. This procedure displays a menu that you can use to perform the following tasks:
  • Add a user account

  • Build a standalone BACKUP kit

  • Shut down your system

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.

To see and use the menu, enter the following command:
$ @SYS$EXAMPLES:MGRMENU

2.2. Logging In to the SYSTEM Account

Caution

VSI recommends that you change the password for the SYSTEM account frequently to maintain system security. Because the SYSTEM account has full privileges by default, exercise caution when using it.

If your site has strong security requirements, VSI recommends that you disable all but batch use of the SYSTEM account and set up separate privileged accounts for individuals who must perform privileged activities on the system. This will allow you to more closely account for privileged activity on the system.

How to Perform This Task

  1. Press Return on the console terminal.

  2. At the Username prompt, enter SYSTEM.

  3. At the Password prompt, enter the password that you chose for the SYSTEM account when you installed or upgraded the operating system, or the current password if you changed it since then.

  4. The system displays a welcome message on the console terminal. If you have logged in previously, the system also prints the time of your last login. When the dollar sign ($) prompt appears, login is complete and you can enter commands.

Example

On VAX systems:
Username: SYSTEM
Password:
        Welcome to OpenVMS VAX Version n.n on node x
    Last interactive login on Thursday, 20-FEB-2000 16:41
    Last non-interactive login on Friday, 21-FEB-20000 17:06
On Alpha systems:
Username: SYSTEM
Password:
        Welcome to OpenVMS Alpha (TM) Operating System, Version n.n on node x
    Last interactive login on Thursday, 20-FEB-2000 16:41
    Last non-interactive login on Friday, 21-FEB-2000 17:06

On I64 systems:

Username: SYSTEM
Password:
        Welcome to HP OpenVMS Industry Standard I64 Operating System, Version n.n on node x
    Last interactive login on Thursday, 20-FEB-2004 16:41
    Last non-interactive login on Friday, 21-FEB-2004 17:06

2.3. Using SYSMAN to Centralize System Management

If you manage more than one computer, you can use the System Management (SYSMAN) utility to centralize system management.

The following table lists some major SYSMAN features and points to sections in this chapter that contain more information.

Function

For More Information

Enable a system to execute SYSMAN commands from remote nodes

Section 2.3.2

Define your SYSMAN management environment

Section 2.3.4

Adjust your SYSMAN profile to set privileges, default device and directory, and DCL verification

Section 2.3.6

Execute DCL commands from SYSMAN

Section 2.3.8

Create SYSMAN command procedures

Section 2.3.9

Set up SYSMAN with an initialization file

Section 2.3.10

2.3.1. Understanding SYSMAN

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.

2.3.1.1. Privileges Required

You must have the following to run SYSMAN:

  • OPER and TMPMBX privileges

  • A separate account with no more than 125 rights, or enough identifiers removed from the current account so the total number of rights falls within the appropriate range.

    The rights limitation of 125 includes a minimum of three identifiers that are granted during login when the process rights list is created:
    • A UIC identifier

    • A system identifier

    • At least one environmental identifier, depending upon the environment in which the process is operating

2.3.1.2. Usage Restriction

If you run SYSMAN from an account with more than 125 rights identifiers, and the environment is set to a remote node, the following error message is displayed:

SMI-E-RIGHTSLIM, Rights limit exceeded.

Note that this rights identifier limitation includes a minimum of three identifiers besides the rights identifiers that are associated with a user authorization record:

  • A UIC identifier

  • A system identifier

  • Depending upon the environment in which the process is operating, at least one environmental identifier

To run SYSMAN, you must have either of the following:

  • A separate account with no more than 125 rights identifiers

  • Enough identifiers removed from your current account so that the total number of rights falls within the appropriate range

2.3.1.3. Tools and Commands

SYSMAN uses many of the same software tools that you traditionally use to manage a system. It can process most DCL commands, such as MOUNT and INITIALIZE. It can also execute many system management utilities and command procedures, such as AUTHORIZE and AUTOGEN.

SYSMAN also includes its own commands that let you perform the following tasks:

CommandTaskFor More Information
ALF (automatic login facility)Associate a terminal or port with a user nameSection 3.2.2
CONFIGURATIONInspect or modify OpenVMS Cluster parametersVSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems
DISKQUOTAControl and monitor disk usageSection 9.12.2
IO (Alpha specific)Control and display the I/O configuration of an Alpha systemSection 8.5.1
LICENSELoad and unload licensesSection 3.2.2
PARAMETERSInspect and modify system parametersVSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems
STARTUPCustomize startup databases by inspecting and modifying software startup componentsSection 5.4

2.3.2. Enabling a Remote System to Execute SYSMAN Commands

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.

2.3.3. Understanding a SYSMAN Management Environment

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:

  • Your own OpenVMS Cluster system

  • A subset of nodes in your OpenVMS Cluster system

  • A nonclustered node available through DECnet

  • Another OpenVMS Cluster system

  • A subset of nodes in another OpenVMS Cluster system

  • Any group of individual nodes

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

Figure 2.2. Sample SYSMAN Management Environment
Sample SYSMAN Management Environment

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.

2.3.4. Defining the SYSMAN Management Environment

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.

2.3.4.1. Defining Another Node as the Environment

You can define a management environment to be any node available through DECnet. To define one or more nodes to be your management environment, use the SET ENVIRONMENT/NODE command.

For the following examples, refer to Figure 2.2; assume you are logged in to NODE 21.

Examples

  1. $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> SET ENVIRONMENT/NODE=NODE22
    %SYSMAN-I-ENV, current command environment:
            Individual nodes: NODE22
            Username ALEXIS will be used on nonlocal nodes

    The SET ENVIRONMENT command in this example defines the management environment to be NODE22. (The command does not, however, set the environment to be Cluster 1.)

  2. SYSMAN> SET ENVIRONMENT/NODE=(NODE23, NODE24, NODE25)
    Remote Password:
    %SYSMAN-I-ENV, Current Command Environment:
            Individual nodes: NODE23, NODE24, NODE25
            At least one node is not in local cluster
            Username ALEXIS   will be used on nonlocal nodes

    The SET ENVIRONMENT command in this example defines the management environment to be a group of nodes --- NODE23, NODE24, and NODE25 --- that are in two separate clusters.

  3. SYSMAN> SET ENVIRONMENT/CLUSTER/NODE=NODE24
    Remote Password:
    %SYSMAN-I-ENV, current command environment:
     Clusterwide on remote cluster NODE24
     Username ALEXIS will be used on nonlocal nodes
    SYSMAN> DO SHOW TIME
    %SYSMAN-I-OUTPUT, command execution on node NODE24
      13-AUG-1996 13:07:54
    %SYSMAN-I-OUTPUT, command execution on node NODE25
      13-AUG-1996 13:10:28

    The SET ENVIRONMENT command in this example defines the management environment to be a cluster that includes NODE24---that is, Cluster 2.

2.3.4.2. Using Logical Names to Organize Management Environments

If you want to organize the nodes in your cluster according to specific categories (for example, all CI-based nodes or all nodes with C installed), you can define logical names to use with the SET ENVIRONMENT/NODE command, as follows:

  1. Create the logical name table SYSMAN$NODE_TABLE by putting the following command into the file SYS$MANAGER:SYLOGICALS.COM, which is executed during system startup:

    $ CREATE/NAME_TABLE/PARENT=LNM$SYSTEM_DIRECTORY SYSMAN$NODE_TABLE
  2. Define one or more logical names to be a node or list of nodes by putting a command similar to the following into SYS$MANAGER:SYLOGICALS.COM:

    $ DEFINE CI_NODES NODE21, NODE22, NODE23/TABLE=SYSMAN$NODE_TABLE
  3. When you set your SYSMAN environment from the DCL level, specify one of the logical names you created for this purpose. For example:

    $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> SET ENVIRONMENT/NODE=(CI_NODES)
    
    Remote Password:
    
    %SYSMAN-I-ENV, current command environment:
            Individual nodes: NODE21, NODE22, NODE23
            At least one node is not in the local cluster.
            Username SYSTEM       will be used on nonlocal nodes.

You can also define logical names for VAX and Alpha nodes in a dual-architecture OpenVMS Cluster system, as explained in VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

Example

The following example demonstrates how you can define multiple logical names to organize several management environments:

$ 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.

2.3.4.3. Defining an OpenVMS Cluster Environment

To define your management environment to be an OpenVMS Cluster system, use the SET ENVIRONMENT/CLUSTER command.

In SYSMAN, OpenVMS Cluster environments can be one of two types:
OpenVMS Cluster EnvironmentDefinition
LocalCluster from which you are using SYSMAN
NonlocalAny cluster other than the one from which you are executing SYSMAN

To expand the management environment in Figure 2.2 from NODE21 to Cluster 1, enter the following command from NODE21:

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

In the OpenVMS Cluster environment shown in Figure 2.2, SYSMAN executes commands on all nodes in Cluster 1, namely NODE21, NODE22, and NODE23.

To manage a nonlocal cluster with SYSMAN, use the /NODE qualifier to identify the cluster. If you define an OpenVMS Cluster alias, the /NODE qualifier can use the alias rather than the node name.

If you use the /CLUSTER and /NODE qualifiers together, the environment becomes the OpenVMS Cluster system where the given node is a member. For example, to perform management tasks on Cluster 2 in Figure 2.2, enter SET ENVIRONMENT with the /CLUSTER qualifier and name one node within Cluster 2 using the /NODE qualifier:

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

For information about using SYSMAN to manage an OpenVMS Cluster system that contains both Alpha and VAX nodes, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

2.3.5. Understanding Your SYSMAN Profile

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:

  • If the environment is an OpenVMS Cluster system that has common SYSUAF and RIGHTSLIST databases, SYSMAN assigns the profile in effect on the local node to the SMISERVER process on the target node or nodes. This profile includes both authorized and current privileges.

  • If the environment is an OpenVMS Cluster system and does not have common SYSUAF and RIGHTSLIST databases, SYSMAN checks the SYSUAF on the target nodes to see if you are an authorized user. If you are an authorized user, SYSMAN copies your profile from the SYSUAF on the target nodes to the SMISERVER process on the target nodes.

  • If the environment has nodes that are not part of your local cluster, or if you have recently changed your user name, SYSMAN prompts you for a password before it checks the SYSUAF on the target node. If you enter the correct password and the SYSUAF shows that you are an authorized user, SYSMAN copies your profile from the SYSUAF on the target nodes to the SMISERVER process on the target nodes.

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.

2.3.6. Adjusting Your SYSMAN Profile

Use the SYSMAN command SET PROFILE to change your SYSMAN management profile. The qualifiers /PRIVILEGES, /DEFAULT, and /VERIFY enable you to change the following attributes of the SMISERVER process:
AttributeQualifierFor More Information
Current privileges/PRIVILEGESSection 2.3.6.1
Default device and directory/DEFAULTSection 2.3.6.2
DCL verification of DO commands/VERIFYSection 2.3.7

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.

2.3.6.1. Changing Your Current Privileges

The SYSMAN command SET PROFILE/PRIVILEGES temporarily changes your current privileges in an environment.

Frequently, system management commands require special privileges. You might need to add privileges before you execute certain commands in an environment. System managers usually have the same privileges on all nodes; if you do not have the required privileges on a node, SYSMAN cannot execute the command and returns an error message.

Example

The following example makes SYSPRV one of your current privileges:

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

2.3.6.2. Changing Your Default Device and Directory

Use the SET PROFILE/DEFAULT command to reset the default device and directory specification for your process and all server processes in the environment.

Most often, the default device and directory specified in your UAF record is a first-level directory in which you create and maintain files and subdirectories. SYSMAN uses this default device and directory name when resolving file specifications. It also assigns the default device and directory name to any files that you create during a session.

In some cases, you might need to change the default device and directory in your SYSMAN profile. For example, you might have a directory containing command procedures as well as some system management utilities that require the default directory to be SYS$SYSTEM.

Example

The following example sets the default device and directory to DMA1:[SMITH.COM]:

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

2.3.7. Setting DCL Verification

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

2.3.8. Executing DCL Commands from SYSMAN

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

2.3.9. Creating SYSMAN Command Procedures

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>

2.3.10. Setting Up SYSMAN with an Initialization File

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"
   ...

2.4. Using OPCOM to Communicate with System Users

The operator communication manager (OPCOM) is a tool for communicating with users and operators on the system. OPCOM allows you to perform the following functions:

Function

For More Information

To broadcast messages to users who are logged in

Section 2.4.3

To control the use of OPA0: as an operator terminal

Section 2.4.4

To designate terminals as operator terminals, enabling them to display messages broadcast by OPCOM

Section 2.4.5

To record messages broadcast by OPCOM in a log file

VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems

To send requests to an operator ?

Section 2.4.6

To reply to operator requests ?

Section 2.4.7

2.4.1. Understanding OPCOM

Figure 2.3 illustrates the function of OPCOM.

Figure 2.3. Operator Communication Manager (OPCOM)
Operator Communication Manager (OPCOM)

OPCOM Components

OPCOM uses the following components:

Component

Description

For More Information

OPCOM process

The system process that manages OPCOM operations. Unless you disable it, the OPCOM process starts automatically at system startup time.

Section 2.4.2

Operator terminals

Terminals designated to display messages broadcast by OPCOM. Usually, the console terminal (with the device name OPA0:) is the operator terminal. However, you can designate any user terminal as an operator terminal.

Section 2.4.5

Operator log file

A file that records messages broadcast by OPCOM. The file is named SYS$MANAGER:OPERATOR.LOG.

VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems>

OPCOM messages

Messages broadcast by OPCOM. These messages are displayed on operator terminals and written to the operator log file. The messages might be general messages sent by you, user requests, operator replies, or system events.

VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems

REPLY and REQUEST commands

DCL commands that allow you to use and control OPCOM.

Section 2.4.3, Section 2.4.6, and Section 2.4.7

OPCOM Defaults

OPCOM uses the following defaults:
  • OPCOM is started by default on all systems.

  • Except for workstations in an OpenVMS Cluster environment, OPCOM logs messages to OPA0:, which is enabled by default as an operator terminal. The log file SYS$MANAGER:OPERATOR.LOG is opened, and all OPCOM classes are enabled on both the operator terminal and the log file.

    Section 2.4.4 explains how to control the use of OPA0: as an operator terminal. The VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems explains how to specify the default state of operator log files.

OPCOM Requirements

OPCOM has the following requirements:
  • To execute a REPLY command, OPCOM must be running, and you must enter REPLY from a terminal device designated as an operator terminal.

  • The REPLY command requires at least OPER privilege. You must have SHARE privilege if another process is logged in to the designated operator terminal. To enable or disable the security class, you must have SECURITY privilege.

  • To designate an operator terminal in batch or SYSTARTUP, you must assign SYS$COMMAND to a valid terminal device.

2.4.2. Starting OPCOM

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.

To start OPCOM, enter the following command from the system manager's account (SYSTEM):
$ @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.)

2.4.3. Sending Messages to Users

To broadcast a message to users, enter the DCL command REPLY as follows:
REPLY [/qualifier...] ["message-text"]
For example:
$ REPLY/ALL/BELL "Please log off"
Use the following qualifiers to control OPCOM messages:

Qualifier

Description

/ALL

Broadcasts a message to all terminals that are attached to the system or cluster. These terminals must be turned on and have broadcast-message reception enabled.

/BELL

Rings a bell at the terminal receiving a message when entered with the /ALL, /TERMINAL, or /USERNAME qualifier; two bells when entered with the /URGENT qualifier; and three bells when entered with the /SHUTDOWN qualifier.

/NODE[=( node-name[, ...])

Broadcasts a message to the local cluster node only, or to a node or nodes you specify.

/SHUTDOWN

Sends a message beginning SHUTDOWN...; if used with the /BELL qualifier, rings three bells at terminals receiving the message.

/TERMINAL=( terminal-name[, ..])

Broadcasts the message to the specified terminals.

/URGENT

Broadcasts a message beginning URGENT...; if used with the /BELL qualifier, rings two bells at terminals receiving the message.

/USERNAME=( username[, ...])

Broadcasts a message to all terminals at which users are logged in to the system (or cluster), or only to the terminals of the specified users.

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

Examples

The REPLY command in the following example sends a message to all users logged in to node WLDWND. When the message is displayed, a bell rings at the terminal.
$ REPLY/ALL/BELL/NODE=WLDWND "Please log off"
The REPLY command in the following example sends a message to the user logged in at terminal TTC1. When the message is displayed, a bell rings at that terminal.
$ REPLY/BELL/TERMINAL=TTC1: "Your file has completed printing"

2.4.4. Controlling the Use of OPA0: as an Operator Terminal

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”)
You can control the use of OPA0: as an operator terminal, whether or not the node is part of an OpenVMS Cluster system, by defining the following logicals in SYS$MANAGER:SYLOGICALS.COM:

Logical Name

Function

OPC$OPA0_ENABLE

Defined as True or False; if True, specifies that OPA0: is to be enabled as an operator terminal.

OPC$OPA0_CLASSES

Specifies the operator classes that are enabled for OPA0. The logical name can be a search list of the allowed classes, a comma-separated list, or a combination of the two. If you specify an invalid class, all classes are enabled, and a message similar to the following is displayed on the console at system startup and logged to the OPERATOR.LOG file:

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

See Section 2.4.5 for a description of the valid operator classes.

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

2.4.5. Designating Operator Terminals

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

To designate a terminal as an operator terminal, enter the REPLY/ENABLE command at the terminal. For example:
$ 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.

If your facility is large, there may be several operators, each of whom is assigned to specific tasks. If this is the case, you can specify the classes of messages the operator terminal receives and responds to when you enable the operator terminal, as follows:
REPLY/ENABLE=(keyword[, ...])
The following table describes each keyword:

Keyword

Description

CARDS

Displays messages sent to the card readers.

CENTRAL

Displays messages sent to the central system operator.

CLUSTER

Displays messages from the connection manager pertaining to OpenVMS Cluster system state changes.

DEVICES

Displays messages pertaining to mounting disks.

DISKS

Displays messages pertaining to mounting and dismounting disk volumes.

LICENSE

Displays messages pertaining to software licenses.

NETWORK

Displays messages pertaining to networks; the keyword CENTRAL must also be specified to inhibit network messages.

OPER1 to OPER12

Displays messages sent to operators identified as OPER1 to OPER12.

PRINTER

Displays messages pertaining to print requests.

SECURITY

Allows messages pertaining to security events; requires SECURITY privilege.

TAPES

Allows messages pertaining to mounting and dismounting tape volumes.

For example:
$ 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

The following example designates terminal TTA3 as an operator terminal, enabling it to receive messages concerning printers, magnetic tapes and disks, and messages intended for the central operator. Later, it relinquishes terminal TTA3's ability to receive messages concerning tapes. The terminal still receives and can respond to messages about disks and printers and messages directed to CENTRAL.
$ 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

2.4.6. Sending Requests to an Operator

In sites where operators are assigned to assist users by mounting volumes and changing printer forms, users can communicate with operators by entering the DCL command REQUEST and the following qualifiers:

Qualifier

Description

/REPLY

Sends a request and requests a reply to the message. Requests sent with this command are issued a unique identification number to which the operator sends the response. The user cannot enter any commands until the operator responds.

/TO=(operator[, ...])

If your facility is large, there may be several operators, each of whom has specific tasks. The /TO qualifier lets users send requests to a specific operator. Options are as follows: CARDS, CENTRAL, CLUSTER, DEVICES, DISKS, NETWORK, OPER1 to OPER12, PRINTER, SECURITY, TAPES.

The DCL commands MOUNT/ASSIST and BACKUP/ASSIST also request operator assistance. For more information, see the following sections:

Example

An operator is monitoring an operator terminal enabled for the PRINTER class. The following PRINT command submits an output job that requires a special print form (/FORM=LETTER).The REQUEST command sends a message to the operator. After completing the request, the operator would send a reply, as explained in Section 2.4.7.
$ 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

2.4.7. Replying to Operator Requests

In sites where operators are assigned to assist users by mounting volumes and changing printer stock, operators can reply to user requests using the DCL command REPLY and the following qualifiers:

Qualifier

Description

/ABORT= identification-number

Replies to the request specified by the identification number and cancels the request.

/PENDING= identification-number

Replies to the request specified by the identification number and prevents the user from entering other commands until the operator fulfills or aborts the request. The current terminal must be enabled as an operator terminal.

/STATUS

Reports which classes are enabled, and all outstanding user requests for the terminal from which this command was entered. The current terminal must be enabled as an operator terminal.

/TO= identification-number

Replies to the request specified by the identification number and completes the request. The current terminal must be enabled as an operator terminal.

Note that you can also use a variation of the REPLY/TO command in response to a MOUNT/ASSIST and BACKUP/ASSIST commands. For more information, see Section 9.5.3 and Section 11.9.1.

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

In the following example, the REPLY/TO command replies to operator request number 5, issued by user ROBINSON. The MOUNT device is switched to DUA4, and the user is notified.
%%%%%%%%%%  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"

2.5. Using VMSKITBLD.COM to Modify a System Disk

On VAX systems, the command procedure SYS$UPDATE:VMSKITBLD.COM allows you to duplicate system files from an existing system disk on another disk.

The procedure offers the following options:

Option

Description

For More Information

BUILD

Builds a new common system disk after destroying all existing files on the disk.

Section 2.5.1

COPY

Copies the operating system files to an existing disk without destroying nonsystem files that are currently on the disk.

Section 2.5.2

ADD

Adds a new system root directory to an existing system disk.

Section 2.5.3

VMSKITBLD uses two disks:

Disk

Description

Source disk

The disk from which you copy system files. The source disk must be an existing system disk.

Target disk

The disk to which you move the system files.


Caution

Do not attempt to use VMSKITBLD with the current system disk as the target disk. VMSKITBLD.COM deletes files that are required for a running system.

2.5.1. Using VMSKITBLD.COM to Build a New System Disk

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.

The existing system disk is the source disk. The new disk is the target disk.

Caution

The VMSKITBLD BUILD option initializes the target disk, deleting all of its previous contents. For information about copying files to an existing system disk without destroying files, see Section 2.5.2.

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

  1. If the source disk is not the current booted system disk, boot the operating system from the source disk.

  2. Log in to the SYSTEM account.

  3. Make sure the disk is spun up and on line. If you are using a removable disk, you must also place the disk into the appropriate drive.

  4. Enter the following command to invoke VMSKITBLD:
    $ @SYS$UPDATE:VMSKITBLD
    VMSKITBLD prompts you to choose one of the following options:
    * Operation [BUILD, ADD, COPY]?
  5. Enter BUILD and press Return. VMSKITBLD displays messages that either prompt you for information needed to complete the operation or inform you of the procedure's status.
    1. In response to the following prompt, enter the name of the source disk:
      * Enter mounted SOURCE disk name (ddcu:):
    2. In response to the following prompt, enter the top-level system directory for the source disk:
      * Enter SOURCE disk top-level system directory [default = SYS0]:

      In most cases, you can choose the default value [SYS0].

    3. In response to the following prompt, enter the name of the target disk:
      * Enter TARGET disk name (ddcu:):
    4. In response to the following prompt, enter the volume label of the target disk:
      * Enter the TARGET disk's label [default = VAXVMSRL5]: 
    5. In response to the following prompt, enter the top-level system directory:
      * Enter TARGET disk top-level system directory [default = SYS0]:

      In most cases, you can choose the default value [SYS0].

    6. The procedure displays the following message to warn you that the target disk will be initialized and to allow you to stop the procedure:
          The target disk will be initialized.
      * Target disk, _DUA0:, ready to be initialized? (Y/N): Y

      Make sure it is safe to destroy the contents of the target disk, and enter Y to continue.

    When the system displays the dollar sign ($) prompt, the system disk is built. VMSKITBLD automatically dismounts the target disk. At this point, the target disk contains all the operating system files required for a complete system.

  6. Complete the system disk by creating a rights database and network proxy database and configuring the system with appropriate system parameters. For instructions, see Section 2.5.1.1.

  7. To use the new system disk, reboot the system with the new system disk.

Example

The following example runs VMSKITBLD.COM to build a new system disk. It copies the files on the current system disk to create a new system disk on the DUA0: disk.
* 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.
$

2.5.1.1. Completing a System Disk Built with VMSKITBLD.COM

After you create a new system disk using the VMSKITBLD BUILD option, use the following procedure to complete the new system disk:
  1. Boot the new system disk using a conversational boot. For instructions, refer to the upgrade and installation supplement for your computer.

  2. When the SYSBOOT> prompt appears, enter the USE DEFAULT command to boot with default values for all system parameters.

  3. To avoid starting all layered products on a system that is not tuned for them, possibly causing the system to hang, enter SET STARTUP_P1 "MIN" after the SYSBOOT> prompt.

  4. Enter the CONTINUE command to continue booting.

  5. After the system boots, log in to the SYSTEM account. The password for the system account will be the default password, MANAGER. Make sure you change this password.

  6. Use the Authorize utility to create a rights database and a network proxy database. For more information, refer to the VSI OpenVMS Guide to System Security.

  7. Run AUTOGEN from the SAVPARAMS phase to set appropriate values for system parameters. Be sure to specify the CHECK_FEEDBACK option. See VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems and the AUTOGEN section of the VSI OpenVMS System Management Utilities Reference Manual> for detailed information about running AUTOGEN.

    To reboot from the former system disk, specify REBOOT as the end phase when invoking AUTOGEN.

    To reboot the system from the new system disk, specify SHUTDOWN as the end phase and reboot manually, specifying the new system disk.

Example
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
.
.
.

2.5.2. Using VMSKITBLD.COM to Copy System Files to an Existing Disk

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

  1. Log in to the SYSTEM account.

  2. Place the target disk into the appropriate drive.

  3. Note the device name of the target disk.

  4. Enter the following command to invoke VMSKITBLD:
    $ @SYS$UPDATE:VMSKITBLD
    VMSKITBLD prompts you to choose one of the following options:
    Operation [BUILD, ADD, COPY]?
  5. Enter COPY and press Return. VMSKITBLD displays messages that either prompt you for information needed to complete the copy operation or inform you of the procedure's status.
    1. In response to the following prompt, enter the name of the source disk.
      * Enter mounted SOURCE disk name (ddcu:):
    2. In response to the following prompt, enter the top-level system directory for the source disk:
      * Enter SOURCE disk top level system directory [default = SYS0]:

      In most cases, you can choose the default value [SYS0].

    3. In response to the following prompt, enter the name of the target disk:
      * Enter TARGET disk name (ddcu:):
    4. In response to the following prompt, enter the top-level system directory:
      * Enter TARGET disk top level system directory [default = SYS0]:

      In most cases, you can choose the default value [SYS0].

    When the system displays the dollar sign ($) prompt, the files have been copied and the system disk is complete. VMSKITBLD automatically dismounts the target disk.

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.
$

2.5.3. Using VMSKITBLD.COM to Add an Alternate System Root Directory

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 system disk that you are adding to cannot be in use.

Note

Do not use the ADD option to create a system root to add a new system to an OpenVMS Cluster environment. Instead, use the SYS$MANAGER:CLUSTER_CONFIG.COM procedure.

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

How to Perform This Task

  1. Log in to the SYSTEM account.

  2. Check the number of free blocks on the system disk to make sure you have adequate space for the new files, including SWAPFILE.SYS, PAGEFILE.SYS, and SYSDUMP.DMP. The sizes of these files are determined by the type of computer you use. For information about calculating size for page, swap, and dump files, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

  3. Make sure the target system disk is dismounted and on line.

  4. Enter the following command to invoke VMSKITBLD:
    $ @SYS$UPDATE:VMSKITBLD
    VMSKITBLD prompts you to choose one of the following options:
    Operation [BUILD, ADD, COPY]?
  5. Enter ADD and press Return. VMSKITBLD displays messages that either prompt you for information needed to complete the operation or inform you of the procedure's status.
    1. In response to the following prompt, enter SYS$SYSDEVICE and press Return:
      * Enter mounted SOURCE disk name (ddcu:):
    2. In response to the following prompt, press Return to choose the default:
      * Enter SOURCE disk top level system directory [default = SYS0]:
    3. In response to the following prompt, enter the name of the target disk:
      * Enter TARGET disk name (ddcu:):
    4. In response to the following prompt, enter the new root directory specification:
      * Enter TARGET disk top level system directory [default = SYS0]:
      Do not specify directories SYSE or SYSF:
      • SYSE is reserved for storing standalone BACKUP.

      • SYSF is reserved for VSI use.

    When the system displays the dollar sign ($) prompt, the target system directory contains the new system root directory. VMSKITBLD automatically dismounts the target disk.

  6. Configure the new system root by booting the target disk and running AUTOGEN. For instructions, see Section 2.5.3.1.

Example

The following example adds an alternate system root directory named SYSA on the target disk SHEMP$DUA5:
* 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.
$ 

2.5.3.1. Configuring a System Root Added with VMSKITBLD

After you use VMSKITBLD to add an alternate system root directory to a system disk, you must configure system parameters for the new root. Perform the following steps:
  1. Shut down the system and halt your computer. For instructions on shutting down your system, see Section 4.8.1.

  2. Perform a conversational boot, as described in the upgrade and installation supplement for your computer.

  3. When the conversational boot prompt (SYSBOOT>) appears, enter the following commands:
    SYSBOOT> USE DEFAULT
    SYSBOOT> SET STARTUP_P1 "MIN"
    SYSBOOT> CONTINUE
  4. After the system boots, log in to the SYSTEM account and execute AUTOGEN from the SAVPARAMS phase to set appropriate values for system parameters.

    To reboot from the former root, specify REBOOT as the end phase when invoking AUTOGEN.

    To reboot from the new root directory, specify SHUTDOWN as the AUTOGEN end phase, and reboot manually. See VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems and the VSI OpenVMS System Management Utilities Reference Manual (AUTOGEN) for detailed information about AUTOGEN.

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

Chapter 3. Installing, Upgrading, and Updating Software

This chapter describes the concepts related to installing, upgrading, and updating OpenVMS layered products.

Note

Instructions for installing, upgrading, and updating the OpenVMS operating system software are in the current OpenVMS Upgrade and Installation Manual for VAX, Alpha, or I64 systems.

Two methods are available for installing or upgrading layered-product software:

  • The VMSINSTAL.COM command procedure

  • The POLYCENTER Software Installation utility

Each layered product is packaged to use one of these. Refer to the layered product's documentation for information about which to use.

Information Provided in This Chapter

This chapter describes the following tasks:

Task

Section

Installing layered product software

Section 3.1

Using VMSINSTAL.COM to install layered software

Section 3.2 through Section 3.5

Using the POLYCENTER Software Installation utility

Section 3.5 through Section 3.8.8

This chapter explains the following concepts:

Concept

Section

VMSINSTAL.COM

Section 3.2

POLYCENTER Software Installation utility

Section 3.6

3.1. Installing or Upgrading Layered Products

If you are installing or upgrading a layered product using VMSINSTAL.COM, review the information in the following sections:

Task

Section

Preparing your system to run VMSINSTAL.COM

Section 3.2

Running VMSINSTAL.COM

Section 3.3

Recovering from a system failure

Section 3.4

Selecting VMSINSTAL.COM options

Section 3.5

Note that these sections do not describe specific VMSINSTAL.COM procedures. The examples used are for illustration only. For details of a particular product, refer to the installation documentation for the specific product.

If you are installing or upgrading a layered product using the POLYCENTER Software Installation utility, refer to Section 3.6 and to the layered product installation documentation.

Task

Section

Using the POLYCENTER Software Installation utility

Section 3.6

Installing software

Section 3.7

Performing operations on installed software

Section 3.8

Removing installed software

Section 3.8.8

3.2. Preparing Your System to Run VMSINSTAL.COM

This section provides guidelines for preparing your system for using VMSINSTAL.COM. Note that each software product that you install might not require you to follow all of the guidelines listed in this section.

3.2.1. Performing Preliminary Operations

Before you use VMSINSTAL.COM, perform the following operations (not necessarily in the order listed):
  • Back up your system disk, as described in Section 11.17. Use the backup copy as a working copy for the installation.

    VMSINSTAL.COM might delete the older version of the product before it installs the newer version. If the system fails during installation, you might have to make a new working copy of the system disk and restart the installation.

  • Log in to the SYSTEM account at the console terminal.

  • Be sure all users have logged out and all batch jobs have completed by using, respectively, the SHOW USERS and SHOW SYSTEM/BATCH commands. Keep users off the system until VMSINSTAL.COM completes by using the following command:
    $ SET LOGINS/INTERACTIVE=0

    Note

    If you cannot log off all users during the installation of a layered product that updates the DCL help library, note that the help files for that layered product will not be installed if a user on the system is accessing DCL help. The installation procedure generates warning messages and stores the help files in a working directory.

  • Shut down network software.

  • Check system parameters. (GBLPAGES, GBLSECTIONS and NPAGEDYN often need to be adjusted.) Read the documentation supplied with each layered product to be installed, and find out if the product has any specific resource requirements.

    If you must change parameter values, increase the values by adding ADD_ parameter-name symbols to MODPARAMS.DAT. (See VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.)

    Use AUTOGEN with feedback to size the system resources properly. (See VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.)

  • Make sure the limits in the SYSTEM account authorization record are equal to or greater than the recommended limits.

    To check these limits, run the Authorize utility (AUTHORIZE) to display the current limits of the SYSTEM account's user authorization file.

    To run AUTHORIZE, enter the following commands:
    $ SET DEFAULT SYS$SYSTEM
    $ RUN AUTHORIZE
    At the UAF prompt (UAF>), enter the following command:
    UAF> SHOW SYSTEM

    See Section 7.1.2 for details.

  • If necessary, use the Authorize utility to modify the SYSTEM account limits. Changes you make do not take effect until you log out and log in again.

    For example, to increase the DIOLM limit to 100, enter the following command:
    UAF> MODIFY SYSTEM/DIOLM=100

    See Section 7.1.2 for details.

  • Physically mount the first distribution media that contains the software product. See Section 9.5 for details.

  • Register and load licenses, as explained in the next section.

3.2.2. Registering and Loading Licenses

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.

If you did not register and load your operating system license during the installation of the OpenVMS operating system, you must perform that task (and register other licenses, if necessary) before you install other software products, as explained in the following steps:
  1. Log in to the system manager's account, SYSTEM.

  2. Register the license in one of two ways:
    • Invoke the SYS$UPDATE:VMSLICENSE.COM procedure. When it prompts you for information, respond with data listed on your operating system PAK. (You can register other software product licenses at this time as well.)

    • At the DCL prompt, enter the LICENSE REGISTER command with the appropriate qualifiers that correspond to License PAK information.

  3. Use either of the following utilities to load a license:
    • License Management Facility (LMF), which loads the PAK only on the local node.

    • System Management utility (SYSMAN), which allows you to load the PAK throughout an entire cluster. (SYSMAN LICENSE commands are a subset of LMF commands.)

    Only the local node requires the installation of a license before you use VMSINSTAL.COM.

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

3.2.3. Preventing Nodes from Sharing PAKs

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.

To remedy this problem, perform the following actions:
  1. Add the NO_SHARE option to the PAK or PAKs causing the NOCOMB warnings.

  2. Assign each PAK to a specific OpenVMS Cluster node.

3.3. Running VMSINSTAL.COM

Before you run VMSINSTAL.COM, note the following points:
  • Read the installation instructions for the specific product or update. If you need assistance during an installation, enter a question mark (?) for an explanation of possible responses.

  • When you first start VMSINSTAL.COM, the procedure displays several prompts and messages that direct and explain the installation. These prompts and messages differ, depending on the software product that you are installing.

  • When the procedure asks if you are satisfied with the backup of your system disk, back up your system disk before continuing with the installation if you do not have a recent backup of your system disk.

  • If you do not satisfy all conditions required to start VMSINSTAL.COM, the procedure displays a warning message explaining the problem and asks you if you want to continue. VSI strongly recommends that you satisfy these conditions before you try to start VMSINSTAL.COM again.

    Caution

    If you continue the procedure without making the required corrections, VSI cannot guarantee that the installation will be supported.

How to Perform This Task

To run VMSINSTAL.COM, enter a command in the following format:
@SYS$UPDATE:VMSINSTAL product-list source: [OPTIONS option-list]  [destination] [qualifiers]

Example

$ @SYS$UPDATE:VMSINSTAL CALENDAR020 MUA0:

The command in this example installs the product CALENDAR, from save sets named CALENDAR020, on a magnetic tape on the MUA0: drive. (This command shows the simplest case, in which you use no options or qualifiers.)

The following sections explain required and optional parameters in the VMSINSTAL.COM command line:

Parameter

Section

Product list

Section 3.3.1

Source

Section 3.3.2

Options

Section 3.3.3

Destination

Section 3.3.4

Backup qualifiers

Section 3.3.5 and Section 3.5.3.3

Section 3.3.6 explains how to complete an installation.

3.3.1. Selecting a Product List

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.)

Note

Do not use the wildcard character (*) if you are installing layered products and updating the operating system at the same time. In this case, update the system first. If you use the wildcard character, VMSINSTAL sorts the product list in alphabetical order; the operating system would probably not be installed first.

If you want to specify more than one item in the product-list parameter, separate the items using commas and no intervening spaces. Use the following format to specify the product list:
facvvu
Table 3.1 explains the format of facvvu. Using this format, you can install a specific version and update of a product from distribution media containing several versions and updates. If you do not include a version and update number, all versions and updates to the specified product from the source are installed in alphabetical order.
Table 3.1. Format of facvvu Save-Set File Name

fac

The product name code (1 to 36 alphanumeric characters)

vv

The major version number (2 digits)

u

The minor version number (1 digit), also known as update number

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.

If you are installing from a disk directory, obtain the product list by entering DIRECTORY and specifying the disk directory in the following format:
DIRECTORY node::device:[directory]

Examples

  1. $ MOUNT/OVERRIDE=ID MUA0:
    %MOUNT-I-MOUNTED, VMS071
           mounted on _MUA0:
    $ DIRECTORY MUA0:[0,0]
    The DIRECTORY command in this example directs the distribution media to find the products included on the MUA0: drive; for example:
    Directory MUA0:[000,000]
    000000.DIR;1        BACKUP.SYS;1        BADBLK.SYS;1        BADLOG.SYS;1
    BITMAP.SYS;1        CONTIN.SYS;1        CORIMG.SYS;1        DECW071.C;1
    DECW071.D;1         DECW071.E;1         DECW071.F;1         INDEXF.SYS;1
    ISL_SCRIPT.ESS;1    SECURITY.SYS;1      SYS0.DIR;1          VMS071.A;1
    VMS071.B;1          VMS071.C;1          VMS071.D;1          VMS071.E;1
    VMS071.F;1          VOLSET.SYS;1
    
    Total of 22 files.
  2. $ DIRECTORY BRAVO::DUA1:[0,0]

    The DIRECTORY command in this example directs the distribution media to find the products on the node BRAVO, which is on the DUA1: device.

Note

To access a remote node, you must have read and execute access (R,E) to the directory.

3.3.2. Selecting the Source

The source parameter identifies the source of the optional software product as one of the following ones:
  • A drive that holds the distribution media; for example, a TK50 drive designated as the MUA0: drive.

  • A disk directory to which the product save set has been transferred from the distribution media for later installation.

    You specify a disk directory as the source when you select the Get Save Set option. For more information about this option, see Section 3.5.3

  • A disk directory on another node.

You can also use a logical name to specify the source. If you do not specify the source, VMSINSTAL.COM asks you for it, as follows:
* Where will the distribution volumes be mounted:

3.3.3. Selecting Options

The VMSINSTAL.COM command procedure permits the use of six options. Table 3.2 briefly describes each option. Section 3.5 contains a detailed description of each option.
Table 3.2. VMSINSTAL.COM Options

Letter Choice

Option

Description

A

Autoanswer

Makes it easier to reinstall a product after an upgrade by providing responses to the questions and prompts during the reinstallation. (Specify this option only when installing layered products.)

AWD=

Alternate Working Device

Lets you specify an alternate working device for the temporary working directory. (You can specify this option when installing layered products or applying updates.)

G

Get Save Set

Saves you time by allowing you to store product save sets temporarily on a magnetic tape or in a disk directory. (Specify this option only when installing layered products.)

L

File Log

Logs all file activity to the terminal during installation.

N

Release Notes

Displays or prints the online release notes file supplied by the layered product.

R

Alternate Root

Lets you install the product on a system disk other than that of the running system.

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

To specify each option:
  1. Invoke the VMSINSTAL.COM procedure, entering appropriate option letters after the keyword OPTIONS.

  2. Press Return.

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

3.3.4. Selecting the Destination

The destination parameter is optional. By default, VMSINSTAL.COM assumes that the product is to be installed in the system common directory SYS$COMMON on the system disk. However, you must use this parameter in the following two instances:
  • To install the product in an alternate root. The product is installed on a system disk other than that on which the target system is running. Specify the alternate system root in the following format:
    device:[SYSn.]
    where:

    device

    The device on which the alternate root resides

    SYSn.

    The top-level directory of the alternate system root

    You can also specify a previously defined logical name for the alternate root.

  • To copy the product kit save sets into a storage directory for later installation. For more information about the Get Save Set option, see Section 3.5.3.

    Specify the destination directory in the following format:
    device:[directory]
    where:

    device

    The destination disk device

    directory

    Usually a directory dedicated to product save sets on the specified disk

3.3.5. Verifying, Logging, and Confirming the Operation

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.

3.3.6. Completing the Installation

When the installation is complete, VMSINSTAL.COM performs one of the following actions, depending on the requirements of the product you have installed:
  • Performs an automatic shutdown of the system; you might be instructed to reboot manually.

  • Returns you to the system prompt.

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

3.4. Recovering from a System Failure

If the system fails during installation of an update or optional software product, VMSINSTAL.COM attempts to continue the installation upon rebooting. Depending on when the system failed, one of three conditions exists:
  • The system disk was not altered before the system failure. In this case, VMSINSTAL.COM instructs you to restart the installation.

  • The system disk or a library used by the installation was corrupted. In this case, VMSINSTAL.COM instructs you to restore either the system disk or the corrupted library from the backup copy and to restart the installation.

  • VMSINSTAL.COM continues the installation. In this case, the procedure performs most of the installation. In addition, VMSINSTAL.COM might tell you that you must perform some tasks manually to complete the installation.

3.5. Selecting VMSINSTAL.COM Options in Detail

When you use VMSINSTAL.COM, the command procedure allows you to select up to six options (summarized previously in Table 3.2.) The following sections describe those VMSINSTAL.COM options in detail.

3.5.1. Using the Autoanswer Option (A) (Layered Products Only)

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

To use the Autoanswer option, specify the following command:
$ SYS$UPDATE:VMSINSTAL.COM NEW$PRODUCT010 CSA1: OPTIONS A
You can then examine the file:
$ 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]? \
$

3.5.2. Using the Alternate Working Device Option (AWD=)

Restriction

Before using this option, check with the product's installation guide to be sure this option is supported by that product.

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.

If you do not specify this option, VMSINSTAL.COM creates the temporary working directory in the following location:
SYS$SPECIFIC:[SYSUPD.facvvu]

Table 3.1 explains the format of facvvu.

How to Perform This Task

Use the following format to specify this option:
AWD=dev:[dir]
where:

dev

Specifies the alternate working device

dir

Specifies the directory under which the facvvu subdirectory will be created

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

To use the working directory [INSTALL] on the alternate device DUA2:, issue the following command:
$ @SYS$UPDATE:VMSINSTAL.COM NEWAID010 CSA1: OPTIONS AWD=DUA2:[INSTALL]

3.5.3. Using the Get Save Set Option (G) (Layered Products Only)

Note

You cannot use this option to copy operating system kits.

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.

3.5.3.1. Storing a Product Save Set

To store a product save set on a disk directory using the Get Save Set option, enter a command using the following syntax:
@SYS$UPDATE:VMSINSTAL.COM product-list source OPTIONS G device:[directory]

The directory you specify must exist, and the device must be mounted.

Examples
If you specify just one option, enter the disk directory name immediately after the OPTIONS G parameter, leaving a space between G and the disk directory. For example, if you are storing save sets for a product named NEWAID010 from the console drive into disk directory USER1:[PRODUCTS], enter the following command:
$ @SYS$UPDATE:VMSINSTAL.COM NEWAID010 CSA1: OPTIONS G USER1:[PRODUCTS]
If you specify more than one option, place the disk directory name after the last option, leaving a space between the last option and the disk directory name. For example:
$ @SYS$UPDATE:VMSINSTAL.COM NEWAID010 CSA1: OPTIONS G,N USER1:[PRODUCTS]
VMSINSTAL.COM creates one or more files to store the product save set in the disk directory. The save-set file name has the following format:
facvvu.x
Table 3.1 explains the format of facvvu. The format of the file type ( x) is:

x

A literal file type that identifies save-set files, where A is the first save set, B the second, and so forth

3.5.3.2. Installing a Product

To install the product on your system, enter a command in the following format:
@SYS$UPDATE:VMSINSTAL product-list device:[directory]
Example
For the product NEWAID010, enter this command:
$ @SYS$UPDATE:VMSINSTAL NEWAID010 USER1:[PRODUCTS]

VMSINSTAL.COM installs the NEWAID product on your system disk.

3.5.3.3. Specifying Backup Qualifiers

When you use the Get Save Set option, you can specify three BACKUP command qualifiers: /VERIFY, /LOG, and /CONFIRM. The qualifiers must be enclosed in quotation marks because they are passed as a parameter of the Get Save Set option (G). VMSINSTAL passes the parameter to the BACKUP command within VMSINSTAL. The following example includes the Get Save Set option and BACKUP qualifiers:
$ @SYS$UPDATE:VMSINSTAL TEST042 DUA0:[KITS] OPTIONS G DUB0:[KITS] -
_$ "VERIFY/LOG/CONFIRM"
The following table contains explanations of the qualifiers shown in the example:

Qualifier

Explanation

/VERIFY

Compares the contents of the output specifier with the contents of the input specifier after a save, restore, or copy operation completes. If a file does not compare successfully, an error message reporting this fact is displayed.

/LOG

Causes the file specification of each file processed to be displayed at the terminal during the operation. The default is /NOLOG.

/CONFIRM

Displays a prompt on your terminal before each file is processed. To process the file, enter Y or YES and press the Return key. The system interprets any other response, including simply pressing the Return key, as NO.

Refer to the VSI OpenVMS System Management Utilities Reference Manual for more information about the BACKUP command and its qualifiers.

3.5.4. Using the File Log Option (L)

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.

3.5.5. Using the Release Notes Option (N)

Use the Release Notes option to display or print the online release notes file supplied by a layered product and by the update procedure.

Note

Not all layered products provide online release notes.

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

If release notes are available and you specify option N, VMSINSTAL.COM asks you the following questions. (The default answers are indicated in brackets.)
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.
1 *Select option [2]:
2 *Queue name [SYS$PRINT]:
3 *Do you want to continue the installation [N]:
The following list contains explanations that correspond to the numbered entries in the example:

1

This prompt allows you to choose options 1 through 4.

2

This prompt is displayed only if you select option 2 or option 3. If you enter the name of a print queue, the system displays a message saying that the release notes have been queued successfully to the printer. If you do not specify a print queue, the release notes are sent to SYS$PRINT by default.

3

This prompt allows you either to continue or to end the installation. The default is to end the installation.

If the product does not supply release notes, VMSINSTAL.COM displays two error messages. It also asks whether you want to continue or to end the installation, as follows:
%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]:

To continue the installation (whether or not release notes are available), enter Y (for YES) and press Return.

3.5.6. Using the Alternate Root Option (R)

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

The operating system in the alternate root must be complete and have the same version or update level as the running system. All files and software products that the product installation refers to must be present in the alternate root.

Note

Not all optional software products allow you to install a product on an alternate root. Consult the documentation of the specific product to determine whether you can install the product on an alternate root.

Also, VSI does not support the installation of a product on an alternate root on the existing system disk.

If you specify option R, the product is installed on the alternate root. However, you cannot create accounts or request a system reboot on an alternate root.
$ PURGE/LOG SYS$SYSROOT:[*...]*.*

3.6. Using the POLYCENTER Software Installation Utility

The POLYCENTER Software Installation utility is used to install, remove, and manage layered software products on Alpha or VAX systems. It can also save information about software products such as system requirements, installation options, and your answers to questions asked during the product installation procedure.

Perform POLYCENTER Software Installation utility operations from the DCL prompt. Use the following command format to invoke each operation:

$ PRODUCT subcommand product-name[/qualifier1,...] 

For example, to install COBOL Version 2.2 and the latest version of Fortran, enter the following command:

$ PRODUCT INSTALL COBOL/VERSION=2.2,FORTRAN [Return]
The following products have been selected:
    DEC AXPVMS COBOL V2.2           Layered Product
    DEC AXPVMS FORTRAN V7.0         Layered Product
Do you want to continue? [YES] [Return]

Section 3.7 describes installation.

You can enter PRODUCT commands at the DCL prompt ($) or in a DCL command procedure. See the VSI OpenVMS System Management Utilities Reference Manual for subcommand syntax information.

To run the POLYCENTER Software Installation utility as a batch job, see Section 3.7.6.

Table 3.3 lists DCL commands the POLYCENTER Software Installation utility can perform and describes each of them.

Table 3.3. DCL Commands and Descriptions
DCL CommandDescription
PRODUCT CONFIGURECreate a product configuration file (PCF)
PRODUCT COPYCopy a software product kit or convert it to another format
PRODUCT EXTRACT FILERetrieve a specified file or files from a software product kit packaged in sequential format
PRODUCT EXTRACT PDFRetrieve the product description file (PDF) from a software product kit packaged in sequential format
PRODUCT EXTRACT PTFRetrieve the product text file (PTF) from a software product kit packaged in sequential format
PRODUCT EXTRACT RELEASE_NOTESRetrieve the release notes for a selected product
PRODUCT FINDDisplay the name of product kits found in a specified directory
PRODUCT INSTALLInstall one or more software products and updates the product database
PRODUCT LISTList a file or files contained in a specified product kit that is packaged in sequential format
PRODUCT PACKAGECreate a software product kit.
PRODUCT RECONFIGUREModify the configuration choices for an installed product and update the product database
PRODUCT REGISTER PRODUCTRecord product information in the product database
PRODUCT REGISTER VOLUMERecord a volume label change of the volume containing the installed products
PRODUCT REMOVERemove a product from the system and from the product database
PRODUCT SHOW HISTORYDisplay in chronological order the operations performed on software products
PRODUCT SHOW OBJECTDisplay information about objects created during software product installation
PRODUCT SHOW PRODUCTDisplay information about installed products
PRODUCT SHOW UTILITYDisplay information about the POLYCENTER Software Installation utility

Privileges required

The POLYCENTER Software Installation utility requires specific privileges to perform certain operations, as shown in the following table:

OperationsPrivileges Required
COPY, EXTRACT, FIND, LIST, PACKAGENone
CONFIGURE, SHOWSYSLCK
REGISTERSYSLCK and SYSPRV (or a system UIC)
INSTALL, RECONFIGURE, REMOVESYSLCK, SYSPRV (or a system UIC), TMPMBX, and CMKRNL

Some commands might also require BYPASS or NETMBX privileges.

The execution of command procedures from the kit you are installing might require additional privileges. Check the installation guides that you receive with product kits for these privileges.

3.6.1. Product Files and Databases

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

  • The product description file (PDF), is provided by the software manufacturer. It contains all the information the POLYCENTER Software Installation utility needs for installing either a software product or a set of software products. The PDF includes a list of configuration choices the product offers, default choices, and product requirements (such as minimum hardware configurations and system parameter values).

  • A product text file (PTF), is optionally supplied by the software manufacturer. It provides information about the product. The information includes product name, producer, configuration choice descriptions, and message text used during product installation.

  • A product configuration file (PCF), is optional. It may be supplied by software manufacturer, or you can create it by using the CONFIGURE operation. A PCF contains responses to some or all of the installation questions for a product. It can provide default or required choices, which may differ from the default choices provided in the PDF.

  • The product database (PDB), is created automatically by the POLYCENTER Software Installation utility. When products are installed, the files and other objects that make up the product, such as directories and accounts, are recorded in the PDB. The configuration choices made during installation are also recorded.

    You can access the PDB to show what products are installed and the dependencies between them. You can also list the files and other objects that make up each product, or the history of installation and upgrade activity.

  • Patch recovery data sets are created automatically by the POLYCENTER Software Installation utility. When products are installed in recovery mode or when patch kits are installed with a request to save recovery data, the files and other objects that are displaced by the current installation are saved in a specially designated directory tree for future use.

    You can display information about recovery data sets and learn which patch kits can be uninstalled using the SHOW RECOVERY_DATA operation.

3.6.2. Format of Software Product Kits

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

  • Compressed format. In this form, a data compression technique has been applied to a sequential kit. A compressed kit has a .PCSI$COMPRESSED file type.

  • Sequential format. In this form, the PDF, the PTF, and all files that comprise the product are packaged in a single container file. This container file can be placed either on a random-access device, such as a compact disc, or on a sequential access device, such as a magnetic tape. Most layered products are distributed in sequential format.

  • Reference format. In this form, the PDF, the PTF, and all files that comprise the product are placed in a directory tree on a random-access device. OpenVMS is distributed in reference copy format on CD-ROM.

3.6.3. Software Product Name Conventions

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:

  • producer is the legal owner of the software product (for example, DEC)

  • base is the base system that specifies the hardware and software platform on which the product runs (for example, AXPVMS, VAXVMS, or I64VMS).

  • product is the name of the software product.

  • version identifies the version according to the format tmmnn-ue.

  • kit_type identifies a kit type specified as a value from 1 through 7, as shown in Table 3.4.

Table 3.4. PDF Kit Types and Values
ValueTypeDescription
1FullApplication software.
2Operating systemOperating system software.
3PartialAn update for the operating system or for a product that is currently installed.
4PatchA correction to existing software.
5PlatformA software system that has more than one product.
6TransitionA kit that is intended to register a product that was not installed by the POLYCENTER Software Installation utility. Transition kits include only a product definition file and (optionally) a product text file.
7Mandatory updateA required update, which produces functionally updated software that has the same version number.

3.6.3.1. Version Identification Format

The version of the software product kit is in the format tmmnn-ue. This format is described in the Table 3.5.

Table 3.5. Format of tmmnn-ue Version Identification
tThe type of version (a single uppercase alphabetic character).
mmThe major version number (decimal integer 01 through 99).
nnThe minor version number (decimal integer 00 through 99).
-The hyphen is required in all cases. When both update level (u) and maintenance edit level (e) are omitted, the version will end with a hyphen and the file name will have a double hyphen (- -) preceding the kit type.
uThe update level (decimal integer 1 through 999). The level is optional.
eThe maintenance edit level (one or more alphanumeric characters beginning with an alphabetic character). This level is optional.

The following table of examples shows how to use the format:

ExampleDescription
V6.1

In this example:

  • Version type: V

  • Major release: 06

  • Minor release: 01

  • Update level: 0 (implicit)

  • No edit level

V6.1-1H2

In this example:

  • Version type: V

  • Major release: 06

  • Minor release: 01

  • Update level: 1

  • Edit level: H2

T6.2-FT2

In this example:

  • Version type: T

  • Major release: 06

  • Minor release: 02

  • Update level: 0 (implicit)

  • Edit level: FT2

3.6.3.2. Software Product Name Examples

The following examples show how the format is used for one sequential and two reference copy format kits:

  • A sequential format kit for DEC Softwindows for OpenVMS VAX that requires a double hyphen has the following format:
    DEC-VAXVMS-SOFTWIN-V0101--1.PCSI

    This format shows that the producer is DEC (Digital), the base is VAXVMS (OpenVMS VAX), the product is SOFTWIN, and the version is V1.1. The type of version is V, the major and minor version numbers are each 1. There are no update or maintenance edit levels. The kit_type is 1 (full).

  • A product description file in a reference copy format kit for OpenVMS Alpha has the following format:
    DEC-AXPVMS-VMS-V0601-1H2-2.PCSI$DESCRIPTION

    This format shows that the producer is DEC (Digital), the base is AXPVMS (OpenVMS Alpha), the product is OpenVMS, and the version is V6.1-1H2. The type of version is V, the major version number is 6, the minor version number 1, the update level is 1, and the maintenance edit level is H2. The kit_type is 2 (operating system).

  • A product description file in a reference format kit for a field test version of OpenVMS Alpha has the following format:
    DEC-AXPVMS-VMS-T0700-FT2-2.PCSI$DESCRIPTION

    This format shows that the producer is DEC (Digital), the base is AXPVMS (OpenVMS Alpha), the product is OpenVMS, and the version is V7.0-FT2. The type of version is T, the major version number is 7, and the minor version number is 0. There is no update level because the first character after the hyphen is not a digit. The maintenance edit level is FT2 and the kit_type is 2 (operating system).

  • A compressed kit for VSI Kerberos has the following format:

    VSI-AXPVMS-KERBEROS-V0200-6-1.PCSI$COMPRESSED

    This format shows that the producer is VSI, the base is AXPVMS (OpenVMS Alpha), the product is KERBEROS, and the version is V2.0-6. The type of version is V, the major version number is 2, the minor version number is 0, and the update level is 6. There is no maintenance edit level. The kit_type is 1 (full).

3.6.4. Creating a Product Configuration File (PCF)

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:

  • If the product database (PDB) contains an entry for the choice that was made in a previous installation, then the PDB entry becomes the default configuration choice. It can be changed.

  • If the PDB does not contain an entry for the choice, either because the product was not previously installed or because this is a new choice, then the default configuration choice comes from the PDF. It can be changed.

3.6.4.1. Configuration Options

Some options available for customizing the PCF are:

  • Saving your answer. You can specify that your response to a question (rather than the current default value) be stored in the PCF.

  • Not saving your answer. When creating a PCF during an installation, you can answer a question without recording your answer in the PCF. This is useful for responding to questions that are specific to a single system or installation.

  • Deferring a question so that it is asked again during a future installation. For example, you might want an installer to verify that a particular response is still valid for the systems on which each installation is being performed.

  • Preventing a question from being asked again. If you do not defer a question when you create a PCF, the response recorded in the PCF is used during future installations. The installer is not prompted for the information. This reduces the length and complexity of the actual installation procedure.

3.6.4.2. Configuration Commands

To create a PCF, use the PRODUCT CONFIGURE command. For example:

$ PRODUCT CONFIGURE CHESSMASTER

The POLYCENTER Software Installation utility creates a PCF in your current default directory. The default PCF is named DEFAULT.PCSI$CONFIGURATION. To override the default file name or directory, use the /CONFIGURATION=OUTPUT qualifier. Refer to the sample procedure in the next section.

3.6.4.3. Recording Configuration Choices

After defining the PCF, the POLYCENTER Software Installation utility prompts you with questions about the product. Determine how and whether your responses are recorded in the PCF by responding to the questions and using two predefined function keys. The following table shows how your responses configure the PCF:

KeyAction by the POLYCENTER Software Installation utility
Return

Accepts the default or explicitly entered choice for the current operation and for entry into the PCF, and then moves to the next choice.

If the Defer option is in effect, this entry can be changed when the PCF is used for future installations or upgrades.

If the Defer option is not in effect, this entry cannot be changed when the PCF is used for future installations or upgrades.

If the Write option is in effect, this entry, including the Defer option, is written into the PCF and used when the PCF is used for future installations or upgrades.

If the Write option is not in effect, this entry, including the Defer option, is not written into the PCF and is not used when the PCF is used for future installations or upgrades. In this case, the default for the future installation or upgrade will come from the PDF or PDB.

F17Toggles the Defer option. By default, the Defer option is not in effect.
F18Toggles the Write option. By default, the Write option is in effect.

Press the Return key after each response.

Example 3.1 shows how to use keys F17 and F18 in the PCF. Note that this is an example only and does not necessarily represent an actual PCF for a product. A description of the callouts follows the example.

Example 3.1. Example 3-1 Sample Procedure for Creating a PCF
$ 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
$

The callouts in the example mark the following actions:

  1. Chooses to select values for individual options instead of accepting default values for all of the options.

  2. Requests (by using the defer key, F17) that the installer be given the choice of whether or not to install the optional example files.

  3. Toggles the defer option (twice to illustrate the toggle effect).

  4. Records the default response [Yes] in the PCF. Because the defer option was in effect, when the PCF is used during a future installation, the installer can select the Accounting Log Report Generator utility by default, or can choose not to select it.

  5. Requests the nowrite option key (F18) so that this choice will not be written to the PCF.

  6. Chooses not to install the Access Control List utilities. Because the nowrite option is in effect, this choice is not written to the PCF.

  7. Chooses not to install the Print and Batch Queue utilities. Because the nowrite option is not in effect (by default) and the defer option is in effect (by default), this choice is written to the PCF and the question is not asked again when the PCF is used during a future installation.

  8. Accepts the default to install the DECdtm Distributed Transaction Manager. Because the nowrite option is not in effect (by default) and the defer option is in effect (by default), this choice is written to the PCF, and the question is not asked again.

  9. Requests that the configuration options be displayed.

  10. Displays the name of the PCF that has been created, MYPCF.PCSI$CONFIGURATION. The POLYCENTER Software Installation utility displays this message only when you enable message logging by using /LOG with PRODUCT CONFIGURE.

When you use a single DCL command to install or configure more than one product and write the responses to a PCF, the information for all the products that are installed or configured is in a single PCF. Use separate operations to install or configure a set of products when you want to keep each product's configuration values in its own PCF.

3.6.4.4. Modifying an Existing PCF

You can use DCL to modify an existing file. Specify the name of the PCF to be modified and the name of the PCF to be created. Include both the INPUT and the OUTPUT keywords with the /CONFIGURATION qualifier on the PRODUCT CONFIGURE command line. For example, read the default values in the file PRODUCTA_REV1.DAT, make changes to the file, and save the changes to PRODUCTA_REV2.DAT, the output file:

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

3.6.5. Using a Product Database

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.

3.6.5.1. Adding Information to the Database

Although the POLYCENTER Software Installation utility stores product information for you automatically, you can also add your own information. When you perform a task, you can include a remark—a comment to be recorded in the product database—along with the other information about the task being performed.

To add a remark to the product database, use the /REMARK qualifier with any of the following DCL commands:

  • PRODUCT RECONFIGURE

  • PRODUCT INSTALL

  • PRODUCT REMOVE

  • PRODUCT REGISTER PRODUCT

See the VSI OpenVMS System Management Utilities Reference Manual for information about this command and the /REMARK qualifier.

3.6.5.2. Registering a Noncompliant Product

To register a product that was installed with a tool other than the POLYCENTER Software Installation utility, enter PRODUCT REGISTER PRODUCT. This command records information that a PDF provides. For example:

$ PRODUCT REGISTER PRODUCT TOOLCHEST

If you do not have a PDF for a product you want to register, enter the following command:

$ @SYS$UPDATE:PCSI$REGISTER_PRODUCT.COM

This procedure prompts you for the product name, version, and producer. For example, the producer for Digital products is DEC. The procedure uses this information to create a temporary, minimal PDF. It then executes the PRODUCT REGISTER PRODUCT command to register the product, and deletes the temporary PDF.

Because PCSI$REGISTER_PRODUCT.COM creates only a minimal PDF, it cannot register with the POLYCENTER Software Installation utility database all the information about the product. For this reason, if a PDF for the product is available, use it.

Although a transition PDF is intended specifically for PRODUCT REGISTER PRODUCT, you can also register full and operating system PDFs.

3.6.5.3. Detecting and Tracking Software Dependencies

Some software products depend on other software products to work correctly. For example, a product might work only when a specific version of another product is installed on the system. The POLYCENTER Software Installation utility detects and tracks the dependencies of the products that you install. The utility also attempts to satisfy the requirements of multiple products. In some instances, the POLYCENTER Software Installation utility is unable to resolve product dependency issues. In such instances, the utility provides feedback on the nature of the conflict and asks you to decide how to proceed.

3.6.6. Understanding Recovery Data Sets

You can use recovery data sets in the following circumstances:

  • When the installation of a patch kit fails

  • When you want to undo (or uninstall) one of more patch kits that have been installed using the POLYCENTER Software Installation utility

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:

  • Saved product files

  • Supplementary data files that catalog actions that reverse the effect of installing a patch kit

  • Database files as they were at the beginning of the installation of the patch kit

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.

3.6.6.1. Recovering from a Failed Installation of a Patch Kit

To be able to recover completely from a failed installation of a patch kit, you must install the kit using the following command:

$ PRODUCT INSTALL/RECOVERY_MODE

When you enter this command, the POLYCENTER Software Installation utility installs the patch kit in what is called recovery mode. When you install a kit in recovery mode, the files that the installation modifies or replaces are saved; they make up a recovery data set. If an error condition interrupts the installation or if you intentionally terminate the installation, the POLYCENTER Software Installation utility can use the recovery data set to roll back the original files. This action restores the product environment that existed prior to the interrupted installation.

Once the rollback completes, the POLYCENTER Software Installation utility destroys the recovery data set. The utility also destroys the recovery data set at the end of a successful product installation or reconfiguration. You can, however, prevent the deletion of the recovery data set by using the /SAVE_RECOVERY_DATA qualifier with the PRODUCT INSTALL command. The next section explains how to do this.

3.6.6.2. Undoing One or More Patch Kit Installations

You can create a recovery data set when you install a patch kit, and, at the same time, explicitly request the POLYCENTER Software Installation utility to save recovery data. You do this by entering the following command:

$ PRODUCT INSTALL/SAVE_RECOVERY_DATA

When you enter this command, the POLYCENTER Software Installation utility permanently saves the files that the installation of the patch has removed. You can subsequently use the recovery data set to uninstall the patch product; you enter the PRODUCT UNDO PATCH command to do this. However, once you use the recovery data set to uninstall the patch product, the POLYCENTER Software Installation utility deletes it, and you cannot use recovery data set files again.

The POLYCENTER Software Installation utility also destroys the recovery data set when you enter any of the following (unrelated) DCL commands:

$ PRODUCT INSTALL (without the /SAVE_RECOVERY_DATA qualifier)
$ PRODUCT RECONFIGURE
$ PRODUCT REGISTER PRODUCT
$ PRODUCT REMOVE
3.6.6.2.1. Using Other Recovery Data Set Commands

You can use the following PRODUCT commands to view and delete recovery data sets:

  • To view information in a recovery data set, enter the following command:

    $ PRODUCT SHOW RECOVERY_DATA
  • To delete selected recovery sets (if you are concerned that the recovery data takes up too much space), enter the following command:

    $ PRODUCT DELETE RECOVERY_DATA

By deleting one or more recovery data sets, you do not disturb your current product environment. However, you cannot uninstall the patch products that correspond to the recovery data that you delete.

3.7. Installing with the POLYCENTER Software Installation utility

The basic steps for installing a software product are:

  1. Perform the preliminary steps.

  2. Review the product's release notes and installation information.

  3. Start the installation.

  4. Respond to installation questions about product options. The product is not installed on your system until you confirm your selections.

  5. Confirm your selections to install the product.

3.7.1. Performing Preliminary Steps

Before installing software, follow these steps:

  1. Back up your system disk.

  2. Optionally identify source and destination locations.

  3. Install prerequisite software.

    Note that the POLYCENTER Software Installation utility will perform this automatically if the kits are available.

  4. Identify post-installation procedures.

3.7.1.1. Specifying Locations

For many operations, you must specify a location where the software kit resides and a location where you want to install the software. Two methods are available for identifying these locations:

  • Define logical names

  • Specify /SOURCE and /DESTINATION qualifiers on the command line.

You can also define logical names, and then override them by using the /SOURCE and /DESTINATION qualifiers on the PRODUCT command.

Note

If you do not deassign logical names after they are used, they can cause unexpected results in future operations of the POLYCENTER Software Installation utility. VSI recommends that you use the /SOURCE and /DESTINATION qualifiers.

Logical name PCSI$SOURCE defines the location of the software kits you want to install. Logical name PCSI$DESTINATION defines the location where you want to install the software. For example, if the software is located in DISK1:[KITS] and you want to install it in DISK2:[APPLICATIONS], use the following commands:

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

You can override the logical name definitions by using /SOURCE and /DESTINATION qualifiers on the PRODUCT command to specify a different source and destination.

If you do not define PCSI$DESTINATION, the utility installs the software product in SYS$COMMON:[VMS$COMMON] and directories under it.

3.7.1.2. Installing Prerequisite Software

Install any prerequisite software or perform any prerequisite tasks. This information should be in the software product's installation instructions or release notes.

Note that the POLYCENTER Software Installation utility will perform this automatically if the kits are available.

3.7.1.3. Identifying Post-installation Procedures

Note any post-installation procedures. This information should also be in the software product's installation instructions or release notes.

3.7.2. Extracting a Product's Release Notes

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.

3.7.3. Installing a Product

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.

Table 3.6. Features You Can Request During an Installation
FeatureQualifier
Supply answers from a PCF/CONFIGURATION=INPUT=pcf-name
Create a new PCF/CONFIGURATION=OUTPUT=pcf-name?
Specify where to install the files/DESTINATION=location
Display full descriptions of all product installation options and information/HELP
Display log messages on your terminal/LOG
Include a remark in the product database/REMARK
Specify where the distribution kit is located/SOURCE
Specify configuration variables/CONFIGURATION=keyword?
Specify a work area for temporary files/WORK=device

3.7.3.1. Using an Existing PCF

Chapter 3 describes how to create a PCF before installing a product. To use this existing PCF during the installation, use the /CONFIGURATION=INPUT qualifier with PRODUCT INSTALL. For example, to install CMS and use configuration choices recorded in the PCF named DEC-VAXVMS-CMS.PCSI$CONFIGURATION:

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

3.7.3.2. Creating a New PCF During the Installation

If you did not create a PCF before the installation, you can create one during the installation. Use the /CONFIGURATION=OUTPUT=pcf-name qualifier with PRODUCT INSTALL. For example:

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

As you respond to questions about the options for CMS Version 3.0, your responses are recorded in the PCF named CMSV3.DAT in your current default directory.

For more information about product configuration files, see Section 3.8.4 and Section 3.8.1.

3.7.4. Responding to Installation Questions

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.

3.7.4.1. Requesting an Explanation to Questions

To request a full description of all product options and information, use the /HELP qualifier with PRODUCT INSTALL. To request help about an individual question, press the Help key or PF2 in response to the question. The POLYCENTER Software Installation utility displays a description (if one is available) and a summary of disk and memory requirements for the option.

The following example uses the Help key:

$ 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]
   .
   .
   .

The amount of information varies; some products provide more information than others, and some products provide no information.

3.7.4.2. Accepting Default Answers

Default answers come from one of three places:

  • A product configuration file (PCF), if one is supplied

  • The product database (PDB), for upgrades of previously installed products

  • The product description file (PDF)

If you specify an input PCF and it contains an answer for an option, the default answer from the PCF is used. Depending on the entry in the PCF, the default answer may or may not be allowed to change.

If no input PCF exists, or if the input PCF does not contain an answer for an option, the default answer comes from either the PDB or the PDF. If the PDB is present and contains the option, then the default answer comes from the PDB. If the PDB is not present (a new installation) or does not contain the option (a new option), then the default comes from the PDF. Default answers that come from either the PDB or PDF may be changed.

To answer an option, either press Return to accept the default answer, or supply your own answer and then press Return.

Some products contain a subset of questions or options. During an installation procedure, you can accept the default values for an entire subset or you can answer each option in the subset.

When you select an option that has suboptions, the POLYCENTER Software Installation utility will ask:

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

If you answer YES, you will not be asked about the subitems. Instead, the utility will use the defaults for the subitems. If you answer NO, the utility asks you about each subitem.

3.7.5. Confirming Your Answers

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.

3.7.5.1. Updating DCL Help Text

When you install a layered product that updates DCL Help text, the PRODUCT INSTALL command requires exclusive access to the DCL Help library file, SYS$HELP:HELPLIB.HLB. For example, if a user is accessing HELP while an installation is trying to update the help library, you see several messages and are asked to respond to several questions. These messages and questions appear in the following order:

  1. The system displays the following messages if the PRODUCT INSTALL command fails to obtain exclusive access to the help library after waiting for two minutes:

    %PCSI-I-PRCOUTPUT, output from subprocess follows ...
    %LIBRAR-F-OPENIN, error opening disk:[SYS0.SYSCOMMON.]
       [SYSHLP]HELPLIB.HLB;1 as input
    -RMS-E-FLK, file currently locked by another user
    
    %PCSI-E-MODREPLFLK1, error replacing module module-name in
       library disk:[SYS0.SYSCOMMON.][SYSHLP]HELPLIB.HLB
    -PCSI-E-MODREPLFLK2, library update failed because it is
       currently accessed by one or more users
    -PCSI-E-MODREPLFLK3, after the file is closed, answer YES
       at the prompt to retry the update
  2. Either retry the library update operation or terminate the installation:

    • To retry the library update, ask users to exit HELP. Then answer YES to the following question:
      Do you want to take this action? [YES] YES

      If users do not exit HELP within two minutes, the question is repeated.

    • To terminate the installation, answer NO to the following two questions:
      Do you want to take this action? [YES] NO
      Do you want to continue? [YES] NO
      %PCSI-E-CANCEL_WIP, termination resulted in an incomplete
         modification to the system

      The last message indicates that some files might have been moved to their target directories, but the product has not been completely installed. Installation of the product at a later time will delete the files from the aborted installation and will then perform a full installation.

3.7.6. Performing the Installation as a Batch Job

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.

Example 3.2. Example 3-2 Sample Command Procedure for Installing a Product
$ 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

3.7.7. Installing a Patch Kit to Allow for its Removal

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.

3.8. Performing Other Operations on Installed Software Products Using the POLYCENTER Software Installation Utility

You can perform other operations on installed software products – for example, reconfiguring choices made during the installation, recording changes in volume label, or copying the software to a new location or to different media. You might also want to convert a kit to a new format, display product information, display recovery details to see which patch kits can be uninstalled, delete recovery data sets to save disk space, display the contents of a sequentially packaged product kit, or extract any file from a sequentially packaged kit.

3.8.1. Reconfiguring an Installed Product

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.

3.8.2. Recording a Change in Volume Label in the Product Database

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.

3.8.3. Copying a Software Kit to a New Location

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

3.8.4. Converting a Software Kit from One Format to Another

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

3.8.5. Retrieving Product Information

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.

3.8.5.1. Displaying Information About Objects

To display information about the managed objects (for example, files, accounts, and directories) associated with the products installed on your system, use the SHOW OBJECT command. Table 3-8 lists questions that can be answered with SHOW OBJECT.

Table 3.7. SHOW OBJECT Command: Displaying Managed Object Information
QuestionCommand

What files or other objects did this product create?

PRODUCT SHOW OBJECT * /PRODUCT=product-name

What product created this file or other object?

PRODUCT SHOW OBJECT object-name/FULL

3.8.5.2. Displaying Information About the Products

You can obtain information about products installed on your system with the SHOW PRODUCT and SHOW HISTORY commands. Table 3-9 lists some of the questions that can be answered with these commands.

Table 3.8. SHOW PRODUCT and SHOW HISTORY Commands
QuestionCommand

Which products have been installed?

PRODUCT SHOW HISTORY * /OPERATION=INSTALL

PRODUCT SHOW PRODUCT *

Product interdependencies: Is product A referenced by product B?

PRODUCT SHOW PRODUCT A /FULL

PRODUCT SHOW PRODUCT * /REFERENCED_BY=B

Which user installed a product?

PRODUCT SHOW HISTORY product-name /FULL

Which products were installed before March 31, 2000?

PRODUCT SHOW HISTORY * /BEFORE=31-MAR-2000

Were any software patches applied to a product?

PRODUCT SHOW PRODUCT product-name /FULL

3.8.6. Retrieving Patch Recovery Information

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.

Table 3.9. SHOW RECOVERY_DATA Command: Displaying Patch Recovery Information
QuestionCommand

How many recovery data sets have been saved?

Which patch kits can you uninstall?

PRODUCT SHOW RECOVERY_DATA

What is the total size of objects saved in recovery data sets?

PRODUCT SHOW RECOVERY_DATA /FULL

Which three newest patches can be uninstalled?

PRODUCT SHOW RECOVERY_DATA /NEWEST=3

Which two oldest recovery data sets can be deleted?

PRODUCT SHOW RECOVERY_DATA /OLDEST=2

Are there any patches installed after 12-DEC-2002 that can be uninstalled?

PRODUCT SHOW RECOVERY_DATA /SINCE=13-DEC-2002

Are there any recovery data sets saved before 01-DEC-2002?

PRODUCT SHOW RECOVERY_DATA /BEFORE=01-DEC-2002

3.8.7. Deleting Patch Recovery Data

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.

Table 3.10. DELETE RECOVERY_DATA Command: Displaying Delete Options
OptionCommand
To delete all recovery data sets

PRODUCT DELETE RECOVERY_DATA

PRODUCT DELETE RECOVERY_DATA /ALL

To delete the oldest three recovery data sets

PRODUCT DELETE RECOVERY_DATA/OLDEST=3

To delete all recovery data sets save before 01-DEC-2002

PRODUCT DELETE RECOVERY_DATA/BEFORE=01-DEC-2002

3.8.8. Removing Installed Software Products and Kits

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

3.8.9. Uninstalling Patch Kits

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:

  • By default, if you do not use any qualifiers, only the latest installed patch kit or kits are removed.

  • If you want to uninstall all patch kits to the extent that recovery data allows, use the /ALL qualifier.

  • To limit the number of patch kits to be uninstalled, specify the /NEWEST=n qualifier, where n is the number of the newest recovery sets.

  • To uninstall patch kits that have been installed after a certain date, use the /SINCE=date qualifier.

Chapter 4. Starting Up and Shutting Down the System

This chapter describes various ways to start up and shut down your system.

To initiate startup of your system, you boot it. Many systems have unique booting commands. For detailed booting instructions for your system, refer to the following manuals:
  • On VAX systems, refer to the most recent version of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

  • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

Information Provided in This Chapter

This chapter describes the following tasks

Task

Section

Deferring memory testing on AlphaServer 4100 computers

Section 4.1.2

Booting with modified system parameter values

Section 4.2

Assigning port allocation classes with SYSBOOT

Section 4.3

Booting in an emergency

Section 4.4

Booting with controlled startup

Section 4.5

Solving booting problems

Section 4.6

Writing a new boot block on the system disk

Section 4.7

Performing an orderly shutdown with SHUTDOWN.COM

Section 4.8.1

Customizing SHUTDOWN.COM to perform site-specific operations

Section 4.8.3

Performing an orderly shutdown with SYSMAN

Section 4.8.4

Performing an emergency shutdown with the OPCCRASH.EXE program

Section 4.8.5

Performing an emergency shutdown using console commands

Section 4.8.6

Using the Boot Manager Utility, BOOT_OPTIONS, to reconfigure devices on OpenVMS I64 systemsSection 4.9.3
This chapter explains the following concepts:

Concept

Section

Booting and startup processes

Section 4.1.1

Nonstop boot: the most common booting operation

Section 4.1.3.1

Conversational boot: for special booting functions

Section 4.1.3.2

System startup and STARTUP.COM

Section 4.1.4

System shutdown procedures

Section 4.8

The order of shutdown events

Section 4.8.2

Reconfiguration of boot, dump, and debug devices on OpenVMS I64 systemsSection 4.9

4.1. Understanding Booting and System Startup

Booting is the process of loading system software from the system disk into processor memory. When you boot your system, it automatically performs a series of tasks to start up your system. These tasks are collectively known as system startup.

You must have installed the operating system before you boot the system for the first time.

Booting procedures vary for different computers. For example, computers with console storage devices use a boot command procedure. You can copy and edit this command procedure to specify the location of the system disk. Other computers have an internal memory device that provides the name of the system disk.

On Alpha and I64 systems, you cannot boot from a magnetic tape device.

4.1.1. Booting and Startup Processes

Together, the booting and startup processes comprise the following steps:
  1. You enter the BOOT command. The boot block, a fixed location on disk, points to the primary bootstrap image, which is loaded from disk into main memory.

    On VAX systems, the primary bootstrap image is VMB.EXE.

    On Alpha systems, the primary bootstrap image is APB.EXE.

    On I64 systems, the primary bootstrap image is IPB.EXE.

    The primary bootstrap image allows access to the system disk by finding the secondary bootstrap image, SYS$SYSTEM:SYSBOOT.EXE, and loading it into memory.

  2. SYSBOOT.EXE loads the system parameters stored in the default parameter file into memory. (For more information about the default parameter file and loading of system parameters at boot time, see Section 4.2.)

    If you are performing a conversational boot, the procedure stops and displays the SYSBOOT> prompt. (For information about conversational booting, see Section 4.1.3.2.) Otherwise, SYSBOOT.EXE loads the operating system executive into memory and transfers control to the executive.

  3. When the executive finishes, it executes the SWAPPER process.

  4. The SWAPPER creates the SYSINIT process.

  5. Among other actions it performs, SYSINIT creates the STARTUP process.

  6. STARTUP executes SYS$SYSTEM:STARTUP.COM (unless you indicated another file using SYSMAN, SYSGEN, or conversational boot). STARTUP.COM executes a series of other startup command procedures, including SYSTARTUP_VMS.COM. (For more information about STARTUP.COM, see Section 4.1.4. For more information about other startup procedures, see Section 5.2.1.)

    The current values of system parameters are written back to the default parameter file.

  7. The boot process finishes, and you can log in to the operating system.

Note

On VAX and Alpha systems, you can reconfigure boot and dump devices only by shutting down the system and entering commands from the console.

On I64 systems, you can reconfigure boot and dump devices either before you shut down the system or after you shut it down. These methods are explained in Section 4.9.

4.1.2. Deferring Memory Testing on AlphaServer 4100 Computers

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.

To use this new feature, you need to specify a value for the MEMORY_TEST environment variable at the console before booting. The values for MEMORY_TEST are the following:

Value

Description

FULL (off)

The console does all the testing.

NONE

32 MB of memory are tested before booting.

PARTIAL

256 MB of memory are tested before booting.

If you set MEMORY_TEST to NONE or PARTIAL, OpenVMS tests any remaining untested memory on an as-needed basis at either or both of the following times:
  • While the operating system is booting

  • In the scheduler idle loop when no processes are available to run

When you change the value of MEMORY_TEST, you must issue the INIT console command before the new value takes effect. Therefore, you need to follow these steps from the console before booting:
  1. Change the value of MEMORY_TEST (if desired).

  2. Issue the INIT command from the console.

  3. Boot the operating system.

OpenVMS also gives you more control over when memory is actually tested. Bit 2 in the system parameter MMG_CTLFLAGS controls deferred memory testing:
  • If the bit is clear (the default), OpenVMS tests memory in the background and not necessarily before the bootstrap process has completed.

  • If you set the bit, OpenVMS guarantees that all memory will be tested by the end of EXEC_INIT in the system bootstrap process; that is, before IPL is lowered from 31.

4.1.3. Types of Booting Operations

You can perform the following types of booting operations:

Type

Purpose

For More Information

Nonstop boot

To boot without stopping to perform special operations. Use this kind of boot in most cases.

Section 4.1.3.1

Conversational boot

To perform special boot operations—for example, to change system parameters before booting.

Section 4.1.3.2

4.1.3.1. Nonstop Boot: The Most Common Booting Operation

The most common boot operation is a nonstop boot from the system disk. You perform a nonstop boot after changing certain system parameters or installing certain layered products, or after a standalone backup.

Follow the instructions for a nonstop boot in either of the following manuals:
  • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

  • On Alpha and I64 systems, refer to the VSI OpenVMS Alpha Upgrade and Installation Manual.

4.1.3.2. Conversational Boot: For Special Booting Functions

A conversational boot is used in programming research and development environments where you must alter operating conditions for experimentation, testing, and debugging. Use a conversational boot to perform the following operations:

Operation

For More Information

Boot after showing or modifying individual system parameter values.?

Section 4.2.1

Boot using system parameter values from an alternate parameter file. ?

Section 4.2.2

Boot with default values for system parameters; for example, when modified system parameter values have caused the system to become unbootable. ?

Section 4.4.1

Boot without running startup or login procedures; for example, when modified startup or login procedures have caused the system to become unbootable.

Section 4.4.2

Boot without the user authorization file; for example, when the user authorization file has been modified so that you cannot log in.

Section 4.4.3

Boot with an alternate site-independent startup procedure.

Section 4.5.1

Boot with a minimum startup.

Section 4.5.3

Display startup procedure commands while booting.

Section 4.5.4

To boot your system conversationally, follow the instructions for a conversational boot in either of the following manuals:
  • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

  • On Alpha and I64 systems, refer to the VSI OpenVMS Alpha Upgrade and Installation Manual.

4.1.4. System Startup and STARTUP.COM

Immediately after your system boots, it runs the site-independent command procedure SYS$SYSTEM:STARTUP.COM to start up the system and control the sequence of startup events. This section describes STARTUP.COM.

Caution

Do not modify SYS$SYSTEM:STARTUP.COM. This file is deleted and replaced each time you upgrade your system to the next version of the operating system. Leaving STARTUP.COM intact prevents you from inadvertently altering any commands in the file, which in turn could cause the startup procedure to fail.

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.

STARTUP.COM uses a series of command procedures, executable images, and database files to perform the following startup tasks:
  • Define systemwide logical names required for the symbolic debugger, language processors, linker, image activator, and help processor.

  • Start processes that control error logging, SMISERVER (the system management server), the job controller, the operator log file, and security auditing.

  • Connect devices that are physically attached to the system by invoking the SYCONFIG.COM procedure. Configure devices and load their I/O drivers.

    Note

    STARTUP.COM creates the CONFIGURE process only on a full boot. If external devices are needed on any other boot (such as a minimum or an upgrade boot), add the following line to SYS$MANAGER:SYLOGICALS.COM:
    $IF P1 .NES. "FULL" THEN @SYS$SYSTEM:STARTUP CONFIGURE
  • Install known images to reduce I/O overhead in activating the most commonly run images or to identify images that must have special privileges.

STARTUP.COM executes the following site-specific startup command procedures in this order:
  1. SYS$MANAGER:SYCONFIG.COM

  2. SYS$MANAGER:SYLOGICALS.COM

  3. SYS$MANAGER:SYPAGSWPFILES.COM

  4. SYS$MANAGER:SYSECURITY.COM

  5. SYS$MANAGER:SYSTARTUP_VMS.COM

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

4.1.5. Messages Indicating Booting and Startup Progress

When you successfully boot a system, it prints a banner, followed by messages similar to the following message:
  1. The following message indicates that the system is executing the command procedure SYS$SYSTEM:STARTUP.COM:
    The OpenVMS system is now executing the system startup procedure.

    This procedure configures and initializes the system and executes several site-specific command procedures. For more information, see Section 4.1.4.

  2. A short time later (up to a few minutes), the system displays a message similar to the following message:
    The OpenVMS system is now executing the site-specific system startup commands.

    This message indicates that the system is executing SYSTARTUP_VMS.COM. You can modify this file to perform various operations at startup time. For more information, see Section 5.2.7.

  3. Finally, the procedure displays informational messages and accounting information. For example:
    %SET-I-INTSET, login interactive limit=64, current interactive value = 0
    19-APR-2000 15:00:00.00
      SYSTEM       job terminated at 19-APR-2000 15:00:00.00
    
    Accounting information:
     Buffered I/O count:       133     Peak working set size:        401
     Direct I/O count:          12     Peak pagefile size:          2379
     Page faults:              325     Mounted volumes:                0
     Charged CPU time: 0 00:00:55.23   Elapsed time:       0 00:01:31.24

    After the system displays this information, you can log in.

4.2. Booting with Modified System Parameter Values

Using a conversational boot, you can modify system parameter values as follows:

Task

For More Information

Boot after showing or modifying individual system parameter values

Section 4.2.1

Boot with an alternate system parameter file

Section 4.2.2

Boot with default values for system parameters

Section 4.4.1

Before using a conversational boot to show or modify system parameter values, you must be familiar with the following terms:

Term

Definition

Active values

System parameter values stored in memory and used by the active system.

Current values

System parameter values stored in the default parameter file. When the system boots, it sets active values for system parameters using the current values.

On VAX systems, the default system parameter file is SYS$SYSTEM:VAXVMSSYS.PAR.?

On Alpha systems, the default system parameter file is SYS$SYSTEM:ALPHAVMSSYS.PAR.?

On I64 systems, the default system parameter files is IA64VMSSYS.PAR.?

Default values

System parameter values stored in the default list and used by default.

For more information about system parameters, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

4.2.1. Booting After Showing or Modifying Individual System Parameter Values

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

  1. Follow the instructions for performing a conversational boot in one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

  2. At the SYSBOOT> prompt, enter SHOW and SET commands to show and change the value of system parameters. For example:
    SYSBOOT> SET UAFALTERNATE 1

    For information about SET and SHOW commands, refer to the VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems (SYSGEN).

  3. Enter the CONTINUE command to continue booting:
    SYSBOOT> CONTINUE

Example

SYSBOOT> SHOW UAFALTERNATE

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

4.2.2. Booting with an Alternate System Parameter File

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

  1. Follow the instructions for performing a conversational boot in one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the VSI OpenVMS Alpha Upgrade and Installation Manual.

  2. At the SYSBOOT> prompt, enter a command in the following format:
    USE file-spec
    where file-spec specifies the file name and type of the alternate parameter file. The file must be in SYS$SYSTEM. You cannot specify a device name. For example:
    SYSBOOT> USE ALTPARAMS.DAT
  3. Enter the CONTINUE command to continue booting:
    SYSBOOT> CONTINUE

Example

SYSBOOT> USE ALTPARAMS.DAT
SYSBOOT> CONTINUE

4.3. Assigning Port Allocation Classes with SYSBOOT

VSI recommends that you use the CLUSTER_CONFIG procedure to define port allocation classes. If this is not possible (for example, if you are booting a private system disk into an existing cluster), you can use the SYSBOOT SET/CLASS command to assign port allocation classes to shared SCSI ports. For example, if port PKB is connected to a SCSI bus that another node has assigned port allocation class 152, you would enter the following command:
SYSBOOT> SET/CLASS PKB 152
Be sure that the DEVICE_NAMING parameter is set to 1 to enable new device-naming; for example:
SYSBOOT> SET DEVICE_NAMING 1
To deassign a port allocation class, enter the port name without a class number; for example:
SYSBOOT> SET/CLASS PKA

4.4. Booting in an Emergency

If a system problem prevents your system from booting, you might need to perform an emergency boot operation. describes these emergency boot operations.
Table 4.1. Emergency Boot Procedures

Operation

Use

For More Information

Booting with default system parameters

When parameter values in the parameter file have been modified so that the system is unbootable

Section 4.4.1

Booting without startup and login procedures

If an error in the startup or login procedures prevents you from logging in

Section 4.4.2

Booting without the user authorization file

If you have forgotten the password and cannot log in to a privileged account

Section 4.4.3

4.4.1. Booting with Default System Parameters

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

  1. Perform a conversational boot by following the instructions in one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

  2. At the SYSBOOT> prompt, enter the following command:
    SYSBOOT> USE DEFAULT

    This command specifies that default values should be used for all parameters.

  3. Enter the following command to ensure that the operating system does not record the STARTUP_P1 parameter change made in Step 2 for subsequent reboots:

    SYSBOOT> SET WRITESYSPARAMS 0
  4. To avoid starting all layered products on a system that is not tuned for them, possibly causing the system to hang, set the STARTUP_P1 system parameter as follows:
    SYSBOOT> SET STARTUP_P1 "MIN"
  5. Enter the CONTINUE command to continue booting:
    SYSBOOT> CONTINUE
  6. When the system finishes booting, determine which changed parameter caused the problem, and reset the parameter value. If you specified the value for the parameter in the AUTOGEN parameter file MODPARAMS.DAT, fix the value in that file and run AUTOGEN. For more information, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

  7. Shut down and reboot the system.

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

4.4.2. Booting Without Startup and Login Procedures

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

  1. Perform a conversational boot operation by following the instructions in one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

  2. Enter the following command at the SYSBOOT> prompt:
    SYSBOOT> SET/STARTUP OPA0:
  3. Enter the following command to ensure that the operating system does not record the STARTUP_P1 parameter change made in Step 2 for subsequent reboots:

    SYSBOOT> SET WRITESYSPARAMS 0
  4. Enter the CONTINUE command to continue booting:
    SYSBOOT> CONTINUE
  5. When the system is booted, the operator console displays the DCL command prompt ($). You are logged in.

  6. Enter the following DCL command:
    $ SET NOON

    This command directs the operating system to ignore any errors that might occur. If you do not enter this command and you invoke an error, the system will log you out.

  7. Correct the error condition that caused the login failure. That is, make the necessary repairs to the startup or login procedures, or to the UAF.

    Invoke a text editor to correct the file. Note that some system consoles might not supply a screen-mode editor. You can also copy a corrected file and delete the incorrect version by using the RENAME and DELETE commands.

  8. Invoke SYSMAN and enter the following commands to reset the startup procedure:
    $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> PARAMETERS USE CURRENT
    SYSMAN> PARAMETERS SET/STARTUP SYS$SYSTEM:STARTUP.COM
    SYSMAN> PARAMETERS WRITE CURRENT
    SYSMAN> EXIT
    $
  9. Perform a normal startup by entering the following command:
    $ @SYS$SYSTEM:STARTUP

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

4.4.3. Booting Without the User Authorization File

Ordinarily, the startup and login procedures provided by VSI always work;however, certain user interventions can cause them to fail. A very simple way to lock yourself out of the system is to set passwords to login accounts and forget them. In such an emergency, you can use the alternate user authorization file rather than the standard user authorization file.

Note

You can use this method only to log in to the system from the console terminal; you cannot use other terminal lines.

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.

When you perform this procedure, the system assigns the following values to your user account:

Field

Value

Name

User name

UIC

[001, 004]

Command interpreter

DCL

Login flags

None

Priority

Value of the system parameter DEFPRI

Resources

Values of the PQL system parameters

Privileges

All

The process name is usually set to the name of the device on which you logged in (for example, _OPA0:).

How to Perform This Task

  1. Perform a conversational boot by following the instructions in one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

  2. At the SYSBOOT> prompt, enter the following command:
    SYSBOOT> SET UAFALTERNATE 1
  3. If your system is running DECwindows Motif for OpenVMS systems, you must also disable the windowing system by entering the following command:
    SYSBOOT> SET WINDOW_SYSTEM 0
  4. Enter the CONTINUE command to continue booting:
    SYSBOOT> CONTINUE
  5. When the startup procedure completes, log in on the console terminal by entering any user name and any two passwords in response to the Username: and Password: prompts.

  6. Enter the following command to use the default UAF:
    $ DEFINE/SYSTEM/EXECUTIVE_MODE SYSUAF SYS$SYSTEM:SYSUAF.DAT
  7. Use the Authorize utility to fix the problem that caused you to be locked out of the system (for example, a forgotten password). Enter HELP MODIFY at the UAF> prompt for information about modifying passwords. For more details, refer to the VSI OpenVMS System Management Utilities Reference Manual.

  8. Enter the following commands to invoke SYSMAN and clear the UAFALTERNATE system parameter you set in step 2:
    $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> PARAMETERS USE CURRENT
    SYSMAN> PARAMETERS SET UAFALTERNATE 0

    In most cases, VSI recommends that you use AUTOGEN to modify system parameters. However, since this parameter is being changed only temporarily, you can use SYSMAN or SYSGEN to change it back.

  9. If you disabled the windowing system in step 3, re-enable it by entering the following command:
    SYSMAN> PARAMETERS SET WINDOW_SYSTEM 1
  10. Enter the following command to save the changed system parameter values:
    SYSMAN> PARAMETERS WRITE CURRENT
  11. Shut down and reboot the system.

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

4.5. Booting with Controlled Startup

Section 4.1.4 explains the site-independent startup command procedure, SYS$SYSTEM:STARTUP.COM. By default, when your system boots, it automatically executes STARTUP.COM to execute startup events. Under special circumstances, you might want to control site-independent startup when you boot the system. For example, you might want to perform one of the following tasks:

Task

For More Information

Boot with an alternate site-independent startup procedure

Section 4.5.1

Boot with an alternate site-independent startup command procedure by default

Section 4.5.2

Boot with minimum startup

Section 4.5.3

Display startup procedure commands as they execute

Section 4.5.4


Caution

Do not modify STARTUP.COM. The system requires this procedure to correctly start up the system. For information about modifying site-specific startup procedures to perform site-specific operations, see Section 5.2.

4.5.1. Booting with an Alternate Site-Independent Startup Procedure

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

  1. Follow the instructions for performing a conversational boot in one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

  2. Enter the following command to show the current startup file:
    SYSBOOT> SHOW/STARTUP
  3. Enter a command in the following format to specify the alternate site-independent startup command procedure:
    SET/STARTUP file-spec
    where file-spec specifies the entire file specification for the startup file to be used, including the device and directory. For example:
    SYSBOOT> SET/STARTUP SYS$SYSTEM:XSTARTUP.COM
    If the startup file specified as file-spec does not exist, the system displays the following message:
    Error opening primary input file SYS$INPUTFile not found

    Check the file name you entered. Make sure you specified it correctly.

  4. Enter the following command to verify the change:
    SYSBOOT> SHOW/STARTUP
  5. Enter the following command to continue booting:
    SYSBOOT> CONTINUE

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

4.5.2. Specifying an Alternate Default Startup Command Procedure

The default system startup procedure is SYS$SYSTEM:STARTUP.COM. However, in special environments, you might want the system to perform special startup commands. If you frequently require a startup command procedure other than SYS$SYSTEM:STARTUP.COM, you can specify that the alternate procedure be used by default.

How to Perform This Task

  1. Edit the file SYS$SYSTEM:MODPARAMS.DAT. AUTOGEN uses this file to modify parameters.

  2. Add a line to MODPARAMS.DAT assigning the name of your alternate procedure to the symbol STARTUP. For example:
    STARTUP = "SYS$SYSTEM:MY_STARTUP.COM"
  3. At a convenient time, invoke AUTOGEN. When the system reboots, the procedure specified in step 2 becomes the default startup command procedure.

Example

$ EDIT SYS$SYSTEM:MODPARAMS.DAT
.
.
.
[Insert the following line in MODPARAMS.DAT:]
STARTUP = "SYS$SYSTEM:MY_STARTUP.COM"
.
.
.
$ @SYS$SYSTEM:AUTOGEN SAVPARAMS REBOOT

4.5.3. Booting with Minimum Startup

In special cases, you might want to boot your system without performing the full sequence of startup events. For example, if a startup event prevents you from logging in, you might want to boot the system without executing the startup, so that you can log in and fix the problem.

When you boot with minimum startup, the system starts only the components that are absolutely required to run the system. These tasks can vary between different releases of the operating system.

Note

When you boot with minimum startup, the CONFIGURE process is not created. If external devices are needed on this boot, add the following line to SYS$MANAGER:SYLOGICALS.COM:
$IF P1 .NES. "FULL" THEN @SYS$SYSTEM:STARTUP CONFIGURE

How to Perform This Task

  1. Follow the instructions for performing a conversational boot in one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

  2. At the SYSBOOT> prompt, enter the following command:
    SYSBOOT> SET STARTUP_P1 "MIN"
  3. Enter the following command to continue booting:
    SYSBOOT> CONTINUE
  4. After the system boots, log in and enter the following commands to invoke SYSMAN and clear the STARTUP_P1 parameter you set in step 2:
    $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> PARAMETERS USE CURRENT
    SYSMAN> PARAMETERS SET STARTUP_P1 ""
    SYSMAN> PARAMETERS WRITE CURRENT

Example

[perform a conversational boot]
SYSBOOT> SET STARTUP_P1 "MIN"
SYSBOOT> CONTINUE
[system completes booting]
Username: [Return]
Password: [Return]
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> PARAMETERS USE CURRENT
SYSMAN> PARAMETERS SET STARTUP_P1 ""
SYSMAN> PARAMETERS WRITE CURRENT

Caution

If you boot with minimum startup with the VAXCLUSTER system parameter set to 0, the only HSC or DSSI devices that will be accessible will be the boot device and then only if the boot device is controlled by an HSC or a DSSI controller.

To make HSC and DSSI devices accessible, perform one of the following actions:
  • Use this command:
    $ RUN SYS$SYSTEM:CONFIGURE/DETACH

    This makes the devices accessible without rebooting the system.

  • Reboot the system setting the STARTUP_P1 system parameter to "".

  • Reboot the system with the VAXCLUSTER system parameter set to 1 or 2.

4.5.4. Booting While Displaying Startup Procedure Commands

In some cases—for example, when you are trying to test a startup command procedure, or when troubleshooting startup problems—it is helpful to display the startup commands as they are executed.

How to Perform This Task

  1. Follow the instructions for performing a conversational boot in one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

  2. At the SYSBOOT> prompt, enter the following command:
    SYSBOOT> SET STARTUP_P2 "YES"
  3. Enter the following command to continue booting:
    SYSBOOT> CONTINUE
  4. After the system boots, log in and enter the following commands to invoke SYSMAN and clear the STARTUP_P2 parameter you set in step 2:
    $ RUN SYS$SYSTEM:SYSMAN
    SYSMAN> PARAMETERS USE CURRENT
    SYSMAN> PARAMETERS SET STARTUP_P2 ""
    SYSMAN> PARAMETERS WRITE CURRENT

Example

 [perform a conversational boot]
SYSBOOT> SET STARTUP_P2 "YES"
SYSBOOT> CONTINUE
 [system completes booting]
Username: [Return]
Password: [Return]
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> PARAMETERS USE CURRENT
SYSMAN> PARAMETERS SET STARTUP_P2 ""
SYSMAN> PARAMETERS WRITE CURRENT

4.5.5. Displaying Startup Procedure Commands with SYSMAN

In addition to performing a conversational boot to display startup procedures, you can use SYSMAN to display startup status with the STARTUP SET OPTIONS command. The advantage of using SYSMAN is that you can obtain verification and logging for multiple nodes at a time.

SYSMAN startup logging redefines STARTUP_P2 to specify:

  • The amount of debugging information STARTUP.COM displays

  • Whether to keep a log of the startup

The STARTUP SET OPTIONS command provides the options shown in Table 4.2.

Table 4.2. Startup Logging Options
OptionFunction
/VERIFY=FULLDisplays every line of DCL executed by component startup procedures and by STARTUP.COM.
/VERIFY=PARTIALDisplays every line of DCL executed by component startup procedures, but does not display DCL executed by STARTUP.COM.

/OUTPUT=FILE

/OUTPUT=CONSOLE

Creates SYS$SPECIFIC:[SYSEXE]STARTUP.LOG, which contains all of the output generated by startup procedures. Alternatively, you can display the output on the console.
/CHECKPOINTINGDisplays informational messages describing the time and status of each startup phase and component file.

How to Perform This Task

  1. At the DCL prompt ($), enter the following command:

    $ RUN SYS$SYSTEM:SYSMAN
  2. At the SYSMAN> prompt, enter the following command:

    SYSMAN> STARTUP SET OPTIONS/[qualifier]

    Qualifiers can be any of the options specified in Table 4.2. These options take effect the next time you boot the system.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP SET OPTIONS/VERIFY=FULL/OUTPUT=FILE/CHECKPOINTING

This example requests startup logging with:

  • Full verification

  • Output to the STARTUP.LOG file

  • Checkpointing

To show the current startup options, enter the following command:

SYSMAN> STARTUP SHOW OPTIONS

For more information, refer to the VSI OpenVMS System Management Utilities Reference Manual.

4.6. Solving Booting Problems

A hardware or software malfunction can prevent the operating system from booting when you enter the BOOT command.

Hardware Problems

A read error on a disk drive or console medium, or a machine check error, might indicate a hardware malfunction. When a hardware problem occurs, a question mark (?) usually precedes the error message that is displayed on the system console terminal. You should then perform one or both of the following actions:
  • Consult the hardware manual for your computer.

  • Contact your VSI support representative.

Software Problems

If the operating system is loaded into memory but the STARTUP.COM command procedure does not execute, a software malfunction has probably occurred. Suspect this condition if a message similar to following message does not appear:
The OpenVMS system is now executing the system startup procedure.
Perform one or both of the following actions to correct the situation:
  • Try again, by repeating the boot procedure. For instructions, refer to one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the most recent version of the OpenVMS Alpha Upgrade and Installation Manual.

    If you have a removable system disk, replace it with a backup copy of the system disk. Try to boot the system again.

  • Leave the system disk in the original drive. Restore a backup copy of the system disk. For instructions, see Section 11.17.Try to boot the system again.

4.7. Writing a New Boot Block on the System Disk

Block 0 on a system disk is the boot block. It contains the size and location of the primary bootstrap image, which is used to boot the system.

On VAX systems, the primary bootstrap image is VMB.EXE.

On Alpha systems, the primary bootstrap image is APB.EXE.

On I64 systems, the primary bootstrap image is IPB.EXE.

Certain processors must read the boot block to obtain the location of the primary bootstrap image. Processors that read a boot block include the following ones:
  • VAX–11/750

  • VAX 8200, 8250, 8300, and 8350

  • VAX 6000–200, 6000–300, 6000–400, 6000–500, and 6000–600

  • VAX 7000 and VAX 10000

  • All Alpha and I64 systems (subject to change for future systems)

To determine if your system reads the boot block, check one of the following manuals:
  • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

  • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

If you suspect that the boot block on the system disk is invalid, you can write a new boot block using the Writeboot utility (WRITEBOOT).The following actions might cause a boot block to become invalid:
  • Modifying the primary bootstrap image with the SET FILE/MOVE command or the $MOVEFILE system service.

  • Restoring a backup of the system disk created without the /IMAGE qualifier.

  • Adding a new version of the primary bootstrap image, for example, during an operating system upgrade. (When the upgrade procedure adds a new version of the primary bootstrap image, it automatically uses WRITEBOOT to write a new boot block.)

  • Adding a new version of the primary bootstrap image that is not contiguous on disk. (Use the DIRECTORY/FULL command to determine this.)

Note

Instructions for using the WRITEBOOT utility are somewhat different on VAX and Alpha systems. Instructions for performing this task on VAX and Alpha systems follow. You must have LOG_IO privilege to use WRITEBOOT.

On I64 systems, you use SETBOOT to write a boot block. Instructions for performing this task are also in this section.

How to Perform This Task

On VAX systems, follow these steps to use the Writeboot utility:
  1. To start the Writeboot utility, enter the following command:
    $ RUN SYS$SYSTEM:WRITEBOOT
  2. The procedure displays the following message:
    Target system device (and boot file if not VMB.EXE):?
    On VAX systems, VMB.EXE is the default bootstrap image. Enter a response in the following format:
    device:[VMS$COMMON.SYSEXE]VMB.EXE;  

    Use the device name format described in the upgrade and installation documentation for your processor. If you want to boot using a bootstrap image other than the default, you must specify the full file specification of the image, including device and directory.

  3. The procedure displays the following message:
    Enter VBN of boot file code (default is one):

    Ordinarily, the boot code is located at virtual block number (VBN) 1of the bootstrap image. Press Return to accept the default value of 1.

  4. The procedure displays the following message:
    Enter load address of primary bootstrap in HEX (default is 200):

    The load address is the location in memory (specified in hexadecimal notation) to which the system loads the bootstrap image. Ordinarily you copy the bootstrap image to address 200. Press Return to accept the default value of 200.

  5. The Writeboot utility writes the information you specified to the boot block (block 0)on the system disk.

On VAX systems, the Writeboot utility might display one or more of the following error messages:

  • “You lack LOG_IO privilege.”

    This message means you do not have the correct privilege to use the Writeboot utility.

  • “You lack READ and/or WRITE access to TARGET DEVICE. DISMOUNT and reMOUNT it.”

    This message means that access to the target device is limited. Check the WRITE PROTECT button on the disk drive.

  • “Boot file is not contiguous.”

    This message means that the primary bootstrap image, VMB.EXE, is not contiguous on disk. Enter the following command:

    $ COPY/CONTIGUOUS device:[VMS$COMMON.SYSEXE]VMB.EXE; -
    _$ device:[VMS$COMMON.SYSEXE]

    Rewrite the boot block for the new image by running WRITEBOOT again.

  • “VBN must be >= 1.”

    This message means you cannot specify a 0 as the virtual block number (VBN).

    Example:

    On VAX systems, the following example writes a boot block on a system disk:

    $ RUN SYS$SYSTEM:WRITEBOOT
    Target system device (and boot file if not VMB.EXE):?
    DUA0:[VMS$COMMON.SYSEXE]VMB.EXE
    Enter VBN of boot file code (default is one):[Return]
    Enter load address of primary bootstrap in HEX (default is 200): [Return]

How to Perform This Task on Alpha Systems

On Alpha systems, follow these steps to use the Writeboot utility:
  1. To start the Writeboot utility, enter the following command:
    $ RUN SYS$SYSTEM:WRITEBOOT
    The procedure asks you whether you want to write the VAX portion of the boot block:
    Update VAX portion of boot block (default is Y):
  2. Enter NO.

  3. The utility displays the following prompt:
    Update Alpha portion of boot block (default is Y):

    Press Return to accept the default value of Y.

  4. The utility prompts you for the Alpha bootstrap image:
    Enter Alpha boot file:
    On Alpha systems, APB.EXE is the default bootstrap image. Enter a response in the following format:
    device:[VMS$COMMON.SYSEXE]APB.EXE;  

    where device specifies the device name of the system disk.

  5. The Writeboot utility writes the information you specified to the boot block (block 0) on the system disk.

On Alpha systems, the Writeboot utility might display one or more of the following error messages:
  • You lack LOG_IO privilege.

    This message means you do not have the correct privilege to use the Writeboot utility.

  • You lack READ and/or WRITE access to TARGET DEVICE. DISMOUNT and reMOUNT it.

    This message means that access to the target device is limited. Check the WRITE PROTECT button on the disk drive.

  • Boot file is not contiguous.

    This message means that the primary bootstrap image, APB.EXE, is not contiguous on disk. Enter the following command:

    $ COPY/CONTIGUOUS device:[VMS$COMMON.SYSEXE]APB.EXE; -
    _$ device:[VMS$COMMON.SYSEXE]

    Rewrite the boot block for the new image by running WRITEBOOT again.

    Example:

    On Alpha systems, the following example writes a boot block on a system disk:

    $ RUN SYS$SYSTEM:WRITEBOOT
    Update VAX portion of boot block (default is Y): N
    Update Alpha portion of boot block (default is Y): [Return]
    Enter Alpha boot file: DUA0:[VMS$COMMON.SYSEXE]APB.EXE;

    How to Perform This Task on I64 Systems

    To write a boot block for OpenVMS I64 systems, VSI provides the DCL SET BOOTBLOCK command, which functions similarly to the Writeboot utility (WRITEBOOT.EXE) used on OpenVMS Alpha systems. (Do not use the Writeboot utility on OpenVMS I64 systems.)

    SET BOOTBLOCK allows you to create a bootable OpenVMS Alpha system disk from one that was originally created by one of the following methods:

    • A nonimage backup of an OpenVMS I64 system disk (possibly corrupting the boot block)

    • A nonimage restore of an OpenVMS I64 system disk from an image save set

    The SET BOOTBLOCK command also allows you to rewrite the boot block of an OpenVMS I64 system disk to point to a new version of the OpenVMS I64 primary bootstrap file (SYS$EFI.SYS) that you have previously copied to the disk. (Note that the file must be contiguous.)

    To write a boot block onto a disk, enter the following command:

    $ SET BOOTBLOCK

    You can specify a boot file with the command. By default, the command creates the bootfile SYS$SYSDEVICE:[VMS$COMMON.SYS$LDR]SYS$EFI.SYS. The boot file must be contiguous. If it is not contiguous, use the DCL COPY/CONTIGUOUS command or similar to recreate a contiguous version of the boot file. In addition, the boot file must also be marked NOMOVE (use the DCL SET FILE/NOMOVE command) to avoid bootstrap failures that could otherwise arise from the normal and expected operations of disk defragmentation tools.

    Alternatively, you can write a boot block by entering the following command:

    $ RUN SYS$SYSTEM:SYS$SETBOOT

    The utility prompts you for the required input (as does the OpenVMS Alpha Writeboot utility).

4.8. Shutting Down the System

The operating system provides the following shutdown procedures:

Procedure

Purpose

For More Information

SHUTDOWN.COM

An orderly shutdown procedure. This procedure shuts down the system while performing housekeeping functions such as disabling future logins, stopping the batch and output queues, dismounting mounted volumes, and stopping user processes.

Section 4.8.1

OPCCRASH.EXE

An emergency shutdown program. Run the OPCCRASH emergency shutdown program if you are unable to perform an orderly shutdown with SHUTDOWN.COM.

Section 4.8.5

Shutdown using console commands

Emergency shutdown commands. Use these console shutdown commands only if OPCCRASH.EXE fails.

Section 4.8.6

4.8.1. Performing an Orderly Shutdown with SHUTDOWN.COM

Use SYS$SYSTEM:SHUTDOWN.COM to shut down the system in an orderly fashion. See Section 4.8.2 for the order of shutdown events.

Do not modify SHUTDOWN.COM. To perform site-specific operations during shutdown, see Section 4.8.3.

Ordinarily, you shut down the system from the SYSTEM account, which includes all privileges by default. To execute SHUTDOWN.COM, you must have either the SETPRV privilege or all of the following privileges:
  • AUDIT
  • CMKRNL
  • EXQUOTA
  • LOG_IO
  • NETMBX
  • OPER
  • SECURITY
  • SYSNAM
  • SYSPRV
  • TMPMBX
  • WORLD
You can cancel a shutdown without any side effects by pressing Ctrl/Y before SHUTDOWN.COM displays the following message:
%SHUTDOWN-I-SITESHUT, The site-specific shutdown procedure will now be invoked.

If you press Ctrl/Y after this display, certain system components might have already been shut down, and you will need to recover manually. For example, you might have to manually restart processes, mount disks, or reboot the system.

How to Perform This Task

  1. Log in to the system manager's account (SYSTEM), or any privileged account, and enter the following command:
    $ @SYS$SYSTEM:SHUTDOWN.COM

    This command invokes the orderly shutdown procedure. The procedure prompts you with a series of questions and messages. The default responses appear in brackets at the end of each question. Press Return to select the default response.

  2. The system displays the following question:
    How many minutes until final shutdown [0]?
    Enter an integer. If you have defined the system logical name SHUTDOWN$MINIMUM_MINUTES, its integer value is the minimum value that you can enter. For example, if the logical name is defined as 10, you must specify at least 10 minutes to final shutdown or an error message is returned. If you do not enter a value, SHUTDOWN.COM uses the logical name value.

    Caution

    The default is 0 minutes. If you have not defined the logical name SHUTDOWN$MINIMUM_MINUTES, and you do not enter a value, the system will beshut down immediately after you answer the last question.

  3. The system displays the following question:
    Reason for shutdown [standalone]:

    Enter a one-line reason for shutting down the system. For example, Monthly preventive maintenance.

  4. The system displays the following question:
    Do you want to spin down the disk volumes [No]?

    Enter YES or NO (Y or N). Note, however, that you cannot spin down the system disk. Also, many disks, particularly SCSI disks, do not spin down in response to this option.

  5. The system displays the following question:
    Do you want to invoke the site-specific shutdown procedure [Yes]?

    If you have entered site-specific commands in SYSHUTDWN.COM, press Return to accept the default answer, YES. For more information, see Section 4.8.3.2.

  6. The system displays the following question:
    Should an automatic system reboot be performed [No]?

    By default, the system does not automatically reboot. However, if you respond YES, the system attempts to reboot automatically when the shutdown is complete. For example, you would specify YES if you are rebooting the system after modifying values for nondynamic system parameters with SYSMAN or SYSGEN. (When you change nondynamic system parameters, you must reboot the system for the new values to take effect.)

  7. The system displays a question similar to the following one:
    When will the system be rebooted [later]?

    If you entered YES in step 6, the default answer to this question is [shortly via automatic reboot].

    Press Return to take the default, or enter the expected reboot time in the format you want users to see. For example, you could specify IMMEDIATELY, or IN 10MINUTES, or a time such as 2 P.M. or 14:00. If you do not know when the system will be available again, press Return to specify later as the time when the system will reboot.

  8. The procedure prompts you to specify one or more shutdown options, as follows (if your system is not a member of an OpenVMS Cluster environment, the procedure lists only the REBOOT_CHECK and SAVE_FEEDBACK options):
    Shutdown options (enter as a comma-separated list):
     REMOVE_NODE         Remaining nodes in the cluster should adjust quorum
     CLUSTER_SHUTDOWN    Entire cluster is shutting down
     REBOOT_CHECK        Check existence of basic system files
     SAVE_FEEDBACK       Save AUTOGEN feedback information from this boot
     DISABLE_AUTOSTART   Disable autostart queues
    Shutdown options [NONE]
    Specify the options you want to use. Choose from the options in the following table:

    Option

    Description

    REMOVE_NODE

    Causes other nodes in the cluster to decrease the value of the EXPECTED_VOTES system parameter. (This parameter is automatically increased each time a node joins the cluster.)Specifying REMOVE_NODE will not decrease the EXPECTED_VOTES below the quorum value.

    Use this option if the node you are shutting down will be out of the cluster a considerable period of time.

    When you use this option, all locally attached disks are dismounted clusterwide. Therefore, you must shut down applications on other nodes that have open files on the locally attached disks. Failure to do so might cause mount verify timeout problems as well as application problems.

    CLUSTER_SHUTDOWN

    Synchronizes the shutdown of a cluster; only when the shutdown of each node has progressed to a certain point will the shutdown be completed.

    Use this option on each node in the cluster to synchronize the shutdown.

    REBOOT_CHECK

    Verifies the presence of files necessary to reboot the system after shutdown completes.

    The procedure checks for the necessary files and notifies you if any are missing. Replace missing files before proceeding.

    SAVE_FEEDBACK

    Records feedback data collected from the system since it was last booted and creates a new version of the AUTOGEN feedback data file, which AUTOGEN can use the next time it runs.

    For detailed information about using the AUTOGEN feedback mechanism, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

    DISABLE_AUTOSTART

    Specifies the time interval between the DISABLE AUTOSTART/QUEUES command and system shutdown. For more information, see Section 14.7.1.9.

Example

$ @SYS$SYSTEM:SHUTDOWN


         SHUTDOWN – Perform an Orderly System Shutdown
How many minutes until final shutdown [0]: 10
Reason for shutdown: [Standalone] MONTHLY PREVENTIVE MAINTENANCE
Do you want to spin down the disk volumes [No]?
Do you want to invoke the site-specific shutdown procedure [Yes]?
Should an automatic system reboot be performed [No]?
When will the system be rebooted [later]? 12:30
Shutdown options (enter as a comma-separated list):
 REMOVE_NODE         Remaining nodes in the cluster should adjust quorum
 CLUSTER_SHUTDOWN    Entire cluster is shutting down
 REBOOT_CHECK        Check existence of basic system files
 SAVE_FEEDBACK       Save AUTOGEN feedback information from this boot
 DISABLE_AUTOSTART   Disable autostart queues
Shutdown options [NONE]

SHUTDOWN message on AVALON, from user SYSTEM at _AVALON$OPA0:   12:00:00.20
AVALON will shut down in 10 minutes; back up 12:30. Please log off node AVALON.
MONTHLY PREVENTIVE MAINTENANCE

%SHUTDOWN-I-OPERATOR, This terminal is now an operator's console.
%%%%%%%%%%%  OPCOM, 16-MAY-2000 12:01:00.15  %%%%%%%%%%%
Operator status for operator _AVALON$OPA0:
CENTRAL, PRINTER, TAPES, DISKS, DEVICES, CARDS, NETWORK, OPER1, OPER2,
OPER3, OPER4, OPER5, OPER6, OPER7, OPER8, OPER9, OPER10, OPER11,
OPER12

%SHUTDOWN-I-DISLOGINS, Interactive logins will now be disabled.
%SET-I-INTSET, login interactive limit = 0 current interactive value = 17
%SHUTDOWN-I-SHUTNET, The DECnet network will now be shut down.



SHUTDOWN message on AVALON, from user SYSTEM at _AVALON$OPA0:   12:05:00.20
AVALON will shut down in 5 minutes; back up 12:30. Please log off node AVALON.
MONTHLY PREVENTIVE MAINTENANCE

17 terminals have been notified on AVALON.

SHUTDOWN message on AVALON from user SYSTEM at
_AVALON$OPA0:   12:06:55.28
AVALON will shut down in 3 minutes; back up 12:30. Please log off node AVALON.
MONTHLY PREVENTIVE MAINTENANCE


%%%%%%%%%%%  OPCOM, 16-MAY-2000 12:07:12.30  %%%%%%%%%%%
Message from user DECnet on AVALON
DECnet event 2.0, local node state change
From node 2.161 (AVALON), 16-MAY-2000 12:07:22.26
Operator command, Old state = On, New state = Shut
SHUTDOWN message on AVALON user SYSTEM at
_AVALON$OPA0:   12:08:12.56
AVALON will shut down in 2 minutes; back up 12:30. Please log off node AVALON.
MONTHLY PREVENTIVE MAINTENANCE

%%%%%%%%%%%  OPCOM, 16-MAY-2000 12:08:12:30  %%%%%%%%%%%
Message from user SYSTEM on AVALON-SYSTEM-S-NORMAL, normal successful completion

%%%%%%%%%%%  OPCOM, 16-MAY-2000 12:08:42.30  %%%%%%%%%%%
Message from user DECNET on AVALONDECnet shutting down

%SYSTEM-I-STOPQUEUES, The queues on this node will now be stopped.
SHUTDOWN message on AVALON from user SYSTEM at
_AVALON$OPA0:   12:09:12.56
AVALON will shut down in 1 minute; back up 12:30. Please log off node AVALON.
MONTHLY PREVENTIVE MAINTENANCE

SHUTDOWN message on AVALON, from user SYSTEM at
_AVALON$OPA0:   12:10:00.20
AVALON will shut down in 0 minutes; back up 12:30. Please log off node AVALON.
MONTHLY PREVENTIVE MAINTENANCE

17 terminals have been notified on AVALON
%SHUTDOWN-I-SITESHUT, The site-specific shutdown procedure will now be invoked.
%SHUTDOWN-I-STOPUSER, All user processes will now be stopped.
%SHUTDOWN-I-REMOVE, All installed images will now be removed.
%SHUTDOWN-I-DISMOUNT, All volumes will now be dismounted.
%%%%%%%%%%%  OPCOM, 16-MAY-2000 12:09:42.30  %%%%%%%%%%%
Message from user System on AVALON_AVALON$OPA0:, AVALON shutdown was requested by the operator.

%%%%%%%%%%%  OPCOM, 16-MAY-2000 12:10:02.44  %%%%%%%%%%%
Logfile was closed by operator _AVALON$OPA0:Logfile was SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;8

%%%%%%%%%%%  OPCOM, 16-MAY-2000 12:10:32.20  %%%%%%%%%%%
Operator _AVALON$OPA0: has been disabled, username SYSTEM

        SYSTEM SHUTDOWN COMPLETE
On VAX systems, the following message is also displayed:
USE CONSOLE TO HALT SYSTEM 

Halt the system after you see this message.

4.8.2. Understanding the Order of Shutdown Events

The following events occur as the shutdown proceeds. The procedure displays the corresponding messages on the terminal.
  1. At decreasing time intervals, SHUTDOWN.COM broadcasts, to all users on the system, a message requesting users to log out.

  2. SHUTDOWN.COM defines the system logical name SHUTDOWN$TIME to be the absolute time of shutdown. For example, if you execute SHUTDOWN.COM, and at 12:00 you specify the value 10 in response to the first question, SHUTDOWN defines the logical name to be 12:10 on that day. To see if a shutdown is in progress or to determine the actual time of shutdown, you can enter the command SHOW LOGICAL SHUTDOWN$TIME. This feature is useful if you miss a shutdown broadcast message.

  3. At 6 minutes or less before system shutdown, the terminal from which you invoked SHUTDOWN becomes an operator's console. SHUTDOWN disables all future non-operator logins and shuts down the DECnet network if it is running. At this point, users logged in to the system with the SET HOST command lose their sessions.

  4. One minute before shutdown, SHUTDOWN.COM stops batch and output execution queues and stops the queue manager.

  5. At the absolute time of shutdown, SHUTDOWN.COM invokes the site-specific shutdown command procedure SYS$MANAGER:SYSHUTDWN.COM, if you requested it.

  6. SHUTDOWN.COM stops all remaining user processes; however, system processes continue. Ancillary control processes (ACPs) might delete themselves when their mounted volumes are finally dismounted.

  7. On multiprocessor systems, SHUTDOWN.COM stops the secondary processors.

  8. SHUTDOWN.COM removes all installed images.

  9. SHUTDOWN.COM dismounts all mounted volumes and, if you requested it, spins down the disks. If you defined SHUTDOWN$VERBOSE, the procedure lists each disk as it is dismounted.

    The procedure does not spin down the system disk, nor does it dismount or spin down the quorum disk (if one exists on your system).

  10. SHUTDOWN.COM closes the operator log file.

  11. SHUTDOWN.COM runs the program SYS$SYSTEM:OPCCRASH.EXE to shut down the system.

  12. If you requested an automatic reboot, the system reboots, provided you set the necessary controls. You requested an automatic reboot if you answered YES to the following question:
    Should an automatic system reboot be performed [No]?
    If you did not request an automatic reboot, a message similar to the following one appears on the system console:
    SYSTEM SHUTDOWN COMPLETE 
    On VAX systems, the following message is also displayed:
    USE CONSOLE TO HALT SYSTEM  

    Halt the system after you see this message.

4.8.3. Customizing SHUTDOWN.COM to Perform Site-Specific Operations

In addition to choosing shutdown options when you execute SHUTDOWN.COM, you can customize SHUTDOWN.COM to meet the needs of your site in the following ways.

Method

For More Information

Defining logical names

Section 4.8.3.1

Modifying the site-specific shutdown command procedure

Section 4.8.3.2

4.8.3.1. Defining Logical Names

Before executing SHUTDOWN.COM, you can define the following logical names to control the operations of the command procedure:

Logical Name

Description

SHUTDOWN$DECNET_MINUTES

Defines the number of minutes remaining before DECnet is shut down; must be defined with the /SYSTEM qualifier. The default is 6 minutes.

SHUTDOWN$DISABLE_AUTOSTART

Specifies the number of minutes between the time autostart is disabled for queues and the time the system is shut down; must be defined with the /SYSTEM qualifier. For more information, see Section 14.7.1.9.

SHUTDOWN$INFORM_NODES

Specifies a list of OpenVMS Cluster nodes to be notified when the system is shutting down. This logical name is described in detail in this section.

SHUTDOWN$MINIMUM_MINUTES

Defines the minimum number of minutes you can specify as number of minutes to shutdown. For example, if your users require 30 minutes' notice before a system shutdown, define this logical name to be 30. This logical must be defined with the /SYSTEM qualifier.

SHUTDOWN$QUEUE_MINUTES

Defines the number of minutes remaining before shutdown when queues are shut down; must be defined with the /SYSTEM qualifier. The default is 1 minute.

SHUTDOWN$TIME

Defines the absolute time of the shutdown; must be defined with the /SYSTEM qualifier.

SHUTDOWN$VERBOSE

If defined to any string, specifies that the shutdown command procedure is to list each disk as it is dismounted.

If you plan to use an option every time you use SHUTDOWN.COM, define the logical name in the site-specific startup command procedure SYLOGICALS.COM. For more information, see Section 5.2.5.

Specifying a List of Nodes to Be Notified When the System Is Shutting Down

You can define the logical name SHUTDOWN$INFORM_NODES to be a list of OpenVMS Cluster nodes that are notified when the system is shut down. You must define SHUTDOWN$INFORM_NODES before executing SYS$SYSTEM:SHUTDOWN.COM.

To define SHUTDOWN$INFORM_NODES, enter a command in the following format:
DEFINE SHUTDOWN$INFORM_NODES "node-list"
where node-list specifies the list of nodes to be informed. For example:
$ DEFINE SHUTDOWN$INFORM_NODES "NODE1, NODE2, NODE3"

If you plan to inform the same nodes every time you shut down the system, add the command to the site-specific startup command procedure SYLOGICALS.COM. For more information, see Section 5.2.5.

If you define SHUTDOWN$INFORM_NODES, all member nodes included in the list are notified when you execute SHUTDOWN.COM. Users on the node that is being shut down are always notified, regardless of whether you define SHUTDOWN$INFORM_NODES. If you omit the name of the node that is being shut down from the list specified in the DEFINE command, SHUTDOWN.COM automatically adds the name to the list.

The information in Table 4.3 indicates which nodes are notified at different phases of the shutdown sequence, depending on whether SHUTDOWN$INFORM_NODES is defined.
Table 4.3. Node Notification During Shutdown

Shutdown Phase

If SHUTDOWN$INFORM_NODES Is Not Defined

If SHUTDOWN$INFORM_NODES Is Defined

First shutdown notification

Notify all terminals on all nodes

Notify all terminals on all listed nodes

Between first shutdown notification and 2minutes before final shutdown

Notify all terminals logged in to the node that is shutting down

Notify all users logged in on all listed nodes

Between 2 minutes before final shutdown notification until final shutdown

Notify all users logged in on all nodes

Notify all users logged in on all listed nodes

Shutdown canceled

Notify all terminals on all nodes

Notify all terminals on all listed nodes

4.8.3.2. Modifying the Site-Specific Shutdown Command Procedure

You can add site-specific commands to the site-specific shutdown procedure SYS$MANAGER:SYSHUTDWN.COM. An empty SYSHUTDWN.COM file is included in your distribution kit.

SHUTDOWN.COM prompts you to indicate if you want to execute the site-specific procedure SYSHUTDWN.COM:
Do you want to invoke the site-specific shutdown procedure [Yes]?

Press Return to accept the default answer YES.

4.8.3.2.1. Using the SYSHUTDWN_0010.TEMPLATE Procedure

Some applications use batch queues and print queues heavily to meet the application requirements. In these heavy use environments, it is recommended to run the optional procedure SYSHUTDWN_0010.COM to stop all the application activity prior to the SYSHUTDWN.COM procedure terminating queue operations.

The file SYS$MANAGER:SYSHUTDWN_0010.TEMPLATE illustrates three different functions a system administrator might want to perform before shutting down the queue system.

  1. The RESET_QUEUES function checks for queues and jobs that could hang or significantly delay shutdown and cleans them off the system.

  2. The QMAN_CHECKPOINT function requests the queue manager shrink the queue journal file, file type .QMAN$JOURNAL, to the smallest possible size.

  3. The KILL_SYMBIONTS function searches for any symbiont processes that are not stopping and kills them. Some symbionts may have long wait times to connect to devices over a WAN and refuse to stop until a network response is received.

Rename SYSHUTDWN_0010.TEMPLATE to SYSHUTDWN_0010.COM and the procedure will be executed at the next system shutdown.

4.8.3.3. Dismounting Shadow Sets in Site-Specific Shutdown Procedures

The default SHUTDOWN.COM procedure that ships with the operating system performs a DISMOUNT/ABORT/OVERRIDE=CHECKS operation on all mounted volumes. If files are left open on any mounted shadow sets, a merge operation is required for these shadow sets when the system is rebooted.

To prevent such unnecessary merge operations, VSI recommends that you modify each site-specific SYSHUTDWN.COM command procedure to dismount the shadow sets without using the /ABORT/OVERRIDE=CHECKS command qualifiers. If you find open files, close them.

4.8.4. Performing an Orderly Shutdown with SYSMAN

The advantage of using the System Management Utility (SYSMAN) for shutdown is that you can shut down a group of nodes quickly. SYSMAN enables you to enter all of the shutdown parameters in one command line, rather than responding to the interactive dialog in SHUTDOWN.COM. SYSMAN does not wait for the nodes to shut down before you can use other SYSMAN commands; the interface returns immediately.

How to Perform This Task

  1. Enter the following command at the DCL prompt ($):

    $ RUN SYS$SYSTEM:SYSMAN
  2. At the SYSMAN> prompt, enter the following command:

    SYSMAN> SHUTDOWN NODE/[qualifier]

Qualifiers can be any of the following options:

QualifierFunction
MINUTES_TO_SHUTDOWNIndicates the number of minutes until shutdown occurs.
REASONIndicates the reason for the shutdown.
REBOOT_TIMEIndicates the time you expect to reboot the system, such as LATER, 2 P.M., or 14:00. This time is displayed in the shutdown message to users.
[NO]SPIN_DOWN_DISKSSpins down disks. The default is NO. You cannot spin down the system disk.
[NO]INVOKE_SYSHUTDOWNInvokes the site-specific shutdown procedure. The default is INVOKE_SYSHUTDOWN.
[NO]AUTOMATIC_REBOOTReboots the system automatically when the shutdown is complete. The default is NO.
[NO]REBOOT_CHECKChecks for basic operating system files and notifies you if any are missing. The default is NO.
[NO]CLUSTER_SHUTDOWNShuts down the entire OpenVMS Cluster system. The default is NO.
[NO]REMOVE_NODERemoves the node from the active cluster quorum; use this when you do not expect the shut-down node to rejoin the cluster for an extended period. The default is NO.
[NO]SAVE_FEEDBACKRecords feedback data from the system since it was last booted and creates a new version of the AUTOGEN feedback data file, which you can use the next time you run AUTOGEN. The default is NO.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SHUTDOWN NODE/MINUTES_TO_SHUTDOWN=10/REBOOT_TIME="later" -
_SYSMAN> /REASON="DISK CORRUPTION PROBLEMS"/REBOOT_CHECK/SAVE_FEEDBACK

If you enter this command example on NODE21, it requests a shutdown on NODE21 with:

  • A message to users on all the cluster nodes, specifying:

    SHUTDOWN message on node NODE21, from user SYSTEM at _NODE21$0PA0:
    12:00:00:20. NODE21 will shut down in 10 minutes; back up later.
    Please log off node NODE21. DISK CORRUPTION PROBLEMS
    
  • A check for any missing operating system files and notification any are missing

  • Creation of a new AUTOGEN feedback data file based on the feedback data collected since the system was last booted

For more information, see the VSI OpenVMS System Management Utilities Reference Manual.

4.8.5. Performing an Emergency Shutdown with the OPCCRASH.EXE Program

Ordinarily, you shut down the system using the orderly shutdown procedure SHUTDOWN.COM. After SHUTDOWN.COM performs orderly housekeeping tasks, it invokes the program SYS$SYSTEM:OPCCRASH.EXE to shut down the system. OPCCRASH.EXE performs only the following minimal housekeeping functions:
  • Writes the modified page list back to disk. This ensures that all writable section files are updated to their correct state before the system crashes and all in-memory data is lost.

  • Unless the logical name OPC$NODUMP is defined, creates a crash dump by writing physical memory to the system dump file. For more information about the system dump file, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

In an emergency, if you cannot invoke SHUTDOWN.COM, you can run the OPCCRASH.EXE program to shut down your system immediately without performing any of the housekeeping functions that ensure an orderly shutdown.

Note

Run the OPCCRASH.EXE program directly only if SHUTDOWN.COM fails.

How to Perform This Task

To run the OPCCRASH.EXE program directly, you must have the CMKRNL privilege. You can enter the commands from any terminal and any privileged account. Follow these steps:
  1. Log in to any privileged account.

  2. Enter the following command:
    $ RUN SYS$SYSTEM:OPCCRASH
  3. If the system fails to respond after a few minutes, use the CRASH procedure or, if your system does not have a CRASH procedure, enter the emergency shutdown commands described in one of the following manuals:
    • On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

    • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

  4. A message similar to the following one is displayed at the console:
    SYSTEM SHUTDOWN COMPLETE 
    On VAX systems, the following message is also displayed:
    USE CONSOLE TO HALT SYSTEM 

    Halt the system when you see this message.

Example

The following example runs the OPCCRASH program to force a system crash, and halts the system:
$ RUN SYS$SYSTEM:OPCCRASH
         SYSTEM SHUTDOWN COMPLETE

Ctrl/P
>>>HALT
     HALTED AT 8000708A
On VAX systems, the following message is also displayed:
USE CONSOLE TO HALT SYSTEM 

Halt the system when you see this message.

4.8.6. Performing an Emergency Shutdown Using Console Commands

Certain computer consoles have an additional emergency CRASH command. If your computer has the CRASH command, it is located on the console media; you can execute it only from the console prompt on the console terminal. For example:
P00>>> CRASH
If the CRASH command does not exist on your console, you can shut down the system manually from the console.

Note

Use CRASH commands from the console only if the OPCCRASH.EXE program fails.

On VAX systems, enter the following commands:
P00>>> D PSL 041F0000
P00>>> D PC FFFFFFFF
P00>>> CON
On Alpha systems, enter the following commands:
P00>>> D PS 1F00
P00>>> D PC FFFFFFFFFFFFFF00
P00>>> CON

On I64 systems, you can do either of the following:

  • Enter Ctrl/P. The system then prompts you to Crash if the XDELTA boot flag is not set.

  • Go to the MP console and type TC (Take Crash) from the Command Menu.

See one of the following manuals for a description of the CRASH command or for equivalent commands to use to force an abrupt emergency shutdown:
  • On VAX systems, see the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.

  • On Alpha and I64 systems, refer to the VSI OpenVMS Version 8.2 OpenVMS Alpha Upgrade and Installation Manual.

4.9. Reconfiguring Devices on OpenVMS I64 Systems

You can reconfigure boot and dump devices on I64 systems at either of two times:

  • After you shut down the system following an installation – but before the system is booted. To use this method, you issue EFI Utilities for OpenVMS commands starting at the EFI Shell> option of the EFI Boot Manager.

    This method is explained in Appendix B of the VSI OpenVMS Version 8.2 Upgrade and Installation Manual. The EFI utilities commands are explained in the “EFI Utilities for OpenVMS” chapter in the VSI OpenVMS System Management Utilities Reference Manual, Volume 1: A-L.

  • Before you shut down the system following installation and initial booting. For this method, you enter DCL commands from the DCL command prompt and select options from the OpenVMS I64 Boot Manager Utility, BOOT_OPTIONS.COM, menu. Using the BOOT_OPTIONS command procedure, you can reconfigure boot, dump, or debug devices before you shut down the system prior to rebooting.

4.9.1. Understanding the OpenVMS I64 Boot Manager Utility, BOOT_OPTIONS. COM

The OpenVMS I64 Boot Manager Utility is a command procedure called BOOT_OPTIONS.COM, which displays menus from which you can select options to manipulate the entries on the following lists that are maintained on OpenVMS I64 systems:

  • Boot device list

  • Dump device list

  • Debug device list

After selecting the list you want to modify, you can add, display, and remove entries from the list and change the position of an entry on the list. On the boot device list, you can also validate and correct entries.

4.9.2. Starting to Use BOOT_OPTIONS.COM

After installing an OpenVMS system using Option 1 of the operating system menu, the system displays an operating system menu that contains eight options. (The steps prior to this are explained in more detail in the VSI OpenVMS Version 8.2 Upgrade and Installation Manual.)

On the operating system menu, select Option 7, Execute DCL commands and procedures. Enter the following from the DCL prompt:

$ @SYS$MANAGER:BOOT_OPTIONS

The system then displays the BOOT_OPTIONS main configuration menu shown in Example 4.1.

Example 4.1. Default BOOT_OPTIONS Configuration Menu
OpenVMS I64 Boot Manager Boot Options List Management Utility

   (1) ADD an entry to the Boot Options list
   (2) DISPLAY the Boot Options list
   (3) REMOVE an entry from the Boot Options list
   (4) MOVE the position of an entry on the Boot Options list
   (5) VALIDATE Boot Options and fix them as necessary
   (6) Modify the Boot Options TIMEOUT setting
   (B) Set to operate on the Boot Device Options list
   (D) Set to operate on the Dump Device List
   (G) Set to operate on the Debug Device List
   (E) EXIT configuration procedure
You can also enter CTRL/Y at any time to abort this utility
Enter your choice:

Table 4.4 explains the options in Example 4.1 in more detail.

Table 4.4. Options on the BOOT_OPTIONS Configuration Menu
OptionDescription
1ADDAdd an entry to the option list you have selected.
2DISPLAYDisplay the contents of the option list you have selected.
3REMOVERemove an entry from the option list you have selected.
4MOVEChange the position of an entry in the option list you have selected.
5VALIDATEVerify an entry in a selected option list and correct entries in the list, as necessary.
6TIMEOUTModify the timeout value.
BBOOTSelect the Boot (Device) Options List. (Default)
DDUMPSelect the Dump Device List.
GDEBUGSelect the Dubug Device List.
EEXITReturn to the DCL prompt.

The BOOT_OPTIONS Configuration menu contains the following types of lists:

  • Boot (Device) Options list

    This list contains devices that are available for the EFI Boot Manager to boot from. The list is also used by some EFI drivers for selective configuration of boot devices. For example, the VSI 2Port 2Gb Fibre Channel Adapter EFI driver searches the boot device options list for entries that contain the adapter path for the fibre channel device. Any matching entries on the SAN Name Server are logged in and reported to the EFI Shell.

  • Dump Device Options list

    This list is used specifically for configuring Dump Off the System Disk (DOSD). For instructions, refer to VSI OpenVMS System Manager’s Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

  • Debug Device Options list

    This list is specifically used for configuring the Debug Device for the System Code Debugger. This option is currently not supported in this release.

The name of the currently selected option list is displayed in the banner of the BOOT_OPTIONS configuration menu, shown in Example 4.1. The configuration menu displays only those commands that are available with the type of list you have selected. The default selection option list when you first execute the command procedure is the Boot (Device) Options List.

To change the selected option list, enter one of the following:

B or BOOT for the Boot (Device) Options list

D or DUMP for the Dump Device List

G or DEBUG for the Debug Device List

4.9.3. Using BOOT_OPTIONS Configuration Menu Options

The following sections show how to use BOOT_OPTIONS Configuration Menu options to perform these operations:

  • Add an entry to the Boot (Device) Options list

  • Display the Boot (Device) Options list

  • Remove an entry from an options list

  • Change the position of an entry on an options list

  • Validate an entry of the Boot (Device) Options list

  • Modifying the timeout period on the Boot (Device) Options list

  • Add an entry to the Dump Device Options list

As the list indicates, you can use some operations for more than one option list; others apply to only one; and, in the case of Adding an entry, the instructions for adding an entry to the Boot (Device) Options list are different from adding an entry to the Dump Device Options list.

4.9.3.1. Adding an Entry to the Boot (Device) Options List

Select 1 on the default Boot Options Configuration Menu (see Example 4.1) to add an entry to the Boot (Device) Options list.

This list requires several inputs to add an entry to the Boot (Device) Options list. Table 4.5 indicates the inputs that are required.

Table 4.5. Required Inputs to Add an Entry to the Boot (Device) Options List
OptionInputDescription
Position#Hex position of the entry to be added to the list. The default value is 1, which places the entry at the top of the list.
?Display the current contents of the Boot (Device) Option list.
DeviceDxy#:

Device Name of the System Disk

Note

The device must fulfill the following requirements:

  • Must be a bootable OpenVMS Integrity System (I64) disk

  • Must be initially mounted prior to running the utility

?Display all available disks.
Boot Flagsx, y

OpenVMS Boot flags

The default value is NULL, which is the same as -fl 0,0.

Description“any string”

String description of the Boot (Device) entry The default value is the device name string.

For a Fibre device, the Port Name and WWID of the target Fibre disk are appended at the end of the Description string.

For a SCSI device, the Port Name of the SCSI disk is appended at the end of the Description string.

For a multipath Fibre Channel device, the automatically adds all possible paths to a given device.

Sample output for adding an entry to the Boot (Device) Options list is in Example 4.2.

Example 4.2. Output from Adding an Entry to the Boot (Device) Options List
Enter the device name (Enter “?” for a list of devices): $1$DGA1
Enter the desired position number (1,2,3,,,) of the entry.
To display the Boot Options list, enter “?” and press Return.
Position [1]:
Enter the value for VMS_FLAGS in the form n,n.
VMS_FLAGS [NONE}:
Enter a short description (do not include quotation marks).
Descrition [“$1$DGA1”]:
efi$bcfg: $1!dga1: {Boot0002) Option successfully added
efi$bcfg: $1$dga1: (Boot0003) Option successfully added
efi$bcfg: $1$dga1: (Boot0004) Option successfully added

4.9.3.2. Displaying the Boot (Device) Options List

Select 2 on the default Boot Options Configuration Menu (see Example 4.1) to display entries on the Boot (Device) Options list. You can do one of the following:

  • Display all entries

  • Enter the number of entry you want to display

  • Enter the device name of the entries you want to display

You can select one of these options on any one of the options. Depending on which type of options list you have selected, the system displays one of the following:

  • The Boot (Device) Option list displays the entry number, the device name, the PCI address, the characteristics of the device, the string description of the entry, and the optional OpenVMS boot flags.

  • The Dump and Debug Device Options List displays the entry number, the device name, the PCI address, and the characteristics of the device.

Sample output from displaying entries in the Boot (Device) Options list is in Example 4.3.

Example 4.3. Output from Displaying Entries in the Boot (Device) Options List
To display all entries in the Boot Options list, press Return,
To display specific entries, enter the entry number or device name.
(Enter "?" for a list of devices):
EFI Boot Options list: Timeout = 10 secs.
-----------------------------------------------------------------------
01. $1$DGA1 PCI(0|60|1|1) Fibre(50001FE10011B158,LunE000000000000)
"OpenVMS V8.2 FGD0.5000-1FE1-0011-B158" OPT -fl 0,0
02. $1$DGA1 PCI(0|60|1|0) Fibre(50001FE10011B15C,LunE000000000000)
"OpenVMS V8.2 FGC0.5000-1FE1-0011-B15C" OPT -fl 0,0
03. $1$DGA1 PCI(0|40|1|1) Fibre(50001FE10011B15D,LunE000000000000)
"OpenVMS V8.2 FGB0.5000-1FE1-0011-B15D" OPT -fl 0,0
04. VenHw(d65a6b8c-71e5-4df0-d2f009a9) "EFI Shell [Built-in]"
-----------------------------------------------------------------------
4 entries found.

4.9.3.3. Removing an Entry from an Options List

Select 3 on the default Boot Options Configuration Menu (see Example 4.1) to remove entries on the one of the options lists. You can do either of the following:

  • • Remove all entries from the options list

    If you decide to remove all entries, the Options list creates an entry for the EFI Shell.

  • Enter the number of the entry you want to remove

    If you select an entry for removal, the Options list displays the selected entry and asks that you confirm a removal before it proceeds.

Sample output from removing an entry from the Boot (Device) Options list is in Example 4.4.

Example 4.4. Sample Output from Removing an Entry from the Boot (Device) Options List
Enter the entry number to delete.
To clear the Boot Options list, enter "ALL".
(Enter "?" to display Boot Options list): 1
EFI Boot Options list: Timeout = 10 secs.
-----------------------------------------------------------------------
01. $1$DGA1 PCI(0|60|1|1) Fibre(50001FE10011B158,LunE000000000000)
"OpenVMS V8.2 FGD0.5000-1FE1-0011-B158" OPT -fl 0,0
-----------------------------------------------------------------------
1 entries found.
Do you really want to delete this option? (Yes/No) y
efi$bcfg: Entry 5 Boot0005 removed.

4.9.3.4. Changing the Position of an Entry on an Options List

Select 4 on the default Boot Options Configuration Menu (see Example 4.1) to change the position of entries on one of the options lists.

The system prompts you to enter the number of the entry you want to move. You can enter either that entry number or "?" to display the list of options. You are then asked to enter the destination number of the entry you want to move.

Sample output of moving entry 4 to position 1 from the Boot Options list is in Example 4.5. (You can also change the position of entries on the Dump and Debug Options lists as well.) In the example, Entry 4 becomes the top-most selection on the Boot (Device) Options List.

Example 4.5. Moving an Entry on the Boot (Device) Options List
Enter the entry number to move.
(Enter "?" to display the Boot Options list): 2
Enter the position to which this entry will be moved: 1
efi$bcfg: Option moved from 2 to 1

4.9.3.5. Validating Entries on the Boot (Device) Options List

This option is available only for the Boot (Device) Options list (see Example 4.1).

This option allows you to verify that the entries on the Boot (Device) Options list are acceptable. You would usually do this if you wanted to re-use an entry after an OpenVMS installation or upgrade, or, under certain circumstances, when the Disk Partition Table has changed.

Select 5 on the Boot Options Configuration Menu (see Example 4.1) to validate the entries on the Boot (Device) Option list. Selecting this option also corrects problems when necessary. You can perform any of the following operations:

  • Validate all entries.

  • Enter the number of entry you want to validate.

  • Enter the device name of the entries you want to validate.

After the validation operation, boot entries that have been validated display the following message on the console:

efi$bcfg: Option Validated. Success.

If the utility determines that a boot entry needs to be corrected, it automatically updates the boot entry to become valid.

Sample output of validating entries in the Boot (Device) Options list is in Example 4.6.

Example 4.6. Validating All Entries in the Boot (Device) Options List
To validate all entries in the Boot Options list, press Return.
To validate specific entries, enter the entry number or device name.
(Enter "?" to display Boot Options list): Return
Do you really want to validate all list entries? (Yes/No) Yes
Validate EFI Boot Options list: Timeout = 100 secs.
-----------------------------------------------------------------------
01. $1$DGA1 PCI(0|60|1|1) Fibre(50001FE10011B158,LunE000000000000)
"OpenVMS V8.2 FGD0.5000-1FE1-0011-B158" OPT -fl 0,0
efi$bcfg: Option Validated. Success.
02. $1$DGA1 PCI(0|60|1|0) Fibre(50001FE10011B15C,LunE000000000000)
"OpenVMS V8.2 FGC0.5000-1FE1-0011-B15C" OPT -fl 0,0
efi$bcfg: Option Validated. Success.
03. $1$DGA1 PCI(0|40|1|1) Fibre(50001FE10011B15D,LunE000000000000)
OpenVMS V8.2 FGB0.5000-1FE1-0011-B15D" OPT -fl 0,0
efi$bcfg: Option Validated. Success.
04. VenHw(d65a6b8c-71e5-4df0-d2f009a9) "EFI Shell [Built-in]"
efi$bcfg: Option Validated. Success.
05. DQA0 PCI(0|0|2|0) ATA(Primary,Master) "DVD-ROM "
efi$bcfg: Option Validated. Success.
06. EWA0 PCI(0|20|2|0) Mac(00306e3967a5) "GigB Ethernet "
efi$bcfg: Option Validated. Success.
07. DKB0 PCI(0|20|1|1) Scsi(Pun0,Lun0) "dkb0: PKB0.0"
efi$bcfg: Option Failed. Fixing Boot Entry automatically.
efi$bcfg: Boot0007 removed 7
efi$bcfg: DKB0 PCI(0|20|1|1) Scsi(Pun0,Lun0) (Boot0007) Option
successfully added
-----------------------------------------------------------------------
7 entries validated.

In this example, entry 07 failed and a Boot Entry correction was performed.

4.9.3.6. Modifying the Timeout Period

This option is available only for the Boot (Device) Options list (see Example 4.1).

The TIMEOUT option allows users to modify the timeout period, in seconds, before the EFI Boot Manager tries to boot each entry on the Boot (Device) Options List. A value of 0 disables the timer.

Select 6 (Modify Boot Options TIMEOUT setting) on the BOOT_OPTIONS main Configuration Manual to modify the timeout.

Sample output for modifying the timeout period to be 20 seconds is in Example 4.7.

Example 4.7. Modify the Timeout Period in the Boot (Device) Options List
Enter your choice: 6
efi$bcfg: Boot Timeout period is 10 secs
Would you like to modify the Timeout value? (Yes/No) [NO] Y
Please enter the Timeout value in seconds: 20
efi$bcfg: Boot Timeout period is 20 secs

4.9.3.7. Adding an Entry to the Dump Device Options List

Enter D for DUMP on the default Boot Options Configuration Menu (see Example 4.1) to select the Dump Device Options list. The system then displays the Dump Device Options Menu.

The instructions for adding the Dump Device Options List is discussed further in Chapter 2 of VSI OpenVMS System Manager’s Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

Chapter 5. Customizing the Operating System

After you install the operating system, you can customize it for site-specific requirements.

Information Provided in This Chapter

This chapter describes the following tasks:

Task

Section

Adding and deleting optional files

Section 5.1

Modifying site-specific startup command procedures

Section 5.2

Modifying login command procedures

Section 5.3

Customizing startup databases

Section 5.4

?Registering images that have system version dependencies

Section 5.5

Customizing the Help Message database

Section 5.6

Customizing Mail

Section 5.7

Setting up the Multipurpose Internet Mail Extension (MIME) utility

Section 5.8

Saving your customization

Section 5.9

This chapter explains the following concepts:

Concept

Section

Site-specific startup command procedures

Section 5.2.1

The order of startup events

Section 5.2.2

Startup databases

Section 5.4.1

The layered product startup database

Section 5.4.2

5.1. Adding and Deleting Optional Files

OpenVMS lets you customize the size of the operating system by deleting or adding optional system files, including support for DECwindows. This is particularly valuable for small systems or systems with limited disk space.

For example, if your system is a MicroVAX II computer with an RD54 system disk and you will not use system programming features such as the Delta/XDelta Debugger (DELTA/XDELTA) or the System Dump Analyzer utility (SDA), you might remove these files from the system disk.

Depending on the system you are using, you can add or delete files in one of the following ways:
  • On VAX systems, you can use the OpenVMS Tailoring utilities, VMSTAILOR and DECW$TAILOR:
    • VMSTAILOR – applies to optional system files

    • DECW$TAILOR – applies to support for DECwindows

    Delete files from and add files to the system disk by identifying classes and subclasses of operating system files that you want to add or delete. You might delete or add an entire class or selected subclasses of files within a class.

    If you delete files, you can add them again at any time using VMSTAILOR or DECW$TAILOR and your operating system distribution media.

    Refer to the Installation and Upgrade Manual for more information about VMSTAILOR and DECW$TAILOR.

  • On Alpha and I64 systems, you can use the POLYCENTER Software Installation utility to add or delete optional system files. Add or delete files by selecting or deselecting options and suboptions.

    To invoke the POLYCENTER Software Installation utility for this purpose, you can use either of the following methods:
    • Use the DCL command PRODUCT RECONFIGURE.

    • Use the DECwindows Motif interface from the POLYCENTER Software Installation utility and select the Reconfigure option on the Mode menu.

    For more information about using the POLYCENTER Software Installation utility, see Section 3.6.

5.2. Modifying Site-Specific Startup Command Procedures

An important part of customizing your system is to create or modify site-specific startup command procedures. Adding commands to these procedures ensures that the commands are executed each time the system reboots.

5.2.1. Understanding Site-Specific Startup Command Procedures

You should understand the following terms:

Term

Definition

Startup command procedure

A command procedure that executes when the system starts up.

Site-independent startup command procedure

A startup command procedure that is required for and provided with all OpenVMS systems, regardless of site-specific requirements. This procedure is named SYS$SYSTEM:STARTUP.COM. Do not modify this procedure.

When your system boots, it automatically executes STARTUP.COM. For more information, see Section 4.1.4.

Site-specific startup command procedures

Startup command procedures that you can modify to perform operations specific to your site. Use any text editor to add or modify commands in these procedures.

STARTUP.COM executes several site-specific startup command procedures that VSI provides. These procedures are listed in Table 5.1.

You can also create your own procedures and execute them from SYSTARTUP_VMS.COM.

Table 5.1 lists and describes the site-specific startup command procedures provided by VSI, in the order in which they execute. These procedures are located in the system directory with the logical name SYS$STARTUP.
Table 5.1. Site-Specific Startup Command Procedures

Order

Command Procedure

Function

1

SYCONFIG.COM

A file to which you add commands for site-specific device configuration. For more information, see Section 5.2.4.

2

SYLOGICALS.COM

A file to which you add commands to define your site-specific system logical names. For more information, see Section 5.2.5.

3

SYPAGSWPFILES.COM

A file to which you add commands to install page and swap files (other than the primary page and swap files in SYS$SYSTEM, which are installed automatically).For more information, see Section 5.2.3.

4

SYSECURITY.COM

A file to which you add commands to define the location of security auditing and security archive files before starting the security auditing server. For more information, see Section 5.2.6.

5

SYSTARTUP_VMS.COM

A general-purpose command procedure to which you add commands to perform miscellaneous operations for setting up your site. For example, you might mount public disks in SYSTARTUP_VMS.COM. For more information, see Section 5.2.7.

5.2.1.1. Using Template Files

Your distribution kit provides two versions of each site-specific command procedure in the directory SYS$MANAGER:
  • An executable version with the file type .COM (for example, SYS$MANAGER:SYCONFIG.COM). The system executes files with the file type .COM; you can edit .COM files (except for STARTUP.COM) to meet your site-specific needs.

  • A backup version with the file type .TEMPLATE (for example, SYS$MANAGER:SYCONFIG.TEMPLATE).


Note

Do not modify or delete the VSI-supplied template command files with the .TEMPLATE file type. The VMSKITBLD.COM procedure uses these files to create a new system disk. If you must use the .TEMPLATE version of the file because your .COM version is damaged, copy the .TEMPLATE file to a file with the .COM file type, and edit the copy.

5.2.1.2. Rules for Modifying Startup Command Procedures

When modifying site-specific startup command procedures, be sure to follow these rules:
  • Conform to the rules of command procedures, as described in the VSI OpenVMS User's Manual.

  • Keep the files in the SYS$MANAGER directory.

  • Keep the file names given to the command procedures.

  • Modify only the executable version of the files (with the file type .COM), not the template version (with the file type .TEMPLATE).

  • Do not modify the site-independent startup command procedure STARTUP.COM.

  • Before modifying command procedures, understand the order of startup events. For information, see Section 5.2.2.


Caution

The startup procedures provided by VSI should always work. However, if you introduce an error in the startup or login procedures, you can accidentally lock yourself out of the system. Section 4.4.2 describes a boot procedure you can use in such an emergency.

5.2.2. Understanding the Order of Startup Events

Before modifying the site-specific startup command procedures, you should understand the order of system startup events.

A database file named VMS$PHASES.DAT determines the order of the phases of the startup procedure. It is a sequential list of the phases that STARTUP.COM starts. It includes a series of four basic phases (INITIAL, CONFIGURE, DEVICE, and BASEENVIRON) that start the operating system, followed by a series of phases for layered products.

Caution

Do not modify VMS$PHASES.DAT. To start up correctly, the system requires that the contents of this file remain intact.

At startup, a system performs tasks in the following order:
  1. Starts the CLUSTER_SERVER process.

  2. Defines logical names needed for basic operations, and installs images listed in SYS$MANAGER:VMSIMAGES.DAT.

  3. Executes SYCONFIG.COM.

  4. Adds any new drivers by executing one of the following commands:
    • On VAX systems, the SYSGEN command AUTOCONFIGURE ALL. This command automatically configures the device driver database, locates all standard devices attached to the system, and loads and connects their device drivers.

    • On Alpha and I64 systems, the SYSMAN command IO AUTOCONFIGURE. This command automatically configures the device driver database, locates all standard devices attached to the system, and loads and connects their device drivers.

    If the symbol STARTUP$AUTOCONFIGURE_ALL is defined as 0 or FALSE by SYS$MANAGER:SYCONFIG.COM, this step is not performed.

  5. Installs the primary swap file, if the file is present.

  6. Starts the CONFIGURE process (swappable). If the system parameter NOAUTOCONFIG is set to 1, the CONFIGURE process is not started. If the symbol STARTUP$AUTOCONFIGURE_ALL is defined as 0 or FALSE by SYS$MANAGER:SYCONFIG.COM, this step is not performed.

  7. Executes SYLOGICALS.COM. At this point, all devices have been made available through the AUTOCONFIGURE ALL command (step 4) or will be made available by the CONFIGURE process (started in step 6).

  8. If the system is a satellite node in a VAX cluster or an OpenVMS Cluster environment, executes SATELLITE_PAGE.COM to install page and swap files on a local disk. SATELLITE_PAGE.COM is created when you execute the CLUSTER_CONFIG.COM procedure.

  9. Executes SYPAGSWPFILES.COM.

  10. Performs the following steps in no specified order:
    • Installs required images

    • Starts various operating system processes (OPCOM, CACHE_SERVER, ERRFMT, JOBCTL)

    • Executes SYSECURITY.COM and starts the AUDIT_SERVER process

    • On VAX systems, starts the security server, SECURITY_SERVER, which manages the proxy database and intrusion database

    • Starts LMF (License Management Facility) and loads all appropriate Product Authorization Keys (PAKs) from the LMF database

  11. Performs the following steps in no specified order:
    • Enables operator consoles and the operator log files

    • Starts the SMISERVER process


Note

The order of events within system startup might change in future releases of the operating system.

5.2.3. Modifying SYPAGSWPFILES.COM to Install Page and Swap Files

When the system boots, it automatically installs the primary page and swap files, if they are present in the SYS$SYSTEM directory. If the page and swap files are not in SYS$SYSTEM, or if secondary page and swap files are located on a disk other than the system disk, you must install these files each time the system boots. To install these files, add commands to SYPAGSWPFILES.COM.

Before performing this task, you should understand page and swap files and why you might want to move them. For more information, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

The SYPAGSWPFILES.COM file can also include commands other than INSTALL commands, such as SYSGEN CREATE commands and the DCL commands INITIALIZE and MOUNT, to set up the page and swap files. Note that, at the time STARTUP.COM invokes SYPAGSWPFILES.COM, only the system disk is mounted. Therefore, you might need to add MOUNT commands to SYPAGSWPFILES.COM to mount the disks that hold the page and swap files.

The system must have installed at least one page file before SYPAGSWPFILES.COM exits. Otherwise, STARTUP.COM displays the following error message:
%STARTUP-E-NOPAGFIL, no page files have been successfully installed.

Caution

If a system dump file with the name SYSDUMP.DMP does not exist in the SYS$SPECIFIC:[SYSEXE] directory, the primary page file PAGEFILE.SYS must exist in SYS$SPECIFIC:[SYSEXE]PAGEFILE.SYS for writing crash dumps. If neither SYSDUMP.DMP nor PAGEFILE.SYS is located in SYS$SPECIFIC:[SYSEXE], no crash dump file is produced.

You can also use SATELLITE_PAGE.COM to install page and swap files on a satellite node's local disk. SATELLITE_PAGE.COM is created when you run CLUSTER_CONFIG.COM. For more information about installing page and swap files on a satellite node's local disk, refer to VSI OpenVMS Cluster Systems Manual.

How to Perform This Task

  1. Enter SYSGEN CREATE commands in the following format to create secondary system files in the desired locations:
    CREATE file-spec/SIZE=block-count
    For example:
    SYSGEN> CREATE DUA2:[PAGE_SWAP]PAGEFILE_1.SYS/SIZE=100000
    SYSGEN> CREATE DUA2:[PAGE_SWAP]SWAPFILE_1.SYS/SIZE=100000

    The CREATE command creates or extends files that can be used as a page, swap, or dump file. You create these files only once.

    For more information about creating page and swap files, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems. For more information about the SYSGEN command CREATE, refer to the SYSGEN section of the VSI OpenVMS System Management Utilities Reference Manual.

  2. Invoke any editor to edit SYS$MANAGER:SYPAGSWPFILES.COM.

  3. If necessary, add a MOUNT command to mount the disk or disks that are to hold the secondary page and swap files. Disks other than the system disk are not yet mounted at the time SYPAGSWPFILES.COM is invoked. For information about the MOUNT command, refer to the MOUNT section of the VSI OpenVMS System Management Utilities Reference Manual.

  4. Add the following command to make it easier to invoke SYSGEN:
    $ SYSGEN := $SYSGEN
  5. Add commands in the following format to SYPAGSWPFILES.COM to install the secondary files each time the system boots.

    For page files, use the following format:
    SYSGEN INSTALL file-spec /PAGEFILE
    For swap files, use the following format:
    SYSGEN INSTALL file-spec /SWAPFILE

    The INSTALL command activates secondary page and swap files. Page and swap files not located in SYS$SYSTEM must be installed each time the system boots.

Example

The following commands in SYPAGSWPFILES.COM install secondary page and swap files on the device DUA10: with the logical name PAGE_SWAP:
$ MOUNT/SYSTEM/NOASSIST DUA10: SYS2 PAGE_SWAP
$ SYSGEN := $SYSGEN
$ SYSGEN INSTALL PAGE_SWAP:[SYSTEM]PAGEFILE1.SYS/PAGEFILE
$ if $status then write sys$output "Installed page file PAGEFILE1.SYS"
$ SYSGEN INSTALL PAGE_SWAP:[SYSTEM]SWAPFILE1.SYS/SWAPFILE
$ if $status then write sys$output "Installed swap file swapfile1.sys"

5.2.4. Modifying SYCONFIG.COM to Configure Devices

You can add commands to SYCONFIG.COM to perform site-specific device configuration, including connecting nonstandard devices and suppressing autoconfiguration.

5.2.4.1. Connecting Nonstandard Devices

Standard devices are automatically connected and configured by STARTUP.COM each time the system boots. Nonstandard devices (devices not supplied by VSI) are not automatically connected and configured; you must connect and configure these devices manually by entering certain commands. To execute these commands each time the system starts up, add the commands to SYCONFIG.COM.

On VAX systems, add SYSGEN CONNECT commands. For more information about connecting devices, see Section 8.5. For more information about the SYSGEN CONNECT command, refer to the SYSGEN section of the VSI OpenVMS System Management Utilities Reference Manual.

On Alpha and I64 systems, add SYSMAN IO CONNECT commands. For more information about connecting devices, see Section 8.5. For more information about the SYSMAN IO CONNECT command, refer to the SYSMAN section of the VSI OpenVMS System Management Utilities Reference Manual.

Example
To connect a nonstandard device called the QQ device, add the following commands to SYCONFIG.COM:
$ SYSGEN := $SYSGEN
$ SYSGEN CONNECT QQA0

5.2.4.2. Suppressing Autoconfiguration of Devices

You might want to suppress autoconfiguration for various reasons, including the following ones:
  • To customize the order in which you configure devices

  • To troubleshoot booting problems

  • To allow Small Computer System Interface (SCSI) based workstations to use devices on another workstation's SCSI bus without causing conflicts during boot time

You can define a symbol in SYCONFIG.COM to suppress autoconfiguration. For more information, see Section 8.5.3.

5.2.5. Modifying SYLOGICALS.COM to Define Systemwide Logical Names

A systemwide logical name applies to the entire system. It is defined in the system logical name table and can be used by any process in the system. A clusterwide system logical name applies to every node in the cluster at a system level. It is defined in the clusterwide system logical name table of every node and can be used by any process in the system.

In general, system managers edit the SYLOGICALS.COM command procedure to define site-specific logical names that take effect at system startup. However, this is not the appropriate command procedure for defining clusterwide logical names, which is, rather, SYSTARTUP_VMS.COM. Refer to "Preparing a Shared Environment" in VSI OpenVMS Cluster Systems Manual for more information.

As supplied by VSI, SYLOGICALS.COM contains commands that assign systemwide logical names on a MicroVAX system that is not in an OpenVMS Cluster environment. If your system is not a standalone MicroVAX system, you can ignore the procedure at the beginning of the template file and add systemwide logical name assignments to the end of the file.

You can add commands to create your own site-specific systemwide logical names. In addition, if you want to change default definitions for the following system logical names, you can include the definitions in SYLOGICALS.COM. Table 5.2 lists some commonly defined logical names.
Table 5.2. Commonly Defined System Logical Names

Logical Name

For More Information

CLUE$DOSD_DEVICE?

VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems

LMF$LICENSE

VSI OpenVMS License Management Utility Guide

MAIL$SYSTEM_FLAGS

Section 5.7

NETNODE_REMOTE

VSI OpenVMS DECnet Networking Manual

NETPROXY

VSI OpenVMS Guide to System Security

NET$PROXY

VSI OpenVMS Guide to System Security

QMAN$MASTER

Section 13.3

RIGHTSLIST

VSI OpenVMS Guide to System Security

SYS$ERRORLOG

VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems

SYS$MONITOR

VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems

SYSUAF

VSI OpenVMS Guide to System Security

VMSMAIL_PROFILE

VSI OpenVMS User's Manual

VSI recommends that you define logical names for system components (for example, public disks and directories) in executive mode, using the /EXECUTIVE_MODE qualifier with the ASSIGN or DEFINE command. This type of logical name, known as a trusted logical name, is available during system operations such as the activation of privileged mode images (LOGINOUT, Mail, and so on).

For detailed information about logical name assignments and the privilege modes (executive, kernel, supervisor, and user), refer to the VSI OpenVMS User's Manual.

How to Perform This Task

  1. Invoke any editor to edit the file SYS$MANAGER:SYLOGICALS.COM.

  2. Add logical name definitions in the following format to the end of the file, immediately preceding the EXIT command:
    DEFINE/SYSTEM/EXECUTIVE/NOLOG logical-name equivalence-name
    For example:
    DEFINE/SYSTEM/EXECUTIVE/NOLOG FINANCE_DISK DRAC$DRA2:

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

  3. Exit the editor to create a new version of the file. The highest version will automatically be invoked by STARTUP.COM each time the system boots.

Example

$ DEFINE/SYSTEM/EXECUTIVE/NOLOG FINANCE_DISK DRAC$DRA2:
$ DEFINE/SYSTEM/EXECUTIVE/NOLOG SYSDSK SYS$SYSDEVICE:

In this example, any user on the system (and any program running on the system) could use the name FINANCE_DISK (the logical name) in place of DRAC$DRA2: (the physical device name). Similarly, you can refer to the system disk (SYS$SYSDEVICE:) as SYSDSK.

5.2.6. Modifying SYSECURITY.COM to Set Up Security Auditing

SYSECURITY.COM runs prior to starting the security audit server process. You can add commands to this file to mount or define any disks that you want to hold security auditing log files or local security archive files. For more information about security auditing, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

Ordinarily, the system turns on auditing in VMS$LPBEGIN just before SYSTARTUP_VMS.COM executes. However, you can change this behavior by redefining the logical name SYS$AUDIT_SERVER_INHIBIT.

To inhibit the automatic startup of auditing, edit the SYS$MANAGER:SYLOGICALS.COM command procedure to add the following line:
$ DEFINE/SYSTEM/EXECUTIVE SYS$AUDIT_SERVER_INHIBIT YES
Then you can initiate auditing during another phase of system startup, perhaps at the end of SYSTARTUP_VMS.COM, by editing the command file to add the following line:
$ SET AUDIT/SERVER=INITIATE

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

5.2.7. Modifying SYSTARTUP_VMS.COM to Perform General Operations

To perform any site-specific command not performed by another startup command procedure, you can add or modify commands in the general-purpose, site-specific startup command procedure, SYSTARTUP_VMS.COM.

VSI recommends that you edit this procedure to modify or add commands that perform tasks such as the following ones:

Task

For More Information

Mounting public disks

Section 5.2.7.1

Setting the characteristics of terminals and printer devices

Section 5.2.7.3

Starting queues and enabling autostart for queues

Section 5.2.7.4

Installing known images

Section 5.2.7.5

?Installing resident images

Section 5.2.7.6

Setting up the OpenVMS InfoServer Client software

Section 5.2.7.7

Running the System Dump Analyzer

Section 5.2.7.8

Purging the operator's log file

Section 5.2.7.9

Submitting batch jobs that are run at system startup time

Section 5.2.7.10

Creating systemwide announcements

Section 5.2.7.11

Starting up the LAT protocol software

Section 5.2.7.12

Starting a DECnet or TCP/IP network

Section 5.2.7.13

Starting up the DIBOL Message Manager

Section 5.2.7.14

Defining the number of interactive users

Section 5.2.7.15

How to Perform This Task

To modify SYSTARTUP_VMS.COM, perform the following steps:
  1. Invoke any editor to edit the file.

  2. To prevent the command procedure from exiting if it invokes an error, include the DCL command SET NOON at the beginning of the file. This command disables error checking after the execution of each command in the procedure. For more information about error checking, refer to the VSI OpenVMS User's Manual.

  3. Add commands to perform site-specific operations. Sections 5.2.7.1 to 5.2.7.15 describe operations that are typically performed by this command procedure.

  4. Exit the editor to create a new version of the file. The highest version will automatically be invoked by STARTUP.COM each time the system boots.

5.2.7.1. Mounting Public Disks

A public volume is a disk that any process on the system can access. To make disks available for public use, you must perform the following tasks:
  • Physically load and spin up the disk.

  • If the disk is new, initialize it.

  • Mount the disk for systemwide access using the DCL command MOUNT. (Using the MOUNT command for the system disk is not necessary – the system disk is already mounted when the system starts.)

How to Perform This Task
Add MOUNT commands in the following format to the command procedure:
MOUNT/SYSTEM device-name: volume_label logical_name
where:
  • device-name is the physical device name (including a colon immediately after the device name). For information about physical device names, see Section 8.1.

  • volume_label is an alphanumeric identification that you assign with the INITIALIZE command.

  • logical_name is the logical name that you want to assign to the device. Consider the advantages of using logical volume names to conceal the physical device names. If you and the users consistently use the logical volume name, it is not necessary to know on which physical drive the volume is mounted. Thus, you can avoid including physical device names in programs and command procedures.

The /SYSTEM qualifier makes the disk available for systemwide access.

Note that, by default, the system creates the following logical name when you use the MOUNT command:
DISK$volume_label

In many cases, using the default logical name will meet your needs.

When mounting disks in a startup command procedure, do not specify the /CLUSTER qualifier, even in a VAXcluster or an OpenVMS Cluster environment. Each node executes its own startup command procedure, so each node mounts disks for itself.

Note

When SYSTARTUP_VMS.COM executes (and only then), the MOUNT command default includes the /NOASSIST qualifier. This qualifier means that operator-assisted mounts are disabled. To enable this feature during SYSTARTUP_VMS.COM, specify /ASSIST with each MOUNT command.

For a DSA disk, you must also insert a WAIT statement in the command procedure prior to the first MOUNT statement. The wait time is controller-dependent. If you omit a WAIT statement, the MOUNT request might fail with a no such device status. Refer to the VSI OpenVMS I/O User's Reference Manual for more information.

For more information about public volumes, see Section 9.1.4 and Section 9.5. For more information about the MOUNT command, refer to the MOUNT section of the VSI OpenVMS System Management Utilities Reference Manual.

5.2.7.2. Mounting Disks That Must Be Available Early in Startup

If you have any disks that must be mounted early in startup, you can add MOUNT commands to SYCONFIG.COM. For example, your site might require that certain files be available before SYSTARTUP_VMS.COM executes. For more information about SYCONFIG.COM, see Section 5.2.4.

5.2.7.3. Setting Terminal and Printer Characteristics

To establish the device characteristics of the terminals and printers on the system, use a series of SET commands in your startup command procedure. For more information about the commands you use to set up devices, see Section 8.7.1 and Section 8.9.1.

If your configuration is simple, you can add the commands to SYSTARTUP_VMS.COM. If your configuration requires a large number of commands, create a separate command procedure (for example, DEVICE_SETUP.COM) and execute it from SYSTARTUP_VMS.COM. When the device setup command procedure finishes executing, control returns to SYSTARTUP_VMS.COM.

5.2.7.4. Starting Queues and Enabling Autostart for Queues

You should add commands to SYSTARTUP_VMS.COM to perform the following tasks:
  • Enable autostart for queues

  • Start non-autostart execution queues

If your configuration is simple, you can add these commands to SYSTARTUP_VMS.COM. On systems with a large number of queues, you might want to include the commands in a separate file named, for example, STARTQ.COM, and include a command in SYSTARTUP_VMS.COM to invoke the queue startup command procedure. The autostart feature simplifies queue startup, and allows you to start queues with fewer commands. VSI recommends you use autostart queues whenever possible to simplify queue startup. For more information about autostart queues, see Section 14.1.3.

For more information about starting queues and enabling autostart for queues in system startup, see Section 14.4.1.

5.2.7.5. Installing Known Images

You can install commonly used programs as known images to reduce the I/O overhead in activating those images and to assign attributes or privileges to the images. Use the Install utility (INSTALL) to install known images, which you must reinstall each time the system boots.

STARTUP.COM includes a series of INSTALL commands that install certain system programs as known images. You should include any site-specific INSTALL commands in SYSTARTUP_VMS.COM to install images each time the system boots.

For information about installing known images, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

Example
The following example shows a command sequence you might include in SYSTARTUP_VMS.COM for installing additional known images:
$ INSTALL
  ADD/OPEN/SHARED/HEADER_RESIDENT BASIC
  ADD/OPEN/SHARED/HEADER_RESIDENT FORTRAN
  EXIT

5.2.7.6. Installing Resident Images (Alpha Only)

Resident images must be installed each time the system boots. You can add commands to SYSTARTUP_VMS.COM to automatically perform this task. VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems explains how you can use the Install utility (INSTALL) to install resident images on Alpha and I64 systems.

5.2.7.7. Setting Up the OpenVMS InfoServer Client Software

If you use the InfoServer system, you will probably perform some setup tasks in SYSTARTUP_VMS.COM. For example, you can add commands to SYSTARTUP_VMS.COM to:
  • Start the InfoServer Client for OpenVMS software

  • Make remote compact discs available on your system each time the system boots

VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems explains the InfoServer system and its uses.

5.2.7.8. Running the System Dump Analyzer

You run the System Dump Analyzer utility (SDA) each time the system boots to analyze the system crash dump in case the system failed the last time it was running. You can do this by adding command lines to SYSTARTUP_VMS.COM.

For details, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems and the OpenVMS VAX System Dump Analyzer Manual and the OpenVMS Programming Environment Manual.

Caution

If you use the page file for the crash dump file, you must enter the SDA command COPY when the system reboots, to copy the dump from the page file to another file suitable for analysis.

If you fail to perform the copy operation, pages used to save the crash dump information are not released for paging, and your system might hang because it has insufficient paging space. For more information, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

Example
The following commands, executed in SYSTARTUP_VMS.COM, invoke SDA, save and analyze the crash dump, and print a listing file:
$ ANALYZE/CRASH_DUMP SYS$SYSTEM:SYSDUMP.DMP
    COPY SYS$SYSTEM:SAVEDUMP.DMP        ! Save dump file
    SET OUTPUT DISK1:SYSDUMP.LIS        ! Create listing file
    READ/EXECUTIVE                      ! Read in symbols for kernel
    SHOW CRASH                          ! Display crash information
    SHOW STACK                          ! Show current stack
    SHOW SUMMARY                        ! List all active processes
    SHOW PROCESS/PCB/PHD/REGISTERS      ! Display current process
    EXIT

5.2.7.9. Purging the Operator Log File

Each time you reboot the system, you create a new version of the operator log file, OPERATOR.LOG. You should devise a plan for regular maintenance of the versions of this file. Add the following command to SYSTARTUP_VMS.COM to purge all but the last two versions of the operator log file:
$ PURGE/KEEP=2 SYS$MANAGER:OPERATOR.LOG

For more information about the operator log file, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

5.2.7.10. Submitting Batch Jobs to Run at Startup Time

Your site might have batch jobs that you want to submit at system startup time. To submit such batch jobs, add SUBMIT commands in the following format to SYSTARTUP_VMS.COM:
$ SUBMIT [/qualifier,...] SYS$MANAGER:file-spec
Example
The following example submits a batch job to run a command procedure each time the system boots. The job is submitted at a high priority to make sure the job is scheduled before any batch jobs users might submit. If possible, submit startup batch jobs at high priority in this way before you start the batch queue.
$ SUBMIT/PRIORITY=255 SYS$MANAGER:SYSDISK_REBUILD

See Section 14.6.5.2 for information about scheduling of jobs. Refer to the VSI OpenVMS DCL Dictionary for information about the SUBMIT command.

5.2.7.11. Creating Systemwide Announcements

Usually, the last command in SYSTARTUP_VMS.COM announces to all terminals that the system is up and running:
$ REPLY/ALL/BELL "OpenVMS Operating System at ANDROMEDA, INC. ready for use."

Before the procedure exits, you can provide site-specific definitions for one or both of the logical names SYS$ANNOUNCE and SYS$WELCOME. Whenever a user logs in, the user's terminal screen displays the messages associated with SYS$ANNOUNCE and SYS$WELCOME.

Defining SYS$ANNOUNCE

You can define SYS$ANNOUNCE to print an announcement at the beginning of the login procedure for each user. The text prints immediately after a successful dial-in, Ctrl/Y, or carriage return is received. It also prints on LAT terminals when a user connects to a service using the CONNECT command. The text can contain up to 63 characters. For longer messages, precede the name of a text-containing file with an at sign(@) so that the login command procedure prints the entire file as an announcement.

For example, you could include the following command in SYSTARTUP_VMS.COM:
$ DEFINE/SYSTEM SYS$ANNOUNCE "SIRIUS OPENVMS CLUSTER AT ANDROMEDA, INC."
Or you might prefer to print a file by including the following command:
$ DEFINE/SYSTEM SYS$ANNOUNCE "@SYS$MANAGER:ANNOUNCE.TXT"
If you do not define SYS$ANNOUNCE, the system does not display an announcement.

Caution

Sites requiring moderate or high security should restrict the amount of information displayed in system announcements.

Defining SYS$WELCOME

You can define SYS$WELCOME to display a welcome message whenever a user logs in. The text prints immediately after the user enters the correct password. The text can contain up to 63 characters. For longer messages, precede the name of a text-containing file with an at sign (@) so that the login command procedure displays the entire file as a welcoming announcement.

For example, you could include a command like the following one in SYSTARTUP_VMS.COM:
$ DEFINE/SYSTEM SYS$WELCOME "Welcome to Node RANDOM"
If you prefer to display the contents of a file containing a message, you could use the following line in the procedure:
$ DEFINE/SYSTEM SYS$WELCOME "@SYS$MANAGER:WELCOME.TXT"
If you do not explicitly define SYS$WELCOME, the terminal displays a standard welcome message similar to the following one:
Welcome to OpenVMS Version n.n

You can add the DECnet node name to this message by including a translation of the logical name SYS$NODE. When DECnet starts, it creates the logical name assignment for SYS$NODE.

SYSTARTUP_VMS.COM, supplied as a template with your distribution kit, includes additional command examples for SYS$ANNOUNCE and SYS$WELCOME.

5.2.7.12. Starting Up and Customizing the LAT Protocol Software

To set up your node as a LAT service node and start the LAT protocol software on your system each time the system boots, add the SYSTARTUP_VMS.COM:
$ @SYS$STARTUP:LAT$STARTUP.COM

When the procedure executes this command, it invokes LAT$STARTUP.COM, which in turn invokes the LAT$CONFIG and LAT$SYSTARTUP command procedures. For more information, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

5.2.7.13. Starting a DECnet or TCP/IP Network

Before starting the network, you must register your DECnet license and configure your network. See VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems for information about setting up DECnet network.

If your system participates in a DECnet network, you might need to start the DECnet software each time your system boots:
  • If you are running DECnet for OpenVMS on your system, edit SYSTARTUP_VMS.COM to delete the exclamation point (!) at the beginning of the following command line:
    $ @SYS$MANAGER:STARTNET.COM
  • If you are running DECnet-Plus on your system, DECnet is started automatically each time you boot your system.

If you are running a different network, you must run the appropriate startup files for the particular network protocol. For example, three common net stack startups are:

@SYS$STARTUP:TCPIP$STARTUP

! TCP/IP SERVICES

@SYS$STARTUP:NET$STARTUP

! DECnet-Plus

@SYS$STARTUP:STARTNET

! DECnet Phase IV

5.2.7.14. Starting the DIBOL Message Manager(VAX and Alpha)

Each node that will execute DIBOL programs must contain a line in SYS$STARTUP:SYSTARTUP_VMS.COM that executes the command procedure SYS$STARTUP:DBLSTRTUP.COM. This command procedure starts the DIBOL Message Manager, used by DIBOL programs as an intermediary in passing messages.

Example
SYSTARTUP_VMS.COM should contain a line as follows:
$ @SYS$STARTUP:DBLSTRTUP.COM 

5.2.7.15. Defining the Number of Interactive Users

By default, when the system starts up, it limits to 64 the number of interactive users allowed to log in.

To change the default value for the number of interactive users that you permit to log in to your system at one time, define the symbol STARTUP$INTERACTIVE_LOGINS to be the maximum number of users in SYSTARTUP_VMS.COM as follows:
STARTUP$INTERACTIVE_LOGINS == n
where n specifies the maximum number of interactive users that can log in at one time.

Note

The number of interactive users is determined by the value authorized by your VAX, Alpha or I64 computer license. Therefore, setting the number higher than the license limit has no effect.

The maximum number of interactive users influences the service rating that the LAT software assigns to a service node. The LAT software uses a ratio of current users to maximum users in calculating a rating. An artificially high user limit results in a high service rating, indicating—erroneously—that the service node is more able to provide services. For information about LAT software, see VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

Example
$ STARTUP$INTERACTIVE_LOGINS == 200

5.3. Modifying Login Command Procedures to Customize User Environments

In addition to modifying site-specific startup command procedures, you can add commands to login command procedures to perform operations each time a user logs in.

Note that although the examples in this section are for DCL (.COM) command procedures, you can substitute other file types to denote other interfaces such as POSIX.

Command Procedure

Description

SYS$MANAGER:SYLOGIN.COM

A file to which you can add common commands to execute whenever any user logs in. If SYS$MANAGER:SYLOGIN.COM exists and the logical name SYS$SYLOGIN points to this file, SYLOGIN.COM automatically executes when any user logs in.

SYS$LOGIN:LOGIN.COM

A file to which you or users can add commands that are to be executed only when individual users log in to their accounts. If a file named LOGIN.COM exists in a user's SYS$LOGIN directory, it automatically executes when the user logs in.


Caution

If you introduce an error in login procedures, you can accidentally lock yourself out of the system. Section 4.4.2 describes a boot procedure you can use in such an emergency.

SYLOGIN.COM Procedure

As system manager, you create and maintain SYLOGIN.COM. This file is supplied on your distribution kit as a template, and contains commands that you can modify and add to as the needs of your site dictate.

The template for SYSTARTUP_VMS.COM includes the following command line that assigns the logical name SYS$SYLOGIN to SYLOGIN.COM:
$ DEFINE/SYSTEM/EXEC/NOLOG SYS$SYLOGIN SYS$MANAGER:SYLOGIN.COM

Note

If SYLOGIN.COM exits with an error, the user's login command procedure is not executed. If this occurs while the user is logging in to a captive account, the process is terminated because the system environment might not have been set up properly.

If you expect SYLOGIN.COM to cause an error, you must use either SET NOON or ON ERROR commands, and explicitly exit the command procedure with a successful status so that the user's login command procedure can be executed.

LOGIN.COM Procedures

Each user creates and maintains a personal copy of the login command procedure LOGIN.COM. This file must be in the top-level directory for the user's account. You might need to help users set up a personal copy of LOGIN.COM.

See Section 7.7.1 for a sample SYLOGIN command file and a sample LOGIN.COM procedure. Refer to the VSI OpenVMS User's Manual for sample LOGIN.COM procedures.

5.4. Customizing Startup Databases with SYSMAN

Startup databases contain information used to start up system software. For example, STARTUP.COM uses information in a startup database named STARTUP$STARTUP_VMS to start the OpenVMS operating system. It uses information in a startup database named STARTUP$STARTUP_LAYERED to start layered products. For more information about startup databases, see Section 5.4.1.

You can use the STARTUP command of the System Management utility (SYSMAN) to customize startup databases as follows:

  • Display information in any startup database.

  • Create a site-specific startup database.

  • Add, modify, or remove elements in the layered product database or site-specific database. (VSI recommends that you do not modify the OpenVMS startup database.)

The following sections describe these tasks.

Before performing these tasks, it helps to understand SYSMAN. For more information about SYSMAN, see Section 2.3.1. You should also understand startup databases, in particular, the layered product startup database. For information, see Section 5.4.1 and Section 5.4.2.

5.4.1. Understanding Startup Databases

Three startup database files are provided with the operating system, in the location defined by the logical name SYS$STARTUP:

FileDescription
VMS$PHASES.DATDetermines the order of the phases of startup in a sequential list. This file includes a series of four basic phases (INITIAL, CONFIGURE, DEVICE, and BASEENVIRON) needed to bring the operating system up to a basic working environment, followed by a series of phases for layered products. STARTUP.COM uses this list of phases for startup. Do not modify this file.
VMS$VMS.DAT

Equivalent to the logical name STARTUP$STARTUP_VMS. This file contains information about the files used to start the base operating system environment during system startup. Do not modify this file.

STARTUP$STARTUP_VMS is provided for your information only. Use SYSMAN to display information in this file. For more information, see Section 5.4.5.

VMS$LAYERED.DAT

Equivalent to the logical name STARTUP$STARTUP_LAYERED. This file contains information about files that start site-specific products and layered products. The system uses the information in this file to start layered products during system startup.

Section 5.4.2 provides more information about this file.

Use SYSMAN to modify this file so that it contains information about all the layered product startup files you want to execute on your system.

If you have site-specific software that you want to manage separately from your layered products, you can use SYSMAN to create an additional startup database.

5.4.2. Understanding the Layered Product Startup Database

The layered product startup database file (referred to by the logical name STARTUP$STARTUP_LAYERED) lists the files and command procedures that start site-specific products and layered products. It contains the following characteristics of each startup file:

  • Name of the component file to be run. The file type must be either .EXE or .COM.

  • Phase in which the component file is to run. Each phase describes a minimum environment that exists at that point in the startup process, as follows:
    1. BASEENVIRON – Startup tasks execute here. These must be performed before the site-specific startup command procedure, SYSTARTUP_VMS.COM, executes.

    2. LPBEGIN – SYSTARTUP_VMS.COM, the site-specific startup command procedure, executes here, as do any other files that prepare an environment necessary for layered products.

    3. LPMAIN – The majority of layered products execute here. This phase is the default.

    4. LPBETA – Layered products that have a dependency on previously installed products execute here.

    5. END – Products that are dependent on layered products execute here.

    Each phase must meet the prerequisites of the following phase; therefore, the order of the phases is extremely important. Components that occur in a phase cannot have dependencies on components that are in the same phase or in subsequent phases. When installing layered products using SYSMAN, be sure that all requisite components occur in a previous phase.

  • Mode (or method) by which the component file is to run. Choose one of the following modes:

    • DIRECT (the default, where the command procedure or image is executed immediately)

    • BATCH (valid only for command procedures)

    • SPAWN

  • Node restrictions for the component. This is either the node or nodes on which the component file should be run, or the node or nodes on which the component file should not be run.

  • Parameters passed to the component file for execution. You can pass up to eight parameters, using the following format:
    (P1:args,P2:args,...) 

    You can omit the parentheses if you pass only a single parameter.

5.4.3. Specifying the Current Startup Database

With SYSMAN, the current database is the one that will be the target for the SYSMAN commands.

You can display or modify STARTUP$STARTUP_LAYERED or database files that you create. You can display STARTUP$STARTUP_VMS, but you should not modify it.

By default, the layered product database is the current database. To perform commands on another database, specify it as the current database by entering the STARTUP SET DATABASE command in the following format:

STARTUP SET DATABASE database 

where database specifies the name of the database.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_LOCAL
%SYSMAN-I-NEWCOMPFIL, current component file is now STARTUP$STARTUP_LOCAL

5.4.4. Showing the Name of the Target Startup Database

To display which database is the target database, enter the STARTUP SHOW DATABASE command.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP SHOW DATABASE

5.4.5. Showing the Contents of a Startup Database

To display the contents of the current database, enter the STARTUP SHOW FILE command. You can specify various qualifiers for this command to control the amount of information displayed. For more information, see the VSI OpenVMS System Management Utilities Reference Manual.

Example

$  RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP SHOW FILE/FULL

5.4.6. Adding Startup Files to a Startup Database

To add a file to the layered product startup database, use the STARTUP ADD command. The /MODE qualifier specifies the mode of execution for the file. The /PHASE qualifier specifies the phase within system startup when the file is to be executed. For information on the layered product startup phases, see Section 5.4.2.

Do not use this command to modify STARTUP$STARTUP_VMS; this command procedure starts the operating system. The STARTUP MODIFY command requires read and write access to the startup database.

When adding layered product startup files using SYSMAN, be sure that all requisite components occur in a previous phase.

Enter the STARTUP ADD command with appropriate qualifiers. For information on the valid qualifiers, see the SYSMAN section of the VSI OpenVMS System Management Utilities Reference Manual.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP SHOW DATABASE
%SYSMAN-I-DATANAME, STARTUP database is STARTUP$STARTUP_LAYERED
SYSMAN> STARTUP ADD FILE/MODE=DIRECT/PHASE=LPMAIN FOR$LPMAIN_043_STARTUP.COM

5.4.7. Changing Information Associated with a Startup File

Once a file is included in the layered product startup database, you can modify the information associated with the file by entering the STARTUP MODIFY command. (The command requires read and write access to the startup database.)

Note

Do not use STARTUP MODIFY to modify STARTUP$STARTUP_VMS.

You can specify any of the following qualifiers to specify the information that is to be changed:

  • /MODE

  • /NAME=filespec

  • /PARAMETER=(P1:arg1, P2:arg2,...)

  • /PHASE

For information on the qualifiers for this command, see the VSI OpenVMS System Management Utilities Reference Manual.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP ADD/MODE=DIRECT/PHASE=LPMAIN FOR$LPMAIN_043_STARTUP.COM
SYSMAN> STARTUP SHOW FILE/NODE
SYSMAN> STARTUP MODIFY FILE FOR$LPMAIN_043_STARTUP.COM/NODE=ZNODE

5.4.8. Deleting a Record from a Startup Database

Deleting a record from a startup database prevents a product from starting up. To delete a record, use the STARTUP REMOVE FILE command. This command leaves the startup file intact, but the file is not used in system startup. (The command requires read and write access to the startup database.)

Note

Do not use STARTUP REMOVE FILE to modify STARTUP$STARTUP_VMS.

To delete a record from a startup database, enter a STARTUP REMOVE FILE command in the following format:

STARTUP REMOVE FILE filespec 

where filespec specifies the name of the startup file to be removed.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP SHOW FILE/FULL
SYSMAN> STARTUP REMOVE FILE FOR$LPMAIN_043_STARTUP.COM
SYSMAN> STARTUP SHOW FILE/FULL
SYSMAN> EXIT

5.4.9. Preventing a Startup File from Executing

To temporarily prevent a startup file from executing, enter the STARTUP DISABLE command. You can specify the /NODE qualifier to disable the startup file on certain nodes.

This command requires read and write access to the startup database. Do not use this command to modify STARTUP$STARTUP_VMS.

To delete a record from a startup database, enter the STARTUP DISABLE command as follows:

STARTUP DISABLE FILE filespec

where filespec specifies the name of the startup file to be disabled.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP SHOW FILE
SYSMAN> STARTUP DISABLE FILE FOR$LPMAIN_043_STARTUP.COM/NODE=ZURICH

5.4.10. Allowing a Previously Disabled Startup File to Execute

If you have disabled a startup file from executing, you can enable it again by using the STARTUP ENABLE command. You can specify the /NODE qualifier to enable the startup file on certain nodes.

This command requires read and write access to the startup database. Do not use this command to modify STARTUP$STARTUP_VMS.

To enable a previously disabled file, enter the STARTUP ENABLE FILE command in the following format:

STARTUP ENABLE FILE filespec

where filespec specifies the name of the file to be enabled.

Example

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP ENABLE FILE FOR$LPMAIN_043_STARTUP.COM/NODE=ZURICH

5.5. Registering Images that Have System Version Dependencies

Applications that run on the OpenVMS operating system sometimes depend on the internal interfaces of a previous version of the operating system. For example, an application might call system routines, reference system data cells, or system data structures. New versions of the operating system might include changes that can break applications depending on those interfaces.

Registering an image records information about the image in a file called the image registry. The image activator, INSTALL, and SYSGEN do not check the versions of images that are recorded in the image registry.

The image registry allows you to continue to run application images (including main images, shared libraries, and device drivers) that were linked on prior versions of the operating system. Use extreme care with this capability. If the image needs to use a data structure that has a changed format, then results from running the image will be unpredictable and might result in a system crash. Register an image only if you are sure that none of the referenced system routines, data cells, and data structures have changed.

The Image Registry facility allows you to register different versions of an image independently. It also allows you to deregister, analyze, and show images in the image registry.

5.5.1. Understanding System Version Dependency and the Image Registry

Applications that depend on internal interfaces are bound to a particular version of the operating system when the application is linked. Version-dependent images reference both of the following version numbers:
  • The major version number of the operating system

  • A set of component version numbers (version numbers of loadable executive images)

When you attempt to run an image, the system checks to determine if the image requires a certain version of the operating system or of system components. If the version of the running system does not match the version requirements of the image, the image fails.

The system also checks version numbers when you attempt to install an image using the Install utility (INSTALL) or connect a device driver using the System Generation utility (SYSGEN).

When you upgrade your system to a new version of the operating system, an image might fail because the new version no longer matches the image's version requirements. However, an image might continue to be compatible with the new operating system version, even if it fails the version check.

Note

In OpenVMS VAX Version 6.0, the major version number was not changed; only the version numbers for the following components were increased to reflect changes in these areas:
  • FILES_VOLUMES

  • MEMORY_MANAGEMENT

  • SECURITY

As a result, many version-dependent images built in VMS VAX Version 5. x systems (that is, images that do not reference FILES_VOLUMES, MEMORY_MANAGEMENT, or SECURITY) will run on OpenVMS Version 6.0 without registering the images. However, version-dependent images that do reference these components must be registered with the image registry, as explained in this section.

In OpenVMS VAX Version 6.1, no version numbers were changed. However, images built on VMS VAX Version 5. x systems needed to be registered if they referenced FILES_VOLUMES, MEMORY_MANAGEMENT, or SECURITY.

To continue running a compatible image, you can register the image using the Image Registry facility. You do not need to register images that are linked as part of the installation because they match the current operating system version. However, linking an image during installation does not ensure that system version dependencies do not exist. For information about changes in the current operating system version that might require you to recompile an image or change source code, see the release notes.

Caution

You must inspect and test an image carefully to avoid system crashes and data corruption. Registering an image does not necessarily make it work; registering only by passes the version checks.

5.5.2. Using the Image Registry Facility

To register an image in the image registry, run the command procedure SYS$UPDATE:REGISTER_PRIVILEGED_IMAGE.COM. Enter a command in the following format:
$ @SYS$UPDATE:REGISTER_PRIVILEGED_IMAGE keyword filename
where:

keyword

Specifies one or more of the keywords described in Table 5.3, separated by commas.

filename

Specifies the name and location of the image you want to register. The filename parameter accepts wildcard characters.


Table 5.3. REGISTER_PRIVILEGED_IMAGE.COM Keywords

Keyword

Action

ANALYZE

Displays version-dependent image names and their subsystem dependencies.

REGISTER

Registers images on the local system.

DEREGISTER

Deletes images from the registry on the local system.

SHOW

Lists the registry content. To display the complete registry content, specify a wildcard (*) for the file name.

CONFIRM

Confirms that each specified image be added to or deleted from the registry (used only with REGISTER and DEREGISTER).

TRACE

Lists each image file for verification purposes (used only with REGISTER and DEREGISTER).

HELP

Describes the supported keywords and provides examples.

If the image does not have a version dependency, the following message is displayed:
REGISTER-I-SUMMARY n images examined, n have dependencies
In this message, n is the number of images examined and the number of images that have dependencies.

Example

The following example adds the V6USRAPP image to the registry:
$ @SYS$UPDATE:REGISTER_PRIVILEGED_IMAGE REGISTER SYS$LIBRARY:V6USRAPP
%REGISTER-I-ADDED added V6USRAPP to registry

5.6. Customizing the Help Message Database

The Help Message utility (MSGHLP) allows users to quickly access online descriptions of system messages from the DCL prompt. Users with write access to VSI-supplied .MSGHLP$DATA files can customize the Help Message database in more radical ways than general users can. The following sections describe how to perform the following customization tasks:

TaskFor More Information
Accessing $STATUS values for uninstalled messagesSection 5.6.1
Creating system-level Help Message database search pathsSection 5.6.2
Deleting VSI-supplied messagesSection 5.6.3
Adding comments to VSI-supplied messagesSection 5.6.4
Changing text in VSI-supplied messagesSection 5.6.5
Adding messages to VSI-supplied database filesSection 5.6.6

Before performing these tasks, you should be familiar with the Help Message utility. For a complete description of Help Message features, basic tasks, and the HELP/MESSAGE command and qualifiers, see the OpenVMS System Messages: Companion Guide for Help Message Users. Also see that manual for a description of the files that you must manipulate to customize the Help Message database.

Note

Currently, user-supplied comments or additions to VSI-supplied .MSGHLP$DATA files are not preserved through the next upgrade. However, your own .MSGHLP$DATA files are not affected by future releases. You can reuse .MSGHLP files to insert your own messages into future VSI-supplied database files. Depending on the data format in future databases, you might also be able to reuse some .MSGHLP files to insert comments.

5.6.1. Accessing $STATUS Values for Uninstalled Messages

Any messages that are not installed as part of the OpenVMS operating system cannot be equated with a value stored in $STATUS until they are recognized by the system. When the Help Message utility attempts to translate the value stored in $STATUS or a value specified with the /STATUS qualifier, the search can fail if the value does not equate to an installed message or a message that was linked into the Help Message utility when it was originally created. You can make your system recognize such uninstalled messages. These messages include user-supplied messages, third-party messages, and messages from layered products and certain other OpenVMS facilities.

How to Perform This Task

  1. Use the Help Message qualifier /SECTION_FILE=* to include all the OpenVMS supplied message section files that have not already been linked into the main Help Message program, MSGHLP$MAIN.EXE:
    $ HELP/MESSAGE/SECTION_FILE=*

    This command generates a user-modifiable object library, SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB. Each module in this library contains a pointer to a message section .EXE file. You can use the /SECTION_FILE qualifier to insert additional modules into this library. (See the following steps.)

    Note

    This HELP/MESSAGE command produces results similar to, but entirely separate from those effected by the SET MESSAGE filespec command. The Help Message utility does not interact with the Message utility. If you want both utilities to translate the same set of message sections, you must separately code each utility to do so. It is perfectly acceptable to have each utility point to different message section files.

  2. When you use the /SECTION_FILE qualifier to create the object library or add modules to it, the MSGHLP$MESSAGE_SECTIONS.EXE file is also automatically created from all the modules in the object library and is placed in your default directory. When you finish modifying the object library, you must copy the final .EXE file to SYS$COMMON:[SYSLIB] (logical name SYS$LIBRARY).

    Thereafter, if Help Message cannot translate a status code and the SYS$LIBRARY:MSGHLP$MESSAGE_SECTION.EXE image exists, Help Message activates it and searches all message section files to which it points. The impact on Help Message search time depends upon the number of files searched.

  3. Use the following command as many times as you want to add pointer modules for any other specific message section files to SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB and MSGHLP$MESSAGE_SECTIONS.EXE:
    HELP/MESSAGE/SECTION_FILE=disk:[directory]file-name.EXE

    The default file specification is SYS$MESSAGE:.EXE.

  4. Review the contents of the resulting SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB file:
    $ LIBRARY/LIST MSGHLP$MESSAGE_SECTIONS.OLB

    The names of the modules in the .OLB file are derived from strings specified in the /SECTION_FILE qualifier.

    Help Message can search a maximum of 42 message section files. Files are searched in this order:
    • The last file activated by a SET MESSAGE command (if any).

    • The message section files that Help Message is linked with before it is shipped:

      • SYSMSG.EXE

      • SYSMGTMSG.EXE

      • CLIUTLMSG.EXE

      • PRGMSG.EXE

    • Any message section files explicitly linked with MSGHLP$MAIN.EXE or with any shareable image that MSGHLP$MAIN.EXE references.

    • Any nonduplicate message section files linked with SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.EXE.

      Message section files are searched in the order in which they are listed in the .OLB file. (Order is alphabetical.) If the total count of message section files exceeds 42, message section files listed near the end of the .OLB file might not be searched.

  5. If you want, remove any references to message section files in the .OLB file to control which 42 message section files are included in the Help Message search. You might delete a file that you rarely use earlier in the alphabet to ensure that a file later in the alphabet is among the 42 files searched. For example, to delete the NCP (Network Control Program) messages from the .OLB file, use this command:
    $ LIBRARY/DELETE=NETWRKMSG SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB

    If you delete a module from the .OLB file, you must execute the HELP/MESSAGE command with the /SECTION_FILE qualifier to generate an updated .EXE file. The qualifier argument can specify either a new file or a file that is already listed in the .OLB file.

  6. When your .OLB file reflects the message section files you want Help Message to search, copy the final .EXE file from your account to SYS$LIBRARY:.

Example

The following example demonstrates this sequence of events:

  1. Link all OpenVMS supplied message section files.

  2. Review the resulting .OLB file.

  3. Delete the VVIEFMSG module from the .OLB file.

  4. Add the file USERS:[TOOLS]NEW_MSGS.EXE to the list in the .OLB file.

  5. Review the revised contents of the .OLB file.

  6. Copy the final .EXE file from the local account to SYS$LIBRARY:.

Note that the output from the LIBRARY/LIST commands is omitted from the example.

$ HELP/MESSAGE/SECTION_FILE=*
$ LIBRARY/LIST SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB
$ LIBRARY/DELETE=VVIEFMSG SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB
$ HELP/MESSAGE/SECTION_FILE=USERS:[TOOLS]NEW_MSGS.EXE
$ LIBRARY/LIST SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB
$ COPY MSGHLP$MESSAGE_SECTIONS.EXE SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.EXE

5.6.2. Creating System-Level Database Search Paths

Help Message database files need not reside on the system disk. You can create system logical names to define one or more Help Message search paths to access multiple .MSGHLP$DATA files in different locations.

When Help Message is installed, the OpenVMS messages database file is installed by default at SYS$COMMON:[SYSHLP]MSGHLP$LIBRARY.MSGHLP$DATA. However, this file can optionally be installed on or moved to another disk. The alternate location must be pointed to by logical name MSGHLP$LIBRARY. Use this command to define the logical name:

DEFINE/SYSTEM MSGHLP$LIBRARY disk:[directory]MSGHLP$LIBRARY

By default, Help Message attempts to look up messages in the default location unless the logical name MSGHLP$LIBRARY is defined. If you do not use the default database location, include the logical name definition command in SYS$MANAGER:SYLOGICALS.COM so that the database is defined each time the system is booted.

Note

If you move MSGHLP$LIBRARY.MSGHLP$DATA to a new location after installation, be sure to set the proper protections on the file and directory so that the database cannot be accidentally deleted or modified. The protections at installation are (RWE, RWE, RE, RE) for the directory and (RWE, RWE, RWE, RE) for the file.

You and other system users can create additional .MSGHLP$DATA files, as described in the OpenVMS System Messages: Companion Guide for Help Message Users. None of the .MSGHLP$DATA files need reside on the system disk. You can add new files to a systemwide default database search path defined by MSGHLP$LIBRARY, or you can create specialized search paths to include different configurations of .MSGHLP$DATA files.

A search path definition can include individual file names or can point to one or more directories. If you specify a directory with no file name, Help Message searches all .MSGHLP$DATA files currently found in that directory. Pointing to a directory instead of individual files can minimize your bookkeeping when .MSGHLP$DATA files are added or removed.

To use system resources more efficiently, you can create different search paths for different user groups, depending on which .MSGHLP$DATA files they need to access. You can also set up different directories for different types of messages or for different user groups. For example, you could use three unique logical names to define three different search paths tailored to different user groups:

DEFINE/SYSTEM logical-name-1 file-a,file-b,file-c 
DEFINE/SYSTEM logical-name-2 file-a,directory-z 
DEFINE/SYSTEM logical-name-3 file-x,file-a,directory-y

Note

The first file you list in a search path is the default database for /INSERT and /DELETE operations that operate on that search path. By default, all other operations access all files in a search path. Specifying a directory first in a search path risks setting up a default moving target for /INSERT and /DELETE operations if files are added to or deleted from the directory.

Users can select an alternate to the system default database by specifying the /LIBRARY qualifier in the HELP/MESSAGE command. Individual users can also create their own logical name search paths at the process level.

Example

The following example defines a Help Message search path that accesses .MSGHLP$DATA database files in three locations: the VSI-supplied OpenVMS messages at USERS:[TOOLS], the user-supplied file USERS:[NEW_PROJ]OUR_MESSAGES.MSGHLP$DATA, and all .MSGHLP$DATA files in directory TEST:[TRY_ME].

$ DEFINE/SYSTEM MSGHLP$LIBRARY USERS:[TOOLS]MSGHLP$LIBRARY,-
_$ USERS:[NEW_PROJ]OUR_MESSAGES.MSGHLP$DATA,TEST:[TRY_ME]

5.6.3. Deleting VSI-supplied Messages from the Database

You can delete VSI-supplied messages from the database to conserve system resources or improve response time.

How to Perform This Task

  1. Use the /EXTRACT qualifier to create a .MSGHLP file containing the messages you want to delete from the database. (See the OpenVMS System Messages: Companion Guide for Help Message Users for a full description of how to select the contents of the .MSGHLP file.) Some examples follow.

    Use the following syntax to extract all the messages for a specified facility:
    HELP/MESSAGE/FACILITY=facility-name/EXTRACT=filename.MSGHLP 
    Use this syntax to extract one or more messages specified by the search string:
    HELP/MESSAGE/EXTRACT=filename.MSGHLP search-string 
  2. Check the contents of the resulting .MSGHLP file to be sure that it contains only the data that you want to delete from the database. Edit out any messages that you do not want to delete from the database.

  3. Use /DELETE to delete the contents of the .MSGHLP file from the database. Include /LIBRARY if the MSGHLP$LIBRARY.MSGHLP$DATA file is not the default database or if it is not the first file in the search path defined by logical name MSGHLP$LIBRARY.
    HELP/MESSAGE/DELETE=filename.MSGHLP 

    HELP/MESSAGE/DELETE=filename.MSGHLP/LIBRARY=disk:[directory]filename.MSGHLP$DATA

    Save the .MSGHLP file if you might ever want to add the deleted messages back into the database prior to the next upgrade. You can store the file on tape to conserve disk space. If you delete and then reinsert messages, these messages are treated like user-supplied messages and are displayed with change bars.

    Any VSI-supplied messages that you delete are currently reinserted into the database at the next upgrade. You can delete the messages again using a saved .MSGHLP file or you can create a new .MSGHLP file. Note that if you keep a .MSGHLP file for future deletion purposes only, you need save only the lines prefixed by 1 and 2.

  4. To save disk space, you can compress the .MSGHLP$DATA file to close up any free space created by the deletions. Use the following command sequence to compress the file:

    CONVERT disk:[directory]filename.MSGHLP$DATA disk:[directory]filename.MSGHLP$DATA 
    PURGE disk:[directory]filename.MSGHLP$DATA

Example

The following example extracts and then deletes all messages for the DDTM (DECdtm services) facility from the default database. The last two commands compress the VSI-supplied database file to conserve disk space after the deletions.

$ HELP/MESSAGE/FACILITY=DDTM/EXTRACT=DDTM.MSGHLP
$ HELP/MESSAGE/DELETE=DDTM.MSGHLP
$ CONVERT SYS$COMMON:[SYSHLP]MSGHLP$LIBRARY.MSGHLP$DATA -
_$ SYS$COMMON:[SYSHLP]MSGHLP$LIBRARY.MSGHLP$DATA
$ PURGE SYS$COMMON:[SYSHLP]MSGHLP$LIBRARY.MSGHLP$DATA

5.6.4. Adding Comments to VSI-supplied Messages

You can add comments to VSI-supplied messages documentation. Comments display with change bars immediately following the VSI-supplied description. This feature is a handy way to publicize a site-specific solution for a common problem.

Note

Currently, user-supplied comments to VSI-supplied .MSGHLP$DATA files are not preserved through the next upgrade. However, if the VSI-supplied message descriptions do not change during the upgrade, you can reuse .MSGHLP files to reinsert comments after the upgrade.

How to Perform This Task

  1. Extract the message to which you want to add a comment. The following example extracts hypothetical message NOSNO:

    $ HELP/MESSAGE/EXTRACT=NOSNO.MSGHLP NOSNO
  2. Edit the .MSGHLP file to add your comment. The .MSGHLP file format uses a unique numerical prefix to designate the message, facility, explanation, and user action sections of the message description. Add your comments at the end using a "5" prefix.
    1NOSNO, can't ski; no snow
    2XCSKI, XCSKI Program
    3Your attempt to ski failed because there is no snow.
    4Wait until there is snow and attempt the operation again.
    5If you don't want to wait, go to a location where there is
    5snow and ski there.
    5
    5Or, try ice skating instead!
    Tips for modifying files:
    • Limit your comments to 60 characters per line so that they do not exceed the terminal display area.

    • Use a "5" prefix on blank lines too.

    • Do not edit VSI-supplied data. Any such edits are ignored when the comment is added to the database.

      Section 5.6.5 describes how you can alter VSI-supplied data.

  3. Update the database by inserting the updated message:
    $ HELP/MESSAGE/INSERT=NOSNO.MSGHLP

    The comment is now displayed following the VSI-supplied message description.

Example

$ HELP/MESSAGE/EXTRACT=ACCVIO.MSGHLP ACCVIO

[Edit ACCVIO.MSGHLP to add your comment.]

$ HELP/MESSAGE/INSERT=ACCVIO.MSGHLP

5.6.5. Changing VSI-supplied Data

You cannot use the procedure described in Section 5.6.4 to alter VSI-supplied information. The recommended way to permanently change VSI-supplied information is to send your comments to the OSSG Documentation Group (see the Preface for Internet and mail addresses) or contact a VSI support representative.

The sequence described in this section allows you to modify VSI-supplied data, with the following results:

  • The VSI-supplied message is deleted from the database and your version of the message is inserted.

  • The message you modify subsequently displays with change bars to designate it as unsupported, user-supplied data.

Note

Currently, the VSI-supplied message is reinserted into the database at the next upgrade and the user-supplied text is overwritten.

How to Perform This Task

  1. Extract the message having the text or description you want to change:

    HELP/MESSAGE/EXTRACT=filename.MSGHLP search-string 
  2. Check the .MSGHLP file to ensure that your search did not pick up any messages that you do not want to change. Delete any such messages that you want to preserve out of the .MSGHLP file.

  3. Delete the VSI-supplied version of the message from the Help Message database by specifying the .MSGHLP file as input. The following command deletes all messages in the .MSGHLP file from the default .MSGHLP$DATA file:

    HELP/MESSAGE/DELETE=filename.MSGHLP
  4. Edit the .MSGHLP file to make your changes.

  5. Insert the revised message description into the Help Message database:
    HELP/MESSAGE/INSERT=filename.MSGHLP 

    Your version of the message now appears in the database with change bars to indicate that it is not a VSI-supplied message.

Example

$ HELP/MESSAGE/EXTRACT=NOFILES.MSGHLP NOFILES
$ HELP/MESSAGE/DELETE=NOFILES.MSGHLP

[Edit NOFILES.MSGHLP to change the text.]

$ HELP/MESSAGE/INSERT=NOFILES.MSGHLP

5.6.6. Adding Messages to VSI-supplied Database Files

The OpenVMS System Messages: Companion Guide for Help Message Usersdescribes how to create your own .MSGHLP$DATA files to add new messages to the Help Message database. Keeping your messages in a separate file can simplify your messages bookkeeping and ensure that your messages are preserved through future upgrades.

With write access to VSI-supplied .MSGHLP$DATA files, you can alternatively insert your own messages into the VSI-supplied MSGHLP$LIBRARY.MSGHLP$DATA file. However, messages inserted using this technique will currently be overwritten at the next upgrade. You can, however, save your input .MSGHLP files and repeat the insertion process at the next upgrade.

How to Perform This Task

  1. Create a .MSGHLP file with your message descriptions in it. (Section 5.6.4 includes an example of the .MSGHLP file format.)

  2. Specify your .MSGHLP file as input to update the VSI-supplied .MSGHLP$DATA file. Assuming that MSGHLP$LIBRARY.MSGHLP$DATA is the default, all you must enter is:

    HELP/MESSAGE/INSERT=filename.MSGHLP 

Example

$ HELP/MESSAGE/INSERT=MYMESSAGES.MSGHLP

5.7. Customizing Mail

OpenVMS contains two logical names to enable you to customize the operation of certain Mail functions on your system. This includes checking the network address format to use and sending mail directly to a user on an OpenVMS Cluster (rather than through the network) if the sender and recipient are both on the same node.

MAIL$SYSTEM_FLAGS

You customize Mail by defining the logical name MAIL$SYSTEM_FLAGS as a system and executive mode logical name. For example:
$ DEFINE/SYSTEM/EXECUTIVE_MODE MAIL$SYSTEM_FLAGS 1
The value of the logical name MAIL$SYSTEM_FLAGS is interpreted in the following ways:

Value

Meaning

1

Indicates that this node is part of a homogeneous OpenVMS Cluster system. In other words, all disks are accessible to the cluster, and a common SYSUAF file and a common mail file exist for the cluster.

When this bit is set, the system checks the node to which you are sending mail to see if it is currently in the cluster. If the node is in the cluster, the system bypasses DECnet, and the message is written directly to the recipient's mail file. (Note that the node must be up to determine whether it is part of the cluster.)

2

Directs Mail to set the OpenVMS Cluster system breakthrough flag when issuing the $BRKTHRU service to notify the recipient of new mail. This flag is used only in OpenVMS Cluster systems and, typically, only in homogeneous OpenVMS Cluster systems (in other words, flag 1 is also set).

4

Directs Mail to include the time the message was delivered in the notification message displayed on the recipient's terminal.

8

Directs Mail to use DECnet VAX address syntax when the system is running DECnet-Plus.

16

Directs Mail to use DECnet-Plus address syntax.

32Indefinitely retry reading a UAF record when the record is locked by another user. Default (bit not set) behavior is to return UAFGETERR and not retry.

For example, if MAIL$SYSTEM_FLAGS translates to 7, the system selects the first three flags. If the logical name does not translate, the default is 0, which indicates that no flags are set.

On VAX systems, if neither 8 nor 16 is in the value for MAIL$SYSTEM_FLAGS, the system checks to see whether DECnet for OpenVMS or DECnet-Plus is running on the system and operates as if the appropriate bit were set. If MAIL$SYSTEM_FLAGS accidentally specifies both DECnet and DECnet-Plus, the Mail utility defaults to DECnet-Plus.

MAIL$INTERNET_MODE

Certain network addresses can be interpreted by the Mail utility as either DECnet-Plus names or SMTP names. These ambiguous network names have the following features:
  • The address does not contain double quotation marks (")

  • The address contains an at sign (@)

  • There are no periods to the right of the at sign

You can control the default system interpretation of those names with the MAIL$INTERNET_MODE logical name.

To specify the mail address mode, define logical name MAIL$INTERNET_MODE as follows:
$ DEFINE/SYSTEM MAIL$INTERNET_MODE address_mode
You must have SYSNAM privilege or write (W) access to the system logical name table. The following table describes the values of address_mode and the effect of each value of MAIL$INTERNET_MODE.

Address Mode

Effect

HYBRID (default)

If the node component of the address contains a period (.),Mail uses SMTP address mode. If there are no periods, Mail uses DECnet address mode.

DECNET

Mail always interprets the node component of the address as a DECnet node specification.

SMTP

Mail always interprets the node component of the address as an Internet address specification. The default address mode is SMTP unless you use logical name MAIL$INTERNET_TRANSPORT to define a different transport (and therefore different address mode).

For more information about using logical names to control the use of internet address modes by the Mail utility, see the VSI OpenVMS User's Manual.

5.8. Setting Up the Multipurpose Internet Mail Extension (MIME) Utility

MIME is the standard used to attach nontext files to mail messages to send them over the Internet. The MIME utility allows users to read and compose MIME-encoded mail messages on OpenVMS systems.

Understanding the MIME Utility

With MIME, users can encode and send nontext files such as graphics or audio files encoded as plain text; however, those files are often unreadable. The MIME utility decodes MIME files sent over the Internet to their original form. MIME also allows users to create MIME-encoded files, which can be sent as mail messages using the OpenVMS Mail utility.

For more information on how users can use the MIME utility, refer to the VSI OpenVMS User's Manual.

5.8.1. Defining a Foreign Command

Your only installation work is to define a foreign command to run the utility, for example:
MIME:== $SYS$SYSTEM:MIME.EXE

You can establish systemwide defaults for displaying MIME-encoded messages by creating two files: MIME$MAILCAP.DAT and MIME$FILETYPES.DAT.

MIME$MAILCAP.DAT identifies an application to display each locally recognized content-type of incoming MIME-encoded files. MIME$FILETYPES.DAT associates a content-type with the file extension of outgoing files.

A user can override those defaults by creating these files in SYS$LOGIN. See the VSI OpenVMS User's Manual for details about those files.

5.9. Saving Your Customization

Once you have installed and customized your system, VSI recommends that you back up your system disk. To do so, follow the instructions in Section 11.17.

On VAX systems, back up the console volume (if applicable). If your computer has a console storage device, make a backup copy of your console volume in case your original becomes corrupted. The operating system provides a command procedure called CONSCOPY.COM (in the SYS$UPDATE directory), which copies your console volume to a blank one.

The procedure for backing up the console volume varies for different computers. For specific instructions on backing up the console volumes, refer to the upgrade and installation supplement for your VAX computer.

Chapter 6. Setting System Time

This chapter describes how to control system time on OpenVMS systems, describes how system time relates to Coordinated Universal Time (UTC), and tells how to ensure that local system time remains correct when local time changes, as it does for daylight saving time.

For a complete list of support time zones that are referenced by VMS services, see the VSI OpenVMS System Manager’s Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

This chapter describes the following tasks:

Task

System

Section

Setting time zone information

OpenVMS Alpha Version 7.3 and later

Open VMS I64

Section 6.2

Setting time zone information

OpenVMS Alpha before Version 7.3

OpenVMS VAX

Section 6.3

Setting time zone information

OpenVMS Cluster

Section 6.4

Controlling daylight saving time conversions

All

Section 6.5

Setting time using the Battery-Backed Watch (BBW)

OpenVMS Alpha

Open VMS I64

Section 6.6

Choosing languages, and date and time formats

OpenVMS

Section 6.7

Saving your time customizations

OpenVMS VAX

OpenVMS Alpha

Open VMS I64

Section 6.8

Using SYSMAN to manage system time

Section 6.9

6.1. Setting Correct Time Zone Information on Your System

Beginning with OpenVMS Version 7.0, VSI C RTL implements its default date/time support for programs compiled with VSI C Version 5.2 and later using a model based on Coordinated Universal Time (UTC), an international standard for measuring time of day.

Note

Even if you do not use the VSI C RTL directly, you must set correct time zone information on your system because other system utilities written in the VSI C language might require it.

6.1.1. Distributed Time Synchronization Service (DTSS)

Your system may be using Distributed Time Synchronization Service (DTSS).DTSS is provided as an option with DECnet-Plus and the Distributed Computing Environment (DCE). If you are using DTSS, you must not use the procedures described in this chapter. Instead, use the procedures supplied with DTSS to set time zone information.

6.1.2. Understanding Time-Setting Concepts

Understanding some time concepts will help you see the importance of setting correct time zone information on your system.

6.1.2.1. Coordinated Universal Time

Coordinated Universal Time (UTC) is similar in most respects to Greenwich Mean Time (GMT). Under the UTC time standard, zero hours occurs when the Greenwich Meridian is at midnight. Unlike local time, which can go backward and forward depending on daylight saving time, UTC always increases.

Local times can be up to 12 hours behind Greenwich Mean Time or 13 hours ahead of it.

Because UTC is independent of time zones, you can use UTC around the world; for example, it is 2:00 UTC at the same moment in Paris as it is in Tokyo. You can examine data that is time-stamped with UTC values in Paris and Tokyo without performing complicated conversions to deal with local time zones.

6.1.2.2. Time Zones

Time zones for geographical areas that share the same local time also share the same rule or rules for seasonal changes between standard time and daylight saving time.

6.1.2.3. Daylight Saving Time and Standard Time

Typically, you make seasonal changes to the local system time (for example, for daylight saving time and standard time). You usually adjust the local time one hour forward or backward.

6.1.2.4. Time Differential Factor

One of the steps in setting the correct time on your system is to calculate a time differential factor (TDF) for your time zone.

The TDF associates each local time zone with UTC;it is the difference between your local system time and UTC. When your system time changes to reflect a local time change between standard time and daylight saving time, the TDF must also change to compensate for the new local system time. The TDF changes in the same direction as the local time;that is, if you add an hour to the local time, you must also add an hour to the TDF. Note, however, that the UTC does not change.

The TDF value is expressed in signed (+ or -) hh:mm format. The Americas have negative TDFs, while Europe, Africa, Asia, and Australia have positive TDFs.

OpenVMS procedures calculate the normal TDFs for standard and daylight saving time (if any) for your time zone. These are presented as the default for your TDF setting. VSI recommends that you accept this default.

You can also use the map in Figure 6.1 to determine the TDF for your time zone. If you prefer, you can use the tables in Appendix B in the VSI OpenVMS System Manager's Manual to determine the standard or daylight saving time TDF for your time zone.

To use the map to determine the TDF of your time zone, follow these steps:
  1. Find your location on the map and notice the time zone band at that location.

  2. Follow the time zone band to the top of the map and note the TDF that corresponds to your time zone. For example, the TDF for California is –8:00; the TDF for Italy is +1:00.

Some time zones do not have full-hour TDFs. In these cases, find the specific value on the map itself. For example, if you live in Adelaide, Australia, your TDF is +9:30.

In a time zone with daylight saving time, the TDF for daylight saving time is typically +1:00 from the standard time. For example, if the standard time TDF is +2:00,the daylight saving time TDF is +3:00;if the standard time TDF is -7:00, the daylight saving time TDF is -6:00.

Figure 6.1. Time Differential Factor Map
Time Differential Factor Map

Note

Time zone rules are under control of each country and are subject to change for political and other reasons. Printed maps are almost inevitably out-of-date. For up-to-date information, see the following web location:
  http://aa.usno.navy.mil/AA/faq/docs/world_tzones.html

6.1.2.5. Time Zone Rules

A time zone rule is used to define the short name (usually three letters) for the time zone, the daylight saving time and standard time TDFs, and the rule for determining when changes are made between daylight saving time and standard time. The format of the time zone rules are defined in the VSI C Run-Time Library Reference Manual for OpenVMS Systems.

6.1.2.6. Setting Time Zone Information

How you set the time zone information on your system depends on the following:
  • Whether DTSS is in use

  • The version of OpenVMS

  • The architecture (VAX, Alpha, or OpenVMS Cluster)


Note

If you are using the Distributed Time Synchronization Service (DTSS), use the procedures supplied with DTSS to set time zone information. See Section 6.1.1.

If DTSS is not in use, use the following table to determine how to set time zone information.

OpenVMS Version

Architecture

See

7.3 and later

Alpha

Section 6.2

7.3 and later

VAX

Section 6.3

7.2 and earlier

VAX or Alpha

Section 6.3

All

OpenVMS Cluster Environment

Section 6.4

6.2. Setting Time Zone Information on OpenVMS Alpha Version 7.3 and Later

This section contains instructions for setting time zone information on OpenVMS Alpha Version 7.3 and later. For instructions on setting time zone information on OpenVMS Alpha prior to Version 7.3 and on OpenVMS VAX, see Section 6.3.

Note

If you are using the Distributed Time Synchronization Service (DTSS), you must use the procedures supplied with DTSS to set time zone information. See Section 6.1.1.

Use the procedure SYS$MANAGER:UTC$TIME_SETUP.COM to set time zone information.

Note

SYS$MANAGER:UTC$TIME_SETUP.COM has some undocumented uses that are not supported and can lead to inconsistent or incorrect time zone information. For this reason, you should use SYS$MANAGER:UTC$TIME_SETUP.COM only in the ways that are documented here.

To use SYS$MANAGER:UTC$TIME_SETUP.COM, you must have the following privileges enabled: OPER, LOG_IO, SYSPRV, SYSNAM and CMEXEC. To ensure that these privileges are enabled, execute the following command:
$ SET PROCESS/PRIVILEGES=(OPER,LOG_IO,SYSPRV,SYSNAM,CMEXEC)

If these privileges are not enabled, you can encounter errors or incorrect results.

You can use SYS$MANAGER:UTC$TIME_SETUP.COM to display current time zone information or to set time zone information.

6.2.1. Displaying Time Zone Information

After ensuring that the required privileges are enabled (see Section 6.2), execute the following command:
$ @SYS$MANAGER:UTC$TIME_SETUP SHOW
This results in the following (or similar) display:
AUTO_DLIGHT_SAV is set to "1".
OpenVMS will automatically change to/from Daylight Saving Time.
(in timezones that use Daylight Saving Time)

    LOCAL TIME ZONE = EASTERN / US -- STANDARD TIME
    LOCAL SYSTEM TIME = 20-MAR-2003 13:23:22.21 (EST)
    TIME DIFFERENTIAL FACTOR = -5:00
    TIME ZONE RULE = EST5EDT4,M4.1.0/02,M10.4.0/02
    Change EST to EDT on the First Sunday of April (6-Apr-2003) at 02:00
    Change EDT to EST on the Fourth Sunday of October (26-Oct-2003) at 02:00
If the AUTO_DLIGHT_SAVE system parameter is set to 0, you may receive a display similar to the following:
AUTO_DLIGHT_SAV is set to "0" and DTSS is not in use.
You will have to manually change to/from Daylight Saving Time.

You can do this by executing SYS$MANAGER:UTC$TIME_SETUP.COM,
or you can use SYS$EXAMPLES:DAYLIGHT_SAVING.COM.

    LOCAL TIME ZONE = ROC -- STANDARD TIME
    LOCAL SYSTEM TIME = 19-MAR-2003 13:02:03.91 (CST)
    TIME DIFFERENTIAL FACTOR = 8:00
    TIME ZONE RULE = CST-8
This time zone does not use Daylight Saving Time.

You may also receive messages indicating that some time zone parameters are not correctly set. If so, correct the time zone information and rerun the procedure.

6.2.2. Setting Time Zone Information

For local time zone support to work correctly, you must set the time zone that accurately describes the location you want to be considered as your default time zone. Usually, this is the time zone in which your system is running. In addition, your system must be correctly configured to use a valid OpenVMS time differential factor (TDF).

After ensuring that the required privileges are enabled (see Section 6.2), execute the following command:
$ @SYS$MANAGER:UTC$TIME_SETUP

Do not include any parameters with this command. When the main time zone menu is displayed, you can select the time zone in either of two ways: (1) by selecting the number in the main time zone menu that best represents the time zone desired (if multiple time zones exist for the selection you make, you will have to select the exact time zone from another menu), or (2) by using a search option that allows you to bypass the time zone menu and search by name.

If you select one of the numbers in the time zone menu, the corresponding time zone is selected. An asterisk (*) next to a number indicates that more than one time zone exists for that selection. If you select such a number, an additional menu displays with choices that allow you to select the appropriate time zone. For example, if you choose the United States (US) time zone from the main menu, a second menu displays the specific time zones within the United States. You then select the menu item that best represents the desired time zone.

The following example shows how you would select the Eastern time zone for the United States by using the menu numbers:

   Configuring the Local Time Zone
TIME ZONE SPECIFICATION -- MAIN Time Zone Menu  “*” indicates a menu
  0* GMT
  1* AFRICA      12) EET        23) JAPAN    34) ROK
  2* AMERICA     13) EGYPT      24) LIBYA    35) SINGAPORE
  3* ANTARCTICA  14) FACTORY    25) MET      36* SYSTEMV
  4* ASIA        15) GB-EIRE    26* MEXICO   37) TURKEY
  5* ATLANTIC    16) GREENWICH  27) NAVAJO   38) UCT
  6* AUSTRALIA   17) HONGKONG   28) NZ-CHAT  39) UNIVERSAL
  7* BRAZIL      18) ICELAND    29) NZ       40* US
  8* CANADA      19* INDIAN     30* PACIFIC  41) UTC
  9) CET         20) IRAN       31) POLAND   42) W-SU
 10* CHILE       21) ISRAEL     32) PRC      43) WET
 11) CUBA        22) JAMAICA    33) ROC      44) ZULU

Press “Return” to redisplay, enter “=” to search or “?” for help, or
Select the number above that best represents the desired time zone: 40

US Time Zone Menu                               “*” indicates a menu

  0* RETURN TO MAIN TIME ZONE MENU
  1) ALASKA    4) CENTRAL       7) HAWAII          10) MOUNTAIN
  2) ALEUTIAN  5) EAST-INDIANA  8) INDIANA-STARKE  11) PACIFIC
  3) ARIZONA   6) EASTERN       9) MICHIGAN        12) SAMOA

Press “Return” to redisplay, enter “=” to search or “?” for help, or
Select the number above that best represents the desired time zone: 6
You selected EASTERN / US as your time zone.
Is this correct? (Yes/No) [YES]:
Table 6.1 lists and describes the acronyms that appear in the Main Time Zone Menu.
Table 6.1. Time Zone Acronyms

Time Zone Acronym

Description

CET

Central European Time

EET

Eastern European Time

Factory

Specifies no time zone

GB-Eire

Great Britain/Ireland

GMT

Greenwich Mean Time

MET

Middle European Time

NZ

New Zealand

NZ-CHAT

New Zealand, Chatham Islands

PRC

People's Republic of China

ROC

Republic of China

ROK

Republic of Korea

SystemV

Specific to System V operating system

UCT

Coordinated Universal Time

US

United States

UTC

Coordinated Universal Time

Universal

Coordinated Universal Time

W-SU

Middle European Time

WET

Western European Time

To use the search option instead of menu numbers to select the time zone, enter an equal string (=) at the menu prompt instead of a number. The procedure then prompts you for the full or partial name of the time zone you want to select. After you enter that information, the procedure displays all matching time zones, and you can then select the appropriate one.

Note

Search only for a specific submenu name, such as US or INDIAN, or for a menu entry, such as POLAND (or partial name POL, for example) or EASTERN. Attempts to search for EASTERN / US or REUNION / INDIAN will fail to bring up choices for you.

The following example shows how you would select the Eastern time zone for the United States by using the search option:

Configuring the Local Time Zone

TIME ZONE SPECIFICATION -- MAIN Time Zone Menu   “*” indicates a menu
  0* GMT
  1* AFRICA      12) EET        23) JAPAN    34) ROK
  2* AMERICA     13) EGYPT      24) LIBYA    35) SINGAPORE
  3* ANTARCTICA  14) FACTORY    25) MET      36* SYSTEMV
  4* ASIA        15) GB-EIRE    26* MEXICO   37) TURKEY
  5* ATLANTIC    16) GREENWICH  27) NAVAJO   38) UCT
  6* AUSTRALIA   17) HONGKONG   28) NZ-CHAT  39) UNIVERSAL
  7* BRAZIL      18) ICELAND    29) NZ       40* US
  8* CANADA      19* INDIAN     30* PACIFIC  41) UTC
  9) CET         20) IRAN       31) POLAND   42) W-SU
 10* CHILE       21) ISRAEL     32) PRC      43) WET
 11) CUBA        22) JAMAICA    33) ROC      44) ZULU

Press “Return” to redisplay, enter “=” to search or “?” for help, or
Select the number above that best represents the desired time zone: =EAST

Search for Time Zone by Full or Partial Name
           “*” indicates a menu
           1) EAST / BRAZIL
           2) EAST-SASKATCHEWAN / CANADA
           3) EASTERN / CANADA
           4) EASTERISLAND / CHILE
           5) EASTER / PACIFIC
           6) EAST-INDIANA / US
           7) EASTERN / US

Press “Return” to redisplay this menu,
enter “=” to search for a new zone,
enter “0” to return to the Main Time Zone Menu,
enter “?” for help, or
Select the number above that best represents the desired time zone: 7

You selected EASTERN / US as your time zone.
Is this correct? (Yes/No) [YES]

If you enter No, you are returned to the Main Time Zone Menu.

If you answer Yes or press Return to accept the default, time zone information is set. This includes:
  • The following system logical names, which are set with the time zone information:
    • SYS$LOCALTIME

    • SYS$POSIXRULES

    • SYS$TIMEZONE_DAYLIGHT_SAVING

    • SYS$TIMEZONE_NAME

    • SYS$TIMEZONE_RULE

  • The following files, which are written so that time zone information can be reset when the system is rebooted:
    • [VMS$COMMON.SYSEXE]SYS$TIMEZONE_SRC.DAT

    • [VMS$COMMON.SYS$STARTUP]TDF$UTC_STARTUP.COM

The TDF is the difference between your system time and Coordinated Universal Time (UTC), which is an international standard (similar to Greenwich Mean Time) for measuring time of day. The system next displays the TDFs for standard and daylight saving time that correspond to the time zone you have selected, and information about the TDF. For example:

    Default Time Differential Factor for standard time is -5:00.
    Default Time Differential Factor for daylight saving time is -4:00.

    The Time Differential Factor (TDF) is the difference between your
    system time and Coordinated Universal Time (UTC).  UTC is similar
    in most repects to Greenwich Mean Time (GMT).

    The TDF is expressed as hours and minutes, and should be entered
    in the hh:mm format.  TDFs for the Americas will be negative
    (-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
    will be positive (1:00, 2:00, etc.).
Note that the system displays daylight saving time information only for time zones that use daylight saving time. If the time zone you selected uses daylight saving time, you must indicate whether daylight saving time is or is not currently in effect. Answer Y (Yes) or N (No) when you are prompted. For example:
Is Daylight Savings time in effect? Y
You are then prompted to enter the TDF. A default, based on your time zone and daylight saving time information, is provided. In the following example the default is -4:00. VSI recommends that you press Return to accept the default.
Enter the Time Differential Factor [-4:00]: Return
This results in the following (or similar) display:
    If this is a seasonal time change, it may also be necessary to
    modify the system time.  Generally, seasonal time changes result
    in adding 1:00 hour, or adding -1:00 hour to the system time.
When you are prompted, enter Yes or No.
Do you wish to modify the local system time [N]: Yes
If you answer Yes, the following is displayed:
    Enter the time adjustment value you would like to add to
    the local time.  You can enter hours only (hh) or hours and
    minutes (hh:mm)  The value can be positive (hh:mm or +hh:mm)
    or negative (-hh:mm).          
You are then asked to enter the time adjustment, usually either -1:00 or+1:00.
Enter the time adjustment value: -1:00
Finally, the TDF and the time adjustment (if any) is displayed, and you are asked to confirm that they are correct.
    NEW SYSTEM TIME DIFFERENTIAL FACTOR = -4:00
    ADDING -1:00 TO THE LOCAL TIME.

Is this correct? [Y]:

If you answer Yes, the TDF is set, and the system logical name SYS$TIMEZONE_DIFFERENTIAL is defined.

If you answer No, you are returned to the TDF information display, from which you can reenter your TDF and time adjustment choices.

6.3. Setting Time Zone Information on OpenVMS VAX Systems

This section presents instructions for setting time zone information on OpenVMS VAX and on OpenVMS Alpha prior to Version 7.3. For instructions about setting time zone information on OpenVMS Alpha Version 7.3 and later, and on I64, see Section 6.2.

You use the command procedure SYS$MANAGER:UTC$TIME_SETUP.COM to set time zone information, including:
  • Setting your local time zone, your TDF, or both

  • Modifying your system's local time to adjust for daylight saving or standard time

  • Displaying the local time and TDF for your system

If you set the time zone and the TDF on one node in a cluster, the values you set take effect on other nodes in the cluster when those nodes are rebooted.

For your convenience, the instructions for using the command procedure have been split into two sections:
  • Setting the time zone

  • Setting the TDF

Beginning the Procedure

To use SYS$MANAGER:UTC$TIME_SETUP.COM, follow these steps:
  1. Log in to the SYSTEM account or enter the following command to enable LOG_IO and OPER privileges:
    $ SET PROCESS/PRIVILEGES=(LOG_IO,OPER)
  2. Enter the following command to start UTC$TIME_SETUP.COM:
    $ @SYS$MANAGER:UTC$TIME_SETUP.COM

     %UTC-I-UPDTIME, updating Time Zone information in SYS$COMMON:[SYSEXE]
  3. Press Return to accept the default of BOTH or enter one of the other choices in answer to the following question:
    Configure which time parameter (TIMEZONE/TDF/BOTH/NONE)? [BOTH]

    Note

    VSI recommends that you set both the time zone and the TDF. If you set the TDF without setting the time zone, the procedure cannot provide default TDF values.

If you answer BOTH or TIMEZONE to the time parameter question in the command procedure, continue in Section 6.3.1.If you answer TDF to the question, continue in Section 6.3.2.

6.3.1. Setting the Time Zone on Your System

The local time zone is the location you want to consider your default local time zone. Usually this local time zone is the same as the local time zone in which your system is located.

You set the local time zone by making choices in a command procedure.

The system first displays the following information:
    Configuring the Local Time Zone
    TIME ZONE SPECIFICATION – Main Time Zone Menu
     1) Australia  11) GMT        21) Mexico   31) Turkey
     2) Brazil     12) Greenwich  22) NZ       32) UCT
     3) CET        13) Hong Kong  23) NZ-CHAT  33) US
     4) Canada     14) Iceland    24) Navajo   34) UTC
     5) Chile      15) Iran       25) PRC      35) Universal
     6) Cuba       16) Israel     26) Poland   36) W-SU
     7) EET        17) Jamaica    27) ROC      37) WET
     8) Egypt      18) Japan      28) ROK      38) Zulu
     9) Factory    19) Libya      29) Singapore
    10) GB-Eire    20) MET        30) SystemV

     0) None of the above

Table 6.1 lists and describes the acronyms that appear in the Main Time Zone Menu.

To select a time zone, follow these steps:
  1. Enter a number after the following question; for example, 33, for the United States:
    Select the number above that best describes your location: 33

    If you enter 0, the system defaults to GMT.

  2. If you enter a country that has more than one time zone, the system displays a message and asks for a confirmation like the following one (if not, skip to the explanation following step 4):
    You selected US as your time zone.
    Is this correct? (Yes/No) [YES]: [Return]
  3. The system displays areas with different time zones and asks you to select your area. Enter a number, for example, 6:
        US Time Zone Menu
       1) Alaska    4) Central       7) Hawaii          10) Mountain
       2) Aleutian  5) East-Indiana  8) Indiana-Starke  11) Pacific
       3) Arizona   6) Eastern       9) Michigan        12) Samoa
    
       0) None of the above

    Select the number above that best describes your location: 6
  4. Confirm the displayed information or enter another number after the following prompt; for example:
    You selected US/Eastern as your time zone.Is this correct? (Yes/No) [YES]: [Return]
    When you confirm the last statement, the system redefines the following system logical names:
    • sys$localtime
    • sys$posixrules

    The VSI C RTL uses these logical names to compute the time zone rules for your applications. The system also writes this information to SYS$TIMEZONE.DAT. The system uses this file to reset SYS$LOCALTIME and SYS$POSIXRULES when you reboot.

    The system then displays the TDFs for standard and daylight saving time that correspond to the time zone you have selected:
        Default Time Differential Factor for standard time is -5:00.
       *Default Time Differential Factor for daylight saving time is -4:00.

    * The system displays daylight saving time only for time zones that use daylight saving time.

6.3.2. Setting the TDF on Your System

If you answer TDF or BOTH to the time parameter question at the beginning of the command procedure, the system displays prompts for the TDF on your system.

To set the TDF, answer the following questions:
  1. Select option 2 to display the TDF the system has calculated for you:
        Configuring the Time Differential Factor (TDF)
        Enter ? anytime for help
        [0]     Exit
        [1]     Set the Time Differential Factor
        [2]     Display the Time Differential Factor
    

    Please pick an option number [2]: 2
    The system displays information similar to the following items:
        SYSTEM TIME DIFFERENTIAL FACTOR = -4:00  (-14400 seconds).
        LOCAL SYSTEM TIME               = 22-JAN-2001 10:49:45.20.
    
  2. Select option 1 to verify the TDF displayed or to enter a new one:
        Configuring the Time Differential Factor (TDF)
        Enter ? anytime for help
        [0]     Exit
        [1]     Set the Time Differential Factor
        [2]     Display the Time Differential Factor

    Please pick an option number [2]: 1
    The system then displays the following information:
        The Time Differential Factor (TDF) is the difference between your
        system time and Coordinated Universal Time (UTC).  UTC is similar
        in most respects to Greenwich Mean Time (GMT).
        The TDF is expressed as hours and minutes, and should be entered
        in the hh:mm format.  TDFs for the Americas will be negative
        (-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
        will be positive (1:00, 2:00, etc.).

    The system displays the following question only if you set the time zone as well. However, some time zones do not have daylight saving time; if they do not, the system also does not display this question.

  3. Answer Yes or No to the following question:
    Is Daylight Saving time in effect? (Yes/No): 
  4. After the following prompt, either press Return to accept the displayed default or enter the correct TDF. (If you have not set the time zone, the system does not display a default TDF value.)
    Enter the Time Differential Factor [-4:00]:
    The system then explains the need to modify the system time as well for season time changes:
        If this is a seasonal time change, it may also be necessary to
        modify the system time.  Generally, seasonal time changes result
        in adding 1:00 hour, or adding -1:00 hour to the system time.
  5. To the following question, answer Yes if you need to modify the local system time or No if you do not:
    Do you wish to modify the local system time [N]: 

    If you answer Yes, the system leads you through a dialogue similar to the one in Section 6.5.3

    If you answer No, the system next displays the new TDF:
        NEW SYSTEM TIME DIFFERENTIAL FACTOR = -4:00.
  6. Answer Yes to confirm the displayed TDF or No if it is incorrect:
     Is this correct? [Y]:

    If you answer No, the system returns to step 1 in this section.

    If you answer Yes, the system displays both the TDF and the local system time.
        SYSTEM TIME DIFFERENTIAL FACTOR = -4:00  (-14400 seconds).
        LOCAL SYSTEM TIME               = 22-JAN-2001 10:52:37.36.

6.4. Setting Time in an OpenVMS Cluster Environment

The local time, the TDF, and the time zone must be the same on all nodes in an OpenVMS Cluster environment. You can use the System Management utility (SYSMAN) DO command to invoke the command procedure SYS$MANAGER:UTC$TIME_SETUP.COM on one node in a cluster to perform the following actions for one or more nodes in the cluster:
  • Display time zone information

  • Set or change the time zone information

Because SYS$MANAGER:UTC$TIME_SETUP.COM is different on OpenVMS Alpha systems and OpenVMS VAX systems, you must take care in a mixed architecture cluster. Set the SYSMAN environment to operate on all Alpha, I64 or all VAX nodes with the following SYSMAM command:
SYSMAN> SET ENVIRONMENT /NODE=(<node_list>)

Then, after you have run UTC$TIME_SETUP.COM for one architecture, reset the environment to the other architecture and run UTC$TIME_SETUP.COM for that architecture.

6.5. Adjusting for Daylight Saving Time

In time zones that use daylight saving time, your system time must be adjusted twice a year. How this change occurs depends on the following:
  • Whether DTSS is in use

  • The version of OpenVMS

  • The architecture (VAX, Alpha or I64)

  • System parameter AUTO_DLIGHT_SAV (OpenVMS Alpha Version 7.3 only)


Note

If you are using the Distributed Time Synchronization Service (DTSS), DTSS makes the necessary changes between daylight saving time and standard time. See Section 6.1.1.

If DTSS is not in use, use the following table to determine how to change system time between standard time and daylight saving time:
OpenVMS VersionArchitectureAUTO_DLIGHT_SAVSee

7.3 and later

Alpha and I64

1

Section 6.5.1

7.3 and later

Alpha and I64

0

Section 6.5.2

7.3 and later

VAX

n/a

Section 6.5.2

7.2 and earlier

VAX or Alpha

n/a

Section 6.5.3

6.5.1. Automatically Adjusting for Daylight Saving Time (OpenVMS Alpha Version 7.3 and Later, OpenVMS I64)

OpenVMS Alpha Version 7.3 and later and OpenVMS I64 contain a system parameter, AUTO_DLIGHT_SAV, that controls automatic switching between standard time and daylight saving time.

If AUTO_DLIGHT_SAV is set to 1, an OpenVMS Alpha Version 7.3 (and later) or I64 system automatically sets the time forward or back when local time changes between daylight saving time and standard time.

If AUTO_DLIGHT_SAV is set to 0 (the default), OpenVMS does not automatically change between daylight saving time and standard time.

The AUTO_DLIGHT_SAV parameter and the automatic changes between daylight saving time and standard time are implemented only on OpenVMS Alpha Version 7.3 and later and on I64 systems.

For this to work correctly, you must set a time zone rule for your time zone. See Section 6.2 for information about setting time zone rules on OpenVMS Alpha Version 7.3 and later systems and on I64 systems.

To enable or disable the automatic changing from standard time to daylight saving time, you must modify AUTO_DLIGHT_SAV. The modification will not take effect until you reboot the system. See VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems for information about modifying system parameters.

Note

Automatic changes between daylight saving time and standard time work only on OpenVMS Alpha Version 7.3 and later systems and on I64 systems. VSI recommends that you do not enable automatic daylight saving time conversion on mixed-version or mixed-architecture OpenVMS Clusters.

For details on manually adjusting for daylight saving time on OpenVMS Version 7.3 systems, see Section 6.5.2.

6.5.2. Manually Adjusting for Daylight Saving Time (OpenVMS Version 7.3 and Later Systems, I64 Systems)

This section contains instructions for adjusting system time between standard time and daylight saving time on OpenVMS Version 7.3 and later when DTSS is not in use. Use these instruction for OpenVMS VAX Version 7.3 and for OpenVMS Alpha Version 7.3 and later and for I64 systems when automatic daylight saving time switching is disabled (system parameter AUTO_DLIGHT_SAV is set to 0).

To adjust the local time to daylight saving time or standard time, invoke command procedure SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM to perform both of the following tasks:
  • Adjust the TDF

  • Modify the local time by one hour forward or backward

DAYLIGHT_SAVINGS.COM allows you to perform either of the following actions:
  • Make the changes immediately.

  • Queue a batch job to make the changes at a future time. (This is the most common use of this command procedure.)

DAYLIGHT_SAVINGS.COM creates a command procedure, DST$CHANGE.COM, in the current directory. DST$CHANGE.COM can execute on the current node only. To change the time for all nodes in an OpenVMS Cluster, DAYLIGHT_SAVINGS.COM also creates command procedure DST$SYSMAN.COM that executes DST$CHANGE.COM by executing a SYSMAN DO command. Note that to change all nodes, you must run DAYLIGHT_SAVINGS.COM on a node that has OpenVMS Alpha Version 7.3 or later or I64 installed.

You can run DAYLIGHT_SAVINGS.COM interactively and respond to prompts for input, or run the command procedure with parameters.

To run DAYLIGHT_SAVINGS.COM with parameters, enter the following command:
$ @SYS$EXAMPLES:DAYLIGHT_SAVINGS P1 P2 P3 P4
The parameters are described in the following table:

P1

DAYLIGHT

Change from standard time to daylight saving time

STANDARD

Change from daylight saving time to standard time

P2

NODE

Change time on this node only

CLUSTER

Change time on the entire OpenVMS Cluster

P3

EXECUTE

Change time immediately

QUEUE

Submit the job to SYS$BATCH for execution at the date and time specified by P4

SAVE

Save the procedure for later modification

P4

date-time

If P3 is QUEUE, date and time that the submitted batch job is to run, in DD-MMM-YYYY:HH:MM:SS format; otherwise P4 is unused

Note that you need enter only the first letter of parameters P1, P2, and P3.

To run DAYLIGHT_SAVINGS.COM interactively, enter the following command:
$ @SYS$EXAMPLES:DAYLIGHT_SAVINGS

DAYLIGHT_SAVINGS.COM prompts you for the parameters specified above.

When executing DAYLIGHT_SAVINGS.COM to change the time on all nodes in an OpenVMS Cluster at a future time, you can specify SAVE for parameter P3. This causes DAYLIGHT_SAVINGS.COM to save command procedures DST$SYSMAN.COM and DST$CHANGE.COM. You can then submit DST$SYSMAN.COM to the correct queue.

6.5.3. Adjusting for Daylight Saving Time on OpenVMS Version 7.2

This section contains instructions for adjusting system time for daylight saving time on OpenVMS Version 7.2 and earlier.

Note

If you are using the Distributed Time Synchronization Service (DTSS), DTSS makes the necessary changes between daylight saving time and standard time. See Section 6.1.1.

To adjust the local time to daylight saving time or standard time, you can invoke the command procedure SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM to perform both of the following tasks:
  • Adjust the TDF

  • Modify the local time

DAYLIGHT_SAVINGS.COM allows you to perform either of the following actions:
  • Make the changes immediately. (Usually, however, you would use UTC$TIME_SETUP.COM to make changes immediately by answering Yes to Question 5 in Section 6.3.2.)

  • Queue a batch job to make the changes at a future time. (This is the most common use of this command procedure.)

The following example of DAYLIGHT_SAVINGS.COM shows answers that cause the procedure to queue a batch job, DST_CHANGE, which will execute when the time changes from standard time to daylight saving time. Many of the questions are similar to those explained in Section 6.3.2.

In the example, the initial TDF value is -5:00. The local date and time are any time from the date in 2000 when the change to standard time was made, until1-APR-2001:02:00, when the change to daylight saving time will be made.
$ SYS$EXAMPLES:DAYLIGHT_SAVINGS
        This procedure queues a batch job that changes the system time
        and system time differential around a daylight saving time
        change.  Press the question mark (?) key at any time for help;
        hit Control-C to exit.
        The Time Differential Factor (TDF) is the difference
        between your system time and Coordinated Universal Time (UTC).
        The difference is expressed in hh:mm format.  The Americas
        have negative offsets from UTC, while Europe, Africa, Asia
        and Australia have positive offsets from UTC.
       * Enter the Time Differential Factor: -4:00
        If this is a seasonal time change, it may also be
        necessary to modify the system time.  Generally,
        seasonal time changes result in adding 1:00 hour,
        or adding -1:00 hour to the local time.
        * Do you wish to modify the local system time [N]: Y
        Enter the time value you would like  to add to
        the local time.  The value can be a positive or
        a negative (-hh:mm) value.
        * Enter the time value: +1:00
        The process to modify your time zone offset and local
        time (if supplied) can occur now or in the future.
        Press Return to run the job now.
        * Enter the run time in the DD-MMM-YYYY:HH:MM:SS format:
01-apr-2001:02:00
NEW SYSTEM TIME DIFFERENTIAL FACTOR = -4:00
ADDING 1:00 TO THE LOCAL TIME.
JOB RUN TIME : 1-APR-2001:02:00

        * Continue? [Y]: Y

Job DST_CHANGE (queue SYS$BATCH, entry 2) holding until 1-APR-2001 02:00
Batch Job DST_CHANGE scheduled to run at 1-APR-2001:02:00
$
$!!The batch job DST_CHANGE will run on 1-Apr-2001 at 02:00

6.6. Setting Time Using the Battery-Backed Watch (BBW) (Alpha Only)

The OpenVMS Alpha and I64 architectures maintain the current date and time in the Battery-Backed Watch (BBW) across power failures and system downtime. The BBW is functionally equivalent to the Time of Day Register (TODR) that the VAX architecture uses. One difference, however, is the BBW's constraint on the date range.

The BBW provides sufficient storage capability for only a century. The OpenVMS Alpha and I64 systems date range has been redefined as 1957 to 2056 to maintain correct leap-year processing and to provide for the millennial transition.

In addition, the OpenVMS Alpha and I64 timing mechanisms have been changed to allow 2-digit year support in the $ASCTIM system service and the DCL command SET TIME. (Prior to this change, only 4-digit year fields were allowed.) With 2-digit support, you need to enter only the last 2 digits of a year. The century associated with the year field is derived from the placement of the 2 digits in the 1957-2056 date range. For example:
$ SET TIME = 1-NOV-98
In this example, 98 is the equivalent of 1998.
$ SET TIME = 1-NOV-05

In this example, 05 is the equivalent of 2005.

6.7. Choosing Languages, and Date and Time Formats

You can specify languages other than English. From the list that the system manager defines, users can later select a language that they want to display.

You can also select the time and date formats for many SHOW commands from a predefined list or define new time and date formats.

Note

The SHOW TIME command does not include this feature because the SHOW TIME command is processed completely by DCL, which does not have access to the LIB$ routines necessary to format the output.

In addition, the SHOW commands for batch and print operations were modified to include, in the default time-stamp, seconds as well as hours and minutes. These new features were not previously documented.

For example, rather than 15-JAN-2001 10:16:25.14, you can use a different format, such as the following one:
$ SHOW USERS
      OpenVMS User Processes at JANUARY 15, 2001 10:16 AM
    Total number of users = 7,  number of processes = 11
 Username     Node     Interactive  Subprocess   Batch
 MCDERMOT    ARD26B            1
 PASTERNAK   ARD26B            -         2         1
.
.
.

Later, users can override the system defaults set up by the system manager and select their own date and time formats.

Steps to Change Languages, and Dates and Times

For languages other than English or date/time formats other than the defaults, you must complete these steps.

Note

VSI recommends that you include these steps within the command procedure SYS$MANAGER:SYSTARTUP_VMS.COM.


  1. Define the logical name SYS$LANGUAGES (plural) to specify the list of languages the users on your system might want to use. (If the language is English, skip this step.)

  2. Invoke the command procedure SYS$MANAGER:LIB$DT_STARTUP.COM, which:
    • Defines output formats you can use to customize the display of dates and times

    • Loads support for languages other than English that you define with the SYS$LANGUAGES logical

  3. Define date and time formats for the system using either:
    • User-defined formats

    • Predefined formats

6.7.1. Specifying Languages Other Than English

Note

Help/Message language variants might become available in a future release of OpenVMS or on a per-country basis.

You use the SYS$LANGUAGES (plural) logical to define a list of languages other than English. (From this list, users can later select a language to be displayed on their processes, as explained in Section 6.7.4.)

Because English is the default language and must therefore always be available, English spellings are not taken from logical name translations; rather, they are looked up in an internal table.

For example, to specify the French, German, and Italian languages, you must define SYS$LANGUAGES
$ DEFINE SYS$LANGUAGES FRENCH, GERMAN, ITALIAN

To add another language, for example, FINNISH, you must add FINNISH to the definition of SYS$LANGUAGES and execute the command procedure again.

6.7.2. Invoking LIB$DT_STARTUP.COM

The SYS$MANAGER:LIB$DT_STARTUP.COM command procedure defines the possible choices for the following logicals:
  • SYS$LANGUAGES

    The system loads the languages you have selected using the SYS$LANGUAGES (plural) logical.

    Users can later select their own choice of languages by defining the SYS$LANGUAGE (singular) logical, as explained in Section 6.7.4.

  • LIB$DT_FORMAT

    The system loads output formats that you can then use to specify default system formats.

    Users can later define their own formats, as explained in Section 6.7.4.

To invoke the command procedure, enter the following command:
$ @SYS$MANAGER:LIB$DT_STARTUP

If the translation of SYS$LANGUAGES fails, then English is used. If the translation of LIB$DT_FORMAT or any logical name relating to format fails, the OpenVMS standard ($ASCTIM) representation of the date and time is used, that is, dd-mmm-yyyy hh:mm:ss.cc.

6.7.3. Defining System Default Date and Time Formats

To define default date and time formats, you can use either user-defined formats, which are shown in Table 6.2, or predefined formats, which are shown in Table 6.3 and Table 6.4.

To select a format for a date, time, or both, you must define the LIB$DT_FORMAT logical name using the following logicals:
  • LIB$DATE_FORMAT_ nnn, where nnn ranges from 001 to 040

  • LIB$TIME_FORMAT_ nnn, where nnn ranges from 001 to 020

The order in which these logical names appear in the definition of LIB$DT_FORMAT determines the order in which they are output. A single space is inserted into the output string between the two elements if the definition specifies that both are output. For example, to define systemwide formats:
$ DEFINE/SYSTEM LIB$DT_FORMAT LIB$DATE_FORMAT_006, LIB$TIME_FORMAT_012
This definition causes the date to be displayed systemwide in the specified format, followed by a space and the time in the specified format. For example:
13 JAN 97 9:13 AM

Section 6.7.4 explains how users can select their own date and time formats to be displayed for their process.

6.7.3.1. Defining Your Own Format

To define your own format, define LIB$DATE_FORMAT_ nnn and LIB$TIME_FORMAT_ nnn, using the mnemonics shown in Table 6.2. Replace nnn with a number of your choice.

Note

For user-defined formats, VSI recommends that you use values of _500 and above for _ nnn.


Table 6.2. Format Mnemonics

Date

Explanation

!D0

Day, Zero-Filled

!DD

Day, No Fill

!DB

Day, Blank-Filled

!WU

Weekday, Uppercase

!WAU

Weekday, Abbreviated, Uppercase

!WC

Weekday, Capitalized

!WAC

Weekday, Abbreviated, Capitalized

!WL

Weekday, Lowercase

!WAL

Weekday, Abbreviated, Lowercase

!MAU

Month, Alphabetic, Uppercase

!MAAU

Month, Alphabetic, Abbreviated, Uppercase

!MAC

Month, Alphabetic, Capitalized

!MAAC

Month, Alphabetic, Abbreviated, Capitalized

!MAL

Month, Alphabetic, Lowercase

!MAAL

Month, Alphabetic, Abbreviated, Lowercase

!MN0

Month, Numeric, Zero-Filled

!MNM

Month, Numeric, No Fill

!MNB

Month, Numeric, Blank-Filled

!Y4

Year, 4 Digits

!Y3

Year, 3 Digits

!Y2

Year, 2 Digits

!Y1

Year, 1 Digit

Time

Explanation

!H04

Hours, Zero-Filled, 24-Hour Clock

!HH4

Hours, No Fill, 24-Hour Clock

!HB4

Hours, Blank-Filled, 24-Hour Clock

!H02

Hours, Zero-Filled, 12-Hour Clock

!HH2

Hours, No Fill, 12-Hour Clock

!HB2

Hours, Blank-Filled, 12-Hour Clock

!M0

Minutes, Zero-Filled

!MM

Minutes, No Fill

!MB

Minutes, Blank-Filled

!S0

Seconds, Zero-Filled

!SS

Seconds, No Fill

!SB

Seconds, Blank-Filled

!C7

Fractional Seconds, 7 Digits

!C6

Fractional Seconds, 6 Digits

!C5

Fractional Seconds, 5 Digits

!C4

Fractional Seconds, 4 Digits

!C3

Fractional Seconds, 3 Digits

!C2

Fractional Seconds, 2 Digits

!C1

Fractional Seconds, 1 Digit

!MIU

Meridiem Indicator, Uppercase

!MIC

Meridiem Indicator, Capitalized (mixed case)

!MIL

Meridiem Indicator, Lowercase

6.7.3.2. Using Predefined Formats

Table 6.3 lists all predefined date format logical names, their formats, and examples of the output generated using those formats. The mnemonics used to specify the formats are listed in Table 6.2.
Table 6.3. Predefined Output Date Formats

Date Format Logical

Format

Example

LIB$DATE_FORMAT_001

!DB-!MAAU-!Y4

13-JAN-1998

LIB$DATE_FORMAT_002

!DB !MAU !Y4

13 JANUARY 1998

LIB$DATE_FORMAT_003

!DB.!MAU !Y4

13.JANUARY 1998

LIB$DATE_FORMAT_004

!DB.!MAU.!Y4

13.JANUARY.1998

LIB$DATE_FORMAT_005

!DB !MAU !Y2

13 JANUARY 98

LIB$DATE_FORMAT_006

!DB !MAAU !Y2

13 JAN 98

LIB$DATE_FORMAT_007

!DB.!MAAU !Y2

13.JAN 98

LIB$DATE_FORMAT_008

!DB.!MAAU.!Y2

13.JAN.98

LIB$DATE_FORMAT_009

!DB !MAAU !Y4

13 JAN 1998

LIB$DATE_FORMAT_010

!DB.!MAAU !Y4

13.JAN 1998

LIB$DATE_FORMAT_011

!DB.!MAAU.!Y4

13.JAN.1998

LIB$DATE_FORMAT_012

!MAU !DD, !Y4

JANUARY 13, 1998

LIB$DATE_FORMAT_013

!MN0/!D0/!Y2

01/13/98

LIB$DATE_FORMAT_014

!MN0-!D0-!Y2

01-13-98

LIB$DATE_FORMAT_015

!MN0.!D0.!Y2

01.13.98

LIB$DATE_FORMAT_016

!MN0 !D0 !Y2

01 13 98

LIB$DATE_FORMAT_017

!D0/!MN0/!Y2

13/01/98

LIB$DATE_FORMAT_018

!D0/!MN0-!Y2

13/01-98

LIB$DATE_FORMAT_019

!D0-!MN0-!Y2

13-01-98

LIB$DATE_FORMAT_020

!D0.!MN0.!Y2

13.01.98

LIB$DATE_FORMAT_021

!D0 !MN0 !Y2

13 01 98

LIB$DATE_FORMAT_022

!Y2/!MN0/!D0

98/01/13

LIB$DATE_FORMAT_023

!Y2-!MN0-!D0

98-01-13

LIB$DATE_FORMAT_024

!Y2.!MN0.!D0

98.01.13

LIB$DATE_FORMAT_025

!Y2 !MN0 !D0

98 01 13

LIB$DATE_FORMAT_026

!Y2!MN0!D0

980113

LIB$DATE_FORMAT_027

/!Y2.!MN0.!D0

/98.01.13

LIB$DATE_FORMAT_028

!MN0/!D0/!Y4

01/13/1998

LIB$DATE_FORMAT_029

!MN0-!D0-!Y4

01-13-1998

LIB$DATE_FORMAT_030

!MN0.!D0.!Y4

01.13.1998

LIB$DATE_FORMAT_031

!MN0 !D0 !Y4

01 13 1998

LIB$DATE_FORMAT_032

!D0/!MN0/!Y4

13/01/1998

LIB$DATE_FORMAT_033

!D0-!MN0-!Y4

13-01-1998

LIB$DATE_FORMAT_034

!D0.!MN0.!Y4

13.01.1998

LIB$DATE_FORMAT_035

!D0 !MN0 !Y4

13 01 1998

LIB$DATE_FORMAT_036

!Y4/!MN0/!D0

1998/01/13

LIB$DATE_FORMAT_037

!Y4-!MN0-!D0

1998-01-13

LIB$DATE_FORMAT_038

!Y4.!MN0.!D0

1998.01.13

LIB$DATE_FORMAT_039

!Y4 !MN0 !D0

1998 01 13

LIB$DATE_FORMAT_040

!Y4!MN0!D0

19980113

Table 6.4 lists all predefined time format logical names, their formats, and examples of the output generated using those formats.
Table 6.4. Predefined Output Time Formats

Time Format Logical

Format

Example

LIB$TIME_FORMAT_001

!H04:!M0:!S0.!C2

09:13:25.14

LIB$TIME_FORMAT_002

!H04:!M0:!S0

09:13:25

LIB$TIME_FORMAT_003

!H04.!M0.!S0

09.13.25

LIB$TIME_FORMAT_004

!H04 !M0 !S0

09 13 25

LIB$TIME_FORMAT_005

!H04:!M0

09:13

LIB$TIME_FORMAT_006

!H04.!M0

09.13

LIB$TIME_FORMAT_007

!H04 !M0

09 13

LIB$TIME_FORMAT_008

!HH4:!M0

9:13

LIB$TIME_FORMAT_009

!HH4.!M0

9.13

LIB$TIME_FORMAT_010

!HH4 !M0

9 13

LIB$TIME_FORMAT_011

!H02:!M0 !MIU

09:13 AM

LIB$TIME_FORMAT_012

!HH2:!M0 !MIU

9:13 AM

LIB$TIME_FORMAT_013

!H04!M0

0913

LIB$TIME_FORMAT_014

!H04H!M0m

09H13m

LIB$TIME_FORMAT_015

kl !H04.!M0

kl 09.13

LIB$TIME_FORMAT_016

!H04H!M0'

09H13'

LIB$TIME_FORMAT_017

!H04.!M0 h

09.13 h

LIB$TIME_FORMAT_018

h !H04.!M0

h 09.13

LIB$TIME_FORMAT_019

!HH4 h !MM

9 h 13

LIB$TIME_FORMAT_020

!HH4 h !MM min !SS s

9 h 13 min 25 s

6.7.4. User Definitions of Language, and Date and Time Formats

A user can specify a choice of language by defining the SYS$LANGUAGE logical. For example:
$ DEFINE SYS$LANGUAGE FRENCH
A user can also specify a date and time format by defining the LIB$DT_FORMAT logical. For example:
$ DEFINE LIB$DT_FORMAT LIB$DATE_FORMAT_002, LIB$TIME_FORMAT_006

6.8. Saving Your Customization

Once you have installed and customized your system, VSI recommends that you back up your system disk. To do so, follow the instructions in Section 11.17.

On VAX systems, back up the console volume (if applicable).If your computer has a console storage device, make a backup copy of your console volume in case your original becomes corrupted. The operating system provides a command procedure called CONSCOPY.COM (in the SYS$UPDATE directory), which copies your console volume to a blank one.

The procedure for backing up the console volume varies for different computers. For specific instructions on backing up the console volumes, refer to the upgrade and installation supplement for your VAX computer.

6.9. Using SYSMAN to Manage System Time

You can manage system time for an OpenVMS Cluster system with SYSMAN CONFIGURATION commands. Table 6.5 summarizes these CONFIGURATION commands and their functions.
Table 6.5. SYSMAN CONFIGURATION Commands

Command

Function

CONFIGURATION SET TIME

Updates system time

CONFIGURATION SHOW TIME

Displays current system time

6.9.1. Modifying the System Time

Use the CONFIGURATION SET TIME command to modify system time for nodes in an OpenVMS Cluster system, as well as for individual nodes. You can specify time values in the following format:
[dd-mmm-yyyy[:]] [hh:mm:ss.cc]

You can also enter delta time values. Refer to the VSI OpenVMS User's Manual for more information about time formats.

In a cluster environment, SYSMAN sets the time on each node to the value you specify. However, if you do not specify a value, SYSMAN reads the clock on the node from which you are executing SYSMAN and assigns this value to all nodes in the cluster. In a remote cluster, SYSMAN reads the clock on the target node in the cluster and assigns that value to all nodes. Note that the time-of-year clock is optional for some processors; refer to your processor's hardware handbook for more information.

SYSMAN tries to ensure that all processors in the cluster are set to the same time. Because of communication and processing delays, it is not possible to synchronize clocks exactly. However, the variation is typically less than a few hundredths of a second. If SYSMAN cannot set the time to within one-half second of the specified time, you receive a warning message that names the node that failed to respond quickly enough.

As a result of slight inaccuracies in each processor clock, times on various members of a cluster tend to drift apart. The first two examples show how to synchronize system time in a cluster.

Examples

  1. The following procedure sets the time on all cluster nodes to the value obtained from the local time-of-year clock, waits 6 hours, then resets the time for the cluster:
    $ SYNCH_CLOCKS:
    $ RUN SYS$SYSTEM:SYSMAN
          SET ENVIRONMENT/CLUSTER
          CONFIGURATION SET TIME
          EXIT
    $ WAIT 6:00:00
    $ GOTO SYNCH_CLOCKS
  2. The next example sets the environment to NODE21, NODE22, and NODE23, sets privilege, and modifies the system time on all three nodes:
    SYSMAN> SET ENVIRONMENT/NODE=(NODE21,NODE22,NODE23)
    SYSMAN> SET PROFILE/PRIVILEGE=LOG_IO
    SYSMAN> CONFIGURATION SET TIME 12:38:00
  3. The following example sets the environment to cluster and displays the system time for all nodes:
    SYSMAN> SET ENVIRONMENT/CLUSTER/NODE=NODE23
    SYSMAN> CONFIGURATION SHOW TIME
    System time on node NODE21: 19-APR-2001 13:32:19.45
    System time on node NODE22: 19-APR-2001 13:32:27.79
    System time on node NODE23: 19-APR-2001 13:32:58.66

6.9.1.1. Resetting System Time After January 1

The Time of Day Register (TODR),which the system uses to maintain system time, has a limit of approximately 15 months. Between January 1 and April 1, reset the system time; otherwise, the following problems might occur:
  • The first time in a new year that you reboot an OpenVMS Cluster system or a node in the system, one or more nodes display any of the following system times:
    • A year in the past

    • A year in the future, which might cause passwords to expire and other difficulties

    • A correct time, but a SHOW SYSTEM command indicates that the system has been up since a time in the 1800s

  • Even if you correct the system time during system boot, the following problems might remain:
    • A SHOW SYSTEM command displays an incorrect up time such as a date in the 1800s

    • The error log report (ERRLOG) shows errors for a year in the future

    • Batch jobs are waiting for a year in the future

    • Files have a creation or modification date in the future

Because the TODR has an approximate limit of 15 months, the system maintains time by combining the TODR value with a base time recorded in the base system image (SYS$LOADABLE_IMAGES:SYS.EXE). The definition of base time is:
01-JAN-CURRENT_YEAR 00:00:00.00

Because all TODRs ordinarily have the same base, multiple CPUs can boot off the same system disk, and you can use multiple system disks on one CPU; the system sets the time correctly.

When a SET TIME command is issued (with or without specifying a time),OpenVMS performs the following actions:
  1. Writes the current time to the system image file

  2. Resets the TODR as an offset within the current year

In an OpenVMS Cluster system (or for a node that is not part of the cluster),when you set the time, the TODR and the base time in the system image are reset with the values for the new year. However, multiple systems might share the system image. This does not normally cause a problem except after the first day of a new year.

Note

The system issues the SET TIME command when it boots and as a part of the normal SHUTDOWN command procedure.

By December, each node has a very large offset stored in the TODR (from the base time of 1-JAN of that year). When the time advances to a new year, the system image still has the old year and the TODR values are still large.

After January 1, if a SET TIME command is issued on any node (or any node is shut down using SHUTDOWN.COM), the following events occur:
  1. The new year becomes the base year.

  2. The system resets the TODR on that node.

  3. The other nodes still have a large value in the TODR.

After these three events occur, if a node that has a large TODR crashes and rejoins the cluster, its system time is initially in the next year (applying the large TODR to the new year).This system time is recorded as the system's boot time. When the node joins the cluster, its time is set to the correct value but the boot time remains one year in the future. Certain forms of the SHOW SYSTEM command compare current time to boot time; in this instance, SHOW SYSTEM displays incorrect values.

If a system disk is used at different times by different, unclustered CPUs or if different system disks are used at different times on the same CPU, the system might incorrectly set the time to a year in the future or a year in the past, depending on how the CPU's TODR and the value recorded on the system disk become unsynchronized:
  • Sharing a system disk across multiple CPUs pushes the time into the future

  • Using multiple disks on one CPU pushes the time into the past

Example
The following example uses SYSMAN commands to reset the time on all nodes in an OpenVMS Cluster system:
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> SET PROFILE/PRIVILEGE=(LOG_IO,SYSLCK)
SYSMAN> CONFIGURATION SET TIME 05-JAN-2001:12:00:00
SYSMAN> EXIT

Notes

In a node that is not part of a cluster, use the SET TIME command and specify a time. If you do not specify a time, the SET TIME command updates the system time using the time in the TODR.

If you are running the DIGITAL Distributed Time Service (DECdts) on your system, you must use it to set the time.

Chapter 7. Managing User Accounts

This chapter describes how to grant access to users on your system. It tells you how to add and maintain user accounts, and it describes the privileges that you can give and the resources that you can allocate to the users on your system. It also describes the system management features of the OpenVMS Mail utility (MAIL).

Information Provided in This Chapter

This chapter describes the following tasks:

Task

Section

Managing system-supplied UAF accounts

Section 7.4

Preparing to add user accounts

Section 7.5

Adding user accounts

Section 7.6

Using command procedures for interactive accounts

Section 7.7.1

Modifying a user account

Section 7.7.2

Listing user accounts

Section 7.7.3

Maintaining the user environment

Section 7.7.4

Deleting a user account

Section 7.7.5

Restricting the use of accounts

Section 7.8

Using login procedures for restricted accounts

Section 7.8.5

Setting up special accounts

Section 7.9

Managing Mail

Section 7.10

Managing system resources

Section 7.11

This chapter explains the following concepts:

Concept

Section

Understanding the user authorization file

Section 7.1

Understanding the protection of authorization files

Section 7.2

Understanding UAF login checks

Section 7.3

Understanding system-supplied UAF accounts

Section 7.4.1

Understanding account security

Section 7.5.3

Understanding network proxy accounts

Section 7.9.3

Understanding pages and pagelets

Section 7.11.1

7.1. Understanding the User Authorization File

The system user authorization file (UAF), SYS$SYSTEM:SYSUAF.DAT, contains user account records. Each record consists of fields that provide information about the account's user name, login characteristics, login restrictions, and resource control attributes. You specify the account user name as a parameter to AUTHORIZE commands; the other fields are specified as qualifiers to AUTHORIZE commands.

The system uses the UAF to validate login requests and to setup processes for users who successfully log in. You create, examine, and modify UAF records with the Authorize utility (AUTHORIZE).

You can assign the following resource control attributes in the UAF record:
  • Priority

  • Limits and quotas

  • Privileges

The following sections briefly discuss these resource control attributes.

7.1.1. Priority

A user's priority is the base process priority that the system uses to schedule computer time for the process associated with the user's account.

On VAX systems, priorities range in value from a low of 0 to a high of 31. 0 through 15 are timesharing priorities; 16 through 31 are real-time priorities.

On Alpha and I64 systems, priorities range in value from a low of 0 to a high of 63. 0 through 15 are timesharing priorities; 16 through 63 are real-time priorities.

The system schedules processes with real-time priorities strictly according to base priority—the executable real-time process with the highest base priority executes first. Processes with timesharing priorities are scheduled according to a slightly different principle, to promote equitable service to all users.

Leave the base priority at the default of 4 for timesharing accounts.

7.1.2. Limits and Quotas

Limits are set on system resources that can be reused; for example, the amount of memory that a process can use for I/O requests. Most limits restrict the use of physical memory. You set limits for processes associated with accounts through the appropriate UAF fields. You can change some of these limits later with DCL commands or by calling system services from programs.

A process passes on its resources to a subprocess (for example, when you create a subprocess with the SPAWN command) in one of several ways, depending on the resource type. Table 7.1 lists the different resource types.
Table 7.1. Resource Type Limits

Resource Type

Description of Limit

Pooled

A process and its subprocesses share the resource on a first-come, first-served basis until the limit is reached.

Nondeductible

A subprocess receives the same limit on the resource as the creator receives. The creator's limit is not affected.

Deductible

A subprocess receives a portion of the creator's resource. That portion is deducted from the creator's limit.

Systemwide

A process and all created subprocesses with the same user name or account share the total limit on a first-come, first-served basis.

Normally, leave limits at their default values. For the default values for the system and user accounts, see the sample SYSTEM and DEFAULT user authorization file records supplied with the Authorize utility on your distribution kit. Also see Section 7.11for a full description of limits and quotas.

7.1.3. Privileges

Privileges determine what functions users are authorized to perform on the system. System manager functions require privileges that are denied to most users. Because the SYSTEM account has full privileges by default, exercise caution in using it. For example, if you log in to the SYSTEM account, you can modify and delete any file regardless of its protection.

Table 7.2 categorizes system privileges and includes a brief definition of the activity permitted with each privilege. See the VSI OpenVMS Guide to System Security for a full description of privileges.
Table 7.2. System Privileges
CategoryPrivilegeActivity Permitted
NoneNoneNone requiring privileges
NormalNETMBXCreate network connections
TMPMBXCreate temporary mailbox
GroupGROUPControl processes in the same group
GRPPRVGroup access through system protection field
DevourACNTDisable accounting
ALLSPOOLAllocate spooled devices
BUGCHKMake machine check error log entries
EXQUOTAExceed disk quotas
GRPNAMInsert group logical names in the name table
PRMCEBCreate/delete permanent common event flag clusters
PRMGBLCreate permanent global sections
PRMMBXCreate permanent mailboxes
SHMEMCreate/delete structures in shared memory
SystemALTPRISet base priority higher than allotment
AUDITGenerate audit records
OPERPerform operator functions
PSWAPMChange process swap mode
SECURITYControl any process
SYSLCKPerform security-related functions
WORLDLock systemwide resources
ObjectsDIAGNOSEDiagnose devices
IMPORTMount a non-labeled tape volume
MOUNTExecute mount volume QIO
SYSGBLCreate systemwide global sections
VOLPROOverride volume protection
READALLBypass existing restrictions to read an object
AllBYPASSDisregard protection
CMEXECChange to executive mode
CMKRNLChange to kernel mode
DETACHCreate detached processes of arbitrary UIC
DOWNGRADEWrite to a lower secrecy object or lower an object's classification
LOG_IOIssue logical I/O requests
PFNMAPMap to specific physical pages
PHY_IOIssue physical I/O requests
READALLPossess read access to all system objects
SETPRVEnable any privilege
SHAREAccess devices allocated to other users
SYSNAMInsert system logical names in the name table
SYSPRVAccess objects through system protection field
UPGRADEWrite to a higher integrity object or raise an object's integrity level

Because certain images (such as SET.EXE) require access to the system UAF and are normally installed with the SYSPRV privilege, make sure you always grant system access to SYSUAF.DAT.

7.2. Understanding the Protection of Authorization Files

To display the protection codes for any file, use the DCL command DIRECTORY/PROTECTION.

Authorization files are created with the following default protections:
  • User authorization file, SYSUAF.DAT

    The user authorization file, SYSUAF.DAT, is created with the following default protection:
    SYSUAF.DAT      S:RWED, O:RWED, G, W
  • Proxy authorization files, NETPROXY.DAT and NET$PROXY.DAT

    Two proxy authorization files, NETPROXY.DAT and NET$PROXY.DAT, are created with the following default protections:

    NETPROXY.DAT   S:RWED, O:RWED, G, W
    NET$PROXY.DAT  S, O, G, W 
    The primary proxy database that the system uses is the NET$PROXY.DAT file. NETPROXY.DAT is maintained:
    • For use by DECnet for OpenVMS

    • For backward compatibility

    See Section 7.9.3 for more details about network proxy accounts.

  • Rights database file, RIGHTSLIST.DAT

    The RIGHTSLIST.DAT authorization file is created with the following default protection:
    RIGHTSLIST.DAT  S:RWED, O:RWED, G, W  

The procedures for adding a user account are discussed in detail in Section 7.6. Because the UAF is the prime repository for storing information about user accounts, it is important to understand its components before you add accounts.

7.3. Understanding UAF Login Checks

This section describes the system checks the login fields of the UAF when a user attempts to login.

When a user activates a terminal (by turning it on and pressing Return if directly connected, by dialing in to a system and observing the remote connect protocol, or by connecting via a LAT), and that terminal is not allocated by a user process, the system prompts for a name and password. The user must enter a name and password combination that exists in a UAF record, or the system denies the user further access. If the name and password are accepted, the system performs the operations in Table 7.3.
Table 7.3. System Login Flow

Step

Action

Result

1.

System examines the login flags.

The system begins with DISUSER. If the DISUSER flag is set, the login attempt fails.

Note that setting this flag for powerful, infrequently used accounts (such as Field Service accounts) eliminates the risk of guessed passwords for those accounts.

2.

System verifies primary or secondary day restrictions.

After checking the current day type, the system determines whether hourly login restrictions are in effect (as defined by the /ACCESS,/DIALUP, /INTERACTIVE, /LOCAL, and /REMOTE qualifiers). If the current hour is restricted, the login fails immediately. VSI recommends that you limit nonbatch access of the SYSTEM account by using access times and day types. See Section 7.8.1 and Section 7.8.2.

3.

System passes control to the command interpreter.

The command interpreter is named in the user's UAF record; for example, DCL.

4.

System checks whether SYS$LOGIN is defined.

If SYS$LOGIN is defined, the logical name is translated (in the case of DCL, to SYS$MANAGER:SYLOGIN.COM) and that procedure executes.

If SYS$SYLOGIN is not defined, no system login is run.

If a command procedure is specified in the LGICMD field and that procedure exists, it executes. Otherwise, if the LGICMD field is blank, the user's command file (named LOGIN.COM if the CLI is DCL), which is located in the SYS$LOGIN directory, executes automatically (if it exists).

The system will not execute both a command procedure specified in the LGICMD field and a user's LOGIN file; if a procedure is specified in the LGICMD field, the system uses that procedure by default. You can, however, instruct the system to execute a user's LOGIN by calling it from within the procedure specified in LGICMD.

After a successful login, the command interpreter prompts for user input (DCL usually displays a dollar sign), and the user responds with commands acceptable to the command interpreter. (DCL accepts those commands documented in the VSI OpenVMS DCL Dictionary.) However, the system prohibits activities that violate the user's privilege allowance or exceed resource quotas.

7.4. Managing System-Supplied UAF Accounts

Typically, you use the UAF supplied with the distribution kit. (You can, however, rename the UAF with the DCL command RENAME, and then create a new UAF with AUTHORIZE.) Allow access to this file only to those with SYSTEM privileges. See the AUTHORIZE section in the VSI OpenVMS System Management Utilities Reference Manual for guidelines on protecting system files.

The UAF is accessed as a shared file. Updates to the UAF are made on aper-record basis, which eliminates the need for both a temporary UAF and a new version of the UAF after each AUTHORIZE session. Updates become effective as soon as you enter AUTHORIZE commands, not after the termination of AUTHORIZE.(For this reason, do not enter temporary values with the intent of fixing them later in the session.)

The Authorize utility (AUTHORIZE) provides a set of commands and qualifiers to assign values to any field in a UAF record. See the Authorize utility section in the VSI OpenVMS System Management Utilities Reference Manual for complete information about UAF record fields and the commands and qualifiers used to assign attributes to these fields.

7.4.1. Understanding System-Supplied UAF Accounts

On VAX systems, the UAF on software distribution kits contains five accounts: DEFAULT, FIELD, SYSTEM, SYSTEST, and SYSTEST_CLIG.

On Alpha and I64 systems, DEFAULT and SYSTEM accounts are created for you. You can use SYS$MANAGER:CREATE_SPECIAL_ACCOUNTS.COM to create SYSTEST, SYSTEST_CLIG, and Field Service accounts, as explained in Section 7.4.2.

Table 7.4 describes system-supplied UAF accounts.
Table 7.4. System-Supplied UAF Accounts

UAF Record

Description

DEFAULT

Serves as a template for creating new user accounts. A new user account is assigned the values of the DEFAULT account except where you explicitly override those values. Thus, whenever you add a new account, you need only specify values for fields that you want to be different. You cannot rename or delete the DEFAULT account from the UAF.

The following AUTHORIZE command creates a new account having the same values as the DEFAULT account, except that the password, UIC, and default directory fields are changed:
UAF> ADD MARCONI/PASSWORD=QLP6YT9A/UIC=[033,004]/DIRECTORY=[MARCONI]

Section 7.6 gives an example of how to use AUTHORIZE to add a user account. Section 7.7.4 explains how to create and use additional default templates.

FIELD

Permits VSI support representatives to test a new system.

On VAX systems, the default Field Service account has the user name FIELD.

On Alpha and I64 systems, you name Field Service accounts for specific VSI support representatives; for example, Mary_Smith or John_Jones.

SYSTEM

Provides a means for you to log in with full privileges. You can modify the record for the system manager's account but you cannot rename it or delete it from the UAF.

Caution

Do not change the SYSTEM account UAF record fields for the default device, directory, and privileges. Installation of maintenance releases of the operating system and optional software products depends on certain values in these fields.

Note any hourly or daily restrictions that you have implemented on the SYSTEM account when performing upgrades from the SYSTEM account.

SYSTEST

Provides an appropriate environment for running UETP, a User Environment Test Package, on standalone systems. (See VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.)

SYSTEST_CLIG

Provides an appropriate environment for running UETP in an OpenVMS Cluster environment. SYSTEST_CLIG accounts have no passwords associated with them.(See VSI OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.)

7.4.2. Creating Accounts On Alpha and I64 systems (Alpha and I64 Systems)

On Alpha and I64 systems, you can use the SYS$MANAGER:CREATE_SPECIAL_ACCOUNTS.COM command procedure to create SYSTEST, SYSTEST_CLIG, and multiple Field Service accounts.

7.4.2.1. Creating Field Service Accounts (Alpha Only)

On Alpha and I64 systems, you can use CREATE_SPECIAL_ACCOUNTS.COM to create accounts for VSI support representatives. In creating these accounts, follow these guidelines:
  • Create an account for each VSI support (Field Service) representative rather than just one account called FIELD for all the representatives. Note that you must use the command procedure for each account you want to create.

  • Use account names that represent the actual names of support representatives, not a generic name such as FIELD.

The following example shows typical dialogue with CREATE_SPECIAL_ACCOUNTS.COM when it is used to create a field service account:
$ @CREATE_SPECIAL_ACCOUNTS.COM
    This procedure creates accounts.
      Passwords may be needed for the following accounts:
        SYSTEST, Field Service
      Passwords must be a minimum of 8 characters in length.  All passwords
      will be checked and verified.  Any passwords that can be guessed easily
      will not be accepted.
* Do you want to create an account for SYSTEST (Y/N): N [Return]
* Do you want to create an account for SYSTEST_CLIG (Y/N): N [Return]
* Do you want to create an account for Field Service (Y/N): Y [Return]
* Enter username for Field Service account: john_jones [Return]
* Enter password for JOHN_JONES: * Re-enter for verification:
* Re-enter for verification:
$

Note that the system does not display the password or password verification that you enter.

Disabling Field Service Accounts (Alpha Only)

You can use the Authorize utility (AUTHORIZE) to disable VSI support representative accounts when these accounts are not in use and enable them again when they are needed.

To disable an account, use the AUTHORIZE command in the following format:
MODIFY username/FLAGS=DISUSER
For example:
$ RUN SYS$SYSTEM:AUTHORIZE
UAF> MODIFY JOHN_JONES/FLAGS=DISUSER

The login flag DISUSER disables the account and prevents anyone from logging in to the account.

Reenabling Field Service Accounts (Alpha Only)
To reenable an account when it is needed again, run AUTHORIZE and enter the command in the following format:
MODIFY username /FLAGS=NODISUSER
For example:
UAF> MODIFY JOHN_JONES/FLAGS=NODISUSER

7.4.2.2. Creating SYSTEST and SYSTEST_CLIG Accounts (Alpha and I64)

The following example shows typical dialogue with CREATE_SPECIAL_ACCOUNTS.COM when it is used to create SYSTEST and SYSTEST_CLIG accounts:
$ @CREATE_SPECIAL_ACCOUNTS.COM
    This procedure creates accounts.
    Passwords may be needed for the following accounts:
        SYSTEST, Field Service
    Passwords must be a minimum of 8 characters in length.  All passwords
    will be checked and verified.  Any passwords that can be guessed easily
    will not be accepted.
* Do you want to create an account for SYSTEST (Y/N): Y
* Enter password for SYSTEST:
* Re-enter for verification:
* Do you want to create an account for SYSTEST_CLIG (Y/N): Y
    The SYSTEST_CLIG account will be disabled.  You must reenable
    it (/FLAGS=NODISUSER) before running UETP but do not assign a password.
* Do you want to create an account for FIELD_SERVICE (Y/N): N
$
Enabling SYSTEST_CLIG Accounts (Alpha and I64)
Although you create a SYSTEST_CLIG account using CREATE_SPECIAL_ACCOUNTS.COM, the account is disabled. Enable the account using the /FLAGS=NODISUSER command; for example:
UAF> MODIFY SYSTEST_CLIG/FLAGS=NODISUSER
Disabling SYSTEST_CLIG Accounts (Alpha and I64)
To disable a SYSTEST_CLIG account again, use the /FLAGS=DISUSER command; for example:
UAF> MODIFY SYSTEST_CLIG/FLAGS=DISUSER

7.4.3. Maintaining System-Supplied Accounts (VAX Only)

Immediately after installing a VAX system, make the following changes in the UAF:
  1. Disable the FIELD and SYSTEST accounts. Also disable any infrequently used accounts.

    To disable an account, use the AUTHORIZE command in the following format:
    MODIFY username/FLAGS=DISUSER
    For example:
    $ RUN SYS$SYSTEM:AUTHORIZE
    UAF> MODIFY WOLF/FLAGS=DISUSER

    The login flag DISUSER disables the account and prevents anyone from logging in to the account.

    To enable the account when it is needed, run AUTHORIZE and enter the command in the following format:
    MODIFY username /FLAGS=NODISUSER
  2. Optionally, change fields in the DEFAULT account. For example:
    UAF> MODIFY DEFAULT/DEVICE=DISK$USER/WSQUO=750

    In this example, the default device is set to the name most commonly used for user accounts that will be added. Likewise, the working set value is set to a value appropriate for most users on the system.

7.4.4. Using the SYSTEM Account

Use the SYSTEM account only for system functions such as performing backups and installing maintenance updates. The SYSTEM account has full privileges enabled by default, so exercise caution when you use it. For example, because you have BYPASS privilege, the system allows you to delete any file, no matter what its protection. If you enter an incorrect name or spurious asterisk, you might destroy files that you or other users need to keep. Consider using an account with fewer privileges for daily system management activities.

If you decide not to use the SYSTEM account for daily system management activities, you can still receive mail from the SYSTEM account. To do this, log in to the SYSTEM account, invoke Mail, and use the SET FORWARD command in the following format to forward the mail to another account:
SET FORWARD node::username
For example:
$ MAIL
MAIL> SET FORWARD WINSTON::WOLF
MAIL> EXIT 

Caution

Do not use DISUSER for user name SYSTEM if SYSTARTUP_VMS.COM submits batch jobs. Disable all access except Batch in these cases.

Also, be careful not to disable all of your privileged system accounts. If you inadvertently do so, you can recover by setting the system parameter UAFALTERNATE during a conversational boot operation. See Chapter 4 for information about emergency startup procedures.

7.4.5. Using AUTHORIZE to Maintain UAF Accounts

Using the Authorize (AUTHORIZE) utility, you create and maintain UAF accounts by assigning values to various fields within each account record. The values you assign perform the following actions:
  • Identify the user

  • Define the user's work environment

  • Control use of system resources

How to Perform This Task

  1. Set your default to the directory that contains the SYSUAF.DAT file, typically, SYS$SYSTEM.

  2. Gain access to a specific user record by running AUTHORIZE.

  3. Enter the SHOW command (see example) to display a specific user record.

  4. Enter AUTHORIZE commands such as ADD and MODIFY to create or change the information in the fields of the UAF record.

See Section 7.11 for a list of privileges, limits, and quotas that you can specify in the resource control and privileges fields of the UAF record.

Example

$ RUN SYS$SYSTEM:AUTHORIZE
UAF> SHOW WELCH
The following example shows a typical user record for a restricted user account. Callouts describe the fields.
Username: WELCH                            Owner:  ROB WELCH   1
Account:  INVOICE                          UIC:    [21,51] ([INV,WELCH])
CLI:      DCL                              Tables: DCLTABLES   2
Default:  USER3:[WELCH]
LGICMD:
Login Flags:  Diswelcome Disnewmail                            3
Primary days:    Mon Tue Wed Thu Fri
Secondary days:                     Sat Sun
Primary   000000000011111111112222  Secondary 000000000011111111112222
Day Hours 012345678901234567890123  Day Hours 012345678901234567890123
Network:  ------ No access -------            ----- Full access ------
Batch:    #########--------#######            ---------#########------
Local:    #########--------#######            ---------#########------
Dialup:   ----- Full access ------            ------ No access -------
Remote:   ----- Full access ------            ------ No access -------
Expiration:            (none)    Pwdminimum:  6   Login Fails:     0

Pwdlifetime:            30       Pwdchange:   15-APR-2000 13:58

Last Login:            (none) (interactive),            (none) (non-interactive)
Maxjobs:         0  Fillm:        20  Bytlm:         8192      4
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:        10  JTquota:       1024
Prclm:           2  DIOlm:        10  WSdef:          150
Prio:            4  ASTlm:        10  WSquo:          256
Queprio:         4  TQElm:        10  WSextent:       512
CPU:        (none)  Enqlm:       100  Pgflquo:      10240
Authorized Privileges:
  TMPMBX NETMBX 5
Default Privileges:
  TMPMBX NETMBX
Identifier 6                    Value              Attributes 7
  PROJECT_X                        %X8001001E         RESOURCE NODYNAMIC
  DOCU_PROC                        %X80010044         NORESOURCE NODYNAMIC

1

User identification fields contain information used by the system for accounting purposes and user identification.

2

Default fields contain the default specifications for the following elements:
  • Command language interpreter (CLI) is Digital Command Language (DCL) by default.

  • Name of the command procedure to be executed automatically at login time. If the field is blank, the system uses the default CLI (DCL), and executes SYS$LOGIN:LOGIN.COM by default.

  • Command language interpreter tables (if blank, same as CLI field).

  • Device and directory names for default file access.

3

Login characteristics fields impose specific login restrictions that perform the following actions:
  • Inhibit certain login functions.

  • Control the days of the week when various types of logins are permitted.

  • Control the times of day when various types of logins are permitted.

4

Resource control fields control system resources by:
  • Limiting the use of system resources such as physical memory and CPU time.

  • Specifying the base priority used in scheduling the process that the system creates for the user.

5

Privileges fields specify the privileges that allow use of restricted and sensitive system functions.

6

Identifier fields list the ACL identifiers that the user holds and that are recorded in the rights database file.

7

Attributes fields list the characteristics specified when adding identifiers to the rights database or when granting identifiers to users.

7.5. Preparing to Add User Accounts

This section describes what to do before adding a user account.

7.5.1. Choosing an Account Type

How you set up a user account depends on the needs of the individual user. Table 7.5 lists the account types and their characteristics.
Table 7.5. Account Types

Account Type

Characteristics

Interactive

This account has access to the system software. Work of a general nature, such as program development or text editing, is performed in this account. Usually, such an account is considered an individual account.

Limited Access

This account provides controlled login to the system and, in some cases, has only a subset of user software available. Limited-access accounts ensure that the system login command procedure (SYLOGIN.COM) and the process login command procedure (specified by the /LGICMD qualifier in the UAF), as well as any command procedures they call, are executed. (See the VSI OpenVMS Guide to System Security for information about writing limited access account command procedures.) The two types of limited accounts are: restricted and captive.

Restricted

Used for network objects like Mail, for network proxy accounts, or for implementing user authentication systems like smart cards.

Captive

Limited by function; that is, only those who perform a particular function can use it (for example, an inventory system). Anyone whose job entails inventory control can access your system, but that person cannot access other subsystems or the base software. You might also use a captive account to run batch operations during unsupervised periods or to run applications programs with information you want to keep private.

7.5.2. Performing Additional Tasks

When adding a user account, you must perform the following steps:
  1. Select a user name and password.

  2. Select a user identification code (UIC).

  3. Decide where the account's files will reside (which device and directory).

  4. Use the System Management utility (SYSMAN) to add a disk quota entry for this UIC, if disk quotas are in effect. You can do this only after you have created the user's account with the Authorize utility.

  5. Create a default directory on the appropriate volume, using the following DCL command format:
    CREATE/DIRECTORY directory-spec/OWNER_UIC=uic
  6. Determine the security needs of the account (that is, the level of file protection, privileges, and access control).

  7. Estab