Boot Process


When the machine—either VAX or Alpha—is turned on, it performs a hardware test on memory and the installed. controllers. Next, the hardware initialization program searches for attached peripherals. Finally, it displays the >>> prompt, called the "dead sergeant" to signal that the console program is ready.

There are several options available at the >>> prompt depending on the hardware model. Typically, more extensive hardware tests can be performed, disks can be initialized, and controllers can be configured. Most systems support a HELP command in some form to guide the manager; however, the operator's manual is essential for any extensive dialogs at this point. because each hardware model has unique capabilities and command syntax.

If the console program is configured to halt when powered up, the manager must enter a command to start the boot process. The command varies by hardware model, but usually a "B" will start the boot from a default device. The console program can be reconfigured to boot from a specific disk, instructed to continue without operator intervention into the OpenVMS boot procedure, and to permit remote boot commands.

On the VAX, the console program is in PROM and is not easily upgraded. On the Alpha, the System Reference Manual (SRM) console firmware controls the console before booting OpenVMS. This firmware is upgraded from time to time by Compaq/HP to reflect new hardware peripherals. The firmware can be downloaded from the Compaq site and upgraded by the manager. Whenever OpenVMS is installed or upgraded, the manager must check the firmware version number for compatibility.

VMB.EXE, the primary boot program, is located on the book disk; however, in early versions of the VAX, this program was either in ROM or a floppy disk. VMB's task is to locate the secondary boot program, SYS$SYSTEM:SYSBOOT.EXE, on disk, load it, and start it. Actually, VMB is a general-purpose boot program whose actions are determined by commands entered at the console. These other capabilities of VMB are beyond the intent of this book. Goldenberg discusses them in some detail (see the Bibliography).

Once SYSBOOT is running, it reads and saves SYS$SYSTEM:VAXVMSSYS.PAR on a VAX or ALPHAVMSSYS.PAR on an Alpha. This file contains all of the machine-specific parameters required to tune OpenVMS to the specific hardware and software configuration. Information in this file is used extensively throughout OpenVMS to control its performance. Then SYSBOOT locates and loads SYS$SYSTEM:EXE$INIT. The xVMSSYS.PAR file is managed automatically by a script called AUTOGEN or manually with the SYSMAN PARAMETER command.

Returning to the boot process, EXE$INIT initializes key data structures for process scheduling and memory management. Then it creates the first OpenVMS resident process called SWAPPER. When SWAPPER is started, it must initialize its local database to correspond with physical memory. The SWAPPER process controls memory management functions for OpenVMS and, therefore, runs continuously monitoring, and if necessary, adding or removing physical pages from each process. Once SWAPPER is running, the boot process has progressed to the point that OpenVMS is running as a time-sharing system, although it cannot yet support logins. SWAPPER also initializes several other OpenVMS kernel routines and databases. Finally, SWAPPER creates and starts a new process, SYSINIT, and then returns to its memory management duties.

SYSINIT loads the rest of the resident parts of OpenVMS and initializes cluster communications if the machine is a member of a cluster. It creates and starts another process, STARTUP, and exits. STARTUP is responsible for executing a machine-independent script called SYS$SYSTEM:STARTUP.COM. This script acts as the executive for all of the activity that will follow (i.e., for starting the OpenVMS support processes such as the file cache server, operator communications, audit server, job control, disk shadow server, license checking, and installation of layered products—e.g., compilers). This activity ends with the execution of two scripts, SYLOGICALS.COM and SYSTARTUP_VMS.COM, which are described in the next section.

Default Boot

Once the default boot command is entered, the standard boot procedure described previously begins. The STARTUP process is the host under which about 50 command files are executed in a specific order. Most of these files are not intended to be modified by the manager, but there are exceptions. The last two, SYLOGICALS and SYSSTARTUP_VMS, are intended to be customized by the manager to reflect the specific software installed on the system. SYS$MANAGER:SYLOGICALS defines systemwide logicals, and the manager may need to insert additions. SYS$MANAGER:SYSTARTUP_VMS [1] performs site-specific and possibly cluster node-specific operations. The system manager normally tailors this command procedure as well. Typical tasks performed by SYSTARTUP_VMS include (but are not limited to) the following:

  • Mounting public disks

  • Initializing and starting print and batch queues

  • Installing privileged images

  • Starting detached processes (called daemons in UNIX), also called symbionts

  • Starting network protocols

  • Housekeeping accounting and log files

  • Defining systemwide announcements displayed at user login

SYSTARTUP_VMS will be referenced often in the chapters that follow. SYSTARTUP_VMS ends by defining the maximum number of interactive users supported by the system, thus activating interactive logins.

Conversational Boot

In certain exceptional cases, usually in emergencies, alternative boot procedures are also defined. These options modify the boot process described previously either by stopping part way through or by skipping through the process. The specific alternative is indicated by adding parameters (or control flags) to the boot command. For example, on several Alpha models, a conversational boot is started with the command

     >>> boot -flags 0,1 device_name 

The user manual for each computer model specifies the specific syntax of this command. With this command, it is possible to stop the boot process in SYSBOOT (introduced earlier). Some reasons for a conversational boot are as follows:

  • Loss of SYSTEM password

  • Incorrect setting of a system parameter in xVMSSYS.PAR that prevents Open VMS from starting because of limited resources

  • Error in a startup script, notably SYSTARTUP_VMS, that prevents its completion

