VOS System Analysis Manual (r073-04)
Uploaded by
kennycheungVOS System Analysis Manual (r073-04)
Uploaded by
kennycheungVOS System Analysis Manual
Stratus Computer, Inc.
R073-04
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.
Fuji is a trademark of Fuji Corporation.
i860 is a trademark of Intel Corporation.
Hewlett-Packard is a trademark of Hewlett-Packard Company.
UNIX is a registered trademark of The Open Group in the United States and other countries.
All other trademarks are the property of their respective owners.
Manual Name: VOS System Analysis Manual
Part Number: R073
Revision Number: 04
VOS Release Number: 14.0.0
Printing Date: November 1998
Stratus Computer, Inc.
55 Fairbanks Blvd.
Marlboro, Massachusetts 01752
1998 by Stratus Computer, Inc. All rights reserved.
Preface
The VOS System Analysis Manual (R073) documents many of the requests of the
analyze_system command available in VOS Release 14.0.0. The
analyze_system requests display information about the operating system as it is in
its current, running state or as it was at the moment of a failure.
This manual is intended for privileged users of the VOS operating system.
This manual does not commit Stratus to maintaining or retaining documented features
or capabilities of the analyze_system command. Undocumented changes such as
new requests, new request arguments, changed request output, or deletions of
requests may occur in any new VOS release.
Owing to performance and other enhancements introduced with each release of VOS,
the analyze_system command is not guaranteed to be cross-release compatible.
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 request descriptions.
This revision includes the following changes.
addition of the -c_expressions argument to the analyze_system command
changes to the following request descriptions:
display_process_info
dump_afte
dump_rsv_socket
dump_stream
dump_vm_pool_info
list_boards
set_comm_thresholds
Preface
iii
Preface
the addition of the following requests.
cache_meters
dump_tpo
clone_command
dump_transaction
disk_lock_meters
event_count_meters
disk_meters
interrupt_meters
display_cache_pin_parameters
list_streams_params
display_meter_file_info
list_tp_params
dump_bsc
list_transactions
dump_cache
lock_meters
dump_fli
lock_summary
dump_giza
page_meters
dump_h3270
scan_streams_msgs
dump_iop_equip_table
sched_lock_meters
dump_iop_meters
sched_meters
dump_lap_meters
set_cache_pin_parameters
dump_lcb
set_meter_file
dump_lock
set_streams_param
dump_net_tids
set_tp_param
dump_queue_info
sim_int_meters
dump_r3270
terminal_meters
dump_r3270_trace
tpq_meters
dump_socket
transaction_meters
dump_stream (dump_streams)
wired_memory_meters
Related Manuals
Refer to the following Stratus manuals for related documentation.
VOS Communications Software: Poll/Select Terminal Support (R044)
Customer Support System Reference Manual (R094)
VOS Commands Reference Manual (R098)
Universal Communications I/O Adapter Programming (R109)
Product Configuration Bulletin: X.25 T1 (R124)
Primary and Secondary Systems Network Architecture: Planning and Operations
Guide (SC34-0757)
iv
VOS System Analysis Manual (R073)
Preface
VOS Communications Software: 3270 Channel Attach Programmers
Guide (R220)
VOS Communications Software: STREAMS Programmers Guide (R306)
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
Preface
Preface
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.
NOTE
Certain applications may define these keys differently.
Refer to the documentation for the application for the
specific key mappings.
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
V105
PC/+ 106
V105
ANSI
CANCEL
<F18>
<5> or *
<F18>
CYCLE
<F17>
<F12>
<4>
<F17>
<Shift>-<F17>
<Shift>-<F12>
<7>
<Shift>-<F17>
<F19>
<6> or -
<F19> or
<Shift>-<Help>
HELP
<Shift>-<F8>
<Shift>-<F2>
<Shift>-<F8>
<Help>
INSERT DEFAULT
<Shift>-<F11>
<Shift>-<F10>
<Shift>-<F11>
<F11>
<F11>
<F10>
<F11>
<Insert_Here>
INTERRUPT
<Shift>-<F20>
<Shift>-<Delete>
<1>
<Shift>-<F20>
NO PAUSE
<Shift>-<F18>
<Shift>- *
<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.
vi
VOS System Analysis Manual (R073)
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
vii
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.
viii
VOS System Analysis Manual (R073)
Preface
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]...
argument_1
argument_2
Optional argument.
Optional argument for which you can specify multiple values.
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.
Preface
ix
Preface
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.
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
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.
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.
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.
VOS System Analysis Manual (R073)
Preface
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, R073, 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>.
NOTE
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
xi
Preface
xii
VOS System Analysis Manual (R073)
Contents
Preface
iii
1. Overview of the analyze_system Command
Summary of analyze_system Functionality
Invoking the analyze_system Command
Getting Help
Summary of the Modes of Operation
Summary of the Documented analyze_system Requests
General Requests
Communications Requests
Disk File-System Requests
Heap, Memory, and Stack Requests
Metering Requests
Mode Setting Requests
Process Requests
Tape Drive Requests
1-1
1-1
1-3
1-3
1-4
1-6
1-6
1-8
1-11
1-12
1-13
1-14
1-14
1-15
2. Using the analyze_system Command
Executing VOS Commands
Executing Internal VOS Commands
Executing External VOS Commands
Canceling a Request
Filtering Output
Filtering Output with the match Request
Filtering Output with Request Arguments
Redirecting Output to a File
Displaying Files
Displaying Files with the VOS display Command
Displaying Files with the display_file Request
Displaying System Error Log Data
Specifying Variable Names and Values
Variable Names
Variable Values
2-1
2-1
2-2
2-3
2-3
2-4
2-4
2-5
2-6
2-7
2-7
2-9
2-11
2-13
2-13
2-14
Contents
xiii
Contents
xiv
3. Specifying Address Formats for Request Arguments
Requests That Take Default Address Values
Using Hexadecimal Address Formats
Using Symbolic Address Formats
Object Module Names
Object Module Code Relative Addressing
Internal Static Relative Addressing
Indirect Addressing
Relative Addressing Used by the display Request
Displaying Stack Data
Stack Relative Addressing
3-1
3-3
3-3
3-4
3-5
3-7
3-11
3-11
3-12
3-13
3-16
4. Using the Modes of Operation
Selecting a Mode
Using Communications Controller Dump Mode
Using Disk Block Mode
Displaying the Contents of a File
Displaying the Contents of an Index
Using Dump Mode
Preparing to Enter Dump Mode
Entering Dump Mode and Selecting a Dump
Displaying the Status of a Dump
Displaying and Selecting Processes Recorded in a Dump
Displaying Stack Information from a Dump
Troubleshooting a Dump
Deleting Dumps and Exiting Dump Mode
Using IOA and IOP Modes
Using IOA Dump Mode
Using IOA Firmware Mode
IOP Requests Available in Module Mode
Using IOP Dump Mode
Using IOP Firmware Mode
Using Module Mode
Request Types Used in Module Mode
The VOS Program Module Memory Structure
The Structure of the XA/R-Series VOS Program
Module
Shared Memory Space for an XA/R-Series VOS
Program Module
The Structure of the Continuum-Series VOS
Program Module
4-1
4-2
4-3
4-3
4-3
4-5
4-7
4-8
4-8
4-9
4-10
4-10
4-11
4-12
4-12
4-12
4-14
4-16
4-16
4-17
4-20
4-21
4-22
VOS System Analysis Manual (R073)
4-23
4-24
4-27
Contents
Shared Memory Space for a Continuum-Series
VOS Program Module
Ranges of Virtual Addresses in User Process Space
Using Partition Mode
Using Program Module (File) Mode
Undefined Mode
4-31
4-34
4-34
4-35
4-35
5. Requests That Provide Metering Information
Types of Meters
Requests That Contain the Word meters
Requests That Contain the Argument -meter(s)
Requests That Contain All Meter Fields
Requests That Contain Some Meter Fields
Resetting Meters
Using a Meter File
5-1
5-1
5-1
5-2
5-3
5-4
5-4
5-5
6. Requests That Display and Change Memory
Displaying Unformatted and Formatted Data in Memory
Displaying Unformatted Data in Memory
Displaying Formatted Data in Memory
Displaying Values in the VOS Symbol Table
Displaying Values in External Variables
Changing Memory
Requests That Change Specific Areas of Memory
Displaying and Setting Data and Instructions in Memory
Additional Rules for XA/R-Series Modules
6-1
6-1
6-1
6-3
6-4
6-4
6-5
6-6
6-7
6-7
7. Requests That Display Process Information
Listing Processes
Determining the Process Number
Finding a Process
Finding a Process That Is Executing a Program
Finding a Process That Is Using an Open File
Finding a Process That Is Waiting on an Event
Finding a Process That Is Using a Device
Determining the State of a Process
Selecting a Process
Displaying User Process Memory
XA/R-Series User Process Memory
Continuum-Series User Process Memory
7-1
7-1
7-3
7-4
7-4
7-5
7-5
7-6
7-6
7-7
7-7
7-8
7-10
Contents
xv
Contents
8. Analyze System Commands and Requests
analyze_system
cache_meters
change_iop_dump_switch
check_area
clone_command
delete_dump
disassemble
disk_lock_meters
disk_meters
display
display_alignment_faults
display_cache_pin_parameters
display_extensible_heap
display_file
display_memory_usage
display_meter_file_info
display_net_trace
display_pm
display_process_info
display_security_info
display_system_usage
dump_adt
dump_adte
dump_afte
dump_area
dump_axte
dump_bmt
dump_bsc
dump_cache
dump_cache_info
dump_channel_info
dump_channels
dump_comm_buffers
dump_eit
dump_et
dump_events
dump_firmware_names
dump_fli
dump_fw_table
dump_giza
dump_h3270
dump_iop_equip_table
dump_iop_meters
dump_lap_meters
dump_lcb
dump_lock
xvi
VOS System Analysis Manual (R073)
8-1
8-2
8-4
8-7
8-10
8-14
8-16
8-18
8-20
8-23
8-28
8-32
8-35
8-36
8-40
8-43
8-50
8-52
8-57
8-64
8-70
8-72
8-75
8-82
8-85
8-92
8-100
8-104
8-107
8-111
8-115
8-118
8-121
8-124
8-129
8-134
8-142
8-146
8-148
8-151
8-153
8-156
8-160
8-163
8-166
8-168
8-171
Contents
dump_mt
dump_net_info
dump_net_tids
dump_nst
dump_poll_select
dump_porte
dump_protocol_names
dump_prt
dump_pte
dump_queue_info
dump_r3270
dump_r3270_trace
dump_rst
dump_rsv_socket
dump_scheduler_queues
dump_socket
dump_socket_info
dump_stream
dump_streams
dump_syserr
dump_tcb
dump_tcbh
dump_tdr
dump_tpo
dump_transaction
dump_vm_pool_info
edit_vm_sizes
evaluate
event_count_meters
find_string
frame
fstack
help
interrupt_meters
list_boards
list_disks
list_dumps
list_file_activity
list_iop_dump_switch
list_iop_dumps
list_port_attachments
list_streams_params
list_tp_params
list_transaction_trace
list_transactions
lock_meters
lock_summary
log_alignment_faults
match
monitor_net_trace
8-176
8-180
8-185
8-188
8-191
8-196
8-206
8-208
8-210
8-217
8-229
8-235
8-239
8-242
8-246
8-249
8-252
8-259
8-298
8-299
8-302
8-309
8-313
8-320
8-325
8-327
8-335
8-339
8-341
8-344
8-345
8-348
8-351
8-352
8-357
8-363
8-365
8-367
8-370
8-372
8-374
8-376
8-381
8-383
8-385
8-389
8-394
8-398
8-401
8-403
Contents
xvii
Contents
page_meters
pme_status
power_summary
process
quit
scan_area
scan_streams_msgs
sched_lock_meters
sched_meters
search_streams
set_byte
set_cache_pin_parameters
set_comm_thresholds
set_instruction
set_longword
set_meter_file
set_net_timeout
set_net_trace
set_streams_param
set_tape_buffer_mode
set_tp_param
set_word
setup_user_program
sim_int_meters
sleep
stack
status
summary
terminal_meters
tpq_meters
trace
transaction_meters
use_block
use_dump
use_file
use_iop
use_iop_dump
use_module
use_partition
variable
walk
where
who
wired_memory_meters
xviii
VOS System Analysis Manual (R073)
8-409
8-413
8-416
8-419
8-422
8-423
8-430
8-435
8-438
8-441
8-445
8-448
8-452
8-459
8-461
8-464
8-466
8-468
8-470
8-472
8-473
8-477
8-480
8-481
8-484
8-486
8-494
8-498
8-502
8-504
8-508
8-512
8-516
8-519
8-523
8-525
8-528
8-530
8-531
8-533
8-535
8-538
8-540
8-543
Contents
Appendix A. Abbreviations Used by the analyze_system Command A-1
Appendix B. VOS Internal Commands
B-1
Appendix C. Requests That Are Described in Other Stratus Manuals C-1
Appendix D. Requests That Are Obsolete or for Stratus Use Only
Index
D-1
Index-1
Contents
xix
Figures
Figure 4-1.
Figure 4-2.
Figure 4-3.
Figure 4-4.
Figure 7-1.
Figure 7-2.
Figure 8-1.
Figure 8-2.
Figure 8-3.
xx
XA/R-Series VOS Program Module at Boot Time
Sample XA/R-Series (G861 or G862) VOS Virtual
Memory Pool
Continuum-Series VOS Program Module at Boot Time
Sample Continuum-Series VOS Virtual Memory Pool
XA/R-Series Modules User Process Space
Continuum-Series Module User Process Space
Socket Structures
VOS STREAMS I/O Data Structures
VOS STREAMS Data Structures That Synchronize
Execution Threads
VOS System Analysis Manual (R073)
4-24
4-27
4-31
4-33
7-9
7-11
8-255
8-264
8-266
Tables
Table 1-1.
Table 1-2.
Table 1-3.
Table 1-4.
Table 1-5.
Table 1-6.
Table 1-7.
Table 1-8.
Table 3-1.
Table 4-1.
Table 4-2.
Table 4-3.
Table 8-1.
Table 8-2.
Table A-1.
Table B-1.
Table D-1.
Requests for Obtaining General System Status
Requests for Obtaining Communications Status
Requests to Obtain Disk and File-System Status
Requests to Obtain Heap, Memory, and Stack Status
Requests to Obtain Metering Information
Requests to Set analyze_system Modes
Requests to Obtain Information about Processes on a
Module
Request to Set Tape Drive Status
Valid Address Formats
Preparing and Selecting Subsystem Modes
Types of Module Mode Requests
Virtual Address Ranges in User Process Space
The dump_stream -stm_sched Meters
Parameter Values of the set_tp_param Request
Abbreviations
VOS Internal Commands
Obsolete and Stratus Use Only Requests
1-6
1-8
1-11
1-12
1-13
1-14
1-14
1-15
3-2
4-2
4-21
4-34
8-275
8-474
A-1
B-1
D-1
Tables
xxi
Tables
xxii
VOS System Analysis Manual (R073)
Chapter 1
Overview of the
analyze_system Command
1-
This chapter provides an overview of the analyze_system command. It contains the
following sections.
Summary of analyze_system Functionality
Invoking the analyze_system Command
Getting Help
Summary of the Modes of Operation
Summary of the Documented analyze_system Requests
Summary of analyze_system Functionality
The analyze_system command contains over 400 requests that enable you to
perform the following tasks.
examine and display information such as the following:
user and VOS kernel memory space on any networked module
a VOS program module in a particular boot partition
a static dump of user and VOS kernel memory space
any 4096-byte block on a disk
firmware running on an I/O processor or I/O adapter or BIO board
a static dump of C200 communications controllers
a static dump of I/O adapter or I/O processor memory
set values in memory
direct command input to any of the following:
VOS internal commands
other analyze_system requests
Overview of the analyze_system Command
1-1
Summary of analyze_system Functionality
iop_debug (running on an I/O processor)
ioa_debug (running on an I/O adapter)
The following are typical reasons to use the analyze_system command:
to set kernel variables
to set communications protocol limits
to collect information about
application performance, including performance meters, in order to improve
performance
system resource use for capacity planning
to debug
UCOMM firmware
alignment faults on XA/R-series and Continuum-series modules
program modules without, or in addition to, the source level debugger.
to patch code or data in program modules or VOS boot partitions
For more information on where additional requests are documented, see Appendix C.
The remaining requests are undocumented, obsolete, or for Stratus use only. See
Appendix D for a list of the obsolete and Stratus internal-use requests.
This chapter briefly describes the following:
how to invoke the analyze_system command
how to get help about the requests supported by the analyze_system command
the modes of operation of the analyze_system command
This chapter also provides a summary of the documented analyze_system
command requests.
1-2
VOS System Analysis Manual (R073)
Invoking the analyze_system Command
Invoking the analyze_system Command
When you issue the analyze_system command at the command line, it displays a
prompt and information such as the following.
ready 11:32:00
analyze_system
VOS Release 14.0.0d, analyze_system Release 14.0.0d
Current process is 472, ptep C3506700, Suzanne_Ryan.Eng
as:
By default, the analyze_system command defines the module as the current module
and the process as the current process (which is running analyze_system). At the
prompt, you can enter any request displayed by the help request, although certain
requests execute only in certain modes of the analyze_system command. For more
information about the help request, see Getting Help. For more information about
modes of operation of the analyze_system command, see Summary of the Modes
of Operation.
Getting Help
The help request enables you to list all of the currently available analyze_system
requests, or to list those requests that match a specified string. The following example
shows the command-line form of the help request.
as: help -usage
Usage: help [-match string]
as:
The following example shows the use of the help request to display request names
that contain a string such as err.
as: help -match err
dump_syserr
interrupt_meters
as:
You can specify the -usage argument for all analyze_system requests. Specify this
argument to display the command-line form of any request, as shown in the following
example.
as: dump_syserr -usage
Usage: dump_syserr [-all] [-last number] [-long]
as:
Overview of the analyze_system Command
1-3
Summary of the Modes of Operation
You can also specify the -usage argument in combination with the -form argument
to display the default values for all arguments to a request without invoking the request.
For example:
as: dump_syserr -usage -form
--------------------- dump_syserr ---------------------all: no
-last:
-long: no
as:
Summary of the Modes of Operation
The analyze_system command operates in one of the following modes: disk block,
dump, module, I/O adapter dump, I/O adapter firmware, I/O processor dump, I/O
processor firmware, partition, program module (file), and undefined. With the exception
of the undefined mode, each mode sets the context in which subsequent requests are
interpreted. Certain requests such as use_dump, use_partition, use_file, or
use_module enable you to change modes. For more information about these modes
of operation, see Chapter 4.
In actuality, mode determines the source of data when analyze_system is given a
memory address from which to fetch data. In some modes, such as use_module,
further clarification of the exact address space must be specified with the process
command.
In disk block mode, you can examine and alter a single 4096-byte disk block. The
analyze_system command enters disk block mode when you issue the
use_block request.
Dump mode re-creates a VOS environment or image from a specified dump and
from any kernel-loadable drivers present when the dump was taken. In dump
mode, the analyze_system command responds to requests by displaying
information about the state of the analyzed module at the time of the failure. For
example, it responds to a list_boards request in dump mode by displaying
information about the boards present in the analyzed module at the time of the
failure you are analyzing. To enter dump mode, issue the use_dump request.
I/O adapter dump mode enables you to display or change data in I/O adapter
memory. An I/O adapter uses the I/O processor to communicate with the CPU. To
enter I/O adapter dump mode, first issue the use_iop_dump or use_dump
request, and then issue the use_iop request with the -ioa argument.
I/O adapter firmware mode enables you to analyze live firmware running on an I/O
adapter. To enter I/O adapter firmware mode, issue the use_iop request with the
-ioa argument.
1-4
VOS System Analysis Manual (R073)
Summary of the Modes of Operation
I/O processor dump mode enables you to display or change data in I/O processor
memory. To enter I/O processor dump mode, first issue the use_iop_dump or
use_dump request, and then issue the use_iop request.
I/O processor firmware mode enables you to analyze live firmware running on an
I/O processor. To enter I/O processor firmware mode, issue the use_iop request.
Module mode sets the VOS environment to that of the specified module. The
specified or analyzed module is the module about which the analyze_system
command displays information. For example, VOS responds to a list_boards
request in module mode by displaying information about the boards currently
present in that module.
By default, the analyze_system command enters module mode when you issue
the command, unless you specify a use_dump, use_partition, or use_file
request for the commands -request_line argument or if you specify no value
for the -module argument (which causes the command to enter undefined mode).
If the command is in another mode, you can reenter module mode by issuing the
use_module request.
Partition mode sets the VOS environment to the vos.pm image in the specified
boot partition. Most of the analyze_system requests are not meaningful in
partition mode.
To enter partition mode, issue the use_partition request and specify a partition
and the disk that partition is on. If you do not specify any arguments, the command
defaults to the currently booted partition.
Program module (file) mode sets the VOS environment to the specified program
module file image. Use this mode to analyze only VOS program modules. Most of
the analyze_system requests are not meaningful in file mode.
To enter program module mode, issue the use_file request and specify a
program module file. The request loads a program module into the address space
of the current process.
Use undefined mode to prevent the analyze_system command from creating an
environment before displaying the as: prompt. Undefined mode saves time if you
plan to immediately enter a mode other than module mode (module mode on the
current module is the default mode). To invoke undefined mode, specify
analyze_system -module at the VOS command line. Do not specify a value
for the -module argument.
Overview of the analyze_system Command
1-5
Summary of the Documented analyze_system Requests
Summary of the Documented analyze_system Requests
The following sections provide summaries of all of the analyze_system requests
documented in this manual. The requests are listed alphabetically under the following
categories.
general
communications
disk file system
heap, memory, and stack
metering information
mode setting
process
tape drive
General Requests
Table 1-1 describes requests that you use to obtain general system status information.
Table 1-1. Requests for Obtaining General System Status (Page 1 of 3)
1-6
Request
Description
clone_command
Executes a single external command on a nonwindow
terminal device
delete_dump
Deletes a specified file containing a dump image
disassemble
Displays a specified number of storage bytes in assembly
language format
display
Displays a specified number of storage bytes in both
hexadecimal and ASCII characters
display_file
Splits a screen to display a file on the top half and an
analyze_system dialog on the bottom half
display_pm
Displays information about a user or kernel program
module
display_security_info
Displays information used by security logging
display_system_usage
Displays information about usage on the specified module
dump_eit
Displays information about the executable image table
dump_et
Displays the event table or selected entries from the event
table
VOS System Analysis Manual (R073)
Summary of the Documented analyze_system Requests
Table 1-1. Requests for Obtaining General System Status (Page 2 of 3)
Request
Description
dump_events
Displays the events for a process
dump_fli
Displays information about one or more
file_lock_info (FLI) structures
dump_lock
Displays information about one or more system locks
dump_porte
Displays information about a port
dump_pte
Displays a process table entry of selected lines from a
process table
dump_scheduler_queues
Displays information about the state of the queues
maintained by the scheduler
dump_syserr
Displays the most recent system error messages
dump_tpo
Displays information about the TPOverseers internal data
structures
dump_transaction
Displays information about a specific Transaction State
Info (TSI) structure
evaluate
Displays the hexadecimal value of the specified indirect or
variable address
find_string
Enables you to search for a matching ASCII or
hexadecimal string in dump mode
help
Displays the current list of analyze_system requests
list_boards
Displays information about a specified board, all boards of
a specified type, or all of the boards on a module
list_dumps
Displays a list of system dump images
list_transaction_trace
Displays information about the specified numbers of
transactions most recently completed
list_transactions
Displays information about a specific list of TSIs or about
all TSIs active in the system
list_tp_params
Displays the values of various TP debugging and tuning
parameters
match
Affects the output of the request given subsequent to this
request. The only lines of output displayed are those
containing the string entered in the match request
power_summary
Displays information about the power loading for the
module
Overview of the analyze_system Command
1-7
Summary of the Documented analyze_system Requests
Table 1-1. Requests for Obtaining General System Status (Page 3 of 3)
Request
Description
quit
Exits the analyze_system command
set_byte
Sets the value of one or more bytes in the current
environment
set_instruction
Sets the value of one or more instructions in the current
environment
set_longword
Sets the value of one or more long words in the current
environment
set_tp_param
Enables you to change the value of an individual
STREAMS parameter
set_word
Sets the value of one or more words in the current
environment
status
Displays information about the current version of VOS and
analyze_system
variable
Defines a variable that can be used in a subsequent
request or, if no arguments are given, lists the value of all
the variables set
walk
Enables you to execute a request for a linked list of
processes on the current module
where
Evaluates an expression and shows where it is located in
memory
Communications Requests
Table 1-2 describes the requests that you use to obtain communications status
information.
Table 1-2. Requests for Obtaining Communications Status (Page 1 of 3)
1-8
Request
Description
change_iop_dump_switch
Sets one of eight dump types for I/O processor and I/O
adapters on a module
display_net_trace
Displays the contents of the StrataLINK net trace buffer in
kernel memory
dump_bsc
Displays information about the specified binary
synchronous communications (BSC) channel
dump_channel_info
Displays the specified channel information structure
VOS System Analysis Manual (R073)
Summary of the Documented analyze_system Requests
Table 1-2. Requests for Obtaining Communications Status (Page 2 of 3)
Request
Description
dump_channels
Displays information about asynchronous communications
channels
dump_comm_buffers
Displays information about the buffers currently in use by
an asynchronous channel
dump_firmware_names
Displays firmware loaded on a module
dump_fw_table
Displays protocols and hardware associated with firmware
configured on a module
dump_giza
Dumps host-side data structures that contain Giza engine
information
dump_h3270
Displays information about the specified 3270_host
channel
dump_iop_equip_table
Displays the contents of the IOP equipment table
dump_lcb
Enables you to examine the control block of a LAPB
channel (lcb stands for LAPB_control_block)
dump_net_info
Displays StrataNET status information for a system
dump_net_tids
Displays transaction IDs (TIDS) for StrataLINK stations on
a module
dump_nst
Displays the net socket table (NST) for a StrataLINK or
StrataNET connection on a module
dump_nst
Displays the net socket table (NST) for a StrataLINK
connection on a module.
dump_poll_select
Displays the state of a poll/select line or a poll/select
terminal
dump_protocol_names
Displays the names of protocols configured for a module
dump_prt
Displays the StrataLINK and StrataNET pending request
table (PRT) on a module
dump_r3270
Displays information about the specified 3270_remote
channel
dump_r3270_trace
Displays information about the specified 3270_remote
channel
dump_rst
Displays the StrataLINK and StrataNET reserved socket
table (RST) on a module
Overview of the analyze_system Command
1-9
Summary of the Documented analyze_system Requests
Table 1-2. Requests for Obtaining Communications Status (Page 3 of 3)
1-10
Request
Description
dump_rsv_socket
Displays information about the traffic on each StrataLINK
and StrataNET socket in the analyzed module or dump
dump_socket
Displays socket information for StrataLINK connections on
a module
dump_socket_info
Displays information about StrataLINK and StrataNET
sockets on a module
dump_stream
dump_streams
Displays stream queues, messages, or timers
dump_tcb
Displays information about the terminal control block
dump_tcbh
Displays information about the terminal control block
header
list_iop_dump_switch
Lists dump types for one or all I/O processors or I/O
adapters on a module
list_iop_dumps
Lists the I/O processor dumps on a module
list_streams_params
Displays the STREAMS parameters that you can change
monitor_net_trace
Traces StrataLINK network activity in real-time
scan_streams_msgs
Summarizes STREAMS message usage
search_streams
Displays all open streams on a module or just the open
streams for a process
set_comm_thresholds
Sets the error threshold and error interval for individual
VOS communications protocols
set_net_timeout
Sets the time limit for a module to complete any StrataLINK
or StrataNET network operation
set_net_trace
Determines when StrataLINK or StrataNET data is sent to
the 4096 byte circular tracing buffer
set_streams_param
Enables you to change the value of an individual
STREAMS parameter
use_iop_dump
Selects an I/O processor dump
VOS System Analysis Manual (R073)
Summary of the Documented analyze_system Requests
Disk File-System Requests
Table 1-3 describes the requests that you use to obtain disk file-system status
information.
Table 1-3. Requests to Obtain Disk and File-System Status
Request
Description
display_cache_pin_parameters
Displays the pinning status of the disk cache
dump_adt
Displays information about the active directory
table
dump_adte
Displays information about the specified active
directory table entries
dump_afte
Displays information about the specified active
file table entries
dump_axte
Displays information about the specified active
index table entries
dump_bmt
Displays information about the file partition bit
map table
dump_cache
Displays a summary of each cache buffer
dump_cache_info
Displays current disk cache information
dump_queue_info
Displays diagnostic information about message
queues and server queues from the VOS kernel
data structures
list_disks
Displays information about the disks on the
specified module along with status information
set_cache_pin_parameters
Enables you to set the cache pin parameters
Overview of the analyze_system Command
1-11
Summary of the Documented analyze_system Requests
Heap, Memory, and Stack Requests
Table 1-4 describes the requests that you use to obtain heap, memory, and stack
status information.
Table 1-4. Requests to Obtain Heap, Memory, and Stack Status
1-12
Request
Description
check_area
Checks the internal structure of a heap for consistency
display_alignment_faults
Displays alignment faults on XA/R-series and
Continuum-series modules
display_extensible_heap
Displays information about the VOS shared extensible
heap
display_memory_usage
Displays information that shows how the virtual address
space of the analyzed process is used
dump_area
Displays information about the contents of a heap
dump_mt
Displays information about the memory table
dump_tdr
Displays information about the task data region
dump_vm_pool_info
Displays information about the virtual memory pool
edit_vm_sizes
Enables some user control of VOS kernel memory size
frame
Sets the default stack frame address to the address
specified or displays the default stack frame address
fstack
Displays a forward stack trace of a stack belonging to
the specified process
scan_area
Displays information about the header and summary
contents of a heap
stack
Displays the stack contents belonging to the specified
process
trace
Displays a stack belonging to a specified process
VOS System Analysis Manual (R073)
Summary of the Documented analyze_system Requests
Metering Requests
Table 1-5 describes the requests that you use to obtain metering information.
Table 1-5. Requests to Obtain Metering Information
Request
Description
cache_meters
Displays the disk cache meters
dir_meters
Displays the directory meters
disk_lock_meters
Displays the disk meters
disk_meters
Displays the disk meters for a specified logical disk or all
disks on a module
display_meter_file_info
Displays information about the current meter file,
including its path name
dump_iop_meters
Displays the I/O processor meters from a dump
dump_lap_meters
Displays the LAPB meters from a dump
event_count_meters
Displays the event count meters
interrupt_meters
Displays the interrupt meters
list_file_activity
Displays the file meters
lock_meters
Displays information about all locks currently in use in
the VOS kernel
lock_summary
Displays a summary of the lock meters
page_meters
Displays the disk paging meters
sched_lock_meters
Displays the scheduler lock meters
sched_meters
Displays the scheduler meters
set_meter_file
Displays the scheduled lock meters
sim_int_meters
Displays the simulated interrupt meters
terminal_meters
Displays the terminal meters
transaction_meters
Displays the transaction processing queue meters
wired_memory_meters
Displays the wired memory meters
Overview of the analyze_system Command
1-13
Summary of the Documented analyze_system Requests
Mode Setting Requests
Table 1-6 describes the requests that you use to set analyze_system modes.
Table 1-6. Requests to Set analyze_system Modes
Request
Description
use_block
Specifies a particular disk block as a data source
use_dump
Places the analyze_system command in dump mode and
displays information about the state of the system at the time the
specified dump was created
use_file
Places the analyze_system command in file mode and opens the
program module file as a data source
use_iop
Places the analyze_system command in I/O processor or I/O
adapter mode for a specified I/O processor or I/O adapter
use_module
Places the analyze_system command in module mode
use_partition
Places the analyze_system command in boot partition mode
Process Requests
Table 1-7 describes the requests that you use to get information about processes on a
module.
Table 1-7. Requests to Obtain Information about Processes on a Module
1-14
Request
Description
display_process_info
Displays information about the specified process
list_port_attachments
Displays information about port attachments in the specified
process
pme_status
Displays information about the process map entry or entries
process
Sets the process to analyze
setup_user_program
In dump, program module (file), or partition mode, sets the
path of a program module that has been moved or deleted
sleep
Enables a process to sleep for a specified period of time
summary
Displays the list of names and process numbers of
processes and a brief description of what each process is
doing
who
Displays information about users and processes
VOS System Analysis Manual (R073)
Summary of the Documented analyze_system Requests
Tape Drive Requests
Table 1-8 describes the request that you use to set tape drive status information.
Table 1-8. Request to Set Tape Drive Status
Request
Description
set_tape_buffer_mode
Sets the buffer mode of a tape drive to streaming or
start-stop mode
Overview of the analyze_system Command
1-15
Summary of the Documented analyze_system Requests
1-16
VOS System Analysis Manual (R073)
Chapter 2
Using the analyze_system
Command
2-
This chapter provides tips for using the analyze_system command and information
about the following:
Executing VOS Commands
Canceling a Request
Filtering Output
Canceling a Request
Displaying Files
Specifying Variable Names and Values
Executing VOS Commands
By default, the analyze_system command interprets any command line entered at
the as: prompt or any value for the analyze_system -request_line argument
as an analyze_system request. The following sections describe how to enter VOS
external and internal commands from within the analyze_system command. Internal
commands are bound into the VOS kernel. The command processor does not search
for internal commands in the directory hierarchy. External commands are command
macros and program modules located in various command libraries.
Using the analyze_system Command
2-1
Executing VOS Commands
Executing Internal VOS Commands
To invoke a VOS internal command, precede it with a two-dot (..) prefix. For example:
as:
as:
..change_current_dir >system
..list -dirs
Directories: 62
m
s
s
s
s
....
as:
2
1
1
1
1
accounting
acl
alc
asn_include_library
asn_object_library
To see a complete list of VOS internal commands, enter help -type internal at
the as: prompt (note that the VOS help command is an internal command). For
example:
as:
..help -type internal
Internal Commands:
add_device (privileged)
add_disk (privileged)
add_link_board (privileged)
....
list_devices
list_kernel_programs (privileged)
as:
list_modules (prelogin)
list_port_attachments
list_process_cmd_limits
where_path
who_locked
If you do not use the two-dot prefix, the analyze_system command displays a
message that it could not find the entry point. For example:
as: change_current_dir >system
analyze_system: Entry point name not found. change_current_dir
as:
If you use the two-dot prefix with an external command, the analyze_system
command displays a message that the specified command is not internal. For example:
as: ..list_users M*
analyze_system: Specified command is not internal. list_users
as:
If you use the two-dot prefix with an internal command followed by a semicolon and an
analyze_system request or external command, the analyze_system command
2-2
VOS System Analysis Manual (R073)
Canceling a Request
interprets the request or external command as an internal command and cannot
execute it. For example:
as: ..display_current_dir; process
%sys#m2>system
analyze_system: Object not found. process
Executing External VOS Commands
Issue the login command to execute one or more external commands. For example:
as: ..login
Suzanne_Ryan.Eng logged in on %sys#m2 at 95-04-10 10:35:05 EDT.
ready: display_current_dir
%sys#m2>system
ready: change_current_dir
ready: display_current_dir
%sys#m2_user>Eng>Suzanne_Ryan
ready: list_users J*
Suzanne_Ryan.Eng
* Suzanne_Ryan.Eng
ready: logout
as:
If you are a window terminal user, the login command creates a subsequent process
and executes your start_up.cm file. When you issue the logout command as a
window terminal user, the command clears the command history displayed on your
screen before displaying the as: prompt.
If you are not a window terminal user, you can issue the clone_command request to
execute a single external command. Enclose the external command line in single
quotes. For example:
as: clone_command list_users J*
Suzanne_Ryan.Eng
* Suzanne_Ryan.Eng
as:
Canceling a Request
If you entered the wrong request or cannot specify a valid required argument to a
request, you can cancel a request without exiting the analyze_system command. To
cancel a request, press the key that invokes the CANCEL function. If that does not work,
Using the analyze_system Command
2-3
Filtering Output
press the key that invokes the BREAK function. At the debug prompt, type reenter.
For example:
as: update_iop_dump_switch -form
iop_slot: BREAK
Request? (stop, continue, debug, keep, login, re-enter) reenter
as:
NOTE
If you are using a window terminal device, you must press
<CTRL>-c twice to invoke the BREAK function. For more
information about invoking the BREAK function on window
terminal devices, see the description of the
set_terminal_parameters command in the VOS
Commands Reference Manual (R098).
Filtering Output
You can filter output with the match request and with the -match argument, which is
available with many analyze_system requests.
Filtering Output with the match Request
You can use the match request to restrict output lines from the next request to those
that contain a match for a specified string. Also, the match request is not case
sensitive. As shown in the following example, the match request displays only the
output lines containing the matching text.
as: match process_id
as: dump_pte
PTE at 8180E440 for Suzanne_Ryan.Eng (login)
process_id:
0111873F
As shown in the following example, the match request affects only the next request.
as: match process_id; dump_pte
PTE at 8180E440 for Suzanne_Ryan.Eng (login)
process_id:
0111873F
as: dump_pte
PTE at 8180E440 for Suzanne_Ryan.Eng (login)
process_id:
0111873F
process_number:
1855
max_priority:
6
max_processes:
0
....
as:
2-4
VOS System Analysis Manual (R073)
Filtering Output
As shown in the following example, you must use single quotes if the match includes
spaces.
as:
match locker fp; dump_afte error_codes.text
locker fp:
81419620
as:
Filtering Output with Request Arguments
Many of the analyze_system requests have arguments such as -match, -long,
-brief, and -all, which enable you to filter a requests output.
As shown in the following example, the -match argument displays the same output as
the match request.
as:
dump_et -match term.17.12.4
All nonfree ETEs:
80F4C4A0
286 device_event_for_term.17.12.4
as:
match term.17.12.4; dump_et -all
80F4C4A0
286 device_event_for_term.17.12.4
As shown in the following example, the -brief argument displays a shorter form of
the output.
as: dump_lock -brief
lock name
--------Lock List Header
wired lock cow stomach
paged lock cow stomach
wired lock queue
paged lock queue
....
as: dump_lock -no_brief
Lock info at 80C11A20
name:
lock_wordp:
lock_state:
type:
flags:
spin_limit:
Lock info at 80C11B40
name:
lock_wordp:
lock_state:
type:
flags:
spin_limit:
....
address
-------
type
----
lock state
----------
80C11A20 single
80C11B40 single
80C11C60 single
80C11D80 single
80C11EA0 single
unlocked
unlocked
unlocked
unlocked
unlocked
num locks
--------103
2
31
28191
3408138
Lock List Header
800063C0 -> 8000x
unlocked
1 (single)
wired
0 (0.000 seconds)
wired lock cow stomach
800064C0 -> 8000x
unlocked
1 (single)
wired
forever
Using the analyze_system Command
2-5
Filtering Output
As shown in the following example, the -long argument displays a longer form of the
output.
as:
dump_et -match term.2.12.4 -long
All nonfree ETEs:
ETE at 80F4C4A0 for
wait_list:
lock:
flags:
array_slot_ptr:
event count:
last full count:
pended notify-1s:
status:
uid:
ref_cnt:
name_len:
ex_ete_ptr:
....
as:
device_event_for_term.2.12.4
8191D13C -> 8190FA60: PreLogin.System (pre-login)
8000
system
80C0FFF8
286 (0000011E)
286 (0000011E)
0 (00000000)
00000000
0.0000.00000000.00000000.0000.0000
(80-01-01 00:00:00 EDT)
2
29
00000001
As shown in the following example, the -all argument displays a longer form of the
output that includes the output from most (but not necessarily all) arguments.
as:
dump_et -all
All nonfree ETEs:
80C0FEA0
79
80C103C0
5745
80C10440
0
80C104C0
361
80C107A0
1028
80C10840
269083
....
network_notify_event
stopped_process_event
system_sleep_event
red_light_interrupt_event
page_wait_event
page_fault_event
Redirecting Output to a File
Issue the start_logging and stop_logging internal commands, or the
attach_default_output and detach_default_output internal commands, to
redirect output to a file.
When you issue the start_logging and stop_logging internal commands, the
analyze_system command also displays the output on your terminal screen. Output
also includes command input and output from other ports. The following is an example
of the use of the start_logging and stop_logging commands in the
analyze_system command. Note that the -no_reads argument of the
start_logging command prevents the command history from being recorded in the
2-6
VOS System Analysis Manual (R073)
Displaying Files
log file. The VOS display commands -no_header argument prevents the display
of the log-file path name and current date and time.
as: ..start_logging (home_dir)>who.log -no_reads
as: who -user
PROC
PTEP
USER NAME
*1855 8180E440 Suzanne_Ryan.Eng, on CPU30
as: ..stop_logging
as: ..display (home_dir)>who.log -no_header
as:
PROC
PTEP
USER NAME
*1855 8180E440 Suzanne_Ryan.Eng, on CPU30
as:
When you issue the attach_default_output internal command, the
analyze_system command does not display subsequent output or the as: prompt
on your terminal screen. Instead, it routes output to the file specified by the
attach_default_output command. You can restore normal operation and the as:
prompt by invoking the detach_default_output command. The following example
illustrates the use of the attach_default_output and detach_default_output
commands in the analyze_system command.
as: ..attach_default_output vos_evars
display_pm -external_vars_map
..detach_default_output
as:
Displaying Files
This section describes how to use the VOS internal command display, the
display_file request, and the dump_syserr request to display the contents of
files in the analyze_system command.
Displaying Files with the VOS display Command
Issue the VOS display internal command to display an entire file, or parts of a file,
matching a certain string or set of line numbers. The following example shows how to
create and display a file containing the VOS external variables map.
as: ..attach_default_output vos_evars
display_pm -external_vars_map
..detach_default_output
as: ..display vos_evars
%es#m24_user2>Eng>Joe_Smith>vos_evars
98-04-10 14:25:15 EDT
as:
External Variable Map:
Using the analyze_system Command
2-7
Displaying Files
Name
Sx
ACCESS_ANY_EXEC$ 1
ACCESS_INTERLOCK$
1
ACCESS_IO$
2
....
as:
Address
Length
80839C60 00000004
80839C64 00000004
8089C194 00000004
You can display part of a file by using a match string. Unless you specify the
-no_caseless argument, match strings are not lower- or upper-case sensitive. The
following example shows the result of caseless and case-sensitive matches. The
example also shows that you can suppress display of the file header information with
the -no_header argument.
as: ..display vos_evars -match MODULE_ID
%es#m24_user2>Eng>Joe_Smith>vos_evars 98-04-10 14:48:00 EDT
sys_info$module_id
as: ..display vos_evars -no_header -match MODULE_ID -no_caseless
as:
You can also specify that a certain number of lines, including the match line, should be
displayed. The following example displays a minimum of two lines.
as: ..display vos_evars -no_header -match module_ID -min_lines 2
sys_info$module_id
1 80839B44 00000002
as:
The following example shows that you can also determine the line numbers where
matches occur and specify a range of line numbers to be displayed.
as: ..display vos_evars -no_header -match module_id -line_numbers
2634 sys_info$module_id
as: ..display vos_evars -no_header -first_line 2634 -last_line 2637
sys_info$module_id
1 80839B44 00000002
sys_info$module_name
1 80839B50 00000022
as:
2-8
VOS System Analysis Manual (R073)
Displaying Files
Displaying Files with the display_file Request
Issue the display_file request to split the screen in order to display the contents of
a file in the top half of a screen and the request history and as: prompt on the bottom
half of the screen. The following example illustrates the use of the display_file
request.
1 as:
2 External Variable Map:
3
4 Name
Sx Address
Length
5 ACCESS_ANY_EXEC$ 1 80839C60 00000004
6 ACCESS_INTERLOCK$
7
1 80839C64 00000004
8 ACCESS_IO$
2 8089C194 00000004
9 ACCESS_KERNEL_EXEC$
10
1 80839C50 00000004
11 ACCESS_KERNEL_READ$
------------------------------------------------------------------Current process is 295, ptep 81BA2600, Joe_Smith.Eng
as: dump_syserr
0 active messages, 638 free.
Total of 64183 logged messages.
Total of 0 lost messages.
as: ..attach_default_output vos_evars
display_pm -external_vars_map
..detach_default_output
as: display_file vos_evars
as:
To scroll a file up half a screen at a time (in this case, 11 lines), issue the
display_file request again, as shown in the following example.
12
1 80839C48 00000004
13 ACCESS_KERNEL_WRITE$
14
1 80839C4C 00000004
15 ACCESS_USER_EXEC$
16
1 80839C5C 00000004
17 ACCESS_USER_READ$
18
1 80839C54 00000004
19 ACCESS_USER_WRITE$
20
1 80839C58 00000004
21 CMD_free_cb_ack_timeout
22
1 8082F210 00000004
-------------------------------------------------------------------
Using the analyze_system Command
2-9
Displaying Files
as:
dump_syserr
0 active messages, 638 free.
Total of 64183 logged messages.
Total of 0 lost messages.
as: ..attach_default_output vos_evars
display_pm -external_vars_map
..detach_default_output
as: display_file vos_evars
as: display_file
as:
To scroll to a specified line, specify the line number with the display_file -line
argument, as shown in the following example.
2634 sys_info$module_id
2635
1 80839B44 00000002
2636 sys_info$module_name
2637
1 80839B50 00000022
2638 sys_info$module_no
2639
1 80839B72 00000002
2640 sys_info$multiple_user_cpus
2641
2 808A82B0 00000002
2642 sys_info$n_kinsurance_pages
2643
1 8082320C 00000002
2644 sys_info$n_paged_stack_pages
------------------------------------------------------------------0 active messages, 638 free.
Total of 64183 logged messages.
Total of 0 lost messages.
as: ..attach_default_output vos_evars
display_pm -external_vars_map
..detach_default_output
as: display_file vos_evars
as: display_file
as: display_file -line 2634
as:
2-10
VOS System Analysis Manual (R073)
Displaying Files
To end the display of a file, specify the -off argument of the display_file
command, as shown in the following example.
display_pm -external_vars_map
..detach_default_output
as: display_file vos_evars
as: display_file
as: display_file 2634
display_file: Object not found. %sys#m2_user>Eng>Joe_Smith>2634
as: display_file -line 2634
display_file: Object not found. %sys#m2_user>Eng>Joe_Smith>2634
as:
display_file vos_evars
as: display_file -line 2634
as: display_file -off
as:
Displaying System Error Log Data
This request displays the contents of a buffer in kernel memory containing the most
recent system error messages. The contents of this buffer and the
syserr_log.(date) file are the same, except that the buffer may contain more
recent messages and may contain messages from the previous day or days (a
syserr_log.(date) file contains messages from only the current day). You can use
this request in dump mode to examine the messages that occurred just before a
system failure.
If you issue the dump_syserr request without any arguments, the request provides a
summary total of the different types of messages in the buffer, and a list of all active
messages; i.e., those messages that have not yet been retrieved by TheOverseer
process to be written to the syserr_log file. Usually, a running system has no active
messages.
as:
dump_syserr
0 active messages, 638 free.
Total of 64183 logged messages.
Total of 0 lost messages.
as:
To display the most recent messages in the buffer, specify the -last argument of the
dump_syserr command, as shown in the following example.
as:
dump_syserr -last 5
0 active messages, 673 free.
Total of 68366 logged messages.
Total of 0 lost messages.
Using the analyze_system Command
2-11
Displaying Files
Messages from free list:
15:51:48 Process 011104DE, Tcp_Install.Comm (mk:pink.obj), created.
15:51:51 Process 011104DA, Joe_Smith.Eng (login), terminated.
15:51:57 link 0100i 18
10982 01
0000000D 00000000 controller status
15:51:57 link 0100i 18
10982 01
00000011 00000000 controller status
15:51:58 scsi 0100r 04/11/07
0 02010180 0002030F Correctable Error
as:
To display the address of the messages in the buffer, specify the -long argument of
the dump_syserr command, as shown in the following example.
as:
dump_syserr -last 1 -long
0 active messages, 669 free.
Total of 68380 logged messages.
Total of 0 lost messages.
Messages from free list:
800521E0x -> 15:52:46 Process 011104DC, Tcp_Install.Communications
(mk:ostc
+p_client_task.obj), terminated.
as:
To display all messages in the buffer, specify the -all argument of the dump_syserr
command, as shown in the following example.
as:
dump_syserr -all
1 active messages, 668 free.
Total of 68396 logged messages.
Total of 0 lost messages.
Messages from free list:
15:30:13 Process 01110410, Tcp_Install.Communications (mk:tmr.obj),
+terminated.
15:30:14 Process 0111040D, Tcp_Install.Communications (mk:timers.obj),
+terminated.
15:30:14 Process 0111041B, Tcp_Install.Communications (mk:tcp.pm),
created.
15:30:14 Process 01110411, Tcp_Install.Communications
(mk:udp_usrreq.obj), +terminated.
15:30:29 link 0100i 18
10982 01
0000000D 00000000 controller status
15:30:29 link 0100i 18
10982 01
00000011 00000000 controller status
....
as:
2-12
VOS System Analysis Manual (R073)
Specifying Variable Names and Values
Specifying Variable Names and Values
You can use the variable request to define a maximum of 10 variables during an
analyze_system session. This section describes the rules for specifying variable
names and values.
Variable Names
Variable names have the following characteristics.
They are lower- and upper-case sensitive. For example, you can define the
variables DIGITS, Digits, and digits, and assign each variable a different
value.
They take precedence over external variable names used in a program module.
The following example shows that even though VOS assigns a value to the external
variable sys_info$module_id, you can use the variable request to specify
another value for that variable.
Note that if the value of an external variable is incorrect, commands that use the
variable will not work.
as: display sys_info$module_id 2
80839B44 0 0111
|..
as: variable sys_info$module_id 0101000
as: display sys_info$module_id 2
display: The specified page is not present in your address space.
00000101
as:
They cannot be reserved words (symbolic register names, etc.).
Keep in mind that analyze_system will treat any variable name of eight or fewer
characters consisting entirely of the characters 09 and af as a hexadecimal
value.
Do not create variable names that look like VOS symbols (e.g.,
sys_info$module_id, etc.). If your variables name is identical to a VOS symbol
name, the name resolution of analyze_system will find and use your variables
value instead of the VOS symbols value. (See Table 3-1 for examples of name
types to avoid.)
If newly specified with the variable request, they have a default value of 0.
They cannot be deleted, and they remain until you exit the analyze_system
session. Of course, you can change the assigned values of existing variable names
during a session.
Using the analyze_system Command
2-13
Specifying Variable Names and Values
Variable Values
Variable values have the following characteristics.
They must be hexadecimal integers. You cannot specify a variable value using
decimal notation such as 3.14159. You can assign a variable an integer or address
value, or the value of another variable, as shown in the following example.
as:
as:
as:
variable digits 12345678
variable mod sys_info$module_id
They must range from 0 to FFFFFFFF. The request rejects large values such as
123456789 because they cannot be stored as a hexadecimal value in the space
allotted.
They are displayed with the variable or display request. To display the values
assigned to all variables, you can issue the variable request with no arguments,
as shown in the following example.
as: variable
digits 12345678
mod 80839B44
as:
To display the value of that variable, you can issue the variable request with a
variable name, as shown in the following example.
as:
mod
as:
variable mod
80839B44
To display the value of a variable when it is an address, you can also issue the
display request, as shown in the following example. The display request
enables you to specify the number of bytes to display in an address. By default, the
request displays four bytes in an address. For more information about the display
request, see Chapter 3 or the description of the display request in Chapter 8.
as: display
80839B44 0
as: display
80839B44 0
as: display
80839B44 0
as: display
80839B44 0
as:
2-14
mod
01110000
mod 3
011100
mod 2
0111
mod 1
01
VOS System Analysis Manual (R073)
|....
|...
|..
|.
Specifying Variable Names and Values
They are converted to twos complement form when negative numbers. A twos
complement number is formed from a given binary value by changing all 1s to 0s
and all 0s to 1s and then adding 1, as shown in the following example.
as: variable minus_one -1
as: variable minus_sixteen -10
as: variable minus_one; variable minus_sixteen
minus_one FFFFFFFF
minus_sixteen FFFFFFF0
as: variable minus_ten FFFFFFF6
as: variable minus_ten
minus_ten FFFFFFF6
as: variable one -FFFFFFFF
as: variable one
one 00000001
as:
Using the analyze_system Command
2-15
Specifying Variable Names and Values
2-16
VOS System Analysis Manual (R073)
Chapter 3
Specifying Address Formats
for Request Arguments
3-
Many requests, such as display, dump_area, dump_et, dump_pte, evaluate,
frame, fstack, set_word, trace, and where, require that you specify a memory
address. In addition, the disk block mode requests, such as use_block, require that
you specify a hexadecimal disk block address. This chapter describes the following
addressing methods: expressions, external variable, hexadecimal number, indirect,
last display relative, object module name, object module static relative, object module
symbol table relative, stack relative, and variable. Some additional information about
using hexadecimal addresses is also provided. This chapter contains the following
sections.
Requests That Take Default Address Values
Using Hexadecimal Address Formats
Using Symbolic Address Formats
Indirect Addressing
Relative Addressing Used by the display Request
Displaying Stack Data
Table 3-1 summarizes the acceptable address formats for arguments that require an
address.
NOTE
An address value that contains spaces must be enclosed
in apostrophes.
Table 3-1. Valid Address Formats (Page 1 of 2)
Address Format
Description
Example
Expression
Hexadecimal addition (+) or subtraction (-) in
combination with any of the formats listed in
this table.
10156+5a
188A34+19-F
(addr$)+4
Specifying Address Formats for Request Arguments
3-1
Specifying Address Formats for Request Arguments
Table 3-1. Valid Address Formats (Page 2 of 2)
Address Format
Description
Example
External variable
Any declared external variable name (can be
found in a program modules active external
variable map).
sys_info$module_id
Hexadecimal
number
Simplest format. All other formats evaluate to
this format.
80839B44
Indirect
An indirect address is a byte pointer to an
address. It is indicated by enclosing
parentheses for each level of indirection. An
indirect address must be enclosed in
apostrophes.
(addr)
(Location addr contains a
byte pointer to address.)
After computing an address from the value
given, a request reads a long word from the
address to use as the address value.
Last display relative
The asterisk (*) represents the value of the
last address given (the default address).
*+100
(last address plus 100)
Object module code
relative (without the
.obj suffix)
Without line number
make_report
With line number (@ followed by the
number)
make_report@121
Object module static
relative
Or internal static reference. Indicated by the
&i prefix followed by the object module
name.
&is$$listener+66
Object module
symbol table relative
Indicated by the &t prefix followed by the
object module name.
&tmake_report
Stack relative
Indicated by the &s prefix and extended on
the left with negative sign bits. Calculates the
offset from the stack frame base specified in
a previous frame request. For more
information, see the description of the frame
request.
&se6
Variable
Any variable defined with the variable
request.
variable addr
80839B44
3-2
VOS System Analysis Manual (R073)
Requests That Take Default Address Values
OS displays executable code in include files using the construct
file_num-line_num. However, because the - indicates subtraction in
analyze_system syntax, you should not use it to locate executable code
embedded in include files. Instead, use the analyze_system construct
file_num.line_num. For example, to locate line 47 of include file 6 of the
program make_report, you would issue the request as follows.
where [email protected]
Requests That Take Default Address Values
The following documented requests set the default address, sometimes represented in
a display form as an asterisk (*). For more information, see the Last display relative
row in Table 3-1.
check_area
display
dump_area
dump_porte
dump_pte
scan_area
set_byte
set_longword
set_word
Using Hexadecimal Address Formats
A hexadecimal (base 16) address can consist of the digits 0 through 9 and the letters
A through F (or a through f).
You can use the (decimal) command function to convert hexadecimal numbers to
decimal and the (hexadecimal) command function to convert decimal numbers to
hexadecimal. The following examples illustrate.
as: ..display_line (decimal 100aX)
4106
as: ..display_line (hexadecimal 4106)
100Ax
as:
Specifying Address Formats for Request Arguments
3-3
Using Symbolic Address Formats
One page of memory contains 4096 or 1000x bytes. To quickly estimate the number of
pages required by a given hexadecimal number of bytes, drop the last three digits in
the hexadecimal number and add one to the fourth digit (unless the last three digits are
all zeros). For example, given 1234x bytes, two (2x) pages of memory are needed.
Given 9876x bytes, 10 (ax) pages of memory are needed. Given 23567x bytes, 36
(24x) pages of memory are needed.
One megabyte of memory contains 1,048,576 or 100000x bytes. Eight megabytes of
memory contains 800000x bytes. A memory space of 72 megabytes in size is
equivalent to 4800000x bytes. To quickly estimate the number of megabytes required
by a given hexadecimal number of bytes, round up the last five digits in the
hexadecimal number. For example, given 123456x bytes, two megabytes of memory
are needed.
You can evaluate hexadecimal expressions (perform hexadecimal arithmetic) using
the evaluate request. Expressions can contain addition (+) or subtraction (-)
operations. If spaces exist in an expression, the expression must be enclosed in single
quotes. Expressions can include the (hexadecimal), (decimal), and (calc) and
other numerical manipulation command functions. The following examples show the
different expressions that you can use in the evaluate request.
as: evaluate
00001000
as: evaluate
00001000
as: evaluate
0000100A
as: evaluate
FFFFFFF6
as: evaluate
00000018
as: evaluate
00000018
as:
100a-A
100a - a
1000+a
-a
8+8+8
(hexadecimal 24)
Using Symbolic Address Formats
Symbolic address formats substitute a name for a hexadecimal address. VOS
recognizes the symbolic name because it is not a hexadecimal number, and it converts
symbolic names to addresses in the following order.
1. star names indicated by an asterisk (*)
2. variable names
3. stack relative addresses indicated by &s
3-4
VOS System Analysis Manual (R073)
Using Symbolic Address Formats
4. program related addressesIf in module or dump mode, VOS checks for the
following addresses first in the kernel, next in the kernel-loadable programs, and
then in user or IOP programs.
a. object module static relative addresses indicated by &i
b. symbol table relative addresses indicated by &t
c. object module map name
d. external variable name
To find the appropriate symbolic names, you can do any of the following:
Display the optional bind map for the program module using a text editor. For more
information about bind maps, see the description of the bind command in the VOS
Commands Reference Manual (R098), VOS PL/I Users Guide (R145), or VOS
Standard C Users Guide (R364).
Display the object module map for a program module using the display_pm
request or the display_program_module command. For more information
about the display_program_module command, see the VOS Commands
Reference Manual (R098).
Display the source file or the optional binder control file using a text editor. For more
information about creating binder control files, see the description of the bind
command in the VOS Commands Reference Manual (R098).
Object Module Names
To display a list of object module names used by a program module, use the
-module_map argument of the display_program_module external command, or
the display_pm request. You can use the display_program_module command to
display the object module map for a running or non-running process. For more
information about this command, see the VOS Commands Reference Manual (R098).
You can use the display_pm request only with a process that is executing a program
module. In the following example, process 457 is running a program module called
storage.pm with three associated object modules, storage.obj, display.obj,
and sum.obj. After the process request is used to select process 457, the
display_pm request displays the object module map (-module_map) for the user
program module (the -program_module argument is a cycle field that can take the
values user_program or kernel) running on this process. The object module map
contains among other things the starting address and length of the code, symbol table,
and static regions for each object module in the program module.
as: match Joe; who
457 04CA9440 Joe_Smith.Eng
* 527 04AADC60 Joe_Smith.Eng, on CPU2
as: process 457
Using nonrunning process.
Current process is 457, ptep 04CA9440, Joe_Smith.Eng
Specifying Address Formats for Request Arguments
3-5
Using Symbolic Address Formats
as:
display_pm -program_module user_program -module_map
Module Map:
Name
Scn
Code
Start
Length
Symtab
Start
Length
storage
3 00E00000 0000004A
00E06000 000000A0
3 00E00050 0000002E
00E060A0 00000090
3 00E00080 0000011E
00E06130 000000A0
sum
display
Date Compiled
Static
UERW, SAP
Start
Length
95-07-05 20:35:13
00E04000 00000026
95-07-05 20:35:43
00E04028 00000016
95-07-05 20:35:28
00E04040 0000003E
....
as:
You can also use the display_pm request to display the object module map for one
object module such as storage.obj.
as:
display_pm -program_module user_program storage
Module Map:
Name
Dir Index
Code
Symtab
Start
Length
Start
Length
1
3 00E00000 0000004A 00E06000 000000A0
Scn
storage
Date Compiled
Static
UERW, SAP
Start
Length
95-07-05 20:35:13
00E04000 00000026
Module Map Dates:
Name
storage
as:
DTM
95-07-05 20:35:19
DTCP
95-07-05 20:35:13
If you do not specify the value of the -program_module argument as
user_program, the display_pm request assumes you wish to display an object
module map for an object module in the kernel. If no object module of the specified
name exists in the kernel, the request finds no entry map. On the other hand, if a user
program module and vos.pm both have an object module with the same name, the
request displays the object module map for the object module in the kernel.
as: display_pm storage
display_pm: No map entry found for storage.
as: display_pm display
Module Map:
3-6
VOS System Analysis Manual (R073)
Using Symbolic Address Formats
Name
Dir Index
Code
Symtab
Start
Length
Start
Length
3
3 0046CC28 00001642 006F50D4 00000910
Scn
display
Date Compiled
Static
UERW, SAP
Start
Length
93-09-23 18:03:35
00500A84 00000232
Module Map Dates:
Name
display
DTM
93-09-23 18:04:45
DTCP
93-09-23 18:03:35
Earlier, it was noted that the object module map displays the start address and length
of the code, symbol table, and static regions in each object module. The following
example shows how you can also use the evaluate request to find the start of the
code, symbol table (&t), and static regions (&i) for a specified object module.
as: evaluate storage; evaluate &tstorage; evaluate &istorage
00E00000
00E06000
00E04000
as: evaluate display; evaluate &tdisplay; evaluate &idisplay
0046CC28
006F50D4
00500A84
as:
Object Module Code Relative Addressing
You can use a compiler listing along with the display and disassemble requests to
examine the instructions and values in an executing program. This section shows a
source code listing and partial assembly-language listing for storage.pm, followed by
examples of object module code relative addressing for the same sections of assembly
code.
The following example shows part of the storage.list file, which was created when
storage.pl1 was compiled with -full. The file contains a source code listing
followed by an assembly language listing.
as:
..display storage.list
%s1#m3_user>Stratus>John_Doe>storage.list
98-09-24 16:20:44 edt
SOURCE FILE: %s1#m3_user>Stratus>John_Doe>storage.pl1
COMPILED ON: 98-09-24 AT: 16:18 by: PL/I Release 14.0.1
OPTIONS:
-optimization_level 3, -full, -processor pa8000,
-minimal_stack_frames
1
2
3
4
/* Program used to demonstrate types of data storage */
main:
proc;
Specifying Address Formats for Request Arguments
3-7
Using Symbolic Address Formats
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
%replace constant_one
by 1;
dcl int_static_two
dcl stack_three
dcl result
bin(15) init(2) static;
bin(15);
bin(15) static external shared;
dcl sum
dcl display
entry(bin(15), bin(15), bin(15));
entry();
stack_three = 3;
call sum(constant_one, int_static_two, stack_three);
call display;
end main;
EXTERNAL ENTRY POINTS
NAME
CLASS
main
constant
SIZE
LOC
ATTRIBUTES
entry external
PROCEDURE main ON LINE 3
NAME
display
int_static_two
result
stack_three
sum
CLASS
constant
static
SIZE
static
2
automatic
2
constant
LOC
ATTRIBUTES
000000
entry external
000004
fixed bin(15,0) internal
initial
000000
fixed bin(15,0)
external
000000
fixed bin(15,0)
000000
entry external
NO PROGRAMMED OPERATORS USED IN THIS COMPILATION.
CODE GENERATED FOR PROCESSOR: pa8000
STACK FRAME SIZES:
(fixed length portion only)
NAME
LINE
main
STACK SIZE
64
ASSEMBLY LANGUAGE LISTING
LINE 3
main:
3-8
VOS System Analysis Manual (R073)
Using Symbolic Address Formats
proc;
00000060: 6BC23FD9
00000064 37DE0080
stw
ldo
%r2,-20(%sp)
64(%sp),%sp
LINE 16
call sum(constant_one, int_static_two, stack_three);
LINE 15
stack_three = 3;
00000068 2B600000 addil
0000006C B4150006 addi
00000070 34330000 ldo
00000074 B4140002 addi
00000078 67D43F85 sth
0000007C 36790009 ldo
00000080 37DA3F85 ldo
00000084 37D83F81 ldo
00000088 E800A048 b,l
0000008C 67D53F81 sth
L%0,%dp,%r1
#16
3,%r0,%r21
#15
0(%r1),%r19
#16
1,%r0,%r20
%r20,-62(%sp)
.t109
-8188(%r19),%r25
-62(%sp),%r26
-64(%sp),%r24
0x000000B4,%r2
sum
%r21,-64(%sp)
#15
stack_three
LINE 17
call display;
00000090 E800A020
00000094 34000000
b,l
nop
0x000000A8,%r2
display
LINE 19
end main;
00000098 4BC23F59
0000009C E840D000
000000A0 37DE3F81
000000A4 E81F1FF7
ldw
bve
ldo
b,n
000000A8: E8200000
000000AC 28200000
000000B0: E020E002
b,l
addil
be,n
STUB(S) FROM LINE 17
0x000000B0,%r1
.l112
L%0,%r1,%r1
display
0(%sr7,%r1)
display
000000B4: E8200000
000000B8 28200000
000000BC: E020E002
b,l
addil
be,n
STUB(S) FROM LINE 16
0x000000BC,%r1
.l113
L%0,%r1,%r1
sum
0(%sr7,%r1)
sum
-84(%sp),%r2
(%r2)
-64(%sp),%sp
0x000000A4
LINE 19
end main;
You can use code relative addressing to examine the instructions in an object module
that correspond to a source-code line number. When you use code relative addressing,
specify the name of an object module followed by a commercial at sign (@) and a
Specifying Address Formats for Request Arguments
3-9
Using Symbolic Address Formats
source-code line number. The following examples show code relative addressing used
with the display, disassemble, and where requests.
NOTE
As shown in the where request examples, it may require
some trial and error to determine which source code line
number contains associated assembly language
instructions.
as: display storage@1
Using line 3
00002060 0 6BC23FD9
as: where storage@1
Using line 3
00002060 at storage+60, line
as: where storage@3
00002060 at storage+60, line
as: where storage@4
Using line 3
00002060 at storage+60, line
as: where storage@17
00002090 at storage+90, line
as: display storage+60
00002060 0 6BC23FD9
as: display storage+64
00002064 0 37DE0080
as: disassemble storage+60
/* Line 3
00002060 6BC23FD9 stw
00002064 37DE0080 ldo
as: display &istorage
00003000 0 00000000
as: display &istorage+4
00003004 0 00020000
as: display &istorage+4 2
00003004 0 0002
3-10
VOS System Analysis Manual (R073)
|k.?.
|k.?.
|7...
|....
|....
|..
3
3
3
17
%r2,-20(%sp)
64(%sp),%sp
Indirect Addressing
As shown in the following examples, you can also use byte offsets from the beginning
of an object modules code region to disassemble an object module. However, this
method is much less intuitive than relative addressing using line numbers.
as:
display storage
00E00000 0 4E4F0000
as: display storage+4
00E00004 0 49ED8018
as: disassemble storage+4
/* Line 3
00E00004 49ED 8018 lea
00E00008 4E56 FFEC link.w
00E0000C 48EE B000 movem.l
00E00010 FFF0
as:
|NO..
|I...
-32744(a5),a4
a6,=-20
a4;a5;a7,-16(a6)
Internal Static Relative Addressing
To display the contents of the static region in an executing object module, you can use
a compiler listing internal stack relative addressing. As shown in the following
examples, precede the name of the object module with the prefix &i (for internal static)
and then use byte offsets from the start of the static region to display its contents.
as: display
00E04000 0
as: display
00E04004 0
as: display
00E04004 0
as:
&istorage
00E00000
&istorage+4
00020000
&istorage+4 2
0002
|....
|....
|..
Indirect Addressing
An indirect address is an address that is derived from another address. You can specify
an indirect address for any argument that requires an address. Use parentheses to
indicate each level of indirection and enclose the outermost set of parentheses in single
quotes to prevent the command parser from interpreting the parenthetical expression
as a command function.
The following example has two parts. The first part shows how an address is derived
from a process number and from the external variable perm_process_datap$. The
process number is multiplied by eight and converted to hexadecimal. This hexadecimal
value is added to the value of the external variable perm_process_datap$. The
display request then displays 16 bytes of data beginning at this address. The second
part of the example shows how the same address is derived using indirect addressing.
Specifying Address Formats for Request Arguments
3-11
Relative Addressing Used by the display Request
Note that the external variable is enclosed in parentheses and is the first level of
indirection. Omitting or misplacing parentheses results in erroneous output.
as: match process_number;dump_pte
PTE at 4109B8C0 for Joe_Smith.Eng (login)
process_number: 770
as: ..display_line (hexadecimal (calc 8 * 770))
1810x
as: display perm_process_datap$
002F10C0 0 0030C760
as: display 0030C760+1810
0030DF70 0 41350030
as: display 41350030 16
41350030 0 01145302 000B4461 76655F4D 61727469
as: display '((perm_process_datap$)+1810)' 16
41350030 0 01145302 000B4461 76655F4D 61727469
as:
|.0.`
|A5.0
|..S...Joe_Smith.|
|..S...Joe_Smith.|
Relative Addressing Used by the display Request
When using the display request, you can specify addresses that are relative to the
last address displayed with the display request or specified with another address
(this is referred to as last display relative addressing). You can create relative
addresses with the last address (*) placeholder, the addition (+) and subtraction (-)
operators, external variable names, and symbolic variable names created with the
variable request.
As shown in the following example, if you issue the display request more than once,
the request displays the same address as was previously displayed. If you issue the
display request with the last address (*) placeholder, the request also displays the
same address as was previously displayed. You can add or subtract any hexadecimal
value from the last display relative address, and, if the resulting address is within the
user address space, the request displays its contents.
as: display
80F78960 0
as: display
80F78960 0
as: display
80F78960 0
as: display
80F78970 0
as:
00145374
|..St
00145374
*
00145374
*+10
636B2028
|..St
|..St
|ck (
Note that the last display relative address can also be relative to the last address you
specified for another request; the display request does not know about addresses in
the output of earlier requests. For example, if you display the sys_info$module_id
address, dump the process table entry, and then issue the display request, the
request displays the sys_info$module_id address, because it is the last specified
3-12
VOS System Analysis Manual (R073)
Displaying Stack Data
address. However, if you specify a process table entry address for the dump_pte
request and then issue the display request, the request displays the specified
process table entry.
as: display sys_info$module_id
80839B44 0 01110000
as: dump_pte
PTE at 81E3AA80 for Joe_Smith.Eng (login)
process_id:
0111C5D6
...
as: display
80839B44 0 01110000
as: dump_pte 81E3AA80
PTE at 81E3AA80 for Joe_Smith.Eng (login)
process_id:
0111C5D6
...
as: display
81E3AA80 0 0111C5D6
as:
|....
|....
|....
Displaying Stack Data
The trace, stack, and fstack requests dump the contents of a stack belonging to
the analyzed process. A stack is an area of user virtual address space consisting of an
ordered series of stack frames associated with the execution of a program. A stack
frame is a portion of a stack associated with a procedure or function call. Multitasking
processes have a stack associated with each task. These requests are useful for
analyzing running processes.
The trace and stack requests dump the stack backwards; that is, from the latest
frame to the earliest frame. The output of the trace request is similar to the output of
the stack -brief request. Before issuing any stack-related request, you must
specify a process that is running a program that you want to analyze. The following is
an example of the output of the trace request for storage.pm.
NOTE
In module mode (versus dump mode), a stack trace may
not be complete or accurate.
Specifying Address Formats for Request Arguments
3-13
Displaying Stack Data
as: process -process_name storage
Using nonrunning process.
Current process is 1235, ptep C5223A80, Dan_Danz.Stratus (storage)
as: trace
switch_process
sp: 7FFF5340 pc: C0012080 (hppa_switch_process+80)
give_up_cpu
sp: 7FFF5240 pc: C01F1188 (give_up_cpu_i+1488,
line 1244)
s$$k_sleep_real
sp: 7FFF5140 pc: C01EDC78 (scheduling+7B8, line
204)
wire_and_forward
sp: 7FFF50C0 pc: C00020D8 (mercury_waf_and_sis+D8)
On-units at 7FFF5040
s$k_sleep_trap
sp: 7FFEC140 pc: C03F9E70 (s$k_sleep+84
(kernel_trap_pa+20
+A70))
kernel_trap
sp: 7FFEC100 pc: C03D890C
(hppa_kernel_trap_support+8C)
On-units at 7FFEC040
s$k_sleep
sp: 00007280 pc: C03F9E00 (s$k_sleep+14
(kernel_trap_pa+20
+A00))
s$sleep
sp: 00007240 pc: C0329638 (task_control+3938,
line 1124)
s$sleep_glue
sp: 00007140 pc: 00002304 (s$paged_glue+44)
display
sp: 00007140 pc: 00002270 (sum+1B0, line 41)
main
sp: 000070C0 pc: 00002090 (storage+90, line 17)
start_user_program
sp: 00007080 pc: C043B8A4
(start_user_program_pa+1E4)
On-units at C043B7E0
Trace complete.
The storage.pm program module consists of three routines: main, sum, and
display. The object module storage.obj contains main. The others are in the
object module sum.obj. At the time of the trace, display has called s$sleep. The
sum routine had already executed and thus does not appear in the trace.
You can obtain additional information about a stack, such as the frame size and
number of arguments passed to a subroutine, by issuing the stack request. By
default, stack display starts with the latest frame, the same as the trace request. If
you specify the address of a stack frame (such as the display routine frame), the
request displays the contents of the stack from that frame back through calling frames
to the beginning of execution. In this case, it is also necessary to provide the program
counter (pc) value associated with the stack frame address.
3-14
VOS System Analysis Manual (R073)
Displaying Stack Data
as: stack 7140
stack: You must specify a pc if specifying a stack address.
as: stack 7140 -pc 2270
display
sp: 00007140 pc: 00002270 (sum+1B0, line 41)
main
sp: 000070C0 pc: 00002090 (storage+90, line 17)
start_user_program
sp: 00007080 pc: C043B8A4
(start_user_program_pa+1E4)
Number of args is unknown.
On-units at C043B7E0
Trace complete.
In contrast to the stack and trace requests, the fstack request dumps the stack
forward, oldest frame first. You must specify a value for the starting frame address.
The fstack request might produce an obsolete view of the stack because it uses a
nondeterministic algorithm for finding possible stack frames. This is evident in the
following example: the frames beyond s$sleep_glue are not part of the current stack
because s$sleep_glue trapped into the kernel and switched stacks. Anything
beyond it is left over from previous use of the memory locations.
as: fstack 7080
start_user_program
sp: 00007080 pc: C043B8A4
(start_user_program_pa+1E4)
main
sp: 000070C0 pc: 00002090 (storage+90, line 17)
display
sp: 00007140 pc: 00002270 (sum+1B0, line 41)
s$sleep_glue
sp: 00007140 pc: 00002304 (s$paged_glue+44)
display
sp: 00007180 pc: 0000225C (sum+19C, line 39)
s$write_glue
sp: 00007180 pc: 0000235C (s$paged_glue+9C)
s$write
sp: 00007200 pc: C03D0158 (io_routines+1658, line
1003)
s$$sleep
sp: 00007240 pc: C0329638 (task_control+3938,
line 1124)cv_fixbin_to_char_pad sp: 00007280 pc: FFF904F8
(cv_fixbin_to_char_pop+138, line 101)
cv_fixbin_to_char
sp: 00007300 pc: FFF905E0
(cv_fixbin_to_char_pop+220, line 197)
s$seq_write
sp: 00007380 pc: C03C457C (iotv+863C, line 2983)
check_io_user$no_icss sp: 00007400 pc: C03C5334 (iotv+93F4, line 3425)
fast_seq_write_file
sp: 00007480 pc: C039FFD0 (fast_file_io+1C50,
line 998)
put_size
sp: 000074C0 pc: C03A14A0 (fast_file_io+3120,
line 1866)
copy_data
sp: 00007500 pc: C03A0594 (fast_file_io+2214,
line 1250)
copy_data
sp: 00007540 pc: C03A0594 (fast_file_io+2214,
line 1250)
Could not find any more stack frames.
as:
Specifying Address Formats for Request Arguments
3-15
Displaying Stack Data
Stack Relative Addressing
You can use the display and frame requests to display the contents of the stack. If
you use just the display request, you can specify a byte offset from the beginning of
a stack frame. For example, if the stack frame for the main routine begins at
04723F30, you can examine the contents of the stack frame 18 bytes below that
address (-18 = ffffffeex).
as: display 04723F30+ffffffee 2
04723F1E 0 0003
as:
|..
If you first issue the frame request, you can use stack relative notation (&s) with the
display request to specify a byte offset from the beginning of a stack frame. For
example, if the stack frame for the main routine begins at 04723F30, you can examine
the contents of the stack frame18 bytes below that address:
as: display 04723F30
as: display &see
047 2FIE 0 00031234
3-16
VOS System Analysis Manual (R073)
Chapter 4
Using the Modes of Operation
4-
This chapter describes how to select and use the modes of the analyze_system
command. The modes allow you to use different requests. This chapter contains the
following sections.
Selecting a Mode
Using Communications Controller Dump Mode
Using Disk Block Mode
Using Dump Mode
Using IOA and IOP Modes
Using Module Mode
Using Partition Mode
Using Program Module (File) Mode
Undefined Mode
By default, when you invoke the analyze_system command, it is in module mode.
Also, by default, analyze_system uses the current module.
Using the Modes of Operation
4-1
Selecting a Mode
Selecting a Mode
Table 4-1 lists the modes of analyze_system in alphabetical order, the requests that
you can use to prepare to select a mode or to select another object within a mode, and
the mode selection requests. The preparation requests list information that you can use
to change mode with a subsequent mode selection request.
.
Table 4-1. Preparing and Selecting Subsystem Modes (Page 1 of 2)
Mode
Purpose
Preparation Request
Mode Selection Request
Communications
controller dump
To analyze a static
dump of the memory in
a communications
controller.
list_comm_dumps
use_comm_dump
dump_number
Disk block
To analyze any
4096-byte block on a
disk.
match disk_addr;
dump_afte
open_file
use_block
block_number -disk
disk
Dump
To analyze a static
dump of VOS kernel
and user space.
list_dumps
use_dump dump_number
IOA firmware
To analyze live firmware
running on an IOA.
list_boards
-board_type iop
use_iop iop_slot
-ioa
IOA dump
To analyze a static
dump of IOA memory.
list_dumps or
list_iop_dumps
use_dump dump_number
or
use_iop_dump
dump_number and
use_iop -iop_no
iop_number
-ioa ioa_slot
IOP firmware
To analyze live firmware
running on an IOP.
list_boards
-board_type iop
use_iop ioa_slot
IOP dump
To analyze a static
dump of IOP memory.
list_dumps or
list_iop_dumps
use_dump dump_number
or
use_iop_dump
dump_number and
use_iop -iop_no
iop_number
Module
To analyze the live
contents of VOS kernel
and user space.
..list_modules or
..list_systems
-brief
analyze_system
-module module_name
or use_module
module_name
4-2
VOS System Analysis Manual (R073)
Using Communications Controller Dump Mode
Table 4-1. Preparing and Selecting Subsystem Modes (Page 2 of 2)
Mode
Purpose
Preparation Request
Mode Selection Request
Partition
To analyze the VOS
program module in a
particular boot partition.
dump_label
use_partition
partition_number
Program module
(file)
To analyze a VOS
program module.
..list
>pathname>*.pm
use_file pathname
Undefined
To quickly display the
as: prompt and enable
you to enter any other
mode.
N/A
analyze_system
-module
Using Communications Controller Dump Mode
Use communications controller dump mode to display the contents of communications
controllers. This mode applies only to C-series IOAs. To display a list of the
communications controller dumps on a module, issue the list_comm_dumps request.
You can then use the dump number of the appropriate dump to issue the
use_comm_dump request and enter communications controller dump mode. When the
analyze_system command is in communications controller dump mode, you can
issue requests such as the status request to determine the nature and cause of the
dump.
Use the delete_comm_dump request to delete a selected communications controller
dump image. Do not delete a dump until you or the CAC have resolved the problem
that caused the dump.
To exit communications controller dump mode, select another mode. For example, you
can select module mode by issuing the use_module request.
Using Disk Block Mode
Use the disk block mode to display a disk block. You can also use this mode to copy a
disk block from the backup partition. This section describes how to use the use_block
request to display the contents of a file or index.
Displaying the Contents of a File
The following example uses a relative file named ex_file. As shown in the output of
the list internal command, this file has been allocated 11 records that are 4096 bytes
long. As shown in the output of the display internal command, data is stored in only
the first and second records. To see the contents of a file as it is stored on disk, you
can issue the dump_file internal command. This same information can be displayed
Using the Modes of Operation
4-3
Using Disk Block Mode
by issuing the dump_afte, use_block, and display requests. The dump_afte
request displays the disk name and disk block addresses for the specified file. Before
issuing the dump_afte request, make sure some application has opened the specified
file. Using the disk name and disk address information supplied by this request, you
can then display the file contents of disk blocks by using the use_block and display
requests. When you are in block mode, your address space is the disk block. The
address space starts at 0 and ends at 4095 bytes. Therefore, the start_address for
the display request is always relative to the beginning of the block specified by the
use_block request.
NOTE
The equal sign (=) that appears in the sample output of
the dump_file command can appear in the output of
many requests. It indicates that the data between two
addresses is identical (in the following example, the data
is FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF), and
therefore is not listed.
as:
..list ex_file -full
Files: 1, Blocks: 11
w
11 rel-4096
95-07-06 13:16:16
ex_file
as: ..display ex_file -no_header
abcde
fghij
as: ..dump_file ex_file
%sys#m2_user>Eng>Joe_Smith>asm_test_code>ex_file
Block number
000
010
FF0
000
010
FF0
4-4
00056162 636465FF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
=
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
Block number
95-07-06 13:12:39
|..abcde.........|
|................|
|................|
FFFF0005 66676869 6AFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
=
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
VOS System Analysis Manual (R073)
|....fghij.......|
|................|
|................|
Using Disk Block Mode
as: dump_afte ex_file
AFTE at 04A4CFE0 for: %sys#m2_user>Eng>Joe_Smith>asm_test_code>ex_file
catep:
04A87400
CATE:
aftep:
04A4CFE0
disk_addr(-1):
FFFFFFFF
disk_addr(0):
00008F2B
disk_addr(1):
00008F2C
disk_addr(2):
FFFFFFFF
....
as: use_block 00008F2B -disk #m2_user; display 0 4096
00000000 000 00056162 636465FF FFFFFFFF FFFFFFFF |..abcde.........|
00000010 010 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
=
00000FF0 FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
as: use_block 00008F2C -disk #m2_user; display 0 4096
00000000 000 FFFF0005 66676869 6AFFFFFF FFFFFFFF |....fghij.......|
00000010 010 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
=
00000FF0 FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|
as:
Displaying the Contents of an Index
The following example uses a sequential file called authors that has an embedded
4-byte index called given_name with an ASCII collation code. As shown in the output
of the display internal command, the records are stored in the file alphabetically by
last name, but the index lists the records in the file alphabetically by first name.
To see the contents of a file as it is stored on disk, you can issue the dump_file
internal command and specify the name of the index. This same information can be
displayed by issuing the dump_axte, use_block, and display requests. The
dump_axte request displays the disk name and disk block addresses for the specified
file and index (note that the index blocks are listed last).
Before issuing the dump_axte request, make sure your application has opened the
specified file. Using the disk name and disk address information supplied by this
request, you can then display the file contents of disk blocks using the use_block and
display requests. Note that the start_address for the display request is always
relative to the beginning of the block specified by the use_block request.
as: ..display authors -no_header
Jane
Austen
Emily
Bronte
William Faulkner
Ernest
Hemingway
as: ..display authors -no_header -index given_name
Emily
Bronte
Ernest
Hemingway
Using the Modes of Operation
4-5
Using Disk Block Mode
Jane
Austen
William Faulkner
as: ..dump_file authors
-index given_name
%sys#m2_user>Eng>Joe_Smith>authors
....
Block number
2
000
010
020
030
FE0
FF0
05011A00
00040FCF
0FDE0000
FFFFFFFF
=
FFFFFF04
696C046A
FFFFFFFF
0FCF0000
00000FD4
FFFFFFFF
FFFFFFFF
003E0FD9
00000028
FFFFFFFF
95-05-03 10:49:28 EDT
FFFFFFFF
00000014
FFFFFFFF
FFFFFFFF
|................|
|.........>......|
|...........(....|
|................|
6561726E 0477696C 6C04656D
616E6508 00000000 00000000
|....erne.will.em|
|il.jane.........|
as: use_module
VOS Release 12.1, analyze_system Release 12.1
as: dump_axte authors given_name
AXTE at 04C24340 for:
%sys#m2_user>Eng>Joe_Smith>asm_test_code>given_name
catep:
04D903A0
CATE:
aftep:
04C24340
disk_addr(-1):
FFFFFFFF
disk_addr(0):
0000742E
disk_addr(1):
000065C0
....
as: use_block 65C0 -disk #m2_user; display 0 4096
00000000 000 05011A00 FFFFFFFF FFFFFFFF FFFFFFFF
00000010 010 00040FCF 0FCF0000 003E0FD9 00000014
00000020 020 0FDE0000 00000FD4 00000028 FFFFFFFF
00000030 030 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
=
00000FE0 FE0 FFFFFF04 6561726E 0477696C 6C04656D
00000FF0 FF0 696C046A 616E6508 00000000 00000000
as:
4-6
VOS System Analysis Manual (R073)
|................|
|.........>......|
|...........(....|
|................|
|....erne.will.em|
|il.jane.........|
Using Dump Mode
Once analyze_system is in disk block mode, you can issue the
dump_index_block request to list the key names and byte locations in the index
block. For example:
as:
dump_index_block 0
Version:
Level Number:
Dup Block:
....
Keys:
earn
emil
jane
will
5
1
false
62
20
0
40
as:
Using Dump Mode
Use dump mode to examine a VOS dump image. A dump image consists of all modified
VOS data and selected data of processes that were running at the time of a module
failure. When the failure occurs, VOS stops running, and the Primitive Control Program
(PCP) automatically writes a dump image to the dump partition.
NOTE
Use the list_iop_dump_switch and
change_iop_dump_switch requests to control
whether the IOPs, selected IOAs, or all IOAs (excluding
C-series IOAs) dump data to the dump partition after an
IOP or IOA failure.
A dump partition is a disk partition that is available to hold a dump image in the event
of the failure of a module. Dump partitions exist only on boot disks; each boot disk has
one dump partition. Space allocated to the dump partition is pre-allocated from the file
partition. If the dump partition is too small, VOS cannot store complete dumps, and
valuable troubleshooting information may be lost. Follow the recommendations for
dump partition size described in the manual VOS System Administration: Disk and
Tape Administration (R284).
When the module is restarted following a system dump, the copy_dump command in
the module_start_up.cm file copies the contents of the dump partition to a dump file
that is stored in the directory (master_disk)>Overseer>dumps. Dump file names
have three-part names consisting of the prefix system, the date and time that the
failure occurred, and the suffix .dump.
Using the Modes of Operation
4-7
Using Dump Mode
Preparing to Enter Dump Mode
Use the list_dumps request to list the available VOS dump images and determine
which one you want to analyze. VOS dump images are created after a system failure.
To enter dump mode, analyze_system requires a dump file, a copy of the VOS
program module that was running at the time of the failure (perhaps in the boot
partition), and a copy of analyze_system.pm that is compatible with the VOS
release running at the time of failure.
As shown in the following example, you can use the list_dumps request to list the
VOS dump images stored in the dump partition.
as: list_dumps
Dumps for %sys#m2, located in %sys#m2>Overseer>dumps:
1) system.95-01-31.13:52:47.c.dump
3)
system.95-04-11.17:05:31.c.dump
2) system.95-03-04.16:22:40.c.dump
as:
Entering Dump Mode and Selecting a Dump
Use the use_dump request to select a VOS dump image to analyze. When you issue
one of these requests, analyze_system also enters dump mode.
As shown in the following example, you can issue the use_dump request to select a
VOS dump image. The specified dump is then known as the analyzed dump. In some
cases, you must also specify a file or partition containing the appropriate version of
VOS. The request displays a summary of the dumps contents.
as: use_dump 1
Detected compressed dump.
Using %sys#m2>Overseer>dumps>system.95-01-31.13:52:47.c.dump
Warning: Modified code pages present in dump.
VOS Release 13.0.1, analyze_system Release 13.0.1
use_dump: The version of the program has changed.
%sys#libs>os>m2_pms>c7100.pm
Using process on CPU31.
Current process is 1060, ptep 82EF41E0, Joe_Smith.Eng
(mk:disk_cm_msg.obj)
PCP called from 80643640 on CPU31
Ram pages from IOP 1 present.
Ram pages from IOAs : 0,2,3,4,5,12,16,18,19,20,21,28,29 present (IOP
1).
Ram pages from IOP 2 present.
Ram pages from IOAs : 2,3,4,5,6,7,18,19,20,21,22,23 present (IOP 2).
Ram pages from IOP 3 present.
Ram pages from IOAs : 1,2,3,4,5,17,18,19,20,21 present (IOP 3).
Crash message: verify_lock_interrupt: Trap Crash.
as:
4-8
VOS System Analysis Manual (R073)
Using Dump Mode
Displaying the Status of a Dump
As shown in the following example, you can use the status request to display more
information about the contents of the selected dump.
as: status
Using dump %sys#m2>Overseer>dumps>system.95-01-31.13:52:47.c.dump (#1)
and partition 4 on disk %sys#m2
Dump info:
PCP time: 95-01-31.13:52:47
dumped at 95-01-31 14:52:47 EDT
dumped on %sys#m2
Operating System bound at 94-11-16 14:15:52 EDT
partition 4
24023 pages.
78 processes.
dump is complete.
Operating system version:
VOS Release 13md
Operating system program module info:
version:
VOS Release 13md
bound by:
Joe_Smith.Eng
date/time bound:
94-11-16 14:15:52 EDT
binder version:
bind, Release 13ls
binder options:
kcbtsm
analyze_system program module info:
pathname: %sys#m2>system>command_library>analyze_system.pm
version:
Release 13.0.1al
bound by:
Installer.Installer
date/time bound:
95-03-13 13:37:03 EDT
binder version:
bind, Release 13.0.1aj
binder options:
cbtsm
as:
Using the Modes of Operation
4-9
Using Dump Mode
Displaying and Selecting Processes Recorded in a Dump
As shown in the following example, you can use the who request to list which
processes were using the system at the time the system failed and the dump image
generated. The asterisk (*) indicates the current process when the system failed.
as: who
PROC
PTEP
1 80C49A40
3 81519720
4 8151C3E0
5 8151EBE0
6 815235E0
7 81523AA0
8 81525020
15 82E9B440
16 81574A20
17 81576820
....
* 770 41350030
as:
USER NAME
CPU30.Idle (Idle_30)
Cache_Manager_Post.System (Cache_Manager_Post)
Cache_Manager_Timer.System (Cache_Manager_Timer)
Cache_Manager_Locker.System (Cache_Manager_Locker)
CPU31.Idle (Idle_31)
CPU28.Idle (Idle_28)
CPU29.Idle (Idle_29), on CPU29
Joe_Smith.Eng (Iake)
Kernel_Utility.System (Kernel_Utility)
Maintenance_Utility.System (Maintenance_Utility)
Joe_Smith.Eng, on CPU4
The analyzed process is the process against which all process-specific commands will
be executed. In dump mode, you can specify an analyzed process with the process
request; however, the analyze_system command initially sets the analyzed process
to the process that was running when the failure occurred that caused the dump you
are examining. Online messages use the term current process to describe the
analyzed process.
Displaying Stack Information from a Dump
You can use the trace request to display a stack trace. For example:
as: trace
MCP: 803F7A30
Fault FIR: 80643640 (atlantic_i860_subrs+640)
Fault EFA: none
Fault r2: 803F7C20
Fault r3: 803F7C50
call_pcp
fp: 803F7C50 pc: 80643640 (atlantic_i860_subrs+640)
begin.420
fp: 803F7D90 pc: 8061CB5C (verify_lock+E6C, line 425
)
setup
fp: 803F7E50 pc: 8061CABC (verify_lock+DCC, line 420
)
verify_lock_interrupt
fp: 803F8120 pc: 8061C4A4 (verify_lock+7B4, line 229
)
atlantic_int_handler fp: 803F8240 pc: 80631BE4 (atlantic_interrupt+BE4)
signal_fault
fp: 803F8480 pc: 80408C70 (s_enable_condition_i+540)
fault_handler
fp: 803F86A0 pc: 804085EC (fault_handler_i+15EC, lin
e 655)
MCP: 803F86D0
Fault FIR: 804E2DFC (disk_driver_module+181C, line 975)
4-10
VOS System Analysis Manual (R073)
Using Dump Mode
Fault EFA: 00000003
Fault r2:
dm_putnext
fp: 803F88E0
line 9
+75)
send_unsolicited_message
fp: 803F8930
ne 406
+0)
check_mailbox
fp: 803F8980
ne 340
+3)
di_interrupt_act
fp: 803F8A10
e 2971
+)
di_interrupt_handler fp: 803F8A70
e 2885
iop_disk_interrupt_handler
fp: 803F8AF0
, line
+ 428)
atlantic_interrupt
fp: 803F8B50
On-units at 80631B90
....
as:
803F88C0
Fault r3: 803F88E0
pc: 804E2DFC (disk_driver_module+181C,
pc: 804DD1E0 (disk_common_util+65F0, li
pc: 804DC874 (disk_common_util+5C84, li
pc: 804EB404 (disk_iop_driver+43E4, lin
pc: 804EB2D0 (disk_iop_driver+42B0, lin
pc: 8060A79C (iop_interrupt_handler+F3C
pc: 80631A28 (atlantic_interrupt+A28)
Troubleshooting a Dump
To troubleshoot a dump, you can use the following requests.
displayUse this request to display the value of system variables in the selected
dump.
check_area, check_boards, check_comm_buffers, check_kel,
check_list, check_map, check_page, and check_prom_codeUse these
requests to determine if part of the dumped VOS image is corrupted.
find_stringUse this request to find the address of string matches in the
contents of the selected dump.
The following example displays the value of the sys_info$module_id in the
selected dump.
as: display sys_info$module_id
8083ABB4 0 01110000
as:
|....
The following example shows the check_boards request being used to check for
board corruption recorded in the dump from the failed module and the check_area
request being used to check for heap corruption.
Using the Modes of Operation
4-11
Using IOA and IOP Modes
as: check_boards
No Hardware Problems Detected.
as: check_area -heap user
--- The area has verified correctly
as:
The following example displays the addresses for string matches found in the selected
dump.
as: find_string Joe -no_hex
ASCII pattern Joe found at
ASCII pattern Joe found at
ASCII pattern Joe found at
....
ASCII pattern Joe found at
....
as:
address 8003B20E (kernel)
address 8003B38E (kernel)
address 8003B60E (kernel)
address 3FF2718C (process 1060)
Deleting Dumps and Exiting Dump Mode
Use the delete_dump request to delete a selected VOS dump image. Do not delete
a dump until you or the CAC have resolved the problem that caused the dump.
To exit dump mode, select another mode. For example, you can select module mode
by issuing the use_module request.
Using IOA and IOP Modes
This section describes the IOA and IOP dump and firmware modes. It contains the
following topics.
Using IOA Dump Mode
Using IOA Firmware Mode
Using IOP Dump Mode
IOP Requests Available in Module Mode
Using IOP Firmware Mode
Using IOA Dump Mode
Use IOA dump mode to display the contents of an IOA dump. To prepare to enter IOA
dump mode, first list the available IOP dumps with the list_iop_dumps request, or
list the system dumps with the list_dumps request. Select an IOP dump with the
use_iop_dump request, or select a system dump with the use_dump request. Then
select an IOA to analyze with the use_iop request. Note that the values for the
use_iop -iop_no argument range from 1 to 14, and refer to the order in which the
4-12
VOS System Analysis Manual (R073)
Using IOA and IOP Modes
IOPs were installed in the cabinet, not the IOP slot numbers.Then, issue the status
request.
as: list_iop_dumps
Dumps for %vse9#m9, located in %vse9#m9>Overseer>dumps:
1) iop6.98-03-17.15:03:52.dump 3)iop6ia20.98-05-07.14:26:20.dump
2) iop6.98-04-23.23:14:45.dump
as: use_iop_dump 3
Using %vse9#m9>Overseer>dumps>iop6ia20.98-05-07.14:26:20.dump
VOS Release 14.0.beta.bx, analyze_system Pre-release
Ram pages from IOAs : 20 present (IOP 1).
as: use_iop -iop_no 1 -ioa 20
as: status
Using dump %vse9#m9>Overseer>dumps>iop6ia20.98-05-07.14:26:20.dump
and partition 3 on disk %vse9#m9
Dump info:
PCP time: 98-05-07.14:26:20
dumped at 98-05-07 14:26:20 edt
dumped on %vse9#m9
Operating System bound at 80-01-01 00:00:00 edt
partition 3
130 pages.
1 processes.
dump is complete.
Operating system program module info:
version:
VOS Release 14.0.beta.bx
bound by:
Installer.Installer
date/time bound:
98-02-25 07:18:48 edt
binder version:
bind, Release 14.0.alpha.bx
binder options:
kcbtsm
IOA program module info:
pathname: %vse9#m9>r14.0_system>firmware>ioa02_bsc.pm
version:
Pre-release
bound by:
Installer.Installer
date/time bound:
98-05-07 10:08:14 edt
binder version:
bind, Release 14.0.0
binder options:
kbsm
currently using (IOA #20 IOP #1)
analyze_system program module info:
pathname: %vse9#m9>r14.0_system>command_library>analyze_system.pm
version:
Pre-release
bound by:
Installer.Installer
date/time bound:
98-04-30 14:38:22 edt
binder version:
bind, Release 14.0.0
binder options:
cbtsm
as:
Using the Modes of Operation
4-13
Using IOA and IOP Modes
If the use_iop request cannot find the firmware file for the IOA in the dump, it returns
the following firmware error message.
Argument is not within the range allowed. iop firmware info @
address.
Use the system>configuration>devices.tin file, the
system>configuration>firmware.tin file, and the system>firmware
directory to determine the appropriate firmware file for the IOA. As shown in the
following example, issue the use_iop -file argument and specify this firmware file
to enter IOA dump mode.
as: use_iop -iop_no 1 -ioa 13 -file sys>frmware>ioa04_hal+.pm
as:
To exit IOA dump mode, select another mode. For example, you can select module
mode by issuing the use_module request.
Using IOA Firmware Mode
Use IOA firmware mode to display the current status of a specified IOAs firmware. This
section describes how to enter IOA firmware mode and some of the requests you can
issue while in IOA firmware mode.
To prepare to enter IOA firmware mode, issue the list_boards request and specify
the value of the -board_type argument as iop. Select an IOP that controls the IOA
whose memory you wish to examine. To enter IOA mode, specify the slot numbers of
the IOP and IOA in the use_iop request. The following example shows the use of the
list_boards and use_iop requests.
as:
list_boards -board_type iop
Module: %sys#m2 (28 Slot Chassis, Model 2)
Id Prom --------Fault Data-----Slot
Board Type
Model Serial Rev Rev Cnt Code Last Fault Time
4 IO Processor
K20010 10841 45 45
0
0 Clock/Remote Service
K10300
3149 26 16
0
2 Disk Adapter
K10500
7119 21 19
0
0 781 MB Disk Drive
D20300 14562
0
0
0
3 Disk Adapter
K10500
7201 21 19
0
0 781 MB Disk Drive
D20300 16137
0
0
0
4 Disk Adapter
K10500
7556 21 19
0
0 781 MB Disk Drive
D20300 16464
0
0
0
5 Disk Adapter
K10500
6183 23 19
0
0 781 MB Disk Drive
D20300
5555
0
0
0
11 SCSI Tape Adapter
K12200
3415 12 12
0
7 Tape Drive 3480 Mobi T40100 ***** ***
0
12 Null Modem Comm Adap
K11100 15866 25 16
0
13 Ethernet Adapter
K10410 12580
6 18
0
14 Terminator
K10810 17107
6
0
0
4-14
VOS System Analysis Manual (R073)
Using IOA and IOP Modes
15 Terminator
BP Bus P
BQ Bus Q
5 IO Processor
...
as: use_iop 4 -ioa 13
as:
K10810
K20010
17290
6
***** ***
***** ***
13870 48
45
0
0
0
0
Once analyze_system is in IOA firmware mode, you can issue requests such as
status and display_pm to check for compatibility among VOS, analyze_system,
and the IOA firmware.
as: status
Using module %sys#m2, booted from partition 2 on disk %sys#m2
Operating system program module info:
version:
VOS Release 13.0.1am
bound by:
Installer.Installer
date/time bound:
95-03-15 20:59:27 EDT
binder version:
bind, Release 13.0.1aj
binder options:
kcbtsm
IOA program module info:
pathname: %sys#m2>system>firmware>ioa04_enet_dl.pm
version:
IO Release 200.alpha.a
bound by:
date/time bound:
93-08-16 16:44:36 EDT
binder version:
CONVERT_IEEE v1.0
binder options:
currently using (IOA #13 IOP #1)
analyze_system program module info:
pathname: %sys#m2>system>command_library>analyze_system.pm
version:
Release 13.0.1al
....
as: display_pm
Header:
version:
program_name:
binder_version:
release_name:
as:
1
ioa04_cloud9.pm
CONVERT_IEEE v1.0
IO Release 200.alpha.a
To exit IOA firmware mode, select another mode. For example, you can select module
mode by issuing the use_module request.
Using the Modes of Operation
4-15
Using IOA and IOP Modes
IOP Requests Available in Module Mode
Not all IOP requests are available in IOP firmware mode. The following table lists some
of the IOP requests that are available only in module mode and some that are available
only in IOP mode.
Some Module-Mode IOP Requests
Some IOP-Mode IOP Requests
dump_iop_chan, dump_iop_cvt,
dump_iop_data, dump_iop_fw,
dump_iop_mailbox,
dump_iop_ring
dump_area -heap iop, dump_async_iop,
dump_fault_info, dump_gci_dev,
dump_gci_slot, dump_ioa_dev_info,
dump_ioa_slot_tbl, dump_iop_cb_queues,
dump_iop_dump_list,
dump_iop_equip_table, dump_iop_map,
dump_iop_meters, dump_iop_prom,
dump_iop_prom_info, dump_iop_reg_list
Using IOP Dump Mode
Use IOP dump mode to display the contents of an IOP dump. To prepare to enter IOP
dump mode, issue the list_iop_dumps request to display a list of IOP dumps for a
module, or issue the list_dumps request to display a list of system dumps. To select
a dump, issue the use_iop_dump request and specify an IOP dump number, or issue
the use_dump request and specify a system dump number. To enter IOP dump mode,
issue the use_iop request with the -iop_no argument. Note that the values for the
use_iop -iop_no argument range from 1 to 14, and refer to the order in which the
IOPs were installed in the cabinet, not the IOP slot numbers. The following example
shows the use of the list_iop_dumps, use_iop_dump, and use_iop requests to
enter IOP dump mode.
as: list_iop_dumps
Dumps for %vse9#m9, located in %vse9#m9>Overseer>dumps:
1) iop6.98-03-17.15:03:52.dump 3)iop6ia20.98-05-07.14:26:20.dump
2) iop6.98-04-23.23:14:45.dump
as: use_iop_dump 1
Using %vse9#m9>Overseer>dumps>iop6.98-03-17.15:03:52.dump
VOS Release 14.0.beta.bx, analyze_system Pre-release
Ram pages from IOP 1 present.
as: use_iop -iop_no 1
4-16
VOS System Analysis Manual (R073)
Using IOA and IOP Modes
Once analyze_system is in IOP dump mode, you can issue requests such as the
status request to determine the contents of the IOP dump.
as: status
Using dump %vse9#m9>Overseer>dumps>iop6.98-03-17.15:03:52.dump
and partition 1 on disk %vse9#m9
Dump info:
PCP time: 98-03-17.15:03:52
dumped at 98-03-17 16:03:52 edt
dumped on %vse9#m9
Operating System bound at 80-01-01 00:00:00 edt
partition 1
108 pages.
1 processes.
dump is complete.
Operating system program module info:
version:
VOS Release 14.0.beta.bx
bound by:
Installer.Installer
date/time bound:
98-02-25 07:18:48 edt
binder version:
bind, Release 14.0.alpha.bx
binder options:
kcbtsm
IOP program module info:
pathname: %vse9#m9>Stratus>Joe_Smith>iop_type_c.pm
version:
PKIO Release 240 rev 21/K121
bound by:
Joe_Smith.Stratus
date/time bound:
98-04-21 17:15:33 edt
binder version:
bind, Release 14.0.0
binder options:
kcbtsm
currently using (IOP #1)
analyze_system program module info:
pathname: %vse9#m9>r14.0_system>command_library>analyze_system.pm
version:
Pre-release
bound by:
Suzanne_Ryan.Stratus
date/time bound:
98-04-30 14:38:22 edt
binder version:
bind, Release 14.0.0
binder options:
cbtsm
as:
To exit IOP dump mode, select another mode. For example, you can select module
mode by issuing the use_module request.
Using IOP Firmware Mode
Use IOP firmware mode to display the current status of a specified IOPs firmware or
memory. This section lists some of the requests that are available in IOP firmware
mode and describes how to enter and use IOP firmware mode.
Using the Modes of Operation
4-17
Using IOA and IOP Modes
To prepare to enter IOP mode, issue the list_boards request and specify the value
of the -board_type argument as iop. Select an IOP whose memory you wish to
examine and then specify the slot number of the IOP in the use_iop request. After you
issue the use_iop request with the IOP slot number, analyze_system enters IOP
mode. No output is displayed. The following shows an example that uses the
list_boards and use_iop requests.
as:
list_boards -board_type iop
Slot
Board Type
Time
4 IO Processor
0 Null Modem Comm Adapt
1 Tape Adapter
0 Tape Adapter
2 SCSI Adapter Type 3
1 1.5 GB SCSI Disk Dr
2 1.5 GB SCSI Disk Dr
3 1.5 GB SCSI Disk Dr
3 SCSI Adapter Type 3
1 1.5 GB SCSI Disk Dr
2 1.5 GB SCSI Disk Dr
3 1.5 GB SCSI Disk Dr
4 SCSI Adapter Type 3
1 3.2 GB SCSI Disk Dr
2 1.5 GB SCSI Disk Dr
3 3.2 GB SCSI Disk Dr
5 SCSI Adapter Type 3
1 3.2 GB SCSI Disk Dr
2 1.5 GB SCSI Disk Dr
3 3.2 GB SCSI Disk Dr
6 SCSI Adapter Type 3
1 3.2 GB SCSI Disk Dr
3 Tape Drive DAT-2 w/
7 SCSI Adapter Type 3
1 3.2 GB SCSI Disk Dr
8 Null Modem Comm Adapt
9 Ethernet Adapter
10 Ethernet Adapter
...
BP Bus P
BQ Bus Q
5 IO Processor
as: use_iop 4
4-18
VOS System Analysis Manual (R073)
Module: %es#m18 (28 Slot Chassis)
Id Prom --------Fault Data-----Model Serial Rev Rev Cnt Code Last Fault
K20010
K11100
K10700
K10700
K12110
D60400
D60400
D60400
K12110
D60400
D60400
D60400
K12110
D60500
D60400
D60500
K12110
D60500
D60400
D60500
K12110
D60500
T60210
K12110
D60500
K11100
K10410
K10410
19025 63
13070 19
2400 18
***** ***
15837 13
99999
0
99999
0
99999
0
12341 13
99999
0
99999
0
14283
0
20133 19
99999
0
99999
0
1557
0
12297 19
99999
0
99999
0
99999
0
12267
4
99999
0
***** ***
15310 13
99999
0
16008 25
16531 14
11726
4
K20010
***** ***
***** ***
10967 63
52
12
8
42
0
16
18
17
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
52
0
0
0
42
0
0
0
42
0
0
0
42
0
0
0
42
0
0
0
42
0
Using IOA and IOP Modes
Once analyze_system is in IOP firmware mode, you can issue requests, such as the
status and display_pm requests, to check for compatibility between VOS,
analyze_system, and the IOP firmware. You can use the check_area -heap iop
request to check for possible problems in the IOP heap. Note that this request may not
display accurate diagnostic information about a live heap because the heap may be
being updated at the time of the request.
as: status
Using module %es#m18, booted from partition 3 on disk %es#m18
Operating system version:
VOS Release 14.0.0m
Operating system program module info:
version:
VOS Release 14.0.0m
bound by:
Installer.Installer
date/time bound:
98-05-07 06:15:41 edt
binder version:
bind, Release 14.0.0
binder options:
kcbtsm
User program module info:
pathname: %es#m18>system>command_library>analyze_system.pm
version:
Release 14.0.0m
bound by:
Installer.Installer
date/time bound:
98-05-06 19:31:49 edt
binder version:
bind, Release 14.0.0
binder options:
cbtsm
analyze_system program module info:
pathname: %es#m18>system>command_library>analyze_system.pm
version:
Release 14.0.0m
bound by:
Installer.Installer
date/time bound:
98-05-06 19:31:49 edt
binder version:
bind, Release 14.0.0
binder options:
cbtsm
as: display_pm
Header:
version:
program_name:
binder_version:
release_name:
pop_version:
processor:
processor_family:
binder_options:
system_name:
user_name:
1
iop_type_b
bind, Release 14.0.0
Release 240.0.1
5
5 (mc68030)
0 (MC68K)
kcbtsm
es
Installer.Installer
Using the Modes of Operation
4-19
Using Module Mode
To exit IOP firmware mode, select another mode. For example, you can select module
mode by issuing the use_module request.
Using Module Mode
By default, when you issue the analyze_system command, it enters module mode.
Also, by default, analyze_system uses the current module. You can specify another
module; the module that you analyze is called the analyzed module. Module mode
enables you to display the following types of memory.
live VOS program module (vos.pm) procedures and all shared data structures,
including:
hardware and software configuration and status
performance and cumulative meters since the last module reboot
active structures and fields
communications tracing tools
any process on a module (selected by the process command)
a networked modules memoryNote that some data structures in memory cannot
be viewed in a networked module. Other data structures on a networked module
may not be available or correct if the networked module is running a different
release of VOS.
In addition, analyzing the memory of another module requires the transfer of large
amounts of data across the network and should only be done in unusual
circumstances because of its impact on other processes.
Note that in module mode, analyze_system may be unable to provide consistent
copies of some data, since the module is running while analyze_system is displaying
data about it.
The command can enter all other modes through module mode.
4-20
VOS System Analysis Manual (R073)
Using Module Mode
Request Types Used in Module Mode
Table 4-2 lists the types of requests that you can issue when analyze_system is in
module mode. It also lists examples of each type of request.
Table 4-2. Types of Module Mode Requests
Module Mode Request
Type
Sample Requests
Display a single structure in
shared memory
dump_adte, dump_afte, dump_apte, dump_board,
dump_cache_info, dump_cache_page,
dump_comm_buffers, dump_lap_trace, dump_pte,
dump_et, dump_eite, dump_mmdata, dump_mme
Display meters
cache_meters, event_count_meters,
page_meters, sched_meters
Display summary data from
a linked list of the same
structure
dump_cache, dump_dqe, dump_eit, dump_et,
list_boards, summary
Display summary data from
multiple structures
dump_eit, mme_status, pme_status,
dump_queue_info, dump_net_info
Change memory
disable_fault, enable_fault,
set_board_thresholds, set_comm_thresholds,
set_tape_buffer_mode, set_word
Display per process
information
display_memory_usage, display_process_info,
dump_events, dump_pdr, dump_porte,
list_port_attachments, process
Change to another mode
use_block, use_dump, use_file, use_iop,
use_module
As shown in the following example, when you issue the analyze_system command,
or issue the status request or the status -brief request in module mode,
analyze_system displays similar information about the current VOS and
analyze_system release numbers, the current module, and the current master disk.
ready analyze_system
VOS Release 14.0.0l, analyze_system Release 14.0.0l
Current process is 2039, ptep C51F5880, Joan_Smith.Publications
Using the Modes of Operation
4-21
Using Module Mode
as: status
Using module %es#m9, booted from partition 4 on disk %es#m9
Operating system version:
VOS Release 14.0.0l
Operating system program module info:
version:
VOS Release 14.0.0l
bound by:
Installer.Installer
date/time bound:
98-05-01 05:55:33 edt
binder version:
bind, Release 14.0.0
binder options:
kcbtsm
User program module info:
pathname: %es#m9>system>command_library>analyze_system.pm
version:
Release 14.0.0l
bound by:
Installer.Installer
date/time bound:
98-04-30 19:21:56 edt
binder version:
bind, Release 14.0.0
binder options:
cbtsm
analyze_system program module info:
pathname: %es#m9>system>command_library>analyze_system.pm
version:
Release 14.0.0l
bound by:
Installer.Installer
date/time bound:
98-04-30 19:21:56 edt
binder version:
bind, Release 14.0.0
binder options:
cbtsm
as: status -brief
Using module %es#m9, booted from partition 4 on disk %es#m9
Operating system version:
as:
VOS Release 14.0.0l
The analyzed process is the process against which all process-specific commands will
be executed. In module mode, you can issue the process request to display the CPU
on which your process is executing and the process table entry pointer (PTEP). Online
messages use the term current process to describe the analyzed process.
as: process
Using process on CPU0.
Current process is 2039, ptep C51F5880, Joan_Ryan.Publications
Process is running on CPU 0 right now; no stack addr known.
The VOS Program Module Memory Structure
The following sections illustrate the structure of the VOS program modules (vos.pm)
for the XA/R-series and Continuum-series modules.
4-22
VOS System Analysis Manual (R073)
Using Module Mode
The Structure of the XA/R-Series VOS Program Module
This section illustrates the memory layout of the VOS program module on XA/R-series
modules (with G861 or G862 CPUs) at boot time. The following is sample output of the
display_pm request for a VOS Release 14.0.0 vos.pm. This output shows the
locations of the wired, initialization, and paged sections in memory at boot time.
as: display_pm
Header:
version:
program_name:
binder_version:
release_name:
pop_version:
processor:
processor_family:
...
Section Info:
Wired
Code
Symtab
Static
External
1
_PPatl_vos
bind, Release 14.0.0
VOS Release 14.0.0m
0
257 (i80860xp)
2 (I860)
address
80400000
80C1A000
80800000
80827000
task_static_len:
block_map_address:
Init
Code
Symtab
Static
External
00026780
00000000
address
80844000
80DBE000
808A8000
808AB000
task_static_len:
block_map_address:
Paged
Code
Symtab
Static
External
address
808B8000
80DDA000
80BF2000
80C10000
task_static_len:
block_map_address:
length
003FF010
001A3DA4
00026780
0001C72C
GOT address:
block_map_len:
00000000
00000000
length
00064000
0001BCAC
00002B40
0000CD70
00002B40
00000000
GOT address:
block_map_len:
00000000
00000000
length
00339748
0011CB68
0001DF80
0000926C
0001DF80
00000000
GOT address:
block_map_len:
00000000
00000000
as:
Based on the output of the display_pm request, Figure 4-1 shows the locations of the
wired, initialization, and paged sections of the XA/R-series vos.pm in memory at boot
time.
Using the Modes of Operation
4-23
Using Module Mode
80400000
Wired Code
80800000
Wired Internal Static
80827000
Wired External Static
80844000
Initialization Code
808A8000
Initialization Internal Static
808AB000
Initialization External Static
808B8000
Paged Code
80BF2000
Paged Internal Static
80C10000
Paged External Static
80C1A000
Wired Symbol Table
80DBE000
Initialization Symbol Table
80DDA000
Paged Symbol Table
Figure 4-1. XA/R-Series VOS Program Module at Boot Time
Shared Memory Space for an XA/R-Series VOS Program Module
Use the dump_vm_pool_info request (vm stands for virtual memory) to determine
which VOS subsystems are using VOS shared memory space and what portions of that
space are available for use. The virtual memory pool is the region of kernel address
space not occupied by system code or fixed-size tables. Various kernel subsystems
dynamically request virtual memory from this pool. The following is sample output of
the dump_vm_pool_info request for VOS Release14.0.0. Output will vary from
module to module, and from modules with G860 CPUs versus modules with G861 or
G862 CPUs. Ellipsis points (...) in the figure indicate the deletion of data.
4-24
VOS System Analysis Manual (R073)
Using Module Mode
as:
dump_vm_pool_info
* Virtual Memory Pool *
Size
Flags
Start
Used
Free (hex)
Owner
80058
8
(00008) u pcp_stack
80060
16
(00010) u I/O Heap 0
80070
16
(00010) u High I/O Heap 0
80080
32
(00020) u I/O Heap 0
800A0
8
(00008) u Comm Heap
800A8
288
(00120) u net_buffer_pool_p$
801C8
16
(00010) u tape_buffers_p$
801D8
160
(000A0) u Paged Heap 0
80278
2
(00002) u dump_disk_buffers_p$
8027A
6
(00006) u ui_abs_pagesp$
80280
192
(000C0) u Paged Heap 0
80340
32
(00020) u High I/O Heap 0
80360
3
(00003) u net_buffer_pool_p$
80363
2
(00002) u Loop locks 0
80365
32
(00020) u High I/O Heap 0
80385
12
(0000C) u Streams MBLKS
80391
6
(00006) u Streams Message Data
80397
8
(00008) u Streams MBLKS
8039F
8
(00008) u Streams Message Data
803A7
2
(00002) u Loop locks 0
803A9
87 (00057) f
Merged Free Block
8084A
64
(00040) u Paged Heap 0
8088A
32
(00020) u High I/O Heap 0
808AA
1 (00001) f
Merged Free Block
80C1A
64
(00040) u Paged Heap 0
80C5A
608
(00260) u High I/O Heap 0
80EBA
64
(00040) u Paged Heap 0
80EFA
224
(000E0) u High I/O Heap 0
80FDA
31 (0001F) f
VM Pool Virgin Storage
80FF9
7
(00007) uh Idle_30 fence/stack
81000
959
(003BF) u Wired Heap 0
813BF
9
(00009) u pmes for 800-817 MB
813C8
20
(00014) u aptes for 800-813 MB
813DC
36
(00024) u mme array(s) for 000-017 MB
81400
188
(000BC) u aptes for 814-8CF MB
814BC
69
(00045) u pmes for 818-8CF MB
81501
156
(0009C) u mme array(s) for 018-07F MB
...
8B69E
18
(00012) u telnet_al.cp.pm
8B6B0
28 (0001C) f
Merged Free Block
8B6CC
49
(00031) u sos.pm
8B6FD
37 (00025) f
Merged Free Block
8B722
12
(0000C) u async_al.cp.pm
8B72E
22 (00016) f
Merged Free Block
8B744
11
(0000B) u mpx_gcomm.pm
8B74F
3 (00003) f
Merged Free Block
8B752
9
(00009) u mpx_gcomm.pm
8B75B
13 (0000D) f
Merged Free Block
Using the Modes of Operation
4-25
Using Module Mode
8B768
...
8CC20
8CC61
8CCFA
8CD0A
8CD23
8CD55
8CD6A
8CD77
8CDD1
8CDE0
8CDF1
8CDF4
8CFEB
8CFF2
8CFF9
Total
33
(00021)
vterm.pm
65
153
16
25
50
21
13
90
15
17
3
503
7
7
7
-----8256
Used
(00041)
(00099)
(00010)
(00019)
(00032)
(00015)
(0000D)
(0005A)
(0000F)
(00011)
(00003)
(001F7)
(00007)
(00007)
(00007)
u
uh
u
uh
u
uh
u
uh
u
uh
u
uh
uh
uh
uh
tcp.pm
cache_manager_pages
tcp_kll.pm
cache_manager_pages
dkux.pm
cache_manager_pages
dlmux.pm
cache_manager_pages
gdl.pm
cache_manager_pages
timod.cp.pm
cache_manager_pages
Idle_29 fence/stack
Idle_28 fence/stack
Idle_31 fence/stack
-----42927
Free
as:
Figure 4-2 shows the vos.pm section map for VOS Release 14.0.0 on an XA/R-series
module with the virtual memory pool used and free list. The initialization code can be
replaced once the module is booted. Other items from the used and free lists are added
to the end of the section map.
The highest possible address on an XA/R module is BFFFF000x, though the actual
value seen may be less, based on the physical memory present.
4-26
VOS System Analysis Manual (R073)
Using Module Mode
80000000
Reserved Kernel Tables
80058000
Virtual Memory Pool
80400000
Wired Code
80800000
Wired Static
80844000
Wired Heap (Was Initialization Code)
8089C000
Initialization External Static
808B8000
Paged Code
80BF2000
Paged Static
80C1A000
Virtual Memory Pool
BFFFF000
Figure 4-2. Sample XA/R-Series (G861 or G862) VOS Virtual Memory Pool
The Structure of the Continuum-Series VOS Program Module
This section illustrates the memory layout of the VOS program module on
Continuum-series modules. The following is sample output of the display_pm
command for a VOS Release 14.0.0 vos.pm.
Using the Modes of Operation
4-27
Using Module Mode
as:
display_pm
Header:
version:
program_name:
binder_version:
release_name:
pop_version:
processor:
processor_family:
binder_options:
...
Section Map:
wired
1
_PPg80_vos
bind, Release 14.0.0
VOS Release 14.0.0l
0
769 (pa8000)
4 (HPPA)
kcbtsm
address
length
file address
Code
C0000000
00765E90
0002A000
Symtab
C0994000
00308D08
00948000
Static
C0800000
0005AD00
007D4000
External C085B000
00038910
0082F000
task_static_len:
0005AD00
GOT address:
block_map_address:
C06FC3F8
block_map_len:
initialization
Code
Symtab
Static
External
address
C0925000
C0C9F000
C0982000
C0986000
task_static_len:
block_map_address:
paged
Code
Symtab
Static
External
maps
Code
Symtab
Static
External
VOS System Analysis Manual (R073)
00000000
00001680
file address
008D9000
00C53000
008D9000
008D9000
GOT address:
block_map_len:
length
00000000
000AB446
00000000
00000000
00000000
00000000
file address
008D9000
00C53000
00936000
0093A000
GOT address:
block_map_len:
length
00000000
00000000
00000000
00000000
00000000
00000000
address
FFFFE000
C0D10000
FFFFE000
FFFFE000
task_static_len:
block_map_address:
4-28
00003100
C0980000
address
C0925000
C0C9F000
C0925000
C0925000
task_static_len:
block_map_address:
length
0005C680
0001B506
00003100
000003E4
00000000
00069A98
00000000
00000000
file address
00D42000
00D42000
00D42000
00D42000
GOT address:
block_map_len:
00000000
00000000
Using Module Mode
physical_wired
Code
Symtab
Static
External
address
00220000
C0987000
0023F000
00240000
task_static_len:
block_map_address:
physical_initialization
address
Code
00260000
Symtab
C0992000
Static
00263000
External 00264000
task_static_len:
block_map_address:
wired_batc
Code
Symtab
Static
External
address
C0766000
C0C9D000
C0894000
C0900000
task_static_len:
block_map_address:
gateways
Code
Symtab
Static
External
address
C0920000
C0C9E000
C0925000
C0925000
task_static_len:
block_map_address:
temporarily_wired
Code
Symtab
Static
External
address
C0925000
C0C9F000
C0925000
C0925000
task_static_len:
block_map_address:
length
0001EF30
0000A840
00000850
00002D04
00000850
0023DA28
GOT address:
block_map_len:
length
000026E0
00001736
00000110
000000D6
00000110
00262508
00000000
C0924210
00000000
00000000
00000000
00000000
file address
008D4000
00C52000
008D9000
008D9000
GOT address:
block_map_len:
length
00000000
00000000
00000000
00000000
00000000
000001D8
file address
00790000
00C51000
00868000
008D4000
GOT address:
block_map_len:
length
000042D8
000003F8
00000000
00000000
00000000
00001508
file address
00025000
00946000
00028000
00029000
GOT address:
block_map_len:
length
00044000
000000B0
0006C000
00000000
0006C000
00000000
file address
00002000
0093B000
00021000
00022000
00000000
000000C8
file address
008D9000
00C53000
008D9000
008D9000
GOT address:
block_map_len:
00000000
00000000
Using the Modes of Operation
4-29
Using Module Mode
programmed_operators address
Code
FFF80000
Symtab
C0CBB000
Static
FFFC7000
External FFFD2000
task_static_len:
block_map_address:
pop_batc
Code
Symtab
Static
External
address
FFFD4000
C0D0F000
FFFFE000
FFFFE000
task_static_len:
block_map_address:
length
000468F0
00053916
0000A0C0
00001510
0000A0C0
FFFC1800
GOT address:
block_map_len:
length
00029800
00000074
00000000
00000000
00000000
00000000
file address
00CC4000
00C6F000
00D0B000
00D16000
00000000
000050F0
file address
00D18000
00CC3000
00D42000
00D42000
GOT address:
block_map_len:
00000000
00000000
Figure 4-3 shows the locations of the wired, initialization, and programmed-operators
sections of the Continuum-series vos.pm in memory, based on the output of the
display_cm command.
4-30
VOS System Analysis Manual (R073)
Using Module Mode
C0000000
Wired Code
C0800000
Wired Internal Static
C085B000
C0894000
Wired External Static
C0925000
Initialization Code
C0982000
Initialization Internal Static
C0986000
Initialization External Static
C0987000
C0994000
Wired Symbol Table
C0C9F000
Initialization Symbol Table
C0CBB000
Virtual Memory Pool
FFF80000
Programmed-Operator (POP) Code
FFFC7000
POP Internal Static
FFFD2000
POP External Static
Figure 4-3. Continuum-Series VOS Program Module at Boot Time
Shared Memory Space for a Continuum-Series VOS Program Module
Use the dump_vm_pool_info request (vm stands for virtual memory) to determine
which VOS subsystems are using VOS shared memory space and what portions of that
space are available for use. The virtual memory pool is the region of kernel address
space not occupied by system code or fixed-size tables. Various kernel subsystems
dynamically request virtual memory from this pool. The following is sample output of
Using the Modes of Operation
4-31
Using Module Mode
the dump_vm_pool_info request for VOS Release 14.0.0. Ellipsis points (...) in the
figure indicate the deletion of data.
as:
Start
C0925
C092D
C0939
C093F
C0947
C094F
C097F
C0987
C098F
C0997
C0AB7
C0AB9
C0AC0
C0AE0
C0AF0
C0B50
C0CB0
C0E10
C0E50
C0ED0
C0F10
C0F50
C0FD0
C0FD8
C0FD9
C1000
C1B78
C1BA0
C1C00
C1FD4
C2142
C29E2
C29FA
...
FEFED
FEFF4
FEFF7
FEFFA
FEFFB
FEFFC
...
Total
4-32
dump_vm_pool_info
* Virtual
Size
Used
Free
8
12
6
8
8
48
7
8
8
288
2
7
32
16
96
352
352
64
128
64
64
128
8
1
7
2936
12
96
980
366
2208
24
6
7
3
1
-----29039
Used
Memory Pool *
Flags
(hex)
Owner
(00008) u Loop locks 0
(0000C) u Streams MBLKS
(00006) u Streams Message Data
(00008) u Streams MBLKS
(00008) u Streams Message Data
(00030) u Loop locks 0
(00007) f
Merged Free Block
(00008) u pcp_stack
(00008) u Comm Heap
(00120) u net_buffer_pool_p$
(00002) u dump_disk_buffers_p$
(00007) f
Merged Free Block
(00020) u I/O Heap 0
(00010) u tape_buffers_p$
(00060) u I/O Heap 0
(00160) u Paged Heap 0
(00160) u I/O Heap 0
(00040) u Paged Heap 0
(00080) u I/O Heap 0
(00040) u Paged Heap 0
(00040) u I/O Heap 0
(00080) u Paged Heap 0
(00008) u Loop locks 0
(00001) f
VM Pool Virgin Storage
(00007) uh Idle_0 fence/stack
(00B78) u Wired Heap 0
(0000C) u pmes for C00-C1F MB
(00060) u mme array(s) for 000-03F MB
(003D4) u aptes for C1C-FEF MB
(0016E) u pmes for C20-FEF MB
(008A0) u mme array(s) for 040-5FF MB
(00018) u Loop locks 0
(00006) f
Merged Free Block
(00007) uh Idle_1 fence/stack
3 (00003) f
Merged Free Block
(00003) uh cache_manager_pages
1 (00001) f
disk_io_block
(00001) uh cache_manager_pages
1 (00001) f
cache_manager_pages
-----226635
Free
VOS System Analysis Manual (R073)
Using Module Mode
Figure 4-4 overlays the vos.pm section map for Release14.0.0 on a Continuum-series
module with the virtual memory pool used and free list. The initialization code and static
regions can be replaced once the module is booted. Other items from the used and free
lists are inserted into empty areas of the section map or added to the end of the section
map.
C0000000
Wired Code
C0800000
Wired Internal Static
C085B000
Wired External Static
C0894000
C0925000
Virtual Memory Pool
C0986000
Initialization External Static
C0987000
C1161000
Virtual Memory Pool
FFF80000
Programmed-Operator (POP) Code
FFFC7000
POP Internal Static
FFFD2000
POP External Static
Figure 4-4. Sample Continuum-Series VOS Virtual Memory Pool
Using the Modes of Operation
4-33
Using Partition Mode
Ranges of Virtual Addresses in User Process Space
Virtual addresses in the user process space are defined per process and are not
unique. The address range in user process space is determined by the module series
you are using and the bind -size argument value specified for a particular
executable. Table 4-3 shows how the virtual address range in the user process space
is affected by these two factors.
Table 4-3. Virtual Address Ranges in User Process Space
Module Series
Address
Space
Default
bind -size
Process
Space Start
Process
Space End
XA/R-series
4 GB
64 MB
800000x
Variable
Continuum-series
4 GB
64 MB
2000x
7FFF8FFF
Using Partition Mode
The partition mode enables you to display or change memory in a particular boot
partition. In the following example, values for system variables such as
sys_info$module_id are those in the specified boot partition.
as: match boot;dump_label
boot1
boot 000065
000002
boot2
boot 000067
000002
boot3
boot 000069
000002
boot4
boot 00006B
000002
boot5
boot 00006D
000002
boot6
boot 00006F
000002
boot7
boot 000071
000002
boot8
boot 000073
000002
Boot disk
Flags: monitor_terminal,auto_boot,no_software_purchased,has_b
+ad_blk_part,using_bd_bitmap
Default boot partition: 4
as: use_partition 4
VOS Release 14.0.0l, analyze_system Release 14.0.0l
as: status
Using partition 4 on disk %es#m9
Operating system version: sys_info$release_version not set
Operating system program module info:
version:
VOS Release 14.0.0l
bound by:
Installer.Installer
date/time bound:
98-05-01 05:55:33 edt
binder version:
bind, Release 14.0.0
binder options:
kcbtsm
4-34
VOS System Analysis Manual (R073)
Using Program Module (File) Mode
analyze_system program module info:
pathname: %es#m9>system>command_library>analyze_system.pm
version:
Release 14.0.0l
bound by:
Installer.Installer
date/time bound:
98-04-30 19:21:56 edt
binder version:
bind, Release 14.0.0
binder options:
cbtsm
as: display sys_info$max_wait_events 2
C0877450 0 0100
|..
|
as: display sys_info$module_id 2
C0880C86 0 0000
|..
|
as: display sys_info$release_version 32
C0880D00 00 7379735F 696E666F 2472656C 65617365 |sys_info$release|
C0880D10 10 5F766572 73696F6E 206E6F74 20736574 |_version not set|
as:
Using Program Module (File) Mode
Program module or file mode enables you to display or change the program header,
the code, static, symbol table regions, and the maps associated with a VOS or firmware
program module. Although program module mode can be used with application
program modules, the same tasks can be more easily accomplished by recompiling the
application or using the debugger.
The following are typical uses of program module mode.
when looking at a dump and the version of a program module has changed, but a
renamed version of the old program module still remains
to change external static variables in order to tune a program module
to determine the source code address of an alignment fault
Issue the use_file request with the name of a VOS program module to enter
program module mode. You can obtain a copy of a VOS program module from a boot
partition by issuing the copy_kernel command. If you are using an XA/R-series
module, you may also find a copy of the alternate VOS kernel in the
>system>release_dir directory.
To exit program module mode, select another mode. For example, you can select
module mode by issuing the use_module request.
Undefined Mode
Use undefined mode when invoking the analyze_system command to prevent
analyze_system from reading VOS data structures before displaying the as:
prompt. Undefined mode saves time if you plan to immediately enter a mode other than
module mode (module mode is the default mode). To invoke undefined mode, specify
Using the Modes of Operation
4-35
Undefined Mode
analyze_system -module at the VOS command line and do not specify a value for
the -module argument. This is the only way to invoke undefined mode.
To exit undefined mode, select another mode. For example, you can select module
mode by issuing the use_module request.
4-36
VOS System Analysis Manual (R073)
Chapter 5
Requests That Provide
Metering Information
5-
The analyze_system command provides meters for measuring the count, quality,
and rate of various VOS operations. All meters count from the boot of the module or
creation of the associated structure. This chapter describes the types of meters
available with the analyze_system command and explains how to reset some
meters. This chapter contains the following sections.
Types of Meters
Resetting Meters
Types of Meters
The analyze_system command provides the following types of metering requests.
requests that contain the word meters
requests that contain the argument -meters
requests in which all fields are counters
requests in which some fields are counters
The following sections further describe each type of meter.
Requests That Contain the Word meters
See Table 1-5 for a description of requests that contain the word meters.
Requests That Provide Metering Information
5-1
Types of Meters
Requests That Contain the Argument -meter(s)
Some requests contain a -meter(s) argument. Two examples are dump_channels
-meter and dump_lock -meters. When you specify this argument, additional
counter fields are displayed in the output, or the output is reorganized to emphasize the
counter field values. The following example shows the different output displayed when
specifying just dump_channels and when specifying dump_channels -meter.
as: dump_channels
Channel name
S C User
OC17
4
0
term.17.0.2
4
1
tape.17.0 not asynchronous.
tape.17.1 not asynchronous.
term.17.12.1
4 192
term.17.12.2
4 193
term.17.12.3
4 194 PreLogin
term.17.12.4
4 195 PreLogin
enet.17.13 not asynchronous.
as: dump_channels -meter
Channel name
Ichars
Ochars
OC17
0
379
term.17.0.2
0
0
tape.17.0 not asynchronous.
tape.17.1 not asynchronous.
term.17.12.1
0
0
term.17.12.2
0
0
term.17.12.3
137
28874
term.17.12.4
84
4023
enet.17.13 not asynchronous.
5-2
VOS System Analysis Manual (R073)
UART Interrupts
0700
4
0000
1
0500
0500
0700
0700
2
1
305
173
Input
0
0
Output
379
0
0
0
137
84
0
0
28874
4023
Locks
10
2
Breaks
0
0
Dialups
2
0
Ints
4
1
3
2
967
334
0
0
0
0
0
0
3
3
2
1
305
173
Types of Meters
Requests That Contain All Meter Fields
The output of some requests consists entirely of meter fields, although this fact is not
stated in the names of the requests. For example, display_system_usage displays
some CPU, I/O, and interrupt meters.
as: display_system_usage
Usage statistics, VOS Release 14.0.0l
----CPU----CPU minutes
Min at PF
Idle
Other
Last
0.20
0.01
1.78
0.00
--I/O Rates-Page faults,/sec10548
File IO, /sec
6213
Disk IO, /sec
6373
--INT Rates-Ints, /sec
Int. Time
as:
26952
0.02
Min
10.2%
0.6%
89.2%
0.0%
Last 5 Min
2.40 24.0%
0.05 0.5%
7.49 74.9%
0.00 0.0%
Last Hour
5.72 4.8%
0.11 0.1%
113.98 95.0%
0.00 0.0%
All 677.6 hours
8197.48 10.1%
85.46 0.1%
72618.68 89.3%
0.00 0.0%
176
104
106
35050 117
22373 74.6
34463 115
75882 21.1
51941 14.4
80952 22.5
65956148 27.0
65457184 26.8
72995175 29.9
449 177663
0.9%
0.12
592 1345063
1.2%
0.55
374 1146376572 470
0.5%
519.20 0.6%
Requests That Provide Metering Information
5-3
Resetting Meters
Requests That Contain Some Meter Fields
Many requests contain some meter fields. The following example shows the counter
and page fault fields displayed by the dump_pte request.
as: match count;dump_pte
PTE at C51F5880 for Joe_Smith.Eng (login)
proc_flags1:
accounting_possible,logged_in
quantum_count:
1
priority_boost_count:
0
watchpoint_count:
0
page_0_ref_count:
0
call_side_locks.write_count:
0
call_side_locks.read_count:
0
call_side_locks.other_count:
1
interrupt_side_locks.write_count:
0
interrupt_side_locks.read_count:
0
interrupt_side_locks.other_count:
0
fmte_count:
0
as: match page_fault;dump_pte
PTE at C51F5880 for Joe_Smith.Eng (login)
page_fault_error_code: 0 ()
page_faults:
1170
page_fault_time:
5976 jiffies (91.2 ms)
profile_last_page_faults: 0
kprofile_last_page_faults: 0
as:
Resetting Meters
By default, most requests report usage since the last module reboot. Requests that
contain the -reset argument enable you to reset to zero the meters associated with
the request. Most requests that have a name containing the word meters can be
reset.
Rather than changing the actual meters, the reset is done by taking a snapshot of the
current meters and using this as the base zero value for interpreting subsequent
requests.
To reset the meters displayed by a request, specify the -reset argument. If the
request also has a -no_report argument, specify it as well so that the request does
not display output when you reset the meters. To specify a specific interval in which to
accumulate metering information, specify the -reset argument in conjunction with the
sleep request. The sleep request enables you to specify the date and time, or
number of hours, minutes, and/or seconds the analyze_system command will wait
before displaying the as: prompt.
The following example shows the result of resetting the disk_lock_meters request.
The first time this request is issued, it displays the disk lock meters accumulated since
5-4
VOS System Analysis Manual (R073)
Resetting Meters
module reboot (3 hours and 50 minutes previously). The disk lock meters are then
reset, and the analyze_system command sleeps for one minute. The user then
reissues the disk_lock_meters request. This time the metering counts are far
smaller because they have accumulated during an interval of slightly longer than a
minute.
as: disk_lock_meters
Total metering time -- 3:49:53
Count
0
48910172
0
0
/sec
0
3546
0
0
%l/f
0.00
2.53
0.00
0.00
lock
lock
lock
lock
all
dctl
cs q
dq
as:
disk_lock_meters -reset -no_report; sleep -minutes 1
as: disk_lock_meters
Total metering time -- 0:01:11
lock
lock
lock
lock
as:
all
dctl
cs q
dq
Count
0
156894
0
0
/sec
0
2209
0
0
%l/f
0.00
1.04
0.00
0.00
Using a Meter File
By default, data accumulated by the -reset argument is stored in the file
as_meter_file in your home directory. You can use the set_meter_file request
to specify a path name to a new meter file and the display_meter_file_info
request to display status information about the specified meter file. After you have reset
a metering request, you can again display usage since the last module reboot by
deleting the last specified meter file. Since this file is locked by the analyze_system
command, you must quit analyze_system before you can delete the file.
Requests That Provide Metering Information
5-5
Resetting Meters
The following example shows the process and result of deleting the file
as_meter_file.
as: ..delete_file (home_dir)>as_meter_file
delete_file: The file is in use.
%es#m24_user>Eng>Joe_Smith>as_meter_file
as: quit
ready 13:19:26
delete_file (home_dir)>as_meter_file
ready 13:19:36
analyze_system
VOS Release 14.0.0l, analyze_system Release 14.0.0l
Current process is 2039, ptep C51F5880, Joe_Smith.Eng
as: disk_lock_meters
Total metering time -- 677:37:55
lock
lock
lock
lock
as:
5-6
all
dctl
cs q
dq
Count
0
328568448
0
0
VOS System Analysis Manual (R073)
/sec
0
134
0
0
%l/f
0.00
0.00
0.00
0.00
Chapter 6
Requests That Display and
Change Memory
6-
This chapter describes how to use the requests that display memory and enable you
to change values in memory. This chapter contains the following sections.
Displaying Unformatted and Formatted Data in Memory
Changing Memory
Displaying and Setting Data and Instructions in Memory
Displaying Unformatted and Formatted Data in Memory
Use the display request to display unformatted data in memory, and use other
requests, such as dump_afte and dump_pte, to display formatted data in memory.
Displaying Unformatted Data in Memory
Use the display request to display unformatted data in memory. The most frequently
used arguments of the display request follow.
display
[start_address]
[n_bytes]
[-no_hex]
[-ebcdic]
[-control_chars]
[-physical]
The following list describes these arguments and provides examples of their use.
* start_address
Specifies any valid hexadecimal address format within the virtual or physical
address range supported by your XA/R-series or Continuum-series module. The
following example shows that you can specify a direct or indirect address for this
Requests That Display and Change Memory
6-1
Displaying Unformatted and Formatted Data in Memory
argument. Note that the indirect address is derived from the permanent process
data pointer. For more information about specifying addresses, see Chapter 3.
as: process
Using process on CPU28.
Current process is 1176, ptep 8175B440, Joseph_Smith.Eng
Process is running on CPU 28 right now; no stack addr known.
as: display 8175B440
8175B440 0 01118498
|....
|
as: match process_number;dump_pte
PTE at 8175B440 for Joseph_Smith.Eng (login)
process_number:
1176
as: ..display_line (hexadecimal (calc 8 * 1176))
24C0x
as: display ((perm_process_datap$)+24C0) 16
8175B440 0 01118498 000B4461 76655F4D 61727469 |......Joseph_Smi|
as:
* n_bytes
Specifies the decimal byte count. The default value is 4 bytes. You can specify the
byte count as a decimal (d or D), hexadecimal (x or X), octal (o or O), or binary
(b or B) number. By default, the value is a decimal number. The following example
shows some of the different ways you can specify a value for this argument.
as: display
8175B440 0
as: display
8175B440 0
as: display
8175B440 0
as: display
8175B440 0
as: display
8175B440 0
as: display
8175B440 0
as:
8175B440 16
01118498 000B4461 76655F4D 61727469
|......Joseph_Smi|
8175B440 10
01118498 000B4461 7665
|......Jose
8175B440 10d
01118498 000B4461 7665
|......Jose
8175B440 10x
01118498 000B4461 76655F4D 61727469
|......Joseph_Smi|
8175B440 10o
01118498 000B4461
|......Jo
|..
8175B440 10b
0111
* -no_hex
Does not display the hexadecimal representation of the value stored at the
specified address. The following example illustrates the use of this argument.
as: display 8175B440 56 -no_hex
8175B440 00 |......Joseph_Smit.......................Eng....|
as:
6-2
VOS System Analysis Manual (R073)
Displaying Unformatted and Formatted Data in Memory
* -ebcdic
Displays characters in EBCDIC instead of ASCII. The following example illustrates
the use of this argument.
as: display 8175B440 16 -ebcdic
8175B440 0 01118498 000B4461 76655F4D 61727469
as:
|..dq.../..^(/...|
* -control_chars
Displays the codes for nonprinting characters instead of periods. The following
example illustrates the use of this argument.
as:
display 8175B440 16 -control_chars
8175B440
01118498 000B4461 76655F4D 61727469
SD N
|OC..UVJoseph_Smi|
H1 LT
as:
* -physical
Causes the request to interpret the address specified in start_address as a
physical and not a virtual address. The following example illustrates the use of this
argument.
as: display
00400000 0
as: display
00400000 0
as:
400000 16
63D0152C 002267CC 152D0022 6AE41530
|c..,.g..-.j..0|
400000 16 -physical
A0000000 45E0F000 00000000 A0000000
|....E...........|
Displaying Formatted Data in Memory
Nearly every analyze_system request provides a formatted display of memory. Use
this manual or the help -match request to find the request or requests that display
data in the desired type of memory.
You may need to provide the address of the memory structure to display. Some
requests require a device or symbolic name. Other requests implicitly use the correct
address.
The following are some of the most important requests that display data in memory.
The disassemble request displays code regions as assembly code.
The fstack, stack, and trace requests display the contents of a stack.
The display_extensible_heap and dump_area requests display the
contents of a heap.
The check_list, dump_list, get_list_header, scan_list, and
walk_list requests look at structures following the standard linked list template.
Requests That Display and Change Memory
6-3
Displaying Unformatted and Formatted Data in Memory
The dump_index_block request displays the contents of a formatted index
block.
Displaying Values in the VOS Symbol Table
The VOS symbol table is available by referencing the file system copy of vos.pm. As
described in Chapter 4, the address of the symbol table can be obtained from the
display_program_module command. As shown in the following example, you can
display variables such as s_listener with the where request.
as: where s__listener
809FF600 at s__listener
as:
Displaying Values in External Variables
You can also examine the starting addresses and value of the external variables for
any vos.pm. To display the external variables map, issue the display_pm
-exernal_vars_map request. The following example lists the starting addresses of
the module-related external variables.
as: ..attach_default_output vos_external_vars
display_pm -external_vars_map
..detach_default_output
as: ..display vos_external_vars -match sys_info$mod -min_lines 2
%sys#m2_user>Eng>Joe_Smith>vos_external_vars
sys_info$module_id
1
95-06-13 13:03:23 EDT
80839B44 00000002
sys_info$module_name
1 80839B50 00000022
sys_info$module_no
1 80839B72 00000002
as:
As shown in the following example, you can display the value of any VOS external
variable with the display request.
as: display
80839B44 0
as: display
80839B50 00
80839B60 10
80839B70 20
as: display
80839B72 0
6-4
sys_info$module_id 2
0111
|..
|
sys_info$module_name 22x
00036D31 37300000 00000000 00000000 |..m170..........|
00000000 00000000 00000000 00000000 |................|
0000
|..
|
sys_info$module_no 2
0011
|..
|
VOS System Analysis Manual (R073)
Changing Memory
Changing Memory
A number of analyze_system requests enable you to change values in VOS
memory.
CAUTION
You should change values in VOS memory only while
under the direction of the CAC.
The following are the requests that are most often used for changing VOS memory.
The set_byte request changes a value in memory in multiples of one byte.
The set_word request changes a value in memory in multiples of two bytes.
The set_longword request changes a value in memory in multiples of four bytes.
All three of these requests take the same arguments, the most important of which are
as follows:
The start_address argument can be any valid hexadecimal address format.
The data argument can be one or more new hexadecimal data values.
The -check argument can be one or more existing hexadecimal data values that
the request verifies before setting the value of data.
The following are examples of the use of the set_byte, set_word, and
set_longword requests on an XA2000-series module. In the first example, the
set_word request changes the two-byte word 4841 to 9999. The first attempt at
setting the new value fails because the check value 0 does not match the existing value
4841. The second attempt at setting the new value succeeds because the check value
4841 matches the existing value 4841.
as: display a8a000 2
00A8A000 0 4841
|HA
as: set_word a8a000 9999 -check 0
set_word: 00A8A000
4841 should be 0000 --- check failed.
as: set_word a8a000 9999 -check 4841
addr
from to
00A8A000 4841 9999
Requests That Display and Change Memory
6-5
Changing Memory
In the following example, the set_byte request changes the 9999 value at address
A8A000 back to the original value of 4841. This request changes the value in multiples
of one byte.
as: display a8a000 2
00A8A000 0 9999
as: set_byte A8A000 48 41 -check 99 99
addr
fm to
00A8A000 99 48
00A8A001 99 41
as: display a8a000 2
00A8A000 0 4841
|..
|HA
In the following example, the set_longword request changes the value of the
symbolic variable recovery_wait$ from 1 to 0 and then back to 1 again.
as: display recovery_wait$
80C10E94 00000001
as: set_longword recovery_wait$ 0 -check 1
addr
from
to
80C10E94 00000001 00000000
as: set_longword recovery_wait$ 1 -check 0
addr
from
to
80C10E94 00000000 00000001
as:
|....
Requests That Change Specific Areas of Memory
Many requests enable you to change a value in memory without specifying an address.
These requests usually contain the keywords disable, edit, enable, set, or
update. The following table lists some of these requests.
change_iop_dump_switch
disable_fault
disable_fault_insertion
disable_timer_fault
edit_vm_sizes
enable_fault
enable_fault_insertion
enable_timer_fault
set_board_thresholds
6-6
VOS System Analysis Manual (R073)
set_comm_thresholds
set_dq_debug_mode
set_dq_defaults
set_instruction
set_lap_trace
set_net_timeout
set_param
set_word
update_fault_info
Displaying and Setting Data and Instructions in Memory
The following is an example of the change_iop_dump_switch request. In the
example, this request resets the dump switch for IOA dumps from IOAs 12 and 13 on
IOP 4. The dump_syserr request shows the address where the value was patched
(80C3458C) and the new value at this location.
as:
as:
change_iop_dump_switch 22 DEVICE_ONLY -ioa_slot 1
dump_syserr -last 6
0 active messages, 712 free.
Total of 262490 logged messages.
Total of 0 lost messages.
Messages from free list:
16:40:59
16:40:59
16:40:59
16:40:59
16:40:59
16:40:59
15:14:46
Joe_Smith.Eng patched location 80839C30 (ptep=817277C0)
0003
-> 0000
***** Security Log Message *****
Joe_Smith.Eng patched location 80C3458C (ptep=817277C0)
3FEA9250 -> 00606468
000C0000 -> 00000000
0000
-> 0003
as:
Displaying and Setting Data and Instructions in Memory
The following list indicates which requests to use when displaying or setting data or
instructions.
To display or set data, use the display, set_byte, set_word, or
set_longword request.
To display or set instructions on Continuum-series and XA/R-series modules, use
the disassemble or set_instruction request.
Additional Rules for XA/R-Series Modules
When examining and setting instructions or data on XA/R-series modules, do not use
the disassemble request with the set_byte, set_word, or set_longword
request and do not use the set_instruction request with the display request.
The following example shows that instructions are displayed in different order with the
disassemble and display requests on an XA/R-series module. The disassemble
Requests That Display and Change Memory
6-7
Displaying and Setting Data and Instructions in Memory
request shows the order of execution, which could be listed as ABCD. The display
request lists the instructions as they are stored, which is BADC.
as: disassemble lock_i 16
8052AA30 A0000000 nop
8052AA34 16110061 ld.l +96(r16),r17
8052AA38 16120069 ld.l +104(r16),r18
8052AA3C 40000800 bri
as: display * 16
8052AA30 0 16110061 A0000000 400000800 16120069
as:
The following paragraphs describe the reasons for the different ordering of instructions.
On XA/R-series modules, two 4-byte instructions are stored as a pair in big-endian
form. Each pair begins on an address that is divisible by 8; that is, a 0 mod 8 address.
The big-endian format swaps the order of the instructions in each pair. The instruction
that executed first is stored as the second member of the pair, and vice versa. The
reverse order of stored instructions is shown by the display request.
The disassemble request lists the instructions in the order of execution.
6-8
VOS System Analysis Manual (R073)
Chapter 7
Requests That Display
Process Information
7-
This chapter describes how to list processes, select processes, and display user
process memory using various analyze_system requests. These requests include
who, process, dump_pte, dump_eit, dump_afte, dump_et, summary, and
display_memory_usage. This chapter contains the following sections.
Listing Processes
Selecting a Process
Displaying User Process Memory
For a description of other process-related requests documented in this manual, see the
section Process Requests in Chapter 1.
Listing Processes
The who request enables you to list processes in several ways. As shown in the
following example, you can use the who request to list all processes on a module.
as: who
PROC
PTEP
1 80C11540
3 80EBB560
4 80EBE720
5 80EC1720
6 80EC75E0
7 80EC7AA0
....
as:
USER NAME
CPU28.Idle (Idle_28)
Cache_Manager_Post.System (Cache_Manager_Post)
Cache_Manager_Timer.System (Cache_Manager_Timer)
Cache_Manager_Locker.System (Cache_Manager_Locker)
CPU29.Idle (Idle_29)
CPU26.Idle (Idle_26), on CPU26
You can also use the who request to list the processes with the same user name as the
process running the analyze_system command. The asterisk (*) indicates which
process is the current analyzed process.
Requests That Display Process Information
7-1
Listing Processes
For example:
as: who -user
PROC
PTEP
*3336 8151D700
3375 819EB9E0
as:
USER NAME
Joe_Smith.Eng, on CPU28
Joe_Smith.Eng
You can use the who request to list the processes with a specified user name. For
example:
as: who -user E*
PROC
PTEP
USER NAME
3142 816A3BE0 Evan_Smith.Eng
3143 817AB6A0 Evan_Smith.Eng
as:
As shown in the following example, you can also use the who request to list the
processes with a specified process name.
as: who -process_name *Link*
PROC
PTEP
USER NAME
63 81462340 Overseer.System (LinkServer1)
64 81466000 Overseer.System (LinkServer2)
65 81469460 Overseer.System (LinkServer3)
66 8146C900 Overseer.System (LinkServer4)
67 81470320 Overseer.System (LinkServer5)
3973 81AD8800 Dave_Smith.SysAdmin (OpenLinkClient)
3974 81AB2440 Dave_Smith.SysAdmin (OpenLinkServer1)
3976 81ACA520 Dave_Smith.SysAdmin (OpenLinkServer2)
3978 81AD8440 Dave_Smith.SysAdmin (OpenLinkServer3)
as:
Finally, you can use the who request to list the processes with a specified user name
and process name. For example:
as: who -user Overseer*
PROC
PTEP
USER NAME
62 8145D880 Overseer.System
63 81462340 Overseer.System
64 81466000 Overseer.System
65 81469460 Overseer.System
66 8146C900 Overseer.System
67 81470320 Overseer.System
68 81470B20 Overseer.System
69 81477000 Overseer.System
70 8147B080 Overseer.System
74 80F3C0C0 Overseer.System
....
7-2
VOS System Analysis Manual (R073)
(TPOverseer)
(LinkServer1)
(LinkServer2)
(LinkServer3)
(LinkServer4)
(LinkServer5)
(NetworkWatchdog)
(TheOverseer)
(BatchOverseer)
(MailUserAgent1)
Listing Processes
as: who -user Overseer* -process_name Mail*
PROC
PTEP
USER NAME
74 80F3C0C0 Overseer.System (MailUserAgent1)
76 80F600E0 Overseer.System (MailUserAgent2)
77 80E90980 Overseer.System (MailCommand1)
79 814847A0 Overseer.System (MailNotifier)
3705 813AA760 Overseer.System (MailTransport1)
3707 81B4C220 Overseer.System (MailSorter)
3710 81C60C20 Overseer.System (MailTransport2)
3713 81A0D220 Overseer.System (MailTransport3)
3715 817504E0 Overseer.System (MailTransport4)
as:
Determining the Process Number
You can determine a process number from a process table entry pointer (PTEP) or a
process ID.
As shown in the examples in the previous section, the output of the who request
contains a process number and associated PTEP. Information about a process, such
as the process number and scheduling parameters that must be accessible to other
processes, is stored in the process table entry (PTE). If you know the PTEP, you can
determine the process number with the match and dump_pte requests, as shown in
the following example.
as: match process_number; dump_pte 8151D700
PTE at 8151D700 for Joe_Smith.Eng (login)
process_number:
3336
as:
A process ID is an eight-digit hexadecimal number that contains the system and
module location of a process as well as the process number. Process IDs have the
following format.
SS8
MM8
U2
PPP14
Requests That Display Process Information
7-3
Listing Processes
The following table describes each element of the process ID.
Process ID
Element
Description
SS
The system number in hexadecimal, 01 to FEx (1 to 254 decimal)
MM
The module number in hexadecimal, 01 to 20x (1 to 32 decimal)
A two-bit unique number (0 to 3 decimal)
PPP
The process number in hexadecimal, 001 to 3FFFx (1 to 16,383 decimal)
You can derive the decimal process number from the process ID as shown in the
following example.
as: match process_id; dump_pte 8151D700
PTE at 8151D700 for Joe_Smith.Eng (login)
process_id:
0111EDO8
as: ..display_line (decimal 2D08x)
3336
as:
Finding a Process
The analyze_system command provides requests that enable you to find processes
that execute a particular program, open a file, wait on an event, or use a device. You
can also display the state of all processes executing on a module.
Finding a Process That Is Executing a Program
Use the dump_eit request to find a process that is executing a particular program. The
execution image table (EIT) contains a list of all programs executing on a module as
well any associated processes. The following is an example of output displayed by the
dump_eit request.
as:
dump_eit -summary
80336A60
%sys#m1>system>kernel_loadable_library>vterm.pm
8033E280
%sys#m1>system>kernel_loadable_library>mpx_gcomm.pm
....
82598D60
%sys#m1>system>command_library>office.pm
011183DB John_Smith.Eng (login)
82497A80
%sys#m1>system>command_library>analyze_system.pm
0111CD08 Joe_Smith.Eng (login)
as:
7-4
VOS System Analysis Manual (R073)
Listing Processes
It is also a way to find programs that have been inefficiently loaded across the network
from a disk on another module.
Finding a Process That Is Using an Open File
Use the dump_afte and dump_fi requests to find a process that is using an open file.
VOS creates an active file table entry (AFTE) structure for each open file. An AFTE
contains one file information (FI) structure for each port that has opened the file. The
FI structures are connected by means of a linked list. The dump_afte request tells you
the first node in the linked list (locker fp) and the number of FI items in the linked
list (ref count). Use the dump_fi request to display the process ID for an FI file
pointer as well as the next FI file pointer (fp). Note that if you are at the end of the linked
list of FI structures, the FI file pointer has a value of 00000001x. The following example
shows the dump_afte and dump_fi values for a file called ex_file that has one
open port. The display_line command determines the process number of the
process that has opened the port from the last three digits of the process ID. You can
also issue the process request to obtain additional information.
as: match locker fp; dump_afte ex_file
locker fp:
04C378A0
as: match ref; dump_afte ex_file
ref count:
1
as: match process; dump_fi 04C378A0
Process ID
011451F6
as: match fp; dump_fi 04C378A0
fp
00000001
as: ..display_line (decimal 1F6x)
502
as: process 1F6x
Using nonrunning process.
Current process is 502, ptep 4104C410, Joe_Smith.Eng
as:
Finding a Process That Is Waiting on an Event
Use the dump_et and dump_pte requests to find a process that is waiting on an event.
An event is a system-maintained resource that can be used to signal a change of status
to a waiting process or processes. User events are associated with a file, but system
events are not. Each module has one event table (ET), which maintains module-wide
parameters for event management and stores the address of all of the modules event
table entries (ETE). The process table entry (PTE) is a per-process data structure that
contains information about the process that is used by the scheduler, page control,
event manager, and other software related to process management. These table
entries contain the information to determine which process is waiting on an event.
as: dump_et -match program_event -long
All nonfree ETEs:
ETE at 04A4F180 for %sys#m2_user>Eng>Joe_Smith>program_event
wait_list:
005A074C -> 04B16760: Joe_Smith.Eng (t6.3)
wait_list:
007566FC -> 04B0AAA0: Mike_Smith.Eng (t6.2)
Requests That Display Process Information
7-5
Listing Processes
lock:
8000
....
as: match process_number; dump_pte 04B0AAA0
process_number:
133
as:
Finding a Process That Is Using a Device
Use the dump_dvt request to find a process that is using a device. The device table
(DVT) is stored in memory and contains information about all devices available on a
system. This information is similar to that in the devices.tin file but also includes
process information.
The following example shows how to display information about a process that is using
a device.
as: match process_id; dump_dvt -name stratanet
process_id:
0D012042 (Overseer)
as:
Determining the State of a Process
You can also use the summary request to display information about the state of all
processes on a module. (This might not produce useful results on an active system.)
as:
summary
1: CPU28.Idle in schedule_interrupt_real.
3: Cache_Manager_Post in post_wait.
4: Cache_Manager_Timer in timer_wait.
5: Cache_Manager_Locker in locker_wait.
Process is running on CPU 29 right now; no stack addr known.
No frame address for process 6, CPU29.Idle on CPU29
Process is running on CPU 26 right now; no stack addr known.
No frame address for process 7, CPU26.Idle on CPU26
Process is running on CPU 27 right now; no stack addr known.
No frame address for process 8, CPU27.Idle on CPU27
Process is running on CPU 30 right now; no stack addr known.
No frame address for process 9, CPU30.Idle on CPU30
Process is running on CPU 31 right now; no stack addr known.
No frame address for process 10, CPU31.Idle on CPU31
35: Kernel_Utility in wait_pi_real.
36: Maintenance_Utility in wait_pi_real.
42: Diagnostic_Utility in wait_pi_real.
45: Diagnostic_Utility in wait_pi_real.
48: Diagnostic_Utility in wait_pi_real.
49: Qrun_Daemon in qrun_daemon.
50: Paging_Daemon in paging_daemon_sleep.
62: System (TPOverseer) in s$$k_wait_event_util_real.
63: System (LinkServer1) in wait_masked_pi_real.
....
as:
7-6
VOS System Analysis Manual (R073)
Selecting a Process
Selecting a Process
Use the process request to select a process. When analyze_system starts, the
active process is the process that is running analyze_system. The following table
describes some of the many ways you can use the process request to switch
processes.
process Request
Result
process
Displays the process number, PTEP, and process name of the
current process
process N
Switch to the process numbered N in decimal
process Nx
Switch to the process numbered N in hexadecimal notation
process user
Switch to the process running analyze_system
process cpuN
Switch to the process currently running on the specified CPU
(usually useful on dumps)
process parent
Switch to the process that created the current analyzed
process
process -user
Switch to the lowest numbered process with the same user
name as the process running analyze_system
process -user
user_name
Switch to the lowest numbered process with the specified user
name
process
-process_name
process_name
Switch to the lowest numbered process with the specified
process name
process -user
user_name
-process_name
process_name
Switch to the process with the specified user and process
names
Displaying User Process Memory
This section describes the organization of user virtual memory on XA/R-series and
Continuum-series modules, as shown by the display_memory_usage request.
Requests That Display Process Information
7-7
Displaying User Process Memory
XA/R-Series User Process Memory
The following output from the display_memory_usage request and Figure 7-1
shows the user virtual memory organization for XA/R-series modules.
NOTE
The amount of space allocated for any particular portion
of user virtual memory depends on the program module
being run. To display the user virtual memory for a
program module, first issue the process request to
select the process that is running the program module.
The VOS program loader puts a program module, which includes the code and static
data regions, and the symbol table and maps in the lower user memory locations. The
VOS program loader also defines the initial stack and heap space requirements for a
program module as the program module begins to execute. On an XA/R-series
module, the heap begins immediately after the last address assigned to the program
and grows toward the higher virtual memory addresses. The stack occupies the higher
addresses and grows downward toward the heap.
as:
display_memory_usage
area
---code
internal static
external static
symbol table
module map
external variables map
link names map
link map
entry map
string pool
object dir map
program module header
user heap
available for stack or heap growth
process fence
user_stack
process heap
process data region heap
process data region
wired kernel stack fence
wired kernel stack
paged kernel stack fence
paged kernel stack
7-8
VOS System Analysis Manual (R073)
address
-------00008000
00320000
00362000
00368000
004445E8
0044DDAA
004511EA
0045276E
00452C1E
004575F2
00457EC0
00457F90
00459000
006C9000
3F6AA000
3F6B2000
3FEAA000
3FF2A000
3FF6A000
3FF6C000
3FF6D000
3FF70000
3FF71000
estimated
maximum
number
bytes
bytes
of bytes
used
used
-------- -------- -------00317C08
00041608
000055A8
000DC5E8
000097C2
00003440
00001584
000004B0
000049D4
000008CE
000000D0
00000B56
00270000 001F05B0
3EFE1000
00008000
007F7000 0000456C
00080000 000005A0
00006000 00004BB0
00002000
00001000
00003000
00000CDD
00001000
00008000
00004610
Displaying User Process Memory
Figure 7-1 displays the output of the display_memory_usage request for
XA/R-series modules in graphical form. Note that the sections in the user process
space are not drawn to scale.
00008000
Code
00320000
Internal Static
00362000
External Static
00368000
Symbol Table
0044445E8
Maps, String Pool, and
Program Module Header
00459000
User Heapgrows
00611000
Available for Stack or Heap Growth
3F6AA000
Process Fence
3F6B2000
User Stackgrows
3FEAA000
Process Heap
3FF2A000
Process Data Region Heap
3FF6A000
Process Data Region
3FF6C000
Wired Kernel Stack Fence
3FF6D000
Wired Kernel Stack grows
3FF70000
Paged Kernel Stack Fence
3FF71000
Paged Kernel Stackgrows
Figure 7-1. XA/R-Series Modules User Process Space
Requests That Display Process Information
7-9
Displaying User Process Memory
Continuum-Series User Process Memory
The following output from the display_memory_usage request and Figure 7-2
shows the user virtual memory organization for Continuum-series modules.
NOTE
The amount of space allocated for any particular portion
of user virtual memory depends on the program module
being run. To display the user virtual memory for a
program module, first issue the process request to
select the process that is running the program module.
The VOS program loader puts a program module, including the code and static data
regions, and the symbol table and maps in the lower user memory locations. The VOS
program loader also defines the initial stack and heap space requirements for a
program module as the program module begins to execute. Unlike XA/R-series
modules, on Continuum-series modules the stack begins immediately after the last
address assigned to the program and grows toward the higher virtual memory
addresses. The heap occupies the higher addresses and grows downward toward the
stack.
as:
display_memory_usage
area
---code
internal static
external static
symbol table
module map
external variables map
link names map
link map
entry map
string pool
object dir map
program module header
user_stack
process fence
available for stack or heap growth
user heap
process heap
process data region heap
7-10
VOS System Analysis Manual (R073)
address
-----00002000
00359000
003C3000
003C9000
004BFC50
004C9DE6
004CEB3E
004D0106
004D05BC
004D55CC
004D5ED8
004D5FB0
004D8000
00CD0000
00CD8000
3FE4E030
7FF2A000
7FFAA000
number
of bytes
-----00356950
00069F58
00005A62
000F6C50
0000A196
00004D58
000015C8
000004B6
00005010
0000090C
000000D8
00000B56
007F8000
00008000
3F176000
3FB26FFF
00080000
00007000
estimated
maximum
bytes
bytes
used
used
------ --------
00001A50
001AC380
000003E0
00005A30
Displaying User Process Memory
process data
paged kernel
paged kernel
wired kernel
wired kernel
region
stack
stack fence
stack
stack fence
7FFEA000
7FFEC000
7FFF4000
7FFF5000
7FFF8000
00002000
00008000
00001000
00003000
00001000
000037A9
FFFFF150
Figure 7-2 displays the output of the display_memory_usage request for
Continuum-series modules in graphical form. Note that the sections in the user process
space are not drawn to scale.
00002000
Code
00359000
Internal Static
003C3000
External Static
003C9000
Symbol Table
004BFC50
Maps, String Pool, and
Program Module Header
004D8000
User Stackgrows
00CD0000
Process Fence
00CD8000
Available for Stack or Heap Growth
3FE4E030
User Heapgrows
7FF2A000
Process Heap
7FFAA000
Process Data Region Heap
7FFEA000
Process Data Region
7FFEC000
Paged Kernel Stackgrows
7FFF4000
Paged Kernel Stack Fence
7FFF500
Wired Kernel Stackgrows
7FFF8000
Wired Kernel Stack Fence
Figure 7-2. Continuum-Series Module User Process Space
Requests That Display Process Information
7-11
Displaying User Process Memory
7-12
VOS System Analysis Manual (R073)
Chapter 8
Analyze System Commands
and Requests
8-
This chapter describes the analyze_system command and many of the
analyze_system requests.
The Examples section of most request descriptions explains column headings and
other elements of the output. In most cases, abbreviations or acronyms that appear in
the output are described in Appendix A.
The output format of every analyze_system request is subject to change. Therefore,
the examples shown for any of the requests documented here may differ slightly from
the output format that you see when you use the analyze_system command.
Because of the length of the output of some requests, the sample output shown in this
manual is often an excerpt from the actual output.
Analyze System Commands and Requests
8-1
analyze_system
analyze_system
Privileged
Purpose
This command enables you to use requests that display or set values in VOS memory.
Display Form
-------------------------------- analyze_system --------------------------------request_line:
-module:
-quit:
no
-c_expressions: no
Command-Line Form
analyze_system [-request_line string]
[-module [-module_name]]
[-quit]
[-c_expressions]
Arguments
* -request_line string
Specifies an analyze_system request or VOS internal command. If the string
contains spaces, apostrophes, or parentheses, it must be enclosed in apostrophes.
If you do not specify a request with the -request_line argument when you issue
the analyze_system command, the command displays the as: prompt.
* -module [-module_name]
The module that analyze_system is to analyze. If you do not specify this
argument, analyze_system uses the current module. If you specify this
argument but do not specify a value for -module_name, the command is initialized
in undefined mode.
8-2
VOS System Analysis Manual (R073)
analyze_system
* -quit
<CYCLE>
Exits the analyze_system command. Use this argument with -request_line
to return to command level immediately after performing the specified request.
* -c_expressions
Specifies that internal expressions are evaluated using a C-language line parser
instead of the traditional analyze_system line parser. The C-language line
parser implements a subset of the keywords and commands supported by the
traditional analyze_system parser.
Explanation
The analyze_system command enables you to use requests that display or set
values in VOS memory. For a full summary of the activities that you can perform with
the analyze_system command, see Chapter 1. When you issue the
analyze_system command, it displays the as: prompt, at which you can specify a
request or a VOS internal command. To exit the loop and return to command level,
issue the quit request.
You can issue internal commands with the -request_line argument to
analyze_system and at the as: prompt. However, you must precede the command
with two dots (..), as shown in the Examples section.
The VOS help command is a VOS internal command that lists the VOS internal
commands. These commands are also listed in Appendix B.
You can issue multiple requests or internal commands on one request line; they must
be separated by a semicolon. However, you cannot mix requests and internal
commands on the same line.
Examples
The following example sets the module to be analyzed.
analyze_system -request_line display_memory_usage
The next example logs output from the analyze_system command to a file called
as_log in the current directory. The VOS internal command start_logging is used
to begin logging. The as_log file has a suffix containing the current date that is
generated by the (date) command function.
analyze_system -request_line ..start_logging as_log.(date)
Note that the -request_line string is enclosed in apostrophes. These are required
because the request line contains spaces.
Analyze System Commands and Requests
8-3
cache_meters
cache_meters
8-
Purpose
This request displays the cache meters.
Display Form
------------------------------- cache_meters -----------------------------------no
-all:
-reset: no
Command-Line Form
cache_meters
[-all]
[-reset]
Arguments
* -all
<CYCLE>
Displays all of the cache meters. By default, only the essential meters are
displayed.
* -reset
<CYCLE>
Resets the cache meters to 0. When you reset the meters, the request does not
display a report. By default, the meters are relative to the current bootload session.
Explanation
In disk I/O, cache is an area of memory where information read from disk is stored. The
cache_meters request displays and, optionally, resets the cache meters in your
system. This request displays the percentage of reads and writes found in the cache
(hits) versus those not found in the cache (misses).
A cache hit occurs when a process performs a read or write operation and the
requested file block is in the cache. A cache miss occurs when a process performs a
read or write operation, the requested file block is not in the cache, and the system has
to access the block from the disk. The ratio of hits to misses shows how efficiently the
8-4
VOS System Analysis Manual (R073)
cache_meters
system is using the cache. To achieve high performance, a cache should have a hit rate
of 90 percent or above, although a low hit rate is not serious if very few accesses are
made to a cache.
You should assess the cache hit ratio on the basis of the size of your database, the
maximum number of physical buffers, and the distribution of accesses to your
database. You can raise the cache size limits with the set_tuning_parameters
command. If you increase the cache size, you can monitor whether you are improving
application and system performance by using:
the display_system_usage command and page_meters request to track the
system page fault rates
the disk_meters request to track the percentage of time the disk is busy
the analyze_pc_samples command to track the applications transaction per
second rate.
When you specify cache_meters -reset, the command affects only the current
process executing analyze_system and the cache_meters request. The
command records the reset in the file (home_dir)>as_meter_file. If more than
one process shares the same home directory, only one process at a time can reset a
metering request. If the file as_meter_file exists, it is reopened when you re-enter
analyze_system. To use the meters set since boot time, delete the file
as_meter_file.
Examples
In the following example, the cache_meters request displays cache data for a
one-minute time period. The table following the example describes the columns and
fields that appear in the output.
as:
cache_meters -reset; sleep
Metering time:
File
Data
Indirect
Index
Data
Indirect
Directory Data
Indirect
Totals
as:
-minutes 1; cache_meters
0:01:00
Hits
15/100.00%
0/ 0.00%
3/100.00%
0/ 0.00%
653/ 86.49%
0/ 0.00%
671/ 86.80%
Misses
0/ 0.00%
0/ 0.00%
0/ 0.00%
0/ 0.00%
102/ 13.51%
0/ 0.00%
102/ 13.20%
Total
15/ 1.94%
0/ 0.00%
3/ 0.39%
0/ 0.00%
755/ 97.67%
0/ 0.00%
773
The analyze_system Command and Requests
8-5
cache_meters
Column/
Field
Description
Hits
The number of cache hits and the hits as percentage of the hits and
misses, totaled together.
Misses
The number of cache misses and the misses as percentage of the hits and
misses totaled together.
Total
The total number of hits and misses, and the percentage of hits and
misses, for this type of cache access (for example, file data, file indirect).
File
The number and percentage of accesses in this category, of file hits,
misses and totals found in the cache (hits), and not found in cache
(misses). These are separated into the categories Data (the actual block
containing the information) and Indirect (blocks of disk addresses that are
the backbone of the file structure).
Index
The number and percentage of accesses in this category, of index hits,
misses and totals found in the cache (hits) and not found in cache (misses).
These are separated into the categories Data (the actual block containing
the information) and Indirect (blocks of disk addresses that are the
backbone of the file structure).
Directory
The number and percentage of accesses in this category, of directory hits,
misses and totals found in the cache (hits), and not found in cache
(misses). These are separated into the categories Data (the actual block
containing the information) and Indirect (blocks of disk addresses that are
the backbone of the file structure).
Related Information
For more information about cache usage, see the description of the
dump_cache_info request in this manual and the set_tuning_parameters
command in the manual VOS System Administration: Administering and Customizing
a System (R281). For information about other system functions that may be affected
by the cache, see the description of the disk_meters and page_meters requests in
this manual and the display_system_usage and analyze_pc_samples
commands in the VOS Commands Reference Manual (R098).
8-6
VOS System Analysis Manual (R073)
change_iop_dump_switch
change_iop_dump_switch
8-
Purpose
This request enables you to specify one of eight dump types for I/O processors and I/O
adapters on a module.
Display Form
-------------------------- change_iop_dump_switch -------------------------------iop_slot:
dump_type: DEVICE_ONLY
-ioa_slot:
Command-Line Form
change_iop_dump_switch iop_slot
[dump_type]
[-ioa_slot number]
Arguments
* iop_slot
The I/O processor slot number.
Required
* dump_type
<CYCLE>
Specifies the type of dump. The default value for individual I/O adapters on module
reboot is NO_DUMP, and the default value for individual I/O processors on module
reboot is DEVICE_ONLY. The following table contains dump switch values and a
description of each value.
The analyze_system Command and Requests
8-7
change_iop_dump_switch
8-8
Dump Switch
Description
DEVICE_ONLY
If the specified device fails, the generated dump
contains data only from that device. For example, if an
I/O processor fails with this dump switch, only that I/O
processor is dumped, and no I/O adapters are dumped.
IOP_SINGLE_IOA
If the specified I/O adapter fails, the generated dump
contains only data from the I/O adapter and its
associated I/O processor. You cannot specify this value
for an I/O processor alone.
SELECTED_IOAS
If the specified device fails, the generated dump
contains data from the associated I/O processor and
any I/O adapters that have dump switch values other
than NO_DUMP.
IOP_ALL_IOAS
If the specified device fails, the generated dump
contains data from the associated I/O processor and all
I/O adapters (regardless of their dump switch values).
SYSTEM_DUMP_AND_GO
If the specified device fails, the generated dump
contains data from the system. The generated dump
does not contain data from an I/O adapter unless an I/O
adapter caused the dump. The system will try to resume
operation after the dump.
SYSTEM_DUMP_AND_GO_
SELECTED_IOA
If the specified device fails, the generated dump
contains data from the system and the specified I/O
processor. In addition, if the I/O processor caused the
dump, then the dump contains data from the I/O
adapters on the associated I/O processor that have
dump switch values other than NO_DUMP. If an I/O
adapter caused the dump, then the dump also contains
data from that I/O adapter, regardless of the dump
switch setting for the I/O adapter. The system will try to
resume operation after the dump.
SYSTEM_DUMP_AND_GO_
ALL_IOA
If the specified device fails, the generated dump
contains data from the system, the specified I/O
processor, and all associated I/O adapters, regardless
of the dump switch setting for particular I/O adapters.
FULL_SYSTEM
If the specified device fails, the generated dump
contains a full system dump. The system reboots
afterwards.
NO_DUMP
If the specified device fails, it does not generate a dump.
VOS System Analysis Manual (R073)
change_iop_dump_switch
* -ioa_slot number
Specifies a slot number of an I/O adapter for which you will specify a dump switch.
If you do not specify an I/O adapter slot number, the specified dump switch applies
to the I/O processor.
Explanation
The change_iop_dump_switch request enables you to specify one of eight dump
types for I/O processor and I/O adapters on a module. When an I/O processor or I/O
adapter fails, VOS reads its corresponding dump switch value and takes the
appropriate action.
NOTE
This request assumes that 32 I/O adapters are associated
with each I/O processor, as is the case on
Continuum-series modules. On XA/R-series modules,
which only support 16 I/O adapters per I/O processor, it is
possible to change the I/O processor dump switch values
of nonexistent I/O adapters. Making such a change will
not affect system operation.
Examples
In the following example, the change_iop_dump_switch request sets the I/O
adapter dump switch for I/O adapter 5 on I/O processor 29.
as: change_iop_dump_switch 29 -ioa_slot 5 -form
Related Information
For information about listing existing dump switches, see the description of the
list_iop_dump_switch request.
The analyze_system Command and Requests
8-9
check_area
check_area
8-
Purpose
This request checks the internal structure of a heap for consistency.
Display Form
---------------------------------- check_area ---------------------------------area_header_address:
-force_address:
-heap:
-memory_pool:
0
Command-Line Form
check_area area_header_address
[-force_address address]
[-heap heap_name]
[-memory_pool pool]
Arguments
* area_header_address
Required
The address of the heap for which information is to be displayed. You must specify
a value for either this argument or the -heap argument; you cannot select both.
(Use the dump_pdr request to display the addresses of the user and pdr heaps.
For information on address formats, see Chapter 3.)
* -force_address address
The address of a block at which to resume checking an area, after a previous
invocation of check_area with the same area_header_address or -heap has
reported an error.
8-10
VOS System Analysis Manual (R073)
check_area
* -heap heap_name
<CYCLE>
The heap that will be checked. The heap_name value can be one of the following:
Value
Description
paged
The paged heap
wired
The wired heap
comm
The communications heap
I/O
The I/O heap. XA/R: 24-bit addressing
Continuum: at least 32-bit addressing
high_I/O
High physical memory I/O heap. XA/R: 29-bit addressing
Continuum: Not applicable.
pdr
The process data region heap of the selected process
user
The user heap of the selected process
iop
The I/O processor heap (available only in the I/O processor modes)
ioa
The I/O adapter heap (available only in the IOA mode))
You must specify a value for either this argument or the area_header_address
argument; you cannot select both. (When you use the display form, the value field
for the -heap argument is blank, indicating no value, which is the default for this
<CYCLE> field.)
* -memory_pool pool
Specifies the memory pool to which the heap belongs. The allowed values are 0
or 1. The default value is 0. Specify the same memory pool as that used by the
process that owns the heap. This argument has significance mainly on
Continuum-series modules, where memory is usually local to the CPU and,
therefore, the heaps in different memory pools may have completely different
contents.
The analyze_system Command and Requests
8-11
check_area
Explanation
Use the -force_address argument only if you have previously invoked
check_area with area_header_address or -heap, and the request reported an
error. To prepare for its use, perform the following steps.
1. Note the first bad block address displayed in the original check_area output.
2. Using the display request, scan from that address about 200x bytes, and look for
the next blocks tag_chars field. The start of the block has the following format.
prev_size
tag_chars
prev_tag_chars
bin (31)
char (2) aligned
char (2) aligned
3. When you find the tag_chars field, calculate the address of the prev_size field
using the following formula.
address of tag_chars - 4 bytes
You can now invoke check_area with -force_address, using the address
calculated in Step 3 as the address to be forced. (Note that you must also enter
either the area_header_address or -heap argument.) The request will now
resume integrity checking from the specified address.
Examples
There is no output if the data used for heap management is consistent. If the data is
inconsistent, the output shows which part of the data has been overwritten.
In the following example, the check_area request displays the data portion in the
paged heap that has been overwritten.
as: check_area -heap paged
check_area: This command may produce unreliable results on a live module
check_area: Bad area, failure: block.prev_free
prev block address: 005D7BCC (00082BCC)
block was most recently a (LC)
Lock Info
bad block address: 005D7C60 (00082C60)
block was most recently a (FI)
File Info Block
check_area: Bad area, failure: block.prev_free
free chain thread is corrupt in bucket 1
bad block address: 005D9F30 (00084F30)
block was most recently a (KC)
Transaction Key Changes
8-12
VOS System Analysis Manual (R073)
check_area
check_area: Bad area, failure: block.prev_free
free chain thread is corrupt in bucket 2
bad block address: 00667978 (00112978)
block was most recently a (RR)
Transaction Record Read Lock
check_area: Bad area, failure: block.prev_free
free chain thread is corrupt in bucket 3
bad block address: 0066AAB0 (00115AB0)
block was most recently a (RW)
Transaction Record Write Lock
check_area: Bad area, failure: block.prev_free
free chain thread is corrupt in bucket 5
bad block address: 0056FC5E (0001AC5E)
block was most recently a (KP)
Key Position
The analyze_system Command and Requests
8-13
clone_command
clone_command
8-
Purpose
This request executes a single external command on nonwindow terminal devices.
Display Form
-------------------------------- clone_command ------------------------------command_line:
-execute_start_up: yes
Command-Line Form
clone_command command_line
[-no_execute_start_up]
Arguments
* command_line
The external command to execute. If the external command contains arguments
and you are using the command-line form of the request, enclose the external
command in single quotes. See the Explanation section for an example of the use
of single quotes. Otherwise, single quotes are not needed.
* -no_execute_start_up
<CYCLE>
Specifies that the subprocess portion of your start_up.cm file is not executed
when the request executes the external command. The default value is no. If you
specify yes, the request executes the subprocess portion of your start_up.cm
file.
Explanation
If you are not a window terminal user, you can issue the clone_command request to
execute a single external command. External commands are command macros and
program modules located in various command libraries.
8-14
VOS System Analysis Manual (R073)
clone_command
Examples
In the following example, the clone_command request displays the output of the
list_users command.
as: clone_command list_users J*
Joe_Smith.Eng
* Joe_Smith.Eng
as:
Related Information
See the discussion of the login command in Executing External VOS Commands
in Chapter 2.
The analyze_system Command and Requests
8-15
delete_dump
delete_dump
8-
Purpose
This request deletes a file containing a dump image.
Display Form
----------------------------------- delete_dump -------------------------------dump_number:
-path_name:
Command-Line Form
delete_dump dump_number
[-path_name dump_path_name]
Arguments
* dump_number
A number identifying the dump file to be deleted. Dump numbers are displayed by
the list_dumps request. You cannot specify both this argument and the
-path_name argument.
* -path_name dump_path_name
The path name of the dump file to be deleted. You may omit the suffix .dump. You
cannot specify both this argument and the dump_number argument.
Explanation
If you delete the dump you are currently using, the deletion is deferred until you are no
longer using the dump (for instance, after issuing the quit request). You cannot delete
a dump that someone else is using.
Unless someone else is using a dump, you can also delete the dump by deleting the
file containing the dump image (using the delete_file command). The dump file can
be found in >Overseer>dumps.
8-16
VOS System Analysis Manual (R073)
delete_dump
Examples
In the following example, the list_dumps request displays the available dump files
and dump numbers, and then the delete_dump request deletes the specified dump
file.
as: list_dumps
Dumps for %sys#m3, located in %sys#m3>Overseer>dumps:
1) system.95-05-19.14:34:37.c.dump
2) system.95-06-28.07:17:00.c.dump
as: delete_dump 1
CAUTION
Be certain that list_dumps has been invoked recently
for the desired module, or you might delete the wrong
dump.
For example, the following request sequence would delete
dump 1 on module m6, not module m19, even though m19
might be the current module for the analyze_system
process.
as: list_dumps -module m19
...
as: list_dumps -module m6
...
as: delete_dump 1
The analyze_system Command and Requests
8-17
disassemble
disassemble
8-
Purpose
This request displays a specified number of bytes of storage in assembly language
format.
Display Form
----------------------------------- disassemble -------------------------------start_address: *
n_bytes:
Command-Line Form
disassemble
[start_address]
[n_bytes]
Arguments
* start_address
The address at which to begin the display. This value can be in any of the formats
for address values of a program. If you do not supply a value, the display begins at
the last address value referenced in a disassemble or display request. (For
information on address formats, see Chapter 3.)
* n_bytes
The number of bytes to be displayed. The default is all bytes in the requested line
number.
Explanation
The disassemble request shows output in assembly language and hexadecimal
format, while the display request shows output in hexadecimal and ASCII format. On
Continuum-series modules, the disassemble request displays data and instructions
in the same order as the display request. On XA/R-series modules, the
disassemble request displays instructions in the order in which they are executed,
8-18
VOS System Analysis Manual (R073)
disassemble
while the display request displays instructions in the order in which they are stored.
For more information about the display of instructions on XA/R-series modules, see the
section Displaying and Setting Data and Instructions in Memory in Chapter 6.
Example
In the following example, the disassemble request displays machine code in a
module called process_control starting at line number 681.
as: disassemble process_control@681
/* Line 681
806EAE10 E40C0001 or
+1,r0,r12
806EAE14 9F400000 subs
+0,r26,r0
806EAE18 1C7F6736 st.s
r12,-202(r3)
806EAE1C 7800000B bnc
+48(pc)
806EAE20 14F50009 ld.l
+8(r7),r21
806EAE24 5EA00809 bte
+1,r21,+40(pc)
=806EAE4C
=806EAE4C
The analyze_system Command and Requests
8-19
disk_lock_meters
disk_lock_meters
8-
Purpose
This request displays the disk lock meters.
Display Form
------------------------------- disk_lock_meters -----------------------------reset: n o
-report: yes
Command-Line Form
disk_lock_meters
[-reset]
[-no_report]
Arguments
* -reset
<CYCLE>
Resets the disk lock meters to 0. When you reset the meters, the request does not
display a report unless you specify that one be displayed. By default, the meters
are relative to the current bootload session.
* -no_report
<CYCLE>
Specifies that the request not display output. By default, the request displays a disk
lock meters report.
Explanation
Specifying disk_lock_meters -reset affects only the current process executing
analyze_system and the disk_lock_meters request. The command records the
reset in the file (home_dir)>as_meter_file. If more than one process shares the
same home directory, only one process at a time can reset a metering request. If the
file as_meter_file exists, it is reopened when you re-enter analyze_system. To
use the meters set since boot time, delete the file as_meter_file.
8-20
VOS System Analysis Manual (R073)
disk_lock_meters
Examples
In the following example, the disk_lock_meters request displays disk lock counters
accumulated since the module was last booted.
as: disk_lock_meters
Total metering time -- 351:00:07
lock
lock
lock
lock
all
dctl
cs q
dq
Q runs
as:
Count
0
380155272
0
0
1156
/sec
0
300
0
0
%l/f
0.00
0.40
0.00
0.00
7.87 avg ms
The following table describes the columns that appear in the output of the previous
example.
Column
Description
Count
The total number of times the disk meters are locked.
/sec
The number of times per second the meters are locked.
%l/f
The percentage of time the disk spun before getting the lock.
The following table describes the fields that appear in the output of the previous
example.
Field
Description
lock dctl
The number of disk control locks issued.
lock cs q
The number of cow stomach queue locks issued for the disk. That
is, if a disk is already locked when the kernel wants to perform
some work on its behalf, a description of the work to be performed
is stored in a cow stomach until the disk becomes unlocked. When
the disk is unlocked, the work described in the cow stomach queue
is performed.
lock dq
The numbers of disk queue locks issues.
Q runs
The number of background processes running on disk Q in a polling
state.
The analyze_system Command and Requests
8-21
disk_lock_meters
Related Information
For more information about disk performance, see the description of the
disk_meters request in this manual and the description of the
display_disk_info command in the VOS Commands Reference Manual (R098).
8-22
VOS System Analysis Manual (R073)
disk_meters
disk_meters
8-
Purpose
This request displays the disk meters for a specified logical disk or all disks on a
module.
Display Form
------------------------------- disk_meters -----------------------------disk:
-reset: no
-brief: no
-report: yes
Command-Line Form
disk_meters
[-disk disk_name]
[-reset]
[-brief]
[-no_report]
Arguments
* -disk disk_name
The name of the logical disk to be metered.
* -reset
<CYCLE>
Resets all disk meter values to the current value. After you reset the meters, all
subsequent invocations of disk_lock_meters will be relative to the last time the
meters were reset. By default, the meters are relative to the current bootload
session.
When you reset the meters, the request does not display a report unless you
specify that one be displayed. By default, the metering values are not reset.
The analyze_system Command and Requests
8-23
disk_meters
* -brief
<CYCLE>
Displays the essential disk metering information. By default, the request displays
detailed disk metering information.
* -no_report
<CYCLE>
Specifies that the request not display output to report metering status. By default,
the request displays output.
Explanation
The disk_meters request enables you to display and reset the disk meters for a
specified logical disk or all disks on a system. This request displays the percentage of
time in which a disk is busy (%BSY or %busy). You can use this information to determine
if I/O load is distributed evenly across the disks on the system and the response time
for particular disks.
If different disks on the system are busy for widely different periods of time, this
indicates uneven utilization loads that can lessen performance. To balance an uneven
load, spread data files over several disks. If you have one large data file, consider using
a multimember disk or physically splitting the file into several smaller files. Note that if
you use multimember disks, load balancing is automatic. Remember, however, that the
boot disk should be only a single volume.
NOTE
Lack of free disk space can lower performance. To
determine the quantity of remaining disk space, the disk
type and status, issue the VOS display_disk_info
command.
To calculate disk response time, use the following formula, where the service_time
can be found in the sales specifications for the disk.
response_time = service_time / (1 - %busy)
When you specify disk_meters -reset, the request resets the meters to the current
values executing analyze_system and the disk_meters request. The command
records the reset in the file (home_dir)>as_meter_file. If more than one process
shares the same home directory, only one process at a time can reset a metering
request. If the file as_meter_file exists, it is reopened when you re-enter
analyze_system. To use the meters set since boot time, delete the file
as_meter_file.
8-24
VOS System Analysis Manual (R073)
disk_meters
Examples
In the following example, the disk_meters request displays disk counters for a
one-minute period in the -brief format.
as: disk_meters -reset; sleep -minutes 1; disk_meters -brief
Total metering time -0:01:01
%
busy
4
4
0
0
as:
atb ms/ < % type >
errors
con con ret Nrm Rcv da dv fa dm
1649 61
0 100
0 0 0 0 0
1649 60
0 100
0 0 0 0 0
3588 19
0 100
0 0 0 0 0
5545 14
0 100
0 0 0 0 0
devID
drive
04/01/01/01 m19.0.pri
04/02/01/01 m19.0.sec
04/01/01/04 m19_user.1.pri
04/01/01/03 m19_user.0.pri
In the following example, the disk_name value is specified with the disk_meters
request. The disk_name value can be obtained from the output of disk_meters
-brief. The request displays disk meters for the specified disk for a 5.5-minute
period.
as: disk_meters -disk m19.0.pri
Total metering time -0:05:39
Disk Device
Connects
I/Os
Interrupts
Average
Reads
Writes
04/01/01/01, m19.0.pri
Count
/sec ATBms BSYms
345
1.02
983
43
894
2.64
379
894
2.64
379
# Qd
0.00
Seek
N/A
%BSY
4.38
Start I/O
%SI/O
470
52.57
/con
2.6
Total
121
1637
Errors (recov/fatal/dma)
0/0/0
as:
The analyze_system Command and Requests
8-25
disk_meters
The following table describes the columns that appear in the output of the previous
example.
Column
Description
Count
The number of metered events: connects, I/Os, or interrupts.
/sec
The amount of time that an event has been metered.
ATBms
The average time in microseconds between metered events.
BSYms
The number of milliseconds that the disk is busy.
%BSY or %busy
The percentage of time that the disk is busy. The most
important performance factor.
Start I/O
The number of times that new I/O was started at interrupt time.
%SI/O
The percentage of time that something is in the queue after the
current interrupt finishes processing.
# Qd (Average)
The average number of metered queued events.
Seek (Average)
The average seek distance in cylinders.
/con (Average)
The average number of metered events per connect.
The following table describes the fields that appear in the output of the previous
example.
(Page 1 of 2)
8-26
Field
Description
Disk Device
The logical disk for which meters are displayed and/or reset.
Connects
The number of connects that occurred on that disk during the
metering period.
I/Os
The number of I/Os that occurred on that disk during the
metering period.
Interrupts
The number of interrupts that occurred on that disk during the
metering period.
Reads (Total)
The total number of reads that occurred on that disk during the
metering period.
Writes (Total)
The total number of writes that occurred on that disk during the
metering period.
VOS System Analysis Manual (R073)
disk_meters
(Page 2 of 2)
Field
Description
Errors
(recov/fatal/dma)
recov: the number of recoverable errors.
fatal: the number of unrecoverable errors.
dma: (D20x drives only): the number of times the bus was busy
and the D20x drive was unable to unload its buffers quickly
enough.
Related Information
For more information about disk performance, see the description of the
disk_lock_meters request in this manual and the description of the
display_disk_info command in the VOS Commands Reference Manual (R098).
The analyze_system Command and Requests
8-27
display
display
8-
Purpose
This request displays a specified number of bytes of data in both hexadecimal and
ASCII or EBCDIC characters.
Display Form
------------------------------------- display ---------------------------------*
start_address:
n_bytes:
-hex:
yes
-ebcdic:
no
-control_chars:
no
-physical:
no
-io:
no
-data_cache:
no
-instruction_cache: no
-cache_tags:
no
-cpu_number:
0
Command-Line Form
display
[start_address]
[n_bytes]
[-no_hex]
[-ebcdic]
[-control_chars]
[-physical]
[-io]
[-data_cache]
[-instruction_cache]
[-cache_tags]
[-cpu_number cpu_number]
8-28
VOS System Analysis Manual (R073)
display
Arguments
* start_address
The address at which to begin the display. This value can be in any of the formats
for address values of a program. If you do not specify a value, VOS begins the
display at the last address value referenced. For information on address formats,
see Chapter 3.
* n_bytes
The number of bytes to display. The default value is four bytes, and the default
number base is decimal. However, the value can also be specified in hexadecimal
digits if it is followed by x; for example, 100x to specify 256 bytes.
* -no_hex
<CYCLE>
Suppresses the hexadecimal representation of the selected bytes. If you omit this
argument, VOS displays the hexadecimal representation of the selected bytes.
* -ebcdic
<CYCLE>
Displays the EBCDIC interpretation of the selected bytes. If you omit this argument,
VOS displays the ASCII interpretation of the bytes.
* -control_chars
<CYCLE>
Displays the ASCII names of nonprinting (control) characters in the ASCII or
EBCDIC part of the displayed output. If you omit this argument, VOS displays
control characters as periods.
* -physical
<CYCLE>
Interprets the starting address you specify as a physical address. If you omit this
argument, VOS interprets the starting address as a virtual address.
* -io
*
*
*
*
<CYCLE>
Interprets the address to be displayed as an I/O space address. This argument is
only valid for XA/R-series and Continuum-series modules.
-data_cache
-instruction_cache
-cache_tags
-cpu_number cpu_number
For engineering use only.
<CYCLE>
<CYCLE>
<CYCLE>
Examples
In the following examples, the output of the display request is shown when the
request is issued with various arguments.
The first column in the output is the virtual address (or the physical address, if the
-physical argument is used) and the second column is the offset from that address.
The next four columns display the storage data in hexadecimal format. Finally, the
The analyze_system Command and Requests
8-29
display
storage data is displayed in a format determined by the -ebcdic and
-control_chars arguments. Each nonprinting character is represented by a period.
In the following example, the display request is issued with the start_address
and n_bytes arguments specified.
as: display 04823830 60
04823830
04823840
04823850
04823860
as:
00
10
20
30
696F6E73
00000000
01000005
00000000
00000000
00000000
6C6F6769
00000000
00000000 00000000 | ions...........|
06008000 00000514 | ...............|
6E6F6769 6E180000 | ...loginogin...|
00000000
| ...........
|
In the following example, the display request is issued with the hexadecimal
representation of the data suppressed.
as: display 04823830 60 -no_hex
04823830 00
04823868 38
as:
| ions......................loginogin.|
| ....
|
In the following examples, the display request is issued first with the hexadecimal,
then with the EBCDIC, expression of the 128 (80x) bytes.
as: d 80ab58c0 80x
80AB58C0 00 40404040
80AB58D0 10 969540A3
80AB58E0 20 A3899695
80AB58F0 30 C1D4C540
80AB5900 40 C5D94B15
80AB5910 50 40C69699
80AB5920 60 00000000
80AB5930 70 00000000
8-30
40404015
96408195
6B40A3A8
81958440
40154040
40D6C6C6
00000000
00000000
4040E396
40819797
978540A3
A3888595
D6C6C6C9
00000000
00000000
00000000
40939687
93898381
888540D5
40C5D5E3
C3C54060
00000000
00000000
00000000
|@@@@@@@.@@..@...|
|..@..@..@.......|
|....k@....@...@.|
|...@...@....@...|
|..K.@.@@......@`|
|@...@...........|
|................|
|................|
as: d 80ab58c0 80x -ebcdic
80AB58C0 00 40404040 40404015
80AB58D0 10 969540A3 96408195
80AB58E0 20 A3899695 6B40A3A8
80AB58F0 30 C1D4C540 81958440
80AB5900 40 C5D94B15 40154040
80AB5910 50 40C69699 40D6C6C6
80AB5920 60 00000000 00000000
80AB5930 70 00000000 00000000
as:
4040E396
40819797
978540A3
A3888595
D6C6C6C9
00000000
00000000
00000000
40939687
93898381
888540D5
40C5D5E3
C3C54060
00000000
00000000
00000000
|
. To log|
|on to an applica|
|tion, type the N|
|AME and then ENT|
|ER.. . OFFICE -|
| For OFF........|
|................|
|................|
VOS System Analysis Manual (R073)
display
In the following example, the display request is issued with ASCII names of
non-printing characters shown.
as: display 00F8D000 60 -control_chars
00008100
00
881C200A E80001C8 341C384C 37DA3EA1
00008110
10
B49902C8 08030258 E400E115 B417000A
00008120
20
881C200A E8000188 341C384E 37DA3EA1
00008130
30
B49902C0 08030258 E400E115
|.F L.UO.4F8L7.>.|
S F LH S
S ES N N EN
|..T.BTTX.U.A.TUL|
X SXX L K BLF
NS
|.F L.UO.4F8N7.>.|
S F LH S
S ES N N
|..T.BTTX.U.A
|
X SXX L K
as:
The analyze_system Command and Requests
8-31
display_alignment_faults
display_alignment_faults
8-
Purpose
This request displays the contents of the log created with the
log_alignment_faults request.
Display Form
----------------------------- display_alignment_faults -------------------------ptep:
-brief: yes
Command-Line Form
display_alignment_faults ptep
[-no_brief]
Arguments
* ptep
Displays only alignment faults for the specified process table entry pointer (PTEP).
You can obtain this value from the who request. Another way of displaying only
alignment faults for the specified process is to issue the process request and
specify the process number associated with the PTEP before issuing the
display_alignment_faults request. If you do not specify a PTEP or issue the
process request prior to issuing this request, the display_alignment_faults
request displays alignment faults for all processes.
* -no_brief
In addition to the information displayed with -brief argument, displays the PTEP
of the process that caused each alignment fault. By default, the request only
displays information about the frequency and instruction location of the fault.
Explanation
The display_alignment_faults request displays the contents of the log created
with the log_alignment_faults request. This log shows the total number of
alignment faults recorded since logging was enabled or last reset, and then a list of up
8-32
VOS System Analysis Manual (R073)
display_alignment_faults
to 256 PTEPs (if you specified -no_brief), fault addresses, and, in some cases, the
source code line numbers.
Before issuing this request, issue the who request to obtain the process number and
PTEP of the process that you want to analyze. Then issue the process request and
specify the process number of the process that you want to analyze.
NOTE
It is easiest to debug alignment faults generated by an
executing application if that application is compiled with
-table. Otherwise, the compilers optimizer may move
code, and the source code line number displayed with this
request may not be correct. If concerns about decreased
performance prevent you from using -table, compile the
application with -full, which generates an assembly
language listing, and bind it with -map. These listings will
help you associate a fault instruction with a source code
line number.
An alignment fault occurs when an i860 RISC processor and/or one of the HPPA family
of RISC processors is asked to access a multiple-byte datum on an address that does
not appropriately match the datums byte size. To prevent alignment faults, a two-byte
datum must start on an even address, a four-byte datum must start on an address that
is evenly divisible by 4, an eight-byte datum or floating-point number must start on an
address that is evenly divisible by 8, and a 16-byte reference must start on an address
that is divisible by 16.
The VOS compilers will detect alignment problems and add bytes between data
structures so that the data structures start at the correct address. If you specify
-mapping_rules longmap/check, or use $longmap or $shortmap in the
structure definition, the compiler issues ADVICE messages about where padding
occurred. If you specify -mapping_rules shortmap, the compiler will generate
extra instructions to handle alignment faults so that the process will not invoke the VOS
fault handler at runtime. The default -mapping_rules value is site settable.
If an i860 RISC processor and or one of the HPPA family of RISC processors detects
an alignment fault, it invokes the VOS alignment fault handler. This fault handler
performs the read or write and returns to the program as if the alignment fault never
happened. The effect is that the data store takes much more time to execute than if the
data reference were handled properly. When you issue the log_alignment_faults
request, alignment faults detected by the processor are logged.
The analyze_system Command and Requests
8-33
display_alignment_faults
Examples
In the following example, the display_alignment_faults request displays the
alignment faults logged for a process on an XA/R-series module.
as: log_alignment_faults -reset
as: ..start_process faults
as: match Joe; who
*2618 81FA5880
Joe_Smith.Eng on CPU26
2628 81FA5440
Joe_Smith.Eng on CPU28
as: process 2628
Using process on CPU28.
Current process is 2628, ptep 81FA5440, Joe_Smith.Eng
Process is running on CPU 28 right now; no stack addr known.
as: display_alignment_faults
49 alignment faults have been logged.
Up to 256 will be displayed.
# of times
Fault instruction
47
pc: 80641D40 (atlantic_fast_timer+320)
2
pc: 8043FCDC (allocators+107C, line 649)
Trace complete.
as:
Related Information
See the description of the log_alignment_faults request. For more information
about detecting and resolving alignment faults, see the manuals Migrating VOS
Applications to the Stratus RISC Architecture (R288) and Migrating VOS Applications
to Continuum Systems (R407). For more information about the -mapping_rules
argument used by the VOS compilers, see the VOS Commands Reference
Manual (R098).
8-34
VOS System Analysis Manual (R073)
display_cache_pin_parameters
display_cache_pin_parameters
8-
Purpose
This request displays the pinning status of the disk cache.
Display Form
------------------------- display_cache_pin_parameters ----------------------No arguments required. Press ENTER to continue.
Command-Line Form
display_cache_pin_parameters
Explanation
The display_cache_pin_parameters request displays the cache pinning control
flags and the priority level and pin count for any priority with a nonzero pin count.
Examples
In the following example, the display_cache_pin_parameters request displays
information about the cache pin counts and the setting of the cache-pinning switches.
as:
display_cache_pin_parameters
Cache buffer pinning parameters:
priority
count
5
1
cache pinning switches: enabled
as:
Related Information
See the descriptions of the set_cache_pin_parameters, dump_cache_info, and
dump_cache requests.
The analyze_system Command and Requests
8-35
display_extensible_heap
display_extensible_heap
8-
Purpose
This request displays information about the VOS virtual memory that is assigned to a
system or extensible heap. There are five system heaps: the paged heap, the wired
heap, the communications heap, the I/O heap, and the high physical I/O heap.
Display Form
----------------------------- display_extensible_heap -------------------------info_block_address:
-heap:
-memory_pool:
0
Command-Line Form
display_extensible_heap info_block_address
[-heap heap_name]
[-memory_pool pool]
Arguments
* info_block_address
The address of one of the five system heaps. For information on address formats,
see Chapter 3.
You must specify a value for either this argument or the -heap argument. You
cannot select both.
8-36
VOS System Analysis Manual (R073)
display_extensible_heap
* -heap heap_name
<CYCLE>
Display information about a specified extensible heap. The heap_name value can
be one of the following:
Value
Description
paged
The paged heap
wired
The wired heap
comm
The communications heap
I/O
The I/O heap
high_I/O
The high physical memory I/O heap
You must specify a value for either this argument or the info_block_address
argument. You cannot select both.
* -memory_pool pool
Specifies the memory pool from which to analyze the heap. Allowed values are 0
or 1.
Explanation
The system heaps grow dynamically in the system virtual memory. This growth is
limited by the available virtual and physical memory and by the heap limit.
Examples
In the following example, the display_extensible_heap request displays
information about the wired heap.
NOTE
Parenthetical values shown in the output are relative
offsets from the beginning of the selected heap.
as:
display_extensible_heap -heap wired
Extensible Heap Info Block for Wired Heap 0 at 8083B8B0
Flags:
wired preallocate_vm_pool allocate_err_msg defined
Area address:
Lock info address:
Prealloc VM poolp:
Allocation count:
Free count:
VM high address:
80C00000
80C12680
82028FA0
7354475
7324287
820F8000
The analyze_system Command and Requests
8-37
display_extensible_heap
Map access:
7
Min pages:
1024
Max pages:
-1
Growth per MB:
128
Extend pages:
64
Wired memory owner: 5
Heap tag
W`00
No memory code:
3077
Memory pool:
0
Current section info
Base address:
820B8000
Num pages:
64
Num to wire:
37
Last Heap Allocation Failure Info
tag chars:
ES
caller address: 80443540
time:
00000000 02E42304
Section
1
2
3
4
5
6
7
8
9
....
Begin
80C00000
81398000
813D8000
81418000
81458000
81498000
81518000
81678000
81718000
End
80FCA000
813D8000
81418000
81458000
81498000
814D8000
81558000
816B8000
81758000
AREA at 80C00000 (80C00000)
Next virgin:
Last available:
Free bytes:
Max size:
Free limit:
Dead space:
Area size:
820BC370 (014BC370)
820D2FF0 (014D2FF0)
001CDE20
00030F20
001735FE
0096E180
00B64E70 (2917 pages)
as:
8-38
VOS System Analysis Manual (R073)
display_extensible_heap
The following table describes some important fields that appear in the output of the
preceding example.
Field
Description
Lock info address
The address of the lock information block
Min pages
The initial size of the heap
Max pages
The maximum size of the heap
Extend pages
The maximum number of pages by which the heap is
expanded at one time
Section
The begin and end addresses of each virtual memory section
Next virgin
The place in the heap above which all blocks in the heap are
free
Last available
The maximum address currently usable by the heap
Free bytes
The total number of bytes free throughout the heap
Max size
An estimate of the largest free block This number is never too
low, but it may be too high
Free limit
The number of free blocks that must be available in order for a
limited allocation to succeed
Dead space
The amount of unusable memory between sections of virtual
memory space in extensible heaps
Area size
The current size of the heap
The analyze_system Command and Requests
8-39
display_file
display_file
8-
Purpose
This request displays the contents of a file in the top half of a screen and the request
history and as: prompt on the bottom half of the screen.
Display Form
---------------------------------- display_file -----------------------------file:
-line:
-on:
no
-off: no
Command-Line Form
display_file file
[-line number]
[-on]
[-off]
Arguments
* file
The name of a file to display.
Required
* -line number
Specifies the line number of the line in a file to display. The request displays this
line plus the ten subsequent lines.
* -on
8-40
<CYCLE>
Displays the file last displayed with the display_file request before you issued
the -off argument. Between the use of the -off and -on arguments, you can
issue any number of other analyze_system requests.
VOS System Analysis Manual (R073)
display_file
NOTE
The -on argument will not work if you use -on as a
subsequent abbreviation for another string such as
-module in your abbreviations file.
* -off
Specifies that the file no longer be displayed.
<CYCLE>
Explanation
Use this request to split the screen in order to display the contents of a file in the top
half of a screen and the request history and as: prompt on the bottom half of the
screen.
Examples
In the following example, the display_file request displays the vos_evars file in
the upper half of the screen while enabling to execute other requests in the lower half
of the screen.
1 as:
2 External Variable Map:
3
4 Name
Sx Address
Length
5 ACCESS_ANY_EXEC$ 1 80839C60 00000004
6 ACCESS_INTERLOCK$
7
1 80839C64 00000004
8 ACCESS_IO$
2 8089C194 00000004
9 ACCESS_KERNEL_EXEC$
10
1 80839C50 00000004
11 ACCESS_KERNEL_READ$
---------------------------------------------------------------------Current process is 295, ptep 81BA2600, Joe_Smith.Eng
as: dump_syserr
0 active messages, 638 free.
Total of 64183 logged messages.
Total of 0 lost messages.
as: ..attach_default_output vos_evars
display_pm -external_vars_map
..detach_default_output
as: display_file vos_evars
as:
The analyze_system Command and Requests
8-41
display_file
Related Information
For more information about the display_file request and other requests and
commands for displaying files, see Chapter 2.
8-42
VOS System Analysis Manual (R073)
display_memory_usage
display_memory_usage
8-
Purpose
This request displays information about the use of the virtual address space by the
analyzed process such as the address and size of each area, the current space used
in each heap, and an estimate of the maximum space used in each stack since the
program module running in the analyzed process was started.
Display Form
----------------------------- display_memory_usage -----------------------------decimal: no
Command-Line Form
display_memory_usage
[-decimal]
Arguments
* -decimal
<CYCLE>
Displays area sizes in decimal rather than hexadecimal. (This argument does not
affect addresses, which are always displayed in hexadecimal). By default, area
sizes are displayed in hexadecimal.
Explanation
The display_memory_usage request can help determine an appropriate stack size
and maximum number of tasks for a tasking process by showing how much memory is
consumed by the current configuration.
In the second example in the section Examples, each task stack has used about 4.25
pages, so a stack size of 5 pages (20480 bytes) may be adequate. The user heap has
just under 5 pages allocated with 4 tasks running, for an average of 1.25 pages per
task.
Therefore, each task is using 3 pages of static, 5 pages of stack, and about 2 pages of
heap, for a total of 10 pages. The output shows 63 pages already allocated for those
The analyze_system Command and Requests
8-43
display_memory_usage
purposes ((5 * 3) + (5 * 8) + 8), and an additional 178x pages available. This means
that you may be able to run about 43 static tasks ((63 + 178x) / 10 = 43) in this program
without exceeding the specified 2MB address space.
When making these calculations, use the display_memory_usage request several
times to determine the highest page usage. Remember that the debugger and the
default_error_handler, both of which are used for debugging, require additional
stack space just as if they were subroutines called from the program. Failure to provide
sufficient space greatly hampers program debugging.
Examples
The output of the display_memory_usage request lists, for the analyzed process,
the regions of virtual address space in order of virtual address, giving the address and
size of each region. For heaps, it also displays the number of bytes currently allocated.
For stacks, it displays an estimate of the maximum number of bytes used since the
program running in the analyzed process was started. To make this estimate, VOS
finds the last nonzero byte in the stack region.
For a more detailed breakdown of the code, symbol table, static, and external static
regions, use the bind command with the -map argument; this command is
documented in the VOS Commands Reference Manual (R098).
In the following example, the display_memory_usage request displays memory
usage information for a nontasking process.
area
---code
internal static
external static
symbol table
module map
external variables map
link names map
link map
relocation map
string pool
object dir map
program module header
user_stack
process fence
available for stack or heap growth
user heap
process heap
process data region heap
8-44
VOS System Analysis Manual (R073)
address
-------00002000
0001D000
00022000
00023000
0002EFE0
00030388
00030DD8
00031614
00031788
00031CE4
00031E24
00031E48
00034000
0082C000
00834000
3FFF6030
7FF2A000
7FFAA000
number
of bytes
-------0001A0E8
00004D00
0000001E
0000BFE0
000013A8
00000A50
0000083C
00000174
0000055C
00000140
00000024
00000B56
007F8000
00008000
3F7C2000
3FFCAFFF
00080000
00002000
bytes
used
------
estimated
maximum
bytes
used
-------
00001CF0
00002000
00001140
00001C70
display_memory_usage
process data
paged kernel
paged kernel
wired kernel
wired kernel
as:
region
stack
stack fence
stack
stack fence
7FFEA000
7FFEC000
7FFF4000
7FFF5000
7FFF8000
00002000
00008000
00001000
00003000
00001000
0000366D
FFFFF2D0
In the following example, the display_memory_usage request displays memory
usage information for a process that was bound for five tasks, but is currently using only
one of them.
as:
display_memory_usage
area
---code
task 1 static
task 2 static
task 3 static
task 4 static
task 5 static
shared static
symbol table
module map
external variables map
link names map
link map
relocation map
string pool
object dir map
program module header
user heap
available for stack or heap growth
process fence
task 5 stack
task 4 fence
task 4 stack
task 3 fence
task 3 stack
task 2 fence
task 2 stack
task 1 fence
task 1 stack
process heap
process data region heap
process data region
wired kernel stack fence
wired kernel stack
paged kernel stack fence
paged kernel stack
address
-------00E00000
00E0B000
00E0D000
00E0F000
00E11000
00E13000
00E15000
00E16000
00E1F9F4
00E2078A
00E20B26
00E21054
00E2124C
00E23B96
00E23C66
00E23C7E
00E25000
00E2D000
3F724000
3FEF8000
3FF00000
3FF01000
3FF09000
3FF0A000
3FF12000
3FF13000
3FF1B000
3FF1C000
3FF24000
3FFA4000
3FFE4000
3FFE6000
3FFE7000
3FFE9000
3FFEA000
number
of bytes
-------0000AF32
00002000
00002000
00002000
00002000
00002000
0000001A
000099F4
00000D96
0000039C
0000052E
000001F8
0000294A
000000D0
00000018
00000B56
00008000
3E8F7000
00008000
00008000
00001000
00008000
00001000
00008000
00001000
00008000
00001000
00008000
00080000
00006000
00002000
00001000
00002000
00001000
00008000
estimated
maximum
bytes
bytes
used
used
-------- --------
00001AF0
00000000
00000000
00000000
00000000
0000166B
00000120
000048D0
000009B7
00004307
The analyze_system Command and Requests
8-45
display_memory_usage
In the following example, the display_memory_usage request displays the same
memory usage information as above except that it is in decimal format.
as:
display_memory_usage -decimal
area
---code
task 1 static
task 2 static
task 3 static
task 4 static
task 5 static
shared static
symbol table
module map
external variables map
link names map
link map
relocation map
string pool
object dir map
program module header
user heap
available for stack or heap growth
process fence
task 5 stack
task 4 fence
task 4 stack
task 3 fence
task 3 stack
task 2 fence
task 2 stack
task 1 fence
task 1 stack
process heap
process data region heap
process data region
wired kernel stack fence
wired kernel stack
paged kernel stack fence
paged kernel stack
as:
8-46
VOS System Analysis Manual (R073)
address
-------00E00000
00E0B000
00E0D000
00E0F000
00E11000
00E13000
00E15000
00E16000
00E1F9F4
00E2078A
00E20B26
00E21054
00E2124C
00E23B96
00E23C66
00E23C7E
00E25000
00E2D000
3F724000
3FEF8000
3FF00000
3FF01000
3FF09000
3FF0A000
3FF12000
3FF13000
3FF1B000
3FF1C000
3FF24000
3FFA4000
3FFE4000
3FFE6000
3FFE7000
3FFE9000
3FFEA000
number
of bytes
-------44850
8192
8192
8192
8192
8192
26
39412
3478
924
1326
504
10570
208
24
2902
32768
********
32768
32768
4096
32768
4096
32768
4096
32768
4096
32768
524288
24576
8192
4096
8192
4096
32768
estimated
maximum
bytes
bytes
used
used
-------- --------
6896
0
0
0
0
5739
288
18640
2487
17159
display_memory_usage
The following table describes the regions that appear in the output of the preceding
examples.
(Page 1 of 3)
Value
Description
code
The code region.
symbol table
This region is used by the debugger. It includes all symbols for program
modules that were compiled with -table or -production_table.
For program modules compiled with -no_table and
-no_production_table, it includes only the address of each line of
code. The symbol table area can be eliminated altogether by binding
with -no_table. (Use of -production_table costs nothing in
execution speed or physical memory. Therefore, use
-production_table when compiling unless disk space or virtual
address space is at a premium.)
internal
static
This region is displayed only for a non-tasking process.
external
static
This region is displayed only for a non-tasking process.
task n static
This region is displayed only for a tasking process. It includes internal
static and unshared external static.
shared static
This region is displayed only for a tasking process.
module map,
external
variables
map, link
names map,
link map,
entry map,
program
module header
These six maps are used by the loader and the debugger. They include
the names and addresses of: program modules, external variables,
references to kernel entry points, and entry points that can be found by
name at run time (which are specified in binder control files with the
retain directive). For more information about these maps, use the
display_pm request or display_program_module command.
user heap or
original user
heap
Storage that is allocated and freed dynamically by user code and by
run-time support routines using the subroutines s$allocate and
s$free. The user heap starts at eight pages (32768 bytes) and the
system automatically expands it when necessary. If room is available,
the user stack fence (described later) is moved eight pages at a time.
To see how a heap is being used, issue the scan_area and
dump_area requests.
The analyze_system Command and Requests
8-47
display_memory_usage
(Page 2 of 3)
8-48
Value
Description
user stack
fence
A set of inaccessible virtual pages used to detect stack overflow. This
area can be moved, as described in the explanation of user heap.
Normally, in a multi-tasking process, there are no fences between the
stacks of individual tasks, so the fence only protects against an
overflow of the last tasks stack and against runaway recursion by any
task, but task stack fences can be requested in a bind or task control
file. However, when VOS executes a task switch, it may detect any task
that is beyond the end of its stack.
available for
stack or heap
growth
The area from the stack fence to the lowest page ever used by a stack.
On XA/R-series modules, the heap grows by increasing addresses,
while stacks grow by decreasing addresses. On Continuum-series
modules, the stack grows by increasing addresses, while the heap
grows by decreasing addresses. Thus, the two grow toward each other
into this available area.
user stack
This region is displayed only for a non-tasking process. See the
description of stack frames under the region task n stack.
task n stack
This region is displayed only for a tasking process. Stack frames are
allocated automatically by procedure and block invocations. They are
grow downward on XA/R-series modules and upward on
Continuum-series modules. Stack frames are allocated in a
last-in-first-out manner and hold automatic variables and return
addresses. These stacks are used by user code, run-time support
routines, the debugger, and the parts of the system service subroutines
that run in user mode. To view the contents of a stack, use the
debugger trace request or the stack request.
process heap
Used by VOS to hold process data that can be written in user mode,
including fast file I/O buffers. Use the dump_process_heap request to
display data.
process data
region heap
Used by VOS to hold process data that cannot be written in user mode,
including command processor data and abbreviations. The data stored
in this area can be displayed with the scan_area and dump_area
requests.
process data
region
Used by VOS to hold data about the state of the process. The data
stored in this area can be displayed with the dump_pdr request.
kernel stack
fence
An inaccessible page that protects against kernel stack overflow.
wired kernel
stack
Used by the VOS routines that cannot allow page faults.
VOS System Analysis Manual (R073)
display_memory_usage
(Page 3 of 3)
Value
Description
paged kernel
stack
Used by the VOS kernel-mode routines that are called by this process.
forms storage
Used to communicate between the forms service subroutines and the
terminal interrupt handler.
edit storage
Used to communicate between the editor and the terminal interrupt
handler.
The analyze_system Command and Requests
8-49
display_meter_file_info
display_meter_file_info
8-
Purpose
This request displays information about the current meter file, including its path name.
Display Form
----------------------- display_meter_file_info ----------------------long: no
Command-Line Form
display_meter_file_info [-long]
Arguments
* -long
<CYCLE>
Displays the path name and the author of the current meter file. The output also
displays the date and time when the meter file was last used, last modified, last
saved, and created.
By default (the value no), the output displays only the path name.
Explanation
This request displays the current meter path and information about the current meter
file. The default current meter path is the file as_meter_file in your home directory.
8-50
VOS System Analysis Manual (R073)
display_meter_file_info
Examples
The following examples illustrate the user User.Test issuing the
display_meter_file_info request to obtain information about the default meter
file.
as: display_meter_file_info
Using: %se#eng>Test>User>as_meter_file
as: display_meter_file_info -long
Using: %se#eng>Test>User>as_meter_file
pathname:
%se#eng>Test>User>as_meter_file
last used:
97-01-30 14:38:05 EST
last modified:
97-01-30 14:35:58 EST
last saved:
never
time created:
97-01-30 14:35:58 EST
author:
User.Test
The following examples illustrate the user User.Test issuing the
display_meter_file_info request to obtain information from a meter file in the
users process directory. The process directory has the advantage of being on the
same module as the users process, therefore eliminating network traffic. In the
examples, the process directory is process_dir_dir.
as: display_meter_file_info
Using: %test>process_dir_dir>pd.060CD29A.User>asmf
as: display_meter_file_info -long
Using: %test#>process_dir_dir>pd.060CD29A.User>asmf
pathname:
%test>process_dir_dir>pd.060CD29A.User>asmf
last used:
97-01-30 14:48:05 EST
last modified:
97-01-30 14:45:58 EST
last saved:
never
time created:
97-01-30 14:38:22 EST
author:
User.Test
Related Information
For information about specifying the path name of the meter file, see the description of
the set_meter_file request.
The analyze_system Command and Requests
8-51
display_net_trace
display_net_trace
8-
Purpose
This request displays the contents of the StrataLINK net trace buffer in kernel memory.
Display Form
------------------------------ display_net_trace ----------------------------num-packets: 2 0
-all:
no
Command-Line Form
display_net_trace
[-num-packets number_of_packets]
[-all]
Arguments
* -num-packets number_of_packets
Specifies the number of packets in the tracing buffer that the request should
display. By default, the request displays the most recent 20 entries in the buffer.
* -all
Displays all packets. The default is not to display all packets.
Explanation
The display_net_trace request displays the same output as the
monitor_net_trace request, except that display_net_trace request displays
information for only one moment in time, whereas monitor_net_trace displays new
information at a specified interval.
You can invoke the display_net_trace request in module or dump mode and from
any module or terminal.
8-52
VOS System Analysis Manual (R073)
display_net_trace
Examples
In the following example, the display_net_trace request dislays information
similar to that of the monitor_net_trace request. Note that the boldfaced capital
letters have been added as an aid to describing each of these columns.
as: display_net_trace
A B C D E
F
0 1 S O ACPT
110
2 1 S I NOM
92
10 2 S O ACPT
334
19 2 S I NOM
78
26 1 S O ACPT
134
29 1 S I NOM
104
40 2 S O ACPT
348
43 2 S I NOM
64
49 1 S O ACPT
110
52 1 S I NOM
138
59 2 S O ACPT
110
62 2 S I NOM
138
71 1 S O ACPT
1386
74 1 S I NOM
64
82 2 S O ACPT
322
86 2 S I NOM
50
94 1 S O ACPT
174
97 1 S I NOM
50
105 2 S O ACPT
322
108 2 S I NOM
50
TRACE MODE = auto_stop
as:
G H
M2 nreq
M2 data
M2 nreq
M2 data
M2 nreq
M2 data
M2 nreq
M2 data
M2 nreq
M2 data
M2 nreq
M2 data
M2 nreq
M2 data
M2 nreq
M2 data
M2 nreq
M2 data
M2 nreq
M2 data
I
18107->11001
11005->18107
18107->11001
11005->18107
18107->11001
11005->18107
18107->11001
11005->18107
18107->11001
11005->18107
18107->11001
11005->18107
18107->11001
11005->18107
18107->11001
11005->18107
18107->11001
11004->18107
18107->11001
11005->18107
J
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
rpt
K
L
00 tid 53BD-0000 #0001
00 tid 53BD-0000 #0001
00 tid 53BE-0000 #0001
02 tid 53BE-0000 #0001
00 tid 53BF-0000 #0001
00 tid 53BF-0000 #0001
00 tid 53C1-0000 #0001
00 tid 53C1-0000 #0001
00 tid 53C2-0000 #0001
00 tid 53C2-0000 #0001
00 tid 53C3-0000 #0001
00 tid 53C3-0000 #0001
00 tid 53C4-0000 #0001
00 tid 53C4-0000 #0001
00 tid 53C5-0000 #0001
00 tid 53C5-0000 #0001
00 tid 53C6-0000 #0001
00 tid 53C6-0000 #0001
00 tid 53C7-0000 #0001
00 tid 53C7-0000 #0001
The following table describes the columns that appear in the output of the preceding
example.
(Page 1 of 4)
Column
Description
Relative time in milliseconds. The first packet trace displayed is always shown as
relative time 0. Subsequent packet times are relative to the first trace.
The link or ring number, in the range from 1 to 8.
The type of ring: subring (S) or backbone ring (B).
The direction of data in relation to the reporting module: input (I) or output(O).
The analyze_system Command and Requests
8-53
display_net_trace
(Page 2 of 4)
8-54
Column
Description
The reply status returned by VOS.
NOM (no match): This value is normally traced for incoming packets because
the trace occurs before the receiving link controller changes the packet status
to ACPT. A value NOM for an output packet trace means that no station on the
ring recognized the destination station address.
ACPT (accept): The receiving station has received the packet without error.
BNR (buffer not ready): The receiving station did not have a receive chain for
the appropriate size packet pool at the time the packet arrived despite
repeated retries.
TMR (too many retries): The transmitting station has exceeded the boards
error retry threshold for a particular socket.
DEAD: VOS is no longer running on the destination station.
The length of the data portion of the packet.
Possible protocol types (most frequent listed first).
M2: message exchange protocol version two. The message exchange
protocol is that used to implement most cross-module kernel services
(s$ calls).
FQ: fast queue protocol (direct queues)
SI: station identification
NS: notify shadow protocol, cross module event notification.
ME: old message exchange protocol (prior to Release 11)
LD: link diagnostics protocol
TI: time protocol
TU: tourist protocol, used to determine network topology
TR: trace control protocol
HT: hardware self test protocol
BM: boom protocol, network boomerang testing
TF: test traffic protocol
LB: link boot protocol
UK: unknown packet type (for cross-release compatibility)
The following are subtypes for the ME and M2 protocols.
nreq (new request): A client sends this packet to initiate a new message.
Sometimes this packet also contains data.
redy (ready): A server sends this packet to indicate that it is ready to receive
data.
data (data): Additional data sent with a request from client to server when
the 4096-byte nreq packet is not large enough to hold the entire request.
iwat (iwait): Sent by a server in response to a wory if the server is
currently waiting for input.
VOS System Analysis Manual (R073)
display_net_trace
(Page 3 of 4)
Column
Description
H
(Cont)
wory (worry) : Sent by a client to a server when the client has not received a
timely answer. If the server is currently processing the request, it ignores the
wory and sends the data packet. If a server has already replied to the
network transaction, it sends terr. If a client receives no response after
sending repeated wory packets, it reports a worry timeout to the
syserr_log.
terr: Transaction ID error, also called TIDERR in error log messages.
stop (stop)
busy (busy)
dead (dead)
The following are subtypes of the SI protocol.
iah (I am here)
sip? (Unknown SI protocol subtype)
The following are subtypes of the FQ protocol.
rqst (request)
rply (reply)
ack (acknowledge)
nosv (no server)
abrt (abort)
stat (status)
The following are subtypes for the LD protocol.
strt/istr (start, intensive start)
ack/iack (acknowledge, intenstive acknowledge)
data/idat (data, intensive data)
age/inot (age data, intensive notify)
err/ierr (errors detected)
The following are subtypes for the TI protocol.
set/seta: Set time on one or all modules)
chk/chka: Check time on one or all modules)
The following is the subtype for the NS protocol.
ntfy: Notify a shadow event
The following is the subtype for TU protocol.
tour: Determine neighbor stations
The following is the subtype for TR protocol.
stop: Stop the trace (used to coordinate traces on sending and receiving
stations)
The analyze_system Command and Requests
8-55
display_net_trace
(Page 4 of 4)
Column
Description
Packet address information, shown as SSsss->DDddd.
SS: Source station address (in hexadecimal)
sss: Socket on the sending station (in hexadecimal)
DD: Destination station address (in hexadecimal)
ddd: Destination socket address (in hexadecimal)
In the case of ME and M2 nreq packets, ddd is the reserved socket to which the
request is directed. Socket numbers for all other ME and M2 packets are regular
socket numbers.
Note that station numbers are not necessarily the same as module numbers. The
relationship between the two can be seen using the dump_nct request or the
dump_net_info request with the -nct option
The repeat switch 1 indicates software and 2 indicates hardware.
The transaction ID number for the client and for the server. The number on the
left hand side of the arrow is the client TID, and the number on the right hand
side of the arrow is the server TID.
The sequence number of the packet for disassembly and reassembly.
Related Information
For more information on StrataLINK network tracing, see the descriptions of the
monitor_net_trace and set_net_trace requests.
8-56
VOS System Analysis Manual (R073)
display_pm
display_pm
8-
Purpose
This request displays information about the kernel program module or the user
program module of the current process.
Display Form
----------------------------------- display_pm --------------------------------name:
-dates:
no
-external_vars_map: no
-header:
no
-module_map:
no
-program_module:
kernel
Command-Line Form
display_pm name
[-dates]
[-external_vars_map]
[-header]
[-module_map]
[-program_module type]
Arguments
* name
The name of an object module in the program module to display information about.
The name argument is ignored if any of the arguments (-dates,
-external_vars_map, -header, and -module_map) is specified.
* -dates
<CYCLE>
Displays the date and time the object modules were created, modified, and
compiled for all object modules of the type specified in -program_module. If you
omit this argument and specify the name argument, the output includes this date
and time information for only the specified object module.
The analyze_system Command and Requests
8-57
display_pm
* -external_vars_map
Displays a list of all the external variables.
<CYCLE>
* -header
<CYCLE>
If you specify this argument, or if no command line arguments (other than
-program_module) are chosen, the output displays the program module header.
With this argument, you can see which version of a program is being used by a
process or VOS.
* -module_map
<CYCLE>
Displays a list of all object modules in the program module. The list shows the
location and size of each region within each section for each object module, the
access on pages in the kernel Code region, and whether the code was compiled
with the -cpu_profile argument.
* -program_module type
<CYCLE>
If kernel is specified, the output displays information about the kernel program
module of the current process on the analyzed system. If user_program is
specified, the output displays information about the user program module of the
current process. The default is kernel.
Explanation
You should understand program module formats to interpret the output displayed by
this request.
Examples
In the following example, the display_pm request displays information about the
object module cpu_indexed_data in the kernel space.
as:
display_pm cpu_indexed_data
Module Map:
Name
Dir Index
Code
Symtab
Start
Length
Start
Length
cpu_indexed_data
9
1 80403000 00000010 80B87198 00000138
Scn
Date Compiled
Static
UERW, SAP
Start
Length
95-01-22 00:06:48
808002E0 00000008
Module Map Dates:
Name
DTM
cpu_indexed_data 95-01-22 01:06:56
as:
DTCP
95-01-22 00:06:48
In the following example, the display_pm request displays the dates and times that
each object module in the kernel was created, modified, and compiled.
8-58
VOS System Analysis Manual (R073)
display_pm
as: display_pm -dates
Module Map Dates:
Name
DTM
write_once_section_begin
95-01-22 01:01:09
write_once_variables
95-03-15 14:52:22
write_once_section_over
95-01-22 01:01:11
atlantic_dump_mem
95-01-22 00:56:55
setup_dump_mem
95-01-22 00:59:25
dump_mem_utils
95-01-22 00:56:58
cpu_indexed_data 95-01-22 01:06:56
powerfail_recovery
95-03-15 14:42:46
reconfigure_cpu 95-03-03 22:11:51
....
as:
DTCP
95-01-21 23:37:33
95-03-15 14:51:35
95-01-21 23:37:39
95-01-21
95-01-21
95-01-21
95-01-22
23:20:29
23:30:22
23:21:14
00:06:48
95-03-15 14:37:06
95-03-03 21:28:21
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
DTC
The date and time the object module file was created
DTM
The date and time the object module file was modified
DTCP
The date and time the object module was compiled
If a file is copied after compilation, DTC and/or DTM might change, but DTCP will remain
constant.
In the following example, the display_pm request displays a list of all object modules
in the kernel program module. It also shows the location and size of each region within
each section for each object module, and the access on pages in the kernel Code
region.
as:
display_pm
-module_map
Module Map:
Name
Scn
Code
Start
Length
write_once_section_begin
1 80400000 00000010
write_once_variables
Symtab
Start
Length
80B86000 0000007E
Date Compiled
Static
UERW, SAP
Start
Length
95-01-21 23:37:33
80800000 00000008
95-03-15 14:51:35
The analyze_system Command and Requests
8-59
display_pm
1 80400010 00000010
write_once_section_over
1 80400020 00000010
atlantic_dump_mem
1 80400030 00002038
setup_dump_mem
1 80402070 00000180
dump_mem_utils
1 804021F0 00000070
cpu_indexed_data
1 80403000 00000010
powerfail_recovery
1 80403010 000012F0
....
as:
80B86080 000003CA
80B86450 0000007E
80B864D0 00000C30
80B87100 00000060
80B87160 00000034
80B87198 00000138
80B872D0 00001058
80800010 00000230
95-01-21 23:37:39
80800240 00000008
95-01-21 23:20:29
80800250 00000084
95-01-21 23:30:22
808002E0 00000000
95-01-21 23:21:14
808002E0 00000000
95-01-22 00:06:48
808002E0 00000008
95-03-15 14:37:06
808002F0 00000044
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
Name
The name of the object module
Code, Symtab
and Static
The code, symbol table, and static regions
Sx or Scn
The section. In this column, 1 means wired, 2 means initialization, and 3
means paged. All user code is in section 3.
Start
The starting address of the region
Length
The length of the region
UERW
SAP
Obsolete in VOS 14.x
In the following example, the display_pm request lists all external variables for object
modules in the kernel.
as:
display_pm -external_vars_map
External Variable Map:
Name
Sx Address
ACCESS_ANY_EXEC$ 1 80839C60
ACCESS_INTERLOCK$
1 80839C64
ACCESS_IO$
2 8089C194
ACCESS_KERNEL_EXEC$
1 80839C50
ACCESS_KERNEL_READ$
1 80839C48
ACCESS_KERNEL_WRITE$
8-60
VOS System Analysis Manual (R073)
Length
00000004
00000004
00000004
00000004
00000004
display_pm
80839C4C 00000004
80839C5C 00000004
ACCESS_USER_EXEC$
ACCESS_USER_READ$
1 80839C54
ACCESS_USER_WRITE$
1 80839C58
CMD_free_cb_ack_timeout
1 8082F210
CMD_lock_debug$ 1 8082F214
....
as:
00000004
00000004
00000004
00000002
In the following example, the display_pm request displays the program module
header.
as:
display_pm -header
Header:
version:
program_name:
binder_version:
release_name:
pop_version:
processor:
processor_family:
binder_options:
system_name:
user_name:
date_bound:
main_ep.code_addr:
main_ep.static_addr:
user_boundary:
max_heap_size:
max_program_size:
max_stack_size:
stack_fence_size:
n_modules:
n_external_vars:
n_link_names:
n_unsnapped_links:
n_entries:
n_vm_pages:
n_header_pages:
n_relocations:
module_map_address:
module_map_len:
ext_vars_map_address:
ext_vars_map_len:
link_names_map_address:
link_names_map_len:
1
atl_vos.0
bind, Release 13.0.1aj
VOS Release 13.0.1am
0
257 (i80860xp)
2 (I860)
kcbtsm
es
Installer.Installer
95-03-15 20:59:27 EDT
80841010
00000000
80400000
00000000
01000000
00000000
00001000
1753
1898
0
0
8652
3093
1
0
0047F4A0
0001FABA
0049EF80
00014638
80E630F2
00000000
The analyze_system Command and Requests
8-61
display_pm
link_map_address:
80E630F2
link_map_len:
00000000
entry_map_address:
004B35E0
entry_map_len:
00058B78
header_address:
0045EDC0
header_len:
00000B56
relocation_map_address: 80EBBC6A
relocation_map_len:
00000000
high_water_mark:
00000000
string_pool_address:
80EBBC6A
string_pool_len:
000006E8
obj_dir_map_address:
80EBC352
obj_dir_map_len:
000000CC
section_map_file_address:00000000
section_map_address:
00000000
section_map_len:
00000000
n_sections:
0
flags:
multisection_references
n_tasks:
1
stack_len:
00008000
copyright_notice:
Copyright (c) 1995 Stratus Computer, Inc. All
Rights Reserved. This program contains
proprietary information of Stratus Computer, Inc.
It may be used, copied or distributed only under
license.
Section Info:
Wired
Code
Symtab
Static
External
address
80400000
80B86000
80800000
80823000
task_static_len:
block_map_address:
Init
Code
Symtab
Static
External
address
8083C000
80D21000
80899000
8089C000
task_static_len:
block_map_address:
8-62
VOS System Analysis Manual (R073)
length
003FF010
0019AFEC
00022F60
0001836C
00022F60
00000000
GOT address:
block_map_len:
00000000
00000000
length
0005D000
0001A9AC
000028B0
0000C3D0
000028B0
00000000
GOT address:
block_map_len:
00000000
00000000
display_pm
Paged
Code
Symtab
Static
External
address
808A9000
80D3C000
80B60000
80B7D000
task_static_len:
block_map_address:
length
002B6CC8
000F2AB8
0001CD60
00008FDC
0001CD60
00000000
GOT address:
block_map_len:
00000000
00000000
as:
The analyze_system Command and Requests
8-63
display_process_info
display_process_info
8-
Purpose
This request displays information about the analyzed process.
Display Form
------------------------------ display_process_info ---------------------------y es
-pdr:
-tdr:
no
-full:
no
Command-Line Form
display_process_info
[-no_pdr]
[-tdr]
[-full]
Arguments
* -no_pdr
<CYCLE>
Suppresses the display of information about the process itself. If you omit this
argument (or specify yes in the display form), VOS displays information from a part
of the process called the process data region (PDR).
* -tdr
<CYCLE>
Displays summary information about tasks running in the process. This information
is from an area of the process called the task data region (TDR). The dump_tdr
request also shows the information displayed by this argument.
* -full
<CYCLE>
Displays information about each task. Specify this argument only with the -tdr
argument.
8-64
VOS System Analysis Manual (R073)
display_process_info
Explanation
The display_process_info request displays information about a process,
including its process data region and task data region.
The process data region lists the process-related flags that are set for this process,
displays the addresses of various pointers to structures, and then lists miscellaneous
information about the process. It displays the path names associated with the process
and information about any subordinate (child) processes.
The task data region lists the task-related flags set for this process, and then lists
miscellaneous information about the tasks within the process. (The examples show
data for a nontasking process, which is considered to be a process with one task.)
Examples
In the following example, the process request displays the current process and then
the display_process_info request displays information about the current process.
as: process
Using process on CPU26.
Current process is 4076, ptep 81CEA000, Joe_Smith.Eng
Process is running on CPU 26 right now; no stack addr known.
as: display_process_info
PDR @ 3FF6A000
Flags:
pad2
use_abbreviations have_run_start_up
have_ready_text default_message_file
banner_displayed
00000000
System Logging Flags:
accounting_enabled port_accounting
log_proc_stats_records log_proc_user_records
Pending Program Interrupts:
^valid
abbrev_info_ptr
3FF2C240
accounting_info_ptr
3FF2B0E0
command_library_paths_ptr3FF2BA80
cp_info_ptr
3FF2BEA0
debug_info_ptr
00000001
debug_ev
00000000
epilogue_handlers
002E806C
event_id_table_ptr
3FF2B4A0
global_macro_vars_ptr
00000001
language_info_ptr
80EC7220
The analyze_system Command and Requests
8-65
display_process_info
lpt_ptr
mail_info_ptr
mp_debug_info_ptr
normal_cli_ptr
pdr_heap_ptr
pick_pib_ptr
pmh_ptr
process_heap_ptr
pte_ptr
rawfile_pool_ptr
rawfile_table_ptr
stack_base
system_access_list_ptr
temp_file_ptr
tdr_ptr
user_heap_ptr
user_pi_mask_count_ptr
vc_events_ptr
3FF2BA60
00000001
00000001
3FF2B4C0
3FF2A000
00000001
00457F90
3FF2A060
81CEA000
00000001
00000001
3FEAA000
00000001
00000001
00459060
00459000
3FF29FE0
00000001
cp_id
00000008
cpu_time_limit
0
default_output_stack_depth0
default_output_stack
0, 0, 0, 0, 0, 0, 0, 0
command_message_port
0
error_message_port
7
event_id_table_size
4
highest_port
24
listener_level
1
n_stacks
1
pdr_heap_size
00040000
process_number
4076
process_type
1
rawfile_open_count
0
rawfile_table_size
0
ready_msg_info.format
1
ready_msg_info.old_cpu_time0
ready_msg_info.old_page_faults0
stack_len
00008000
time_zone
`00`00`00
zone_delta
0
allocate_tag
current_dir
event_path
home_dir
owner_access_group
owner_access_person
groups(1)
process_dir
ready_msg_text
subsystem
8-66
XX
%sys#m2_user>Eng>Joe_Smith
%sys#m2_user>Eng>Joe_Smith
Eng
ready
VOS System Analysis Manual (R073)
display_process_info
process_lock_wait_time
-1
program_lock_wait_time
-1
tp_process_time_value
0
tp_program_time_value
0
tp_process_params.priority0
tp_process_params.flags:
tp_program_params.priority0
tp_program_params.flags:
as:
In the following example, the display_process_info request displays summary
information about tasks running in the process but omits information about the process
itself.
as: display_process_info -no_pdr -tdr
TDR @ 00459060
Flags:
tasking_enabled
n_tasks
1
current_task_num
1
n_static_tasks
1
max_n_tasks
1
stack_base
3FEAA000
stack_len
32768
first_task_static_ptr
00320000
first_task_static_len
267784
ready_list:
004590A0: 00459520 00459528 00459520 00459528
wait_list:
004590B0: 00000001 004590B0 00000001 004590B0
unready_list:
004590C0: 00000001 004590C0 00000001 004590C0
old_cpu_time
0
old_page_faults
0
macro_event
00000000
completion_command
switched_frame
00000001
preemption_interval
0
tdr.lock_id
00000000
tdr.tdre_ptr_ptr
00459500
ready_list
Task ID
wait_list
unready_list
Tasks:
Num State
1
ready
1 @00459520 ready
saved_a6 term tid / abort reason
3FEA9F60
5 00000000-0000-0000
0
as:
The analyze_system Command and Requests
8-67
display_process_info
In the following example, the display_process_info request displays information
about each task running in the process (in this case, only one task).
as: display_process_info -no_pdr -tdr -full
TDR @ 00459060
Flags:
tasking_enabled
n_tasks
1
current_task_num
1
n_static_tasks
1
max_n_tasks
1
stack_base
3FEAA000
stack_len
32768
first_task_static_ptr
00320000
first_task_static_len
267784
ready_list:
004590A0: 00459520 00459528 00459520 00459528
wait_list:
004590B0: 00000001 004590B0 00000001 004590B0
unready_list:
004590C0: 00000001 004590C0 00000001 004590C0
old_cpu_time
0
old_page_faults
0
macro_event
00000000
completion_command
switched_frame
00000001
preemption_interval
0
tdr.lock_id
00000000
tdr.tdre_ptr_ptr
00459500
ready_list
Task ID
wait_list
unready_list
1 @00459520 ready
TDRE @ 00459520
Task 1:
task_id
links:
state
priority
n_fence_pages
task_alloc_ptr
fence_ptr
saved_a6
task_stack_base
task_stack_len
task_static_ptr
task_static_len
task port (1)
task port (2)
8-68
VOS System Analysis Manual (R073)
1
00459528: 00000001 004590A0 00000001 004590A0
ready
0
0
00000001
3FEA1000
3FEA9F60
3FEAA000
32768
00320000
267784
1
2
display_process_info
task port (3)
task port (4)
task port (5)
accept_info_ptr
cpu_time
page_faults
tid
transaction abort reason
wait_info.event_index
wait_info.event_count
wait_info.code
epilogue_handlers
3
4
5
00000001
0
0
00000000-0000-0000
0
0
0
0
s_pl1_stop+104, line 64
as:
The analyze_system Command and Requests
8-69
display_security_info
display_security_info
8-
Purpose
This request displays information about security logging for the current module.
Display Form
------------------------------display_security_info----------------------------No arguments required. Press ENTER to continue.
Command-Line Form
display_security_info
Explanation
Security logging can be turned on or off using the security_admin command,
documented in the manual VOS System Administration: Registration and
Security (R283).
Examples
In the following example, the display_security_info request displays security
data for the analyzed module.
as: display_security_info
log_buffer_busy:
seq_no:
security_lock:
time_stamp:
security_log_bufferp:
audit events:
8-70
VOS System Analysis Manual (R073)
true
5672
80177AE0
1C70D427 (95-06-19 10:59:13 EDT)
80BAD280
security
display_security_info
The following table describes the fields that appear in the output of the preceding
example.
Field
Description
log_buffer_busy
If there are messages in the buffer, true is displayed. If
there are no messages in the buffer, false is displayed.
seq_no
The sequence number for the last message written to the
security log
security_lock
The pointer to the lock information used by system
security
time_stamp
The time stamp set when a message is put in the buffer.
The buffer is written to the security log within 30 seconds
after a time stamp and when the message changes. This
minimizes the number of duplicate messages written to
the security log. The time stamp shows the date and time
it was set (in VOS integer date time format, and translated
into a recognizable date and time.)
security_log_bufferp
The pointer to the buffer where the message is being held
audit events
Audit events are specified with the audit_admin
command and include admin, channel,
configuration, io, object, performance, print,
process, security, utility, access, all, and a
blank. The default is a blank, which does not select a type
of event to be audited.
Related Information
For more information about security logging and auditing, see the descriptions of the
audit_admin and security_admin commands in the manual VOS System
Administration: Registration and Security (R283).
The analyze_system Command and Requests
8-71
display_system_usage
display_system_usage
8-
Purpose
This request displays information about system usage for the analyzed module.
Display Form
------------------------------ display_system_usage ----------------------------long: n o
Command-Line Form
display_system_usage
[-long]
Arguments
* -long
<CYCLE>
Displays information about system usage by user, system, and server processes.
By default, the request displays only total CPU usage, I/O rates, and interrupt rates.
Explanation
The display_system_usage request displays information about the use of a
module. The information displayed includes the following:
VOS release number
the CPU usage percentage of the module
the page faults taken on the module
the disk I/O rate of the module
the percentage of idle CPU time of the module
the percentage of time handling page faults
the percentage of time handling interrupts
If you specify -long, the display_system_usage request displays usage
information by user, system, and server processes.
8-72
VOS System Analysis Manual (R073)
display_system_usage
Note that you can obtain similar, but not precisely the same amount of, system usage
information with the display_system_usage command.
Examples
In the following example, the display_system_usage request displays system
usage information for the analyzed module.
as:
display_system_usage
Usage statistics, VOS Release 13.1
----CPU----CPU minutes
Min at PF
Idle
Other
--I/O Rates-Page faults,/sec
File IO, /sec
Disk IO, /sec
--INT Rates-Ints, /sec
Int. Time
Last Min
1.46 29.2%
0.02 0.4%
2.52 50.3%
0.13 2.7%
344
446
460
5.7
7.4
7.7
Last 5 Min
7.28 29.0%
0.05 0.2%
13.31 53.1%
0.61 2.4%
758
2253
2433
2.5
7.5
8.1
Last Hour
95.02 31.6%
0.47 0.2%
130.80 43.5%
11.48 3.8%
8221
27125
27883
2.3
7.5
7.7
28963 483 129138 429 1939322 538
0.87 17.5%
3.82 15.2%
62.72 20.9%
All 3.2 hours
265.75 27.4%
1.68 0.2%
497.88 51.3%
38.89 4.0%
24895 2.1
315954 27.2
321854 27.7
5084689 437
165.38 17.1%
In the following example, the display_system_usage request displays system
usage information for the analyzed module in the -long format.
as: display_system_usage -long
Usage statistics, VOS Release 13.1
----CPU----CPU minutes
User procs
System procs
Server procs
Last Min
1.46 29.2%
0.16 3.2%
0.06 1.1%
1.24 24.9%
Last 5 Min
7.28 29.0%
1.42 5.7%
0.40 1.6%
5.47 21.8%
Min at PF
User procs
System procs
Server procs
0.02
0.02
0.00
0.00
0.05
0.05
0.00
0.00
Idle
Other
2.52 50.3%
0.13 2.7%
--I/O Rates-Page faults,/sec
User procs
344
344
0.4%
0.4%
0.0%
0.0%
5.7
5.7
0.2%
0.2%
0.0%
0.0%
13.31 53.1%
0.61 2.4%
758
757
2.5
2.5
Last Hour
95.02 31.6%
14.13 4.7%
8.18 2.7%
72.72 24.2%
0.47
0.47
0.00
0.00
0.2%
0.2%
0.0%
0.0%
130.80 43.5%
11.48 3.8%
8221
8188
2.3
2.3
All 3.2 hours
265.96 27.4%
47.77 4.9%
27.97 2.9%
190.21 19.6%
1.69
1.58
0.07
0.03
0.2%
0.2%
0.0%
0.0%
498.07 51.3%
38.91 4.0%
24911
23809
The analyze_system Command and Requests
2.1
2.0
8-73
display_system_usage
System procs
Server procs
0
0
0.0
0.0
0
1
0.0
0.0
2
31
0.0
0.0
File IO, /sec
Disk IO, /sec
446
460
7.4
7.7
2253
2433
7.5
8.1
27125
27883
7.5
7.7
--INT Rates-Ints, /sec
Int. Time
as:
28963 483 129138 429 1939322 538
0.87 17.5%
3.82 15.2%
62.72 20.9%
711
391
0.1
0.0
315996 27.1
321899 27.7
5087543
165.46
437
17.1%
The output contains columns of data for the last minute, the last five minutes, the last
hour, and the total time since the module was last booted.
The following table describes some of the fields that appear in the output of the
preceding examples.
Field
Description
Min at PF
The number and percentage of CPU minutes spent processing page faults
Idle
The number minutes and percentage of time in which the CPU was idle per
second
Ints, /sec
The number of interrupts per second
Int. Time
The number and percentage of minutes that the CPU spent processing
interrupts
Related Information
For more information about the display_system_usage command, see the manual
VOS Commands Reference Manual (R098).
8-74
VOS System Analysis Manual (R073)
dump_adt
dump_adt
8-
Purpose
This request displays information about the active directory table (ADT) on the
analyzed module or about a specified object in the active directory table.
Display Form
------------------------------------ dump_adt ---------------------------------entry_name:
-dir:
no
-file:
no
-hash_table:
no
-all_entries:
no
-header:
no
-unused:
no
-brief:
no
-mod_blocks:
no
-queue_entries: no
Command-Line Form
dump_adt entry_name
[-dir]
[-file]
[-hash_table]
[-all_entries]
[-header]
[-unused]
[-brief]
[-mod_blocks]
[-queue_entries]
8-74
VOS System Analysis Manual (R073)
dump_adt
Arguments
* entry_name
An object (or objects) to display information about. The specified name must be a
file or a directory. If neither -dir nor -file is specified, the name is assumed to
be a directory name. If more than one file or directory matches the name, all entries
with the specified name are displayed.
* -dir
<CYCLE>
Displays the active directory table entry for entry_name. You must specify the
entry_name argument when using this argument. You cannot specify both this
argument and the -file argument.
* -file
<CYCLE>
Displays the active file table entry for entry_name. You must specify the
entry_name argument when using this argument. You cannot specify both this
argument and the -dir argument. The file must be open for this argument to work.
* -hash_table
Displays the hash table of the active directory table.
<CYCLE>
* -all_entries
<CYCLE>
Displays all entries of the active directory table. This argument is meaningful only
when you do not specify entry_name.
* -header
<CYCLE>
Displays information about the header of the active directory table.
* -unused
<CYCLE>
Displays all the directories in the active directory table that are not currently being
used. If a directory is not used for a certain period of time, the information about it
is moved to disk. This time-out period is set by the VOS command
set_tuning_parameters, documented in the VOS System Administration:
Administering and Customizing a System (R281).
* -brief
<CYCLE>
Displays the location of the control block, but does not interpret the control block.
You must specify the entry_name argument when you specify this argument.
* -mod_blocks
<CYCLE>
Displays the blocks modified for certain types of dirty readers. You must specify a
file name as entry_name to use this argument. This argument is for Stratus
internal use only.
* -queue_entries
<CYCLE>
Displays the queue header and all queue entries in the queue. You must specify a
server queue or message queue as entry_name to use this argument.
The analyze_system Command and Requests
8-75
dump_adt
Explanation
Four arguments of the dump_adt request display general information about the active
directory table: -hash_table, -all_entries, -header, and -unused. These
arguments are generally used when you do not specify a value for entry_name.
The entry_name argument displays information about a specific object in the active
table directory; the -dir and -file arguments indicate the object type specified in
entry_name.
Because only object names are specified, it is possible to match more than one ADT
entry.
Since the ADT changes frequently when a system is active, it is possible to receive
spurious error messages when using this command on a running system.
8-76
VOS System Analysis Manual (R073)
dump_adt
Examples
In the following example, the dump_adt request displays the active directory table
entry for the directory Smith.
as:
dump_adt Smith
ADTE at 81BC53C0 for: %s1#m1>Smith
catep:
81708660
CATE:
aftep:
81BC53C0
disk_addr(-1):
FFFFFFFF
disk_addr(0):
01071F0E
disk_addr(1):
00071F9C
disk_addr(2):
00071FB3
disk_addr(3):
01071FA8
disk_addr(4):
020722F4
disk_addr(5):
010722A8
....
blocks_used:
6
last_block:
5
allocation_size:
1
type:
DIR
error_code:
0
cate flags:
data_modified
disk_no:
16
phy_hash_no:
102
disk_io_count:
3123
num_diskw_started:
1843
num_diskw_done:
1843
extent_size:
1
number_blocks_at_creation: 0
flags:
resv_catep:
81708660
resv_blocks:
0
mod_phy_count:
168
log_phy_count:
0
log_data_ptr:
00000001
unmod_phy_list:
817086E8: 81643A60
mod_phy_list:
817086F8: 81759740
pcommit_links:
81708708: 00000001
req_wait_list:
81708718: 00000001
entry_disk_addr:
01070D88
entry_offset:
0B80
epx:
0000CB80
uid:
1C49BF53
parents catep:
81A518A0
salvage refcount:
0
next catep:
81955720
prev catep:
81A518A0
parent_ptr:
81CBD6E0
uid:
1C49BF53
81643A9C
8175977C
00000001
81708718
816993A0
81759740
00000001
00000001
816993DC
8175977C
00000001
81708718
The analyze_system Command and Requests
8-77
dump_adt
uid_hash_fp:
dt_modified:
common flags:
....
as:
80BB54C0
95-02-08 11:35:03 EST
data_used
In the following example, the dump_adt request displays the hash table of the active
directory table.
as:
dump_adt -hash_table
Hash table:
SLOT
ADDR
1 82657BE0
1 826573C0
1 82656BA0
1 8241EEE0
1 8214BD60
1 8214AA20
1 82149B00
1 82149140
1 82148440
1 82147400
1 816C5F60
1 8216A200
2 816DD480
2 80B97080
2 82088B60
2 8214A1C0
2 824298A0
2 80BB0040
2 80B82940
3 81CA6880
....
as:
8-78
REF
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
INF
0
0
0
0
1
1
1
1
1
1
1
1
0
2
0
1
1
3
5
0
VOS System Analysis Manual (R073)
NAME
%sys#libs>r13.01>base>os>global>tables
%sys#libs>r13.01>fixes>os>global>tables
%sys#libs>r13.01>base>os>tables
%sys#libs>r13.01>fixes>os>tables
%sys#m1_more>postoffice>ship_to_dir>irvine
%sys#m1_more>postoffice>ship_to_dir>phx
%sys#m1_more>postoffice>ship_to_dir>ams
%sys#m1_more>postoffice>ship_to_dir>stl
%sys#m1_more>postoffice>ship_to_dir>sydney
%sys#m1_more>postoffice>ship_to_dir>atl
%sys#libs>r13.01>base>tcp_os>100
%sys#libs>r13.01>base>swd>tables
%sys#libs>testing>t2>wtm
%sys#libs>r13.01>fixes>wtm
%sys#libs>r13.0>fixes
%sys#m1_more>postoffice>ship_to_dir>la
%sys#m1_more>postoffice>ship_to_dir>tor
%sys#libs>r13.01>base>wtm
%sys#libs>r13.01>fixes
%sys#m1_more>postoffice>ship_to_dir>es>m111
dump_adt
In the following example, the dump_adt request displays all entries of the active
directory table.
as:
dump_adt -all_entries
UID Hash table:
SLOT
ADDR
TYPE
1 820E0C40
ADTE
1 820E0900
ADTE
1 820DF0C0
ADTE
1 820DEF20
ADTE
1 82661340
ADTE
1 826611A0
ADTE
1 8214C0A0
ADTE
1 824274E0
ADTE
1 8208D020
AFTE
1 8208AFC0
AFTE
1 82656280
AFTE
1 81F9C640
ADTE
1 8241C180
AFTE
1 820D4600
AFTE
1 80BB5300
ADTE
1 80BB3700
ADTE
1 80B7F2C0
AFTE
1 8020A8A0
ADTE
1 801783C0
ADTE
2 820DF400
ADTE
2 820DF260
ADTE
....
as:
NAME
%sys#sc3>products>tcp_os>12.2-5
%sys#sc3>products>tcp_os>12-32
%sys#m1_more>postoffice>ship_to_dir>cmh>m1
%sys#m1_more>postoffice>ship_to_dir>irvine>m1
%sys#m1_more>postoffice>ship_to_dir>wdc>m1
%sys#m1_more>postoffice>ship_to_dir>hou>m1
%sys#m1_more>postoffice>ship_to_dir>cmh
%sys#m1_more>postoffice>ship_to_dir>wdc
%sys#sc3>products>tcp_os>dev.12.2>incl>prototypes.h
%sys#sc3>products>tcp_os>dev.12.2>incl>lockdef.h
%sys#sc3>products>tcp_os>dev.12.2>incl>kll_defs.h
%sys#m1>system>tcp_os>telnet_logs
%sys#m1>system>ofc_janitor_log.95-02-13
%sys#m1>system>queues>batch>rebuild_13.0
%sys#m1>system>tcp_os>command_library
%sys#m1>system>calendars
%sys#m1>system>command_library>tp_overseer.pm
%sys#m1>system>tcp_os
%sys#m1>Overseer
%sys#m1_more>postoffice>ship_to_dir>milan>m1
%sys#m1_more>postoffice>ship_to_dir>esc>m1
In the following example, the dump_adt request displays information about the header
of the active directory table.
as:
dump_adt -header
ADT Header:
next_uid:
unused_head:
unused_tail:
file_usedp:
prev_file_usedp:
FFFFFFFF
007373F8
0480D5B8
00000001
00000001
The analyze_system Command and Requests
8-79
dump_adt
Related Information
dump_adte is the same as dump_adt -dir.
dump_afte is the same as dump_adt -file.
dump_queue_info shows additional information about server and message queues.
8-80
VOS System Analysis Manual (R073)
dump_adte
dump_adte
8-
Purpose
This request displays information about the specified active directory table entries
(ADTE) on the analyzed module.
Display Form
------------------------------------ dump_adte --------------------------------dir_name:
-address:
-brief:
no
Command-Line Form
dump_adte dir_name
[-address address]
[-brief]
Arguments
* dir_name
The name of the directory to display information about. Use only the last
component of the path name. You must specify a value for either this argument or
the -address argument. You cannot select both.
* -address address
The address of an active directory table entry to display information about. You
must specify a value for either this argument or the dir_name argument. You
cannot select both.
* -brief
<CYCLE>
Displays the location of the control block, but the control block is not interpreted.
The analyze_system Command and Requests
8-81
dump_adte
Explanation
If more than one directory in the active directory table matches the name specified by
dir_name, dump_adte displays them all. To display only one directory, use the
-address argument.
Since the ADT changes frequently when a system is active, it is possible to receive
spurious error messages when using this command on a running system.
Examples
In the following example, the dump_adte request displays information about the active
directory table entry for the directory Jones.
as: dump_adte Jones
ADTE at 006A3062 for: %s1#m1>Jones
catep:
81708660
CATE:
aftep:
81BC53C0
disk_addr(-1):
FFFFFFFF
disk_addr(0):
01071F0E
disk_addr(1):
00071F9C
disk_addr(2):
00071FB3
disk_addr(3):
01071FA8
disk_addr(4):
020722F4
disk_addr(5):
010722A8
....
blocks_used:
6
last_block:
5
allocation_size:
1
type:
DIR
error_code:
0
cate flags:
data_modified
disk_no:
16
phy_hash_no:
102
disk_io_count:
3117
num_diskw_started:
1841
num_diskw_done:
1841
extent_size:
1
number_blocks_at_creation: 0
(Continued on next page)
8-82
VOS System Analysis Manual (R073)
dump_adte
flags:
resv_catep:
resv_blocks:
mod_phy_count:
log_phy_count:
log_data_ptr:
unmod_phy_list:
mod_phy_list:
pcommit_links:
req_wait_list:
entry_disk_addr:
entry_offset:
epx:
uid:
parents catep:
salvage refcount:
next catep:
prev catep:
....
as:
81708660
0
167
0
00000001
817086E8: 819C92E0
817086F8: 00000001
81708708: 00000001
81708718: 00000001
01070D88
0B80
819C931C
817086F8
00000001
81708718
819B3020
00000001
00000001
00000001
819B305C
817086F8
00000001
81708718
0000CB80
1C49BF53
81A518A0
0
81955720
81A518A0
The analyze_system Command and Requests
8-83
dump_afte
dump_afte
8-
Purpose
This request displays information about the specified active file table entries (AFTE) on
the analyzed module. This includes the default character set and shift mode fields; if
the file has indexes, the active index table entry (AXTE) for each index is displayed.
Display Form
------------------------------------ dump_afte --------------------------------filename:
-address:
-brief:
no
-mod_blocks:
no
-queue_entries: no
-fi_locks:
no
Command-Line Form
dump_afte filename
[-address address]
[-brief]
[-mod_blocks]
[-queue_entries]
[-fi_locks ]
Arguments
* filename
The name of an open file to display information about. Use only the last component
of the path name. You must specify a value for either this argument or the
-address argument; you cannot select both. If more than one file matches the
specified name, all entries with the specified name are displayed.
8-84
VOS System Analysis Manual (R073)
dump_afte
* -address address
The address of an active file table entry to display information about. You must
specify a value for either this argument or filename; you cannot select both.
* -brief
<CYCLE>
Displays the location of the control block, but the control block is not interpreted.
* -mod_blocks
<CYCLE>
Displays the blocks modified for certain types of dirty readers. This argument is for
Stratus internal use only.
* -queue_entries
<CYCLE>
Displays the queue header and all queue entries in the queue that match
entry_name. You must specify a server queue or a message queue as
entry_name.
* -fi_locks
Dump all process lock attachments to the files. The default value of -fi_locks is
no. This argument cannot be used in conjunction with any other dump_afte switch
argument.
Explanation
The information displayed is the same when either the filename or the -address
argument is specified; the dump_afte request displays the full path name of the
object. To display only one file, use the -address argument. Otherwise, all files in the
active directory table that match filename are displayed.
Since the ADT changes frequently when a system is active, it is possible to receive
spurious error messages when using this command on a running system.
The analyze_system Command and Requests
8-85
dump_afte
Examples
In the following example, the dump_afte request displays information about the active
file table entry for test_file_5.
as:
dump_afte test_file_5
AFTE at 8208D020 for: %m1#s1>incl>test_file_5
catep:
818DB5C0
CATE:
aftep:
8208D020
disk_addr(-1):
FFFFFFFF
disk_addr(0):
00006557
disk_addr(1):
00006558
disk_addr(2):
00006559
disk_addr(3):
0000655A
....
blocks_used:
4
last_block:
3
allocation_size:
1
type:
FILE
error_code:
0
cate flags:
disk_no:
12
phy_hash_no:
57
disk_io_count:
2
num_diskw_started:
0
num_diskw_done:
0
extent_size:
1
number_blocks_at_creation: 0
flags:
resv_catep:
818DB5C0
resv_blocks:
0
mod_phy_count:
0
log_phy_count:
0
log_data_ptr:
00000001
unmod_phy_list:
818DB648: 00000001 818DB648
mod_phy_list:
818DB658: 00000001 818DB658
pcommit_links:
818DB668: 00000001 00000001
req_wait_list:
818DB678: 00000001 818DB678
entry_disk_addr:
0000CCD8
entry_offset:
0320
epx:
00001320
uid:
1C6B8AA0
parents catep:
81B59920
last_record:
13937
next catep:
816A5E00
prev catep:
814599C0
parent_ptr:
826517A0
uid:
uid_hash_fp:
8-86
VOS System Analysis Manual (R073)
1C6B8AA0
8208AFC0
00000001
00000001
00000001
00000001
818DB648
818DB658
00000001
818DB678
dump_afte
dt_modified:
common flags:
mod_blocksp:
fp:
bp:
locker fp:
flags:
flags2:
locking flags:
file type:
ref count:
index_datap:
record size:
first record:
last record:
tp last record:
min record_size:
queue_header_ptr:
lock_infop:
pipe_datap:
object_lock_event:
time_stamp:
dirty_readers:
excl_read_lockers:
last_tid:
last_cid:
vm_filep:
num_writers:
num_readers:
character_set:
shift_mode:
rawfile_pool_ptr:
rawfile_disk_addrp:
num_rewrite_read_lock:
No indexes.
....
as:
95-02-09 10:11:31 EST
data_used
00000001
00000000
00000000
8208D200
stream file
1
00000001
0
0
13937
0
0
00000001
8208D140
00000001
00000000
00000000
0
1
0000000000000000
0000000000000000
00000001
0
1
none
none
00000000
00000000
0
The analyze_system Command and Requests
8-87
dump_afte
In the following example, the dump_afte request displays information about the queue
header and all queue entries in the queue. Queue header information follows the
heading queue_header_ptr (shown in the first example) in full output.
as:
dump_afte load_control.server_queue -queue_entries
AFTE at 005E548C for: %s1#m1>system>load_control.server_queue
catep:
00569F34
CATE:
aftep:
005E548C
disk_addr(-1):
FFFFFFFF
disk_addr(0):
00003E49
....
blocks_used:
1
last_block:
0
allocation_size:
1
disk_no:
1
type:
FILE
cate flags:
error_code:
0
resv_catep:
00569F34
resv_blocks:
0
phy_hash_no:
143
unmod_phy_list:
00569F9A: 00000001 00569F9A 00000001 00569F9A
mod_phy_list:
00569FAA: 00000001 00569FAA 00000001 00569FAA
num_diskw_started:
0
num_diskw_done:
0
disk_io_count:
0
flags:
extent_size:
1
number_blocks_at_creation: 0
parent_ptr:
005334B4
uid:
0F82A005
uid_hash_fp:
005E1C30
dt_modified:
90-06-25 07:02:32 edt
common flags:
data_used
mod_blocksp:
00000001
fp:
00000000
bp:
00000000
locker fp:
005E559C
flags:
implicit_locking
locking flags:
file type:
server queue file
ref count:
1
index_datap:
00000001
record size:
0
first record:
0
last record:
0
tp last record:
0
min record_size:
0
epx:
00009540
queue_header_ptr:
005E589E
8-88
VOS System Analysis Manual (R073)
dump_afte
max_queue_depth
256
queue_header
-number_of_requestors:
0
-number_of_servers:
1
-sqi_list:
005E58A2: 005E559C 005E55BC 005E559C 005E55BC
-main_sqe_list:
005E58B2: 00000001 005E58B2 00000001 005E58B2
-num_free_sqe:
1
-free_sqe_list:
005E58C4: 005E5628 005E5628 005E5628 005E5628
-num_free_sqe_space:
3
-free_sqe_space_list:
005E58D6: 005E42A0 005E42A0 005E56D6
005E56D6
-space_list:
-free_space_list:
-high_offset:
-last_at_priorityp (0):
-last_at_priorityp (1):
-last_at_priorityp (2):
-last_at_priorityp (3):
....
-last_record:
-max_messages:
-num_messages:
-num_non_busy_messages:
-highest_num_messages:
-total_num_messages:
-max_per_priority:
-num_per_priority(0):
-num_per_priority(1):
-num_per_priority(2):
-num_per_priority(3):
....
-first_non_busyp:
-lock_infop:
-time_stamp
-num_refused:
lock_infop:
pipe_datap:
object_lck_event:
time_stamp:
dirty_readers:
excl_read_lockers:
last_tid:
last_cid:
vm_filep:
num_writers:
num_readers:
005E58E6: 00000001 005E58E6 00000001 005E58E6
005E58F6: 00000001 005E58F6 00000001 005E58F6
0
00000001
00000001
00000001
00000001
0
256
0
0
0
0000000000000000
4
0
0
0
0
00000001
005E59EC
0000000000000000
0
005E472E
00000001
0113409A
00000000
0
0
0000000000000000
0000000000000000
00000001
1
0
The analyze_system Command and Requests
8-89
dump_afte
character_set:
shift_mode:
rawfile_pool_ptr:
rawfile_disk_addrp:
num_rewrite_read_lock:
metersp:
No indexes.
as:
Related Information
dump_queue_info
8-90
VOS System Analysis Manual (R073)
none
none
00000000
00000000
0
00000001
dump_area
dump_area
8-
Purpose
This request displays information about the contents of a heap and specific information
about the blocks in the heap.
Display Form
----------------------------------- dump_area ---------------------------------area_address:
-heap:
-dump:
no
-type:
-free:
no
-show_caller: no
-header:
yes
-memory_pool: 0
-match_file:
-min_matches: 1
-echo_matches: no
Command-Line Form
dump_area area_address
[-heap heap_name]
[-dump]
[-type string]
[-free]
[-show_caller]
[-no_header]
[-memory_pool pool]
[-match_file file_name]
[-min_matches match_number]
[-echo_matches]
The analyze_system Command and Requests
8-91
dump_area
Arguments
* area_address
The address of the heap you want information displayed about. You must specify a
value for either this argument or the -heap argument. You cannot select both. (You
can use the dump_pdr request to display the addresses of the user and PDR
heaps. For information on address formats, see Chapter 3.)
* -heap heap_name
<CYCLE>
The heap that you want to display information about. The heap_name value can
be one of the following:
Value
Description
paged
The paged heap
wired
The wired heap
comm
The communications heap
I/O
The I/O heap. XA/R: 24-bit addressing
Continuum: at least 32-bit addressing
high_I/O
High physical memory I/O heap. XA/R: 29-bit addressing
Continuum: Not applicable
pdr
The process data region heap of the selected process
user
The user heap of the selected process
iop
The input/output processor heap (available only in the IOP modes)
ioa
The input/output adapter heap (available only in the IOP modes)
You must specify a value for either this argument or the area_address argument.
You cannot select both. (When you use the Display Form, the value field for the
-heap argument is blank, indicating no value, which is the default for this <CYCLE>
field.)
* -dump
<CYCLE>
Displays for each specified block, the block header, and the data in the block. If you
do not specify -dump, only the block headers are displayed.
* -type string
Displays information only about blocks of the specified type. The value for string
must be one of the two-character abbreviations (tags) that VOS assigns to the
types of blocks. (You can use the scan_area request to display the tags and their
meanings.)
* -free
Displays information only about the free blocks.
8-92
VOS System Analysis Manual (R073)
<CYCLE>
dump_area
* -show_caller
<CYCLE>
Displays the calling programs and the line numbers of the code that performed
block allocation on the user heap. This argument is meaningful only when
displaying the user heap and only when Stratus has enabled additional information
capture.
* -no_header
<CYCLE>
Suppresses header information and displays information only about the blocks in
the heap. By default, the request does not suppress header information.
* -memory_pool pool
Displays the kernel heap for a specified memory pool. Allowed values are 0 and 1.
* -match_file file_path_name
Specifies the path to a file which contains a list of heap addresses, one per line
(with optional text after the address). The addresses in the file must be sorted from
lowest to highest. When you specify this argument, the request displays only
information about blocks that contain addresses in the file. For each block, it
displays the number of addresses from the file that are inside that heap allocation.
* -min_matches match_number
Displays only blocks having a number of address matches that equal or exceed the
specified match_number value. You can only specify a value for this argument if
a file_path_name is specified for the -match_file argument. The default
value is 1.
* -echo_matches
<CYCLE>
Displays the line or lines in the match file that match the block after the request
displays information about the block. You can only specify a value for this argument
if a file_path_name is specified for the -match_file argument and the value
of match_number is 1. The default values is no.
Explanation
A heap is a portion of virtual address space in which VOS can allocate storage for data.
The display_memory_usage request shows the user heap addresses.
The dump_area request displays header information that is also displayed by
scan_area.
You cannot use the dump_area request to display information about a process heap.
The analyze_system Command and Requests
8-93
dump_area
Examples
In the following example, the dump_area request displays the block headers for all
blocks in the wired heap.
as:
dump_area -heap wired
AREA at 001AF000 (wired_heap)
Next virgin:
Last available:
Free bytes:
Max size:
Free limit:
Dead space:
Area size:
Bucket(1)
Bucket(2)
Bucket(3)
Bucket(4)
Bucket(5)
Bucket(6)
Bucket(7)
Bucket(8)
0-32
33-64
65-96
97-128
129-256
257-512
513-1024
1025-up
04AFCD2E (0494DD2E)
04AFCFEC (0494DFEC)
000A56A6
000027B0
00082BFD
045380C6
00415F26 (1046 pages)
04964D46
04A317B6
048E094A
00786782
049199DE
0491BB2A
0497E336
04992FE2
(047B5D46)
(048827B6)
(0473194A)
(005D7782)
(0476A9DE)
(0476CB2A)
(047CF336)
(047E3FE2)
Busy block (**) at 001AF040 (00000040) size=0000000A Permanent Heap
Overhead Block
Busy block (VM) at 001AF04A (0000004A) size=00000044 VM Pool Information
Busy block (LC) at 001AF08E (0000008E) size=000000B8 Lock Info
Busy block (LC) at 001AF146 (00000146) size=000000B8 Lock Info
Busy block (LC) at 001AF1FE (000001FE) size=000000B0 Lock Info
Busy block (VS) at 001AF2AE (000002AE) size=0000001C Varying String
Busy block (VS) at 001AF2CA (000002CA) size=00000020 Varying String
Busy block (VS) at 001AF2EA (000002EA) size=00000020 Varying String
Busy block (VS) at 001AF30A (0000030A) size=00000024 Varying String
Busy block (VM) at 001AF32E (0000032E) size=00000044 VM Pool Information
Busy block (PM) at 001AF372 (00000372) size=00000194 Process Map Block
Busy block (VM) at 001AF506 (00000506) size=00000044 VM Pool Information
Free block (IC) at 001AF54A (0000054A) size=0000002C Disk Buffer List
Blocks
Busy block (PA) at 001AF576 (00000576) size=0000008C Memory Map Page Tables
Busy block (PM) at 001AF602 (00000602) size=00000194 Process Map Block
Busy block (VM) at 001AF796 (00000796) size=00000044 VM Pool Information
....
as:
In the following example, the dump_area request displays the data in each block, as
well as the header information. The -dump argument expands the display to show the
data in each block. The first column is the virtual address and the second column is the
offset from the start of the block. The next four columns display the block header or the
8-94
VOS System Analysis Manual (R073)
dump_area
storage data in hexadecimal format. Finally, the storage data is displayed in ASCII
format, with each nonprinting character represented by a dot.
as:
dump_area
-heap pdr -dump
AREA at 047A7000 (47A7000)
Next virgin:
Last available:
Free bytes:
Max size:
Free limit:
Dead space:
Area size:
Bucket(1)
Bucket(2)
Bucket(3)
Bucket(4)
Bucket(5)
Bucket(6)
Bucket(7)
Bucket(8)
047AAD9E (00003D9E)
047AB000 (00004000)
0000058C
00000544
00000200
00000000
00004000 (4 pages)
0-32
33-64
65-96
97-128
129-256
257-512
513-1024
1025-up
00000001
00000001
047A87EA
00000001
00000001
00000001
00000001
047A884A
(00000000)
(00000000)
(000017EA)
(00000000)
(00000000)
(00000000)
(00000000)
(0000184A)
Busy block (**) at 047A7040 (00000040) size=0000000A
Overhead Block
047A7040 000000 00000000 2A2AFFFF FFF6
Permanent Heap
Busy block (PH) at 047A704A (0000004A) size=00000024
047A704A 000000 0000000A 5048FFFF FFDC
Process Heap Info
|....PH....
|
047A7054
047A7064
000000
000010
04727000 00004000 00000083 00003FCD
047A7078 047A7884 0000
Busy block (HL) at 047A706E (0000006E) size=0000080C
Lamps
047A706E 000000 00000024 484CFFFF F7F4
047A7078
047A7088
=
047A7268
047A7278
....
as:
|....**....
|.rp...@.......?.|
|.zpx.zx...
|
Process Heap Head
|...$HL....
000000
000010
80000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
|................|
|................|
0001F0
000200
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
|................|
|................|
In the following example, the dump_area request displays information about the free
blocks in the wired heap. In the output from the -free argument, the tag for a free
block indicates the purpose for which the block was last used. The tag ** is used to
indicate free space created when part of a free block was allocated.
The analyze_system Command and Requests
8-95
dump_area
as:
dump_area -heap wired -free
AREA at 0030E000 (wired_heap)
Next virgin:
Last available:
Free bytes:
Max size:
Free limit:
Dead space:
Area size:
Bucket(1)
Bucket(2)
Bucket(3)
Bucket(4)
Bucket(5)
Bucket(6)
Bucket(7)
Bucket(8)
40DDF900 (40AD1900)
40DF9FE0 (40AEBFE0)
000222D0
00005120
0007D1FC
40718160
003D3E80 (980 pages)
0-32
33-64
65-96
97-128
129-256
257-512
513-1024
1025-up
40D9B960
40D09A90
40C5C890
00000001
00000001
00000001
00000001
40DDB3C0
(40A8D960)
(409FBA90)
(4094E890)
(00000000)
(00000000)
(00000000)
(00000000)
(40ACD3C0)
Busy block (**) at 0030E040 (00000040) size=00000010 Permanent Heap
Overhead l
+ock
0030E040 000000 00000000 2A2A0000 00000000 FFFFFFF0 |....**..........|
Busy block (VM) at 0030E050 (00000050) size=00000050 VM Pool Information
0030E050 000000 00000010 564D0000 00000000 FFFFFFB0 |....VM..........|
0030E060
0030E070
0030E080
0030E090
000000
000010
000020
000030
0054F4F0
00000547
48656170
00000000
0054F4F0
00000040
00000000
00000000
0031D7C0
000A5769
00000000
00000000
0031D7C0
72656420
00000000
00000000
|.T...T...1...1..|
|[email protected] |
|Heap............|
|................|
Busy block (PA) at 0030E0A0 (000000A0) size=000000A0 Memory Map Page Tables
0030E0A0 000000 00000050 5041454E 00000000 FFFFFF60 |...PPAEN.......`|
.
.
.
as:
The following table describes the fields that appear in the header output of the
preceding examples. The header is displayed unless you specify the -no_header
argument (see the example following the table). This header is also displayed by the
8-96
VOS System Analysis Manual (R073)
dump_area
scan_area request, but this request additionally displays the number of blocks in each
bucket.
Field
Description
Next virgin
The first number is the address above which all blocks in the
heap are free. The number in parentheses is the relative next
virgin, which is the number of bytes between that address and the
beginning of the heap.
Last available
The maximum address currently usable by the heap. The number
in parentheses is the relative offset.
Free bytes
The total number of bytes free throughout the heap
Max size
An estimate of the largest free block
Free limit
The number of bytes that must be available for a limited allocation
to succeed
Dead space
The number of unusable blocks between sections of virtual
memory space in extensible heaps. This allows for
non-contiguous heaps.
Area size
The current size of the heap
Bucket(n)
Free blocks within the non-virgin area are placed into buckets
based on their size. For each bucket, the output shows the
address of the first block in the bucket and the number of bytes
between that address and the beginning of the heap (the offset).
To calculate the amount of free space in the heap, use the following formula:
free bytes + (relative last available - relative next virgin)
Note that this formula does not account for space made available by heap expansion;
the user, paged, wired, and comm heaps are all automatically expanded when
allocated space is used. For an explanation of user heap expansion, see the discussion
in the display_memory_usage request description of the user_heap or
original_user_heap region. Refer to the descriptions of
display_extensible_heap and dump_vm_pool_info for information on paged,
wired, and comm heap expansion.
Following the header, the dump_area request displays information about each block.
This includes the notation Busy block or Free block, the abbreviation tag for the
type of block, the address of the block, the number of bytes between that address and
the beginning of the heap, the size of the block, and the full name for the type of block.
Every heap has a dummy block tagged ** as its first element.
The analyze_system Command and Requests
8-97
dump_area
In the following example, the dump_area request displays only data about the blocks
in the wired heap and no header information.
as:
dump_area -heap wired -no_header
Busy block (**) at 001A040 (000000040) size=0000000A Permanent Heap
Overhead Block
Busy block (VM) at 001AD04A (0000004A) size=00000044 VM Pool Information
Busy block (LC) at 001AD08E (0000008E) size=000000B8 Lock Info
Busy block (LC) at 001AD146 (00000146) size=000000B8 Lock Info
Busy block (LC) at 001AD1FE (000001FE) size=000000B0 Lock Info
Busy block (VS) at 001AD2AE (000002AE) size=00000020 Varying String
Busy block (CR) at 001AD2CE (000002CE) size=00000020 Cache Manager Request
Busy block (VS) at 001AD2EE (000002EE) size=00000024 Varying String
Busy block (VM) at 001AD312 (00000312) size=00000044 VM Pool Information
Busy block (PM) at 001AD356 (00000356) size=000001A0 Process Map Block
Busy block (PA) at 001AD4F6 (000004F6) size=0000008C Memory Map Page Tables
Busy block (PM) at 001AD582 (00000582) size=00000194 Process Map Block
Busy block (LC) at 001AD716 (00000716) size=000000B0 Lock Info
Busy block (WQ) at 001AD7C6 (000007C6) size=00000030 Diag Cmd Q Wait Entry
Busy block (PA) at 001AD7F6 (000007F6) size=0000080C Memory Map Page Tables
Busy block (ND) at 001AE002 (00001002) size=000000BC Net Driver Table
Busy block (VS) at 001AE0BE (000010BE) size=0000001C Varying String
Busy block (VS) at 001AE0DA (000010DA) size=0000001C Varying String
Busy block (VM) at 001AE0F6 (000010F6) size=00000044 VM Pool Information
....
as:
8-98
VOS System Analysis Manual (R073)
dump_axte
dump_axte
8-
Purpose
This request displays information about the specified active index table entries (AXTE)
on the analyzed module.
Display Form
------------------------------------ dump_axte --------------------------------filename:
index:
-address:
-brief:
no
-mod_blocks: no
Command-Line Form
dump_axte filename
[index]
[-address address]
[-brief]
[-mod_blocks]
Argument
* filename
The name of a file to display information about. Use only the last component of the
path name. If you select the filename argument you must also specify the index
argument. If you do not select the filename argument you must specify the
-address argument.
* index
The index of an active table entry to display information about. You must specify
index when you specify filename. If you omit filename, you must also omit
index.
The analyze_system Command and Requests
8-99
dump_axte
* -address address
The address of an active table index entry to display information about. You must
specify a value for either this argument or for the filename and index
arguments.
* -brief
<CYCLE>
Displays the location of the control block, but the control block is not interpreted.
* -mod_blocks
<CYCLE>
Displays the blocks modified for certain types of dirty readers. This argument is for
Stratus internal use only.
Explanation
The dump_axte request display the full path name of the active index table entry. If
more than one file in the active directory table matches filename, dump_axte
searches them all. To display only one file, use the -address argument.
Since the ADT changes frequently when a system is active, it is possible to receive
spurious error messages when using this command on a running system.
8-100
VOS System Analysis Manual (R073)
dump_axte
Examples
In the following example, the dump_axte request displays information about the active
index table entries for the file test_file_5.
as:
dump_axte test_file_5 first
AXTE at 0054CA94 for: %sys#m2_user>Eng>Joe_Smith>first
catep:
0064551C
CATE:
aftep:
0054CA94
disk_addr(-1):
FFFFFFFF
disk_addr(0):
00001BFC
disk_addr(1):
000105F3
....
blocks_used:
2
last_block:
1
allocation_size:
1
disk_no:
2
type:
INDEX
cate flags:
error_code:
0
resv_catep:
00655A9A
resv_blocks:
0
phy_hash_no:
438
unmod_phy_list:
00645580: 00000001 00645580 00000001 00645580
mod_phy_list:
00645590: 00000001 00645590 00000001 00645590
num_diskw_started:
0
num_diskw_done:
0
disk_io_count:
0
flags:
extent_size:
1
number_blocks_at_creation: 0
parent_ptr:
006615C8
uid:
139BF8EC
uid_hash_fp:
00000001
dt_modified:
never
common flags:
mod_blocksp:
00000001
Non TP fields
time stamp
00000000
root block num
1
cur index depth
1
High Block Used
1
TP fields
time stamp
00000000
root block num
1
cur index depth
1
High Block Used
1
collating_tp:
1
flags
dup_ok
xpx:
00004A20
The analyze_system Command and Requests
8-101
dump_axte
max_key_len:
n_components:
component.pos(1): 1
component.len(1): 21
blocks_used:
last_block:
allocation_size:
disk_no:
type:
cate flags:
error_code:
resv_catep:
resv_blocks:
phy_hash_no:
buffer_list:
parent_ptr:
uid:
uid_hash_fp:
dt_modified:
common flags:
mod_blocksp:
Non TP fields
time stamp
root block num
cur index depth
last Block
TP fields
time stamp
root block num
cur index depth
last Block
collating_tp:
flags
xpx:
max_key_len:
n_components:
component.pos(1): 19
component.len(1): 5
....
as:
8-102
VOS System Analysis Manual (R073)
21
1
3
2
1
1
INDEX
0
006AEAD6
0
0
00211896: 00000001 00211896 00000001 00211896
006688BE
0D0888BA
00000001
never
00000001
00000000
1
-1
2
00000000
1
-1
2
1
dup_ok
00000780
5
1
dump_bmt
dump_bmt
8-
Purpose
This request displays information about the file partition bit map table for each disk on
a module.
Display Form
---------------------------------- dump_bmt -----------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
dump_bmt
Explanation
The dump_bmt request displays information about the file partition bit map table for
each disk on a module.
The analyze_system Command and Requests
8-103
dump_bmt
Examples
In the following example, the dump_bmt request displays information about the file
partition bit map table for each disk on a module.
as: dump_bmt
File partition info for disk m17
aftep:
801C5040
first_block:
10119
n_blocks:
178680
n_used:
125249
n_map_blocks:
6
n_free_bytes:
5814
byte_alloc_info:
current_block:
3
current_byte:
2573
bit_alloc_info:
current_block:
2
current_byte:
125
byte_withdraws:
70685
byte_failures:
0
bit_withdraws:
5283644
deposits:
5848825
bit_map_page # 1
bmex:
2
blockp:
94FDB000
first_block:
10119
n_blocks:
32768
n_bytes:
4096
bit_map_page # 2
bmex:
3
blockp:
94FDA000
first_block:
42887
n_blocks:
32768
n_bytes:
4096
bit_map_page # 3
bmex:
4
blockp:
94FD9000
first_block:
75655
n_blocks:
32768
n_bytes:
4096
....
File partition info for disk m17_more
aftep:
801C5560
first_block:
100011
n_blocks:
258568
n_used:
241698
n_map_blocks:
8
n_free_bytes:
1773
byte_alloc_info:
current_block:
1
current_byte:
0
8-104
VOS System Analysis Manual (R073)
dump_bmt
bit_alloc_info:
current_block:
current_byte:
byte_withdraws:
byte_failures:
bit_withdraws:
deposits:
bit_map_page # 1
bmex:
blockp:
first_block:
n_blocks:
n_bytes:
bit_map_page # 2
bmex:
blockp:
first_block:
n_blocks:
n_bytes:
bit_map_page # 3
bmex:
blockp:
first_block:
n_blocks:
n_bytes:
....
as:
1
767
0
0
97285
97019
9
94FD4000
100011
32768
4096
10
94FD3000
132779
32768
4096
11
94FD2000
165547
32768
4096
The analyze_system Command and Requests
8-105
dump_bsc
dump_bsc
8-
Purpose
The dump_bsc request displays information about the specified binary synchronous
communications (BSC) channel.
Display Form
---------------------------------dump_bsc--------------------------------------channel_name:
-meter:
no
Command-Line Form
dump_bsc channel_name
[-meter]
Arguments
* channel_name
Required
The name of the channel that you want information about. Do not include the pound
sign (#) character in the channel name. Use the list_devices command to list
the active BSC channels on a module.
* -meter
<CYCLE>
Displays metering information for the specified channel. The default value is no.
8-106
VOS System Analysis Manual (R073)
dump_bsc
Sample Output
In the following example, the dump_bsc request displays information about BSC
channel syn1.6.0. The table that follows the output describes many of the output
fields.
as: dump_bsc syn1.6.0
BCB for channel syn1.6.0 found at 8133E360
emulator:
13 (IBM 3780)
slot_no:
6
channel_no:
96
comm_controller_no:
3
com_mbxp:
80062000
timer_idx1:
68
timer_idx2:
69
modes:
suppress_idle_eot suppress_echo_eot using_3780
block_size:
512
buf_per_block:
6
rec_per_block:
10
buf_data_len:
128
buf_max_data_len:
125
record_size:
135
iob_rh_len:
0
frame_mode_hdr_len:
4
max_input_records:
100
max_input_buffers:
18
ten_byte_time:
9
turnaround_timer:
0
state:
1 (listen)
last_sent:
0 (no_msg)
last_read:
0 (no_msg)
timer_action:
0 (idle)
last_timeout:
15360
next_ack:
0
message_limit:
-1
nak_count:
0
enq_count:
0
timeout_count:
0
flags:
get_id
max_wacks:
0
recd wack_count:
0
max_naks:
15
max_enq:
15
max_bid:
15
max_dead:
7
nak_time:
1024
enq_time:
3072
REC queue:
0 input records queued (paged)
headp:
00000001
tailp:
00000001
OUT queue #1:
headp:
00000001
The analyze_system Command and Requests
8-107
dump_bsc
tailp:
00000001
records: 0
bytes:
0
OUT queue #2:
headp:
00000001
tailp:
00000001
records: 0
bytes:
0
OUT queue #3:
headp:
00000001
tailp:
00000001
records: 0
bytes:
0
IN queue:
0 input buffers queued (wired)
headp:
00000001
tailp:
00000001
RCV queue:
0 active buffers
headp:
00000001
tailp:
00000001
pending:
00000001
XMT headp:
00000001
last xmt block size:
0
ACK headp:
00000001
last ack block size:
0
CTL bufp:
80094F20
Free(6):
8008FEE0
protocol_name:
RS_bsc
(Page 1 of 2)
8-108
Field
Description
emulator
BSC emulator being used
slot_no
IOP slot number
channel_no
Logical channel number assigned by the
system
block_size
Value set by application
buf_per_block
System value
rec_per_block
Value set by application
buf_data_len
buf_max_data_len
System value
record_size
Value set by application
max_input_records
max_input_buffers
System value
VOS System Analysis Manual (R073)
dump_bsc
(Page 2 of 2)
Field
Description
state
State of communications link
last_sent
Last protocol message sent
last_read
Last protocol message received
nak_count
enq_count
timeout_count
Actual count during error recovery
max_naks
max_enq
max_bid
max_dead
Value set by application
nak_time
enq_time
System value
Related Information
For more information about BSC and BANCS, see the manual VOS Communications
Software: Binary Synchronous Communications (R027).
The analyze_system Command and Requests
8-109
dump_cache
dump_cache
8-
Purpose
This request dumps a summary of each cache buffer.
Display Form
---------------------------------- dump_cache -------------------------------*
name:
-all:
no
-full_path: no
-log:
no
-pin_info: no
Command-Line Form
dump_cache
[name]
[-all]
[-full_path]
[-log]
[-pin_info]
Arguments
* name
A file name or file star name for which to list cache activity. If you specify the -all
argument, the request ignores this argument. The default value is a star (*), or all
files.
* -all
<CYCLE>
Displays all cache activity on the module. If you specify no, the request displays
only those file names listed in the name argument. The default value is no.
* -full_path
<CYCLE>
Displays the full path name for all files using cache buffers. If you specify no, the
request displays only the file name. The default value is no.
8-110
VOS System Analysis Manual (R073)
dump_cache
* -log
<CYCLE>
Logs cache activity to the log partition until you issue the dump_cache request
again and specify a no value for this argument. For example:
as: dump_cache c* -log; sleep -minutes 5; dump_cache c*
Logging cache activity enables you to see periodic short-term cache activity. The
default value is no.
* -pin_info
<CYCLE>
If buffer pinning is enabled, this argument displays the buffer pin priority, pin count,
and time pinned. If you specify no, pinning information is not displayed. The default
value is no.
Explanation
The dump_cache request dumps a summary of each cache buffer.
Examples
In the following example, the dump_cache request displays information about all
caches having names that begin with the letter c.
as: dump_cache c*
phy
Block
State
Type
Name
136
6 UNMOD
V DIR
command_library
195
0 UNMOD
V DIR
cac
251
0 UNMOD
V DIR
cm
302
0 UNMOD
V DIR
command_library
...
356
0 UNMOD
V DIR
control_files
913
1 UNMOD
V DIR
command_library
941
28 UNMOD
V DIR
command_library
5516
-1 UNMOD
VR DIR
command_library
...
S => log page safe; R => reference count > 0
as:
The analyze_system Command and Requests
8-111
dump_cache
In the following example, the dump_cache request displays the full path name of all
caches on the module.
as: dump_cache -full_path
phy
Block
State
Type
Name
195
0 UNMOD
V DIR
#m19>system>postoffice>ship_to_dir>cac
283
14 UNMOD
V DIR
#m19>system>command_library
302
0 UNMOD
V DIR
#m19>system>command_library
303
2 UNMOD
V DIR
#m19>system>command_library
316
0 UNMOD
V DIR
#m19>system>tcp_os>command_library
341
8 UNMOD
V DIR
#m19>system>command_library
...
356
0 UNMOD
V DIR
#m19>system>postoffice>control_files
...
6077
0 UNMOD
V DIR
#m19>system>postoffice>ship_to_dir>chi1
S => log page safe; R => reference count > 0
as:
In the following example, the dump_cache request displays the pinning status for all
caches on the module.
as:
phy
2
3
4
...
16
17
18
as:
8-112
dump_cache -pin_info
Block
State
Type
0 UNMOD
VR FILE
1 UNMOD
VR FILE
2 UNMOD
VR FILE
93
-1
80
UNMOD
UNMOD
UNMOD
V FILE
VR FILE
V FILE
VOS System Analysis Manual (R073)
P PC
7 0
7 0
7 0
5
7
5
1
0
1
PSEC
598
598
598
Name
bitmap.m12_user.0
bitmap.m12_user.0
bitmap.m12_user.0
342 streams.cp.pm
501 tcp_kll.pm
342 streams.cp.pm
dump_cache
The following table describes the columns that appear in the output of the preceding
examples.
Column
Description
phy
The disk cache buffer number
Block
The file/directory block number
State
The disk cache buffer state. Values include UNMOD (unmodified),
MOD (modified), WRITE (writing to disk), READ (reading from disk). If -all is
used, NO MEM (no memory assigned), FREE (memory assigned but not tied to
a file or directory), and INVAL (a transitory state between FREE and READ) are
also possible.
Type
FILE, DIR (block belongs to file or directory, respectively)
P
V
R
S
The buffer pin priority
Virtual address assigned
Reference count > 0
Log page safe
PC
The buffer pin count.
PSEC
The number of seconds a buffer is pinned.
Related Information
See the descriptions of the display_cache_pin_parameters,
set_cache_pin_parameters, and dump_cache_info requests.
The analyze_system Command and Requests
8-113
dump_cache_info
dump_cache_info
8-
Purpose
This request displays information about the state of the disk cache.
Display Form
--------------------------dump_cache_info---------------------------------------all: n o
Command-Line Form
dump_cache_info
[-all]
Arguments
* -all
<CYCLE>
Displays additional disk cache statistics for debugging purposes. If you specify no,
this additional information is not displayed. The value no is the default value.
Explanation
This request display summary information about the disk cache configuration and the
state of the buffers. If buffer pinning is enabled, it also prints a summary of the number
of buffers pinned by priority level.
Several fields displayed by the dump_cache_info request contain information that is
also displayed by the display_tuning_parameters command. These fields also
correspond to the command arguments of the set_tuning_parameters command,
which you can use to change several cache parameters. The following table shows
these dump_cache_info fields along with their display_tuning_parameters
and set_tuning_parameters equivalents.
8-114
VOS System Analysis Manual (R073)
dump_cache_info
dump_cache_info
display_tuning_parameters
set_tuning_parameters
max phys
Cache manager, max buffers
-bm_max_buffers
min phys
Cache manager, min buffers
-bm_min_buffers
max virs
Cache manager, max virtual pages
-bm_max_virtual_pages
last_mod_grace_
time
Cache manager, modified grace
time
-bm_modified_grace
_time
unref_grace_
time
Cache manager, unreferenced
grace time
-bm_unreferenced_grace
_time
ref_grace_time
Cache manager, referenced grace
time
-bm_referenced_grace
_time
free_grace_time
Cache manager, free grace
-bm_free_grace_time
In addition to the above fields, the max phyps field displays the maximum number of
physical blocks that can be stored in the cache during the current bootload.
Examples
In the following example, the dump_cache_info request displays information about
the caches on the module.
as:
dump_cache_info
phyps:
phys:
virs:
max
8192
8192
4096
cur
8192
4481
3724
min
4481
32
32
first_mod_grace_time:
last_mod_grace_time:
real_last_mod_grace_time:
unref_grace_time:
ref_grace_time:
free_grace_time:
phy states
no memory
free
unmodified
modified
in use
3719
3339
1131
3
227
real
max
mem
max
log
max
8192
4096
8192
32766
240
60
60
300
60
300
seconds
seconds
seconds
seconds
seconds
seconds
(45.40% of total phyps)
(74.51% of total phys)
(25.24% of total phys)
(0.07% of total phys)
(5.07% of total phys)
The analyze_system Command and Requests
8-115
dump_cache_info
In the following example, the dump_cache_info request displays cache pinning
information.
as:
dump_cache_info
pinning
priority
priority
priority
priority
priority
priority
4
5
6
7
8
9
phys
0
218
0
0
0
0
% all
0.0
62.1
0.0
0.0
0.0
0.0
avg pin
0.0
1.0
0.0
0.0
0.0
0.0
avg secs
0
54
0
0
0
0
unpinned
1
0
4
94
20
14
% all
0.3
0.0
1.1
26.8
5.7
4.0
as:
This output shows that pinning is enabled, but only priority 5 has a pin count assigned.
The cache buffers (phys) are counted according to buffer pin priority, which is set to the
priority of the executing process whenever the buffer pin count is set.
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
phys
Number of phys (buffers) with nonzero pin-count: i.e., pinned phys
% all
Number of pinned phys as a percentage of disk cache size
avg pin
Average pin count of pinned phys
avg secs
Average number of seconds each phy has been pinned
unpinned
Number of nonfree phys with zero pin-count (i.e., unpinned phys)
Related Information
For more information about the display_tuning_parameters and
set_tuning_parameters commands, see the manual VOS System Administration:
Administering and Customizing a System (R281).
See also the descriptions of the display_cache_pin_parameters,
set_cache_pin_parameters, and dump_cache requests.
8-116
VOS System Analysis Manual (R073)
dump_channel_info
dump_channel_info
8-
Purpose
This request displays the channel information structure of a specified communications
channel on the analyzed module.
Display Form
-------------------------------- dump_channel_info ----------------------------channel_name:
-brief:
no
-format_driver_entries: no
Command-Line Form
dump_channel_info channel_name
[-brief]
[-format_driver_entries]
Arguments
* channel_name
The name of the channel you want information about.
Required
* -brief
<CYCLE>
Suppresses the display of information about driver table entries. The default is no.
* -format_driver_entries
<CYCLE>
Displays the kernel driver table entries allowed in each state specified.
The analyze_system Command and Requests
8-117
dump_channel_info
Explanation
The information displayed by the dump_channel_info request shows the current
state of the channel.
The channel information displayed using this request can be changed with the VOS
command update_channel_info. See the VOS System Administration:
Configuring a System (R287) for more information about this command.
Use the list_devices command, documented in the VOS Commands Reference
Manual (R098), to display a list of the active channels on a module.
Examples
In the following example, the dump_channel_info request displays the state of a
channel in its brief format.
as:
dump_channel_info term.113.2 -brief
Previous CIP:
Next CIP:
Event ID:
Interrupt Index:
Logical Chan No:
DVTEP:
DRIVER_TEP:
METERP:
TCBP:
Out of service:
Needs testing:
Force listen:
Login:
Dialup:
Loading Firmware:
Trace Enabled:
Firm Load Failed:
TZM:
Device Type:
81596A40
00000001
815B6B40
0
5
801B46E0
8151DE60
815B6C40
800857A0
no
no
no
yes
no
no
no
no
no
Unknown device type #0
(Continued on next page)
8-118
VOS System Analysis Manual (R073)
dump_channel_info
Timers:
0000
Error count:
5
Baud:
9600
Stop bits:
one
Parity:
odd
Device Index:
2
Bits per char:
7
Firmware Name:
async
Error time:
95-02-01 09:28:47 EST
Name Index:
6 (term.17.0.2)
UART error count: 0
UART error time:
None
UART Ints masked: no
Unmask UART Ints: no
Dialout:
yes
Using Firmware:
yes
Modem Speed Select: no
Break isnt ctrl-q: no
UART Error Rate Exceeded: no
IO_CONFIG_DATAP:
800C8F60
Salvage State:
0
as:
The following table describes some important fields in the output of the preceding
example.
Field
Description
DVTEP
The device table entry pointer
TTEP
The default terminal type entry pointer
TCBP
The terminal control block pointer
The analyze_system Command and Requests
8-119
dump_channels
dump_channels
8-
Purpose
This request displays information about the asynchronous communications channels
on the analyzed module.
Display Form
-------------------------------- dump_channels --------------------------------channel_name:
-normal:
no
-buffer:
no
-meter:
no
Command-Line Form
dump_channels channel_name
[-normal]
[-buffer]
[-meter]
Arguments
* channel_name
The asynchronous channel to display information about. If you do not specify a
channel name, the output includes information about all asynchronous channels on
the analyzed module.
* -normal
<CYCLE>
Displays basic information about the specified channel or channels. The operating
system uses this argument by default in the absence of the -buffer and -meter
arguments. You cannot specify both this argument and -buffer or -meter.
* -buffer
<CYCLE>
Displays data about the buffers associated with the specified channel or all the
channels. You cannot specify both this argument and -normal or -meter.
8-120
VOS System Analysis Manual (R073)
dump_channels
* -meter
<CYCLE>
Displays metering information about the specified channel or all the channels. You
cannot specify both this argument and -normal or -buffer.
Explanation
Use the list_devices command, documented in the VOS Commands Reference
Manual (R098), to display a list of the active channels on a module. Use the
dump_channels request to display a list of the active asynchronous channels on a
module.
Examples
In the following example, the dump_channels request displays information about all
of the asynchronous channels on the module.
as:
dump_channels
Channel name
S
C User
OC17
4
0
term.17.0.2
4
1
sync.17.0 not asynchronous.
sync.17.1 not asynchronous.
term.17.12.1
4 192
term.17.12.2
4 193
term.17.12.3
4 194
term.17.12.4
4 195 PreLogin
enet.17.13 not asynchronous.
....
as:
UART Interrupts
0700
5
0000
1
0500
0500
0500
0700
2
1
1
28618
Input
0
0
Output
300
0
0
0
0
5540
0
0
0
1117902
In the following example, the dump_channels request displays information about
channel term.17.12.2.
as: dump_channels term.17.12.2
Channel name
S
C User
term.17.12.2
4 193
as:
UART Interrupts
0500
1
Input
0
Output
0
The following table describes the most important columns that appear in the output of
the preceding example. The remaining output from a dump_channels request with no
arguments or with -normal shows the number of interrupts, the number of characters
of input, and the number of characters of output since the module was booted.
The analyze_system Command and Requests
8-121
dump_channels
Column
Description
The number of the slot containing the communications controller that controls
this channel
The channel number
UART
The UART status. (Interpreted values for this status are provided in the
Status column of the dump_tcbh request.)
In the following example, the dump_channels request displays information about the
buffers associated with channel term.17.12.2. The -buffer output displays
information about the five types of buffers associated with each channel (input,
collection, active, inactive, and echo). Then it shows the number of input, output, and
collection buffers held by each channel. If the dump_tcbh request shows a small
number of free buffers, this data indicates where buffers are being held.
as: dump_channels term.17.12.2 -buffer
Channel name
Input
Collec
Active
Inact
Echo
#In #Col #Out
term.17.12.2
00000001 00000001 00000001 00000001 00000001
0
0
0
as:
In the following example, the dump_channels request displays metering information
about channel term.17.12.2. The -meter output displays the following information
for each channel for the time period since the module was booted:
the number of characters input and output
the number of times the channel was locked
the number of times <CTRL><BREAK> was used
the number of attempts to dial up to a remote channel
the number of interrupts
as: dump_channels term.17.12.2 -meter
Channel name
Ichars
Ochars
term.17.12.2
0
0
as:
8-122
VOS System Analysis Manual (R073)
Locks
2
Breaks
0
Dialups
0
Ints
1
dump_comm_buffers
dump_comm_buffers
8-
Purpose
This request displays information about all of the buffers currently in use by an
asynchronous (device_type terminal) channel and, optionally, the data contained
in each buffer in use.
You cannot use this request on a window terminal device.
Display Form
-------------------------------- dump_comm_buffers ----------------------------channel_name:
-data:
no
Command-Line Form
dump_comm_buffers channel_name
[-data]
Arguments
* channel_name
Required
The name of the asynchronous channel to display buffer information about.
* -data
Displays the data contained in each of the buffers.
<CYCLE>
Explanation
The dump_comm_buffers request displays information about all of the buffers
currently in use by an asynchronous channel and, optionally, the data contained in
each buffer in use. The buffer chains displayed by dump_comm_buffers change
frequently. If this request is used in module mode, it is likely that the chains will appear
to be inconsistent.
The analyze_system Command and Requests
8-123
dump_comm_buffers
Examples
In the following example, the dump_comm_buffers request displays information
about all buffers in use by channel t1.32. The output shows five lists of buffer chains:
the input chain, the collection chain, the active chain, the inactive chain, and the echo
chain. The buffers are not cleared prior to use. Therefore, you must be careful when
examining the data. The count field shows the size of each buffer, tally shows a
decrementing count of available characters.
as:
dump_comm_buffers t1.32
INPUT CHAIN:
Input Buffer @005067B4:
Physical Addr:
Next Buffer:
Next to Process:
Next Block:
Control Bits:
Sync Control Bits:
Status Bits:
Exit Status:
Count:
Tally:
00FE27C0
00509EE8
97
00FDFEF4
interrupt_on_exit
opened_io_block
Not Exited
100
4
Input Buffer @00509EE8:
Physical Addr:
Next Buffer:
Next to Process:
Next Block:
Control Bits:
Sync Control Bits:
Status Bits:
Exit Status:
Count:
Tally:
00FDFEF4
00000001
1
FFFFFFFF
interrupt_on_exit
Not Exited
100
100
COLLECTION CHAIN:
Collection buffer @001ECFC4:
Next Buffer:
Max Byte:
Next Byte:
Count:
Record Type:
Code:
8-124
001F02C4
80
1
1
0
0
VOS System Analysis Manual (R073)
dump_comm_buffers
Collection buffer @001F02C4:
Next Buffer:
Max Byte:
Next Byte:
Count:
Record Type:
Code:
00000001
80
1
1
0
0
ACTIVE CHAIN:
INACTIVE CHAIN:
ECHO CHAIN:
Output Buffer @0050565C:
Physical Addr:
00FE3668
Next Buffer:
00000001
Flags:
State:
echo buffer
Next Byte:
1
Next Block:
FFFFFFFF
Control Bits:
Sync Control Bits:
Status Bits:
Exit Status:
Not Exited
Count:
0
Tally:
0
INPUT LINE COLLECTION BUFFER:
Collection buffer @001ECD84:
Next Buffer:
Max Byte:
Next Byte:
Count:
Record Type:
Code:
00000001
80
24
0
0
0
COMMAND LINE COLLECTION BUFFER:
Collection buffer @001F8C44:
Next Buffer:
Max Byte:
Next Byte:
00000001
80
3
The analyze_system Command and Requests
8-125
dump_comm_buffers
Count:
Record Type:
Code:
1
0
0
as:
In the following example, the dump_comm_buffers request displays the data
contained in each buffer in use by channel t1.32, as well as the information about
those buffers. The sample shown is an excerpt. In the first block, only the first 26
characters (count - tally) are current, and all have been processed (Next to
Process = 27). None of the characters in the second buffer are current (count tally = 0).
as:
dump_comm_buffers t1.32 -data
INPUT CHAIN:
Input Buffer @00509EE8:
Physical Addr:
Next Buffer:
Next to Process:
Next Block:
Control Bits:
Sync Control Bits:
Status Bits:
Exit Status:
Count:
Tally:
00
10
20
30
40
50
60
0D842064
8508842D
850D2E84
84850884
85080808
656C7385
6D6D5F62
61746185
64617461
2E737461
85088485
08648475
0D0D1B52
00FDFEF4
005067B4
27
00FE27C0
interrupt_on_exit
opened_io_block
Not Exited
100
74
08848508
850D6F67
72745F85
08848508
6D705F63
6484756D
84850884
67696E67
08848508
84850884
68616E6E
705F636F
Input Buffer @005067B4:
Physical Addr:
Next Buffer:
Next to Process:
Next Block:
Control Bits:
Sync Control Bits:
Status Bits:
Exit Status:
Count:
Tally:
8-126
00FE27C0
00000001
1
FFFFFFFF
interrupt_on_exit
Not Exited
100
100
VOS System Analysis Manual (R073)
| .. data.........
| ...-data..ogging
| .....start_.....
| ................
| .....d.ump_chann
| els....Rd.ump_co
| mm_b
|
|
|
|
|
|
|
dump_comm_buffers
00 75666665
10 7461850D
20 73746172
30 6D70636F
40 6D706C65
50 5F627566
60 1B45014B
as:
72732074
0D0D0D0D
745F6C6F
6D6D6275
850D6484
66657273
312E3332
0D6C8485
6767696E
66666572
756D705F
2074312E
202D6461
0D2E842E
67206475
732E7361
636F6D6D
3332850D
| uffers t1.32 -da
| ta.......l......
| start_logging du
| mpcommbuffers.sa
| mple..d.ump_comm
| _buffers t1.32..
| .E.K
|
The analyze_system Command and Requests
|
|
|
|
|
|
8-127
dump_eit
dump_eit
8-
Purpose
This request displays information about the executable image table (EIT) on the
analyzed module.
Display Form
------------------------------------ dump_eit ---------------------------------flags:
-long:
no
-summary: no
Command-Line Form
dump_eit flags
[-long]
[-summary]
Arguments
* flags
<CYCLE>
Specifies the search criteria used to scan executable image table entries (EITEs)
for matches. Values include kernel_pm, profile, network_case,
references_kernel, execute_in_kernel, and
profile_alignment_faults. If no EITEs exist that match a specified flag, the
request does not display any output.
* -long
<CYCLE>
Displays detailed information about each program currently in use on the analyzed
module.
* -summary
<CYCLE>
Displays the pathname of each program module currently in use on the analyzed
module and which processes are using it. This is useful for determining if program
modules are being shared or are being loaded and executed from a disk on another
module.
8-128
VOS System Analysis Manual (R073)
dump_eit
Examples
In the following example, the dump_eit request displays information about the
executable image table.
as:
dump_eit
EIT at 80139280
head(0):
tail(0):
lock_infop:
n_load_calls:
n_unload_calls:
n_links_snapped:
n_network_loads:
as:
8017C1A0
8266B120
8013F5E0
363215
363155
2926490, avg 8.06
2648
In the following example, the dump_eit request displays information about which
program modules are currently executing in the kernel.
as:
dump_eit execute_in_kernel
8024C600
%sys#m1>system>command_library>tp_overseer.pm
01118023 Overseer.System (TPOverseer)
as:
The analyze_system Command and Requests
8-129
dump_eit
In the following example, the dump_eit request displays information about which
program modules are currently in use on the analyzed module and which processes
are using them.
as:
dump_eit -summary
80204840
%sys#m1>system>kernel_loadable_library>mpx_gcomm.pmm
80205300
%sys#m1>system>kernel_loadable_library>async_al.cp.pmm
80205820
%sys#m1>system>kernel_loadable_library>sos.pmrary>list_cpus
80207340
%sys#m1>system>kernel_loadable_library>server_device.pm
80207E80
%sys#m1>system>kernel_loadable_library>streams.cp.pm
....
8020CB80
8020E720
%sys#m1>system>kernel_loadable_library>dkux.pm
%sys#m1>system>kernel_loadable_library>3270_remote.pm
8020F4A0
%sys#m1>system>kernel_loadable_library>sdlc.pm
80B7E880
%sys#m1>system>kernel_loadable_library>x25_lap.pm
80B7F520
%sys#m1>system>command_library>tp_overseer.pm
01118028 Overseer.System (TPOverseer)
80B809C0
%sys#m1>system>command_library>link_server.pm
01118029 Overseer.System (LinkServer1)
0111802A Overseer.System (LinkServer2)
0111802B Overseer.System (LinkServer3)
0111802C Overseer.System (LinkServer4)
0111802D Overseer.System (LinkServer5)
80B83140
%sys#m1>system>command_library>network_watchdog.pm
0111802E Overseer.System (NetworkWatchdog)
....
as:
8-130
VOS System Analysis Manual (R073)
dump_eit
In the following example, the dump_eit request displays detailed information about
each program module running on the analyzed module.
as:
dump_eit -long
EIT at 80139280
head(0):
tail(0):
lock_infop:
n_load_calls:
n_unload_calls:
n_links_snapped:
n_network_loads:
8017C1A0
820941C0
8013F5E0
363230
363169
2926668, avg 8.06
2648
EITE at 8017C1A0
flags:
kernel_pm references_kernel
nextp:
80204840
prevp:
00000001
program:
%sys#m1>system>kernel_loadable_library>vterm.pm
aftep:
00000001
ref ct:
1
base vm at:
80227000
paged VM at
8022B000
date_bound:
94-10-04 23:06:22 EST
main_lk.code:
00000000
main_lk.static:
00000000
init static_addr:
80229000
init static_len:
00000198
paged static_len:
000003F8
paged ext_static_addr: 8024A000
paged ext_static_len:
00000544
n_link_names:
120
n_unsnap_links:
131
n_entries:
1
link_nm_map_addr:
8025355A
link_nm_map_len:
00000FF0
link_map_addr:
8025454A
link_map_len:
00000312
entry_map_addr:
8025485C
entry_map_len:
0000002A
header_address:
80261C5C
header_len:
00000B56
n_stacks:
1
stack_len:
32768
user_heap_start:
00000000
user_boundary:
00000000
EITE at 80204840
program:
The analyze_system Command and Requests
8-131
dump_eit
%sys#m1>system>kernel_loadable_library>mpx_gcomm.pm
aftep:
00000001
ref ct:
1
base vm at:
80872000
wired VM at
80872000
paged VM at
80880000
date_bound:
94-10-04 23:05:52 EST
main_lk.code:
00000000
main_lk.static:
00000000
wired static_addr:
8087B000
wired static_len:
000000F0
....
as:
The following table describes the most important fields that appear in the output of the
preceding examples.
8-132
Field
Description
n_load_calls
The number of times program modules have been loaded since the
module was last booted
n_unload_calls
The number of programs finished since the module was last
booted. Note that the difference between this number and the
number of n_load_calls is the number of programs that are still
in progress.
n_links_snapped
The total number of links used and the average number of links per
program since the module was last booted
n_network_loads
The number of programs loaded across the network since the
module was last booted
aftep
The active file table entry pointer
VOS System Analysis Manual (R073)
dump_et
dump_et
8-
Purpose
This request displays the event table or selected entries from the event table.
Display Form
----------------------------------- dump_et -----------------------------------address:
-all:
no
-free:
no
-hash:
no
-header:
no
-remote:
no
-long:
no
-loop_lock: no
-match:
Command-Line Form
dump_et address
[-all]
[-free]
[-hash]
[-header]
[-remote]
[-long]
[-loop_lock]
[-match string]
Arguments
* address
The address of the event-table entry about which you want information. To obtain
a list of event-table entry addresses, first issue the dump_et request with the -all
The analyze_system Command and Requests
8-133
dump_et
argument. Note that you can issue the dump_et request specifying either the
address argument or the -all argument, but not both.
* -all
<CYCLE>
Displays a list of all the event table entries in use (event IDs) on the analyzed
module. You cannot specify both this argument and address.
Use -match with -all to limit the display to certain entries.
* -free
<CYCLE>
Displays the Free list, which is a list of the event numbers of all entries not in use.
* -hash
<CYCLE>
Displays all the events listed in the hash table. This includes all remote events and
all events with path names.
* -header
<CYCLE>
Displays the event table header and summary information about the events.
* -remote
<CYCLE>
Displays information about remote events being used by the analyzed module and
events on the analyzed module being used by other modules.
* -long
<CYCLE>
Displays all the event information for every event-table entry in use on the specified
module.
* -loop_lock
Displays information about hardware locks.
<CYCLE>
* -match string
Displays only those entries from the event table that match the given string.
Explanation
The dump_et request displays the event table or selected entries from the event table.
An event is a data structure used by processes to communicate with each other. An
event table is a list of all the events that exist on a module. See Chapter 2 in the VOS
Transaction Processing Facility Guide (R215) for further information about events.
8-134
VOS System Analysis Manual (R073)
dump_et
Examples
In the following example, the dump_et request displays the event table for the
specified network change event.
as: dump_et C1124F80
ETE at C1124F80 for network change event
wait_list:
C1729288 -> C1724740: Overseer.System (TheOverseer)
C174ECE0 -> C1727000: Overseer.System (BatchOverseer)
C15CB784 -> C15CD640: Overseer.System (MailTransport2)
C1722490 -> C171C000: Overseer.System (TPOverseer)
lock:
8000
flags:
system
array_slot_ptr:
C10123C0
event count:
16719 (0000414F)
last full count:
16719 (0000414F)
pended notify-1s: 0 (00000000)
status:
00000000
uid:
0.0000.00000000.00000000.0000.0000
(80-01-01 00:00:00 edt)
ref_cnt:
6
name_len:
20
ex_ete_ptr:
00000001
as:
The following table describes the most important fields that appear in the output of the
preceding example.
Field
Description
wait_list
The name of each process that is currently waiting for the event
status
The status passed to the event by the last caller to notify. This is used
only for user events.
ref_cnt
The number of processes attached to this event
event count
The number of times this event has been notified
The analyze_system Command and Requests
8-135
dump_et
In the following example, the dump_et request displays all the in-use event table
entries on the analyzed module. Each entry lists the event-table entry address, event
count, and event name.
as:
dump_et -all
All nonfree ETEs:
80C11080
29119
80C115A0
96261
80C11620
0
80C116A0
547
80C11960
1307
80C11A00
3613684
80C4C180
224931
813CE560
113
813D2340
74
813D23C0
73
813D2440
73
813D24C0
73
813D2540
73
813D25C0
73
813EAB80
2
813FB440
0
813FB4C0
16931
813FB540
980
813FEB80
0
813FECC0
0
...
813FF080
0
8140D800
0
81411920
748
81522D40
13546
81522DC0
0
81523FC0
24649
8156CB20
1
8156CC20
0
81523F40
23005
8156CBA0
0
81526E40
0
8156CCA0
0
8156CD20
0
8156CDA0
0
8156CE20
0
8156CEA0
0
8156CF20
0
8156CFA0
0
8156DA60
4
....
as:
8-136
network_notify_event
stopped_process_event
system_sleep_event
red_light_interrupt_event
page_wait_event
page_fault_event
syserr_buffer_event
diag proc
chan lock event 1
chan lock event 2
chan lock event 3
chan lock event 4
chan lock event 5
chan lock event 6
Add Comm Ctlr Event
packet pool 1
packet pool 2
packet pool 3
net boomer 1
net boomer 2
net boomer 8
Back-Release Sockets
Login Device Event
network change event
VCTE lock event
TpOverseer Signal Event
event_for_clock
event_for_clock
TpOverseer Wait Event
event_for_clock
comm_trace
event_for_clock
event_for_clock
event_for_clock
event_for_clock
event_for_clock
event_for_clock
event_for_clock
device_event_for_OC17
VOS System Analysis Manual (R073)
dump_et
In the following example, the dump_et request displays the Free list, consisting of the
address of the event-table slots of all unused events.
as:
dump_et -free
Free list:
81783C48,
81783BE0,
81783D20,
80C11480,
80C114DC,
80C11470,
80C114FC,
81783C94,
80C114D8,
81783C14,
81783E04,
80C114D0,
81783CB0,
81783C20,
81783DF4,
81783E58,
80C1142C,
81783CC4,
81783C5C,
81783D4C,
81783DE4,
81783BA8,
81783BD4,
80C114D4,...
as:
In the following example, the dump_et request displays all events listed in the hash
table. Each entry shows the address of the event-table entry number, forward and
backward pointers, and the event name.
as:
dump_et -hash
Hash table:
Hash 1
0069E560 (00000001 00000001) for %s1#d01>system>hardware_error_event
Hash 2
0069FBE0 (00000001 04AC2E30) for remote_shadow.010A20CE
04AC2E30 (0069FBE0 00000001) for %s1#d01>system>load_control_event
Hash 7
007A5830 (00000001 00000001) for remote_shadow.010A80DA
Hash 9
0482C560 (00000001 00000001) for %s1#d01>system>syserr_log_event
Hash 11
04A61A70 (00000001 00000001) for remote_shadow.010AD0CA
Hash 12
049DDB00 (00000001 00000001) for %s1#d01>system>echo_event
Hash 24
0069FCD0 (00000001 00000001) for %s1#d01>system>system_red_light_event
Hash 26
0494FF10 (00000001 00000001) for
%s1#d01>process_dir_dir>pd.010E1D1B.Overseer>_aq4DgWaaabqaaabY.temp
Hash 30
048AEF00 (00000001 00000001) for remote_shadow.0106404F
....
as:
The analyze_system Command and Requests
8-137
dump_et
In the following example, the dump_et request displays summary information about
the events listed in the event table. The -header argument produces this output.
as:
dump_et -header
EVENT TABLE at 00180A10
flags:
max_events_per_proc:
max_events_per_task:
max_events:
time_event_sim_int:
n_etep_arrays:
n_events:
n_extended_events:
free_slot_ptr:
hw_lock.lockp:
broadcast_lock.lock_word:
free_slot_lock.lock_word:
hash_lock.lock_word:
shadow_lock.lock_word:
timed_lock.lock_word:
n_calls:
n_waits:
n_no_wait_calls:
as:
dynamic_max_events
256
64
65535
1
2
348
57
04814610
00006242
8000
8000
8000
8000
8000
589970
585067
4969
In the following example, the dump_et request displays information about remote
events. The first line of each entry shows the event-table entry address, the event
count, and the name of the event. For a remote event being used by the analyzed
module, the second line displays information about the module on which the event
exists. For a local event being used on a remote module, the second and subsequent
lines display information about each remote module that is using the event.
A shadow is a copy of a remote event made by VOS and stored for use on a local
module. A shadow event is created when you attach to an event on another module.
The shadow points to the real event on the remote module and is used for event
operations.
as:
dump_et -remote
Shadow ETEs:
0078BCB0
8900
%hq_net#d00>system>postoffice>registration.global.sysdb
0.3601.00000000.0000143B.0000.64E5
007A3550
2 0105.shadow.04863CF0
0.0105.0000272A.1563064F.00C7.0041
Remote ETEs:
04A11100
8-138
1 REQ event for mail_reader.server
0110
VOS System Analysis Manual (R073)
dump_et
049716A0
12 REQ event for mail_reader.server
0111
as:
The following is sample output from the dump_et request that shows information about
hardware locks. An asterisk (*) in the VALUE column indicates that the lock is currently
locked. A low value indicates (see page control lock below) the process number
holding the lock. Any value with the high bit (MSB) set is unlocked.
as:
dump_et -loop_lock
LOCK ADDR
00006000
00006002
00006004
00006006
00006008
0000600A
0000600C
0000600E
00006010
00006012
00006014
00006016
00006018
0000601A
0000601C
0000601E
00006020
00006022
00006024
00006026
00006028
0000602A
0000602C
0000602E
00006030
00006032
00006034
00006036
00006038
0000603A
0000603C
0000603E
00006040
VALUE
0000*
8000
8000
8000
8000
8000
FFFF
8000
8000
001D*
8000
8000
8000
8000
8000
8000
8000
8000
8000
8000
8000
8000
8000
8000
8000
FFFF
FFFF
FFFF
FFFF
8000
8000
FFFF
8000
LOCK NAME
process_control_lock
timer_manager_lock
pcp_entry_lock
Lock List Header
wired lock cow stomach
paged lock cow stomach
Wired Heap
trace_data_lock
syserr_buffer_lock
page_control_lock
pc_q_lock
map_lock
disk_csq
disk_control
disk_queue
MASTER CHANNEL LOCK
TCB HEADER LOCK
buffer_pool.199DFC
interim_io_cpu_lock
Comm Heap
net driver table
net buffer pool
buffer_pool.1A0FCE
net socket table
link_boot_info table
tape_1.lk
tape_2.lk
tape_3.lk
tape_4.lk
diag cmd q
Login Device Database Lock
Paged Heap
Virtual Circuit Entries
....
The analyze_system Command and Requests
8-139
dump_et
In the following example, the dump_et request displays information about all non-free
event table entries containing the character string tape_op.
as:
dump_et
-match tape_op
All nonfree ETEs:
005D5F90
4
0067AD00
0
0067AD70
0
as:
8-140
VOS System Analysis Manual (R073)
tape_op_chain_lock
tape_op_chain_lock
tape_op_chain_lock
dump_events
dump_events
8-
Purpose
This request displays information about the events being used by the current analyzed
process.
Display Form
--------------------------------- dump_events ---------------------------------event_no:
-attached: no
-kernel:
no
-long:
no
-task:
Command-Line Form
dump_events event_no
[-attached]
[-kernel]
[-long]
[-task task_id]
Arguments
* event_no
The event number of the event about which you want information. The event_no
is a per-process index into the table of events attached by the process. The table
provides the true system event ID value, an ETEP.
* -attached
<CYCLE>
If this switch is on, VOS displays a list of all the events being used by the process.
* -kernel
<CYCLE>
If this switch is on, VOS displays information about the processs kernel events.
The analyze_system Command and Requests
8-141
dump_events
* -long
<CYCLE>
If this switch is on, VOS displays more information about each event and its usage.
* -task task_id
The task_id of the tasks about which you want information. Information about
other tasks in the process is not displayed.
Examples
In the following example, the dump_events request displays events associated with
the analyzed process.
The following table describes some of the fields that appear in the output.
Field
Description
TASK
The task ID of the waiting task
EVENTNO
The event ID used by the process
ETEP
The address of the event-table entry
EVENTCNT
The event count
NEXT-NOTIFY
A two-part number consisting of (1) the task number of the next task
that has a notified event, and (2) the event number of that event
as:
dump_events
SYNC_WAIT_LIST at 006A6AF0 for Overseer.System (BatchOverseer)
flags:
thread_notify update_event_counts
num_tasks:
1
first notify:
TASK
1
EVENTNO
2
3
4
5
7
8
9
ETEP
FLAGS
006A6E30
006A7E20
006A7BB0
005CFF90
048C9060
04AD4EC0
04A39DA0
TASK TIMEOUT
as:
8-142
VOS System Analysis Manual (R073)
EVENTCNT
00001F68
0000001F
00000D67
00000A73
00000013
0000C754
00000000
NEXT-NOTIFY PRI
0
0
0
0
0
0
0
dump_events
In the following example, the dump_events request displays all events used by the
current process.
as:
dump_events -attached
EVENT_ID_TABLE at 047A8D10 for Overseer.System (BatchOverseer)
Event_no
ETEP
Name
1
006A6D60
''
2
006A6E30
''
3
006A7E20
SERVER for batch.server_queue
4
006A7BB0
SERVER for batch.one_way_server_
5
005CFF90
network change event
6
0066E140
TpOverseer Wait Event
7
048C9060
File local
8
04AD4EC0
0105.shadow.04ACD1F0
9
04A39DA0
File rebuild_12
as:
In the following example, the dump_events request displays information about each
event and its usage.
as:
dump_events -long
SYNC_WAIT_LIST at 006A6AF0 for Overseer.System (BatchOverseer)
flags:
thread_notify update_event_counts
num_tasks:
1
macro_ete_ptr:
006A6D60
timeout_list:
prevp=00000001 nextp=00000001
notify_list:
prevp=00000001 nextp=00000001
SYNC_LIST at 048ECB30
pte_ptr:
sync_wait_ptr:
flags:
task_id:
task_priority:
task_timeout:
max_sync_objects:
num_sync_objects:
006A0850
006A6AF0
thread_notify update_event_counts
0001
0000
00007FFFFFFFFFFF
0007
0007
SYNC_OBJECT_INFO(0) at 048ECB4C
sync_list_ptr:
00000000
sync_objectp:
00000000
last_event_count:
00000000
wait_links:
prevp=00000000 nextp=00000000
flags:
notify_priority:
0
user_event_no:
0
SYNC_OBJECT_INFO(1) at 048ECB7C
sync_list_ptr:
048ECB30
sync_objectp:
006A6E30
The analyze_system Command and Requests
8-143
dump_events
last_event_count:
wait_links:
flags:
notify_priority:
user_event_no:
00001F68
prevp=00000001 nextp=00000001
0
2
SYNC_OBJECT_INFO(2) at 048ECBAC
sync_list_ptr:
048ECB30
sync_objectp:
006A7E20
last_event_count:
0000001F
wait_links:
prevp=00000001 nextp=00000001
flags:
notify_priority:
0
user_event_no:
3
....
as:
8-144
VOS System Analysis Manual (R073)
dump_firmware_names
dump_firmware_names
8-
Purpose
This request displays the firmware configured for the analyzed module.
Display Form
-------------------------------- dump_firmware_names ----------------------------No arguments required. Press ENTER to continue.
Command-Line Form
dump_firmware_names
Explanation
The dump_firmware_names request lists all the firmware name values in a kernel
structure built from the firmware.table file by the configure_firmware_types
command. The request lists each value only once, regardless of how many times the
value is repeated in the file.
The analyze_system Command and Requests
8-145
dump_firmware_names
Examples
In the following example, the dump_firmware_names request displays the firmware
configured for the module.
as: dump_firmware_names
Max firmware types = 002D
firmware name:
bsc
bsc_nasdaq
bsc_djnr
tse
ose
bsc_swift
bsc_fas
bsc_chips
sdlc
x25_lap
3270_host
3270_remote
amex_h3270
hasp
bsc_hasp
as:
8-146
VOS System Analysis Manual (R073)
dump_fli
dump_fli
8-
Purpose
This request displays information about one or more file_lock_info (FLI)
structures. An FLI structure is a structure that holds information about records and keys
locked by a transaction.
Display Form
---------------------------------- dump_fli ---------------------------------address:
-brief:
no
-full:
no
-blocked_lists:
no
-follow_chain:
-output_path:
Command-Line Form
dump_fli address
[-brief]
[-full]
[-blocked_lists]
[-follow_chain]
[-output_path file_name]
Arguments
* address
Required
A typical analyze_system address string that represents the location of the FLI
structure. Such addresses are normally contained in Transaction State Information
(TSI) files and other FLIs.
* -brief
<CYCLE>
Suppresses the display of the individual record and key locks attached to the FLI.
By default, the request displays these locks. Note that the request does not display
the individual record and key locks for any of the additional FLIs displayed in the
The analyze_system Command and Requests
8-147
dump_fli
blocked_list chain or other chains unless you also specify the -full
argument.
* -full
<CYCLE>
Displays the individual record and key locks attached to all FLIs. By default (the
value no), the request does not display these locks. Because the -full argument
can generate a large amount of output, you should specify this argument with the
-output_path argument. If you specify this argument interactively, you might
want to observe the members of the chains and then issue the dump_fli request
with the specific address of any chain for which you would like more information.
* -blocked_lists
<CYCLE>
Traverses the read and write blocked_lists and displays each FLI member. By
default, this action does not occur. (A blocked list is a data structure containing a
list of transactions that are currently blocked because they are waiting for locks.)
* -follow_chain
<CYCLE>
Displays a chain of FLIs, depending on which of the following values you specify.
If you do not specify a value, the request does not display any chains.
If you specify the afte (active-file table) value, the request displays the chain
of FLIs rooted at the active-file table of which the specified FLI is a member.
First, the request displays the specified FLI, followed by all FLIs before it,
beginning with the first FLI pointed to by the active-file table. The request then
displays all FLIs after the specified FLI, up to the end of the chain. This ensures
that you can view all FLIs associated with a files particular lock mode.
If you specify the tsi value, the request displays the chain of FLIs rooted at
the Transaction State Information (TSI) structure of which the specified FLI is
a member. First, the request displays the specified FLI, followed by all FLIs
before, ending with the first FLI pointed to by the TSI. The request then displays
all FLIs after the specified FLI, up to the end of the chain. This ensures that you
can view all FLIs associated with a particular transaction.
If you specify the waiting value, the request displays the chain of FLIs rooted
at the FLI blocked list of which the specified FLI is a member (note that the
request displays this information only if the FLI is blocked). First, the request
displays the specified FLI, followed by all FLIs before, ending with the first FLI
pointed to by the blocking FLI. The request then displays all FLIs after the
specified FLI, up to the end of the chain. This ensures that you can view all
read-blocked or write-blocked FLIs that are waiting for another FLI. Note that
these FLIs are ordered first by priority, then by transaction ID (TID) value.
If you specify the all value, the request displays all of the chains described in
this list.
8-148
VOS System Analysis Manual (R073)
dump_fli
* -output_path file_name
Directs the output from the terminals screen to file_name. By default, the
request directs output to the terminals screen.
Explanation
This request displays a single FLI structure and optionally, a list of associated FLI
structures.
Examples
The following example illustrates the use of the dump_fli request.
as:
dump_fli 802A74E0 -brief
File_lock_info: 802A74E0
by_tsi:
by_afte:
tsi_ptr:
afte_ptr:
afte name:
afte last record:
tp old last record:
tp last record:
required tplock:
req_tplock_ptr:
links:
rec w locked:
existed:
exists:
cur_size:
log_len:
log_offset:
waiting:
blocked_list(0):
blocked_list(1):
file lock type:
tp lock flags:
record_r_list:
record_w_list:
n_indexes:
locks on index:
r_list (1):
w_list (1):
802A74E0: 00000001
802A74F0: 802AC0E0
802822A0
8028FEC0
other_file
20
20
20
record write lock
802AD020
802AD020: 00000001
9
true
true
254
256
-2146589171
802A7540: 00000001
802A7520: 00000001
802A7530: 00000001
reserve write lock
abort/deadlock
802A7560: 802ACF20
802A7574: 00000001
1
oth_idx
802A758C: 802921C0
802A75A0: 00000001
80282310 00000001 80282310
802AC0F0 802AB7E0 802AB7F0
00000001 00000001 00000001
802AC120 00000001 802AC120
802A7520 00000001 802A7520
802A7530 00000001 802A7530
802ACF20 802ACF20 802ACF20
802A7574 00000001 802A7574
802921C0 80290CC0 80290CC0
802A75A0 00000001 802A75A0
The analyze_system Command and Requests
8-149
dump_fw_table
dump_fw_table
8-
Purpose
This request displays the protocols and hardware associated with the firmware
configured on the analyzed module.
Display Form
------------------------------- dump_fw_table ---------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
dump_fw_table
Explanation
The dump_fw_table request displays all the firmware configured for the analyzed
module. In addition, it lists each communications card or I/O adapter and the protocol
associated with each firmware type. Note that firmware is configured with the
configure_firmware_types command, which is described in the manual VOS
System Administration: Configuring a System (R287).
8-150
VOS System Analysis Manual (R073)
dump_fw_table
Examples
In the following example, the dump_fw_table request displays the protocols and
hardware associated with the firmware configured on the module.
as: dump_fw_table
fw ptr = 00606468
pr ptr = 00606808
hw_protocol_table ptr = 00606C28
fw link ptr = 0050C188
Max firmware types = 002D
Max protocol types = 002E
Max hardware types = 0025
firmware name = bsc
hardware name = C107
protocol name = RS_bsc
hardware name = C107
protocol name = RS_3270_host
....
hardware name = C107
protocol name = RS_ose
hardware name = C109
protocol name = RS_ose
....
firmware name = sdlc
hardware name = C107
protocol name = RS_sdlc
hardware name = C109
protocol name = RS_sdlc
....
firmware name = x25_lap
....
hardware name = K114
protocol name = RS_x25_lap
hardware name = K119
protocol name = RS_x25_lap
....
as:
The analyze_system Command and Requests
8-151
dump_giza
dump_giza
8-
Purpose
Dumps host-side data structures that contain Giza engine information that is based on
the variable os_giza_control_tablep$.
Display Form
--------------------------------- dump_giza --------------------------------0
iop_no:
-all:
no
-salvage_forward: yes
-salvage_backward: yes
-long:
no
Command-Line Form
dump_giza iop_no
[-all]
[-salvage_forward]
[-salvage_backward]
[-long]
Arguments
* iop_no
The IOP slot number for the Giza engine.
* -all
Specifies that all Giza engines will be dumped.
* -salvage_forward
Specifies that the request follow the command ring salvage pointer forward.
* -salvage_backward
Specifies that the request follow the command ring salvage pointer backward.
8-152
VOS System Analysis Manual (R073)
dump_giza
* -long
Specifies that the request list any outstanding MDBs on the command ring.
Explanation
Dumps host side data structures that contain Giza engine information that is based on
the variable os_giza_control_tablep$. Giza engine information includes a single
command ring along with the seven different response rings.
Examples
In the following example, the dump_giza request displays host side data structures
that contain Giza engine information.
as: dump_giza
os_giza_control_tablep$ at 00550EE0
SLOT: 22
ENGINE: 00553990
COMMAND RING: 00553A10
ring size: 64
input_index: 20
output_index: 20
ring_start_virt: 00553A50 salvage_hp: 00556000
salvage_tp: 005551D0
ring_phys_addr: 00000000 Overflow_list_hp: 00000001 Overflow_list_tp:
00000001
salvage list head: 00556000
1st MDB: 00556000 callback: llc+1005A, line 4287
chan: 1600005F
stat: 0
return_index: 4
next MDB: 00556190 callback: llc+1005A, line 4287
chan: 1600005F
stat: 0
return_index: 4
salvage list tail: 005551D0
last MDB: 005551D0 callback: llc+123F6, line 4840
chan: 16000096
stat: 0
return_index: 4
prev MDB: 00557EA0 callback: llc+E4AE, line 3760
chan: 16000097
stat: 0
return_index: 4
RESPONSE RINGS:
M_AND_D RING:
ring_start_virt:
00553CC0
00553D00
size: 64 input_index: 0 output_index: 0
overflow hp: 00000000 overflow tp: 00000000
CPU DEBUG RING:
ring_start_virt:
00553E10
00553E50
size: 64 input_index: 0 output_index: 0
overflow hp: 00000000 overflow tp: 00000000
INTERRUPT RING:
ring_start_virt:
00553F60
00554000
size: 64 input_index: 0 output_index: 0
overflow hp: 00000000 overflow tp: 00000000
UNLOCK INTER RING: 00554110
ring_start_virt:
00554150
size: 64 input_index: 0 output_index: 0
overflow hp: 00000000 overflow tp: 00000000
The analyze_system Command and Requests
8-153
dump_giza
QRUN RING:
ring_start_virt:
00554260
005542A0
SCHEDULER RING:
0ring_start_virt:
00000000
005543B0 size: 64 input_index: 0 output_index:
005543F0 overflow hp: 00000000 overflow tp:
UNLOCK SCHED RING: 00554500
ring_start_virt:
00554540
8-154
size: 64 input_index: 37 output_index: 35
overflow hp: 00000000 overflow tp: 00000000
size: 64 input_index: 40 output_index: 40
overflow hp: 00000000 overflow tp: 00000000
VOS System Analysis Manual (R073)
dump_h3270
dump_h3270
8-
Purpose
The dump_h3270 request displays information about the specified 3270_host
channel.
Display Form
---------------------------------- dump_h3270 -------------------------------channel_name:
cux:
0
devx:
0
-long:
no
Command-Line Form
dump_h3270 channel_name
[cux]
[devx]
[-long]
Arguments
* channel_name
Required
The name of a primary channel that you want information about; do not specify a
subchannel. Do not include the pound sign character (#) in the channel name. Use
the list_devices command to list the active 3270_host channels on a module.
* -cux
Selects the control unit index. If you specify a value other than 0, the request
displays information about the specified control unit. This value must be 1 greater
than the channels mpx_number value in the devices.tin file. The default value
is 0.
The analyze_system Command and Requests
8-155
dump_h3270
* -devx
Selects the device index. If you specify a value other than 0, the request displays
information about the sub-device. This value must be 1 greater than the channels
sub_dev_number value in the devices.tin file. The default value is 0.
You must specify a nonzero value for cux if you specify a value for devx.
* -long
<CYCLE>
Displays additional output fields. The default value is no.
Examples
The following example shows output from the dump_h3270 request in two forms, the
default shorter form and the -long form. The table that follows the output describes
many of the output fields.
as: dump_h3270 32h1.8.0
H3270 ctl block for channel 32h1.8.0 found at 81671E60
flags:
ebcdic
state:
2 (control)
last_sent:
8 (eot_msg)
last_rcvd:
6 (enq_msg)
last_ack:
0
flags:
started dsr xmt_active
n_controllers:
1
Cur CU: -1
Cur DV: -1
Rcv buffer count:
32
rcv_headp:
80095EA0
rcv_tailp:
80095C20
pending_input:
00000001
xmt_bufp:
80095220
ack_bufp:
00000001
ctl_bufp:
00000001
free buffer count: 4
free_headp:
80095D60
input_queue_length:
7
input_interrupts:
1624
output_interrupts:
0
dsl_interrupts:
2
timer_interrupts:
0
firmware_string:
bsc
cup(0):
81671FE0
as: dump_h3270 32h1.8.0 -long
H3270 ctl block for channel 32h1.8.0 found at 81671E60
ctlr_no:
3
slot_no:
6
channel_no:
128
com_mbxp:
80062000
timer_idx1:
68
timer_idx2:
69
8-156
VOS System Analysis Manual (R073)
dump_h3270
timer_idx3:
baud:
flags:
state:
last_sent:
last_rcvd:
last_ack:
enq_count:
nak_count:
timeout_count:
timer_action:
flags:
n_controllers:
Cur CU: -1
Cur DV:
Rcv buffer count:
32
rcv_headp:
rcv_tailp:
pending_input:
xmt_bufp:
ack_bufp:
ctl_bufp:
free buffer count: 4
free_headp:
input_queue_length:
input_interrupts:
output_interrupts:
dsl_interrupts:
timer_interrupts:
firmware_string:
cup(0):
70
14 (9600)
ebcdic
2 (control)
8 (eot_msg)
6 (enq_msg)
0
0
0
0
2
started dsr xmt_active
1
-1
80097B40
800978C0
00000001
80095220
00000001
00000001
80097A00
7
3923
0
2
0
bsc
81671FE0
(Page 1 of 2)
Field
Description
slot_no
IOP slot number
channel_no
Logical channel number assigned by the
system
flags
Info on port setup
state
Protocol line state
last_sent
Last protocol message sent
last_rcvd
Last protocol message received
enq_count
nak_count
Count during error
The analyze_system Command and Requests
8-157
dump_h3270
(Page 2 of 2)
Field
Description
flags
Internal information
n_controllers
Number of controllers opened
input_queue_length
Number of input buffers
input_interrupts
output_interrupts
dsl_interrupts
timer_interrupts
On-going count per channel
firmware_string
Firmware being used
cup(n)
Pointer to the control unit structure for unit
n (cux is n + 1)
Related Information
For more information about 3270_host support and emulation, see the manual VOS
Communications Software: 3270 Support and 3270 Emulation (R026).
8-158
VOS System Analysis Manual (R073)
dump_iop_equip_table
dump_iop_equip_table
8-
Purpose
This request displays the contents of the IOP equipment table.
Display Form
----------------------------- dump_iop_equip_table --------------------------No arguments required. Press ENTER to continue.
Command-Line Form
dump_iop_equip_table
Explanation
Before using this request, you must issue the use_iop request and specify an IOP on
the module.
Examples
In the following example, the dump_iop_equip_table request displays the contents
of the IOP equipment table using IOP number 1. The (abbreviated) output includes
three sections, reflecting the three major resources that the IOP ES operating system
manages:
IOA statusthe IOA slots
ENTITY statusthe IOP entities (drivers)
CHANNEL statusthe logical channels that connect VOS drivers through the
IOP to the firmware on the IOA.
The sample output also includes printouts, available with Release 14.0, for the second
chassis (available on the K600 only). The DEADBEEF value in the Status column
indicates that no K600 is present.
Ellipses (...) in the output indicate where data has been deleted for the sake of brevity.
The analyze_system Command and Requests
8-159
dump_iop_equip_table
as: dump_iop_equip_table
as: use_iop -iop_no 1
as: dump_iop_equip_table
IOP equipment table at 000B87A0
IOA status
IOA
Entity
Type
Priority
Status
E_ptr
0
2
74
7
80050020
00000001
initialized, alive, present, running
1
4
70
7
80050020
00000001
initialized, alive, present, running
2
4
87
7
80050020
00000001
initialized, alive, present, running
3
4
87
7
80050020
00000001
initialized, alive, present, running
4
4
87
7
80050000
00000001
initialized, alive, present
5
4
87
7
80050000
00000001
initialized, alive, present
6
4
87
7
80050000
00000001
initialized, alive, present
7
4
87
7
80050020
00000001
initialized, alive, present, running
...
16
-1
-16657
-8531
DEADBEEF
00000001
initialized, exception, alive, present, running, prom_start, testing,
burning_p
+rom, soft_reset
17
-1
-16657
-8531
DEADBEEF
00000001
initialized, exception, alive, present, running, prom_start, testing,
burning_p
+rom, soft_reset
18
-1
-16657
-8531
DEADBEEF
00000001
initialized, exception, alive, present, running, prom_start, testing,
burning_p
+rom, soft_reset
...
ENTITY status
Entity
Type
Status
E_ptr
1
5
00000000
00000001
Cmd_entry at: 00026040 x -> jug_disk_entity+128, line 305
Cfg_entry at: 00026D98 x -> jug_disk_entity+E80, line 643
Slot_entry at: 00028BA4 x -> jug_disk_entity+2C8C, line 1246
2
2
80000000
00000001
Cmd_entry at: 0000807C x -> generic_comm_driver+7C, line 402
Cfg_entry at: 00008E50 x -> generic_comm_driver+E50, line 824
Slot_entry at: 00009388 x -> generic_comm_driver+1388, line 1033
3
8-160
6
00000000
00000001
Cmd_entry at: 00018C44 x -> iop_ctape_entity+94, line 243
Cfg_entry at: 00018F2E x -> iop_ctape_entity+37E, line 344
Slot_entry at: 000194AC x -> iop_ctape_entity+8FC, line 619
VOS System Analysis Manual (R073)
dump_iop_equip_table
4
Cmd_entry at:
Cfg_entry at:
Slot_entry at:
5
Cmd_entry at:
Cfg_entry at:
Slot_entry at:
1234
Cmd_entry at:
Cfg_entry at:
Slot_entry at:
...
CHANNEL status:
Channel
Entity
1
4
initialized
2
4
initialized
3
4
initialized
35
4
initialized
as:
80000000
0001B6D0 x ->
0001D2D4 x ->
0001DD10 x ->
80000000
0004E944 x ->
0004E9E2 x ->
0004E98A x ->
00000000
0001A6F4 x ->
0001A7BA x ->
0001A832 x ->
00000001
jug_gci_entity+9B8, line 692
jug_gci_entity+25BC, line 1569
jug_gci_entity+2FF8, line 1939
00000001
jug_giza_entity+6C, line 367
jug_giza_entity+10A, line 397
jug_giza_entity+B2, line 381
00000001
iop_test_entity+4, line 29
iop_test_entity+CA, line 62
iop_test_entity+142, line 74
Type
0
Priority
0
Status
80000000
E_ptr
000CAD3C
80000000
000C6F1E
80000000
000C2362
80000000
000CADC6
The analyze_system Command and Requests
8-161
dump_iop_meters
dump_iop_meters
8-
Purpose
This request displays the meters maintained by the IOP Environment Services (ES) in
the IOP.
Display Form
------------------------------- dump_iop_meters -----------------------------No arguments required. Press ENTER to continue.
Command-Line Form
dump_iop_meters
Explanation
The dump_iop_meters request displays information about the current IOP.
NOTE
To use this request, you must have used use_iop
previously to select an I/O processor. See the use_iop
request for more information.
8-162
VOS System Analysis Manual (R073)
dump_iop_meters
Examples
In the following example, the dump_iop_meters request displays IOP metering
information, based on an I/O processor you selected previously with the use_iop
request.
as: dump_iop_meters
IOP meters at 0003A262
Syserr
10
Bgnd_calls 557551932
Timer_call 1079161
Dma_calls 24016
Byte_avg
2048
Cmd_send
7768
Interrupts 13022
Failed_syserr
Bgnd_time
Time
Dma_byte
Dma_time_avg
Cmd_recv
ENTITY meters at 0003A2EC
Entity: 0
Calls
Commands
130
Bgnd_callback
0
Timer_callback 1084969
Interrupts
0
0
0
2145319
49184768
1
7764
Bgnd_avg 0
Timer_avg 1
Dma_time 37178
Host_busy 0
Time
254
0
2145322
0
Avg
128
0
129
0
Max
621
0
1486
0
Time
28027
0
0
69229
Avg
240
0
0
348
Max
480
0
0
5997
Entity: 1
Commands
Bgnd_callback
Timer_callback
Interrupts
Calls
7636
0
0
13022
Entity: 2
....
as:
The analyze_system Command and Requests
8-163
dump_iop_meters
The following table describes the columns that appear in the output of the preceding
example.
8-164
Columns
Description
Syserr
The number of system error messages recorded by the IOP.
Failed_syserr
The number of failed system errors recorded.
Entity
The type of driver on the IOP.
0 - ES (IOP OS)
1 - Command disk
2 - Communications
3 - Cartridge tape
4 - GCI SCSI
5 - Giza (message passing protocol)
Bgnd_callback
Information about background callbacks.
Timer_callback
Information about timer callbacks.
Cmd_send
Cmd_recv
The number of commands sent and received, respectively
Host_busy
The number of times the host was busy and did not accept
commands from the IOP.
Interrupts
The numbers of interrupts handled by the IOP.
VOS System Analysis Manual (R073)
dump_lap_meters
dump_lap_meters
8-
Purpose
This request displays the LAPB protocol meters. LAPB stands for Link Access
ProrocolBalanced, the link-level protocol for X.25.
Display Form
------------------------------- dump_lap_meters -----------------------------channel_name:
Command-Line Form
dump_lap_meters channel_name
Arguments
* channel_name
Required
The name of a LAPB channel from which meters are being dumped.
Explanation
The dump_lap_meters request displays the meters maintained by the LAPB protocol
driver for an active (open) LAPB channel.
Counts are set to 0 when the channel is opened; otherwise, there is no reset capability.
The analyze_system Command and Requests
8-165
dump_lap_meters
Examples
In the following example, the dump_lap_meters request displays LAPB metering
information.
as: dump_lap_meters phx
***** LAP METERS *****
interrupts = 2621966
dsl_interrupts = 1
input_interrupts = 1346993
output_interrupts = 1291494
timeouts = 39
xmit_timeouts = 0
frames_sent = 1304571
frames_rcvd = 1433412
chars_sent = 225816896
chars_rcvd = 43692087
read_waits = 776538
write_waits = 263220
crc_errors = 3
rej_frames_rcvd = 772
timer_recoveries = 89
aborts_rcvd = 56
as: dump_lap_meters cac_s2
***** LAP METERS *****
interrupts = 2492731
dsl_interrupts = 4
input_interrupts = 1086891
output_interrupts = 1104842
timeouts = 1
xmit_timeouts = 0
frames_sent = 1106811
frames_rcvd = 1091424
chars_sent = 10659418
chars_rcvd = 16440040
read_waits = 478658
write_waits = 0
timer_recoveries = 80
input_int_time (msec) = 1350045.00
msec per input int = 1.24
msec per input frame = 1.24
output_int_time (msec) = 594396.40
msec per output int = 0.54
msec per output frame = 0.54
as:
8-166
VOS System Analysis Manual (R073)
dump_lcb
dump_lcb
8-
Purpose
This request enables you to examine the control block of a LAPB channel. LAPB
stands for Link Access ProrocolBalanced, the link-level protocol for X.25. lcb stands
for LAPB_control_block.
Display Form
----------------------------------- dump_lcb --------------------------------channel_name:
-long:
no
Command-Line Form
dump_lcb channel_name
[-long]
Arguments
* channel_name
The name of the LAPB channel control block to examine.
Required
* -long
If -long is set to yes, the requests output includes the head and tail pointers to
the write, send, resend, recv, and read queues, as well as information
contained in the frames on those queues, such as EOF, count, tally, and data.
The default is no.
Examples
The following is sample output from a dump_lcb request that specifies information for
a LAPB channel being used by a StrataNET X.25.
as: dump_lcb stratnet
lap_dfr_interval$ = 15
***** LCB DUMP *****
LCB addr = 816F4320
The analyze_system Command and Requests
8-167
dump_lcb
state = Info_xfer
addrs: cr = 1 cs = 3 rr = 3 rs = 1
Node type is DCE.
loopback_mode = -1
baud_rate = 56000
t1 = 3073 n2 = 5 k = 7
t2 = 0
config_flags: defer_dsl_drop
frame_size = 517
bufs_per_frame = 8
max_output_bufs = 40
recv_low_wat = 9
recv_overflow = 0
recv_bufs = 41
input_bufs = 41
dfr_cnt = 0
dfr_pm_action = 0
dfr_pm_code = 0
dfr_last_time = 0 (80-01-01 00:00:00 edt)
dfr_msg =
Vs = 6 Vr = 1 As = 1 Ar = 6
xfer_flags:flags:
trace_mode = on
free_bufs = 40
free_bufp = 80091E00
as:
The following table describes the fields in the dump_lcb requests output.
(Page 1 of 2)
8-168
Field
Description
LCB addr
The physical location in the wired comm heap of the control
block for this channel
state
The current state of the LAPB line. The states are:
firmware_load, undefined, Stopped, DSR_wait,
SABM_wait, SABM_setup, DISC_send, Info_xfer,
FRMR_send, SABM_reset, Down_send, and Down.
addrs
CR is the command receive address
CS is the command send address
RR is the response receive address
RS is the response send address
loopback_mode
Indicates if the channel is in loopback mode
baud_rate
The line speed the channel has been configured for.
VOS System Analysis Manual (R073)
dump_lcb
(Page 2 of 2)
Field
Description
t1,...t2,...n2,
...k
The value of the t1 and t2 timers and the values of LAPB
parameters n2 and k are displayed
config_flags
The user-configurable flags that have been set. Possible
values are defer_dsl_drop, send_dm_response,
accept_non_final_dm, and accept_unsolicited_dm.
frame_size
The LAP frame size
bufs_per_frame
The number of buffers per frame
max_output_bufs
The maximum number of output buffers for this line
recv_low_wat
The receive side low-water mark count of buffer
recv_overflow
The number of receive overflows that have occurred on this
channel
recv_bufs
The number of receive buffers currently available. Displayed
only if the number of buffers is nonzero
input_bufs
The number of receive buffers wired in memory. Displayed only
if the number of buffers is nonzero.
output_bufs
The number of output buffers available. Displayed only if the
number of buffers is nonzero.
Vs, Vr
As, Ar
The following are displayed when the line is in
INFO_XFER_STATE. They are used for protocol state control.
Vs, VrThe sequence state variables
As, ArThe send and receive acknowledgment variables
xfer_flags
The xfer_flag values are sending_I_frame,
output_hold, timer_recovery, rej_sent, rnr_recv,
rnr_sent, and recv_timeout_enabled
flags
The possible flags values are runout, broken,
output_blocked, need_output_buf,
xmt_timeout_enabled, consecutive_xmt_timeouts,
frmr_control, frmr_zyxw, and frmr_response
trace_mode
Modes are on, off, auto-start
free_bufs
The number of free buffers for this line
free_bufp
The pointer to the head of the free buffer chain
The analyze_system Command and Requests
8-169
dump_lock
dump_lock
8-
Purpose
The dump_lock command displays information on a specific kernel database lock or
locks, as well as associated meters.
Display Form
---------------------------------- dump_lock --------------------------------address:
-name:
-member:
-brief: yes
-meters: no
Command-Line Form
dump_lock
[address]
[-name lock_star_name]
[-member [member_lock_star_name]]
[-brief]
[-meters]
Arguments
* -address
Displays the locks for the specified address.
* -name lock_star_name
Displays the locks that match this star name. You can supply this instead of a lock
address.
* -member [member_lock_star_name]
Displays all members of a group lock.
8-170
VOS System Analysis Manual (R073)
dump_lock
* -no_brief
Displays additional information about each lock.
<CYCLE>
* -meters
<CYCLE>
Displays lock usage meters of the lock being displayed. By default, these meters
are not displayed.
Explanation
The dump_lock request displays the system locks.
Examples
In the following example, the dump_lock request displays lock information for the
module.
as: dump_lock
lock name
---------
address
-------
Lock List Header
wired lock cow stomach
paged lock cow stomach
wired lock queue
paged lock queue
Wired Heap 0
process_creation_lock
unique_id_lock
config table
Loop locks 0
I/O Heap 0
hardware history table
maint int
mem_test_page
....
Total Locks: 179532515
Minimum Cost: 18296.465 seconds of
as:
C1016140
C1016280
C10163C0
C1016500
C1016640
C1016780
C10168C0
C1016A00
C1016B40
C1016C80
C1017A80
C101E200
C101F240
C10202C0
type
---single
single
single
single
single
single
single
single
single
single
single
group
single
single
lock state
----------
num locks
---------
unlocked
unlocked
unlocked
unlocked
unlocked
unlocked
unlocked
unlocked
unlocked
unlocked
unlocked
unlocked
unlocked
unlocked
326
34
330
6169
2448986
1515239
432762
196801
39858
197302
1549
776062
18552
0
cpu time
In the following example, the dump_lock request displays detailed information about
each lock on the module.
as: dump_lock -no_brief
Lock info at C1016140
name:
lock_wordp:
lock_state:
type:
flags:
pool:
spin_limit:
Lock List Header
C0803180 -> 0000x
unlocked
1 (single)
wired
-1
0 (0.000 seconds)
The analyze_system Command and Requests
8-171
dump_lock
Lock info at C1016280
name:
lock_wordp:
lock_state:
type:
flags:
pool:
spin_limit:
Lock info at C10163C0
name:
lock_wordp:
lock_state:
type:
flags:
pool:
spin_limit:
....
as:
wired lock cow stomach
C0804180 -> 0000x
unlocked
1 (single)
wired
-1
forever
paged lock cow stomach
C0805180 -> 0000x
unlocked
1 (single)
wired
-1
128 (0.002 seconds)
In the following example, the dump_lock request displays detailed information about
a lock at a specified address. Address information for all locks on a module can be
obtained by issuing the dump_lock request with no arguments.
as: dump_lock C10203C0
Lock info at C10203C0
name:
lock_wordp:
lock_state:
type:
flags:
pool:
spin_limit:
as:
recc_md_recc_mand_channel_lock
C080AF80 -> 0000x
unlocked
1 (single)
wired
-1
0 (0.000 seconds)
In the following example, the dump_lock request displays information about the
system group lock.
as: dump_lock -member system*
lock name
--------system
system_default
address
-------
C0AD49C0 member
C0B0D080 member
Total Locks: 0
Minimum Cost: 0.000 seconds of cpu time
as:
8-172
VOS System Analysis Manual (R073)
type
----
lock state
----------
num locks
---------
unlocked
unlocked
98552
1
dump_lock
In the following example, the dump_lock request displays detailed information about
the system lock.
as: dump_lock -name system
Lock info at C0AD49C0
name:
lock_wordp:
lock_state:
type:
flags:
pool:
group_lock_infop:
as:
system
C080FF00 -> 0000x
unlocked
0 (member)
-1
C0AD0180
In the following example, the dump_lock request displays detailed information about
the system lock, including the number of spins for a lock word, and the number of lock
writes per lock.
as: dump_lock -name system -meters
Lock info at C0AD49C0
name:
system
lock_wordp:
C080FF00 -> 0000x
lock_state:
unlocked
type:
0 (member)
flags:
pool:
-1
group_lock_infop:
C0AD0180
n_spins_for_lock_word:
2 (0.002% of total locks)
n_lock_word_failures:
1 (50.000% of n_spins_for_lock_word)
n_write_locks:
98647
write_meters:
n_waits:
1283 (1.301% of locks)
n_false_notifies:
57 (4.443% of n_waits)
wait_time:
3004724 (mean 35.735 milliseconds)
The following table describes the columns that appear in the output of the preceding
examples.
Column
Description
lock name
The name of the lock.
address
The address of the lock.
type
The type of the lock. Types can be single or group.
lock state
The state of the lock. States can be locked, unlocked
num locks
The total number of times the lock was locked since the last time the
system was booted.
The analyze_system Command and Requests
8-173
dump_lock
The following table describes the fields that appear in the output of the preceding
examples.
Field
Description
Total Locks
The total number of locks that were locked by all processes since the
last time the system was booted.
Minimum Cost
The number of seconds of CPU time spent holding locks for all
processes since the last time the system was booted.
Related Information
For more information about locks, see the description of the lock_meters and
lock_summary requests.
8-174
VOS System Analysis Manual (R073)
dump_mt
dump_mt
8-
Purpose
On XA/R-series modules, this request displays information about the memory table
configured for the analyzed module. On Continuum-series modules, the request
indicates how much memory there is.
Display Form
------------------------------------- dump_mt ----------------------------------long: n o
Command-Line Form
dump_mt [-long]
Arguments
* -long
<CYCLE>
Displays more detailed information about the memory table.
Explanation
On XA/R-series modules, the dump_mt request displays information about the memory
table configured for the analyzed module. This request is useful for determining if
memory boards are duplex or nonduplex.
On Continuum-series modules, the dump_mt request indicates how much memory
there is and suggests using list_boards to obtain details on memory configuration.
The analyze_system Command and Requests
8-175
dump_mt
Examples
In the following example, the dump_mt request displays memory table information for
an XA/R-series module.
as: dump_mt
Configured memory 65536 pages, 256MB.
4 memories configured, 1 present.
Pages present: 65536
Slot
20
21
22
23
as:
Defined
Partner
21
20
23
22
Paired
with
Size
21
20
-1
-1
256MB.
256MB.
0MB.
0MB.
Address
Defined
duplex
0MB.
0MB.
missing
missing
yes
yes
no
no
Defined Wireable
address
none
none
none
none
no
yes
The following table describes the columns, other than Slot and Defined Partner,
that appear in the output in the preceding example.
(Page 1 of 2)
8-176
Column
Description
Paired with
Indicates the current duplex state of the board. A value of -1
indicates that the memory board is not configured, not present,
or not working.
Size
The size of the memory on the board. A value of 0MB indicates
that the memory board is not configured, not present, or not
working.
Address
Is the first (or base) physical address served by the controller.
The range served can be determined from the address and the
size fields. A value of missing indicates that the memory board
is not configured, not present, or not working.
Defined duplex
Indicates the requested state of memory duplexing. It is set
according to the duplex attribute in the boards table and
subsequently modified by the reconfigure_memory
command, documented in the manual VOS System
Administration: Configuring a System (R287).
Defined address
The address wired onto the board. If no address is wired, the
output is none.
VOS System Analysis Manual (R073)
dump_mt
(Page 2 of 2)
Column
Description
Wireable
Indicates whether a memory controller can have wired pages.
Note that the requirements of a particular subsystem may place
additional restrictions on the location of wired pages.
In the following example, the dump_mt -long request displays information about the
memory table and each memory board on the analyzed module.
as: dump_mt -long
Memory table at:
Number of memories:
Maximum memory:
Present memory:
User limit:
Boot memory type:
Config lock ptr:
Flags:
MEMORY #1
Slot:
Duplex slot:
Duplex memory #:
Size:
Base address:
Memory type:
Flags:
MEMORY #2
Slot:
Duplex slot:
Duplex memory #:
Size:
Base address:
Memory type:
Flags:
MEMORY #3
Slot:
Duplex slot:
Duplex memory #:
Size:
Base address:
Memory type:
Flags:
....
as:
80E929C0
4
131072 pages, 512MB
65536 pages, 256MB
NONE
FREEWAY-256MB
80E92BC0
initialized,
20
21
2
256MB
0MB
FREEWAY-256MB
present,def duplex,tested
21
20
1
256MB
0MB
FREEWAY-256MB
present,def duplex,wireable,tested
22
23
0
0MB
-1
UNKNOWN
missing
The analyze_system Command and Requests
8-177
dump_mt
In the following example, the dump_mt request displays the amount of memory on a
Continuum-series module and suggests using list_boards for details on memory
configuration.
as: dump_mt
Configured memory 131072 pages, 512MB.
Memory table information is not supported for a Continuum-series
product.
For details on memory configuration, use list_boards.
as:
8-178
VOS System Analysis Manual (R073)
dump_net_info
dump_net_info
8-
Purpose
Displays StrataNET status information for a system.
Display Form
------------------------------- dump_net_info ------------------------------system_name:
-module_name:
-gateway_name:
-stations:
-nct:
no
-ngt:
no
-nrt:
no
-ngt_calls:
no
-all:
no
-long:
no
-header:
no
Command-Line Form
dump_net_info
[-system_name system_name]
[-module_name module_name]
[-gateway_name gateway_name]
[-stations station_number]
[-nct]
[-ngt]
[-nrt]
[-ngt_calls]
[-all]
[-long]
[-header]
The analyze_system Command and Requests
8-179
dump_net_info
Arguments
* -system_name system_name
Specifies the name of the system for which you want StrataNET status information.
Do not precede the system name with the percent sign (%) prefix. By default, the
request displays StrataNET status information for all systems with gateways to the
current system.
* -module_name module_name
Specifies the name of the module for which you want StrataNET status information.
Do not precede the module name with the number sign (#) prefix. By default, the
request displays StrataNET status information for all modules on the system.
* -gateway_name gateway_name
Specifies the name of the gateway for which you want StrataNET status
information. By default, the request displays StrataNET status information for all
gateways on the system.
* -stations station_number
Specifies the station number for which you want StrataNET status information. By
default, the request displays StrataNET status information for all stations on the
system. Note that the station number is usually the same as the module number.
Check the modules.tin file for correspondence between the module and station
numbers.
* -nct
Displays the network client table.
* -ngt
Displays the network gateway table.
* -nrt
Displays the network routing table.
* -ngt_calls
Displays the calls made to the network gateway table.
<CYCLE>
<CYCLE>
<CYCLE>
<CYCLE>
* -all
<CYCLE>
Displays the network client table, network gateway table, network routing table, the
status of all modules in the system, the status of all systems connected to the
current system, and the network client table header.
* -long
<CYCLE>
For each (specified) module in the system, displays the network address, number
of requests, lock ID, and state, and for each (specified) system, displays the bridge
address and socket, number of requests, lock ID, state, and additional information.
8-180
VOS System Analysis Manual (R073)
dump_net_info
* -header
<CYCLE>
Displays the network client table header, which lists the number of messages sent
to the system and module by size and volume.
Explanation
The dump_net_info request displays information about the current status of
StrataNET for a module, system, or entire network.
Examples
In this example, the dump_net_info request displays the status of StrataNET.
as:
dump_net_info
Network Gateway Table - NGT at (ngtp$) 80170840x
Max Gateways: 1
Nr Gateway
Module Eventid Process
1:swc_nimbus
1-23 00000000 00000000
Network Route Table - NRT at (nrtp$) 80170960x
max_sysno: 197
Sys System Name
Nbr
Delay
Network
Gate Gateway Name (*-> best route)
Hops Total First Address
--- ------ -------------------------------- ---- ----- ----- -------------197 swcnim
*-> 1 swc_nimbus
1
2
2
Network Client Table - NCT at (nctp$) 8016AC00x
------------------------MODULES--------------------------------------Mod NetAdr Requests Flags Lock Id State Mod Name TCP Link Rsv Socket
--- ------ -------- ----- -------- ----- -------- --------- ---------1
3
57409
80215C20 Clean
m3
0
0
3
6 10097687
80215D00 Clean
m6
0
0
4
10
71441
80204260 Clean
m10
0
0
5
14 15289848
802045A0 Clean
m14
0
0
6
21
107211
802048E0 Clean
m21
0
0
7
27
780585
802049C0 Clean
m27
0
0
....
------------------------SYSTEMS---------------------------------------Sys Bridge-Skt Lcl Fnl
Requests Unclean State
System Name TCP Net
--- ---------- --- --- ----------- -------- ------- ----------- ------1
10
2
1
1
0 00000000 Clean
es
0
4
10
6 -1
4
10657 1FFFFFFF Clean
mktg
0
5
10 16 -1
5
3022 FFFFFFFF Clean
ht2
0
6
10
6 -1
6
32030 8CEFFFBF Clean
cac
1
7
10
2 -1
7
7617 E383FFFF Clean
swsle
0
8
10 16 -1
8
3022 FFFFFFFF Clean
ht4
0
....
The analyze_system Command and Requests
8-181
dump_net_info
NCT HEADER:
max_module: 25 max_system: 247
last_timeout: 95-06-15 11:17:21 EDT
n_requests:
55256621
Total Messages:
Size
Messages
% of Total
6:
17294538
15.65
7:
21135416
19.13
8:
29718818
26.90
9:
29132363
26.37
....
110445285
The following table describes the columns that appear in the MODULES section of the
output of the preceding example.
Column
Description
Mod
The module number
NetAdr
The modules station number
Requests
Number of transactions to other modules in that system
Flags
Possible values are: uncl and t/o for unclean and timed out
Lock Id
Pointer to the lock
State
Possible values are Clean and Unclean
Mod Name
The name of the module in the system
TPC Link
The module that has been connected via StrataLINK using TCP
Rsv Socket
The socket TCP link is using
The following table describes the columns that appear in the SYSTEMS section of the
output of the preceding example.
(Page 1 of 2)
8-182
Column
Description
Sys
The system number
Bridge
The module in the current system used for the bridge to the system
designated by Sys
Skt
The socket number for the bridge
Lcl
Values are 1 if the system is local and -1 if the system is remote
Fnl
The system number of the funnel for the system
VOS System Analysis Manual (R073)
dump_net_info
(Page 2 of 2)
Column
Description
Requests
The number of transactions to other systems
Unclean
64 bits (The maximum number modules in a system is 64) per module. If
the module exists and the bit is 0, the module is clean. If the module
exists and the bit is 1, the module is unclean. If no module exists, then
the switch is set to all Fs. The module number corresponds to the bit
number.
State
Possible values are Clean and Unclean
System Name
The name of the system connected to the current system
TCP Net
The system that has been connected via StrataNET using TCP
Related Information
For more information about StrataNET-related analyze_system requests, see the
description of the dump_net_tids, dump_nst, dump_prt, dump_rsv_socket,
dump_socket, and dump_socket_info requests.
The analyze_system Command and Requests
8-183
dump_net_tids
dump_net_tids
8-
Purpose
This request displays transaction IDs (TIDS) for StrataLINK stations on a module.
Display Form
--------------------------------- dump_net_tids -------------------------------station_numbers:
-all:
no
-full:
no
Command-Line Form
dump_net_tids
[station_numbers ids]
[-all]
[-full]
Arguments
* station_numbers ids
The station numbers of 0 or more link stations for which you want to display net
TIDS. You cannot specify this argument if you specified the -all argument. If you
specify backbone stations, add 128 to the station number before specifying the
value.
* -all
<CYCLE>
Displays information about all station numbers (1255), if you also specify the
-full argument.
* -full
<CYCLE>
Displays of information about all specified stations, whether or not the station entry
contains nonzero data. If you do not specify this argument, the request displays
information only about stations that are in use.
8-184
VOS System Analysis Manual (R073)
dump_net_tids
Explanation
The dump_net_tids request displays TIDs for StrataLINK stations on a module. The
request reads this information from the network socket table (NST).
The protocol requires the server to remember the client TIDs for the last 15 transactions
served by the server.
Examples
In the following example, the dump_net_tids request displays TIDS for StrataLINK
stations on a module.
as:
dump_net_tids 17
Station Information from Net Socket Table - NST
at (nstp$) 80C49B00x
Station Skt Mode Last Served Skt TID
Client TID Slots Unsafe TID Slots
------- ----------- ---- ---- ---------------- ---------------17 Extended
0:
0 0000 0000000000000000 1000000000000000
1: 257 D531
2: 278 4CE2
3: 278 4CE3
4: 278 4CE4
5: 278 4CE5
6: 278 4CE6
7: 278 4CE7
8: 278 4CE8
9: 278 4CE9
10: 278 4CEA
11: 278 4CEB
12: 278 4CEC
13: 278 4CED
14: 278 4CEE
15: 257 D80F
BB 17 Extended
0:
0 0000 0000000000000000 1111111111111111
as:
The analyze_system Command and Requests
8-185
dump_net_tids
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
Station
The station number.
Skt Mode
The socket mode.
Last Served
Index of saved entry
Skt
Client socket
TID
Client TID served
Client TID Slots
Bitmap of used slots
Unsafe TID Slots
Outstanding requests
Related Information
For more information about StrataNET-related analyze_system requests, see the
description of the dump_net_info, dump_nst, dump_prt, dump_rsv_socket,
dump_socket, and dump_socket_info requests.
8-186
VOS System Analysis Manual (R073)
dump_nst
dump_nst
8-
Purpose
This request displays the net socket table (NST) for a StrataLINK or StrataNET
connection on a module.
Display Form
----------------------------------- dump_nst --------------------------------socket_numbers:
-header:
no
-full:
no
-long:
no
-reset:
no
-all:
no
Command-Line Form
dump_nst
[socket_numbers...]
[-header]
[-full]
[-long]
[-reset]
[-all]
Arguments
* sockets_numbers...
The numbers of zero or more regular socket numbers to be displayed. You cannot
specify this argument if you specify -all.
* -all
<CYCLE>
Displays all sockets. You cannot specify this argument if you specify a value for
socket_numbers.
The analyze_system Command and Requests
8-187
dump_nst
* -header
<CYCLE>
Displays NST header information. If you give this argument by itself, then only
header information is displayed.
* -full
<CYCLE>
Displays in-depth information about each socket; in particular, if socket transaction
lists or input queues exist, they are listed.
* -long
<CYCLE>
Displays in-depth information; in some cases, the request displays more than one
table. For example, when reserved sockets are listed, any subordinate regular
sockets are listed adjacent to the reserved sockets.
* -reset
<CYCLE>
Temporarily resets the meters in the NST header. The meters are reset for only this
execution of analyze_system. The request resets the meters after it reports the
current values.
Explanation
Sockets are used by StrataLINK and StrataNET to route messages between Stratus
modules. StrataLINK and StrataNET sockets are completely distinct from the sockets
used by TCP/IP for addressing.
If you do not specify the socket_numbers, -all, or -header arguments, the
request assumes you meant to specify the -all and -header arguments.
To display the most information about a network socket, specify dump_nst -long.
8-188
VOS System Analysis Manual (R073)
dump_nst
Examples
In the following example, the dump_nst request displays the NST header.
as:
dump_nst -header
Net Socket Table - NST at (nstp$) 80C49B00x
nst_max_socket$:
4096
lockp:
80006660
locker_pid:
00000000
metering_time:
869:35:51
COUNT
ATB
/SEC
lock_count
987382931
3.2 315.4
lock_cycles
1016677401
3.1 324.8
client_requests
57812063
54.2
18.5
slot_zero_requests
225200
13901.2
0.0
worry_rcvd
185 16921900.0
0.0
dead_sent
120 26087930.0
0.0
tiderr_sent
232 13493750.0
0.0
iwait_sent:
0
sockets attached: 1-6 256-261 263-276 278-287 289-290 292 294-296 300
{dump_socket_info -full -long
{dump_rst
{dump_prt
as:
for most information }
Reserved Socket Table}
Pending Request Table}
Related Information
For more information about StrataNET-related analyze_system requests, see the
description of the dump_net_info, dump_net_tids, dump_prt,
dump_rsv_socket, dump_socket, and dump_socket_info requests.
The analyze_system Command and Requests
8-189
dump_poll_select
dump_poll_select
8-
Purpose
This request displays the state of a poll/select line or a poll/select terminal.
Display Form
------------------------------- dump_poll_select ------------------------------channel_name:
-address:
Command-Line Form
dump_poll_select channel_name
[-address address]
Arguments
* channel_name
Required
The name of the channel that you want information about. Do not include the
number sign (#) in the channel name.
* -address address
The two-character address of a terminal that you want to display information about.
The terminal must be open.
Explanation
If you specify only the channel name, the output displayed shows information that VOS
maintains internally about the state of the poll/select line and any terminals that are
currently open. The information displayed is from the channel data cd structure. You
can use the list_devices command, documented in the VOS Commands
Reference Manual (R098), to display a list of the active channels on a module.
If you specify a terminal address in the -address argument, the information displayed
includes the state of the specified poll/select terminal.
8-190
VOS System Analysis Manual (R073)
dump_poll_select
The information displayed is from the subchannel data (subch) structure. The
information displayed by the channel_name and -address arguments can overlap.
Examples
In the following example, the dump_poll_select request displays two poll/select
terminals on the line have been opened: a terminal with address aa and a terminal with
address ab.
as: dump_poll_select sync.7.34
"cd" structure for channel sync.7.34 found at 001C1334
comm_controller_no:
2
slot_no:
12
channel_no:
2
com_mbxp:
007F809C
control_bufp:
001AE806
sim_interrupt_index:
8
baud:
9600 (14)
group_address:
(2020x)
poll_address:
aa (6161x)
select_address:
(2020x)
state:
3 (idle)
last_xmit:
6 (poll)
poll_interval:
1024 time units (65536 jiffies, 1000 msec)
slow_poll_interval:
120 seconds
poll_response_timeout:
1.8574 seconds (1902 time units)
msg_response_timeout:
1.8574 seconds (1902 time units)
n_input_bufs:
0
xmit_number_length:
0
input_buf_data_size:
1026
max_input_msg_size:
1024
max_output_msg_size:
1024
max_input_queue_length: 4
write_retry_count:
0
nak_count:
0
timeout_count:
0
msgs_written:
0
selects_since_poll:
0
max_poll_timeouts:
4
max_select_timeouts:
4
max_write_timeouts:
3
max_poll_naks:
10
max_write_naks:
10
max_write_retrys:
5
flags:
half_duplex dsr
n_terminals:
2
terminal #1
terminal_address:
group_address:
aa (6161x)
(0404x)
The analyze_system Command and Requests
8-191
dump_poll_select
poll_address:
select_address:
n_channels:
poll_timeouts:
max_input_msg_size:
max_output_msg_size:
flags:
single_subchp:
terminal #2
terminal_address:
group_address:
poll_address:
select_address:
n_channels:
poll_timeouts:
last_poll_try:
max_input_msg_size:
max_output_msg_size:
flags:
single_subchp:
first_subchp:
last_subchp:
uart_status:
flags:
input_subchp:
input_bufp:
input_type:
input_expected_for:
next_terminal:
n_broken_terminals:
next_poll_subchp:
first_poll_subchp:
last_poll_subchp:
poll_subchp:
output_subchp:
output_bufp:
first_output_subchp:
last_output_subchp:
trace_datap:
trace_data_n_entries:
trace_enabled:
interrupt_count:
aa (6161x)
aa (6161x)
1
0
0
0
single_device
001BF656
ab (6162x)
(0404x)
ab (6162x)
ab (6162x)
1
4
0B82FACA (64 seconds)
0
0
broken single_device
001B7618
001BF656
001B7618
41
output_complete input_available
control_buf_output
00000001
001C17AA
1 (eot)
00000001
1
1
00000001
00000001
00000001
00000001
00000001
00000001
00000001
00000001
00000001
0
false (at 001C179A)
704
Terminal address hash table has 15 entries.
Subdevices for entry 0: (none)
Subdevices for entry 1:
structure for terminal address aa (6161x) at 001BF656
Subdevices for entry 2:
structure for terminal address ab (6162x) at 001B7618
Subdevices for entry 3: (none)
8-192
VOS System Analysis Manual (R073)
dump_poll_select
Subdevices for entry 4:
Subdevices for entry 5:
Subdevices for entry 9:
(none)
(none)
(none)
....
as:
The following is sample output of the dump_poll_select request when it is issued
with the -address argument.
as: dump_poll_select sync.7.34 -address aa
Structure for terminal address aa (6161x) at 001BF656
prev_subchp:
00000001
next_subchp:
001B7618
hash_fp:
00000001
dvtx:
28
terminal_address:
aa (6161x)
group_address:
(0404x)
poll_address:
aa (6161x)
select_address:
aa (6161x)
max_input_queue_length: 2
n_input_bufs:
0
event_id:
0207C0CF
first_input_bufp:
00000001
last_input_bufp:
00000001
output_bufp:
00000001
prev_output_subchp:
00000001
next_output_subchp:
00000001
prev_poll_subchp:
00000001
next_poll_subchp:
00000001
flags:
position_undefined
ref_count:
1
ttep:
00000001
message_prefix:
status:
00 00
output_code:
0 ()
primary_process_id:
00000000
terminal_index:
1
as:
The analyze_system Command and Requests
8-193
dump_poll_select
The following table describes the most important fields that appear in the output of the
preceding example.
8-194
Field
Description
last_xmit
Indicates the last transmission on the line. Values include poll.
poll_address
Indicates the address of the terminal which is responding to polls.
input_type
Indicates the response from the terminal receiving polls. Values
include EOT.
flags
Indicates whether a terminal has been responding to polls.
Values include broken.
slow_poll_interval
Indicates the interval in seconds between successive polls of a
broken terminal.
last_poll_try
Indicates when, in seconds, a broken terminal was last polled.
poll_timeouts
Indicates how many times a terminal was polled before it was
marked as broken.
max_poll_timeouts
Indicates the maximum permissible number of poll time-outs.
VOS System Analysis Manual (R073)
dump_porte
dump_porte
8-
Purpose
This request displays information about the port table entry (PORTE) specified on the
analyzed module or process.
Display Form
----------------------------------- dump_porte --------------------------------address:
-name:
-number:
-brief:
no
-format_driver_entries: yes
Command-Line Form
dump_porte address
[-name port_name]
[-number port_number]
[-brief]
[-no_format_driver_entries]
* address
The address of the porte about which to display information. (For information on
address formats, see Chapter 3.) If you select this argument, you cannot specify
-name or -number. You must specify one of these three arguments to identify the
PORTE.
* -name port_name
The name of the port about which to display information. If you specify this
argument, you cannot select address or -number. You must specify one of these
three arguments to identify the PORTE.
The analyze_system Command and Requests
8-195
dump_porte
* -number port_number
The number of the port about which to display information. If you specify this
argument, you cannot specify address or -name. You must specify one of these
three arguments that identify the PORTE.
* -brief
Displays summary information as output.
<CYCLE>
* -no_format_driver_entries
<CYCLE>
Does not display the user and kernel entries for the PORTE. By default, the request
does display the user and kernel entries for the PORTE.
Explanation
The dump_porte request displays information about the PORTE specified on the
analyzed module or process. The request also displays the default character set and
shift mode fields of the PORTE. Ports are process specific, except in the case of global
ports, which are module specific.
Note that the list_port_attachments request displays information about the ports
attached to the current process which can be useful as input to dump_porte.
Also note that if the a port is attached to a streams file, then the dump_porte request
displays streams information as well.
Examples
In the following example, the dump_porte request displays port table entry
information for port 5. The output of the dump_porte request can have three parts.
The first part of the output displays information about the PORTE, such as the port
name and path name.
If the port is attached to a file, the output also describes the type of file, current locking
on the file, a description of the current and primary indexes on the file, and enabled user
and kernel entries.
If the port is attached to a device, the output also contains enabled user entries and
kernel entries.
as: dump_porte -number 5
PORT 5 at C0DA1500
Portname:
terminal
Pathname:
%es#os_telnet_m19.5
Type:
window terminal
Flags:
attached,open,hold_attachment,logging,read_logging
write_logging,hold_opening,port_accounting
system_port,count_down_driver
Access mode:
sequential
I/O type:
output
8-196
VOS System Analysis Manual (R073)
dump_porte
log_port:
process_id:
info_ptr:
dvtep:
port_id:
user_info_ptr:
forms_info_ptr:
tv:
user_tv:
tasking_info_ptr:
accounting_info_ptr:
time_limit:
conflict_count:
character_set:
shift_mode:
pte_ptr:
amte_ptr:
tv_driver_tep:
--- SAFE STORAGE at
window_hdl
screen_hdl
dil_driver_tep
20
0113CFB8
C1B3FDC0
C0B54880
5
C0BCFCC0
00000001
110 (Open Window)
110 (Open Window)
7FFA9FC0
7FFA9FA0
-1
0
latin_1
single
C1ABD980
00000001
C112AD00
C0BCFCC0
7FF2A000
7FF2A054
C1124F00
--- WINDOW at
7FF2A000
sp.next
00000001
sp.prev
00000001
sp.window viewport
ul 0:0, lr 24:79
sp.background_attrs
0000x
sp.Flags:
sp.visible_region_list
00000001
owner
7FF2A054
top_pane
00000001
bottom_pane
00000001
current_pane
00000001
win_flags:
window_no_user_heap
port_id
5
current_io_pane
00000001
displaytype_list
00000001
global_dt_text_heap
00000001
saved_form_list
00000001
global_disptype_alloc_vec C08728C0
free_pane_list
00000001
uid
0
next_pane_uid
16
first_free_displaytype
-32768
lang_info_ptr
00000001
out_notation:
hex_notation_char
ascii/60
undisplayable_notation_mode 0
The analyze_system Command and Requests
8-197
dump_porte
--- SCREEN at
fm_config
dil_ptr
window_alloc_vec
device_dcs
desired_image_ptr
ttp
7FF2A054
&iwm_open_user_window+108 (C083E648)
term_dil_vector (C0864BA0)
FMSwm_alloc_vector (C08728C0)
1
00000000
00000001
--- WCB at
C1B3FDC0
w.sp.next
00000001
w.sp.prev
00000001
w.sp.window viewport
ul 0:0, lr 24:80
w.sp.background_attrs
0000x
w.sp.Flags:
visible
w.sp.visible_region_list C1589F80
...->element[0].view
ul 0:0, lr 24:80
w.owner
C1893680
w.top_pane
C1632C00
w.bottom_pane
C1632C00
w.current_pane
C1632C00
w.win_flags:
window_no_user_heap
window_line_pane_exists
w.port_id
5
w.current_io_pane
C1632C00
w.displaytype_list
00000001
w.global_dt_text_heap
00000001
w.saved_form_list
00000001
w.global_disptype_alloc_vec C1893714
w.free_pane_list
00000001
w.uid
1
w.next_pane_uid
16
w.first_free_displaytype -32768
w.lang_info_ptr
C11E4F40
w.out_notation:
hex_notation_char
ascii/60
undisplayable_notation_mode 0
Flags:
process_is_primary_user
prompt_text_changed
process_key_on_int
interrupt_enable
virtual_status_changed
call_side_notified
process_id
0113CFB8x
event_id
C16FCE40x
event_count
38
echo_table_hdl
00000001
interrupt_table_hdl
00000001
insert_default_hdl
C1544600 (as)
virtual_status_line_hdl
00000001
8-198
VOS System Analysis Manual (R073)
dump_porte
reset_window_params
C1B0D840
flags:
scroll
FIELD_SCROLL
ref_count
2
pause_lines
24
cursor_format
BLINKING_BLOCK
prompt_chars
continue_chars
+
pause_chars
--PAUSE-max_typeahead
10
num_tab_stops
25
tabs
6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86
91 96 101 106 111 116 121 126
window_params
C1B0D840
flags:
scroll
FIELD_SCROLL
ref_count
2
pause_lines
24
cursor_format
BLINKING_BLOCK
prompt_chars
continue_chars
+
pause_chars
--PAUSE-max_typeahead
10
num_tab_stops
25
tabs
6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86
91 96 101 106 111 116 121 126
min_height
0
max_height
24
min_width
0
max_width
80
input_mode
GENERIC_INPUT
Flags2:
window_open
ref_count
1
current_input_section
0
cur_cursor_loc
23:0
cur_cursor_format
BLINKING_BLOCK
break_action
SIGNAL AND DISCARD
keystroke_info:
reqs_disabled
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
input_options
00000000x
ENTER_maskkeys
00000000x
CANCEL_maskkeys
00000000x
keyused
-1
function_key
4
sw_line_state:
top_scroll_field
28
top_scroll_offset
0
scroll_lines
0
start_field
-32768
end_field
-32768
The analyze_system Command and Requests
8-199
dump_porte
8-200
clr_rel_v_offset
clr_lines
end_input_loc
end_prompt_loc
lines_remaining
prev_size
lines_that_fit
cursor_format
Flags:
lm_data_on_pause
lm_might_wrap
attrs
title
read_form_region:
num_panes
max_panes
rfpi_ptr
formid
paneid
last_input_request
compatibility_info:
flags:
read_raw_index
wait_state:
wm_update
wait_state_ids:
sw_write_id
sw_read_id
control_id
cached_message_hdl
-1
0
25
0
23
0
1
STEADY_BLOCK
--- PANE at
sp.next
sp.prev
sp.window viewport
sp.background_attrs
sp.Flags:
visible
sp.visible_region_list
...->element[0].view
owner
parent_pane
object_origin
form
sw_screen_state_hdl
CURSOR_field
CURSOR_offset
Flags:
pane_io
uid
pane_image_hdl
pane_image_ptr
C1632C00
00000001
00000001
ul 0:0, lr 24:80
0000x
00000000x
C199DBC0 (analyze_system)
0
0
00000001
0
-32768
return (4)
0
NO_UPDATE_IN_PROGRESS
-32768
-32768
-32768
C1795B80
C16BD540
ul 0:0, lr 24:80
C1B3FDC0
00000001
0:0
C1232F40
00000001
9
0
0
00000001
00000001
VOS System Analysis Manual (R073)
dump_porte
--- FORM at
next
owner_window
owner_pane
display_list_alloc_vec
field_list
predef_displaytype_list
predef_text_heap
anon_displaytype_list
anon_text_heap
value_heap
field_lines
field_flags
uid
first_field
last_field
State Flags:
background_attribs
required_field_attribs
C1232F40
00000001
C1B3FDC0
C1632C00
C1893714
C1B7C880
00000001
00000001
00000001
00000001
C1748680
C170BF40
C1714600
0
11
9
0000x
0004x
Verified references of fields to string heaps.
--- FORM FIELD LIST
ID
--
NEXT PREV rel
av # or DT
---- ---- --,--- -- - -- ---
11
4
8 05,000 22 1 00
4
10
11 06,000 22 1 00
10
13
4 07,000 22 1 00
....
Verified handles to be between
Verified free handle list
Verified free block list
--- SCB at
s.fm_config
s.dil_ptr
s.window_alloc_vec
s.device_dcs
s.desired_image_ptr
s.ttp
acb_hdl
access_layer_type
first_meta
last_meta
screen viewport
top_window
bottom_window
current_window
0004
0004
0004
len loc datastate/flags
-- ---- --------------0 0012
0 002E
0 0023
fence and end offsets
C1893680
wm_config_ev_in_heap (C0864B40)
term_dil_vector (C0864BA0)
C1893714 (C1893714)
1
00000001
C14DED80
C1116D00
TELNET
80x
85x
ul 0:0, lr 24:80
C1B3FDC0
C1B3FDC0
C1B3FDC0
The analyze_system Command and Requests
8-201
dump_porte
status_messages
C1A2E2C0
terminal_state_hdl
C237CD00
Flags:
dil_attached
terminal_type_valid
break_to_wmgr
image_allocated
login_slave
Output_Flags:
default_window_params
C199D300
flags:
scroll
FIELD_SCROLL
ref_count
1
pause_lines
24
cursor_format
STEADY_BLOCK
prompt_chars
continue_chars
+
pause_chars
--PAUSE-max_typeahead
10
num_tab_stops
25
tabs
6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86
91 96 101 106 111 116 121 126
input_buf
C1AEE200
insert_saved_hdl
C22EE9C0 (dump_porte -number 5)
virtual_status_line_hdl
C237AB00 (Mail: You have mail from Joe Smith)
status_info:
timer_no
0
changed
0
formatted_status
00000001
al_ptr
tel_al_vector (E4B97080)
dil_driver_tep
C1124F00
al_driver_tep
C15BADC0
max_input_len
300
next_window_uid
1
wmgr_state.cursor_loc
0:0
open_action
ALLOW CONNECTION
num_procs_to_start
0
original_user_name
Joe_Smith
allocation_info:
NEW_ptr_ptr
md_wired_utils+170, line 138 (C02244F0)
REUSE_ptr_ptr
md_wired_utils+298, line 214 (C0224618)
FREE_ptr_ptr
md_wired_utils+3E0, line 289 (C0224760)
error_code
3077
max_bytes
131072
num_bytes
15684
til_ptr
wm_til_vector (C08649A0)
wait_state:
wm_update
WAITING_FOR_INPUT
wmgr_wm_update_flags
0000x
update_window_or_pane
C1632C00
update_form
C1232F40
update_first_field
18
8-202
VOS System Analysis Manual (R073)
dump_porte
update_last_field
screen_wait_state_flags
meterp
screen_vm_reg_ptr
screen_vm_reg_size
Flags2:
-32768
0000x
00000001
C23C6300
8460
--- ACB at
C1116D00
scbp
C1893680
access_layer_type
1
acb_lockp
C1580580
serverp
C2379840
(os_telnet)
dvtep
C0B54880
(os_telnet_m19.5)
acb_link.nextp
00000001
acb_link.next_linksp
00000001
acb_link.prevp
00000001
acb_link.prev_linksp
00000001
socketp
C1537900
in_bufsetp
C1AEE200
extra_bufp
C16E5C80
out_bufp_list.nextp
00000001
....
num_out_bufs
0
num_in_bufs
3
num_free_bufs
2
conn_state
CS_CONNECTED
recv_state
RS_NORMAL
xmit_state
XS_NORMAL
acb_flags
22002000x
acb_input_enabled
acb_suppress_goahead
acb_login
socket_id
8
acb_index
4
acb_serv_flags
00000000x
peer_name
134.111.50.14,3225
timers[0]
83
dvtx
21
til_ptr
wm_til_vector (C08649A0)
Enabled kernel entries:
seq_read:
seq_read_windowed)
seq_write:
seq_write_windowed)
control:
control_windowed)
close:
close_windowed)
read_form:
read_form_windowed)
s$yield_processor+10DC2C (line 326 in module
s$yield_processor+10FE14 (line 191 in module
s$yield_processor+1017CC (line 972 in module
s$yield_processor+100204 (line 335 in module
s$yield_processor+110DBC (line 158 in module
The analyze_system Command and Requests
8-203
dump_porte
....
Enabled user entries:
seq_read:
s$k_seq_read (kernel_trap_pa+1AD7C)
seq_write:
s$k_seq_write (kernel_trap_pa+1B490)
control:
s$k_control+184 (kernel_trap_pa+4C48)
close:
s$yield_processor+FFBEC (line 408 in module
client_open_windowed)
read_form:
s$k_read_form (kernel_trap_pa+1710C)
seq_write_partial:
s$k_seq_write_partial (kernel_trap_pa+1BAA8)
read_raw:
s$k_read_raw (kernel_trap_pa+177D0)
write_raw:
s$k_write_raw (kernel_trap_pa+26208)
....
as:
8-204
VOS System Analysis Manual (R073)
dump_protocol_names
dump_protocol_names
8-
Purpose
This request displays the names of the protocols configured for the analyzed module.
Display Form
------------------------------ dump_protocol_names ----------------------------No arguments required. Press ENTER to continue.
Command-Line Form
dump_protocol_names
Explanation
The dump_protocol_names request lists the protocol_name values in the
firmware.table file. It lists each value only once, regardless of how many times it
is repeated in the file. Note that this file is populated with the
configure_firmware_types command, which is described in the manual VOS
System Administration: Configuring a System (R287).
The analyze_system Command and Requests
8-205
dump_protocol_names
Examples
In the following example, the dump_protocol_names request displays the names of
protocols configured for the module. Note that one protocol is sometimes associated
with different firmware. For example, the BSC protocol is associated with the NASDAQ,
DJNR, SWIFT, FAS, CHIPS, and HASP firmware.
as: dump_protocol_names
Max protocol types = 002E
protocol name:
RS_bsc
RS_bsc_nasdaq
RS_bsc_djnr
RS_tse
RS_ose
RS_bsc_swift
RS_bsc_fas
RS_bsc_chips
RS_sdlc
RS_x25_lap
RS_3270_host
RS_3270_remote
RS_3270_remote_os
RS_amex_h3270
RS_hasp
RS_bsc_hasp
RS_poll_ss
as:
8-206
VOS System Analysis Manual (R073)
dump_prt
dump_prt
8-
Purpose
This request displays the StrataLINK or StrataNET pending request table (PRT) for a
module.
Display Line Form
------------------------------------- dump_prt -----------------------------------full:
no
-free:
no
-header: no
Command-Line Form
dump_prt
[-full]
[-free]
[-header]
Arguments
* -free
<CYCLE>
Displays information about all free slots in the PRT except for those free slots that
have not been used. If you also specify the -full argument to display the active
slots, each active entry is marked by an asterisk (*).
* -header
<CYCLE>
Displays the PRT header information. If you specify only this argument, then the
request displays only header information.
* -full
<CYCLE>
Displays detailed information about active PRT slots. If you also specify the -free
argument, each active entry is marked by an asterisk.
The analyze_system Command and Requests
8-207
dump_prt
Explanation
The dump_prt request displays the StrataLINK or StrataNET PRT for a module. If you
do not specify the -full, -free, or -header arguments, then the request displays
only header information.
To obtain the most information about the PRT, specify dump_prt -header -free
-full.
Examples
In the following example, the dump_prt request displays the PRT for a module.
as:
dump_prt
Pending Request Table - PRT at (prtp$) 80C56A80x
prt_max_entry$:
150
nleft:
150
min_left:
113
free list: 118 137 125 129 115 146 141-142 130 128 114 145 131 126 143
117 140 134 116 122 132 120 123 127 150 144 124 139 149 135 147
121 136 119 133 138 1-113
as:
Related Information
For more information about StrataNET-related analyze_system requests, see the
description of the dump_net_info, dump_net_tids, dump_nst,
dump_rsv_socket, dump_socket, and dump_socket_info requests.
8-208
VOS System Analysis Manual (R073)
dump_pte
dump_pte
8-
Purpose
This request displays the process table entry (PTE) for the analyzed process, or any
process for which the address argument is given.
Display Form
----------------------------------- dump_pte ----------------------------------address:
-match:
-current_pte: no
-all:
no
Command-Line Form
dump_pte address
[-match match_string]
[-current_pte]
[-all]
Arguments
* address
The address of a process table entry. You can specify the process table entry
pointer (PTEP), which is displayed by the who request.
You cannot select both this argument and the -current_pte argument.
* -match match_string
Displays only those lines from the specified process table entry that match the
value given for match_string.
* -current_pte
<CYCLE>
Displays information about the process table entry for the current analyzed
process.
The analyze_system Command and Requests
8-209
dump_pte
You cannot specify both this argument and the address argument. If you omit both
arguments, VOS uses -current_pte by default.
* -all
<CYCLE>
Displays all PTEs in the process table. You cannot specify both this argument and
the address or -current_pte argument. The default is to display the PTE for
the current process.
Explanation
The dump_pte request displays all or selected lines from a PTE. A PTE contains
information about a process that the kernel must access whether or not a process is
active or in memory. The Process Data Region (PDR) and Task Data Region (TDR)
also contain process-related information that is only accessed when the process is
active.
8-210
VOS System Analysis Manual (R073)
dump_pte
Examples
In the following example, the dump_pte request displays the PTE for a module.
as:
dump_pte
PTE at 827ADBE0 for Joe_Smith.Eng (login)
process_id:
011148CD
max_priority:
6
max_processes:
0
privs:
privileged
priority:
5
process_number:
2253
process_type:
1 (interactive)
meter_class:
1 (user)
proc_flags1:
accounting_possible,logged_in
proc_flags2:
other_flags:
sched_flags:
pc_flags:
quantum_count:
3
quantum_type:
4
quantum_left:
98569 jiffies (1504.0 ms)
quantum_index:
2
quantum_started:
00000010 238B7EA9
sched_infop:
80C496E8
memory_pool:
0
cpu_no:
29
cpu_no_required:
255
last_cpu_used:
29
state:
1 (ready)
alarm_time:
00000010 267A8EF2
time_last_run:
00000010 266BA235
process_int_bias:
5322
process_q.prevp:
00000001
process_q.nextp:
00000001
alarm_q.prevp:
8151D3E0
alarm_q.nextp:
828168C0
priority_boost_count:
0
last_run_over_time:
00000010 266B8EF5
scheduling flags:
sync_wait_list_ptr:
81C07FC0
kernel_list_ptr:
827ADFA0
notify_lock_infop:
00000001
alarm_clock_time:
00000000 00000000
alarm_clock_q.prevp:
00000001
alarm_clock_q.nextp:
00000001
cpu_alarm_time:
0
task_timer_time:
00000000 00000000
task_timer_q.prevp:
00000001
task_timer_q.nextp:
00000001
stop_timer_time:
00000000 00000000
The analyze_system Command and Requests
8-211
dump_pte
stop_timer_q.prevp:
stop_timer_q.nextp:
user_fence_pgno:
fence_pages:
ustack_top_vpn:
ustack_bottom_vpn:
uheap_top_vpn:
uheap_bottom_vpn:
00000001
00000001
259882 (3F72Ax)
8
261920 (3FF20x)
261929 (3FF29x)
1603 (00643x)
1164 (0048Cx)
total_space:
14925824 (00E3C000x)
maximum_total_limit:
268435456 (10000000x)
maximum_heap_limit:
134217728 (08000000x)
maximum_stack_limit:
134217728 (08000000x)
current_total_limit:
75497472 (04800000x)
current_heap_limit:
67108864 (04000000x)
current_stack_limit:
8388608 (00800000x)
initial_total_limit:
75497472 (04800000x)
initial_heap_limit:
67108864 (04000000x)
initial_stack_limit:
8388608 (00800000x)
first_pmb_ptr:
827B1920
page_fault_error_code: 0 ()
page_trace_ptr:
00000001
vm_procp:
00000001
map_root_tbl_phys_addr: 0B209000
map_root_ptr_phys:
827B2000
map_root_ptr_virt:
00000001
map_pdir_phys_addr:
0
per_process_space_reg: 00000000
page_0_control:
2 (fault all)
ct_page_0_control:
2 (fault)
page_0_ref_count:
0
login_time:
1C70DC99 (95-02-13 11:02:33 EST)
cpu_time_limit:
0 seconds
disk_reads:
1167
disk_writes:
9
page_faults:
1634
cpu_time:
00000000 001EDBFD (30.86 seconds)
page_fault_time:
107713 jiffies (1643.6 ms)
alignment_faults:
2
vcpu_time:
00000000 001D373C (29.22 seconds)
profile_last_data:
00000001
profile_last_cpu_time: 00000000
profile_last_page_faults: 0
kprofile_last_data:
00000001
kprofile_last_cpu_time: 00000000
kprofile_last_page_faults: 0
program_port_id:
7
program_info_ptr:
820E0340
command_status:
0 ()
pi_flags:
pi_mask (off):
pi_welcome_mask (off):
8-212
VOS System Analysis Manual (R073)
dump_pte
processinterrupt_value: 0
kernel_stack_ptr:
3FFEFB70
wired_stack_bottom:
3FFF0000
kernel_stack_bottom:
3FFF9000
kernel_stack_top:
3FFED000
call_side_locks.locks_held_id:
EE66
call_side_locks.write_count:
0
call_side_locks.read_count:
0
call_side_locks.other_count:
1
interrupt_side_locks.locks_held_id:
EE65
interrupt_side_locks.write_count:
0
interrupt_side_locks.read_count:
0
interrupt_side_locks.other_count:
0
wait_lock_infop:
00000001
pdr_ptr:
3FFEA000
first_port_ptr:
820DD540
n_events_attached:
0
net_xmit_event:
00000000
net_recv_socket:
284
zone_delta:
-1 minutes
terminal_event_id:
81B6C5C0
n_orawcle_io:
0
reserved_devices.flags:
reserved_device_list:
00000001
stop_process_infop:
00000001
mp_debug_master_pid:
00000000
net_msg_info_ptr:
821448A0
cache_manager_requestp: 81A53A60
clone_level:
0
invoking_process:
0114D0CC
sub_process_list_ptr:
00000001
max_sub_processes:
0
num_sub_processes:
0
pp_pages:
479
terminal_ptr:
820976A0
lock_queue_time:
00000000 000000A8
fmte_count:
0
fmte_links.prevp:
00000001
fmte_links.nextp:
00000001
cmi_process_cache_hit:
increments:
1691
cmi_process_cache_miss:
increments:
730
cmi_process_cache_soiled:
increments:
9
qmi_process_cpu:
wait_time:
-69360658796
arrivals:
4990
completions:
4989
busy_time:
-69361991674
starts:
4990
qmi_process_diskr:
The analyze_system Command and Requests
8-213
dump_pte
wait_time:
arrivals:
completions:
busy_time:
starts:
smi_process_int:
space_time_product:
pluses:
minuses:
smi_process_unsh_mem:
space_time_product:
pluses:
smi_process_sh_mem:
space_time_product:
pluses:
minuses:
smi_process_pf:
space_time_product:
pluses:
minuses:
as:
1132819
726
726
1132819
726
5322
512
512
-32412021168580
1427
39001401469
148
148
756561
1636
1636
The following table describes some important fields that appear in the output of the
preceding example.
8-214
Field
Description
meter_class
The class VOS has placed this process in for metering purposes.
Values are User process, System process, or Server
process. (See the Examples section of the
display_system_usage request description, where output
was generated with the -long argument.)
state
The state the process is in
process_number
The decimal value of the last three hexadecimal digits of the
process ID
program_port_id
If this process is executing an external command, the number of
the port being used
pi_flags
Program interrupt flags. Indicates which (if any) program
interrupts are pending for this process
alarm_time
If the process is waiting, the time at which the wait will time out
VOS System Analysis Manual (R073)
dump_pte
The following is sample output of the dump_pte request that shows the page-related
lines in the specified process table entry.
as:
dump_pte 04A23918 -match page
PTE at 04A23918 for Smith.SysAdmin (login)
page_fault_error_code: 0 ()
page_trace_ptr:
00000001
page_0_control:
1 (simulate 68010)
ct_page_0_control:
1 (simulate 68010)
page_0_ref_count:
0
page_faults:
634
page_fault_time:
250774 jiffies (3826.5 ms)
profile_last_page_faults: 0
kprofile_last_page_faults: 0
as:
Related Information
See the description of the dump_tdr request for related information.
The analyze_system Command and Requests
8-215
dump_queue_info
dump_queue_info
8-
Purpose
This request displays diagnostic information about message queues and server
queues from the VOS kernel data structures.
Display Form
----------------------------- dump_queue_info -------------------------------filename:
-address:
-entry_detail: no
-sqi_detail:
no
-afte_detail: no
-free:
no
-full:
no
Command-Line Form
dump_queue_info [filename]
[-address address]
[-entry_detail]
[-sqi_detail]
[-afte_detail]
[-free]
[-full]
Arguments
* filename
The object name of the file (not a full path name) or a star name representing a pattern
of file object names. The dump_queue_info request searches the Active Directory
Table (ADT) for the names of one or more entries that match filename. Therefore, this
request displays information about only currently open objects.
8-216
VOS System Analysis Manual (R073)
dump_queue_info
You must specify a value for the filename or -address argument, but you cannot
specify a value for both; the arguments filename and -address are mutually
exclusive.
In a live environment with data constantly changing, the dump_queue_info request
might not find the specified filename because this request searches by examining all
hash-table entries. Sometimes VOS changes the hash-table threads during the search,
and the thread is temporarily disconnected, so the filename may not be available.
Similarly, the dump_queue_info request sometimes displays unusual
invalid-address messages before or after it finds the correct object. Therefore, after you
have identified the address of the Active File Table Entry (AFTE) for the queue you are
interested in, you should specify a value for the -address argument for subsequent
requests. Specifying an AFTE address is more reliable and efficient than specifying a
value for the filename argument.
* -address address
Specifies an AFTE address that uniquely identifies the queue to be displayed.
You must specify a value for the -address or filename argument, but you cannot
specify a value for both; the arguments -address and filename are mutually
exclusive.
* -entry_detail
<CYCLE>
The value yes enables the dump_queue_info request to display additional detail
data when listing Queue Entries (QE) for message queues or Server Queue Entries
(SQE) for server queues. By default, the dump_queue_info request displays the
minimal amount of data required for you to quickly assess what further detail you need.
* -sqi_detail
<CYCLE>
The value yes enables the dump_queue_info request to display additional detail
data when listing Server Queue Info (SQI) entries. By default, the dump_queue_info
request displays the minimal amount of data required for you to quickly assess what
further detail you need.
* -afte_detail
<CYCLE>
The value yes enables the dump_queue_info request to display additional detail
data from the AFTE associated with the queue. The data displayed is similar to that of
the analyze_system request dump_afte -queue_entries except that the
dump_queue_info request displays the queue header and queue entry detail in a
terser format.
* -free
<CYCLE>
The value yes enables the dump_queue_info request to display additional detail
data about free_sqe, free_sqe_space, and free_space_lists. Typically, only
support personnel or file-system developers require this information.
The analyze_system Command and Requests
8-217
dump_queue_info
* -full
<CYCLE>
Specifies that the output includes all of the information that the arguments
-entry_detail, -sqi_detail, and -free provide. (Information provided by the
-afte_detail argument is not included.)
Explanation
Queues are an interprocess communication (IPC) mechanism. VOS has four types of
queues: server queues, message queues, direct queues, and virtual memory queues.
Server queues provide an IPC mechanism between clients and servers. VOS
server queues can be one-way or two-way, and can be transaction-protected.
Server queues are objects in the VOS file system and they can be used in
operations between modules linked together using a local area network (LANfor
example, Open StrataLINK) or wide area network (WAN).
Message queues provide a persistent queuing mechanism between clients and
servers. Like server queues, they are objects in the VOS file system. Unlike server
queues and direct queues, though, VOS retains the queue entries until they are
explicitly deleted by program action.
Message queues are basically files with two indexes (_record_index, which
reclaims unused space, and _priority_index, which implements queuing).
Direct queues provide restricted but faster queue operations, especially between
modules connected by a LAN (for example, Open StrataLINK).
Virtual memory queues are the fastest, but are further restricted to access only on
the same module.
The dump_queue_info request displays information only about server queues and
message queues.
The AFTE contains information about the file system object, including a pointer to
Queue Header (QH) blocks for message queues or to Server Queue Header (SQH)
blocks for server queues. The AFTE (and its extensions tracks information that is global
to all attachments to the queue. There is only one AFTE for each open/active queue,
and it resides in the paged heap of the module on which the file system object resides.
A logical extension of the AFTE, the Common Active Table Entry (CATE) exists in the
wired heap of the same module and contains information that the cache manager and
the file I/O routines need in order to manage the data storage or the queue. A basic
AFTE entry requires approximately 300 bytes of storage in the kernel paged heap; in
addition, the CATE requires approximately 280 bytes in the kernel wired heap.
A message queue entry is a paged-heap structure that exists for each active entry in a
message queue. Each entry requires approximately160 bytes. Unlike server queues,
the order of the queue of messages in a message queue is determined by priority keys
8-218
VOS System Analysis Manual (R073)
dump_queue_info
in an index on the file. The message queue entries in memory are used only to maintain
context while a user accesses the messages.
A Server Queue Entry (SQE) is a paged-heap structure that exists for each entry
(request and/or reply) in a server queue, whether or not the entry is actively being
accessed. The SQE is always threaded on the local_sqe_list of the SQI of the
requester that entered the message. While it is queued for service, and while it is being
serviced, it is also threaded (in priority and chronological order) on the
main_sqe_list whose head/tail controls are in the SQH. Each entry requires
approximately 128 bytes of memory in the kernel paged heap. The threaded list of
SQEs forms the actual queue and determines the ordering of the messages.
The SQE space structure tracks chunks of storage in the file system. It records the
offset and the number of bytes in each chunk. Each such structure requires
approximately 60 bytes in the kernel paged heap. A small number (currently, 8) of free
SQE space structures are retained on the free_sqe_space list in the SQH structure
for rapid access instead of being returned to the paged heap when not needed.
A Server Queue Information (SQI) structure is a subordinate type of File Information
(FI) structure that contains information about one attachment to a server queue. A
one-to-one relationship always exists between an attached port table entry (PORTE)
in each requester or server process and an SQI. Together, they track data unique to
that attachment.
All SQIs for a server queue are threaded together, and the SQH maintains the head/tail
controls of the list.
Each SQI contains the head/tail controls for a local_sqe_list that maintains a
threaded list of every SQE associated with the SQI/PORTE. Every SQI requires
approximately 100 bytes of storage in the kernel paged heap.
Examples
This section presents five examples. Examples 1, 2, and 3 display information about
server queues. Examples 4 and 5 display information about message queues.
The analyze_system Command and Requests
8-219
dump_queue_info
Example 1
Example 1 presents the output of the dump_queue_info request when only the
filename argument is specified. Specifying only the filename (or -address)
argument enables the dump_queue_info request to display the least amount of
information. From this minimal output, however, you can determine the state of
messages on the queue.
as: dump_queue_info tsq
AFTE at 054D3160 for: %sys#dev>SysAdmin>John_Doe>test>tsq
file type:
server queue file
ref count:
3
max_queue_depth:
256
Queue Header @ 04D828F0x
requestors:
2
servers:
1
total messages: 13
refused: 0
current: 13
non_busy: 9
max per priority: 4
highest: 13
max: 256
time_stamp: 13
main_sqe_list:
04D82904: 054DF4E0 054DF4E0 04FCDE80 04FCDE80
SQEp
Pr Message ID Msg Length Info
--------- -- ----------- -------------------------------------------054DF4E0x 0
4
7 busy
054CDC70x 0
5
7
04AD1B30x 0
6
7
04AC2440x 0
7
7
05557EB0x 0
8
7
04D94C80x 0
9
7
054EDDE0x 0
10
7
04AAE4B0x 0
11
7
0553D810x 0
12
7
04FCDE80x 0
13
0
space_list:
04ACD578: 04ACE2C0 04ACE2C0 054AF170 054AF170
sqi_list:
04D828F4: 04FCAF40 04FCAF60 048CFC20 048CFC40
S
R
R
8-220
========
04FCAF40
04FB1B30
048CFC20
========
4301F0A6
4301D0A5
060763B1
======== ----- ----- ----- -------- ======== ========
00000000
0
0
0
4 04FCAF70 054DF4E0
04B4A530
12
3
12
12 04FB1B60 00000001
05C1A480
1
0
1
1 048CFC50 00000001
VOS System Analysis Manual (R073)
dump_queue_info
Example1 indicates that the queue has the following:
one server (process A6x on system 67, module 1)
two requesters:
process A5x on system 67, module 1
process 381x on system 6, module 7
13 messages that are in the following states on the queue (not one message has
been through the entire cycle of send, receive, send_reply, and
receive_reply).
9 messages awaiting service
1 message currently being serviced
3 messages whose replies have not yet been received by one of the
requesters
The analyze_system Command and Requests
8-221
dump_queue_info
Example 2
Example 2 illustrates the -sqi_detail argument. In the output, server_done in the
Info column indicates that the server has finished processing the message and, since
the entry is still in the queue, it implies that what remains is the reply from the server
that has not yet been received by the requester.
as:
dump_queue_info tsq -sqi_detail
AFTE at 054D3160 for: %sys#dev>SysAdmin>John_Doe>test>tsq
file type:
server queue file
ref count:
2
max_queue_depth:
256
Queue Header @ 04D828F0x
requestors:
1
servers:
1
total messages: 13
refused: 0
current: 12
non_busy: 8
max per priority: 4
highest: 13
max: 256
time_stamp: 13
main_sqe_list:
04D82904: 054DF4E0 054DF4E0 0553D810 0553D810
SQEp
Pr Message ID Msg Length Info
--------- -- ----------- ------------------------------------------054DF4E0x 0
4
7 busy
054CDC70x 0
5
7
054EDDE0x 0
10
7
04AAE4B0x 0
11
7
0553D810x 0
12
7
04AD1B30x 0
6
7
04AC2440x 0
7
7
05557EB0x 0
8
7
04D94C80x 0
9
7
054EDDE0x 0
10
7
04AAE4B0x 0
11
7
0553D810x 0
12
7
space_list:
04ACD578: 04ACE2C0 04ACE2C0 054AF170 054AF170
sqi_list:
04D828F4: 04FCAF40 04FCAF60 04FB1B30 04FB1B50
last_sqi_notifiedp:
00000001x
Tp
SQIp
Crnt SQEp Event ID ProcessID Person
- --------- --------- --------- ----------------------------------------S 04FCAF40x 054DF4E0x 00000000x 4301F0A6x John_Doe
messages: 0
replies: 0
flags: is_server
highest: 0
total: 4
Tp
SQIp
Crnt SQEp Event ID ProcessID Person
- --------- --------- --------- ----------------------------------------R 04FB1B30x 00000001x 04B4A530x 4301D0A5x John_Doe
messages: 12
replies: 3
flags:
highest: 12
total: 12
servers w/ access: 1
8-222
VOS System Analysis Manual (R073)
dump_queue_info
local_sqe_list:
04FB1B60: 04AA8410 04AA8420 0553D810 0553D820
SQEp
Pr Message ID Msg Length Info
--------- -- ----------- ---------------------------------------------04AA8410x 0
1
7 server_done
05524FF0x 0
2
7 server_done
05505C00x 0
3
7 server_done
054DF4E0x 0
4
7 busy
054CDC70x 0
5
7
04AD1B30x 0
6
7
04AC2440x 0
7
7
05557EB0x 0
8
7
04D94C80x 0
9
7
054EDDE0x 0
10
7
04AAE4B0x 0
11
7
0553D810x 0
12
7
In Example 2, the output contains 12 messages, not 13. Message 13 (SQE
04FCDE80x, Message ID 13 in Example 1) is omitted, probably because the requester
closed the queue without the server seeing the request (since the server is still working
on the same request), and the SQE was removed entirely.
If the one existing requester were to close the queue now, all messages except
Message ID 4 would be removed. That message, though, would be marked
requester_aborted, and the error_code e$requester_aborted would be
set. If the server were to reply (and receive the error code), the message would be
removed from the queue.
Example 3
Example 3 illustrates the -full argument, which specifies that the output include the
information that the -entry_detail and -sqi_detail arguments provide. In the
output, three vertical dots indicate that entries have been omitted from the example
output for brevity.
as:
dump_queue_info -address 054D3160 -full
AFTE at 054D3160 for: %sys#dev>SysAdmin>John_Doe>test>tsq
file type:
server queue file
ref count:
2
max_queue_depth:
256
Queue Header @ 04D828F0x
requestors:
1
servers:
1
total messages: 13
refused: 0
current: 12
non_busy: 8
max per priority: 4
highest: 13
max: 256
time_stamp: 13
main_sqe_list:
04D82904: 054DF4E0 054DF4E0 0553D810 0553D810
Pri Number Last at
Pri Number Last at
first_non_busyp: 054CDC70x
The analyze_system Command and Requests
8-223
dump_queue_info
--- ------ ----------- ------ --------10
0 00000001x
0
9 0553D810x
SQEp
Pr Message ID Msg Length Flags
--------- -- ----------- ---------------------------------------------054DF4E0x 0
4
7 busy
Server done: false
Srv SQIp: 04FCAF40x
SQE Space: 049397B0x Req SQIp: 04FB1B30x John_Doe
offset: 768 (00000300x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 1
time_stamp: 3
error_code: 0
054CDC70x 0
5
7
Server done: false
Srv SQIp: 00000001x
SQE Space: 048C00F0x Req SQIp: 04FB1B30x John_Doe
offset: 1024 (00000400x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 0
time_stamp: 4
error_code: 0
04AD1B30x 0
6
7
Server done: false
Srv SQIp: 00000001x
SQE Space: 054E05C0x Req SQIp: 04FB1B30x John_Doe
offset: 1280 (00000500x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 0
time_stamp: 5
error_code: 0
.
.
.
0553D810x 0
12
7
Server done: false
Srv SQIp: 00000001x
SQE Space: 04ACDA00x Req SQIp: 04FB1B30x John_Doe
offset: 2816 (00000B00x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 0
time_stamp: 11
error_code: 0
num_free_sqe:
free_sqe_list:
free_sqe_space_list:
free_space_list:
space_list:
sqi_list:
last_sqi_notifiedp:
num_free_sqe_space:
2
high_offset: 3328
04D82918: 04FCDE80 04FCDE80 04FCDE80 04FCDE80
04D82928:
04D82948:
04D82938:
04D828F4:
00000001x
04D82080
04D80B60
04AD7190
04FCAF40
04D82080
04D80B70
04AD7190
04FCAF60
054D05F0
04D80B60
04D7DAE0
04FB1B30
054D05F0
04D80B70
04D7DAE0
04FB1B50
Tp
SQIp
Crnt SQEp Event ID ProcessID Person
- --------- --------- --------- --------------------------------------S 04FCAF40x 054DF4E0x 00000000x 4301F0A6x John_Doe
messages: 0
replies: 0
flags: is_server
highest: 0
total: 4
8-224
VOS System Analysis Manual (R073)
dump_queue_info
Tp
SQIp
Crnt SQEp Event ID ProcessID Person
- --------- --------- --------- ------------------------------------R 04FB1B30x 00000001x 04B4A530x 4301D0A5x John_Doe
messages: 12
replies: 3
flags:
highest: 12
total: 12
servers w/ access: 1
local_sqe_list:
04FB1B60: 04AA8410 04AA8420 0553D810 0553D820
SQEp
Pr Message ID Msg Length Flags
04AA8410x 0
1
7
Server done: true
Srv SQIp: 04FCAF40x
SQE Space: 04D7DAE0x Req SQIp: 04FB1B30x John_Doe
offset: 3072 (00000C00x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 0
time_stamp: 0
error_code: 0
05524FF0x 0
2
7
Server done: true
Srv SQIp: 04FCAF40x
SQE Space: 04AD7190x Req SQIp: 04FB1B30x John_Doe
offset: 0 (00000000x) size: 256
ref cnt: 1
offset: 0 (00000000x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 0
time_stamp: 1
error_code: 0
05505C00x 0
3
7
Server done: true
Srv SQIp: 04FCAF40x
SQE Space: 05510030x Req SQIp: 04FB1B30x John_Doe
offset: 256 (00000100x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 0
time_stamp: 2
error_code: 0
054DF4E0x 0
4
7 busy
Server done: false
Srv SQIp: 04FCAF40x
SQE Space: 049397B0x Req SQIp: 04FB1B30x John_Doe
offset: 768 (00000300x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 1
time_stamp: 3
error_code: 0
054CDC70x 0
5
7
Server done: false
Srv SQIp: 00000001x
SQE Space: 048C00F0x Req SQIp: 04FB1B30x John_Doe
offset: 1024 (00000400x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 0
time_stamp: 4
error_code: 0
04AD1B30x 0
6
7
Server done: false
Srv SQIp: 00000001x
SQE Space: 054E05C0x Req SQIp: 04FB1B30x John_Doe
offset: 1280 (00000500x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 0
time_stamp: 5
error_code: 0
.
.
.
.
The analyze_system Command and Requests
8-225
dump_queue_info
0553D810x 0
12
7
Server done: false
Srv SQIp: 00000001x
SQE Space: 04ACDA00x Req SQIp: 04FB1B30x John_Doe
offset: 2816 (00000B00x) size: 256
ref cnt: 1
jiffy_time_queued: 0
pos_count: 0
time_stamp: 11
error_code: 0
Example 4
Example 4 presents information about a message queue file.
as: dump_queue_info tmq
AFTE at 0550C1A0 for: %sys#dev>SysAdmin>John_Doe>test>tmq
file type:
message queue file
ref count:
2
Queue Header @ 04D8D250x
requestors:
1
servers:
1
-qe_list:
04D8D254: 05505F70 05505F70 054D6150 054D6150
Example 5
Example 5 presents additional information about a message queue file by using the
-full argument.
as: dump_queue_info -address 550c1a0x -full
AFTE at 0550C1A0 for: %sys#dev>SysAdmin>John_Doe>test>tmq
file type:
message queue file
ref count:
2
Queue Header @ 04D8D250x
requestors:
1
servers:
1
-qe_list:
04D8D254: 05505F70 05505F70 054D6150 054D6150
Active queue entries
queue_entry
05505F70x
-links:
04D8D254: 054D6150 054D6150 00000001 04D8D254
-priority:
3
-priority_key:
FC00202B7DAECB0Fx
-saved_priority:
3
-saved_priority_key:
FC00202B7DAECB0Fx
-message_no:
1
-message_offset:
0
-message_length:
10
-message_size:
-11
-flags:
been_busy,busy,requestor_privileged
-saved_flags:
been_busy,requestor_privileged
-requestor-fip:
00000001
-requestor-person:
John_Doe
-server-fip:
05530390
-server-process_id:
43011171
8-226
VOS System Analysis Manual (R073)
dump_queue_info
-saved_server-fip:
-saved_server-process_id:
-tsip:
queue_entry
-links:
-priority:
-priority_key:
-saved_priority:
-saved_priority_key:
-message_no:
-message_offset:
-message_length:
-message_size:
-flags:
-saved_flags:
-requestor-fip:
-requestor-person:
-server-fip:
-server-process_id:
-saved_server-fip:
-saved_server-process_id:
-tsip:
00000001
00000000
00000001
054D6150x
04D8D254: 00000001 04D8D254 05505F70 05505F70
8
F700202B7DC8F1F3x
8
F700202B7DC8F1F3x
2
256
10
-11
been_busy,busy,requestor_privileged
been_busy,requestor_privileged
00000001
John_Doe
05530390
43011171
00000001
00000000
00000001
The analyze_system Command and Requests
8-227
dump_r3270
dump_r3270
8-
Purpose
This request displays information about the specified 3270_remote channel.
Display Form
---------------------------------- dump_r3270 -------------------------------channel_name:
-subch:
-interval:
Command-Line Form
dump_r3270 channel_name
[-subch subchannel_address]
[-interval time]
Arguments
* channel_name
Required
The name of a primary channel that you want information about; do not specify a
subchannel. Do not include the pound sign (#) character in the channel name. Use
the list_devices command to list the active 3270_remote channels on a
module.
* -subch subchannel_address
Specifies the address of a subchannel for which you want to display information.
Use the format control_unit_number-subdevice_number, as shown in the
Hash code fields in the Example 1 section. An example of a valid value is 10.
* -interval seconds
Specifies the time interval in which the request will display information about the
state of the channel, the number of control messages sent, and the number of
messages written.
8-228
VOS System Analysis Manual (R073)
dump_r3270
Example 1
In the first example, the dump_r3270 request displays information about the specified
3270_remote channel.
The table that follows Example 2 describes many of the output fields.
as: dump_r3270 32r1.9.0
CD for channel 32r1.9.0 found at 81644260
comm_controller_no:
3
slot_no:
6
channel_no:
144
com_mbxp:
80062000
control_bufp:
800A0604
sim_interrupt_index:
71
poll_interrupt_index: 72
dsr_index:
73
watchdog_index:
74
fw_response_index:
75
baud:
9600 (14)
flags:
ebcdic general_poll dsr
n_controllers:
1
controller address 0:
poll_address:
40 40 7F 7F
n_channels:
1
flags:
responding_to_poll
single_subchp:
00000001
first_subchp:
812F32A0
last_subchp:
812F32A0
uart_status:
07
state:
21 (wait_line_adapt_resp)
last_xmit:
1 (eot_msg
)
naxt_ack:
1
poll timeout:
196608 jiffies (3 seconds)
select timeout:
196608 jiffies (3 seconds)
device busy delay:
15 seconds
write_retry_count:
0
nak_count:
0
timeout_count:
0
flags:
first_block_expected
other_flags:
polling_smart_sync2
input_subchp:
00000001
input_bufp:
800A0704
input_type:
15 (ss2_status_msg)
input_expected_for:
00000001
next_controller:
1
n_broken_controllers: 0
conflict_count:
0
next_poll_subchp:
00000001
first_poll_subchp:
00000001
last_poll_subchp:
00000001
poll_subchp:
00000001
The analyze_system Command and Requests
8-229
dump_r3270
output_subchp:
00000001
output_bufp:
00000001
select_address:
00 00
first_output_subchp:
00000001
last_output_subchp:
00000001
poll_interval:
33536 jiffies (511 msec)
msgs_written:
0
selects_since_poll:
0
trace_datap:
00000001
trace_data_n_entries: 0
trace_enabled:
0 (at 81644DB8)
interrupt_count:
18
max_poll_timeouts:
3
max_select_timeouts:
3
device_subchp:
00000001
poll_interval_brkn_ctlr: 120 seconds
cycles_rmvd_from_pl_lst: 3
n_sync_chars:
2
max_input_buffs:
16
max_naks:
10
output int timeout:
13312
Hash code 8
subch at 812F32A0 for device 0-0
watchdog_flags:
timer_enabled init
Poll_hang_count:
0
firmware_data:
number_of_polls:
117
state_flags:
07 hex
control_flags:
40 hex
poll_flags:
44 hex
n_controllers:
1
n_broken_controllers: 0
poll_address:
40 7F
status:
responding_to_poll
n_cu_polls:
117
8-230
VOS System Analysis Manual (R073)
dump_r3270
Example 2
In the second example, the dump_r3270 request displays information about channel
32r1.9.0, subchannel 0-0. The table that follows this example describes many of the
output fields.
as: dump_r3270 32r1.9.0 -subch 0-0
Subch for 0-0 at 812F32A0
prev_subchp:
00000001
next_subchp:
00000001
hash_fp:
00000001
dvtx:
177
poll_addrress:
40 40
select_addrress:
60 40
event_id:
81358200
first_input_bufp:
00000001
last_input_bufp:
00000001
output_bufp(1):
00000001
output_bufp(2):
00000001
output_queue_requests: 0
prev_output_subchp:
00000001
next_output_subchp:
00000001
prev_poll_subchp:
00000001
next_poll_subchp:
00000001
flags:
position_undefined
ref_count:
1
ttep:
812E5640
current_input_section: 0
current_setup:
0
last_line:
23
last_column:
79
message_prefix:
27
status:
00 00
n_input_bufs:
0
output_code:
0 ()
cur_line:
0
cur_col:
0
prompt_chars:
continue_chars:
+
pause_chars:
---PAUSE---
escape_char:
`
primary_process_id:
00000000
break_aid:
6C
cancel_aid:
6E
controller_index:
1
national_language:
0 (ascii)
new_resp_time:
0 jiffies (0.00 milliseconds)
avg_resp_time:
0 jiffies (0.00 milliseconds)
high_resp_time:
0 jiffies (0.00 milliseconds)
The analyze_system Command and Requests
8-231
dump_r3270
(Page 1 of 2)
8-232
Field
Description
slot_no
IOP slot number
channel_no
Logical channel number assigned by the
system
baud
Value determined by channel configuration
flags
Information from port setup
n_controllers
Number of controllers open
n_broken_controllers
Number of controllers not responding
controller address
First controller address
poll_address
First controller poll
n_channels
Number of open devices on controller
flags
Controller response
state
Code state
last_xmit
Last protocol message
poll timeout
-pt parameter value
select timeout
-st parameter value
write_retry_count
nak_count
timeout_count
Protocol error count
next_controller
Next controller to be polled
select_address
Address of last selected controller
poll_interval
-pi parameter value
msgs_written
Number of messages written
selects_since_poll
Number of selects since last poll
trace_data_n_entries
Value of -trace parameter
trace_enabled
The value 1, if -trace is used
max_poll_timeouts
-mpto parameter value
VOS System Analysis Manual (R073)
dump_r3270
(Page 2 of 2)
Field
Description
max_select_timeouts
-msto parameter value
poll_interval_brkn_ctrl
-pibc parameter value
cycles_rmvd_from_pl_lst
-crfpl parameter value
n_sync_chars
-nsc parameter value
max_input_buffs
-mib value
max_naks
System value
output int timeout
Derived from baud_rate setting
Poll hang count
Total number of messages in log
status
Status of controller 1
n_cu_polls
Number of polls to controller 1
poll_address
Poll address of controller 1
select_address
Select address of controller 1
n_input_buffs
Number of unread messages from controller 1
Related Information
For more information about 3270_remote support and emulation parameter values,
see the manual VOS Communications Software: 3270 Support and 3270
Emulation (R026).
The analyze_system Command and Requests
8-233
dump_r3270_trace
dump_r3270_trace
8-
Purpose
This request performs a link-level trace in addition to tracing information on the state of
the line. This request displays information only if the channels device table entry
contains the value -trace N in the parameters field. N specifies the maximum
number of entries to include in the trace.
Display Form
-------------------------------- dump_r3270_trace ------------------------------channel_name:
-interactive: yes
Command-Line Form
dump_r3270_trace channel_name
[-no_interactive]
Arguments
* channel_name
Required
The name of a primary channel that you want information about; do not specify a
subchannel. Do not include the pound sign (#) character in the channel name. Use
the list_devices command to list the active 3270_remote channels on a
module.
* -no_interactive
Specifies that the tracing session is not interactive. The default is to enable an
interactive tracing session.
Explanation
The trace performed by this request includes everything that occurs on the
specified line and cannot be broken down by device.
8-234
VOS System Analysis Manual (R073)
dump_r3270_trace
Examples
The following is sample output from a trace of channel s8.80. The text following the
example explains the output.
as: dump_r3270_trace s8.80
(1)
(2)
0.000
0.004
0.008
0.100
0.102
0.146
0.150
0.153
0.272
0.275
0.279
0.0000
0.0043
0.0202
0.0921
0.0018
0.0443
0.0031
0.0036
0.1189
0.0027
0.0043
(3)
239
239
240
241
241
242
242
243
244
244
245
(4)
(5)
r-done
start-w
w-done
timer_sim
out_pend
r-done
start-w
w-done
r-done
start-w
w-done
(6)
tally=1
tally=1
tally=1
(trans) 61
() 37
() 37
tally=1
tally=9
tally=9
tally=1
tally=249
tally=249
() 37
() 37 FF 32 32 60 60 C1 C1 2D
() 37 FF 32 32 60 60 C1 C1 2D
(trans) 70
(trans,stx,etx) 27 F5 C3 32 24 EF
(trans,stx,etx) 27 F5 C3 32 24 EF
The data in columns 1 through 6 have the following meaning.
Column (1) is the time stamp, starting from 0.000 of when this entry was logged in
reference to the beginning of the trace.
Column (2) is the delta time difference since the last entry:
previous_entry - current_entry = delta_time_difference
Column (3) is the buffer entry number and helps indicate the order in which events
occurred. Identical numbers on sequential entries indicate that the events happened in
the same cycle.
Column (4) is the action of the line. It indicates the type of interrupt that was generated.
Input/output interrupts indicate if the I/O command was issued or actually completed
(i.e., start-w versus w-done).
The following table describes the possible states.
(Page 1 of 2)
Action
Description
start-w
Start write
stop-w
Stop write
stop-r
Stop read
The analyze_system Command and Requests
8-235
dump_r3270_trace
(Page 2 of 2)
8-236
Action
Description
data_set
A data set lead changed. Currently only dsr is required to
be present and is debounced by timer_dsr.
w-done
Write done
r-done
Read done
timer_wdt
watch_dog timer. The r3270 watch_dog timer is used to
gather information from the firmware to determine the state
of the line, and whether polling is occurring normally.
timer_sim
simulate_timer. A simulated timer used to check when
something happened.
timer_pi
poll_interval timer. This timer is recorded when using
os_polling and records the time between the response to
a poll and the next poll being sent. This time is controlled by
the -pi N parameter.
timer_dsr
dsr_timer. This is a 1-second timer that is used to check
for changes in the state of dsr.
wdt_pend
The watch_dog timer is pending.
fw_meters
Indicates that information from the firmware has been
returned as a result of the watch_dog timer. (The r-done
following fw_meters is the actual firmware meter
information.)
dir_ch_cm
direct_channel_commands. These are issued to have
the adapter execute certain functions.
start_polling
Tells the adapter to begin polling the line. It is followed in the
trace by strt_poll.
get_meters
Requests information from the adapter about the physical
link. It is followed in the trace by fw_meters.
output_pending
Indicates either data to be sent or a channel command to be
executed.
VOS System Analysis Manual (R073)
dump_r3270_trace
Column (5) shows the tally count, which indicates the number of characters in this
interrupt.
Column (6) displays nine characters of the data, including framing characters (if
present).
Related Information
For more information about 3270_remote support and emulation, see the manual
VOS Communications Software: 3270 Support and 3270 Emulation (R026).
The analyze_system Command and Requests
8-237
dump_rst
dump_rst
8-
Purpose
This request displays the StrataLINK and StrataNET reserved socket table (RST) on a
module.
Display Form
----------------------------------- dump_rst ----------------------------------rsv_socket_numbers:
-all:
no
-full:
no
-long:
no
-header:
no
Command-Line Form
dump_rst
[rsv_socket_numbers...]
[-all]
[-full]
[-long]
[-header]
Arguments
* rsv_sockets_numbers...
The numbers of 0 or more reserved sockets to be displayed. You cannot specify a
value for this argument if you specified the -all argument.
* -all
<CYCLE>
Displays information about all reserved sockets except for those that have not been
used. You cannot specify this argument if you specified a value for the
rsv_socket_numbers argument.
8-238
VOS System Analysis Manual (R073)
dump_rst
* -header
<CYCLE>
Displays RST header information. If you give this argument by itself, then only
header information is displayed.
* -full
<CYCLE>
Displays detailed information about each reserved socket; in particular, if the
rsv_socket owns a group of regular sockets, then each of those sockets is also
displayed (indented), along with any pending requests queued.
* -long
<CYCLE>
Displays the data in long form; in some cases, the request displays more than one
table. For example, when reserved sockets are listed, any subordinate regular
sockets are listed adjacent to the reserved sockets.
Explanation
Sockets are used by StrataLINK and StrataNET to route messages between Stratus
modules. StrataLINK and StrataNET sockets are completely distinct from the sockets
used by TCP/IP for addressing.
This request dumps the StrataLINK or StrataNET RST on a module. If you do not
specify the rsv_socket_numbers, -all, or -header arguments, then the request
displays all reserved sockets, plus header information.
To obtain the most information about reserved sockets, specify dump_rst -full
-long.
Examples
In the following example, the dump_rst request displays information about sockets
used by StrataLINK and StrataNET.
as:
dump_rst -full
Reserved Socket Table - RST at (rstp$) 80C56740x
rst_max_socket$:
100
rst_max_queue_len$:
100
rsv sockets attached: 1 13
RSV
SKT
--1
Last Pendg Req Queue ----------- New Requests ----------Busy
S-TID Len Max 1st Lst
Received Rpts Queued %Qd Ignrd
Sent
----- --- --- --- --- ----------- ----- -------- ---- ----- ------A62D
0 28
0
0
87205753 ***** 3927235
4%
0
61
Skt
Last
Event
TID
Other
CTID
ID
Clnt-Srvr
Stn Skt
---- ---- -------- --------- ----- ---5 FFFF 81470260 0000-0000
0
0
input_wait
Response
Type Seq
---- ---0
Group
Rsv Nxt
Flags
--- ---- ----1
4 server(M2),
The analyze_system Command and Requests
8-239
dump_rst
pid: 01118043x, process
4 FFFF 81476CA0 0000-0000
input_wait
pid: 01118042x, process
3 FFFF 81476BE0 0000-0000
input_wait
pid: 01118041x, process
2 FFFF 814768E0 0000-0000
input_wait
pid: 01118040x, process
1 FFFF 81470F80 0000-0000
input_wait
pid: 0111803Fx, process
RSV
SKT
--13
67: Overseer.System (LinkServer5)
0
0 -0
1
3 server(M2),
66: Overseer.System (LinkServer4)
0
0 -0
1
2 server(M2),
65: Overseer.System (LinkServer3)
0
0 -0
1
1 server(M2),
64: Overseer.System (LinkServer2)
0
0 -0
1
0 server(M2),
63: Overseer.System (LinkServer1)
Last Pendg Req Queue ----------- New Requests ----------Busy
S-TID Len Max 1st Lst
Received Rpts Queued %Qd Ignrd
Sent
----- --- --- --- --- ----------- ----- -------- ---- ----- ------1C5B
0
1
0
0
72794
0
40
0%
0
0
Skt
Last
Event
TID
Other
Response Group
CTID
ID
Clnt-Srvr
Stn Skt
Type Seq Rsv Nxt
Flags
---- ---- -------- --------- ----- ---- ---- --- --- ---- ----6 FFFF 81A4B980 0000-0000
0
0 -0
13
0 server(M2),
input_wait
pid: 0111CF85x, process 3973: JoeSmith.SysAdmin (OpenLinkClient)
Socket Transaction List at 81741AC0
stl.max:
20
stl.cur_used:
0
stl.max_used:
4
as:
Related Information
For more information about StrataLINK or StrataNET-related analyze_system
requests, see the descriptions of the dump_nst, dump_prt, dump_rsv_socket, and
dump_socket_info requests.
8-240
VOS System Analysis Manual (R073)
dump_rsv_socket
dump_rsv_socket
8-
Purpose
This request displays information about the traffic on each StrataLINK and StrataNET
socket in the analyzed module or dump.
Display Form
--------------------------------- dump_rsv_socket -----------------------------rsv_socket_numbers:
-all:
no
-full:
no
-long:
no
-reset:
no
Command-Line Form
dump_rsv_socket [rsv_socket_numbers...]
[-all]
[-full]
[-long]
[-reset]
Arguments
* rsv_socket_numbers...
Specifies the numbers of zero or more reserved sockets to be displayed. You
cannot specify this argument and the -all argument.
* -all
<CYCLE>
Displays all active reserved sockets. You cannot specify this argument and the
rsv_socket_numbers argument.
* -full
<CYCLE>
Displays detailed information about each reserved socket; in particular, if the
reserved socket owns a group of regular sockets, then each of those sockets is also
displayed (indented), along with any pending requests queued.
The analyze_system Command and Requests
8-241
dump_rsv_socket
* -long
<CYCLE>
Displays a long form of the data, which in general uses one display line per table
item. You must specify at least one socket number or the -all argument.
* -reset
Temporarily resets the meters. The meters are reset only for this execution of
analyze_system. The request resets the meters after it reports the current
values.
Explanation
Sockets are used by StrataLINK and StrataNET to route messages between Stratus
modules. StrataLINK and StrataNET sockets are completely distinct from the sockets
used by TCP/IP for addressing.
The dump_rsv_socket request displays information about the traffic on each
StrataLINK and StrataNET socket in the analyzed module or dump. In particular, it can
tell you how many transactions were queued on the socket waiting to be acted upon.
This information is contained in the %Qd (percent queued) field, which is displayed
when you specify rsv_socket_numbers or -all. This field indicates the highest
percentage of queued transactions since module reboot. A value greater than 10
percent indicates that there have been significant delays in sending packets.
Note that the current value might be lower than 10 percent. To determine the current
percent queued value, record the values in the New Requests Received and New
Requests Queued fields. Record these values during a peak usage period. This is
referred to as Time 1. Wait about five minutes and record these values again. This is
referred to as Time 2. Use the following formula to calculate the percentage used.
((Queued2 - Queued1) / (Received2 - Received1)) * 100
For example:
(3927304 - 3927235) / (87442773 - 87215645) * 100 = .0003
Examples
In the following example, the dump_rsv_socket request displays information about
the traffic on each StrataLINK and StrataNET socket.
as:
dump_rsv_socket 1
RSV Last Pendg Req Queue ----------- New Requests ----------Busy
SKT S-TID Len Max 1st Lst
Received Rpts Queued %Qd Ignrd
Sent
--- ----- --- --- --- --- ----------- ----- -------- ---- ----- ------1 CCCC
0 28
0
0
87215645 ***** 3927235
4%
0
61
group: 1-5
as:
8-242
VOS System Analysis Manual (R073)
dump_rsv_socket
In the following example, the dump_rsv_socket request displays detailed
information about the traffic on each StrataLINK and StrataNET socket..
as: dump_rsv_socket 1 -full -long
RSV Socket 1 at 81476860x
last_server_tid:
D844
newreq_rcvd:
87218584
newreq_rpts:
1602808
busy_sent:
61
n_queued:
3927235 (4%)
n_ignored:
0
prq_len:
0
prq_max_len:
28
Skt
---5
Last
Event
TID
CTID
ID
Clnt-Srvr
---- -------- --------FFFF 81470260 AF4C-D857
unclean, data_accepted
pid: 01118043x, process
FFFF 81476CA0 0000-0000
input_wait
pid: 01118042x, process
FFFF 81476BE0 0000-0000
input_wait
pid: 01118041x, process
FFFF 814768E0 0000-0000
input_wait
pid: 01118040x, process
FFFF 81470F80 0000-0000
input_wait
pid: 0111803Fx, process
Other
Stn Skt
----- ---113 308
Response
Type Seq
---- ---0
Group
Rsv Nxt
Flags
--- ---- ----1
4 server(M2),
67: Overseer.System (LinkServer5)
0
0 -0
1
3 server(M2),
66: Overseer.System (LinkServer4)
0
0 -0
1
2 server(M2),
65: Overseer.System (LinkServer3)
0
0 -0
1
1 server(M2),
64: Overseer.System (LinkServer2)
0
0 -0
1
0 server(M2),
63: Overseer.System (LinkServer1)
as:
The analyze_system Command and Requests
8-243
dump_rsv_socket
The following table discribes the most important fields in the output of the preceding
example.
Field
Description
last_server_tid
The last server transaction ID used for this socket
group nxt
The thread of socket numbers of regular sockets; rsv points to the
parent rsv socket.
newreq_rcvd
The number of requests that have been received at the reserved
socket
newreq_rpts
The number of requests that were repeated because the receiver
did not handle them within a certain period of time
busy_sent
The number of times VOS responded to a repeated request by
saying that the server was busy
n_queued
The number of requests that could not be immediately assigned to
a server at the time of arrival because all servers were busy. Also
the percentage of requests queued.
n_ignored
The number of requests that could not be queued because the
queue was full
prq_len
The current pending request queue length
prq_max_len
The maximum length of the pending request queue
pending_request_
queue
First, the entry number from the pending request table. Then the
source (src) address, which is made up of a two-character client
station number and two-character client socket number, both in
hexadecimal form. Finally, the client transaction ID (tid), in
hexadecimal form. If the pending request queue is empty, this
heading does not appear.
Related Information
For more information about StrataNET-related analyze_system requests, see the
description of the dump_net_info, dump_net_tids, dump_nst, dump_prt,
dump_rst, dump_socket, and dump_socket_info requests.
Refer to Figure 8-1 in the description of the dump_socket_info request for
information about the linking of sockets, rsv_sockets, and other structures.
8-244
VOS System Analysis Manual (R073)
dump_scheduler_queues
dump_scheduler_queues
8-
Purpose
This request displays information about the state of the queues maintained by the
scheduler on the analyzed module or dump.
Display Form
------------------------------- dump_scheduler_queues --------------------------interval:
Command-Line Form
dump_scheduler_queues
[-interval number]
Argument
* -interval number
Specifies a time interval, in seconds, between repetitive displays of scheduler
queue information on the analyzed module. The default value for number is three
seconds; the value cannot be less than 1. If this argument is not specified, the
information is displayed once.
To cancel the repetitive display, press <CTRL><BREAK>. This brings your process to
command level.
Explanation
The dump_scheduler_queues request displays information about the state of the
queues maintained by the scheduler on the analyzed module or dump.
See the section Setting and Defining Priority Levels and the set_scheduler_info
command description in the manual VOS System Administration: Administering and
Customizing a System (R281) for information about how processing priorities are
scheduled.
The analyze_system Command and Requests
8-245
dump_scheduler_queues
Examples
In the following example, the dump_scheduler_queues request displays information
about the scheduler queues on a module.
NOTE
A process is idle when the value of the LEFT column is
**.**, the value of the START column is >999, and the
value of the RUN column is >999.
as:
QUEUE
alarm
P#
41
49
19
5
66
67
65
4
3
40
33
27
35
39
279
28
68
23
45
38
44
C P
8
7
9
9
7
7
7
9
9
8
8
7
8
6
8 5
7
7
9
5
6
5
Q CT LEFT START
RUN USER
4 1 0.37 >999 59.5 Overseer (load_control.pm)
6 1 0.06 49.8
4.4 Overseer (oop.pm)
2 1 0.25 600.2
9.4 Maintenance_Utility ()
2 1 **.** >999
4.1 Cache_Manager_Locker ()
6 1 0.01 242.8
1.9 Overseer (oracle_tpo.pm)
6 1 0.39 165.4
1.1 Overseer (oracle_tpo.pm)
6 1 0.36 417.6
1.1 Overseer (oracle_tpo.pm)
2 1 **.** >999
7.6 Cache_Manager_Timer ()
2 1 **.** >999
0.4 Cache_Manager_Post ()
4 1 0.98
1.8
1.8 Overseer (mail_handler.pm)
4 1 0.29 253.8 80.3 Overseer (mail_handler.pm)
6 1 0.49 44.3 44.3 Overseer (watch_kernel.pm)
4 1 0.82 573.0 40.4 Overseer (mail_handler.pm)
10 1 2.00 809.2 44.9 Overseer (mh_notifier.pm)
4 3 1.55
7.2
0.0 Joe_Smith (office.pm)
6 1 0.49 742.5 742.5 Overseer (mail_handler.pm)
6 1 0.35 50.1 49.8 Overseer (oracle_tpo.pm)
2 1 0.31 78.2 34.8 Overseer (tp_overseer.pm)
10 1 1.87 >999 327.5 Overseer (cal_notifier.pm)
10 1 4.26 847.9 841.5 Overseer (mh_sorter.pm)
10 1 0.51 >999 >999 Overseer (oracle_tpo.pm)
The following table describes the fields that appear in the output of the previous
example.
(Page 1 of 2)
8-246
Field
Description
QUEUE
One of three types of queues for a process. The following table describes
these queues.
P#
The process number
The CPU the process is running on
The priority level
VOS System Analysis Manual (R073)
dump_scheduler_queues
(Page 2 of 2)
Field
Description
The quantum type (time-slice type)
CT
The count (the number of time slices of the corresponding type that the
process can receive)
LEFT
The number of seconds remaining in the processs time slice
START
The number of seconds since the time slice started to run
RUN
The number of seconds since the process was last run
USER
The user logged in to the process, and the program that the process is
running
The following types of queues may be listed in the QUEUE column.
Field
Description
ready
Lists processes that are in the ready queue, waiting for CPU time
short wait
Lists processes that VOS is keeping in the short wait queue for a short
time, pending notification of an event
alarm
Lists processes that are waiting for time-outs (alarms)
The analyze_system Command and Requests
8-247
dump_socket
dump_socket
8-
Purpose
This request displays socket information for StrataLINK connections on a module.
Display Form
-------------------------------- dump_socket -------------------------------socket_numbers:
-all:
no
-full:
no
-long:
no
Command-Line Form
dump_socket
[socket_numbers]
[-all]
[-full]
[-long]
Arguments
* socket_numbers
The numbers of zero or more regular socket numbers to be displayed. You cannot
specify this argument if you specified the -all argument.
* -all
<CYCLE>
Displays all sockets. You cannot specify this argument if you specified a value for
the socket_numbers argument.
* -full
<CYCLE>
Displays detailed information about each socket. In particular, if Socket Transaction
Lists or input queues exist, they are listed.
8-248
VOS System Analysis Manual (R073)
dump_socket
* -long
<CYCLE>
Displays data in long form; in some cases, the requst displays more than one table.
For example, when reserved sockets are listed, any subordinate regular sockets
are listed adjacent to the reserved sockets.
Explanation
You must specify at least one socket number or the -all switch.
To obtain the most information about all sockets, specify dump_socket -all -full
-long.
Examples
In the following example, the dump_socket request displays information about all
active StrataLINK sockets on a module.
as: dump_socket -all
Skt Last
Event
TID
Other
Response Group
CTID
ID
Clnt-Srvr
Stn Skt
Type Seq Rsv Nxt
Flags
---- ---- -------- --------- ----- ---- ---- --- --- ---- ----1 FFFF 4096B900 0000-0000
0
0 -0
1
0 server(M2),
input_wait, <transaction_list_present>
pid: 010F2016x, process 22: Overseer.System (LinkServer1)
2 FFFF 409699F0 0000-0000
0
0 -0
1
1 server(M2),
input_wait, <transaction_list_present>
pid: 010F2017x, process 23: Overseer.System (LinkServer2)
3 FFFF 4096FD70 0000-0000
0
0 -0
1
2 server(M2),
input_wait, <transaction_list_present>
pid: 010F2018x, process 24: Overseer.System (LinkServer3)
4 FFFF 40B0F110 0000-0000
0
0 -0
13
0 server(M2),
input_wait, <transaction_list_present>
pid: 010F203Ex, process 62: Overseer.System (OpenLinkClient)
256 052F 40C25E80 0000-0000
0
0 -0
0
0
<transaction_list_present>
pid: 010F2025x, process 37: Overseer.System (MailSorter)
257 50F7 40979420 0000-0000
0
0 -0
0
0
<transaction_list_present>
pid: 010F201Ax, process 26: Overseer.System (NetworkWatchdog)
258 0075 409E10A0 0000-0000
0
0 -0
0
0
<transaction_list_present>
....
as:
The analyze_system Command and Requests
8-249
dump_socket
Related Information
For more information about StrataNET-related analyze_system requests, see the
description of the dump_net_info, dump_net_tids, dump_nst, dump_prt,
dump_rsv_socket, and dump_socket_info requests.
8-250
VOS System Analysis Manual (R073)
dump_socket_info
dump_socket_info
8-
Purpose
This request displays information about StrataLINK and StrataNET sockets on a
module.
Display Form
------------------------------- dump_socket_info -----------------------------sockets:
-rsv_sockets:
-stations:
-net_socket_table:
no
-rsv_socket_table:
no
-pending_request_table: no
-net_tids:
no
-all:
no
-full:
no
-long:
no
-header:
no
-free:
no
Command-Line Form
dump_socket_info
[-sockets [number...]]
[-rsv_sockets [number...]]
[-stations [number...]]
[-net_socket_table]
[-rsv_socket_table]
[-pending_request_table]
[-net_tids]
[-all]
[-full]
[-long]
[-header]
[-free]
The analyze_system Command and Requests
8-251
dump_socket_info
Arguments
* -sockets [number...]
Specifies the numbers of zero or more regular sockets to display.
* -rsv_sockets [number...]
Specifies the numbers of zero or more reserved sockets to display.
* -stations [number...]
Specifies the station numbers of zero or more link stations for which to display net
transaction IDs (tids).
* -net_socket_table
Displays the net socket table (NST).
* -rsv_socket_able
Displays the reserved socket table (RST).
* -pending_request_table
Displays the pending request table (PRT).
* -net_tids
Displays all last server tids for a station.
* -all
Displays all tables.
* -header
Displays only header information for each table.
<CYCLE>
<CYCLE>
<CYCLE>
<CYCLE>
<CYCLE>
<CYCLE>
* -full
<CYCLE>
Displays in depth information; in some cases, the request displays more than one
table. For example, when reserved sockets are listed, any subordinate regular
sockets are listed subordinate to the reserved sockets.
* -long
<CYCLE>
Displays the data in long form, which in general uses one display line per table item.
If you specify no, the request displays only the most important information.
8-252
VOS System Analysis Manual (R073)
dump_socket_info
Explanation
Sockets are used by StrataLINK and StrataNET to route messages between Stratus
modules. StrataLINK and StrataNET sockets are completely distinct from the sockets
used by TCP/IP for addressing.
The dump_socket_info request displays information about StrataLINK and
StrataNET sockets on a module. Requests related to this request include:
dump_net_tids
dump_nst
dump_prt
dump_rst
dump_rsv_socket
dump_socket
The data dumped by these commands come from the following interlinked structures:
NST - Net Socket Table
PKT - VC Packets
PRT - Pending Request Table
RST - Reserved Socket Table
STL - Socket Transaction List
Figure 8-1 shows the relationship between these structures.
The analyze_system Command and Requests
8-253
dump_socket_info
nstp$
rstp$
NST
HDR
1
Attached Socket
Data
Attached RSV
Socket Data
Skt 1
RSV Skt 1
in
stl
nx
gp
RST
HDR
1
prq
Skt 5
in
stl
nx
62
63
Skt 9
in
stl
nx
RSV Skt 67
64
gp
65
prq
10
66
11
67
12
13
rst_max_sockets$
VC Packet
STL
prtp$
PRT
nst_max_sockets$
VC Packet
HDR
prt_max_entry$
Figure 8-1. Socket Structures
8-254
VOS System Analysis Manual (R073)
dump_socket_info
If you do not specify the -net_socket_table, -reserved_socket_table,
-pending_request_table, -sockets, -rsv_sockets, -net_tids, or
-stations argument, the request displays all tables.
To display the most information about sockets on a module, specify
dump_socket_info -full -long -all.
Examples
In the following example, the dump_socket_info request displays information about
StrataLINK and StrataNET sockets on a module.
as: dump_socket_info
Net Socket Table - NST at (nstp$) 004802A4x
nst_max_socket$:
255
lockp:
00006286
locker_pid:
00000000
lock_count:
1794496
lock_cycles:
2108030
client_requests:
81489
slot_zero_requests:
0
worry_rcvd:
0
dead_sent:
5904
tiderr_sent:
0
iwait_sent:
0
sockets attached:
1-15 21
Reserved Socket Table - RST at (rstp$) 00483EB4x
rst_max_socket$:
100
rst_max_queue_len$:
100
rsv sockets attached: 1
Pending Request Table - PRT at (prtp$) 00484116x
prt_max_entry$:
150
nleft:
150
min_left:
148
free list:
1-150
{dump_nst for Net Socket Table}
{dump_rst for Reserved Socket Table}
{dump_prt for Pending Request Table}
{dump_socket, dump_rsv_socket for socket information}
{dump_net_tids for station information}
The analyze_system Command and Requests
8-255
dump_socket_info
In the following example, the dump_socket_info request indicates an apparent
threading error, but is not really an error because the request was used in a live
environment and the list was changing.
as:
dump_socket_info -rsv_sockets -full
RSV
SKT
--2
Last Pendg Req Queue ----------- New Requests ----------Busy
S-TID Len Max 1st Lst
Received Rpts Queued %Qd Ignrd
Sent
----- --- --- --- --- ----------- ----- -------- ---- ----- ------61E6
1 11 133 133
1073622
280
38
0%
0
2
Skt
Last
Event
TID
Other
Response Group
CTID
ID
Clnt-Srvr
Stn Skt
Type Seq Rsv Nxt
Flags
---- ---- -------- --------- ----- ---- ---- --- --- ---- ----24 FFFF 04883950 26E2-C15B BB 60
18 -0
2
23 server(MEP),
unclean, data_accepted
pid: 4303204Fx, process 79: Overseer.System (BridgeServer2)
23 FFFF 04880F30 A295-C1B8 BB 1
15 -0
2
0 server(MEP),
unclean, data_accepted
pid: 4303204Ex, process 78: Overseer.System (BridgeServer1)
Pending request queue: Source
Client TID
133:
166- 16
7C5E
142:
147- 13
0FF7
135:
129- 15
26D2
PRQ THREADING ERROR: prq_last (133) does not equal last (135).
RSV
SKT
--38
Last Pendg Req Queue ----------- New Requests ----------Busy
S-TID Len Max 1st Lst
Received Rpts Queued %Qd Ignrd
Sent
----- --- --- --- --- ----------- ----- -------- ---- ----- ------38DF
0
6
0
0
7289209
845
2129
0%
0
263
Skt
Last
Event
TID
Other
Response Group
CTID
ID
Clnt-Srvr
Stn Skt
Type Seq Rsv Nxt
Flags
---- ---- -------- --------- ----- ---- ---- --- --- ---- ----12 FFFF 04852F90 0000-0000
0
0 -0
38
10 server(M2),
input_wait
pid: 43032040x, process 64: Overseer.System (NetClient2)
Socket Transaction List at 04860650
stl.max:
20
stl.cur_used:
0
stl.max_used:
20
10 FFFF 001F4D20 0000-0000
0
0 -0
38
0 server(MEP),
input_wait
pid: 4303203Fx, process 63: Overseer.System (NetClient)
Socket Transaction List at 001D3530
stl.max:
20
stl.cur_used:
0
stl.max_used:
20
as:
8-256
VOS System Analysis Manual (R073)
dump_socket_info
Related Information
For more information about StrataNET-related analyze_system requests, see the
description of the dump_net_info, dump_net_tids, dump_nst, dump_prt,
dump_rst, dump_rsv_socket, and dump_socket requests.
The analyze_system Command and Requests
8-257
dump_stream
dump_stream
Purpose
This request displays VOS STREAMS structures, including the device, osr, sth,
queue, msg, and other streams internal structures.
Display Form
----------------------------------- dump_stream --------------------------------sth:
-queue:
-sigs:
-osr:
-polls:
-dev:
-msg:
-sq:
-sqh:
-stm_sched:
no
-driver_table: no
-stm_msg:
no
-timerq:
no
-bufcallq:
no
-all_streams:
no
-dbg_mhq:
no
-msg_q:
no
-verbose:
yes
-drivers:
yes
-long:
no
-msg_dump_size: 32
-leaks_only:
no
8-258
VOS System Analysis Manual (R073)
8-
dump_stream
Command-Line Form
dump_stream
[-sth address]
[-queue address]
[-sigs address]
[-osr address]
[-polls address]
[-dev address]
[-msg address]
[-sq address]
[-sqh address]
[-stm_sched]
[-driver_table]
[-stm_msg ]
[-timerq ]
[-bufcallq ]
[-all_streams ]
[-dbg_mhq ]
[-msg_q ]
[-no_verbose ]
[-no_drivers ]
[-long ]
[-msg_dump_size number]
[-leaks_only]
Arguments
* -sth address
Displays the stream head structure. Specify the address contained in the sth_ptr
of the device structure or the osr_sth field in the osr. The stream head structure
displays all queues associated with a stream.
* -queue address
Specifies the address of a queue to display a queue and its call stacks. Specify this
argument when you want to look at call stacks of a queue that is a parameter to a
streams put routine.
* -sigs address
Displays the sigs_s structure. Specify the address contained in the sth_sigs
field of the sth.
The analyze_system Command and Requests
8-259
dump_stream
* -osr address
Displays the osr structure. Specify the address denoted by read_osrp,
write_osrp, and ioctl_orsp in the device structure. You can display these
values with the -dev argument using the info_ptr address displayed with the
dump_porte request.
* -polls address
Displays the polls_s structure. Specify the address contained in the sth_polls
field of the sth.
* -dev address
Displays the device structure. Use the address denoted by the info_ptr in the
porte structure.
* -msg address
Displays structures and contents of any messages contained in a streams queue.
* -sq address
Displays the synchronization queue element structures for a msg or an osr
structure.
* -sqh address
Displays the synchronization queue head structures. These are also displayed with
the -queue argument, unless the parents sqh structure is different from the
queues.
* -stm_sched
Dumps the scheduling queues for the STREAMS daemons. This argument also
dumps various meters. The Explanation section describes the meters, and the
Example 1 section provides an example. The default value is no.
* -driver_table
Dumps information about all STREAMS drivers from the device driver table. This
argument also prints per-driver totals for the SQH meters (these totals are also
displayed by specifying the -stm_sched argument). Only nonzero meters are
printed. The default value is no.
* -stm_msg
<CYCLE>
Displays the VOS STREAMS memory cache, which contains all allocated msg
structures. Some of these msg structures may be in use by a module or driver.
Others may have been freed by the VOS STREAMS environment but not by VOS.
* -timerq
<CYCLE>
Displays the streams timer queue in the streams message cache. This queue
maintains active and inactive timer requests.
8-260
VOS System Analysis Manual (R073)
dump_stream
* -bufcallq
<CYCLE>
Displays the streams bufcall queue in the streams message cache. This queue
maintains active and inactive bufcall requests.
* -all_streams
<CYCLE>
Displays all open streams listed in a streams hash table. The output for each
stream is the same as the output from the -sth argument when the -verbose
mode is also specified.
* -dbg_mhq
<CYCLE>
Displays all free messages. Free messages are those messages which are no
longer used and which are ready for reuse. By default, no free messages are
displayed.
* -msg_q
<CYCLE>
Displays all allocated messages. By default, no allocated messages are displayed.
* -no_verbose
<CYCLE>
Specifies that other arguments display arguments in a summary format. If you
specify -verbose, more detailed information is displayed by each argument.
* -no_drivers
<CYCLE>
Does not display queues associated with modules or drivers (other than the sth
queue) unless you specify -verbose.
* -long
<CYCLE>
Displays additional fields. By default, these additional fields are not displayed.
* -msg_dump_size
Sets the maximum number of bytes to be dumped when mblks are dumped. The
dump is never more than the amount of data from the beginning of the message
(b_rptr) to the end of the message (b_wptr). This argument affects output from
the arguments -msg, -msg_q, and -dbg_mhq as well as arguments such as
-sth, -osr, and -all_streams, which print out messages referenced by other
data structures. The default value is 32.
* -leaks_only
When you specify this argument, analyze_system examines all STREAMS
structures it can find and eliminates any messages referenced by those structures
from the display of allocated messages. Allocated messages that will be displayed
are as follows:
Transient (i.e., being passed up or down the stack of a process that is currently
executing)
Memory leaks
The analyze_system Command and Requests
8-261
dump_stream
Messages that were missed by the marking prepass because the driver .pm
files were out of date and analyze_system could not associate queue_t
nodes with the appropriate driver
Missing or incorrect code in the analyze_system marking prepass. The
default value for this argument is no.
Explanation
The dump_stream request displays VOS STREAMS structures, including the
device, osr, sth, queue, msg, and streams hash table structures.
Figures 8-2 and 8-3 illustrate the relationships between a number of VOS STREAMS
data structures than can be displayed with the dump_stream request. Figure 8-2
illustrates the data structures used to perform input and output operations in VOS
STREAMS.
The output of the dump_stream request has been modified. You no longer need
detailed knowledge of STREAMS internals to understand its output. The request now
validates many of the STREAMS structures and detected errors contain the string ***.
Therefore, you can issue the following command to check STREAMS structures.
match ***;dump_stream -all_streams -long
A dump of the synchronization queue header (SQH) now indicates who locked it and
prints out queued operations in easy-to-understand output.
8-262
VOS System Analysis Manual (R073)
dump_stream
porte
device
read osr
write osr
ioctl osr
hash table
poll osr
sth
write queue
read queue
write queue
read queue
streams cache
msg
msg
msg
Figure 8-2. VOS STREAMS I/O Data Structures
The analyze_system Command and Requests
8-263
dump_stream
The VOS STREAMS data structures shown in Figure 8-2 are described in the following
table.
Data Structure
Description
porte
This data structure is allocated for each attachment to a streams device
by a process.
streams hash
table
All open streams are stored in a hash table in the kernel.
device
This structure is pointed at by the porte. It contains pointers to the
per-process streams data structures, including the stream head data
structure.
osr
The data structure used to pass streams requests from VOS to the
streams environment in the kernel. Three osrs are stored in the device
structure. These are used for reading, writing, and sending ioctl
requests to a stream. These osrs are allocated for opening a stream,
closing a stream, and for polling a stream. These latter osrs exist only
for the duration of the operation while the osrs stored in the device exist
while a stream is open.
sth
The stream head data structure contains information about a stream,
including the stream head queues, flags, write offsets, and signal and
poll structures.
queue
The stream head points to the stream head queues, which in turn point
to the queues for any modules pushed below the stream head and the
driver.
msg
The message structure used to hold streams messages. Figure 8-3
displays two messages on the write queue of a driver. The first message
contains two msg structures while the second message contains only
one.
Figure 8-3 illustrates the data structures used to synchronize different threads of
execution accessing streams structures within the kernel.
8-264
VOS System Analysis Manual (R073)
dump_stream
sq_next
sq
sqh_next
sq
mult_sqh
sqh_prev
sqh_prev
osr sq owner
sth
queue pair
locking
write queue
sqh
module locking
write queue
sqh
sqh_parent
sqh_parent
nt
re
a
p
h_
sq
sqh_owner
read queue
sqh
sqh_parent
read queue
sqh
sqh_parent
module sqh
sq
sq
sq
Figure 8-3. VOS STREAMS Data Structures That Synchronize Execution Threads
The analyze_system Command and Requests
8-265
dump_stream
The VOS STREAMS data structures shown in Figure 8-3 are described in the following
table.
Data Structure
Description
sqh
The synchronization queue head is responsible for collecting
synchronization elements and coordinating their access to the streams
resource the sqh is governing.
sq
The synchronization element is used to gain access to streams
resources. Both osrs and msg structures contain an sq element.
mult_sqh
It is sometimes necessary in VOS STREAMS to have control of multiple
streams resources simultaneously. When this need arises, the
mult_sqh is acquired first. After the mult_sqh is acquired, VOS
STREAMS attempts to acquire the next resource. The mult_sqh is
used for opening and closing streams as well as pushing and popping
streams modules onto a streams stack and links and unlinking. In all of
those cases, both the mult_sqh and the governing sqh of the stream
head are acquired before operations commence.
In addition to the mult_sqh, the queue sqhs of both the stream head and a driver are
shown in Figure 8-3. The stream head uses queue pair locking and so the write queue
sqh points to the read queue sqh. All stream head acquisitions use the read queue
sqh. The driver shown below the stream head used module level locking. In this case,
both the write queue and the read queue sqhs point to a third sqh. All acquisitions of
this driver use the third sqh labeled module sqh.
Examples
Before issuing this request, issue the list_port_attachments request to identify
the address, port name, or port number of a port attached to a streams device. Then
issue the dump_porte request to obtain the pointer to the streams device structure
(info_ptr). If this is a streams module and you have not specified -brief, this
request always displays the info_ptr address.
8-266
VOS System Analysis Manual (R073)
dump_stream
Description of the Output from dump_stream -dev
When you first issue the dump_stream request, use the -dev argument and specify
the address of info_ptr displayed by dump_porte. The following table describes
the most important fields displayed by dump_stream -dev.
Field
Description
read_osrp
A pointer to the osr used for all read operations. These include read,
getmsg, and getpmsg.
write_osrp
A pointer to the osr used for all write operations. These include write,
putmsg, and putpmsg.
ioctl_osrp
A pointer to the osr used for ioctl operations
sth_ptr
A pointer to the stream head structure
Description of the Output from dump_stream -osr
With the read_osrp, write_osrp, or ioctl_osrp pointers displayed the
dump_stream -dev request, you can then issue the dump_stream -osr request.
The following table describes the most important fields displayed by dump_stream
-osr.
(Page 1 of 2)
Field
Description
osr_sth
A pointer to the owning stream head. This value should always match the
sth_ptr value displayed by dump_stream -dev.
osr_pid
This value uniquely identifies a portes set of osrs to a stream head.
This is necessary since a number of process could be performing I/O
concurrently on a stream.
osr_flags
For the three permanent osrs stored in the device structure, the bit
F_OSR_NOFREE should always be set. For transient osrs such as the
close osr or the poll osr, this flag is not set.
osr_state
If a streams operation is in progress, then this field contains the next state
where execution will continue in the streams environment code.
osr_istate
Some streams operations a second state value which is identified by this
field. In close operations, for example, VOS STREAMS uses both state
fields. The field osr_state is used to close a stream and the field
osr_istate is used to pop modules and drivers off a stream during the
close.
The analyze_system Command and Requests
8-267
dump_stream
(Page 2 of 2)
Field
Description
event_id
The three permanent osrs each have a system event that is used for
synchronization purposes in the kernel. This field contains the event
address.
event_count
The current event count for the event indicated by the event_id field
Description of the Output from dump_stream -sth
With the sth_pointer pointer displayed by the dump_stream -dev request or the
osr_sth pointer displayed by the dump_stream -osr request, you can then issue
the dump_stream -sth request. The following table describes the most important
fields displayed by dump_stream -sth.
(Page 1 of 2)
8-268
Field
Description
sth_rq
A pointer to the stream head read queue
sth_wq
A pointer to the stream head write queue
sth_dev
The major and minor number for the stream device. The major
number is contained in the upper 14 bits and the minor number is
contained in the lower 18 bits.
sth_write_error
If an M_ERROR message has been sent up in response to a write
operation, this field contains an error. If this value is nonzero, it will
be returned in response to all write operations on the stream.
sth_read_error
If an M_ERROR message has been sent up in response to a read
operation, this field contains an error. If this value is nonzero, it will
be returned in response to all read operations on the stream.
VOS System Analysis Manual (R073)
dump_stream
(Page 2 of 2)
Field
Description
sth_flags
This field contains one or more of the following informational flags
for the stream:
F_STH_ONDELAY - The stream is in non-blocking mode.
F_STH_READ_WAIT - The stream is waiting for data to read.
F_STH_WRITE_WAIT - The stream is waiting to write data.
F_STH_IOCTL_WAIT - The stream is waiting for an ioctl to
finish.
F_STH_READ_ERROR - The stream received an M_ERROR
and all reads will fail.
F_STH_WRITE_ERROR - The stream received an M_ERROR
and all writes will fail.
F_STH_LINKED - The stream is linked under another stream.
F_STH_HANGUP - The stream is in non-blocking mode.
F_STH_CLOSE_WAIT - The stream is in non-blocking mode.
F_STH_CLOSED - The stream is in non-blocking mode.
F_STH_CLOSING - The stream is in non-blocking mode.
sth_sigs
A pointer to the sigs structure. This field becomes active in
response to an I_SETSIG operation on a stream.
sth_wroff
If a driver sends an M_SETOPTS message in order to set the stream
heads write offset value, this field contains the offset.
sth_muxid
The multiplexor identifier. This field is only valid if a stream is linked
on top of another stream.
sth_next
A pointer to another stream that is stored in the same bucket in the
same streams hash table
event_id
The stream head maintains a pointer to the same system event
allocated as port of an add device operation in the kernel. This
event is used for poll handling.
event_count
The event count for the stream
ref_cnt
A reference count of the number of processes that have the stream
open
Description of the Output from dump_stream -queue
With the sth_rq or sth_wq pointers displayed by the dump_stream -sth request,
you can then issue the dump_stream -queue request. The following table describes
the most important fields displayed by dump_stream -queue.
The analyze_system Command and Requests
8-269
dump_stream
.
Field
Description
q_qinfo
A pointer to the qinit structure for this queue. The qinit structure is
described in the VOS Communications Software: STREAMS Programmers
Guide (R306).
q_first
A pointer to the first message (if any) on the queue
q_last
A pointer to the last message (if any) on the queue
q_next
A pointer to the next queue either up stream or down stream. For a write
queue this points to the next queue down stream. For a read queue this
pointer to the next queue up stream.
q_ptr
A pointer to the private module or driver data. For the stream heads queues
this value is a pointer to the sth.
q_count
The byte total of all messages currently on the queue
q_flag
Like the stream head, the queue structure has a set of informational flags.
These flags include the following:
QREADR - The queue is a read queue.
QNOENB - The queue wont be enabled with a call to putq.
QFULL - The queues qcount has been exceeded, the queue is full.
QUSE - The queue is ready to use.
QOLD - The module supports UNIX System 5.3 style opens as
opposed to UNIX System 5.4 opens.
q_hiwat
The high-water mark for the queue
q_lowat
The low- water mark for the queue
q_ffcp
A pointer to the forward flow control queue
q_bfcp
A pointer to the backward flow control queue
Description of the Output from dump_stream -msg
With the q_first or q_last pointers displayed by the dump_stream -queue
request, you can then issue the dump_stream -msg request. The following table
describes the most important fields displayed by dump_stream -msg.
(Page 1 of 2)
8-270
Field
Description
b_next
A pointer to the next message on the queue
b_prev
A pointer to the previous message on the queue
VOS System Analysis Manual (R073)
dump_stream
(Page 2 of 2)
Field
Description
b_cont
A pointer to the next part of this message. For example, if an
application had sent both a control portion and data portion down
stream as port of a putmsg call, the first msg structure of the
message would have an M_PROTO type, and the b_contr msg
structure would have an M_DATA type.
b_rptr
A pointer to where data would be read from the message. This
typically denotes the beginning of the data in the message.
b_wptr
A pointer to where data would be written in the message. This
typically denotes the end of the data in the message.
datap->db_type
The type of message such as M_PROTO, M_DATA, or M_PCPROTO.
datap->db_size
The memory bucket size this message was allocated from.
mhp->vhm.caller
The routine responsible for allocating the message or for a freed
message the last routine to free the message. The system variable
who_done_it$ must be set to 1 for this field to display meaningful
information.
mhp->ref_cnt
The number of message references to a message structure. When
a message is duplicated using dupb the reference count is
increased.
Description of the Output from dump_stream -sqh
With the q_sqh_ptr pointer displayed by the dump_stream -queue request, you
can then issue the dump_stream -sqh request. The following table describes the
most important fields displayed by dump_stream -sqh.
Field
Description
sqh_next
A pointer to the next sq on the synchronization queue. If this pointer is the
same as sqh_parent, then the synchronization queue is empty.
sqh_prev
A pointer to the last sq on the synchronization queue
sqh_parent
A pointer to the parent synchronization queue
flags
The status flags for the synchronization queue, such as SQ_INUSE
sqh_owner
A pointer to current owning sq
sqh_refcnt
The number of times the owning sq has acquired this synchronization
queue
The analyze_system Command and Requests
8-271
dump_stream
Description of the Output from dump_stream -sq
With the sqh_next or sqh_prev pointers displayed by the dump_stream -sqh
request, you can then issue the dump_stream -sq request. The following table
describes the most important fields displayed by dump_stream -sq.
Field
Description
sq_next
A pointer to the next sq waiting to acquire the synchronization queue.
This pointer is the same as the synchronization queues address if the sq
is the last on the list.
sq_prev
A pointer to the previous sq in the list
sq_target
A pointer to the synchronization queue
sq_flags
The status flags for this sq
sq_event_id
If the sq is also an osr, this field contains the event that will be notified
when the targeted synchronization queue is released.
sq_entry
If the sq is part of a message or queue, this field contains the routine to
be called when the owning process is finished with it callback.
sq_arg()
The argument passed in the call to sq_entry
Description of the Output from dump_stream -stm_msg
The following table describes the most important fields displayed by dump_stream
-stm_msg.
8-272
Field
Description
total_size
The actual number of bytes in use by streams. This includes the msg
headers that are in cache and in use by modules and drivers.
max_size
The maximum memory size that is usable by VOS STREAMS
total_mhs
The number of msg header structures currently in use by VOS STREAMS
n_free_mhs
The number of msg header structures in the cache
hq_size
The size of the memory space bucket. The following are the bucket sizes
for VOS STREAMS in bytes: 8, 16, 32, 64, 256, 512, 1024, 2048, and
4096. A msg structure is allocated from the appropriate memory bucket
based on size.
hq_total
The total number of msg header structures allocated for a bucket
VOS System Analysis Manual (R073)
dump_stream
Description of the Output from dump_stream -timerq
The following table describes the most important fields displayed by dump_stream
-timerq.
Field
Description
lbolt
The current time in lbolts
Callback Time
Per queue, the time in lbolt units when the timer is to fire
Entry
Variable Ptr
Per queue, the entry which is to be called when the timer fires
Callback
Argument
Per queue, the argument to the Entry Variable Ptr
Description of the Output from dump_stream -bufcallq
The following table describes the most important fields displayed by dump_stream
-bufcallq.
Field
Description
n_bc_entries
The total number of bufcall requests that can be outstanding
n_bc_sched
The actual number of bufcall requests scheduled
Description of the Output from dump_stream -stm_sched
This section describes the meters that are dumped when you specify the argument
-stm_sched. The first section of the meters is SQH-specific; the remaining sections
are per memory pool. Only nonzero meters are printed. The output repeats this
organization for each memory pool.
The SQH meters are generally used to determine the amount of lock contention. High
values often indicate performance problems.The SQH-specific meters indicate the
number of times an SQH lock could not be obtained when trying to perform some
operation on a message and a queue. The SQH-specific meters are as follows:
SQ_PUT MISS
SQ_PUTQ MISS
SQ_CHECK_AND_PUTNEXT MISS SQ_DRAIN_GIZA MISS
SQ_PUTNEXT_MISS
The analyze_system Command and Requests
8-273
dump_stream
Table 8-1 describes the meters that the dump_stream -stm_sched request
generates in its output.
Table 8-1. The dump_stream -stm_sched Meters (Page 1 of 5)
8-274
Meter
Description
CSQ_ACQUIRE_AND_WAIT_SPIN
The number of times the STREAM head spun
while trying to lock an SQH.
CSQ_ACQUIRE_AND_WAIT_SUSPEND
The number of times the STREAM head
suspended (waited) while trying to lock an
SQH.
DRAIN_WORK_Q_MISS
The number of times a call-side operation was
unable to lock an SQH while draining a work
queue (that is, while trying to execute deferred
operations such as service routines or
putnexts that were deferred because the
SQH lock could not be obtained).
DRAIN_WORK_Q_DAEMON_MISS
The number of times the STREAMS daemon
was unable to lock an SQH while draining its
work queue.
FINISH_STREAMS_INTERRUPT_MISS
The number of times an interrupt was unable to
lock an SQH while draining a work queue.
FREEZESTR_MISS
The number of times FREEZESTR was unable
to freeze the STREAM.
TRYLOCK_STREAM_Q_MISS
The number of times a non-STREAMS facility
had to wait to get an SQH lock.
HIT_DISABLED_INTERRUPT
The number of times STREAMS could not
perform operations at interrupt time because a
driver was encountered that had not been
modified to run at interrupt time.
HIT_INTERRUPT_CANPUT_LIMIT
The number of times STREAMS shut down
interrupt processing to avoid tripping dead
CPU timers.
FINISH_STREAMS_INT_QUICK_MISS
The number of times an interrupt was not able
to determine which CPU had locked an SQH it
was trying to lock.
FINISH_STREAMS_INT_HANDOFF
The number of times an interrupt handed off an
SQH (and the work queued on it) to the CPU
that had the SQH locked.
VOS System Analysis Manual (R073)
dump_stream
Table 8-1. The dump_stream -stm_sched Meters (Page 2 of 5)
Meter
Description
DRAIN_WORK_Q_QUICK_MISS
The number of times a call-side operation was
not able to determine which CPU had locked
an SQH it was trying to lock.
DRAIN_WORK_Q_HANDOFF
The number of times a call-side operation
handed off an SQH (and the work queued on
it) to the CPU that had the SQH locked.
DRAIN_WORK_Q_DAEMON_HANDOFF
The number of times the STREAMS daemon
handed off an SQH (and the work queued on
it) to the CPU that had the SQH locked.
DRAIN_WORK_Q_HO_DRAIN
The number of times the target CPU unlocked
an SQH while another CPU was handing it off
to the target CPU.
PUTBQ_IN_UNLOCKED_CONTEXT **
The number of times putbq was called in an
unlocked context. This may indicate that the
driver calling putbq has a message reordering
bug (it depends on what locking algorithm the
driver was using to protect the queue it does
the putbq on).
Q_FLOW_ON
The number of times ordinary STREAMS flow
control was relaxed. The number of times flow
control was hit is not metered, but should be
symmetrical.
QB_FLOW_ON
The number of times ordinary STREAMS band
flow control was relaxed.
SQ_FLOW_ON
The number of times flow control was relaxed
due to an inordinate number of messages
deferred on an SQH.
CALL_SIDE_TO_DAEMON
DAEMON_QUICK_LOOP
DRAIN_WORK_Q
DRAIN_WORK_Q_DAEMON
ENTER_STREAMS
EXIT_STREAMS
FINISH_STREAMS_INTERRUPT
Global meters
FINISH_STREAMS_INTERRUPT
The number of times interrupt processing
handled STREAMS work.
The analyze_system Command and Requests
8-275
dump_stream
Table 8-1. The dump_stream -stm_sched Meters (Page 3 of 5)
8-276
Meter
Description
HAND_OFF_STREAMS_TO_CALL_
SIDE
The number of times interrupt processing
handed off processing to call side because call
side was executing STREAMS.
HAND_OFF_STREAMS_TO_DAEMON
The number of times anything (for example, an
interrupt that scheduled STREAMS activity or
a call-side execution of STREAMS) handed off
processing to the daemon. Such activities may
be transferred because (1) the SQH could not
be locked after a certain number of tries; (2)
there was too much STREAMS activity for a
single interrupt, and/or (3), the STREAMS
driver in question is not written to execute at
interrupt time.
INTERRUPT_SIDE_TO_DAEMON
The number of times interrupt processing
handed off processing to the daemon (either
because the canput limit was hit or because a
driver could not run at interrupt time).
KERNEL_TRAP_EXIT_WORK_DONE
IDLE_PROC_BOTH_TO_DAEMON
IDLE_PROC_INT_Q_TO_DAEMON
IDLE_PROC_CALL_Q_TO_DAEMON
Indicate that unfinished STREAMS work has
been found in various contexts where it is
normally not found. These situations
occasionally occur when a rare window in CPU
targeting is encountered, but the most common
cause is drivers that wait without bracketing the
wait with exit_streams/enter_streams.
Small numbers here do not indicate a problem.
VOS System Analysis Manual (R073)
dump_stream
Table 8-1. The dump_stream -stm_sched Meters (Page 4 of 5)
Meter
Description
CHECK_AND_PUTNEXT_CALLS
INTERRUPT_PUTNEXT_CALLS
PUT_CALLS
PUTQ_CALLS
PUTNEXT_CALLS
QREPLY_CALLS
ALLOCB_CALLS
DUPB_CALLS
ESBALLOC_CALLS
VOS_ESBALLOC_CALLS
QENABLE_CALLS
PUTBQ_CALLS
PULLUPMSG_CALLS
INSQ_CALLS RMVQ_CALLS
GETQ_CALLS
FREEZESTR_CALLS
FLUSHQ+FLUSHBAND_CALLS
COPYB_CALLS
ADJMSG_CALLS
MSGPULLUP_CALLS
BUFCALL_BPRI_LO_SUCCEEDS
BUFCALL_BPRI_MED_SUCCEEDS
BUFCALL_BPRI_HI_SUCCEEDS
BUFCALL_BPRI_LO_FAILS
BUFCALL_BPRI_MED_FAILS
BUFCALL_BPRI_HI_FAILS
UNBUFCALL_CALLS
These indicate the number of times the various
STREAMS primitives have been called.
BUFCALL has been broken down further by
priority and whether or not it succeeded.
SHRINK_MBLK_BUCKET[N]
The number of times STREAMS has moved a
block of STREAMS messages from the
per-CPU cache back into the per-pool cache.
This happens occasionally as STREAMS
messages are freed (by freeb). This indicates
how much the per-CPU caching speeds up
allocb/freeb.
EXPAND_MBLK_BUCKET[N]
The number of times STREAMS has moved a
block of STREAMS messages from the
per-pool cache into the per-CPU cache. This
indicates how much the per-CPU caching
speeds up allocb/freeb.
ALLOC_MBLK_CHUNK
The number of times STREAMS has allocated
a block of STREAMS messages from the
system.
The analyze_system Command and Requests
8-277
dump_stream
Table 8-1. The dump_stream -stm_sched Meters (Page 5 of 5)
8-278
Meter
Description
FREE_MBLK_CHUNK
The number of times STREAMS has freed a
block of STREAMS messages back to the
system.
ALLOC_BPRI_LO_FAILS
ALLOC_BPRI_MED_FAILS
ALLOC_BPRI_HI_FAILS
The number of times allocb (or dupb or
esballoc) has failed because the current
allocation exceeded the threshold for the given
priority.
ALLOC_SYS_LIMIT_EXCEEDED
The number of times allocb (or dupb or
esballoc) has failed because the current
threshold for memory allocated from the
system has been exceeded.
ALLOC_SYS_LIMIT_BALANCE
The number of times the per-pool free lists
were balanced to try to avoid an allocb (or
dupb or esballoc) failure.
ALLOC_NO_MBLK_VM
LLOC_NO_MBLK_BUFFERS
ALLOC_NO_IO_VM
LLOC_NO_IO_BUFFERS
ALLOC_PKIO_CVI_FAILURE
The number of times STREAMS was not able
to obtain virtual memory and/or wired buffers
(backing store for the VM) from the system.
This would indicate another cause of allocb
(or dupb or esballoc) failures.
BUFCALL_BPRI_LO_CALLBACKS
BUFCALL_BPRI_MED_CALLBACKS
BUFCALL_BPRI_HI_CALLBACKS
The number of bufcall callbacks.
GLOBAL_CACHE_FLUSH
The number of times the per-pool free lists
were flushed because the limit for the amount
of memory to allocate from the system was
reached.
GLOBAL_CACHE_BALANCE
The number of times the memory daemon
executed cache balancing when there was no
immediate pressure to do so.
UNBUFCALL_WAITS
The number of times unbufcall had to spin
because another CPU was executing the
callback routine for the bufcall in question.
CROSS_POOL_FREES
The number of times a message allocated from
one memory pool was freed back into a
different memory pool. High numbers indicate
that the per-CPU and per-memory pool
caching of the freed STREAMS message is not
working effectively.
VOS System Analysis Manual (R073)
dump_stream
Example 1
The following request dumps the scheduling queues for the STREAMS daemon, as
well as various meters.
as: dump_stream -stm_sched
Dumping stm_sched @ C087D2A0.
ppi[0].spin_lock
= C08064C0 (unlocked)
ppi[0].num_sqhs_queued
= 0
ppi[0].num_busy_procs
= 0
ppi[0].num_procs
= 2
ppi[0].spcpu[0].ptep
= C1754000
ppi[0].spcpu[0].proc_busy = 0
ppi[0].spcpu[0].proc_state = PROC_RUNNING
ppi[0].spcpu[1].ptep
= C17549C0
ppi[0].spcpu[1].proc_busy = 0
ppi[0].spcpu[1].proc_state = PROC_RUNNING
ppi[0].meters[SQ_PUT MISS]
= 280
ppi[0].meters[SQ_CHECK_AND_PUTNEXT MISS]
= 18373
ppi[0].meters[SQ_PUTNEXT_MISS]
= 6985
ppi[0].meters[CSQ_ACQUIRE_AND_WAIT_SPIN]
= 81
ppi[0].meters[FINISH_STREAMS_INTERRUPT_MISS] = 1
ppi[0].meters[HIT_DISABLED_INTERRUPT]
= 211233
ppi[0].meters[FINISH_STREAMS_INT_QUICK_MISS] = 21
ppi[0].meters[FINISH_STREAMS_INT_HANDOFF] = 1382
ppi[0].meters[DRAIN_WORK_Q_QUICK_MISS]
= 394
ppi[0].meters[DRAIN_WORK_Q_HANDOFF]
= 3504
ppi[0].meters[DRAIN_WORK_Q_HO_DRAIN]
= 128
ppi[0].meters[PUTBQ_IN_UNLOCKED_CONTEXT **] = 2946
ppi[0].meters[Q_FLOW_ON]
= 2707
ppi[0].meters[DAEMON_QUICK_LOOP]
= 3560
ppi[0].meters[DRAIN_WORK_Q]
= 37820
ppi[0].meters[DRAIN_WORK_Q_DAEMON]
= 368301
ppi[0].meters[ENTER_STREAMS]
= 939196
ppi[0].meters[EXIT_STREAMS]
= 939177
ppi[0].meters[FINISH_STREAMS_INTERRUPT]
= 297194
ppi[0].meters[HAND_OFF_STREAMS_TO_CALL_SIDE] = 14493
ppi[0].meters[HAND_OFF_STREAMS_TO_DAEMON] = 220636
ppi[0].meters[INTERRUPT_SIDE_TO_DAEMON]
= 211234
ppi[0].meters[KERNEL_TRAP_EXIT_WORK_DONE] = 365
ppi[0].meters[IDLE_PROC_CALL_Q_TO_DAEMON] = 9402
ppi[0].meters[CHECK_AND_PUTNEXT_CALLS]
= 36612
ppi[0].meters[INTERRUPT_PUTNEXT_CALLS]
= 571810
ppi[0].meters[PUT_CALLS]
= 2295258
ppi[0].meters[PUTQ_CALLS]
= 180455
ppi[0].meters[PUTNEXT_CALLS]
= 3514925
ppi[0].meters[QREPLY_CALLS]
= 50808
ppi[0].meters[ALLOCB_CALLS]
= 3773841
The analyze_system Command and Requests
8-279
dump_stream
ppi[0].meters[DUPB_CALLS]
= 21609
ppi[0].meters[ESBALLOC_CALLS]
= 974
ppi[0].meters[QENABLE_CALLS]
= 513038
ppi[0].meters[PUTBQ_CALLS]
= 16919
ppi[0].meters[GETQ_CALLS]
= 836962
ppi[0].meters[FLUSHQ+FLUSHBAND_CALLS]
= 174978
ppi[0].meters[COPYB_CALLS]
= 930777
ppi[0].meters[ADJMSG_CALLS]
= 360127
ppi[0].meters[SHRINK_MBLK_BUCKET[0]]
= 45
ppi[0].meters[SHRINK_MBLK_BUCKET[1]]
= 1979
ppi[0].meters[SHRINK_MBLK_BUCKET[2]]
= 1076
ppi[0].meters[SHRINK_MBLK_BUCKET[3]]
= 710
ppi[0].meters[SHRINK_MBLK_BUCKET[4]]
= 390
ppi[0].meters[SHRINK_MBLK_BUCKET[5]]
= 60
ppi[0].meters[SHRINK_MBLK_BUCKET[7]]
= 6
ppi[0].meters[SHRINK_MBLK_BUCKET[8]]
= 10125
ppi[0].meters[SHRINK_MBLK_BUCKET[9]]
= 115
ppi[0].meters[EXPAND_MBLK_BUCKET[0]]
= 52
ppi[0].meters[EXPAND_MBLK_BUCKET[1]]
= 1314
ppi[0].meters[EXPAND_MBLK_BUCKET[2]]
= 477
ppi[0].meters[EXPAND_MBLK_BUCKET[3]]
= 358
ppi[0].meters[EXPAND_MBLK_BUCKET[4]]
= 170
ppi[0].meters[EXPAND_MBLK_BUCKET[5]]
= 26
ppi[0].meters[EXPAND_MBLK_BUCKET[6]]
= 2
ppi[0].meters[EXPAND_MBLK_BUCKET[7]]
= 8
ppi[0].meters[EXPAND_MBLK_BUCKET[8]]
= 5524
ppi[0].meters[EXPAND_MBLK_BUCKET[9]]
= 100
ppi[0].meters[ALLOC_MBLK_CHUNK]
= 43
ppi[0].meters[UNBUFCALL_CALLS]
= 136170
ppi[0].meters[CROSS_POOL_FREES]
= 100048
ppi[0].meters[MSGPULLUP_CALLS]
= 137973
ppi[1].spin_lock
= C0B23000 (unlocked)
ppi[1].num_sqhs_queued
= 0
ppi[1].num_busy_procs
= 0
ppi[1].num_procs
= 2
ppi[1].spcpu[0].ptep
= C0BD8040
ppi[1].spcpu[0].proc_busy = 0
ppi[1].spcpu[0].proc_state = PROC_RUNNING
ppi[1].spcpu[1].ptep
= C0BD8A00
ppi[1].spcpu[1].proc_busy = 0
ppi[1].spcpu[1].proc_state = PROC_RUNNING
ppi[1].pcpu[0].num_canputs_this_interrupt = 4
ppi[1].meters[SQ_PUT MISS]
= 223
ppi[1].meters[SQ_CHECK_AND_PUTNEXT MISS]
= 2
ppi[1].meters[SQ_PUTNEXT_MISS]
= 4367
ppi[1].meters[CSQ_ACQUIRE_AND_WAIT_SPIN]
= 61
ppi[1].meters[HIT_DISABLED_INTERRUPT]
= 123528
ppi[1].meters[FINISH_STREAMS_INT_HANDOFF] = 7
8-280
VOS System Analysis Manual (R073)
dump_stream
ppi[1].meters[DRAIN_WORK_Q_QUICK_MISS]
= 40
ppi[1].meters[DRAIN_WORK_Q_HANDOFF]
= 2707
ppi[1].meters[DRAIN_WORK_Q_HO_DRAIN]
= 99
ppi[1].meters[PUTBQ_IN_UNLOCKED_CONTEXT **] = 1711
ppi[1].meters[Q_FLOW_ON]
= 1577
ppi[1].meters[DAEMON_QUICK_LOOP]
= 19777
ppi[1].meters[DRAIN_WORK_Q]
= 32623
ppi[1].meters[DRAIN_WORK_Q_DAEMON]
= 225241
ppi[1].meters[ENTER_STREAMS]
= 805418
ppi[1].meters[EXIT_STREAMS]
= 805409
ppi[1].meters[FINISH_STREAMS_INTERRUPT]
= 123555
ppi[1].meters[HAND_OFF_STREAMS_TO_CALL_SIDE] = 419
ppi[1].meters[HAND_OFF_STREAMS_TO_DAEMON] = 123912
ppi[1].meters[INTERRUPT_SIDE_TO_DAEMON]
= 123528
ppi[1].meters[KERNEL_TRAP_EXIT_WORK_DONE] = 50
ppi[1].meters[IDLE_PROC_CALL_Q_TO_DAEMON] = 384
ppi[1].meters[CHECK_AND_PUTNEXT_CALLS]
= 31703
ppi[1].meters[INTERRUPT_PUTNEXT_CALLS]
= 93
ppi[1].meters[PUT_CALLS]
= 549709
ppi[1].meters[PUTQ_CALLS]
= 69026
ppi[1].meters[PUTNEXT_CALLS]
= 843523
ppi[1].meters[QREPLY_CALLS]
= 45230
ppi[1].meters[ALLOCB_CALLS]
= 1270440
ppi[1].meters[DUPB_CALLS]
= 12726
ppi[1].meters[ESBALLOC_CALLS]
= 699
ppi[1].meters[QENABLE_CALLS]
= 260881
ppi[1].meters[PUTBQ_CALLS]
= 1927
ppi[1].meters[GETQ_CALLS]
= 597420
ppi[1].meters[FLUSHQ+FLUSHBAND_CALLS]
= 158859
ppi[1].meters[COPYB_CALLS]
= 398112
ppi[1].meters[ADJMSG_CALLS]
= 2961
ppi[1].meters[SHRINK_MBLK_BUCKET[0]]
= 19
ppi[1].meters[SHRINK_MBLK_BUCKET[1]]
= 285
ppi[1].meters[SHRINK_MBLK_BUCKET[3]]
= 3
ppi[1].meters[SHRINK_MBLK_BUCKET[8]]
= 139
ppi[1].meters[SHRINK_MBLK_BUCKET[9]]
= 1
ppi[1].meters[EXPAND_MBLK_BUCKET[0]]
= 17
ppi[1].meters[EXPAND_MBLK_BUCKET[1]]
= 1038
ppi[1].meters[EXPAND_MBLK_BUCKET[2]]
= 637
ppi[1].meters[EXPAND_MBLK_BUCKET[3]]
= 379
ppi[1].meters[EXPAND_MBLK_BUCKET[4]]
= 236
ppi[1].meters[EXPAND_MBLK_BUCKET[5]]
= 39
ppi[1].meters[EXPAND_MBLK_BUCKET[6]]
= 2
ppi[1].meters[EXPAND_MBLK_BUCKET[7]]
= 1
ppi[1].meters[EXPAND_MBLK_BUCKET[8]]
= 5221
ppi[1].meters[EXPAND_MBLK_BUCKET[9]]
= 30
ppi[1].meters[ALLOC_MBLK_CHUNK]
= 38
ppi[1].meters[UNBUFCALL_CALLS]
= 130210
The analyze_system Command and Requests
8-281
dump_stream
ppi[1].meters[CROSS_POOL_FREES]
ppi[1].meters[MSGPULLUP_CALLS]
= 2039
= 59335
Example 2
The following request dumps information about all STREAMS drivers from the device
table driver, as well as nonzero per-driver totals for the SQH meters
as: dump_stream -driver_table
Streams sth stream head @ C156BD00 (modsw @ C15BFF00):
modsw_sq_level
SQLVL_QUEUEPAIR
modsw_disable_ints
no interrupts disabled
modsw_desc
Stream Head.
modsw_meters[SQ_PUT MISS] 41
modsw_meters[CSQ_ACQUIRE_AND_WAIT_SPIN] 142
modsw_meters[FINISH_STREAMS_INT_QUICK_MISS] 1
modsw_meters[FINISH_STREAMS_INT_HANDOFF] 30
modsw_meters[DRAIN_WORK_Q_QUICK_MISS] 5
modsw_meters[DRAIN_WORK_Q_HANDOFF] 15
modsw_meters[DRAIN_WORK_Q_HO_DRAIN] 7
modsw_meters[Q_FLOW_ON]
3720
Streams log driver @ C1565D00 (modsw @ C156BF00):
modsw_sq_level
SQLVL_QUEUE
modsw_disable_ints
no interrupts disabled
modsw_desc
Driver to read strlog output from.
Streams telnet driver @ C17F3880 (modsw @ C17F3780):
modsw_sq_level
SQLVL_QUEUE
modsw_disable_ints
no interrupts disabled
modsw_desc
OS Telnet Streams Driver
Streams hrsd driver @ C17F3D40 (modsw @ C17F3C40):
modsw_sq_level
SQLVL_QUEUEPAIR
modsw_disable_ints
no interrupts disabled
modsw_desc
Host Remote Streams Driver for IOAs
Streams ip driver @ C1865340 (modsw @ C1865240):
SQLVL_QUEUE
modsw_disable_ints
no interrupts disabled
modsw_desc
STCP ip
modsw_meters[SQ_PUTNEXT_MISS] 2244
modsw_meters[FINISH_STREAMS_INT_QUICK_MISS] 13
modsw_meters[FINISH_STREAMS_INT_HANDOFF] 863
modsw_meters[DRAIN_WORK_Q_QUICK_MISS] 179
modsw_meters[DRAIN_WORK_Q_HANDOFF] 337
modsw_meters[DRAIN_WORK_Q_HO_DRAIN] 43
8-282
VOS System Analysis Manual (R073)
modsw_sq_level
dump_stream
Streams loop driver @ C1867700 (modsw @ C1867600):
SQLVL_MODULE
modsw_disable_ints
no interrupts disabled
modsw_desc
LOOPBACK Driver below IP
modsw_meters[SQ_PUT MISS] 462
modsw_meters[DRAIN_WORK_Q_QUICK_MISS] 5
modsw_meters[DRAIN_WORK_Q_HANDOFF] 299
modsw_meters[DRAIN_WORK_Q_HO_DRAIN] 31
modsw_sq_level
Streams raw module @ C1868D00 (modsw @ C1868C00):
modsw_sq_level
SQLVL_MODULE
modsw_disable_ints
no interrupts disabled
modsw_desc
Raw module provides raw access to IP
Streams udp driver @ C18695C0 (modsw @ C18694C0):
SQLVL_QUEUE
modsw_disable_ints
no interrupts disabled
modsw_desc
STCP udp
modsw_meters[SQ_PUTNEXT_MISS] 3666
modsw_meters[FINISH_STREAMS_INT_HANDOFF] 2
modsw_meters[DRAIN_WORK_Q_QUICK_MISS] 204
modsw_meters[DRAIN_WORK_Q_HANDOFF] 2591
modsw_meters[DRAIN_WORK_Q_HO_DRAIN] 56
modsw_sq_level
Streams stcp driver @ C186BD00 (modsw @ C186BC00):
SQLVL_QUEUE
modsw_disable_ints
no interrupts disabled
modsw_desc
STCP tcp
modsw_meters[SQ_PUTNEXT_MISS] 5443
modsw_meters[FINISH_STREAMS_INTERRUPT_MISS] 1
modsw_meters[FINISH_STREAMS_INT_QUICK_MISS] 7
modsw_meters[FINISH_STREAMS_INT_HANDOFF] 480
modsw_meters[DRAIN_WORK_Q_QUICK_MISS] 41
modsw_meters[DRAIN_WORK_Q_HANDOFF] 2968
modsw_meters[DRAIN_WORK_Q_HO_DRAIN] 90
modsw_meters[Q_FLOW_ON]
15
modsw_sq_level
Streams tpipe driver @ C18CA7C0 (modsw @ C18CA6C0):
modsw_sq_level
SQLVL_MODULE
modsw_disable_ints
no interrupts disabled
modsw_desc
Telnet pipe driver
Streams timod module @ C18CF8C0 (modsw @ C18CF7C0):
modsw_sq_level
SQLVL_QUEUEPAIR
modsw_disable_ints
no interrupts disabled
modsw_desc
Streams TLI Module
The analyze_system Command and Requests
8-283
dump_stream
Streams lat_st driver @ C18E3600 (modsw @ C18E3500):
modsw_sq_level
SQLVL_QUEUEPAIR
modsw_disable_ints
ur uw
modsw_desc
Window Term to TLI Multiplexor
Streams tli_term driver
modsw_sq_level
modsw_disable_ints
modsw_desc
modsw_meters[Q_FLOW_ON]
@ C18E3BC0 (modsw @ C18E3AC0):
SQLVL_QUEUEPAIR
ur uw
Window Term to TLI Multiplexor
535
Streams ad driver @ C1EC3940 (modsw @ C1EC3840):
modsw_sq_level
SQLVL_QUEUE
modsw_disable_ints
no interrupts disabled
modsw_desc
DLPI interface for DLMUX
modsw_meters[SQ_CHECK_AND_PUTNEXT MISS] 18375
modsw_meters[FINISH_STREAMS_INT_HANDOFF] 14
modsw_meters[DRAIN_WORK_Q_HANDOFF] 1
modsw_meters[Q_FLOW_ON]
14
Streams adp module @ C1EC5680 (modsw @ C1EC5580):
SQLVL_QUEUE
modsw_disable_ints
no interrupts disabled
modsw_desc
DLPI conversion MODULE
modsw_sq_level
Streams arp module @ C1EC5F00 (modsw @ C1EC5E00):
SQLVL_QUEUE
modsw_disable_ints
no interrupts disabled
modsw_desc
STCP ARP MODULE
modsw_sq_level
Streams sosl_net_driver
modsw_sq_level
modsw_disable_ints
modsw_desc
8-284
driver @ C1908200 (modsw @ C1908980):
SQLVL_QUEUE
no interrupts disabled
STCP OSL mux
Streams dkhs driver @ C191A0C0 (modsw @ C1919FC0):
SQLVL_MODULE
modsw_disable_ints
ur uw lr lw
modsw_desc
Datakit DKHS Driver
modsw_meters[HIT_DISABLED_INTERRUPT] 272
modsw_meters[PUTBQ_IN_UNLOCKED_CONTEXT **] 4657
modsw_sq_level
Streams dkux module @ C191A800 (modsw @ C191A700):
SQLVL_MODULE
modsw_disable_ints
no interrupts disabled
modsw_desc
Datakit DKUX Module
modsw_sq_level
VOS System Analysis Manual (R073)
dump_stream
Streams dkbk module @ C191B840 (modsw @ C191B740):
SQLVL_MODULE
modsw_disable_ints
no interrupts disabled
modsw_desc
Datakit DKBK Module
modsw_sq_level
Streams dkxqt driver @ C19254C0 (modsw @ C19253C0):
modsw_sq_level
SQLVL_MODULE
modsw_disable_ints
no interrupts disabled
modsw_desc
Datakit DKXQT Driver
Streams dkty_al driver @ C1925CC0 (modsw @ C1925BC0):
modsw_sq_level
SQLVL_QUEUE
modsw_disable_ints
ur uw
modsw_desc
Datakit Terminal Access Driver
Streams tnmod module @ C1765F40 (modsw @ C1765340):
modsw_sq_level
SQLVL_QUEUE
modsw_disable_ints
no interrupts disabled
modsw_desc
STCP telnet module
Example 3
The following two requests set the amount of each buffer to display and then display
information about a specific STREAMS message.
as: dump_stream -msg_dump_size 32
as: dump_stream -msg C0939180
mp->b_next
00000000
mp->b_prev
00000000
mp->b_cont
C0942500
mp->b_rptr
C0945080
mp->b_wptr
C09450A8
mp->b_datap
C09391BC
mp->b_band
0
mp->b_flag
0000x
mp->b_driver_private
00000000x
mp->datap->db_base
C0945080
mp->datap->db_lim
C09450C0
mp->datap->db_ref
1
mp->datap->db_type
M_IOCTL
mp->datap->db_size
64
mhp->vmh.hdr_type
STD_HDR
mhp->vmh.mh_ref_cnt
1
mhp->vmh.mh_caller
sthi+4B7D, line 3149
mhp->mh_allocp
C0939000
The analyze_system Command and Requests
8-285
dump_stream
mhp->vmh.mh_bucket_no
1
mhp->vmh.mh_q_qinfo
00000000
C0945080 000 0000741E C24BF9B8 00000058 00000020 |..t..K....X....|
C0945090 010 00000000 00000000 06C66420 0B15E3E3 |..........d ....|
Example 4
The following request is the same as the one in Example 3, except that it displays more
information in the buffer.
as: dump_stream -msg_dump_size 128
as: dump_stream -msg C0939180
mhp->b_next
00000000
mp->b_prev
00000000
mp->b_cont
C0942500
mp->b_rptr
C0945080
mp->b_wptr
C09450A8
mp->b_datap
C09391BC
mp->b_band
0
mp->b_flag
0000x
mp->b_driver_private
00000000x
mp->datap->db_base
C0945080
mp->datap->db_lim
C09450C0
mp->datap->db_ref
1
mp->datap->db_type
M_IOCTL
mp->datap->db_size
64
mhp->vmh.hdr_type
STD_HDR
mhp->vmh.mh_ref_cnt
1
mhp->vmh.mh_caller
sthi+4B7D, line 3149
mhp->mh_allocp
C0939000
mhp->vmh.mh_bucket_no
1
mhp->vmh.mh_q_qinfo
00000000
C0945080 000 0000741E C24BF9B8 00000058 00000020 |..t..K.....X... |
C0945090 010 00000000 00000000 06C66420 0B15E3E3 |..........d ....|
C09450A0 020 50184000 3C290000
|P.@.<)..
|
Example 5
The following request displays a specific STREAMS queue head.
as:
dump_stream -sqh C162E9B0
SQH = C162E9B0
SQH_NEXT
SQH_PREV
SQH_FIRST
SQH_LAST
sqh_vos_lock
508)
sqh_refcnt
sqh_meterp
8-286
VOS System Analysis Manual (R073)
=
=
=
=
=
00000001
00000001
00000001
00000001
C0DD3C80 (locked by interrupt in process
= 1
= C159F100
dump_stream
sqh_disable_interrupts
sqh_sq_list_status_flags
sqh_cpu_locked
= 0
= 00x
= -32
Example 6
The following request displays information from a STREAMS porte.
as: dump_porte -number 11
PORT 11 at C0E92100
Portname:
_aaaboaaaanObCWdN
Pathname:
%sq#stcp.st52_1
Type:
streams
Flags:
attached,open
Access mode:
sequential
I/O type:
streams delay
process_id:
2A0C8035
info_ptr:
C0E8D500
dvtep:
C0E91600
port_id:
11
user_info_ptr:
00000001
forms_info_ptr:
00000001
tv:
99 (Open Stream)
user_tv:
99 (Open Stream)
tasking_info_ptr: 7FFA9F20 accounting_info_ptr: 00000001 time_limit:
-1
conflict_count:
0
character_set:
none
shift_mode:
none
pte_ptr:
C1864B00
amte_ptr:
00000001
tv_driver_tep:
00000001
DEVICE = C0E8D500
read_osrp
=
write_osrp
=
ioctl_osrp
=
poll_osrp
=
close_osrp
=
read_peekp
=
write_peekp
=
sth_ptr
=
STH = C18CE800
sth_flags
sth_polls
sth_read_mode
sth_write_mode
sth_close_wait_timeout
C18CBB80
C18CE000
C18CE180
C18CE300
C18CE500
C18CB540
C18CB580
C18CE800
=
=
=
=
=
00000000x
C18E45C0
17
1
15000
The analyze_system Command and Requests
8-287
dump_stream
sth_rq
= C18CE8C0
sth_wq
= C18CE960
sth_dev
= 00BC0001x
sth_ref_cnt
= 1
sth_dvtx
= 1727 (stcp.st52_1)
STH_POLLS = C18E45C0
next
= 00000000
prev
= 00000000
ps_sth
= C18CE800
ps_osr
= C18CC1C0
ps_events
= 0003x (POLLIN POLLPRI)
DUMPING QUEUE PAIRS FOR EACH MODULE/DRIVER
QUEUE Name:
sth
WRITE SIDE
QUEUE = C18CE960
q_qinfo
= C082D2B8
q_driver_tep = 00000000
q_next
= C18D05A0
q_ptr
= C18CE800
q_sqh_ptr = C18CE930
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 2048
q_lowat
= 1024
q_qlock
= C0FBEA20
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 10x
QSAMESTR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
NEXT LEVELS QUEUES
8-288
VOS System Analysis Manual (R073)
READ SIDE
QUEUE = C18CE8C0
q_qinfo
= C082D2F8
q_driver_tep = 00000000
q_next
= 00000000
q_ptr
= C18CE800
q_sqh_ptr = C18CE930
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 8191
q_lowat
= 6143
q_qlock
= C0FBE9E0
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 01x
QREADR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
dump_stream
QUEUE Name:
mi_timod
WRITE SIDE
QUEUE = C18D05A0
q_qinfo
= D33E9018
q_driver_tep = C18CF8C0
q_next
= C18CEBE0
q_ptr
= C18D06C0
q_sqh_ptr = C18D0570
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 2048
q_lowat
= 128
q_qlock
= C0FBEEA0
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 10x
QSAMESTR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
NEXT LEVELS QUEUES
QUEUE Name:
stcp
WRITE SIDE
QUEUE = C18CEBE0
q_qinfo
= D337E818
q_driver_tep = C186BD00
q_next
= 00000000
q_ptr
= C18CEDC0
q_sqh_ptr = C18CEC50
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 98304
q_lowat
= 2048
READ SIDE
QUEUE = C18D0500
q_qinfo
= D33E9068
q_driver_tep = C18CF8C0
q_next
= C18CE8C0
q_ptr
= C18D06C0
q_sqh_ptr = C18D0570
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 2048
q_lowat
= 128
q_qlock
= C0FBEE60
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 11x
QREADR set
QSAMESTR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
READ SIDE
QUEUE = C18CEB40
q_qinfo
= D337E8A8
q_driver_tep = C186BD00
q_next
= C18D0500
q_ptr
= C18CEDC0
q_sqh_ptr = C18CEBB0
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 98304
q_lowat
= 2048
The analyze_system Command and Requests
8-289
dump_stream
q_qlock
= C0FBEB20
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 00x
q_qlock
= C0FBEAE0
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 11x
QREADR set
QSAMESTR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
q_wantr set
Q Locked?
no
Svc Scheduled? no
Enabled kernel entries:
as_check_kel: KEL.n_entries = 1476, actual = 1537
close:
line 1824 in module vos_pse
read_raw:
line 2006 in module vos_pse
write_raw:
line 2068 in module vos_pse
set_no_wait_mode:
line 4316 in module vos_pse
set_wait_mode:
line 4357 in module vos_pse
start_logging:
line 1424 in module io_routines
stop_logging:
line 1574 in module io_routines
read_device_event:
line 1975 in module vos_pse
get_port_attachment: line 496 in module io_routines
get_port_status:
line 703 in module io_routines
get_port_info:
line 785 in module io_routines
getmsg:
line 2463 in module vos_pse
putmsg:
line 2525 in module vos_pse
poll:
line 3119 in module vos_pse
ioctl_str:
line 3427 in module vos_pse
peek:
line 2930 in module vos_pse
fdinsert:
line 3004 in module vos_pse
getpmsg:
line 2766 in module vos_pse
putpmsg:
line 2835 in module vos_pse
Enabled user entries:
8-290
VOS System Analysis Manual (R073)
dump_stream
close:
read_raw:
write_raw:
set_no_wait_mode:
set_wait_mode:
start_logging:
stop_logging:
read_device_event:
get_port_attachment:
get_port_status:
set_tasking_mode:
get_port_info:
set_io_time_limit:
poll:
ioctl_str:
peek:
fdinsert:
getpmsg:
putpmsg:
line 5295 in module iotv
s$k_read_raw (kernel_trap_pa+17B38)
s$k_write_raw (kernel_trap_pa+266D0)
line 1294 in module io_routines
line 1366 in module io_routines
s$k_start_logging (kernel_trap_pa+20BE4)
s$k_stop_logging (kernel_trap_pa+212A0)
s$k_read_device_event (kernel_trap_pa+16FF8)
s$k_get_port_attachment (kernel_trap_pa+C8D8)
s$k_get_port_status (kernel_trap_pa+CCD4)
line 1364 in module io_routines
line 553 in module io_routines
line 1213 in module io_routines
s$k_poll (kernel_trap_pa+314)
s$k_str (kernel_trap_pa+54C)
s$k_peek (kernel_trap_pa+DE0)
s$k_fdinsert (kernel_trap_pa+FC0)
s$k_getpmsg (kernel_trap_pa+BE0)
s$k_putpmsg (kernel_trap_pa+858)
Example 7
The following request displays a specific OSR.
as: dump_stream -osr C18CBB80
STH_OSR = C18CBB80
BEGINNING of OSR_SQ structure
SQ_NEXT
= 00000001
SQ_PREV
= 00000001
sq_type
= SQ_NOTIFY
sq_queue_time
= 00000000x
resume_process_ptep(C1864B00, 0)
END of OSR_SQ structure
osr is not queued
osr_sth
osr_ret_val
osr_err
osr_callback
osr_flags
osr_finished
osr_state
osr_istate
osr_creds.cr_uid
osr_creds.cr_gid
osr_creds.sd_infop
=
=
=
=
=
=
=
=
=
=
=
C18CE800
0
0
sthi+2878, line 1344
00000000x
TRUE
0
0
0
0
00000000
The analyze_system Command and Requests
8-291
dump_stream
osr_bufcall_id
osr_type
Read OSR Begin
osr_rw_total
osr_rw_flags
osr_rw_oia_argp
osr_rw_oia_len
osr_ioctl_arg1
osr_ioctl_arg1_len
osr_ioctl_arg2
osr_ioctl_arg2_len
Read OSR End
osr_time_limit
osr_xtrap
osr_copy_mp
osr_devp
osr_sqhp
osr_dfreeq
osr_ref_count
osr_wait_lock
osr_acquires.num
= 00000000x
= READ
=
=
=
=
=
=
=
=
0000740Fx
00000000x
C18CB540x
00000000x
000503A4x
00000000x
00000001x
00000000x
=
=
=
=
=
=
=
=
=
never
00000000
00000000
C0E8D500
C18CE930
00000000
0
C0FBE320 (unlocked)
0
STH = C18CE800
sth_flags
= 00000000x
sth_read_osr_q @ C18CE804 is empty.
sth_write_osr_q @ C18CE810 is empty.
sth_ioctl_osr_q @ C18CE81C is empty.
sth_ioc_id
= 00000000x
sth_iocblk_id
= 23
sth_polls
= C18E45C0
BEGINNING of STH_CTTY_SIGS structure
ss_link
= 00000000
ss_procid
= 00000000x
ss_mask
= 00000000x
END of STH_CTTY_SIGS structure
sth_read_mode
sth_write_mode
sth_close_wait_timeout
sth_next
sth_rq
sth_wq
sth_dev
sth_ref_cnt
sth_dvtx
sth_any_pse_mods_pushed
sth_drv_priv
8-292
=
=
=
=
=
=
=
=
=
=
=
17
1
15000
C186B400
C18CE8C0
C18CE960
00BC0001x
1
1727 (stcp.st52_1)
1
0
VOS System Analysis Manual (R073)
dump_stream
STH_POLLS = C18E45C0
next
prev
ps_sth
ps_osr
ps_events
=
=
=
=
=
00000000
00000000
C18CE800
C18CC1C0
0003x (POLLIN POLLPRI)
DUMPING QUEUE PAIRS FOR EACH MODULE/DRIVER
QUEUE Name:
sth
WRITE SIDE
READ SIDE
QUEUE = C18CE960
QUEUE = C18CE8C0
q_qinfo
= C082D2B8
q_driver_tep = 00000000
q_next
= C18D05A0
q_ptr
= C18CE800
q_ffcp
= C18CEBE0
q_bfcp
= 00000000
q_sqh_ptr = C18CE930
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 2048
q_lowat
= 1024
q_qlock
= C0FBEA20
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 10x
QSAMESTR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
q_qinfo
= C082D2F8
q_driver_tep = 00000000
q_next
= 00000000
q_ptr
= C18CE800
q_ffcp
= 00000000
q_bfcp
= C18CEB40
q_sqh_ptr = C18CE930
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 8191
q_lowat
= 6143
q_qlock
= C0FBE9E0
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 01x
QREADR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
START OF SQH STRUCT
SQH = C18CE930
The analyze_system Command and Requests
8-293
dump_stream
SQH_NEXT
= 00000001
SQH_PREV
= 00000001
SQH_FIRST
= 00000001
SQH_LAST
= 00000001
sqh_vos_lock
= C0FBE960 (unlocked)
sqh_refcnt
= 1
sqh_meterp
= C15BFF40
sqh_disable_interrupts = 0
sqh_sq_list_status_flags = 00x
sqh_cpu_locked
END OF SQH STRUCT
NEXT LEVELS QUEUES
QUEUE Name:
mi_timod
WRITE SIDE
QUEUE = C18D05A0
q_qinfo
= D33E9018
q_driver_tep = C18CF8C0
q_next
= C18CEBE0
q_ptr
= C18D06C0
q_ffcp
= C18CEBE0
q_bfcp
= C18CE960
q_sqh_ptr = C18D0570
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 2048
q_lowat
= 128
q_qlock
= C0FBEEA0
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 10x
QSAMESTR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
8-294
VOS System Analysis Manual (R073)
= -64
READ SIDE
QUEUE = C18D0500
q_qinfo
= D33E9068
q_driver_tep = C18CF8C0
q_next
= C18CE8C0
q_ptr
= C18D06C0
q_ffcp
= C18CE8C0
q_bfcp
= C18CEB40
q_sqh_ptr = C18D0570
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 2048
q_lowat
= 128
q_qlock
= C0FBEE60
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 11x
QREADR set
QSAMESTR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
dump_stream
START OF SQH STRUCT
SQH = C18D0570
SQH_NEXT
= 00000001
SQH_PREV
= 00000001
SQH_FIRST
= 00000001
SQH_LAST
= 00000001
sqh_vos_lock
= C0FBEC60 (unlocked)
sqh_refcnt
= 1
sqh_meterp
= C18CF800
sqh_disable_interrupts = 0
sqh_sq_list_status_flags = 00x
sqh_cpu_locked
= -64
END OF SQH STRUCT
NEXT LEVELS QUEUES
QUEUE Name:
stcp
WRITE SIDE
QUEUE = C18CEBE0
q_qinfo
= D337E818
q_driver_tep = C186BD00
q_next
= 00000000
q_ptr
= C18CEDC0
q_ffcp
= 00000000
q_bfcp
= C18CE960
q_sqh_ptr = C18CEC50
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 98304
q_lowat
= 2048
q_qlock
= C0FBEB20
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 00x
READ SIDE
QUEUE = C18CEB40
q_qinfo
= D337E8A8
q_driver_tep = C186BD00
q_next
= C18D0500
q_ptr
= C18CEDC0
q_ffcp
= C18CE8C0
q_bfcp
= 00000000
q_sqh_ptr = C18CEBB0
q_minpsz = 0
q_maxpsz = -1
q_hiwat
= 98304
q_lowat
= 2048
q_qlock
= C0FBEAE0
Mblk Q Locked? no
q_bandp
= 00000000
q_nbands = 0
q_mem_pool = 0
q_frozen = 0
q_sq_full = 0
q_deferred_put_count = 0
q_first
= 00000000
q_last
= 00000000
q_count
= 0
q_noenb
= 0
q_wantr
= 1
q_full
= 0
q_flag
= 11x
QREADR set
The analyze_system Command and Requests
8-295
dump_stream
q_wantr set
Q Locked?
no
Svc Scheduled? no
START OF SQH STRUCT
SQH_NEXT = 00000001
SQH_PREV = 00000001
SQH_FIRST = 00000001
SQH_LAST = 00000001
sqh_vos_lock = C0FBEAA0
sqh_refcnt = 1
sqh_meterp = C186BC40
disable ints = 0
sq_list_status_flags = 00x
sqh_cpu_locked = -64
END OF SQH STRUCT
QSAMESTR set
q_wantr set
Q Locked?
no
Svc Scheduled? no
SQH_NEXT = 00000001
SQH_PREV = 00000001
SQH_FIRST = 00000001
SQH_LAST = 00000001
sqh_vos_lock = C0FBEA60
sqh_refcnt = 1
sqh_meterp = C186BC40
disable ints = 0
sq_list_status_flags = 00x
sqh_cpu_locked = -64
Related Information
See the description of the search_streams request. For more information on VOS
STREAMS, see the VOS Communications Software: STREAMS Programmers
Guide (R306) and the IOA STREAMS Programmers Guide (R341).
8-296
VOS System Analysis Manual (R073)
dump_streams
dump_streams
8-
Purpose
The dump_streams request is a synonym for the previously described dump_stream
request.
The analyze_system Command and Requests
8-297
dump_syserr
dump_syserr
8-
Purpose
This request displays a buffer containing the most recent system error messages.
Display Form
----------------------------------- dump_syserr --------------------------------all: n o
-last:
-long: no
Command-Line Form
dump_syserr
[-all]
[-last number]
[-long ]
Arguments
* -all
<CYCLE>
Displays all of the system error messages in the buffer. If you omit this argument,
only active messages are is displayed. Active messages are those that have not
been written to the syserr_log file. Free messages are messages that are being
stored in the buffer. You cannot specify both this argument and the -last
argument.
* -last number
Displays the last number error messages from the buffer that you request. It will
also display the last number of messages that have not yet been written to the
syserr_log file. You cannot specify both this argument and the -all argument.
* -long
<CYCLE>
Displays the addresses messages in the buffer. By default, this information is not
displayed.
8-298
VOS System Analysis Manual (R073)
dump_syserr
Explanation
The dump_syserr request is particularly useful for examining the messages that
occurred just before a system failure from a dump file.
When the request is issued with no arguments, the output summarizes the message
activity. The logged messages total is the number logged since the last reboot of the
module. Lost messages are messages that are lost because the buffer could not hold
the messages until they could be written to disk.
The output displayed with either argument shows, for each error message, the time
when the error occurred and the error message.
Examples
In the following example, the dump_syserr request displays a summary of message
activity.
as:
dump_syserr
0 active messages, 756 free.
Total of 227326 logged messages.
Total of 0 lost messages.
as:
In the following example, the dump_syserr request displays a summary of message
activity and a list of the last 10 error messages. The request also displays the last 10
messages that are not yet written to the syserr_log file.
as:
dump_syserr -last 10
11 active messages, 1431 free.
Total of 715169 logged messages.
Total of 0 lost messages.
Messages from free list:
15:36:37 Process
terminated.
15:37:03 Process
created.
15:37:10 Process
terminated.
15:37:34 Process
created.
15:37:42 Process
terminated.
15:38:13 Process
created.
15:38:22 Process
terminated.
0109891E, Overseer.System (Os.src_ctrl4F2A.0825153622BA),
0109891F, Overseer.System (Os.src_ctrl4F2A.082515370348),
0109891F, Overseer.System (Os.src_ctrl4F2A.082515370348),
01098920, Overseer.System (Os.src_ctrl4F2A.08251537346E),
01098920, Overseer.System (Os.src_ctrl4F2A.08251537346E),
01098921, Overseer.System (Os.src_ctrl4F2A.0825153813AF),
01098921, Overseer.System (Os.src_ctrl4F2A.0825153813AF),
The analyze_system Command and Requests
8-299
dump_syserr
15:38:46 Process 01098922, Overseer.System (Os.src_ctrl4F2A.082515384673),
created.
15:38:53 Process 01098922, Overseer.System (Os.src_ctrl4F2A.082515384673),
terminated.
15:40:59 Process 01098923, Suzanne_Ryan.Publications (login), created.
Messages from active list:
07:34:54 tape 2202i 04/03/01/06
0 00000000 00000000 restored
07:34:54 tape 2202i 04/02/01/06
0 00000000 00000000 restored
07:34:55 disk 2202i 04/01/01/01 EEEEE 00000000 00000000 restored
07:35:10 bbc 8 add
forcing dual initiation
07:35:17 disk 2202i 06/01/01/01 EEEEE 00000000 00000000 restored
07:35:17 tape 2202i 06/03/01/06
0 00000000 00000000 restored
07:35:22 disk 0002i 06/01/01/03 EEEEE 00000000 00000015 device
07:35:22 tape 0002i 06/01/01/06
0 00000000 00000015 device
07:35:34 disk 0002i 04/04/01/05 EEEEE 00000000 00000015 device
07:35:41 tape 0002i 06/02/01/06
0 00000000 00000015 device
as:
8-300
VOS System Analysis Manual (R073)
to service
to service
to service
to service
to service
present
present
present
present
dump_tcb
dump_tcb
8-
Purpose
This request displays information for devices with device type terminal about the
terminal control block (TCB), which is a data structure used by asynchronous
communications software to manage one channel.
Display Form
------------------------------------ dump_tcb ---------------------------------channel_name:
-address:
-echo_table:
no
-enable_auto_echo: no
Command-Line Form
dump_tcb channel_name
[-address address]
[-echo_table]
[-enable_auto_echo]
Arguments
* channel_name
The name of the asynchronous channel whose terminal control block you want
information about. Do not include the number sign (#) in the channel name. You
cannot specify both this argument and the -address argument.
* -address address
The address of the terminal control block that you want information about. (For
information on address formats, see Chapter 3.) You cannot specify both this
argument and the channel_name argument.
* -echo_table
<CYCLE>
If an echo table structure exists, the output shows the address of the echo table
structure in the echo_table_ptr field, and displays the structure. If this
The analyze_system Command and Requests
8-301
dump_tcb
argument is not specified, or an echo table structure does not exist, the output
shows only a null pointer (00000001) in the echo_table_ptr field.
* -enable_auto_echo
<CYCLE>
If an enable auto echo structure exists, the output shows the address of the enable
auto echo structure in the enable_auto_echo_ptr field, and displays the
structure. If this argument is not specified, or an enable auto echo structure does
not exist, the output shows only a null pointer (00000001) in the
enable_auto_echo_ptr field.
Explanation
The dump_tcb request displays information for devices with device type terminal
about the terminal control block, which is a data structure used by asynchronous
software to manage one channel.
To obtain a value for channel_name, issue the list_port_attachments,
dump_tcbh, or dump_channels request, or the list_devices command. This
command is documented in the VOS Commands Reference Manual (R098).
Examples
In the following example, the dump_tcb request displays information about the
terminal control block for channel term.23.43.
as: dump_tcb term.23.43
process ID
01132A14
num input buffers
2
num output buffers
1
num col'n buffers
2
conflict count
2
channel number
11
slot index
2
slot number
4
current line
1
current line byte size
0
chars_to_echo
0
echoed_chars
0
status:
80400000 0000 0000 00
listening
initial_string_sent
number of tabs
25
modes
00080302
interrupt_key_enabled
display_enable
break_enabled
output_flow
output queued
0
....
next char to take
1
8-302
VOS System Analysis Manual (R073)
dump_tcb
flow on char
''
flow off char
''
tab columns
6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91
96 101 106 111 116 121 126
pause lines
23
cur n lines
1
kill column
0
kill line
23
prompt chars
''
continue chars
'+'
pause chars
'--PAUSE--'
first input buffer
004CD280
last input buffer
004CE706
first col'n buffer
0062FBA0
cur col'n buffer
0062FBA0
last col'n buffer
006095E4
first active buffer
00000001
last active buffer
00000001
first inact buffer
00000001
last inact buffer
00000001
first echo buffer
004CEE12
last echo buffer
004CEE12
forms pointer
00000001
forms text ptr
00000001
forms values ptr
00000001
field number
0
code
0
dwi.cur_char
0
dwi.cur_size
0
dwi.display_width
11111111111111111111111111110000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
old page faults
0
input tally
30
cur field byte offset
0
input line cb ptr
005FBC92
command line cb ptr
0062CC3E
line state
dialed
redisplay column
0
open count
1
clean point offset
0000
clean point ptr
00000001
dsl interrupts
2
min collections
2
max collections
10
Break table:
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
break_effect
0
protocol_ptr
00000001
protocol_count
0
The analyze_system Command and Requests
8-303
dump_tcb
form_buffer_size
echo buffers queued
top_window_size
top_window_line
top_window_column
queued chars
next queued char
char queue
type queue
form_abs_segs
# of wired pages
0
0
0
0
0
0
1
''
''
0
0000
0000
0000
0000
0000 0000 0000
rfi_offset
text_offset
values_offset
No error timeout
timers
45,0,0,47,0,0
No runout deadline
No hangup deadline
forms porte ptr
00000001
config_data:
baud
19200
stop_bits
1
parity
odd
lang info ptr
00552234
echo_table_ptr
00000001
enable_auto_echo_ptr
00000001
init_cursor_row
0
notify_if_zero
0
fsi.config_info.ttep
001FBEE4
fsi.config_info.current_config
0
fsi.config_info.current_input_section
0
fsi.config_info.last_col
79
fsi.config_info.last_line
23
fsi.config_info.last_page
1
fsi.config_info.escape character
ascii/60
fsi.config_info.cursor format
steady block
fsi.config_info.position_seq_len
7
fsi.config_info.clear_mult_chars_len
64
fsi.config_info.clear_eol_len
2
fsi.config_info.supported_attrs
005F (, standout, dim,
underline, reverse, blink, blank)
fsi.config_info.blank_sig_mode_attrs
0050 (, standout, dim)
fsi.config_info.blank_sig_cleared_modes
0000
fsi.config_info.config_flags:
FBE0FC00
fsi.config_info.up_supported
fsi.config_info.down_supported
fsi.config_info.left_supported
fsi.config_info.right_supported
fsi.config_info.position_cursor_supported
fsi.config_info.has_clear_to_eor
8-304
VOS System Analysis Manual (R073)
dump_tcb
fsi.config_info.has_clear_to_eol
fsi.config_info.delete_chars_supported
fsi.config_info.insert_chars_supported
fsi.config_info.insert_mode_supported
fsi.config_info.home_cursor_supported
fsi.config_info.move_horizontal_supported
fsi.config_info.move_vertical_supported
fsi.config_info.delete_lines_supported
fsi.config_info.insert_lines_supported
fsi.config_info.can_move_cursor
fsi.config_info.output_cap_flags:
80000000
fsi.out_state.page
0
fsi.out_state.reserved
0
fsi.out_state.cp.valid_flags:
0000
fsi.out_state.cp.flags:
0000
....
fsi.archaic_flags:
0000
fsi.lines since pause
0
fsi.saved_input_bytes
''
working_kill_line
23
working_kill_column
0
as:
The following table describes some important fields that appear in the output of the
preceding example.
(Page 1 of 3)
Fields
Description
process ID
The ID of the process, if any, that is currently using the
asynchronous channel
escape character
The character used to enter and display control
characters at command level or in forms. On input, it
forces the next character to be processed without any
translation. On output, it prefixes each byte of
hexadecimal output. This can be set with VOS command
set_terminal_parameters, documented in the VOS
Commands Reference Manual (R098).
modes
Displays the names of the mode bits that are on. The
bits are first shown in hexadecimal format and then are
listed. There are 32 possible bits, and they can be set by
an application program.
flow on char and
The characters that the channel hardware uses for flow
control
flow off char
pause lines,
The number of lines displayed before you see the
-pause- message
The analyze_system Command and Requests
8-305
dump_tcb
(Page 2 of 3)
8-306
Fields
Description
prompt chars,
continue chars,
and pause chars
Character strings that VOS will use for prompting,
displaying long lines, and pausing after a full screen of
output. These can be set with VOS command
set_terminal_parameters, documented in the VOS
Commands Reference Manual (R098).
ttep
Pointer to the terminal type currently in use. Use the
dump_tte -address request to view the terminal type
entry.
line state
Indicates if the line is dialed (full connection), hung up
(broken connection), or if a listen is active. Dialed = 2;
listen = 1; hungup = 0.
open count
The number of open ports attached to this
asynchronous channel
dsl interrupts
The number of data set lead interrupts
Break table
Which of the 128 ASCII characters are break characters.
In any of the four areas of characters, a 1 bit indicates a
break character, and a 0 bit indicates a non-break
character.
config_data
The line configuration currently in use
echo_table_ptr
The address of the echo table structure used by echo
negotiation
enable_auto_echo_ptr
The address of the enable auto echo structure used by
echo negotiation
current line
The current relative line number (for wrapped lines)
current line byte size
The number of bytes in the current line
cur n lines
The number of lines for the current input line. (Could be
wrapped).
forms pointer
The pointer to the rfi structure (read_form_info)
which is used by FMS.
cur field byte offset
The current byte offset in the input line (zero based).
fsi.config_info.ttep
The pointer to the terminal type currently in use. The fsi
information describes your terminal, the size of the
screen, the cursor location, the cursor format, output
sequences that are supported, national language
support information, and the terminal type in use.
VOS System Analysis Manual (R073)
dump_tcb
(Page 3 of 3)
Fields
Description
fsi.config_info.last_co
l
The last column number. Width is last_col+1.
fsi.config_info.last_li
ne
The last line number. Height is last_line+1.
fsi.config_info.escap
character
The character used to enter and display control
characters at command level or in forms. On input, it
forces the next character to be processed without any
translation. On output, it prefixes each byte of
hexadecimal output. This can be set with VOS command
set_terminal_parameters, documented in the VOS
Commands Reference Manual (R098).
fsi.out_state.cp.line
The current line number for the cursor
fsi.out_state.cp.column
The current column number for the cursor
In the following example, the dump_tcb request displays information about echo
negotiation. This is typically seen only when using the edit text editor.
as:
dump_tcb term.23.43 -echo_table -enable_auto_echo
echo_table_ptr
006C534A
echo_table.version 1
echo_table.characters(0)
echo_table.characters(1)
echo_table.characters(2)
....
echo_table.characters(255)
echo_table.sequences(0)
echo_table.sequences(1)
....
as:
0
0
0
0
0
0
Related Information
Use the dump_comm_buffers request to display the contents of the data buffers. The
dump_comm_buffers channel_name -data request displays the input and output
I/O blocks, and any input collection buffers for the channel. For more information, see
the manual VOS Communications Software: Asynchronous Communications (R025).
The analyze_system Command and Requests
8-307
dump_tcbh
dump_tcbh
8-
Purpose
This request displays the terminal control block header (TCBH), which contains data
used by the communications software.
Display Form
------------------------------------ dump_tcbh --------------------------------channel_name:
-header:
yes
-channels:
yes
-locks:
no
-slot:
-channel:
Command-Line Form
dump_tcbh channel_name
[-no_header]
[-no_channels]
[-locks]
[-slot slot_number]
[-channel channel_number]
Arguments
* channel_name
The name of the channel to display information about, regardless of the slot or
channel number. The name can be an explicit channel name, such as sync1.34,
or a string to match, such as sync. In the latter case, information is displayed for
all channels on all controllers whose names contain the string sync. If you give this
argument, you must also give the -no_header argument.
If you omit this argument, information is displayed for all channels on all
communications controllers.
8-308
VOS System Analysis Manual (R073)
dump_tcbh
* -no_header
<CYCLE>
Does not display the information shown under TCBH in the sample output. You must
give the -no_header argument if you give channel_name.
* -no_channels
<CYCLE>
Does not display the information shown under Channel Name in the sample
output.
* -locks
<CYCLE>
Displays the processes that have each selected channel locked.
* -slot slot_number
Displays information about all channels of the communications controller in the
specified slot.
* -channel channel_number
Displays information about a specified channel on the communications controller
specified with the -slot argument.
Examples
In the following example, the dump_tcbh request displays TCBH information for each
controller or controller pair and the channels connected to it.
as:
dump_tcbh
TCBH lock ptr
80006680
Num controllers
CONTROLLER IN SLOT 4
Lock address (virt)
Lock address (phys)
Vector number
Global status
IOP No
Interrupts
Pending interrupts
Comm buffer notify
X25 buffer notify
Being configured
Temporarily broken
80006088
80006088
130
0000
1
00000000
00000000
00000000
00000000
no
no
The analyze_system Command and Requests
8-309
dump_tcbh
Processing error interrupt
Model C200
Model K100
Model E593
Model ENET
Channel Name
CIP
OC17
term.17.0.2
tape.17.0
tape.17.1
term.17.12.1
term.17.12.2
term.17.12.3
term.17.12.4
enet.17.13
as:
81596A40
815B6BC0
815B9920
815B9A60
815B6D60
815B6F00
815B70A0
815B7240
815B7460
no
no
yes
no
no
TCBP
80085440
800857A0
00000001
00000001
80085B00
80086000
80086360
800866C0
8166EB00
Type
K111
K101
UNKN
UNKN
K111
K111
K111
K111
K104
Status
07004A00
00000000
00000000
00000000
05004A00
05000000
05000000
07004A00
01000000
dsr dcd
dcd
dcd
dcd
dsr dcd
dsr
The following table describes important fields that appear in the output of the preceding
example.
8-310
Field
Description
num controllers
VOS counts as one controller each nonduplex communications
controller and each duplex pair of communications controllers.
CONTROLLER IN SLOT
N
For a duplex pair, only the even slot is shown here. For a
nonduplex controller in an odd slot, the output sometimes shows
the adjacent even slot.
Interrupts
A bit on indicates that an interrupt has occurred on the
corresponding channel and has not yet been serviced.
Pending interrupts
A bit on indicates that an interrupt has occurred on the
corresponding channel, and that the interrupt CPU could not
process it immediately and so queued it for later processing.
X.25 buffer notify
Buffer notify fields are provided for each available protocol. A bit
on in one of these fields indicates that the corresponding
channel is waiting for a buffer in the fields category.
Being configured
If yes, the controller (or one controller of the pair) is being
added, removed, or reconfigured.
Temporarily broken
If yes, the slot no longer has a running controller.
Processing error
interrupt
If yes, the software is servicing an error detected on the
communications bus.
VOS System Analysis Manual (R073)
dump_tcbh
The following table describes columns in the channel information output.
Field
Description
CIP
The channel info pointer
TCBP
The terminal control block pointer
Type
The type of the line adapter card
Status
The status last reported by the channel. The first four digits are
the UART status.
The following table describes the abbreviations in the Status column.
Status Column
Abbreviation
Description
cd
Carrier detect
dcd
Data carrier detect
dsr
Data set ready
frm
Framing error
int
Interrupt
tbmt
Transmit buffer empty
The analyze_system Command and Requests
8-311
dump_tdr
dump_tdr
8-
Purpose
This request displays information about a task data region (TDR).
Display Form
------------------------------------ dump_tdr ----------------------------------full: n o
-brief: no
-task:
Command-Line Form
dump_tdr [-full]
[-brief]
[-task task_id]
Arguments
* -full
Displays detailed information about one or more tasks.
* -brief
Displays limited information about one or more tasks.
<CYCLE>
<CYCLE>
* -task task_id
Specifies a task for which to dump the TDR entry; by default, the TDR entry for
each task is dumped.
Explanation
Tasking is a feature of VOS that enables you to divide a program and process into
multiple tasks, each of which has its own execution environment within the process,
including its own stack, heap, port attachments (and possibly a dedicated terminal),
event attachments, and execution point. The same piece of code may be run by more
than one task.
8-312
VOS System Analysis Manual (R073)
dump_tdr
A task is a subdivision of a process that is dedicated to performing some predefined
specific subset of procedures. Each task in a process has its own stack and static area.
Usually each task is attached to a specific terminal and user.
Every (non-kernel) process has a task data region (TDR) even if it is not a tasking
process; every process has at least one task. VOS allocates and initializes the TDR
when a program module begins execution. VOS also allocates and initializes a task
data region entry (TDRE) for every created task. As shown in the following figure, the
TDREs are pointed to by a dynamically built structure of pointers contained in the TDR
field tdre_ptr_ptr. The TDRs and TDREs are allocated in the user heap and are
sometimes destroyed by errant user programs.
Use the check_area -heap request if you suspect the validity of the data shown.
TDR
tdre_ptr_ptr
TDRE
TDRE
TDRE
TDRE
The analyze_system Command and Requests
8-313
dump_tdr
Examples
In the following example, the who request displays information about MailTransport
processes and the dump_tdr request displays the number of tasks for the process.
as:
match mail; who
33 0492B780 Overseer.System (MailTransport1)
34 0493A980 Overseer.System (MailUserAgent1)
35 04911030 Overseer.System (MailTransport2)
....
as: process 33
Using nonrunning process.
Current process is 33, ptep 0492B780, Overseer.System (MailTransport1)
as: dump_tdr
TDR @ 00845060
Flags:
tasking_enabled ignore_preemption
n_tasks
current_task_num
n_static_tasks
max_n_tasks
3
1
3
3
....
ready_list
wait_list
Task ID
Task ID
Task ID
unready_list
Tasks:
Num State
1
2
3
ready
ready
ready
1 @00845520 ready
3 @00845720 ready
2 @00845620 ready
saved_a6 term tid
04723340
0471B680
04713680
as:
8-314
VOS System Analysis Manual (R073)
5 00000000-0000-0000
0 00000000-0000-0000
0 00000000-0000-0000
dump_tdr
In the following example, the dump_tdr request displays information about a specific
task.
as:
dump_tdr -task 3
TDRE @ 00845720
Task 3:
task_id
3
links:
00845728: 00845620 00845628 00845520 00845528
state
ready
priority
0
n_fence_pages
0
task_alloc_ptr
00000001
fence_ptr
0470C000
saved_a6
04713680
task_stack_base
04714000
task_stack_len
32768
task_static_ptr
00829000
task_static_len
24576
terminal_port_id
0
Flags:
waiting_for_notify
accept_info_ptr
00000001
cpu_time
0
page_faults
0
tid
00000000-0000-0000
wait_info.event_index
0
wait_info.event_count
0
wait_info.code
1081
epilogue_handlers
as:
When you issue the dump_tdr -full request, it displays a number of fields from the
TDR. The following table describes the important TDR-related fields.
(Page 1 of 3)
Field
Description
Flags
tasking_enabled
This flag is off if the application made a call to disable tasking
(s$enable_tasking switch:off).
metering_enabled
This flag is on if the application made a call to start metering
(s$control_task op_code:enable metering).
The analyze_system Command and Requests
8-315
dump_tdr
(Page 2 of 3)
Field
Description
priorities_enabled
This flag is on if the application made a call to user priorities
(s$set_task_priority).
Dynamic Task Creation and Maintenance
n_tasks
The current number of predefined and created tasks.
current_task_num
The task that is currently running. This value is changed by
the task scheduler when it schedules a task to run.
n_static_tasks
The number of tasks that were predefined when you issued
the bind command.
max_n_tasks
The maximum number of tasks that can be accommodated
by the current TDRE pointer array space allocation.
Information to Automatically Start Task 1
stack_base
A copy of the pdr.stack_base marking where task 1s
return stack starts.
stack_len
A copy of the pdr.stack_len marking the stack length of
task 1s stack.
first_task_static_ptr
The base address of task 1s static area, which is obtained
from the program module.
first_task_static_len
The size of task 1s static area, which is obtained from the
program module.
Scheduling Lists for Task States
ready_list
Head and tail of tasks that are ready to run. If you enabled
priorities, the tasks are in priority order.
wait_list
Head and tail of tasks that are waiting on an event.
unready_list
Head and tail of tasks that have been paused.
Information to Permit Task Metering
8-316
old_cpu_time
Stores cumulative CPU time for the process to enable VOS to
calculate the CPU time for each task if your application
turned on metering. This value is updated on a task switch.
old_page_faults
Stores cumulative page faults for the process to enable VOS
to calculate page faults for each task if your application
turned on metering. This value is updated on a task switch.
VOS System Analysis Manual (R073)
dump_tdr
(Page 3 of 3)
Field
Description
Other
macro_event
In a program consisting of more than one task, VOS attaches
an unnamed event to be used as a macro event; this field
displays the event ID of that macro event.
completion_command
If your application calls s$stop_program and that call
contains a command to be executed after the application
stops, this field displays the command.
tdr.tdre_ptr_ptr
This field displays a pointer to a structure that contains the
addresses of all the TDREs for this process.
The analyze_system Command and Requests
8-317
dump_tdr
When you issue the dump_tdr -full request, it displays a number of fields from the
TDRE. The following are the most important TDRE-related fields.
(Page 1 of 2)
Field
Description
To Identify and Queue the Task in the Proper Lists
task_id
This array entrys task ID.
links
Previous and next pointer for the slot this TDRE is threaded on
(ready, wait, or unready).
state
What state the task is in (initialized, ready, stopped, etc.). This
value is used to check task calls for appropriate action.
priority
Used to queue tasks on the ready list in priority order.
To Enable Dynamic Task Creation and Static Task Control
n_fence_pages
The number of fence pages specified by s$create_task.
task_alloc_ptr
The pointer to the block allocated from user heap for the task
area.
fence_ptr
Where the fence starts between created tasks.
Other Fields
saved_a6
The tasks stack frame pointer saved when the task last ran.
task_stack_base
The position in the user stack which is the base of stacks task.
term_port_id
The port ID of the terminal associated with this task (set by
s$init_task, which is described in the VOS Subroutines
manuals.)
For Per-Task Monitoring of CPU Usage and Page Faults
cpu_time
The accumulated CPU time used by this task if metering is
enabled.
page_faults
The accumulated number of page faults counted for this task if
metering is enabled.
For Per-Task Transaction Protection
tid
The per-task transaction ID for protection and locking.
Per-Task Macro Event Data
wait_info.event_
index
8-318
First entry in the macro event structure. It is used to look up
what the task is waiting on.
VOS System Analysis Manual (R073)
dump_tdr
(Page 2 of 2)
Field
Description
wait_info.event_
count
Event count returned from the tasks wait.
wait_info.code
Used to pass an error code to the task from a wait event.
For Clean Up of a Stopped Task
epilogue_handlers
Entry points for up to ten epilogue handlers for this task.
Enabled by s$add_task_epilogue_handler.
The analyze_system Command and Requests
8-319
dump_tpo
dump_tpo
8-
Purpose
This request displays information about the TPOverseers internal data structures.
Display Form
----------------------------------- dump_tpo -------------------------------a ll
structure:
-match:
-hash_tables: no
-brief:
yes
Command-Line Form
dump_tpo structure
[-match match_string]
[-hash_tables]
[-no_brief]
Arguments
* structure
<CYCLE>
The internal data structure to be dumped. The default value all dumps all three
structures: tp_state_info, gn, and g. The tp_state_info structure is a part
of VOS and therefore can be referenced regardless of the current process.
If you specify tp_state_info, note that the request also dumps the
tp_default_parameters structure. The gn and g structures are global
structures internal to the TPOverseer. To display information in these structures,
the current process must be the TPOverseer process. (To change the current
process to the TPOverseer process, specify the process request, followed by the
TPOverseer process. See the Examples section.)
* -match match_string
Displays only the lines containing a match with the specified string. (For information
on the characters you can specify for match_string, see information on the
match request of the analyze_system command.)
8-320
VOS System Analysis Manual (R073)
dump_tpo
* -hash_tables
<CYCLE>
Displays the various hash tables contained in the structures. These hash tables
contain the following:
the tio and gtid hash tables in the tp_state_info structure
the page, afte, and mod_page hash tables in the gn structure
the shorthand and module hash tables in the g structure
This argument produces lengthy output, so you should specify it only if you have a
specific reason to examine these tables. By default, the request does not display
the hash tables contained in the structures.
* -no_brief
<CYCLE>
Specifies detailed information about the structures. By default, the request displays
concise information about the structures.
Explanation
This request displays values related to the TPOverseer.
Examples
The following examples illustrate the use of the dump_tpo request. In the following
example, the -no_brief argument is specified to show detailed information about the
structures. Note that the last line of the output indicates that the TPOverseer is not the
current process in the analyze_system subsystem.
as:
dump_tpo -no_brief
tp_overseer_running:
TRUE
tp_overseer_alive:
TRUE
Structure tp_state_info @ 40C01030
tp_version_no:
1356
tp_file_version_no:
5
tp_o/r_wait_event:
40C07990
tp_o/r_signal_event:
40C07A00
file_change_lockp:
40C025E0
tp_overseer_pid:
01088026
tp_overseer_no_space:
FALSE tp_overseer_dying:
FALSE
tp_overseer_working:
FALSE tp_overseer_notified:
FALSE
tlf_nearly_full:
FALSE tlf_too_long_since_idle: FALSE
tlf_too_long_since_switch: TRUE
tpo_work_list:
40C01070: 00000001 40C01070 00000001 40C01070
num_odd_log_tsi:
0
num_odd_log_gbl_tsi:
0
num_even_log_tsi:
1
num_even_log_gbl_tsi:
0
current_view:
1
num_committing_gbl_tsi (0): 0
num_committing_gbl_tsi (1): 0
The analyze_system Command and Requests
8-321
dump_tpo
num_local_committing_tsi (0): 1
num_local_committing_tsi (1): 0
num_local_committing_gbl_tsi (0): 0
num_local_committing_gbl_tsi (1): 0
TSI list header:
40C01088:
TSI free list num_entries: 5
KWL list header:
40C010B0:
KWL free list num_entries: 1
FLI list header:
40C010D8:
FLI free list num_entries: 3
RRL list header:
40C01100:
RRL free list num_entries: 44
RWL list header:
40C01128:
RWL free list num_entries: 4
KRL list header:
40C01150:
KRL free list num_entries: 4
GTID list header:
40C01178:
GTID free list num_entries: 0
num_precommitted_txns:
0
precommitted_gtid_list:
40C025A4:
40D79FE0 40D79FE0 4144C4C0 4144C4C0
40FE8EC0 40FE8EC0 40FE8EC0 40FE8EC0
40FFC4A0 40FFC4A0 40FF6EB0 40FF6EB0
40FCC600 40FCC600 40FED6E0 40FED6E0
4144AE70 4144AE70 40FF2FF0 40FF2FF0
40DDE7C0 40DDE7C0 40FD4AF0 40FD4AF0
00000001 40C01178 00000001 40C01178
00000001 40C025A4 00000001 40C025A4
Structure tp_default_parameters @ 005FEB76
priority:
0
flags:
none
dump_tpo: Further information available only with TPOverseer as current
process.
In the following example, the process request is specified to set the TPOverseer
process as the analyzed process. Finally, the dump_tpo request is specified to display
information about the TPOverseers internal structures (note that the request also
displays the g and gn structures).
as:
process -process_name TPOverseer
Using process on CPU10.
Current process is 38, ptep 40E41640, Overseer.System (TPOverseer)
Process is running on CPU 10 right now; no stack addr known.
as:
dump_tpo
tp_overseer_running:
TRUE
tp_overseer_alive:
Structure tp_state_info @ 40C01030
tp_version_no:
1356
tp_file_version_no:
5
tp_o/r_wait_event:
40C07990
tp_o/r_signal_event:
40C07A00
file_change_lockp:
40C025E0
tp_overseer_pid:
01088026
tp_overseer_no_space:
FALSE tp_overseer_dying:
8-322
VOS System Analysis Manual (R073)
TRUE
FALSE
dump_tpo
tp_overseer_working:
FALSE tp_overseer_notified:
FALSE
tlf_nearly_full:
FALSE tlf_too_long_since_idle: FALSE
tlf_too_long_since_switch: TRUE
tpo_work_list:
40C01070: 00000001 40C01070 00000001 40C01070
num_odd_log_tsi:
0
num_odd_log_gbl_tsi:
0
num_even_log_tsi:
3
num_even_log_gbl_tsi:
0
current_view:
0
num_committing_gbl_tsi (0): 0
num_committing_gbl_tsi (1): 0
num_local_committing_tsi (0): 0
num_local_committing_tsi (1): 3
num_local_committing_gbl_tsi (0): 0
num_local_committing_gbl_tsi (1): 0
num_precommitted_txns:
0
precommitted_gtid_list:
40C025A4: 00000001 40C025A4 00000001 40C025A4
Structure tp_default_parameters @ 005FEB76
priority:
0
flags:
none
Structure g @ 00E2D888
my_process_id:
01088026
flags:
idle_written,semi_idle_written
next_run_time:
0000000C2FA332FD
last_free_time:
0000000C2F99A137
next_network_time:
FFFFFFFFFFFFFFFF
next_flush_time:
0000000000000000
next_flush_try_time:
0000000C2F9E00DC
next_idle_time:
0000000C31F60AB1
next_idle_flush_time:
0000000000000000
next_flush_section_time:
0000000000000000
wait_lists:
driver_list:
00E2D8E0: 00000001 00E2D8E0 00000001 00E2D8E0
flush_list:
00E2D8F0: 00000001 00E2D8F0 00000001 00E2D8F0
physical_wait_list:
00E2D910: 00000001 00E2D910 00000001 00E2D910
module_wait_list:
00E2D920: 00000001 00E2D920 00000001 00E2D920
tlf_output_info:
tlf_number:
299878
high_offset:
8339973
high_offset_tried:
8339885
high_offset_flushed:
8339885
high_offset_idled:
3451
log_record.max_len:
24576
log_record.recp:
00E955F0
free_shorthand:
00E2D95C: 00E73E9C 00E73E9C 00E73E48 00E73E48
shorthand_hashp:
00E42620
Structure gn @ 00E2A558
twa_portep:
40DC6E10
twa_aftep:
40DC6EE0
twa_fip:
40DC7000
n_indexes:
28
num_pages:
2000
num_free_pages:
2000
cur_section_infop:
00000001
cur_file_infop:
00000001
The analyze_system Command and Requests
8-323
dump_tpo
next_to_twa_time:
0000000000000000
to_twa_list:
00E2A578: 00000001 00E2A578 00000001 00E2A578
next_log_in_twa_time:
0000000000000000
log_in_twa_list:
00E2A590: 00000001 00E2A590 00000001 00E2A590
in_twa_list:
00E2A5A0: 00000001 00E2A5A0 00000001 00E2A5A0
next_to_file_time:
0000000000000000
to_file_list:
00E2A5B8: 00000001 00E2A5B8 00000001 00E2A5B8
next_log_in_file_time:
0000000000000000
log_in_file_list:
00E2A5E0: 00000001 00E2A5E0 00000001 00E2A5E0
next_bmex:
5
twa_path:
%s#m1>system>transaction_logs>transaction_work_area
8-324
VOS System Analysis Manual (R073)
dump_transaction
dump_transaction
8-
Purpose
This request displays information about a specific Transaction State Info (TSI)
structure.
Display Form
----------------------------- dump_transaction -----------------------------address:
-brief:
no
-output_path:
Command-Line Form
dump_transaction address
[-brief]
[-output_path file_name]
Arguments
* address
Required
A standard analyze_system address string representing the TSIs location. The
list_transactions request identifies the address of the various TSIs that this
argument displays. See list_transactions later in this chapter.
* -brief
<CYCLE>
Displays only basic information about the transaction, including state, flags, and
lock list information. By default, the request displays detailed information about the
transaction, including the hash, work, and net links and the FLI structures queued
on the lock_list links.
* -output_path file_name
Directs the output from the terminals screen to file_name. By default, the
request directs output to the terminals screen.
The analyze_system Command and Requests
8-325
dump_transaction
Explanation
The dump_transaction request displays a single TSI structure and, optionally, a list
of associated FLI structures.
Examples
In the following example, the dump_transaction request displays a TSI structure.
as: dump_transaction 80283740 -brief
Transaction_state_info: 80283740
Transaction ID:
1F6EDF8B471116BD
Commit ID: 0000000000000000
Started on module:
%se#m120 (71-17)
at: 96-09-16 12:51:23 EDT
Started by process:
40 on module %se#m120 (71-17) (process ID: 47118028)
Lock process ID:
40 on module %se#m120 (71-17) (process ID: 47118028)
State:
TID_RUNNING_LOCKED (global abort)
Transaction flags:
started on odd log, on hash list
rlocks:
20
wlocks:
0
blocked_flip:
802B0840
lock_list:
802837B0: 802B0840 802B0840 802B0840 802B0840
8-326
VOS System Analysis Manual (R073)
dump_vm_pool_info
dump_vm_pool_info
8-
Purpose
This request displays information about the virtual memory pool on the analyzed
module.
Display Form
-------------------------------- dump_vm_pool_info -----------------------------dump_free: y es
-dump_used: yes
-header:
no
-by_tree:
no
-descending: no
-show_links: no
Command-Line Form
dump_vm_pool_info
[-no_dump_free]
[-no_dump_used]
[-header]
[-by_tree]
[-descending]
[-show_links]
Arguments
* -no_dump_free
<CYCLE>
Displays only the virtual memory pool used list and not the free list. If you specify
no for this argument, you must specify a value of yes for the -dump_used
argument. If you specify yes for this argument, the request displays the virtual
memory pool free list. The default value is yes.
* -no_dump_used
<CYCLE>
Displays only the virtual memory pool free list and not the used list. If you specify
no for this argument, you must specify a value of yes for the -dump_free
The analyze_system Command and Requests
8-327
dump_vm_pool_info
argument. If you specify yes for this argument, the request displays the virtual
memory pool used list. The default value is yes.
NOTE
You must specify the value yes for one of the following
three arguments: -no_dump_free, -no_dump_used, or
-header. If you do not specify the value yes for one of
these three arguments, you receive a command-line error.
<CYCLE>
* -header
The value yes formats the vm_pool header structure for the user. The value no
(the default) specifies that the header is not displayed.
* -by_tree
The value yes specifies that the output displays blocks (free or used) that are found
on the binary tree structures supporting the virtual memory pool. Note that not all
used blocks in the system can be seen on the used tree; in other words, when you
specify -no_dump_free and -by_tree, not all used blocks are displayed. The
value no (the default) displays only the block list.
* -descending
<CYCLE>
The value yes specifies that the blocks in the pool are displayed in descending
order. The value no (the default) specifies that the blocks in the pool are displayed
in ascending order.
* -show_links
<CYCLE>
The value yes specifies that the output shows the locations in the individual
structures that point to neighboring structures, which makes the output similar to a
true dump command. The value no (the default) does not show the link values.
Explanation
When you issue the dump_vm_pool_info request with default values, the request
displays the contents of the kernel virtual memory pool. The Start column shows the
virtual page number at which each pool block begins. The Size area displays the size
of the block in the appropriate column for the block being free or in use. The Owner
column shows the user of that block (a description of that block or the name of the
external static variable that points to the block).
The virtual memory pool is the region of kernel address space that is not occupied by
system code or fixed-size tables. Various kernel subsystems dynamically request
virtual memory from this pool. You can use the display_extensible_heap request
to obtain further information about the virtual memory pool usage of the paged, wired,
or communications heaps.
8-328
VOS System Analysis Manual (R073)
dump_vm_pool_info
Diagnostic messages such as the following may be displayed when there is a problem
with a data structure in the pool.
*** This node breaks vpn sequence.
*** Problem with node size or vpn.
All such messages begin with *** to facilitate scanning. The end of the output also
contains a summary line, as in the following example:
*** 6 discrepancies in databases observed.
***
Examples
The following example is an excerpt from output of the dump_vm_pool_info request
with the -no_dump_free argument.
as:
dump_vm_pool_info -no_dump_free
Virtual Memory Pool Used List
Start
Size
C0923
12 (0000C)
C092F
6 (00006)
C0935
8 (00008)
C093D
8 (00008)
C0980
8 (00008)
C0988
16 (00010)
C0998
8 (00008)
C09A0
288 (00120)
C0AC0
32 (00020)
.
.
[... many lines removed ...]
.
ECE9A
28 (0001C)
ECEB6
28 (0001C)
ECED2
11 (0000B)
ECEDD
284 (0011C)
ECFF9
7 (00007)
Owner
Streams MBLKS
Streams Message Data
Streams MBLKS
Streams Message Data
pcp_stack
I/O Heap 0
Comm Heap
net_buffer_pool_p$
I/O Heap 0
vterm.pm
cache_manager_pages
async_al.cp.pm
cache_manager_pages
Idle_3 fence/stack
The following is an example of the dump_vm_pool_info request with the
-no_dump_used argument.
as:
dump_vm_pool_info -no_dump_used
Virtual Memory Pool Free List
Start
Size
Owner
C0945
58 (0003A)
Merged Free Block
C0D3C
669 (0029D)
Merged Free Block
C22B6
142640 (22D30)
Merged Free Block
The analyze_system Command and Requests
8-329
dump_vm_pool_info
E4FF4
E51B0
ECDAA
12 (0000C)
31678 (07BBE)
6 (00006)
Merged Free Block
Merged Free Block
Merged Free Block
The following example of the dump_vm_pool_info request illustrates the header
(alone).
as:
dump_vm_pool_info -no_dump_used -no_dump_free -header
Virtual Memory Pool Header
Head of block list:
Tail of block list:
Root of used tree:
Root of free tree:
Lowest managed page:
First page in main range:
Highest managed page:
Ultimate high page:
Pages managed:
C1027340
C0AF3C00
C15961C8
C1027F08
C0980
00000
ECFFF
FEFFF
181948
The following example illustrates the new, combined output.
as:
dump_vm_pool_info -header
Virtual Memory Pool Header
Head of block list:
Tail of block list:
Root of used tree:
Root of free tree:
Lowest managed page:
First page in main range:
Highest managed page:
Ultimate high page:
Pages managed:
C0923
8-330
Start
12
C092F
C0935
C093D
C0945
C0980
C0988
C0998
C09A0
C0AC0
C0AE0
C0AF0
C1027340
C0AF3C00
C15961C8
C1027F08
C0980
00000
ECFFF
FEFFF
181948
* Virtual Memory Pool *
Size
Flags
Used
Free (hex)
Owner
(0000C) u Streams MBLKS
6
(00006) u Streams Message Data
8
(00008) u Streams MBLKS
8
(00008) u Streams Message Data
58 (0003A) f
Merged Free Block
8
(00008) u pcp_stack
16
(00010) u I/O Heap 0
8
(00008) u Comm Heap
288
(00120) u net_buffer_pool_p$
32
(00020) u I/O Heap 0
16
(00010) u tape_buffers_p$
50
(00032) u Wired Heap 1
VOS System Analysis Manual (R073)
dump_vm_pool_info
[... many lines removed ...]
ECE9A
ECEB6
ECED2
ECEDD
ECFF9
Total
28
28
11
284
7
-----6885
Used
(0001C)
(0001C)
(0000B)
(0011C)
(00007)
u
u
u
u
u
vterm.pm
cache_manager_pages
async_al.cp.pm
cache_manager_pages
Idle_3 fence/stack
-----175063
Free
The following is an example of the dump_vm_pool_info request with the
-show_links argument. Note that when the output contains a large amount of
information, output compression is disabled, as illustrated by the entries just before
page ECFF9.
as:
dump_vm_pool_info -show_links
* Virtual Memory Pool *
Size
Flags
Start
Used
Free (hex)
Owner
Forward
This
Backward
C0923
12
(0000C) u Streams
C10273C0
C1027340
00000000
C092F
6
(00006) u Streams
C1586180
C10273C0
C1027340
C0935
8
(00008) u Streams
C1586200
C1586180
C10273C0
C093D
8
(00008) u Streams
C15918C0
C1586200
C1586180
.
.
.
MBLKS
Message Data
MBLKS
Message Data
[... many lines removed ...]
ECFF5
1
C153ED80
ECFF6
1
C153EBC0
ECFF7
1
C10179C0
ECFF8
1
C0AF3C00
ECFF9
7
00000000
-----Total
6885
Used
(00001) u cache_manager_pages
C153EF40
C1545500
(00001) u cache_manager_pages
C153ED80
C153EF40
(00001) u cache_manager_pages
C153EBC0
C153ED80
(00001) u cache_manager_pages
C10179C0
C153EBC0
(00007) u Idle_3 fence/stack
C0AF3C00
C10179C0
-----175063
Free
The analyze_system Command and Requests
8-331
dump_vm_pool_info
The following is an example of the dump_vm_pool_info request with the -by_tree
argument. The output of the request with the -by_tree argument is not compressed.
The Key field shows the position of the node in the tree in a compact form. The root
node is 1. The nodes on the next level are 2 and 3, and their parent is node 1. Nodes
47 are on level 2, and nodes 815 are on level 3. The parent nodes key is always
floor (my_key/2). An individual nodes left child is my_key*2, and the right child is
my_key*2+1.
as:
dump_vm_pool_info -by_tree -show_links
Virtual Memory Pool Used Tree
Start
Size Flags Owner
This
Left
Right
Parent
Key
C0923
12 u
Streams MBLKS
C1027340
00000000
00000000
C10273C8
2048.
C092F
6 u R Streams Message Data
C10273C0
C1027348
C1586208
C1017C89
1024.
C0935
8 u R Streams MBLKS
C1586180
00000000
00000000
C1586209
4098.
C093D
8 u
Streams Message Data
C1586200
C1586188
C1017088
C10273C8
2049.
C0980
8 u R pcp_stack
C1017080
00000000
00000000
C1586209
4099.
C0988
16 u
I/O Heap 0
C1017C80
C10273C8
C104ABC8
C104B608
512.
C0998
8 u
Comm Heap
C104ABC0
00000000
00000000
C1017C88
1025.
C09A0
288 u
net_buffer_pool_p$
C104B600
C1017C88
C105DD08
C105FD08
256. C0AC0
32 u
I/O Heap 0
C104B680
00000000
00000000
C105DD08
1026.
.
.
[... many lines removed ...]
.
ECFF6
1
C153ED80
63.
8-332
u
cache_manager_pages
C1545508
C10179C8
C1545888
VOS System Analysis Manual (R073)
dump_vm_pool_info
ECFF7
1 u
cache_manager_pages
C153EBC0
00000000
00000000
C10179C8
254.
ECFF8
1 u
cache_manager_pages
C10179C0
C153EBC8
C0AF3C08
C153ED88
127.
ECFF9
7 u
Idle_3 fence/stack
C0AF3C00
00000000
00000000
C10179C8
255.
488 nodes on 14 levels
26 red nodes and 462 black nodes.
Level
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Nodes
1
2
4
8
16
32
64
128
128
37
29
23
12
4
Density
1.000000
1.000000
1.000000
1.000000
1.000000
1.000000
1.000000
1.000000
0.500000
0.072266
0.028320
0.011230
0.002930
0.000488
Virtual Memory Pool Free Tree
Start
Size
This
Key
C0945
58
C15918C0
4.
C0D3C
669
C112EF80
2.
C22B6 142640
C1027F00
1.
E4FF4
12
C101C5C0
6.
E51B0
31678
C15B2340
3.
ECDAA
6
C1669F80
7.
Flags
Left
f
Owner
Right
Parent
Merged Free Block
00000000
00000000
C112EF88
Merged Free Block
C15918C8
00000000
C1027F08
Merged Free Block
C112EF88
C15B2348
00000000
Merged Free Block
00000000
00000000
C15B2348
Merged Free Block
C101C5C8
C1669F88
C1027F08
Merged Free Block
00000000
00000000
C15B2348
The analyze_system Command and Requests
8-333
dump_vm_pool_info
6 nodes on 3 levels
Level
0
1
2
Nodes
1
2
3
Density
1.000000
1.000000
0.750000
The following is an example of the dump_vm_pool_info request with the arguments
-by_tree, -descending, and -no_show_links.
as:
dump_vm_pool_info -no_dump_used -by_tree -descending
Virtual Memory Pool Free Tree
Start
Size Flags Owner
ECDAA
6 f
Merged Free
E51B0
31678 f
Merged Free
E4FF4
12 f
Merged Free
C22B6 142640 f
Merged Free
C0D3C
669 f
Merged Free
C0945
58 f
Merged Free
6 nodes on 3 levels
8-334
VOS System Analysis Manual (R073)
Block
Block
Block
Block
Block
Block
edit_vm_sizes
edit_vm_sizes
8-
Purpose
This request is used in partition mode and sets the maximum sizes for the tape and
disk I/O buffers, and maximum number of pages for the paged, wired, I/O, and
communications heaps in the kernel.
CAUTION
Use this request only when instructed to do so by the
CAC.
Display Form for XA/R-Series Modules
-------------------------------- as_edit_vm_sizes -----------------------------16
-vm_size$tape_buffers:
-vm_size$dump_disk_buffers: 2
-vm_size$ui_abs_pages:
6
-sys_info$ioh_pages_per_mb: 32
-sys_info$ph_pages_per_mb: 64
-sys_info$wh_pages_per_mb: 128
-sys_info$max_ch_pages:
-1
-sys_info$max_ih_pages:
-1
-sys_info$max_ph_pages:
-1
-sys_info$max_wh_pages:
-1
The analyze_system Command and Requests
8-335
edit_vm_sizes
Display Form for Continuum-Series Modules
-------------------------------- as_edit_vm_sizes ------------------------------vm_size$tape_buffers:
16
-vm_size$dump_disk_buffers: 2
-vm_size$ui_abs_pages:
6
-sys_info$ch_pages_per_mb: 32
-sys_info$ioh_pages_per_mb: 32
-sys_info$ph_pages_per_mb: 64
-sys_info$wh_pages_per_mb: 128
-sys_info$max_ch_pages:
-1
-sys_info$max_ih_pages:
-1
-sys_info$max_ph_pages:
-1
-sys_info$max_wh_pages:
-1
Command-Line Form
edit_vm_sizes
[-vm_size$tape_buffers number]
[-vm_size$dump_disk_buffers number]
[-vm_size$ui_abs_pages number]
[-sys_info$ch_pages_per_mb number]
[-sys_info$ioh_pages_per_mb number]
[-sys_info$ph_pages_per_mb number]
[-sys_info$wh_pages_per_mb number]
[-sys_info$max_ch_pages number]
[-sys_info$max_ih_pages number]
[-sys_info$max_ph_pages number]
[-sys_info$max_wh_pages number]
Arguments
* -vm_size$tape_buffers number
The maximum number of pages the VOS kernel uses for tape I/O buffers. The
default value is 16. You can specify this or a lesser value, although, given the large
virtual address space on XA/R-series and Continuum-series modules, no change
is necessary. This argument should be considered obsolete.
* -vm_size$dump_disk_buffers number
The maximum number of pages the dump_disk and reload_disk commands
use for dump disk I/O buffers. The default value is 2.
8-336
VOS System Analysis Manual (R073)
edit_vm_sizes
* -vm_size$ui_abs_pages number
The maximum number of UI (PSI) pages that the VOS kernel uses. The default
value is 6. You can specify this or a lesser value, although, given the large virtual
address space on XA/R-series and Continuum-series modules, no change is
necessary. This argument should be considered obsolete.
* -sys_info$ch_pages_per_mb number
On Continuum-series modules, the amount of physical space occupied by the
communications heap as a fraction of one megabyte, or 256 pages, of memory.
The default value is 32 or one eighth (32/256) of physical memory.
* -sys_info$ioh_pages_per_mb number
The amount of physical space occupied by the I/O heap as a fraction of one
megabyte, or 256 pages, of memory. The default value is 32 or one eighth (32/256)
of physical memory.
* -sys_info$ph_pages_per_mb number
The amount of physical space occupied by the physical heap as a fraction of one
megabyte, or 256 pages, of memory. The default value is 64 or one quarter
(64/256) of physical memory.
* -sys_info$wh_pages_per_mb number
The amount of physical space occupied by the wired heap as a fraction of one
megabyte, or 256 pages, of memory. The default value is 128 or one half (128/256)
of physical memory.
* -sys_info$max_ch_pages number
The maximum size in pages for the communications heap, unless size is less than
0, in which case a hard minimum value is used. On XA/R-series modules, the
communications heap is restricted to the bottom 16 MB of physical memory.
* -sys_info$max_ih_pages number
Maximum size in pages for the I/O heap, unless size is less than 0, in which case
the maximum is determined by the value of the -sys_info$ioh_pages_per_mb
argument.
* -sys_info$max_ph_pages number
Maximum size in pages for the paged heap, unless size is less than 0, in which
case the maximum is determined by the value of the
-sys_info$ph_pages_per_mb argument.
* -sys_info$max_wh_pages number
Maximum size in pages for the wired heap, unless size is less than 0, in which case
the maximum is determined by the value of the -sys_info$wh_pages_per_mb
argument.
The analyze_system Command and Requests
8-337
edit_vm_sizes
Explanation
Before using the edit_vm_sizes request, issue the use_partition request to
specify a disk and boot partition. The edit_vm_sizes request does not display
output.
The edit_vm_sizes request sets the maximum sizes for the tape and disk I/O
buffers, and maximum number of pages for the paged, wired, I/O, and communications
heaps in the kernel.
NOTE
The arguments in the request use the abbreviations ch for
communications heap, ioh or ih for I/O heap, ph for
paged heap, and wh for wired heap.
You can determine the maximum number of pages for the paged, wired, I/O, and
communications heaps in the kernel using a dynamic kernel sizing algorithm, a fixed
maximum, or a predefined hard maximum.
Dynamic sizing. By default, VOS limits a heap to a fraction of the physical space
available that might change during a system upgrade or startup. The
-sys_info$ioh_page_per_mb, -sys_info$ph_page_per_mb, and
-sys_info$wh_page_per_mb arguments enable you to specify a fractional
portion of kernel memory that will be used by I/O, physical, and wired heaps.
Fixed maximum. You can specify fixed maximum sizes for the communications, I/O,
physical, and wired heaps using the -sys_info$max_ch_pages,
-sys_info$max_ih_pages, -sys_info$max_ph_pages, and
-sys_info$max_wh_pages arguments. Even if the amount of physical memory
changes, these maximums do not change unless you respecify them and reboot
the module.
Predefined hard minimum. If you specify fixed maximum values for the
communications, I/O, physical, and wired heaps that are less than certain
predefined hard minimum values, these minimum values override the specified
maximums. These predefined hard minimum values may change from release to
release.
VOS uses the values that you specify after you reboot the module with the modified
boot partition.
8-338
VOS System Analysis Manual (R073)
evaluate
evaluate
8-
Purpose
This request displays the hexadecimal value of the address specified in the address
argument.
Display Form
------------------------------------ evaluate ---------------------------------address: *
Command-Line Form
evaluate address
Arguments
* address
The address to evaluate. The value can be in any of the formats for address values.
If you do not supply a value in place of the asterisk, VOS uses the address value
referenced in the last display request. (For information on address formats, see
Chapter 3.)
Explanation
You can use the evaluate request to calculate a hexadecimal address, or to get an
address in a format that can be used with other requests.
Examples
In the following example, the evaluate request displays the address of an offset from
the wired_heap$ external variable.
as: evaluate wired_heap$+106
80C00106
as:
The analyze_system Command and Requests
8-339
evaluate
In the following example, the evaluate request works in a complementary fashion
with the where request.
as: where 80C00106
80C00106 is in the VM Pool, Wired Heap 0+00000106.
as:
As described in Chapter 3 and shown in the following example, the evaluate request
can also be used for hexadecimal arithmetic.
as: evaluate F-5
0000000A
as:
8-340
VOS System Analysis Manual (R073)
event_count_meters
event_count_meters
8-
Purpose
This request displays the event count meters.
Display Form
------------------------------ event_count_meters ----------------------------first:
-reset: no
-report: yes
Command-Line Form
event_count_meters
[-first event]
[-reset]
[-no_report]
Arguments
* -first event
Specifies the first event during the metering period.
* -reset
<CYCLE>
Resets the event count meters to 0. When you reset the meters, the request does
not display a report unless you specify that a report should be displayed. By default,
the meters are relative to the current bootload session.
* -no_report
<CYCLE>
Specifies that the request not display output. By default, the request displays
output.
Explanation
An event is a data structure associated with a file or device that is used by processes
to communicate with one another. When one process notices that some action has
occurred that is of potential interest to one or more processes, the first process notifies
The analyze_system Command and Requests
8-341
event_count_meters
the event. For information about using subroutines to notify events, see the VOS
Subroutines manuals. This notification causes VOS to inform all processes that have
been waiting for the action. (These processes are said to be waiting on the event.) Each
time an event is notified, its event count is incremented.
The event_count_meters request enables you to determine which events are
notified most frequently over a given period of time. To determine which processes are
waiting on an event, you can use the EVENT_IDs displayed by this request as an
argument to the dump_et request. You may have to issue the dump_et request
several times to see all the processes waiting on a particular event.
When you issue event_count_meters -reset, it affects only the current process
executing analyze_system and the event_count_meters request. The command
records the reset in the file (home_dir)>as_meter_file. If more than one process
shares the same home directory, only one process at a time can reset a metering
request. If the file as_meter_file exists, it is reopened when you re-enter
analyze_system. To use the meters set since boot time, delete the file
as_meter_file.
Examples
In the following example, the event_count_meters request displays event count
meter information since the module was last booted.
as: event_count_meters
Metering time:
351:43:06
EVENT_ID
813C7880
813C4BE0
80C10840
813C3CA0
813C3BE0
813C0F40
81658FA0
80F539E0
813C7B40
813CF320
815D5100
80C141A0
8249ABE0
82084980
813CF7C0
81574BC0
81743F00
80C103C0
813D03C0
814AD680
8171A820
81B232A0
8-342
DELTA COUNT ATB
26492511
47.8
7720387
164.0
3836774
330.0
2796241
452.8
1212203
1044.5
655847
1930.6
491879
2574.2
429719
2946.5
305993
4138.0
253366
4997.5
231605
5467.0
210758
6007.8
200815
6305.2
193796
6533.6
144114
8786.0
125926 10055.0
104877 12073.1
99639 12707.7
99442 12732.9
84507 14983.2
74283 17045.4
54230 23348.4
VOS System Analysis Manual (R073)
/SEC
20.9
6.1
3.0
2.2
1.0
0.5
0.4
0.3
0.2
0.2
0.2
0.2
0.2
0.2
0.1
0.0
0.0
0.0
0.0
0.0
0.0
0.0
NAME
socket for proc 0111802A
socket for proc 01118029
page_fault_event
socket for proc 01118026
socket for proc 01118027
socket for proc 01118028
net_xmit
device_event_for_tape.17.2
socket for proc 0111802B
SERVER for overseer.one_way_serv
net_xmit
syserr_buffer_event
device_event_for_tape.17.6
device_event_for_tape.17.5
%es#m17>system>syserr_log_event
net_xmit
socket for proc 0111803F
stopped_process_event
SERVER for batch.one_way_server_
socket for proc 0111802D
net_xmit
net_xmit
event_count_meters
80F538A0
41181 30746.8
0.0 device_event_for_tape.17.1
813CF620
22432 56445.5
0.0
80EC5080
20737 61059.3
0.0 TpOverseer Signal Event
815B8420
19741 64139.9
0.0 socket for proc 01118025
80EC47A0
18766 67472.3
0.0 TpOverseer Wait Event
813CB700
17579 72028.3
0.0
816B7AE0
15925 79509.3
0.0 socket for proc 0111802C
80C0FEA0
12377 102301.5
0.0 network_notify_event
813C7C00
12084 104782.0
0.0 net_xmit
815B8B00
11964 105833.0
0.0 socket for proc 01118016
80EA1080
6394 198027.2
0.0 network change event
80F51080
4491 281938.5
0.0 device_event_for_term.17.12.4
80F36AA0
4005 316151.3
0.0
%hq_net#d00>system>postoffice>registration.g
+lobal.sysdb
813C8F20
3566 355071.8
0.0 SERVER for overseer.server_queue
80F5D440
3118 406089.2
0.0 net_xmit
815511A0
1935 654359.7
0.0 socket for proc 011142DD
81743E80
1658 763682.8
0.0 socket for proc 01114EBF
....
46053574
27.5 36.4 Total for 117 events.
as:
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
EVENT_ID
The hexadecimal address of an event.
DELTA COUNT
The number of times that an event has been notified.
ATB
The average time in seconds between events of a given type.
/SEC
The amount of CPU time used for all events of a given type.
NAME
The name of the event data structure associated with a file or device.
Related Information
For more information about events, see the descriptions of the dump_et and
dump_events requests.
The analyze_system Command and Requests
8-343
find_string
find_string
8-
Purpose
In dump mode, this request enables you to search memory for specific string data.
Display Form
----------------------------------- find_string -------------------------------search_string:
-hex:
yes
Command-Line Form
find_string search_string
[-no_hex]
Arguments
* search_string
Required
The data for which you wish to search. You can use a hexadecimal representation
or actual ASCII data.
* -no_hex
<CYCLE>
Specifies that VOS search for actual ASCII data. If the value is yes, VOS searches
for hexadecimal data. The default value is yes.
Examples
In the following example, the find_string request displays the addresses for string
matches found in a selected dump.
as: find_string Joe -no_hex
ASCII pattern Joe found at
ASCII pattern Joe found at
ASCII pattern Joe found at
....
ASCII pattern Joe found at
....
as:
8-344
VOS System Analysis Manual (R073)
address 8003B20E (kernel)
address 8003B38E (kernel)
address 8003B60E (kernel)
address 3FF2718C (process 1060)
frame
frame
8-
Purpose
This request either sets the default stack frame address to the address specified or
displays the default stack frame address.
Display Form
------------------------------------- frame -----------------------------------address:
Command-Line Form
frame address
Arguments
* address
An address to be set as the default stack frame address. If you omit this argument,
the operating system displays the current default stack frame address. If you
specify the asterisk symbol (*) as the value, it sets the default stack frame address
to the value last referenced in any request that alters the current address. For more
information on relative stack addressing, see Chapter 3.
Explanation
The frame referenced by the default stack frame address is called the current frame.
Once the current frame is set, requests that take addresses will take frame offsets, in
the form &soffset, where offset can be found in compiler listing maps. The
analyze_system command extends the specified number with leading hexadecimal
Fs, to produce a negative offset in the stack frame. For example, the value &sea
specifies the following hexadecimal or decimal values in the stack frame:
current_frame+FFEA
offset-22
The analyze_system Command and Requests
8-345
frame
Before issuing a frame request, you can issue the stack request to display the
addresses from which to select the address value.
Examples
The following example deals with a program in a process that has suspended itself by
calling s$sleep. The task is to determine what value was passed as the first argument
to s$sleep, i.e., the amount of time to suspend. The example shows how to use the
process, trace, frame, disassemble, and display requests to determine the
value of an argument that is stored in a stack frame.
First, the addressing environment must be set. The process request is issued with the
name of the process running the program module to analyze. Then, the trace request
displays the contents of the stack for that process.
as: process -process_name example
Using nonrunning process.
Current process is 801, ptep 82146C40, John_Doe.Stratus (example)
as: trace
give_up_cpu
fp: 3FF6FF40 pc: 80540EBC (give_up_cpu_i+16EC, line
1247)
s$$k_sleep_real
fp: 3FF6FFC0 pc: 8053D194 (scheduling+A64, line 204)
wire_and_forward
fp: 3FF6FFF0 pc: 80692258 (atlantic_waf_and_sis+258)
On-units at 80692AF8
kernel_trap$
fp: 3FF78FC0 pc: 807CC0FC (s$k_sleep+5C)
On-units at 807B4808
s$sleep
fp: 3FEA9EF0 pc: 806E4F8C (task_control+401C, line 1124)
s$sleep_glue
fp: 3FEA9F30 pc: 00008130 (s$paged_glue+80)
example
fp: 3FEA9F60 pc: 00008090 (example+90, line 14)
start_user_program fp: 3FEA9F90 pc: 807F9AB4 (start_user_program_i+3D4)
On-units at 80826760
Trace complete.
The frame request is then issued with the stack frame pointer of the entry point named
example (which happens to also be in the object module named example). It is the
routine that contains the call to s$sleep.
as:
frame 3fea9f60
Then the disassemble request is used to show the calling sequence that the program
used to pass its arguments to s$sleep.
as: disassemble example@14
/* Line 14
00008080 8461FFE2 addu
00008084 A0310000 mov
00008088 8461FFE4 addu
0000808C A0300000 mov
00008090 6C00001A call
00008094 A0000000 nop
8-346
VOS System Analysis Manual (R073)
-30,r3,r1
r1,r17
-28,r3,r1
r1,r16
+108(pc)
=000080FC
frame
In the protocol for XA/R systems, the address of the first argument is passed in register
r16. In this example, the generated code adds -28 to the contents of r3 (the current
stack frame pointer) and passes that result as the value in register r1. So the value of
interest is at a stack frame location that is 28 bytes below the top of the stack frame.
Examination of the machine code shows that -28 is FFE4 in the machine instruction.
This fits well with the frame request and the shortcut &s notation, which always
extends its argument value to the left with 1 bits before adding it to the address
specified in the frame request. This mimics the actions of the hardware, which signextends the 16-bit constant value in the addu instruction before adding it to register r3.
Thus, the following three requests are equivalent and all show the current value of the
automatic variable.
as: d &se4
3FEA9F44 0 00096000
as: d &sfe4
3FEA9F44 0 00096000
as: d &sffe4
3FEA9F44 0 00096000
|..`.
|..`.
|..`.
The value at that stack location, 96000x, is the number of seconds to sleep, expressed
in ticks of 1/1024 of a second. In this case, the argument specifies 600 seconds.
as:
600
..display_line (calc 96000x / 1024)
Of course, it is possible to display stack-relative locations without using the frame
request and &s but it requires manual calculations, perhaps using command-line
functions, as in the following example. The amount of offset (28 bytes in this case) must
be subtracted from the frame pointer (fp: 3FEA9F60x) to arrive at the address to
display. The end result is the same.
as:
display (hexadecimal (calc 3fea9f60x - 28))
3FEA9F44 0 00096000
|..`.
The analyze_system Command and Requests
8-347
fstack
fstack
8-
Purpose
This request displays a forward stack trace.
Display Form
------------------------------------- fstack -----------------------------------stack_address:
-speculate:
no
Command-Line Form
fstack stack_address
Arguments
* stack_address
Required
A stack frame address. Issue the trace request to obtain a value for this
argument.
* -speculate
This argument has an effect only on Continuum-series modules. With
-speculate set to yes, fstack attempts to validate a prospective frame to see
if it agrees with its containing frame and its entry block information, as well as
attempting other points of validation.
By default, -speculate is set to no. In this mode, the request examines the stack
by brute force, looking at every 0 modulo (stack alignment) boundary and
performing far fewer cross-frame consistency checks. The Continuum stack
alignment boundary is 0 modulo 64.
The -speculate and -no_speculate options are meant to be complementary.
While neither of them always produces the desired answer, they suggest where the
user can start looking.
8-348
VOS System Analysis Manual (R073)
fstack
Explanation
Unlike the trace and stack requests, which display a stack trace in the reverse order
of execution, the fstack request displays a forward stack trace. A forward stack trace
follows the order of execution. For example, if the fstack request displays
start_user_program at the beginning of a stack trace, the trace request displays
start_user_program at the end of a stack trace.
CAUTION
The fstack request might produce an obsolete view of
the stack because it uses a nondeterministic algorithm for
finding stack frames.
Before issuing the fstack request, issue the who request to determine which process
is running the stack that you want to analyze. Then issue the process request and
specify this process. If you issue the trace -brief request, the request displays a
list of stack addresses from which you can specify the fstack request.
Expect an incomplete stack trace on XA/R-series and Continuum-series modules. It is
recommended that you use the stack or trace requests on XA/R-series modules
instead of fstack to obtain a better stack trace.
Examples
In the following example, the output of the fstack request from an XA/R-series
module is contrasted with the output of the trace request. Note that in this case,
fstack returns a list of stack frame pointers (fp) as well as program counter (pc)
pointers. Specify only fp pointers in the fstack, stack, and trace requests.
as: who -user Joe_Smith.*
PROC
PTEP
USER NAME
2400 81C4C9E0 Joe_Smith.Eng
*2402 817D85A0 Joe_Smith.Eng, on CPU28
as: process 2400
Using nonrunning process.
Current process is 2400, ptep 81C4C9E0, Joe_Smith.Eng
as: trace
give_up_cpu
fp: 3FF6FF50 pc: 80525124 (give_up_cpu_i+1564, line
111)
s$$k_sleep_real
fp: 3FF6FFC0 pc: 80521C0C (scheduling+88C, line 168)
wire_and_forward
fp: 3FF6FFF0 pc: 80635260 (atlantic_waf_and_sis+260)
On-units at 80635A98
kernel_trap$
fp: 3FF78FC0 pc: 807A1848 (kernel_trap_i+16CB8)
On-units at 8078A768
s$sleep
fp: 3FEA9A40 pc: 806888A0 (task_control+4030, line 1
121)
s$sleep_glue
fp: 3FEA9A80 pc: 0001AF20 (s$paged_glue+670)
sleep
fp: 3FEA9AC0 pc: 0001239C (sleep+9C, line 42)
The analyze_system Command and Requests
8-349
fstack
main
fp: 3FEA9B20 pc:
s$start_c_program
fp: 3FEA9F60 pc:
ne
+0)
On-units at 3FEA9B30
start_user_program
fp: 3FEA9F90 pc:
On-units at 80822D20
Trace complete.
as: fstack 3FEA9F90
start_user_program
fp: 3FEA9F90 pc:
s$start_c_program
fp: 3FEA9F60 pc:
ne
+8)
s$allocate_glue
fp: 3FEA9E00 pc:
Cannot find any more forward frames.
as:
00008148 (t1+148, line 24)
00008574 (s_start_c_program+314, li
807E1C04 (start_user_program_i+3D4)
807E1C04 (start_user_program_i+3D4)
000083A8 (s_start_c_program+148, li
unknown
Related Information
See the descriptions of the stack and trace requests. For more information about
tracing stacks for a process, see Chapter 6.
The stack and trace requests are useful only if a process or task is idle and if a
current frame pointer is known. Sometimes, using the fstack request is the only way
to determine where a process or task might be executing, but it is accurate only if the
process or task is idle.
8-350
VOS System Analysis Manual (R073)
help
help
8-
Purpose
This request displays the available analyze_system requests.
Display Form
-------------------------------------- help ------------------------------------match:
Command-Line Form
help
[-match string]
Arguments
* -match string
Displays all the analyze_system request names that contain string. If you omit
this argument, all request names are displayed.
Examples
In the following example, the help request displays a list of the requests containing the
word list.
as: help -match list
get_list_header
list_boards
list_breaks
list_comm_dumps
list_disks
list_dumps
list_global_ports
list_iop_dumps
list_params
list_port_attachments
list_transaction_trace
list_transactions
The analyze_system Command and Requests
8-351
interrupt_meters
interrupt_meters
8-
Purpose
This request displays a breakdown of which devices are generating interrupts the
interrupt meters.
Display Form
------------------------------ interrupt_meters ---------------------------no
-reset:
-report: yes
-l7:
no
Command-Line Form
interrupt_meters
[-reset]
[-no_report]
[-l7]
Arguments
* -reset
<CYCLE>
Resets the interrupt meters to 0. When you reset the meters, the request does not
display a report unless you specify that a report should be displayed. By default,
the meters are relative to the current bootload session.
* -no_report
<CYCLE>
Specifies that the request not display output. By default, the request displays
output.
* -l7
<CYCLE>
Specifies level-7 (highest priority) interrupts.
Explanation
An interrupt is an external request for CPU time or the notification of device status
change other than an exception or a branch, jump, case, or call instruction that
8-352
VOS System Analysis Manual (R073)
interrupt_meters
changes the normal flow of instruction execution. Interrupts are generally external to
the process executing when the interrupt occurs. There are three major sources of
interrrupts: storage devices such as disks and tapes, timed interrupts such as from the
cache manager or the s$sleep subroutine, and communications interrupts such as
from terminals, StrataLINK, or X.25.
When an interrupt occurs, it is serviced by any idle CPU. When the idle CPU time is
high, interrupts do not slow down any process that needs the CPU. If there are no idle
CPUs, a CPU is picked to service the interrupt in a round-robin fashion. Use the
dipslay_system_usage command to display idle CPU time and interrupt rates for a
module. Note that in the output of this command, the Ints, /sec field displays the
total number of interrupts for all devices; the Int. Time field displays the time the
CPUs spent processing interrupts.
To determine if interrupts are causing a performance problem, look for large changes
in the number of interrupts per device over a period of time. Use the -reset argument
to take samples (see the Examples section for an example). No controller should be
over 50 percent busy, as expressed by the following formula.
(("AVG md" * "#/SEC") / 1000) < .05
In addition, you should check for imbalanced usage between disks and between IOPs
as an indicator of over- and under-utilized resources.
When you specify interrupt_meters -reset, it affects only the current process
executing analyze_system and the interrupt_meters request. The command
records the reset in the file (home_dir)>as_meter_file. If more than one process
shares the same home directory, only one process at a time can reset a metering
request. If the file as_meter_file exists, it is reopened when you re-enter
analyze_system. To use the meters set since boot time, delete the file
as_meter_file.
Examples
In the following example, the interrupt_meters request displays measurements
taken over a 45-minute period on a Continuum module.
as: interrupt_meters -reset; sleep -minutes 45; interrupt_meters
Metering time:
0:45:00
Per-vector interrupt meters
VEC
2
4
5
25
29
DEVICE
Slot-2
Slot-4
Slot-5
Recc-Console
System Timer
INTERRUPTS
137546
12774
1364
1682
215967
AVG ms
0.09
0.11
0.03
0.06
0.14
ATB ms #/SEC
19.83
50.4
213.56
4.7
2000.00
0.5
1621.88
0.6
12.63 79.2
MAX ms
25.63
2.12
0.56
0.40
3.08
The analyze_system Command and Requests
>50ms
0
0
0
0
0
8-353
interrupt_meters
Per-CPU interrupt meters
CPU
0
0
1
1
INT_TYPE
real ints
subtotal
real ints
subtotal
total
INTERRUPTS
363211
363211
6119
6119
369330
AVG ms
0.12
0.12
ATB ms
7.51
7.51
445.82
445.82
7.39
#/SEC
133.1
133.1
2.2
2.2
135.4
ATB ms
170.82
3.17
3.11
#/SEC
5.9
315.4
321.3
1.6%
0.0%
Per-module interrupt step meters
Busy
Idle
Total
INTERRUPTS
15970
860536
876506
AVG ms
0.08
0.05
0.05
as:
In the following example, the interrupt_meters request displays interrupt meter
information for an XA/R-series module.
as: interrupt_meters
Metering time:
352:29:19
Per-vector interrupt meters
VEC
64
66
69
156
157
160
161
162
174
175
176
DEVICE
bad interrupt
maint
system timer
link-1 (18)
link-2 (19)
iop-1 (4,5)
iop-2 (6,7)
iop-3 (8,9)
Disk Vector
Disk Vector
Disk Vector
INTERRUPTS
24040
379
173361633
122148692
122294062
16803432
14155063
43929652
2283
33335
73377
AVG ms
ATB ms #/SEC
0.14 52785.32
0.0
0.11 *********
0.0
0.12
7.32 136.6
0.20
10.39 96.3
0.20
10.38 96.4
0.45
75.52 13.2
0.38
89.65 11.2
0.38
28.89 34.6
0.47 555829.60
0.0
0.67 38066.87
0.0
0.49 17293.69
0.0
MAX ms
0.44
0.31
3658.13
391.31
313.61
1253.92
3796.91
209.18
1.50
260.99
87.78
Per-CPU interrupt meters
CPU
30
30
30
30
31
31
31
31
29
29
29
8-354
INT_TYPE
bad ints
null ints
real ints
subtotal
bad ints
null ints
real ints
subtotal
bad ints
null ints
real ints
INTERRUPTS
23676987
215853825
99024708
338555520
26079628
203736074
139908696
369724398
24037933
199444193
139558066
VOS System Analysis Manual (R073)
AVG ms
0.18
0.22
0.21
ATB ms
53.59
5.88
12.81
3.75
48.66
6.23
9.07
3.43
52.79
6.36
9.09
#/SEC
18.7
170.1
78.0
266.8
20.6
160.6
110.3
291.4
18.9
157.2
110.0
1.4%
2.4%
2.3%
>50ms
0
0
35
289
321
9
71
53
0
1
6
interrupt_meters
29
28
28
28
28
subtotal
bad ints
null ints
real ints
subtotal
total
363040192
24681218
220389631
114380884
359451733
1430771843
0.18
3.50 286.1
51.41
19.4
5.76 173.7
11.09
90.1
3.53 283.3
0.89 1127.5
1.7%
Per-module interrupt step meters
Busy
Idle
Total
INTERRUPTS
66016696
826873141
892889837
AVG ms
0.27
0.10
0.12
ATB ms
19.22
1.53
1.42
#/SEC
52.0
651.6
703.6
as:
The following table describes the columns that appear in the per-vector, per-CPU, and
per-module output of the preceding example.
Column
Description
VEC
The address of a service routine. A vector identifies a service routine for
a process or processor that is handling an interrrupt.
DEVICE
A VOS software module, module clock, StrataLINK controller, IOP, or
disk.
INTERRUPTS
The number of interrupts received by a device or of a given type since
the module last booted or you reset the interrupt meters.
AVG ms
The average time in milliseconds spent processing an interrupt received
by a device.
ATB ms
The average time in milliseconds between interrupts received by a
device or of a given type.
#/SEC
The average number of interrupts per second received by a device or of
a given type.
MAX ms
The maximum time in milliseconds spent processing an interrupt
received by a device.
>50ms
The number of interrupts received by a device that took longer than 50
milliseconds to process.
CPU
The main chassis slot number of a CPU board.
INT_TYPE
A CPU can receive bad, null, or real interrupts. A bad interrupt indicates
an interrupt that is ignored. A null interrupt indicates the number of times
this CPU tried to handle an interrupt but it was serviced by another idle
CPU first. A real interrupt is either busy, meaning it is handled by a busy
CPU, or idle, meaning it is handled by an idle CPU.
The analyze_system Command and Requests
8-355
interrupt_meters
Related Information
For more information about interrrupts, see the description of the sim_int_meters
request.
8-356
VOS System Analysis Manual (R073)
list_boards
list_boards
8-
Purpose
This request displays information about a specified board, all boards of a specified
type, or all of the boards in the analyzed module.
Display Form
--------------------------------- list_boards ---------------------------------no
-long:
-slot:
-board_type:
-interval:
Command-Line Form
list_boards
[-long]
[-slot]
[-board_type]
[-interval number]
Arguments
* -long
<CYCLE>
Displays full information about the board specified by -slot, all boards of the type
specified by -board_type, or all of the boards in the analyzed module.
* -slot number
The number of the slot containing the board you want information about. If you
specify -slot, you cannot also specify -board_type.
* -board_type string
<CYCLE>
The type of board that you want information about. Allowed values are cpu,
memory, disk, comm, link, psi, sci, tape, iop, bus, power, and fan. If you
specify -board_type, you cannot also specify -slot.
The analyze_system Command and Requests
8-357
list_boards
* -interval number
Displays information about the boards, and then checks, every specified number of
seconds, for boards added to or removed from service. The display is updated
when a change in the status of one of the boards occurs.
You cannot specify the -long argument with -interval. Therefore, only the brief
information display can be updated at intervals.
Examples
In the following example, the list_boards request displays a board listing for a
Continuum-series module. Note that if a board is removed from service, the
list_boards display without the -long argument highlights the entire line that
contains information about that board. If the board has a fault but has not been
removed from service, the display highlights only the Code field for the board.
as:
list_boards
Module: %sys#m3 (20 Slot Chassis)
Id Prom --------Fault Data-----Slot
Board Type
Model Serial Rev Rev Cnt Code Last Fault Time
0 CPU-Memory
G72500
829 39 28
0
2 IO Processor
K60000
121 29
8
0
4 Null Modem Comm Adap
K11100 15059 25 16
0
7 Ethernet Adapter
K10410 16355
9 18
0
8 Ethernet Adapter
K10400
5561 18 17
0
14 Terminator
K10810 29230 12
0
0
15 Terminator
K10810 29189 12
0
0
BP Bus P0
***** ***
0
BQ Bus Q0
***** ***
0
BP Bus P1
***** ***
0
BQ Bus Q1
***** ***
0
4 SCSI-ENET Controller
K45000
362 37 13
0
1 SCSI Port
SCSI00 ***** ***
0
1 Device Enclosure
ENCL00 ***** ***
0
0 RS-485 Status Cont E57500
883
0
4
0
1 1.05 GB SCSI Disk D70100 99999
0
0
0
2 1.05 GB SCSI Disk D70100 99999
0
0
0
3 1.05 GB SCSI Disk D70100 99999
0
0
0
4 1.05 GB SCSI Disk D70100 99999
0
0
0
2 Device Enclosure
ENCL00 ***** ***
0
2 SCSI Port
SCSI00 ***** ***
0
1 Device Enclosure
ENCL00 ***** ***
0
0 RS-485 Status Cont E57500
625
0
4
0
1 1.05 GB SCSI Disk D70100 99999
0
0
0
2 1.05 GB SCSI Disk D70100 99999
0
0
0
3 1.05 GB SCSI Disk D70100 99999
0
0
0
4 1.05 GB SCSI Disk D70100 ***** ***
0
6 Tape Drive DDS-2 D T70100 ***** ***
0
2 Device Enclosure
ENCL00 ***** ***
0
6 RS-485 Port
R48500 ***** ***
0
7 RS-485 Port
R48500 ***** ***
0
8-358
VOS System Analysis Manual (R073)
list_boards
5 SCSI-ENET Controller
BU Bus
BA Bus A
BB Bus B
C0 Console Controller
C1 *Console Controller
K45000
E59300
E59300
533 39
***** ***
***** ***
***** ***
142 26
208 26
13
11
11
0
0
0
0
0
0
as:
In the following example, the list_boards request displays a board listing for the
CPUs on a Continuum-series module.
as: list_boards -board_type cpu -long
Module: %es#m9 (12 Slot Chassis, Continuum)
Slot 0 : CPU-Memory
Model Number:
G321
Sub Model Number:
0
Serial Number:
10070
Revision Level:
43
Artwork Revision:
0
Min Partner Rev:
10
State:
SM_RUNNING_PAIRED
Substate:
SM_NULL
Last Soft error at 80-01-01 00:00:00 edt
Total Soft Errors:
0
Current Soft Error count: 0
Soft Error Limit:
5
Prom Rev:
8
Minor Rev:
0
Status:
Active, Paired, Alive
Array Size:
1536MB.
Fault Data:
No Faults
Subassembly IDs:
Number Subassemblies 9
Subassembly #
model number
Serial Number
submodel number
revision
artwork rev
1
G805
10657
0
0
0
Subassembly #
model number
Serial Number
submodel number
revision
artwork rev
2
G805
10658
0
0
0
The analyze_system Command and Requests
8-359
list_boards
Subassembly #
model number
Serial Number
submodel number
revision
artwork rev
...
Memory Array size
iCache size
dCache size
Number cpus
Clock speed
Ecc Time
Ecc Address
Ecc Syndrome
3
G805
10669
0
0
0
1536
1024
1024
2
180
3
00000000
0
Wedgewood info
Callaway Status
Memory base
Memory size
Callaway id
Ecc time
Ecc address
Ecc syndrome
Ecc count
8-360
Subassembly record
00000002
00000000
512
00000000
00000000
0
Subassembly #
Model number
Serial Number
submodel number
revision
artwork rev
7
M707
11431
0
40
0
Callaway Status
00000002
Subassembly #
Memory base
00000000
Model number
Memory size
512
Serial Number
Callaway id
00000000
submodel number
Ecc time
00000000
revision
Ecc address
0
artwork rev
Ecc syndrome
Ecc count
...
Slot 1 : CPU-Memory
Model Number:
G321
Sub Model Number:
0
Serial Number:
10081
Revision Level:
43
Artwork Revision:
2
Min Partner Rev:
10
State:
SM_RUNNING_PAIRED
Substate:
SM_NULL
Last Soft error at 80-01-01 00:00:00 edt
Total Soft Errors:
0
Current Soft Error count: 0
Soft Error Limit:
5
Prom Rev:
8
Minor Rev:
0
Status:
Active, Paired, Alive
8
M707
11613
0
40
0
VOS System Analysis Manual (R073)
list_boards
Array Size:
Fault Data:
1536MB.
No Faults
Subassembly IDs:
Number Subassemblies 10
Subassembly #
model number
Serial Number
submodel number
revision
artwork rev
Subassembly #
model number
Serial Number
submodel number
revision
artwork rev
...
as:
1
M707
10281
0
0
0
2
G306
0
0
0
0
In the following example, the list_boards request displays a board listing for the
CPUs on an XA/R-series module.
as: list_boards -board_type cpu -long
Module: %sys#m1
(28 Slot Chassis)
Slot 28 : Central Processor
Model Number:
G862
Sub Model Number:
20
Serial Number:
3474
Revision Level:
55
Artwork Revision:
5
Min Partner Rev:
44
State:
SM_NULL
Last Soft error at 80-01-01 00:00:00 EST
Total Soft Errors:
0
Current Soft Error count: 0
Soft Error Limit:
0
Prom Rev:
42
Minor Rev:
0
Status:
Active, Paired, Alive
Fault Data:
No Faults
Slot 29 : Central Processor
Model Number:
G862
Sub Model Number:
20
Serial Number:
5022
Revision Level:
55
Artwork Revision:
5
The analyze_system Command and Requests
8-361
list_boards
Min Partner Rev:
44
State:
SM_NULL
Last Soft error at 80-01-01 00:00:00 EST
Total Soft Errors:
0
Current Soft Error count: 0
Soft Error Limit:
0
Prom Rev:
42
Minor Rev:
0
Status:
Active, Paired, Alive
Fault Data:
No Faults
....
as:
The following table describes the most important fields that appear in the output of the
previous examples.
8-362
Field
Description
Count
This field, when related to boards, lists the number of errors on the board since it
was inserted. When related to a fan unit, it indicates the number of times the fan
unit has failed, come back up to speed, and failed again. When related to a
battery unit, it indicates the number of successful power fail recoveries by this
module since the last bootload.
Code
Whenever a board fails, this field displays a code describing the type of failure.
When a code is displayed, it is interpreted at the bottom of the screen.
MBTF
If you issue this request with the -long argument, this field shows the mean
time between failures on the board.
VOS System Analysis Manual (R073)
list_disks
list_disks
8-
Purpose
This request displays information about the disk drives in the analyzed module or in the
system containing the analyzed module.
Display Form
---------------------------------- list_disks ----------------------------------all: n o
Command-Line Form
list_disks
[-all]
Arguments
* -all
<CYCLE>
Displays information about all the disks in the system. If you omit this argument,
information is displayed about only the disks in the analyzed module.
Explanation
The list_disks request displays information about disk drives on the analyzed
module, or about all disks in the system.
Examples
In the following example, the list_disks request displays information about the
disks on a module.
as:
list_disks
W Disk Name
L m1
m1.0
L m1_d1
m1_d1.0
ldtep
00502018
DDN
Disk Device Ids
status
22/01/01 23/01/01
duplexed,verify
25/01/01 24/01/01
duplexed,verify
00503918
The analyze_system Command and Requests
8-363
list_disks
600 queue entries, 0 queued.
Disk queue head @ 00228FB4
as:
In the following example, the list_disks request displays information about all disks
in the system. Note that DDN, disk device IDs, and status information about remote
disks is not available.
as:
list_disks -all
W Disk Name
L m1
m1
L m1_d1
m1_d1.0
R m2
R m2_d1
ldtep
00502018
DDN
Disk Device Ids
status
22/01/01 23/01/01
duplexed,verify
25/01/01 24/01/01
uplexed,verify
00503918
001F61EC
001F9938
600 queue entries, 0 queued.
Disk queue head @ 0022AEA4
as:
The following table describes the most important fields that appear in the output of the
previous examples.
8-364
Field
Description
Where (local or remote)
Local (on the current module)
Remote (on another module in the system)
ldtep
Logical disk table entry pointer
DDN
Duplex disk number
duplexed
If this notation is present, the disk is duplex.
verify
If this notation is present, the verify_flag field is turned on for the
disks entry in the disks table.
queue entries
The maximum number of disk I/Os that can be outstanding at any
one time
queued
The number of outstanding disk I/Os
Disk queue
head
The head pointer for the list of disk queue entries
VOS System Analysis Manual (R073)
list_dumps
list_dumps
8-
Purpose
This request displays the path names of all the dump files in a directory on a module.
Display Form
---------------------------------- list_dumps ----------------------------------module:
-dir:
Command-Line Form
list_dumps
[-module module_name]
[-dir path_name]
Arguments
* -module module_name
The module for which to list the dump files. The default is the users current module,
where analyze_system is being run.
* -dir path_name
The path name of a directory containing dump files. The default is
(master_disk)>Overseer>dumps. If you specify -dir without a path name,
the request lists the dumps in the current directory.
The analyze_system Command and Requests
8-365
list_dumps
Explanation
The list_dumps request displays the path names of all files with the suffix .dump that
are currently located in one of the following directories:
the (master_disk)Overseer>dumps directory of your current module (if you do
not specify the -module or -dir arguments)
the (master_disk)>Overseer>dumps directory on the specified module (if you
use the -module argument)
the specified directory (if you use the -dir argument)
This request displays the same output in both module mode and dump mode.
VOS assigns to each dump file a number, called the dump number, that you can use
in the delete_dump and use_dump requests. In the sample output, the dump
numbers are 1 and 2.
Examples
In the following example, the list_dumps request lists the dump files available on a
module.
as: list_dumps
Dumps for %sys#m1, located in %sys#m1>Overseer>dumps:
1) system.95-05-16.05:48:52.c.dump
2) system.95-07-12.07:15:43.c.dump
as:
8-366
VOS System Analysis Manual (R073)
list_file_activity
list_file_activity
8-
Purpose
This request displays cache manager I/O activity counts for each file, index, or
directory.
Display Form
----------------------------- list_file_activity ------------------------------0
-min_io_count:
-min_write_count: 0
Command-Line Form
list_file_activity
[-min_io_count number]
[-min_write_count number]
Arguments
* -min_io_count number
Displays objects which have an I/O count (number of reads and writes) greater than
or equal to the specified value. The I/O count is displayed in the I/O COUNT
column in the output. Values can be in the range from 0 to 4,294,967,295.
* -min_write_count number
Displays objects which have a write count greater than or equal to the specified
value. The write count is displayed in the WRITS STARTD column in the output.
Values can be in the range from 0 to 4,294,967,295.
Explanation
The list_file_activity request displays the cache manager I/O activity counts
for each file, index, or directory. These are the values used to enforce the I/O limits.
They can also be used to determine which entries have the most I/O activity.
The analyze_system Command and Requests
8-367
list_file_activity
Examples
In the following example, the list_file_activity request displays cache manager
I/O activity counts for each file, index, or directory on a module.
as: list_file_activity
File activity from ADT:
AxTE
DSK
I/O
#WRITS #WRITS NODE
ADDR
NUM
COUNT
STARTD PENDNG TYPE PATHNAME
C33A3A40 7
1
0
0 ADTE %es#sc3>products>stcp>1-364.71
+00>src
C2D9EF40 7
1
0
0 ADTE %es#sc3>products>stcp>1-364.71
+00
C2D6AE80 4
2
1
0 ADTE %es#m9>system>postoffice>ship_
+to_dir>mis
C0EFE380 11
3
0
0 ADTE %es#vpg>vos_pool>Joe_Smith>
+install
C2D48F80 4
11
6
0 AFTE %es#m9>system>tcp_os>telnet_lo
+gs>tlog807a.98-06-02.1
C0FCCAC0 4
11378
11345
0 AFTE %es#m9>system>accounting>raw_a
+cct_log.98-06-02
C0F94EC0 3
78
0
0 AFTE %es#libs>r13.4>base>incl>bio_s
+csi.incl.c
C2D642C0 4
110
57
0 AFTE %es#m9>system>db_prog_install_d
+ir>network>trace>list_drq.log
...
C0C96D00 4
1216
0
0 AFTE %es#m9>system>kernel_loadable_
+library>async_al.cp.pm
C0C87B00
4
5
1
0 AFTE %es#m9>Overseer>22.out
C0C86BC0
4
5
1
0 AFTE %es#m9>Overseer>21.out
C0C86940
4
5
1
0 AFTE %es#m9>Overseer>20.out
C0C85E40
4
5
1
0 AFTE %es#m9>Overseer>19.out
C0C85900
4
5
1
0 AFTE %es#m9>Overseer>18.out
C0BBC2C0
5
1884
408
0 ADTE %es#sc2
C0BBAF40
2
19
4
0 ADTE %es#
list_file_activity: The specified page is not present in your address space.
cate @ 04C60230
In the following example, the list_file_activity request displays cache manager
I/O activity for objects which have been accessed more than 150 times.
as: list_file_activity -min_io_count
File activity from ADT:
AxTE
DSK
I/O
#WRITS
ADDR
NUM
COUNT
STARTD
C0FCCAC0 4
11378
11345
+cct_log.98-06-02
C0E35440 4
374
308
+gs
C0E23AC0
4
2711
1803
C0E23900
4
491
292
C0C9F880
4
160053
159138
8-368
VOS System Analysis Manual (R073)
150
#WRITS NODE
PENDNG TYPE PATHNAME
0 AFTE %es#m9>system>accounting>raw_a
0 ADTE %es#m9>system>tcp_os>telnet_lo
0 ADTE %es#m9>system>queues>batch
0 ADTE %es#m9>system>queues
0 ADTE %es#m9>system>accounting
list_file_activity
C0C99980 4
1824
+library>telnet_al.cp.pm
C2DAD4C0
3
440
C2D839C0 2
2421
+l1.dbf
C0BF0700 4
21497
C0BEF7C0
4
573
C0CA2100 4
18551
+_server_queue
C0CA0AC0 4
6617
+queue
C0C97300 4
2934
+library>sos.pm
C0CA80C0 8
310
+14.1.0.dev.bm_pl168k.pm
C2D849C0 9
1536024
C3570E40 4
937
+ir>rdbms>mesg
...
as:
0 AFTE %es#m9>system>kernel_loadable_
299
1022
9081
0 ADTE %es#libs>r13.4>fixes
0 AFTE %es#sc1>db_prog>src_ctrl>contro
17710
0 ADTE %es#m9>system>command_library
0 ADTE %es#m9>Overseer
0 AFTE %es#m9>system>overseer.one_way
4384
0 AFTE %es#m9>system>overseer.server_
0 AFTE %es#m9>system>kernel_loadable_
0 AFTE %es#dsk14>r14.1>compiler_pool>
0
72
0 AFTE %es#sc4>db_prog>vos_cfg_idx.dbf
0 ADTE %es#m9>system>db_prog_install_d
326
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
AxTE ADDR
The AFTE, AXTE, or ADTE address
DSK NUM
The logical disk number for the object
I/O COUNT
The cate.disk_io_count, which is the number of I/O operations
performed on this object since it was activated. It is never reset, but
can wrap around. It is in the range of 0 to 4,294,967,295.
#WRITS STARTD
The number of disk writes that have been started for this object
(cate.num_diskw_started). It is in the range 0 to 4,294,967,295.
#WRITS PENDNG
The number of disk writes that are pending (started but not finished)
for this object. It is the difference between
cate.num_diskw_started and cate.num_diskw_done. It is in
the range 0 to 999999. The cache managers write throttle resets
value of cate.num_diskw_started and cate.num_diskw_done
to 0.
NODE TYPE
The type of object (file, directory, or index)
PATHNAME
The full path name of the object
The analyze_system Command and Requests
8-369
list_iop_dump_switch
list_iop_dump_switch
8-
Purpose
This request enables you to list dump types for one or all IOPs or IOAs on a module.
Display Form
--------------------------- list_iop_dump_switch --------------------------------iop_slot:
-ioa_slot:
Command-Line Form
list_iop_dump_switch iop_slot
[-ioa_slot number]
Arguments
* iop_slot
The IOP slot number for which to list the dump switch. If you do not specify an IOP
slot number, then the request lists all dump switches for a module.
* -ioa_slot number
Specifies an IOA slot number of an IOA for which to list the dump switches. If you
do not specify an IOA slot number, then the request lists all dump switches for an
IOP.
Explanation
The list_iop_dump_switch request enables you to list dump types for the
following:
one IOA
one IOP and all IOAs associated with that IOP
all IOPs and IOAs on a module
8-370
VOS System Analysis Manual (R073)
list_iop_dump_switch
Examples
In the following example, the list_iop_dump_switch request lists the dump switch
for a specified IOP slot and the IOA slot.
as:
list_iop_dump_switch 28 -ioa_slot 5
IOP 28 IOA 5 dump switch is NO_DUMP.
as:
In the following example, the list_iop_dump_switch request lists the dump
switches for all IOPs and IOAs on a module.
as:
list_iop_dump_switch 28
IOP 28 dump
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
IOP 28 IOA
as:
switch is DEVICE_ONLY.
0 dump switch is NO_DUMP.
1 dump switch is NO_DUMP.
2 dump switch is NO_DUMP.
3 dump switch is FULL_SYSTEM.
4 dump switch is NO_DUMP.
5 dump switch is DEVICE_ONLY.
6 dump switch is NO_DUMP.
7 dump switch is NO_DUMP.
8 dump switch is IOP_AND_SINGLE_IOA.
9 dump switch is NO_DUMP.
10 dump switch is NO_DUMP.
11 dump switch is IOP_AND_SELECTED_IOAS.
12 dump switch is NO_DUMP.
13 dump switch is NO_DUMP.
14 dump switch is NO_DUMP.
15 dump switch is NO_DUMP.
Related Information
For information about changing dump switches, see the description of the
change_iop_dump_switch request.
The analyze_system Command and Requests
8-371
list_iop_dumps
list_iop_dumps
8-
Purpose
This request lists the IOP dump files on a module.
Display Form
-------------------------------- list_iop_dumps ------------------------------module:
-dir:
Command-Line Form
list_iop_dumps
[-module module_name]
[-dir directory_path_name]
Arguments
* -module module_name
The name of the module for which you want to list IOP dumps. By default, the
request uses the current module.
* -dir directory_path_name
Specifies the directory path name of the directory containing IOP dumps. The
default is (master_disk)>Overseer>dumps. If you specify -dir without a path
name, the request lists the dumps in the current directory.
Explanation
Issue the list_iop_dumps request to list the IOP dump files on a module. You can
use the dump numbers displayed by this request to issue the use_iop_dump request.
8-372
VOS System Analysis Manual (R073)
list_iop_dumps
Examples
In the following example, the list_iop_dumps request lists the iop dumps on a
module.
as: list_iop_dumps
Dumps for %sys#m2, located in %sys#m2>Overseer>dumps:
1) iop4ia13.95-06-16.17:42:14.dump
11) iop4ia13.95-06-23.15:35:39.dump
2) iop4ia13.95-06-19.10:30:52.dump
12) iop4ia13.95-06-23.16:19:43.dump
3) iop4ia13.95-06-21.14:38:29.dump
13) iop4ia13.95-06-23.19:29:11.dump
4) iop4ia13.95-06-21.19:46:57.dump
14) iop4ia13.95-06-23.22:07:47.dump
5) iop4ia13.95-06-21.20:10:22.dump
15) iop4ia13.95-06-24.14:42:00.dump
6) iop4ia13.95-06-21.22:38:56.dump
16) iop4ia13.95-06-24.14:58:22.dump
7) iop4ia13.95-06-22.16:38:55.dump
17) iop4ia13.95-06-24.15:08:21.dump
8) iop4ia13.95-06-22.17:54:05.dump
18) iop4ia13.95-06-24.18:05:41.dump
9) iop4ia13.95-06-22.22:21:38.dump
19) iop4ia13.95-06-30.03:22:27.dump
10) iop4ia13.95-06-23.13:30:52.dump
20) iop4ia13.95-06-30.22:05:29.dump
as:
Related Information
For more information about the use_iop_dump request, see the description in this
manual.
The analyze_system Command and Requests
8-373
list_port_attachments
list_port_attachments
8-
Purpose
This request displays information about ports attached to the current process or in the
current dump.
Display Form
---------------------------- list_port_attachments --------------------------No arguments required. Press ENTER to continue.
Command-Line Form
list_port_attachments
Explanation
The list_port_attachments request displays information about ports attached to
the current process or in the current dump. Specify a process with the process
request or a dump with the use_dump request prior to using this request. This request
and the list_port_attachments command have very similar output.
Examples
In the following example, the list_port_attachments request lists the port
attachements on a module.
as: list_port_attachments
PORT 1 at 3FF6AEE8
Portname:
default_input
Type:
unknown
Porte indirects to port 5
PORT 2 at 3FF6AF20
Portname:
terminal_output
Type:
unknown
Porte indirects to port 5
PORT 3 at 3FF6AF58
8-374
VOS System Analysis Manual (R073)
list_port_attachments
Portname:
command_input
Type:
unknown
Porte indirects to port 5
PORT 4 at 3FF6AF90
Portname:
default_output
Type:
unknown
Porte indirects to port 5
PORT 5 at 80384DA0
Portname:
Pathname:
Type:
Flags:
Access mode:
I/O type:
PORT 6 at 82446160
Portname:
Pathname:
Type:
Flags:
Access mode:
I/O type:
PORT 7 at 82446220
Portname:
Pathname:
Type:
Flags:
Access mode:
I/O type:
....
as:
terminal
%sys#os_telnet_m2.27
unknown
attached,hold_attachment,no_wait,hold_opening
network_attachment,tasking,port_accounting
system_port,count_down_driver
Unknown access mode #0
port not open
_aaaY7bZ9ZLqa0Ksw
%sys#m1>system>error_codes.text
sequential file
attached,open,hold_attachment,hold_opening
port_accounting
indexed
input
_aaaY7bZ9ZLqa0KsO
%sys#m1>system>command_library>analyze_system.pm
fixed file
attached,open,hold_attachment,hold_opening
port_accounting,system_port
random
input
Related Information
For information about the list_port_attachments command, see its description in
the VOS Commands Reference Manual (R098).
The analyze_system Command and Requests
8-375
list_streams_params
list_streams_params
8-
Purpose
This request displays the STREAMS parameters that you can change.
Display Form
--------------------------- list_streams_params ------------------------param_name:
Command-Line Form
list_streams_params param_name
Arguments
* param_name
If specified, the name of the parameter whose value is to be displayed. If you do
not specify a value for this argument, the request displays all parameter values.
Explanation
In the command output, the columns present the following information. (For an
example, see the Examples section.)
The first column lists the full name of the parameter (for example, daemon wait
time). This field contains up to 32 characters. If the length of the parameter name
provides sufficient space, the parameter range appears in parentheses after the
name (for example, (1/1024 sec)).
The second column lists the short name of the parameter, which is used to set the
parameter (for example, (daemon_wait_time)).
The third column lists the current value of the parameter (for example, 61440).
8-376
VOS System Analysis Manual (R073)
list_streams_params
The following are STREAMS parameters; a detailed explanation follows the list.
daemon wait time
memory wait time
flush memory age
balance memory age
stale memory age
bufcall hysteresis
sys max heap threshold
sys max heap numerator
sys max heap denomin
LO max heap threshold
LO max heap numerator
LO max heap denomin
MED max heap threshold
MED max heap numerator
MED max heap denomin
HI max heap threshold
HI max heap numerator
HI max heap denomin
streams canput limit
streams daemon factor
streams max daemons
daemon wait time
The amount of time that the memory daemon waits when it is not processing. The time
is specified in milliseconds. The current default value is one minute (60 * 1000).
memory wait time
The maximum amount of time that the daemon waits when there are outstanding
bufcalls. This time is specified in milliseconds. The current default is 10 * 1000.
flush memory age
balance memory age
stale memory age
These three age parameters specify intervals over which a virtual memory (vm) region
containing memory blocks must remain untouched before STREAMS can make the
system call to free the memory. The interval used depends on the current state of the
system. The values for these parameters must be even numbers as there is a scaling
factor which is a multiple of two. The time specified for these parameters is as follows:
flush memory age is in milliseconds
balance memory age is in seconds
stale memory age is in hours
The analyze_system Command and Requests
8-377
list_streams_params
Typically, you do not need to change the values for these parameters.
bufcall_hysteresis
No bufcall callbacks are made until the value for bufcall_hysteresis is less
than the value for (threshold - bufcall_hysteresis). The default value is
10000.
Per-memory-pool STREAMS memory daemons handle memory configuration. Each
memory daemon sleeps and awakens once a minute to examine memory
configuration. The memory daemons determine memory configuration according to the
max heap parameters. These parameters are listed below with their default values.
sys max heap threshold = 0;
sys max heap numerator = 1;
sys max heap denominator = 8;
/* 1 to 4095 */
/* >= sys_numerator * 2 */
lo max heap threshold = 0;
lo max head numerator = 1;
lo max heap denominator = 16;
/* 0 to 4095 */
/* >= lo_numerator * 4 */
med max heap threshold = 0;
med max heap numerator = 1;
med max heap denominator = 32;
/* 0 to 4095 */
/* >= med_numerator * 4 */
hi max heap threshold = 0;
hi max heap numerator = 1;
hi max heap denominator = 4;
/* 0 to 4095 */
/* >= hi_numerator */
STREAMS allocates memory from the system for each application. STREAMS
allocates this memory based on the low, medium, or high limit, as specified by the
values for the following allocating parameters: BPRI_LO, BPRI_MED, or BPRI_HI.
When memory usage exceeds these limits, STREAMS starts to fail allocations.
8-378
VOS System Analysis Manual (R073)
list_streams_params
STREAMS uses the following algorithm to compute the limits.
validate max stream heap and replace invalid fields with defaults;
if sys_threshold > 0
sys_limit = MAX( hq_min_pages * 4096, sys_threshold );
else
sys_limit = 4096 * MAX( hq_min_pages,
(mm_pool_data.wireable_pages *
sys_numerator)
/ sys_denominator );
/ sys_denominator );
if hi_threshold > 0 && hi_threshold <= sys_limit
hi_limit = hi_threshold;
else
hi_limit = sys_limit - (sys_limit * hi_numerator)
/ hi_denominator;
if med_threshold > 0 && med_threshold <= hi_limit
med_limit = med_threshold;
else
med_limit = hi_limit - (sys_limit * med_numerator)
/ med_denominator;
if lo_threshold > 0 && lo_threshold <= med_limit
lo_limit = lo_threshold;
else
lo_limit = med_limit - (sys_limit * lo_numerator)
/ lo_denominator;
The remaining STREAMS parameters follow.
streams canput limit
STREAMS limits the number of canputs that can return true on the interrupt side in
order to prevent interrupts from taking too much time. This is checked before other flow
control processes so STREAMS does not consume too much CPU time when handling
an interrupt if we encounter a queue that is flowed off. The default is 100.
streams daemon factor
This parameter affects how deep the daemon work queue must be before
STREAMS can resume more than one daemon process. The current default is 3.
streams max daemons
The maximum number of STREAMS daemons per pool. The current default is 3. If you
need more information about this request, contact the CAC.
The analyze_system Command and Requests
8-379
list_streams_params
Examples
The first example presents the list_streams_params request issued without an
argument.
as: list_streams_params
Streams Parameters:
daemon wait time (ms)
(daemon_wait_time)
memory wait time (ms)
(memory_wait_time)
flush memory age (ms)
(flush_memory_age)
balance memory age (sec)
(balance_memory_age)
stale memory age (hrs)
(stale_memory_age)
bufcall hysteresis
(bufcall_hysteresis)
sys max heap threshold
(sys_threshold)
sys max heap numerator [1 - 4095] (sys_numerator)
sys max heap denomin [1 - (num*2)](sys_denominator)
LO max heap threshold
(lo_threshold)
LO max heap numerator [0 - 4095] (lo_numerator)
LO max heap denomin [1 - (num*4)](lo_denominator)
MED max heap threshold
(med_threshold)
MED max heap numerator [0 - 4095] (med_numerator)
MED max heap denomin [1 - (num*4)](med_denominator)
HI max heap threshold
(hi_threshold)
HI max heap numerator [0 - 4095] (hi_numerator)
HI max heap denomin [1 - num]
(hi_denominator)
streams canput limit [100]
(canput_limit)
streams daemon factor
(daemon_factor)
streams max daemons
(max_daemons)
60000 ms
10000 ms
250 ms
20
192
10000
0
1
8
0
1
16
0
1
32
0
1
4
100
3
3
The second example presents the list_streams_params request issued with the
argument daemon_wait_time.
as: list_streams_params daemon_wait_time
daemon wait time (ms)
(daemon_wait_time)
8-380
VOS System Analysis Manual (R073)
61440
list_tp_params
list_tp_params
8-
Purpose
This request displays the values of various TP debugging and tuning parameters.
Display Form
------------------------------- list_tp_params ------------------------------param_name:
Command-Line Form
list_tp_params param_name
Arguments
* param_name
If specified, the name of the parameter whose value is to be displayed. If you do
not specify a value for this argument, the request displays all parameter values.
Explanation
This request displays the values of TP debugging and tuning parameters. For
descriptions of the parameters and their values, see the set_tp_param description
later in this chapter.
The analyze_system Command and Requests
8-381
list_tp_params
Examples
The following example illustrates the use of the list_tp_params request.
as:
list_tp_params
TP Parameters:
transaction abort priority [0-9]
transaction abort wait time (ms)
lock manager [off/on]
deadlock detection [off/on/log]
lock conflict detection
min lock conflict time (ms)
syserr action when logging
performance diags
section tsi limit
section block limit
max resv blks per record [1-10]
max resv blks per key [1-4]
max resv blks for seq file [1-9]
8-382
VOS System Analysis Manual (R073)
(abort_priority)
(abort_wait_time)
(lock_manager)
(deadlocks)
(lock_conflicts)
(conflict_timeout)
(syserr_action)
(perf_diags)
(sect_tsi_limit)
(sect_blk_limit)
(max_blks_per_rcd)
(max_blks_per_key)
(max_seq_blks)
5
5000 ms
on
on
no_logging
5000 ms
2 (dont_display)
off
24
100
10
4
9
list_transaction_trace
list_transaction_trace
8-
Purpose
This request displays information about the specified number of recently completed
transactions.
Display Form
----------------------------- list_transaction_trace ---------------------------number: 2 0
-reverse: no
Command-Line Form
list_transaction_trace
[-number number]
[-reverse]
Arguments
* -number number
The number of transactions to display information about; the maximum value you
can specify is 200. The default value is 20.
* -reverse
<CYCLE>
Displays information about the most recent transaction first, followed in order by
information about each preceding transaction.
The analyze_system Command and Requests
8-383
list_transaction_trace
Examples
In the following example, the list_transaction_trace request displays
information about the last four transactions. The output contains the transaction ID and
the process ID for each transaction and indicates whether the transaction was aborted
or committed. If the transaction was aborted, the output displays the date and time of
the abort. If the transaction was committed, the output displays the date and time the
commit began.
as:
list_transaction_trace -number 4
Last 4 Transactions Completed
Transaction ID:
Process ID:
Transaction Committed:
Time completed:
1C71274D01116B65
01118032
User initiated commit. (finished)
95-02-13 16:21:17 EST
Transaction ID:
Process ID:
Transaction Committed:
Time completed:
1C71274D01116B66
0111829C
User initiated commit. (started)
95-02-13 16:21:17 EST
Transaction ID:
Process ID:
Transaction Committed:
Time completed:
1C71274D01116B66
0111829C
User initiated commit. (finished)
95-02-13 16:21:17 EST
Transaction ID:
Process ID:
Transaction Aborted:
Time completed:
as:
1C71274D01116B67
0111829C
User initiated abort.
95-02-13 16:21:18 EST
Related Information
For more information about transactions, see the descriptions of the dump_tpo,
dump_transaction, list_transactions, transaction_meters, and
transaction_meters requests.
8-384
VOS System Analysis Manual (R073)
list_transactions
list_transactions
8-
Purpose
This request displays information about a specific list of transaction state info structures
(TSIs) or about all TSIs active in the system.
Display Form
---------------------------- list_transactions ------------------------------list_addr:
-list:
-started_before:
-state:
all
-brief:
yes
-output_path:
Command-Line Form
list_transactions
list_addr
-list
[-started_before date_time_string]
[-state]
[-no_brief]
[-output_path file_name]
Arguments
* list_addr
A standard analyze_system address string representing the location of links that
head a list of TSIs. This argument and the -list argument are mutually exclusive.
The analyze_system Command and Requests
8-385
list_transactions
* -list
Specifies an internal queue. The values are as follows:
all
driver_list
flush_list
free_tsi_list
free_wait_list
idle_wait_list
<CYCLE>
module_wait_list
physical_wait_list
tpo_work_list
If you specify the value all, the request displays the transactions on each queue,
except for transactions on the free_wait_list and tpo_work_list queues.
To specify this argument, the current process must be the TPOverseer process
except when you specify the tpo_work_list value. When you specify the
tpo_work_list value, the current process can be any process. This argument
and the list_addr argument are mutually exclusive.
* -started_before date_time_string
Displays only TSIs for transactions started before date_time_string, which is
a standard date/time string.
* -state
<CYCLE>
Displays those TSIs in the indicated state. The values are all, aborted,
committed, locked, waiting, or running. The default value is all.
* -no_brief
<CYCLE>
Displays detailed information about the transaction, including the hash, work, and
net links and the FLI structures queued on the lock_list links. By default, the
list_transactions request displays basic information about the transaction,
including state, flags, and lock list information.
* -output_path file_name
Directs the output from the terminals screen to file_name. By default, the
request directs output to the terminals screen.
Explanation
This request displays a list of TSI structures and, optionally, a list of each of their
associated FLI structures.
8-386
VOS System Analysis Manual (R073)
list_transactions
Examples
An example of the list_transactions request follows. In this example, the
-list all argument displays the transactions on the various internal queues. Note
that this argument does not display transactions on the tpo_work_list queue.
as: list_transactions -list all
driver_list
There are no transactions on the driver_list.
flush_list
flush_list:
3FEA8780: 8038E9E0 8038E9F0 802BFDE0 802BFDF0
Transaction_state_info: 8038E9E0
Transaction ID:
1F8C4F56471183D9
Commit ID: 1F8C44C600008307
Started on module:
%se#m120 (71-17)
at: 96-10-08 20:44:06 EDT
Started by process:
54 on module %se#m120 (71-17) (process ID: 47118036)
State:
TID_NET_PHASE_2
Transaction flags:
take_tp_lock, file modified, on work list,
commit_started, start_log_is_set
rlocks:
2
wlocks:
1
blocked_flip:
null
lock_list:
8038EA50: 80381620 80381620 80381620 80381620
Transaction_state_info:
Transaction ID:
Started on module:
Started by process:
State:
Transaction flags:
rlocks:
wlocks:
blocked_flip:
lock_list:
802A48E0
1F8C4F56471183DA
Commit ID: 1F8C44C600008308
%se#m120 (71-17)
at: 96-10-08 20:44:06 EDT
50 on module %se#m120 (71-17) (process ID: 47118032)
TID_NET_PHASE_2
take_tp_lock, on work list, commit_started,
start_log_is_set
2
1
null
802A4950: 00000001 802A4950 00000001 802A4950
Transaction_state_info: 80395AA0
Transaction ID:
1F8C4F56471183DB
Commit ID: 1F8C44C600008309
Started on module:
%se#m120 (71-17)
at: 96-10-08 20:44:06 EDT
Started by process:
52 on module %se#m120 (71-17) (process ID: 47118034)
State:
TID_NET_PHASE_2
Transaction flags:
take_tp_lock, on work list, commit_started,
start_log_is_set
rlocks:
2
wlocks:
1
blocked_flip:
null
lock_list:
80395B10: 00000001 80395B10 00000001 80395B10
The analyze_system Command and Requests
8-387
list_transactions
Transaction_state_info:
Transaction ID:
Started on module:
Started by process:
State:
Transaction flags:
rlocks:
wlocks:
blocked_flip:
lock_list:
Transaction_state_info:
Transaction ID:
Started on module:
Started by process:
State:
Transaction flags:
rlocks:
wlocks:
blocked_flip:
lock_list:
80395C00
1F8C4F56471183DC
Commit ID: 1F8C44C60000830A
%se#m120 (71-17)
at: 96-10-08 20:44:06 EDT
53 on module %se#m120 (71-17) (process ID: 47118035)
TID_NET_PHASE_2
take_tp_lock, on work list, commit_started,
start_log_is_set
2
1
null
80395C70: 00000001 80395C70 00000001 80395C70
802BFDE0
1F8C4F56471183DD
Commit ID: 1F8C44C60000830B
%se#m120 (71-17)
at: 96-10-08 20:44:06 EDT
51 on module %se#m120 (71-17) (process ID: 47118033)
TID_NET_PHASE_2
take_tp_lock, on work list, commit_started,
start_log_is_set
2
1
null
802BFE50: 00000001 802BFE50 00000001 802BFE50
free_wait_list
There are no transactions
physical_wait_list
There are no transactions
module_wait_list
There are no transactions
idle_wait_list
There are no transactions
8-388
on the free_wait_list.
on the physical_wait_list.
on the module_wait_list.
on the idle_wait_list.
VOS System Analysis Manual (R073)
lock_meters
lock_meters
8-
Purpose
This request displays information about all of the kernel locks.
Display Form
---------------------------------- lock_meters -------------------------------address:
-name:
-member:
-reset: no
-report: yes
Command-Line Form
lock_meters address
[-name lock_star_name]
[-member member_lock_star_name]
[-reset]
[-no_report]
Arguments
* address
The address of a member, group, or single lock node.
Required
* -name lock_star_name
The name of a lock or set of locks on which the command is to report. The name
can be a star name. By default, the command reports on all locks.
* -member member_lock_star_name
The name of a member lock on which the command is to report. The name can be
a star name. By default, the command reports on all locks.
The analyze_system Command and Requests
8-389
lock_meters
* -reset
<CYCLE>
Resets the meters to the current values. Subsequent analysis is relative to the time
the meters were reset. By default, the meters are relative to the current bootload
session.
* -no_report
<CYCLE>
Generates a report on the lock specified. The command generates a report unless
you specify -no_report.
Explanation
The lock_meters request produces a detailed display of every operating system lock
currently in use. The output is arbitrarily ordered. All locks matching the report criteria
are reported, even those locks that have not been used during the metering interval.
If you give both the -reset and -report arguments, the command produces the
report first. Then it resets the meters.
Since the requests lock_meters and lock_summary share the same values for the
-reset argument, you can switch back and forth between these two requests while
interpreting the same metering interval.
Examples
The following examples show output from the lock_meters request.
Example 1
The following output is an example of a single lock that has been used as a write lock.
It has been locked 40 times in approximately 2358 hours. On average, it took 14.114
microseconds to acquire the lock. The total time to acquire the lock is insignificant.
VOS Release 13.1, analyze_system Release 13.1,
Current process is 310, ptep 40BE2420, John_Smith.Sales
Lock List Header lock @ 0030CC80
metering time
2357:58:56
n_write_locks
40
write_meters:
mean_time_to_lock
14.114 us (estimated)
total_time_to_lock
0.0 s (estimated)
Example 2
The following output is an example of a single lock that has been used only as a write
lock.
It has been locked 845 times in the metering interval. The locking code had to spin to
acquire the lock for 8 times out of the 845 locks. On average, it spun for 604.629
8-390
VOS System Analysis Manual (R073)
lock_meters
microseconds each of the 8 times. The average time to acquire the lock, out of all 845
times, is 20.08 microseconds. The total time to acquire the lock is insignificant.
paged lock cow stomach lock @ 0030CE80
metering time
2357:58:56
n_write_locks
845
write_meters:
n_spins
8(0.95% of locks)
mean_spin_time
604.629 us
mean_time_to_lock
20.080 us (estimated)
total_time_to_lock
0.0 s (estimated)
Example 3
The following output is an example of a lock that had both spins and waits. The system
first tries to acquire a lock by spinning; if it cannot do so, it waits. This lock had to spin
206,049 times; of those times, it had to wait 38,918 times. The mean spin time for each
of the 206,049 instances of spinning is 1.238 milliseconds. The mean wait time for each
of the 38,918 instances of waiting is 11.158 milliseconds. The average time to acquire
the lock over all 47,406,969 times it was acquired, is 28.963 microseconds. The system
has spent 1373 seconds acquiring this lock during the metering interval.
The n_false_notifies meter counts the number of times that a process waiting for
a lock woke up, only to discover that some other process had locked it first. In this
example, this happened 956 times, which is insignificant.
paged lock queue lock @ 0030C260
metering time
2357:58:56
n_write_locks
47406969
n_spins_for_lock_word
58672(0.12% of locks)
n_lock_word_failures
11970(20.40%of
n_spins_for_lock_word)
write_meters:
n_spins
206049 (0.43% of locks)
mean_spin_time
1.238 ms
n_waits
38918(0.08% of locks)
n_false_notifies
956(2.46% of n_waits)
mean_wait_time
11.158 ms
mean_time_to_lock
28.963 us (estimated)
total_time_to_lock
1373.0 s (estimated)
Example 4
In this example, the Files group lock holds all of the file locks, with one file member
lock for each active (open) file. The Files group lock has been locked 4,084,575
times, or once for each time a member lock has been created or deleted: each time a
file has been opened or closed. Of these times, there were 40 instances in which the
lock code had to wait, for an average of 14.007 milliseconds. The average time to
acquire the Files group lock is 14.633 microseconds, and the system has spent 59.8
seconds acquiring this lock in the metering interval.
The analyze_system Command and Requests
8-391
lock_meters
The members of the files group are the file locks themselves. Since the request was
invoked without the -member argument, the member locks are not shown, but all the
statistics are displayed in the section with the member info: label. In this example,
this section gives statistics on all the previous member locks, even those since
detached, as well as all the current member locks. As a group, the members have been
write-locked 43,081,060 times. They have been read-locked 35,429,104 times. There
have been 61,137 try_locks, which is a form of write -lock that never waits. The rest
of the items are similar to those in the previous examples.
NOTE
You can ignore values such as the following that are not
otherwise explained, as long as they are small relative to
the total number of locks: n_spins_for_lock_word,
n_lock_word_failures, and
n_try_lock_failures.
Files lock @ 0067F7E0
metering time
group info:
n_write_locks
n_spins_for_lock_word
n_lock_word_failures
n_spins_for_lock_word)
write_meters:
n_waits
mean_wait_time
mean_time_to_lock
total_time_to_lock
n_member_attaches
n_member_detaches
member info:
n_write_locks
n_read_locks
n_try_locks
n_try_lock_failures
n_spins_for_lock_word
n_lock_word_failures
write_meters:
n_waits
n_false_notifies
mean_wait_time
mean_time_to_lock
total_time_to_lock
read_meters:
n_waits
n_false_notifies
mean_wait_time
mean_time_to_lock
total_time_to_lock
8-392
VOS System Analysis Manual (R073)
2357:58:56
4084575
7 (0.00% of locks)
2(28.57 % of
40
14.007
14.633 us
459.8 s
2042375
2042200
(0.00% of locks)
ms
(estimated)
(estimated)
43081060
35429104
61137
9 (0.01% of n_try_locks)
34042 (0.04% of locks)
2214 (6.50% of n_spins_for_lock_word)
49302
2174
57.160
79.893
3441.9
(0.11% of locks)
(4.41% of n_waits)
ms
us (estimated)
s (estimated)
25012
591
8.226
20.293
719.0
(0.07% of locks)
(2.36% of n_waits)
ms
us (estimated)
s (estimated)
lock_meters
Related Information
See the description of the dump_lock and lock_summary requests for related
information on locks and lock meters.
The analyze_system Command and Requests
8-393
lock_summary
lock_summary
8-
Purpose
This request displays an ordered summary of important kernel lock statistics.
Display Form
--------------------------------- lock_summary -------------------------------name:
-member:
-threshold: 1
-reset:
no
-report:
yes
Command-Line Form
lock_summary [-name lock_star_name]
[-member member_lock_star_name]
[-threshold report_threshold]
[-reset]
[-no_report]
Arguments
* -name lock_star_name
The name of a lock or set of locks to be summarized. The name can be a star
name. By default, the command summarizes all locks.
* -member member_lock_star_name
The name of a member lock to be summarized. The name can be a star name. If
you do not supply member_lock_star_name, the command uses the value *. By
default, the command summarizes all members.
* -threshold report_threshold
The minimum lock percent shared value necessary for a lock to be listed in the
report. The minimum threshold you can specify is 0, which indicates you do not
want to exclude any locks. The maximum threshold you can specify is 99. The
8-394
VOS System Analysis Manual (R073)
lock_summary
default value for -threshold is 1, which causes the system to exclude all locks
that have less than a 1% contribution to system locking time.
* -reset
<CYCLE>
Resets the meters to the current values. Subsequent analysis is relative to the time
the meters were reset. By default, the meters are relative to the current bootload
session.
* -no_report
<CYCLE>
Generates a report on the specified lock. The command generates a report unless
you specify -no_report.
Explanation
The lock_summary request displays an ordered summary of important kernel lock
statistics.
The lock_summary request produces a report showing which operating system locks,
or groups of locks, are consuming the most time to be acquired. The locks are reported
in decreasing order. The report lists write locks separately from read locks. Also, it lists
group locks independently from their collection of group member locks.
The system sorts the report in descending order of the share of overall system locking
time. This value is reported in the % Share column. Overall system locking time is the
sum of the locking time for each lock. Locking time is the sum of the spin time and wait
time, if any, and estimated no-wait time, which is the time necessary to acquire locks
when no spinning or waiting is required. Locks that were not acquired during the
metering interval are not included in the report.
The report shows the percentage of metering time (the wall clock time) that was used
to acquire each lock. This value is reported in the % Busy column. The report also
shows the total number of lock acquisitions, the total number of seconds spent
acquiring locks, and the overall time to acquire a lock.
You can use the -threshold argument to exclude locks whose total locking time is
insignificant.
If you give both the -reset and -report arguments, the command produces the
report first, then it resets the meters.
Since the requests lock_summary and lock_meters share the same values for the
-reset argument, you can switch back and forth between these two requests while
interpreting the same metering interval.
The analyze_system Command and Requests
8-395
lock_summary
Examples
In the following example, the lock_summary request displays a write lock summary
report.
as: lock_summary
Write Lock Summary:
%
%
Mean Time
Lock Name
Lock Type
Address Share Busy To Lock(ms) Metering Time
--------------------- ------- ----- ---- ---------- -----------Wired Low Use Locks
group members 00313DF0 54.8
0.1
0.143
80:14:34
Disk group
group members 00315760 17.3
0.0
0.063
80:14:34
Paged Heap
single lock
005BF930
7.2
0.0
0.015
80:14:34
Wired Heap
single lock
00313D20
4.7
0.0
0.014
80:14:34
IOP_vos_lock_22 single lock
0053E5A0
3.9
0.0
0.014
80:14:34
IOP_iop_lock_22 single lock
0053E4A0
3.7
0.0
0.014
80:14:34
Task Event
group members 005C1A10
2.5
0.0
0.014
80:14:34
Event Control
group members 005BFAC0
2.4
0.0
0.041
80:14:34
Disk Allocators single lock
005C1E40
1.3
0.0
0.017
80:14:34
Total write locks:
Total write lock time:
Mean time/write lock:
14358220
594.7 s
0.041 ms
The following is an example of a read lock summary report.
Read Lock Summary:
Lock Name
----------Event Control
%
%
Mean Time
Lock Type
Address Share Busy To Lock(ms) Metering Time
------------- ------- ----- ----- ----------- ------------group members 005BFAC0 99.9
0.0
0.017
80:14:34
Total read locks:
Total read lock time:
Mean time/read lock:
as:
8-396
403000
7.1 s
0.018 ms
VOS System Analysis Manual (R073)
lock_summary
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
Lock Name
The column displays the name of the lock.
Lock Type
The type of the lock (the group lock, member lock, or single lock) or
the group members, when all the members of a single group are
summarized together.
Address
The address of the lock; for group members, the address of the group
lock.
% Share
The share of time, in percent, during the metering interval that this
lock contributes to the overall system locking time. This column adds
up to 100%.
% Busy
The percent of wall clock time during the metering interval that the
system spends locking this lock. This can add up to more than 100%,
since multiple processes can attempt to acquire the same lock
simultaneously.
Mean Time to
Lock
The average time to acquire this lock, or group of locks, during the
metering interval.
Metering Time
The length of time that this lock has been metered.
Related Information
Refer to the description of the dump_lock and lock_summary requests for related
information on locks and lock meters.
The analyze_system Command and Requests
8-397
log_alignment_faults
log_alignment_faults
8-
Purpose
This request logs all alignment faults on a module or those for a specified process.
Display Form
----------------------------- log_alignment_faults ----------------------------ptep:
-mode: on
-reset: yes
Command-Line Form
log_alignment_faults
[ptep pte_pointer]
[-mode]
[-no_reset]
Arguments
* ptep pte_pointer
Logs only alignment faults from the specified process table entry pointer (PTEP).
This value can be obtained from the who request. If you do not specify a PTEP, the
request logs alignment faults for all processes.
* -mode
<CYCLE>
When the value of this argument is on, the request logs faults. When the value of
this argument is off, the request does not log faults. The default value is on.
* -no_reset
<CYCLE>
Resets the alignment faults in the log to zero. By default, the alignment faults in the
log are reset to zero. More than one process at a time can reset the alignment
faults.
8-398
VOS System Analysis Manual (R073)
log_alignment_faults
Explanation
The log_alignment_faults request causes VOS to log the total number of
alignment faults that have occurred since the last reset. It also provides detailed
information about the last 255 alignment faults. The detail contains the PTEP and the
fault instruction register (FIR), which is a list of the addresses of the machine
instructions that faulted. The alignment fault log is stored in memory. The request does
not display any output.
An alignment fault occurs when an i860 RISC processor and/or one of the HPPA family
of RISC processors is asked to access a multiple-byte datum on a non-congruent
address. To prevent alignment faults, a two-byte datum must start on an even address,
a four-byte datum must start on an address that is evenly divisible by 4, an eight-byte
datum or floating-point number must start on an address that is evenly divisible by 8,
and a 16-byte reference must start on an address that is divisible by 16.
The VOS compilers will detect alignment problems and add bytes between data
structures so that the data structures start at the correct address. If you specify
-mapping_rules longmap/check, or use $longmap or $shortmap in the
structure definition, the compiler issues ADVICE messages about where padding
occurred. If you specify -mapping_rules shortmap, the compiler will generate extra
instructions to handle alignment faults so that the process need not call the VOS fault
handler at runtime. The default -mapping_rules value is site settable.
If an i860 RISC processor and or one of the HPPA family of RISC processors detects
an alignment fault, it invokes the VOS fault handler. This fault handler fixes the
instruction and returns to the program as if the alignment fault never happened. The
effect is that the instruction takes much more time to execute than if the instruction
reference were handled properly. When you issue the log_alignment_faults
request, alignment faults detected by the processor are logged.
NOTE
It is easiest to debug alignment faults generated by an
executing application if that application is compiled with
-table. Otherwise, the compilers optimizer may move
code, and the source code line number displayed with the
display_alignment_faults request may not be
correct. If concerns about decreased performance
prevent you from using -table, compile the application
with -full, which generates an assembly language
listing, and bind it with -map. These listings will help you
associate a fault instruction with a source code line
number.
The analyze_system Command and Requests
8-399
log_alignment_faults
You can use the log_alignment_faults request in conjunction with the
display_alignment_faults request to determine the source code line number
containing the instruction that caused alignment faults.
Related Information
See the description of the display_alignment_faults request. For more
information about detecting and resolving alignment faults, see the manuals Migrating
VOS Applications to the Stratus RISC Architecture (R288) or Migrating VOS
Applications to Continuum Systems (R407). For more information about the
-mapping_rules argument used by the VOS compilers, see the VOS Commands
Reference Manual (R098).
8-400
VOS System Analysis Manual (R073)
match
match
8-
Purpose
This request enables you to restrict the output displayed by the next requests to that
which matches the specified string. This request must be used prior to the request for
which you want to selectively display output.
Display Form
-------------------------------------- match ----------------------------------match_string:
-and:
-or:
-min_lines:
1
-and_first:
yes
Command-Line Form
match match_string
[-and string]
[-or string]
[-min_lines number]
[-no_and_first]
Arguments
* match_string
The character string to be matched. If you omit match_string, the default
matches everything and therefore displays the entire output of the next request.
Note that match_string is a caseless argument.
* -and string
Displays lines that contain this string and the match string.
* -or string
Displays lines that contain this string or the match string.
The analyze_system Command and Requests
8-401
match
* -min_lines number
Displays the specified number of lines starting with the line in which a match was
found. If another match is found on a line fewer than number lines from the
previous match, the match request restarts the line count. You cannot specify a
value of less than 1. The default value is 1.
* -no_and_first
<CYCLE>
Specifies the order of precedence when both the -and string and -or string
arguments are specified. If you specify yes, the request matches output lines
containing both the match_string and -and string values, or just -or
string. If you specify no, the request matches output lines containing either the
match_string or -or string values, and also containing -and string. The
default value is yes.
Explanation
The match request displays matching lines of output from the request issued
subsequent to match.
Examples
In the following example, the match request lists instances of the word heap in the
output of the dump_pdr request.
as:
match heap; dump_pdr
pdr_heap_ptr
process_heap_ptr
user_heap_ptr
pdr_heap_size
3FFAA000
3FFAA060
0048C000
00040000
as:
In the following example, the match request lists instances of the word stack in the
output of the dump_pdr request.
as:
match stack; dump_pdr
stack_base
3FF2A000
default_output_stack_depth0
default_output_stack
0, 0, 0, 0, 0, 0, 0, 0
n_stacks
1
stack_len
00008000
as:
8-402
VOS System Analysis Manual (R073)
monitor_net_trace
monitor_net_trace
8-
Purpose
This request traces StrataLINK network activity over a period of time.
Display Form
------------------------------ monitor_net_trace ----------------------------scan_interval: 1000
-output_path:
Command-Line Form
monitor_net_trace
[-scan_interval milliseconds]
[-output_path path_name]
Arguments
* -scan_interval milliseconds
Specifies how often the request is to collect tracing information. The default is 1000
milliseconds or 1 second.
* -output_path path_name
Specifies the path name of a file in which to store the output of this request. If you
do not specify a value for this argument, the request displays its output on your
terminal screen.
Explanation
The monitor_net_trace request displays the same output as the
display_net_trace request, except that monitor_net_trace displays new
information at a specified interval, whereas the display_net_trace request
displays information for only one moment in time. In contrast to the
display_net_trace request, the monitor_net_trace request has the following
restrictions.
The analyze_system Command and Requests
8-403
monitor_net_trace
It can only run in module mode (online mode is the terminology used by the
request).
It can only run on the module on which the analyze_system command is
running.
It can only send output to a file or terminal on the current module running the
analyze_system command.
Because the request only runs on and sends output to the current module on which the
analyze_system command is executing, the monitored link traffic is not affected by
the request.
Examples
The output of the monitor_net_trace request is similar to that of the
display_net_trace request. In the following example, the monitor_net_trace
request StrataLINK network activity. Note that the boldfaced capital letters have been
added as an aid to describing each of these columns.
as: monitor_net_trace
TRACE MODE = auto_stop
A B C D E
F
0 1 S O ACPT
372
8 1 S I NOM
106
15 2 S O ACPT
110
21 2 S I NOM
92
29 1 S O ACPT
334
43 1 S I NOM
78
50 2 S O ACPT
134
....
as:
M2
M2
M2
M2
M2
M2
M2
G H
I
J
nreq 18106->31001 rpt 00
data 31003->18106 rpt 00
nreq 18106->31001 rpt 00
data 31003->18106 rpt 00
nreq 18106->31001 rpt 00
data 31003->18106 rpt 00
nreq 18106->31001 rpt 00
tid
tid
tid
tid
tid
tid
tid
K
B61F-0000
B61F-0000
B621-0000
B621-0000
B622-0000
B622-0000
B623-0000
L
#0001
#0001
#0001
#0001
#0001
#0001
#0001
The following table describes the columns that appear in output of the preceding
example.
(Page 1 of 4)
8-404
Column
Description
Relative time in milliseconds. The first packet trace displayed is always shown as
relative time 0. Subsequent packet times are relative to the first trace. You can
use this information with the interrupt_meters request to determine the
length and cause of delays.
The link or ring number, in the range from 1 to 8.
The type of ring: subring (S) or backbone ring (B).
The direction of data in relation to the reporting module: input (I) or output (O).
VOS System Analysis Manual (R073)
monitor_net_trace
(Page 2 of 4)
Column
Description
The reply status returned by VOS.
NOM (no match): This value is normally traced for incoming packets because
the trace occurs before the receiving link controller changes the packet status
to ACPT. A value NOM for an output packet trace means that no station on
the ring recognized the destination station address.
ACPT (accept): The receiving station has received the packet without error.
BNR (buffer not ready): The receiving station did not have a receive chain for
the appropriate size packet pool at the time the packet arrived despite
repeated retries.
TMR (too many retries): The transmitting station has exceeded the boards
error retry threshold for a particular socket.
DEAD: VOS is no longer running on the destination station.
The length of the data portion of the packet.
Possible protocol types (most frequent listed first).
M2: message exchange protocol version two. The message exchange
protocol is that used to implement most cross-module kernel services
(s$ calls).
FQ: fast queue protocol (direct queues)
SI: station identification
NS: notify shadow protocol, cross module event notification.
ME: old message exchange protocol (prior to Release 11)
LD: link diagnostics protocol
TI: time protocol
TU: tourist protocol, used to determine network topology
TR: trace control protocol
HT: hardware self test protocol
BM: boom protocol, network boomerang testing
TF: test traffic protocol
LB: link boot protocol
UK: unknown packet type (for cross-release compatibility)
The analyze_system Command and Requests
8-405
monitor_net_trace
(Page 3 of 4)
8-406
Column
Description
The following are subtypes type for the ME and M2 protocols.
nreq (new request): A client sends this packet to initiate a new message.
Sometimes this packet also contains data.
redy (ready): A server sends this packet to indicate that it is ready to receive
data.
data (data): Additional data sent with a request from client to server when
the 4096-byte nreq packet is not large enough to hold the entire request.
iwat (iwait): Sent by a server in response to a wory if the server is currently
waiting for input.
wory (worry) : Sent by a client to a server when the client has not received a
timely answer. If the server is currently processing the request, it ignores the
wory and sends the data packet. If a server has already replied to the
network transaction, it sends terr. If a client receives no response after
sending repeated wory packets, it reports a worry timeout to the
syserr_log.
terr: Transaction ID error, also called TIDERR in error log messages.
stop (stop)
busy (busy)
dead (dead)
The following are subtypes of the SI protocol.
iah (I am here)
sip? (Unknown SI protocol subtype)
The following are subtypes of the FQ protocol.
rqst (request)
rply (reply)
ack (acknowledge)
nosv (no server)
abrt (abort)
stat (status)
The following are subtypes for the LD protocol.
strt/istr (start, intensive start)
ack/iack (acknowledge, intenstive acknowledge)
data/idat (data, intensive data)
age/inot (age data, intensive notify)
err/ierr (errors detected)
The following are subtypes for the TI protocol.
set/seta: Set time on one or all modules
chk/chka: Check time on one or all modules
The following is the subtype for the NS protocol.
ntfy: Notify a shadow event
The following is the subtype for TU protocol.
tour: Determine neighbor stations
The following is the subtype for TR protocol.
stop: Stop the trace (used to coordinate traces on sending and receiving
stations)
VOS System Analysis Manual (R073)
monitor_net_trace
(Page 4 of 4)
Column
Description
Packet address information, shown as SSsss->DDddd.
SS: Source station address (in hexadecimal)
sss: Socket on the sending station (in hexadecimal)
DD: Destination station address (in hexadecimal)
ddd: Destination socket address (in hexadecimal)
In the case of ME and M2 nreq packets, ddd is the reserved socket to which the
request is directed. Socket numbers for all other ME and M2 packets are regular
socket numbers.
Note that station numbers are not necessarily the same as module numbers.
The relationship between the two can be seen using the dump_nct request or
the dump_net_info request with the -nct option
The repeat switch. 1 indicates software and 2 indicates hardware.
The transaction ID number for the client and for the server. The number on the
left hand side of the arrow is the client TID, and the number on the right hand
side of the arrow is the server TID.
The sequence number of the packet for disassembly and reassembly.
Stopping Output
When you issue the request and it sends output to the controlling terminal, you can
terminate the request by pressing the key that invokes the CANCEL or BREAK function.
When you issue the request and it sends output to a file, you can terminate the request
by pressing the key that invokes the BREAK function.
Note that pressing the key that invokes the BREAK function does not terminate
analyze_system execution or your process.
Possible Anomalies in Trace Output
The net_trace is captured by the net_interrupt routine of net_driver in the
kernel. The information is placed in a circular trace buffer. Periodically (no earlier than
the -scan_interval specified), monitor_net_trace will transfer the entire
net_trace buffer to the analyze_system address space and then attempt to
resume display from the oldest un-displayed trace entry until it either wraps around in
the buffer or reaches the last entry written. It then sleeps for the -scan_interval and
then repeats.
The analyze_system Command and Requests
8-407
monitor_net_trace
Because of the method used for displaying the net trace, you may notice one or more
of the following problems.
If the -scan_interval is too long (or if analyze_system is unable to get
enough CPU time in a timely manner), the buffer might wrap before it is retrieved.
If the -scan_interval is too short, excessive CPU time could be used by the
analyze_system process to retrieve no new data or to retrieve less than an
optimal amount of data. The optimal amount of data is just less than all entries in
the buffer being new, undisplayed entries.
Time stamps are taken as the least significant 31 bits of a 48-bit
jiffy_date_time; internally, they are treated as signed 31-bit numbers, and the
start_time of the monitoring period is subtracted from all displayed values.
Because the sign bit of these values can be different, the display routine
occasionally thinks that the time has wrapped or gone negative, and displays the
time as 9999999999.
Related Information
For more information on StrataLINK network tracing, see the descriptions of the
display_net_trace and set_net_trace requests.
8-408
VOS System Analysis Manual (R073)
page_meters
page_meters
8-
Purpose
This request displays the page meters.
Display Form
---------------------------------- page_meters --------------------------------reset: n o
-report: yes
Command-Line Form
page_meters
[-reset]
[-no_report]
Arguments
* -reset
<CYCLE>
Resets the page meters to 0. When you reset the meters, the request does not
display a report unless you specify that a report should be displayed. By default,
the meters are relative to the current bootload session.
* -no_report
<CYCLE>
Specifies that the request not display output. By default, the request displays
output.
Explanation
All memory paging is handled by the VOS page control software. Page control monitors
all pages in physical memory that can be paged.
VOS tracks physical memory using arrays of memory map entries (MMEs). Each page
of physical memory has one MME associated with it. There MMEs are kept in two lists,
which are maintained by page control.
The analyze_system Command and Requests
8-409
page_meters
The free list contains all the physical memory pages that do not belong to any
process.
The used list contains all the currently in-use pages in physical memory.
The display_system_usage and list_users commands can also give you
general information about page faults. The Min at PF field in the output of the
display_system_usage command shows the total time the modules CPUs spent
processing page faults. The Page faults,/sec field displays the total number of
page faults that have occurred on the module. If the command reports fewer than three
to five page faults per second, paging is not a problem.
The list_users command with the -admin page_faults argument lists the total
page fault time (PFTIME) and the number of page faults (PF) for each process since
the machine was booted. This command also enables you to display changing pagefault information at regular intervals. To lessen the number of page faults, begin with
the process that is generating the most page faults. Note that this command does not
also meter page fault activity as disk activity.
When you specify page_meters -reset, it affects only the current process
executing analyze_system and the page_meters request. The command records
the reset in the file (home_dir)>as_meter_file. If more than one process shares
the same home directory, only one process at a time can reset a metering request. If
the file as_meter_file exists, it is reopened when you re-enter analyze_system.
To use the meters set since boot time, delete the file as_meter_file.
Examples
In the following example, the page_meters request displays paging information for a
Continuum-series module.
as: page_meters
Total metering time:
49:55:22
Total pages:
Wired pages:
Temp-wired pages:
Free pages:
Kernel in-memory pages:
Paged in-use pages:
131072
7476
2886
113396
744
7306
Page faults:
Kernel page faults:
Average page fault time:
8-410
VOS System Analysis Manual (R073)
Total
ATB/msec
1235193
145
648
277348
1.34 msec
page_meters
New pages:
Reads:
Disk:
Null:
No I/O:
Reclaimed:
Writes:
Posts:
Posts queued:
Max post queue depth:
Total
556172
773370
66922
577650
128798
2918
495
67417
118
2
ATB/msec
323
232
2685
311
1395
61590
363074
2665
1523067
Get memory
Free taken:
memory waits:
Total
712272
0
ATB/msec
252
Paging daemon
Evictions:
Evict writes:
Total
0
0
ATB/msec
Virtual buffer wires:
Virtual buffer unwires:
PMB inits:
PMB destroys:
PM disconnects:
Physical frames:
Map clears:
Clears w/trailers:
APTEs in use:
APTE allocates:
APTE frees:
PME finds:
PME creates:
2616
2452
68701
73296
1683
1630
10117
106786
110258
17764
648274
943119
0
277
190
12920
790455
777535
32960999
2492864
VM File Operations
Trailer activations:
Trailer deactivations:
Trailer connects:
Trailer disconnects:
Pages activated:
Total
9248
8716
12874
12687
308481
Paging Partition
Total pages:
Free pages:
Minimum free pages:
100000
94322
82561
227
231
5
72
ATB/msec
19433
20619
13960
14165
The analyze_system Command and Requests
8-411
page_meters
PC Lock Meters
Lock count:
Unlock count:
Loop count:
Average loop time:
5154719
5154718
26617
1.19 msec
as:
The following table describes the most important fields in the output of the preceding
example.
8-412
Field
Description
Total pages
The total number of physical pages.
Wired pages
The number of wired pages locked in main memory.
Temp-wired pages
The number of temporarily wired pages in memory, e.g., the cache
manager.
Free pages
The number of free pages (physical pages that are not currently in
use by any process) in memory.
Kernel in-memory
pages
The number of VOS kernel pages in memory.
Paged in-use
pages
The number of pages currently on the list of used pages in memory.
Page faults
The total number of page faults.
Avg page fault
time
The average time to satisfy a page fault.
Get memory
The number of times processes needed a page of memory.
Free taken
The number of pages of memory found on the free list.
Evictions
The number of times the memory manager process took a page of
memory from a process.
Laps
The number of times the command went through all of memory.
VOS System Analysis Manual (R073)
pme_status
pme_status
8-
Purpose
This request displays information about the process map entry (PME) or entries of the
current process on the analyzed module.
Display Form
----------------------------------- pme_status --------------------------------vpn:
last_vpn:
-kernel: no
Command-Line Form
pme_status [vpn]
[last_vpn]
[-kernel]
Arguments
* vpn
The virtual page number. If you omit vpn, all pages in the process map entry of the
current process are displayed. If you supply a value for vpn, the information for only
the specified virtual page is displayed. If you specify a page number of the kernel,
the display shows the process map entry of that page in the kernel.
* last_vpn
The last virtual page number for which process map entries will be displayed.
* -kernel
<CYCLE>
Specifies that process map entries only from the kernel be displayed. If you specify
no, the request displays process map entries only from the user space. The default
value is no.
The analyze_system Command and Requests
8-413
pme_status
Explanation
The dump_pme request displays the state of a page of the virtual memory of the current
process. The flags describe the state of the process map entry (PME), the active page
table entry (APTE), or the memory map entry (MME).
Examples
In the following example, the pme_status request displays process map entry
information for a module.
as: pme_status
Processing PMEs for pte @ C1AC0B80
PME
VPN Flags
00002
00003
00004
00005
00006
00007
00008
00009
0000A
0000B
0000C
0000D
0000E
0000F
00010
00011
00012
00013
00014
00015
00016
00017
00018
00019
0001A
0001B
0001C
0001D
0001E
0001F
....
as:
8-414
ACC
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
code
APTE
Flags
M
M
M
M
M
M
M
VOS System Analysis Manual (R073)
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
APTE
address
00007D81
000005D2
00005397
01026FE1
01026FE3
01026FE4
01026FE5
01026FE6
00006CFE
0000036C
01026FE9
0000229F
00006721
01026FEC
01026FED
01026FEF
01026FF0
01026FF1
01026FF2
01026FF3
01026FF4
01026FF5
01026FF6
01026FF7
01026FF8
01026FF9
01026FFA
01026FFB
01026FFC
01026FFD
rc
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
MME
flags
C
C
C
A
A
A
MME
address
01026FDE
01026FDF
01026FE0
C
C
A
A
01026FE7
01026FE8
C
C
A
A
01026FEA
01026FEB
pme_status
The following table describes the values that appear in each column of the output of
the preceding example.
Entry
Column
Description
PME
VPN
The virtual page number of the page
Flags
Possible values are:
C - copy on write
F - fence
P - patched
W - wired
ACC
The access code for the page
Flags
Possible values are:
B - shared buffer
C - cache manager
D - must dump
E - I/O error
F - forked page
M - memory assigned
P - per process
W - waiting
k - kernel page
o - CPU patch
v - virtual memory flush
address
The address of the page, memory if M, or else a disk address of the
backing store
rc
The reference count
flags
Possible values are:
A - access code for page (XA/R-series modules only)
C - connected
I - I/O in progress
M - modified
P - page fault
R - Release MME
U - user I/O request
W- wired
f - evict free
u - used
w - write
address
For in-memory pages, the disk address of the backing store
APTE
MME
The analyze_system Command and Requests
8-415
power_summary
power_summary
8-
Purpose
This request displays information about the power loading on the analyzed module and
the communications buses.
Display Form
---------------------------------- power_summary -------------------------------long: n o
Command-Line Form
power_summary
[-long]
Arguments
* -long
<CYCLE>
Expands the display of information to include a listing of the board types and the
power required by each. If you omit this argument, VOS displays a brief report
containing bulk power loading and communications bus loading.
Explanation
The power_summary request displays information about the power loading on the
analyzed module and the communications buses.
Continuum-series modules do not have even/odd bulk loading. On Continuum-series
modules, the power_summary request reports bulk loads separately for main chassis,
IOP boards and BIO boards. The main chassis bulk load consists of the board power
for CPU, BIO, IOP, RECC and fans. The IOP bulk load consists of the power
consumption for all the IOAs hanging off of it (each logical IOP has a separate bulk
load). The BIO bulk load consists of the power consumption of the disks/tapes hanging
off of it (each logical BIO has a separate bulk load).
8-416
VOS System Analysis Manual (R073)
power_summary
Since an I/O board may have connections to several different expansion cabinets on a
Continuum-series module, the request cannot accurately report the bulk power for
each cabinet and instead separately reports the bulk load for each I/O board.
NOTE
For Continuum 600-series modules, the request does not
report the power used by IOAs that are installed in the
main chassis as part of the main chassis bulk load.
Instead, IOA power usage is reported as part of the bulk
load of the I/O board to which the IOA is connected.
Examples
In the following example, the power_summary request displays power information in
brief for an XA/R-series module.
as: power_summary
Power Loading Summary for Module: %sys#m1
(28 Slot Chassis, Model 2)
|---Bulk Power (Watts)--|
IOP/
Comm
Even Odd
Bus Device
Bulk Power Totals (Watts)
2149.0 2144.0 386.2
0
(A)
(B)
(C)
(D)
Even Bulk Loading = A + C =
2535.2 or101.4%of max of 2500.0 watts
Odd Bulk Loading = B + C =
2530.2 or101.2%of max of 2500.0 watts
Total Bulk Loading = A + B + C = 4679.2
**
**
**
**
IOP
IOP
IOP
IOP
slot:
slot:
slot:
slot:
04
06
08
10
bulk_load
bulk_load
bulk_load
bulk_load
=
=
=
=
261.20
193.00
162.60
139.00
or
or
or
or
54.4%
40.2%
33.8%
28.9%
of
of
of
of
max
max
max
max
480.00
480.00
480.00
480.00
as:
In the following example, the power_summary request displays power information in
the long format for a Continuum-series module. The long format includes slot, board
type, model number, and bulk power for each board.
The analyze_system Command and Requests
8-417
power_summary
as: power_summary -long
Power Loading Summary for Module: %sys#m3
(20 Slot Chassis)
|---Bulk Power (Watts)----|-Comm Bus--|
IOP/
Slot
Board Type
Model
Comm
| Load (Watts)
Even
Odd
Bus Device| Even
Odd
00 CPU-Memory
G745
50.0
02 IO Processor
K600
50.0
04 SCSI-ENET Controller
K450
120.0
01 SCSI Port
SCSI
01 Device Enclosure
ENCL
00 RS-485 Status Controll E575
0.0
01 1.05 GB SCSI Disk Driv D701
40.0
02 1.05 GB SCSI Disk Driv D701
40.0
03 1.05 GB SCSI Disk Driv D701
40.0
04 1.05 GB SCSI Disk Driv D701
40.0
02 Device Enclosure
ENCL
02 SCSI Port
SCSI
01 Device Enclosure
ENCL
00 RS-485 Status Controll E575
0.0
01 1.05 GB SCSI Disk Driv D701
40.0
02 1.05 GB SCSI Disk Driv D701
40.0
03 1.05 GB SCSI Disk Driv D701
40.0
04 1.05 GB SCSI Disk Driv D701
40.0
06 Tape Drive DDS-2 DAT ( T701
40.0
02 Device Enclosure
ENCL
06 RS-485 Port
R485
07 RS-485 Port
R485
05 SCSI-ENET Controller
K450
50.0
36 Console Controller
E593
50.0
37 Console Controller
E593
50.0
-- Chassis & BBU
---15.0
15.0
-- Fans & AC Control
---0.0 124
------ ------ -------Bulk Power Totals (Watts)
335.0
65.0
0.0 124
(A)
(B)
(C)
(D)
Even
Odd
Total
Even
Odd
DC Bulk
DC Bulk
DC Bulk
Cabinet
Cabinet
Loading
Loading
Loading
AC Power
AC Power
Total Cabinet AC
8-418
= A + C
= 335.0
= B + C
= 65.0
= A + B + C = 400.0
= A + C + D = 459.0
= B + C + D = 189.0
or18.6%of max of 1800.0 watts
or3.6%of max of 1800.0 watts
or25.0%of max of 1600.0 watts
or26.2%of max of 1750.0 watts
or10.8%of max of 1750.0 watts
Power = 524.0
** IOP slot: 02 bulk_load
= 0.00 or 0.0% of max 960.00
** BIO slot: 04 bulk_load
= 360.00
VOS System Analysis Manual (R073)
process
process
8-
Purpose
This request sets the analyze_system addressing context for subsequent
process-specific requests.
Display Form
------------------------------------- process ---------------------------------process_number:
-user:
-process_name:
Command-Line Form
process process_number
[-user user_name]
[-process_name process_name]
Arguments
* process_number
Either the number of the process to be set as the analyzed process, or one of the
following values: cpuN, interrupt, user, or parent.
* -user user_name
The name of the user whose process is to be set as the analyzed process. It is not
necessary to include the group name of the user. You can specify just the person
name; if more than one process matches the person name, VOS selects the
process with the lower process number.
If you specify -user without a value for user_name, the request uses the name
of the user whose process is executing analyze_system.
* -process_name process_name
The name of the process to be set as the analyzed process.
The analyze_system Command and Requests
8-419
process
Explanation
The process request defines the process context to be used in resolving per-process
addresses. Requests which use this context include display_memory_usage,
display_process_info, dump_pte, and stack. In general, any virtual address in
user address space requires that this command be used to specify which user address
space to use.
The who request displays a list that includes the process numbers and names and user
names of all processes on the analyzed module or dump.
If you do not specify any of the arguments, this request either displays the number of
the current analyzed process or issues a message that no analyzed process is defined.
The following list describes which process is set as the analyzed process when you use
one of the specified strings for the process_number value.
Fields
Description
cpuN
The process running on CPUN, where N is an integer representing a valid CPU
number.
cpu0
The process running on CPU0
user
The process running when the analyzed dump was taken (if in dump mode), or
the process executing the analyze_system command (if in module mode)
parent
The parent process of the analyzed process
You can specify the -user argument with a value for user_name that matches the
user names of several processes, or the -process_name argument with a value for
process_name that matches the process names of several processes. In either case,
VOS selects the matching process with the lowest process number.
This request is effective only within the current invocation of the mode in which the
request is given. For example, an analyzed process that you set while you are working
in module mode is no longer effective if you switch to dump mode, if you change the
analyzed module, or if you issue another use_module request for the same module.
Examples
In the following example, the process request displays information about process
number 9. Note that the Current process field indicates the currently analyzed
process and not the currently executing process.
as:
process 9
Using nonrunning process.
Current process is 9, pte 001087CE, Overseer.System (BridgeServer)
as:
8-420
VOS System Analysis Manual (R073)
process
In the following example, the process request displays information about the process
on CPU2.
as:
process cpu2
Using process on CPU2.
Current process is 50, ptep 005987AA, Overseer.System (MailHandler1)
as:
In the following example, the process request displays information about a specified
users process.
as:
process -user Smith
Using nonrunning process.
Current process is 25, ptep 006AE88A, Smith.Sales
as:
In the following example, the process request displays information about a specified
process name.
as:
process -process_name pre-login
Using nonrunning process.
Current process is 5, ptep 001B9B22, PreLogin.System (pre-login)
as:
NOTE
The first line of information that this request displays
shows the current state of the process as running or
nonrunning.
The analyze_system Command and Requests
8-421
quit
quit
8-
Purpose
This request exits the analyze_system command and returns to command level.
Display Form
------------------------------------- quit ------------------------------------No arguments required. Press ENTER to continue.
Command-Line Form
quit
Explanation
The quit request exits the analyze_system command and returns to command
level. Note that the analyze_system -quit argument has the same effect.
Related Information
For information about the analyze_system -quit argument, see the description of
the analyze_system command.
8-422
VOS System Analysis Manual (R073)
scan_area
scan_area
8-
Purpose
This request displays information about the contents of a heap, including header
information and a summary of the types of blocks in the heap.
Display Form
------------------------------------ scan_area --------------------------------area_address:
-heap:
-sort:
size
-memory_pool: 0
Command-Line Form
scan_area area_address
[-heap heap_name]
[-sort sort_order]
[-memory_pool sort]
Arguments
* area_address
The address of a memory area. You must specify a value for either this argument
or the -heap argument. You cannot select both. (For information on address
formats, see Chapter 3.)
* -heap heap_name
<CYCLE>
Specifies the heap to display information about. The following table describes the
values for heap_name.
The analyze_system Command and Requests
8-423
scan_area
Value
Description
paged
The paged heap
wired
The wired heap
comm
The communications heap
I/O
The I/O heap. XA/R: 24-bit addressing
Continuum: at least 32-bit addressing
high_I/O
High physical memory I/O heap. XA/R: 29-bit addressing
Continuum: Not applicable.
pdr
The PDR heap
user
The user heap
old_user
The old or original user heap, which contains data allocated and
freed dynamically by user programs. For more information, see the
description of the display_memory_usage request in this
manual.
iop
The input/output processor heap (available only in the IOP dump or
firmware modes)
ioa
The input/output adapter heap (available only in the IOP dump or
firmware modes)
You must specify a value for either this argument or the area_address argument.
You cannot select both. (In the display form, the value for the -heap argument is
blank, indicating no value, which is the default for this <CYCLE> field.)
* -sort sort_order
<CYCLE>
Specifies the order in which the data for the various types in the area are displayed.
The following table describes the values for sort_order.
8-424
Value
Description
size
Numerically sorts by the total size of used blocks of each type.
This is the default.
free_count
Numerically sorts by the number of free blocks of each type
free_size
Numerically sorts by the total size of free blocks of each type
type
Alphabetically sorts by the two-character tag of each type
count
Numerically sorts by the number of used blocks of each type
VOS System Analysis Manual (R073)
scan_area
Explanation
A heap is a portion of virtual address space in which VOS can allocate storage for
programs. The display_memory_usage request shows the addresses of heaps.
You cannot use the scan_area request to display information about the process heap
of a process, but you can use it to examine the user heap of a process.
To calculate the amount of free space in the heap, use the following formula:
free bytes + (relative last available - relative next virgin)
Note that this formula does not account for space made available by heap expansion;
the user, paged, wired, and comm heaps are all automatically expanded when
available space is used up. For an explanation of user heap expansion, see the
discussion in the display_memory_usage request description of the user_heap or
original_user_heap region. Refer to the descriptions of
display_extensible_heap and dump_vm_pool_info for information on paged,
wired, and comm heap expansion.
Examples
In the following example, the scan_area request displays header information,
followed by a summary of the types of blocks in the paged heaps, sorted by size (the
default).
as:
scan_area -heap paged
AREA at C11CE000 (C11CE000)
Next virgin:
Last available:
Free bytes:
Max size:
Free limit:
Dead space:
Area size:
C23F9170 (0122B170)
C2431FF0 (01263FF0)
00015840
0000203E
0003BFFE
01084140
001DFEB0 (480 pages)
Bucket(1)
Bucket(2)
Bucket(3)
Bucket(4)
Bucket(5)
Bucket(6)
Bucket(7)
Bucket(8)
00000001
C12604F0
00000001
00000001
C2329FB0
C22F2EB0
C21296F0
C22F49F0
0-32
33-64
65-96
97-128
129-256
257-512
513-1024
1025-up
USED
(00000000)
(000924F0)
(00000000)
(00000000)
(0115BFB0)
(01124EB0)
(00F5B6F0)
(011269F0)
Number
Number
Number
Number
Number
Number
Number
Number
in
in
in
in
in
in
in
in
bucket:
bucket:
bucket:
bucket:
bucket:
bucket:
bucket:
bucket:
0
22
0
0
24
8
1
29
FREE
The analyze_system Command and Requests
8-425
scan_area
DV
GP
ES
LC
TY
PT
TV
AF
FI
VT
KP
AD
EM
EI
KE
AX
DU
NM
DF
FW
LG
TX
CX
QH
NC
QE
DB
....
5664
1
183
430
318
294
168
96
188
1
108
53
20
54
4
58
85
84
1
43
14
2
1
16
1
21
11
000AF440
0003E040
0001C980
000180C0
00015E40
0000F7C0
0000E640
00007800
00005E00
00004040
00003600
00003500
00003200
000030C0
00002FC0
00002B80
00002A80
00002940
00002040
00002000
00001F80
00001680
00001300
00000F40
00000D80
00000AC0
00000A80
0
0
0
8
0
14
0
3
3
0
0
9
0
2
0
0
2
0
0
0
0
0
0
0
0
0
2
00000000
00000000
00000000
00000600
00000000
00005900
00000000
00000500
00000280
00000000
00000000
00001C00
00000000
00000340
00000000
00000000
00000A40
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00001D40
-------8098
-------001917B0
-------84
-------00015840
Device Table
Global Port
NCT System Entry
Lock Info
Terminal Type Component
PORT Entry Block
I/O Transfer Vector
AFTE Block
File Info Block
Virtual Circuit Table
Key Position
ADTE Block
NCT Module Entry
EITE Block
Kernel Entry List
AXTE Block
Device User
Net Message Info
Disk Addresses to free
Firmware Data Structure
Language Info
Transaction State Info
Completed Transaction Info
Queue File Header
Net Client Table
Queue File Message Entry
Dir Buffer Info
as:
In the following example, the scan_area request displays header information and
then a summary of the type of blocks in the paged heap, sorted by type.
as:
scan_area -heap paged -sort type
AREA at C11CE000 (C11CE000)
Next virgin:
Last available:
Free bytes:
Max size:
Free limit:
Dead space:
Area size:
8-426
C23F9170 (0122B170)
C2431FF0 (01263FF0)
00016CC0
0000203E
0003BFFE
01084140
001DFEB0 (480 pages)
VOS System Analysis Manual (R073)
scan_area
Bucket(1)
Bucket(2)
Bucket(3)
Bucket(4)
Bucket(5)
Bucket(6)
Bucket(7)
Bucket(8)
!!
**
ock
AC
AD
AF
AX
CM
CP
CS
CX
DA
DB
DF
DL
DP
DR
DT
DU
DV
EI
EM
ES
FI
FL
....
0-32
33-64
65-96
97-128
129-256
257-512
513-1024
1025-up
00000001
C125DF70
00000001
C23F4770
C230DE30
C22F2EB0
C232BBF0
C22F49F0
(00000000)
(0008FF70)
(00000000)
(01226770)
(0113FE30)
(01124EB0)
(0115DBF0)
(011269F0)
Number
Number
Number
Number
Number
Number
Number
Number
in
in
in
in
in
in
in
in
bucket:
bucket:
bucket:
bucket:
bucket:
bucket:
bucket:
bucket:
0
22
0
2
22
7
3
31
USED
FREE
0
1
00000000
00000030
1
0
00000080
00000000
Virgin Split Block
Permanent Heap Overhead Bl
2
47
96
58
1
0
2
1
0
11
1
1
31
1
1
85
5664
54
20
183
188
1
00000280
00002F00
00007800
00002B80
00000040
00000000
00000380
00001300
00000000
00000B00
00002040
00000040
000007C0
00000040
00000300
00002A80
000AF440
000030C0
00003200
0001C980
00005E00
00000500
0
4
2
0
0
11
0
0
6
1
0
0
0
0
0
2
0
2
0
0
1
0
00000000
00001600
00000380
00000000
00000000
00007700
00000000
00000000
000024C0
00001C40
00000000
00000000
00000000
00000000
00000000
00000A40
00000000
00000240
00000000
00000000
00000080
00000000
Access Control Hash Table
ADTE Block
AFTE Block
AXTE Block
Command Meters
Create Process Info
Control Sizes
Completed Transaction Info
-------8080
-------001909F0
-------87
-------00016600
Dir Buffer Info
Disk Addresses to free
Device Table Ptr List
DVTE Parameters
Dump Disk Table
ADT Header
Device User
Device Table
EITE Block
NCT Module Entry
NCT System Entry
File Info Block
Transaction File Lock
as:
The analyze_system Command and Requests
8-427
scan_area
The following table describes the fields that appear in the header output of the
preceding examples.
Field
Description
Next virgin
The first number is the address above which all blocks in the heap are
free. The number in parentheses is the relative next virgin, which is the
number of bytes between that address and the beginning of the heap.
Last
available
The maximum address currently usable by the heap. The number in
parentheses is the relative last available.
Free bytes
The total number of bytes free throughout the heap.
Max size
An estimate of the largest free block. This number is never too low, but
it may be too high.
Free limit
The number of free blocks that must be available for a limited allocation
to succeed.
Dead space
The number of unusable blocks between sections of virtual memory
space in extensible heaps
Area size
The current size of the heap
Bucket(n)
Free blocks within the non-virgin area are placed into buckets based on
their size. For each bucket, the output shows the address of the first
block in the bucket and the number of bytes between that address and
the beginning of the heap (the offset).
The scan_area output also shows the number of blocks in each bucket.
Following the header information, scan_area displays a summary of the blocks of
each type within the specified heap. The abbreviated name (the tag) for each type of
block is in the left-most column, and the full name for the type of block is in the
right-most column. The tag and number for each free block indicate the purpose for
which that block was last used. Columns 2 and 3 show the number of used blocks of
each type and the amount of space allocated to those blocks. Columns 4 and 5 show
the distribution of free blocks in the heap: the number of blocks of each type and the
amount of space allocated to them.
Blocks of a given type can be allocated if there is space in the heap, regardless of
whether or not any of that type are currently free.
Every heap has a dummy block tagged ** as its first element.
8-428
VOS System Analysis Manual (R073)
scan_area
Related Information
For more information about the status of the user heap, see the descriptions of the
display_memory_usage, display_extensible_heap, and
dump_vm_pool_info requests.
The analyze_system Command and Requests
8-429
scan_streams_msgs
scan_streams_msgs
8-
Purpose
This request summarizes STREAMS message usage.
Display Form
--------------------------- scan_streams_msgs -------------------------sort:
size
-memory_pool: all
-use_mh_q:
no
-leaks_only: no
Command-Line Form
scan_streams_msgs [-sort string]
[-memory_pool string]
[-use_mh_q]
[-leaks_only]
Arguments
* -sort
Specifies how to sort the summarized output. It has the following values.
sizeSort by the number of bytes allocated (descending). This is the default
value.
countSort by the number of messages allocated (descending).
caller_PCSort by the program counter of the last allocate or free caller.
q_qinfoSort by the q_qinfo value of the last queue_t node the message was
put to.
free_sizeSort by the number of bytes in the free caches.
free_countSort by the number of messages in the free caches.
8-430
VOS System Analysis Manual (R073)
scan_streams_msgs
* -memory_pool
Specifies the memory pool from which messages are dumped. (This argument is
relevant only to quad-processor configurations of Continuum-series modules.) Values
are 0, 1, or all (the default).
* -use_mh_q
When you specify this argument, analyze_system examines the vmh.mh_q field in
the STREAMS message header when it scans messages and generates a separate
summary line for each queue_t node found. When you do not specify this option,
analyze_system includes all queue_t nodes with the same value for q_qinfo in
the same summary line.You can use this argument to determine if a particular queue
is consuming an unusual amount of resources.
* -leaks_only
When you specify this argument, analyze_system examines all STREAMS
structures it can find and eliminates from the scan any messages that it referenced by
those structures. Messages that remain in the scan are as follows:
1. Transient (i.e., being passed up or down the stack of a process that is currently
executing)
2. Memory leaks
3. Messages that were missed by the marking prepass because the driver .pm files
were out of date and analyze_system could not associate queue_t nodes with
the appropriate driver
4. Missing or incorrect code in the analyze_system marking prepass
The default value for this argument is no.
Explanation
The scan_streams_msgs request summarizes STREAMS message usage. (It is
similar to the way scan_area works on the system heaps.) Each STREAMS
message is categorized according to the following information.
The Program Counter (PC) of the last allocate or free caller
The q_qinfo value of the last queue_t node the message was put to
(vmh.mh_q_qinfo)
Optionally, the last STREAMS queue_t node the message was put to
(vmh.mh_q) (see the -use_mh_q argument description)
The analyze_system Command and Requests
8-431
scan_streams_msgs
Examples
as:
scan_streams_msgs
Count
Size Free Cnt
10578 015F3900
10157 01513E80
17533 0066BB80
19704 0039BA00
469 0004CC00
(FE853918)
1260 0003B100
1252 0003AB00
472 0002C400
827 00026C40
827 00026C40
826 00026B80
740 00022B00
667 0001F440
667 0001F440
583 0001B540
583 0001B540
388 00018400
512 00018000
384 00012000
384 00012000
388 0000C200
(FE853918)
14 00007700
6 00006300
125 00005DC0
125 00005DC0
98 00004980
97 000048C0
4 00002280
00000000
10 00000A00
9 00000900
9 000006C0
9 00000480
(FE853918)
5 000003C0
1 00000380
1 000000C0
1 000000C0
1 000000C0
1 000000C0
0 00000000
8-432
Free Sz
Caller; Q_INFO
0 00000000 ad_wfunc+12E4, line 758; 00000000
0 00000000 ad_dlmux+3E0, line 132; 00000000
0 00000000 allocb+2B59, line 1833; tcp (FE853918)
0 00000000 receive+D9C, line 671; 00000000
0 00000000 stcp_link_service+3464, line 1826; tcp
0 00000000 open+50C, line 278; 00000000
0 00000000 open+16F4, line 1272; 00000000
0 00000000 allocb+2B59, line 1833; 00000000
0 00000000 tcp_stream+1E70, line 646; 00000000
0 00000000 tcp_stream+1F04, line 654; 00000000
0 00000000 tcp_stream+1DF4, line 640; 00000000
0 00000000 open+1794, line 1277; sth (C082D3B8)
0 00000000 tcp_ip+35C, line 169; 00000000
0 00000000 tcp_ip+3F8, line 180; 00000000
0 00000000 fast+368, line 211; 00000000
0 00000000 fast+404, line 217; 00000000
0 00000000 lat_al_buffers+71D, line 302; 00000000
0 00000000 open+1794, line 1277; 00000000
0 00000000 sthi+4D1D, line 3236; 00000000
0 00000000 sthi+4D59, line 3239; 00000000
0 00000000 lat_al_buffers+765, line 315; tcp
0 00000000 ad_dlmux+3E0, line 132; sth (C082D3B8)
0 00000000 arp_stream+207C, line 829; 00000000
0 00000000 sthi+4041, line 2551; tcp (FE853918)
0 00000000 sthi+4065, line 2558; 00000000
0 00000000 lat_ai_init+7F9, line 331; 00000000
0 00000000 lat_ai_init+4D4, line 215; 00000000
0 00000000 stcp_link_service+34E0, line 1851;
0 00000000 udp_stream+17B4, line 395; 00000000
0 00000000 lat_al_buffers+71C, line 302; 00000000
0 00000000 close+A08, line 594; sth (C082D3B8)
0 00000000 lat_al_buffers+764, line 315; tcp
0
0
0
0
0
0
1232
00000000
00000000
00000000
00000000
00000000
00000000
00072040
VOS System Analysis Manual (R073)
close+C98, line 671; sth (C082D3B8)
loop+B38, line 178; 00000000
timech+441, line 219; 00000000
timech+82D, line 369; 00000000
gateway+64C, line 301; 00000000
raw+9D8, line 210; 00000000
00000000; 00000000
scan_streams_msgs
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
FE8054C0
0 00000000
FE8054C0
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
(FE87DA40)
0 00000000
0 00000000
(FE87DA40)
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
5 00002A80 vos_pse+39A9, line 2646; 00000000
171 00059640 vos_pse+39A9, line 2646; sth (C082D3B8)
1 00000180 vos_pse+5AA9, line 4365; 00000000
2 00000180 sth+31A4, line 2317; sth (C082D3B8)
1 000000C0 sthi+4311, line 2684; sth (C082D3B8)
2 00000180 sthi+4941, line 2988; 00000000
4 00000300 sthi+4941, line 2988; sth (C082D3B8)
11 00000840 sutl+3F48, line 2383; 00000000
8 00000600 sutl+3F48, line 2383; sth (C082D3B8)
1 000000C0 stcp_link_service+1C18, line 675;
27 0000E580
stcp_link_service+3280, line 1761;
2 00000180 abort+4B8, line 173; 00000000
7 000063C0 ack+F58, line 877; 00000000
2909 0015B840 ack+F58, line 877; tcp (FE853918)
2036 00439A00 ip_tcp+594, line 273; 00000000
175 00008340 ip_tcp+594, line 273; tcp (FE853958)
1 000000C0 receive+510, line 311; 00000000
49 000024C0 receive+540, line 320; 00000000
2 00000180 receive+6D0, line 422; 00000000
1 00000180 resend+1720, line 978; 00000000
7 000024C0 send+BB0, line 722; 00000000
17 00000CC0 tcb+9DC, line 398; 00000000
12 00000900 tcb+A08, line 403; 00000000
8 00000600 tcb+A34, line 408; 00000000
36 00001B00 tcb+121C, line 870; 00000000
20 00000F00 tcb+1240, line 876; 00000000
8 00000600 tcb+12F4, line 926; 00000000
2219 00068040 tcb+14E8, line 1029; 00000000
9 000006C0 tcb+1620, line 1071; 00000000
7 00000540 tcb+1644, line 1078; 00000000
66 00002300 tcb+1878, line 1281; tcp (FE853918)
1 000000C0 tcp_stream+62AC, line 2779; tcp (FE853918)
3 00000240 tcp_stream+6E24, line 3279; tcp (FE853958)
4 00000400 lat_al_buffers+12A4, line 826; 00000000
407 00019EC0 lat_al_buffers+13FC, line 862; 00000000
4 00002200 lat_st_lrput+3CC, line 120; 00000000
143 00006B00 lat_st_lrput+454, line 149; lat_streams
27 0000E580 lat_st_lrsrv+1758, line 655; 00000000
2 00000180 lat_st_lrsrv+1758, line 655; lat_streams
3 00000240 udp_receive+8A8, line 245; udp (FE8AB0B0)
8 00004400 udp_receive+B14, line 355; 00000000
2 00001100 icmp+1F28, line 1105; 00000000
13 000009C0 ip_stream+5944, line 2860; ip (FE8E7338)
4 00000540 ip_stream+59C0, line 2873; 00000000
The analyze_system Command and Requests
8-433
scan_streams_msgs
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
0 00000000
-------- -------69717 037913C0
8-434
1 000000C0 ip_stream+59C0, line 2873; ip (FE8E7338)
9 000006C0 ip_stream+5D2C, line 2987; ip (FE8E7338)
42 00016500 arp+C3C, line 595; 00000000
6 00000480 arp+C3C, line 595; arp (FE8F8150)
42 00001500 tnmod+29E4, line 1360; 00000000
1353 002CEC80 ad_dlmux+A30, line 437; 00000000
66 00023100 ad_dlmux+BA8, line 516; 00000000
1 00000880 ad_dlmux+1308, line 754; 00000000
438 000305C0 ad_wfunc+1360, line 777; 00000000
13 000009C0 ad_wfunc+1360, line 777; ad (FE9B42B8)
105664 01498E40 ad_wfunc+18E4, line 994; 00000000
10 00000780 ad_wfunc+18E4, line 994; udp (FE8AB080)
102945 012D98C0 ad_wfunc+18E4, line 994; ad (FE9B42B8)
-------- -------220267 031DCAC0
VOS System Analysis Manual (R073)
sched_lock_meters
sched_lock_meters
8-
Purpose
This request displays the VOS kernel scheduler lock meters.
Display Form
------------------------------ sched_lock_meters ----------------------------reset: n o
-report: yes
Command-Line Form
sched_lock_meters
[-reset]
[-no_report]
Arguments
* -reset
<CYCLE>
Resets the relative scheduler lock meters to 0. When you reset the meters, the
request does not display a report unless you specify that a report should be
displayed. By default, the meters are relative to the current bootload session.
* -no_report
<CYCLE>
Specifies that the request not display output. By default, the request displays
output.
Explanation
The sched_lock_meters request displays the meters for locks associated with the
scheduler of processor resources in the VOS kernel.
When you specify sched_lock_meters -reset, it affects only the current process
executing analyze_system and the sched_lock_meters request. The command
records the reset in the file (home_dir)>as_meter_file. If more than one process
shares the same home directory, only one process at a time can reset a metering
request. If the file as_meter_file exists, it is reopened when you re-enter
The analyze_system Command and Requests
8-435
sched_lock_meters
analyze_system. To use the meters set since boot time, delete the file
as_meter_file.
Examples
In the following example, the sched_lock_meters request displays the schedulers
lock meters.
as: sched_lock_meters
Metering time
50:01:31
LOCK NAME
LOCKS
/SEC
sim interrupt
44460373 246.9
event table master
34732012 192.9
single event
34494726 191.5
broadcast
75697
0.4
free_slot
88065
0.5
hash table
21590
0.1
shadow
11033
0.0
timed
40664
0.2
Pool 0
process master lock
104452132 580.0
single process
104451962 580.0
process queue
70086726 389.2
alarm queue
9574129
53.2
alarm clock queue
11575
0.0
task timer queue
11535
0.0
stopped process queue
6488
0.0
global lock
30
0.0
memory management
5162988
28.7
as:
8-436
VOS System Analysis Manual (R073)
LOOPS
/SEC %LOCKS
48092
0.3
0.1
24164
0.1
0.0
394896
2.2
1.1
0
0.0
0.0
0
0.0
0.0
0
0.0
0.0
0
0.0
0.0
25
0.0
0.0
57698
846247
856477
5250
0
0
0
0
26641
0.3
4.7
4.8
0.0
0.0
0.0
0.0
0.0
0.1
0.0
0.8
1.2
0.0
0.0
0.0
0.0
0.0
0.5
AVG MS/SEC
0.01
0
0.00
0
0.11
0
0.00
0
0.00
0
0.00
0
0.00
0
0.04
0
0.00
0.02
0.04
0.01
0.00
0.00
0.00
0.00
1.20
0
0
0
0
0
0
0
0
0
sched_lock_meters
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
LOCK NAME
The name of the lock type, such as sim interrupt, event table
master, process master lock, or memory management.
LOCKS
The number of locks of various types that occurred during the metering
interval.
/SEC
The number of locks that occurred per second during the metering
interval.
LOOPS
The number of loops that occurred during the metering interval because
the lock was not immediately available.
/SEC
The number of loops that occurred per second during the metering
interval.
%LOCKS
The ratio of loops to locks occurring during the metering interval. This is a
measure of lock contention.
AVG
The average loop time in milliseconds.
MS/SEC
The average number of milliseconds spent locking this lock every second.
The analyze_system Command and Requests
8-437
sched_meters
sched_meters
8-
Purpose
This request displays the scheduler meters.
Display Form
--------------------------------- sched_meters ------------------------------no
-reset:
-report: yes
Command-Line Form
sched_meters
[-reset]
[-no_report]
Arguments
* -reset
<CYCLE>
Resets the relative scheduler lock meters to 0. When you reset the meters, the
request does not display a report unless you specify that a report should be
displayed. By default, the meters are relative to the current bootload session.
* -no_report
<CYCLE>
Specifies that the request not display output. By default, the request displays
output.
Explanation
The sched_meters request displays the scheduler meters.
When you specify sched_meters -reset, only the meters for the current process
executing analyze_system and the sched_meters request are reset. The
command records the reset in the file (home_dir)>as_meter_file. If more than
one process shares the same home directory, only one process at a time can reset a
metering request. If the file as_meter_file exists, it is reopened when you re-enter
8-438
VOS System Analysis Manual (R073)
sched_meters
analyze_system. To use the meters set since boot time, delete the file
as_meter_file.
Examples
In the following example, the sched_meters request displays the scheduler meters.
as: sched_meters
Metering time:
50:10:31
POOL 0 METER
short_waits
schedule_calls
schedule_int_calls
schedule_nops
process_switches
processes_created
tachy_meters:
new_binding
same_cpu
twin_timeout
offboard_timeout
scheduling interrupts:
start_idle_cpu
looped_waits
looped_waits_aborted
try_master_wait_abort
sleeps
COUNT
13868451
87936
33772162
1265135
6187130
1586
ATB
13.0
2054.1
5.3
142.8
29.2
113890.9
/SEC
76.8
0.5
187.0
7.0
34.3
0.0
1500479
13369139
7702
0
120.4
13.5
23452.5
8.3
74.0
0.0
7512078
24.0
7883716
22.9
7883715
22.9
1 **********
5603
32238.3
41.6
43.6
43.6
0.0
0.0
CPU time distribution
CPU
CPU SECONDS INCREMENTS
CPU0
7673.10
9741873
CPU1
3827.66
5132450
CPUavg
5750.38
7437161
ATB
18.5
35.2
24.3
/SEC
53.9
28.4
41.2
AVG INC
0.8
0.7
0.8
BUSY
4.2%
2.1%
3.2%
as:
The analyze_system Command and Requests
8-439
sched_meters
The following table describes the columns that appear in the output of the preceding
example.
8-440
Column
Description
METER
The type of metering event. Examples are short_waits,
schedule_calls, schedule_int_calls, schedule_nops,
process_switches, scheduling_interrupts,
looped_waits, looped_waits_aborted,
try_master_wait_aborts, and sleeps.
COUNT
The number of each kind of metering event that occurred during the
metering time.
ATB
The average time, in seconds, between scheduled metering events.
/SEC
The time, per second, of metering events.
CPU
The CPU on which the metering events reside.
CPU SECONDS
The number of seconds of CPU time during which the metering
events occurred.
INCREMENTS
The number of times this CPU switched processes. A nonidle
process was scheduled.
AVG INC
The average amount of time in milliseconds that a scheduled
process runs on this CPU before being suspended.
BUSY
The percentage of CPU seconds that were busy during the
metering events.
VOS System Analysis Manual (R073)
search_streams
search_streams
8-
Purpose
This request scans VOS processes for open streams and displays the read, write, and
ioctl OSRs for a PORTE, the stream head, and all module and driver queues below the
head.
Display Form
-------------------------------- search_streams ------------------------------process:
-from:
-to:
Command-Line Form
search_streams
[-process process_id]
[-from process_id]
[-to process_id]
Arguments
* -process process_id
Specify the ID of a process in which you want to search for open streams.
Specifying a value for this argument causes the request to display all open streams
for the process.
* -from process_id
Specify a process ID for this argument and for the -to argument in order to display
the open streams for a number of processes.
* -to process_id
Specify a process ID for this argument and for the -from argument in order to
display the open streams for a number of processes.
The analyze_system Command and Requests
8-441
search_streams
Explanation
The search_streams request scans VOS processes for open streams and displays
the read, write, and ioctl OSRs for a PORTE, the stream head, and all module and
driver queues below the head.
If you specify the -from and -to arguments, the output may be quite extensive and
you may want to log it to a file with the start_logging and stop_logging
commands or attach_default_output and detach_default_output
commands. For more information on using these commands in the analyze_system
command, see Chapter 2.
Examples
In the following example, the search_streams request displays information about a
stream associated with a specific process in a system dump.
as: use_dump 13
Detected compressed dump.
Using %se#m2>Overseer>dumps>system.95-08-18.15:10:38.c.dump
Warning: Modified code pages present in dump.
VOS Release 13.1bp w/ streams, analyze_system Pre-release
Using process on CPU31.
Current process is 263, ptep 8154C360, Smith.Communications
(cello_server22)
PCP called from 80678640 on CPU31
Ram pages from IOP 1 present.
Ram pages from IOAs : 0,3,5,12 present (IOP 1).
as: match smith; who
....
* 263 8154C360 Smith.Eng (cello_server22), on CPU31
....
as: search_streams -process 263
Using process on CPU31.
Current process is 263, ptep 8154C360, Smith.Eng (cello_server22)
%se#tcp_238 10
===========
DEVICE = 8026A400
READ_OSRP
STH_OSR = 8154CA60
8-442
= 8154CA60
osrq_next
osrq_prev
= 8154D090
= 8154D090
osr_sth
osr_ret_val
osr_err
= 8154D060
= 0
= 0
VOS System Analysis Manual (R073)
search_streams
osr_callback
= sthi+24E0, line 505
osr_pid
= 8026A400x
osr_flags
= 00000001x
F_OSR_NOFREE set
osr_finished
= TRUE
osr_state
= 0
osr_istate
= 0
osr_creds.cr_ref
= 0
osr_creds.cr_ngroups = 0
osr_creds.cr_uid
= 0
osr_creds.cr_gid
= 0
osr_creds.cr_ruid
= 0
osr_creds.cr_rgid
= 0
osr_creds.cr_suid
= 0
osr_creds.cr_sgid
= 0
osr_creds.cr_groups[1] = 0
osr_creds.sd_infop = 00000000
osr_bufcall_id
= 00000000x
osr_type
= READ
Rd/Wr OSR Begin
osr_rw_total
= 00007428x
osr_rw_flags
= 00000000x
osr_rw_oia_argp
= 80F0FFC0x
osr_rw_oia_len
= 00000000x
Rd/Wr OSR End
osr_time_limit
= never
osr_xtrap
= 00000000
open_dev
= 000C002A
devp
= 00000000
sqhp
= 8154D1B8
ref_count
= 0
osr_tsq
= 8154CD30
osr_wait_lock
= 80244448 (unlocked)
WRITE_OSRP
STH_OSR = 8154CB60
= 8154CB60
osr is not queued
osr_sth
osr_ret_val
osr_err
osr_callback
osr_pid
osr_flags
F_OSR_NOFREE set
osr_finished
osr_state
=
=
=
=
=
=
8154D060
0
0
00000000x
8026A400x
00000001x
= FALSE
= 0
The analyze_system Command and Requests
8-443
search_streams
osr_istate
osr_creds.cr_ref
= 0
= 0
....
osr_creds.sd_infop
osr_bufcall_id
osr_type
Rd/Wr OSR Begin
osr_rw_total
osr_rw_flags
osr_rw_oia_argp
osr_rw_oia_len
Rd/Wr OSR End
....
IOCTL_OSRP
STH_OSR = 8154CC60
as:
= 00000000
= 00000000x
= WRITE
=
=
=
=
00000000x
00000000x
00000000x
00000000x
= 8154CC60
Related Information
See the description of the dump_stream request. For more information about VOS
STREAMS, see the VOS Communications Software: STREAMS Programmers
Guide (R306) and the IOA STREAMS Programmers Guide (R341).
8-444
VOS System Analysis Manual (R073)
set_byte
set_byte
8-
Purpose
This request sets the value of one or more bytes in the current environment.
CAUTION
Use this request only when instructed to do so by the
CAC.
Display Form
----------------------------------- set_byte ----------------------------------start_address: *
data:
-check:
-io:
no
-physical:
no
Command-Line Form
set_byte start_address data
[-check check_values]
[-io]
[-physical]
Arguments
* start_address
The address of the first byte to be set. This value can be in any of the formats for
address values of a program. If you do not supply a value, VOS selects bytes
beginning at the last address value referenced in similar requests. (For information
on address formats, see Chapter 3.)
* data
Required
A string of one or more hexadecimal data values, separated by spaces, to which
consecutive bytes beginning at start_address are set.
The analyze_system Command and Requests
8-445
set_byte
* -check check_values
A string of one or more hexadecimal data values, separated by spaces, to which
consecutive bytes beginning at start_address are compared. If you specify this
argument, the specified bytes are set only if the current values of the compared
bytes match the check values.
* -io
<CYCLE>
On XA/R-series and Continuum-series modules, enables you to write to I/O space
memory locations. If you specify no, you can only write to kernel space virtual
memory locations. This is the default.
* -physical
<CYCLE>
On Continuum-series modules, enables you to write to physical memory locations.
If you specify no, you can only write to virtual memory locations . This is the default.
Explanation
The number of bytes set is determined by the number of data values in the string data.
For a string of n data values, the first n consecutive bytes, beginning with the byte
specified in start_address, are set to the corresponding data values in the string.
The number of bytes compared is determined by the number of data values in the string
check_values, and does not need to equal the number of data values in the string
data. The bytes are then set only if all current values match the check values.
Examples
The following sequence of examples illustrates the use of the set_byte request. In
the following examplet, the set_byte request sets the values of the three bytes
beginning at the address 00FD4000.
as:
set_byte 00FD4000 1 2 3 -check 0
addr
00FD4000
00FD4001
00FD4002
as:
8-446
fm
00
00
00
to
01
02
03
VOS System Analysis Manual (R073)
set_byte
In the following example, the set_byte request sets the same bytes after it performs
a successful check.
as:
set_byte * 4 5 6 -check 1 2 3
addr
00FD4000
00FD4001
00FD4002
as:
fm
01
02
03
to
04
05
06
In the following example, the set_byte request checks but does not change the same
bytes, because the check failed.
as:
set_byte 00FD4000 4 5 6 -check 1 2 3
set_byte: 00FD4000
as:
04 should be 01 --- check failed.
The analyze_system Command and Requests
8-447
set_cache_pin_parameters
set_cache_pin_parameters
8-
Purpose
This request enables you to set the cache manager buffer pinning parameters.
Display Form
--------------------------- set_cache_pin_parameters -------------------------pin_priority:
-pin_count:
-set_flag:
-clear_flag:
Command-Line Form
set_cache_pin_parameters
[-pin_priority pin_priority]
[-pin_count pin_count]
[-set_flag]
[-clear_flag]
Arguments
* -pin_priority pin_priority
Specifies a scheduler priority. This argument and the -pin_count argument must
be specified together, although the values for the two arguments can be different.
Allowed values match a scheduler priority level and can range from 0 to 9.
* -pin_count pin_count
Specifies the pin count for a scheduler priority. This argument and the
-pin_priority argument must be specified together, although the values for the
two arguments can be different. Allowed values can range from 0 to 9. For example,
to set the pin count for scheduler priority 5 to 2, set -pin_count to 2 and set
-pin_priority to 5.
8-448
VOS System Analysis Manual (R073)
set_cache_pin_parameters
* -set_flag
Sets the flag to enabled or raise_count.
<CYCLE>
To enable pinning using the pin count values specified in the -pin_count and
-pin_priority arguments, specify the value enabled.
Enabling raise_count makes the following sequence possible. If
a get block cache operations hits in the disk cache
enabled and raise_count are set to on
the pin count tied to the priority of the calling process is higher than the current
buffer pin count
then the new pin count is assigned to the block. If any of the preceding conditions
is false, nothing happens.
For raise_count to have any effect, you must have previously set -set_flag
to enabled.
If you enable both -set_flag and -clear_flag at the same time,
set_cache_pin_parameters performs any clear-flag actions first, then any
set-flag actions.
* -clear_flag
<CYCLE>
Clears the enabled or raise_count flag. To clear a flag, leave the value of the
-set_flag field blank.
Explanation
The set_cache_pin_parameters request controls buffer use through a
mechanism called disk cache pinning.
Disk cache pinning is disabled by default. Enable disk cache pinning only if
performance analysis shows that higher-priority processes are experiencing cache
interference from lower-priority processes.
Normal Disk Cache Operation
The cache manager maintains disk blocks in cache in order to reduce the number of
actual I/O operations required to satisfy programmed read and write requests. If a
buffer is not referenced after a certain time, it is reassigned to another disk block.
The disk cache is sized according to the system memory configuration and several
tuning parameters. However, there is no basic control over the use of those buffers by
processes of various priorities. For example, you cannot restrict the number of buffers
used per process or per priority-level.
The analyze_system Command and Requests
8-449
set_cache_pin_parameters
Disk Cache Operation with Pinning
When buffer pinning is enabled, the buffer pin count is set by certain operations and
the enabled and raise_count flags. The pin count is based upon the scheduling
priority of the referencing process.
Before the disk cache algorithm reassigns a buffer to a new disk block, it examines the
buffer pin count. If the pin count is greater than 0, it is decremented, the buffer is not
reassigned, and the disk cache algorithm proceeds to the next buffer. Eventually, the
buffers pin count is reduced to 0, and the buffer is reassigned.
For example, if the pin count for a buffer is 2, that buffer can remain unreferenced for
approximately three times (pin count + 1) as long as a buffer has a pin count greater
than 0. The actual time a buffer is pinned depends on many factors.
There are other circumstances which influence the time that a disk block is in the disk
cache. For example, a file must be open in at least one process to occupy buffers.
When the last process using the file closes the port, all associated buffers are freed and
can be immediately reused.
Tuning Buffer Pinning
Use the following rules when tuning disk cache pinning.
In general, the pin counts assigned to priority N should be greater or equal to that pin
count of priority N-1. Assuming that you run less-favored processes at a lower
scheduler priority, the module will most effectively use the disk cache if you assign a
pin count to the higher priority level.
Pin counts are only effective when competing processes have different scheduling
priorities. Use the lowest pin count values to provide the desired result. The time that
a buffer remains pinned depends on the disk cache size, the rate of requests for new
blocks to be placed in the disk cache, the disk cache hit patterns, and the pinning
control flags.
Pin counts do not affect cache usage if the module typically runs with the current
number of buffers less than the maximum because the cache manager can create new
buffers to meet instantaneous demand. The dump_cache_info request shows the
minimum, maximum, and current counts of buffers (phy) and virtual pages (vir).
Examples of Tuning Buffer Pinning
Given a module configured so that system processes run at priority 7 or higher and user
processes run at priority 6 or lower, most system processes will not use the disk cache.
This suggests that priorities 7 to 9 have pin counts of 0.
If you are using TP-protected files, the TPOverseer system process runs for each
transaction. The TPOverseer runs at priority 9 and does use the disk cache. In general,
buffers referenced by the TPOverseer should not get a high pin count just because the
8-450
VOS System Analysis Manual (R073)
set_cache_pin_parameters
TPOverseer is involved in part of the transaction. Rather, the pin count should depend
upon the priority of the user TP processes that are running.This is another reason for
priority 9 to have a pin count of 0.
Given that a module runs a number of processes that service an interactive load at
priority 5 and some report-generating processes that run at priority 4, and standard
scheduling parameters, the interactive processes are given more CPU access than the
report-generator processes. If you give priority 5 a higher pin count than priority 4, the
interactive processes will have greater access to the disk cache.
Related Information
See the descriptions of the display_cache_pin_parameters,
dump_cache_info, and dump_cache requests.
The analyze_system Command and Requests
8-451
set_comm_thresholds
set_comm_thresholds
8-
Purpose
This request sets the error threshold and error interval pair for the individual VOS
communications protocols on a module. Once these are set, the threshold error count
against a particular channel will be incremented if any of the error counts exceeds the
defined threshold within the defined time interval. If the threshold error count exceeds
a predetermined count within a predetermined amount of time, the channel is removed
from service.
CAUTION
Use this request only when instructed to do so by the
CAC.
Display Form
------------------------------ set_comm_thresholds -----------------------------async_error_interval:
60
-async_error_threshold:
500
-bsc_error_interval:
60
-bsc_error_threshold:
500
-eft_error_interval:
60
-eft_error_threshold:
500
-r3270_error_interval:
60
-r3270_error_threshold:
500
-h3270_error_interval:
60
-hasp_error_threshold:
500
-sdlc_error_interval:
60
-sdlc_error_threshold:
500
-lap_error_interval:
60
-lap_error_threshold:
1000
-g_comm_error_interval: 60
-g_comm_error_threshold: 500
-ps_error_interval:
60
-ps_error_threshold:
500
-visa_error_interval:
60
-visa_error_threshold:
500
-uart_error_interval:
60
-uart_error_threshold:
25
-mpx_gcomm_err_interval: 60
-mpx_gcomm_err_threshld: 500
8-452
VOS System Analysis Manual (R073)
set_comm_thresholds
Command-Line Form
set_comm_thresholds
[-async_error_interval seconds]
[-async_error_threshold max_error_count]
[-bsc_error_interval seconds]
[-bsc_error_threshold max_error_count]
[-eft_error_interval seconds]
[-eft_error_threshold max_error_count]
[-r3270_error_interval seconds]
[-r3270_error_threshold max_error_count]
[-h3270_error_interval seconds]
[-h3270_error_threshold max_error_count]
[-hasp_error_interval seconds]
[-hasp_error_threshold max_error_count]
[-sdlc_error_interval seconds]
[-sdlc_error_threshold max_error_count]
[-lap_error_interval seconds]
[-lap_error_threshold max_error_count]
[-g_comm_error_interval seconds]
[-g_comm_error_threshold max_error_count]
[-ps_error_interval seconds]
[-ps_error_threshold max_error_count]
[-visa_error_interval seconds]
[-visa_error_threshold max_error_count]
[-uart_error_interval seconds]
[-uart_error_threshold max_error_count]
[-mpx_gcomm_err_interval seconds]
[-mpx_gcomm_err_threshold max_error_count]
Arguments
* -async_error_interval seconds
Sets the interval, in seconds, for all asynchronous communications. The default is
60.
* -async_error_threshold max_error_count
Sets the error count that can occur in the set time interval for all asynchronous
communications. The default is 500.
The analyze_system Command and Requests
8-453
set_comm_thresholds
* -bsc_error_interval seconds
Sets the interval, in seconds, for BSC, FTPS (SIAC/NASDAQ), and RJE
2780/3780. The default is 60.
* -bsc_error_threshold max_error_count
Sets the error count that can occur in the set time interval for BSC, FTPS
(SIAC/NASDAQ), and RJE 2780/3780. The default is 500.
* -eft_error_interval seconds
Sets the interval, in seconds, for FAS, SWIFT, and CHIPS. The default is 60.
* -eft_error_threshold max_error_count
Sets the error count that can occur in the set time interval for FAS, SWIFT, and
CHIPS. The default is 500.
* -r3270_error_interval seconds
Sets the interval, in seconds, for 3270 Terminal Support. The default is 60.
* -r3270_error_threshold max_error_count
Sets the error count that can occur in the set time interval for 3270 Terminal
Support. The default is 500.
* -h3270_error_interval seconds
Sets the interval, in seconds, for 3270 Emulation. The default is 60.
* -h3270_error_threshold max_error_count
Sets the error count that can occur in the set time interval for 3270 Emulation. The
default is 500.
* -hasp_error_interval seconds
Sets the interval, in seconds, for RJE HASP. The default is 60.
* -hasp_error_threshold max_error_count
Sets the error count that can occur in the set time interval for RJE HASP. The
default is 500.
* -sdlc_error_interval seconds
Sets the interval, in seconds, for host SDLC and remote SDLC. The default is 60.
* -sdlc_error_threshold max_error_count
Sets the error count that can occur in the set time interval for host SDLC and
remote SDLC. The default is 500.
* -lap_error_interval seconds
Sets the interval, in seconds, for LAPB. The default is 60.
8-454
VOS System Analysis Manual (R073)
set_comm_thresholds
* -lap_error_threshold max_error_count
Sets the error count that can occur in the set time interval for LAPB. The default is
1000.
* -g_comm_error_interval seconds
Sets the interval, in seconds, for the Generic Communications (GCOMM) driver.
The default is 60.
* -g_comm_error_threshold max_error_count
Sets the error count that can occur in the set time interval for the GCOMM driver.
The default is 500.
* -ps_error_interval seconds
Sets the interval, in seconds, for Poll/Select. The default is 60.
* -ps_error_threshold max_error_count
Sets the error count that can occur in the set time interval for Poll/Select. The
default is 500.
* -visa_error_interval seconds
Sets the interval, in seconds, for VISA 3270. The default is 60.
* -visa_error_threshold max_error_count
Sets the error count that can occur in the set time interval for VISA 3270. The
default is 500.
* -uart_error_interval seconds
Sets the interval, in seconds, for all communications products. The default is 60.
* -uart_error_threshold max_error_count
Sets the error count that can occur in the set time interval for all communications
products. The default is 25.
* -mpx_g_comm_error_interval seconds
Sets the interval, in seconds, for communications products using the MPX
GCOMM driver. The default is 60.
* -mpx_g_comm_error_threshold max_error_count
Sets the error count that can occur in the set time interval for communication
products using the MPX GCOMM driver. The default is 500.
Explanation
The set_comm_thresholds request does not display output. You can only use this
request if the protocol has been loaded by the configure_comm_protocol
command.
The analyze_system Command and Requests
8-455
set_comm_thresholds
For information on resetting a channel, see the description of the
update_channel_info command in the manual VOS System Administration:
Configuring a System (R287).
Each VOS communications protocol defines an error threshold and an error interval
pair. For example, the LAPB protocol has a default threshold of 500 and a default
interval of 60 seconds. If the error threshold reaches the set value (500 when using the
default setting), the channel is removed from service.
This error threshold mechanism is designed to protect VOS from error-prone
communications lines. Under normal conditions, you should never need to change the
error threshold or error interval for a given protocol.
If you find the error threshold mechanism unacceptable as defined, it is best to have
your application handle e$out_of_service (2535), the VOS error code indicating
that a channel was removed from service because the error threshold was exceeded
or because the line adapter card was removed.
CAUTION
Do not disable the threshold mechanism for any
communications protocol. Disabling this mechanism (by
specifying a value of -1 for the error interval parameter)
defeats the protection mechanism against rogue devices
implemented by VOS and is likely to result in a crash.
Disabling the error threshold mechanism can cause the following adverse system
conditions: system interruption, degraded system performance, filling the master disk
with numerous error messages, and degraded performance of the Overseer process
due to processing numerous syserr messages.
Before you modify any of the thresholds or intervals with the set_comm_thresholds
request, it is important to understand what conditions will increment a channels error
count. Generally, the error count is incremented when a data set signal changes and
when a bad exit status is found in a VOS I/O block. (An I/O block is a wired buffer used
to send and receive data to and from a communications controller.) A bad exit status
can be one of the following:
I/O block overrun
I/O block aborted
CRC error
transfer error (receiver overrun)
device error (bad line adapter card status)
8-456
VOS System Analysis Manual (R073)
set_comm_thresholds
Some communication protocols increment their error counts for other reasons; these
are shown under the specific protocols.
The following table lists the arguments and the protocols they affect.
(Page 1 of 2)
Errors
Arguments
Protocols Affected
Type
Count
-async_error_interval
-async_error_threshold
All asynchronous
communications
protocols
Data set lead changes
I/O block overrun
Parity error
Framing error
Character overrun
Collection buffer overrun
Bad input sequence
5
100
1
1
2
1
1
-bsc_error_interval
-bsc_error_threshold
BSC, FTPS,
(SIAC/NASDAQ),
RJE 2780/3780
Data set lead changes
No receive message
Bad I/O block exit status
No receive buffers
1
10
20
10
-eft_error_interval
-eft_error_threshold
FAS,
SWIFT,
CHIPS
Data set lead changes
No receive message
Bad I/O block exit status
No receive buffers
5
1
1
1
-r3270_error_interval
-r3270_error_threshold
3270 Terminal
Support (Remote
3270)
Data set lead changes
Bad I/O block exit status
1
20
-h3270_error_interval
-h3270_error_threshold
3270 Emulation
(Host 3270)
Data set lead changes
Bad I/O block exit status
1
20
-hasp_error_interval
-hasp_error_threshold
RJE HASP
Data set lead changes
Bad I/O block exit status
1
20
-sdlc_error_interval
-sdlc_error_threshold
Host SDLC,
Remote SDLC
Data set lead changes
Aborted receive frames
CRC errors
Receiver overruns (transfer
errors)
I/O block overruns
Device errors
Zero length receive frames
Invalid I/O block exit status
5
20
20
The analyze_system Command and Requests
20
30
10
10
20
8-457
set_comm_thresholds
(Page 2 of 2)
Errors
Arguments
-lap_error_interval
-lap_error_threshold
-g_comm_error_interval
-g_comm_error_threshold
Protocols Affected
LAPB
GCOMM
Type
Count
Data set lead changes
Aborted receive frames
CRC errors
Receiver overruns (transfer
errors)
I/O block overruns
Device errors
Invalid I/O block exit status
5
20
20
Data set lead changes
CRC errors
Receiver overruns (transfer
errors)
I/O block overruns
Device errors
5
20
20
30
10
20
20
30
10
-ps_error_interval
-ps_error_threshold
Poll/Select
Data set lead changes
Bad I/O block exit status
1
20
-visa_error_interval
-visa_error_threshold
VISA 3270
Data set lead changes
Bad I/O block exit status
1
20
-uart_error_interval
-uart_error_threshold
All communications
products
This is a special type of error increment.
Each channel keeps a UART error count,
which is incremented by 1 each time a
UART error interrupt is generated by the
communications controller.
-mpx_gcomm_error_interval
-mpx_gcomm_error_threshold
ENET-LL,
ENET-TCP
NETBIOS,
SNAGDLC
Channel attach,
UCOMM
Bad I/O block exit status
8-458
VOS System Analysis Manual (R073)
10
set_instruction
set_instruction
8-
Purpose
This request sets the value of one or more instructions in the current environment.
CAUTION
Use this request only when instructed to do so by the
CAC.
Display Form
-------------------------------- set_instruction --------------------------------start_address: *
instruction:
-check:
Command-Line Form
set_instruction start_address
instruction
[-check check_values]
Arguments
* start_address
The address of the first instruction to be set. This value can be in any of the formats
for address values of a program described in Chapter 3. If you do not specify a
value, VOS selects an instruction beginning at the last address value referenced in
similar requests.
* instruction
A set of assembly language instructions enclosed in single quotes.
Required
* -check check_values
set of assembly language instructions enclosed in single quotes, to which
consecutive instructions beginning at start_address are compared. If you
The analyze_system Command and Requests
8-459
set_instruction
specify this argument, the specified data values are set only if the current values of
the compared data values match the check values.
Explanation
The number of instructions that are set is determined by the number of data values in
the string instruction. For a string of n data values, the first n consecutive
instructions, beginning with the instruction specified in start_address, are set to the
corresponding data values in the string.
The number of instructions compared is determined by the number of data values in
the string check_values and does not need to equal the number of data values in the
string instruction. The longwords are then set only if all current values match the
check values.
Example
The following sequence of requests illustrates the use of the set_instruction
request on an XA/R-series module.
as: set_instruction 807b4000x addu,1888,r2,r3 -check addu 1888,r2,r3
set_instruction: 807B4000
807B3760 should be 84430760 --- check failed.
as:
8-460
VOS System Analysis Manual (R073)
set_longword
set_longword
8-
Purpose
This request sets the value of one or more longwords in the current environment.
CAUTION
Use this request only when instructed to do so by the
CAC.
Display Form
-------------------------------- set_longword --------------------------------start_address: *
data:
-check:
-io:
no
-physical:
no
Command-Line Form
set_longword start_address data
[-check check_values]
[-io]
[-physical]
Arguments
* start_address
The address of the first longword to be set. This value can be in any of the formats
for address values of a program described in Chapter 3. If you do not specify a
value, VOS selects longwords beginning at the last address value referenced in
similar requests.
* data
Required
A string of one or more hexadecimal data values, separated by spaces, to which
consecutive longwords beginning at start_address are set.
The analyze_system Command and Requests
8-461
set_longword
* -check check_values
A string of one or more hexadecimal data values, separated by spaces, to which
consecutive longwords beginning at start_address are compared. If you
specify this argument, the specified longwords are set only if the current values of
the compared longwords match the check values.
* -io
<CYCLE>
On XA/R-series and Continuum-series modules, enables you to write to I/O space
memory locations. If you specify no, you can only write to kernel space virtual
memory locations. This is the default.
* -physical
<CYCLE>
On Continuum-series modules, enables you to write to physical memory locations.
If you specify no, you can only write to virtual memory locations. This is the default.
Explanation
The number of longwords set is determined by the number of data values in the string
data. For a string of n data values, the first n consecutive longwords, beginning with
the longword specified in start_address, are set to the corresponding data values
in the string.
The number of longwords compared is determined by the number of data values in the
string check_values, and does not need to equal the number of data values in the
string data. The longwords are set only if all current values match the check values.
Examples
The following sequence of example illustrates the use of the set_longword request.
In the following example, the set_longword request sets the values of the two
longwords beginning at the address 00FD4000.
as:
set_longword 00FD4000 12345678 abcdef
addr
00FD4000
00FD4004
as:
from
00010002
12340000
to
12345678
00ABCDEF
In the following example, the set_longword request sets the same bytes after the
request performs a successful check.
as:
set_longword * 87654321 FEDCBA -check 12345678 ABCDEF
addr
00FD4000
00FD4004
as:
8-462
from
12345678
00ABCDEF
to
87654321
00FEDCBA
VOS System Analysis Manual (R073)
set_longword
In the following example, the set_longword request checks but does not change the
same bytes, because the check failed.
as:
set_longword 00FD4000 87654321 FEDCBA -check 12345678 ABCDEF
set_longword: 00FD4000
as:
87654321 should be 12345678 --- check failed.
The analyze_system Command and Requests
8-463
set_meter_file
set_meter_file
8-
Purpose
This request allows you to specify the name of the meter file used to display and reset
meters. Specifying the name of a meter file allows you to run multiple processes that
gather meters and to save the meter file following a dump.
Display Form
-------------------------------- set_meter_file -----------------------------meter_file_path:
-default:
no
-long:
no
Command-Line Form
set_meter_file
[meter_file_path]
[-default]
[-long]
Arguments
* meter_file_path
A simple name or a full or relative path name.
You must specify a value for the meter_file_path argument or the -default
argument; however, you cannot specify both.
* -default
When you specify the value yes for this argument, the name of the meter file is its
default value (as_meter_file in the home directory). By default (the value no),
you must specify a name for the meter file.
You must specify either a value for the meter_file_path argument or the
-default argument; however, you cannot specify both.
8-464
VOS System Analysis Manual (R073)
set_meter_file
* -long
When you specify the value yes for this argument, the output displays the path
names of the previous meter file and the new meter file. By default (the value no),
the output does not display these names.
Explanation
This request uses the specified name to reset the current meter file.
If the name of the meter file is a simple name, the request uses a file with that name
in the home directory.
If the name of the meter file is the name of an existing file, the request uses that file.
If the request cannot locate the specified file, the system returns an error, and the
current meter path is not changed.
Examples
The following examples illustrate the user User.Test issuing the set_meter_file
request first to set the meter file to the default meter file and then to set the file
(process_dir)>asmf as the current meter file.
as:
set_meter_file -default -long
Was using: %test>process_dir_dir>pd.060CD29A.User>asmf
Now using: %test>Test>User>as_meter_file
as:
as:
set_meter_file (process_dir)>asmf
Related Information
For information about displaying the file status of the current meter file, see the
description of the display_meter_file_info request.
The analyze_system Command and Requests
8-465
set_net_timeout
set_net_timeout
8-
Purpose
This request sets the time limit for a module to complete any StrataLINK or StrataNET
network operation.
Display Form
--------------------------------- set_net_timeout -----------------------------num_minutes:
Command-Line Form
set_net_timeout num_minutes
Arguments
* num_minutes
Required
The number of minutes to set as the time-out limit to complete any network
operations.
Explanation
A network operation corresponds to a remote system subroutine call from one module
to another. The time required to complete a network operation varies according to
communications delays and the nature of the system subroutine call. The
set_net_timeout request enables you to specify the maximum time that any
process will wait to complete any network operation initiated from the current module.
If the time-out occurs while a network operation is in progress, the operation is aborted
as though there had been a communications failure. This causes all network port
attachments between the two modules (StrataLINK) or between two systems
(StrataNET) to be broken and flushed. This action is disruptive and generally requires
applications to reacquire network port attachments.
The time-out set by this request applies to both StrataLINK and StrataNET operations.
For this reason, the default time-out is large enough to accommodate the longer delays
8-466
VOS System Analysis Manual (R073)
set_net_timeout
typical of StrataNET operations. If the StrataNET network is not used, you may want to
choose a smaller time-out.
When the StrataNET network is used, the time-out set with this request should be
coordinated with the value set in the -request_timeout argument of the
network_client command. The default value for the argument is 4 minutes. Refer
to the manual VOS Communications Software: X.25 and StrataNET
Administration (R091) for a description of the network_client command.
The set_net_timeout request does not display output.
The analyze_system Command and Requests
8-467
set_net_trace
set_net_trace
8-
Purpose
This request determines when StrataLINK data is sent to the 4096 byte circular tracing
buffer.
Display Form
----------------------------------- set_net_trace -------------------------------go
mode:
-station:
0
-exclude_boom: no
Command-Line Form
set_net_trace [mode]
[-station station_number]
[-exclude_boom]
Arguments
* mode
<CYCLE>
The StrataLINK tracing mode. Specify go, stop, auto_stop, single_station,
or single_station_auto_stop. If you specify go, the request sends trace data
to the buffer. The default value is go. If you specify stop, the request stops sending
trace data to the buffer. If you specify auto_stop and an error occurs, the request
stops sending trace data to the buffer. If you specify single_station, the
request sends trace data from the current station to the buffer. If you specify
single_station_auto_stop, the request sends trace data from the current
station to the buffer until an error occurs.
* -station station_number
Specifies the station number. The default value is 1. The station number is usually
the same as the module number. Use the dump_net or dump_net_info request
for correspondence between station and module numbers.
8-468
VOS System Analysis Manual (R073)
set_net_trace
* -exclude_boom
<CYCLE>
Specifies that trace data for any network booms (volume test traffic) be excluded
from the network trace data. The default value is no, so data will be included.
Explanation
The set_net_trace request determines when StrataLINK data is sent to the 4096
byte circular tracing buffer. It does not display any output.
You can determine the current tracing mode of the circular tracing buffer by issuing the
display_net_trace or monitor_net_trace requests. At the top of the trace,
these requests display a TRACE MODE field which indicates the current tracing mode.
Related Information
For more information about StrataLINK-related analyze_system requests, see the
descriptions of the display_net_trace, monitor_net_trace and
set_net_timeout requests.
The analyze_system Command and Requests
8-469
set_streams_param
set_streams_param
8-
Purpose
This request allows you to change the value of an individual STREAMS parameter.
Display Form---------------------------- set_streams_param --------------------------------param_name:
param_value:
Command-Line Form
set_streams_param
param_value
param_name
Arguments
* param_name
The short name of the STREAMS parameter to be changed.
* param_value
The desired value of the STREAMS parameter to be changed.
Required
Required
Explanation
The set_streams_param request allows you to change the value of an individual
STREAMS parameter.
The request checks the range of the parameters.
For information on the individual parameters, see the Explanation section of the
list_streams_params request earlier in this chapter.
8-470
VOS System Analysis Manual (R073)
set_streams_param
Examples
The following example uses the set_streams_param request to perform range
checking on the parameters, then uses the list_streams_params request to
display the changed parameters.
as: set_streams_param max_daemons 2
Changing sys streams max daemons (max_daemons) from 3 to 2
as: set_streams_param daemon_wait_time -5
set_streams_param: Argument is not within the range allowed.
Error in param_value. -5
as: set_streams_param flush_memory_age 34
Changing flush memory age (flush_memory_age) from 32 to 34
as: list_streams_params daemon_wait_time
std daemon wait time (1/1024 sec) (daemon_wait_time) 61440
The analyze_system Command and Requests
8-471
set_tape_buffer_mode
set_tape_buffer_mode
8-
Purpose
This request sets the buffer mode of a tape drive to streaming or start-stop mode.
Display Form
------------------------------ set_tape_buffer_mode ---------------------------device_name:
buffer_mode: start_stop
Command-Line Form
set_tape_buffer_mode device_name buffer_mode
Arguments
* device_name
The name of the tape that you want to set the buffer mode for.
Required
* buffer_mode
<CYCLE>
The values are streaming or start_stop. The default is start_stop.
When the module is booted, the buffer modes are automatically set to streaming.
Explanation
VOS allots more memory to a tape drive in streaming mode than one in start-stop
mode. This means that, depending on the types of tasks you are doing, the tape drive
may be faster if it is set to streaming. However, the primary purpose of the
set_tape_buffer_mode request is not to control speed, but to tailor system memory
usage.
The set_tape_buffer_mode request does not display output.
8-472
VOS System Analysis Manual (R073)
set_tp_param
set_tp_param
8-
Purpose
This request modifies the values of a TP debugging/tuning parameter.
Display Form
------------------------------- set_tp_param ----------------------------------param_name:
param_value:
Command-Line Form
set_tp_param param_name
param_value
Arguments
* param_name
The name of the parameter whose value is to be displayed.
* param_value
The value to which the parameter will be set.
Required
Required
Explanation
This request allows you to change the TP debugging/tuning parameters listed in
Table 8-2. If param_value is invalid, the request displays a message supplying valid
values or ranges. If the request successfully changes the parameter, the request
displays the previous and subsequent values as an acknowledgment.
The analyze_system Command and Requests
8-473
set_tp_param
Table 8-2. Parameter Values of the set_tp_param Request (Page 1 of 3)
Name
Values
Description
abort_priority
0 through 9
(the default is 5)
A transaction with this priority or higher
immediately aborts lower-priority transactions
that hold needed locks. A transaction with a
priority less than this value waits the amount
of time specified for the abort_wait_time
parameter before aborting another
transaction.
abort_wait_time
0 through 2**31 ms
(the default is 5000 ms)
This parameter specifies the maximum
amount of time that a transaction waits for a
lock to become free (when neither priority nor
start-time criteria is met).
conflict_timeout
0 through 2**31 ms
(the default is 5000 ms)
This parameter specifies the conflict time
used with conflict logging. For more
information, see the lock_conflicts
parameter description.
deadlocks
on, off, and log
(the default is on)
This parameter controls deadlock detection.
Its values are as follows:
on turns on deadlock detection but does not
log deadlocks
off turns off deadlock detection
log turns on deadlock detection and logs
deadlocks in the file syserr_log.date
lock_conflicts
no_logging,
log_timeout,
log_preemptive,
and log_all
(the default is
no_logging)
This parameter controls lock-conflict logging.
Its values are as follows:
no_logging specifies no logging
log_timeout logs apparent deadlocks;
specifically, it logs lock-conflict aborts in
which the aborted transaction held the
required lock longer than the time specified
in conflict_timeout
log_preemptive logs suspicious aborts;
specifically, it logs lock-conflict aborts in two
cases: (1) when the aborting transaction
waited for a required lock longer than the
time specified in conflict_timeout; or
(2) when the aborting transaction started
more than 10 seconds before the aborted
transaction (the set_tp_parameters
command specifies this time)
log_all logs all lock-conflict aborts. Do
not use this value during normal operation
because it can affect performance.
8-474
VOS System Analysis Manual (R073)
set_tp_param
Table 8-2. Parameter Values of the set_tp_param Request (Page 2 of 3)
Name
Values
Description
lock_manager
on and off
(the default is on)
This parameter activates or deactivates the
lock manager. Its values are as follows:
on turns on the lock manager
off turns off the lock manager and causes
behavior similar to that in releases prior to
VOS Release 14.0.0
max_blks_per_key
1 through 4
(the default is 4)
This parameter allows you to modify the
disk-block-reservation algorithm. Specifically,
it allows you to modify the maximum number
of blocks for a key.
max_blks_per_rcd
1 through 10
(the default is 10)
This parameter allows you to modify the
disk-block-reservation algorithm. Specifically,
it allows you to modify the maximum number
of blocks for a record.
max_seq_blks
1 through 9
(the default is 9)
This parameter allows you to modify the
disk-block-reservation algorithm. Specifically,
it allows you to modify the maximum number
of blocks for a sequential file.
perf_diags
off and
write_with_read_lock
(the default is off)
This parameter provides diagnostic
information. Specify
write_with_read_lock to log all
situations in which a write operation is
performed while holding a read lock to that
record. Although such a situation is not
invalid, it is inefficient and can result in
deadlocks if two processes are executing the
same sequence concurrently.
sect_blk_limit
0 through 2**31
(the default is 100)
This parameter represents the maximum
number of modified blocks related to the TSIs
being accumulated in a section before the
section is completed and its processing
commenced. This parameter can affect
system performance.
sect_tsi_limit
0 through 2**31
(the default is 24)
This parameter represents the maximum
number of TSIs being accumulated in a
section before the section is completed and its
processing commenced. This parameter can
affect system performance.
The analyze_system Command and Requests
8-475
set_tp_param
Table 8-2. Parameter Values of the set_tp_param Request (Page 3 of 3)
Name
Values
Description
syserr_action
value
crash, warn, or
dont_display,
or the corresponding
values 0, 1, or 2
(the default is
dont_display);
you can form additional
valid values by masking
bits together; thus, any
integer is accepted
This parameter is used when messages are
logged to the file syserr_log.date as the
result of deadlock detection, lock-conflict
logging, or performance diagnostics. The
value crash causes the system to crash
when the message is logged. The value warn
causes the message to be logged without
crashing the system.
CAUTION: An incorrect setting of this parameter can cause the s$commit_transaction
subroutine to return with no error even when insufficient disk space prevents the TPOverseer from
committing the transaction. For information on the s$commit_transaction subroutine, see the
VOS TPF reference manuals.
Examples
The following example illustrates the use of the set_tp_param request.
as:
set_tp_param abort_priority 9
Changing transaction abort priority (abort_priority)
from 5 to 9
8-476
VOS System Analysis Manual (R073)
set_word
set_word
8-
Purpose
This request sets the value of one or more words in the current environment.
CAUTION
Use this request only when instructed to do so by the
CAC.
Display Form
----------------------------------- set_word ----------------------------------start_address: *
data:
-check:
-io:
no
-physical:
no
Command-Line Form
set_word start_address data
[-check check_values]
[-io]
[-physical]
Arguments
* start_address
The address of the first word to be set. This value can be in any of the formats for
address values of a program. If you do not supply a value, VOS selects words
beginning at the last address value referenced in similar requests. (For information
on address formats, see Chapter 3.)
* data
Required
A string of one or more hexadecimal data values, separated by spaces, to which
consecutive words beginning at start_address are set.
The analyze_system Command and Requests
8-477
set_word
* -check check_values
A string of one or more hexadecimal data values, separated by spaces, to which
consecutive words beginning at start_address are compared. If you specify this
argument, the specified words are set only if the current values of the compared
words match the check values.
* -io
<CYCLE>
On XA/R-series and Continuum-series modules, enables you to write to I/O space
memory locations. If you specify no, you can only write to kernel space virtual
memory locations. This is the default.
* -physical
<CYCLE>
On Continuum-series modules, enables you to write to physical memory locations.
If you specify no, you can only write to virtual memory locations. This is the default.
Explanation
The number of words set is determined by the number of data values in the string data.
For a string of n data values, the first n consecutive words, beginning with the word
specified in start_address, are set to the corresponding data values in the string.
The number of words compared is determined by the number of data values in the
string check_values, and does not need to equal the number of data values in the
string data. The words are then set only if all current values match the check values.
Examples
The following sequence of examples illustrates the use of the set_word request. In
the following example, the set_word request sets the values of the three words
beginning at the address 00FD4000.
as:
set_word 00FD4000 1 2 1234
addr
00FD4000
00FD4002
00FD4004
as:
8-478
from
0000
0000
0000
to
0001
0002
1234
VOS System Analysis Manual (R073)
set_word
In the following example, the set_word request checks and then sets the same bytes.
as:
set_word 00FD4000 5 6 7 -check 1 2 1234
addr
00FD4000
00FD4002
00FD4004
as:
from
0001
0002
1234
to
0005
0006
0007
In the following example, the set_word request checks but does not change the same
bytes, because the check failed.
as:
set_word * 5 6 7 -check 1 2 1234
set_word: 00FD4000
as:
0005 should be 0001 --- check failed.
The analyze_system Command and Requests
8-479
setup_user_program
setup_user_program
8-
Purpose
In dump, program module (file), or partition mode, this request sets the path of a
program module that has been moved or deleted.
Display Form
---------------------------- setup_user_program -------------------------------user_program_path_name:
Command-Line Form
setup_user_program user_program_path_name
Arguments
* user_program_path_name
The path name of a program module that a process is currently executing or was
executing at the time of a dump. If you specify only a file name, the request
searches the current directory. If you do not specify a value for this argument, VOS
removes or cleans up the information related to the last program module specified
with the setup_user_program request.
Explanation
In dump, program module (file), or partition mode, the setup_user_program request
sets the path of a program module that has been moved or deleted.
This request does not display any output.
8-480
VOS System Analysis Manual (R073)
sim_int_meters
sim_int_meters
8-
Purpose
This request displays the simulated interrupt meters.
Display Form
-------------------------------- sim_int_meters --------------------------------no
-reset:
-report: yes
Command-Line Form
sim_int_meters
[-reset]
[-no_report]
Arguments
* -reset
<CYCLE>
Resets the relative simulated interrupt meters to 0. When you reset the meters, the
request does not display a report unless you specify that a report should be
displayed. By default, the request does not reset the meters.
* -no_report
<CYCLE>
Specifies that the request not display output. By default, the request displays
output.
Explanation
When you specify sim_int_meters -reset, it affects only the current process
executing analyze_system and the sim_int_meters request. The command
records the reset in the file (home_dir)>as_meter_file. If more than one process
shares the same home directory, only one process at a time can reset a metering
request. If the file as_meter_file exists, it is reopened when you re-enter
analyze_system. To use the meters set since boot time, delete the file
as_meter_file.
The analyze_system Command and Requests
8-481
sim_int_meters
Examples
In the following example, the sim_int_meters request displays the simulated
interrupt meters.
as: sim_int_meters
Metering time
353:45:54
HANDLER
time_event_notify
check_dead_cpu
scheduler timer
update_load_meters
check_for_missing_ints
disk_run
iop_ring_checker
lcd_interrupt_handler
net_sip_timeout
net_retry_timeout
di_interrupt_check
di_disk_retry
fastq_status_timeout
increment_free_counter
comm_interrupt, @351
Streams Timer
TCP: 1 Sec
TCP: 1 Min
TCP: 1/2 Sec
TCP: 1/5 Sec
TCP: Sim Intr - IP Input
TELNET Server rsrv int
TELNET ACB timer int
Total
CALLS
43941
21220
6300078
1272493
42439
127283
688
254530
253955
7764
79054
160
18151
12713510
61
25882804
1274125
21244
2546803
84228
736250
132086
437
51813304
AVG TIME
ATB
LONGEST
0.29 28983.27
1.25
0.10 60016.68
0.46
0.16
202.15
3657.44
0.20
1000.83
2.93
0.76 30009.05
3.40
3.62 10005.69
865.54
0.37 *********
37.19
1.83
5003.55
41.23
0.19
5014.88
2.03
0.25 164033.20
0.81
1.03 16109.93
233.69
14.07 *********
2182.10
0.43 70164.40
1.68
0.06
100.17
0.84
2.18 *********
3.27
0.08
49.20
2.06
0.11
999.55
0.95
0.63 59948.88
2.14
0.17
500.06
9.75
0.43 15120.32
5.13
0.49
1729.78
17.01
1.78
9641.85
265.08
0.35 *********
0.90
0.13
Total simulated interrupt time: 6553.96 seconds, 0.51%
as:
8-482
VOS System Analysis Manual (R073)
24.58
LONG
0
0
1
0
0
1
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
sim_int_meters
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
HANDLER
The event for which a simulated interrupt occurred. Example of such
events are time_event_notify, check_dead_cpu,
scheduler_timer, update_load_meters,
check_for_missing_ints, disk_run, iop_ring_checker,
lcd_interrupt_handler, net_sip_timeout,
net_retry_timeout, di_interrrupt_check, di_disk_retry,
fastq_status_timeout, increment_free_counter, and
comm_interrupt.
CALLS
The number of occurrences of each type of simulated interrupt that
occurred.
AVG TIME
The average duration of each simulated interrupt.
ATB
The average time between simulated interrupts.
LONGEST
The longest amount of time a simulated interrupt of the type occurred.
LONG
The number of simulated interrupts that take more than 50 milliseconds
to process.
Related Information
For more information about metering interrupts, see the description of the
interrupt_meters request.
The analyze_system Command and Requests
8-483
sleep
sleep
8-
Purpose
This request puts the analyze_system command to sleep for a specified period, after
which VOS reactivates the analyze_system command.
Display Form
------------------------------------- sleep ------------------------------------hours:
-minutes:
-seconds:
-until:
-forever: no
Command-Line Form
sleep
[-hours hours]
[-minutes minutes]
[-seconds seconds]
[-until date_time]
[-forever ]
Arguments
* -hours hours
Puts the analyze_system command to sleep for the specified number of hours.
By default, the value of hours is 0.
* -minutes minutes
Puts the analyze_system command to sleep for the specified number of
minutes. By default, the value of minutes is 0.
* -seconds seconds
Puts the analyze_system command to sleep for the specified number of
seconds. By default, the value of seconds is 0.
8-484
VOS System Analysis Manual (R073)
sleep
* -until date_time
Puts the analyze_system command to sleep until a specified date and time. The
date_time value can be a character string in the standard form.
yy-mm-dd_hh:mm:ss
It can also be a character string in any form accepted by the (date_time)
command function. In this case, the string must be enclosed in apostrophes.
* -forever
Specifies that the analyze_system command sleep until it receives an interrupt.
Explanation
The sleep request suspends the analyze_system command for a period of time.
The request is useful after you have reset a metering request and wish to accumulate
metering information for a specific period of time.
If you specify one or more of -hours, -minutes, and -seconds, the
analyze_system command sleeps for a period of time given by the values you
specify for hours, minutes, and seconds.
If you specify -until, the analyze_system command sleeps until the specified
date and time. If the date and time are in the past, VOS reactivates the
analyze_system command immediately.
If you specify -forever, the analyze_system command sleeps until the break
condition is signaled to the analyze_system command.
Unless you specify a value for one or more arguments, the analyze_system
command does not sleep.
Related Information
For more information on the (date_time) command function and the sleep
command, see the VOS Commands Reference Manual (R098). For more information
on using the sleep request with the metering requests, see Chapter 5.
The analyze_system Command and Requests
8-485
stack
stack
8-
Purpose
This request displays the contents of the stack belonging to the analyzed process.
Display Form
------------------------------------- stack -----------------------------------stack_address:
-brief:
no
-on_units:
no
-pc:
-task:
-machine_conditions:
-unwind_data:
no
Command-Line Form
stack stack_address
[-brief]
[-on_units]
[-pc code_address]
[-task number]
[-machine_conditions address]
[-unwind_data]
Arguments
* stack_address
The address of a stack frame at which to begin the display. (In most cases, you will
not use this argument.) If you do not specify this argument, the contents of the
entire stack belonging to the analyzed process is displayed. You cannot specify
both the -task and stack_address arguments. This argument and the
-machine_conditions argument are mutually exclusive.
8-486
VOS System Analysis Manual (R073)
stack
* -brief
<CYCLE>
Displays partial information about the stack contents. The request does not display
the arguments passed. If you do not specify -brief, full information about the
stack is displayed. Arguments are displayed by the -brief no request.
* -on_units
<CYCLE>
Displays additional information about any on units in the frames of the analyzed
stack.
* -pc code_address
On a Continuum-series module, specifies the static code region address or
program counter (pc) associated with a stack_address. Although this value is
not required, specifying it may increase the amount of information displayed by
stack on a Continuum-series module. This argument and the
-machine_conditions argument are mutually exclusive.
* -task number
When you specify this argument, you must also provide a task number. The output
from the request will then display stack information applying only to the specified
task. You cannot specify both the -task and stack_address arguments.
* -machine_conditions address
On a Continuum-series module, displays the stack trace using the stack pointer
(sp) and program counter (pc) pointer values derived from the full set of registers
at a point in time such as when an interrupt, trap, or break instruction is issued.
Specifies the address of the machine conditions register structure. You can verify
the address by specifying it for the dump_regs request. This argument and the
stack_address and -pc arguments are mutually exclusive.
* -unwind_data
<CYCLE>
On a Continuum-series module, displays derived data such as registers saved on
the stack and other detailed stack frame information which you can use to decipher
the stack and produce a trace. This argument is usually only used for kernel
debugging. The default value is no.
Explanation
The stack request displays the contents of a stack belonging to the analyzed process.
Specify the process request to indicate a particular process before using the stack
request.
On Continuum-series modules, much less information is available in stacks than on
XA/R-series modules. Much of the information that used to appear in stacks now
appears in Continuum-series processor registers. A machine conditions structure
tracks the contents of the registers. In order to display a complete stack trace on a
Continuum-series module, especially a stack trace that starts in the middle of a stack,
The analyze_system Command and Requests
8-487
stack
you need to specify additional information with the -pc or -machine_conditions
argument, and possibly, the -unwind_data argument.
Examples
In the following example, the stack request displays a (shortened) stack listing. When
no arguments are specified, the output lists each procedure name, program module
called by the process, the stack frame address of the program module, and arguments
passed.
NOTE
When the value of arguments is displayed, the stack
request does not know the size of the arguments. It
always displays four bytes of data. If the actual data is
shorter, ignore the extra information. If the actual
argument is larger, you must use the display request to
see the additional information.
as: stack
give_up_cpu
fp: 3FF6FF00 pc: 80540EBC (give_up_cpu_i+16EC, line
1247)
2 args:
Arg 1: r16 = 81B82780 -> 011280FB
Arg 2: r17 = 3FF6FF80 -> 0000002A
s$$suspend_process_real
fp: 3FF6FFB0 pc: 80541758 (suspend_resume_i+7A8,
line 197)
2 args:
Arg 1: r16 = ******** -> ********
Arg 2: r17 = 3FF78FAE -> 043902A6
wire_and_forward
fp: 3FF6FFF0 pc: 80692258
(atlantic_waf_and_sis+258)
Number of args is unknown.
On-units at 80692AF8
kernel_trap$
fp: 3FF78FC0 pc: 807CCE64 (s$suspend_process+5C
(kernel_trap_i+18234))
Number of args is unknown.
On-units at 807B4808
s$suspend_process_glue
fp: 3FEA8040 pc: 0082E578 (s$paged_glue+1350)
Number of args is unknown.
spwat
fp: 3FEA80A0 pc: 000C1F34 (sp+FE4, line 9483)
3 args:
Arg 1: r16 = 3FEA8108 -> 00000000
Arg 2: r17 = ******** -> ********
Arg 3: r18 = ******** -> ********
8-488
VOS System Analysis Manual (R073)
stack
ksliwat
7 args:
Arg 1: r16
Arg 2: r17
Arg 3: r18
Arg 4: r19
Arg 5: r20
Arg 6: r21
Arg 7: r22
kslwait
ksuclnwt
ksucln
ksbrdp
opirip
opidrv
sou2o
opimai
fp: 3FEA8260
pc: 000D1838 (ksl+5468, line 12919)
= 0000012C ->
= 00000001 ->
= 00000004 ->
= 00000000 ->
= 0000012C ->
= 00000000 ->
= 00000000 ->
fp: 3FEA82B0
********
********
********
********
********
********
********
pc: 000D1C00 (ksl+5830, line 12957)
6 args:
Arg 1: r16 = ******** -> ********
Arg 2: r17 = 00062638 -> 17940005
Arg 3: r18 = 00000001 -> ********
Arg 4: r19 = 0004F268 -> 78000010 x
Arg 5: r20 = ******** -> ********
Arg 6: r21 = 00062638 -> 17940005
fp: 3FEA8450 pc: 000F32A8 (ksucln+3828, line 10344)
2 args:
Arg 1: r16 = ******** -> ********
Arg 2: r17 = ******** -> ********
fp: 3FEA8500 pc: 000F3414 (ksucln+3994, line 10374)
1 args:
Arg 1: r16 = ******** -> ********
fp: 3FEA86A0 pc: 000ED42C (ksb+2A7C, line 9815)
Number of args is unknown.
fp: 3FEA9210 pc: 0082AF10 (opirip+430, line 10634)
3 args:
Arg 1: r16 = ******** -> ********
Arg 2: r17 = 00000000 -> ********
Arg 3: r18 = 00000000 -> ********
fp: 3FEA9570 pc: 0082A604 (opidrv+544, line 11304)
3 args:
Arg 1: r16 = 00000032 -> ********
Arg 2: r17 = 00000000 -> ********
Arg 3: r18 = 00000000 -> ********
fp: 3FEA95F0 pc: 0082A07C (sou2o+18C, line 8186)
4 args:
Arg 1: r16 = 3FEA9758 -> 00000000
Arg 2: r17 = 00000032 -> ********
Arg 3: r18 = 00000000 -> ********
Arg 4: r19 = 00000000 -> ********
On-units at 3FEA9590
fp: 3FEA98C0 pc: 000087DC (opimai+11C, line 102)
2 args:
Arg 1: r16 = ******** -> ********
Arg 2: r17 = 008CF9B0 -> 013C18E0
The analyze_system Command and Requests
8-489
stack
main
298)
fp: 3FEA9B00
pc: 000084A8 (oracle_main_7+4A8, line
Number of args is unknown.
On-units at 3FEA98E0
s$start_c_program
fp: 3FEA9F40 pc: 00008CA4 (s_start_c_program+314,
line 190)
Number of args is unknown.
On-units at 3FEA9B10
start_user_program
fp: 3FEA9F90 pc: 807F9AB4
(start_user_program_i+3D4)
On-units at 80826760
Trace complete.
In the following example, the stack request displays brief information about all object
modules in the stack. When you specify -brief, the arguments are not displayed.
(The stack -brief request is the same as the trace request.)
as: stack -brief
give_up_cpu
fp: 3FF6FF00 pc: 80540EBC (give_up_cpu_i+16EC, line
1247)
s$$suspend_process_real
fp: 3FF6FFB0 pc: 80541758 (suspend_resume_i+7A8,
line 197)
wire_and_forward
fp: 3FF6FFF0 pc: 80692258
(atlantic_waf_and_sis+258)
On-units at 80692AF8
kernel_trap$
fp: 3FF78FC0 pc: 807CCE64 (s$suspend_process+5C
(kernel_trap_i+18234))
On-units at 807B4808
s$suspend_process_glue
fp: 3FEA8040 pc: 0082E578 (s$paged_glue+1350)
spwat
fp: 3FEA80A0 pc: 000C1F34 (sp+FE4, line 9483)
ksliwat
fp: 3FEA8260 pc: 000D1838 (ksl+5468, line 12919)
kslwait
fp: 3FEA82B0 pc: 000D1C00 (ksl+5830, line 12957)
ksuclnwt
fp: 3FEA8450 pc: 000F32A8 (ksucln+3828, line 10344)
ksucln
fp: 3FEA8500 pc: 000F3414 (ksucln+3994, line 10374)
ksbrdp
fp: 3FEA86A0 pc: 000ED42C (ksb+2A7C, line 9815)
opirip
fp: 3FEA9210 pc: 0082AF10 (opirip+430, line 10634)
opidrv
fp: 3FEA9570 pc: 0082A604 (opidrv+544, line 11304)
sou2o
fp: 3FEA95F0 pc: 0082A07C (sou2o+18C, line 8186)
On-units at 3FEA9590
opimai
fp: 3FEA98C0 pc: 000087DC (opimai+11C, line 102)
main
fp: 3FEA9B00 pc: 000084A8 (oracle_main_7+4A8, line
298)
On-units at 3FEA98E0
s$start_c_program
fp: 3FEA9F40 pc: 00008CA4 (s_start_c_program+314,
line 190)
8-490
VOS System Analysis Manual (R073)
stack
On-units at 3FEA9B10
start_user_program
fp: 3FEA9F90
(start_user_program_i+3D4)
On-units at 80826760
Trace complete.
pc: 807F9AB4
In the following example, the stack request displays full (but here abbreviated)
information about all object modules in the stack, and additional information about all
on units in the stack. When you specify -on_units, the following information is
displayed for each on unit on the analyzed stack.
flags shows the settings of flags for the on unit. The two most important are
enabled, which indicates that the on unit is active, and system, which indicates
that the default system error handler should be invoked.
handler returns the address where the executable code for the on unit is located.
fcb_ptr is a pointer to a VOS PL/I file control block.
as: stack -on_units
give_up_cpu
fp: 3FF6FF00 pc: 80540EBC (give_up_cpu_i+16EC, line
1247)
2 args:
Arg 1: r16 = 81B82780 -> 011280FB
Arg 2: r17 = 3FF6FF80 -> 0000002A
s$$suspend_process_real
fp: 3FF6FFB0 pc: 80541758 (suspend_resume_i+7A8,
line 197)
2 args:
Arg 1: r16 = ******** -> ********
Arg 2: r17 = 3FF78FAE -> 043902A6
wire_and_forward
fp: 3FF6FFF0 pc: 80692258
(atlantic_waf_and_sis+258)
Number of args is unknown.
On unit for the anyother condition at 80692AF8:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
atlantic_waf_and_sis+550
fcb_ptr:
00000001
kernel_trap$
fp: 3FF78FC0 pc: 807CCE64 (s$suspend_process+5C
(kernel_trap_i+18234))
Number of args is unknown.
On unit for the anyother condition at 807B4808:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
i860_kernel_trap_support+4FC
fcb_ptr:
00000001
s$suspend_process_glue
fp: 3FEA8040 pc: 0082E578 (s$paged_glue+1350)
The analyze_system Command and Requests
8-491
stack
spwat
ksliwat
kslwait
...
main
298)
Number of args is unknown.
fp: 3FEA80A0 pc: 000C1F34 (sp+FE4, line 9483)
3 args:
Arg 1: r16 = 3FEA8108 -> 00000000
Arg 2: r17 = ******** -> ********
Arg 3: r18 = ******** -> ********
fp: 3FEA8260 pc: 000D1838 (ksl+5468, line 12919)
7 args:
Arg 1: r16 = 0000012C -> ********
Arg 2: r17 = 00000001 -> ********
Arg 3: r18 = 00000004 -> ********
Arg 4: r19 = 00000000 -> ********
Arg 5: r20 = 0000012C -> ********
Arg 6: r21 = 00000000 -> ********
Arg 7: r22 = 00000000 -> ********
fp: 3FEA82B0 pc: 000D1C00 (ksl+5830, line 12957)
6 args:
Arg 1: r16 = ******** -> ********
Arg 2: r17 = 00062638 -> 17940005
Arg 3: r18 = 00000001 -> ********
Arg 4: r19 = 0004F268 -> 78000010 x
Arg 5: r20 = ******** -> ********
Arg 6: r21 = 00062638 -> 17940005
fp: 3FEA9B00
pc: 000084A8 (oracle_main_7+4A8, line
Number of args is unknown.
On unit for the error condition at 3FEA98E0:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
se_service_condition_wrap+64, line 74
fcb_ptr:
00000001
s$start_c_program
fp: 3FEA9F40 pc: 00008CA4 (s_start_c_program+314,
line 190)
Number of args is unknown.
On unit for the error condition at 3FEA9B10:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
s_crt_sigassert+964, line 390
fcb_ptr:
00000001
On unit for the zerodivide condition at 3FEA9B30:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
s_crt_sigassert+A38, line 440
fcb_ptr:
00000001
On unit for the overflow condition at 3FEA9B50:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
8-492
VOS System Analysis Manual (R073)
stack
handler:
fcb_ptr:
On unit for the
flags:
s_crt_sigassert+A38, line 440
00000001
underflow condition at 3FEA9B70:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
s_crt_sigassert+A38, line 440
fcb_ptr:
00000001
On unit for the break condition at 3FEA9B90:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
s_crt_sigassert+B98, line 529
fcb_ptr:
00000001
On unit for the user_defined condition at 3FEA9BB0:
name:
_crt_kill
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
s_crt_sigassert+F1C, line 727
fcb_ptr:
00000001
...
On unit for the user_defined condition at 3FEA9DB0:
name:
_C_SIGABRT
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
s_crt_sigassert+964, line 390
fcb_ptr:
00000001
start_user_program
fp: 3FEA9F90 pc: 807F9AB4
(start_user_program_i+3D4)
On unit for the tasktimer condition at 80826760:
flags:
enabled, ^snap, ^system, ^use_frame, shared,
^do_goto, ^allow_reraise
handler:
task_control+2C70, line 830
fcb_ptr:
00000001
Trace complete.
as:
The analyze_system Command and Requests
8-493
status
status
8-
Purpose
This request displays information about the current analyze_system environment,
including version of VOS, the analyzed program module, and the analyze_system
command.
Display Form
------------------------------------ status ---------------------------------no
-dump_pages:
-dump_page_hash_table: no
-controller_pages:
no
-modified_pages:
no
-brief:
no
Command-Line Form
status
[-dump_pages]
[-dump_page_hash_table]
[-controller_pages]
[-modified_pages]
[-brief]
Arguments
* -dump_pages
<CYCLE>
Displays a list of virtual pages in the dump if analyze_system is in dump mode.
The default is not to display virtual pages in the dump.
* -dump_page_hash_table
<CYCLE>
Displays the hash table for virtual pages in the dump if analyze_system is in
dump mode. The hash table lists the number of entries for each bucket. The default
is not to display the hash table for virtual pages in the dump.
8-494
VOS System Analysis Manual (R073)
status
* -controller_pages
<CYCLE>
Displays s list of any IOP pages in the dump if analyze_system is in dump mode.
The default is not to display controller pages in the dump.
* -modified_pages
<CYCLE>
Displays a list of any modified code pages in the dump if analyze_system is in
dump mode. The default is not to display modified pages in the dump.
* -brief
<CYCLE>
Displays information only about the current module, boot partition, and version of
VOS. The default is to display full status information.
Explanation
If you do not specify any arguments for the status request, this request displays
version and bind information about the VOS release, analyzed program module, and
analyze_system command on the current module.
If you place analyze_system in dump mode by issuing the use_dump request, the
status request -dump_pages, -controller_pages, and -modified_pages
arguments display information about the pages in the dump.
Examples
In the following example, the status command displays status information about the
operating system, user program, and the analyze_system command.
as:
status
Using module %es#m17, booted from partition 4 on disk %es#m17
Operating system version:
VOS Release 13md
Operating system program module info:
version:
VOS Release 13md
bound by:
Joe_Smith.Eng
date/time bound:
94-11-16 13:15:52 EST
binder version:
bind, Release 13ls
binder options:
kcbtsm
User program module info:
pathname: %es#m17>system>command_library>analyze_system.pm
version:
Release 13md
bound by:
Installer.Installer
date/time bound:
94-11-03 10:27:55 EST
binder version:
bind, Release 13ls
binder options:
cbtsm
The analyze_system Command and Requests
8-495
status
analyze_system program module info:
pathname: %es#m17>system>command_library>analyze_system.pm
version:
Release 13md
bound by:
Installer.Installer
date/time bound:
94-11-03 10:27:55 EST
binder version:
bind, Release 13ls
binder options:
cbtsm
as:
Note that the binder options are k for bind_kernel, c for -compact, b for
-control, t for -table, s for -search, p for pathnames used in arguments and m
for -map.
In the following example, the status command displays the modified pages in a
dump.
as: list_dumps
Dumps for %es#m17, located in %es#m17>Overseer>dumps:
1) system.95-01-31.13:52:47.c.dump
3) system.95-04-11.17:05:31.c.dump
2) system.95-03-04.16:22:40.c.dump
4) system.95-05-16.05:48:52.c.dump
as: use_dump 1
Detected compressed dump.
Using %sys#m1>Overseer>dumps>system.95-01-31.13:52:47.c.dump
Warning: Modified code pages present in dump.
VOS Release 13md, analyze_system Release 13.0.1al
use_dump: The version of the program has changed.
%sys#libs>m1_pms>c7100.pm
Using process on CPU31.
Current process is 1060, ptep 82EF41E0, Joe_Smith.Eng (mk:disk_cm_msg.obj
+)
PCP called from 80643640 on CPU31
Ram pages from IOP 1 present.
Ram pages from IOAs : 0,2,3,4,5,12,16,18,19,20,21,28,29 present (IOP 1).
...
Crash message: verify_lock_interrupt: Trap Crash.
as: status -modified_pages
Using dump %sys#m1>Overseer>dumps>system.95-01-31.13:52:47.c.dump (#1)
and partition 4 on disk %es#m17
Dump info:
PCP time:
dumped at
dumped on
Operating
partition
8-496
95-01-31.13:52:47
95-01-31 14:52:47 EDT
%sys#m1
System bound at 94-11-16 14:15:52 EDT
4
VOS System Analysis Manual (R073)
status
24023 pages.
78 processes.
dump is complete.
Dump pages:
VPN
PTEX
801D3
0 mod_code_cpu,in_mem
801D6
0 mod_code_cpu,in_mem
801E6
0 mod_code_cpu,in_mem
801E7
0 mod_code_cpu,in_mem
80631
0 mod_code_cpu,in_mem
80636
0 mod_code_cpu,in_mem
BFD3E
0 mod_code_cpu,in_mem
BFD3F
0 mod_code_cpu,in_mem
BFD44
0 mod_code_cpu,in_mem
...
as:
The analyze_system Command and Requests
8-497
summary
summary
8-
Purpose
This request lists the process names, numbers, and state of processes on the analyzed
module.
Display Form
------------------------------------ summary ----------------------------------nno
-full:
-running: no
-pp_pages: no
Command-Line Form
summary
[-full]
[-running]
[-pp_pages]
Arguments
* -full
<CYCLE>
Displays detailed information about any process that is waiting.
* -running
<CYCLE>
Displays information about processes that are currently running on CPUs, or that
were assigned to CPUs at the time a dump was taken. If you omit this argument,
VOS displays information about all processes, except those waiting on log-in
terminal events.
* -pp_pages
<CYCLE>
Shows the amount of paging partition and the paging file space being used by the
processes on the module. Other ways of obtaining this information include using
the match pp_pages;dump_pte request, the display_paging_usage
command, and the s$get_paging_usage subroutine. For more information
about the s$get_paging_usage subroutine, see the VOS Subroutines manuals.
8-498
VOS System Analysis Manual (R073)
summary
Explanation
The summary request lists the process names, numbers, and state of processes on
the analyzed module. You can issue this request in module or dump mode.
The -full argument displays detailed information on blocked processes that do not
have locks. The detailed information typically includes the name of the event the
process is waiting on, or how long the process will be sleeping. If a process has locks,
this detailed information is always displayed.
Examples
In the following example, the summary request displays information about processes
on a module.
as: summary
3: Cache_Manager_Post in suspend_process_real.
4: Cache_Manager_Timer in suspend_process_real.
12: Steve_Leverone.SysAdmin in s$$k_sleep_real (60.0 seconds).
13: System (TPOverseer) in s$$k_wait_event_real (2 events).
14: System (LinkServer1) waiting on socket for proc 0104020E event.
15: System (LinkServer2) waiting on socket for proc 0104020F event.
16: System (LinkServer3) waiting on socket for proc 01040210 event.
17: System (WatchNet) in s$$k_sleep_real (60.0 seconds).
18: System (NetworkWatchdog) in s$$k_sleep_real (900.0 seconds).
Process is running on CPU 4 right now; no stack addr known.
No frame address for process 19, System (TheOverseer) on CPU4
20: System (BatchOverseer) in s$$k_wait_event_real (6 events).
21: System (MailTransport1) waiting on macro event 01042079.
22: System (MailUserAgent1) waiting on macro event 01044066.
23: System (MailTransport2) waiting on macro event 0104406D.
24: System (load_control) waiting on SERVER for load_control.server_q event.
25: System (MailUserAgent2) waiting on macro event 0104607F.
26: System (wb_janitor) waiting on SERVER for ofc_janitor.server_qu event.
27: System (MailCommand1) waiting on SERVER for mail_command.server_q event.
28: System (MailNotifier) waiting on
%es#m10>system>postoffice>MH_Notifier.event.
29: System (MailSorter) waiting on
%es#m10>system>postoffice>MH_Sorter.event.
30: System (LinkServer4) waiting on socket for proc 0104031E event.
31: System (terminal_logger) in s$$k_sleep_real (1800.0 seconds).
32: System (pdnClient.1) waiting on socket for proc 01040220 event.
33: System (pdnClient.2) waiting on socket for proc 01040221 event.
34: System (pdnClient.3) waiting on socket for proc 01040222 event.
....
as:
The analyze_system Command and Requests
8-499
summary
In the following example, the summary request displays information only about running
processes in a dump.
as: list_dumps
Dumps for %es#m17, located in %es#m17>Overseer>dumps:
1) system.96-12-16.18:51:42.c.dump
3) system.98-07-20.12:06:29.c.dump
2) system.98-06-15.11:41:18.c.dump
as: use_dump 2
Detected compressed dump.
Using %es#m17>Overseer>dumps>system.98-06-15.11:41:18.c.dump
Warning: The dump was taken from partnered memory contents after reboot.
Warning: The kernel-loadable program streams.cp.pm has been modified since
the d
+ump was generated.
Warning: The kernel-loadable program gdl.pm has been modified since the dump
was
+ generated.
Warning: The kernel-loadable program dlmux.pm has been modified since the
dump w
+as generated.
Warning: The kernel-loadable program 3270_remote.pm has been modified since
the
+dump was generated.
Warning: The kernel-loadable program osl_net_driver.pm has been modified
since t
+he dump was generated.
VOS Release 13.3.3l, analyze_system Release 14.0.0m
PCP was not entered
CPU28 was not stopped.
CPU29 was not stopped.
CPU26 was not stopped.
CPU27 was not stopped.
CPU30 was not stopped.
CPU31 was not stopped.
Crash message:
as: summary -running
Crash message:
No frame address for process 1, CPU28.Idle on CPU28
No frame address for process 6, CPU29.Idle on CPU29
No frame address for process 7, CPU26.Idle on CPU26
No frame address for process 8, CPU27.Idle on CPU27
No frame address for process 10, CPU31.Idle on CPU31
No frame address for process 26, Maintenance_Utility on CPU30
Process has the maintenance process lock member of the hardware
history
table group write locked on call side.
Process has 1 fast locks locked.
as:
8-500
VOS System Analysis Manual (R073)
summary
The following is example from the summary request that displays information about the
paging partition space used by running processes on a module.
as:
summary -pp_pages
1: CPU28.Idle in atlantic_evict_cache_page.
3: Cache_Manager_Post in post_wait.
26 paging partition pages used.
4: Cache_Manager_Timer in timer_wait.
26 paging partition pages used.
5: Cache_Manager_Locker in locker_wait.
26 paging partition pages used.
6: CPU29.Idle in schedule_interrupt_real.
Process is running on CPU 30 right now; no stack addr known.
No frame address for process 7, CPU30.Idle on CPU30
Process is running on CPU 31 right now; no stack addr known.
No frame address for process 8, CPU31.Idle on CPU31
27: Kernel_Utility in wait_pi_real.
26 paging partition pages used.
28: Maintenance_Utility in wait_pi_real.
26 paging partition pages used.
29: Diagnostic_Utility in wait_pi_real.
26 paging partition pages used.
33: Diagnostic_Utility in wait_pi_real.
26 paging partition pages used.
37: Qrun_Daemon in qrun_daemon.
26 paging partition pages used.
38: Paging_Daemon in paging_daemon_sleep.
26 paging partition pages used.
40: System (TPOverseer) in s$$k_wait_event_util_real.
61 paging partition pages used.
41: System (LinkServer1) in wait_masked_pi_real.
96 paging partition pages used.
42: System (LinkServer2) in wait_masked_pi_real.
96 paging partition pages used.
43: System (LinkServer3) in wait_masked_pi_real.
96 paging partition pages used.
....
as:
The analyze_system Command and Requests
8-501
terminal_meters
terminal_meters
8-
Purpose
This request displays the terminal meters.
Display Form
------------------------------- terminal_meters -----------------------------no
nA
-all:
-channel:
-histogram: no
Command-Line Form
terminal_meters
[-all]
[-channel channel]
[-histogram]
Arguments
* -all
<CYCLE>
Displays statistics about each terminal device attached to a module. By default, the
request displays summary information about all terminal devices attached to a
module.
* -channel channel
Displays statistics about a specified terminal device and summary information
about all terminal devices attached to a module.
* -histogram
Displays input and output terminal data traffic.
<CYCLE>
Explanation
The terminal_meters request displays the terminal meters.
8-502
VOS System Analysis Manual (R073)
terminal_meters
Examples
In the following example, the terminal_meters request displays terminal meter
information.
as: terminal_meters
Function
total input characters
total host echoed chars
total z80 echoed chars
total output characters
average input size
average output size
total breaks
total dialups
total read waits
total write waits
total interrupts
total reads
total writes
as:
Count
ATB
9764
42870
0
13727081
2.7
54.2
3
97
2715
3488
59090
3224
232738
130475.6
29716.9
0.0
92.8
424654700.0
13133650.0
469231.7
365242.0
21559.7
395150.1
5473.8
The following table describes the columns that appear in the output of the preceding
example.
Column
Description
Function
The terminal meter being measured.
Count
The number of characters, breaks, dialups and other events occurring on a
terminal device since the last reboot.
ATB
The average time in milliseconds between characters, breaks, dialups, and
other events on a terminal device.
The analyze_system Command and Requests
8-503
tpq_meters
tpq_meters
8-
Purpose
This request displays information about queues and pseudoqueues used in transaction
processing.
Display Form
-------------------------------- tpq_meters ----------------------------------no
nA
-no_header:
-reset:
no
-full:
no
-queues:
-data:
-report:
yes
-interval:
-output_path:
Command-Line Form
tpq_meters
[-no_header]
[-reset]
[-full]
[-queues]
[-data]
[-no_report]
-interval [time_interval]
[-output_path file_name]
Arguments
* -no_header
<CYCLE>
Suppresses the display of header information. By default, the request displays
header information.
8-504
VOS System Analysis Manual (R073)
tpq_meters
* -reset
<CYCLE>
Temporarily resets the queue meters until you exit analyze_system. The meters
are reset only for the execution of analyze_system. The meter file (either
as_meter_file in the home directory or the meter file specified by the
use_meter_path request) records the current values and provides a new 0-point
for reporting. By default, the request does not reset the queue meters.
* -full
<CYCLE>
Displays all queues, including those that are currently not active. By default, the
request does not display all queues. This argument is meaningful only if you also
specify the -interval argument.
* -queues
<CYCLE>
Displays actual and/or pseudoqueues, based on which of the following values you
specify.
If you specify the driver value, the request displays actual queues.
If you specify the running value, the request displays pseudoqueues.
If you specify the all value, the request displays actual and pseudoqueues.
This is the default value.
* -data
<CYCLE>
Determines the format in which the request displays data when you also specify
the -interval argument. By default, the argument displays the average wait,
busy, and total times associated with a queue, plus the message arrival count. A
list of the formats follows.
The averages value displays the average wait and busy times only.
The all value displays average and total times.
The counts value displays the counts for arrivals, starts, and completions, as
well as averages.
The time/counts value displays the total times and the total counts.
The time value displays the total wait and busy times, as well as the total
combined times since you started the tpq_meters request.
* -no_report
<CYCLE>
Specifies that the request should not display data. By default, the request always
displays data. You should specify this argument with the -reset argument, which
typically does not display data; in this case, the request displays the data before
the reset occurs.
* -interval [time_interval]
Specifies a value from 1 through 60 indicating the interval at which the request
displays queue values. The time_interval value represents seconds and is
The analyze_system Command and Requests
8-505
tpq_meters
rounded up to one of the following: 1, 2, 5, 10, 30, or 60. If you do not specify the
optional time_interval value, the default value is 10. When you specify this
argument, the -data argument determines the displays format.
* -output_path file_name
Directs the output from the terminals screen to file_name. By default, the
request directs output to the terminals screen.
Explanation
This request displays information about queues and pseudoqueues.
Examples
The following example illustrates the use of the tpq_meters request without the
-interval argument specified.
as: tpq_meters
time
meter
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
driver
idle_wait
tlf_flush
phy_wait
section
to_twa
log_in_twa
in_twa
to_file
file_info
log_infile
mod_wait
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
1:04:41
running
rmt_running
hold_rlocks
hold_wlocks
waiting
retrying
wait_time
busy_time
arrive
start complete
1
0
324
63
0
23
69
37
10305
10328
349
0
0
0
0
0
595
120
464
309
816
52
465
0
2513
0
845
845
845
844
843
843
843
831
816
0
2513
0
845
845
845
843
843
843
833
816
816
0
2513
0
845
845
844
843
843
843
831
816
816
0
523
0
3766
3767
95448
124279
1656
0
1510
3658
108837
0
858
0
870
870
3885
6386
858
0
867
867
3775
6143
856
0
865
863
3642
6143
The columns in the preceding example have the following meanings.
The time column shows the number of hours, minutes, and seconds (in the format
hh:mm:ss) over which the statistics have been collected.
The meter column shows the name of the queue.
The wait_time column shows the average queue waiting time.
8-506
VOS System Analysis Manual (R073)
tpq_meters
The busy_time column shows the average queue busy time.
The arrive, start, and complete columns show the counts of arrival, start, and
completion events, respectively, for each queue.
If you specify the -reset argument, the request will reset the output shown in the
preceding example; future counts and averages will be calculated from the time of the
reset.
The analyze_system Command and Requests
8-507
trace
trace
8-
Purpose
This request displays the contents of the stack belonging to the analyzed process. The
trace request is similar to the stack -brief request.
Display Form
------------------------------------ trace ------------------------------------stack_address:
-brief:
yes
-on_units:
no
-pc:
-task:
-machine_conditions:
-unwind_data:
no
Command-Line Form
trace stack_address
[-no_brief]
[-on_units]
[-pc address]
[-task number]
[-machine_conditions conditions]
[-unwind_data]
Arguments
* stack_address
The address of a stack frame at which to begin the display. (In most cases, you will
not use this argument.) If you do not specify this argument, the contents of the
entire stack belonging to the analyzed process is displayed.
8-508
VOS System Analysis Manual (R073)
trace
* -no_brief
<CYCLE>
Displays information about the stack contents and arguments passed. The default
is -brief. When you specify the default, the request only displays a list of stack
frames in the stack.
* -on_units
<CYCLE>
Displays information about each on unit in the traced stack.
* -pc address
On a Continuum-series module, the static code region address or program counter
(pc) associated with a stack_address. Although this value is not required,
specifying it may increase the amount of information displayed by stack on a
Continuum-series module. This argument and the -machine_conditions
argument are mutually exclusive.
* -task number
The task to display stack information about; the output is limited to that task. You
cannot specify both the -task and stack_address arguments.
* -machine_conditions conditions
On a Continuum-series module, the stack trace using the stack pointer (sp) and
program counter (pc) pointer values derived from the full set of registers at a point
in time such as when an interrupt, trap, or break instruction is issued. Specify the
address of the machine conditions register structure. You can verify address by
specifying it for the dump_regs request. This argument and the stack_address
and -pc arguments are mutually exclusive.
* -unwind_data
<CYCLE>
On a Continuum-series module, displays derived data such as registers saved on
the stack and other detailed stack frame information which you can use to decipher
the stack and produce a trace. This argument is usually only used for kernel
debugging. The default value is no.
Explanation
The trace request displays the contents of a stack belonging to the analyzed process.
Specify the process request to indicate a particular process before using the trace
request.
On Continuum-series modules, much less information is available in stacks than on the
XA/R-series modules. Much of the information that used to appear in stacks now
appears in Continuum-series processor registers. A machine conditions structure
tracks the contents of the registers. In order to display a complete stack trace on a
Continuum-series module, especially a stack trace that starts in the middle of a stack,
you need to specify additional information with the -pc or -machine_conditions
argument, and possibly, the -unwind_data argument.
The analyze_system Command and Requests
8-509
trace
Examples
In the following example, the trace request displays stack trace information for a user
program. When no arguments are specified, the output lists each procedure called, the
stack frame address for that procedure, the arguments passed, and the program name.
If you specify -brief, the arguments passed to each procedure are not displayed.
as: trace
00FF1E50 give_up_cpu
(give_up_cpu+7C0, line 842)
00FF1EBC suspend_process_masked_pi_real
(suspend_resume+14A, line 187)
00FF1FD4 wait_pi_real
(event+2B2, line 446)
00FF1FEC wire_and_forward
(hydra_switch_process+65E, line 996)
00FF87B4 wait_for_channel
(real_terminal_io+3CFC, line 2804)
00FF87E8 pause_wait
(real_terminal_io+1BBC, line 1490)
00FF8810 pause
(real_terminal_io+1B38, line 1473)
00FF8FB0 seq_write_terminal
(real_terminal_io+1312, line 1159)
00FF8FF4 kernel_trap
(kernel_trap+D090)
00FD58CC s$seq_write
(kernel_trap+D030)
00FD5914 seq_write
(display+14CE, line 676)
00FD595C emit_line
(display+136E, line 640)
00FD6768 display_line
(display+124E, line 611)
00FD6798 display_open_file
(display+ECA, line 503)
00FD6F34 display
(display+9A6, line 351)
00FD6FE0 start_user_program
(start_user_program+282, line 620)
Trace complete.
as:
In the following example, the trace request dipslays information about each on unit in
the analyzed stack. If you specify -on_units, the following information is displayed
for each on unit on the analyzed stack.
flags shows the settings of flags for the on unit. The two most important are
enabled, which indicates that the on unit will be invoked if found during the stack
searching phase of condition signaling, and system, which indicates that the
default system error handler will be invoked if this on unit is invoked.
handler returns the address where the code for the on unit is located.
fcb_ptr is a pointer to a VOS PL/I file control block.
as: trace -on_units
00FF1E50 give_up_cpu
(give_up_cpu+7C0, line 842)
00FF1EBC suspend_process_masked_pi_real
(suspend_resume+14A, line 187)
00FF1FD4 wait_pi_real
(event+2B2, line 446)
00FF1FEC wire_and_forward
(hydra_switch_process+65E, line 996)
On unit for the anyother condition at 001A29E0:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
line 866 in module hydra_switch_process
8-510
VOS System Analysis Manual (R073)
trace
fcb_ptr:
00000001
00FF87B4 wait_for_channel
(real_terminal_io+3CFC, line 2804)
00FF87E8 pause_wait
(real_terminal_io+1BBC, line 1490)
00FF8810 pause
(real_terminal_io+1B38, line 1473)
00FF8FB0 seq_write_terminal
(real_terminal_io+1312, line 1159)
00FF8FF4 kernel_trap
(kernel_trap+D090)
On unit for the anyother condition at 004871AC:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
s$kernel_trap+2A (kernel_trap+2A)
fcb_ptr:
00000001
00FD58CC s$seq_write
(kernel_trap+D030)
00FD5914 seq_write
(display+14CE, line 676)
00FD595C emit_line
(display+136E, line 640)
00FD6768 display_line
(display+124E, line 611)
00FD6798 display_open_file
(display+ECA, line 503)
00FD6F34 display
(display+9A6, line 351)
On unit for the cleanup condition at 00FD67A0:
flags:
enabled, ^snap, ^system, ^use_frame, ^shared,
^do_goto, ^allow_reraise
handler:
begin.248 (line 248 in module display)
fcb_ptr:
00000001
00FD6FE0 start_user_program
(start_user_program+282, line 620)
On unit for the tasktimer condition at 0025C898:
flags:
enabled, ^snap, ^system, ^use_frame, shared,
^do_goto, ^allow_reraise
handler:
s$preempt_task (line 803 in module task_control)
fcb_ptr:
00000001
Trace complete.
as:
The analyze_system Command and Requests
8-511
transaction_meters
transaction_meters
Purpose
This request displays various transaction processing (TP) meters and allows you to
reset the TP metering level.
Display Form
---------------------------- transaction_meters -------------------------------set_metering:
-no_header:
no
-reset:
no
-report:
yes
-interval:
-wait_info:
no
-section_info:
no
-lock_info:
no
-queue_info:
no
-all:
no
-detailed_aborts: no
-full:
no
-output_path:
8-512
VOS System Analysis Manual (R073)
8-
transaction_meters
Command-Line Form
transaction_meters
[-set_metering]
[-no_header]
[-reset]
[-no_report]
-interval [time_interval]
[-wait_info]
[-section_info]
[-lock_info]
[-queue_info]
[-all]
[-detailed_aborts]
[-full]
[-output_path file_name]
Arguments
* -set_metering
<CYCLE>
Changes the current TP metering level. This argument has the following values.
none indicates that metering is not enabled.
basic enables basic metering.
queue enables queue metering.
extended enables extended metering. You can specify extended only if the
-max_metering argument of the tp_overseer command was set to
extended.
* -no_header
<CYCLE>
Suppresses the display of header information. By default, the request displays
header information.
* -reset
<CYCLE>
Temporarily resets the queue meters until you exit analyze_system. The meters
are reset only for the execution of analyze_system. The meter file (either
as_meter_file in the home directory or the meter file specified by the
use_meter_path request) records the current values and provides a new 0-point
for reporting. By default, the request does not reset the queue meters.
The analyze_system Command and Requests
8-513
transaction_meters
* -no_report
<CYCLE>
Specifies that the request should not display data. By default, the request always
displays data. You should specify this argument with the -reset argument, which
typically does not display data; in this case, the request displays the data before
the reset occurs.
* -interval [time_interval]
Specifies a value from 1 through 60 indicating the interval at which the request
displays queue values. The time_interval value represents seconds and is
rounded up to one of the following: 1, 2, 5, 10, 30, or 60. If you do not specify the
optional time_interval value, the default value is 10. When you specify this
argument, the -data argument determines the displays format.
* -wait_info
<CYCLE>
Displays information involving the number of waits, the number of retries to acquire
locks, and a breakdown of timeouts and notifies from iotv (I/O transfer vector or I/O
transfer interface). By default, the request does not display this information. Note
that the request displays the number of lock waits and maximum retries per
transaction even if you do not specify this argument.
* -section_info
<CYCLE>
Displays the number of times sections were completed by reaching block limits and
TSI limits. This argument also displays the maximum TSIs and blocks per section
and the maximum time spent on the section queue. By default, the request does
not display this information.
* -lock_info
<CYCLE>
Displays information about lock-contention statistics involving the number of
read-key, read-record, write-key, and write-record locks acquired as well as search
information for each lock. This argument also displays statistics about
lock-manager activity. By default, the request does not display this information.
Note that the request displays information about the number of lock conflicts
leading to transaction aborts, deadlocks, and maximum read and write locks per
transaction even if you do not specify this argument.
* -queue_info
<CYCLE>
Displays the maximum per-transaction time spent on each actual queue. By
default, the request does not display this information. Note that the request displays
the maximum pseudoqueue time even if you do not specify this argument.
* -all
<CYCLE>
Displays all of the information provided by the -wait_info, -section_info,
-lock_info, and -queue_info arguments. By default, the request does not
display this information.
8-514
VOS System Analysis Manual (R073)
transaction_meters
* -detailed_aborts
<CYCLE>
Breaks down the display of aborts into further categories. When you specify the
default value of no, the request categorizes aborts as user requested, lock conflict,
remote, or other, which is sufficient detail in most cases. If you specify a value of
yes, the request displays up to 16 different types of aborts. In general, you should
not specify this argument with the -interval argument, as a terminal screen
cannot display all the information.
* -full
<CYCLE>
Displays all meters, including those with a value of 0. By default, the request does
not display all meters.
* -output_path file_name
Directs the output from the terminals screen to file_name. By default, the
request directs output to the terminals screen.
Explanation
This request displays the values of various TP meters.
Examples
The following example illustrates the use of the transaction_meters request with
the -interval argument specified.
as: transaction_meters -interval
Transaction Processing Statistics
10sec
30sec
1min
metering time: 2:17:26
5min
10min
1hr
Total
Started
Committed
Completed
Lock aborts
priority
timeout
Lock Waits
Deadlocks
Modified Blocks
11
12
12
0
0
0
0
0
1
33
34
34
0
0
0
5
0
3
70
70
71
0
0
0
8
0
0
331
330
330
2
1
1
94
1
4
723
719
720
3
1
2
204
0
8
906
901
903
5
2
3
233
1
12
Max
Max
Max
Max
Max
Max
Max
Max
Max
4810
10s
13s
144
142
1
0
41
140
4878
10s
14s
1507
897
2
0
42
147
5513
11s
14s
1507
897
2
0
42
147
7569
20s
23s
1603
1001
8
1
42
147
7569
20s
23s
1605
1020
8
1
42
147
8449
20s
27s
5005
4824
8
1
42
147
running
hold_rlocks
hold_wlocks
waiting
retrying
retries
aborts
rlocks
wlocks
The analyze_system Command and Requests
8-515
use_block
use_block
8-
Purpose
This request places the analyze_system command in disk block mode.
Display Form
------------------------------------ use_block ---------------------------------block_number:
-disk:
master_disk
-read_partner:
-write_partner:
Command-Line Form
use_block block_number
[-disk disk_name]
[-read_partner]
[-write_partner]
Arguments
* block_number
The block number of disk block on the specified disk.
Required
* -disk disk_name
Specifies the name of the disk from which you want to read a block. By default, the
request uses the master disk on the analyzed module.
* -read_partner
<CYCLE>
On a logically paired disk, specifies that the request read from either disk, the
primary disk, or the secondary disk. If you do not specify a value, the request
reads from either partner.
* -write_partner
<CYCLE>
On a logically paired disk, specifies that the request write to both disks, the
primary disk, or the secondary disk. If you do not specify a value, the request
writes to both paired disks.
8-516
VOS System Analysis Manual (R073)
use_block
CAUTION
Writing a value to only one disk can have unpredictable
consequences.
Explanation
The use_block request places the analyze_system command in disk block mode.
Prior to using this request, you need to determine the physical location of an active file
or other object on disk. This information can be found in the active file table entry
(AFTE) or in the active index table entry (AXTE) for indexed files. Active files are open
files opened with s$openor a related subroutine. Files opened with a word processor
such as emacs may be stored in a buffer and may not have an AFTE or AXTE. You
can display the AFTE for an active file with dump_afte and the AXTE for an active
indexed file with dump_axte. Both requests display disk address fields. Specify a field
for use_block block_number that does not contain FFFFFFFF. Also note that the
dump_afte and dump_axte requests both display the path name of the file; note the
disk on which the file is stored and specify that value as use_block disk_name.
After selecting a block with the use_block request, you can display the contents of
the block with the display request.
Examples
In the following example, the display request displays the block specified with the
use_block request. The disk block address and disk name are copied from the output
of the dump_afte request on an open abbreviations file.
as: dump_afte abbreviations
AFTE at 04C32830 for: %sys#m2_user>Eng>Joe_Smith>abbreviations
catep:
04BD5150
CATE:
aftep:
04C32830
disk_addr(-1):
FFFFFFFF
disk_addr(0):
000039A5
disk_addr(1):
000039E4
disk_addr(2):
FFFFFFFF
...
blocks_used:
2
last_block:
1
...
as: use_block 39A5 -disk %sys#m2_user; display 0 4096
00000000 000 001D616C 6C202020 43442020 20202020 |..all
CD
|
00000010 010 20627920 63757272 656E745F 64697220 | by current_dir |
00000020 020 001D0020 616C6C20 2020434D 20202020 |... all
CM
|
00000030 030 20202062 79206375 7272656E 745F6D6F |
by current_mo|
The analyze_system Command and Requests
8-517
use_block
00000040
00000050
00000060
00000070
040
050
060
070
64756C65
20202020
795F6461
676E0029
00200029
20202062
74655F74
00206669
66697273
79206469
696D6520
72737420
74202F2F
73706C61
2D6C6F6E
61732020
|dule. .)first //|
|
by displa|
|y_date_time -lon|
|gn.). first as |
00000080
00000090
000000A0
....
as:
080
090
0A0
20202020 20627920 616E616C 797A655F
73797374 656D0020 003A6669 72737420
61642020 20202020 20627920 616E616C
|
by analyze_|
|system. .:first |
|ad
by anal|
Related Information
For more information on the dump_afte and dump_axte requests, see the
descriptions in this chapter and in the section Using Disk Block Mode in Chapter 4.
For more information on file indexes, see the description of the create_file_index
command in VOS Commands Reference Manual (R098). For more information about
primary and secondary disks, see the manual VOS System Administration: Disk and
Tape Administration (R284).
8-518
VOS System Analysis Manual (R073)
use_dump
use_dump
8-
Purpose
This request places the analyze_system command in dump mode, sets the
analyzed dump, and displays information about the state of the module at the time the
analyzed dump was created.
Display Form
------------------------------------ use_dump ---------------------------------dump_number:
dump_type:
system
-path_name:
-file:
-kernel_pm_dir:
-disk:
-partition:
-next:
no
-previous:
no
-last:
no
-wait:
no
Command-Line Form
use_dump dump_number dump_type
[-path_name dump_path_name]
[-next]
[-previous]
[-last]
[-wait]
[-file program_module_path_name]
[-disk master_disk_name]
[-partition number]
[-wait]
The analyze_system Command and Requests
8-519
use_dump
Arguments
* dump_number
The dump number of the dump file to use. Use the list_dumps request to
generate and display dump numbers in >Overseer>dumps. You cannot specify
this argument and any of the other arguments that specify the dump
(-path_name, -next, -previous, and -last).
* dump_type
<CYCLE>
The type of dump; the possible values are system and iop. The default is
system.
* -path_name dump_path_name
The path name of the dump file to reference. The list_dumps request displays
the path names of the current dumps on a specified module. You cannot specify
this argument and any other arguments that specify the dump (dump_number,
-next, -previous, and -last).
* -file program_module_path_name
The path name of a file containing a copy of the version of VOS that was in use at
the time of the failure.
* -kernel_pm_dir kernel_pm_dir
The path name of the directory containing kernel-loadable program modules that
were in use when the dump was taken. If this argument is specified, use_dump
searches the specified directory for all kernel-loadable programs in use by VOS.
Otherwise, use_dump searches for each program module in the directory from
which VOS loaded that program module. This argument is useful when analyzing
a dump stored on a tape.
* -disk master_disk_name
The name of the master disk containing the VOS boot partition specified in the
-partition argument. This master disk may not necessarily contain the dump.
* -partition number
The number of a boot partition on the disk specified in the -disk argument. The
partition must contain a copy of the version of VOS that was in use at the time of
the failure.
* -next
<CYCLE>
The analyze_system command analyzes the dump file with a dump number one
greater than the dump number given in the most recent use_dump request. You
cannot specify this argument and any of the other arguments that specify the dump
(dump_number, -path_name, -previous, and -last).
8-520
VOS System Analysis Manual (R073)
use_dump
* -previous
<CYCLE>
The analyze_system command analyzes the dump file with a dump number one
less than the dump number given in the most recent use_dump request. You
cannot specify this argument and any other arguments that specify the dump
(dump_number, -path_name, -next, and -last).
* -last
<CYCLE>
The analyze_system command analyzes the most recent dump. You cannot
specify this argument and any other arguments that specify the dump:
dump_number, -path_name, -next, or -previous.
* -wait
<CYCLE>
If the dump to be analyzed is in use, the use_dump request waits until it is free,
then makes it the analyzed dump. If you do not specify this argument and the dump
is in use, the analyze_system command displays an error message and does
not set the analyzed dump.
Explanation
All of the use_dump arguments determine the data that the analyze_system
command uses in dump mode.
You must specify one of the following arguments to indicate a dump file when issuing
the use_dump request.
dump_number
-path_name
-next
-previous
-last
In addition to the dump file, the analyze_system command also needs a copy of the
version of VOS that was running at the time of the failure. In most cases, the same
version of VOS is still in a boot partition. The analyze_system command can
determine from the specified location of the dump file which boot partition contains that
correct version.
However, if that partition no longer contains that version of VOS (for example, if the
copy was lost or overwritten), you must specify a file or a partition that does contain a
copy of the version running at the time of the failure. If the copy is in a file, name the
file in the -file argument. If it is in a boot partition, use the -disk and -partition
arguments to specify the location of the partition.
Similarly, the use_dump request needs a copy of the kernel-loadable program
modules that were in use when the dump was taken. In most cases, the same versions
The analyze_system Command and Requests
8-521
use_dump
of these modules are still in the directory from which they were originally loaded, and
the use_dump request will, by default, reference these kernel-loadable program
modules.
However, if that directory no longer contains the correct versions, you must specify the
location of the proper routines by using the -kernel_pm_dir argument.
Output Format
The use_dump request displays the following:
the path name of the dump file being used
the address from which the PCP was called at the time of the failure
the version of VOS running at the time of the failure
the message issued at the time of the failure
Examples
In the following example, the list_dumps request displays a list of available dumps
and the use_dump request is set for one of these dumps.
as:
list_dumps
Dumps for %s1#m1, located in %s1#m1>Overseer>dumps:
1) system.90-02-07.16:23:03.dump
3) system.90-02-26.10:06:50.dump
2) system.90-02-22.09:35:47.dump
as:
use_dump 3
Using %s1#m1>Overseer>dumps>system.90-02-26.10:06:50.dump
VOS Release 10.0, analyze_system Release 10.0
Using process on CPU8.
Current process is 74, ptep 0074780C, Overseer.System (LANserver.6-10)
PCP called from 00158FDE on CPU8
Comm controller ram pages present for slot 20.
Comm controller ram pages present for slot 21.
Crash message: give_up_cpu: process switch on interrupt stack (via Trap
15 Fault at 000B4AA4)
as:
8-522
VOS System Analysis Manual (R073)
use_file
use_file
8-
Purpose
This request makes a VOS or firmware program module file available for analysis and
places the analyze_system command in program module (file) mode.
Display Form
------------------------------------ use_file ---------------------------------file_path_name:
Command-Line Form
use_file file_path_name
Arguments
* file_path_name
Required
The path name of a program module file that you want to analyze. This program
module can contain a copy of VOS, a user program, or a CPU PROM file whose
suffix has been changed from .rom to .pm.
Explanation
The use_file request makes a VOS or firmware program module file available for
analysis and places the analyze_system command in program module (file) mode.
You can obtain a copy of a VOS program module from a boot partition by issuing the
copy_kernel command. If you are using an XA/R-series module, you may also find
a copy of the alternate VOS kernel in the >system>release_dir directory.
NOTE
Stratus recommends that you use the debugger instead of
program module (file) mode when debugging your own
program modules.
When the analyze_system command is in program module (file) mode, you can
display or set values in the specified VOS or firmware program module.
The analyze_system Command and Requests
8-523
use_file
Example
In the following example, the use_file request is set for a VOS program module.
as: use_file vos.pm
VOS Release 13.1, analyze_system Release 13.1
as:
Related Information
For more information about program module mode, see the section Using Program
Module (File) Mode in Chapter 4. For more information about the copy_kernel
command, see the manual VOS System Administration: Disk and Tape
Administration (R284). For more information about the alternate kernel, see the VOS
Installation Guide (R386).
8-524
VOS System Analysis Manual (R073)
use_iop
use_iop
8-
Purpose
This request places the analyze_system command in IOP or IOA dump mode.
Display Form
------------------------------------ use_iop ---------------------------------iop_slot:
-iop_no:
-iop_aux: no
-ioa:
-file:
Command-Line Form
use_iop iop_slot
[-iop_no iop_number]
[-iop_aux ]
[-ioa ioa_number]
[-file file_name]
Arguments
* iop_slot
The slot number of the IOP whose memory you want to analyze. To obtain the IOP
slot number, issue the list_boards -board_type iop request. This argument
and the -iop_no argument are mutually exclusive.
* -iop_no iop_number
Specifies when the IOP whose memory you want to analyze was installed. For
example, if the IOPs in slot 2 and slot 6 were installed before the module was
rebooted, and the IOP in slot 4 was installed after the module was rebooted, the
IOP number for the IOP in slot 2 is 1, the IOP number for the IOP in slot 6 is 2, and
the IOP in slot 4 is 3. Specify a value between 1 and 14. This argument and the
iop_slot argument are mutually exclusive.
The analyze_system Command and Requests
8-525
use_iop
* -iop_aux
<CYCLE>
For paired IOPs in a dump, this argument specifies that the unspecified IOP in the
pair be analyzed. By default, only the specified IOP in a pair is analyzed.
* -ioa ioa_number
The slot number of the IOA whose memory you want to analyze. This IOA must be
controlled by the specified IOP. To obtain the IOA slot number, issue the
list_boards -board_type iop request.
* -file file_name
Specifies a file containing IOP firmware for the specified IOP or a file containing
IOA firmware for the specified IOA.
Explanation
The use_iop request places the analyze_system command in IOP or IOA mode.
This request can be used in module or dump mode. It does not display any output.
Examples
In the following example, the list_boards request displays the boards and IOPs on
a module, and the use_iop request is set to one of these IOPs.
as:
list_boards -board_type iop
Module: %sys#m1 (28 Slot Chassis, Model 2)
Id Prom --------Fault Data-----Slot
Board Type
Model Serial Rev Rev Cnt Code Last Fault Time
4 IO Processor
K20010 10841 45 45
0
0 Clock/Remote Service
K10300
3149 26 16
0
2 Disk Adapter
K10500
7119 21 19
0
0 781 MB Disk Drive
D20300 14562
0
0
0
3 Disk Adapter
K10500
7201 21 19
0
0 781 MB Disk Drive
D20300 16137
0
0
0
4 Disk Adapter
K10500
7556 21 19
0
0 781 MB Disk Drive
D20300 16464
0
0
0
5 Disk Adapter
K10500
6183 23 19
0
0 781 MB Disk Drive
D20300
5555
0
0
0
11 SCSI Tape Adapter
K12200
3415 12 12
0
7 Tape Drive 3480 Mobi T40100 ***** ***
0
12 Null Modem Comm Adap
K11100 15866 25 16
0
13 Ethernet Adapter
K10410 12580
6 18
0
14 Terminator
K10810 17107
6
0
0
...
as: use_iop 4 -ioa 13
as:
8-526
VOS System Analysis Manual (R073)
use_iop
Related Information
For more information about the list_boards request, see the description in this
manual. For more information about IOP and IOA dump modes, see the Using IOA
Dump Mode and Using IOP Dump Mode sections in Chapter 4.
The analyze_system Command and Requests
8-527
use_iop_dump
use_iop_dump
8-
Purpose
This request selects an IOP dump.
Display Form
--------------------------------- use_iop_dump ------------------------------dump_number:
-path_name:
-next:
no
-previous:
no
Command-Line Form
use_iop_dump dump_number
[-path_name dump_path_name]
[-next]
[-prev]
Arguments
* dump_number
The IOP dump number of the IOP dump you want to analyze. To obtain the IOP
dump number, issue the list_iop_dumps request. This argument and the
-path_name argument are mutually exclusive.
* -path_name dump_path_name
Specifies the path name of an IOP dump. This argument and the -path_name
argument are mutually exclusive.
* -next
<CYCLE>
Specifies that the request use the next IOP dump in the list since the request was
last executed. If a subsequent dump does not exist, the request returns an error
message.
8-528
VOS System Analysis Manual (R073)
use_iop_dump
* -prev
<CYCLE>
Specifies that the request use the previous IOP dump in the list since the request
was last executed. If the previous dump was dump number 1, the request returns
an error message.
Explanation
Issue the use_iop_dump request to select an IOP dump. You can display a list of
available IOP dumps by issuing the list_iop_dumps request.
After issuing the use_iop_dump request, you can enter IOP or IOA dump mode by
issuing the use_iop request.
Examples
In the following example, the list_iop_dumps request lists IOP dumps for a module
and the use_iop_dump request is set to one of these dumps.
as: list_iop_dumps
Dumps for %sys#m4, located in %sys#m4>Overseer>dumps:
1) iop18.95-08-15.13:32:37.dump
3) iop22.95-08-16.07:04:25.dump
2) iop18.95-08-17.09:11:06.dump
as: use_iop_dump 2
Using %sys#m4>Overseer>dumps>iop18.95-08-17.09:11:06.dump
VOS Release 12.2h, analyze_system Release 12.2h
as: use_iop -iop_no 1
as:
Related Information
For more information about the list_iop_dumps and use_iop requests, see their
descriptions in this manual. For more information about the IOP and IOA dump modes,
see Chapter 4.
The analyze_system Command and Requests
8-529
use_module
use_module
8-
Purpose
This request places the analyze_system command in module mode and specifies
the module that will be analyzed by subsequent requests.
Display Form
--------------------------------- use_module ----------------------------------module_name: % current_module
Command-Line Form
use_module module_name
Arguments
* module_name
The name of the module that subsequent requests will analyze. The default value
is the current module.
Explanation
Use the use_module request to specify the module that you want to analyze.
Examples
In the following example, the use_module request is set to a specified module.
as: use_module m7
VOS Release 13.1, analyze_system Release 13.1
as:
8-530
VOS System Analysis Manual (R073)
use_partition
use_partition
8-
Purpose
This request places the analyze_system command in partition mode and specifies
the boot partition that will be analyzed by subsequent requests.
Display Form
---------------------------------- use_partition ------------------------------partition_number: current_boot_partition
-disk:
master_disk_name
Command-Line Form
use_partition partition_number
[-disk master_disk_name]
Arguments
* partition number
The number of the boot partition that subsequent requests will analyze. The default
is the current boot partition for the current module.
* -disk master_disk_name
The name of the master disk containing the boot partition that subsequent requests
will analyze. Use this argument only if you specify a boot partition other than the
current boot partition. The default is the master disk for the current module.
Explanation
Use the use_partition request to specify the boot partition that you want to analyze.
To list the contents of the boot partition, use the display_disk_label command.
For more information about this command, see the manual VOS System
Administration: Disk and Tape Administration (R284).
The analyze_system Command and Requests
8-531
use_partition
Examples
In the following example, the use_partition request is set to a specified boot
partition on a specified module.
as: use_partition 2 -disk %s2#m1
VOS Release 13.1, analyze_system Release 13.1
as:
8-532
VOS System Analysis Manual (R073)
variable
variable
8-
Purpose
This request defines a variable that can be used in subsequent requests or lists the
values of all variables set thus far.
Display Form
---------------------------------- variable -----------------------------------variable_name:
value:
Command-Line Form
variable variable_name value
Arguments
* variable_name
A name to be used as a defined variable with the value specified in the value
argument.
* value
The value to be defined by variable_name.
Explanation
The variable request is most often used to define short names for strings that are
frequently referenced, and to store address locations found while examining a dump.
Once set, the variable can be used in any request involving an address.
If you issue the request without any arguments and no variables have been set, the
message No variables. is displayed.
Note that variable names are case-sensitive. A maximum of 10 variables may be
defined.
The analyze_system Command and Requests
8-533
variable
Examples
In the following example, the variable request sets the variable rti to stand for
real_terminal_io.
as:
as:
variable rti real_terminal_io
The variable rti can then be used in any request involving an address, as shown in
the following example.
as: where rti+50
as:
Related Information
For more information about the use of the variable request, see the section
Specifying Variable Names and Values in Chapter 2.
8-534
VOS System Analysis Manual (R073)
walk
walk
8-
Purpose
This request searches for a specified set of objects and executes a request for each
object.
Display Form
------------------------------------ walk ------------------------------------p rocess
object:
command_line:
Command-Line Form
walk object command_line
Arguments
* object
The operating system object is always process.
* command_line
An analyze_system request line.
Required
Explanation
The walk request walks through a specified set of processes and executes the
specified analyze_system request line for each process found, using the default
address of the process. The default address is set to the process table entry (PTE) for
the process. You can use the match request to limit the set of processes.
The analyze_system Command and Requests
8-535
walk
Examples
In the following example, the walk reqeust executes list_port_attachments for
each process running on a module.
as: walk process list_port_attachments
Using nonrunning process.
Current process is 1, ptep C13151C0, CPU0.Idle (Idle_0)
default_input (1)
Indirects to terminal
terminal_output (2)
Indirects to terminal
command_input (3)
Indirects to terminal
default_output (4)
Indirects to terminal
terminal (5)
Pathname:
Type:
I/O type:
Access mode:
Attributes:
%swsle#os_telnet_m10.2
window terminal
output
sequential
wait mode, hold attached and open
_aaaaerZd0H8byu43 (6)
Pathname:
%swsle#m10_mas>system>command_library>analyze_system.pm
Type:
fixed file
I/O type:
input
Access mode: random
Attributes: wait mode, hold attached and open
Record size:
4096
Cur record number:
1
Last record number:
1220
Disk blocks:
1222
....
as:
In the following example, the walk request executes match overseer for kernel
processes running on a module.
as: walk process match overseer
Using nonrunning process.
Current process is 1, ptep 80C11540, CPU28.Idle (Idle_28)
Current process is 42, ptep 81C89C20, Overseer.System
(Os.src_ctrl.0418152545F2)
8-536
VOS System Analysis Manual (R073)
walk
Current process is 45, ptep 81CDE4E0, Overseer.System
(Os.src_ctrl.041815255039)
Current process is 51, ptep 81441B00, Overseer.System (TPOverseer)
Current process is 52, ptep 81446000, Overseer.System (LinkServer1)
Current process is 53, ptep 81449940, Overseer.System (LinkServer2)
Current process is 54, ptep 8144CC20, Overseer.System (LinkServer3)
Current process is 55, ptep 81450360, Overseer.System (LinkServer4)
Current process is 56, ptep 81450BA0, Overseer.System (LinkServer5)
Current process is 57, ptep 81457000, Overseer.System (NetworkWatchdog)
Current process is 58, ptep 8145B3C0, Overseer.System (TheOverseer)
Current process is 59, ptep 8145EBE0, Overseer.System (BatchOverseer)
Current process is 61, ptep 80F1B860, Overseer.System (MailTransport1)
Current process is 62, ptep 80F16000, Overseer.System (MailUserAgent1)
Current process is 63, ptep 80F0DAE0, Overseer.System (MailTransport2)
Current process is 64, ptep 80F40360, Overseer.System (MailUserAgent2)
Current process is 65, ptep 813E3B00, Overseer.System (MailCommand1)
Current process is 66, ptep 81465680, Overseer.System (MailSorter)
Current process is 67, ptep 81468540, Overseer.System (MailNotifier)
Current process is 68, ptep 8146CC40, Overseer.System (MailTransport3)
Current process is 69, ptep 814706C0, Overseer.System (load_control)
Current process is 73, ptep 81482000, Overseer.System (wb_janitor)
Current process is 74, ptep 814824E0, Overseer.System (CalNotifier)
Current process is 77, ptep 814A12E0, Overseer.System (terminal_logger)
Current process is 78, ptep 814A9320, Overseer.System (OOP)
Current process is 80, ptep 814CC0E0, Overseer.System (Oc.V.041200320553)
Current process is 81, ptep 814DD000, Overseer.System (inetd)
Current process is 103, ptep 815332C0, Overseer.System (Ob.src_ctrl.pmon)
Current process is 104, ptep 81542000, Overseer.System (Ob.src_ctrl.dbwr)
Current process is 107, ptep 81532880, Overseer.System (Ob.src_ctrl.lgwr)
Current process is 108, ptep 815552E0, Overseer.System (Ob.src_ctrl.smon)
Current process is 138, ptep 80F5C080, Overseer.System
(Os.src_ctrl.041320275891
+)
Current process is 2266, ptep 818FA860, Overseer.System
(tcp_telnet_04180734245)
Current process is 4041, ptep 818CF800, Overseer.System
(Os.src_ctrl.04181523370
+9)
as:
The analyze_system Command and Requests
8-537
where
where
8-
Purpose
This request displays the object module name and the executing line number or
address.
Display Form
------------------------------------ where ------------------------------------address: *
Command-Line Form
where address
Arguments
* address
An address expression. If you do not supply a value, analyze_system uses the
address last referenced in similar requests.
Explanation
You can specify any of the addressing formats described in Chapter 3 as a value for
the where request.
Examples
In the following example, the where request locates the address 98762 in the
net_boomer program on line 101.
as:
where 98762
00098762 at net_boomer+23C, line 101
as:
In the following example, the address specified with the where request lies in an area
that was allocated from the virtual memory pool (see the description of the
8-538
VOS System Analysis Manual (R073)
where
dump_vm_pool_info request), so the request displays the offset relative to the block
name in the virtual memory pool.
as: where 5953ec
005953EC is in the VM Pool, 'Wired Heap'+000083EC.
as:
In the following example, the address specified with the where request lies in
unallocated memory.
as: where 70f452
0070F452 is in unallocated virtual memory (was 'sdlc.pm')
as: where f0452
000F0452 is in unallocated virtual memory (was 'Merged Free Block')
as:
Related Information
For more information about using the where request and addressing formats, see
Chapter 3.
The analyze_system Command and Requests
8-539
who
who
8-
Purpose
This request displays information about users and processes on the analyzed module.
Display Form
------------------------------------- who -------------------------------------* .*
-user:
-process_name: *
-cpu:
no
Command-Line Form
who
[-user user_name]
[-process_name name]
[-cpu]
Arguments
* -user user_name
Specifies the user or users that you want information about. You can specify only
one value for this argument, but it can be a star name. The default displays
information about all users on the analyzed module.
* -process_name name
Specifies the process or processes that you want information about. You can
specify only one value for this argument, but it can be a star name. The default
displays information about all processes on the analyzed module.
* -cpu
<CYCLE>
Specifies that for each CPU on the analyzed module, a total of the number of
processes that are assigned on the CPU be provided.
8-540
VOS System Analysis Manual (R073)
who
Explanation
The who request displays the process number, user name, and process table entry
pointer (PTEP) of all or selected processes on the analyzed module.
The request displays an asterisk to the left of the number of the current process, if such
a process is defined. Use the process number in a subsequent process request to set
the addressing environment for analyze_system.
Examples
In the following example, the who request displays the processes on a module.
as: who
PROC
PTEP
USER NAME
1 C1315080 CPU0.Idle (Idle_0)
4 C1323300 CPU1.Idle (Idle_1), on CPU1
10 C172F000 Cache_Manager_Post.System (Cache_Manager_Post)
11 C172FBC0 Cache_Manager_Timer.System (Cache_Manager_Timer)
12 C17303C0 Cache_Manager_Locker.System (Cache_Manager_Locker)
19 C1775080 Kernel_Utility.System (Kernel_Utility)
20 C1775B80 Maintenance_Utility.System (Maintenance_Utility)
22 C1778380 Diagnostic_Utility.System (Diagnostic_Utility7)
24 C177A000 Diagnostic_Utility.System (Diagnostic_Utility9)
25 C177AB80 Qrun_Daemon.System (Qrun_Daemon)
26 C177B540 Paging_Daemon.System (Paging_Daemon0)
28 C1817580 Overseer.System (inetd)
29 C182F8C0 Overseer.System (OpenLinkClient)
30 C1831500 Overseer.System (OpenLinkServer1)
31 C1834480 Overseer.System (OpenLinkServer2)
32 C1836000 Overseer.System (OpenLinkServer3)
33 C1838380 Overseer.System (OpenLinkServer4)
34 C183A7C0 Overseer.System (OpenLinkServer5)
35 C183C140 Overseer.System (OpenLinkServer6)
36 C183D600 Overseer.System (OpenLinkServer7)
37 C1840B80 Overseer.System (OpenLinkServer8)
38 C185B140 Overseer.System (TPOverseer)
40 C185E940 Overseer.System (NetworkWatchdog)
41 C18619C0 Overseer.System (TheOverseer)
42 C1864480 Overseer.System (BatchOverseer)
46 C185C400 Overseer.System (MailTransport1)
47 C184FB00 Overseer.System (MailUserAgent1)
48 C17772C0 Overseer.System (MailTransport2)
....
*3578 C186C3C0 Joe_Smith.Eng, on CPU0
as:
The analyze_system Command and Requests
8-541
who
In the following example, the who request displays the number of processes assigned
on a specified CPU.
as:
CPU
0:
1:
as:
8-542
who -cpu
COUNT
26
15
VOS System Analysis Manual (R073)
wired_memory_meters
wired_memory_meters
8-
Purpose
This request displays the wired memory meters.
Display Form
------------------------------- wired_memory_meters ------------------------------reset: no
-report: yes
Command-Line Form
wired_memory_meters
[-reset]
[-no_report]
Arguments
* -reset
<CYCLE>
Resets the wired memory meters to 0. When you reset the meters, the request
does not display a report unless you specify that a report should be displayed. By
default, the request does not reset the meters.
* -no_report
<CYCLE>
Specifies that the request not provide output. By default, the request displays a
metering report.
Explanation
Wired memory is memory that is always in the same location in physical memory.
Wired pages are used for communications buffers, cache manager buffers, and certain
parts of VOS that cannot be paged (such as the code that implements paging). VOS
can add a page to wired memory by removing it from the used and free lists.
When you issue wired_memory_meters -reset, it affects only the current process
executing analyze_system and the wired_memory_meters request. The
command records the reset in the file (home_dir)>as_meter_file. If more than
The analyze_system Command and Requests
8-543
wired_memory_meters
one process shares the same home directory, only one process at a time can reset a
metering request. If the file as_meter_file exists, it is reopened when you re-enter
analyze_system. To use the meters set since boot time, delete the file
as_meter_file.
Examples
In the following example, the wired_memory_meters request displays wired memory
meters for a module.
as: wired_memory_meters
Metering time:
915:01:09
8-544
OWNER
kernel
disk cache
wired heap
comm heap
link
disk
map
I/O heap
HI I/O heap
iop tape
COUNT
3698
5394
6021
10
39
0
309
34
832
0
TOTAL
16337
mm.n_wired
mm.n_temp_wired
mm.TOTAL
as:
4188
12149
16337
VOS System Analysis Manual (R073)
MAX
4601
26215
6021
10
39
125
1267
34
832
384
WIRES
691439
594811
6098
10
39
168516
789354
34
832
3156
UNWIRES
687741
589417
77
0
0
168516
789045
0
0
3156
2254289
2237952
wired_memory_meters
The following table describes the colums that appear in the output of the preceding
example.
Column
Description
OWNER
The operating system service that places or removes a page from wired
memory. Example of owners are kernel, disk cache, tape, wired
heap, comm heap, link, disk, map, I/O heap, and HI I/O heap.
COUNT
The number of occurrences of each type of operating system service that
places or removes a page from wired memory.
MAX
The maximum number of each type of occurrence.
WIRES
The number of occurences of adding pages to wired memory.
UNWIRES
The number of occurrences of removing a page from wired memory and
returning it to free memory.
The following table describes the fields that appear in the output of the preceding
example.
Field
Description
mm.n_wired
The number of pages that are permanently wired.
mm.n_temp_wired
The number of pages that are temporarily wired, such as disk
cache pages.
mm.TOTAL
The total number of pages that are currently wired.
Related Information
For more information about paging, see the description of the page_meters request.
The analyze_system Command and Requests
8-545
wired_memory_meters
8-546
VOS System Analysis Manual (R073)
Appendix A
Abbreviations Used by the
analyze_system Command
A-
Table A-1 expands some of the abbreviations used with the analyze_system
command.
Table A-1. Abbreviations (Page 1 of 2)
Abbreviation
Description
Abbreviation
Description
ack
adt
adte
afte
apt
apte
atb
axte
bcb
bme
bmex
bmt
bp
bsc
cd
cip
cux
dcd
dde
DDN
ddte
devx
dqe
dsl
dsr
dtr
dvt
dvte
dvtep
acknowledge
active directory table
active directory table entry
active file table entry
active page table
active page table entry
average time between
active index table entry
BSC control block
buffer map entry
buffer map entry index
bit map table
backward pointer
binary synchronous
carrier detect
channel info pointer
control unit index
data carrier detect
disk data entry
disk drive number
disk data table entry
device index
disk queue entry
data set lead
data set ready
data terminal ready
device table
device table entry
device table entry pointer
eit
eite
epx
et
ete
evid
evx
FLCK
fp
frm
hashx
iah
idx
int
lap
LAPB
executable image table
executable image table entry
entry pointer index
event table
event table entry
event ID
event index
file lock
forward pointer
frame error
hash index
I am here
index
interrupt
link access protocol
Link Access Protocol,
Balanced
lap control block
login device database
login disk table
login disk table entry
login disk table entry pointer
mailbox
mailbox pointer
memory manager data
memory map entry
memory table
mean time between failures
lcb
lddb
ldt
ldte
ldtep
mbx
mbxp
mmdata
mme
mt
MTBF
Abbreviations Used by the analyze_system Command
A-1
Abbreviations Used by the analyze_system Command
Table A-1. Abbreviations (Page 2 of 2)
Abbreviation
Description
Abbreviation
Description
nak
nct
ndt
ngt
nrt
nst
OBJLCK
obp
ovr
par
pc
pcp
pdr
pf
PHYLCK
PI
pid
pmb
pme
porte
ppe
procp
prq
prt
pte
ptep
ptw
pop
ppn
Q
rba
rnr
rr
rst
negative acknowledge
network client table
network driver table
network gateway table
network routing table
network socket table
logical file lock
output buffer pointer
overrun error
parity error
page control
primitive control program
process data region
page fault
physical file lock
programmed interrupt
process ID
process map block
process map entry
port table entry
packet pool entry
process pointer
pending request queue
pending request table
process table entry
process table entry pointer
page table word
VOS programmed operators
physical page number
queue
read buffer active
receive not ready
receive ready
reserved socket table
sip
sle
sqe
sqh
station identification protocol
StrataLINK entry
server queue entry
server queue header or
streams queue head
server queue information
StrataLINK mailbox
Universal Asynchronous
Receiver/Transmitter
Universal Interface
unique ID
transmit buffer empty
terminal control block
terminal control block header
terminal control block pointer
task data region
task ID or transaction ID
tape control block
trailer pointer
terminal type entry pointer
terminal type
transfer vector
virtual circuit
virtual circuit call request
virtual circuit listen entry
virtual circuit listen module
virtual circuit table
virtual circuit table entry
virtual terminal port info
virtual page number
virtual terminal table
virtual terminal table entry
wire and forward
A-2
VOS System Analysis Manual (R073)
sqi
smbx
UART
ui
uid
tbmt
tcb
tcbh
tcbp
tdr
tid
tpcb
trlrp
ttep
tty
tv
vc
vccr
vcle
vclm
vct
vcte
vpi
vpn
vtt
vtte
waf
Appendix B
VOS Internal Commands
B-
Table B-1 lists the VOS internal commands. Issue these commands from within the
analyze_system command by preceding them by two periods (..). Note that you
can also use VOS command functions with internal commands. However, you cannot
specify both internal commands and analyze_system requests on the same request
line.
Table B-1. VOS Internal Commands (Page 1 of 2)
add_device (privileged)
add_disk (privileged)
add_link_board (privileged)
add_module (privileged)
add_paging_file (privileged)
add_system (privileged)
attach_default_output
attach_port
break_process
cancel_fast_disk_recovery (privileged)
change_current_dir
configure_comm_protocol (privileged)
continue
copy_dir
copy_file
create_dir
create_file
create_index
create_os_symtab (privileged)
debug
delete_comm_protocol (privileged)
delete_dir
delete_disk (privileged)
delete_file
delete_index
delete_link_board (privileged)
delete_module (privileged)
delete_system (privileged)
detach_default_output
detach_port
dismount_disk (privileged)
display_dir_status
display_error
display_file_status
display_line (prelogin)
display_links
display_lock_wait_time
display_paging_usage
display_process_lock_wait_time
display_terminal_parameters
display_tp_default_parameters
display_tp_parameters
dump_disk (privileged)
dump_file
enforce_region_locks
format_disk (privileged)
give_access
give_default_access
help (prelogin)
initialize_boot_disk (privileged)
initialize_disk (privileged)
initialize_duplex_disk (privileged)
initialize_pick_boot_disk (privileged)
initialize_pick_disk (privileged)
keep
link
list
list_comm_protocols (privileged)
list_devices
list_kernel_programs (privileged)
VOS Internal Commands
B-1
VOS Internal Commands
Table B-1. VOS Internal Commands (Page 2 of 2)
display
display_access
display_access_list
display_current_dir
display_current_module (prelogin)
display_date_time (prelogin)
display_default_access_list
display_device_info
list_modules (prelogin)
list_port_attachments
list_process_cmd_limits
list_systems (prelogin)
load_kernel_program (privileged)
login (prelogin)
logout
mount_disk (privileged)
move_dir
move_file
ready
reenter
reload_disk (privileged)
remove_access
remove_default_access
remove_disk (privileged)
remove_disk_pack (privileged)
rename
restore
salvage_disk (privileged)
select_duplex_disk (privileged)
set_alignment_fault_mode
set_bootload_time (privileged)
set_date_time (privileged)
set_default_time_zone (privileged)
set_expiration_date
set_file_allocation
set_implicit_locking
set_lock_wait_time (privileged)
set_log_protected_file (privileged)
B-2
VOS System Analysis Manual (R073)
set_max_queue_depth
set_object_audit (privileged)
set_owner_access
set_pipe_file
set_priority
set_process_audit (privileged)
set_process_lock_wait_time
set_ready
set_safety_switch
set_terminal_parameters
set_text_file
set_time_zone
set_tp_default_parameters (privileged)
set_tp_parameters
set_transaction_file (privileged)
setup_disk (privileged)
setup_disk_pack (privileged)
shutdown (privileged)
start_disk_recovery (privileged)
start_link (privileged)
start_logging
start_process
stop
stop_link (privileged)
stop_logging
stop_process
truncate_file
uninitialize_disk (privileged)
unlink
unload_kernel_program (privileged)
update_channel_info (privileged)
update_io_syserr (privileged)
update_process_cmd_limits
use_abbreviations
use_message_file
verify_system_access
where_path
who_locked
Requests That Are Described in Other Stratus Manuals
Appendix C
Requests That Are Described
in Other Stratus Manuals
C-
This appendix lists other Stratus manuals that document analyze_system requests.
(Page 1 of 2)
Request
Manual
dump_chan_attach
VOS Communications Software: 3270 Channel Attach Programmers
Guide (R220)
dump_chan_attach_ddb
VOS Communications Software: 3270 Channel Attach Programmers
Guide (R220)
dump_dkbk
VOS Multiplexed Host Interface Administrators and Programmers
Guide (R307)
dump_dkhs
VOS Multiplexed Host Interface Administrators and Programmers
Guide (R307)
dump_dkty
VOS Multiplexed Host Interface Administrators and Programmers
Guide (R307)
dump_dkux
VOS Multiplexed Host Interface Administrators and Programmers
Guide (R307)
dump_dkxqt
VOS Multiplexed Host Interface Administrators and Programmers
Guide (R307)
dump_ioa_adapt_mbox
Universal Communications I/O Adapter Programming (R109)
dump_ioa_chan_mbox
Universal Communications I/O Adapter Programming (R109)
dump_ioa_hdr
Universal Communications I/O Adapter Programming (R109)
dump_ioa_pm_info
Universal Communications I/O Adapter Programming (R109)
dump_ioa_xr_mbox
Universal Communications I/O Adapter Programming (R109)
dump_k120_fw
VOS Multiplexed Host Interface Administrators and Programmers
Guide (R307)
dump_mpx_gccb
Universal Communications I/O Adapter Programming (R109)
Requests That Are Described in Other Stratus Manuals
C-1
Requests That Are Described in Other Stratus Manuals
(Page 2 of 2)
Request
Manual
dump_sdlc
VOS Communications Software: SDLC (R043)
dump_ucomm
Universal Communications I/O Adapter Programming (R109)
dump_ucomm_idle_q
Universal Communications I/O Adapter Programming (R109)
dump_ucomm_timer_q
Universal Communications I/O Adapter Programming (R109)
dump_ucomm_udcb
Universal Communications I/O Adapter Programming (R109)
dump_ucomm_user_lcb
Universal Communications I/O Adapter Programming (R109)
monitor_sdlc
VOS Communications Software: SDLC (R043)
monitor_sna
Primary and Secondary Systems Network Architecture: Planning and
Operations Guide (SC34-0757)
sna_psna_trace
Primary and Secondary Systems Network Architecture: Planning and
Operations Guide (SC34-0757)
sna_ssna_trace
Primary and Secondary Systems Network Architecture: Planning and
Operations Guide (SC34-0757)
t1_getstate
Product Configuration Bulletin: X.25 T1 (R124)
t1_getstats
Product Configuration Bulletin: X.25 T1 (R124)
t1_gettune
Product Configuration Bulletin: X.25 T1 (R124)
t1_lap_getstats
Product Configuration Bulletin: X.25 T1 (R124)
t1_lap_gettune
Product Configuration Bulletin: X.25 T1 (R124)
t1_wan_getstats
Product Configuration Bulletin: X.25 T1 (R124)
t1_wan_gettune
Product Configuration Bulletin: X.25 T1 (R124)
C-2
VOS System Analysis Manual (R073)
Appendix D
Requests That Are Obsolete or
for Stratus Use Only
D-
Table D-1 lists analyze_system requests considered by Stratus to be obsolete,
partly obsolete, or for Stratus use only. Undocumented requests that do not appear on
this list may also be obsolete or for Stratus-use only. Many of these requests display
low-level data structures that are not available in the current release of VOS.
.
Table D-1. Obsolete and Stratus Use Only Requests (Page 1 of 3)
active_dma_requests
bd_break
bd_comm
bd_echo
bd_go
bd_raw
biodriver_meters
break
call_pcp
check_comm_buffers
check_kel
check_list
check_prom_code
clear_break
comm_md_trace
create_os_map
disable_fault
disable_fault_insertion
disable_timer_fault
display_language_info
display_map_codes
display_periodic_test_time
display_trace
dump_acb
dump_acl
dump_async_ioa
dump_async_iop
dump_batch_overseer
dump_bsc
dump_bsc_ioa
dump_call_requests
dump_cdt
dump_cld
dump_comm
dump_comm_md
dump_cpu_private
dump_ctape_data
dump_dde
dump_dma_tcb
dump_dqe
dump_driver
dump_eft
dump_fault_info
dump_fbe
dump_fi
dump_fmpi
dump_form
dump_fse
dump_gccb
dump_giza_match_table
dump_h3270
dump_hal_llc
dump_hal_streams
dump_hal_timers
dump_hasp
Requests That Are Obsolete or for Stratus Use Only
D-1
Requests That Are Obsolete or for Stratus Use Only
Table D-1. Obsolete and Stratus Use Only Requests (Page 2 of 3)
dump_idp
dump_image
dump_kel
dump_lat_acb
dump_lat_as
dump_lat_cb
dump_lat_dev
dump_lat_gli
dump_lat_hi
dump_lat_hs
dump_lat_ls
dump_lat_nd
dump_lat_ob
dump_lat_qr
dump_lat_sb
dump_lat_ses
dump_lat_sessions
dump_lcd_info
dump_lde
dump_lde_int
dump_list
dump_map
dump_message_queue
dump_old_mct
dump_overseer
dump_packed_net_buffer
dump_pane
dump_pcb
dump_pick_data
dump_pick_disk_data
dump_pmt
dump_poll_select_trace
dump_ppe
dump_pscb
dump_psi_data
dump_psi_dev
dump_r3270
dump_r3270_trace
dump_rawfile_pool
dump_remap_hash_table
dump_rfi
dump_rse
dump_rsi
dump_rsn
D-2
VOS System Analysis Manual (R073)
dump_scb
dump_scsi_tape
dump_sle
dump_smbx
dump_sna
dump_sna_ovr
dump_sna_pass_thru
dump_snadv_cbs
dump_snasc_cbs
dump_sqe_list
dump_sqe_space_list
dump_stape_ioa_ram
dump_streams_area
dump_tape_init_area
dump_tbuf
dump_tcmd
dump_tcp_in_ifaddr
dump_tdrv
dump_tel_acb
dump_tel_buffer
dump_tel_gti
dump_tel_server
dump_tsrv
dump_tte
dump_ucomm_bsc
dump_ucomm_h3270
dump_ucomm_m3780
dump_ucomm_udcb
dump_wcb
dump_window
dump_x25lct
enable_fault
enable_fault_insertion
enable_periodic_test
enable_timer_fault
get_list_header
graph_module_usage
list_breaks
list_scsi_devices
list_tcp_xmt_queues
monitor_rse
psi_monitor
save_profile
scan_list
Requests That Are Obsolete or for Stratus Use Only
Table D-1. Obsolete and Stratus Use Only Requests (Page 3 of 3)
set_board_thresholds
set_break
set_dq_debug_mode
set_dq_defaults
sna_62_trace
sna_appc_trace
sna_history_trace
sna_lu_trace
sna_psna_trace
sna_ssna_trace
sna_t2_trace
sna_t5_trace
snadv_history_trace
snasc_history_trace
timer_meters
tr_adpcb
tr_ccb
tr_dcb
tr_lcb
tr_lnkcb
tr_mpx
tr_sapcb
tr_tables
tr_trace
ucomm_monitor_bsc
ucomm_monitor_h3270
ucomm_monitor_m3780
update_fault_info
use_bd
walk_list
Requests That Are Obsolete or for Stratus Use Only
D-3
Requests That Are Obsolete or for Stratus Use Only
D-4
VOS System Analysis Manual (R073)
Index
Index-
Misc.
&i (object module static relative
addressing), 3-2, 3-4, 3-7, 3-11
&s (stack relative addressing), 3-2, 3-4
&t (object module symbol table relative
addressing), 3-2, 3-5, 3-7
@n (source code line number addressing), 3-3,
3-10
A
Abbreviations, A-1
Active directory table entry (ADTE), 8-82
Active directory tables (ADT), 8-75
Active file table entry (AFTE), 8-85, 8-517
Active files, 8-517
Active index table entry (AXTE), 8-85, 8-100,
8-517
Active page table entry (APTE), 8-415
Active processes, 8-498
Address formats, 3-1
expression, 3-2
external variable, 3-2
hexadecimal, 3-2, 3-3
indirect, 3-2, 3-11
last display relative, 3-2, 3-12
line numbers, 3-3
object module code relative, 3-2, 3-7
object module static relative, 3-2
object module symtab relative, 3-2
stack relative, 3-2
symbolic, 3-4
variable, 3-2
Address values
hexadecimal, 8-339
megabyte of memory, 3-4
memory page, 3-4
Alignment faults
compiling checking, 8-33
Continuum-series modules, 8-33, 8-399
executable image table, 8-129
logging, 8-398
XA/R-series modules, 8-33, 8-399
analyze_system command, 8-2
functionality, 1-1
help for, 1-3
invoking, 1-3
modes of operation, 1-4
prompt, 1-5, 2-1
status of, 8-494
uses, 1-2
Analyzed dump, 8-519
definition of, 4-8
Analyzed module, 8-530
definition of, 4-20
Analyzed process, 8-420
definition of, 4-10, 4-22
as: prompt, 1-5, 2-1, 8-3
as_meter_file file, 5-6
Assembly language
disassemble request, 8-18
listing example, 3-7
Asynchronous communications
channels, 8-121
attach_default_output command, 2-7
audit_admin command, 8-71
B
Batteries
power failure, 8-362
bind command, 8-44
bind maps, 3-5
binder control file, 3-5
Boards
listing, 8-357
power loading, 8-416
Boot partition
specifying, 8-531
Buffer chains
types, 8-125
Index-1
Index
Byte values
setting, 8-445
C
Cache
disk, 8-115
cache_meters request, 1-13, 8-4
(calc) command function, 3-4
Calculating addresses, 8-339
Canceling requests, 2-4
change_iop_dump_switch request, 1-8, 8-7
Channels
information structure, 8-118
managing, 8-302
check_area request, 1-12, 8-10
IOP firmware mode, 4-19
check_boards request
dump mode, 4-11
C-language line parser, 8-3
clone_command request, 1-6, 2-3, 8-14
Code relative addressing
alternative method, 3-11
Command level
returning to, 8-422
Commands
analyze_system, 8-2
audit_admin, 8-71
bind, 8-44
configure_comm_protocol, 8-455
configure_firmware_types, 8-151,
8-206
delete_file, 8-16
display_disk_label, 8-531
display_paging_usage, 8-498
display_system_usage, 8-73
display_tuning_parameters, 8-116
external, 2-3
internal, 2-2, 8-3, B-1
list_devices, 8-119, 8-122, 8-191,
8-303
list_port_attachments, 8-374
network_client, 8-467
reconfigure_memory, 8-177
security_admin, 8-70
set_scheduler_info, 8-246
set_terminal_parameters, 8-306
set_tuning_parameters, 8-76, 8-116
update_channel_info, 8-119, 8-456
Index-2
VOS System Analysis Manual (R073)
Communication requests
dump_queue_info, 1-11
Communications buffers
dumping, 8-124
Communications buses
power loading, 8-416
Communications channels, 8-118
asynchronous, 8-121
Communications controller dump mode, 4-2,
4-3
list_comm_dumps requst, 4-3
requests, 4-2
use_comm_dump request, 4-3
Communications protocols
error thresholds, 8-452
Communications request
set_streams_param, 1-10
Communications requests
change_iop_dump_switch, 1-8
display_net_trace, 1-8, 8-52
dump_channel_info, 1-8, 8-118
dump_channels, 1-9, 8-121
dump_comm_buffers, 1-9, 8-124
dump_firmware_names, 1-9
dump_fw_table, 1-9
dump_h3270, 1-9
dump_iop_equip_table, 1-9
dump_lcb, 1-9
dump_net_info, 1-9, 1-9, 8-180
dump_net_tids, 1-9, 8-185
dump_nst, 1-9, 8-188
dump_poll_select, 1-9, 8-191
dump_protocol_names, 1-9, 8-206
dump_prt, 1-9, 8-208
dump_r3270, 1-9
dump_r3270_trace, 1-9
dump_rst, 1-9, 8-239
dump_rsv_socket, 1-10, 8-242
dump_socket, 1-10
dump_socket_info, 1-10
dump_stream, 1-10
dump_streams, 1-10
dump_tcb, 1-10, 8-302
dump_tcbh, 1-10, 8-309
list_iop_dump_switch, 1-10
list_iop_dumps, 1-10
list_streams_params, 1-10
monitor_net_trace, 1-10, 8-403
scan_streams_msgs, 1-10
Index
search_streams, 1-10, 8-441
set_comm_thresholds, 1-10, 8-452
set_net_timeout, 1-10, 8-466
set_net_trace, 1-10, 8-468
use_iop_dump, 1-10
Compiling
alignment faults checking, 8-33, 8-399
configure_comm_protocol
command, 8-455
configure_firmware_types
command, 8-151, 8-206
Continuum-series modules
alignment faults, 8-33, 8-399
forward stack traces, 8-349
stack traces, 8-488, 8-509
user process memory, 7-10
VOS shared memory space, 4-32
copy_dump command, 4-7
CPU PROM files, 8-523
D
Data
displaying, 8-28
(date) command function, 8-3
Debugger, 8-48
(decimal) command function, 3-3
delete_dump request, 1-6, 8-16
delete_file command, 8-16
detach_default_output command, 2-7
Devices
port table entry (PORTE), 8-197
process using, 7-6
Directories
active table entries, 8-82
active tables, 8-75
listing activity, 8-367
directory_meters request, 1-13
disassemble request, 1-6, 8-18
code relative addressing, 3-10
display request, 8-19
displaying instructions with, 6-7
XA/R-series modules, 8-19
Disk block mode, 1-4, 4-2, 4-3
requests, 4-2
use_block request, 4-4, 8-516
Disk cache, 8-115
Disk drives
buffers, 8-335
listing, 8-363
Disk file system requests
dump_adt, 1-11
dump_adte, 1-11
dump_afte, 1-11
dump_axte, 1-11
dump_bmt, 1-11, 8-104
dump_cache, 1-11
dump_cache_info, 1-11
list_disks, 1-11
set_cache_pin_parameters, 1-11
disk_lock_meters request, 1-13, 8-20, 8-20
resetting, 5-5
disk_meters request, 1-13, 8-23
display command, 2-7
display request, 1-6, 6-7, 8-28
code relative addressing, 3-10
disassemble request, 8-19
displaying unformatted data with, 6-1
displaying variables with, 2-14
dump mode, 4-11
external variables, 6-4
indirect addressing, 3-12
partition mode, 4-34
relative addressing, 3-12
stack relative addressing, 3-16
stack request, 8-488
use_block request, 8-517
where request, 8-538
display_alignment_faults
request, 1-12, 8-32
log_alignment_faults request, 8-32,
8-400
specifying process for, 8-33
display_cache_pin_parameters
request, 1-11, 8-35
display_disk_label command
use_partition request, 8-531
display_extensible_heap request, 1-12,
8-36
display_file request, 1-6, 2-9, 8-40
display_memory_usage request, 1-12, 7-8,
7-10, 8-43, 8-94, 8-425
display_meter_file_info request, 1-13,
8-50
Index-3
Index
display_net_trace request, 1-8, 8-52
monitor_net_trace request, 8-403
set_net_trace request, 8-469
display_paging_usage command, 8-498
display_pm request, 1-6, 3-5, 8-57
external variables, 6-4
IOA firmware mode, 4-15
IOP firmware mode, 4-19
Module mode, 4-23
display_process_info request, 1-14, 8-64
display_program_module command, 3-5,
6-4
display_security_info request, 1-6, 8-70
audit_admin command, 8-71
display_system_usage command, 8-73
display_system_usage request, 1-6, 5-3,
8-72, 8-215
display_tuning_parameters
command, 8-116
display_vm_pool_info request
module mode, 4-32
Displaying files, 2-7, 4-4
display command, 2-7
display_file request, 2-9
dump_syserr request, 2-11
Dump files
listing, 8-366
Dump image
definition of, 4-7
Dump mode, 1-4, 4-2, 4-7
check_boards request, 4-11
display request, 4-11
entering, 4-8
find_string request, 4-12, 8-344
finding data, 8-344
list_dumps request, 4-8
preparing to use, 4-8
process request, 4-10
requests, 4-2
requirements for, 4-8, 8-521
status request, 4-9, 8-495
summary request, 8-499
trace request, 4-10
use_dump request, 4-8, 8-519
use_iop request, 8-526
who request, 4-10
Dump numbers
definition of, 8-366
Index-4
VOS System Analysis Manual (R073)
Dump partition
definition of, 4-7
Dump path names, 8-520
dump_adt request, 1-11, 8-75
dump_adte request, 1-11, 8-82
dump_afte request, 1-11, 4-4, 8-85
processes, 7-5
use_block request and, 8-517
dump_area request, 1-12, 8-92
dump_axte request, 1-11, 4-5, 8-100
use_block request, 8-517
dump_bmt request, 1-11, 8-104
dump_bsc request, 1-8, 8-107
dump_cache request, 1-11, 8-111, 8-111
dump_cache_info request, 1-11, 8-115
dump_chan_attach request, C-1
dump_chan_attach_ddb request, C-1
dump_channel_info request, 1-8, 8-118
dump_channels request, 1-9, 5-2, 8-121
dump_tcb request, 8-303
dump_tcbh request, 8-123
dump_comm_buffers request, 1-9, 8-124
dump_dkbk request, C-1
dump_dkhs request, C-1
dump_dkty request, C-1
dump_dkux request, C-1
dump_dkxqt request, C-1
dump_dvt request
processes, 7-6
dump_eit request, 1-6, 8-129
finding processes with, 7-4
dump_et request, 1-6, 8-134
processes, 7-5
dump_events request, 1-7, 8-142
dump_fi request
processes, 7-5
dump_file command, 4-4
dump_firmware_names request, 1-9, 8-146
dump_fli request, 1-7, 8-148
dump_fw_table request, 1-9, 8-151
dump_giza request, 1-9, 8-153
dump_h3270 request, 1-9, 8-156
dump_index_block request, 4-7
dump_ioa_adapt_mbox request, C-1
dump_ioa_chan_mbox request, C-1
dump_ioa_hdr request, C-1
dump_ioa_pm_info request, C-1
dump_ioa_xr_mbox request, C-1
dump_iop_equip_table request, 1-9, 8-160
Index
dump_iop_meters request, 1-13, 8-163
dump_k120_fw request, C-1
dump_label request
partition mode, 4-34
dump_lap_meters request, 1-13, 8-166
dump_lcb request, 1-9, 8-168
dump_lock request, 1-7, 5-2, 8-171
dump_mpx_gccb request, C-1
dump_mt request, 1-12, 8-176
dump_net_info request, 1-9, 8-180
dump_net_tids request, 1-9, 8-185
dump_nst request, 1-9, 8-188
dump_poll_select request, 1-9, 8-191
dump_porte request, 1-7, 8-196, 8-197
and the dump_stream request, 8-267
list_port_attachments
request, 8-197
dump_protocol_names request, 1-9, 8-206
dump_prt request, 1-9, 8-208
dump_pte request, 1-7, 5-4, 7-3, 8-210, 8-215
processes, 7-5
dump_queue_info request, 1-11, 8-217
dump_r3270 request, 1-9, 8-229
dump_r3270_trace request, 1-9, 8-235
dump_rst request, 1-9, 8-239
dump_rsv_socket request, 1-10, 8-242
dump_scheduler_queues request, 1-7,
8-246
dump_sdlc request, C-2
dump_socket request, 1-10, 8-249
dump_socket_info request, 1-10, 8-252
dump_stream request, 1-10, 8-259
and the dump_porte request, 8-267
and the list_port_attachments
request, 8-267
dump_streams request, 1-10, 8-259, 8-298
dump_syserr request, 1-7, 2-11, 8-299
dump_tcb request, 1-10, 8-302
dump_channels request, 8-303
dump_tcbh request, 8-303
dump_tte request, 8-307
list_devices command, 8-303
list_port_attachments
request, 8-303
set_terminal_parameters
command, 8-306
dump_tcbh request, 1-10, 8-309
dump_channels request, 8-123
dump_tcb request, 8-303
dump_tdr request, 1-12, 8-313
dump_tpo request, 1-7, 8-320
dump_transaction request, 1-7, 8-325
dump_tte request
dump_tcb request, 8-307
dump_ucomm request, C-2
dump_ucomm_idle_q request, C-2
dump_ucomm_timer_q request, C-2
dump_ucomm_udcb request, C-2
dump_ucomm_user_lcb request, C-2
dump_vm_pool_info request, 1-12, 8-327
Dumps
boot partition, 8-520
deleting, 8-16
displaying processes, 4-10
displaying stack information, 4-10
displaying status, 4-9
IOP, 8-520
kernel, 8-520
numbers, 8-16
program module, 8-520
selecting, 4-8
troubleshooting, 4-11
E
e$out_of_service error message, 8-456
edit_vm_sizes request, 1-12, 8-335
use_partition request, 8-338
Error messages
active, 8-299
free, 8-299
system, 8-299
evaluate request, 1-7, 8-339
(calc) command function, 3-4
(decimal) command function, 3-4
(hexadecimal) command function, 3-4
hexadecimal expressions, 3-4
object module names, 3-7
where request, 8-340
Event table (ET), 8-134
event_count_meters request, 1-13, 8-341
Events
dumping, 8-134, 8-142
free list, 8-135
kernel, 8-142
process waiting, 7-5
remote, 8-135
Index-5
Index
shadow, 8-139
tasks and, 8-143
Executable image table (EIT), 8-129
alignment faults, 8-129
Exiting analyze_system, 8-422
Expressions
evaluating hexadecimal, 3-4
Extensible heaps, 8-36
External commands
clone_command request, 2-3, 8-14
definition of, 2-1
executing, 2-3
login command, 2-3
window terminal, 2-3
External variables, 3-2
display request, 6-4
display_pm request, 6-4
displaying values in, 6-4
listing, 8-58
F
Fans
failures, 8-362
Fences
kernel stack, 8-48
user stack, 8-48
File index
displaying contents of, 4-5
File mode. See Program module (file) mode
File partition, 8-104
bit map table, 8-104
Files
active table entry (AFTE), 8-85
displaying, 2-7, 4-4, 8-40
listing activity, 8-367
port table entry (PORTE), 8-197
Filtering output
match request, 2-4
with request arguments, 2-5
find_string request, 1-7, 8-344
dump mode, 4-12, 8-344
Firmware
dumping names, 8-146, 8-151
dumping table, 8-151
protocol names, 8-206
Forward stack trace
definition of, 8-349
Index-6
VOS System Analysis Manual (R073)
frame request, 1-12, 8-345
stack relative addressing, 3-16
Frames
current, 8-345
fstack request, 1-12, 8-348
output varies by module, 8-349
stack request, 8-349
trace request, 8-348
H
Heap requests
check_area, 1-12
display_extensible_heap, 1-12
dump_area, 1-12
scan_area, 1-12
Heaps, 8-94
buckets, 8-428
calculating free space, 8-425
check_area request, 8-10
communications, 8-11, 8-37, 8-93, 8-424
display_memory_usage request, 8-425
displaying space in, 8-43
dump_area request, 8-92
dump_vm_pool_info, 1-12
extensible, 8-36
high I/O, 8-11, 8-37, 8-93, 8-424
I/O, 8-37, 8-93
internal structure, 8-10
ioa, 8-11, 8-93, 8-424
iop, 8-11, 8-93, 8-424
old user, 8-424
paged, 8-11, 8-37, 8-93, 8-424
process data region, 8-11, 8-93, 8-424
scan_area request, 8-423
system, 8-36
tags, 8-428
user, 8-11, 8-93, 8-424
wired, 8-11, 8-37, 8-93, 8-424
help command, 2-2
help request, 1-7, 8-351
using, 1-3
Hexadecimal address formats, 3-3
Hexadecimal address values, 8-339
(hexadecimal) command function, 3-3
Hexadecimal expressions
evaluating, 3-4
Index
I
Indexes
active table entries, 8-100
active table entry, 8-85
listing activity, 8-367
Indirect addressing, 3-11
Instructions
displaying, 6-7
setting, 6-7, 8-459
Internal commands, 8-3
definition of, 2-1
executing in analyze_system, 2-2
external commands and, 2-3
help command, 2-2
listing, 2-2, B-1
requests and, 2-3
VOS, 8-3
Internal static relative addressing, 3-4
interrupt_meters request, 1-13, 8-352
Interrupts
displaying, 8-72
IOA dump mode, 1-4, 4-2
list_iop_dumps request, 4-13
requests, 4-2
use_iop request, 4-13
use_iop_dump request, 4-13
IOA firmware mode, 1-4, 4-2, 4-14
display_pm request, 4-15
list_boards request, 4-14
requests, 4-2
status request, 4-15
use_iop request, 4-14
IOA mode
use_iop request, 8-372, 8-525, 8-528
IOP dump mode, 1-5, 4-2, 4-13, 4-16
list_dumps request, 4-16
requests, 4-2
status request, 4-17
use_dump request, 8-520
use_iop request, 4-16
IOP firmware mode, 1-5, 4-2, 4-17
check_area request, 4-19
display_pm request, 4-19
entering, 4-18
list_boards request, 4-18
requests, 4-2
status request, 4-19
use_iop request, 4-18
IOP mode
change_iop_dump_switch request, 8-7
list_iop_dump_switch request, 8-370
use_iop request, 8-525
IOP requests
module mode, 4-16
IOPs
list_iop_dumps request, 8-372
use_iop_dump request, 8-528
K
Kernel
dumps, 8-520
executable image table, 8-129
heaps, 8-335
program modules, 8-57
L
list_boards request, 1-7, 4-18, 8-357
in dump mode, 1-4
IOA firmware mode, 4-14
list_comm_dumps request
communications controller dump
mode, 4-3
list_devices command, 8-119, 8-122,
8-191
dump_tcb request, 8-303
list_disks request, 1-11, 8-363
dump mode, 8-366
list_dumps request, 1-7, 8-365
dump mode, 4-8
IOP dump mode, 4-16
module mode, 8-366
list_file_activity request, 1-13, 8-367
list_iop_dump_switch request, 1-10,
8-370
list_iop_dumps request, 1-10, 8-372
IOA dump mode, 4-13
list_port_attachments command, 8-374
list_port_attachments request, 1-14,
8-197, 8-374
and the dump_stream request, 8-267
dump_tcb request, 8-303
list_port_attachments
command, 8-374
list_streams_params request, 1-10, 8-376
list_tp_params request, 1-7, 8-381
list_transaction_trace request, 1-7,
Index-7
Index
8-383
list_transactions request, 1-7, 8-385
lock_meters request, 1-13, 8-389
lock_summary request, 1-13, 8-394
Locks
summary request, 8-499
log_alignment_faults request, 8-32,
8-398
display_alignment_faults
request, 8-400
Logged messages, 8-299
Longword values
setting, 8-461
Lost messages, 8-299
M
match request, 1-7, 8-401
effect on subsequent requests, 8-402
using, 2-4
Memory
changing, 6-5
changing on XA/R-series modules, 6-7
displaying formatted data, 6-3
displaying unformatted data, 6-1
displaying user process, 7-7
Memory addressing
megabytes, 3-4
pages, 3-4
Memory map entry (MME)
displaying, 8-415
Memory pool, 8-11, 8-37, 8-94
Memory requests
display_alignment_faults, 1-12,
8-32
display_memory_usage, 1-12, 8-43
dump_eit, 8-129
dump_mt, 1-12, 8-176
dump_tdr, 1-12
dump_vm_pool_info, 1-12, 8-327
edit_vm_sizes, 1-12, 8-335
set_byte, 8-445
set_instruction, 8-459
set_longword, 8-461
set_word, 8-477
Memory tables
dumping, 8-176
Metering
Index-8
VOS System Analysis Manual (R073)
as_meter_file, 5-6
Metering fields
dump_pte request, 5-4
Metering requests, 5-1
cache_meters, 1-13
directory_meters, 1-13
disk_lock_meters, 1-13
disk_meters, 1-13
display_cache_pin_parameters, 111
display_meter_file_info, 1-13
display_system_usage, 5-3
dump_channels, 5-2
dump_iop_meters, 1-13
dump_lap_meters, 1-13
dump_lock, 5-2
event_count_meters, 1-13
interrupt_meters, 1-13
list_file_activity, 1-13
lock_meters, 1-13
lock_summary, 1-13
page_meters, 1-13
sched_lock_meters, 1-13
sched_meters, 1-13
set_meter_file, 1-13
sim_int_meters, 1-13
terminal_meters, 1-13
tpq_meters, 1-13
wired_memory_meters, 1-13
Meters
resetting, 5-4
Mode setting requests
use_block, 1-14, 8-516
use_dump, 1-14, 8-519
use_file, 1-14, 8-523
use_iop, 1-14, 8-372, 8-525, 8-528
use_module, 1-14, 8-530
use_partition, 1-14, 8-531
Modes
changing, 4-20
communications controller dump, 4-2, 4-3
disk block, 1-4, 4-2, 4-3
dump, 1-4, 4-2, 4-7
IOA dump, 1-4, 4-2
IOA firmware, 1-4, 4-2, 4-14
IOP dump, 1-5, 4-2, 4-13, 4-16
IOP firmware, 1-5, 4-2, 4-17
module, 1-5, 4-2, 4-20
partition, 1-5, 4-3, 4-34
Index
program module (file), 1-5, 4-3, 4-35
selecting, 4-2
undefined, 1-5, 4-36
Module mode, 1-5, 4-2, 4-20
default, 4-1
display_pm request, 4-23
display_vm_pool_info request, 4-32
IOP requests, 4-16
process request, 4-22
requests, 4-2, 4-21
use_module request, 8-530
monitor_net_trace request, 1-10, 8-403
display_net_trace request, 8-403
output anomalies, 8-407
set_net_trace request, 8-469
stopping output, 8-407
monitor_sdlc request, C-2
monitor_sna request, C-2
N
Network socket table (NST), 8-186
network_client command
set_net_timout request, 8-467
O
Object module code relative addressing, 3-7
Object module names
display_pm request, 3-5
display_program_module
command, 3-5
evaluate request, 3-7
Object module static relative addressing, 3-11
Object modules
displaying values in, 8-538
maps, 8-47, 8-58
Obsolete requests, D-1
Open file
process using, 7-5
P
Page faults
displaying, 8-72
page_meters request, 1-13, 8-409
Paging partition
summary request, 8-498
Partition mode, 1-5, 4-3, 4-34
display request, 4-34
dump_label request, 4-34
requests, 4-3
status request, 4-34
use_partition request, 4-34, 8-531
Partitions
boot, 8-338, 8-520, 8-531
disk, 8-338
dump, 4-7
file, 8-104
Pending request table (PRT)
StrataLINK, 8-208
pme_status request, 1-14, 8-413
Poll/select
dumping, 8-191
terminal states, 8-192
Port table entry (PORTE), 8-196
Ports
listing, 8-374
Power
loading, 8-416
recovery from failure, 8-362
power_summary request, 1-7, 8-416
Process map entry (PME), 8-413
displaying, 8-415
process request, 1-14, 4-10, 7-7, 8-419
dump mode, 4-10
module mode, 4-22
stack request, 8-487
trace request, 8-509
who process, 8-420
Process space, 4-34
Process table entry (PTE), 8-210
walk request, 8-535
Process table entry pointer (PTEP), 8-32,
8-398
who request, 8-541
Processes
analyzed, 4-10, 8-420
current, 8-420, 8-541
data region, 8-48, 8-64, 8-424
data region heap, 8-11, 8-93
display_process_info request, 1-14,
8-64
displaying descriptions of, 8-540
displaying dumped, 4-10
dump_afte request, 7-5
dump_dvt request, 7-6
dump_eit request, 7-4
Index-9
Index
dump_et request, 7-5
dump_fi request, 7-5
dump_pte request, 7-3, 7-5, 8-210
executing a program, 7-4
executing requests for, 8-535
finding, 7-4
IDs, 7-4, 8-215, 8-306
list_port_attachments request, 1-14
listing, 7-1
locks, 8-499
names, 8-419, 8-498
numbers, 7-3, 8-215, 8-419, 8-498
parent, 8-420
pme_status request, 1-14, 8-413
process request, 1-14, 7-7, 8-419
selecting, 7-7
setup_user_program request, 1-14
sleep request, 1-14
state, 7-6
summary request, 1-14, 7-6, 8-498
system usage, 8-72
table entry pointer (PTEP), 7-3
tasks and, 8-47, 8-314
transaction ID, 8-384
user, 8-420
who request, 1-14, 7-1, 8-540
Program counter (PC)
stack addresses, 8-487
stacks, 8-509
Program module (file) mode, 1-5, 4-3, 4-35,
8-523
requests, 4-3
use_file request, 4-35
Program modules
display_pm request, 8-57
dumps, 8-520
finding process executing, 7-4
kernel, 8-57
setting paths to, 8-480
status request, 8-494
user, 8-57
Protocol names
dumping, 8-206
Q
Queues, 8-89
Index-10
VOS System Analysis Manual (R073)
message and server, 8-217
scheduler, 8-246
quit request, 1-8, 8-3, 8-422
R
reconfigure_memory command, 8-177
Redirecting output, 2-6
attach_default_output
command, 2-7
detach_default_output
command, 2-7
start_logging command, 2-7
stop_logging command, 2-7
Relative addressing, 3-12
Requests
canceling, 2-4
default address values, 3-3
filtering output, 2-4
listing, 8-351
metering, 5-1
obsolete, D-1
redirecting output, 2-6
Reserved socket table (RST)
StrataLINK, 8-239
Resetting meters
as_meter_file file, 5-6
Running processes, 8-498
S
s$allocate subroutine, 8-47
s$control_task subroutine, 8-316
s$enable_tasking subroutine, 8-316
s$free subroutine, 8-47
s$get_paging_usage subroutine, 8-498
s$open subroutine, 8-517
s$set_task_priority subroutine, 8-317
scan_area request, 1-12, 8-423
scan_streams_msgs request, 1-10, 8-430
sched_lock_meters request, 1-13, 8-435
sched_meters request, 1-13, 8-438
Scheduler queues, 8-246
search_streams request, 1-10, 8-441
logging output, 8-442
Security logging, 8-70
security_admin command, 8-70
set_byte request, 1-8, 6-6, 6-7, 8-445
set_cache_pin_parameters
request, 1-11, 8-448
Index
set_comm_thresholds request, 1-10, 8-452
set_instruction request, 1-8, 6-7, 8-459
set_longword request, 1-8, 6-6, 6-7, 8-461
set_meter_file request, 1-13, 8-464
set_net_timeout request, 1-10, 8-466
network_client command, 8-467
set_net_trace request, 1-10, 8-468
display_net_trace request, 8-469
monitor_net_trace request, 8-469
set_scheduler_info command, 8-246
set_streams_param request, 1-10, 8-470,
8-470
set_tape_buffer_mode request, 1-15,
8-472
set_terminal_parameters command
dump_tcb request, 8-306
set_tp_param request, 1-8, 8-473
set_tuning_parameters command, 8-116
active directory tables, 8-76
set_word request, 1-8, 6-5, 6-7, 8-477
Setting byte values, 8-445
Setting instructions
versus data values, 6-7
setup_user_program request, 1-14, 8-480
sim_int_meters request, 1-13, 8-481
sleep request, 1-14, 8-484
sna_psna_trace request, C-2
sna_ssna_trace request, C-2
Sockets, 8-189, 8-240, 8-254
reserved, 8-239, 8-242
structures, 8-255
Source code line numbers
addressing with, 3-3
Stack frame
definition of, 3-13
Stack relative addressing, 3-4
frame request, 3-16
stack request, 1-12, 8-486
display request, 8-488
fstack request, 8-349
process request, 8-487
Stacks
Continuum-series modules, 8-488, 8-509
default address, 8-348
default frame addresses, 8-345
definition of, 3-13
displaying, 3-13
dumps, 4-10
forward trace, 8-349
frame request, 1-12, 8-345
fstack request, 1-12, 8-348
on units, 8-487, 8-509
program counter (PC), 8-487, 8-509
relative addressing, 3-2
space usage, 8-43
stack request, 1-12, 8-486
tasks and, 8-487, 8-509
trace request, 1-12, 3-13, 8-508
Star names
in addresses, 3-4
start_logging command, 2-7, 8-3
Static region
addresses, 3-2
status request, 1-8, 8-494
dump mode, 4-9, 8-495
IOA firmware mode, 4-15
IOP dump mode, 4-17
IOP firmware mode, 4-19
partition mode, 4-34
stop_logging command, 2-7
StrataLINK
circular tracing, 8-468
network socket table (NST), 8-186
pending request table (PRT), 8-208
reserved socket table (RST), 8-239
set_net_timout request, 8-466
set_net_trace request, 8-468
transaction IDs, 8-185
StrataLINK requests
display_net_trace, 8-52
dump_net_tids, 8-185
dump_nst, 8-188
dump_prt, 8-208
dump_rst, 8-239
dump_rsv_socket, 8-242
dump_socket_info, 8-252
monitor_net_trace, 8-403
StrataNET
gateways, 8-181
set_net_timeout request, 8-466
setting timeouts, 8-466
stations, 8-181
StrataNET requests
dump_net_info, 8-180
dump_nst, 8-188
dump_prt, 8-208
dump_rst, 8-239
dump_rsv_socket, 8-242
Index-11
Index
dump_socket_info, 8-252
Streams. See VOS STREAMS
Strings
matching, 8-401
summary request, 1-14, 8-498
dump mode, 8-499
module mode, 8-499
processes, 7-6
Symbol table
relative addressing, 3-2, 3-5
Symbolic address formats, 3-4
Symbolic names
finding, 3-5
syserr_log.(date) file, 2-11, 8-299
System
error messages, 8-299
heaps, 8-36
usage, 8-72
T
t1_getstate request, C-2
t1_getstats request, C-2
t1_gettune request, C-2
t1_lap_getstats request, C-2
t1_lap_gettune request, C-2
t1_wan_getstats request, C-2
t1_wan_gettune request, C-2
Tape drives
buffers, 8-335
set_tape_buffer_mode request, 1-15,
8-472
setting mode, 8-472
Task data region (TDR), 8-64
dumping, 8-313
Task data region entry (TDRE), 8-314
Tasks
dump_tdr request, 8-313
events and, 8-143
processes and, 8-47, 8-314
stacks and, 8-487, 8-509
task data region (TDR), 8-313
Terminal control block (TCB)
dumping, 8-302
Terminal control block header (TCBH)
dumping, 8-309
terminal_meters request, 1-13, 8-502
tpq_meters request, 1-13, 8-504
trace request, 1-12, 3-13, 8-508
Index-12
VOS System Analysis Manual (R073)
dump mode, 4-10
fstack request, 8-348
process request, 8-509
Transaction IDs
StrataLINK, 8-185
transaction_meters request, 8-512
Transactions
ID, 8-384
listing, 8-383
process ID, 8-384
U
Undefined mode, 1-5, 4-3, 4-36
update_channel_info command, 8-119,
8-456
use_block request, 1-4, 1-14, 4-4, 8-516
active files, 8-517
display request, 8-517
dump_afte request, 8-517
dump_axte request, 8-517
use_comm_dump request
communications controller dump
mode, 4-3
use_dump request, 1-14, 8-519
dump mode, 4-8
use_file request, 1-5, 1-14, 8-523
program module (file) mode, 4-35
use_iop request, 1-4, 1-5, 1-14, 8-525
IOA dump mode, 4-13, 8-526
IOA firmware mode, 4-14
IOP dump mode, 4-16, 8-526
IOP firmware mode, 4-18
module mode, 8-526
use_iop_dump request, 1-10, 8-528
IOA dump mode, 4-13
use_module request, 1-5, 1-14, 8-530
use_partition request, 1-5, 1-14, 8-531
display_disk_label command, 8-531
edit_vm_sizes request, 8-338
partition mode, 4-34
User process memory
Continuum-series, 7-10
displaying, 7-7
XA/R-series, 7-8
User processs space, 4-34
V
Variable names
Index
characteristics, 2-13
specifying, 2-13, 8-533
variable request, 1-8, 2-14, 8-533
Variable values
display request, 2-14
specifying, 2-14, 8-533
Variables
addresses in, 3-2
external, 3-2
Virtual address space, 8-43
displaying, 8-43
Virtual memory pools, 8-327
VOS
status of, 8-494
VOS program module (vos.pm)
XA/R-series, 4-23
VOS shared memory space
Continuum-series modules, 4-32
VOS STREAMS
data structures that synchronize execution
threads, 8-266
dump_porte request, 8-197
dump_stream request, 8-259
input/output data structures, 8-264
search_streams request, 8-441
VOS symbol table
displaying values in, 6-4
disassemble request, 8-19
forward stack traces, 8-349
user process memory, 7-8
VOS program module, 4-23
XA2000-series modules
forward stack traces, 8-349
W
walk request, 1-8, 8-535
process table entry (PTE), 8-535
where request, 1-8, 8-538
code relative addressing, 3-10
display request, 8-538
evaluate request, 8-340
who request, 1-14, 4-10, 7-1, 8-540
dump mode, 4-10
process request, 8-420
process table entry pointer (PTEP), 8-541
wired_memory_meters request, 1-13, 8-543
Word values
setting, 8-477
X
XA/R-series modules
alignment faults, 8-33, 8-399
changing memory in, 6-7
Index-13
Index
Index-14
VOS System Analysis Manual (R073)
You might also like
- VOS Administering and Customizing A System r281-03No ratings yetVOS Administering and Customizing A System r281-03396 pages
- VOS Startup and Shutdown A System (r282-03)No ratings yetVOS Startup and Shutdown A System (r282-03)198 pages
- Operating Systems Interview Questions You'll Most Likely Be AskedFrom EverandOperating Systems Interview Questions You'll Most Likely Be AskedNo ratings yet
- SAS Programming Guidelines Interview Questions You'll Most Likely Be AskedFrom EverandSAS Programming Guidelines Interview Questions You'll Most Likely Be AskedNo ratings yet
- Improved Performance Research Integration Tool User Guide - Version 4.6From EverandImproved Performance Research Integration Tool User Guide - Version 4.6No ratings yet
- Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and ObfuscationFrom EverandPractical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and ObfuscationNo ratings yet
- The Software Programmer: Basis of common protocols and proceduresFrom EverandThe Software Programmer: Basis of common protocols and proceduresNo ratings yet
- Stratus Ftserver System Administrator'S Guide For The Windows Operating SystemNo ratings yetStratus Ftserver System Administrator'S Guide For The Windows Operating System144 pages
- FortiGate 7.4 Admin Study Notes: 499 Study Notes for Accelerated Certification SuccessFrom EverandFortiGate 7.4 Admin Study Notes: 499 Study Notes for Accelerated Certification SuccessNo ratings yet
- “Information Systems Unraveled: Exploring the Core Concepts”: GoodMan, #1From Everand“Information Systems Unraveled: Exploring the Core Concepts”: GoodMan, #1No ratings yet
- ServiceNow Certified Implementation Specialist: Software Asset Management - Study NotesFrom EverandServiceNow Certified Implementation Specialist: Software Asset Management - Study NotesNo ratings yet
- Software Suite: Revolutionizing Computer Vision with the Ultimate Software SuiteFrom EverandSoftware Suite: Revolutionizing Computer Vision with the Ultimate Software SuiteNo ratings yet
- Python Advanced Programming: The Guide to Learn Python Programming. Reference with Exercises and Samples About Dynamical Programming, Multithreading, Multiprocessing, Debugging, Testing and MoreFrom EverandPython Advanced Programming: The Guide to Learn Python Programming. Reference with Exercises and Samples About Dynamical Programming, Multithreading, Multiprocessing, Debugging, Testing and MoreNo ratings yet
- IBM VIOS 2.2.4.20 Release Notes - Nov 2016No ratings yetIBM VIOS 2.2.4.20 Release Notes - Nov 201626 pages
- Computerised Systems Architecture: An embedded systems approachFrom EverandComputerised Systems Architecture: An embedded systems approachNo ratings yet
- Securing Application Deployment with Obfuscation and Code Signing: How to Create 3 Layers of Protection for .NET Release BuildFrom EverandSecuring Application Deployment with Obfuscation and Code Signing: How to Create 3 Layers of Protection for .NET Release BuildNo ratings yet
- Installers Guide To The Bose Serial Interface For Bose AV20, AV35 and AVM Home Theater Control ConsolesNo ratings yetInstallers Guide To The Bose Serial Interface For Bose AV20, AV35 and AVM Home Theater Control Consoles42 pages
- ASP.NET For Beginners: The Simple Guide to Learning ASP.NET Web Programming Fast!From EverandASP.NET For Beginners: The Simple Guide to Learning ASP.NET Web Programming Fast!No ratings yet
- Husqvarna Automover 420 - Quick Manual (Mantenimiento)No ratings yetHusqvarna Automover 420 - Quick Manual (Mantenimiento)8 pages
- Revision Information For PCMC ActiveX Library For WindowsXPNo ratings yetRevision Information For PCMC ActiveX Library For WindowsXP10 pages
- Pemeriksaan Sputum: Dr. Sanarko Lukman Halim, SPPK Bagian Patologi Klinik F.K. Ukrida Juli 2011No ratings yetPemeriksaan Sputum: Dr. Sanarko Lukman Halim, SPPK Bagian Patologi Klinik F.K. Ukrida Juli 201112 pages
- Liquid Penetrant Test Procedure: Document No.: SP-1.5 Rev. 1.2No ratings yetLiquid Penetrant Test Procedure: Document No.: SP-1.5 Rev. 1.212 pages
- 15-11-04 Apple Reply in Support of Alice Motion Against Two Ericsson PatentsNo ratings yet15-11-04 Apple Reply in Support of Alice Motion Against Two Ericsson Patents41 pages
- St. Paul Fire & Marine Insurance Company v. The Medical Protective Company, 691 F.2d 468, 10th Cir. (1982)No ratings yetSt. Paul Fire & Marine Insurance Company v. The Medical Protective Company, 691 F.2d 468, 10th Cir. (1982)4 pages
- Useb Dgcetfw Tetdip Piddiviaionline Publicationemployer List2021 Employer List2021q4finaltfwp 2No ratings yetUseb Dgcetfw Tetdip Piddiviaionline Publicationemployer List2021 Employer List2021q4finaltfwp 2629 pages
- Instant Access to Explorations in Monte Carlo Methods 2nd Edition Ronald W. Shonkwiler · Franklin Mendivil ebook Full Chapters100% (1)Instant Access to Explorations in Monte Carlo Methods 2nd Edition Ronald W. Shonkwiler · Franklin Mendivil ebook Full Chapters71 pages
