VOS Startup and Shutdown A System (r282-03)

VOS System Administration:
Starting Up and Shutting Down a Module or System
Stratus Computer, Inc.

R282-03
Notice
The information contained in this document is subject to change without notice.

UNLESS EXPRESSLY SET FORTH IN A WRITTEN AGREEMENT SIGNED BY AN AUTHORIZED REPRESENTATIVE
OF STRATUS COMPUTER, INC., STRATUS MAKES NO WARRANTY OR REPRESENTATION OF ANY KIND WITH
RESPECT TO THE INFORMATION CONTAINED HEREIN, INCLUDING WARRANTY OF MERCHANTABILITY AND
FITNESS FOR A PURPOSE. Stratus Computer, Inc., assumes no responsibility or obligation of any kind for any errors
contained herein or in connection with the furnishing, performance, or use of this document.
Software described in Stratus documents (a) is the property of Stratus Computer, Inc., or the third party, (b) is furnished
only under license, and (c) may be copied or used only as expressly permitted under the terms of the license.
Stratus manuals document all of the subroutines and commands of the user interface. Any other operating-system
commands and subroutines are intended solely for use by Stratus personnel and are subject to change without warning.
This document is protected by copyright. All rights are reserved. No part of this document may be copied, reproduced, or
translated, either mechanically or electronically, without the prior written consent of Stratus Computer, Inc.
Stratus, the Stratus logo, Continuum, StrataNET, FTX, and SINAP are registered trademarks of Stratus Computer, Inc.
XA, XA/R, StrataLINK, RSN, Continuous Processing, Isis, the Isis logo, Isis Distributed, Isis Distributed Systems, RADIO,
RADIO Cluster, and the SQL/2000 logo are trademarks of Stratus Computer, Inc.
Apple and Macintosh are registered trademarks of Apple Computer, Inc.
IBM PC is a registered trademark of International Business Machines Corporation.
Sun is a registered trademark of Sun Microsystems, Inc.
Hewlett-Packard is a trademark of Hewlett-Packard Company.
All other trademarks are the property of their respective owners.
Manual Name: VOS System Administration: Starting Up and Shutting Down a Module or System
Part Number: R282
Revision Number: 03
VOS Release Number: 14.0.0
Printing Date: January 1998
Stratus Computer, Inc.
55 Fairbanks Blvd.
Marlboro, Massachusetts 01752
1998 by Stratus Computer, Inc. All rights reserved.
Contents
Preface
ix
1. The Continuum-Series System Console

Front Panel Commands
Recovering a Hung System
System Messages
Console Controller Messages
Console and Error-Log Status Messages
Module Status Lights
Expansion Cabinet Lights
Unit Status Lights
1-1
1-1
1-6
1-6
1-7
1-9
1-9
1-9
1-9
2. The XA/R-Series Modular Control Panel

The Stratus Modular Control Panel
Control Panel Components
Module Control Unit (MCU)
Operator Interface Unit (OIU)
Other Control Panel Features
Status Display
OIU Query and Control Messages
System Messages
Unit Failure Lights
Control Panel Buttons
The Immediate Power Off Button
2-1
2-2
2-2
2-3
2-3
2-3
2-3
2-4
2-5
2-7
2-7
2-7
2-9
3. Starting Up a Module or System

Automatic Startup
Single Module Startup
Automatic Startup Functions
Handling Problems with Automatic Startup
3-1
3-1
3-1
3-2
3-2
Contents
iii
Contents
Manual Startup
Disk Boot and Tape Boot
The Steps in a Manual Startup from Disk or Tape
Link Boot
Link Boot Module Requirements
The Link Boot Source
The Link Boot Server
The Steps in a Link Boot
The Operating System Symbol Table
4. The Module Startup

Command File
The module_start_up.cm File
Tailoring the module_start_up.cm File
3-3
3-3
3-4
3-9
3-9
3-10
3-10
3-11
3-12
4-1
4-1
4-2
5. Responding to Status Lights

5-1
5-1
5-1
Fault Indicator Lights on Boards
5-3
Board Testing
5-5
Board Failure
5-5
System Problem Analysis
5-5
Proper Recovery
5-6
Recovery Procedures
5-7
Recovering with Automatic Dump and Reboot
5-7
Recovering with PCP Execution
5-7
5-8
Determining the attempt_auto_recovery Setting 5-8
Changing the attempt_auto_recovery Setting
5-9
Continuum-Series Manual Recovery
5-9
Continuum-Series Automatic Recovery
5-10
XA/R-Series Recovery
5-11
Recovering from System Initialization Process Failure
during a Boot
5-11
6. Shutting Down and Powering Off

The module_shut_down.cm File
Planned Shutdowns
Emergency Shutdown
iv
6-1
6-1
6-1
6-3
VOS System Administration: Starting Up and Shutting Down a Module or System (R282)
Contents
7. Recovering from a Crash

Rebooting after a Crash
Checking the Module Hardware
Checking for Disk Salvage and Recovery
Disk Salvager Errors
Disk Recovery
Checking the Module Service Processes
Checking for File Recovery
Understanding File Recovery
Disk I/O Concepts
Checking for File Consistency
Checking Transaction-Protected Files
Checking Other Types of Files
8. Command Overview
broadcast
patch_file
patch_index
recreate_index
shutdown
test_index
Current Session Requests
The help Request
The names Request
The quit Request
Requests That Establish a Current Index
The look_at Request
The use Request
Requests That Display Information
The check Request
The dump_node Request
The free Request
The status Request
Requests That Set Up, Display, and Alter Position
The backward_index Request
The convert_key Request
The convert_key_range Request
The forward_index Request
The locate_record Request
The position Request
7-1
7-1
7-2
7-3
7-3
7-4
7-5
7-6
7-6
7-7
7-8
7-8
7-9
8-1
8-2
8-4
8-7
8-10
8-20
8-26
8-28
8-28
8-29
8-30
8-31
8-31
8-33
8-35
8-35
8-40
8-47
8-48
8-49
8-49
8-51
8-53
8-56
8-58
8-59
Contents
Contents
Buffer Management Requests

The create_buffer Request
The delete_buffer Request
The display_buffer Request
The dump_buffer Request
The fill_buffer Request
The list_buffers Request
The set_buffer_byte Request
The set_buffer_length Request
The set_buffer_longword Request
The set_buffer_text Request
The set_buffer_word Request
The use_buffer Request
verify_end_of_file
verify_index
8-61
8-61
8-63
8-64
8-65
8-66
8-67
8-68
8-69
8-70
8-71
8-72
8-73
8-74
8-86
Appendix A. Control Panels

The Control Panel for the 10-Slot XA/R Model 20 Module
Master Startup Procedure
The LEVEL-7 Interrupt Button
Recovery Procedures for No Activity
A-1
A-1
A-4
A-4
A-5
Index
vi
Index-1
Figures
Figure 1-1. Continuum-Series Modules (PA-7100 Processor) Front Panel

Commands
1-2
Figure 1-2. Continuum-Series Modules (PA-8000 Processor) Front Panel
Commands
1-3
Figure 2-1. The Modular Control Panel
2-2
Figure 2-2. Control Panel Buttons
2-8
Figure 5-1. Main Cabinet and Expansion Cabinet Status Lights
5-2
Figure 5-2. Logic-Chassis Board Lights
5-3
Figure A-1. Control Panel for the 10-Slot XA/R Model 20 Module
A-1
Figures
vii
Tables
Table 5-1.
Table 5-2.
Table 5-3.
Table 5-4.
viii
Main Cabinet and Expansion Cabinet Lights

Logic-Chassis Board Lights
Manual Recovery Command Sequence
Automatic Recovery Command Sequence
5-2
5-4
5-9
5-10
Preface
The manual VOS System Administration: Starting Up and Shutting Down a Module or
System (R282) documents the procedures for starting up and shutting down Stratus
modules. It covers VOS Release 14.0.0 information for the following hardware
platforms:
all Continuum-series modules
all XA/R-series modules
This manual is intended for system administrators.
Manual Version
This manual is a revision. Change bars, which appear in the margin, note the specific
changes to text since the previous publication of this manual. Note, however, that
change bars are not used in new chapters or appendixes.
This revision incorporates the following changes.
three new commands that help to diagnose and repair corrupted file indexes:
verify_index
patch_file
patch_index
the test_index commands check requests three new arguments:
-verify_record, -verbose, and -repair

the recreate_index commands three new arguments: -duplicate_path,
-syserr, and -recovery_macro

module_shut_down.cm, a new user-supplied command macro thatif present
in the >system directorywill automatically execute prior to system shutdown

when the shutdown command is given
Preface
ix
Preface
Manual Organization
The manual contains eight chapters and one appendix.
Chapter 1 documents the Stratus system console found on Continuum-series
modules.
Chapter 2 documents the Stratus module control panels found on XA/R-series
modules.
Chapter 3 describes how to start up a module or system.
Chapter 4 briefly introduces the module startup command file.
Chapter 5 explains how to respond to problem lights on the control panels.
Chapter 6 explains how to shut down and power off a module or system.
Chapter 7 describes the procedures to follow when recovering from a crash.
Chapter 8 documents the commands that manage system availability and that
diagnose and repair file indexes.
Appendix A describes the control panel of the older 10-slot XA/R Model 20 Stratus
modules.
Related Manuals
Refer to the following Stratus manuals for related documentation.
Introduction to VOS (R001)
VOS Reference Manual (R002)
Site Planning Guide (R003)
VOS Commands Reference Manual (R098)
VOS System Administration manuals
VOS System Administration: Administering and Customizing a System (R281)

VOS System Administration: Registration and Security (R283)
VOS System Administration: Disk and Tape Administration (R284)
VOS System Administration: Backing Up and Restoring Data (R285)
VOS System Administration: Administering the Spooler Facility (R286)
VOS System Administration: Configuring a System (R287)
Preface
Notation Conventions
This manual uses the following notation conventions.
Italics introduces or defines new terms. For example:
The master disk is the name of the member disk from which the module was
booted.
Boldface emphasizes words in text. For example:
Every module must have a copy of the module_start_up.cm file.

Monospace represents text that would appear on your terminals screen (such as
commands, subroutines, code fragments, and names of files and directories).

For example:
change_current_dir (master_disk)>system>doc
Monospace italic represents terms that are to be replaced by literal values. In the
following example, the user must replace the monospace-italic term with a literal
value.
list_users -module module_name
Monospace bold represents user input in examples and figures that contain both
user input and system output (which appears in monospace). For example:
display_access_list system_default
%dev#m1>system>acl>system_default
w
*.*
Key Mappings for VOS Functions

VOS provides several command-line and display-form functions. Each function is
mapped to a particular key or combination of keys on the terminal keyboard. To
perform a function, you press the appropriate key(s) from the command-line or display
form. For an explanation of the command-line and display-form functions, see the
manual Introduction to VOS (R001).
The keys that perform specific VOS functions vary depending on the terminal. For
example, on a V103 ASCII terminal, you press the <Shift> and <F20> keys simultaneously
to perform the INTERRUPT function; on a V105 PC/+ 106 terminal, you press the <1> key
on the numeric keypad to perform the INTERRUPT function.
Certain applications may define these keys differently.
Refer to the documentation for the application for the
specific key mappings.
Preface
xi
Preface
The following table lists several VOS functions and the keys to which they are mapped
on commonly used Stratus terminals and on an IBM PC or compatible PC that is
running the Stratus PC/Connect-2 software. (If your PC is running another type of
software to connect to a Stratus host computer, the key mappings may be different.)
For information about the key mappings for a terminal that is not listed in this table, refer
to the documentation for that terminal.
V103
ASCII
V103
EPC
IBM PC or
Compatible
PC
V105
PC/+ 106
V105
ANSI
CANCEL
<F18>
<5> or *
<F18>
CYCLE
<F17>
<F12>
<Alt>-<C>
<4>
<F17>
<Shift>-<F17>
<Shift>-<F12>
<Alt>-<B>
<7>
<Shift>-<F17>
<F19>
<6> or -
<F19> or
<Shift>-<Help>
HELP
<Shift>-<F8>
<Shift>-<F2>
<Shift>-<F2>
<Shift>-<F8>
<Help>
INSERT DEFAULT
<Shift>-<F11>
<Shift>-<F10>
<Shift>-<F10>
<Shift>-<F11>
<F11>
<F11>
<F10>
<F10>
<F11>
<Insert_Here>
INTERRUPT
<Shift>-<F20>
<Shift>-<Delete>
<Alt>-<I>
<1>
<Shift>-<F20>
NO PAUSE
<Shift>-<F18>
<Shift>- *
<Alt>-<P>
<8>
<Shift>-<F18>
VOS Function
CYCLE BACK
DISPLAY FORM
INSERT SAVED
Numeric-keypad key
Format for Commands and Requests

Stratus manuals use the following format conventions for documenting commands and
requests. (A request is typically a command used within a subsystem, such as
analyze_system). Note that the command and request descriptions do not
necessarily include all of the following sections.
xii
Preface
add_disk
Privileged
Purpose
The add_disk command tells the operating system on the current
module to recognize the specified logical volume for the duration of
the current bootload.
Display Form
-------------------------- add_disk ------------------------disk_name:
module_name: current_module
Command Line Form

add_disk disk_name
[ module_name ]
Arguments
Required
disk_name
The name of the logical volume to be recognized for the current
bootload.
.
.
.
A name
The name of the command or request is at the top of the first page of the
description.
B Privileged
This notation appears after the name of a command or request that can be issued
only from a privileged process. (See the online glossary, which is located in the file
>system>doc>glossary.doc, for the definition of privileged process.)
C Purpose
Explains briefly what the command or request does.

D Display Form
Shows the form that is displayed when you type the command or request name
followed by -form or when you press the key that performs the DISPLAY FORM
function. Each field in the form represents a command or request argument. If an
Preface
xiii
Preface
argument has a default value, that value is displayed in the form. (See the online
glossary for the definition of default value.)
The following table explains the notation used in display forms.
The Notation Used in Display Forms
Notation
Meaning
Required field with no default value.
The cursor, which indicates the current position on the
screen. For example, the cursor may be positioned on the
first character of a value, as in a ll.
current_user
current_module
current_system
current_disk
The default value is the current user, module, system, or

disk. The actual name is displayed in the display form of the
command or request.
E Command-Line Form
Shows the syntax of the command or request with its arguments. You can display
an online version of the command-line form of a command or request by typing the
command or request name followed by -usage.
The following table explains the notation used in command-line forms. In the table,
the term multiple values refers to explicitly stated separate values, such as two or
more object names. Specifying multiple values is not the same as specifying a star
name. (See the online glossary for the definition of star name.) When you specify
multiple values, you must separate each value with a space.
The Notation Used in Command-Line Forms
Notation
Meaning
argument_1
Required argument.
argument_1...
Required argument for which you can specify multiple values.
Set of arguments that are mutually exclusive; you must specify

one of these arguments.
argument_1
argument_2
[argument_1]
[argument_1]...
xiv
Optional argument.
Optional argument for which you can specify multiple values.
Preface
Notation
Meaning
argument_1
argument_2
Set of optional arguments that are mutually exclusive; you can

specify only one of these arguments.
Note: Dots, brackets, and braces are not literal characters; you should not type them.
Any list or set of arguments can contain more than two elements. Brackets and braces
are sometimes nested.
F Arguments
Describes the command or request arguments. The following table explains the
notation used in argument descriptions.
G The Notation Used in Argument Descriptions
Notation
Meaning
<CYCLE>
There are predefined values for this argument. In the display

form, you display these values in sequence by pressing the key
that performs the CYCLE function.
Required
You cannot issue the command or request without specifying a

value for this argument.
If an argument is required but has a default value, it is not labeled
Required since you do not need to specify it in the command-line
form. However, in the display form, a required field must have a
valueeither the displayed default value or a value that you
specify.
(Privileged)
Only a privileged process can specify a value for this argument.
H The following additional headings may appear in the command or request
description: Explanation, Error Messages, Examples, and Related Information.

Explanation
Explains how to use the command or request and provides supplementary
information.
Error Messages
Lists common error messages with a short explanation.
Preface
xv
Preface
Examples
Illustrates uses of the command or request.
Related Information
Refers you to related information (in this manual or other manuals), including
descriptions of commands, subroutines, and requests that you can use with or in
place of this command or request.
Online Documentation
Stratus provides the following types of online documentation.
The directory >system>doc provides supplemental online documentation. It
contains the latest information available, including updates and corrections to

Stratus manuals and a glossary of terms.
Stratus offers some of its manuals online, via StrataDOC, an online-documentation
product that consists of online manuals and StrataDOC Viewer, delivered on a

CD-ROM (note that you must order StrataDOC separately). StrataDOC Viewer
allows you to access online manuals from an IBM PC or compatible PC, a Sun or
Hewlett-Packard workstation, or an Apple Macintosh computer. StrataDOC
provides such features as hypertext links and, on the workstations and PCs, text
search and retrieval across the manual collection. The online and printed versions
of a manual are identical.
If you have StrataDOC, you can view this manual online.
For a complete list of the manuals that are available online, as well as more
information about StrataDOC, contact your Stratus account representative.
For more information about StrataDOC as well as a complete list of the manuals
that are available online, contact your Stratus account representative.
Ordering Manuals
You can order manuals in the following ways.
If your system is connected to the Remote Service Network (RSN), issue the
maint_request command at the system prompt. Complete the on-screen form

with all of the information necessary to process your manual order.
Customers in North America can call the Stratus Customer Assistance Center
(CAC) at (800) 221-6588 or (800) 828-8513, 24 hours a day, 7 days a week. All
other customers can contact their nearest Stratus sales office, CAC office, or
distributor; see the file cac_phones.doc in the directory >system>doc for CAC
phone numbers outside the U.S.
Manual orders will be forwarded to Order Administration.
xvi
Preface
Commenting on This Manual

You can comment on this manual by using the command comment_on_manual or by
completing the customer survey that appears at the end of this manual. To use the
comment_on_manual command, your system must be connected to the RSN. If your
system is not connected to the RSN, you must use the customer survey to comment
on this manual.
The comment_on_manual command is documented in the manual VOS System
Administration: Administering and Customizing a System (R281) and the VOS
Commands Reference Manual (R098). There are two ways you can use this command
to send your comments.
If your comments are brief, type comment_on_manual, press <Enter> or <Return>, and
complete the data-entry form that appears on your screen. When you have
completed the form, press <Enter>.
If your comments are lengthy, save them in a file before you issue the command.
Type comment_on_manual followed by -form, then press <Enter> or <Return>. Enter

this manuals part number, R282, then enter the name of your comments file in the
-comments_path field. Press the key that performs the CYCLE function to change
the value of -use_form to no and then press <Enter>.
If comment_on_manual does not accept the part
number of this manual (which may occur if the manual is
not yet registered in the manual_info.table file), you
can use the mail request of the maint_request
command to send your comments.
Your comments (along with your name) are sent to Stratus over the RSN.
Stratus welcomes any corrections and suggestions for improving this manual.
Preface
xvii
Preface
xviii
Chapter 1
The Continuum-Series
System Console
1-
A Continuum-series module does not have a control panel. Instead, a system console
command interface, accessed through a terminal, brings up the commands formerly
available only via the control panel buttons and switches on a Stratus modules front
panel.
The system console is one part of the console controller. The console controller
functions as the central controller for the system. It serves as the systems central
collection point for maintenance and diagnostic information, the information to the
Remote Service Network (RSN), and the control point for the systems power. The
console controller also provides the monitor terminal functionality.
This chapter describes the Stratus system console and includes the following main
topics.
System Messages
For information on the modular control panel found on XA/R-series modules, see
Chapter 2, The XA/R-Series Modular Control Panel. For information about the control
panel that Stratus supported before the modular control panel, see Appendix A,
Control Panels.

On previous Stratus modules, the control panel provided the mechanism for a system
administrator to issue basic instructions, such as those used to shut down and start up
the module. On Continuum-series modules, you issue these instructions through the
system console.
Since the system console simulates a control panel command interface, the system
consoles main menu is called the front panel.
The Continuum-Series System Console
1-1
The system console allows you to perform functions such as booting the module,
shutting down the module, killing power to the module, and reporting the state of all
system indicator lights. Online help is also available via the front panel help command.
To enter the system console front panel, press the <Ctrl> key and the key that performs
the BREAK function simultaneously. The console displays a list of commands. The
exact list of commands presented by the system console varies slightly between
Continuum models. See Figure 1-1 and Figure 1-2.
If the front panel receives no input for 20 seconds, it times out and reverts back to
displaying system messages (Panel goes to sleep... message). Press the <Ctrl>
key and the key that performs the BREAK function simultaneously once again to return
to the front panel display and prompt.
Front Panel Commands:

help ......... displays command list.
boot_auto .... begin automatic mode startup.
boot_manual .. begin operator assisted mode startup.
shutdown ..... begin orderly system shutdown.
power_off .... immediately kill power.
restart_cpu .. force CPU into kernel dump/debug mode.
reset_bus .... force reset *ALL* boards.
status ....... report state of system indicator lamps.
history ...... display switch closure history.
quit, q ...... exit the front panel command loop.
.
.......... display firmware version.
Front panel ready.
Figure 1-1. Continuum-Series Modules (PA-7100 Processor) Front Panel Commands
1-2
Front Panel Commands:

help ......... displays command list.
boot_auto .... begin automatic mode startup.
boot_manual .. begin operator assisted mode startup.
shutdown ..... begin orderly system shutdown.
power_off .... immediately kill power.
restart_cpu .. force CPU into kernel dump/debug mode.
reset_bus .... force reset *ALL* boards.
hpmc_reset ... send HPMC to CPU.
status ....... report state of system indicator lamps.
history ...... display switch closure history.
quit, q ...... exit the front panel command loop.
.
.......... display firmware version.
Front panel ready.
Figure 1-2. Continuum-Series Modules (PA-8000 Processor) Front Panel Commands
The following commands are available through the system console front panel.
* help
Displays a list of front panel commands.
* boot_auto
If the system power is off, boot_auto turns the power on and initiates an
autoboot. If the power is on, this command just sets the auto flag in the console
controller firmware so that the CPU prom will do an automatic boot the next time it
is asked to boot. No further input is required.
* boot_manual
If the system power is off, boot_manual turns the power on and initiates an
operator assisted module startup. If the power is already on, this command just
sets the manual flag in the console controller firmware so that the CPU prom will
perform an operator assisted manual boot the next time it is asked to boot.
* shutdown
This command sends a shutdown message to the operating system, causing it to
initiate an orderly shutdown. When the operating system completes its shutdown,
it sends a command to the console controller to turn off the system power. (The
console controller remains running on housekeeping power.)
* power_off
Immediately kills power to the module. This leaves the console controller running
on housekeeping power.
1-3
Use the POWER_OFF command only when instructed to do

so by the Customer Assistance Center (CAC) or when
there is an emergency such as a fire. Do not use this
button to initiate a normal shutdown. Issue the SHUTDOWN
command for that purpose. If the system is not properly
shut down before it is restarted, its files are left in a state
similar to the state after a system failure.
* restart_cpu
Commences a halt and restart of the module, equivalent to the LEVEL-7 button on
some older Stratus modules. It forces the operating system into kernel
dump/debug mode.
Initiating a halt and restart may require issuing additional
recovery commands once the module has restarted. Files
open at the time of a halt might be left in an inconsistent
state. When possible, issue the shutdown operating
system command from a terminal, or the SHUTDOWN
control command from the control panel. Use the
RESTART_CPU command only if the module does not
respond to other commands or if requested to by the CAC.
* reset_bus
This command sends a reset_bus command to the system. If there is an
unbroken CPU board in the system, reset_bus causes a reset to be sent to all
boards on the bus. What kind of reset will occur on each board depends on its
state. If the board is broken, it will force a cold reset. Otherwise, it will force a
warm reset. If there are no viable CPU boards, the command is a no-operation.
On Continuum-series modules using the PA-7100 processor, if reset_bus
succeeds, the caches are flushed so that a meaningful memory dump can be
taken.
On Continuum-series modules using the PA-8000 processor, if this command
succeeds, the caches are initialized and any dump contents are lost. (This cache
initialization is required as part of the PA-8000 chip initialization). Therefore, the
following warning has been added to the confirm message for this command.
1-4
PA-7100 systems
Repeat command to confirm
PA-8000 systems
Repeat command to confirm:

Warning this does NOT preserve dump data
* hpmc_reset (PA-8000 processor systems only)

hpmc_reset sends a high priority machine check (HPMC) to all CPUs on all
CPU/memory boards in the system. This is essentially a high-priority interrupt. It
invokes an HPMC handler in the console controller prom code that saves context
to RAM memory and flushes the caches to preserve dump information.
This command should be attempted on a Continuum-series module with a
PA-8000-based processor after the shutdown and then restart_cpu
commands fail, and before using reset_bus.
* status
Reports the status of system indicator lights.
* history
Displays a history of the last n front panel commands (limited to the boot_auto,
boot_manual, shutdown, power_off, restart_cpu, reset_bus, and
hpmc_reset commands).
* quit, q
Exits from the system console front panel. As noted previously, the system console
front panel times out automatically if it receives no input for 20 seconds.
* .
Displays the version of firmware currently in use.
When your system is having problems, the order in which you attempt these
commands (from mildest to severest: shutdown, restart_cpu, hpmc_reset, and
reset_bus,) can assist or inhibit the CACs ability to diagnose problems with your
system. Seek assistance from the CAC if you are in doubt as to the order in which you
should enter them.
For more information on using these system console commands within the context of
actually starting up or shutting down a system, see Chapter 3, Starting Up a Module
or System, Chapter 5, Responding to Status Lights, or Chapter 6, Shutting Down
and Powering Off.

A system is hung if the console controller receives no indication of activity from the
operating system for five minutes. Continuum-Series Manual Recovery in Chapter 5
explains how to return a hung system to operation.
System Messages
The following informational messages may appear when the module is running. These
messages do not require any operator input.
1-5
System Messages
* Booting release_number
Specifies the operating system release number being booted. It appears once
during a boot.
* Salvaging logical_volume_name
Specifies the logical volume being salvaged.
* Recovering disk_name
Specifies the disk that is recovering.
* module_start_up
Indicates the start of processing the module_start_up.cm file. While
module_start_up.cm is running, you will see many messages as it starts
individual system services.
* module_start_up complete
Indicates that the module_start_up.cm file has finished processing.
* manual boot ready

Indicates that the system has booted as far as the manual boot command level.
* Shutdown request sent to CPU

Indicates that the shutdown command has been issued from the system console
front panel and the module is being shut down.
* overseer: Shutdown started by username
Indicates that the user username has issued a shutdown command from the
operating system and that the module is being shut down.
* PCP - dumping
Indicates that a dump is being created.
* PCP - command
Indicates that the PCP (Primitive Control Program) is capable of accepting
command input.
* Creating Symbols
Indicates that the OS symbol table creation is in progress.
* HH:MM module_name
Shows the current time and name of the module.
* slot_id message
Indicates that there are board or device errors. For slot_id, one of the following
is displayed:
the affected slot number of the chassis
1-6
System Messages
one of these component names: Bus, BusA, BusB, Battery, Fan, EvBulk,
or OddBulk
For message, one of the following is displayed:
broken: The board is marked as broken.
Failure: The board has a failure code.
missing: The board is marked as missing.
no devs: This board should have devices attached, but none are known.
dev err: Some device attached to the controller has an error, is broken, or is
missing.
Console Controller Messages