Once in SYSBOOT, several system utilities, particularly AUTHORIZE and SYSMAN, are available for use at the console, but only at the console, because OpenVMS has not yet started. When the required change is made, the manager has the option to either continue booting or stopping the boot and shutting down the system. If the manager wishes to continue booting, he or she has the following additional options:

  • Use the alternative SYSUAF. If privileged account passwords are lost, the alternative SYSUAF can be substituted for the real one.

  • Minimal startup. Continue the boot normally, but do not execute SYSTARTUP_VMS. This permits repair of SYSTARTUP_VMS.COM.

  • Bypass startup. This option bypasses the execution of all startup scripts but starts a minimal system, which can be used to repair damaged script files.

  • Reverting to previous xVMSSYS.PAR file. Occasionally, the manager may inadvertently or accidentally enter bad OpenVMS parameter data. If he or she does not immediately know what went wrong, the previously correct parameter file, xVMSSYS.OLD, can be used instead of the current one.

Details of the previous operations are not included in this book because of the intricacies involved. These details are provided in OpenVMS System Management Guide, Chapter 4, and the System Manager's Manual, Chapter 4.

Standalone Boot

A standalone boot is a term used when booting from a specially created tape (on a VAX, created with SYS$UPDATE:STABACKIT.COM) or from CD (on a VAX or an Alpha) for the purpose of disk backup. Only the BACKUP tool is loaded into memory, not OpenVMS; hence no disk files are open. Historically, this option was necessary to back up the system disk, but more recent versions of OpenVMS have options that permit backups of any disk during normal operations.

The value of a standalone backup is that the system is in a known, quiescent state. When backing up an operating system disk on a running system, some files will be open (e.g., the printer queues), and the queue manager database files that are backed up are a snapshot of a dynamic state of those files. Normally, backup of a running system is acceptable and, indeed, desirable because the system is expected to be accessible and operational 100 percent of the time. BACKUP is discussed in Chapter 6.

Shutdown

Shutting down the system or shutting down a single cluster node in the system is done with a script called SYS$SYSTEM:SHUTDOWN.COM; however, the most common reason for a shutdown is to accommodate changes made to xVMSSYS.PAR either automatically with AUTOGEN or manually with SYSMAN PARAMETER. If AUTOGEN is used, the system shutdown script is optionally executed.

The SHUTDOWN script permits the operator (or system manager) to inform the users of a pending shutdown and then gracefully shut down. In particular, if continuously running applications (with open databases) need to be informed of a shutdown, this is the recommended mechanism to use.

SYS$MANAGER:SYSHUTDWN.COM is called by SHUTDOWN.COM and is tailored by the system manager for site-specific tasks. Normally, it should mirror the startup script by undoing installs and mounts in the reverse order. In a clustered system, SYSHUTDWN can be coded to be node specific (i.e., to shut down certain processes only on the node on which they are running). The SHUTDOWN dialog is similar to the following:

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

This causes the following message to be displayed on all user displays to permit users to complete their work before the shutdown event:

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

Countdown messages are sent out to users as well. A similar message is recorded in the operator's log, SYS$MANAGER:OPERATOR.LOG. All operator messages are stored in that file as a log and for security purposes.

Alternately, the operator or manager can shut down the entire cluster with a single command. Using SYSMAN, the SHUTDOWN script is invoked on each node with the specified parameters automatically:

     $ RUN SYS$SYSTEM:SYSMAN     SYSMAN> SET ENVIRONMENT/CLUSTER     %SYSMAN-I-ENV, current command environment:       Clusterwide on local cluster       Username SYSTEM will be used on nonlocal nodes     SYSMAN> SHUTDOWN NODE/CLUSTER_SHUTDOWN/MINUTES_TO_SHUTDOWN=10     _SYSMAN> /AUTOMATIC_REBOOT/REASON="Cluster Reconfiguration"     %SYSMAN-I-SHUTDOWN, SHUTDOWN request sent to node 

If SHUTDOWN does not work for some reason, there is an immediate (also called emergency) shutdown executable called SYS$SYSTEM:OPCCRASH (OPerator Console CRASH), which stops the node without warning or grace. Cached data and print jobs may be lost when using this option, so it should be used with great care. OPCCRASH produces a crash dump, which is written to disk for later analysis.

Booting after Crash

It may be desirable to examine the crash dump after rebooting the system. This step can be automated within the startup script with ANALYZE/CRASH_DUMP. Doing this immediately on restartup ensures that a new dump does not overwrite the previous dump yet to be analyzed. Information in that analysis might be used to determine (and possibly correct) the root cause of the crash, to investigates the causes of system failure and debugs kernel-mode code, such as a device driver. The system manager should have some knowledge of OpenVMS data structures to properly interpret the results of system dump analyzer (SDA) commands.

[1]Before OpenVMS Version 6, this file is called SYSTARTUP_Vx, where x is the version number.




Getting Started with OpenVMS System Management
Getting Started with OpenVMS System Management (HP Technologies)
ISBN: 1555582818
EAN: 2147483647
Year: 2004
Pages: 130
Authors: David Miller

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net