1397 lines
64 KiB
Plaintext
1397 lines
64 KiB
Plaintext
VMS
|
|
System Managers Manual
|
|
ORDER NUMBER AA-LA00A-TE
|
|
Typed in by: Guardian Of Time
|
|
|
|
|
|
This Manual provides the basic concepts and procedures for VMS system
|
|
management; it is especially inteded for managers of small clusters and
|
|
systems.
|
|
|
|
Chapter 1
|
|
Introduction
|
|
|
|
The VMS operating system and the other software products that run on your
|
|
computer provide you and the other users on your system w/ a wide range of
|
|
computing capabilities. In order to create and maintain a proper and
|
|
efficient computing environment, certain administrative tasks must be
|
|
undertaken. These tasks are called SYSTEM MANAGEMENT, and they include the
|
|
following:
|
|
|
|
: Setting up the system
|
|
: Giving individual users access to the system
|
|
: Installing software (and software updates)
|
|
: Managing acceptable performance levels
|
|
: Preventing the loss of important information that you keep on line
|
|
: Making sure that the system is secure
|
|
: Handling media (such as disks/magnetic tapes)
|
|
: setting up the software to allow for printers and for batch jobs
|
|
: Setting up a cluster
|
|
: Setting up a network
|
|
|
|
As system manager, you may need to do some of these tasks only once (for
|
|
example, setting up software to allow for printers or batch jobs, or setting
|
|
up a network); others are done on a continuing basis (for example, maintaining
|
|
system security and preventing the loss of data). At some sites, one or more
|
|
people are designated as SYSTEM MANAGERS, and other individuals are designated
|
|
as OPERATORS. In these cases, operators are responsible for tasks such as
|
|
physically mounting magnetic tapes and disks, monitoring printers, responding
|
|
to emergencies or security alarms, and maintaining system log files.
|
|
|
|
Not all of the tasks described in this manual may be necessary for your site.
|
|
This chapter provides an overview of the information that this manual
|
|
contains. You should read this introductory chapter to determine which parts
|
|
of the manual may be applicable to your site.
|
|
|
|
<NOTE: I overlooked section 1.1 because all it does is say that system >
|
|
< Managers should use this chapter / Operators should use this Chapter >
|
|
< there was NO usefull information on that part...Guardian of Time >
|
|
|
|
1.2 SYSTEM MANAGEMENT CONCEPTS AND TERMS
|
|
|
|
Some concepts and terms are used frequently in system management, and you
|
|
should become familiar w/ them. The following terms and concepts are used
|
|
both in the context of everday general use in a VMS system and in the context
|
|
of system management; they are described in the VMS GENERAL USER'S MANUAL:
|
|
|
|
: Accounts and directories
|
|
: Command Procedures
|
|
: Digital Command Language (DCL)
|
|
|
|
The following concepts and terms apply primarily to system management:
|
|
|
|
: SYSTEM account and [SYSMGR] directory
|
|
|
|
The SYSTEM account is reserved for use by the system manager. When you
|
|
are logged into the SYSTEM ACCOUNT, your default directory (Which is also
|
|
reserved for the system manager) is SYS$SYSROOT:[SYSMGR].
|
|
|
|
Always be carefule when you are logged into the SYSTEM account. When you
|
|
are logged into the SYSTEM account, all privileges are enabled, by default.
|
|
You need these privileges to perform many system management tasks; however,
|
|
they can also produce unwanted or even destructive results if you use them
|
|
carelessly.
|
|
|
|
: CONSOLE (OPERATOR'S) TERMINAL
|
|
|
|
You can perform most system management tasks from any terminal that is
|
|
connected to the processor (or the cluster). However, certain tasks such
|
|
as bootstrapping the system and communicating w/ the VAX processor's
|
|
console subsystem must be performed at a special terminal called the
|
|
CONSOLE TERMINAL.
|
|
|
|
The console terminal, which always has the designation OPA0, is also
|
|
usually designated as the OPERATOR'S TERMINAL. You use the operator's
|
|
terminal to send messages to system users and respond to user requests,
|
|
using the operator communication process (OPCOM).
|
|
|
|
CHAPTER 2 -- STARTING UP THE SYSTEM
|
|
|
|
The system startup procedure establishes the computing environment for your
|
|
system
|
|
|
|
This chapter covers three major topics:
|
|
|
|
: How to start your system for the first time
|
|
: How to create the proper computing environment whenever you restart your
|
|
system
|
|
: How to shut down your system
|
|
|
|
Before you can use the procedures described in this chapter, you must girst
|
|
set up the hardware for each VAX processor. To set up the hardware and
|
|
install the VMS operating system, refer to the instructions in your VAX
|
|
processor installation and operations guide. After you have installed the
|
|
operating system, you will be able to log into the SYSTEM account on your
|
|
computer.
|
|
|
|
After the operating system has been successfully loaded, you can set up the
|
|
proper computing environment for your system. The site-specific system
|
|
startup file, SYSTARTUP_V5.COM, is an essential aspect of establishing an
|
|
environment specific to the needs of your site. Section 2.4 describes how to
|
|
modify SYSTARTUP_V5.COM to meet the needs of your site.
|
|
|
|
2.1 STARTING UP YOUR SYSTEM FOR THE FIRST TIME
|
|
|
|
Instufctions for installing the VMS operating system are included in the
|
|
installation and operations guide for your processor. You must choose whether
|
|
you are installing the VMS operating systsm as a new installation or as an
|
|
upgrade. If you are installing the VMS operating system for the first time,
|
|
you must use the new installation procedure. If you already have a previous
|
|
version of the VMS operating system on your processor, then you should use the
|
|
upgrade prodcedure. Instructions for a new unstallation are found in your
|
|
processor installation and operations guide; instructions for an upgrade
|
|
procedure are found in the Release Notes for the VMS operating system.
|
|
|
|
When you install the VMS operating system using the new installation
|
|
procedure, the disk on which you install the operating system is first erased,
|
|
and then a directory structuure and the operating system itself is put in
|
|
place. When you use the upgrade procedure, the files for the VMS operating
|
|
system are replaced (w/ files for the upgraded operating system), and all
|
|
other files on your system disk (for example, data files, executable images
|
|
that are NOT part of the operating system, and so on) remain as they are.
|
|
|
|
CAUTION: if you use the new installation procedure for a processor that
|
|
already has a previous version of the VMS operating system, you will DESTROY
|
|
the previous contents of the disk that you designate as they system disk.
|
|
|
|
2.2 BOOTING THE SYSTEM
|
|
|
|
Booting is the process of loading the operating system from the system disk
|
|
into processor memory. You can perform either a nonstop boot or a
|
|
conversational boot. A nonstop boot is the quickest and easiest method, and
|
|
the operating system will automatically set system parameters that are
|
|
appropriate for most computing activities for your system's hardware
|
|
configuration. A conversational boot requires you to supply more information
|
|
during the boot process, but it allows you to change system parameters during
|
|
the boot procedure. See your VAX processor installation and operations guide
|
|
for detailed booting instructions.
|
|
|
|
After a system shuts down, it must be rebooted before you can use it. Some
|
|
processors provide the capability of an automatice reboot; when you enable
|
|
this feature, the system automatically attempts to reboot itself after it has
|
|
been shut down. For example, if your site experiences a power failure, a
|
|
processor that has automatic reboot enabled restarts itself automatically
|
|
after the power has been restored. See your VAX processor installation and
|
|
operations guide for information about automatic rebooting.
|
|
|
|
In unusual cases, the normal startup procedures will NOT work properly and
|
|
troubleshooting may be necessary. Section 2.9 describes procedures that you
|
|
should follow if the normal startup procedure fails, or if you find yourself
|
|
locked out of your system.
|
|
|
|
2.3 LOGGING INTO THE NEW SYSTEM
|
|
|
|
When the boot procedure is complete, a message is displayed on the terminal
|
|
from which the system is booted (except on workstations, where the message is
|
|
displayed on the operators window). The message is similar to the following:
|
|
|
|
VAX/VMS VERSION 5.0 08-JUN-1989 07:00:00.00
|
|
|
|
%%%%%%%%%%% OPCOM, <08-JUN-1980 07:00:01.P> %%%%%%%%%%%
|
|
Logfile has been initialized by operator _OPA0:
|
|
Logfile is SYS$SYSROOT: [SYSMGR]OPERATOR.LOG;1
|
|
|
|
%SET-I-INTSET, login interactive limit = 64, Current interactive value = 0
|
|
SYSTEM job terminated at <08-JUN-1980 07:00:00.00
|
|
|
|
After you see this display, you can then log into the system managers account,
|
|
using the following procedure:
|
|
|
|
1. Press the RETURN/ENTER key on the console terminal.
|
|
2. In response to the system's request for your USERNAME, type SYSTEM.
|
|
3. In response to the system's request for your PASSWORD, type the password
|
|
that you chose for the sysstem account during installation. You should
|
|
change your system password immediatly after logging into the system for
|
|
the first time. To change your password, enter the DCL command SET
|
|
PASSWORD.
|
|
|
|
CAUTION: DIGITAL recommends that you change the system manager's account
|
|
password frequently to maintain system security. The system manager's account
|
|
has full privileges by default; therefore, you should exercise caution when
|
|
using it.
|
|
|
|
After you enter your password, the system prints a welcome message on the
|
|
console terminal. If it is not your first time loggin in, the system also
|
|
prints the time of your last login, for example:
|
|
|
|
Welcome to VAX/VMS Version n.n
|
|
|
|
Last interactive login at 01-Jun-1989 15:13:21.07
|
|
|
|
The command procedure SYS$EXAMPLES:MGRMENU.COM generates the system manager
|
|
menu. This command procedure can serve as a sample for designin site-specific
|
|
system manager menus.
|
|
|
|
2.4 STARTUP COMMAND PROCEDURE FOR YOUR SITE (SYSTARTUP_V5.COM)
|
|
|
|
A command procedure that sets up a computing environment for the specific
|
|
needs of your site is executed each time that your system starts up. This
|
|
file is located in the system manager's directory, [SYSMGR], and it is called
|
|
SYSTARTUP_V5.COM. In order to customize SYSTARTUP_V5.COM for the needs of
|
|
your site, you must make the appropriate edits to the file. This section
|
|
describes how to customize the SYSTARTUP_V5 command procedure.
|
|
|
|
After you install the VMS operating system, the file SYSTARTUP_V5.COM is
|
|
placed in the [SYSMGR] directory. SYSTARTUP_V5.COM is a template file, which
|
|
means that it can be used as a basis or guide for creating a startup file that
|
|
suits your own system. In particular, the SYSTARTUP_V5.COM template includes
|
|
sections that can perform the following tasks at startup time:
|
|
|
|
: Mounting public disks
|
|
: Setting the charactersistics of terminals and other devices
|
|
: Initializing and starting queues
|
|
: Installing known images
|
|
: Starting up the DECnet network
|
|
: Running the System Dump Analyzer
|
|
: Purging the operator's log file
|
|
: Submitting batch jobs that are run at system startup time
|
|
: Limiting the number of interactive users
|
|
: Starting up the LAT network
|
|
: Site-specific LAT command procedure
|
|
: Creating systemwide announcements
|
|
: Defining a system login command procedure
|
|
: Backing up the system
|
|
|
|
To modify SYSTARTUP_V5.COM, you can use any text editor. This file is a
|
|
command procedure, so any changes that you make must conform to the rules for
|
|
command procedures, as described in the VMS GENERAL USER'S MANUAL. In order
|
|
tobe used as a site-specific startup file, be sure to keep the file in the
|
|
[SYSMGR] directory and use the file name SYSTARTUP_V5.COM.
|
|
|
|
To allow SYSTARTUP_V5.COM to continue in the event of an error, include the
|
|
DCL command SET NOON at the beginning of the file, as follows:
|
|
|
|
$ SET NOON
|
|
|
|
This command disables error checking after the execution of each command in
|
|
the SYSTARTUP_V5.COM.
|
|
|
|
The following sections describe many of the elements of your userr environment
|
|
that you can establish w/ SYSTARTUP_V5.COM.
|
|
|
|
2.4.1 MOUNTING PUBLIC DISKS
|
|
|
|
A public disk is a disk that can be accessed by any system process. In order
|
|
to make a public disk available for use, the disk must be physically mounted
|
|
and you must then use the MOUNT command. You do not need to use the mount
|
|
command for the system disk, because the system disk is alreadymounted when
|
|
the system starts up.
|
|
|
|
This section describes how to mount disks in the SYSTARTUP_V5.COM file. If
|
|
your system uses any disks that should be mounted whenever the system is
|
|
running, you should read this section.
|
|
|
|
To include MOUNT commands in SYSTARTUP_V5.COM to mount your public disks for
|
|
systemwide access, use the following MOUNT command syntax:
|
|
|
|
$ MOUNT/SYSTEM ddcu: volume_label logical_name
|
|
|
|
You use the /SYSTEM qualifier to mount the disk for systemwide access; this is
|
|
caolled a public volume. If you are in a VAXcluster environment, then you
|
|
should also use the /CLUSTER qualifier in order to make the volume accessible
|
|
to any user in the cluster.
|
|
|
|
The expression ddcu represents the physical device name. You must always
|
|
include a colon after the device name. The expression volume_label is a label
|
|
that you choose for the disk. For example, if you mount a disk w/ the
|
|
physical device name DRA1, and you choose USERFILES as the volume label for
|
|
this disk, then you would include the following command in the
|
|
SYSTARTUP_V5.COM file:
|
|
|
|
$ MOUNT DRA1: USERFILES
|
|
|
|
The expression logical_name, in the context of the MOUNT command, is a logical
|
|
volume name that is associated q/ the volume that you mount. You can use the
|
|
logical volume name (instead of the physical device name) in programs and
|
|
procedures that are used on your system, and it is not necessary to know the
|
|
physical drive on which the volume is mounted.
|
|
|
|
If you do not specify a logical volume name in the MOUNT command, then the
|
|
logical volume name is in the form DISK$volume_label. In the previous
|
|
example, where no logical name was specified and the volume label was
|
|
USERFILES, the MOUNT cammand would automatically assign the logical name
|
|
DISK$USERFILES to the disk.
|
|
|
|
The following command produces the logical volume name USER and equates it to
|
|
DRA1, the device name. Note that the logical volume name USER is equivalent
|
|
to DRA1 only while the disk is actually mounted; if the volume is dismounted,
|
|
then the logical volume name no longer has any systemwide meaning.
|
|
|
|
$ MOUNT/SYSTEM DRA1: USERFILES USER
|
|
|
|
2.4.2 SETTING DEVICE CHARACTERISTICS
|
|
|
|
On some systems, certain devices (such as terminals or printers) should have
|
|
the same characteristics whenever the system is running. Characteristics
|
|
includ defining the device as a printer, setting the transmission speed for
|
|
terminals, and so on. You can define these characteristics in the
|
|
SYSTARTUP_V5.COM procedure. REad this section you want to define certain
|
|
characteristics for specific devices on your system.
|
|
|
|
To establish the characteristics of the terminals and other devices on the
|
|
system, use a series of SET commands in SYSTARTUP_V5.COM. Use the SET
|
|
TERMINAL command for terminals; you may want to include comments to remind
|
|
yourself of the user to whom specific terminals may be assigned.
|
|
|
|
Use the SET PRINTER command for printers. Printer characteristics must be
|
|
seet before you establish queues for the printers.
|
|
|
|
The following example shows how you could modify SYSTARTUP_V5.COM to set up
|
|
characterisitcs for terminals and a printer:
|
|
|
|
$ SET TERMINAL TTC2: /SPEED=300 /DEVICE_TYPE=LA36 /PERMANENT !JONES
|
|
$ SET TERMINAL TTD1: /SPEED=9600 /PERMANENT !WRENS
|
|
$ SET TERMINAL TTD4: /SPEED=1200 /PERMANENT !JRSMITH
|
|
$ SET TERMINAL TTG4: /SPEED=1200 /MODEM /PERMANENT !DIALUP1
|
|
$ SET PRINTER /LA11 /PAGE=60 /WIDTH=80 LPA0:
|
|
|
|
For more information about the qualifiers available w/ the SET TERMINAL and
|
|
SET PRINTER commands, see the VMS General Users Manual (NOTE: I'm going to
|
|
start to type that manual up at the same time as this one starting 19-Jun-89).
|
|
|
|
2.4.3 PRINTERS AND BATCH PROCESSING: INITALIZING AND STARTING QUEUES
|
|
|
|
If your system has a printer that you want to make available for general use
|
|
(that is, a printer that is not connected directly to an individual terminal),
|
|
youmust establish a print queue. Similarly, if you want to allow batch
|
|
processing on your system, you must establish a batch queue. A quese allows
|
|
users to submit requests for printing or batch processing, and the system
|
|
prints or processes the user' jobs as resources allow.
|
|
|
|
If you want to include printing or batch processing capabliities on your
|
|
system, you should include commands in SYSTARTUP_V5.COM that do the following:
|
|
|
|
1: Start the system job queue manager
|
|
2: Initialize and start each queue w/ a separate INITALIZ/QUEUE/START command
|
|
line
|
|
|
|
The following example shows how to start the system job queue manager and
|
|
initialize and start queues in SYSTARTUP_V5.COM:
|
|
|
|
$ !
|
|
$ ! Start the system job queue manager
|
|
$ !
|
|
$ START/QUEUE/MANAGER
|
|
$ !
|
|
$ ! Set printers spooled and establish printer queues
|
|
$ !
|
|
$ SET PRINTER/LOWER LAO:
|
|
$ SET DEVICE/SPOOLED=SYS$PRINT LPA0:
|
|
$ INITIALIZE/QUEUE/START/DEFAULT=FLAG/NOENABLE_GENERIC LPA0:
|
|
$ !
|
|
$ SET PRINTER/LOWER LPA0:
|
|
$ SET DEVICE/SPOOLED=SYS$PRINT LPB0:
|
|
$ ITITIALIZE/QUEUE/START/DEFAULT=FLAG/NOENABLE_GENERIC LPB0:
|
|
$ !
|
|
$ INITIALIZE/QUEUE/START/GENERIC=(LPA0,LPB0) SYS$PRINT
|
|
$ !
|
|
$ !Establish batch queues
|
|
$ !
|
|
$ INITIALIZE/QUEUE/START/BATCH/JOB_LIMIT=2/BASE_PRIORITY=3 SYS$BATCH
|
|
|
|
NOTE: DIGITAL recommends using the /RESTART qualifier w/ the
|
|
START/QUEUE/MANAGER command. This qualifier causes the queue manager to
|
|
restart automatically if the job controller should abort.
|
|
|
|
A spooled device directs the output of an application to an intermediate file
|
|
until the application program finishes. When the application completes, the
|
|
file is submitted for printing. A spooled device can help balance the
|
|
workload deman on line printers if you are running applications on a
|
|
time-shared system. Use the SET DEVICE/SPOOLED command to establish spooled
|
|
devices.
|
|
|
|
2.4.4 INSTALLING KNOW 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. If you have programs on your system that meet any of the
|
|
following conditions, you should read this section and install such programs
|
|
as known images in the SYSTARTUP_V5.COM startup file:
|
|
|
|
: Programs that are frequently run
|
|
: Programs that are usually run concurrently by several processes
|
|
: Programs that require special privileges
|
|
|
|
All known images must be reinstalled each time the system is rebooted, because
|
|
known file lists are not saved if the system is shut down or fails. You
|
|
include INSTALL commands in SYSTARTUP_V5.COM to install programs as known
|
|
images. Chaper 9 includes a discussion about performance characteristics and
|
|
known images.
|
|
|
|
The following example shows a command sequence that might appear in
|
|
SYSTARTUP_V5.COM for installing additional known images:
|
|
|
|
$ INSTALL
|
|
|
|
ADD/OPEN/SHARED/HEADER_RESIDENT BLISS32
|
|
ADD/OPEN/SHARED MACRO32
|
|
ADD/OPEN DIRECTORY
|
|
|
|
2.4.5 STARTING UP THE DECNET NETWORK
|
|
|
|
The DECnet software lets your system communicate w/ other computers. If you
|
|
install DECnet software on your system, you must include commands in
|
|
SYSTARTUP_V5.COM that start up the DECnet network. REad this section if you
|
|
have the DECnet software on your system.
|
|
|
|
If you have started a batch queue on your system (as described in an earlier
|
|
section), then you should start the network using the following commands in
|
|
SYSTARTUP_V5.COM:
|
|
|
|
$ IF F$SEARCH("SYS$SYSTEM:NETACP.EXE") .NES. "" - ! This is faster, if you
|
|
$ THEN SUBMIT SYS$MANAGER:STARTNET.COM ! have batch queues setup.
|
|
|
|
These commands submit the network startup procedure (SYS$MANAGER:STARTNET.COM)
|
|
as a batch job, which reduces the amount of time it takes to boot your system.
|
|
Alternatively, if you have not started a batch queue, use the following
|
|
command in SYSTARTUP_V5.COM to start up the network:
|
|
|
|
$ IF F$SEARCH("SYS$SYSTEM: NETACP.EXE") .NES. "" THEN @SYS$MANAGER:STARTNET
|
|
|
|
2.4.6 RUNNING THE SYSTEM DUMP ANALYZER
|
|
|
|
In the event of a system failure, the System Dump Analyzer (SDA) can help you
|
|
determine why the system failed. In order to use SDA for this purpose, you
|
|
should make sure that the system dump file is available for analysis and not
|
|
overwritten by a new crash. REad the rest of this section if you want to
|
|
learn about using SDA w/ SYSTARTUP_V5.COM.
|
|
|
|
You can start SDA in your site-specific startup file by using the following
|
|
lines in SYSTARTUP_V5.COM:
|
|
|
|
$ ANALYZE/CRASH_DUMP SYS$SYSTEM: SYSDUMP.DMP
|
|
COPY SYS$ERRORLOG: SYSDUMP.DMP SYSDUMP.BACK
|
|
|
|
For further information, invoke the SDA for an intereactive session upon
|
|
completion of startup, or refer to the SDA documentation in the extended VMS
|
|
documentation set.
|
|
|
|
CAUTION: If you use the page file for the crash dump file, when the system
|
|
reboots, you MUST enter the SDA command COPY to copy the dump[ from the page
|
|
file to another file suitable for analysis. If you fail to perorm the copy
|
|
operation, pages used to save the crash dump information are not released for
|
|
paging, and your system hangs while executing STARTUP.COM in the rebooting
|
|
process.
|
|
|
|
2.4.7 PURGING OPERATORS LOG FILE
|
|
|
|
Each time the system is rebooted, a new version of OPERATOR.LOG is created in
|
|
the SYS$MANAGER directory. You should devise a plan for regular maintenance
|
|
of these files. Adding the following command to SYSTARTUP_V5.COM purges all
|
|
but the last two (2) versions of the operator's log file:
|
|
|
|
$ PURGE/KEEP=2 SYS$MANAGER: OPERATOR.LOG
|
|
|
|
See Chapter 10 for additional suggestions for maintaining the operators log
|
|
files.
|
|
|
|
2.4.8 SUBMITTING BATCH JOBS THAT ARE RUN AT STARTUP TIME
|
|
|
|
Some sites may have batch jobs that are submitted at system startup time. To
|
|
submit such batch jobs, add SUBMIT commands to your SYSTARTUP_V5 file, in the
|
|
following format:
|
|
|
|
$ SUBMIT [/qualifier,...] file-spec
|
|
|
|
In the following example, a batch job is submitted to run a command procedure
|
|
that rebuilds the disks each time the system is initalized.
|
|
|
|
$ SUBMIT SYS$MANAGER: SYSDISK_REBUILD
|
|
|
|
If you submit batch processing jobs in SYSTARTUP_V5.COM, make sure that the
|
|
batch processing jobs are submitted after the batch queues have been
|
|
initialized. See Chapter 5 for more information on submitting batch jobs.
|
|
|
|
2.4.9 DEFINING THE NUMBER OF INTERACTIVE USERS
|
|
|
|
You can set a limit for the number of interactive unsers that are allowed to
|
|
be logged into your system at one time. To do this, include the following
|
|
command in SYSTARTUP_V5.COM:
|
|
|
|
$ STARTUP$INTERACTIVE_LOGINS ==n <- where n is is where you would put a #
|
|
|
|
Where n is the maximum number of interactive users that are perrmitted to log
|
|
in at one time.
|
|
|
|
NOTE: the number of interactive users mujst be set to a value no greater than
|
|
that which is authorized by your VAX processor license.
|
|
|
|
2.4.10 STARTING UP THE LAT NETWORK
|
|
|
|
A LAT network is any local area network where terminal servers and operating
|
|
systems use the Local Area Transport (LAT) protocol. A LAT network can
|
|
coexist on the same Ethernet w/ other protocols. If your system uses a LAT
|
|
network, you should read this section.
|
|
|
|
To configure your system as a service node w/in a LAT network, execute the
|
|
command procedure SYS$MANAGER:LTLOAD.COM from w/in SYSTARTUP_V5.COM.LTLOAD.COM
|
|
starts up the LAT protocl. In the LAT protocol, a VMS operating system
|
|
advertises its services over the Ethernet and responds to connection requests
|
|
from terminal servers supporting user terminals and oterh asynchronous
|
|
devices.
|
|
|
|
to start up the LAT network, add the following command line to
|
|
SYSTARTUP_V5.COM:
|
|
|
|
$ @SYS$MANAGER: LTLOAD
|
|
|
|
To configure a node as a service node that connects only to interactive
|
|
terminals on a terminal server, include the command line shown in the last
|
|
example in SYSTARTUP_V5.COM.
|
|
|
|
However, if you want to use remote printers on a terminal server or to create
|
|
dedicated application services on the VMS service node, you must modify
|
|
LTLOAD.COM
|
|
|
|
SUPPORTING USER TERMINALS ON A TERMINAL SERVER
|
|
|
|
To create a VMS service node on a LAT network that supports only interactive
|
|
terminals is a one-step procedure. You insert the command @SYS$MANAGER:LTLOAD
|
|
into SYSTEARTUP_V5.COM and append any of the following arguments:
|
|
|
|
$ @SYS$MANAGER:LTLOAD "P1" "P2" "P3" "P4"
|
|
|
|
The arguments P1/P4 have the following meanings:
|
|
|
|
P1..Service name..Name of the VMS service. For clustered VMS service nodes,
|
|
use the cluster name as the service name. For independent VMS service nodes,
|
|
use the physical node name.
|
|
|
|
P2 - P4..any of the following: /IDENTIFICATION="string"..Description of the
|
|
node and its services that are advertised over the Ehternet. The default is
|
|
the string defined by the logical name SYS$ANNOUNCE.
|
|
|
|
/ENABLE=group-list..Terminal server groups qualified to establish connections
|
|
w/ the VMS servic node. By defauld, Group 0 is enabled.
|
|
|
|
/DISABLE=group-list..Removes previously enabled terminal server groups.
|
|
|
|
The argument P1 assigns a service name to the node, using the LATCP command
|
|
CREATE SERVICE. Arguments P2 through P4 can be any valid qualifier to the SET
|
|
NODE command.
|
|
|
|
For example, the following command creates the service OFFICE on the VMS node,
|
|
MOE, which is part of the OFFICE cluster.
|
|
|
|
$ @SYS$MANAGER:LTLOAD OFFICE "/ENABLE=1" "/DIABLE=0"
|
|
|
|
2.4.11 CREATING SYSTEMWIDE ANNOUCEMENTS
|
|
|
|
This section describes how to define the following types of systemwide
|
|
announcements in your SYSTARTUP_V5.COM file:
|
|
|
|
: A message to users informing them that the system is available for use
|
|
(after a system boot)
|
|
|
|
: A message to users when first accessing the system for login
|
|
|
|
: A welcoming message when a user logs in
|
|
|
|
When your system has completed the startup procedure and is up and running,
|
|
you can send a message to all connected terminals announcing the system's
|
|
availability. To do this, include a line, w/ an appropriate message w/in the
|
|
quotation marks, before the $EXIT command in your SYSTARTUP_V5.COM file:
|
|
|
|
$ REPLY/ALL/BELL "VMS Operating System at NIGHTMARE 589-7840..READ FOR USE."
|
|
|
|
if you want to display at the beginning of each user's login procedure,
|
|
include a line, w/ an appropriate message w/in the quotation marks, in
|
|
SYSTARTUP_V5.COM:
|
|
|
|
$ DEFINE/SYSTEM SYS$ANNOUNCE "NIGHTMARE, 589-7840 -- AUHTORIZED USE ONLY"
|
|
|
|
You can also display a messge to all interactive users immediately after they
|
|
log in by including a line similar to the folling in SYSTARTUP_V5.COM:
|
|
|
|
$ DEFINE/SYSTEM SYS$WELCOME "Welcome to the VMS Operating System at Nightmare,
|
|
589-7840."
|
|
|
|
If you do not define SYS$WELCOME, the following standard messaged is
|
|
displayed:
|
|
|
|
Welcome to VMS version n.n
|
|
|
|
The SYSTARTUP_V5 command file supplied as a template w/ DIGITAL'S distribution
|
|
kit includes additional command examples for SYS$ANNOUNCE and SYS$WELCOME.
|
|
|
|
You may also want to display various system announcements to users at the time
|
|
they log in. You do this w/ a command in the systemwide login command
|
|
procedure, SYLOGIN.COM, as explained later in this chapter.
|
|
|
|
2.5 DEFINING A SYSTEM LOGIN COMMAND PROCEDURE
|
|
|
|
A system login command procedure is executed for each interactive usree when
|
|
the user logs in. W/ a system login command procedure, you can establish
|
|
elements of a computing environment that are the same for all interactive
|
|
users. To use a system login procedure, you should do as follows:
|
|
|
|
1. Define the logical name SYS$SYLOGIN, usually in your site-specific startup
|
|
file (SYSTARTUP_V5.COM).
|
|
|
|
2. Create a system login command procedure.
|
|
|
|
To define the logical name SYS$SYLOGIN and point to a system login command
|
|
file name SYS$MANAGER:SYLOGIN.COM, include the following line in
|
|
SYSTARTUP_V5.COM:
|
|
|
|
$ DEFINE/SYSTEM/EXEC/NOLOG SYS$SYSLOGIN SYS$MANAGER:SYLOGIN.COM
|
|
|
|
A template for a system login command procedure is found in
|
|
SYS$MANAGER:SYLOGIN.COM. This file includes commands that you can modify and
|
|
add to according to the needs of your site.
|
|
|
|
You can use the system login command procedure to display announcements for
|
|
your site. Todo this, you would do the following:
|
|
|
|
1. Create a text file that has current announcements, for example w/ the
|
|
filename SYS$MANAGER:ANNOUNCEMENTS.TXT. You could then update this file
|
|
(adding/deleting announcements) as needed.
|
|
|
|
2. Include a line at the end of your system login command procedure that
|
|
displays the announcements file, such as the following:
|
|
|
|
$ TYPE SYS$MANAGER: ANNOUNCEMENTS.TXT
|
|
|
|
In addition to a system login command procedure, users can also have their own
|
|
login command procedures. User login command procedures are executed
|
|
immediately after the system login command procedure.
|
|
|
|
2.6 BACKING UP THE SYSTEM
|
|
|
|
To limit the risk of losing your operating system environment, you should
|
|
perform the following sequential operations after installing and customizing
|
|
your system:
|
|
|
|
1. Back up the console volume
|
|
|
|
2. Build a standalone backup kit
|
|
|
|
3. Back up the system disk
|
|
|
|
If your processor has a console storage device, DIGITAL recommends that you
|
|
make a backup copy of your console volume, it is useful to have a backup copy
|
|
in case your original becomes corrupted. The VMS operating system provides a
|
|
command procedure called CONSCOPY.COM in the SYS$UPDATE directory that copies
|
|
your console volume to a blank one.
|
|
|
|
To back up your system disk, DIGITAL recommends that you use standalone
|
|
BACKUP, which uses a subset of Backup Utility qualifiers. If your system was
|
|
not distributed on magnetic tape, youmust build a standalone BACKUP kit either
|
|
on console media or on disk. You can then boot standalone directory root SYSE
|
|
on a Files-11 disk.
|
|
|
|
Installing and using standalone BACKUP in an alternate root on your system
|
|
disk saves time when you are backing up your system disk, because you do not
|
|
have to boot standalone BACKUP from your console volume.
|
|
|
|
NOTE: The procedures for backing up the console volume and backing up the
|
|
system disk vary for different VAX processors. See your VAX processor
|
|
installation and operations guide for the setp-by-step procedures that apply
|
|
to your processor.
|
|
|
|
2.7 BUILDING AND COPYING A VMS SYSTEM DISK
|
|
|
|
The command procedure SYS$UPDATE:VMSSKITBLD is used for building and copying a
|
|
VMS system disk. The procedure provides you w/ the following options:
|
|
|
|
: BUILD -- Destroys all previous information on the target disk and then
|
|
builds the new system disk.
|
|
|
|
: ADD -- Adds another copy of the operating system to an alternate system
|
|
root directory on the same system disk.
|
|
|
|
: COPY -- Copies the operating system files to a target disk w/out
|
|
destroying the files that are currently on the target disk.
|
|
|
|
: COMMON - Initializes the target disk and builds it as a cluster-common
|
|
system disk.
|
|
|
|
CAUTION: The VMSKITBLD BUILD and COMMON options initialize the target disk,
|
|
deleting, all of its previous contents.
|
|
|
|
In some cases, you may want the operating system to exist on another disk.
|
|
The following paragraphs describe two such cases and the procedures that you
|
|
would use.
|
|
|
|
You may want to move your operating system files to another disk. for
|
|
example, assume that your operating system is initally stored on a disk
|
|
together w/ some ofyour user files. Suppose that you want to move only the
|
|
operating system files from original disk to a smaller disk. You can build
|
|
the operating system on the smaller disk (called the target/destination disk)
|
|
w/out affecting the user files on the original disk (the source disk) by using
|
|
the BUILD option of the VMSKITBLD command procedure.
|
|
|
|
You may want to create a separate test envionment where you can modify the
|
|
operating system w/out affecting current operations. You could use the ADD
|
|
option to copy the operating system to an alternate system root directory and
|
|
create a boot command procedure to select that version for testing sessions.
|
|
In addition, you may want to preserve the current version of the operating
|
|
system before upgrading your system to the next major version. To do so, use
|
|
the ADD option to make a copy of the current operating system in an alternate
|
|
system root directory (SYSA) and then upgrade and run the new version of the
|
|
operating system in SYSO.
|
|
|
|
CAUTION: When you copy the system disk using VMSKITBLD.COM, SYSUAF.DAT and
|
|
all user-modified command files are NOT copied onto the target disk.
|
|
VMSKITBLD.COM uses the site-specific template files w/ the TEMPLATE file type
|
|
in building the new system disk.
|
|
|
|
2.8 SYSTEM STARTUP PROCEDURES
|
|
|
|
This section describes the process that the VMS operating system follows when
|
|
you boot your system. This section is mostly informational -- that is, you
|
|
usually do NOT have todo anything during the booting process, but you may want
|
|
to know how the operating system is set up.
|
|
|
|
Each time that your systesm is booted, the VMS operating system initiates a
|
|
startup procedure. The startup procedure includes the execution of the
|
|
following series of command procedures:
|
|
|
|
: SYS$SYSTEM:STARTUP.COM -- A file containing a series of procedures that
|
|
must execute at system startup time in order for
|
|
the system to run properly. STARTUP.COM is the
|
|
site-independent startup command procedure
|
|
supplied by DIGITAL. Do not modify this command
|
|
procedure. The STARTUP.COM procedure invokes
|
|
the site-specific procedures that are described
|
|
in this section.
|
|
|
|
: SYS$MANAGER:SYCONFIG.COM -- A template file suplied by DIGITAL to which you
|
|
can add site-specific configuration commands.
|
|
|
|
: SYS$MANAGER:SYLOGICALS.COM -- A termplate file supplied by DIGITAL for
|
|
defining logical names. This file contains
|
|
a command procedure for adding system logical
|
|
names for a MicroVAX that is not in a cluster
|
|
If your processor is not a standalone Micro
|
|
Vax, you can ignore that section of the
|
|
procedure that pertains only to MicroVax
|
|
systems and add any systemwide logical name
|
|
assignments for your own system to the end
|
|
of this file.
|
|
|
|
: SYS$MANAGER:SYLOGIN.COM -- A template file supplied by DIGITAL to which you
|
|
can add commands that are executed whenever a
|
|
user logs in.
|
|
|
|
: SYS$MANAGER:SYSTARTUP_V5.COM -- A template file supplied by DIGITAL to
|
|
which you can add various commands for
|
|
setting up site-specific operations that
|
|
are executed at startup time. The template
|
|
contains commands that you can modify to
|
|
meet the needs of your processing
|
|
environment.
|
|
|
|
: SYS$MANAGER:SYPAGSWPFILES.COM -- A file supplied by DIGITAL to which you
|
|
can add commands to install page and swap
|
|
files on any disk.
|
|
|
|
Two versions of the template files are included in your VMS distribution kit:
|
|
an executable version w/ the file name extension COM, and a nonexecutable
|
|
version w/ the file exetension TEMPLATE (for example, SYS$MANAGER:SYCONFIG.COM
|
|
and SYS$MANAGER:SYCONFIG.TEMPLATE). The files w/ the COM filetype are
|
|
executed at startup time, and those are the files that you should modify to
|
|
meet the needs of your site. The files w/ the TEMPLATE filetype should NOT be
|
|
modifed.
|
|
|
|
CAUTION: Do NOT delete the DIGITAL-supplied template command files w/ the
|
|
TEMPLATE file type. The VMSKITBLD.COM procedure uses the TEMPLATE versions to
|
|
create a new system disk.
|
|
|
|
More information on STARTUP.COM and the site-specific command procedures is
|
|
provided in the sections that follow.
|
|
|
|
2.8.1 STARTUP COMMAND PROCEDURE FOR THE SYSTEM (STARTUP.COM)
|
|
|
|
This section describes the system startup file (STARTUP.COM). STARTUP.COM is
|
|
executed whenever the system is booted, and it creates the basic environment
|
|
for the operating system and some software products. It is not a startup file
|
|
that is customized for your site. You should not modify the STARTUP.COM file.
|
|
Read this section if you are interested in learnig about the startup porcess.
|
|
|
|
The file SYSTARTUP_V5.COM, which is also executed each time the system is
|
|
booted, is the startup file where you include features specific to your site.
|
|
To learn how to customize the startup process for your site by modifying
|
|
STARTUP_V5.COM, see section 2.4.
|
|
|
|
The file SYS$SYSTEM:STARTUP.COM executes immediately after the operating
|
|
system is booted. It is a driver that uses a series of component files to
|
|
perform the following startup tasks:
|
|
|
|
: Defines 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, and the operator's log. (on a
|
|
standalone workstation the operator's log is not automatically started.)
|
|
|
|
: Connects and configures devices that are physically attached to the system
|
|
and loads their I/O drivers by invoking the SYCONFIG.COM procedure.
|
|
|
|
: Installs known images to reduce I/O overhead in activating the most commonly
|
|
fun images or to identify images that must have special privileges.
|
|
|
|
CAUTION: Do not modify SYS$SYSTEM:STARTUP.COM. This file is deleted and
|
|
replaced each time you upgrade your system w/ the next version of the VMS
|
|
operqating 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.
|
|
|
|
All of the component files used by STARTUP.COM are in the directories w/ the
|
|
logical name SYS$STARTUP. SYS$STARTUP is actually a searchlist that includes
|
|
both SYS$SYSROOT:[SYSMGR] (the SYS$MANAGER directory) and
|
|
SYS$SYSROOT:[SYS$STARTUP].
|
|
|
|
In VMS Version 5.0, the following three data files are involved in startup
|
|
process and located in SYS$STARTUP:
|
|
|
|
1. VMS$PHASES.DAT--This file determines the order of the phases of the
|
|
startup procedure. It is a sequential list of phases that will be started by
|
|
STARTUP.COM. It includes a series of four (4) basic phases ( INITIAL,
|
|
CONFIGURE, SYSFILES, & BASEENVIRON) needed to bring the VMS operating system
|
|
up to a basic working evironment, followed by a series of phases for optional
|
|
software products. This fule must not be modified.
|
|
|
|
2. VMS$VMS.DAT--This is a component data file for starting the vase VMS
|
|
operating system environment. You should NOT modify this file.
|
|
|
|
3. VMS$LAYERED.DAT--This is a component file for optional software products
|
|
that are installed using the callback procedure of VMSINSTAL. It is an
|
|
indexedsequential file, containing the following fields for each file:
|
|
|
|
1. Name of the component file(either .EXE or .COM) to be run.
|
|
|
|
2. Phase in which the comonent file is to be run. The valid phases are
|
|
LPBEGIN, LPMAIN (default), LPBETA, & END.
|
|
|
|
3. Method (or mode) by which the component file is to run. The valid
|
|
choices are DIRECT(the default, where the command procedure or image
|
|
is executed immediately), BATCH(valid only for command procedures,
|
|
or SPAWN.
|
|
|
|
4. Node restrictions for the component. This is either the node or nodes
|
|
on which the component file should ONLY be run, or the node or nodes on
|
|
which the component file should NOT be run.
|
|
|
|
|
|
5. Node restriction byte field. This field determines whether the nodes
|
|
listed in the previous field are allowed or disallowed (for running
|
|
the component).
|
|
|
|
6. Parameters passes to the component file for execution. You can pass up
|
|
to eight parameters, using the following format:
|
|
|
|
(P1:args, P2: args,...)
|
|
(The paretheses can be omitted if you pass only a single parameter.)
|
|
|
|
An important function of each phase is to meet the prerequisites of the
|
|
following phase; therefore, the ordering of the phases is extrememly
|
|
important. Components that occur in a phase cannot have dependencies on
|
|
components that are in the smae phase or in subsequent phases. When
|
|
installing optional software products as known images using the STARTUP.COM
|
|
procedure, be sure that all requisite components occur in a previous phase.
|
|
|
|
If an optional software product can use the callback procedure included in
|
|
VMSINSTALL, then you can install it as a known image at system startup using
|
|
the method described earlier in this section, and you do not have to include
|
|
the product in the site-specific startup file(SYSTARTUP_V5.COM). In these
|
|
cases, the component files must be in the SYS$STARTUP directory. Software
|
|
products that do not use the callback procedure should be installed as known
|
|
images at system startup using SYSTARTUP_V5.COM.
|
|
|
|
You can also use the System Management Utility (SYMAN) to manage the new
|
|
startup process. W/ the STARTUP command of SYSMAN, you can add, modify,
|
|
display, or remove elements of existing component files, create a new startup
|
|
file and perform other startup functions. A description of SYSMAN commands is
|
|
found in the Reference section.
|
|
|
|
Several site-specific command procedures are executed from w/in STARTUP.COM.
|
|
You can add commands to these files or modify the template files supplied in
|
|
your VMS distribution kit. Remember, however, to modify only the executable
|
|
version of the file(w/ the file extension .COM)and not the template version
|
|
(w/ the file extension TEMPLATE). If you have an existing .COM file and you
|
|
want to modify a version of the original TEMPLATE file, then you should first
|
|
make a copy of the TEMPLATE file(giving the copy a filetype of .COM).
|
|
|
|
STARTUP.COM executes the site-specific command procedures in the following
|
|
sequence:
|
|
|
|
1. SYS$MANAGER:SYPAGSWPFILES.COM
|
|
2. SYS$MANAGER:SYCONFIG.COM
|
|
3. SYS$MANAGER:SYLOGICALS.COM
|
|
4. SYS$MANAGER:SYSTARTUP_V5.COM
|
|
|
|
2.8.2 SETTING UP LOGICAL NAMES FOR YOUR SITE (SYLOGICALS.COM)
|
|
|
|
A logical name is a name that is equivalent to a file specification, a
|
|
directory, a device name, another logical name, or some other equivalence
|
|
string. For example, when you have a logical name associated w/ a device
|
|
name, you can use the logical name instead of the formal device name.
|
|
|
|
You can assign logical names that apply for the entire system; these are
|
|
called systemwide logical names, and they can be used by any process on the
|
|
system. For example, if a systemwide logical name equated the logical name
|
|
FINANCE_DISK to the device DRA2, any user on the system (and any program
|
|
running on the system) could use the name FINANCE_DISK in place of DRA2.
|
|
|
|
The file SYS$MANAGER:SYLOGICALS.COM can be used for assigning systemwide
|
|
logical names. SYLOGICALS.COM is executed as part of the STARTUP.COM
|
|
procedure whenever your system is booted. The logical names defined in
|
|
SYLOGICALS.COM (as well as the logical names assigned automatically in
|
|
STARTUP.COM) are always included in the system logical name table.
|
|
|
|
If your system is a MicroVAX that is NOT in a cluster, you should use the file
|
|
SYLOGICALS.COM as a template for assigning systemwide logical names. If you
|
|
have a MicroVAX that is not in a VAXcluster environment and you want to have
|
|
systemwide logical names, you should read this section.
|
|
|
|
Unless your processor ia a MicroVAX that is NOT in a VAXcluster environment,
|
|
the template procedure that is found in SYLOGICALS.COM has NO effect.
|
|
However, if your processor is on where the template procedure does not apply,
|
|
you can still use SYLOGICALS.COM to assign systemwide logical names by adding
|
|
them to SYLOGICALS.COM before the EXIT command, as indicated in the
|
|
SYLOGICALS.COM template.
|
|
|
|
During VMS system operations when the integrity of the system could be
|
|
compromised by incorrect logical names, such as the activation of priviledged
|
|
images (LOGINOUT,MAIL, etc...) only executive-mode and kernel-mode logical
|
|
names are used; supervisor-mode and user-mode names are ignored. DIGITAL
|
|
therefore recommends that logical names for system components (for example,
|
|
public disks/directories) be defined in executive mode, for example:
|
|
|
|
$ DEFINE/SYSTEM/EXECUTIVE/NOLOG SYSDSK SYS$SYSDEVICE:
|
|
|
|
See the VMS General Users Manual for information about logical name
|
|
assignments and the privilege modes.
|
|
|
|
2.9 EMERGENCY STARTUP PROCEDURES
|
|
|
|
The startup and login procedures provided by DIGITAL should always work;
|
|
however, certian user interventions may cause them to fail. For example, if
|
|
you modify the startup of login procedures, or modify the login accounts, you
|
|
may accidentally lock yourself out of the system. A very simple way to lock
|
|
yourself out of the system is to set passwords and forget them. Another way
|
|
to lock yourself out of the system is to introduce an error condition or an
|
|
infinite loop into a startup or login procedure. Under such circumstances,
|
|
use the emergency startup procedure described in this section.
|
|
|
|
2.9.1 BYPASSING THE USER AUTHORIZATION FILE
|
|
|
|
|
|
The preferred method of breaking into a locked system isto set the alternate
|
|
user authorization file. This method requires setting the system parameter
|
|
UAFALTERNATE, which 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/password.
|
|
|
|
If this file is not located, the system assumes that the UAF is corrup and
|
|
accepts any user name/password to log you into the system from the system
|
|
console. Logins are prohibited from all other locations.
|
|
|
|
NOTE: You can use this method only to log into the system from the console
|
|
terminal; you cannot use other terminal lines.
|
|
|
|
To set the alternate user authorization file, use the following procedure:
|
|
|
|
1. Perform a conversational boot by following the instructions in your VAX
|
|
processor installation/operations guide.
|
|
|
|
2. When the SYSBOOT> prompt appears, enter the following command:
|
|
|
|
SYSBOOT> SET UAFALTERNATE 1
|
|
|
|
3. Type CONTINUE and press RETURN/ENTER KEY.
|
|
|
|
4. When the startup procedure completes, log in on the console terminal by
|
|
entering any user name/password in sresponse to the USERNAME: and then the
|
|
PASSWORD: prompts.
|
|
|
|
The system assigns the following values to your user account:
|
|
: NAME -User Name
|
|
: UIC -[001,004]
|
|
: command Interpreter -DCL (Digital Command Language)
|
|
: Login Flags -None
|
|
: Priority -Value of the system parameter DEFPRI
|
|
: Resources -Values of the PQL system parameters
|
|
: Privileges -All
|
|
The process name is usually the name of the device on which you logged in
|
|
(for example, _OPA0:).
|
|
|
|
5. Fix the problem that caused you to be locked out of the system. That is,
|
|
make the necessary repairs to the UAF or to the startup or login
|
|
procedures. (If you modify a login or startup procedure and the problem is
|
|
still not solved, you should restore the procedure to its previous state.)
|
|
If the problem is a forgotten password, reset the UAFALTERNATE system
|
|
parameter to 0, as explained in the next step. Then invoke the Authorize
|
|
Utility and type HELP MODIFY for information on modifying passwords.
|
|
|
|
6. Clear the UAFALTERNATE parameter by running SYSGEN and giving appropriate
|
|
SYSGEN commands. To run SYSGEN, enter the following command at the DCL
|
|
prompt:
|
|
$ RUN SYS$SYSTEM:SYSGEN
|
|
|
|
The SYSGEN> prompt is displayed, and you should enter the following
|
|
commands:
|
|
SYSGEN> SET UAFALTERNATE 0
|
|
SYSGEN> WRITE CURRENT
|
|
SYSGEN> EXIT
|
|
|
|
7. Shut down and reboot the system.
|
|
|
|
2.9.2 EMERGENCY STARTUP AFTER MODIFYING SYSTEM PARAMTERS
|
|
|
|
In some cases, modifying system parameters may cause the system to become
|
|
unbootable. If this occurs, use the following emergency startup procedure to
|
|
restore to normal operation:
|
|
|
|
1. Perform a conversational boot by following the instructions in your VAX
|
|
processor installation/operations guide.
|
|
|
|
2. When the SYSBOOT> prompt appears, enter the following commands:
|
|
SYSBOOT> USE DEFAULT.PAR
|
|
SYSBOOT> CONTINUE
|
|
|
|
3. When the system finishes booting, review any changes you made to SYSGEN
|
|
parameters, modify MODPARAMS.DAT as necessary, and reexecute AUTOGEN.
|
|
|
|
2.9.3 BYPASSING STARTUP/LOGIN
|
|
|
|
If the system does not complete the startup procedures or does not allow you
|
|
to log in, bypass the startup/login procedures by following these steps:
|
|
|
|
1. Perform a conversational boot by following the isntructions in your VAX
|
|
processor installation/operations guide.
|
|
|
|
2. Define the console tobe the startup procecdure by entering the following
|
|
command at the SYSBOOT> promt:
|
|
|
|
SYSBOOT> SET/STARTUP OPA0:
|
|
|
|
type CONTINUE and press Return/Enter in response to the next SYSBOOT>
|
|
prompt. Wait for the DCL prompt to return.
|
|
|
|
3. Correct the error condition that caused the login failure. That is, make
|
|
the necessary repairs to the startup/login procedures, or to the UAF. You
|
|
may want to enter the following DCL commands because bypassing the startup
|
|
procedures leaves the system in a partially initalized state:
|
|
|
|
$ SET NOON
|
|
$ SET DEFAULT SYS$SYSROOT: [SYSEXE]
|
|
|
|
Invoke a text editor to correct the startup/login procedure file. Note
|
|
that some system consoles may NOT supply a screen/mode editor. You can
|
|
also copy a corrected file and delete the incorrect version by using
|
|
the RENAME/DELETE commands.
|
|
|
|
4. Reset the startup procedure by invoking SYSGEN and entering the following
|
|
commands:
|
|
|
|
$ RUN SYS$SYSTEM:SYSGEN
|
|
SYSGEN> SET/STARTUP SYS$SYSTEM:STARTUP.COM
|
|
SYSGEN> WRITE CURRENT
|
|
SYSGEN> EXIT
|
|
|
|
5. Perform a normal startup by entering the following command:
|
|
|
|
$ @SYS$SYSTEM:STARTUP
|
|
|
|
2.9.4 STARTUP PROBLEMS
|
|
|
|
Sometimes the operating system does not boot after you enter the BOOT command.
|
|
This can be caused by either a hardware/software malfunction.
|
|
|
|
A read error on a disk drive or console medium, or a machine check error, may
|
|
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 do the following:
|
|
|
|
1. Consult the hardware manual for your VAX processor.
|
|
|
|
2. If you still cannot correct the problem, contact your DIDGITAL FIELD
|
|
REPRESENTITIVE.
|
|
|
|
When the operating system is loaded into memory but the STARTUP.COM command
|
|
procedure does not execute, a softsare malfunction has probably occured. You
|
|
should suspect this condition if the usual message specifying the number of
|
|
interactive users does not appear.
|
|
|
|
Perform one or both of the following actions to correct the situation:
|
|
|
|
1. Try again, by repeating the boot procedure to restart the system.
|
|
|
|
2. Leave the system disk in the original drive. Restore a backup copy of the
|
|
system disk using Standalong Backup.
|
|
|
|
2.10 SHUTDOWN PROCEDURES
|
|
|
|
The VMS operating system provides the folowing types of shutdown procedures:
|
|
|
|
: An orderly shutdown w/ SYS$SYSTEM:SHUTDOWN.COM. 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.
|
|
|
|
SHUTDOWN.COM optionally invokes a site-specific command procedure named
|
|
SYS$MANAGER:SYSHUTDWN.COM, which you can modify to meed the needs of your
|
|
basic installation. An empty SYSHUTDWN.COM file is included in your VMS
|
|
distribution kit.
|
|
|
|
: An emergency shutdown w/ OPCCRASH. If you are unable to perform an orderly
|
|
shutdown w/ SHUTDOWN.COM, run the OPCCRASH emergency shutdown program.
|
|
|
|
: An emergency shutdown w/ CRASH. Use this emergency shutdown procedure if
|
|
OPCCRASH fails. Note that not all VAX processors have the CRASH program.
|
|
If your VAX processor has the CRASH procedure, it is located on the console
|
|
media, and it can only be executed from the console terminal. See your
|
|
VAX processor installation/operations guide for a description of the CRASH
|
|
procedure or for the equivalent commands to use to force an abrupt
|
|
emergency shutdown.
|
|
|
|
2.10.1 ORDERLY SHUTDOWN W/ SHUTDOWN.COM
|
|
|
|
Use SHUTDOWN.COM to shut down the system in an orderly fashion. Do not
|
|
mnodify SHUTDOWN.COM. Add commands to the SYS$MANAGER:SYSHUTDWN.COM command
|
|
procedure to perform site-specific functions.
|
|
|
|
To execute SHUTDOWN.COM, you must have either the SETPRV privilege or all the
|
|
following privileges: CMKRNL, EXQUOTA, LOG_IO, OPER, SYSNAM, SYSPRV, TMPMBX,
|
|
and WORLD. Usually, you shut down the system from the SYSTEM account, which
|
|
includes these privileges by default.
|
|
|
|
2.10.1.1 SHUTDOWN.COM SEQUENCE OF PROMPTS AND MESSAGES
|
|
|
|
To perform an orderly shutdown of the system, invoke SHUTDOWN.COM from any
|
|
terminal and any privileged account w/ the following DCL command:
|
|
|
|
$ @SYS$SYSTEM:SHUTDOWN
|
|
|
|
The procedure then prompts you w/ a series of questions and messages. The
|
|
default response appear in brackets at the end of each question. Press the
|
|
RETURN key to select the default response. A summary of the questions
|
|
follows:
|
|
|
|
: Minutes until shutdown:
|
|
How many minutes until final shutdown [0]?
|
|
|
|
Enter an integer. If the system logical name SHUTDOWN$MINIMUM_MINUTES is
|
|
defined, its integer value is the minimum value that you can enter.
|
|
Therefore, 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, the logical name value is used. If the logical name is
|
|
not defined, and you do not enter a value, 0 minutes is the default.
|
|
|
|
: Reson for shutdown:
|
|
Reason for shutdown [standalone]:
|
|
|
|
Enter a one-line reason for shutting down the system.
|
|
|
|
: Decide if you want to spin down the disk volumes:
|
|
Do you want to spin down the disk volumes [No]?
|
|
|
|
Enter Yes or No (Y or N). Note, however, that the system disk cannot
|
|
be spun down.
|
|
|
|
: Decide if you want to invoke a site-specific shutdown procedure:
|
|
Do you want to invoke the site-specific shutdown procedure [Yes]?
|
|
|
|
Enter Yes or No. This refers to SYS$MANAGER:SYSHUTDWN.COM.
|
|
|
|
: Decide if you want an automatic system reboot:
|
|
Should an automatic system reboot be performed [No]?
|
|
|
|
By default, the system does not automatically reboot. However, if you
|
|
respond w/ YES, the system attempts to reboot automatically when the
|
|
shutdown is complete.
|
|
|
|
: Message broadcast to users about rebooting the system:
|
|
When will the system be rebooted [later]?
|
|
|
|
Enter the expected reboot time in the format you want printed in the
|
|
message that will be broadcast to users. For example, you could specify
|
|
IMMEDIATELY, or IN 10 MINUTES, or a time such as 2 PM, or 14:00. If you
|
|
do not know when the system will be abailable again, press RETURN to
|
|
specify 'later' as the time when the system will reboot.
|
|
|
|
: Shutdown options:
|
|
Shutdown options (enter as a comma--separated list):
|
|
SAVE_FEEDBACK : Saves feedback data for AUTOGEN calculations
|
|
REMOVE_NODE : Remaining nodes in the cluster should be adjust quorum
|
|
CLUSTER_SHUTDOWN : Entire cluster is shutting down
|
|
REBOOT_CHECK : Check exestence of basic system files
|
|
Shutdown options [NONE]
|
|
|
|
The procedure prompts you to specify one or more shutdown options.
|
|
|
|
Entering the SAVE_FEEDBACK option records feedback data collected from the
|
|
system since it was last booted. This option creates a new version of the
|
|
AUTOGEN feedback data file, which can be used when you next run AUTOGEN.
|
|
|
|
If your system is a cluster member, all options are listed. When the
|
|
REMOVE_NODE option is specified on one cluster member system, users on all
|
|
member systems are notified. Clusterwide notification is required, because
|
|
users logged in to any member system may be affected by the shutdown of another
|
|
system, for example:
|
|
|
|
: Users may have batch jobs running on other systems.
|
|
: If therminal servers are in operation, users may have alternate terminal
|
|
sessions in progress on the system being shut down.
|
|
|
|
Otherwise, only the REBOOT_CHECK and SAVE_FEEDBACK options are listed. Enter
|
|
REBOOT_CHECK to verifty the presence of a subset of files necessary to reboot
|
|
the system after shutdown completes. (if you are certain that the files exist,
|
|
press RETURN.)
|
|
|
|
If you select the REBOOT_CHECK option, the procedure checks for the necessary
|
|
files and notifies you if any are missing. Replace missing files before
|
|
proceeding. If all files are present, the following success message appears:
|
|
|
|
%SHUTDOWN-I-CHECKOK, Basic reboot consistency check completed.
|
|
|
|
The following events occur as the shutdown procedure continues, and the
|
|
corresponding messages are printed on the terminal:
|
|
|
|
1. A message requesting users to log out is broadcast at decreasing time
|
|
intervals to all users on the system.
|
|
|
|
2. The system logical name SHUTDOWN$TIME is defined as the absolute time of
|
|
shutdown. For example, if the value 10 is specified at 12:00 in response
|
|
to the first question, the logical name is assigned the absolute time value
|
|
12:10 along w/ the date. By requesting the logical name definition
|
|
SHUTDOWN$TIME (w/ the SHOW LOGICAL command), you can see if a shutdown is
|
|
in progress or determine the actual time of shutdown. This feature is
|
|
useful if a user missed the shutdown broadcast message.
|
|
|
|
3. At six minutes or less until system shutdown, the terminal from which
|
|
shutdown was invoked is made an operator's console and all future
|
|
nonoperator logins are disabled. If the DECnet network is running, it
|
|
is shuto down.
|
|
|
|
4. When there is one minute left until system shutdown, batch and device
|
|
queues and the system job queue manager are stopped.
|
|
|
|
5. At zero minutes before system shutdown the site-specific command procedure
|
|
SYS$MANAGER:SYSHUTDWN.COM is invoked.
|
|
|
|
6. All user processes are stopped; however, system processes continue.
|
|
Ancillary Control Processes (ACP's) may delete themselves when their
|
|
mounted volumes are finally dismounted.
|
|
|
|
7. For dual-processor systems, the secondary processor is stoped.
|
|
|
|
8. All installed images are removed.
|
|
|
|
9. All mounted volumes are dismounted and, if you request it, the disks are
|
|
spun down. Note, however, that the system disk cannot be spun down. Also,
|
|
the quorum disk (if present on your system) is not dismounted or spun down.
|
|
|
|
10. The operator's log file is closed.
|
|
|
|
11. The program SYS$SYSTEM:OPCCRASH is invoked to shut down the system.
|
|
|
|
12. If you did not request an automatic reboot, the following message appears
|
|
on the system console:
|
|
|
|
SYSTEM SHUTDOWN COMPLETE -- USE CONSOLE TO HALT SYSTEM
|
|
|
|
iF you requested an automatic reboot, the system reboots, provided the
|
|
necessary controls are set.
|
|
|
|
13. If you are not automatically rebooting, halt the system after the
|
|
previous message is printed at the console terminal.
|
|
|
|
Example 2-1 demonstrates an orderly system shutdown on standalone node AVALON.
|
|
|
|
EXAMPLE 2-1: ORDERLY SYSTEM SHUTDOWN W/ SHUTDOWN.COM
|
|
-----------------------------------------------------
|
|
|
|
$ @SYS$SYSTEM:SHUTODOWN
|
|
|
|
SHUTDOWN -- Perform an Orderly System Shutdown
|
|
|
|
How many minutes until final shutdown [0]: 10
|
|
Reason for shutdown: [Standalone] MONTHLY PREVENTIVE MAINTENACNE.
|
|
Do you want to spin down the disk volumes [NO]? RETURN
|
|
Do you want to invoke the site-specific shutdown procedure [Yes]? RETURN
|
|
Should an automatic system reboot be performed [NO]? RETURN
|
|
When will the system be rebooted [Later]? 12:30
|
|
Shutdown options:
|
|
REBOOT_CHECK : Check existence of basic system files
|
|
|
|
shutdown options [NONE]: RETURN
|
|
|
|
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 MAINTENACE
|
|
|
|
%SHUTDOWN-I-OPERATOR, This terminal is now an operator's console.
|
|
%%%%%%%%%%% OPCOM, 16JUL1988 12:01:00.15 (NOTE THE TIME WILL BE ACUTAL TIME)
|
|
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-I-STOPQUEMAN, The queue manager will now be stopped.
|
|
|
|
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 MAINTENACE
|
|
|
|
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 4 minutes; back up 12:30. Please log off node AVALON.
|
|
MONTHLY PREVENTIVE MAINTENANCE
|
|
|
|
%%%%%%%% OPCOM, 16-Jul-1988 12:07:12:30 %%%%%%%%
|
|
|
|
Message from user DECnet on AVALON
|
|
DECnevt even 2.0, local node state change
|
|
From node 2.161 (AVALON), 16-Jul-1988 12:07:22.26
|
|
Operator command, old state = on, New state = Shut
|
|
|
|
SHUTDOWN message on AVALON from user SYSTEM at _AVALON$OPA0: 12:07:12:56
|
|
AVALON will shut down in 3 minutes; back up 12:30. Please log off node AVALON.
|
|
MONTHLY PREVENTIVE MAINTENANCE
|
|
|
|
%SHUTDOWN-I-STOPQUEMAN, The queue manager will now be stopped.
|
|
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-JUL-1988 12:08:12:30 %%%%%%%%%%
|
|
Message from user JOB_CONTROL on AVALON
|
|
-SYSTEM-S-NORMAL, normal successful completion
|
|
|
|
%%%%%%%%% OPCOM, 16-JUL-1988 12:08:42:30
|
|
Message from user DECNET on AVALON
|
|
DECnet shutting down
|
|
|
|
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.
|
|
|
|
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-JUL-1988 12:09:42.30
|
|
Message from user System on AVALON
|
|
_AVALON$OPA0:, AVALON shutdown requested by the operator.
|
|
|
|
%%%%%%%%%% OPCOM, 16-JUL-1988 12:10:02.44 %%%%%%%%%%%%%
|
|
Logfile was closed by operator _AVALON$OPA0:
|
|
Logfile was SYS$SYSROOT: [SYSMGR] OPERATOR.LOG;8
|
|
|
|
%%%%%%%%%% OPCOM, 16-JUL-1988 12:10:32.20
|
|
Operator _AVALON$OPA0: has been disabled, username SYSTEM
|
|
|
|
SYSTEM SHUTDOWN COMPLETE -- USE CONSOLE TO HALT SYSTEM
|
|
|
|
------------------------------------------------------------------
|
|
|
|
2.10.1.2 DEFINING SHUTDOWN$INFORM_NODES
|
|
|
|
Before you execute SYS$SYSTEM:SHUTDOWN.COM, you can define the logical name
|
|
SHUTDOWN$INFORM_NODES to be a list of cluster member nodes. The nodes listed
|
|
in SHUTDOWN$INFORM_NODES will be notified when the system is shutdown, as shown
|
|
in the following example:
|
|
|
|
$ DEFINE SHUTDOWN$INFORM_NODES "NODE1,NODE2,NODE3"
|
|
$ @SYS$SYSTEM:SHUTDOWN
|
|
|
|
If you define SHUTDOWN$INFORM_NODES and then execute SYS$SYSTEM:SHUTDOWN.COM,
|
|
all cluster member nodes included in the list are notified of the shutodwn.
|
|
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, the name
|
|
is automatically added to the list by the SHUTDOWN.COM procedure.
|
|
|
|
2.10.2 EMERGENCY SHUTDOWN W/ OPCCRASH
|
|
|
|
|