The following messages may be generated by the console controller.
* CC:System ID does not match CC stored system ID

The console controller has been inserted in a new host; that is, a host where the
host operating system has not yet burned the backplane ID into the console
controller prom.
* CC:System power is off;CC saved power state is off.

A newly inserted console controller detects that the host power is off. However,
since its stored power state is also off, it did not turn on host power. Use the front
panel command to turn on the power.
* CC:Deadman timer expired; system restart option not selected.
The console controller detected a host failure but the host restart option was not
enabled. You will see this message only if your Continuum systems console
controller was configured with attempt_auto_recovery set to off.
* CC:Host did not respond to initial power on command.

The console controller powered on the host either automatically or as a result of a
panel command, and the host failed to start.
* CC:Sable Diagnostic Failed.
The console controller detected a failure when running the Sable diagnostic
routines. This is an information message only; the console controller continues to
operate if possible. The Sable is the shared memory used for communication
between the console controller and the host.
In addition, when a Continuum-series modules console controller is configured with
attempt_auto_recovery turned on, the controller sends the following series of
messages as it proceeds through its protocol of successively more comprehensive
efforts to restart the system. Once one of the efforts succeeds, the console brings up
1-7
the operating system and, if possible, generates a dump. The protocol and messages
are slightly different, depending upon the Continuum-series module in use.
A PA-7100-based Continuum system displays the following messages.
* CC: Deadman timer expired; trying level7.

The console controller detected a host failure and is attempting a LEVEL-7 restart
of the system equivalent to entering a restart_cpu command on the front panel.
If this effort succeeds, a dump will be produced.
* CC: Level 7 failed after deadman timer expired; trying reset.

The LEVEL-7 restart attempt failed. The console controller is attempting a system
reset equivalent to entering a reset_bus command on the front panel. If this effort
succeeds, a dump will be attempted.
A PA-8000-based Continuum system displays the following messages.
* CC: Deadman timer expired; trying level7.

The console controller detected a host failure and is attempting a LEVEL-7 restart
of the system equivalent to entering a restart_cpu command on the front panel.
If this effort succeeds, a dump will be produced.
* CC: Level 7 failed after deadman timer expired; trying HPMC.
The LEVEL-7 restart attempt failed. The console controller is attempting a system
reset equivalent to entering a hpmc_reset command on the front panel. If this
effort succeeds, a dump will be produced.
* CC: HPMC failed after deadman timer expired; trying reset.

The hpmc_reset attempt failed. The console controller is attempting a system
reset equivalent to entering a reset_bus command on the front panel. If this effort
succeeds, a dump will be attempted, but it will likely be incomplete.
If the reset_bus restart effort fails, the console controller will automatically power
cycle the module.
Console and Error-Log Status Messages

The system console displays the messages that the system continually sends to it
about the operational status of its hardware components. If a status light signals an
error condition, check the system console display for a corresponding error message,
which may give more specific information about the error condition.

A Continuum-series module has three main indicator lights at the top of the module.
From left to right, these lights are the system fault indicator (yellow), the cabinet fault
1-8
indicator (yellow), and the system no fault light (green). Each of these three lights is
either on or off; they do not blink. A brief description follows.
Yellow (first light on the left)There is a faulty component in the system.
Yellow (the light in the center)There is a faulty component in the main cabinet.
GreenAll system components are operating normally.
The lights cycle (repeatedly light one after the other) during system testing. If all
main-cabinet lights are off, there is a power failure.

Each expansion cabinet has one yellow light at the top of the cabinet. The light is off
when all the components within that cabinet are operating without fault. The light is on
only when any component within the cabinet is faulty.
Unit Status Lights

Status lights are located on each customer-replaceable unit in your system. Depending
upon the component, there may be one, two, or three status lights.
For more information on status lights, refer to Chapter 5, Responding to Status
Lights, and the VOS Continuum 600 and 1200 Series with PA-8000: Operation and
Maintenance Guide (R445) and Continuum Operation and Maintenance: 600 and 1200
Series (R396) manuals.
1-9
1-10
Chapter 2
The XA/R-Series
Modular Control Panel
2-
Stratus has adopted a standard, modular control panel for all XA/R-series modules.
This standard control panel is fault-isolating and comprises customer-replaceable
units. It is possible to configure the control panel to be fault tolerant, and you can attach
a terminal or modem directly to the control panel via a serial port. The control panel
supports a special set of query and control commands.
This chapter describes the modular control panel. For more information, see Module
Control Panel Guide: Operation and Replacement (R334). The chapter includes the
following main topics.
Status Display
System Messages
Unit Failure Lights
The only exception to this standardized module control

panel is the panel found on the earliest XA/R-series
module, the 10-slot XA/R Model 20. For information about
this control panel that Stratus provided before the modular
control panel, see Appendix A, Control Panels.
The XA/R-Series Modular Control Panel
2-1

The control panel provides the mechanism for a system administrator to issue basic
instructions, such as those used to shut down and start up the module. The panel for
XA/R-series (RISC-based) modules is mounted in the top left-hand corner of the main
door, protected by a small cover plate that slides upward. The module status lights on
the right side of the control panel are visible through the door.
The modular control panel offers many features, including the following:
configurable fault tolerance
replacement of components by customers
communication to the panel via the panel buttons, or via a serial port connected to
a terminal or modem
Figure 2-1 shows the modular control panel.
Unit Failure Light
Unit Failure Light
OPERATING
MODULE CONTROL UNIT
UNIT
FAILURE
OPERATOR INTERFACE UNIT
UNIT
FAILURE
IMMEDIATE
POWER
OFF/ON
Operating Light
BATTERY
Battery Light
TEST/
PROBLEM
ENTER
CYCLE
Test/Problem Light
Power Switches Door

Cycle Button
LCD
Enter Button
AD0494
Figure 2-1. The Modular Control Panel

The control panel comprises the following:
two customer-replaceable components
module status lights
a door labeled IMMEDIATE POWER OFF/ON, that conceals the two power buttons
The customer-replaceable components are the Module Control Unit (MCU) and the
Operator Interface Unit (OIU). System administrators can remove and replace these
2-2
units without special tools. Refer to Module Control Panel Guide: Operation and
Replacement (R334) for information about replacing these components.

The MCU is typically located on the left of the panel, and has a UNIT FAILURE light.
The MCU controls the operating states of the module, sending signals between the
control panel and the module. It is the only unit capable of controlling the signals sent
to and received from CPUs in the module. During an MCU failure, the system should
continue to run. The ENTER button on the OIU is not operational during an MCU
failure.

The OIU is typically located in the middle of the control panel. It consists of a liquid
crystal display (LCD), a UNIT FAILURE light, and two buttons, CYCLE and ENTER.
These buttons display and select query and control messages. See OIU Query and
Control Messages later in this chapter for more information.

To the right of the customer-replaceable units is the door to the IMMEDIATE POWER
OFF/ON buttons and the OPERATING, BATTERY, and TEST/PROBLEM lights. The
power buttons are located behind a door to prevent a user from accidentally pressing
one of them. The buttons behind the IMMEDIATE POWER OFF/ON door should
always function, even if the MCU fails. These control panel components are described
in the sections Module Status Lights, and Control Panel Buttons, later in this
chapter.
Status Display
The LCD on the OIU displays query and control messages. The LCD also displays
Primitive Control Program (PCP) messages. These two types of messages are
described in the following sections.
2-3

The OIU query and control messages are displayed and cycled by pressing the CYCLE
button and are issued by pressing the ENTER button. Here is the list of the OIU query
and control messages and message descriptions.
* BLANK
The LCD is blank when the OIU enters an idle state. Once the OIU is in an idle
state, either the date/time and module name or a CPU status message or
command are displayed by the LCD. From the idle state, you can use the CYCLE
button to cycle through the OIU commands and press the ENTER button to
execute one.
* AUTO BOOT
Press the ENTER button to instruct the MCU to boot the module without further
input.
* MANUAL BOOT
Press the ENTER button to instruct the MCU to boot the module manually.
* SHUTDOWN
Press the ENTER button to commence an orderly shutdown of the module. The
MCU will send a SHUTDOWN? query to the LCD. To verify that the shutdown should
be initiated, press the CYCLE button until the YES message appears on the LCD,
then press the ENTER button. If you do not press the ENTER button in response
to the YES message within approximately ten seconds, the MCU returns the control
panel to the idle state.
* RESTART
Press the ENTER button to commence a halt and restart of the module, equivalent
to the LEVEL-7 button on some Stratus modules. The MCU sends a HALT &
RESTART? query to the LCD. To verify that the halt and restart should be issued,
press the CYCLE button until the YES message appears on the LCD, then press
the ENTER button. If you do not press the ENTER button in response to YES within
approximately ten seconds, the MCU returns the control panel to the idle state.
Initiating a halt and restart may require issuing additional
recovery commands once the module has restarted. Files
open at the time of a halt may be left in an inconsistent
state. When possible, issue the shutdown operating
system command from a terminal, or the SHUTDOWN
control command from the control panel. Use the
RESTART command only if the module does not respond
to other commands, or if instructed to do so by the CAC.
* REV?
Press the ENTER button to display the current revisions of the MCU board and
PROM code in the control panel.
2-4
System Messages
* YES
* NO
Press the ENTER button to confirm the SHUTDOWN and HALT & RESTART?
commands from the MCU.
Press the ENTER button to terminate the SHUTDOWN and HALT & RESTART?
commands from the MCU.
When you press the CYCLE button, the query and control message appears on the
LCD for approximately five seconds. If you do not press the ENTER button within that
time, the OIU returns to the idle state. If the module sends a message to the OIU in the
middle of a cycle operation, the OIU retains the state currently appearing on the LCD
until you press the CYCLE button again, or until the time out has elapsed.
If you do not respond to the prompt for the SHUTDOWN or HALT & RESTART?
messages within approximately 10 seconds, the MCU treats the lack of response as a
NO.
System Messages
The informational messages appear when the module is running and do not require
any operator input. Following is a list of the system messages.
Booting release_number
during a boot.
Salvaging logical_volume_name

Recovering disk_name

module_start_up
Indicates the start of processing the module_start_up.cm file. While

module_start_up.cm is running, you will see many messages as it starts
individual system services.
module_start_up complete
Indicates that the module_start_up.cm file has finished processing.

manual boot ready
Indicates that the system has booted as far as the manual boot command level.
2-5
System Messages
Shutdown request
Indicates that the SHUT DOWN button on the module has been pressed and the
module is being shut down.
PCP - dumping

PCP - command
Indicates that the PCP (Primitive Control Program) is capable of accepting

command input.
Creating Symbols
Indicates that the operating system symbol table creation is in progress.

HH:MM module_name

slot_id message
Indicates that there are board or device errors. For slot_id, one of the following
is displayed:

one of these component names: Bus, BusA, BusB, Battery, Fan, EvBulk,
or OddBulk

failure: The board has a failure code.
dev err: Some device attached to the controller has an error, is broken, or is
missing.
2-6

The module status lights (described briefly below) are located to the right of the
customer-replaceable units and are visible through small openings in the control panel
door.
* OPERATING
During module startup, this green light alternates with the amber TEST/PROBLEM
light. Once the module is operating, the green light remains lit.
* BATTERY
This yellow light comes on when power to the module is lost, indicating that the
module is not operating but is maintaining a restartable state on its emergency
batteries. The control panel will not operate when the battery light is on, except for
the IMMEDIATE POWER OFF/ON buttons.
* TEST/PROBLEM
This amber light comes on when a fault is detected during the modules operation.
It also alternates with the green OPERATING light approximately every four
seconds during module startup. If the power-on diagnostic detects a problem, the
TEST/PROBLEM light stays on.
Unit Failure Lights

A UNIT FAILURE light is the round amber light located on each customer-replaceable
unit. An amber light on either unit means that the unit has failed and that the unit should
be replaced. Contact the CAC for a replacement unit.
Since the loss of the MCU suspends operation of the control panel, the amber
TEST/PROBLEM light will stay lit until the MCU is removed and replaced. When you
replace the MCU, the UNIT FAILURE light in the replacement MCU will not be lit; the
TEST/PROBLEM light will be on or off depending on whether there are other red-lit
boards in the module.

The control panel has only two visible buttons:
CYCLE
ENTER
However, behind the door labelled IMMEDIATE POWER OFF/ON are two additional
buttons labelled:
O (red power off)
(green power on)

2-7
Figure 2-2 shows the location of the control panel buttons.
OPERATOR INTERFACE UNIT
UNIT
FAILURE
OPERATING
(Power Off
Red Button)
BATTERY
TEST/
PROBLEM
CYCLE
ENTER
(Power On
Green Button)
Cycle
Button
Enter
Button
AD0501
Figure 2-2. Control Panel Buttons
* CYCLE
Use this white button to display and cycle through the query and control messages.
* ENTER
Use this white button to instruct the MCU to perform the operation displayed on the
LCD. For example, if the AUTOBOOT command is on the status display when the
ENTER button is pressed, an automatic reboot of the module is initiated.
* O
* 1
2-8
This red power-off button is located behind the IMMEDIATE POWER OFF/ON
door. Pressing it will initiate an immediate loss of power to the module. Avoid
pressing this button; use the shutdown command whenever possible. Consult
with the CAC before pressing this button unless there is an emergency (such as a
fire) that requires an instantaneous power cut.
This green power-on button is located behind the IMMEDIATE POWER OFF/ON
door. Pressing it will initiate an automatic boot; however, if the disk label had the
-no_auto_boot flag set, a manual boot is initiated. Avoid pressing this button;
use the MANUAL BOOT or AUTO BOOT option instead. Consult the CAC before
pressing this button, unless there is an emergency.

The IMMEDIATE POWER OFF button powers off the module immediately. This button
is located behind the IMMEDIATE POWER OFF/ON door on the modular control panel.
Never press this button unless instructed to do so by the
Customer Assistance Center (CAC) unless there is an
emergency, such as a fire. Do not use this button to initiate
a normal shutdown. Issue the shutdown command for
that purpose. If the system is not properly shut down
before it is restarted, its files are left in a state similar to
the state after a system failure.
2-9
2-10
Chapter 3
Starting Up a Module or
System
3-
Startup is the procedure that powers on and boots a module. This chapter explains how
to perform automatic startup and manual startup, and explains what to do when a
module fails. It includes the following main topics.
Automatic Startup
Manual Startup
Link Boot
As indicated in the Preface, this chapter focuses on the instructions pertaining to

modules with the new system console or modular control panel. Instructions pertaining
to 10-slot XA/R Model 20 modules with a different control panel are included as
additional information. Refer to Appendix A, Control Panels, for more information on
this older control panel.
Automatic Startup
This section describes the automatic startup process.
Single Module Startup

To start up a Continuum-series module with the system console, perform the following
steps.
1. Press the <Ctrl> key and the key that performs the BREAK function simultaneously.
The console displays a list of commands.
2. Enter the boot_auto command to begin startup.
To start up a module with the modular control panel, perform the following steps.
1. Press the CYCLE button until the AUTOBOOT option is displayed.
2. Press the ENTER button to execute the AUTOBOOT option.
Starting Up a Module or System
3-1
Automatic Startup
The OPERATING light alternates with the TEST/PROBLEM light approximately every
four seconds until the operating system is started.
Automatic Startup Functions

At automatic startup, the CPU/memory board runs diagnostics and self-tests stored in
a PROM. After these run successfully, the module finds the master disk. The PROM
starts up the master disk and reads a utility program that loads the operating system
from the master disks default boot partition.
The operating system initializes all disks and then creates a process that executes the
commands in the file module_start_up.cm. See Chapter 4, The Module Startup
Command File, for more information.
During startup, the TEST/PROBLEM light and OPERATING light blink alternately
about every four seconds. When the process TheOverseer is successfully loaded,
the OPERATING light becomes steady. Ordinarily the amber TEST/PROBLEM light
goes off; however, it stays on if the power-on diagnostic tests detect trouble.
Handling Problems with Automatic Startup

For an automatic startup to proceed normally, the >system directory must contain the
file module_start_up.cm and all the files it references. (See VOS System
Administration: Administering and Customizing a System (R281) for more information.)
Following are ways the operating system responds differently to a missing
module_start_up.cm file than it does to the absence of a file the macro references.
If module_start_up.cm is missing, the operating system sends messages
noting its absence to the system consoles monitor terminal and the current system
error log. It waits briefly to allow you to see the monitor terminal message, then
starts an interactive process at command level.
At this point, the operating system has terminated the automatic startup. You are
now at Step 6 of the manual startup procedure described later in this chapter.
Follow Step 6 to finish the startup.
If a configuration table or other file referenced in module_start_up.cm is
missing, the operating system sends messages noting the missing file to the
system consoles monitor terminal and the current system error log, and attempts
to complete the automatic startup. If it is able to finish, you must now perform a
manual startup and re-create the file, as described in VOS System Administration:
Configuring a System (R287).
If the operating system cannot complete the automatic startup successfully, ask the
CAC for assistance.
The automatic startup may also experience problems if module_start_up.cm or any
of the files it references is present, but defective, in >system. In this case, the
3-2
Manual Startup
operating systems behavior and your response are the same as when a configuration
table is missing.
See VOS System Administration: Administering and Customizing a System (R281) for
further information about the system consoles monitor terminal functionality, and
system error logs.
Manual Startup
Manual startup allows you to load the operating system from tape or disk. The
procedure is interactive and therefore requires a monitor terminal. See VOS System
Administration: Administering and Customizing a System (R281) for more information
about the system consoles monitor terminal functions.
During a manual startup, the only functioning editing key
is <BACKSPACE>.
Disk Boot and Tape Boot

In most cases, you perform the manual boot from disk. This means that the operating
system is loaded from a boot partition, which is a region of the master disk. See VOS
System Administration: Disk and Tape Administration (R284) for more information.
Boot from tape only in the following cases:
if you want to physically reload all the contents of the master disk
if the master disk has so many irrecoverable errors that you cannot boot from it
In a boot from tape, the operating system is loaded from a boot tape. This is a tape that
contains a copy of the operating system and a complete copy of the contents of the
master disk. A boot tape is created when the dump_disk command executes on a
master disk. See VOS System Administration: Backing Up and Restoring Data (R285)
for specific information. Always have a current boot tape available.
If you rename a boot disk, you must create a new boot tape. When you boot from tape,
the disk name on the boot tape must be the same as the boot disks name. If the names
are inconsistent, the operating system prompts you to rename the disk to its former
name (the name on the boot tape) so that the tape can reload the disk. See VOS
System Administration: Disk and Tape Administration (R284) for more information on
boot disks.
A boot from tape is a relatively standard task except when
a tape drive is not attached to the module that is to be
booted. If you have an XA/R-series module, you may
prefer to perform a link boot, a boot through the
3-3
Manual Startup
StrataLINK communications network. See Link Boot

later in this chapter for details.
The Steps in a Manual Startup from Disk or Tape

The following sections describe the procedure for manual startup from disk or tape for
Stratus modules. Except for Steps 4a and 4b, the steps are the same for disk boot and
for tape boot.
If the manual startup is not successful, call the CAC.
1. To initiate the manual reboot, perform the following steps.
a. On a Continuum-series module with the system console, press the <Ctrl> key
and the key that performs the BREAK function simultaneously, and then enter
the boot_manual command. The module status lights cycle while the
computer is starting up. The green no-fault light become steady when the
computer is running.
b. On a module with the modular control panel, cycle to the MANUAL BOOT
command on the LCD and press the ENTER button. The green OPERATING
lights alternate with the amber TEST/PROBLEM lights approximately every
four seconds while the computer is starting up. The green OPERATING lights
become steady when the computer is running.
2. If you manually boot a module from tape, you must first load the tape. If the tape
drive has an ONLINE button on its control panel, you must also press that button
to put the tape online.
3. The system consoles monitor terminal displays the following question:
Boot from slot?
If you are booting from the master disk, press <RETURN> without entering a number.
Otherwise, enter the number of the main chassis slot containing the disk controller,
tape controller, or IOP to be used for the manual boot, and press <RETURN>.
If the specified main chassis slot contains an IOP, the terminal displays an
additional prompt:
Enter IOA slot/device in the form ss/dd
To boot from the default device on the IOA associated with the specified IOP, press
<RETURN> without entering any numbers. To boot from the default device on a
specified IOA, enter the adapter slot number and press <RETURN>. To boot from any
other device, enter its adapter slot number and device number, separated by a
slant character (/), and press <RETURN>.
4. The procedure differs, depending on whether you are booting from disk or tape.
3-4
Manual Startup
a. Disk. Because you specified either a disk controller or disk IOA connected to
an IOP in Step 3, the terminal displays the following question:
Boot from partition?
To load the operating system from the default boot partition, press <RETURN>
without entering a number. To load the operating system from a specific
partition, enter a valid boot partition number from 1 to 8; in this case, pressing
<RETURN> is not necessary.
The boot disk should always be a duplex disk, as described in VOS System
Administration: Disk and Tape Administration (R284). If the primary partner of
the boot disk is not functioning, press the STOP button and repeat Steps 1, 2,
and 3, using the slot number of the secondary partner of the boot disk.
This is the end of the disk description. Skip to Step 5.
b. Tape. Because you specified either a tape controller or a tape IOA connected
to an IOP in Step 3, the operating system asks you questions regarding
formatting, initializing, and reloading the master disk. See VOS System
Administration: Disk and Tape Administration (R284) for more information. You
can choose to reformat or initialize the master disk before you reload it, or you
can answer no to the formatting and initializing questions to go directly to the
reloading procedure.
i. The terminal displays the question on formatting first.
Do you want to format disk_name?
The disk_name argument above refers to the uninitialized disk name of
the master disk. The uninitialized disk name describes the disks physical
location within the module. Refer to VOS System Administration: Disk and
Tape Administration (R284) for more information about uninitialized disk
names.
If you answer yes and the master disk does not already have a valid label,
the master disk is formatted. If you answer yes and the master disk
already has a valid label, the operating system asks you to verify that you
want to destroy the master disks contents by formatting.
Are you sure? disk_name has a valid label now-If you answer yes to this question, the master disk is formatted.
If you formatted the master disk, go to Step iii.
Answering no to either the formatting question or the verification question
bypasses the formatting procedure and lets you choose initialization or
reloading instead.
3-5
Manual Startup
ii. The terminal displays the initialization question next.

Do you want to initialize disk_name?
The disk_name argument above refers to the uninitialized disk name of
the master disk. The uninitialized disk name describes the disks physical
location within the module. Refer to VOS System Administration: Disk and
Tape Administration (R284) for more information about uninitialized disk
names.
If you answer yes and the master disk does not already have a valid label,
the operating system asks you to supply certain initialization data. If you
answer yes and the master disk already has a valid label, the operating
system asks you to verify that you want the master disks contents
destroyed by initialization.
Are you sure? disk_name has a valid label now-If you answer yes to this question, the master disk is initialized.
If you answered no, go to Step iv.
iii. If you formatted or initialized the master disk, the operating system then
asks you to supply two values: the type of disk drive and size of its paging
partition. See the descriptions of the initialize_boot_disk and
display_disk_label commands in VOS System Administration: Disk
and Tape Administration (R284) for information about these values. After
you supply these values, the terminal displays the question on reloading.
iv. Answering no to either the initialization question or the verification
question bypasses the initializing procedure and skips to the reloading
question.
Reload master disk disk_name?
You can answer yes, no, or -u (unattended).
Answer yes if you have a boot tape to work with and you want to reload
the master disk from that boot tape. The operating system is loaded from
the boot tape along with all files of the master disk.
Make sure the master disk you are reloading is the same size as the
master disk from which the dump image was made. If the new master disk
is a different size, the reload will not be performed correctly. Also, make
sure that the disk you are reloading uses dynamic bad block remapping.
Dynamic bad block remapping copies bad blocks to good blocks in a spare
disk partition.
While reloading progresses, the operating system prompts you to load any
subsequent tapes needed. You do not need to rewind them.
3-6
Manual Startup
If you answer -u (unattended), the operating system is loaded as if you

