home *** CD-ROM | disk | FTP | other *** search
Text File | 2003-06-11 | 63.9 KB | 1,397 lines |
- 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
-
-
-