answered yes, but you are not prompted to load subsequent tapes. Note
that this option is meaningful only of your tape drive supports
-unattended mode. For additional information about loading tapes with
the -u option, refer to the description of the save command in VOS
Commands Reference Manual (R098).
If you answer no, the operating system alone is loaded into memory and
the paging partition from the boot tape. The usual disk boot partitions will
not be reloaded, and other methods of restoring at least one such partition
must be done before a disk boot can be performed.
5. The system consoles monitor terminal displays the following question:
Enter PCP for manual damage repair (%system#master_disk)?
Unless the CAC tells you to respond to this question with yes, respond with no
followed by <RETURN>.
If you respond no, the monitor terminal displays the following question:
Override devices.table parameters with system defaults for
monitor terminal?
Answer no to this question to use the device parameters specified in the
devices.table file for the system consoles monitor terminal.
Answer yes if there is a problem with the devices.table file for the monitor
terminal. This override allows the system to accept data from the monitor terminal.
Correct the devices.tin file from the monitor terminal and re-create the
devices.table file. Reboot the system once the correction is made to the file
and answer no once the reboot process reaches this question again.
When performing a manual boot from an IOP-based device on an XA/R-series
module, you are asked an additional question. (This IOP-related dialogue does not
appear on Continuum-series modules.)
Override IOP configuration?
Answer no to this question to use the normally configured IOP software (as you
would for an automatic boot).
Answer yes if there is a problem with the configured software. You will then be
prompted to supply the names of the firmware files to be used for the IOP and for
3-7
Manual Startup
asynchronous channels on communications adapter types 1, 3, and 5, with

questions similar to these.
Default IOP Firmware (iop_type_a.pm)?
Comm adapter types 1/3/5 Firmware file (ioa01_async.pm)?
The default answer for each question is given in parentheses. Press <RETURN> if you
want to use the default; otherwise, specify the name of a file in the directory
>system>firmware to be loaded.
Finally, on all systems, the terminal displays the following message to indicate that
the manual boot is completed:
Overseer.System logged in
ready date/time
You are now at command level; your current directory is
(master_disk)>Overseer. The user name of the process on the system
consoles monitor terminal is Overseer.System.
6. If necessary, repair or re-create module_start_up.cm or a configuration table,
or repair the command library. See VOS System Administration: Configuring a
System (R287) for instructions, and finish the startup as described in that manual.
If a previous module startup failed, display the file module_start_up.out,
located in the >Overseer directory, for information about why the startup failed.
If you do not need to repair or re-create files, proceed to Step 7.
7. To complete a normal startup, type the following:
start_logging module_start_up.out <RETURN>
>system>module_start_up <RETURN> <NOPAUSE>
This sequence tells the operating system to execute the commands in the file
module_start_up.cm (described in Chapter 4, The Module Startup Command
File) and to create a log file that records the execution of the commands.
If you log out before executing module_start_up.cm and/or TheOverseer
process is not running, the operating system creates a new login process and
positions you at Step 6.
8. Log out the Overseer process on the system consoles monitor terminal.
3-8
Link Boot
Link Boot
As noted in the previous section, you perform a tape boot when the master disk on the
module to be booted has enough unrecoverable errors to prevent a reliable disk boot
or when you want to physically reload the entire contents of the master disk. In most
cases, a tape boot is a straightforward task; however, if a tape drive is not physically
attached to the module to be booted, the operation can be complicated and time
consuming. If you have an XA/R-series module, you may want to perform a link boot in
this circumstance.
You cannot perform a link boot on Continuum-series
modules.
A link boot of a module is a boot of the module performed via the StrataLINK
communications network. A boot source, accessible to another module on the same
system, communicates with the module to be booted using a server process called a
link boot server (described later in this section) to provide the information needed for
the boot.
The performance of a link boot operation is slightly slower than that of a local boot, but
a link boot can be more convenient.
Link Boot Module Requirements

A link boot operation requires two modules.
The booting module, the module to be booted via the StrataLINK communications
network.
The server module, the module to perform the boot. The server module must be on
the same system as the booting module, and must have access to the boot source.
The number of modules on a given system may affect the success of a link boot.
StrataLINK traffic density is directly proportional to the total number of modules on a
given system, so the likelihood of an error during a link boot increases as the number
of modules increases. Therefore, the maximum number of modules that can exist on a
system without interfering with a link boot is unique to each case.
1. If you initiate the link boot from a module that is
running VOS Release 11.1 or later, all I101-10 and
I101-11 Link Controllers in the module that was
booted are capable of transferring 32 bits of data at a
time on to and off of the StrataBUS.
2. If you initiate the link boot from a module that is
running a release of VOS earlier than 11.1, all I101-10
and I101-11 Link Controllers in the module that was
booted will transfer 16 bits of data at a time on to and
off of the StrataBUS.
3-9
Link Boot
The Link Boot Source

The boot source for the link boot can be a boot tape, an operating system program file,
or a boot partition located on any other module on your system. Therefore, when
performing a link boot from a boot tape, you do not need to be concerned with the
physical location of the tape drive on which the boot tape will be mounted.
When you perform a link boot from tape, you can reformat, reinitialize, and/or reload
the master disk.
The Link Boot Server

A link boot server is a server process that responds to link boot requests from the
booting module by transferring data from the boot source to the booting module. The
link boot server must be started on the server module. Start the link boot server with
the command link_boot_server.
Only one link boot server is allowed on a system at a time. To ensure this, a link boot
server, when started, checks immediately to see whether there is another link boot
server on the same system by issuing a new link boot request. If it finds a second link
boot server, the first link boot server stops further processing and performs a routine
cleanup. If it does not find a second link boot server, it proceeds with the link boot.
See VOS System Administration: Administering and Customizing a System (R281) for
the description of the link_boot_server command.
The Steps in a Link Boot

To boot a module via the StrataLINK communications network, perform the following
steps in the order shown. Two messages shown below often appear during this
procedure which do not indicate a problem with the link boot.
net interrupt for unassigned link
net_driver: station ## has ring number # configured as ring #
If you see these messages, continue the link boot procedure as if no messages were
displayed.
1. On the server module, invoke a link boot server by entering the
link_boot_server command with a valid boot source option.
2. On the booting module, perform a manual boot as described earlier in the section
Manual Startup with the following directions.
a. Supply the main-chassis slot number of a link controller in the booting module
at the following prompt:
Boot from slot?
3-10
Link Boot
b. The following prompts appear only in the boot from link procedure. The values
displayed in parentheses are default values for the booting module. To accept
a value, press <RETURN> at the prompt. To change a value, enter the new value
at the prompt followed by <RETURN>.
Enter
Enter
Enter
Enter
Enter
system number system_number:

system name system_name:
system module number system_module_number:
system module name system_module_name:
net address net_address:
c. At the end of this step, the module is booted but the link boot may not be
complete. However, the link boot server is no longer needed; it will be
terminated automatically.
3-11

The operating system symbol table is created each time a new version of the operating
system is booted. If an error occurs and this file is not created during bootload, you will
get one of the following messages during the execution of programs that reference the
symbol table file, such as analyze_system and tp_overseer.
e$corrupted_os_symtab (4214) if the format of the symbol table is unusable
e$wrong_os_symtab (4215) if the symbol table is not for the current version of
the operating system

e$cant_open_os_symtab (4216) if the symbol table is not readable or has not
been created
These messages are returned to the .out file for that process and to the terminal if the
process is run from a terminal. If this occurs, delete the out-of-date symbol table by
typing delete_file (master_disk)>system>os.symtab and create an
updated version with the create_os_symtab command.
3-12
Chapter 4
The Module Startup
Command File
4-
This chapter documents the module_start_up.cm file and includes an excerpt from
the file. It includes the following main topics.

The module_start_up.cm file contains commands that the operating system
executes as part of the procedure for starting up a module. It is contained in the
>system directory of the master disk of every module in a system. See VOS System
Administration: Administering and Customizing a System (R281) for information about
the >system directory. You may want to store a copy of the module_start_up.cm
file in the >system>configuration directory for protection if the >system copy is
lost.
Some of the functions performed by commands in this file include the following:
reading the table files that specify the configurations of boards, disks, and devices
connected to the module

identifying the modules within a system
starting system service processes such as TheOverseer, spooler, and network
watchdog
Some commands, called system process commands, are used mostly in
module_start_up.cm files. For example, you would never issue the operating
system command overseer, and you probably would not use the commands
link_server or network_watchdog. The system process commands initiate
service processes for the module.
Every module must have a copy of module_start_up.cm. You cannot start up the
operating system properly without it. If it is missing, refer to VOS System
Administration: Configuring a System (R287) for instructions on re-creating it.
The Module Startup Command File
4-1
The sample module_start_up.cm file that is shipped with the installation software
is stored in the directory (master_disk)>system>release_dir.

This section provides an example of how to construct a single module_start_up.cm
file for use in every module of a multimodule system. The purpose of this procedure is
to solve the following problems that exist when each module has its own
module_start_up.cm file.
Whenever you make a change that applies to the whole system, you must make
the same change to copies on every module. You can make the change in one
copy and then copy that file to another location on the same module, but you
should check before copying the updated file to another module. The
module_start_up.cm file for each module probably has commands unique to its
own module, and executing it on another module may not work.
To have a complete picture of the systems startup configuration, you must look at
all the files.

The example uses goto and label statements to execute different commands on
different modules.
Example
The following excerpt from a module_start_up.cm file replaces several lines of the
installation file.
The first block of commands starts the spooler and the print queues on module #m1. It
replaces the lines in the installation file that initialize and start the spooler process. The
second block starts X.25 gateway processes on module #m2. (These processes allow
the system to be part of a wide area network.) It replaces the lines in the installation file
that start the X.25 gateway processes. The last four lines of the file contain labels for
use when additional modules are added to the system.
4-2
&set_string module_name (after (current_module) #)

&goto setup_per-module_&module_name&
&
&label setup_per-module_m1
&
delete_file spool.p1.0.out.old
rename spool.p1.0.out spool.p1.0.out.old
create_file spool.p1.0.out
set_implicit_locking spool.p1.0.out
spooler_admin login #p1.0 -queue standard
&
spooler_admin attach_printer #p1.1 -queue standard
spooler_admin start_queue #p1.1 -queue wide
spooler_admin start_queue #p1.1 -queue envelopes
&
&goto setup_per-module_end
&
&
delete_file x25.m2.1.out.old
rename x25.m2.1.out x25.m2.1.out.old
create_file x25.m2.1.out
set_implicit_locking x25.m2.1.out
start_process 'x25 m2.1 #sc01.2 -syserr' -priority 8
-privileged
+-process_name x25.c01.1 -output_path x25.m2.1.out
&
delete_file x25.m2.2.out.old
rename x25.m2.2.out x25.m2.2.out.old
create_file x25.m2.2.out
set_implicit_locking x25.m2.2.out
start_process 'x25 m2.2 #sc01.4 -syserr' -priority 8
-privileged
+-process_name x25.c01.2 -output_path x25.m2.2.out
&
&goto setup_per-module_end
&
&label setup_per-module_end
The Module Startup Command File
4-3
4-4
Chapter 5
Responding to Status Lights
5-
This chapter describes what to do if a status light, or fault indicator light, is lit on a
controller board or cabinet. This chapter focuses on Continuum-series modules. On
older modules, the meaning of status-light states may be different. This chapter
includes the following main topics.
Proper Recovery
Recovery Procedures
Recovering from System Initialization Process Failure during a Boot
If you suspect that a module has stopped functioning, first check the system fault
indicator light. If it is on, check to see if a red light is lit on one of the controllers. The
system console will then indicate one of three conditions, which are outlined and
discussed in the section Recovery Procedures later in this chapter.
After you check the system console, call the CAC to report the failure. You probably will
not need assistance to recover from the failure. However, notify the CAC staff
immediately that the failure has occurred so that they can trace and correct its cause.

Each Continuum main cabinet has three labeled status lights arranged at the top of the
main cabinet (see Figure 5-1). From left to right, there are two yellow lights and one
green light.

Each expansion cabinet has one yellow light, labeled Cabinet Fault, at the top of the
cabinet (see Figure 5-1). It lights when a component within the expansion cabinet has
failed.
5-1
For more information on status lights, refer to the VOS Continuum 600 and 1200 Series
with PA-8000: Operation and Maintenance Guide (R445) and Continuum Operation
and Maintenance: 600 and 1200 Series (R396) manuals. (The latter manual is for
PA-7100 based processors.)
SYSTEM
FAULT
CABINET
FAULT
Main Cabinet
NO
FAULT
Expansion Cabinet
CABINET
FAULT
cm0046
Figure 5-1. Main Cabinet and Expansion Cabinet Status Lights
Table 5-1 describes the meanings of the status lights.

Table 5-1. Main Cabinet and Expansion Cabinet Lights
5-2
Yellow
System
Fault Light
Yellow
Cabinet
Fault Light
Green
No Fault
Light
On
Off
Off
There is a faulty component somewhere in

the system outside of the main cabinet.
On
On
Off
There is a faulty component inside the main

cabinet.
Off
Off
On
All components are operating normally.
Off
Off
Off
The power is off.
Meaning

Both CPU/memory boards and communications boards have three lights arranged
vertically in a traffic-light configuration (see Figure 5-2). From top to bottom, they are
red, yellow, and green.
K450,
K460
CPU/
or
Memory K600
600-Series
Main Chassis
Red
Amber
Green
Backpanel
Power Supply
Console
Controller
CPU/Memory
K450, K460
or K600
1200-Series
Main Chassis
Red
Amber
Green
Backpanel
Power Supply
CM0047
Console
Controller
cm0047
Figure 5-2. Logic-Chassis Board Lights
Table 5-2 describes the meanings of the logic-chassis board lights.

5-3
Table 5-2. Logic-Chassis Board Lights
Red Light
Yellow
Light
Green
Light
Meaning
On
Off
Off
The board is faulty and should be replaced.
Off
On
On
Do not remove the board. It is operating, but its

partner is not.
Off
Off
On
The board is operating normally and is duplexed.
Off
Off
Off
The board is not operating. This could be due to a

power failure or a need to reboot the module.
On
On
On
The system is conducting a self-test.
Blinking
On
Off
The system is conducting a self-test.
Blinking
Blinking
Off
The board has not been configured.
For more information on status lights, refer to the VOS Continuum 600 and 1200 Series
with PA-8000: Operation and Maintenance Guide (R445) and Continuum Operation
and Maintenance: 600 and 1200 Series (R396) manuals.
A red light on a board indicates either that the board is being tested or that the board
has experienced a failure. This section discusses both of these conditions.
To determine the reason for a red light, check the following:
the system console
the boards and connectors themselves, to be sure they are in place
the list_boards and check_boards requests in the analyze_system
subsystem
the modules current syserr_log.date file
Use the notify_hardware_error command to

instruct the operating system to display notification on one
or more specified terminals whenever an entry is written
to hardware_log.date.
Keep these log files for at least two weeks, or until the CAC verifies that the information
is no longer needed, and then delete them.
Board Testing
Board testing occurs at the following times:
5-4

when the module is started up (by either a manual boot or an automatic boot). All
boards in the module are tested at this time.

when a board is inserted. The board itself is tested at this time.
Staff at the CAC may also conduct board testing at other times. For example, the CAC
may test the boards in a module to determine which board is causing bus errors.
Board Failure
If a board fails a test or if the checking logic on a board detects erroneous data, the
operating system removes the board from service for further testing by a system
process called the diagnostic utility process. If this process finds that the boards
problem was transient, it restores the board to service. Otherwise, the board remains
out of service, its red light remains lit, and the fault indicator light on the cabinet is lit.
The reset_configuration command turns off the fault indicator light when a board
has been removed from service but has not yet been replaced or repaired. This frees
the light so that it can signal additional failures, if necessary. See VOS System
Administration: Configuring a System (R287) for information about the
reset_configuration command.
If your system is part of the Remote Service Network (RSN), the diagnostic process
sends notification of the failure to the RSNs hub, where the CAC attempts to diagnose
and correct the problem. If your system is not part of the RSN, call the CAC to report
the problem.
If the failed board is not duplex and is crucial to the modules operation, the module
fails. See the next section, System Problem Analysis, for information about how to
proceed.

Stratus emphasizes system availability and reliability and therefore carefully analyzes
incidents of system problems at customer sites.
In the event of a system problem, it is very important that you save all files and other
information pertinent to problem resolution, even after a successful reboot, so that the
cause of the problem can be resolved. Therefore, for all open or unresolved calls to the
CAC, save the information for a minimum of one month unless the CAC indicates that
it is no longer needed.
5-5
Proper Recovery
When there is a system problem, save the following files:

syserr_log.date files
dump files
the version of any user programs (the .pm files) involved in a failure, related files
such as .kp modules and (for batch processes) their .out files, and the source
files
Installing a different version of the operating system before the cause of the problem is
resolved destroys some information necessary for problem analysis. Therefore, before
any such installation during the one month period, save the following items as well:
a copy of the boot partition in use at the time of the dump. Use the copy_kernel
command to save a copy of the boot partition on another disk if necessary.

the analyze_system.pm file that corresponds to the kernel version at the time of
the dump
If you cannot save dump files on the master disk itself, copy the dump to another disk
and create a link in (master_disk)>Overseer>dumps that points to the dump in the
new location. Use the object name of the dump as the name of the link. Do not save
the hardware_log.(date) files.
To ensure that relevant information is saved, use the command
set_expiration_time to set an explicit expiration date before which the files
cannot be deleted.
Proper Recovery
This section describes what must occur in a proper recovery and then explains how to
respond to each of the conditions you may encounter after a failure.
For a module to recover properly from failure, the following must occur.
A dump image must be written to the dump partition of the master disk. A dump
image consists of all modified disk blocks of the operating system and selected disk
blocks of processes that were running at the time of the failure. A dump partition is
a region of a disk; see VOS System Administration: Disk and Tape
Administration (R284) for a full explanation.
The module must reboot by loading the operating system.
The operating system must execute the commands in the module_start_up.cm
file, including the copy_dump command, which copies the contents of the dump
partition to a file. The CAC can examine this file for information about the cause of
the failure.
5-6
Recovery Procedures
Recovery Procedures
After a module failure, the modules system console indicates one of the following
conditions:
The module is automatically dumping and rebooting if the -auto_boot switch is
on in the label of the modules master disk.

The module is running the Primitive Control Program (PCP) if the -auto_boot
switch is off in the label of the modules master disk.

The module is taking no action.
The rest of this chapter describes the recovery procedures to use for each of these
conditions.
Recovering with Automatic Dump and Reboot

Wait several minutes for the module to execute the automatic restart sequence. While
the sequence executes, the system console displays various messages. When the
recovery is complete, the message Please login appears on all login terminals
connected to the module.
Recovering with PCP Execution

If the system console displays the message pcp ready, follow these steps.
1. Type dump at the system console, and press <RETURN>. If you omit this step, you will
be prompted later to request that a dump image be written. See Step 2.
2. When the console displays the ready message, type boot and press <RETURN>.
If you omitted Step 1, the console displays the following prompt before performing
the reboot:
Would you like to dump the current state of the
system before rebooting? (yes, no)
Type yes or y and press <RETURN>.
When the recovery is complete, the message Please login appears on all login
terminals connected to the module.
5-7
Recovery Procedures

A module is hung if it sends no indication of activity to the console controller for five
minutes.
The recovery process is either manual or automatic for Continuum-series modules,
depending on the setting of the attempt_auto_recovery variable. The recovery
process for XA/R-series modules is manual.
This section explains:
how to determine and change the attempt_auto_recovery setting on a
Continuum system
manual and automatic recovery of a Continuum system
manual recovery of an XA/R system.
Determining the attempt_auto_recovery Setting

The setting of the attempt_auto_recovery variable determines whether your
Continuum system automatically attempts to recover or requires that you restart it
manually. This variable may be set differently on different systems.
To determine a systems attempt_auto_recovery setting, use the eeprom_admin
command to read the config partition on both console controllers. Perform this
procedure.
1. Issue the eeprom_admin command from the VOS command line. The display
form appears.
2. Supply the following argument values.
device_idthe slot number of the first console controller, 36
-actionread
-partitionconfig
-forceno
-askyes
3. Press <Enter>. The following form appears.

---------------------------eeprom_admin: ReCC Config -----------------------------config_output_dir
4. Press <Enter>. A display form appears, confirming your choices and asking if you
want to continue.
5-8
Recovery Procedures
5. If the information is correct, answer yes to the question Do you want to

continue?.
6. The eeprom_admin command produces output similar to the following. The
second line shows the attempt_auto_recovery setting. In this example, it is
set to Yes.
power_boot: Yes
attempt_auto_recovery: Yes
shadow_console: no_shadow
Front panel timeout (recc_config.panel_timeout): 20000 ms
Successful completion of read.
7. Repeat the procedure for the second console controller, specifying slot number 37
in the device_id field in step 2.
Changing the attempt_auto_recovery Setting
Enabling automatic recovery attempts (that is, setting attempt_auto_recovery to
Yes) is not recommended, since the automatic recovery process can delete system
information the CAC needs to determine the cause of the system failure.
To change the setting of the attempt_auto_recovery variable in either case, call
the CAC.
Continuum-Series Manual Recovery
If your module hangs, you will receive the CC:Deadman timer expired; system
restart option not selected console controller message after five minutes of
module inactivity. Follow these steps to recover the module.
1. Press the <Ctrl> key and the key that performs the BREAK function simultaneously.
The console displays a list of commands. Try each of these commands in
succession until one succeeds in bringing up the module and operating system.
Table 5-3 shows the commands to use in the manual recovery process.
Table 5-3. Manual Recovery Command Sequence
PA-7100-Based Systems
restart_cpu
reset_bus
restart_cpu
hpmc_reset
reset_bus
2. If none of these commands succeeds, issue the power_off command to power

down the module.
5-9
Recovery Procedures
3. Issue the boot_auto command.

4. If powering up in automatic mode is unsuccessful, issue the boot_manual
command and follow the steps for startup documented in the The Steps in a
Manual Startup from Disk or Tape section of Chapter 3.
Continuum-Series Automatic Recovery
You can have the CAC configure your modules console controller to attempt recovery
automatically. The CAC sets the console controller variable to on to enable automatic
recovery attempts. Automatic recovery is chosen in some installations where modules
run untended for extended periods of time. However, automatic recovery is not
recommended, since it can destroy data the CAC needs to diagnose the cause of the
module failure.
If attempt_auto_recovery is set to yes, when the console controller receives no
response from the operating system for five minutes (that is, its deadman timer
expires), the console controller attempts to restart the module. Various messages are
sent to the system console indicating that this is happening. (See the Console
Controller Messages section in Chapter 1, The Continuum-Series System Console,
for a description of the messages sent to the system console during an automatic
restart sequence.)
In its effort to restart the module, the console controller starts with restart_cpu. This
operation will generate a dump that will enable the CAC to analyze the problem.
(Issuing restart_cpu is equivalent to pressing the RESTART, HALT & RESTART, or
LEVEL-7 interrupt buttons on older Stratus modules.) If issuing restart_cpu does
not work, the console controller tries progressively more powerful restarts including,
ultimately, a power cycle of the system.
The sequence of commands entered depends upon the modules processor type.
Table 5-4 shows the sequence.
Table 5-4. Automatic Recovery Command Sequence
restart_cpu
reset_bus
power cycle
restart_cpu
hpmc_reset
reset_bus
power cycle
For example, on a PA-8000-based Continuum-series module, the console controller

first tries a restart_cpu command. If that is unsuccessful, it tries the hpmc_reset
command. If that does not work, it tries reset_bus. If that is unsuccessful, it power
cycles the machine.
5-10
XA/R-Series Recovery
On an XA/R-series module with the modular control panel, perform the following steps.
1. Cycle to the RESTART command and press ENTER. This should begin either
automatic startup or execution of the Primitive Control Program (PCP).
2. Power down the module. Do this by pressing the red POWER OFF button located
behind the IMMEDIATE POWER ON/OFF door.
3. Cycle to the AUTO BOOT command on the LCD and press the ENTER button.
4. If powering up in automatic mode is unsuccessful, repeat Step 3 using the
boot_manual command and follow the steps for startup documented in The
Steps in a Manual Startup from Disk or Tape section of Chapter 3.
Recovering from System Initialization Process Failure during a

Boot
During a boot of the operating system, a system initialization process is created to
manage certain aspects of the boot. For an automatic boot, the system initialization
process is the process that runs module_start_up.cm; for a manual boot, it is the
login process created on the monitor terminal (which runs module_start_up.cm).
The operating system checks for the existence of the system TheOverseer process
at termination of the system initialization process. If TheOverseer is not running, the
operating system displays the following message on the system console monitor
terminal.
System initialization failed, performing manual boot. Code XXXX.
A login process is then created on the monitor terminal so that you can correct the
problem that caused the initialization to fail. You can use the code displayed in the
message, output files such as module_start_up.out, and the current system error
log to identify the problem that caused the failure.
5-11
5-12
Chapter 6
Shutting Down and
Powering Off
6-
This chapter outlines the steps in shutting down and powering off one or more modules,
and discusses emergency shutdowns. It includes the following main topics.
Planned Shutdowns
Emergency Shutdown
A module must be shut down before it is powered off;

otherwise, its files will be left in a state similar to the state
after a module interruption.

You can define a series of commands to be executed immediately before module
shutdown. For example, you can arrange to stop queue requester processes before
queue server processes.
When VOS starts to shut down, it searches for the command macro
(master_disk)>system>module_shut_down.cm. If it finds the command macro,
VOS executes it before shutting down the module. Note, however, that VOS will stop
the command macro after two minutes and begin terminating user processes and
shutting down the module. If the command macro does not exist, module shutdown will
proceed normally.
Planned Shutdowns
The shutdown command shuts down one or more modules. The -module argument
determines which modules are shut down. You can shut down:
only the current module by omitting the -module argument
one specified module by naming it in the -module argument
all modules in the system by giving the value * in the -module argument
Shutting Down and Powering Off
6-1
Planned Shutdowns
some modules in the system by giving a star name that matches those modules in
the -module argument

Unless you give the -no_ask argument, the operating system asks if you wish to shut
down each of the designated modules.
The shutdown command has several additional arguments, called the reboot
arguments, that are used to reboot each designated module immediately after it is shut
down. In addition, for the purpose of tracking system availability, the command
indicates a reason for the shutdown in an output statement verifying that the system is
shutting down. See Chapter 8, Command Overview, for information about the
shutdown command.
Issue the shutdown command with a reboot argument when you want to update
configuration tables, implement changes made to a disk label, or install a new release
of the operating system. Do not use a reboot argument when you need to power down
the module to move it, or in case of an emergency.
If you choose to execute the shutdown command as a
batch process, you must be sure to give the batch
commands -no_restart argument. Otherwise, when
the module on which the batch process was running starts
up, the process restarts and shuts down the specified
modules again.
Perform the following steps to shut down and power off a module.
1. Give the broadcast command to inform users of imminent shutdown. For
example, you could give the command in either of the following forms when
shutting down a module:
broadcast '%m1 will shut down in 5 minutes' -module *
broadcast '%m1 will shut down at 5:00 p.m.' -module *
2. If your system is connected to the RSN, always invoke the demo_mode request of
the maint_request command if you are merely demonstrating a shutdown of
your module or if you are pulling any boards. This prevents spurious hardware error
messages from being sent to the CAC. When you are finished demonstrating these
features, invoke maint_request again to turn the demo mode off. See VOS
System Administration: Administering and Customizing a System (R281) for
information about the maint_request command.
3. Give the following command to display the names of users still logged in on the
module to be shut down:
list_users -module module_name
6-2
Emergency Shutdown
4. When you are satisfied that no users are logged in, give the shutdown command.
This tells TheOverseer to terminate all processes still logged in on the specified
module and to shut down the operating system on that module.
Entering the shutdown command on the system console
has the same effect on the module as invoking the VOS
shutdown command.
5. Wait for TheOverseer to display the following message on the monitor terminal:
overseer: Shutdown started by user.group
If the -auto_boot argument of the display_disk_label command is in force,
the module reboots automatically; otherwise, the module powers off. Powering off
a module in this way does not affect other modules in the system. The module can
also be powered up again without affecting other modules.
Emergency Shutdown
Emergency shutdown is a process called during a module interruption. For example, if
the CAC instructs you to enter the restart (XA/R-series) or restart_cpu
(Continuum-series) command from the system console, the operating system
automatically calls the emergency shutdown process.
When possible, use the shutdown command to shut the
module down before rebooting it. See the shutdown
command description in Chapter 8, Command
Overview.
Emergency shutdown performs the following tasks:
verifies in-memory structures for disks and files
saves a dump image of the operating system
writes out modified disk cache blocks to disk
writes out file partition bit maps to disk
updates directory entries for modified files, indexes, and directories

updates labels on mounted disks
When emergency shutdown is successful, the disks do not need to be salvaged,

directory entries for modified files are updated, and the module returns to service
without invoking the salvager. It also eliminates disk recovery for disks that have been
successfully shut down. Note that if the -auto_boot flag is not set, the module
remains in PCP mode.
6-3
Emergency Shutdown
You can follow the progress of an emergency shutdown by watching the monitor
terminal for messages about the shutdown these messages are not written out to the
syserr_log.date file. The output for emergency shutdown varies depending on
what forced the shutdown. The following example shows the output produced by
emergency shutdown after entering the RESTART (XA/R-series) or restart_cpu
(Continuum-series) command from the control panel.
Emergency Shutdown in progress...
Emergency Shutdown: The wired heap has verified.
Emergency Shutdown: No hardware problems have been detected.
Emergency Shutdown: Level 7 button pressed / 0000xxxx.
Emergency Shutdown: Scanning for idle disks.
Emergency Shutdown: No shared vm pages written.
Emergency
Emergency
Emergency
Emergency
Emergency
Shutdown: Starting cache writes for %s1#m2_d01.

Shutdown: Cache writes complete for %s1#m2_d01.
Shutdown: Writing out bitmaps for %s1#m2_d01.
Shutdown: Shutting down disk %s1#m2_d01.
Shutdown complete.
Allow emergency shutdown to complete. It is usually

the fastest way to recover from a malfunctioning or
non-responsive system, since it prevents lengthy salvage
and disk recovery operations after reboot. Power-cycling
a nonresponsive system is not the fastest way to reboot
and resume operation. Moreover, power-cycling prevents
the CAC from diagnosing the problem.
6-4
Emergency Shutdown
Emergency shutdown is not called in the following instances.

Either you (manually) or the system console controller (automatically) issues an
hpmc_reset (Continuum-series), reset (XA/R-series), or reset_bus

(Continuum-series) command.
You issue the power_off command from the Continuum system console, or press
the red power off button located behind the IMMEDIATE POWER ON/OFF door on
an XA/R modular control panel.
The module loses power, and the power is out longer than the batteries can retain
the contents of memory. Since memory is not preserved, there is no data for the
emergency shutdown process to use. The batteries will last about 20 minutes.
The system determines that an emergency shutdown cannot be successfully
performed. In this case, the message Emergency Shutdown not attempted

is displayed.
If the message Emergency Shutdown complete does not appear on the monitor
terminal, it means that emergency shutdown did not complete. This may occur even if
the module reboots successfully. In this case, VOS invokes the salvage_disk and
start_disk_recovery commands. Follow the procedures documented in
Chapter 7, Recovering from a Crash.
6-5
Emergency Shutdown
6-6
Chapter 7
Recovering from a Crash
7-
This chapter includes the following main topics.

A module interruption, or crash, may occur due to an extended power failure, softwareor hardware-detected inconsistencies in system behavior, or the failure of multiple
hardware components. Stratus modules can recover automatically following a crash,
often without user intervention. This chapter documents what to do after a module
recovers from a crash, and describes the intervention you, as the system administrator,
need to perform if a module does not recover automatically. It also explains what can
happen to files during a crash and what you may need to do to recover files.
If you have any questions about the material presented
here, contact the CAC.

After a crash, the module either reboots automatically, or requires a system
administrator to restart the module. Whether or not a module reboots automatically
depends upon how the -auto_boot argument of the update_disk_label
command is set. For information about this command, see VOS System
Administration: Disk and Tape Administration (R284). For information on starting up a
module, see Chapter 3, Starting Up a Module or System.

During startup, the operating system attempts to configure all hardware as part of its
normal reboot sequence. However, occasionally it is unable to return certain hardware
7-1
devices to service following a crash. A device may fail during a crash, and may require
intervention to return to service.
Normally, the operating system automatically sends in a trouble call to the CAC when
a device cannot be restored to service. CAC personnel then log in to the module to
diagnose the cause of failure, to assist in failure recovery, and to determine whether
part replacement is required.
However, you should perform a manual review of the hardware state, to determine
whether any hardware was not returned to service and how such failures may impact
applications on the module.
Here are the tasks you should perform for each module after it starts up.
Examine module boards, IOAs (I/O adapters), communication cards, and power
supplies to be sure they have successfully returned to operation.

Use the list_boards or check_boards requests of analyze_system to
list the boards or IOAs that are out of service.
Check the >system>syserr_log.date file for information about boards
and IOAs.
Check disks to ensure that they have powered up successfully, and are going
through correct disk recovery measures.

Inspect the READY lights on disk drives and red lights on disk controllers and
use the display_disk_info -long command to review the state of each
drive.
Check the >system>syserr_log.date file for information about drives that
may have failed to return to service, mount, or recover.
Check the syserr_log.date file for information about communications devices.
Make sure the firmware loads correctly in all communications boards and IOAs.
Typical failures can result from changes made during the prior bootload that do not
occur automatically when the module is rebooted. These types of changes include:
device attributes changed with the update_channel_info command, but
not changed in the devices.tin file, or changes to the devices.tin file
that have not been applied to the devices.table file
communications protocols added with the configure_comm_protocol
command, but not added to the module_start_up.cm file

The disk salvager detects and repairs directory information about files on each member
of a logical disk. A directory is a segment of disk storage containing files, links, and
subdirectories. The disk salvager detects when data blocks have been allocated to a
file and written to the disk, but are not reflected in the count of the number of blocks in
7-2
the directory entry for the file. The disk salvager does not update file attributes
describing the contents of a file. The salvager ensures that data structures within each
directory are consistent. A logical volume is a grouping of up to ten member disks. The
disk salvager writes to one partner of each member of the logical volume being
salvaged. When salvaging completes, the logical disk is mounted with simplexed
members. Disk recovery copies the data from each salvaged member onto its partner.
Disk Salvager Errors

The operating system sends the following messages to the syserr_log.date file
during a successful disk salvage.
20:43:22
20:44:07
20:44:10
Starting salvage of %s1#m2_d01.

Salvage of %s1#m2_d01 complete. 837 blocks read, 3
blocks written.
m2_d01 mounted. 64756 blocks used out of 84336.
The following syserr_log.date file indicates that salvage_disks failed when

attempting to mount one of the partners of a duplexed disk pair. In this case, the
duplexed pair is member 0 of a two-member logical disk.
20:42:06
20:42:54
20:42:54
20:42:54
disk 0500 f 10
4718 02 00000000 00000000 unable to
read valid label
salvage_disks: Partner expected but not found for disk
m1_d02.0-2.sec
m1_d02.0-2.sec state: DUPLEXED updated: 91-07-26
20:20:04
salvage_disks: Duplex disk m1_d02.0 is invalid.
Code = 3514
The syserr_log.date file identifies directory entries for file data, indexes, and
directories changed by the salvager.
17:55:46
17:55:57
17:55:57
Starting salvage of %s1#m1_d04.

Error salvaging #m1_d04>production>data
Last block for _record_index has been changed from 16
to 17.
7-3
17:55:57
17:56:10
17:56:10
17:58:32
17:58:38
17:59:51
18:01:16
Blocks used for _record_index has been changed from 18

to 19.
Last block for dfile1 has been changed from 3229 to
3231.
Blocks used for dfile1 has been changed from 3234 to
3236.
Blocks used is wrong for directory. Is 86,
should be 87.
Last block is wrong for directory. Is 84, should be 85
Salvage of %s1#m1_d04 complete. 1841 blocks read,
6 blocks written.
m1_d04 mounted. 1058006 blocks used out of 1120256.
If you use transaction protection, do not attempt to restart
your applications until the TPOverseer restarts
successfully. The TPOverseer restart may fail because
transaction-protected files were lost or damaged during
the crash or during disk salvage. Contact the CAC for
information on how to recover from a TPOverseer failure.
Disk Recovery
To recover a duplex disk is to bring the less current partner of a duplex disk pair up to
date with its mounted partner. When recovery completes, the recovered partner is then
mounted. The disk pair is again operating as a duplexed pair, as indicated by the
display_disk_info command. See VOS Commands Reference Manual (R098) for
more information on this command.
The start_disk_recovery command checks all the duplex disks in a module for
recovery. It starts a disk recovery operation for each pair that is not fully duplexed. The
recover_disk command recovers the partner of a duplexed disk. At the end of a
recovery, the partnered disks are identical.
For more information on disk salvage and recovery, see VOS System Administration:
Disk and Tape Administration (R284). To improve performance of the disks, configure
the disks to write in parallel. For information on this, see VOS System Administration:
Disk and Tape Administration (R284).

The module reboot sequence includes steps to automatically start service processes
used during normal module operation. Service processes are processes started by the
module_start_up.cm file that perform background functions for the module. Service
processes include communication and queue servers and TheOverseer processes.
7-4
Before starting applications, check that all service processes required for the module
started correctly. Review the state of module service processes by performing the
following tasks.
Check the >Overseer>module_start_up.out file and the other .out files in
that directory to ensure that all service processes started up correctly. If any error
messages are found, correct the problems and restart the service process before
continuing.
Compare the .out and .out.old files to look for differences which indicate
failures. For example, compare module_start_up.out with
module_start_up.out.old.
If you use transaction protection, check the syserr_log.date file to ensure that
the TPOverseer (Transaction Processing Overseer) process was able to

successfully reprocess the existing transaction logs and has begun to process new
transactions.
The following system messages show a typical restart of the TPOverseer process.
19:57:01
19:57:04
19:57:04
19:57:05
19:57:05
tp_overseer(11.11.01): Initializing.
tp_overseer(11.11.01): Processing transaction log
tlf.3-1.0000018077.91-09-07
tp_overseer(11.11.01): Reestablishing unfinished
transactions.
tp_overseer(11.11.01): Transaction log processing
completed.
tp_overseer(11.11.01): Transaction processing
started.
The following set of system messages show a failure of the TPOverseer process
to restart correctly.
19:08:48
19:08:51
19:08:51
19:08:51
19:08:51
tp_overseer(11.11.01): Initializing.
tp_overseer(11.11.01): Processing transaction log
tlf.3-1.0000018077.91-09-07
tp_overseer(11.11.01): Reestablishing unfinished
transactions.
tp_overseer(11.11.01): The specified disk volume is
not mounted. %s1#m1_d04>production>data>file_1
Record #3492 (TLF_MOD_PHASE_1_COMMIT) in log
tlf.3-1.0000018077.91-09-07
tp_overseer(11.11.01): Terminated.
If you use transaction protection, do not attempt to restart

you applications until the TPOverseer restarts
successfully. TPOverseer restart may fail because
transaction-protected files were lost or damaged during
7-5
the crash or during disk salvage. Contact the CAC for help
in recovering from a TPOverseer failure.

This section documents how a file can become damaged during a crash, and what you
may need to do to recover it.
Understanding File Recovery

A file is a logical unit of storage containing a sequence of records. Many applications
require that files have indexes. An index is an ordered set of keys; each key is
associated with zero records or one record in a file. Files and indexes that are open at
the time of a crash may be damaged by the interruption, causing inconsistencies in
data. For more information about file indexes, see the VOS Reference Manual (R002).
Transaction protection prevents the loss of file data during a crash. Changes to
transaction-protected files are recorded in a transaction log before the file is modified.
File and index changes in progress at the time of a crash are applied to their respective
files and indexes when the TPOverseer restarts. For more information about
transaction protection, see VOS Transaction Processing Facility Guide (R215).
Disk I/O Concepts
Disk Cache
The operating system stores recently accessed disk blocks in a disk cache in system
main memory. The disk cache is a temporary buffer that stores data until it is written
out to disk by the runout_opcode of the s$control subroutine, or until it is pushed
out of the buffer by normal use.
File data, file indexes, and directories are first modified in the disk cache, and then the
modified blocks are written out to disk.
When a crash occurs, modified blocks still residing in the disk cache may be lost. Files,
indexes, or directories modified near the time of a crash may be incomplete or
inconsistent when the module reboots. Usually, data blocks for a file are written to disk,
but the directory information for the file may not have been written to disk at the time of
a crash. Also, modified data and index blocks written to disk before the crash may not
have been recorded in the directory entry for the file.
When a module is stopped by the shutdown command, the disk cache is written to
disk before the module shuts down. Since the blocks in the disk cache are written to
disk, the files are left in a consistent state before the shutdown occurs. For more
information on invoking planned shutdowns with the shutdown command, see
Chapter 6, Shutting Down and Powering Off, of this manual.
7-6
When a crash calls the emergency shutdown process, emergency shutdown writes
modified disk cache blocks to disk and updates the directory entry for modified files.
Thus, file data loss and inconsistencies are minimal when emergency shutdown
succeeds. Only records or keys being modified at the time of the crash are lost. See
Chapter 6, Shutting Down and Powering Off, for information on emergency
shutdown.
End-of-File Pointer
The file system keeps a record of file attributes, including information such as the
last_record_number value, in the directory entry for the file. This
last_record_number value is used differently by the various file types, but is
commonly called the end-of-file (EOF) pointer. It tells the operating system where to
begin when writing new records, and where to stop when reading file data. This value
is typically updated only at the time the file is closed or when the buffers are written out
(by a program calling s$control with the runout_opcode). Between updates, the
information is kept only in operating system memory. Data records can be lost when
the value of this field does not reflect the true end of file, and the data may not appear
to be on the disk.
After a reboot, the end-of-file pointer may not include records in blocks written to disk
since the last runout_opcode or file open operation. Thus, valid data records written
to disk before the crash might be on the disk but not logically accessible when the
module reboots. The salvager does not attempt to verify the last_record_number
value against the actual contents of a file as it does not examine a files contents.
Similarly, modified file index blocks may not be written to disk at the same time as the
data blocks containing modified records associated with the index. At crash time, if the
index block is written but the data block is not, then an index entry may point to a
nonexistent or invalid data record location, or to the wrong data record. If the data block
is written but the index block is not, then a data record may not be pointed to by any
index entry, or the wrong index entry may point to the record. As a result, file accesses
through the index will return incorrect data.
Checking for File Consistency

Before starting applications after a crash, check for file and directory consistency by
performing the following tasks.
Check the syserr_log.date file for disk information. The log will report whether
the disks were successfully updated by emergency shutdown. No further checking

for file recovery is required on disks that were successfully shut down by
emergency shutdown. A successful emergency shutdown logs the following
message to the syserr_log.date file:
Salvage not required for #m1, Emergency Shutdown complete.
7-7

Check the syserr_log.date file for salvager messages. If the disk salvager
found inconsistencies, the inconsistencies were recorded, as shown previously in

the system error logs. If the salvager discovered inconsistencies in any directory,
you should examine the files in the directory and repair damage logged by the
salvager. If the salvager found major inconsistencies and removed objects from a
directory, you may need to restore the removed objects from the most recent save
tape.
Checking Transaction-Protected Files
The TPOverseer preserves the contents of transaction-protected files and indexes
following a crash by reapplying all committed transactions that were not completely
written to disk prior to the crash. During most recoveries, as long as the TPOverseer
restarts successfully following the module reboot, transaction-protected files will not
have file integrity problems. However, transaction-protected files may be lost if the
disk salvager, in an attempt to make directory entries consistent, deleted directory
entries for these files. While these files may be lost, the records are stored in
transaction logs, which means transaction-protected files may be restored after a
crash.
Before restarting applications using transaction protection on the module, perform the
following tasks.
Check the syserr_log.date file for a list of transaction-protected files that were
changed by the disk salvager during module recovery.

If you need to restore transacted-protected files from tape, refer to VOS
Transaction Processing Facility Guide (R215) to learn about the tp_restore

command.
Checking Other Types of Files
Files being modified at the time of the crash may be inconsistent after the module
reboots. Before starting applications after a crash, check files opened by the
application at the time of a crash, to be sure data was not lost.
Tell your users to get in the habit of checking files they had open at the time of a crash
once the module reboots.
Verifying the End of a File
Before restarting any application that uses non-transaction-protected files, use the
verify_end_of_file command to check for consistency between the end-of-file
pointer and records actually written to data blocks at the end of the file.
The verify_end_of_file command verifies that the end-of-file pointer, in a
directory entry, points to a correct location within a file following a crash. The command
also has the ability to search for the correct (or likely) end-of-file pointer in the file data
and update the directory entry. If verify_end_of_file advises that additional
records can be recovered by adjusting the end-of-file pointer on one or more files, use
7-8
verify_end_of_file command with the -update_directory argument to make

the adjustments.
Be sure you understand this chapter and the
verify_end_of_file command before attempting to
use the command. Only privileged users are allowed to
execute this command with the -update_directory
argument. For complete documentation of the
verify_end_of_file command, see Chapter 8,
Command Overview.
Testing and Verifying File Indexes
File indexes may be damaged during a crash, and it is impossible to look at an index
the way you can a file. VOS provides two tools in the >system>maint_library
directory to help you diagnose problems with file indexes and the data files they
reference.
* test_index
The test_index command invokes the test index subsystem. The test index
subsystem provides a series of tools to display the structure of an index and
determine whether you will need to re-create it. The test_index command will
help you determine whether the index itself has become corruptedit checks the
index file for internal consistency. To discover whether the data file that the index
references has become inconsistent with its index, you must use the
verify_index command.
* verify_index
The verify_index command uses the index file to exhaustively access its
accompanying data file, thereby revealing any inconsistencies between the two
files that must be repaired. Because verify_index tests every key in the index
to reference the data file, it executes considerably more slowly than test_index.
It is, however, faster than recreate_index.
Both test_index and verify_index are described in detail in Chapter 8,
Command Overview.
Re-creating File Indexes
After a crash, index keys may no longer point to the file data records they should. The
verify_index command checks for this inconsistency. If it discovers
inconsistencies, the recreate_index command rebuilds embedded-key indexes
from the data records in the file, ensuring that keys and records are consistent. Use this
command if your application reports errors when referencing an index, or if it points to
the wrong record identified by a key, or if some records have no corresponding key.
When files have been adjusted by the
-update_directory argument of the
7-9
verify_end_of_file command, their indexes must be

re-created.
To re-create indexes, check the type of indexes you need to re-create, and perform the
following steps.
Use the recreate_index command to re-create embedded-key indexes.
When files have non-embedded key indexes, a tool should be written to rebuild
these indexes in case they are damaged. The recreate_index command

cannot re-create the other types of indexes. You may need to restore these files
and their indexes from a backup tape.
For more information on re-creating indexes, see the recreate_index command in
Chapter 8, Command Overview, of this manual.
Patching Files and Indexes

The VOS directory >system>maint_library contains two commands,
patch_file and patch_index, that perform what is colloquially known as a patch
function upon files and indexes, respectively. That is, given a user-specified offset into
a file or index, these commands will substitute the byte(s) at that location with the
byte(s) that the user specified in the disk image of the file or index.
Experienced users can use the patch_file and patch_index commands to make
small emergency repairs to files where the exact location and mistaken bytes are
known.
Use of these tools requires detailed knowledge of VOS file
and index formats (see the VOS Reference
Manual (R002) for information about VOS file and index
formats). They are designed for use by knowledgeable
customers or service personnel. If misused, they can
render a file or index unusable.
Both patch_file and patch_index require that the user be logged in as privileged
and have write access to the file or index being repaired.
You can use the dump_file command to display the contents of a file in hexadecimal
format. See its description in theVOS Commands Reference Manual (R098).
For more information on patching files and indexes, see the patch_file and
patch_index descriptions in Chapter 8, Command Overview, of this manual.
7-10
Chapter 8
Command Overview
8-
This chapter documents the following system administration commands.

broadcast
patch_file
patch_index
recreate_index
shutdown
test_index
verify_end_of_file
verify_index
The patch_file, patch_index, test_index, and
verify_index commands are not stored in the
command_library directory. They are stored in the
maint_library directory.
To access these commands from the maint_library directory, you must do one of
the following:
invoke the command with its path name, such as
>system>maint_library>test_index
add the following line to your start_up.cm file.
add_library_path command >system>maint_library
Command Overview
8-1
broadcast
broadcast
8-
Purpose
The broadcast command sends a message to all login terminals on one or more
modules or throughout a system.
Display Form
----------------------------------- broadcast ---------------------------------message:
-module: ''
Command-Line Form
broadcast message
[-module modules]
Arguments
* message
Required
The text of the message to be broadcast. The message must be no longer than a
single terminal display line. When you give the message in the command line form,
it must be enclosed in apostrophes if it contains any spaces.
* -module modules
Specifies a module name or star name. To broadcast the message throughout all
the modules in the current system use the value * for modules. If you omit this
value, the operating system broadcasts the message to users on the current
module.
Examples
The following command sends throughout the system the message that is enclosed in
apostrophes.
broadcast
8-2
'System shutting down at 7 PM'
-module *
broadcast
The following command sends to all login terminals on module m2 the message that is
enclosed in apostrophes.
broadcast
'%s1#m2 shutting down at 7 pm'
-module %s1#m2
Related Information
See the description of the send_message command in VOS Commands Reference
Manual (R098).
Command Overview
8-3
patch_file
patch_file
Privileged
Purpose
The patch_file command changes a file without regard to its organization or
content.
Use of this tool requires detailed knowledge of internal
VOS file formats. (See the VOS Reference
Manual (R002) for information about VOS file formats.) It
is a repair tool designed to be used by knowledgeable
customers or service personnel.
Display Form
----------------------------------- patch_file ---------------------------------file_path_name:
block_num:
offset:
value:
-check
-long:
no
Command-Line Form
patch_file file_path_name block_num offset value
[-check check_value]
[-long]
Arguments
* file_path_name
The name of the file to be patched.
Required
* block_num
Required
The zero-origin number of the 4096-byte file block to be patched. (Note that
dump_file uses one-origin record numbers.)
8-4
patch_file
* offset
Required
The zero-origin offset of the word or longword within the specified file block to be
patched.
* value
Required
The new value. It must be four or eight hexadecimal digits representing either two
or four bytes of data.
* -check check_value
An optional argument that specifies the old value of the word or longword to be
patched. It must be four or eight hexadecimal digits representing either two or four
bytes of data. If the check_value value does not equal the present value at the
specified offset, then the patch is not applied. The default is to accept any value.
* -long
<CYCLE>
An optional argument that specifies that a message recording the offset, old value,
and new value is to be displayed. The default is to display no message.
Explanation
The patch_file command opens a file for exclusive update access in block I/O
mode, which permits it to operate on any file type. Any indexes on the file are ignored;
any changes made to the records of the file will not be reflected in any of the indexes.
Use the accompanying patch_index command to change an index.
Use of the -check argument is recommended to ensure that the location you are
changing has the expected value.
Access Requirements
You must be logged in as privileged and have write permission to a file in order to patch
it.
Examples
The following example changes the first line of the default system abbreviations
file. Specifically, it replaces the line
all
CD
by
current_dir
with the line:

first
CD
by
current_dir
Note that the character represents a blank character. 66697273 is firs, 616C6C20
is all , 7420 is t , and 2020 is
. The patch begins in block 0 at offset 2
because the first two bytes of the file is a record control word.
Command Overview
8-5
patch_file
Example:
!copy_file >system>abbreviations abbrev.test -delete
!patch_file abbrev.test 0 2 66697273 -check 616C6C20
!patch_file abbrev.test 0 6 7420
-check 2020
Related Information
See the VOS Reference Manual (R002) for information on the internal formats of files
and file indexes.
See the VOS Commands Reference Manual (R098) for a description of the
dump_file command. It produces a hexadecimal dump of a files data blocks.
See the patch_index, recreate_index, test_index, verify_end_of_file,
and verify_index command descriptions in this chapter. All provide tools to analyze
and fix file problems.
8-6
patch_index
Privileged
patch_index
Purpose
The patch_index command changes the data in an index block without regard to its
organization or content.
Use of this tool requires detailed knowledge of VOS file
formats. (See the VOS Reference Manual (R002) for
information about VOS file formats.) It is a repair tool
designed to be used by knowledgeable customers or
service personnel.
Display Form
----------------------------------- patch_index --------------------------------file_path_name:
index_name:
block_num:
offset:
value:
-check:
-root_block:
-numeric:
no
-long:
no
Command-Line Form
patch_index file_path_name index_name block_num offset value
[-check check_value]
[-numeric]
-root_block root_block_value
[-long]
Arguments
* file_path_name
The path name of the file whose index is to be patched.
Required
Command Overview
8-7
patch_index
* index_name
The name of the index to be patched.
Required
* block_num
Required
The zero-origin number of the 4096-byte index block to be patched.
* offset
Required
The zero-origin offset of the word or longword within the specified index block to be
patched.
* value
Required
The new value. It must be a hexadecimal value representing either 4 or 8 bytes of
data.
* -check check_value
An optional argument that specifies the old value of the word or longword to be
patched. It must be four or eight hexadecimal digits representing either two or four
bytes of data. If the check_value value does not equal the present value at the
specified offset, then the patch is not applied. The default is to accept any value.
* -root_block root_block_value
Required
Use extreme care in determining and specifying the root
block number. You can easily render the index unusable.
If you do happen to use the wrong root block value, simply
patch the location back to the previous value in order to
respecify the correct root block value.
Specifies the value of the root block number for this index. The value specified will
become the new root block number for the index. The test_index commands
status request will display the root block number.
You can obtain the value of the current root block number by using the
verify_index command.
* -numeric
<CYCLE>
An optional argument that specifies that this is a numeric index. The default is no,
meaning that an alphanumeric index is displayed. This argument is needed only to
produce a readable display of formatted output; it does not affect the patching
process.
* -long
<CYCLE>
An optional argument that specifies that a message recording the offset, old value,
and new value is to be displayed. The default is to display no message.
Explanation
The patch_index command opens a file for exclusive update access in block I/O
mode, which permits it to operate on any file type. Any changes made to any of the
8-8
patch_index
indexes are local to that index; any key changes will not be reflected back to the file.
Use the accompanying patch_file command to change the file contents.
Stratus recommends using the -check option to ensure that the location you are
changing has the expected value.
Access Requirements
You must be logged in as privileged and have write permission to a file index in order
to patch it.
Examples
The following example swaps the first two keys in the system dictionary, rendering
them out of order.
!copy_file >system>system_dictionary dict.bad -delete
!patch_index dict.bad primary 1 14 0FD6 -check 0FDC -root_block 3
!patch_index dict.bad primary 1 1A 0FDC -check 0FD6 -root_block 3
Related Information
See the VOS Reference Manual (R002) for information on the internal formats of files
and file indexes.
See the VOS Commands Reference Manual (R098) for a description of the
dump_file command. It produces a hexadecimal dump of a files contents.
See the patch_file, recreate_index, test_index, verify_end_of_file,
Command Overview
8-9
recreate_index
recreate_index
Purpose
The recreate_index command re-creates embedded-key indexes of files.
Display Form
----------------------------------- recreate_index -----------------------------pathnames:
-index_names:
*
-max_num_processes: 5
-work_dir:
-brief:
no
-ask:
yes
-duplicate_path:
-recovery_macro:
-syserr:
yes
8-10
8-
recreate_index
Command-Line Form
recreate_index pathnames ...
[-index_names index_names] ...
[-max_num_processes number_of_processes]
-work_dir [pathname]
[-brief]
[-no_ask]
-duplicate_path [pathname]
-recovery_macro [pathname]
[-syserr]
Arguments
* pathnames
Required
The path names of one or more files, any of which may be star names, with indexes
to be re-created.
* -index_names index_names
Required
One or more index names, any of which may be star names, associated with the
files named by pathnames. The default is *, which means all embedded-key
indexes of all the files specified in the pathnames argument will be re-created.
* -max_num_processes number_of_processes
Required
Specifies the number of index creation processes that may be run simultaneously.
The default value is 5.
* -work_dir pathname
Specifies that the temporary work files created when the indexes are re-created
reside in the specified directory. The directory can be on the same or another disk
of the current module. If you specify the -work_dir argument but do not specify
pathname, recreate_index uses the current directory. If you do not specify a
work directory, the command uses the process directory of the current process.
* -brief
Suppresses the display of non-error information.
<CYCLE>
Command Overview
8-11
recreate_index
* -no_ask
<CYCLE>
Processes the indexes without prompting the user for confirmation. Use this
argument when issuing the recreate_index command from a batch process.
* -duplicate_path pathname
Specifies that invalid duplicate keys found in records read from the file(s) should
not be inserted into the index. Instead, information should be logged in the file
specified by pathname.
If the -duplicate_path argument is not specified and invalid duplicate keys are
encountered, the command will terminate immediately.
The duplicate path log file in pathname will contain information about all of the
indexes that were re-created sufficiently to locate the records containing the invalid
duplicate keys, as well as information about the record that the key (already in the
index) locates.
If the file contains no duplicate keys, or the indexes allow duplicate keys, the
duplicate path log file in pathname will be deleted when the command completes.
See the Examples section later in this command description for sample output of
-duplicate_path.
* -recovery_macro pathname
Helps prevent the loss of an index if recreate_index cannot re-create the index.
If you specify this argument, recreate_index writes a command macro that
uses the create_index command to re-create all indexes that
recreate_index could not re-create.
If recreate_index cannot create one or more indexes, it writes a warning to the
system error log file, (master_disk)>system>syserr_log.date, that
instructs the user to correct the problem and run the command macro. If
recreate_index can create the indexes, the command macro is deleted.
Note that recreate_index does not append a .cm suffix to the command macro
name if one is not present. The command does not create the command macro if
you specify -recovery_macro without a path name.
The command macro deletes any existing indexes and uses the start_process
command to start subprocesses, each of which runs create_index on the target
file with the arguments needed to re-create an index. The command macro
creates, in the same directory as the target file, the output files used by these
subprocesses to hold the index information. These output files are named
target_file_name.index_name.out. You must examine the output files to
ensure that all create_index commands completed successfully.
8-12
recreate_index
If any resulting output-file names will exceed 32 characters, recreate_index

displays a warning and also includes the warning in the command macro. (The
command macro will abort with a warning to shorten long output-file names if you
run it before renaming the output files.) If you receive this warning, you must
shorten the output-file name(s), and you must also remove the warning message
and its accompanying &return statement from the command macro.
The recreate_index command determines whether to delete the command
macro and issue a warning based on whether the index definition information has
been written successfully, not on whether the index itself has been written
successfully. If the index attributes for any of the re-created indexes do not match
those of the original index, recreate_index displays a message on your
terminals screen instructing you to use the command macro after correcting the
original problem.
* -syserr
<CYCLE>
Causes recreate_index to write the information needed to re-create the
indexes to the >system>syserr_log.date log file before starting to re-create
the indexes. The default is yes. This process allows you to recover this information
from the syserr_log.date log file if a system interruption occurs during the
re-creation. Note that the command writes this information only to the
syserr_log.date log file, not to the system console monitor terminal.
Explanation
The recreate_index command performs three functions in one command. The
command specifies correct index parameters, deletes the old index, and creates a new
index. It also allows for interactive selection of the files and indexes.
Index rebuilding can be delayed for several hours if there is a pressing need to restart
applications immediately. However, indexed access to nontransaction-protected files
adjusted by the verify_end_of_file command may result in accessing the wrong
record, or in displaying file system error codes diagnosing index or file format errors.
The recreate_index command attempts to predict when the creation of an index will
fail, and does not attempt to re-create the index if this validation fails. This is done to
prevent deletion of an index. The indexes are created in parallel.
Because the recreate_index command creates temporary files, you must be sure
that you have sufficient disk space. In many cases, you can estimate the amount of disk
space required by multiplying the total number of index blocks by 1.5. This disk space
must be available on the disk containing the work directory.
After executing the recreate_index command, always execute the command
display_line (command_status) to display the current value of
command_status. The command_status value for the process is affected by this
command. When the command terminates, the (command_status) command
Command Overview
8-13
recreate_index
function can be tested for the following values. Other nonzero values are possible if
errors occur.
Status
Code
Status Code Name
Meaning
None
Normal termination. This includes the case when the

specified files and/or indexes could not be processed
(and no attempt was made to re-create the indexes in
question) or all attempts at actually creating an index
were successful.
1099
e$bad_index_defined
At least one attempt to create an index failed, leaving

a file without that index. The problem that prevented
creation of the index must be corrected and the index
must be created using the create_index
command.
1279
e$abort_output
The <CANCEL> key was pressed while output was being

displayed.
For more information on command functions, see VOS Commands Users

Guide (R089).
8-14
recreate_index
The recreate_index command validates the following types of files:

sequential
relative
fixed
The recreate_index command does not validate pipe, stream, or transaction files.
Transaction protection must be turned off before using this command; however, this
command should not be needed for transaction-protected files. Implicit locking must be
turned off, and the file whose index you are trying to re-create must not be open when
using this command. The safety switch must also be turned off.
You must have write access to the files, and modify access to the directory
containing the files before executing this command.
The recreate_index can only process embedded-key indexes. Reserved system
indexes, record indexes, deleted-record indexes, separate key, embedded-separate
key, and item indexes cannot be processed. The number of components of the index
must be greater than zero. An embedded index with zero components is an invalid
index.
Examples
In the following examples, file_a has one index, file_b has two indexes, and
file_c has no indexes. In the first example, the recreate_index command
processes all the files in the directory interactively.
recreate_index *
%s1#m2>Sales>D_Jones>file_a
file organization: sequential file
last used: 93-03-04 09:32:49 EST
last modified: 93-03-03 09:05:33 EST
last saved: never
time created: 93-03-03 09:05:33 EST
transaction file: no
implicit locking: no
safety switch: no
next byte: 220
blocks used: 1
num indexes: 1
allocation size: 1
mode: w
author: D_Jones.Sales
(Continued on next page)
Command Overview
8-15
recreate_index
Do you want to continue with this file? (yes, no, info) info
last used: 93-03-04 09:32:49 EST
last saved: never
safety switch: no
next byte: 220
blocks used: 1
num indexes: 1
allocation size: 1
mode: w
Do you want to continue with this file? (yes, no, info) y
index name: a.1
key components: 1,3
type: embedded_key
collation: ascii
data type: nonvarying string
ascending: yes
duplicates: yes
null keys: no
automatic update: yes
blocks: 2
Do you want to continue with this index? (yes, no, info) y
%s1#m2>Sales>D_Jones>file_b
last used: 93-03-03 10:39:52 EST
last saved: never
safety switch: no
next byte: 220
blocks used: 1
num indexes: 2
allocation size: 1
mode: w
8-16
recreate_index
Do you want to continue with this file? (yes, no, info) y

index name: b.2
key components: 6,2
type: embedded_key
collation: ascii
ascending: yes
duplicates: yes
null keys: no
blocks: 2
index name: b.1
key components: 1,3
type: embedded_key
collation: ascii
ascending: yes
duplicates: yes
null keys: no
blocks: 2
%s1#m2>Sales>D_Jones>file_c
last used: 93-03-03 09:06:02 EST
last saved: never
safety switch: no
next byte: 220
blocks used: 1
num indexes: 0
allocation size: 1
mode: w
recreate_index: The file has no indexes.
%s1#m2>Sales>D_Jones>file_c
Bypassed file %s1#m2>Sales>D_Jones>file_c
Command Overview
8-17
recreate_index
Creating index(es)...
Deleting index "a.1"...
Deleting index "b.2"...
Deleting index "b.1"...
Creating index "a.1" on file
Create index complete for index "a.1" on file
Creating index "b.2" on file
Create index complete for index "b.2" on file
3 index(es) processed.
2 file(s) processed.
In the following example, recreate_index processes the indexes in file_b without
asking for confirmation and without displaying non-error information.
recreate_index file_b -brief -no_ask
Creating index(es)...
2 index(es) processed.
8-18
recreate_index
The following example shows the output format of the duplicate path log file.
file: %68k#m5>dir_1>dir_2>dir_3>huge_seq
index: index_1
duplicate key:
00000000 494E4445 585F315F 4B45595F 37
|INDEX_1_KEY_7
ignored in record number 4417 [1141x] at position 4417 [1141x]
(block 2 [2x] offset 320 [140x]):
00000000 494E4445 585F315F

00000010 20202049 4E444558
00000020 30202020 20202049
00000030 45595F37 30202020
existing key locates record
(block 1 [1x] offset 384
4B45595F 37202020 |INDEX_1_KEY_7

|
5F325F4B 45595F37 |
INDEX_2_KEY_7|
4E444558 5F335F4B |0
INDEX_3_K|
20202020
|EY_70
|
385 [181x] at position 385 [181x]
[180x]):
00000000
00000010
00000020
00000030
4B45595F 37202020
5F325F4B 45595F37
4E444558 5F335F4B
2020202
494E4445
20202049
20202020
45595F37
585F315F
4E444558
20202049
20202020
|INDEX_1_KEY_7
|
|
INDEX_2_KEY_7|
|
INDEX_3_K|
|EY_7
|
First, the file is identified, followed by the index. Then, each invalid duplicate key is
identified with the following information.
a dump of the duplicate key
the position of the record where the invalid duplicate key was found
a dump of the record that has the invalid duplicate key
the position of the record currently located by the key
a dump of the record currently located by the key
The information presented is sufficient for you to correct the situation. For example, you
could delete the records with duplicate keys, or you could rewrite the records with a
new and unique key.
Related Information
See Chapter 7, Recovering from a Crash, for information about re-creating indexes
See the create_index, delete_index, and display_file_status command
descriptions in theVOS Commands Reference Manual (R098); all provide information
useful for analyzing file problems.
See the patch_file, patch_index, recreate_index, test_index,
verify_end_of_file, and verify_index command descriptions in this chapter.
All provide tools to analyze and fix file problems.
Command Overview
8-19
shutdown
shutdown
8-
Purpose
The shutdown command shuts down one or more modules and indicates the reason
for the shutdown.
Display Form
-------------------------------------- shutdown ---------------------------------current_module
-module:
-ask:
yes
-reboot:
no
-manual:
no
-disruptive:
yes
-by_customer:
yes
-reason:
unspecified
-from_slot:
-ioa_slot:
-ioa_device:
-from_device:
-from_partition:
Command-Line Form
shutdown [ -module module_name ...]

[-no_ask]
[-reboot]
[-manual]
[-no_disruptive]
[-no_by_customer]
[-reason string]
[-from_slot slot_number]
[-ioa_slot ioa_slot]
[-ioa_device ioa_device]
[-from_device multilevel_device_ID]
8-20
[-from_partition partition_number]
shutdown
Arguments
* -module module_name
Specifies one or more modules to be shut down. The value for module_name can
be a single module or it can be a module star name (*). The value * shuts down
all modules in the current system. If you omit this argument, the operating system
shuts down the current module.
* -no_ask
<CYCLE>
Asks you before shutting down each of the designated modules. The default is yes,
which means you are asked before a module is shut down.
* -reboot
<CYCLE>
Starts up each designated module immediately after the shutdown. Use this
argument to change the version of the operating system by switching to a different
partition or to make the system recognize table files. The default is no, which
means the module does not immediately reboot after a shutdown.
* -manual
<CYCLE>
Manually starts up each designated module immediately after shutdown. Use this
argument to perform a manual boot without physically entering the boot_manual
command from the system console. If you give this argument, you cannot give the
-from_slot argument. The default is no, which means the module does not
perform a manual start up after a shut down.
* -no_disruptive
<CYCLE>
Indicates that the shutdown is not disruptive to the normal operation of business.
The default is yes, meaning the shutdown is disruptive.
* -no_by_customer
<CYCLE>
Indicates that the shutdown is not initiated by the customer. The default is yes,
meaning that the shutdown is initiated by the customer.
Command Overview
8-21
shutdown
* -reason
<CYCLE>
Specifies the reason for the shutdown. The possible values follow.
unspecified
The default value, used when no reason for the

shutdown is indicated.
other
None of the other reason codes applies, and you want

to indicate that fact explicitly.
application_problem
The shutdown and reboot are required because of a

user application problem.
system_problem
The module must be shut down and rebooted to

allocate system resources for normal module
operation.
environment
Shutdown is not caused by a Stratus problem, but by

an external event, such as an air conditioning
problem, storm, or fire.
maintenance
Shutdown is required for the purpose of module

maintenance.
testing
Shutdown is required for the purpose of module

testing.
installing_hardware
Shutdown is required to install hardware.
installing_software
Shutdown is required to install software.
reconfiguring
Shutdown and reboot are required to affect changes

in the hardware tables.
* -from_slot slot_number
Specifies the disk controller or IOP in a main chassis slot to be used for a module
reboot. Valid slot numbers are 0 through the highest numbered slot in the module.
If an IOP is specified, the -ioa_slot argument must also be given with the
command. If this argument is not given, the disk controller or IOP in the lowest
numbered main cabinet slot will be used. If you give this argument, you cannot give
the -manual argument.
This argument is valid on XA/R-series modules only. For Continuum-series
modules, use the -from_device argument.
* -ioa_slot ioa_slot
Specifies the slot number in the IOA chassis in which the IOA is mounted, for use
in a module reboot. If this argument is not given, the disk IOA in the lowest
numbered IOA chassis slot will be used.
8-22
shutdown

modules, use the -from_device argument instead.
* -ioa_device ioa_device
Specifies the device number of the boot device (tape, disk, or link) connected to the
IOA specified in the -ioa_slot argument. If this argument is not specified when
either the -reboot or -manual argument is given, the boot will be performed
using the default boot device attached to the IOA specified in the ioa_slot
argument. This argument allows you to specify a device other than the default.
modules, use the -from_device argument instead.
* -from_device multilevel_device_ID
Specifies the boot device on which to find the boot partition. The format of the
multilevel device ID is cc/ss/ee/dd, where cc is the controller slot number, ss is
the SCSS port number, ee is the peripheral enclosure number, and dd is the device
number. See VOS System Administration: Disk and Tape Administration (R284) for
more information. There is no default for this argument; if you specify
-from_device, you must also give a multilevel device ID. However, if -reboot
was specified or a reboot is going to automatically occur and -from_device is
not specified, then the system will boot off the same device it used the last time it
rebooted.
On Continuum-series modules, use -from_device instead of -from_slot,
-ioa_device, and -ioa_slot.
* -from_partition partition_number
Specifies the boot partition on the master disk from which to perform the startup.
This lets you use a partition other than the default boot partition.
Explanation
The shutdown command sends to TheOverseer process of each specified module
a request to shut down. For the purpose of tracking system availability, the command
also indicates a reason for the shutdown in an output statement verifying that the
module is shutting down. For example, if a customer or field engineer types in just the
command shutdown, the following output statement is displayed.
The reason for the shutdown is unspecified and is disruptive
to normal business.
The Overseer then issues a request for verification of the shutdown with the following
statement.
Do you really want to shutdown %s#m13? (yes, no)
Command Overview
8-23
shutdown
After the customer or field engineer types y to verify the shutdown, TheOverseer
process executes the command. Each module then broadcasts the following message
to its local terminals.
From Overseer: Module name shutdown at date.time
The arguments -disruptive, -by_customer, and -reason are called availability
tracking arguments and can be used to modify the text of the output statement.
The arguments -reboot, -manual, -from_device, -from_slot, -ioa_slot,
-ioa_device, and -from_partition are known as the reboot arguments. Entering
any one of these arguments indicates that a reboot is to be performed. Note, however,
that you cannot specify both the -manual and -from_slot (XA/R-series) or
-from_device (Continuum-series) arguments.
1. When executing the shutdown command with the
batch command, you must supply the
-no_restart argument of the batch command.
Otherwise, the batch process restarts and shuts down
the specified modules again when the module which
the batch process was running is started up.
2. Do not confuse issuing the shutdown command with
the emergency shutdown process, described in
Chapter 6, Shutting Down and Powering Off. The
shutdown command halts all processes on the
module in an orderly manner, and writes all cache
blocks to disk, preventing data loss. Issuing the
shutdown command is not considered a module
interruption.
Examples
In the following examples, only the command and arguments are shown. The
verification statements are not shown for each command example.
The following command shuts down all modules in the system without asking. The
command indicates no reason for the shutdown, so by default, the shutdown is
recorded as being disruptive to normal business operation.
shutdown
8-24
-module *
-no_ask
shutdown
The following command shuts down the current module due to an environmental
problem and automatically reboots it using boot partition 3. The shutdown is recorded
as being disruptive to normal business operations.
shutdown -reboot -disruptive -reason environment
-from_partition 3
The following command shuts down the current module and then does a manual
startup. The reason for the shutdown is that hardware is being installed, and the
shutdown is recorded as not being disruptive to normal business operations.
shutdown
-manual -no_disruptive -reason installing_hardware
The following command shuts down the current (XA/R-series) module and then does
a startup using the IOA in IOA chassis slot 1 which is connected to the IOP in main
cabinet slot 19. Since the -ioa_device argument is not specified, the default boot
device attached to the specified IOA is used. The module is recorded as being shut
down due to an application problem.
shutdown -reason application_problem -from_slot 19
-ioa_slot 1
The following command shuts down the current (XA/R-series) module and then reboots
it automatically using device 0 connected to the IOA in IOA chassis slot 2, attached to
the IOP in main cabinet slot 3, and using boot partition 5. No reason for the shutdown
is given.
shutdown -reboot -from_slot 3 -ioa_slot 2 -ioa_device 0
-from_partition 5
The following command shuts down the current (Continuum-series module) and then
reboots it using the device located at multilevel device ID 4/1/1/2. The command
does not specify a reason for the shutdown, but records the shutdown as being
nondisruptive to normal business operations.
shutdown
-no_disruptive -from_device 4/1/1/2
The following command shuts down the current (Continuum-series module) and then
reboots it automatically using the device located at multilevel device ID 4/1/1/2 and
using boot partition 5. No reason for the shutdown is given.
shutdown
-reboot
-from_device 4/1/1/2 -from_partition 5
Related Information
See Chapter 6, Shutting Down and Powering Off.
Command Overview
8-25
test_index
test_index
8-
Purpose
The test_index command invokes the test index subsystem, a diagnostic tool used
to display information about an index.
Display Form
-------------------------------------- test_index -------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
test_index
Explanation
The test_index command invokes the test index subsystem. Once you have
invoked the command, test_index prompts you with ti: to enter a request. To exit
the subsystem and return to command level, give the request quit.
The following test_index requests are available:
backward_index
check
convert_key
convert_key_range
create_buffer
delete_buffer
display_buffer
dump_buffer
dump_node
fill_buffer
forward_index
free
help
list_buffers
8-26
locate_record
look_at
names
position
quit
set_buffer_byte
set_buffer_length
set_buffer_longword
set_buffer_text
set_buffer_word
status
use
use_buffer
test_index
The requests are documented in five functional groups. The first group of requests
deals with the current test_index session.
help
names
quit
The second group of requests establishes a current index.
look_at
use
The third group of requests displays information about the specified index.
check
dump_node
free
status
The fourth group of requests allows the user to set up and alter a position within an
index.
backward_index
convert_key
convert_key_range
forward_index
locate_record
position
The fifth group of requests creates and modifies buffers for test_index requests.
create_buffer
delete_buffer
display_buffer
dump_buffer
fill_buffer
list_buffers
set_buffer_byte
set_buffer_length
set_buffer_longword
set_buffer_text
set_buffer_word
use_buffer
Related Information
See the patch_file, patch_index, recreate_index, verify_end_of_file,
Command Overview
8-27
test_index
Current Session Requests

The help Request
The help request displays requests available in the test_index subsystem.
Display Form
-------------------------------------- help --------------------------------------match:
Command-Line Form
help [-match string]
Arguments
* -match string
Displays all the requests of the test_index subsystem that contain string. If
you omit this argument, all test_index requests are displayed.
Example
The following example invokes the help request without the -match argument.
backward_index
check
convert_key
convert_key_range
create_buffer
delete_buffer
display_buffer
dump_buffer
dump_node
fill_buffer
forward_index
free
help
list_buffers
locate_record
look_at
names
position
quit
set_buffer_byte
set_buffer_length
set_buffer_longword
set_buffer_text
set_buffer_word
status
use
use_buffer
The following example invokes the help request with the -match argument.
ti: help -match convert
convert_key
convert_key_range
8-28
test_index
The names Request

The names request lists all the files and indexes that have been looked at during the
current session of test_index.
Display Form
--------------------------------------- names -----------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
names
Explanation
The names request displays the name of each file looked at followed by the indexes
that have been accessed for that file. Since there is always a current index (unless the
list is empty), the names request specifies the current index by placing an asterisk (*)
next to its name.
Example
The following example shows the list of files looked at during the current session of
test_index.
ti:
names
* file: %s1#m3>Sales>Vanessa_Smith>indexes>ggg
*
index: one
file: %s1#m3>Sales>Vanessa_Smith>indexes>fff
index: one
index: oo
Command Overview
8-29
test_index
The quit Request

The quit request returns the current process to command level.
Display Form
----------------------------------------- quit ----------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
quit
8-30
test_index
Requests That Establish a Current Index

You can examine one or more indexes in a test_index session. Since indexes
belong to files, you must specify the file whose index is to be examined. This file is the
current file. Only one index is opened at a time; this index is designated as the current
index.
Use the look_at request the first time you examine an index in a test_index
session. The look_at request creates and saves the data structures necessary for
that index. That index then becomes the current index.
When you are done with one index and want to look at another, invoke the look_at
request. The old index is closed and the new one is opened. Its data structures are
added to a list of all indexes opened during the current test_index session. The new
index becomes the current index.
To view to an index previously examined in the session, invoke the use request.
The look_at Request
The look_at request defines a file and index for use in the current invocation of
test_index.
Display Form
---------------------------------------- look_at --------------------------------file:
index:
Command-Line Form
look_at file_name index_name
Arguments
* file_name
Specifies the file whose index is to be examined.
* index_name
Specifies the index to be examined.
Required
Required
Explanation
The look_at request defines a file and index to be examined in the current
test_index session. It creates the data structures needed for examining an index,
and opens the index for the user. The index specified becomes the current index. The
Command Overview
8-31
test_index
data structures for the new index are added to a list of files/indexes that have been
defined during this test_index session.
If there is already a current index when the look_at request is specified, that index is
closed, but its data structures are not deallocated. Since test_index keeps a list of
all files and indexes specified during one session, the user can re-examine a previously
looked at index with the use request.
This request should not be used on indexes that are being modified. Modifications
made to the index cannot be seen during the current session, and some information
may be inconsistent.
This request does not produce any output unless the request is unsuccessful. Here is
the output from a successful look_at request.
ti:
ti:
look_at iii one
Here is the output from an unsuccessful look_at request.

ti: look_at fff one
look_at: The specified object is already defined. Error
in 'index_name'. Use "use" command.
8-32
test_index
The use Request

The use request closes the current file and index, finds the specified file and index,
opens the index, and makes it the current index.
Display Form
----------------------------------------- use -----------------------------------file:
index:
Command-Line Form
use file_name index_name
Arguments
* file_name
Specifies the file whose index is to be examined.
Required
* index_name
Specifies the index to be examined.
Required
Explanation
The use request recalls a file and index to be examined. These files and indexes must
have been previously defined by the look_at request. This request does not produce
any output unless the request is unsuccessful. Here is the output from a successful use
request.
ti:
ti:
use ggg one
Here is the output from an unsuccessful use request in which a nonexistent file was
referenced.
ti: use fff one
use: Object not found. Error in 'pathname'.
Command Overview
8-33
test_index
Here is the output from an unsuccessful use request in which a nonexistent index was
referenced.
ti: use ggg two
use: Object not found. Error in 'index_name'. Use "look_at"
command.
To list the files that have already been defined by the look_at request, execute the
names request.
8-34
test_index
Requests That Display Information

These requests display general information about the current index. The check
request checks that the structure of the current index is valid. The dump_node request
displays information stored in a particular index block or node of the current index in
the specified format. The free request displays a list of all free blocks in the current
index. The status request displays general information about the current index.
The check Request
The check request examines the structure of the index to see if it is valid.
Display Form
----------------------------------------- check ----------------------------------brief:
y es
-verify_record: no
-verbose:
no
-repair:
no
Command-Line Form
check
[-no_brief]
[-verify_record]
[-verbose]
[-repair]
Arguments
* -no_brief
<CYCLE>
Displays output in the long form. The default is yes, which suppresses most output
unless errors are found in the index.
When you invoke -no_brief, test_index displays a header for each node or
block. For branch nodes, this header consists of the node number. For leaf nodes,
this header consists of the leaf node numbers and of its siblings. A description of
any errors discovered pertaining to a block will immediately follow the nodes
header.
* -verify_record
<CYCLE>
If this argument is set to yes, the request checks the validity of each entry in the
index and its associated data record. If the -verbose argument is set to no (the
default value), the check request does not generate any output unless it finds
corrupted entries in the index. If a check request finds corrupted entries, the
Command Overview
8-35
test_index
request generates output for those entries, along with a description of the error in
each entry.
* -verbose
<CYCLE>
If this argument is set to yes and if you have also specified the -verify_record
argument, -verbose displays the key values for each record. The default value for
this argument is no.
* -repair
<CYCLE>
Specifies whether corrupted entries should be repaired. This argument has three
values: no, query, and all. If you specify the value no (the default value) for this
argument, no entries are repaired. If you specify the value query, then for each
corrupted index, you will be asked to verify whether the request should remove the
key from the index. If you specify the value all, the check request removes from
the index the keys for all corrupted records and generates a list of those removed
keys.
Explanation
The check request starts at the root of the index and walks the tree, checking for
consistency. The items checked by the check request include:
valid sibling pointers
valid index version
valid index depth
valid duplicate information
valid key entries
valid string storage
This request may report errors on an index being modified even though the index is
correct.
8-36
test_index
Examples
Example 1: -no_brief
The following example shows information displayed using check -no_brief.
ti:
check -no_brief
node:
3
leaf:
leaf:
leaf:
leaf:
leaf:
dup:
leaf:
leaf:
leaf:
leaf:
leaf:
leaf:
leaf:
Index is ok.
1
2
4
5
13
14
12
11
6
7
8
9
10
left:
left:
left:
left:
left:
left:
left:
left:
left:
left:
left:
left:
left:
-1
1
2
4
5
13
14
12
11
6
7
8
9
right:
right:
right:
right:
right:
right:
right:
right:
right:
right:
right:
right:
right:
2
4
5
13
14
12
11
6
7
8
9
10
-1
The following example shows the information displayed using check on the same
index as in the example above.
ti: check
Index is ok.
Example 2: An Index with Errors
The following example shows the information displayed using check on an index with
errors.
ti: check
leaf:
11
left:
10
right:
12
check: Invalid index block in indexed file. Key out of order.
Key #: 7
Key: 16055N7750987
Key #: 8
Key: 14658N9929733
Key #: 10
Key: 14737C4643766
Command Overview
8-37
test_index

Key #: 12
Key: 14737C4643766
.
.
.
Key #: 75
Key:
20D15857H06147360D14862C33054430D14560C44073780C1593600
00000
Example 3: -verify_record and -verbose
The following example shows the information displayed using check
-verify_record -verbose. This allows you to see the key value for each record
in the index.
Note that the number shown after record : is different based on the file type. For
sequential files it is the byte offset from the start of the file to the beginning of the record
that contains the key. For fixed and relative files, it is the number of the record that
contains the key.
This example was created as follows:
!copy_file abbreviations sample_file
!create_index sample_file index_7_6 6,6
!test_index
ti:
look_at sample_file index_7_6
ti: check -usage

Usage: check [-no_brief] [-verify_record] [-verbose] [-repair
+string]
ti: check -verbose
Index is ok.
ti:
check -verify_record -verbose

leaf:
1
left:
-1
key: //
record :
0
key: ?
record :
1042
key: CD
record :
1686
key: HD
record :
1722
key: MD
record :
1754
right:
-1

8-38
test_index
key: PD
key: STTP
key: TN
key: UN
key: UTTP
key: ad
key: ado
key: alp
key: am
key: ap
key: arc
key: as
key: dt
key: dtd
key: dtp
key: dtt
key: ebk
.
.
.
key: xt
key: xt66
key: quent
key: quent
record
record
record
record
record
record
record
record
record
record
record
record
record
record
record
record
record
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
1790
7936
5292
5330
8010
1826
2258
4752
5000
5724
6192
6568
7326
7638
7756
7852
730
record
record
record
record
:
:
:
:
7430
7550
2616
2648
Command Overview
8-39
test_index
The dump_node Request

The dump_node request displays the information found in an index node.
Display Form
--------------------------------------- dump_node -------------------------------node:
-physical: no
-hex:
no
Command-Line Form
dump_node node
[-physical]
[-hex]
Arguments
* node
Required
Specifies the number of the node to be dumped. This is the physical block number
of the index node.
* -physical
<CYCLE>
Prints information after the index block header. The output is a list of keys and the
record numbers to which they point. The default value is no, meaning the logical
format is displayed.
When -physical is invoked, the information is displayed in physical format. Each

key entry in the key space is displayed with its actual values, and each string in the
string space is displayed as it is found.
* -hex
<CYCLE>
Prints the information about the node in hexadecimal. The default is no, meaning
the node information is displayed in ASCII.
Explanation
The dump_node request displays the information found in an index node. This request
may report errors on an index being modified even though the index is correct.
8-40
test_index
Example
The following example shows the information stored in an index node, displayed in
logical format.
ti:
dump_node 5
Block Number:
Version:
Level Number:
Dup Block:
Dup on Left:
Dup on Right:
Root Block:
Long Value:
Squish String Area:
Storage Reserved:
MBZ:
Left:
Right:
Far Right:
Number of keys:
Bottom Key Area:
Top String Area:
Im Commit Id:
5
5
1
FALSE
FALSE
FALSE
FALSE
TRUE
TRUE
TRUE
FALSE
4
13
-1
9
54
3946
0000000000000000
Keys:
aaaaaaabbj
aaaaaaabbk
aaaaaaabbl
aaaaaaabbm
aaaaaaabbn
aaaaaaabbq
aaaaaaabbr
aaaaaaabbs
aaaaaaabbt
711
712
713
714
715
718
719
720
721
Command Overview
8-41
test_index
The following example shows the information stored in an index node displayed in
physical format. This is the same index node displayed previously in logical format.
ti:
dump_node 5 -physical
Block Number:
Version:
Level Number:
Dup Block:
Dup on Left:
Dup on Right:
Root Block:
Long Value:
Squish String Area:
Storage Reserved:
MBZ:
Left:
Right:
Far Right:
Number of keys:
Bottom Key Area:
Top String Area:
Im Commit Id:
5
5
1
FALSE
FALSE
FALSE
FALSE
TRUE
TRUE
TRUE
FALSE
4
13
-1
9
54
3946
0000000000000000
Key entries:
key
storage
block
key
entry
offset
offset
value
-------------------------------------1:
0FD8x
0FECx
711
2:
0FCDx
0FE1x
712
3:
0FC2x
0FD6x
713
4:
0FB7x
0FCBx
714
5:
0FACx
0FC0x
715
6:
0F8Bx
0F9Fx
718
7:
0F80x
0F94x
719
8:
0F75x
0F89x
720
9:
0F6Ax
0F7Ex
72
8-42
test_index
String space:
storage
block
key
key
offset
offset
length
string
--------------------------------------------------0F6Ax
0F7Ex
10
aaaaaaabbt
0F75x
0F89x
10
aaaaaaabbs
0F80x
0F94x
10
aaaaaaabbr
0F8Bx
0F9Fx
10
aaaaaaabbq
0F96x
0FAAx
22
deleted space
0FACx
0FC0x
10
aaaaaaabbn
0FB7x
0FCBx
10
aaaaaaabbm
0FC2x
0FD6x
10
aaaaaaabbl
0FCDx
0FE1x
10
aaaaaaabbk
0FD8x
0FECx
10
aaaaaaabbj
0FE3x
0FF7x
8
0000000000000000
Command Overview
8-43
test_index
The following example shows the information stored in an index node displayed in
hexadecimal logical format. This example is not related to the previous examples.
ti:
dump_node 1
-hex
Block Number:
Version:
Level Number:
Dup Block:
Dup on Left:
Dup on Right:
Root Block:
Long Value:
Squish String Area:
Storage Reserved:
MBZ:
Left:
Right:
Far Right:
Number of keys:
Bottom Key Area:
Top String Area:
Im Commit Id:
1
5
1
FALSE
FALSE
FALSE
TRUE
TRUE
FALSE
TRUE
FALSE
-1
-1
-1
334
2004
2342
0000000000000000
Keys:
3139313932
3139343634
33303132
33303331
33333031
47882
48238
48594
48950
49484
.
.
.
8-44
test_index
The following example uses the same node displayed in the previous example, but
displayed in hexadecimal physical format.
ti:
dump_node 1 -physical -hex
Block Number:
Version:
Level Number:
Dup Block:
Dup on Left:
Dup on Right:
Root Block:
Long Value:
Squish String Area:
Storage Reserved:
MBZ:
Left:
Right:
Far Right:
Number of keys:
Bottom Key Area:
Top String Area:
Im Commit Id:
1
5
1
FALSE
FALSE
FALSE
TRUE
TRUE
FALSE
TRUE
FALSE
-1
-1
-1
334
2004
2342
0000000000000000
Key entries:
key
storage
block
key
entry
offset
offset
value
-------------------------------------1:
0A9Ax
0AAEx
47882
2:
0A8Dx
0AA1x
48238
3:
0A82x
0A96x
48594
4:
0A77x
0A8Bx
48950
5:
0A66x
0A7Ax
49484
.
.
.
Command Overview
8-45
test_index
String space:
storage
block
key
key
offset
offset
length
string
--------------------------------------------------0926x
093Ax
4
54522D33
092Bx
093Fx
4
54522D32
0930x
0944x
4
54522D31
0935x
0949x
9
534C32332D30313832
093Fx
0953x
9
534C32332D30313536
.
.
.
8-46
test_index
The free Request

The free request reads the index map blocks for the index, and displays a list of all
the free blocks in the index.
Display Form
----------------------------------------- free ----------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
free
Explanation
The free request displays the number of each free index map block and the blocks
designated as free in that free index map block. The free index map block is always
block 0 of an index. If more than 32,753 blocks are in an index, then another map block
is initialized in block 32,753.
Example
The following example shows which blocks in the current index are free.
ti:
free
High Block Used: 112

Free Block: 0
2
5
9
32
47
73
88
92
99
101
110-112
Command Overview
8-47
test_index
The status Request

The status request displays information about the current index.
Display Form
----------------------------------- status -------------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
status
Explanation
The status request displays the name of the current file and index, the root block
number, the number of the last block in the index, the current index depth, and the
status of various flags in the indexs internal data structures
(root_block_modified, empty_index, entered_in_order, and
empty_index_valid).
Example
The following example shows information about the current index.
ti:
status
Status:
File:
%s1#m3>Sales>Vanessa_Smith>indexes>fff
Index:
one
Root Block No:
3
Root Block Modified: FALSE
High Block Used::
10
Cur Index Depth:
2
Empty Index:
FALSE
Entered in Order:
FALSE
Empty Index Valid:
FALSE
8-48
test_index
Requests That Set Up, Display, and Alter Position

Each index has an associated position status. Position status consists of:
current key
key value
index into internal buffer array (bmex)
block pointer
time stamp
block number of the block in which the current key is located
key number and key offset within the block of the current key
current low and high key values
A range of values is used when locating a specific record. The low and high key values
specify the upper and lower bounds of this range. They are updated with the
convert_key and convert_key_range requests.
The other values of the position status are updated by the backward_index,
forward_index, and locate_record requests. The position request displays
the position.
The backward_index Request
The backward_index request moves the current position in the index backward by
the number of keys specified.
Display Form
------------------------------------ backward_index -----------------------------num: 1
Command-Line Form
backward_index [num]
Arguments
* num
Specifies the number of keys by which to move the current position backward. The
default is 1.
Explanation
The backward_index request moves the current position in the index backward by
the specified number of keys and displays the resulting position. Before issuing the
Command Overview
8-49
test_index
backward_index request, issue the position request to locate the current position
in the index.
Example
The following example shows the position in the index after the user has requested a
position backward of 9, from a position in the middle of the index.
ti: backward_index 9
Key:
"aaaaaaaadm"
Key Value: 90
Bmex:
1
Blockp:
00E9875C
Time Stamp: 0
Block No:
1
Key No:
91
Key Offset: 1
Low Key:
"000000000000000000000000000000000000000
00000
+000000000000000000000000000000000000000
0000000000000
+0000000000000000000000000000000000"
High Key:
"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFF
+FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFF
+FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"
The next example shows the position in the index after a position backward of 9 was
requested, from a position at the beginning of the index. In this case, the request simply
leaves the position at the beginning of the file.
ti: backward_index 9
backward_index: Beginning of file.
8-50
test_index
The convert_key Request

The convert_key request converts the string representation of the key given by the
user into the representation used in the index.
Display Form
------------------------------------- convert_key -------------------------------key:
Command-Line Form
convert_key key
Arguments
* key
Required
The key to be converted. If you use buffers, convert_key can use the buffer text
for the key; see the next section, Buffer Management Requests, for more
information.
Explanation
The convert_key request displays the converted key. The key you specify is
converted into a form consistent with the index. This value is stored in the current key,
low key, and high key values for the index. These low key and high key values are used
in any subsequent locate_record request.
If you specify a key that is longer than the key defined in the current index, the
convert_key request displays the following message:
convert_key: The specified key is too long. Error in 'key'.
Example
The following example converts a key.
ti: convert_key 90
Key: "90"
Command Overview
8-51
test_index
In the following example, the key 444 is inserted in the current buffer, and is used by
the convert_key request.
ti:
ti:
444
ti:
Key:
8-52
set_buffer_text 0 444
display_buffer
convert_key
"444"
test_index
The convert_key_range Request

The convert_key_range request converts the string representation of a key into a
range of keys in the representation used in the index.
Display Form
----------------------------------- convert_key_range ---------------------------key:
relation: eq
Command-Line Form
convert_key_range key
[relation]
Arguments
* key
Required
The key to be used in setting up a key range. If you use buffers,
convert_key_range can use buffer text for the key; see the next section, Buffer
Management Requests, for more information.
* relation
<CYCLE>
The relation to be used in setting up a key range. The possible values are:
Value
Equivalent
eq
KEY_EQ
gteq
KEY_GTEQ
gt
KEY_GT
peg
KEY_PREFIX_EQ
pgteq
KEY_PREFIX_GTEQ
pgt
KEY_PREFIX_GT
The default is eq.
Explanation
The convert_key_range request displays the low key and high key values specified
by key and relation. These low key and high key values will be used in any
subsequent locate_record request.
Command Overview
8-53
test_index
If you specify a key that is longer than the key defined in the current index, the
convert_key_range request displays the following message:
convert_key_range: The specified key is too long. Error in
'key'.
Example
The output of this series of requests shows the results of convert_key_range for an
alphabetic key.
ti: convert_key_range a eq
Low Key: "a"
High Key: "a"
ti: convert_key_range a gteq
Low Key: "a"
High Key:
FFFFF
FFFFFFFFFFFFF
ti: convert_key_range a gt
Low Key: "a
!"
High Key:
FFFFF
FFFFFFFFFFFFF
ti: convert_key_range a peq
Low Key:
"a00000000000000000000000000000000000000
000000
+000000000000000000000000000000000000000
0000000000000
+0000000000000000000000000000000000"
High Key:
"aFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFF
FFFFFFFFFFFFF
ti: convert_key_range a pgteq
8-54
test_index
Low Key:
"a00000000000000000000000000000000000000
000000
+000000000000000000000000000000000000000
0000000000000
+0000000000000000000000000000000000"
High Key:
FFFFF
FFFFFFFFFFFFF
ti: convert_key_range a pgt
Low Key:
"b00000000000000000000000000000000000000
000000
+000000000000000000000000000000000000000
0000000000000
+0000000000000000000000000000000000"
High Key:
FFFFF
FFFFFFFFFFFFF
In the following example, the key xx is inserted in the current buffer and is used by the
convert_key_range request.
ti: set_buffer_text 0 xx
ti: display_buffer
xx
ti: convert_key_range
Low Key: "xx"
High Key: "xx"
ti: display_buffer
xx
For more information on the buffer requests, see the next section, Buffer Management
Requests.
Command Overview
8-55
test_index
The forward_index Request

The forward_index request moves the current position in the current index forward
by the number of keys specified.
Display Form
------------------------------------ forward_index ------------------------------num: 1
Command-Line Form
forward_index [num]
Arguments
* num
Specifies the number of keys by which to move the current position forward. The
default is 1.
Explanation
The forward_index displays the resulting position after the operation has been
performed. Before issuing the forward_index request, issue the position request
to locate the current position in the index. The information displayed is listed previously
in the section Requests That Set Up, Display, and Alter Position.
Example
The following example shows the position in the index after the user has moved
forward seven keys.
ti: forward_index 7
Key:
"Murphy"
Key Value: 488
Bmex:
1
Blockp:
00E2D2A6
Time Stamp: 0
Block No:
1
Key No:
7
Key Offset: 1
Low Key:
"00000000000000000000000000000000000000+
000000
8-56
test_index
+00000000000000000000000000000000000000+
00+000000000000
+0000000000000000000000000000000000"
High Key:
"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF+
FF+FFFF
+FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF+
FF+FFFFFFFFFFFF
The following example shows the position in the index after the user has requested a
position forward of 30, and forward_index encounters the end of the index.
ti: forward_index 30
forward_index: Positioned at end of file.
Command Overview
8-57
test_index
The locate_record Request

Given the key value, the locate_record request sets the current position to the
appropriate value.
Display Form
------------------------------------- locate_record -----------------------------key_value: - 1
Command-Line Form
locate_record [key_value]
Arguments
* key_value
The value of the key to be located. When the default value is used,
locate_record finds the first record within the range specified by the
convert_key_range request. The default value is -1.
Explanation
The locate_record request displays the position status of the current index after the
operation has taken place. The information displayed is listed previously in the section
Requests That Set Up, Display, and Alter Position.
Example
The following example uses the convert_key_range and locate_record
requests to display information about a record.
ti: convert_key_range Tucker
Low Key: "Tucker"
High Key: "Tucker"
ti:
locate_record
Key:
"Tucker"
Key Value: 444
Bmex:
1
Blockp:
00E2D2A6
Time Stamp: 0
Block No:
1
Key No:
9
Key Offset: 1
Low Key:
"Tucker"
High Key:
"Tucker"
8-58
test_index
The position Request

The position request displays information about the current position in the current
index.
Display Form
-------------------------------------- position ---------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
position
Explanation
The position request displays information about the position status in the file.
Position status consists of:
current key
key value
index into internal buffer array (bmex)
block pointer
time stamp
block number of the block in which the current key is located
key number and key offset within the block of the current key
current low and high key values
Example
The following example shows the position of an index immediately after that index is
initially opened (by the look_at request).
ti: position
Key:
"Clough"
Key Value: 90
Bmex:
1
Blockp:
00E2D2A6
Time Stamp: 0
Block No:
1
Key No:
3
Key Offset: 1
Command Overview
8-59
test_index
Low Key:
"00000000000000000000000000000000000000+
000000
+00000000000000000000000000000000000000+
00000000000000
+0000000000000000000000000000000000"
High Key:
"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF+
FFFFFF
+FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF+
FFFFFFFFFFFFFF
8-60
test_index
Buffer Management Requests

The buffer management commands provide a way to manipulate values consisting of
non-alphabetic characters. Hexadecimal values, for example, can be inserted into a
buffer then used by the current index.
The create_buffer Request
The create_buffer request creates a named buffer.
An unnamed buffer always exists. This request creates
named buffers.
Display Form
---------------------------------- create_buffer --------------------------------buffer_name:
buffer_size: 66
-display:
yes
-dump:
no
-ebcdic:
no
Command-Line Form
create_buffer buffer_name
[buffer_size]
[-no_display]
[-dump]
[-ebcdic]
Arguments
* buffer_name
Names the buffer to be created.
Required
* buffer_size
Specifies the size of the buffer. The default is 66 bytes, the maximum length in
decimal of a key.
* -no_display
<CYCLE>
Suppresses the display of the buffers contents. The default displays the
characters.
* -dump
Dumps the contents of the buffer. The default is no.
<CYCLE>
Command Overview
8-61
test_index
* -ebcdic
<CYCLE>
Displays the contents of the buffer as EBCDIC characters. The default is no, so the
characters are displayed as ASCII characters.
Example
This example creates a buffer and represents buffer characters as EBCDIC characters.
ti:
8-62
create_buffer foo -ebcdic
test_index
The delete_buffer Request

The delete_buffer request deletes a named buffer.
An unnamed buffer always exists. The unnamed buffer
cannot be deleted.
Display Form
---------------------------------- delete_buffer --------------------------------buffer_name: c urrent_buffer
Command-Line Form
delete_buffer [buffer_name]
Arguments
* buffer_name
Specifies the buffer to be deleted. The default is the current buffer.
Required
Example
The following example deletes a specified buffer.
ti:
delete_buffer parts
Command Overview
8-63
test_index
The display_buffer Request

The display_buffer request displays the current buffer.
Display Form
---------------------------------- display_buffer --------------------------------dump:
no
-ebcdic:
no
Command-Line Form
display_buffer [-dump]
[-ebcdic]
Arguments
* -dump
Dumps the contents of the buffer. The default is no.
<CYCLE>
* -ebcdic
<CYCLE>
characters are displayed as ASCII characters.
Examples
The following example fills the current buffer with the letter S and displays the buffer.
ti: fill_buffer 4 10 53
ti: display_buffer
Buffer length = 20
00000000 00000000 53535353 53535353 53535353 |....SSSSSSSSSSSS|
00000010 53535353
|SSSS
|
The following example displays the same buffer with EBCDIC characters.
ti: display_buffer -ebcdic
Buffer length = 20
00000000 00000000 ABABABAB ABABABAB ABABABAB |................|
00000010 ABABABAB
|....
|
8-64
test_index
The dump_buffer Request

The dump_buffer request dumps the contents of the current buffer.
Display Form
------------------------------------ dump_buffer ---------------------------------ebcdic:
no
Command-Line Form
dump_buffer [-ebcdic]
Arguments
* -ebcdic
<CYCLE>
contents are displayed as ASCII characters.
Example
The following example fills the current buffer, then dumps it to the screen.
ti: fill_buffer 6 6 5B
ti: dump_buffer
Buffer length = 12
00000000 00000000 00005B5B 5B5B5B5B
|......[[[[[[
The following example dumps the same buffer as EBCDIC characters.

ti: dump_buffer -ebcdic
Buffer length = 12
00000000 00000000 00002A2A 2A2A2A2A
|......******
Command Overview
8-65
test_index
The fill_buffer Request

The fill_buffer request fills all or part of a buffer with the specified fill character.
Display Form
------------------------------------ fill_buffer -------------------------------displacement:
length:
fill:
20
Command-Line Form
fill_buffer displacement length fill
Arguments
* displacement
Required
The byte, in hexadecimal, at which to begin filling the buffer. Byte numbering starts
at 0. A displacement of 0 means that filling starts at the beginning of the buffer.
* length
The number of bytes, in hexadecimal, to fill.
Required
* fill
Required
A hexadecimal character with which to fill the buffer. The default is 20 hexadecimal,
the space character.
Example
The following example fills a buffer with the letter j.
ti: fill_buffer 2 8 6A
ti: display_buffer
Buffer length = 10
00000000 00006A6A 6A6A6A6A 6A6A
8-66
|..jjjjjjjj
test_index
The list_buffers Request

The list_buffers request lists all buffers.
Display Form
------------------------------------ list_buffers -------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
list_buffers
Example
The following example lists the buffers in the current test_index session.
ti:
*
list_buffers
66
0
66
0
foo
The asterisk (*) marks the current buffer. The unnamed buffer is the buffer
test_index uses by default.
Command Overview
8-67
test_index
The set_buffer_byte Request

The set_buffer_byte request sets a specified byte of the current buffer.
Display Form
---------------------------------- set_buffer_byte -----------------------------displacement:
data:
Command-Line Form
set_buffer_byte displacement data
Arguments
* displacement
Required
* data
A hexadecimal string.
Required
Example
ti: set_buffer_byte 0 2
disp
fm to
000000 00 02
8-68
test_index
The set_buffer_length Request

The set_buffer_length request sets the current buffer to a given length.
Display Form
--------------------------------- set_buffer_length------------------------------length:
Command-Line Form
set_buffer_length length
Arguments
* length
Required
Specifies the length of the buffer in hexadecimal. The maximum length is 66.
Example
In the following example, the length of the buffer is set at 40.
ti:
set_buffer_length 40
Command Overview
8-69
test_index
The set_buffer_longword Request

The set_buffer_longword request sets a specified longword of the current buffer.
Display Form
------------------------------- set_buffer_longword------------------------------displacement:
data:
Command-Line Form
set_buffer_longword displacement data
Arguments
* displacement
Required
The byte, in hexadecimal, at which to begin filling the buffer. Longword numbering
starts at 0. A displacement of 0 means that filling starts at the beginning of the
buffer.
* data
Required
Example
ti: set_buffer_longword 3 3
disp
from
to
000003 00202020 00000003
8-70
test_index
The set_buffer_text Request

The set_buffer_text request inserts text in a buffer.
Display Form
---------------------------------- set_buffer_text -----------------------------displacement:
text:
Command-Line Form
set_buffer_text displacement text
Arguments
* displacement
Required
* text
An ASCII string.
Required
Example
The following example inserts the string authors in the current buffer.
ti: set_buffer_text 10 authors
ti: dump_buffer
Buffer length = 21
00000000 00000000 00000007 00000000 00000000 |................|
00000010 6E616D65 73
|authors
|
This request inserts text at the beginning of the buffer, without clearing the buffer of
existing text. If after inserting the string authors, you then insert 000, dump_buffer
displays the following string.
ti: set_buffer_text 10 000
ti: dump_buffer
Buffer length = 21
00000000 00000000 00000007 00000000 00000000 |................|
00000010 30303065 73
|000hors
|
Command Overview
8-71
test_index
The set_buffer_word Request

The set_buffer_word request sets a specified word of the current buffer.
Display Form
---------------------------------- set_buffer_word -----------------------------displacement:
data:
Command-Line Form
set_buffer_word displacement data
Arguments
* displacement
Required
The byte, in hexadecimal, at which to begin filling the buffer. Word numbering starts
* data
Required
Example
ti: set_buffer_word 2 00
disp
from to
000002 3600 0000
8-72
test_index
The use_buffer Request

The use_buffer request specifies the buffer that test_index uses for subsequent
requests.
Display Form
----------------------------------- use_buffer ----------------------------------buffer_name: c urrent_buffer
Command-Line Form
use_buffer buffer_name
Arguments
* buffer_name
Specifies the buffer to use. The default is the current buffer.
Required
Example
The following example selects the previously created buffer code as the current buffer.
ti:
use_buffer code
Command Overview
8-73
verify_end_of_file
verify_end_of_file
8-
Purpose
The verify_end_of_file command verifies the placement of the end-of-file pointer
and updates the directory entry for the file.
Display Form
---------------------------------- verify_end_of_file ---------------------------pathnames:
-brief:
no
-update_directory: no
-ask:
yes
Command-Line Form
verify_end_of_file pathnames
[-brief]
[-update_directory]
[-no_ask]
Arguments
* pathnames
Specifies one or more file or star names to be verified.
* -brief
Suppresses the display of non-error information.
Required
<CYCLE>
* -update_directory
<CYCLE>
Using this argument modifies directory information
without the usual file system internal checks. Do not
8-74
(Privileged)
verify_end_of_file
indiscriminately use this argument. Always invoke this

command first without the -update_directory
argument and ensure that the end-of-file position is
reasonable before invoking the -update_directory
argument. See the Examples section for sample
command output.
Updates the directory with a new value for the last_record_number field
computed by the command. You must have write access to the file, and you can
only issue this argument from a privileged process.
* -no_ask
<CYCLE>
Updates the directory entry without prompting you for confirmation.
Explanation
The verify_end_of_file command verifies the placement of the end-of-file
pointer, and updates the directory entry for the file. The verify_end_of_file
command can be invoked interactively or from a batch process or command macro.
When trying to determine where the end-of-file pointer is located, this command makes
some assumptions and may not work properly if the file does not fit these assumptions.
One important assumption is that the end-of-file pointer initially points to a valid record.
If it does not, then verify_end_of_file will probably fail in its attempt to examine
records beyond this invalid record location. In such a case, the command will report
that the original end-of-file location is the most likely value, and that no records could
be recovered.
The operating system disk and file I/O routines implement the concept of the unwritten
block. When space is allocated for a disk block, the directory entry for that block is
marked. If any attempt is made to read the block before it has first been written, the
software returns a block containing all FFx bytes.
The unwritten block affects the different file types in different ways.
In a sequential file, the control word -1 (FFFFx) signals the end-of-file.
In a relative file, the control word -1 signals a deleted record.
In a fixed file, the bytes of FFx are treated as data (by definition, there is no such
thing as a deleted record for fixed files). However, the verify_end_of_file

command has the following convention: if the first two bytes of the record are
FFFFx, then the record has been deleted. Thus, unwritten block(s) in a fixed or
relative file are considered to contain deleted records, even though fixed files
normally do not contain deleted records.
See VOS Reference Manual (R002) for more information on the format of records in
various file types.
Command Overview
8-75
verify_end_of_file
The verify_end_of_file command might include some previously deleted records

if it cannot be certain that they should remain deleted. These records will be located
between the original end-of-file point and the one calculated by the
verify_end_of_file command. The command includes these records because it
is better to include records that an application can later redelete than it is to exclude
records that could be useful.
Sequential Files
In a sequential file, the end-of-file pointer for the file contains the byte offset to the first
byte beyond the last record, and is called next_byte.
If the file contains n blocks and the pointer is to the first byte of block n+1, then the file
is assumed to exactly fill the blocks, and the end of file is considered valid.
Otherwise, the pointer must be to a 2-byte value (on an even byte boundary) that
contains -1 (FFFFx) for the end-of-file pointer to be considered valid.
If the current end-of-file pointer is not truly at the end of the data this command
assumes that at one time it was a valid end-of-file pointer, and that the new end-of-file
pointer is located beyond it.
The command repeatedly moves the pointer toward the end of the file, advancing the
pointer by looking at the record length control words at the front of each record. For a
record to be considered valid, the control words at the front and back of the record must
be identical. Otherwise, the verify_end_of_file command stops looking and
reports the point at which it found the discrepancy as the probable end-of-file.
If, at any time, a valid end-of-file pointer is encountered, that position will be reported
as the correct end-of-file.
Relative Files
In a relative file, the end-of-file pointer is called the last_record_number. It contains
the (1-origin) count of the number of records in the file. The following formula is used
to calculate the byte offset within the file of the first record located beyond the
end-of-file.
last_record_number * (max_record_size + 2 +
mod(max_record_size,2))
is assumed to exactly fill the blocks, and the end of file is considered valid. Otherwise,
the pointer is positioned towards the end of the file, moving (max_record_size + 2
+ mod(max_record_size, 2)) bytes each time. If only deleted records (those with
a control word of -1) are encountered, then the end-of-file pointer in the directory is
considered valid. If any intervening non-deleted data records are encountered, then the
8-76
verify_end_of_file
command continues from the directory-recorded position to the end of the data blocks
until it finds a record that either contains an invalid length (less than -1 or greater than
max_record_size) or until the current record extends beyond the end of allocated
blocks.
This process may result in the verify_end_of_file command including some
extraneous records in the file. The extraneous records occur in the following cases.
The file at one time contained many records, but the s$truncate_open_file
subroutine was used to set the end-of-file pointer to a record in the middle of a
block. The verify_end_of_file command will consider all records that fit in the
block as valid records.
The block(s) between the directory end-of-file and the end of the allocated space
for the file, contain at least one valid record that is then followed by records filled
with FFx bytes. The verify_end_of_file command considers the bytes of FFx
as deleted records and positions the end-of-file pointer beyond them.
Fixed Files
In a fixed file, the end-of-file pointer is called the last_record_number. It contains
the (1-origin) count of the number of records in the file. The following formula is used
to calculate the byte offset within the file.
last_record_number * (max_record_size +
mod(max_record_size,2))
is assumed to exactly fill the blocks and the end of file is considered valid.
Otherwise, the pointer is positioned towards the end of the file, moving
(max_record_size + mod(max_record_size,2)) bytes each time. If only
deleted records (whose first two bytes are -1) are encountered, then the end-of-file in
the directory is considered valid. If any intervening nondeleted data records are
encountered, then the command continues from the directory-recorded position to the
end of the data blocks until the current record extends beyond the end of allocated
blocks.
Command Overview
8-77
verify_end_of_file
This process may result in the verify_end_of_file command including some

extraneous records in the file. The extraneous records occur in the following cases.
The file at one time contained many records, but the s$truncate_open_file
subroutine was used to set the end-of-file to a record in the middle of a block. The
verify_end_of_file command considers all records that fit in the block as
valid records.
The block(s) between the directory end-of-file and the end of the allocated space
for the file, contain at least one valid record that is then followed by records filled
with FFx bytes. The verify_end_of_file command considers the bytes of FFx
as deleted records and positions the end-of-file pointer beyond them.
Types of Files That Cannot Be Verified

The verify_end_of_file command will not operate on files with the following types
and/or attributes:
stream files
transaction files
pipe files
queues
The verify_end_of_file command also cannot operate on file indexes. When the
end-of-file pointer is repositioned by the -update_directory argument, and the file
has indexes, a warning is issued that the indexes need to be re-created. See the
recreate_index command for information on re-creating indexes after crashes.
After executing the verify_end_of_file command, always execute
display_line (command_status) to display the current value of
command_status. When the command terminates, the (command_status)
command function can be tested for the following values. Other nonzero values are
possible if errors occur.
Status
Code
Meaning
None
Normal termination.
1279
e$abort_output
The <CANCEL> key was pressed while output was

being displayed.
1665
e$file_format_error
One or more files failed verification.
3019
m$abort_output
One or more files failed verification, and the

-update_directory argument was used to
change the directory information.
8-78
Status Code Name
verify_end_of_file
For more information on command functions, see VOS Commands Users

Guide (R089).
To check all the files in your application directories, write a walk_dir command macro
to execute the verify_end_of_file command throughout the hierarchy. A typical
walk_dir command macro follows:
walk_dir %prod#m3>jit>pubs -depth 3
+
-down_command 'verify_end_of_file *.data'
+
-down_start_process
walk_dir %prod#m3>jit.4>cards -depth 3
+
-down_command 'verify_end_of_file *.data'
+
-down_start_process
Examples
This section contains four examples of typical verify_end_of_file sessions. The
first example shows a sequential file whose end-of-file pointer is earlier than the actual
end-of-file.
verify_end_of_file file_1
%s1#m1>sales>file_1
file type: sequential file
last used: 93-04-08 10:17:08 est
last modified: 93-04-08 10:13:55 est
last saved: never
time created: 93-04-08 10:13:54 est
safety switch: no
next byte: 73054 (00011D5Ex)
blocks used: 19 (00000013x)
num indexes: 0
allocation size: 1
mode: w
author: Gary_Jones.Sales
Command Overview
8-79
verify_end_of_file
***** End of file is NOT correct *************

Expected at file position 73054 (0000000000011D5Ex), block 17
(00000011x) at
offset 3422 (0D5Ex).
A consistent new end of file was found at file position 73086
(0000000000011D7Ex), block 17 (00000011x) at offset 3454
(0D7Ex).
2 intervening record(s) could be recovered if
-update_directory is used.
1 file(s) failed verification.
8-80
verify_end_of_file
The following example shows a verify_end_of_file session on a file whose last

record number is earlier than the actual last record number in the file.
%s1#m1>Sales>file_2
file type: relative file
last used: 93-04-08 09:50:15 est
last saved: never
safety switch: no
record size: 1
last record: 569916400 (21F83BF0x)
blocks used: 32807 (00008027x)
num indexes: 0
allocation size: 1
mode: w
author: James_Joseph.Sales
Expected at file position 2279665600 (0000000087E0EFC0x),
block 556558
(00087E0Ex) at offset 4032 (0FC0x).
A consistent new end of file was found at file position
2279665664
(0000000087E0F000x), block 556559 (00087E0Fx) at offset 0
(0000x).
Command Overview
8-81
verify_end_of_file
The following session reruns verify_end_of_file, specifying the

-update_directory argument to recover these records.
verify_end_of_file file_2 -update_directory
%s1#m1>Sales>file_2
last used: 93-04-08 09:59:43 est
last saved: never
safety switch: no
record size: 1
last record: 569916400 (21F83BF0x)
blocks used: 32807 (00008027x)
num indexes: 0
allocation size: 1
mode: w
author: James_Joseph.Sales
Expected at file position 2279665600 (0000000087E0EFC0x),
block 556558
(00087E0Ex) at offset 4032 (0FC0x).
A consistent new end of file was found at file position
2279665664
(0000x).
Changing end of file to record 569916416 located at position
2279665664
(0000x).
Do you want to continue? (yes, no) yes
Last record number field in directory set to: 569916416
(21F83C00x).
16 record(s) recovered.
File/directory data has changed.
1 file(s) modified.
8-82
verify_end_of_file
The following example shows verify_end_of_file with a large file (that is, the last
byte is at an offset greater than 2**31 - 1).
verify_end_of_file big_file
%s1#m1>Sales>big_file
last used: 93-04-08 09:04:19 est
last saved: never
safety switch: no
record size: 1
last record: 569916416 (21F83C00x)
blocks used: 32807 (00008027x)
num indexes: 0
allocation size: 1
mode: w
author: Gary_Jones.Sales
End of file appears to be correct.
WARNING: Only the end-of-file has been verified, not the
consistency/integrity of the data.
All files verified.
Command Overview
8-83
verify_end_of_file
In the final example, verify_end_of_file is able to detect data corruption because

the end-of-file pointer was earlier than the position of the record where the corruption
occurs. In this case, the file has been deliberately corrupted for this example. A file like
this cannot be processed. Contact the CAC to recover a file damaged in this way.
%s1#m1>Sales>file_3
file type: sequential file
last used: 93-04-08 10:31:15 est
last saved: never
safety switch: no
next byte: 65918 (0001017Ex)
blocks used: 19 (00000013x)
num indexes: 0
allocation size: 1
mode: w
author: Jay_Long.Sales
Expected at file position 65918 (000000000001017Ex), block 16
(00000010x) at offset 382 (017Ex).
The record at position 66132 (00010254x) block 16 (00000010x),
offset 596 (0254x) has inconsistent record size.
File damage and data loss is likely. Please contact the
Customer Assistance Center for help with this file.
The correct end of file cannot be positively determined.
The last known consistent location is at file position 66132
(0000000000010254x), block 16 (00000010x) at offset 596
(0254x).
The CAC uses the information provided by

verify_end_of_file to determine the problems
8-84
verify_end_of_file
location. The CAC dumps the file starting at block 17

(recalling that verify_end_of_file block numbers are
0-based while dump_file block numbers are 1-based).
The CAC would look at the offset where the inconsistent
record length is identified and examine the record to
locate its trailing record length. The CAC could possibly
repair the damage and re-run verify_end_of_file.
Related Information
See the patch_file, patch_index, recreate_index, test_index, and
verify_index command descriptions in this chapter. All provide tools to analyze and
fix file problems.
Command Overview
8-85
verify_index
verify_index
8-
Purpose
The verify_index command validates the structure and (in some cases) the
contents of one or more indexes of indexed files.
Display Form
----------------------------------- verify_index --------------------------------pathnames:
-index_names: *
-error_limit: 20
-all:
no
-brief:
no
-ask:
yes
-dirty_input: no
-dump:
yes
Command-Line Form
verify_index pathnames ...
[-index_names index_names ...]
[-error_limit number]
[-all]
[-brief]
[-no_ask]
[-dirty_input]
[-no_dump]
Arguments
* pathnames
Required
The path names of one or more file names, any of which can be star names, to be
processed. There is no default value; you must specify at least one value. The files
you specify must reside on the current module.
8-86
verify_index
* -index_names index_names
Specifies one or more index names, any of which may be star names, associated
with the files named by pathnames. The default is *, which means that
verify_index will process all indexes associated with the specified file(s).
* -error_limit number
Specifies the number of errors to be reported before the command aborts the
processing of an index. The value can be between 1 and 32,767. The default value
is 20.
* -all
<CYCLE>
Specifies whether all types of indexes are to be processed. If you specify the value
no (the default), only embedded-key indexes are verified. If you specify the value
yes, embedded-key indexes are verified and embedded separate-key,
separate-key, and item indexes are scanned to confirm index-structure integrity
only.
* -brief
<CYCLE>
Specifies the level of detail displayed for each file and index. If you set this
argument to yes, the command provides only a minimal amount of information.
(Note that error and statistical information are always displayed.) The default value
is no.
* -ask
<CYCLE>
Asks you if the command should process a file and/or an index. For batch
processes, the default value is no. For interactive processes, the default value is
yes, except that you are not asked to confirm processing of a single file, and you
are not asked about the processing of indexes if no star names are provided for the
index name(s).
* -dirty_input
<CYCLE>
Specifies that the verify_index command use the DIRTY_INPUT type. The
default value is no. This argument is required if the file is locked (other than
implicitly locked) by another process or if the file is a transaction file. See the VOS
Reference Manual (R002) for more information about file locking.
If you specify this argument, false errors might be reported
when the index changes as it is being processed by
verify_index. You should confirm these errors by
reprocessing the file with the -no_dirty_input
argument.
* -dump
<CYCLE>
Dumps the record area whenever verify_index detects an error. The default
value is yes. When a file is being scanned (as opposed to verifying an embedded
index), the record that is dumped might be the last record successfully accessed
rather than the one that caused the error, depending on the type of error.
Command Overview
8-87
verify_index
Explanation
The verify_index command is a tool provided in the >system>maint_library
directory for the use of system administrators, as well as Stratus Customer Service and
Customer Assistance Center personnel. This command attempts to validate the
structure (and, in some cases, the contents) of one or more indexes of indexed files.
To thoroughly check an index, you should also use the verify_index command with
the test_index command.
See the VOS Reference Manual (R002) for more information about file indexes.
Using verify_index on Different Index Types

The following sections describe how verify_index processes each type of index.
Embedded-Key Indexes
An embedded-key index contains keys that consist of data that is wholly contained
within each data record. The components of the key can be verified from the data in the
record.
The verify_index command opens the file for indexed access via the index and
sequentially reads the records in the file in the order in which they appear in the index.
The key in the index is compared with the data in the record. This technique is called
verifying the index. In addition, verify_index checks the indexs sequence for
out-of-sequence keys.
Separate-Key Indexes
A separate-key index contains keys that are not necessarily part of the data record. An
application defines a key independently of the records contents. A separate-key index
must be maintained by the application, as the file system does not know the
relationship between the key and the record.
The verify_index command opens the file for indexed access and reads the
records in the file in the order in which they appear in the index. The key in the index is
not compared to the data in the record, since verify_index has no knowledge of the
algorithm used to form the keys. This technique is called scanning the index. In
addition, verify_index checks the indexs sequence for out-of-sequence keys.
Embedded Separate-Key Indexes
An embedded separate-key index combines the features of an embedded-key index
and a separate-key index. As with an embedded-key index, there is a place in the data
record where the key value is found initially, and when a record is added, updated, or
deleted in the file, the system maintains the embedded keys. As with a separate-key
index, you can add or delete the separate keys, and more than one separate key can
point to the same record.
8-88
verify_index
The verify_index command opens the file for indexed access and reads the
records in the file in the order in which they appear in the index. The key in the index is
not compared with the data in the record, since verify_index has no knowledge of
the algorithm used to form some of the keys and cannot determine which types of keys
are involved. The verify_index command can only scan, not verify, the index;
however, the command does validate the indexs sequence.
Item Indexes
An item index contains no data records; the index entry that normally contains a key
and a record number instead consists of a key and a 32-bit value.
The verify_index command opens the file for indexed access and repeatedly calls
the s$get_item subroutine for each item until all items have been scanned. The
verify_index command can only scan, not verify, the index; however, the command
does validate the indexs sequence.
System Indexes
The file system can maintain two other types of indexes: a deleted-record index and a
record index. Both are used to reclaim the space when records are deleted. The
verify_index command cannot process either type of system index, and it will
bypass them if it encounters them.
Record Counts
When a file contains multiple indexes, verify_index can report different values for
the number of records processed via each index. This is explained by the fact that
indexes can suppress null keys (that is, keys containing only spaces).
Index Structure Damage

If the file system detects a problem with the structure of the index, it reports the error
e$invalid_index (1712) to the verify_index command, which does not attempt
to validate or scan that index further.
Command Status
The verify_index command sets the command_status system variable to the
error e$invalid_index (1712) if it fails to validate or scan an index. This is a
pseudoerror status set by the command, not by the file system. Thus, this message
might not indicate an invalid index block; you should consult earlier error messages to
determine the exact cause of failure. The command does not set command_status if
a file is not found, or if the command bypasses files or indexes because of ineligibility.
This property of the command can be used within a command macro to log a message
to the system error log, and/or to inhibit the starting of application processes if any
index appears to be corrupted. For example:
&
<< command-macro fragment >>

Command Overview
8-89
verify_index
&
!verify_index customer_db -brief -no_ask
&set cs (command_status)
&if &cs& ^= 0
&then !log_syserr_message(string Verify Failed (message &cs&))
&
Performance
The verify_index command might take significant time to execute, as it must read
every disk block of every index before reading the record associated with every key.
The execution time of verify_index is comparable to the time necessary to
re-create all of a files indexes.
To avoid burdening Open StrataLINK, StrataNET, and/or StrataLINK, this command
accesses only files on the current module. If you specify a file that resides on a different
module, verify_index returns the error e$wrong_module (1069) and bypasses
the file.
Error Messages
After executing the verify_index command, always execute display_line
(command_status) to display the current value of command_status. The
command_status value for the process is affected by this command. When the
command terminates, the (command_status) command function can be tested for
the values shown in the following table. Other nonzero values are possible if errors
occur.
(Page 1 of 2)
8-90
Error
Code
Error Code Name
Meaning
1052
e$invalid_file_type
The command can process only

sequential, relative, and fixed values.
1160
e$fixedoverflow
The command did not convert a numeric

key.
1069
e$wrong_module
The file must reside on the current module

to avoid heavy I/O across the network.
1093
e$no_star_match
No indexes matched the specified star

name.
1164
e$overflow
An error occurred while converting a

numeric key.
verify_index
(Page 2 of 2)
Error
Code
Error Code Name
Meaning
1446
e$key_not_same
The embedded key in the record does not

match the key in the index.
1574
e$no_indexes
The command bypassed the file because it

has no indexes.
1712
e$invalid_index
The index keys are out of sequence, or a

duplicate key appears in an index that
does not allow duplicate keys.
2508
e$invalid_numeric_key
The command could not convert the

specified key to an integer.
2607
e$reserved_index
The verify_index command cannot

process a deleted-record index or a record
index, so the command bypassed it.
2802
e$fault_limit_exceeded
The error limit has been reached.
2911
e$invalid_char_var_key
The keys size is negative or larger than

the maximum key size.
2927
e$invalid_transfile_op
You cannot issue the verify_index

command on a transaction-protected file
unless you specify the -dirty_input
argument.
3080
e$no_alloc_user_heap
The program could not allocate buffer

space. This is a fatal error.
3398
e$invalid_pipe_operation
You cannot issue the verify_index

command for a pipe.
3480
e$invalid_index_type
The command encountered a

separate-key, embedded separate-key, or
item index when you specified the no
value for the -all argument.
Examples
This section contains examples illustrating how to use the verify_index command.
Example 1: Processing a Single File
The following example illustrates how to process a single file.
verify_index test_file.fix -no_ask
%se#d01>Work>Brown>files>test_file.fix
Command Overview
8-91
verify_index
file organization:
last used:
last modified:
last saved:
time created:
transaction file:
log protected:
implicit locking:
safety switch:
record size:
last record:
blocks used:
num indexes:
allocation size:
mode:
author:
fixed file
95-10-20 10:37:10 EDT
95-10-20 09:52:29 EDT
never
95-10-20 09:52:19 EDT
no
no
no
no
79
60
2
2
1
w
Brown.Stratus
Processing
%se#d01>Work>Brown>files>test_file.fix, index line_no.
key components:
6,4
type:
embedded_key
collation:
numeric
data type:
nonvarying string
ascending:
yes
duplicates:
no
null keys:
no
extent index:
no
automatic update:
yes
blocks:
2
root block:
1
high block used:
1
Verified 60 records via embedded key index line_no for file
%se#d01>Work>Brown>files>test_file.fix
8-92
verify_index
Processing
%se#d01>Work>Brown>files>test_file.fix, index data_1.
key components:
11,10
type:
embedded_key
collation:
numeric
data type:
nonvarying string
ascending:
yes
duplicates:
yes
null keys:
no
extent index:
no
automatic update:
yes
blocks:
2
root block:
1
high block used:
1
Verified 60 records via embedded key index data_1 for file
%se#d01>Work>Brown>files>test_file.fix.
Index(es) processed:
Index(es) verified:
Index(es) scanned:
2
2
0
----- File Totals ----1 file(s) examined.

0 file(s) bypassed.
0 file(s) verified.
------ Index Totals ---2 index(es) processed.
2 index(es) verified.
0 index(es) scanned.
Example 2: Processing Multiple Files Interactively
The following example illustrates how to interactively process multiple files.
verify_index >system>m*.table -ask
%se#m49>system>manual_info.table
file organization:
sequential file
last used:
95-08-03 12:01:07
last modified:
95-08-03 12:01:07
last saved:
95-10-03 11:09:00
time created:
95-08-03 12:01:05
transaction file:
no
log protected:
no
implicit locking:
no
EDT
EDT
EDT
EDT

Command Overview
8-93
verify_index
safety switch:
next byte:
blocks used:
num indexes:
allocation size:
mode:
author:
Do you want to continue?
no
57672
15
1
1
r
John_Lee.SysAdmin
(yes, no, info) y
Processing %se#m49>system>manual_info.table, index part_num.

key components:
1,32
type:
embedded_key
collation:
ascii_var
data type:
varying string
ascending:
yes
duplicates:
no
null keys:
no
extent index:
no
automatic update:
yes
blocks:
2
root block:
1
high block used:
1
Do you want to continue? (yes, no, info) y
Verified 324 records via embedded key index part_num for file
%se#m49>system>manual_info.table.
1
Index(es) verified:
1
Index(es) scanned:
0
%se#m49>system>modules.table
file organization:
last used:
last modified:
last saved:
time created:
transaction file:
log protected:
implicit locking:
safety switch:
record size:
last record:
blocks used:
num indexes:
allocation size:
fixed file
80-01-01 00:00:00
94-12-28 15:44:14
95-10-03 11:09:11
94-12-28 15:44:13
no
no
no
no
38
21
1
0
1
EDT
EDT
EDT
EDT

8-94
verify_index
mode:
r
author:
Janet_Smith.SysAdmin
verify_index: The file has no indexes.+
%se#m49>system>modules.table
Bypassed file %se#m49>system>modules.table
1 file(s) bypassed.
0 file(s) verified.
Example 3: Separate-Key Index
The following example illustrates what happens when you do not specify the -all
argument and the command encounters a separate-key index.
verify_index >system>error_codes.text -brief
verify_index: Invalid index type. A separate_key index will not
be scanned without -all. number index of
%se#m49>system>error_codes.text
be scanned without -all. name index of
be scanned without -all. name_to_number index of
be scanned without -all. number_to_name index of
Warning: Only 0 out of 4 index(es) verified or scanned for file
%se#m49>system>error_codes.text.
0 file(s) bypassed.
0 file(s) verified.
Command Overview
8-95
verify_index
The following example illustrates how the command processes the file when you
specify the -all argument.
verify_index >system>error_codes.text -brief -all
Processing %se#m49>system>error_codes.text, index number.
Scanned 6726 records via index number for file
Processing %se#m49>system>error_codes.text, index name.
Do you want to continue? (yes, no, info) info
Index name:
name
type:
separate_key
collation:
ascii
data type:
varying string
ascending:
yes
duplicates:
no
null keys:
no
extent index:
no
blocks:
74
root block:
3
high block used:
72
Scanned 6726 records via index name for file
Processing %se#m49>system>error_codes.text, index+
name_to_number.
Do you want to continue? (yes, no, info) n
Processing %se#m49>system>error_codes.text, index+
number_to_name.
Do you want to continue? (yes, no, info) n
Warning: Only 2 out of 4 index(es) verified or scanned for file
0 file(s) bypassed.
0 file(s) verified.
8-96
verify_index
Example 4: A Bad Index

The following example shows output that was obtained by patching the index of a file
so that a key string that previously read S028 was changed to S0ZZ, making it appear
that the index pointed to the wrong record. Actually, the index used the same string as
the key for three records, counting each incorrect record as an error, and therefore
exceeding the error limit of two.
verify_index bad_file -no_ask -error_limit 2
%se#m5_user>SysAdmin>Bobbi_Jones>bad_file
file organization:
sequential file
last used:
90-07-08 20:20:29 mst
last modified:
90-07-07 22:48:19 mst
last saved:
never
time created:
90-07-07 22:48:16 mst
transaction file:
no
implicit locking:
no
safety switch:
no
next byte:
50464
blocks used:
13
num indexes:
1
allocation size:
1
mode:
w
author:
Bobbi_Jones.CAC
Processing
%se#m5_user>SysAdmin>Bobbi_Jones>bad_file,
index product.
key components:
1,16
type:
embedded_key
collation:
ascii_var
data type:
varying string
ascending:
yes
duplicates:
yes
null keys:
no
automatic update:
yes
blocks:
2
root block:
1
high block used:
1
verify_index: The specified separate key is not the same as
the embedded key.
%se#m5_user>SysAdmin>Bobbi_Jones>bad_file [product]
Command Overview
8-97
verify_index
Current position: 25536 (000063C0x)

Current key (hex):
53305A5A 20202020 20202020 20202020
(alpha):
S0ZZ
Index key
(hex):
53305A5A
(alpha):
S0ZZ
Embedded key(hex):
53303238
(alpha):
S028
File record:
00000000 00045330 32380000 00000000 00000000 |..S028..........|
00000010 00000009 70617363 616C3E70 6D000000 |....pascal>pm...|
00000020 00000000 00000000 00000000 00000000 |................|
=
00000110 00000000 00042A2E 2A6D0000 00000000 |......*.*m......|
00000120 00000000 00000000 00000000 00000000 |................|
=
00000150 00000000 00000000 00000017 3E737973 |............>sys|
00000160 74656D3E 636F6D6D 616E645F 6C696272 |tem>command_libr|
00000170 61727900 00000000 00000000 00000000 |ary.............|
00000180 00000000 00000000 00000000 00000000 |................|
=
00000250 00000000 00000000 00000000
|............
|
the embedded key.
Current position: 26144 (00006620x)
Current key
(hex): 53305A5A 20202020 20202020 20202020
(alpha):
S0ZZ
Index key
(hex):
53305A5A
(alpha):
S0ZZ
Embedded key(hex):
53303238
(alpha):
S028
File record:
00000000 00045330 32380000 00000000 00000000 |..S028..........|
00000010 00000012 70617363 616C3E72 756E7469 |....pascal>runti|
00000020 6D653E6F 626A0000 00000000 00000000 |me>obj..........|
00000030 00000000 00000000 00000000 00000000 |................|
=
00000110 00000000 00052A2E 6F626A00 00000000 |......*.obj.....|
00000120 00000000 00000000 00000000 00000000 |................|
=
8-98
verify_index
00000150 00000000 00000000 00000016 3E737973 |............>sys|

00000160 74656D3E 6F626A65 63745F6C 69627261 |tem>object_libra|
00000170 72790000 00000000 00000000 00000000 |ry..............|
00000180 00000000 00000000 00000000 00000000 |................|
=
00000250 00000000 00000000 00000000
|............
|
verify_index: Fault limit exceeded.
FAILURE: UNABLE TO VALIDATE INDEX product for file
%se#m5_user>SysAdmin>Bobbi_Jones>bad_file.
Warning: Only 0 out of 1 index(es) verified or scanned for+
file
1
Index(es) verified:
0
Index(es) scanned:
0
0 file(s) bypassed.
0 file(s) verified.
1 index(es) FAILED validation
In the previous example, the use of the -error_limit argument hid another error
report. Specifically, after the command reports the third embedded-key difference, the
next key read appears to be out of sequence and is reported as such in the following
examples.
verify_index bad_file -brief -no_dump -no_ask
the embedded key.
.
.
.
Index key
(hex):
53305A5A
(alpha):
S0ZZ
Embedded key(hex):
53303238
(alpha):
S028
Command Overview
8-99
verify_index
verify_index: Invalid index block in indexed file.

The key sequence is not correct.
Current position: 27360 (00006AE0x)
Current key (hex):
53303330 20202020 20202020 20202020
(alpha):
S030
Index key
(hex):
53303330
(alpha):
S030
Embedded key (hex):
53303330
(alpha):
S030
Previous key (hex):
53305A5A
(alpha):
S0ZZ
FAILURE: UNABLE TO VALIDATE INDEX product for file
.
.
.
Example 5: Transaction File
The following example illustrates how the verify_index command must include the
-dirty_input argument if a file is transaction-protected. Otherwise, the command
returns an error.
verify_index company_db -brief -no_ask -no_dump
verify_index: Invalid operation on a transaction file.
%se#m3_bug>test_db_dir>company_db
1 file(s) bypassed.
0 file(s) verified.
8-100
verify_index
In the following example, the command can access the file if you specify the
-dirty_input argument.
verify_index company_db -brief -no_ask -no_dump -dirty_input
WARNING: dirty_input I/O might cause false error reports
the embedded key.
%se#m3_bug>test_db_dir>company_db [primary]
Current position: 637 (0000027Dx)
Current key (hex):
45534920 20202020 20202020 20202020
(alpha):
ESI
Index key
(hex):
455349
(alpha):
ESI
Embedded key(hex):
50524158 4953
(alpha):
PRAXIS
FAILURE: UNABLE TO VALIDATE INDEX primary for file
%se#m3_bug>test_db_dir>company_db.
the embedded key.
%se#m3_bug>test_db_dir>company_db [time_updated]
Current position: 637 (0000027Dx)
Current key
(hex):
10B1E03
(alpha):
`10`B1`E0:
Index key
(hex):
10B1E03A
(alpha):
`10`B1`E0:
Embedded key (hex):
10B44181
(alpha):
`10`B4A`81
FAILURE: UNABLE TO VALIDATE INDEX time_updated for file
Warning: Only 0 out of 2 index(es) verified or scanned for+
file
0 file(s) bypassed.
0 file(s) verified.
2 index(es) FAILED validation
Command Overview
8-101
verify_index
Related Information
See Chapter 7, Recovering from a Crash, for information about re-creating indexes
See the create_index, delete_index, and display_file_status command
descriptions in theVOS Commands Reference Manual (R098); all provide information
useful for analyzing file problems.
See the patch_file, patch_index, recreate_index, test_index, and
verify_end_of_file command descriptions in this chapter. All provide tools to
analyze and fix file problems.
8-102
Appendix A
Control Panels
A-
This appendix describes the lights, buttons, and switches on the older Stratus 10-slot
XA/R Model 20 module control panel.
To activate a button on a module control panel, you must
hold the button down for at least 10 seconds. It may take
up to 10 seconds before a response occurs.

The control panel on an 10-slot XA/R Model 20 module is located on the top front of the
module. This panel includes a status display, which displays messages about the
module.
Figure A-1 shows the control panel on the 10-slot XA/R Model 20 module.
MANUAL OVERRIDE
IMMEDIATE
MANUAL
HALT & POWER
START UP
RESTART
OFF
OPERATING
SHUT
AUTO
DOWN START UP
STATUS DISPLAY
BATTERY
TEST/
PROBLEM
LEVEL 7
OFF
ON
POWER
AD0020
Figure A-1. Control Panel for the 10-Slot XA/R Model 20 Module
Control Panels
A-1
* HALT & RESTART Button

This white button terminates all processes and initiates the Primitive Control
Program (PCP) that is used to load the operating system.
Never press this button unless told to do so by the CAC.
Pressing this button will interrupt the operation of the
module and force an emergency shutdown.
If you press this button and the status display on the module indicates that the
module is in PCP mode, type go and press <RETURN> from the monitor terminal. In
this case, the module should return to command level. If the module does not
return to command level, it remains in PCP mode, and an emergency shutdown
process, described in Chapter 6, Shutting Down and Powering Off, is invoked.
* IMMEDIATE POWER OFF Button

This red button turns off power to the module.
This button is not used to initiate a normal shutdown. Use

the SHUT DOWN button to initiate a normal shutdown.
* MANUAL START UP Button
This green button is used for manual startup. To boot the module from a boot
partition other than the default boot partition of the master disk, to boot from tape,
or to perform a link boot, hold down this button and the AUTO START UP button
until the green OPERATING light comes on.
* SHUT DOWN Button
The red button initiates a normal shutdown, terminating all processes, shutting
down, and powering off the module. A normal shutdown is possible only if the
process TheOverseer is running. Hold this button down until the status display
shows the message:
Shutdown request
* AUTO START UP Button

This green button turns on power to the module and initiates a boot from the default
boot partition.
* OPERATING Light
This green light alternates with the red TEST/PROBLEM light during module
startup until the process TheOverseer is started from module_start_up.cm.
The version number of the operating system will be displayed on the monitor
terminal when the operating system is successfully loaded.
* BATTERY Light
This yellow light comes on when power to the module is lost, indicating that the
module is not operating but is maintaining a restartable state on its emergency
battery.
A-2
* TEST/PROBLEM Light
This red light comes on when a fault is detected during the modules operation.
During module startup, this light alternates with the green OPERATING light. When
the process TheOverseer is successfully started from module_start_up.cm,
the red light goes off. However, if power-on diagnostic tests detect trouble, the
TEST/PROBLEM light stays on.
* STATUS DISPLAY Panel
This LCD panel displays various messages from the operating system. The
messages that may be shown on the status display panel and their meanings are
as follows:
Booting release_number
during a boot.
Salvaging logical_volume_name

Recovering disk_name

module_start_up
Indicates the file module_start_up.cm is being processed. The message

remains displayed until the process TheOverseer is running.
manual boot ready
Indicates that the system has booted as far as the manual boot command
level.
Shutdown request
Indicates that the SHUT DOWN button on the module has been pressed and
the module is being shut down.
PCP - dumping

PCP - command
Indicates that the PCP is capable of accepting command input.

HH:MM module_name

slot_id message
Control Panels
A-3
Indicates that there are board or device errors. For slot_id, one of the
following is displayed:
one of these component names: Bus, BusA, BusB, Battery, Fan,
EvBulk, or OddBulk
failure: The board has a failure code.
dev err: Some device attached to the controller has an error, is broken,
or is missing.
Master Startup Procedure

To start up more than one module at the same time from a 10-slot module, hold the
MASTER/NORMAL/LOCAL button in the MASTER position and press the START UP
button on the module. This starts up all modules on the system except those with their
MASTER/NORMAL/LOCAL switches set to LOCAL. Any modules already started up
are unaffected.

On the 10-slot XA/R Model 20, the LEVEL-7 interrupt button is the HALT & RESTART
button on the control panel.
The LEVEL-7 interrupt button sends an interrupt to the module, causing all CPUs to
stop. If the -auto_boot flag in the disk label is set, pressing this button causes the
module to dump the state of the machine and reboot immediately. If the -auto_boot
flag is not set, pressing the LEVEL-7 button puts the module in PCP mode.
Do not press this button unless the CAC instructs you to.
Pressing this button will interrupt the operation of the
module and force an emergency shutdown.
If you press this button and the status display on the module indicates that the module
is in PCP mode, type go and press <RETURN> from the monitor terminal. In this case, the
module should return to command level. Otherwise, if the module remains in PCP
mode, the emergency shutdown process, described in Chapter 6, Shutting Down and
Powering Off, is invoked.
A-4

If the monitor terminal indicates that the module is taking no action, perform Step 1, and
continue with the other steps if necessary.
1. Push the HALT & RESTART button. This should begin either automatic startup or
execution of PCP.
2. If this is not successful, notify the CAC of the situation. Then perform Step 3.
3. Power down the module. Do this by pressing either the POWER OFF or POWER
OFF THIS POWER MODULE button on the control panel.
4. Press the POWER ON or AUTO START UP button on the control panel. If powering
up in automatic mode is unsuccessful, repeat Step 3.
5. Follow the steps for startup documented in the The Steps in a Manual Startup from
Disk or Tape section of Chapter 3.
Control Panels
A-5
A-6
Index
Misc.
. (dot) Continuum system console
command, 1-5
10-slot XA/R Model 20 module. See XA/R Model
20 10-slot module
A
analyze_system command, 5-6
list_boards request, 5-4
Analyzing system problems, 5-5
attempt_auto_recovery variable
changing the setting of, 5-9
determining the setting of, 5-8
-auto_boot switch, 5-7
AUTO START UP button, A-2
Automatic dumps, 5-7
Automatic reboot, 7-1, 8-21
Automatic recovery (continuous), 5-9
Automatic startup, 3-2, 5-7
completion of, A-4
troubleshooting, 3-2
B
backward_index request, test_index
subsystem, 8-49
BATTERY lights
10-slot XA/R Model 20 module, A-3
Blocks
in the disk cache, 7-7
unwritten, 8-75
written to disk, 7-7
Boards
checking after a crash, 7-2
failure, 5-5
inserting, 5-5
removing from service, 5-5
testing, 5-5
Boot partition, 3-2
Boot source for a link boot, 3-10
Boot tape, 3-3

boot_auto Continuum system console
command, 1-3
boot_manual Continuum system console
command, 1-3
Booting modules
for link boot, 3-9
from disk, 3-3
from StrataLINK, 3-9
from tape, 3-3
Booting release_number status
message, 1-6, 2-5, A-3
broadcast command, 8-2
Buffers
creating, 8-61
deleting, 8-63
displaying, 8-64
dumping, 8-65
filling, 8-66
listing, 8-67
selecting, 8-73
setting
bytes for, 8-68
length of, 8-69
longwords for, 8-70
text strings for, 8-71
words for, 8-72
Buttons
10-slot XA/R Model 20 module
AUTO START UP, A-2
HALT/RESTART, A-2
IMMEDIATE POWER OFF, A-2
MANUAL START UP, A-2
SHUT DOWN, A-2
LEVEL-7 interrupt
on Continuum-series, 1-4
on XA/R Model 20, A-4
on XA/R-series, 2-4
Index-1
Index-
Index
XA/R-series
CYCLE, 2-7
ENTER, 2-7
Bytes in buffers, 8-68
C
CAC, 5-5
saving files for, 5-6
Cache, 7-7
Changing the attempt_auto_recovery
setting, 5-9
check request, test_index
subsystem, 8-31, 8-35
Checking
disk salvage and recovery, 7-3
file recovery, 7-8
indexes for validity, 8-35
module hardware, 7-2
service processes, 7-5
Command macros
module_shut_down.cm, 6-1
module_start_up.cm, 4-1
Commands
analyze_system, 5-6
broadcast, 8-2
copy_kernel, 5-6
create_os_symtab, 3-12
dump, 5-7
dump_disk, 3-3
dump_file, 7-11
link_boot_server, 3-10
patch_file, 7-11, 8-4
patch_index, 7-11, 8-7
recover_disk, 7-4
recreate_index, 7-10, 8-10
reset_configuration, 5-5
salvage_disk, 7-3
shutdown, 6-1, 8-20
spooler_admin, 4-3
start_disk_recovery, 7-4
start_logging, 3-8
system console, 1-1
system process, 4-1
test_index, 7-9, 8-26
verify_end_of_file, 7-9, 8-74
verify_index, 7-9, 8-86
x25, 4-3
Index-2
Completion of startup
automatic, 5-7
manual, 5-7
Configuration tables
modifying, 3-8
Console controller, 1-1
Continuum module status lights, 1-9
Continuum system console, 1-1
. (dot) command, 1-5
boot_auto command, 1-3
boot_manual command, 1-3
commands, 1-1
help command, 1-3
history command, 1-5
hpmc_reset command, 1-5
hung system automatic recovery, 5-10
hung system manual recovery, 5-9
messages, 1-6
power_off command, 1-3
quit command, 1-5
reset_bus command, 1-4
restart_cpu command, 1-4
shutdown command, 1-3
status command, 1-5
Control panels
for 10-slot XA/R Model 20 modules, A-1
for Continuum-series modules, 1-1
for XA/R-series modules, 2-1
convert_key request, test_index
subsystem, 8-51
convert_key_range request, test_index
subsystem, 8-53
Converting
keys to strings in indexes, 8-51
string representations of keys, 8-53
copy_kernel command, 5-6
Crash, 7-1
checking boards after, 7-2
checking files after, 7-9
checking service processes after, 7-5
checking syserr_log.date file
after, 7-2
file recovery after, 7-6
hardware recovery after, 7-2
reboot, 7-1
create_buffer request, test_index
subsystem, 8-61
create_os_symtab command, 3-12
CYCLE button, 2-7
Index
Default boot partition, 3-2

delete_buffer request, test_index
subsystem, 8-63
Determining the attempt_auto_recovery
setting, 5-8
Diagnostic utility process, 5-5
Directory entries
updating, 8-75
Directory recovery, 7-3
Disk cache, 7-7
Disk I/O, 7-7
Disk salvager
errors from, 7-3
log errors generated by, 7-4
Disks
boot, 3-5
booting from, 3-3
dump partition of, 5-6
duplex, 3-5
master, 3-3
recovering, 7-4
salvaging, 7-3
display_buffer request, test_index
subsystem, 8-64
Displaying
buffers, 8-64
information about the current position in an
index, 8-59
Disruptive shutdown, 8-21
dump command, 5-7
Dump image, 5-6
Dump partition, 5-6
dump_buffer request, test_index
subsystem, 8-65
dump_disk command, 3-3
dump_file command, 7-11
dump_node request, test_index
subsystem, 8-40
Dumps
automatic, 5-7
buffer, 8-65
invoked, 5-7
Duplex disks, 3-5
e$cant_open_os_symtab error
message, 3-12
e$corrupted_os_symtab error
message, 3-12
e$wrong_os_symtab error message, 3-12
eeprom_admin command, 5-8
Emergency shutdown, 6-3
End-of-file, 7-9
End-of-file pointer, 7-7, 7-9, 8-75
ENTER button, 2-7
Errors
messages
caused by uncreated symbol
tables, 3-12
spurious, 3-11
notification
signalling the hub, 5-5
writing to the hardware_log.date
file, 5-4
Evaluating the (command_status) command
function
after recreate_index, 8-14
after verify_end_of_file, 8-78
after verify_index, 8-90
Executing module_start_up.cm, 3-9
Expiration time
setting, 5-6
F
File recovery, 7-8
Files
advantages of transaction protection
for, 7-7
end-of-file pointer, 7-7, 7-9
fixed
verifying the end-of-file, 8-77
indexes of
patching, 7-11, 8-7
re-creating, 7-10, 8-10
testing, 7-10, 8-26
verifying, 7-10, 8-86
patching binary versions, 7-11, 8-4
recovery of, 7-6
relative
Index-3
Index
sequential
transaction-protected
checking after crash, 7-8
verifying end-of-file pointer, 8-74
verifying the end of, 7-9
fill_buffer request, test_index
subsystem, 8-66
Filling buffers, 8-66
Fixed files
forward_index request, test_index
subsystem, 8-56
free request, test_index subsystem, 8-47
H
HALT/RESTART button, A-2
Hardware checks after a crash, 7-2
Hardware requirements
for link boots, 3-9
hardware_log.date file, 5-4
help Continuum system console
command, 1-3
Help for index testing, 8-28
help request, test_index subsystem, 8-28
HH:MM module_name status message, 1-7,
2-6, A-4
history Continuum system console
command, 1-5
hpmc_reset Continuum system console
command, 1-5
Hung system, 5-8
Continuum-series
manual recovery, 5-9
XA/R-series module recovery, 5-11
I
IMMEDIATE POWER OFF button, 2-9, A-2
Indexes, 7-6
buffers for testing, 8-61
checking structure for validity, 8-35, 8-48
converting
keys to strings, 8-51
string representations of keys, 8-53
current position in, 8-59
listing all free blocks, 8-47
listing index node information, 8-40
locating records in, 8-58
Index-4
patching, 7-11
patching binary versions, 8-7
positioning in, 8-49, 8-56
re-creating, 7-10, 8-10
testing, 7-10, 8-26
verifying, 7-10, 8-86
Initializing the master disk, 3-6
L
last_record_number value, 7-9, 8-75
Length of buffers, 8-69
LEVEL-7 interrupt button
on Continuum-series, 1-4
on XA/R Model 20, A-4
on XA/R-series, 2-4
Lights
Continuum-series
board lights, 5-3
module status lights, 5-1
overview, 1-9
XA/R Model 20
BATTERY, A-3
OPERATING, A-3
TEST/PROBLEM, A-3
XA/R-series
BATTERY, 2-7
OPERATING, 2-7
TEST/PROBLEM, 2-7
unit failure lights, 2-7
Link boots, 3-4, 3-9
boot source, 3-10
hardware requirements for, 3-9
link boot server, 3-10
servers
invoking, 3-11
link_boot_server command, 3-10
list_buffers request, test_index
subsystem, 8-67
Listing
buffers, 8-67
index free blocks, 8-47
index node information, 8-40
information on current index, 8-48
Loading the operating system
from a link boot, 3-11
from the boot tape, 3-7
from the master disk, 3-2
Index
locate_record request, test_index
subsystem, 8-58
Longwords in buffers, 8-70
M
manual boot ready status message, 1-6,
2-6, A-3
MANUAL START UP button, A-2
Manual startup, 3-3, 5-7, 8-21
completion of, 5-7
Master disks, 3-3, 3-5
labels
-auto_boot switch, 5-7
Master startup procedure, A-4
Messages
console controller, 1-7
error
caused by uncreated symbol
tables, 3-12
e$cant_open_os_symtab, 3-12
e$corrupted_os_symtab, 3-12
e$wrong_os_symtab, 3-12
spurious, 3-11
sending to all users, 8-2
status
Booting release_number, 1-6,
2-5
HH:MM module_name, 1-7, 2-6, A-4
manual boot ready, 1-6, 2-6, A-3
module_start_up, 1-6, 2-5
module_start_up complete, 1-6,
2-5
module_start_up.cm, A-3
overseer: Shutdown
started, 1-6
PCP - command, A-4
PCP - dumping, 1-6, 2-6, A-3
Recovering disk_name, 1-6, 2-5,
A-3
Salvaging
logical_volume_name, 1
-6, 2-5, A-3
Shutdown request, 1-6, 2-6, A-3
slot_id message, 1-7, 2-6, A-4
system console, 1-6
Modifying the module_start_up.cm file, 3-8,
4-2
Module interruption
rebuilding indexes after, 8-13
updating directory entries after, 8-75
Module status lights
Continuum, 1-9
module_shut_down.cm file, 6-1
module_start_up status message, A-3
module_start_up.cm file, 3-9, 4-1
editing, 4-2
executing, 3-9
for multimodule systems, 4-2
missing from >system, 3-2
modifying, 3-8
module_start_up.out file, 3-8
Modules
booting
from disk, 3-3
from tape, 3-3
over StrataLINK, 3-9
Continuum
control panel for, 1-1
control panels of, 1-1
10-slot XA/R Model 20, A-1
Continuum-series, 1-1
XA/R-series, 2-1
manual startup of, 5-7
number of slots in, A-1
powering off, 5-9, A-5
recovering from a crash, 5-6
sending messages to, 8-2
server, 3-9
shutting down, 6-1, 8-21
starting up, 3-1
multiple, A-4
Monitor terminals. See System console
Moving
position in index, 8-49
N
names request, test_index subsystem, 8-29
Naming boot tapes, 3-3
notify_hardware_error command, 5-4
Index-5
Index
OPERATING light (XA/R Model 20), A-3

Operating lights
10-slot XA/R Model 20 module, A-3
during startup, 3-2
turning off, 5-5
Operating system, 5-6
loading from default boot partition, 3-5
symbol table, 3-12
Overseer process, 7-5
logging in, 3-8
Overseer.System, 3-8
logging out, 3-9
Rebooting after a crash, 7-1

Reboots, 8-21
Record location, 8-58
recover_disk command, 7-4
Recovering disk_name status
message, 1-6, 2-5, A-3
Recovery
disk, 7-4
from a crash, 5-6, 7-1
from module failure, 5-7
of directories, 7-3
of files, 7-6
recreate_index command, 7-10, 8-10
Re-creating file indexes, 7-10, 8-10
Red lights, 5-1
Relative files
Reloading the master disk, 3-7
reset_bus Continuum system console
command, 1-4
reset_configuration command, 5-5
restart_cpu Continuum system console
command, 1-4
RSN, 5-5
P
Partitions
dump, 5-6
Partner disks
recovering, 7-4
patch_file command, 7-11, 8-4
patch_index command, 7-11, 8-7
Patching files and indexes, 7-11
PCP - command status message, A-4
PCP - dumping status message, 1-6, 2-6, A-3
PCP process, 5-7
Planned shutdown, 6-1, 7-7
position request, test_index
subsystem, 8-59
power_off Continuum system console
command, 1-3
Powering off modules, 5-9, A-5
Primitive Control Program, 5-7
Problem analysis
system, 5-5
Processes
diagnostic utility, 5-5
Overseer, 3-8, 7-5
service, 4-1
checking, 7-5
starting, 4-1, 4-3
Q
quit Continuum system console
command, 1-5
quit request, test_index subsystem, 8-30
Index-6
S
salvage_disk command, 7-3
Salvager
errors from, 7-3
Salvaging disks, 7-3
Salvaging logical_volume_name status
message, 1-6, 2-5, A-3
Saving
dump files, 5-6
files for the CAC, 5-6
Selecting buffers for test_index, 8-73
Sending messages to all users, 8-2
Sequential files
Server module for link boot, 3-9
Server process for link boot, 3-10
Service processes, 4-1
starting, 4-3
set_buffer_byte request, test_index
subsystem, 8-68
Index
set_buffer_length request, test_index
subsystem, 8-69
set_buffer_longword request,
test_index subsystem, 8-70
set_buffer_text request, test_index
subsystem, 8-71
set_buffer_word request, test_index
subsystem, 8-72
Setting expiration time, 5-6
SHUT DOWN button, A-2
Shutdown
command macro used during, 6-1
disruptive, 8-21
emergency, 6-3
initiated by administrator, 8-20
module, 6-1
planned, 6-1, 7-7
warning users of impending, 6-2
shutdown command, 6-1, 8-20
and the disk cache, 7-7
invoking from batch, 6-2
status message, 1-6
shutdown Continuum system console
command, 1-3
Shutdown request status message, 1-6,
2-6, A-3
slot_id message status message, 1-7, 2-6,
A-4
spooler_admin command
in module_start_up.cm, 4-3
start_disk_recovery command, 7-4
start_logging command, 3-9
Starting
service processes, 4-3
Startup, 3-1
after a crash, 5-6
automatic, 3-2, 5-7, 8-21
command macro used during, 4-1
completing, 3-9
manual, 3-3, 5-7, 8-21
completion of, 5-7
missing files during, 3-2
multiple module, A-4
over StrataLINK, 3-9
reading table files, 4-1
starting system service processes, 4-1
system initialization process failure
during, 5-11
status Continuum system console

command, 1-5
STATUS DISPLAY panel
messages displayed on, 2-5, A-3
for components, 1-7, 2-6, A-4
Status lights
Continuum, 1-9
status request, test_index
subsystem, 8-48
StrataLINK
booting over, 3-4
using during startup, 3-9
Symbol tables
operating system, 3-12
syserr_log.date file
disk salvager errors in, 7-4
System console, 1-1
. (dot) command, 1-5
boot_auto command, 1-3
boot_manual command, 1-3
commands, 1-1
help command, 1-3
history command, 1-5
hpmc_reset command, 1-5
messages, 1-6
other documentation, 3-3
power_off command, 1-3
quit command, 1-5
reset_bus command, 1-4
restart_cpu command, 1-4
shutdown command, 1-3
status command, 1-5
System error logs, 3-3
System initialization process failure, 5-11
System interrupts, A-5
System problem analysis, 5-5
saving files for, 5-6
System process commands, 4-1
Systems
shutting down, 6-2
starting up, 3-1, A-4
Index-7
Index
T
Table files, 4-1
Tapes
booting from, 3-3
TEST/PROBLEM light, 3-2, 5-1
TEST/PROBLEM light (XA/R Model 20), A-3
test_index command, 8-26
backward_index request, 8-49
check request, 8-35
convert_key request, 8-51
convert_key_range request, 8-53
create_buffer request, 8-61
delete_buffer request, 8-63
display_buffer request, 8-64
dump_buffer request, 8-65
dump_node request, 8-40
fill_buffer request, 8-66
forward_index request, 8-56
free request, 8-47
help request, 8-28
list_buffers request, 8-67
locate_record request, 8-58
look_at request, 8-31
names request, 8-29
position request, 8-59
quit request, 8-30
set_buffer_byte request, 8-68
set_buffer_length request, 8-69
set_buffer_longword request, 8-70
set_buffer_text request, 8-71
set_buffer_word request, 8-72
status request, 8-48
use request, 8-33
use_buffer request, 8-73
Testing boards, 5-5
Testing file indexes, 7-10, 8-26
Text strings in buffers, 8-71
Transaction-protected files
and service recovery, 7-7
checking after crash, 7-8
Troubleshooting
a crash, 7-1
boards, 5-5
bus errors, 5-5
during automatic startup, 3-2, 3-3
file indexes, 8-10, 8-86
Index-8
link boots
limitations, 3-10
number of modules in a system, 3-9
manual boots from an IOP-based
device, 3-8
operating lights, 3-2
red lights, 5-4
system problems, 5-5
U
Unwritten blocks, 8-75
Updating directory entries, 8-75
use request, test_index subsystem, 8-33
use_buffer request, test_index
subsystem, 8-73
Users and messages, 8-2
V
Variables
attempt_auto_recovery, 5-8, 5-9
verify_end_of_file command, 7-9, 8-74
Verifying file indexes, 7-10, 8-86
Verifying the end of a file, 7-9
W
Words in buffers, 8-72
X
x25 command
in module_start_up.cm, 4-3
XA/R Model 20 10-slot module
AUTO START UP button, A-2
BATTERY light, A-3
control panel for, A-1
HALT/RESTART button, A-2
IMMEDIATE POWER OFF button, A-2
MANUAL START UP button, A-2
OPERATING light, A-3
SHUT DOWN button, A-2
TEST/PROBLEM light, A-3
XA/R-series module
control panel, 2-1
hung system recovery, 5-11

VOS Startup and Shutdown A System (r282-03)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

VOS Startup and Shutdown A System (r282-03)

Încărcat de

Drepturi de autor:

Formate disponibile

VOS System Administration:

Starting Up and Shutting Down a Module or System

Stratus Computer, Inc.

The information contained in this document is subject to change without notice.

1. The Continuum-Series System Console

2. The XA/R-Series Modular Control Panel

3. Starting Up a Module or System

4. The Module Startup

5. Responding to Status Lights

6. Shutting Down and Powering Off

7. Recovering from a Crash

Buffer Management Requests

Appendix A. Control Panels

Figure 1-1. Continuum-Series Modules (PA-7100 Processor) Front Panel

Main Cabinet and Expansion Cabinet Lights

This manual is intended for system administrators.

-verify_record, -verbose, and -repair

-syserr, and -recovery_macro

in the >system directorywill automatically execute prior to system shutdown

VOS System Administration: Administering and Customizing a System (R281)

Every module must have a copy of the module_start_up.cm file.

commands, subroutines, code fragments, and names of files and directories).

Key Mappings for VOS Functions

Format for Commands and Requests

Command Line Form

Explains briefly what the command or request does.

The default value is the current user, module, system, or

Required argument for which you can specify multiple values.

Set of arguments that are mutually exclusive; you must specify

Set of optional arguments that are mutually exclusive; you can

There are predefined values for this argument. In the display

You cannot issue the command or request without specifying a

Only a privileged process can specify a value for this argument.

H The following additional headings may appear in the command or request

description: Explanation, Error Messages, Examples, and Related Information.

contains the latest information available, including updates and corrections to

product that consists of online manuals and StrataDOC Viewer, delivered on a

maint_request command at the system prompt. Complete the on-screen form

Commenting on This Manual

Type comment_on_manual followed by -form, then press <Enter> or <Return>. Enter

Front Panel Commands

The Continuum-Series System Console

Front Panel Commands

Front Panel Commands:

Figure 1-1. Continuum-Series Modules (PA-7100 Processor) Front Panel Commands

Front Panel Commands

Front Panel Commands:

Figure 1-2. Continuum-Series Modules (PA-8000 Processor) Front Panel Commands

The Continuum-Series System Console

Front Panel Commands

Use the POWER_OFF command only when instructed to do

Repeat command to confirm

Repeat command to confirm:

Recovering a Hung System

* hpmc_reset (PA-8000 processor systems only)

Displays the version of firmware currently in use.

Recovering a Hung System

* manual boot ready

* Shutdown request sent to CPU

Console Controller Messages

* CC:System ID does not match CC stored system ID

* CC:System power is off;CC saved power state is off.

* CC:Host did not respond to initial power on command.