VOS System Analysis Manual (r073-04)

Stratus Computer, Inc.R073-04

VOS System Analysis Manual

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: R073Revision Number: 04 VOS Release Number: 14.0.0Printing 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 VersionThis 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.

Related ManualsRefer 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)

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

iv VOS System Analysis Manual (R073)

Preface

• VOS Communications Software: 3270 Channel Attach Programmer’s Guide (R220)

• VOS Communications Software: STREAMS Programmer’s Guide (R306)

Notation ConventionsThis 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 terminal’s 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 FunctionsVOS 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 v

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.

N O T E

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.

Format for Commands and RequestsStratus 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.

VOS Function V103ASCII

V103EPC

V105PC/+ 106

V105ANSI

CANCEL <F18> * †

† Numeric-keypad key

<5> † or * † <F18>

CYCLE <F17> <F12> <4> † <F17>

CYCLE BACK <Shift>-<F17> <Shift>-<F12> <7> † <Shift>-<F17>

DISPLAY FORM <F19> - † <6> † or - † <F19> or <Shift>-<Help>

HELP <Shift>-<F8> <Shift>-<F2> <Shift>-<F8> <Help>

INSERT DEFAULT <Shift>-<F11> <Shift>-<F10> <Shift>-<F11> <F11>

INSERT SAVED <F11> <F10> <F11> <Insert_Here>

INTERRUPT <Shift>-<F20> <Shift>-<Delete> <1> † <Shift>-<F20>

NO PAUSE <Shift>-<F18> <Shift>- * † <8> † <Shift>-<F18>

vi VOS System Analysis Manual (R073)

Preface

nameThe name of the command or request is at the top of the first page of the description.

PrivilegedThis 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.)

PurposeExplains briefly what the command or request does.

Display FormShows 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

add_disk Privileged

PurposeThe add_disk command tells the operating system on the currentmodule to recognize the specified logical volume for the duration ofthe current bootload.

Display Form

Command Line Formadd_disk disk_name

[ module_name ]

Argumentsdisk_name

The name of the logical volume to be recognized for the current bootload.

. . .

H

A B

C

D

E

F

G

-------------------------- add_disk ------------------------- disk_name: module_name: current_module

Required

A

B

C

D

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

Command-Line FormShows 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.

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 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.

a

E

viii VOS System Analysis Manual (R073)

Preface

The Notation Used in Command-Line Forms

ArgumentsDescribes the command or request arguments. The following table explains the notation used in argument descriptions.

The Notation Used in Argument Descriptions

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] Optional argument.

[argument_1]... 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.

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 value—either the displayed default value or a value that you specify.

(Privileged) Only a privileged process can specify a value for this argument.

argument_1 argument_2

argument_1 argument_2

F

G

Preface ix

Preface

The following additional headings may appear in the command or request description: Explanation, Error Messages, Examples, and Related Information.

ExplanationExplains how to use the command or request and provides supplementary information.

Error MessagesLists common error messages with a short explanation.

ExamplesIllustrates uses of the command or request.

Related InformationRefers 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 DocumentationThe 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 ManualsYou 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 ManualYou 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.

H

x 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 manual’s 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>.

N O T E

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 1-1Summary of analyze_system Functionality 1-1Invoking the analyze_system Command 1-3Getting Help 1-3Summary of the Modes of Operation 1-4Summary of the Documented analyze_system Requests 1-6

General Requests 1-6Communications Requests 1-8Disk File-System Requests 1-11Heap, Memory, and Stack Requests 1-12Metering Requests 1-13Mode Setting Requests 1-14Process Requests 1-14Tape Drive Requests 1-15

2. Using the analyze_system Command 2-1Executing VOS Commands 2-1

Executing Internal VOS Commands 2-2Executing External VOS Commands 2-3

Canceling a Request 2-3Filtering Output 2-4

Filtering Output with the match Request 2-4Filtering Output with Request Arguments 2-5Redirecting Output to a File 2-6

Displaying Files 2-7Displaying Files with the VOS display Command 2-7Displaying Files with the display_file Request 2-9Displaying System Error Log Data 2-11

Specifying Variable Names and Values 2-13Variable Names 2-13Variable Values 2-14

Contents xiii

Contents

3. Specifying Address Formats for Request Arguments 3-1Requests That Take Default Address Values 3-3Using Hexadecimal Address Formats 3-3Using Symbolic Address Formats 3-4

Object Module Names 3-5Object Module Code Relative Addressing 3-7Internal Static Relative Addressing 3-11

Indirect Addressing 3-11Relative Addressing Used by the display Request 3-12Displaying Stack Data 3-13

Stack Relative Addressing 3-16

4. Using the Modes of Operation 4-1Selecting a Mode 4-2Using Communications Controller Dump Mode 4-3Using Disk Block Mode 4-3

Displaying the Contents of a File 4-3Displaying the Contents of an Index 4-5

Using Dump Mode 4-7Preparing to Enter Dump Mode 4-8Entering Dump Mode and Selecting a Dump 4-8Displaying the Status of a Dump 4-9Displaying and Selecting Processes Recorded in a Dump 4-10Displaying Stack Information from a Dump 4-10Troubleshooting a Dump 4-11Deleting Dumps and Exiting Dump Mode 4-12

Using IOA and IOP Modes 4-12Using IOA Dump Mode 4-12Using IOA Firmware Mode 4-14IOP Requests Available in Module Mode 4-16Using IOP Dump Mode 4-16Using IOP Firmware Mode 4-17

Using Module Mode 4-20Request Types Used in Module Mode 4-21The VOS Program Module Memory Structure 4-22

The Structure of the XA/R-Series VOS Program Module 4-23

Shared Memory Space for an XA/R-Series VOS Program Module 4-24

The Structure of the Continuum-Series VOS Program Module 4-27

xiv VOS System Analysis Manual (R073)

Contents

Shared Memory Space for a Continuum-Series VOS Program Module 4-31

Ranges of Virtual Addresses in User Process Space 4-34Using Partition Mode 4-34Using Program Module (File) Mode 4-35Undefined Mode 4-35

5. Requests That Provide Metering Information 5-1Types of Meters 5-1

Requests That Contain the Word meters 5-1Requests That Contain the Argument -meter(s) 5-2Requests That Contain All Meter Fields 5-3Requests That Contain Some Meter Fields 5-4

Resetting Meters 5-4Using a Meter File 5-5

6. Requests That Display and Change Memory 6-1Displaying Unformatted and Formatted Data in Memory 6-1

Displaying Unformatted Data in Memory 6-1Displaying Formatted Data in Memory 6-3Displaying Values in the VOS Symbol Table 6-4Displaying Values in External Variables 6-4

Changing Memory 6-5Requests That Change Specific Areas of Memory 6-6

Displaying and Setting Data and Instructions in Memory 6-7Additional Rules for XA/R-Series Modules 6-7

7. Requests That Display Process Information 7-1Listing Processes 7-1

Determining the Process Number 7-3Finding a Process 7-4

Finding a Process That Is Executing a Program 7-4Finding a Process That Is Using an Open File 7-5Finding a Process That Is Waiting on an Event 7-5Finding a Process That Is Using a Device 7-6Determining the State of a Process 7-6

Selecting a Process 7-7Displaying User Process Memory 7-7

XA/R-Series User Process Memory 7-8Continuum-Series User Process Memory 7-10

Contents xv

Contents

8. Analyze System Commands and Requests 8-1analyze_system 8-2cache_meters 8-4change_iop_dump_switch 8-7check_area 8-10clone_command 8-14delete_dump 8-16disassemble 8-18disk_lock_meters 8-20disk_meters 8-23display 8-28display_alignment_faults 8-32display_cache_pin_parameters 8-35display_extensible_heap 8-36display_file 8-40display_memory_usage 8-43display_meter_file_info 8-50display_net_trace 8-52display_pm 8-57display_process_info 8-64display_security_info 8-70display_system_usage 8-72dump_adt 8-75dump_adte 8-82dump_afte 8-85dump_area 8-92dump_axte 8-100dump_bmt 8-104dump_bsc 8-107dump_cache 8-111dump_cache_info 8-115dump_channel_info 8-118dump_channels 8-121dump_comm_buffers 8-124dump_eit 8-129dump_et 8-134dump_events 8-142dump_firmware_names 8-146dump_fli 8-148dump_fw_table 8-151dump_giza 8-153dump_h3270 8-156dump_iop_equip_table 8-160dump_iop_meters 8-163dump_lap_meters 8-166dump_lcb 8-168dump_lock 8-171

xvi VOS System Analysis Manual (R073)

Contents

dump_mt 8-176dump_net_info 8-180dump_net_tids 8-185dump_nst 8-188dump_poll_select 8-191dump_porte 8-196dump_protocol_names 8-206dump_prt 8-208dump_pte 8-210dump_queue_info 8-217dump_r3270 8-229dump_r3270_trace 8-235dump_rst 8-239dump_rsv_socket 8-242dump_scheduler_queues 8-246dump_socket 8-249dump_socket_info 8-252dump_stream 8-259dump_streams 8-298dump_syserr 8-299dump_tcb 8-302dump_tcbh 8-309dump_tdr 8-313dump_tpo 8-320dump_transaction 8-325dump_vm_pool_info 8-327edit_vm_sizes 8-335evaluate 8-339event_count_meters 8-341find_string 8-344frame 8-345fstack 8-348help 8-351interrupt_meters 8-352list_boards 8-357list_disks 8-363list_dumps 8-365list_file_activity 8-367list_iop_dump_switch 8-370list_iop_dumps 8-372list_port_attachments 8-374list_streams_params 8-376list_tp_params 8-381list_transaction_trace 8-383list_transactions 8-385lock_meters 8-389lock_summary 8-394log_alignment_faults 8-398match 8-401monitor_net_trace 8-403

Contents xvii

Contents

page_meters 8-409pme_status 8-413power_summary 8-416process 8-419quit 8-422scan_area 8-423scan_streams_msgs 8-430sched_lock_meters 8-435sched_meters 8-438search_streams 8-441set_byte 8-445set_cache_pin_parameters 8-448set_comm_thresholds 8-452set_instruction 8-459set_longword 8-461set_meter_file 8-464set_net_timeout 8-466set_net_trace 8-468set_streams_param 8-470set_tape_buffer_mode 8-472set_tp_param 8-473set_word 8-477setup_user_program 8-480sim_int_meters 8-481sleep 8-484stack 8-486status 8-494summary 8-498terminal_meters 8-502tpq_meters 8-504trace 8-508transaction_meters 8-512use_block 8-516use_dump 8-519use_file 8-523use_iop 8-525use_iop_dump 8-528use_module 8-530use_partition 8-531variable 8-533walk 8-535where 8-538who 8-540wired_memory_meters 8-543

xviii VOS System Analysis Manual (R073)

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 D-1

Index Index-1

Contents xix

xx VOS System Analysis Manual (R073)

Figures

Figure 4-1. XA/R-Series VOS Program Module at Boot Time 4-24Figure 4-2. Sample XA/R-Series (G861 or G862) VOS Virtual

Memory Pool 4-27Figure 4-3. Continuum-Series VOS Program Module at Boot Time 4-31Figure 4-4. Sample Continuum-Series VOS Virtual Memory Pool 4-33Figure 7-1. XA/R-Series Modules User Process Space 7-9Figure 7-2. Continuum-Series Module User Process Space 7-11Figure 8-1. Socket Structures 8-255Figure 8-2. VOS STREAMS I/O Data Structures 8-264Figure 8-3. VOS STREAMS Data Structures That Synchronize

Execution Threads 8-266

Tables

Table 1-1. Requests for Obtaining General System Status 1-6Table 1-2. Requests for Obtaining Communications Status 1-8Table 1-3. Requests to Obtain Disk and File-System Status 1-11Table 1-4. Requests to Obtain Heap, Memory, and Stack Status 1-12Table 1-5. Requests to Obtain Metering Information 1-13Table 1-6. Requests to Set analyze_system Modes 1-14Table 1-7. Requests to Obtain Information about Processes on a

Module 1-14Table 1-8. Request to Set Tape Drive Status 1-15Table 3-1. Valid Address Formats 3-2Table 4-1. Preparing and Selecting Subsystem Modes 4-2Table 4-2. Types of Module Mode Requests 4-21Table 4-3. Virtual Address Ranges in User Process Space 4-34Table 8-1. The dump_stream -stm_sched Meters 8-275Table 8-2. Parameter Values of the set_tp_param Request 8-474Table A-1. Abbreviations A-1Table B-1. VOS Internal Commands B-1Table D-1. Obsolete and Stratus Use Only Requests D-1

Tables xxi

Tables

xxii VOS System Analysis Manual (R073)

Chapter 1Overview of the

analyze_system Command1-

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 FunctionalityThe 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 CommandWhen you issue the analyze_system command at the command line, it displays a prompt and information such as the following.

ready 11:32:00analyze_systemVOS Release 14.0.0d, analyze_system Release 14.0.0dCurrent process is 472, ptep C3506700, Suzanne_Ryan.Engas:

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 HelpThe 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 -usageUsage: 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 errdump_syserrinterrupt_metersas:

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 -usageUsage: dump_syserr [-all] [-last number] [-long]as:


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 OperationThe 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.


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 command’s -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.


Summary of the Documented analyze_system Requests

Summary of the Documented analyze_system RequestsThe 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 RequestsTable 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)

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



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 TPOverseer’s 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


Request Description



Communications RequestsTable 1-2 describes the requests that you use to obtain communications status information.

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

Table 1-2. Requests for Obtaining Communications Status (Page 1 of 3)

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


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


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_streamdump_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


Request Description



Disk File-System RequestsTable 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



Heap, Memory, and Stack RequestsTable 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

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



Metering RequestsTable 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



Mode Setting RequestsTable 1-6 describes the requests that you use to set analyze_system modes.

Process RequestsTable 1-7 describes the requests that you use to get information about processes on a module.

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

Table 1-7. Requests to Obtain Information about Processes on a Module

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



Tape Drive RequestsTable 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




Chapter 2Using the analyze_system

Command2-

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 CommandsBy 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 CommandsTo invoke a VOS internal command, precede it with a two-dot (..) prefix. For example:

as: ..change_current_dir >systemas: ..list -dirs

Directories: 62

m 2 accountings 1 acls 1 alcs 1 asn_include_librarys 1 asn_object_library....as:

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) list_modules (prelogin)add_disk (privileged) list_port_attachmentsadd_link_board (privileged) list_process_cmd_limits....list_devices where_pathlist_kernel_programs (privileged) who_lockedas:

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 >systemanalyze_system: Entry point name not found. change_current_diras:

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_usersas:

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


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>systemanalyze_system: Object not found. process

Executing External VOS CommandsIssue the login command to execute one or more external commands. For example:

as: ..loginSuzanne_Ryan.Eng logged in on %sys#m2 at 95-04-10 10:35:05 EDT.ready: display_current_dir%sys#m2>systemready: change_current_dirready: display_current_dir%sys#m2_user>Eng>Suzanne_Ryanready: list_users J*Suzanne_Ryan.Eng* Suzanne_Ryan.Engready: logoutas:

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.Engas:

Canceling a RequestIf 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,


Filtering Output

press the key that invokes the BREAK function. At the debug prompt, type reenter. For example:

as: update_iop_dump_switch -formiop_slot: BREAKRequest? (stop, continue, debug, keep, login, re-enter) reenteras:

N O T E

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 OutputYou 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 RequestYou 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_idas: dump_ptePTE 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_ptePTE at 8180E440 for Suzanne_Ryan.Eng (login) process_id: 0111873Fas: dump_ptePTE at 8180E440 for Suzanne_Ryan.Eng (login) process_id: 0111873F process_number: 1855 max_priority: 6 max_processes: 0....as:


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: 81419620as:

Filtering Output with Request ArgumentsMany of the analyze_system requests have arguments such as -match, -long, -brief, and -all, which enable you to filter a request’s 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.4as: match term.17.12.4; dump_et -all80F4C4A0 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 -brieflock name address type lock state num locks--------- ------- ---- ---------- ---------

Lock List Header 80C11A20 single unlocked 103wired lock cow stomach 80C11B40 single unlocked 2paged lock cow stomach 80C11C60 single unlocked 31wired lock queue 80C11D80 single unlocked 28191paged lock queue 80C11EA0 single unlocked 3408138....as: dump_lock -no_briefLock info at 80C11A20 name: Lock List Header lock_wordp: 800063C0 -> 8000x lock_state: unlocked type: 1 (single) flags: wired spin_limit: 0 (0.000 seconds)Lock info at 80C11B40 name: wired lock cow stomach

lock_wordp: 800064C0 -> 8000x lock_state: unlocked type: 1 (single) flags: wired spin_limit: forever....


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 device_event_for_term.2.12.4 wait_list: 8191D13C -> 8190FA60: PreLogin.System (pre-login) lock: 8000 flags: system array_slot_ptr: 80C0FFF8 event count: 286 (0000011E) last full count: 286 (0000011E) pended notify-1’s: 0 (00000000) status: 00000000 uid: 0.0000.00000000.00000000.0000.0000 (80-01-01 00:00:00 EDT) ref_cnt: 2 name_len: 29 ex_ete_ptr: 00000001....as:

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 network_notify_event80C103C0 5745 stopped_process_event80C10440 0 system_sleep_event80C104C0 361 red_light_interrupt_event80C107A0 1028 page_wait_event80C10840 269083 page_fault_event....

Redirecting Output to a FileIssue 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


Displaying Files

log file. The VOS display command’s -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_readsas: who -user PROC PTEP USER NAME*1855 8180E440 Suzanne_Ryan.Eng, on CPU30as: ..stop_loggingas: ..display (home_dir)>who.log -no_headeras: PROC PTEP USER NAME*1855 8180E440 Suzanne_Ryan.Eng, on CPU30as:

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_evarsdisplay_pm -external_vars_map..detach_default_outputas:

Displaying FilesThis 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_evarsdisplay_pm -external_vars_map..detach_default_outputas: ..display vos_evars

%es#m24_user2>Eng>Joe_Smith>vos_evars 98-04-10 14:25:15 EDT

as:External Variable Map:


Displaying Files

Name Sx Address LengthACCESS_ANY_EXEC$ 1 80839C60 00000004ACCESS_INTERLOCK$ 1 80839C64 00000004ACCESS_IO$ 2 8089C194 00000004....as:

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_idas: ..display vos_evars -no_header -match MODULE_ID -no_caselessas:

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 2sys_info$module_id 1 80839B44 00000002as:

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_idas: ..display vos_evars -no_header -first_line 2634 -last_line 2637sys_info$module_id 1 80839B44 00000002sys_info$module_name 1 80839B50 00000022as:


Displaying Files

Displaying Files with the display_file RequestIssue 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:34 Name Sx Address Length5 ACCESS_ANY_EXEC$ 1 80839C60 000000046 ACCESS_INTERLOCK$7 1 80839C64 000000048 ACCESS_IO$ 2 8089C194 000000049 ACCESS_KERNEL_EXEC$10 1 80839C50 0000000411 ACCESS_KERNEL_READ$-------------------------------------------------------------------Current process is 295, ptep 81BA2600, Joe_Smith.Engas: dump_syserr

0 active messages, 638 free.Total of 64183 logged messages.Total of 0 lost messages.

as: ..attach_default_output vos_evarsdisplay_pm -external_vars_map..detach_default_outputas: display_file vos_evarsas:

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 0000000413 ACCESS_KERNEL_WRITE$14 1 80839C4C 0000000415 ACCESS_USER_EXEC$16 1 80839C5C 0000000417 ACCESS_USER_READ$18 1 80839C54 0000000419 ACCESS_USER_WRITE$20 1 80839C58 0000000421 CMD_free_cb_ack_timeout22 1 8082F210 00000004-------------------------------------------------------------------


Displaying Files

as: dump_syserr


as: ..attach_default_output vos_evarsdisplay_pm -external_vars_map..detach_default_outputas: display_file vos_evarsas: display_fileas:

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_id2635 1 80839B44 000000022636 sys_info$module_name2637 1 80839B50 000000222638 sys_info$module_no2639 1 80839B72 000000022640 sys_info$multiple_user_cpus2641 2 808A82B0 000000022642 sys_info$n_kinsurance_pages2643 1 8082320C 000000022644 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_evarsdisplay_pm -external_vars_map..detach_default_outputas: display_file vos_evarsas: display_fileas: display_file -line 2634as:


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_outputas: display_file vos_evarsas: display_fileas: display_file 2634display_file: Object not found. %sys#m2_user>Eng>Joe_Smith>2634as: display_file -line 2634display_file: Object not found. %sys#m2_user>Eng>Joe_Smith>2634as: display_file vos_evarsas: display_file -line 2634as: display_file -offas:

Displaying System Error Log DataThis 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


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



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 status15:51:57 link 0100i 18 10982 01 00000011 00000000 controller status15:51:58 scsi 0100r 04/11/07 0 02010180 0002030F Correctable Erroras:

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



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



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 status15:30:29 link 0100i 18 10982 01 00000011 00000000 controller status....as:


Specifying Variable Names and Values

Specifying Variable Names and ValuesYou 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 NamesVariable 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 280839B44 0 0111 |.. |as: variable sys_info$module_id 0101000as: display sys_info$module_id 2display: The specified page is not present in your address space. 00000101as:

• 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 0–9 and a–f as a hexadecimal value.

• Do not create variable names that look like VOS symbols (e.g., sys_info$module_id, etc.). If your variable’s name is identical to a VOS symbol name, the name resolution of analyze_system will find and use your variable’s value instead of the VOS symbol’s 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.



Variable ValuesVariable 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: variable digits 12345678as: variable mod sys_info$module_idas:

• 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: variabledigits 12345678mod 80839B44as:

To display the value of that variable, you can issue the variable request with a variable name, as shown in the following example.

as: variable modmod 80839B44as:

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 mod80839B44 0 01110000 |.... |as: display mod 380839B44 0 011100 |... |as: display mod 280839B44 0 0111 |.. |as: display mod 180839B44 0 01 |. |as:



• They are converted to two’s complement form when negative numbers. A two’s 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 -1as: variable minus_sixteen -10as: variable minus_one; variable minus_sixteenminus_one FFFFFFFFminus_sixteen FFFFFFF0as: variable minus_ten FFFFFFF6as: variable minus_tenminus_ten FFFFFFF6as: variable one -FFFFFFFFas: variable oneone 00000001as:




Chapter 3Specifying Address Formats

for Request Arguments3-

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.

N O T E

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+5a188A34+19-F(addr$)+4

Specifying Address Formats for Request Arguments 3-1

Specifying Address Formats for Request Arguments

External variable Any declared external variable name (can be found in a program module’s 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.

After computing an address from the value given, a request reads a long word from the address to use as the address value.

’(addr)’

(Location addr contains a byte pointer to address.)

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

Table 3-1. Valid Address Formats (Page 2 of 2)

Address Format Description Example


Requests That Take Default Address Values

Requests That Take Default Address ValuesThe 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 FormatsA 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)4106as: ..display_line (hexadecimal 4106)100Axas:

† 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]


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 100a-A00001000as: evaluate ’100a - a’00001000as: evaluate 1000+a0000100Aas: evaluate -aFFFFFFF6as: evaluate 8+8+800000018as: evaluate (hexadecimal 24)00000018as:

Using Symbolic Address FormatsSymbolic 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



4. program related addresses—If 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 User’s Guide (R145), or VOS Standard C User’s 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 NamesTo 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 CPU2as: process 457Using nonrunning process.Current process is 457, ptep 04CA9440, Joe_Smith.Eng



as: display_pm -program_module user_program -module_map

Module Map:

Name Date Compiled Scn Code Symtab Static UERW, SAP Start Length Start Length Start Lengthstorage 95-07-05 20:35:13 3 00E00000 0000004A 00E06000 000000A0 00E04000 00000026sum 95-07-05 20:35:43 3 00E00050 0000002E 00E060A0 00000090 00E04028 00000016display 95-07-05 20:35:28 3 00E00080 0000011E 00E06130 000000A0 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 Date Compiled Scn Code Symtab Static UERW, SAP Start Length Start Length Start Lengthstorage 1 95-07-05 20:35:13 3 00E00000 0000004A 00E06000 000000A0 00E04000 00000026

Module Map Dates:

Name DTM DTCPstorage 95-07-05 20:35:19 95-07-05 20:35:13as:

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 storagedisplay_pm: No map entry found for storage.as: display_pm display

Module Map:



Name Dir Index Date Compiled Scn Code Symtab Static UERW, SAP Start Length Start Length Start Lengthdisplay 3 93-09-23 18:03:35 3 0046CC28 00001642 006F50D4 00000910 00500A84 00000232

Module Map Dates:

Name DTM DTCPdisplay 93-09-23 18:04:45 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 &istorage00E0000000E0600000E04000as: evaluate display; evaluate &tdisplay; evaluate &idisplay0046CC28006F50D400500A84as:

Object Module Code Relative AddressingYou 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.pl1COMPILED ON: 98-09-24 AT: 16:18 by: PL/I Release 14.0.1OPTIONS: -optimization_level 3, -full, -processor pa8000, -minimal_stack_frames

1 /* Program used to demonstrate types of data storage */ 2 3 main: 4 proc;



5 6 %replace constant_one by 1; 7 8 dcl int_static_two bin(15) init(2) static; 9 dcl stack_three bin(15); 10 dcl result bin(15) static external shared; 11

12 dcl sum entry(bin(15), bin(15), bin(15)); 13 dcl display entry(); 14 15 stack_three = 3; 16 call sum(constant_one, int_static_two, stack_three); 17 call display; 18 19 end main; 20

EXTERNAL ENTRY POINTS

NAME CLASS SIZE LOC ATTRIBUTES

main constant entry external

PROCEDURE main ON LINE 3

NAME CLASS SIZE LOC ATTRIBUTES

display constant 000000 entry externalint_static_two static 2 000004 fixed bin(15,0) internal initialresult static 2 000000 fixed bin(15,0) externalstack_three automatic 2 000000 fixed bin(15,0)sum constant 000000 entry external

NO PROGRAMMED OPERATORS USED IN THIS COMPILATION.

CODE GENERATED FOR PROCESSOR: pa8000

STACK FRAME SIZES:(fixed length portion only)

NAME LINE STACK SIZE

main 3 64

ASSEMBLY LANGUAGE LISTING

LINE 3main:



proc;00000060: 6BC23FD9 stw %r2,-20(%sp)00000064 37DE0080 ldo 64(%sp),%sp

LINE 16 call sum(constant_one, int_static_two, stack_three);

LINE 15 stack_three = 3;00000068 2B600000 addil L%0,%dp,%r1 #160000006C B4150006 addi 3,%r0,%r21 #1500000070 34330000 ldo 0(%r1),%r19 #1600000074 B4140002 addi 1,%r0,%r2000000078 67D43F85 sth %r20,-62(%sp) .t1090000007C 36790009 ldo -8188(%r19),%r2500000080 37DA3F85 ldo -62(%sp),%r2600000084 37D83F81 ldo -64(%sp),%r2400000088 E800A048 b,l 0x000000B4,%r2 sum0000008C 67D53F81 sth %r21,-64(%sp) #15 stack_three

LINE 17 call display;00000090 E800A020 b,l 0x000000A8,%r2 display00000094 34000000 nop

LINE 19 end main;00000098 4BC23F59 ldw -84(%sp),%r20000009C E840D000 bve (%r2)000000A0 37DE3F81 ldo -64(%sp),%sp000000A4 E81F1FF7 b,n 0x000000A4

STUB(S) FROM LINE 17000000A8: E8200000 b,l 0x000000B0,%r1 .l112000000AC 28200000 addil L%0,%r1,%r1 display000000B0: E020E002 be,n 0(%sr7,%r1) display

STUB(S) FROM LINE 16000000B4: E8200000 b,l 0x000000BC,%r1 .l113000000B8 28200000 addil L%0,%r1,%r1 sum000000BC: E020E002 be,n 0(%sr7,%r1) sum

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



source-code line number. The following examples show code relative addressing used with the display, disassemble, and where requests.

N O T E

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@1Using line 300002060 0 6BC23FD9 |k.?. |as: where storage@1Using line 300002060 at storage+60, line 3as: where storage@300002060 at storage+60, line 3as: where storage@4Using line 300002060 at storage+60, line 3as: where storage@1700002090 at storage+90, line 17as: display storage+6000002060 0 6BC23FD9 |k.?. |as: display storage+6400002064 0 37DE0080 |7... |as: disassemble storage+60/* Line 300002060 6BC23FD9 stw %r2,-20(%sp)00002064 37DE0080 ldo 64(%sp),%spas: display &istorage00003000 0 00000000 |.... |as: display &istorage+400003004 0 00020000 |.... |as: display &istorage+4 200003004 0 0002 |.. |


Indirect Addressing

As shown in the following examples, you can also use byte offsets from the beginning of an object module’s code region to disassemble an object module. However, this method is much less intuitive than relative addressing using line numbers.

as: display storage00E00000 0 4E4F0000 |NO.. |as: display storage+400E00004 0 49ED8018 |I... |as: disassemble storage+4/* Line 300E00004 49ED 8018 lea -32744(a5),a400E00008 4E56 FFEC link.w a6,=-2000E0000C 48EE B000 movem.l a4;a5;a7,-16(a6)00E00010 FFF0as:

Internal Static Relative AddressingTo 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 &istorage00E04000 0 00E00000 |.... |as: display &istorage+400E04004 0 00020000 |.... |as: display &istorage+4 200E04004 0 0002 |.. |as:

Indirect AddressingAn 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.


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_ptePTE at 4109B8C0 for Joe_Smith.Eng (login) process_number: 770as: ..display_line (hexadecimal (calc 8 * 770)) 1810xas: display perm_process_datap$002F10C0 0 0030C760 |.0.` |as: display 0030C760+18100030DF70 0 41350030 |A5.0 |as: display 41350030 1641350030 0 01145302 000B4461 76655F4D 61727469 |..S...Joe_Smith.|as: display '((perm_process_datap$)+1810)' 1641350030 0 01145302 000B4461 76655F4D 61727469 |..S...Joe_Smith.|as:

Relative Addressing Used by the display RequestWhen 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: display80F78960 0 00145374 |..St |as: display80F78960 0 00145374 |..St |as: display *80F78960 0 00145374 |..St |as: display *+1080F78970 0 636B2028 |ck ( |as:

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


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_id80839B44 0 01110000 |.... |as: dump_ptePTE at 81E3AA80 for Joe_Smith.Eng (login) process_id: 0111C5D6...as: display80839B44 0 01110000 |.... |as: dump_pte 81E3AA80PTE at 81E3AA80 for Joe_Smith.Eng (login) process_id: 0111C5D6...as: display81E3AA80 0 0111C5D6 |.... |as:

Displaying Stack DataThe 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.

N O T E

In module mode (versus dump mode), a stack trace may not be complete or accurate.



as: process -process_name storageUsing nonrunning process.Current process is 1235, ptep C5223A80, Dan_Danz.Stratus (storage)as: traceswitch_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 7FFF5040s$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 7FFEC040s$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 C043B7E0Trace 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.



as: stack 7140stack: You must specify a pc if specifying a stack address.as: stack 7140 -pc 2270display 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 C043B7E0Trace 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 7080start_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:



Stack Relative AddressingYou 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 204723F1E 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 04723F30as: display &see047 2FIE 0 00031234


Chapter 4Using the Modes of Operation4-

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 ModeTable 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

Communicationscontroller 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 orlist_iop_dumps

use_dump dump_number oruse_iop_dump dump_number anduse_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 orlist_iop_dumps

use_dump dump_number oruse_iop_dump dump_number anduse_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


Using Communications Controller Dump Mode

Using Communications Controller Dump ModeUse 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 ModeUse 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 FileThe 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

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

Table 4-1. Preparing and Selecting Subsystem Modes (Page 2 of 2)

Mode Purpose Preparation Request Mode Selection Request


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.

N O T E

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_headerabcdefghijas: ..dump_file ex_file

%sys#m2_user>Eng>Joe_Smith>asm_test_code>ex_file 95-07-06 13:12:39

Block number 1

000 00056162 636465FF FFFFFFFF FFFFFFFF |..abcde.........|010 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................| =FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|

Block number 2

000 FFFF0005 66676869 6AFFFFFF FFFFFFFF |....fghij.......|010 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................| =FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|



as: dump_afte ex_fileAFTE 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 409600000000 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 409600000000 000 FFFF0005 66676869 6AFFFFFF FFFFFFFF |....fghij.......|00000010 010 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................| =00000FF0 FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................|as:

Displaying the Contents of an IndexThe 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_headerJane AustenEmily BronteWilliam FaulknerErnest Hemingwayas: ..display authors -no_header -index given_nameEmily BronteErnest Hemingway



Jane AustenWilliam Faulkneras: ..dump_file authors -index given_name

%sys#m2_user>Eng>Joe_Smith>authors 95-05-03 10:49:28 EDT....Block number 2

000 05011A00 FFFFFFFF FFFFFFFF FFFFFFFF |................|010 00040FCF 0FCF0000 003E0FD9 00000014 |.........>......|020 0FDE0000 00000FD4 00000028 FFFFFFFF |...........(....|030 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |................| =FE0 FFFFFF04 6561726E 0477696C 6C04656D |....erne.will.em|FF0 696C046A 616E6508 00000000 00000000 |il.jane.........|

as: use_moduleVOS Release 12.1, analyze_system Release 12.1as: dump_axte authors given_nameAXTE 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 409600000000 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 |....erne.will.em|00000FF0 FF0 696C046A 616E6508 00000000 00000000 |il.jane.........|as:


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: 5Level Number: 1Dup Block: false....Keys:

earn 62emil 20jane 0will 40

as:

Using Dump ModeUse 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.

N O T E

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 Dump Mode

Preparing to Enter Dump ModeUse 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_dumpsDumps 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.dumpas:

Entering Dump Mode and Selecting a DumpUse 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 dump’s contents.

as: use_dump 1Detected compressed dump.Using %sys#m2>Overseer>dumps>system.95-01-31.13:52:47.c.dumpWarning: Modified code pages present in dump.VOS Release 13.0.1, analyze_system Release 13.0.1use_dump: The version of the program has changed. %sys#libs>os>m2_pms>c7100.pmUsing process on CPU31.Current process is 1060, ptep 82EF41E0, Joe_Smith.Eng (mk:disk_cm_msg.obj)PCP called from 80643640 on CPU31Ram 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:


Using Dump Mode

Displaying the Status of a DumpAs shown in the following example, you can use the status request to display more information about the contents of the selected dump.

as: statusUsing 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: cbtsmas:


Using Dump Mode

Displaying and Selecting Processes Recorded in a DumpAs 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 USER NAME 1 80C49A40 CPU30.Idle (Idle_30) 3 81519720 Cache_Manager_Post.System (Cache_Manager_Post) 4 8151C3E0 Cache_Manager_Timer.System (Cache_Manager_Timer) 5 8151EBE0 Cache_Manager_Locker.System (Cache_Manager_Locker) 6 815235E0 CPU31.Idle (Idle_31) 7 81523AA0 CPU28.Idle (Idle_28) 8 81525020 CPU29.Idle (Idle_29), on CPU29 15 82E9B440 Joe_Smith.Eng (Iake) 16 81574A20 Kernel_Utility.System (Kernel_Utility) 17 81576820 Maintenance_Utility.System (Maintenance_Utility)....* 770 41350030 Joe_Smith.Eng, on CPU4as:

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 DumpYou can use the trace request to display a stack trace. For example:

as: traceMCP: 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, line 655)MCP: 803F86D0

Fault FIR: 804E2DFC (disk_driver_module+181C, line 975)


Using Dump Mode

Fault EFA: 00000003 Fault r2: 803F88C0 Fault r3: 803F88E0dm_putnext fp: 803F88E0 pc: 804E2DFC (disk_driver_module+181C,line 9+75)send_unsolicited_message

fp: 803F8930 pc: 804DD1E0 (disk_common_util+65F0, line 406+0)check_mailbox fp: 803F8980 pc: 804DC874 (disk_common_util+5C84, line 340+3)di_interrupt_act fp: 803F8A10 pc: 804EB404 (disk_iop_driver+43E4, line 2971+)di_interrupt_handler fp: 803F8A70 pc: 804EB2D0 (disk_iop_driver+42B0, line 2885iop_disk_interrupt_handler

fp: 803F8AF0 pc: 8060A79C (iop_interrupt_handler+F3C, line+ 428)atlantic_interrupt fp: 803F8B50 pc: 80631A28 (atlantic_interrupt+A28)

On-units at 80631B90....as:

Troubleshooting a DumpTo troubleshoot a dump, you can use the following requests.

• display—Use 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_code—Use these requests to determine if part of the dumped VOS image is corrupted.

• find_string—Use 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_id8083ABB4 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 IOA and IOP Modes

as: check_boardsNo Hardware Problems Detected.as: check_area -heap user

--- The area has verified correctlyas:

The following example displays the addresses for string matches found in the selected dump.

as: find_string Joe -no_hexASCII pattern ’Joe’ found at address 8003B20E (kernel)ASCII pattern ’Joe’ found at address 8003B38E (kernel)ASCII pattern ’Joe’ found at address 8003B60E (kernel)....ASCII pattern ’Joe’ found at address 3FF2718C (process 1060)....as:

Deleting Dumps and Exiting Dump ModeUse 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 ModesThis 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 ModeUse 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



IOPs were installed in the cabinet, not the IOP slot numbers.Then, issue the status request.

as: list_iop_dumpsDumps 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.dumpas: use_iop_dump 3Using %vse9#m9>Overseer>dumps>iop6ia20.98-05-07.14:26:20.dumpVOS Release 14.0.beta.bx, analyze_system Pre-release Ram pages from IOAs : 20 present (IOP 1).as: use_iop -iop_no 1 -ioa 20as: statusUsing dump %vse9#m9>Overseer>dumps>iop6ia20.98-05-07.14:26:20.dumpand 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 3130 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: cbtsmas:



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+.pmas:

To exit IOA dump mode, select another mode. For example, you can select module mode by issuing the use_module request.

Using IOA Firmware ModeUse IOA firmware mode to display the current status of a specified IOA’s 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



15 Terminator K10810 17290 6 0 0 BP Bus P ***** *** 0 BQ Bus Q ***** *** 0 5 IO Processor K20010 13870 48 45 0...as: use_iop 4 -ioa 13as:

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: statusUsing 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.0binder 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: 1program_name: ioa04_cloud9.pmbinder_version: CONVERT_IEEE v1.0release_name: IO Release 200.alpha.aas:

To exit IOA firmware mode, select another mode. For example, you can select module mode by issuing the use_module request.



IOP Requests Available in Module ModeNot 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.

Using IOP Dump ModeUse 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_dumpsDumps 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.dumpas: use_iop_dump 1Using %vse9#m9>Overseer>dumps>iop6.98-03-17.15:03:52.dumpVOS Release 14.0.beta.bx, analyze_system Pre-releaseRam pages from IOP 1 present.as: use_iop -iop_no 1

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



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: statusUsing dump %vse9#m9>Overseer>dumps>iop6.98-03-17.15:03:52.dumpand 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: cbtsmas:

To exit IOP dump mode, select another mode. For example, you can select module mode by issuing the use_module request.

Using IOP Firmware ModeUse IOP firmware mode to display the current status of a specified IOP’s 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.



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

Module: %es#m18 (28 Slot Chassis) Id Prom --------Fault Data------Slot Board Type Model Serial Rev Rev Cnt Code Last Fault Time 4 IO Processor K20010 19025 63 52 0 0 Null Modem Comm Adapt K11100 13070 19 12 0 1 Tape Adapter K10700 2400 18 8 0 0 Tape Adapter K10700 ***** *** 0 2 SCSI Adapter Type 3 K12110 15837 13 42 0 1 1.5 GB SCSI Disk Dr D60400 99999 0 0 0 2 1.5 GB SCSI Disk Dr D60400 99999 0 0 0 3 1.5 GB SCSI Disk Dr D60400 99999 0 0 0 3 SCSI Adapter Type 3 K12110 12341 13 42 0 1 1.5 GB SCSI Disk Dr D60400 99999 0 0 0 2 1.5 GB SCSI Disk Dr D60400 99999 0 0 0 3 1.5 GB SCSI Disk Dr D60400 14283 0 0 0 4 SCSI Adapter Type 3 K12110 20133 19 42 0

1 3.2 GB SCSI Disk Dr D60500 99999 0 0 0 2 1.5 GB SCSI Disk Dr D60400 99999 0 0 0 3 3.2 GB SCSI Disk Dr D60500 1557 0 0 0 5 SCSI Adapter Type 3 K12110 12297 19 42 0 1 3.2 GB SCSI Disk Dr D60500 99999 0 0 0 2 1.5 GB SCSI Disk Dr D60400 99999 0 0 0 3 3.2 GB SCSI Disk Dr D60500 99999 0 0 0 6 SCSI Adapter Type 3 K12110 12267 4 42 0 1 3.2 GB SCSI Disk Dr D60500 99999 0 0 0 3 Tape Drive DAT-2 w/ T60210 ***** *** 0 7 SCSI Adapter Type 3 K12110 15310 13 42 0 1 3.2 GB SCSI Disk Dr D60500 99999 0 0 0 8 Null Modem Comm Adapt K11100 16008 25 16 0 9 Ethernet Adapter K10410 16531 14 18 0 10 Ethernet Adapter K10410 11726 4 17 0...

BP Bus P ***** *** 0 BQ Bus Q ***** *** 0 5 IO Processor K20010 10967 63 52 0

as: use_iop 4



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: statusUsing 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: 1program_name: iop_type_bbinder_version: bind, Release 14.0.0release_name: Release 240.0.1pop_version: 5processor: 5 (mc68030)processor_family: 0 (MC68K)binder_options: kcbtsmsystem_name: esuser_name: Installer.Installer


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 ModeBy 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 module’s memory—Note 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.


Using Module Mode

Request Types Used in Module ModeTable 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.

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_systemVOS Release 14.0.0l, analyze_system Release 14.0.0lCurrent process is 2039, ptep C51F5880, Joan_Smith.Publications

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


Using Module Mode

as: statusUsing 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: cbtsmas: status -briefUsing module %es#m9, booted from partition 4 on disk %es#m9

Operating system version: VOS Release 14.0.0las:

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.PublicationsProcess is running on CPU 0 right now; no stack addr known.

The VOS Program Module Memory StructureThe following sections illustrate the structure of the VOS program modules (vos.pm) for the XA/R-series and Continuum-series modules.


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_pmHeader:version: 1program_name: _PPatl_vosbinder_version: bind, Release 14.0.0release_name: VOS Release 14.0.0mpop_version: 0processor: 257 (i80860xp)processor_family: 2 (I860)...Section Info:

Wired address length Code 80400000 003FF010 Symtab 80C1A000 001A3DA4 Static 80800000 00026780 External 80827000 0001C72C

task_static_len: 00026780 GOT address: 00000000block_map_address: 00000000 block_map_len: 00000000

Init address length Code 80844000 00064000 Symtab 80DBE000 0001BCAC Static 808A8000 00002B40 External 808AB000 0000CD70

task_static_len: 00002B40 GOT address: 00000000 block_map_address: 00000000 block_map_len: 00000000

Paged address length Code 808B8000 00339748 Symtab 80DDA000 0011CB68 Static 80BF2000 0001DF80 External 80C10000 0000926C

task_static_len: 0001DF80 GOT address: 00000000 block_map_address: 00000000 block_map_len: 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 Module Mode

Figure 4-1. XA/R-Series VOS Program Module at Boot Time

Shared Memory Space for an XA/R-Series VOS Program ModuleUse 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.

Wired Code

Wired Internal Static

Wired External Static

Initialization Code

Initialization Internal Static

Initialization External Static

Paged Code

80400000

80800000

80827000

80844000

808A8000

808AB000

808B8000

80BF2000Paged Internal Static

Paged External Static

Wired Symbol Table

Initialization Symbol Table

Paged Symbol Table

80C10000

80C1A000

80DBE000

80DDA000


Using Module Mode

as: dump_vm_pool_info* Virtual Memory Pool *

Size FlagsStart Used Free (hex) Owner80058 8 (00008) u pcp_stack 80060 16 (00010) u I/O Heap 080070 16 (00010) u High I/O Heap 080080 32 (00020) u I/O Heap 0800A0 8 (00008) u Comm Heap800A8 288 (00120) u net_buffer_pool_p$801C8 16 (00010) u tape_buffers_p$801D8 160 (000A0) u Paged Heap 080278 2 (00002) u dump_disk_buffers_p$8027A 6 (00006) u ui_abs_pagesp$80280 192 (000C0) u Paged Heap 080340 32 (00020) u High I/O Heap 080360 3 (00003) u net_buffer_pool_p$80363 2 (00002) u Loop locks 080365 32 (00020) u High I/O Heap 080385 12 (0000C) u Streams MBLKS80391 6 (00006) u Streams Message Data80397 8 (00008) u Streams MBLKS8039F 8 (00008) u Streams Message Data803A7 2 (00002) u Loop locks 0803A9 87 (00057) f Merged Free Block8084A 64 (00040) u Paged Heap 08088A 32 (00020) u High I/O Heap 0808AA 1 (00001) f Merged Free Block80C1A 64 (00040) u Paged Heap 080C5A 608 (00260) u High I/O Heap 080EBA 64 (00040) u Paged Heap 080EFA 224 (000E0) u High I/O Heap 080FDA 31 (0001F) f VM Pool Virgin Storage80FF9 7 (00007) uh Idle_30 fence/stack81000 959 (003BF) u Wired Heap 0813BF 9 (00009) u pmes for 800-817 MB813C8 20 (00014) u aptes for 800-813 MB813DC 36 (00024) u mme array(s) for 000-017 MB81400 188 (000BC) u aptes for 814-8CF MB814BC 69 (00045) u pmes for 818-8CF MB81501 156 (0009C) u mme array(s) for 018-07F MB...8B69E 18 (00012) u telnet_al.cp.pm8B6B0 28 (0001C) f Merged Free Block8B6CC 49 (00031) u sos.pm8B6FD 37 (00025) f Merged Free Block8B722 12 (0000C) u async_al.cp.pm8B72E 22 (00016) f Merged Free Block8B744 11 (0000B) u mpx_gcomm.pm8B74F 3 (00003) f Merged Free Block8B752 9 (00009) u mpx_gcomm.pm8B75B 13 (0000D) f Merged Free Block


Using Module Mode

8B768 33 (00021) u vterm.pm...8CC20 65 (00041) u tcp.pm8CC61 153 (00099) uh cache_manager_pages8CCFA 16 (00010) u tcp_kll.pm8CD0A 25 (00019) uh cache_manager_pages8CD23 50 (00032) u dkux.pm8CD55 21 (00015) uh cache_manager_pages 8CD6A 13 (0000D) u dlmux.pm8CD77 90 (0005A) uh cache_manager_pages8CDD1 15 (0000F) u gdl.pm8CDE0 17 (00011) uh cache_manager_pages8CDF1 3 (00003) u timod.cp.pm8CDF4 503 (001F7) uh cache_manager_pages8CFEB 7 (00007) uh Idle_29 fence/stack8CFF2 7 (00007) uh Idle_28 fence/stack8CFF9 7 (00007) uh Idle_31 fence/stack ------ ------Total 8256 42927

Used 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.


Using Module Mode

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.

Wired Code

Wired Static

Wired Heap (Was Initialization Code)


Paged Code

80400000

80800000

80844000

8089C000

808B8000

80BF2000

Paged Static

Virtual Memory Pool

80058000

Virtual Memory Pool

80C1A000

Reserved Kernel Tables80000000

BFFFF000


Using Module Mode

as: display_pm

Header:

version: 1program_name: _PPg80_vosbinder_version: bind, Release 14.0.0release_name: VOS Release 14.0.0lpop_version: 0processor: 769 (pa8000)processor_family: 4 (HPPA)binder_options: kcbtsm...Section Map:

wired 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: 00000000 block_map_address: C06FC3F8 block_map_len: 00069A98

initialization address length file address Code C0925000 0005C680 008D9000 Symtab C0C9F000 0001B506 00C53000 Static C0982000 00003100 00936000 External C0986000 000003E4 0093A000

task_static_len: 00003100 GOT address: 00000000 block_map_address: C0980000 block_map_len: 00001680

paged address length file address Code C0925000 00000000 008D9000 Symtab C0C9F000 00000000 00C53000 Static C0925000 00000000 008D9000 External C0925000 00000000 008D9000

task_static_len: 00000000 GOT address: 00000000 block_map_address: 00000000 block_map_len: 00000000

maps address length file address Code FFFFE000 00000000 00D42000 Symtab C0D10000 000AB446 00D42000 Static FFFFE000 00000000 00D42000 External FFFFE000 00000000 00D42000



Using Module Mode

physical_wired address length file address Code 00220000 0001EF30 00002000 Symtab C0987000 0000A840 0093B000 Static 0023F000 00000850 00021000 External 00240000 00002D04 00022000

task_static_len: 00000850 GOT address: 00000000 block_map_address: 0023DA28 block_map_len: 00001508

physical_initialization address length file address Code 00260000 000026E0 00025000 Symtab C0992000 00001736 00946000 Static 00263000 00000110 00028000 External 00264000 000000D6 00029000

task_static_len: 00000110 GOT address: 00000000 block_map_address: 00262508 block_map_len: 000001D8

wired_batc address length file address Code C0766000 00044000 00790000 Symtab C0C9D000 000000B0 00C51000 Static C0894000 0006C000 00868000 External C0900000 00000000 008D4000

task_static_len: 0006C000 GOT address: 00000000 block_map_address: 00000000 block_map_len: 00000000

gateways address length file address Code C0920000 000042D8 008D4000 Symtab C0C9E000 000003F8 00C52000 Static C0925000 00000000 008D9000 External C0925000 00000000 008D9000

task_static_len: 00000000 GOT address: 00000000 block_map_address: C0924210 block_map_len: 000000C8

temporarily_wired address length file address Code C0925000 00000000 008D9000 Symtab C0C9F000 00000000 00C53000 Static C0925000 00000000 008D9000 External C0925000 00000000 008D9000



Using Module Mode

programmed_operators address length file address Code FFF80000 000468F0 00CC4000 Symtab C0CBB000 00053916 00C6F000 Static FFFC7000 0000A0C0 00D0B000 External FFFD2000 00001510 00D16000

task_static_len: 0000A0C0 GOT address: 00000000 block_map_address: FFFC1800 block_map_len: 000050F0

pop_batc address length file address Code FFFD4000 00029800 00D18000 Symtab C0D0F000 00000074 00CC3000 Static FFFFE000 00000000 00D42000 External FFFFE000 00000000 00D42000


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.


Using Module Mode

Figure 4-3. Continuum-Series VOS Program Module at Boot Time

Shared Memory Space for a Continuum-Series VOS Program ModuleUse 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

Wired Code


Wired External Static

Initialization Code

Initialization Internal Static


C0000000

C0800000

C085B000

C0925000

C0982000

C0986000

Wired Symbol TableC0994000

C0C9F000Initialization Symbol Table

Virtual Memory Pool

Programmed-Operator (POP) Code

POP Internal Static

POP External Static

FFF80000

FFFC7000

FFFD2000

C0894000

C0987000

C0CBB000


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: dump_vm_pool_info

* Virtual Memory Pool * Size FlagsStart Used Free (hex) OwnerC0925 8 (00008) u Loop locks 0C092D 12 (0000C) u Streams MBLKSC0939 6 (00006) u Streams Message DataC093F 8 (00008) u Streams MBLKSC0947 8 (00008) u Streams Message DataC094F 48 (00030) u Loop locks 0C097F 7 (00007) f Merged Free BlockC0987 8 (00008) u pcp_stackC098F 8 (00008) u Comm HeapC0997 288 (00120) u net_buffer_pool_p$C0AB7 2 (00002) u dump_disk_buffers_p$C0AB9 7 (00007) f Merged Free BlockC0AC0 32 (00020) u I/O Heap 0C0AE0 16 (00010) u tape_buffers_p$C0AF0 96 (00060) u I/O Heap 0C0B50 352 (00160) u Paged Heap 0C0CB0 352 (00160) u I/O Heap 0C0E10 64 (00040) u Paged Heap 0C0E50 128 (00080) u I/O Heap 0C0ED0 64 (00040) u Paged Heap 0C0F10 64 (00040) u I/O Heap 0C0F50 128 (00080) u Paged Heap 0C0FD0 8 (00008) u Loop locks 0C0FD8 1 (00001) f VM Pool Virgin StorageC0FD9 7 (00007) uh Idle_0 fence/stackC1000 2936 (00B78) u Wired Heap 0C1B78 12 (0000C) u pmes for C00-C1F MBC1BA0 96 (00060) u mme array(s) for 000-03F MBC1C00 980 (003D4) u aptes for C1C-FEF MBC1FD4 366 (0016E) u pmes for C20-FEF MBC2142 2208 (008A0) u mme array(s) for 040-5FF MBC29E2 24 (00018) u Loop locks 0C29FA 6 (00006) f Merged Free Block...FEFED 7 (00007) uh Idle_1 fence/stackFEFF4 3 (00003) f Merged Free BlockFEFF7 3 (00003) uh cache_manager_pagesFEFFA 1 (00001) f disk_io_blockFEFFB 1 (00001) uh cache_manager_pagesFEFFC 1 (00001) f cache_manager_pages...

------ ------Total 29039 226635 Used Free


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.

Figure 4-4. Sample Continuum-Series VOS Virtual Memory Pool

Virtual Memory Pool


C0000000

C0800000

C0986000

Virtual Memory PoolC1161000

Programmed-Operator (POP) Code

POP Internal Static

POP External Static

FFF80000

FFFC7000

FFFD2000

Wired Code


Wired External StaticC0894000

C085B000

C0925000

C0987000


Using Partition Mode

Ranges of Virtual Addresses in User Process SpaceVirtual 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.

Using Partition ModeThe 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_labelboot1 boot 000065 000002boot2 boot 000067 000002boot3 boot 000069 000002boot4 boot 00006B 000002boot5 boot 00006D 000002boot6 boot 00006F 000002boot7 boot 000071 000002boot8 boot 000073 000002Boot disk Flags: monitor_terminal,auto_boot,no_software_purchased,has_b+ad_blk_part,using_bd_bitmap Default boot partition: 4as: use_partition 4VOS Release 14.0.0l, analyze_system Release 14.0.0las: statusUsing partition 4 on disk %es#m9Operating 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

Table 4-3. Virtual Address Ranges in User Process Space

Module SeriesAddress 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 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: cbtsmas: display sys_info$max_wait_events 2C0877450 0 0100 |.. |as: display sys_info$module_id 2C0880C86 0 0000 |.. |as: display sys_info$release_version 32C0880D00 00 7379735F 696E666F 2472656C 65617365 |sys_info$release|C0880D10 10 5F766572 73696F6E 206E6F74 20736574 |_version not set|as:

Using Program Module (File) ModeProgram 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 ModeUse 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


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.


Chapter 5Requests That Provide

Metering Information5-

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 MetersThe 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 metersSee 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_channelsChannel name S C User UART Interrupts Input OutputOC17 4 0 0700 4 0 379term.17.0.2 4 1 0000 1 0 0tape.17.0 not asynchronous.tape.17.1 not asynchronous.term.17.12.1 4 192 0500 2 0 0term.17.12.2 4 193 0500 1 0 0term.17.12.3 4 194 PreLogin 0700 305 137 28874term.17.12.4 4 195 PreLogin 0700 173 84 4023enet.17.13 not asynchronous.

as: dump_channels -meterChannel name Ichars Ochars Locks Breaks Dialups IntsOC17 0 379 10 0 2 4term.17.0.2 0 0 2 0 0 1tape.17.0 not asynchronous.tape.17.1 not asynchronous.term.17.12.1 0 0 3 0 0 2term.17.12.2 0 0 2 0 0 1term.17.12.3 137 28874 967 0 3 305term.17.12.4 84 4023 334 0 3 173enet.17.13 not asynchronous.


Types of Meters

Requests That Contain All Meter FieldsThe 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_usageUsage statistics, VOS Release 14.0.0l

----CPU----- Last Min Last 5 Min Last Hour All 677.6 hoursCPU minutes 0.20 10.2% 2.40 24.0% 5.72 4.8% 8197.48 10.1%Min at PF 0.01 0.6% 0.05 0.5% 0.11 0.1% 85.46 0.1%Idle 1.78 89.2% 7.49 74.9% 113.98 95.0% 72618.68 89.3%Other 0.00 0.0% 0.00 0.0% 0.00 0.0% 0.00 0.0%

--I/O Rates--Page faults,/sec10548 176 35050 117 75882 21.1 65956148 27.0File IO, /sec 6213 104 22373 74.6 51941 14.4 65457184 26.8Disk IO, /sec 6373 106 34463 115 80952 22.5 72995175 29.9

--INT Rates--Ints, /sec 26952 449 177663 592 1345063 374 1146376572 470Int. Time 0.02 0.9% 0.12 1.2% 0.55 0.5% 519.20 0.6%as:


Resetting Meters

Requests That Contain Some Meter FieldsMany 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_ptePTE 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: 0as: match page_fault;dump_ptePTE 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: 0as:

Resetting MetersBy 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


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_metersTotal metering time -- 3:49:53

Count /sec %l/flock all 0 0 0.00lock dctl 48910172 3546 2.53lock cs q 0 0 0.00lock dq 0 0 0.00

as: disk_lock_meters -reset -no_report; sleep -minutes 1

as: disk_lock_metersTotal metering time -- 0:01:11

Count /sec %l/flock all 0 0 0.00lock dctl 156894 2209 1.04lock cs q 0 0 0.00lock dq 0 0 0.00as:

Using a Meter FileBy 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.


Resetting Meters

The following example shows the process and result of deleting the file as_meter_file.

as: ..delete_file (home_dir)>as_meter_filedelete_file: The file is in use. %es#m24_user>Eng>Joe_Smith>as_meter_fileas: quitready 13:19:26delete_file (home_dir)>as_meter_fileready 13:19:36analyze_systemVOS Release 14.0.0l, analyze_system Release 14.0.0lCurrent process is 2039, ptep C51F5880, Joe_Smith.Engas: disk_lock_metersTotal metering time -- 677:37:55

Count /sec %l/flock all 0 0 0.00lock dctl 328568448 134 0.00lock cs q 0 0 0.00lock dq 0 0 0.00as:


Chapter 6Requests That Display and

Change Memory6-

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 MemoryUse 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 MemoryUse 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_addressSpecifies 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: processUsing process on CPU28.Current process is 1176, ptep 8175B440, Joseph_Smith.EngProcess is running on CPU 28 right now; no stack addr known.as: display 8175B4408175B440 0 01118498 |.... |as: match process_number;dump_ptePTE at 8175B440 for Joseph_Smith.Eng (login) process_number: 1176as: ..display_line (hexadecimal (calc 8 * 1176))24C0xas: display ‘((perm_process_datap$)+24C0)’ 168175B440 0 01118498 000B4461 76655F4D 61727469 |......Joseph_Smi|as:

* n_bytesSpecifies 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 168175B440 0 01118498 000B4461 76655F4D 61727469 |......Joseph_Smi|as: display 8175B440 108175B440 0 01118498 000B4461 7665 |......Jose |as: display 8175B440 10d8175B440 0 01118498 000B4461 7665 |......Jose |as: display 8175B440 10x8175B440 0 01118498 000B4461 76655F4D 61727469 |......Joseph_Smi|as: display 8175B440 10o8175B440 0 01118498 000B4461 |......Jo |as: display 8175B440 10b8175B440 0 0111 |.. |as:

* -no_hexDoes 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_hex8175B440 00 |......Joseph_Smit.......................Eng....|as:



* -ebcdicDisplays characters in EBCDIC instead of ASCII. The following example illustrates the use of this argument.

as: display 8175B440 16 -ebcdic8175B440 0 01118498 000B4461 76655F4D 61727469 |..dq.../..^(/...|as:

* -control_charsDisplays the codes for nonprinting characters instead of periods. The following example illustrates the use of this argument.

as: display 8175B440 16 -control_chars SD N8175B440 0 01118498 000B4461 76655F4D 61727469 |OC..UVJoseph_Smi| H1 LTas:

* -physicalCauses 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 400000 1600400000 0 63D0152C 002267CC 152D0022 6AE41530 |c..,.”g..-.”j..0|as: display 400000 16 -physical00400000 0 A0000000 45E0F000 00000000 A0000000 |....E...........|as:

Displaying Formatted Data in MemoryNearly 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.



• 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__listener809FF600 at s__listeneras:

Displaying Values in External VariablesYou 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_varsdisplay_pm -external_vars_map..detach_default_outputas: ..display vos_external_vars -match sys_info$mod -min_lines 2

%sys#m2_user>Eng>Joe_Smith>vos_external_vars 95-06-13 13:03:23 EDT

sys_info$module_id 1 80839B44 00000002

sys_info$module_name 1 80839B50 00000022sys_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 sys_info$module_id 280839B44 0 0111 |.. |as: display sys_info$module_name 22x80839B50 00 00036D31 37300000 00000000 00000000 |..m170..........|80839B60 10 00000000 00000000 00000000 00000000 |................|80839B70 20 0000 |.. |as: display sys_info$module_no 280839B72 0 0011 |.. |


Changing Memory

Changing MemoryA number of analyze_system requests enable you to change values in VOS memory.

C A U T I O N

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 200A8A000 0 4841 |HA |as: set_word a8a000 9999 -check 0set_word: 00A8A000 4841 should be 0000 --- check failed.as: set_word a8a000 9999 -check 4841addr from to00A8A000 4841 9999


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 200A8A000 0 9999 |.. |as: set_byte A8A000 48 41 -check 99 99addr fm to00A8A000 99 4800A8A001 99 41as: display a8a000 200A8A000 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 1addr from to80C10E94 00000001 00000000as: set_longword recovery_wait$ 1 -check 0addr from to80C10E94 00000000 00000001as:

Requests That Change Specific Areas of MemoryMany 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_switchdisable_faultdisable_fault_insertiondisable_timer_faultedit_vm_sizesenable_faultenable_fault_insertionenable_timer_faultset_board_thresholds

set_comm_thresholdsset_dq_debug_modeset_dq_defaultsset_instructionset_lap_traceset_net_timeoutset_paramset_wordupdate_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: change_iop_dump_switch 22 DEVICE_ONLY -ioa_slot 1as: dump_syserr -last 6



16:40:59 Joe_Smith.Eng patched location 80839C30 (ptep=817277C0)16:40:59 0003 -> 000016:40:59 ***** Security Log Message *****16:40:59 Joe_Smith.Eng patched location 80C3458C (ptep=817277C0)16:40:59 3FEA9250 -> 0060646816:40:59 000C0000 -> 0000000015:14:46 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 ModulesWhen 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


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 168052AA30 A0000000 nop8052AA34 16110061 ld.l +96(r16),r178052AA38 16120069 ld.l +104(r16),r188052AA3C 40000800 bri

as: display * 168052AA30 0 16110061 A0000000 400000800 16120069as:

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.


Chapter 7Requests That Display

Process Information7-

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 ProcessesThe 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 USER NAME 1 80C11540 CPU28.Idle (Idle_28) 3 80EBB560 Cache_Manager_Post.System (Cache_Manager_Post) 4 80EBE720 Cache_Manager_Timer.System (Cache_Manager_Timer) 5 80EC1720 Cache_Manager_Locker.System (Cache_Manager_Locker) 6 80EC75E0 CPU29.Idle (Idle_29) 7 80EC7AA0 CPU26.Idle (Idle_26), on CPU26....as:

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 USER NAME*3336 8151D700 Joe_Smith.Eng, on CPU28 3375 819EB9E0 Joe_Smith.Engas:

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.Engas:

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 (TPOverseer) 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) 68 81470B20 Overseer.System (NetworkWatchdog) 69 81477000 Overseer.System (TheOverseer) 70 8147B080 Overseer.System (BatchOverseer) 74 80F3C0C0 Overseer.System (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 NumberYou 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 8151D700PTE at 8151D700 for Joe_Smith.Eng (login) process_number: 3336as:

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


Listing Processes

The following table describes each element of the process ID.

You can derive the decimal process number from the process ID as shown in the following example.

as: match process_id; dump_pte 8151D700PTE at 8151D700 for Joe_Smith.Eng (login) process_id: 0111EDO8as: ..display_line (decimal 2D08x)3336as:

Finding a ProcessThe 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 ProgramUse 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:

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)

U A two-bit unique number (0 to 3 decimal)

PPP The process number in hexadecimal, 001 to 3FFFx (1 to 16,383 decimal)


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 FileUse 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: 04C378A0as: match ref; dump_afte ex_file ref count: 1as: match process; dump_fi 04C378A0 Process ID 011451F6as: match fp; dump_fi 04C378A0 fp 00000001as: ..display_line (decimal 1F6x)502as: process 1F6xUsing nonrunning process.Current process is 502, ptep 4104C410, Joe_Smith.Engas:

Finding a Process That Is Waiting on an EventUse 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 module’s 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 -longAll nonfree ETEs:ETE at 04A4F180 for %sys#m2_user>Eng>Joe_Smith>program_eventwait_list: 005A074C -> 04B16760: Joe_Smith.Eng (t6.3)wait_list: 007566FC -> 04B0AAA0: Mike_Smith.Eng (t6.2)


Listing Processes

lock: 8000....as: match process_number; dump_pte 04B0AAA0process_number: 133

as:

Finding a Process That Is Using a DeviceUse 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 stratanetprocess_id: 0D012042 (Overseer)

as:

Determining the State of a ProcessYou 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 CPU29Process is running on CPU 26 right now; no stack addr known.No frame address for process 7, CPU26.Idle on CPU26Process is running on CPU 27 right now; no stack addr known.No frame address for process 8, CPU27.Idle on CPU27Process is running on CPU 30 right now; no stack addr known.No frame address for process 9, CPU30.Idle on CPU30Process 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:


Selecting a Process

Selecting a ProcessUse 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.

Displaying User Process MemoryThis section describes the organization of user virtual memory on XA/R-series and Continuum-series modules, as shown by the display_memory_usage request.

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

XA/R-Series User Process MemoryThe following output from the display_memory_usage request and Figure 7-1 shows the user virtual memory organization for XA/R-series modules.

N O T E

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 estimated

maximumnumber bytes bytes

area address of bytes used used---- -------- -------- -------- --------code 00008000 00317C08internal static 00320000 00041608external static 00362000 000055A8symbol table 00368000 000DC5E8module map 004445E8 000097C2external variables map 0044DDAA 00003440link names map 004511EA 00001584link map 0045276E 000004B0entry map 00452C1E 000049D4string pool 004575F2 000008CEobject dir map 00457EC0 000000D0program module header 00457F90 00000B56user heap 00459000 00270000 001F05B0available for stack or heap growth 006C9000 3EFE1000process fence 3F6AA000 00008000user_stack 3F6B2000 007F7000 0000456Cprocess heap 3FEAA000 00080000 000005A0process data region heap 3FF2A000 00006000 00004BB0process data region 3FF6A000 00002000wired kernel stack fence 3FF6C000 00001000wired kernel stack 3FF6D000 00003000 00000CDDpaged kernel stack fence 3FF70000 00001000paged kernel stack 3FF71000 00008000 00004610



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.

Figure 7-1. XA/R-Series Modules User Process Space

Code00008000

Internal Static00320000

External Static00362000

Symbol Table00368000

0044445E8

User Heap—grows00459000

Process Fence3F6AA000

Available for Stack or Heap Growth00611000

User Stack—grows 3F6B2000

Process Heap3FEAA000

Process Data Region Heap3FF2A000

Process Data Region3FF6A000

Wired Kernel Stack Fence

Paged Kernel Stack Fence

Paged Kernel Stack—grows

3FF6C000

3FF70000

3FF71000

Wired Kernel Stack —grows 3FF6D000

Maps, String Pool, and Program Module Header

¦



Continuum-Series User Process MemoryThe following output from the display_memory_usage request and Figure 7-2 shows the user virtual memory organization for Continuum-series modules.

N O T E

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 estimated

maximumnumber bytes bytes

area address of bytes used used---- ------ ------ ------ --------code 00002000 00356950internal static 00359000 00069F58external static 003C3000 00005A62symbol table 003C9000 000F6C50module map 004BFC50 0000A196external variables map 004C9DE6 00004D58link names map 004CEB3E 000015C8link map 004D0106 000004B6entry map 004D05BC 00005010string pool 004D55CC 0000090Cobject dir map 004D5ED8 000000D8program module header 004D5FB0 00000B56user_stack 004D8000 007F8000 00001A50process fence 00CD0000 00008000available for stack or heap growth 00CD8000 3F176000user heap 3FE4E030 3FB26FFF 001AC380process heap 7FF2A000 00080000 000003E0process data region heap 7FFAA000 00007000 00005A30



process data region 7FFEA000 00002000paged kernel stack 7FFEC000 00008000 000037A9paged kernel stack fence 7FFF4000 00001000wired kernel stack 7FFF5000 00003000 FFFFF150wired kernel stack fence 7FFF8000 00001000

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.

Figure 7-2. Continuum-Series Module User Process Space

Code00002000

Internal Static00359000

External Static003C3000

Symbol Table003C9000

004BFC50

User Stack—grows 004D8000

Process Fence00CD0000

Available for Stack or Heap Growth00CD8000

User Heap—grows 3FE4E030

Process Heap7FF2A000

Process Data Region Heap7FFAA000

Process Data Region7FFEA000

Wired Kernel Stack Fence

Paged Kernel Stack Fence

Paged Kernel Stack—grows 7FFEC000

7FFF500

7FFF8000

Wired Kernel Stack—grows

7FFF4000

Maps, String Pool, and Program Module Header




Chapter 8Analyze System Commands

and Requests8-

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

PurposeThis command enables you to use requests that display or set values in VOS memory.

Display Form

Command-Line Formanalyze_system [-request_line string] [-module [-module_name]] [-quit] [-c_expressions]

Arguments* -request_line stringSpecifies 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.

-------------------------------- analyze_system ---------------------------------request_line: -module: -quit: no-c_expressions: no


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_expressionsSpecifies 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.

ExplanationThe 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.

ExamplesThe 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-

PurposeThis request displays the cache meters.

Display Form

Command-Line Formcache_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.

ExplanationIn 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

------------------------------- cache_meters -------------------------------------all: o-reset: no

n


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 application’s 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.

ExamplesIn 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 -minutes 1; cache_meters

Metering time: 0:01:00

Hits Misses Total

File Data 15/100.00% 0/ 0.00% 15/ 1.94%

Indirect 0/ 0.00% 0/ 0.00% 0/ 0.00%

Index Data 3/100.00% 0/ 0.00% 3/ 0.39%

Indirect 0/ 0.00% 0/ 0.00% 0/ 0.00%

Directory Data 653/ 86.49% 102/ 13.51% 755/ 97.67%

Indirect 0/ 0.00% 0/ 0.00% 0/ 0.00%

Totals 671/ 86.80% 102/ 13.20% 773

as:

The analyze_system Command and Requests 8-5

cache_meters

Related InformationFor 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).

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).


change_iop_dump_switch

change_iop_dump_switch 8-

PurposeThis request enables you to specify one of eight dump types for I/O processors and I/O adapters on a module.

Display Form

Command-Line Formchange_iop_dump_switch iop_slot[dump_type] [-ioa_slot number]

Arguments* iop_slot RequiredThe I/O processor slot number.

* 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.

-------------------------- change_iop_dump_switch --------------------------------iop_slot: dump_type: DEVICE_ONLY-ioa_slot:



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.



* -ioa_slot numberSpecifies 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.

ExplanationThe 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.

N O T E

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.

ExamplesIn 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 InformationFor information about listing existing dump switches, see the description of the list_iop_dump_switch request.


check_area

check_area 8-

PurposeThis request checks the internal structure of a heap for consistency.

Display Form

Command-Line Formcheck_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 addressThe 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.

---------------------------------- check_area ----------------------------------area_header_address: -force_address:-heap:-memory_pool: 0


check_area

* -heap heap_name <CYCLE>The heap that will be checked. The heap_name value can be one of the following:

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 poolSpecifies 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.

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))


check_area

ExplanationUse 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 block’s tag_chars field. The start of the block has the following format.

prev_size bin (31)tag_chars char (2) alignedprev_tag_chars 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.

ExamplesThere 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


free chain thread is corrupt in bucket 1

bad block address: 005D9F30 (00084F30)

block was most recently a (KC) Transaction Key Changes


check_area



bad block address: 00667978 (00112978)

block was most recently a (RR) Transaction Record Read Lock



bad block address: 0066AAB0 (00115AB0)

block was most recently a (RW) Transaction Record Write Lock



bad block address: 0056FC5E (0001AC5E)

block was most recently a (KP) Key Position


clone_command

clone_command 8-

PurposeThis request executes a single external command on nonwindow terminal devices.

Display Form

Command-Line Formclone_command command_line[-no_execute_start_up]

Arguments* command_lineThe 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.

ExplanationIf 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.

-------------------------------- clone_command ------------------------------- command_line: -execute_start_up: yes


clone_command

ExamplesIn 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 InformationSee the discussion of the login command in ‘‘Executing External VOS Commands” in Chapter 2.


delete_dump

delete_dump 8-

PurposeThis request deletes a file containing a dump image.

Display Form

Command-Line Formdelete_dump dump_number[-path_name dump_path_name]

Arguments* dump_numberA 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_nameThe 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.

ExplanationIf 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.

----------------------------------- delete_dump --------------------------------dump_number: -path_name:


delete_dump

ExamplesIn 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_dumpsDumps 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.dumpas: delete_dump 1

C A U T I O N

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


disassemble

disassemble 8-

PurposeThis request displays a specified number of bytes of storage in assembly language format.

Display Form

Command-Line Formdisassemble [start_address] [n_bytes]

Arguments* start_addressThe 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_bytesThe number of bytes to be displayed. The default is all bytes in the requested line number.

ExplanationThe 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,

----------------------------------- disassemble --------------------------------start_address: n_bytes:

*


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.

ExampleIn 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 681806EAE10 E40C0001 or +1,r0,r12806EAE14 9F400000 subs +0,r26,r0806EAE18 1C7F6736 st.s r12,-202(r3)806EAE1C 7800000B bnc +48(pc) =806EAE4C806EAE20 14F50009 ld.l +8(r7),r21806EAE24 5EA00809 bte +1,r21,+40(pc) =806EAE4C


disk_lock_meters

disk_lock_meters 8-

PurposeThis request displays the disk lock meters.

Display Form

Command-Line Formdisk_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.

------------------------------- disk_lock_meters ------------------------------reset: o-report: yes

n


disk_lock_meters

ExamplesIn 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

Count /sec %l/f lock all 0 0 0.00 lock dctl 380155272 300 0.40 lock cs q 0 0 0.00 lock dq 0 0 0.00

Q runs 1156 7.87 avg ms as:

The following table describes the columns that appear in the output of the previous example.

The following table describes the fields 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.

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.


disk_lock_meters

Related InformationFor 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).


disk_meters

disk_meters 8-

PurposeThis request displays the disk meters for a specified logical disk or all disks on a module.

Display Form

Command-Line Formdisk_meters[-disk disk_name] [-reset] [-brief] [-no_report]

Arguments* -disk disk_nameThe 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.

------------------------------- disk_meters ------------------------------disk:-reset: no-brief: no-report: yes


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.

ExplanationThe 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.

N O T E

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.


disk_meters

ExamplesIn 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 -briefTotal metering time -- 0:01:01

% atb ms/ < % type > errorsbusy con con ret Nrm Rcv da dv fa dm devID drive

4 1649 61 0 100 0 0 0 0 0 04/01/01/01 m19.0.pri 4 1649 60 0 100 0 0 0 0 0 04/02/01/01 m19.0.sec

0 3588 19 0 100 0 0 0 0 0 04/01/01/04 m19_user.1.pri 0 5545 14 0 100 0 0 0 0 0 04/01/01/03 m19_user.0.prias:

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.priTotal metering time -- 0:05:39

Disk Device 04/01/01/01, m19.0.pri Count /sec ATBms BSYms %BSY Start I/O %SI/OConnects 345 1.02 983 43 4.38I/Os 894 2.64 379Interrupts 894 2.64 379 470 52.57

Average # Qd Seek /con 0.00 N/A 2.6

TotalReads 121Writes 1637

Errors (recov/fatal/dma) 0/0/0

as:


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.

(Page 1 of 2)

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.


disk_meters

Related InformationFor 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).

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.

(Page 2 of 2)

Field Description


display

display 8-

PurposeThis request displays a specified number of bytes of data in both hexadecimal and ASCII or EBCDIC characters.

Display Form

Command-Line Formdisplay [start_address] [n_bytes] [-no_hex] [-ebcdic] [-control_chars] [-physical] [-io] [-data_cache] [-instruction_cache] [-cache_tags] [-cpu_number cpu_number]

------------------------------------- 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

*


display

Arguments* start_addressThe 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_bytesThe 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 <CYCLE>* -instruction_cache <CYCLE>* -cache_tags <CYCLE>* -cpu_number cpu_numberFor engineering use only.

ExamplesIn 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


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 00 696F6E73 00000000 00000000 00000000 | ions...........|04823840 10 00000000 00000000 06008000 00000514 | ...............|04823850 20 01000005 6C6F6769 6E6F6769 6E180000 | ...loginogin...|04823860 30 00000000 00000000 00000000 | ........... |as:

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 | ions......................loginogin.|04823868 38 | .... |as:

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 80x80AB58C0 00 40404040 40404015 4040E396 40939687 |@@@@@@@.@@..@...|80AB58D0 10 969540A3 96408195 40819797 93898381 |..@..@..@.......|80AB58E0 20 A3899695 6B40A3A8 978540A3 888540D5 |....k@....@...@.|80AB58F0 30 C1D4C540 81958440 A3888595 40C5D5E3 |...@...@....@...|80AB5900 40 C5D94B15 40154040 D6C6C6C9 C3C54060 |..K.@.@@......@`|80AB5910 50 40C69699 40D6C6C6 00000000 00000000 |@...@...........|80AB5920 60 00000000 00000000 00000000 00000000 |................|80AB5930 70 00000000 00000000 00000000 00000000 |................|

as: d 80ab58c0 80x -ebcdic80AB58C0 00 40404040 40404015 4040E396 40939687 | . To log|80AB58D0 10 969540A3 96408195 40819797 93898381 |on to an applica|80AB58E0 20 A3899695 6B40A3A8 978540A3 888540D5 |tion, type the N|80AB58F0 30 C1D4C540 81958440 A3888595 40C5D5E3 |AME and then ENT|80AB5900 40 C5D94B15 40154040 D6C6C6C9 C3C54060 |ER.. . OFFICE -|80AB5910 50 40C69699 40D6C6C6 00000000 00000000 | For OFF........|80AB5920 60 00000000 00000000 00000000 00000000 |................|80AB5930 70 00000000 00000000 00000000 00000000 |................|as:


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 |.F L.UO.4F8L7.>.| S F LH S S ES N N EN00008110 10 B49902C8 08030258 E400E115 B417000A |..T.BTTX.U.A.TUL| X SXX L K BLF NS00008120 20 881C200A E8000188 341C384E 37DA3EA1 |.F L.UO.4F8N7.>.| S F LH S S ES N N00008130 30 B49902C0 08030258 E400E115 |..T.BTTX.U.A | X SXX L Kas:


display_alignment_faults

display_alignment_faults 8-

PurposeThis request displays the contents of the log created with the log_alignment_faults request.

Display Form

Command-Line Formdisplay_alignment_faults ptep[-no_brief]

Arguments* ptepDisplays 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_briefIn 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.

ExplanationThe 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

----------------------------- display_alignment_faults --------------------------ptep: -brief: yes



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.

N O T E

It is easiest to debug alignment faults generated by an executing application if that application is compiled with -table. Otherwise, the compiler’s 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 datum’s 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.



ExamplesIn 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 -resetas: ..start_process faultsas: match Joe; who *2618 81FA5880 Joe_Smith.Eng on CPU262628 81FA5440 Joe_Smith.Eng on CPU28

as: process 2628Using process on CPU28.Current process is 2628, ptep 81FA5440, Joe_Smith.EngProcess 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 InformationSee 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).


display_cache_pin_parameters

display_cache_pin_parameters 8-

PurposeThis request displays the pinning status of the disk cache.

Display Form

Command-Line Formdisplay_cache_pin_parameters

ExplanationThe 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.

ExamplesIn 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 count5 1

cache pinning switches: enabled

as:

Related InformationSee the descriptions of the set_cache_pin_parameters, dump_cache_info, and dump_cache requests.

------------------------- display_cache_pin_parameters ----------------------- No arguments required. Press ENTER to continue.


display_extensible_heap

display_extensible_heap 8-

PurposeThis 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

Command-Line Formdisplay_extensible_heap info_block_address[-heap heap_name] [-memory_pool pool]

Arguments* info_block_addressThe 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.

----------------------------- display_extensible_heap --------------------------info_block_address: -heap:-memory_pool: 0



* -heap heap_name <CYCLE>Display information about a specified extensible heap. The heap_name value can be one of the following:

You must specify a value for either this argument or the info_block_address argument. You cannot select both.

* -memory_pool poolSpecifies the memory pool from which to analyze the heap. Allowed values are 0 or 1.

ExplanationThe 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.

ExamplesIn the following example, the display_extensible_heap request displays information about the wired heap.

N O T E

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: 80C00000Lock info address: 80C12680Prealloc VM poolp: 82028FA0Allocation count: 7354475Free count: 7324287VM high address: 820F8000

Value Description




I/O The I/O heap

high_I/O The high physical memory I/O heap



Map access: 7Min pages: 1024Max pages: -1Growth per MB: 128Extend pages: 64Wired memory owner: 5Heap tag W`00No memory code: 3077Memory pool: 0Current section infoBase address: 820B8000 Num pages: 64 Num to wire: 37Last Heap Allocation Failure Info tag chars: ES caller address: 80443540 time: 00000000 02E42304

Section Begin End 1 80C00000 80FCA000 2 81398000 813D8000 3 813D8000 81418000 4 81418000 81458000 5 81458000 81498000 6 81498000 814D8000 7 81518000 81558000 8 81678000 816B8000 9 81718000 81758000....

AREA at 80C00000 (80C00000)

Next virgin: 820BC370 (014BC370)Last available: 820D2FF0 (014D2FF0)Free bytes: 001CDE20Max size: 00030F20Free limit: 001735FEDead space: 0096E180Area size: 00B64E70 (2917 pages)

as:



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


display_file

display_file 8-

PurposeThis 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

Command-Line Formdisplay_file file[-line number] [-on] [-off]

Arguments* file Required The name of a file to display.

* -line numberSpecifies the line number of the line in a file to display. The request displays this line plus the ten subsequent lines.

* -on <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.

---------------------------------- display_file ------------------------------file: -line:-on: no-off: no


display_file

N O T E

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 <CYCLE> Specifies that the file no longer be displayed.

ExplanationUse 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.

ExamplesIn 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:34 Name Sx Address Length5 ACCESS_ANY_EXEC$ 1 80839C60 000000046 ACCESS_INTERLOCK$7 1 80839C64 000000048 ACCESS_IO$ 2 8089C194 000000049 ACCESS_KERNEL_EXEC$10 1 80839C50 0000000411 ACCESS_KERNEL_READ$----------------------------------------------------------------------Current process is 295, ptep 81BA2600, Joe_Smith.Engas: dump_syserr


as: ..attach_default_output vos_evarsdisplay_pm -external_vars_map..detach_default_outputas: display_file vos_evarsas:


display_file

Related InformationFor more information about the display_file request and other requests and commands for displaying files, see Chapter 2.


display_memory_usage

display_memory_usage 8-

PurposeThis 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

Command-Line Formdisplay_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.

ExplanationThe 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

----------------------------- display_memory_usage ------------------------------decimal: no



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.

ExamplesThe 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.

estimatedmaximum

number bytes bytesarea address of bytes used used---- -------- -------- ------ -------code 00002000 0001A0E8internal static 0001D000 00004D00external static 00022000 0000001Esymbol table 00023000 0000BFE0module map 0002EFE0 000013A8external variables map 00030388 00000A50link names map 00030DD8 0000083Clink map 00031614 00000174relocation map 00031788 0000055Cstring pool 00031CE4 00000140object dir map 00031E24 00000024program module header 00031E48 00000B56user_stack 00034000 007F8000 00001CF0process fence 0082C000 00008000available for stack or heap growth 00834000 3F7C2000user heap 3FFF6030 3FFCAFFF 00002000process heap 7FF2A000 00080000 00001140process data region heap 7FFAA000 00002000 00001C70



process data region 7FFEA000 00002000paged kernel stack 7FFEC000 00008000 0000366Dpaged kernel stack fence 7FFF4000 00001000wired kernel stack 7FFF5000 00003000 FFFFF2D0wired kernel stack fence 7FFF8000 00001000as:

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_usageestimatedmaximum

number bytes bytesarea address of bytes used used---- -------- -------- -------- --------code 00E00000 0000AF32task 1 static 00E0B000 00002000task 2 static 00E0D000 00002000task 3 static 00E0F000 00002000task 4 static 00E11000 00002000task 5 static 00E13000 00002000shared static 00E15000 0000001Asymbol table 00E16000 000099F4module map 00E1F9F4 00000D96external variables map 00E2078A 0000039Clink names map 00E20B26 0000052Elink map 00E21054 000001F8relocation map 00E2124C 0000294Astring pool 00E23B96 000000D0object dir map 00E23C66 00000018program module header 00E23C7E 00000B56user heap 00E25000 00008000 00001AF0available for stack or heap growth 00E2D000 3E8F7000process fence 3F724000 00008000task 5 stack 3FEF8000 00008000 00000000task 4 fence 3FF00000 00001000task 4 stack 3FF01000 00008000 00000000task 3 fence 3FF09000 00001000task 3 stack 3FF0A000 00008000 00000000task 2 fence 3FF12000 00001000task 2 stack 3FF13000 00008000 00000000task 1 fence 3FF1B000 00001000task 1 stack 3FF1C000 00008000 0000166Bprocess heap 3FF24000 00080000 00000120process data region heap 3FFA4000 00006000 000048D0process data region 3FFE4000 00002000wired kernel stack fence 3FFE6000 00001000wired kernel stack 3FFE7000 00002000 000009B7paged kernel stack fence 3FFE9000 00001000paged kernel stack 3FFEA000 00008000 00004307



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 -decimalestimatedmaximum

number bytes bytesarea address of bytes used used---- -------- -------- -------- --------code 00E00000 44850task 1 static 00E0B000 8192task 2 static 00E0D000 8192task 3 static 00E0F000 8192task 4 static 00E11000 8192task 5 static 00E13000 8192shared static 00E15000 26symbol table 00E16000 39412module map 00E1F9F4 3478external variables map 00E2078A 924link names map 00E20B26 1326link map 00E21054 504relocation map 00E2124C 10570string pool 00E23B96 208object dir map 00E23C66 24program module header 00E23C7E 2902user heap 00E25000 32768 6896available for stack or heap growth 00E2D000 ********process fence 3F724000 32768task 5 stack 3FEF8000 32768 0task 4 fence 3FF00000 4096task 4 stack 3FF01000 32768 0task 3 fence 3FF09000 4096task 3 stack 3FF0A000 32768 0task 2 fence 3FF12000 4096task 2 stack 3FF13000 32768 0task 1 fence 3FF1B000 4096task 1 stack 3FF1C000 32768 5739process heap 3FF24000 524288 288process data region heap 3FFA4000 24576 18640process data region 3FFE4000 8192wired kernel stack fence 3FFE6000 4096wired kernel stack 3FFE7000 8192 2487paged kernel stack fence 3FFE9000 4096paged kernel stack 3FFEA000 32768 17159as:



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.



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 task’s 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.

(Page 2 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.

(Page 3 of 3)

Value Description


display_meter_file_info

display_meter_file_info 8-

PurposeThis request displays information about the current meter file, including its path name.

Display Form

Command-Line Formdisplay_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.

ExplanationThis 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.

----------------------- display_meter_file_info -----------------------long: no


display_meter_file_info

ExamplesThe 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_infoUsing: %se#eng>Test>User>as_meter_file

as: display_meter_file_info -longUsing: %se#eng>Test>User>as_meter_filepathname: %se#eng>Test>User>as_meter_filelast used: 97-01-30 14:38:05 ESTlast modified: 97-01-30 14:35:58 ESTlast saved: nevertime created: 97-01-30 14:35:58 ESTauthor: 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 user’s process directory. The process directory has the advantage of being on the same module as the user’s process, therefore eliminating network traffic. In the examples, the process directory is process_dir_dir.

as: display_meter_file_infoUsing: %test>process_dir_dir>pd.060CD29A.User>asmf

as: display_meter_file_info -longUsing: %test#>process_dir_dir>pd.060CD29A.User>asmfpathname: %test>process_dir_dir>pd.060CD29A.User>asmflast used: 97-01-30 14:48:05 ESTlast modified: 97-01-30 14:45:58 ESTlast saved: nevertime created: 97-01-30 14:38:22 ESTauthor: User.Test

Related InformationFor information about specifying the path name of the meter file, see the description of the set_meter_file request.


display_net_trace

display_net_trace 8-

PurposeThis request displays the contents of the StrataLINK net trace buffer in kernel memory.

Display Form

Command-Line Formdisplay_net_trace[-num-packets number_of_packets] [-all]

Arguments* -num-packets number_of_packetsSpecifies 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.

* -allDisplays all packets. The default is not to display all packets.

ExplanationThe 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.

------------------------------ display_net_trace -----------------------------num-packets: 0-all: no

2


display_net_trace

ExamplesIn 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 G H I J K L

0 1 S O ACPT 110 M2 nreq 18107->11001 rpt 00 tid 53BD-0000 #0001 2 1 S I NOM 92 M2 data 11005->18107 rpt 00 tid 53BD-0000 #0001 10 2 S O ACPT 334 M2 nreq 18107->11001 rpt 00 tid 53BE-0000 #0001 19 2 S I NOM 78 M2 data 11005->18107 rpt 02 tid 53BE-0000 #0001 26 1 S O ACPT 134 M2 nreq 18107->11001 rpt 00 tid 53BF-0000 #0001 29 1 S I NOM 104 M2 data 11005->18107 rpt 00 tid 53BF-0000 #0001 40 2 S O ACPT 348 M2 nreq 18107->11001 rpt 00 tid 53C1-0000 #0001 43 2 S I NOM 64 M2 data 11005->18107 rpt 00 tid 53C1-0000 #0001 49 1 S O ACPT 110 M2 nreq 18107->11001 rpt 00 tid 53C2-0000 #0001 52 1 S I NOM 138 M2 data 11005->18107 rpt 00 tid 53C2-0000 #0001 59 2 S O ACPT 110 M2 nreq 18107->11001 rpt 00 tid 53C3-0000 #0001 62 2 S I NOM 138 M2 data 11005->18107 rpt 00 tid 53C3-0000 #0001 71 1 S O ACPT 1386 M2 nreq 18107->11001 rpt 00 tid 53C4-0000 #0001 74 1 S I NOM 64 M2 data 11005->18107 rpt 00 tid 53C4-0000 #0001 82 2 S O ACPT 322 M2 nreq 18107->11001 rpt 00 tid 53C5-0000 #0001 86 2 S I NOM 50 M2 data 11005->18107 rpt 00 tid 53C5-0000 #0001 94 1 S O ACPT 174 M2 nreq 18107->11001 rpt 00 tid 53C6-0000 #0001 97 1 S I NOM 50 M2 data 11004->18107 rpt 00 tid 53C6-0000 #0001 105 2 S O ACPT 322 M2 nreq 18107->11001 rpt 00 tid 53C7-0000 #0001 108 2 S I NOM 50 M2 data 11005->18107 rpt 00 tid 53C7-0000 #0001TRACE MODE = auto_stopas:

The following table describes the columns that appear in the output of the preceding example.

(Page 1 of 4)

Column Description

A 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.

B The link or ring number, in the range from 1 to 8.

C The type of ring: subring (S) or backbone ring (B).

D The direction of data in relation to the reporting module: input (I) or output(O).


display_net_trace

E The reply status returned by VOS.NOM (no match): This value is normally traced for incoming packets becausethe trace occurs before the receiving link controller changes the packet statusto ACPT. A value NOM for an output packet trace means that no station on thering 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 board’s error retry threshold for a particular socket.DEAD: VOS is no longer running on the destination station.

F The length of the data portion of the packet.

G Possible protocol types (most frequent listed first).M2: message exchange protocol version two. The message exchangeprotocol is that used to implement most cross-module kernel services(s$ calls).FQ: fast queue protocol (direct queues)SI: station identificationNS: notify shadow protocol, cross module event notification.ME: old message exchange protocol (prior to Release 11)LD: link diagnostics protocolTI: time protocolTU: tourist protocol, used to determine network topologyTR: trace control protocolHT: hardware self test protocolBM: boom protocol, network boomerang testingTF: test traffic protocolLB: link boot protocolUK: unknown packet type (for cross-release compatibility)

H 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.

(Page 2 of 4)

Column Description


display_net_trace

H (Con’t)

wory (worry) : Sent by a client to a server when the client has not received atimely answer. If the server is currently processing the request, it ignores thewory 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 thesyserr_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 receivingstations)

(Page 3 of 4)

Column Description


display_net_trace

Related InformationFor more information on StrataLINK network tracing, see the descriptions of the monitor_net_trace and set_net_trace requests.

I 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

J The repeat switch 1 indicates software and 2 indicates hardware.

K 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.

L The sequence number of the packet for disassembly and reassembly.

(Page 4 of 4)

Column Description


display_pm

display_pm 8-

PurposeThis request displays information about the kernel program module or the user program module of the current process.

Display Form

Command-Line Formdisplay_pm name[-dates] [-external_vars_map] [-header] [-module_map] [-program_module type]

Arguments* nameThe 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.

----------------------------------- display_pm ---------------------------------name: -dates: no-external_vars_map: no-header: no-module_map: no-program_module: kernel


display_pm

* -external_vars_map <CYCLE>Displays a list of all the external variables.

* -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.

ExplanationYou should understand program module formats to interpret the output displayed by this request.

ExamplesIn 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 Date Compiled Scn Code Symtab Static UERW, SAP Start Length Start Length Start Lengthcpu_indexed_data 9 95-01-22 00:06:48 1 80403000 00000010 80B87198 00000138 808002E0 00000008

Module Map Dates:

Name DTM DTCPcpu_indexed_data 95-01-22 01:06:56 95-01-22 00:06:48as:

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.


display_pm

as: display_pm -dates

Module Map Dates:

Name DTM DTCPwrite_once_section_begin 95-01-22 01:01:09 95-01-21 23:37:33write_once_variables 95-03-15 14:52:22 95-03-15 14:51:35write_once_section_over 95-01-22 01:01:11 95-01-21 23:37:39atlantic_dump_mem 95-01-22 00:56:55 95-01-21 23:20:29setup_dump_mem 95-01-22 00:59:25 95-01-21 23:30:22dump_mem_utils 95-01-22 00:56:58 95-01-21 23:21:14cpu_indexed_data 95-01-22 01:06:56 95-01-22 00:06:48powerfail_recovery 95-03-15 14:42:46 95-03-15 14:37:06reconfigure_cpu 95-03-03 22:11:51 95-03-03 21:28:21....as:


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 Date Compiled Scn Code Symtab Static UERW, SAP Start Length Start Length Start Lengthwrite_once_section_begin 95-01-21 23:37:33 1 80400000 00000010 80B86000 0000007E 80800000 00000008write_once_variables 95-03-15 14:51:35

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


display_pm

1 80400010 00000010 80B86080 000003CA 80800010 00000230write_once_section_over 95-01-21 23:37:39 1 80400020 00000010 80B86450 0000007E 80800240 00000008atlantic_dump_mem 95-01-21 23:20:29 1 80400030 00002038 80B864D0 00000C30 80800250 00000084setup_dump_mem 95-01-21 23:30:22 1 80402070 00000180 80B87100 00000060 808002E0 00000000dump_mem_utils 95-01-21 23:21:14 1 804021F0 00000070 80B87160 00000034 808002E0 00000000cpu_indexed_data 95-01-22 00:06:48 1 80403000 00000010 80B87198 00000138 808002E0 00000008powerfail_recovery 95-03-15 14:37:06 1 80403010 000012F0 80B872D0 00001058 808002F0 00000044....as:


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 LengthACCESS_ANY_EXEC$ 1 80839C60 00000004ACCESS_INTERLOCK$ 1 80839C64 00000004ACCESS_IO$ 2 8089C194 00000004ACCESS_KERNEL_EXEC$ 1 80839C50 00000004ACCESS_KERNEL_READ$ 1 80839C48 00000004ACCESS_KERNEL_WRITE$

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

UERWSAP

Obsolete in VOS 14.x


display_pm

1 80839C4C 00000004ACCESS_USER_EXEC$ 1 80839C5C 00000004ACCESS_USER_READ$ 1 80839C54 00000004ACCESS_USER_WRITE$ 1 80839C58 00000004CMD_free_cb_ack_timeout 1 8082F210 00000004CMD_lock_debug$ 1 8082F214 00000002....as:

In the following example, the display_pm request displays the program module header.

as: display_pm -header

Header:

version: 1program_name: atl_vos.0binder_version: bind, Release 13.0.1ajrelease_name: VOS Release 13.0.1ampop_version: 0processor: 257 (i80860xp)processor_family: 2 (I860)binder_options: kcbtsmsystem_name: esuser_name: Installer.Installerdate_bound: 95-03-15 20:59:27 EDTmain_ep.code_addr: 80841010main_ep.static_addr: 00000000user_boundary: 80400000max_heap_size: 00000000max_program_size: 01000000max_stack_size: 00000000stack_fence_size: 00001000n_modules: 1753n_external_vars: 1898n_link_names: 0n_unsnapped_links: 0n_entries: 8652n_vm_pages: 3093n_header_pages: 1n_relocations: 0module_map_address: 0047F4A0module_map_len: 0001FABAext_vars_map_address: 0049EF80ext_vars_map_len: 00014638link_names_map_address: 80E630F2link_names_map_len: 00000000


display_pm

link_map_address: 80E630F2link_map_len: 00000000entry_map_address: 004B35E0entry_map_len: 00058B78header_address: 0045EDC0header_len: 00000B56relocation_map_address: 80EBBC6Arelocation_map_len: 00000000high_water_mark: 00000000string_pool_address: 80EBBC6Astring_pool_len: 000006E8obj_dir_map_address: 80EBC352obj_dir_map_len: 000000CCsection_map_file_address:00000000section_map_address: 00000000section_map_len: 00000000n_sections: 0flags: multisection_referencesn_tasks: 1stack_len: 00008000copyright_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 address length Code 80400000 003FF010 Symtab 80B86000 0019AFEC Static 80800000 00022F60 External 80823000 0001836C

task_static_len: 00022F60 GOT address: 00000000 block_map_address: 00000000 block_map_len: 00000000

Init address length Code 8083C000 0005D000 Symtab 80D21000 0001A9AC Static 80899000 000028B0 External 8089C000 0000C3D0

task_static_len: 000028B0 GOT address: 00000000 block_map_address: 00000000 block_map_len: 00000000


display_pm

Paged address length Code 808A9000 002B6CC8 Symtab 80D3C000 000F2AB8 Static 80B60000 0001CD60 External 80B7D000 00008FDC

task_static_len: 0001CD60 GOT address: 00000000 block_map_address: 00000000 block_map_len: 00000000as:


display_process_info

display_process_info 8-

PurposeThis request displays information about the analyzed process.

Display Form

Command-Line Formdisplay_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.

------------------------------ display_process_info -----------------------------pdr: es-tdr: no-full: no

y



ExplanationThe 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.)

ExamplesIn the following example, the process request displays the current process and then the display_process_info request displays information about the current process.

as: processUsing process on CPU26.Current process is 4076, ptep 81CEA000, Joe_Smith.EngProcess is running on CPU 26 right now; no stack addr known.as: display_process_info

PDR @ 3FF6A000

Flags: use_abbreviations have_run_start_up have_ready_text default_message_file banner_displayed pad2 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



lpt_ptr 3FF2BA60 mail_info_ptr 00000001 mp_debug_info_ptr 00000001 normal_cli_ptr 3FF2B4C0 pdr_heap_ptr 3FF2A000 pick_pib_ptr 00000001 pmh_ptr 00457F90 process_heap_ptr 3FF2A060 pte_ptr 81CEA000

rawfile_pool_ptr 00000001 rawfile_table_ptr 00000001 stack_base 3FEAA000 system_access_list_ptr 00000001 temp_file_ptr 00000001 tdr_ptr 00459060 user_heap_ptr 00459000 user_pi_mask_count_ptr 3FF29FE0 vc_events_ptr 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 XX current_dir %sys#m2_user>Eng>Joe_Smith event_path home_dir %sys#m2_user>Eng>Joe_Smith owner_access_group owner_access_person groups(1) Eng process_dir ready_msg_text ready subsystem



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 -tdrTDR @ 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 1 @00459520 ready wait_list unready_list

Tasks: Num State saved_a6 term tid / abort reason

1 ready 3FEA9F60 5 00000000-0000-0000 0as:



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 -fullTDR @ 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 1 @00459520 ready wait_list unready_list

TDRE @ 00459520

Task 1: task_id 1 links: 00459528: 00000001 004590A0 00000001 004590A0 state ready priority 0 n_fence_pages 0 task_alloc_ptr 00000001 fence_ptr 3FEA1000 saved_a6 3FEA9F60 task_stack_base 3FEAA000 task_stack_len 32768 task_static_ptr 00320000 task_static_len 267784

task port (1) 1 task port (2) 2



task port (3) 3 task port (4) 4 task port (5) 5 accept_info_ptr 00000001 cpu_time 0 page_faults 0 tid 00000000-0000-0000 transaction abort reason 0 wait_info.event_index 0 wait_info.event_count 0 wait_info.code 0 epilogue_handlers s_pl1_stop+104, line 64as:


display_security_info

display_security_info 8-

PurposeThis request displays information about security logging for the current module.

Display Form

Command-Line Formdisplay_security_info

ExplanationSecurity logging can be turned on or off using the security_admin command, documented in the manual VOS System Administration: Registration and Security (R283).

ExamplesIn the following example, the display_security_info request displays security data for the analyzed module.

as: display_security_info log_buffer_busy: trueseq_no: 5672security_lock: 80177AE0time_stamp: 1C70D427 (95-06-19 10:59:13 EDT)security_log_bufferp: 80BAD280audit events: security

------------------------------display_security_info-----------------------------No arguments required. Press ENTER to continue.


display_security_info

The following table describes the fields that appear in the output of the preceding example.

Related InformationFor 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).

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.


display_system_usage

display_system_usage 8-

PurposeThis request displays information about system usage for the analyzed module.

Display Form

Command-Line Formdisplay_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.

ExplanationThe 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.

------------------------------ display_system_usage -----------------------------long: on



Note that you can obtain similar, but not precisely the same amount of, system usage information with the display_system_usage command.

ExamplesIn 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----- Last Min Last 5 Min Last Hour All 3.2 hoursCPU minutes 1.46 29.2% 7.28 29.0% 95.02 31.6% 265.75 27.4%Min at PF 0.02 0.4% 0.05 0.2% 0.47 0.2% 1.68 0.2%Idle 2.52 50.3% 13.31 53.1% 130.80 43.5% 497.88 51.3%Other 0.13 2.7% 0.61 2.4% 11.48 3.8% 38.89 4.0%

--I/O Rates--Page faults,/sec 344 5.7 758 2.5 8221 2.3 24895 2.1File IO, /sec 446 7.4 2253 7.5 27125 7.5 315954 27.2Disk IO, /sec 460 7.7 2433 8.1 27883 7.7 321854 27.7

--INT Rates--Ints, /sec 28963 483 129138 429 1939322 538 5084689 437Int. Time 0.87 17.5% 3.82 15.2% 62.72 20.9% 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 -longUsage statistics, VOS Release 13.1

----CPU----- Last Min Last 5 Min Last Hour All 3.2 hoursCPU minutes 1.46 29.2% 7.28 29.0% 95.02 31.6% 265.96 27.4% User procs 0.16 3.2% 1.42 5.7% 14.13 4.7% 47.77 4.9% System procs 0.06 1.1% 0.40 1.6% 8.18 2.7% 27.97 2.9% Server procs 1.24 24.9% 5.47 21.8% 72.72 24.2% 190.21 19.6%

Min at PF 0.02 0.4% 0.05 0.2% 0.47 0.2% 1.69 0.2% User procs 0.02 0.4% 0.05 0.2% 0.47 0.2% 1.58 0.2% System procs 0.00 0.0% 0.00 0.0% 0.00 0.0% 0.07 0.0% Server procs 0.00 0.0% 0.00 0.0% 0.00 0.0% 0.03 0.0%

Idle 2.52 50.3% 13.31 53.1% 130.80 43.5% 498.07 51.3%Other 0.13 2.7% 0.61 2.4% 11.48 3.8% 38.91 4.0%

--I/O Rates--Page faults,/sec 344 5.7 758 2.5 8221 2.3 24911 2.1 User procs 344 5.7 757 2.5 8188 2.3 23809 2.0



System procs 0 0.0 0 0.0 2 0.0 711 0.1 Server procs 0 0.0 1 0.0 31 0.0 391 0.0

File IO, /sec 446 7.4 2253 7.5 27125 7.5 315996 27.1Disk IO, /sec 460 7.7 2433 8.1 27883 7.7 321899 27.7

--INT Rates--Ints, /sec 28963 483 129138 429 1939322 538 5087543 437Int. Time 0.87 17.5% 3.82 15.2% 62.72 20.9% 165.46 17.1%as:

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.

Related InformationFor more information about the display_system_usage command, see the manual VOS Commands Reference Manual (R098).

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


dump_adt

dump_adt 8-

PurposeThis 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

Command-Line Formdump_adt entry_name[-dir] [-file] [-hash_table] [-all_entries] [-header] [-unused] [-brief] [-mod_blocks] [-queue_entries]

------------------------------------ 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


dump_adt

Arguments* entry_nameAn 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 <CYCLE>Displays the hash table of the active directory table.

* -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.


dump_adt

ExplanationFour 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.


dump_adt

ExamplesIn 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 81643A9C 816993A0 816993DC mod_phy_list: 817086F8: 81759740 8175977C 81759740 8175977C pcommit_links: 81708708: 00000001 00000001 00000001 00000001 req_wait_list: 81708718: 00000001 81708718 00000001 81708718 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


dump_adt

uid_hash_fp: 80BB54C0 dt_modified: 95-02-08 11:35:03 EST common flags: data_used....as:

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 REF INF NAME 1 82657BE0 0 0 %sys#libs>r13.01>base>os>global>tables 1 826573C0 0 0 %sys#libs>r13.01>fixes>os>global>tables 1 82656BA0 0 0 %sys#libs>r13.01>base>os>tables 1 8241EEE0 0 0 %sys#libs>r13.01>fixes>os>tables 1 8214BD60 0 1 %sys#m1_more>postoffice>ship_to_dir>irvine 1 8214AA20 0 1 %sys#m1_more>postoffice>ship_to_dir>phx 1 82149B00 0 1 %sys#m1_more>postoffice>ship_to_dir>ams 1 82149140 0 1 %sys#m1_more>postoffice>ship_to_dir>stl 1 82148440 0 1 %sys#m1_more>postoffice>ship_to_dir>sydney 1 82147400 0 1 %sys#m1_more>postoffice>ship_to_dir>atl 1 816C5F60 0 1 %sys#libs>r13.01>base>tcp_os>100 1 8216A200 0 1 %sys#libs>r13.01>base>swd>tables 2 816DD480 0 0 %sys#libs>testing>t2>wtm 2 80B97080 0 2 %sys#libs>r13.01>fixes>wtm 2 82088B60 0 0 %sys#libs>r13.0>fixes 2 8214A1C0 0 1 %sys#m1_more>postoffice>ship_to_dir>la 2 824298A0 0 1 %sys#m1_more>postoffice>ship_to_dir>tor 2 80BB0040 0 3 %sys#libs>r13.01>base>wtm 2 80B82940 0 5 %sys#libs>r13.01>fixes 3 81CA6880 0 0 %sys#m1_more>postoffice>ship_to_dir>es>m111....as:


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 NAME 1 820E0C40 ADTE %sys#sc3>products>tcp_os>12.2-5 1 820E0900 ADTE %sys#sc3>products>tcp_os>12-32 1 820DF0C0 ADTE %sys#m1_more>postoffice>ship_to_dir>cmh>m1 1 820DEF20 ADTE %sys#m1_more>postoffice>ship_to_dir>irvine>m1 1 82661340 ADTE %sys#m1_more>postoffice>ship_to_dir>wdc>m1 1 826611A0 ADTE %sys#m1_more>postoffice>ship_to_dir>hou>m1 1 8214C0A0 ADTE %sys#m1_more>postoffice>ship_to_dir>cmh 1 824274E0 ADTE %sys#m1_more>postoffice>ship_to_dir>wdc 1 8208D020 AFTE %sys#sc3>products>tcp_os>dev.12.2>incl>prototypes.h 1 8208AFC0 AFTE %sys#sc3>products>tcp_os>dev.12.2>incl>lockdef.h 1 82656280 AFTE %sys#sc3>products>tcp_os>dev.12.2>incl>kll_defs.h 1 81F9C640 ADTE %sys#m1>system>tcp_os>telnet_logs 1 8241C180 AFTE %sys#m1>system>ofc_janitor_log.95-02-13 1 820D4600 AFTE %sys#m1>system>queues>batch>rebuild_13.0 1 80BB5300 ADTE %sys#m1>system>tcp_os>command_library 1 80BB3700 ADTE %sys#m1>system>calendars 1 80B7F2C0 AFTE %sys#m1>system>command_library>tp_overseer.pm 1 8020A8A0 ADTE %sys#m1>system>tcp_os 1 801783C0 ADTE %sys#m1>Overseer 2 820DF400 ADTE %sys#m1_more>postoffice>ship_to_dir>milan>m1

2 820DF260 ADTE %sys#m1_more>postoffice>ship_to_dir>esc>m1....as:

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: FFFFFFFF unused_head: 007373F8 unused_tail: 0480D5B8 file_usedp: 00000001 prev_file_usedp: 00000001


dump_adt

Related Informationdump_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.


dump_adte

dump_adte 8-

PurposeThis request displays information about the specified active directory table entries (ADTE) on the analyzed module.

Display Form

Command-Line Formdump_adte dir_name[-address address] [-brief]

Arguments* dir_nameThe 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 addressThe 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.

------------------------------------ dump_adte ---------------------------------dir_name: -address:-brief: no


dump_adte

ExplanationIf 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.


ExamplesIn 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>Jonescatep: 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)


dump_adte

flags: resv_catep: 81708660 resv_blocks: 0 mod_phy_count: 167 log_phy_count: 0 log_data_ptr: 00000001 unmod_phy_list: 817086E8: 819C92E0 819C931C 819B3020 819B305C mod_phy_list: 817086F8: 00000001 817086F8 00000001 817086F8 pcommit_links: 81708708: 00000001 00000001 00000001 00000001 req_wait_list: 81708718: 00000001 81708718 00000001 81708718 entry_disk_addr: 01070D88 entry_offset: 0B80

epx: 0000CB80 uid: 1C49BF53 parents catep: 81A518A0 salvage refcount: 0 next catep: 81955720 prev catep: 81A518A0....as:


dump_afte

dump_afte 8-

PurposeThis 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

Command-Line Formdump_afte filename[-address address] [-brief] [-mod_blocks] [-queue_entries] [-fi_locks ]

Arguments* filenameThe 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.

------------------------------------ dump_afte ---------------------------------filename: -address:-brief: no-mod_blocks: no-queue_entries: no-fi_locks: no


dump_afte

* -address addressThe 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_locksDump 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.

ExplanationThe 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.



dump_afte

ExamplesIn 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: 3allocation_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 00000001 818DB648 mod_phy_list: 818DB658: 00000001 818DB658 00000001 818DB658 pcommit_links: 818DB668: 00000001 00000001 00000001 00000001 req_wait_list: 818DB678: 00000001 818DB678 00000001 818DB678 entry_disk_addr: 0000CCD8 entry_offset: 0320epx: 00001320 uid: 1C6B8AA0 parents catep: 81B59920 last_record: 13937 next catep: 816A5E00 prev catep: 814599C0 parent_ptr: 826517A0

uid: 1C6B8AA0 uid_hash_fp: 8208AFC0


dump_afte

dt_modified: 95-02-09 10:11:31 EST common flags: data_used mod_blocksp: 00000001fp: 00000000

bp: 00000000 locker fp: 8208D200 flags: flags2: locking flags: file type: stream file ref count: 1index_datap: 00000001

record size: 0 first record: 0last record: 13937

tp last record: 0 min record_size: 0 queue_header_ptr: 00000001 lock_infop: 8208D140 pipe_datap: 00000001 object_lock_event: 00000000 time_stamp: 00000000 dirty_readers: 0 excl_read_lockers: 1 last_tid: 0000000000000000 last_cid: 0000000000000000 vm_filep: 00000001 num_writers: 0 num_readers: 1 character_set: none shift_mode: none rawfile_pool_ptr: 00000000 rawfile_disk_addrp: 00000000 num_rewrite_read_lock: 0 No indexes.....as:


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


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: 005E58E6: 00000001 005E58E6 00000001 005E58E6 -free_space_list: 005E58F6: 00000001 005E58F6 00000001 005E58F6 -high_offset: 0

-last_at_priorityp (0): 00000001 -last_at_priorityp (1): 00000001 -last_at_priorityp (2): 00000001 -last_at_priorityp (3): 00000001....

-last_record: 0 -max_messages: 256 -num_messages: 0 -num_non_busy_messages: 0 -highest_num_messages: 0 -total_num_messages: 0000000000000000 -max_per_priority: 4 -num_per_priority(0): 0 -num_per_priority(1): 0 -num_per_priority(2): 0 -num_per_priority(3): 0....

-first_non_busyp: 00000001 -lock_infop: 005E59EC -time_stamp 0000000000000000 -num_refused: 0

lock_infop: 005E472E pipe_datap: 00000001 object_lck_event: 0113409A time_stamp: 00000000 dirty_readers: 0 excl_read_lockers: 0 last_tid: 0000000000000000 last_cid: 0000000000000000 vm_filep: 00000001 num_writers: 1 num_readers: 0


dump_afte

character_set: none shift_mode: none rawfile_pool_ptr: 00000000 rawfile_disk_addrp: 00000000 num_rewrite_read_lock: 0 metersp: 00000001 No indexes.as:

Related Informationdump_queue_info


dump_area

dump_area 8-

PurposeThis request displays information about the contents of a heap and specific information about the blocks in the heap.

Display Form

Command-Line Formdump_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]

----------------------------------- 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


dump_area

Arguments* area_addressThe 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:

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 stringDisplays 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 <CYCLE>Displays information only about the free blocks.

Value Description




I/O The I/O heap. XA/R: 24-bit addressingContinuum: at least 32-bit addressing

high_I/O High physical memory I/O heap. XA/R: 29-bit addressingContinuum: 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)


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 poolDisplays the kernel heap for a specified memory pool. Allowed values are 0 and 1.

* -match_file file_path_nameSpecifies 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.

ExplanationA 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.


dump_area

ExamplesIn 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: 04AFCD2E (0494DD2E)Last available: 04AFCFEC (0494DFEC)Free bytes: 000A56A6Max size: 000027B0Free limit: 00082BFDDead space: 045380C6Area size: 00415F26 (1046 pages)

Bucket(1) 0-32 04964D46 (047B5D46)Bucket(2) 33-64 04A317B6 (048827B6)Bucket(3) 65-96 048E094A (0473194A)Bucket(4) 97-128 00786782 (005D7782)Bucket(5) 129-256 049199DE (0476A9DE)Bucket(6) 257-512 0491BB2A (0476CB2A)Bucket(7) 513-1024 0497E336 (047CF336)Bucket(8) 1025-up 04992FE2 (047E3FE2)

Busy block (**) at 001AF040 (00000040) size=0000000A Permanent Heap Overhead BlockBusy block (VM) at 001AF04A (0000004A) size=00000044 VM Pool InformationBusy block (LC) at 001AF08E (0000008E) size=000000B8 Lock InfoBusy block (LC) at 001AF146 (00000146) size=000000B8 Lock InfoBusy block (LC) at 001AF1FE (000001FE) size=000000B0 Lock InfoBusy block (VS) at 001AF2AE (000002AE) size=0000001C Varying StringBusy block (VS) at 001AF2CA (000002CA) size=00000020 Varying StringBusy block (VS) at 001AF2EA (000002EA) size=00000020 Varying StringBusy block (VS) at 001AF30A (0000030A) size=00000024 Varying StringBusy block (VM) at 001AF32E (0000032E) size=00000044 VM Pool InformationBusy block (PM) at 001AF372 (00000372) size=00000194 Process Map BlockBusy block (VM) at 001AF506 (00000506) size=00000044 VM Pool InformationFree block (IC) at 001AF54A (0000054A) size=0000002C Disk Buffer List BlocksBusy block (PA) at 001AF576 (00000576) size=0000008C Memory Map Page TablesBusy block (PM) at 001AF602 (00000602) size=00000194 Process Map BlockBusy 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


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: 047AAD9E (00003D9E)Last available: 047AB000 (00004000)Free bytes: 0000058CMax size: 00000544Free limit: 00000200Dead space: 00000000Area size: 00004000 (4 pages)

Bucket(1) 0-32 00000001 (00000000)Bucket(2) 33-64 00000001 (00000000)Bucket(3) 65-96 047A87EA (000017EA)Bucket(4) 97-128 00000001 (00000000)Bucket(5) 129-256 00000001 (00000000)Bucket(6) 257-512 00000001 (00000000)Bucket(7) 513-1024 00000001 (00000000)Bucket(8) 1025-up 047A884A (0000184A)

Busy block (**) at 047A7040 (00000040) size=0000000A Permanent Heap Overhead Block047A7040 000000 00000000 2A2AFFFF FFF6 |....**.... |

Busy block (PH) at 047A704A (0000004A) size=00000024 Process Heap Info047A704A 000000 0000000A 5048FFFF FFDC |....PH.... |

047A7054 000000 04727000 00004000 00000083 00003FCD |.rp...@.......?.|047A7064 000010 047A7078 047A7884 0000 |.zpx.zx... |

Busy block (HL) at 047A706E (0000006E) size=0000080C Process Heap Head Lamps047A706E 000000 00000024 484CFFFF F7F4 |...$HL.... |

047A7078 000000 80000000 00000000 00000000 00000000 |................|047A7088 000010 00000000 00000000 00000000 00000000 |................| =047A7268 0001F0 00000000 00000000 00000000 00000000 |................|047A7278 000200 00000000 00000000 00000000 00000000 |................|....as:

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.


dump_area

as: dump_area -heap wired -free

AREA at 0030E000 (wired_heap)

Next virgin: 40DDF900 (40AD1900)Last available: 40DF9FE0 (40AEBFE0)Free bytes: 000222D0Max size: 00005120Free limit: 0007D1FCDead space: 40718160Area size: 003D3E80 (980 pages)

Bucket(1) 0-32 40D9B960 (40A8D960)Bucket(2) 33-64 40D09A90 (409FBA90)Bucket(3) 65-96 40C5C890 (4094E890)Bucket(4) 97-128 00000001 (00000000)Bucket(5) 129-256 00000001 (00000000)Bucket(6) 257-512 00000001 (00000000)Bucket(7) 513-1024 00000001 (00000000)Bucket(8) 1025-up 40DDB3C0 (40ACD3C0)

Busy block (**) at 0030E040 (00000040) size=00000010 Permanent Heap Overhead l+ock0030E040 000000 00000000 2A2A0000 00000000 FFFFFFF0 |....**..........|

Busy block (VM) at 0030E050 (00000050) size=00000050 VM Pool Information0030E050 000000 00000010 564D0000 00000000 FFFFFFB0 |....VM..........|

0030E060 000000 0054F4F0 0054F4F0 0031D7C0 0031D7C0 |.T...T...1...1..|0030E070 000010 00000547 00000040 000A5769 72656420 |[email protected] |0030E080 000020 48656170 00000000 00000000 00000000 |Heap............|0030E090 000030 00000000 00000000 00000000 00000000 |................|

Busy block (PA) at 0030E0A0 (000000A0) size=000000A0 Memory Map Page Tables0030E0A0 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


dump_area

scan_area request, but this request additionally displays the number of blocks in each bucket.

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.

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.


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).


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 BlockBusy block (VM) at 001AD04A (0000004A) size=00000044 VM Pool InformationBusy block (LC) at 001AD08E (0000008E) size=000000B8 Lock InfoBusy block (LC) at 001AD146 (00000146) size=000000B8 Lock InfoBusy block (LC) at 001AD1FE (000001FE) size=000000B0 Lock InfoBusy block (VS) at 001AD2AE (000002AE) size=00000020 Varying StringBusy block (CR) at 001AD2CE (000002CE) size=00000020 Cache Manager RequestBusy block (VS) at 001AD2EE (000002EE) size=00000024 Varying StringBusy block (VM) at 001AD312 (00000312) size=00000044 VM Pool InformationBusy block (PM) at 001AD356 (00000356) size=000001A0 Process Map BlockBusy block (PA) at 001AD4F6 (000004F6) size=0000008C Memory Map Page TablesBusy block (PM) at 001AD582 (00000582) size=00000194 Process Map BlockBusy block (LC) at 001AD716 (00000716) size=000000B0 Lock InfoBusy block (WQ) at 001AD7C6 (000007C6) size=00000030 Diag Cmd Q Wait EntryBusy block (PA) at 001AD7F6 (000007F6) size=0000080C Memory Map Page TablesBusy block (ND) at 001AE002 (00001002) size=000000BC Net Driver TableBusy block (VS) at 001AE0BE (000010BE) size=0000001C Varying StringBusy block (VS) at 001AE0DA (000010DA) size=0000001C Varying StringBusy block (VM) at 001AE0F6 (000010F6) size=00000044 VM Pool Information....as:


dump_axte

dump_axte 8-

PurposeThis request displays information about the specified active index table entries (AXTE) on the analyzed module.

Display Form

Command-Line Formdump_axte filename[index] [-address address] [-brief] [-mod_blocks]

Argument* filenameThe 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.

* indexThe 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.

------------------------------------ dump_axte ---------------------------------filename:index:-address:-brief: no-mod_blocks: no


dump_axte

* -address addressThe 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.

ExplanationThe 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.



dump_axte

ExamplesIn 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: 0parent_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


dump_axte

max_key_len: 21 n_components: 1 component.pos(1): 1 component.len(1): 21 blocks_used: 3 last_block: 2 allocation_size: 1 disk_no: 1 type: INDEX cate flags: error_code: 0 resv_catep: 006AEAD6 resv_blocks: 0 phy_hash_no: 0 buffer_list: 00211896: 00000001 00211896 00000001 00211896 parent_ptr: 006688BE uid: 0D0888BA 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 last Block 2 TP fields time stamp 00000000 root block num 1 cur index depth -1 last Block 2

collating_tp: 1 flags dup_ok xpx: 00000780 max_key_len: 5 n_components: 1 component.pos(1): 19 component.len(1): 5....as:


dump_bmt

dump_bmt 8-

PurposeThis request displays information about the file partition bit map table for each disk on a module.

Display Form

Command-Line Formdump_bmt

ExplanationThe dump_bmt request displays information about the file partition bit map table for each disk on a module.

---------------------------------- dump_bmt ------------------------------------No arguments required. Press ENTER to continue.


dump_bmt

ExamplesIn the following example, the dump_bmt request displays information about the file partition bit map table for each disk on a module.

as: dump_bmtFile 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: 5848825bit_map_page # 1bmex: 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


dump_bmt

bit_alloc_info: current_block: 1 current_byte: 767 byte_withdraws: 0 byte_failures: 0 bit_withdraws: 97285 deposits: 97019 bit_map_page # 1 bmex: 9 blockp: 94FD4000

first_block: 100011 n_blocks: 32768 n_bytes: 4096 bit_map_page # 2 bmex: 10 blockp: 94FD3000 first_block: 132779 n_blocks: 32768 n_bytes: 4096 bit_map_page # 3 bmex: 11 blockp: 94FD2000 first_block: 165547 n_blocks: 32768 n_bytes: 4096....as:


dump_bsc

dump_bsc 8-

PurposeThe dump_bsc request displays information about the specified binary synchronous communications (BSC) channel.

Display Form

Command-Line Formdump_bsc channel_name [-meter]

Arguments* channel_name RequiredThe 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.

---------------------------------dump_bsc---------------------------------------channel_name: -meter: no


dump_bsc

Sample OutputIn 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: 00000001OUT queue #1: headp: 00000001


dump_bsc

tailp: 00000001 records: 0 bytes: 0OUT queue #2: headp: 00000001 tailp: 00000001 records: 0 bytes: 0OUT queue #3: headp: 00000001 tailp: 00000001 records: 0 bytes: 0IN queue: 0 input buffers queued (wired) headp: 00000001 tailp: 00000001RCV queue: 0 active buffers headp: 00000001 tailp: 00000001 pending: 00000001XMT headp: 00000001last xmt block size: 0ACK headp: 00000001last ack block size: 0CTL bufp: 80094F20Free(6): 8008FEE0 protocol_name: RS_bsc

(Page 1 of 2)

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_lenbuf_max_data_len

System value

record_size Value set by application

max_input_recordsmax_input_buffers

System value


dump_bsc

Related InformationFor more information about BSC and BANCS, see the manual VOS Communications Software: Binary Synchronous Communications (R027).

state State of communications link

last_sent Last protocol message sent

last_read Last protocol message received

nak_countenq_counttimeout_count

Actual count during error recovery

max_naksmax_enqmax_bidmax_dead

Value set by application

nak_timeenq_time

System value

(Page 2 of 2)

Field Description


dump_cache

dump_cache 8-

PurposeThis request dumps a summary of each cache buffer.

Display Form

Command-Line Formdump_cache[name] [-all] [-full_path] [-log] [-pin_info]

Arguments* nameA 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.

---------------------------------- dump_cache -------------------------------- name: -all: no -full_path: no -log: no -pin_info: no

*


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.

ExplanationThe dump_cache request dumps a summary of each cache buffer.

ExamplesIn 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 Name136 6 UNMOD V DIR command_library195 0 UNMOD V DIR cac251 0 UNMOD V DIR cm302 0 UNMOD V DIR command_library...356 0 UNMOD V DIR control_files913 1 UNMOD V DIR command_library941 28 UNMOD V DIR command_library5516 -1 UNMOD VR DIR command_library...S => log page safe; R => reference count > 0as:


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_pathphy Block State Type Name195 0 UNMOD V DIR #m19>system>postoffice>ship_to_dir>cac283 14 UNMOD V DIR #m19>system>command_library302 0 UNMOD V DIR #m19>system>command_library303 2 UNMOD V DIR #m19>system>command_library316 0 UNMOD V DIR #m19>system>tcp_os>command_library341 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>chi1S => log page safe; R => reference count > 0as:

In the following example, the dump_cache request displays the pinning status for all caches on the module.

as: dump_cache -pin_infophy Block State Type P PC PSEC Name2 0 UNMOD VR FILE 7 0 598 bitmap.m12_user.03 1 UNMOD VR FILE 7 0 598 bitmap.m12_user.04 2 UNMOD VR FILE 7 0 598 bitmap.m12_user.0...16 93 UNMOD V FILE 5 1 342 streams.cp.pm17 -1 UNMOD VR FILE 7 0 501 tcp_kll.pm18 80 UNMOD V FILE 5 1 342 streams.cp.pmas:


dump_cache

The following table describes the columns that appear in the output of the preceding examples.

Related InformationSee the descriptions of the display_cache_pin_parameters, set_cache_pin_parameters, and dump_cache_info requests.

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)

PVRS

The buffer pin priorityVirtual address assignedReference count > 0Log page safe

PC The buffer pin count.

PSEC The number of seconds a buffer is pinned.


dump_cache_info

dump_cache_info 8-

PurposeThis request displays information about the state of the disk cache.

Display Form

Command-Line Formdump_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.

ExplanationThis 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.

--------------------------dump_cache_info----------------------------------------all: on


dump_cache_info

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.

ExamplesIn the following example, the dump_cache_info request displays information about the caches on the module.

as: dump_cache_info

real mem log max cur min max max maxphyps: 8192 8192 4481phys: 8192 4481 32 8192 8192 32766virs: 4096 3724 32 4096

first_mod_grace_time: 240 seconds last_mod_grace_time: 60 seconds real_last_mod_grace_time: 60 seconds unref_grace_time: 300 seconds ref_grace_time: 60 seconds free_grace_time: 300 seconds

phy states no memory 3719 (45.40% of total phyps) free 3339 (74.51% of total phys) unmodified 1131 (25.24% of total phys) modified 3 (0.07% of total phys) in use 227 (5.07% of total phys)

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


dump_cache_info

In the following example, the dump_cache_info request displays cache pinning information.

as: dump_cache_info

pinning phys % all avg pin avg secs unpinned % all priority 4 0 0.0 0.0 0 1 0.3 priority 5 218 62.1 1.0 54 0 0.0 priority 6 0 0.0 0.0 0 4 1.1 priority 7 0 0.0 0.0 0 94 26.8 priority 8 0 0.0 0.0 0 20 5.7 priority 9 0 0.0 0.0 0 14 4.0as:

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.


Related InformationFor 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.

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)


dump_channel_info

dump_channel_info 8-

PurposeThis request displays the channel information structure of a specified communications channel on the analyzed module.

Display Form

Command-Line Formdump_channel_info channel_name[-brief] [-format_driver_entries]

Arguments* channel_name RequiredThe name of the channel you want information about.

* -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.

-------------------------------- dump_channel_info -----------------------------channel_name:-brief: no-format_driver_entries: no


dump_channel_info

ExplanationThe 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.

ExamplesIn 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: 81596A40Next CIP: 00000001Event ID: 815B6B40Interrupt Index: 0Logical Chan No: 5DVTEP: 801B46E0DRIVER_TEP: 8151DE60METERP: 815B6C40TCBP: 800857A0Out of service: noNeeds testing: noForce listen: noLogin: yesDialup: noLoading Firmware: noTrace Enabled: noFirm Load Failed: noTZM: noDevice Type: Unknown device type #0

(Continued on next page)


dump_channel_info

Timers: 0000Error count: 5Baud: 9600Stop bits: oneParity: oddDevice Index: 2Bits per char: 7Firmware Name: asyncError time: 95-02-01 09:28:47 ESTName Index: 6 (term.17.0.2)UART error count: 0UART error time: NoneUART Ints masked: noUnmask UART Ints: noDialout: yesUsing Firmware: yesModem Speed Select: noBreak isn”t ctrl-q: noUART Error Rate Exceeded: noIO_CONFIG_DATAP: 800C8F60Salvage State: 0as:

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


dump_channels

dump_channels 8-

PurposeThis request displays information about the asynchronous communications channels on the analyzed module.

Display Form

Command-Line Formdump_channels channel_name[-normal] [-buffer] [-meter]

Arguments* channel_nameThe 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.

-------------------------------- dump_channels ---------------------------------channel_name: -normal: no-buffer: no-meter: no


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.

ExplanationUse 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.

ExamplesIn 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 UART Interrupts Input OutputOC17 4 0 0700 5 0 300term.17.0.2 4 1 0000 1 0 0sync.17.0 not asynchronous.sync.17.1 not asynchronous.term.17.12.1 4 192 0500 2 0 0term.17.12.2 4 193 0500 1 0 0term.17.12.3 4 194 0500 1 0 0term.17.12.4 4 195 PreLogin 0700 28618 5540 1117902enet.17.13 not asynchronous.....as:

In the following example, the dump_channels request displays information about channel term.17.12.2.

as: dump_channels term.17.12.2Channel name S C User UART Interrupts Input Outputterm.17.12.2 4 193 0500 1 0 0as:

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.


dump_channels

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 -bufferChannel name Input Collec Active Inact Echo #In #Col #Outterm.17.12.2 00000001 00000001 00000001 00000001 00000001 0 0 0as:

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 -meterChannel name Ichars Ochars Locks Breaks Dialups Intsterm.17.12.2 0 0 2 0 0 1as:

Column Description

S The number of the slot containing the communications controller that controls this channel

C The channel number

UART The UART status. (Interpreted values for this status are provided in the Status column of the dump_tcbh request.)


dump_comm_buffers

dump_comm_buffers 8-

PurposeThis 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

Command-Line Formdump_comm_buffers channel_name[-data]

Arguments* channel_name RequiredThe name of the asynchronous channel to display buffer information about.

* -data <CYCLE>Displays the data contained in each of the buffers.

ExplanationThe 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.

-------------------------------- dump_comm_buffers -----------------------------channel_name: -data: on


dump_comm_buffers

ExamplesIn 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: 00FE27C0 Next Buffer: 00509EE8 Next to Process: 97 Next Block: 00FDFEF4 Control Bits: interrupt_on_exit Sync Control Bits: Status Bits: opened_io_block Exit Status: Not Exited Count: 100 Tally: 4

Input Buffer @00509EE8: Physical Addr: 00FDFEF4 Next Buffer: 00000001 Next to Process: 1 Next Block: FFFFFFFF Control Bits: interrupt_on_exit Sync Control Bits: Status Bits: Exit Status: Not Exited Count: 100 Tally: 100 COLLECTION CHAIN:

Collection buffer @001ECFC4: Next Buffer: 001F02C4 Max Byte: 80 Next Byte: 1 Count: 1 Record Type: 0 Code: 0


dump_comm_buffers

Collection buffer @001F02C4: Next Buffer: 00000001 Max Byte: 80 Next Byte: 1 Count: 1 Record Type: 0 Code: 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: 00000001 Max Byte: 80 Next Byte: 24 Count: 0 Record Type: 0 Code: 0 COMMAND LINE COLLECTION BUFFER:

Collection buffer @001F8C44: Next Buffer: 00000001 Max Byte: 80 Next Byte: 3


dump_comm_buffers

Count: 1 Record Type: 0 Code: 0as:

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: 00FDFEF4 Next Buffer: 005067B4 Next to Process: 27 Next Block: 00FE27C0 Control Bits: interrupt_on_exit Sync Control Bits: Status Bits: opened_io_block Exit Status: Not Exited Count: 100 Tally: 74

00 0D842064 61746185 08848508 84850884 | .. data......... |10 8508842D 64617461 850D6F67 67696E67 | ...-data..ogging |20 850D2E84 2E737461 72745F85 08848508 | .....start_..... |30 84850884 85088485 08848508 84850884 | ................ |40 85080808 08648475 6D705F63 68616E6E | .....d.ump_chann |50 656C7385 0D0D1B52 6484756D 705F636F | els....Rd.ump_co |60 6D6D5F62 | mm_b |

Input Buffer @005067B4: Physical Addr: 00FE27C0 Next Buffer: 00000001 Next to Process: 1 Next Block: FFFFFFFF Control Bits: interrupt_on_exit Sync Control Bits: Status Bits: Exit Status: Not Exited Count: 100 Tally: 100


dump_comm_buffers

00 75666665 72732074 312E3332 202D6461 | uffers t1.32 -da |10 7461850D 0D0D0D0D 0D6C8485 0D2E842E | ta.......l...... |20 73746172 745F6C6F 6767696E 67206475 | start_logging du |30 6D70636F 6D6D6275 66666572 732E7361 | mpcommbuffers.sa |40 6D706C65 850D6484 756D705F 636F6D6D | mple..d.ump_comm |50 5F627566 66657273 2074312E 3332850D | _buffers t1.32.. |60 1B45014B | .E.K |as:


dump_eit

dump_eit 8-

PurposeThis request displays information about the executable image table (EIT) on the analyzed module.

Display Form

Command-Line Formdump_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.

------------------------------------ dump_eit ----------------------------------flags: -long: no-summary: no


dump_eit

ExamplesIn the following example, the dump_eit request displays information about the executable image table.

as: dump_eit EIT at 80139280head(0): 8017C1A0tail(0): 8266B120lock_infop: 8013F5E0n_load_calls: 363215n_unload_calls: 363155n_links_snapped: 2926490, avg 8.06n_network_loads: 2648as:

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:


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 %sys#m1>system>kernel_loadable_library>dkux.pm8020E720 %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:


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 80139280head(0): 8017C1A0tail(0): 820941C0lock_infop: 8013F5E0n_load_calls: 363230n_unload_calls: 363169n_links_snapped: 2926668, avg 8.06n_network_loads: 2648

EITE at 8017C1A0flags: kernel_pm references_kernelnextp: 80204840prevp: 00000001program: %sys#m1>system>kernel_loadable_library>vterm.pmaftep: 00000001ref ct: 1base vm at: 80227000paged VM at 8022B000date_bound: 94-10-04 23:06:22 ESTmain_lk.code: 00000000main_lk.static: 00000000init static_addr: 80229000init static_len: 00000198paged static_len: 000003F8paged ext_static_addr: 8024A000paged ext_static_len: 00000544n_link_names: 120n_unsnap_links: 131n_entries: 1link_nm_map_addr: 8025355Alink_nm_map_len: 00000FF0link_map_addr: 8025454Alink_map_len: 00000312entry_map_addr: 8025485Centry_map_len: 0000002Aheader_address: 80261C5Cheader_len: 00000B56n_stacks: 1stack_len: 32768user_heap_start: 00000000user_boundary: 00000000

EITE at 80204840program:


dump_eit

%sys#m1>system>kernel_loadable_library>mpx_gcomm.pmaftep: 00000001ref ct: 1base vm at: 80872000wired VM at 80872000paged VM at 80880000date_bound: 94-10-04 23:05:52 ESTmain_lk.code: 00000000main_lk.static: 00000000wired static_addr: 8087B000wired static_len: 000000F0....as:

The following table describes the most important fields that appear in the output of the preceding examples.

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


dump_et

dump_et 8-

PurposeThis request displays the event table or selected entries from the event table.

Display Form

Command-Line Formdump_et address[-all] [-free] [-hash] [-header] [-remote] [-long] [-loop_lock][-match string]

Arguments* addressThe 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

----------------------------------- dump_et ------------------------------------address:-all: no-free: no-hash: no-header: no-remote: no-long: no-loop_lock: no-match:


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 <CYCLE>Displays information about hardware locks.

* -match stringDisplays only those entries from the event table that match the given string.

ExplanationThe 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.


dump_et

ExamplesIn the following example, the dump_et request displays the event table for the specified network change event.

as: dump_et C1124F80ETE 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-1’s: 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: 00000001as:

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


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 network_notify_event80C115A0 96261 stopped_process_event80C11620 0 system_sleep_event80C116A0 547 red_light_interrupt_event80C11960 1307 page_wait_event80C11A00 3613684 page_fault_event80C4C180 224931 syserr_buffer_event813CE560 113 diag proc813D2340 74 chan lock event 1813D23C0 73 chan lock event 2813D2440 73 chan lock event 3813D24C0 73 chan lock event 4813D2540 73 chan lock event 5813D25C0 73 chan lock event 6813EAB80 2 Add Comm Ctlr Event813FB440 0 packet pool 1813FB4C0 16931 packet pool 2813FB540 980 packet pool 3813FEB80 0 net boomer 1813FECC0 0 net boomer 2...813FF080 0 net boomer 88140D800 0 Back-Release Sockets81411920 748 Login Device Event81522D40 13546 network change event81522DC0 0 VCTE lock event81523FC0 24649 TpOverseer Signal Event8156CB20 1 event_for_clock8156CC20 0 event_for_clock81523F40 23005 TpOverseer Wait Event8156CBA0 0 event_for_clock81526E40 0 comm_trace8156CCA0 0 event_for_clock8156CD20 0 event_for_clock8156CDA0 0 event_for_clock8156CE20 0 event_for_clock8156CEA0 0 event_for_clock8156CF20 0 event_for_clock8156CFA0 0 event_for_clock8156DA60 4 device_event_for_OC17....as:


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, 80C114DC, 80C114D8, 81783CB0, 80C1142C, 81783DE4, 81783BE0, 80C11470, 81783C14, 81783C20, 81783CC4, 81783BA8, 81783D20, 80C114FC, 81783E04, 81783DF4, 81783C5C, 81783BD4, 80C11480, 81783C94, 80C114D0, 81783E58, 81783D4C, 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_eventHash 2 0069FBE0 (00000001 04AC2E30) for remote_shadow.010A20CE 04AC2E30 (0069FBE0 00000001) for %s1#d01>system>load_control_eventHash 7 007A5830 (00000001 00000001) for remote_shadow.010A80DAHash 9 0482C560 (00000001 00000001) for %s1#d01>system>syserr_log_eventHash 11 04A61A70 (00000001 00000001) for remote_shadow.010AD0CAHash 12 049DDB00 (00000001 00000001) for %s1#d01>system>echo_eventHash 24 0069FCD0 (00000001 00000001) for %s1#d01>system>system_red_light_eventHash 26 0494FF10 (00000001 00000001) for %s1#d01>process_dir_dir>pd.010E1D1B.Overseer>_aq4DgWaaabqaaabY.tempHash 30 048AEF00 (00000001 00000001) for remote_shadow.0106404F....as:


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: dynamic_max_events max_events_per_proc: 256 max_events_per_task: 64 max_events: 65535 time_event_sim_int: 1 n_etep_arrays: 2 n_events: 348 n_extended_events: 57 free_slot_ptr: 04814610 hw_lock.lockp: 00006242 broadcast_lock.lock_word: 8000 free_slot_lock.lock_word: 8000 hash_lock.lock_word: 8000 shadow_lock.lock_word: 8000 timed_lock.lock_word: 8000 n_calls: 589970 n_waits: 585067 n_no_wait_calls: 4969as:

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.64E5007A3550 2 0105.shadow.04863CF0 0.0105.0000272A.1563064F.00C7.0041

Remote ETEs:04A11100 1 REQ event for mail_reader.server 0110


dump_et

049716A0 12 REQ event for mail_reader.server 0111as:

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 VALUE LOCK NAME 00006000 0000* process_control_lock 00006002 8000 timer_manager_lock 00006004 8000 pcp_entry_lock 00006006 8000 Lock List Header 00006008 8000 wired lock cow stomach 0000600A 8000 paged lock cow stomach 0000600C FFFF Wired Heap 0000600E 8000 trace_data_lock 00006010 8000 syserr_buffer_lock 00006012 001D* page_control_lock 00006014 8000 pc_q_lock 00006016 8000 map_lock 00006018 8000 disk_csq 0000601A 8000 disk_control 0000601C 8000 disk_queue 0000601E 8000 MASTER CHANNEL LOCK 00006020 8000 TCB HEADER LOCK 00006022 8000 buffer_pool.199DFC 00006024 8000 interim_io_cpu_lock 00006026 8000 Comm Heap 00006028 8000 net driver table 0000602A 8000 net buffer pool 0000602C 8000 buffer_pool.1A0FCE 0000602E 8000 net socket table 00006030 8000 link_boot_info table 00006032 FFFF tape_1.lk 00006034 FFFF tape_2.lk 00006036 FFFF tape_3.lk 00006038 FFFF tape_4.lk 0000603A 8000 diag cmd q 0000603C 8000 Login Device Database Lock 0000603E FFFF Paged Heap 00006040 8000 Virtual Circuit Entries....


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 tape_op_chain_lock 0067AD00 0 tape_op_chain_lock 0067AD70 0 tape_op_chain_lockas:


dump_events

dump_events 8-

PurposeThis request displays information about the events being used by the current analyzed process.

Display Form

Command-Line Formdump_events event_no[-attached] [-kernel] [-long] [-task task_id]

Arguments* event_noThe 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 process’s kernel events.

--------------------------------- dump_events ----------------------------------event_no: -attached: no-kernel: no-long: no-task:


dump_events

* -long <CYCLE>If this switch is on, VOS displays more information about each event and its usage.

* -task task_idThe task_id of the tasks about which you want information. Information about other tasks in the process is not displayed.

ExamplesIn 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.

as: dump_events

SYNC_WAIT_LIST at 006A6AF0 for Overseer.System (BatchOverseer) flags: thread_notify update_event_counts num_tasks: 1 first notify:

TASK EVENTNO ETEP FLAGS EVENTCNT NEXT-NOTIFY PRI 1 2 006A6E30 00001F68 0 3 006A7E20 0000001F 0 4 006A7BB0 00000D67 0 5 005CFF90 00000A73 0 7 048C9060 00000013 0 8 04AD4EC0 0000C754 0 9 04A39DA0 00000000 0

TASK TIMEOUTas:

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


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_12as:

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: 006A0850 sync_wait_ptr: 006A6AF0 flags: thread_notify update_event_counts task_id: 0001 task_priority: 0000 task_timeout: 00007FFFFFFFFFFF max_sync_objects: 0007 num_sync_objects: 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


dump_events

last_event_count: 00001F68 wait_links: prevp=00000001 nextp=00000001 flags: notify_priority: 0 user_event_no: 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:


dump_firmware_names

dump_firmware_names 8-

PurposeThis request displays the firmware configured for the analyzed module.

Display Form

Command-Line Formdump_firmware_names

ExplanationThe 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.

-------------------------------- dump_firmware_names -----------------------------No arguments required. Press ENTER to continue.


dump_firmware_names

ExamplesIn the following example, the dump_firmware_names request displays the firmware configured for the module.

as: dump_firmware_namesMax 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_haspas:


dump_fli

dump_fli 8-

PurposeThis 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

Command-Line Formdump_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

---------------------------------- dump_fli ----------------------------------address:-brief: no -full: no -blocked_lists: no -follow_chain: -output_path:


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 file’s 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.


dump_fli

* -output_path file_name Directs the output from the terminal’s screen to file_name. By default, the request directs output to the terminal’s screen.

ExplanationThis request displays a single FLI structure and optionally, a list of associated FLI structures.

ExamplesThe following example illustrates the use of the dump_fli request.

as: dump_fli 802A74E0 -brief

File_lock_info: 802A74E0 by_tsi: 802A74E0: 00000001 80282310 00000001 80282310 by_afte: 802A74F0: 802AC0E0 802AC0F0 802AB7E0 802AB7F0 tsi_ptr: 802822A0 afte_ptr: 8028FEC0 afte name: other_file afte last record: 20

tp old last record: 20 tp last record: 20 required tplock: record write lock req_tplock_ptr: 802AD020 links: 802AD020: 00000001 00000001 00000001 00000001 rec w locked: 9 existed: true exists: true cur_size: 254 log_len: 256 log_offset: -2146589171 waiting: 802A7540: 00000001 802AC120 00000001 802AC120

blocked_list(0): 802A7520: 00000001 802A7520 00000001 802A7520 blocked_list(1): 802A7530: 00000001 802A7530 00000001 802A7530 file lock type: reserve write lock tp lock flags: abort/deadlock record_r_list: 802A7560: 802ACF20 802ACF20 802ACF20 802ACF20 record_w_list: 802A7574: 00000001 802A7574 00000001 802A7574 n_indexes: 1 locks on index: oth_idx r_list (1): 802A758C: 802921C0 802921C0 80290CC0 80290CC0 w_list (1): 802A75A0: 00000001 802A75A0 00000001 802A75A0


dump_fw_table

dump_fw_table 8-

PurposeThis request displays the protocols and hardware associated with the firmware configured on the analyzed module.

Display Form

Command-Line Formdump_fw_table

ExplanationThe 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).

------------------------------- dump_fw_table ----------------------------------No arguments required. Press ENTER to continue.


dump_fw_table

ExamplesIn the following example, the dump_fw_table request displays the protocols and hardware associated with the firmware configured on the module.

as: dump_fw_tablefw ptr = 00606468pr ptr = 00606808hw_protocol_table ptr = 00606C28fw 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:


dump_giza

dump_giza 8-

PurposeDumps host-side data structures that contain Giza engine information that is based on the variable os_giza_control_tablep$.

Display Form

Command-Line Formdump_giza iop_no[-all] [-salvage_forward] [-salvage_backward] [-long]

Arguments * iop_noThe IOP slot number for the Giza engine.

* -allSpecifies that all Giza engines will be dumped.

* -salvage_forwardSpecifies that the request follow the command ring salvage pointer forward.

* -salvage_backwardSpecifies that the request follow the command ring salvage pointer backward.

--------------------------------- dump_giza ---------------------------------iop_no: -all: no-salvage_forward: yes-salvage_backward: yes-long: no

0


dump_giza

* -longSpecifies that the request list any outstanding MDBs on the command ring.

ExplanationDumps 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.

ExamplesIn the following example, the dump_giza request displays host side data structures that contain Giza engine information.

as: dump_gizaos_giza_control_tablep$ at 00550EE0

SLOT: 22 ENGINE: 00553990

COMMAND RING: 00553A10ring size: 64 input_index: 20 output_index: 20ring_start_virt: 00553A50 salvage_hp: 00556000 salvage_tp: 005551D0ring_phys_addr: 00000000 Overflow_list_hp: 00000001 Overflow_list_tp: 00000001

salvage list head: 005560001st MDB: 00556000 callback: llc+1005A, line 4287chan: 1600005F stat: 0 return_index: 4next MDB: 00556190 callback: llc+1005A, line 4287chan: 1600005F stat: 0 return_index: 4

salvage list tail: 005551D0last MDB: 005551D0 callback: llc+123F6, line 4840chan: 16000096 stat: 0 return_index: 4prev MDB: 00557EA0 callback: llc+E4AE, line 3760chan: 16000097 stat: 0 return_index: 4

RESPONSE RINGS:

M_AND_D RING: 00553CC0 size: 64 input_index: 0 output_index: 0ring_start_virt: 00553D00 overflow hp: 00000000 overflow tp: 00000000

CPU DEBUG RING: 00553E10 size: 64 input_index: 0 output_index: 0ring_start_virt: 00553E50 overflow hp: 00000000 overflow tp: 00000000

INTERRUPT RING: 00553F60 size: 64 input_index: 0 output_index: 0ring_start_virt: 00554000 overflow hp: 00000000 overflow tp: 00000000

UNLOCK INTER RING: 00554110 size: 64 input_index: 0 output_index: 0ring_start_virt: 00554150 overflow hp: 00000000 overflow tp: 00000000


dump_giza

QRUN RING: 00554260 size: 64 input_index: 37 output_index: 35ring_start_virt: 005542A0 overflow hp: 00000000 overflow tp: 00000000

SCHEDULER RING: 005543B0 size: 64 input_index: 0 output_index: 0ring_start_virt: 005543F0 overflow hp: 00000000 overflow tp: 00000000

UNLOCK SCHED RING: 00554500 size: 64 input_index: 40 output_index: 40ring_start_virt: 00554540 overflow hp: 00000000 overflow tp: 00000000


dump_h3270

dump_h3270 8-

PurposeThe dump_h3270 request displays information about the specified 3270_host channel.

Display Form

Command-Line Formdump_h3270 channel_name [cux] [devx] [-long]

Arguments* channel_name RequiredThe 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.

* -cuxSelects 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 channel’s mpx_number value in the devices.tin file. The default value is 0.

---------------------------------- dump_h3270 -------------------------------- channel_name: cux: 0 devx: 0 -long: no


dump_h3270

* -devxSelects 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 channel’s 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.

ExamplesThe 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


dump_h3270

timer_idx3: 70 baud: 14 (9600) flags: ebcdic state: 2 (control) last_sent: 8 (eot_msg) last_rcvd: 6 (enq_msg) last_ack: 0 enq_count: 0 nak_count: 0 timeout_count: 0 timer_action: 2 flags: started dsr xmt_active n_controllers: 1 Cur CU: -1 Cur DV: -1 Rcv buffer count: 32 rcv_headp: 80097B40 rcv_tailp: 800978C0 pending_input: 00000001 xmt_bufp: 80095220 ack_bufp: 00000001 ctl_bufp: 00000001 free buffer count: 4 free_headp: 80097A00 input_queue_length: 7 input_interrupts: 3923 output_interrupts: 0 dsl_interrupts: 2 timer_interrupts: 0 firmware_string: bsc

cup(0): 81671FE0

(Page 1 of 2)

Field Description



flags Info on port setup

state Protocol line state

last_sent Last protocol message sent

last_rcvd Last protocol message received

enq_countnak_count

Count during error


dump_h3270

Related InformationFor more information about 3270_host support and emulation, see the manual VOS Communications Software: 3270 Support and 3270 Emulation (R026).

flags Internal information

n_controllers Number of controllers opened

input_queue_length Number of input buffers

input_interruptsoutput_interruptsdsl_interruptstimer_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)

(Page 2 of 2)

Field Description


dump_iop_equip_table

dump_iop_equip_table 8-

PurposeThis request displays the contents of the IOP equipment table.

Display Form

Command-Line Formdump_iop_equip_table

ExplanationBefore using this request, you must issue the use_iop request and specify an IOP on the module.

ExamplesIn 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 status—the IOA slots

• ENTITY status—the IOP entities (drivers)

• CHANNEL status—the 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.

----------------------------- dump_iop_equip_table --------------------------- No arguments required. Press ENTER to continue.



as: dump_iop_equip_table as: use_iop -iop_no 1as: dump_iop_equip_tableIOP equipment table at 000B87A0

IOA statusIOA Entity Type Priority Status E_ptr0 2 74 7 80050020 00000001 initialized, alive, present, running1 4 70 7 80050020 00000001 initialized, alive, present, running2 4 87 7 80050020 00000001 initialized, alive, present, running3 4 87 7 80050020 00000001 initialized, alive, present, running4 4 87 7 80050000 00000001 initialized, alive, present5 4 87 7 80050000 00000001 initialized, alive, present6 4 87 7 80050000 00000001 initialized, alive, present7 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_reset17 -1 -16657 -8531 DEADBEEF 00000001 initialized, exception, alive, present, running, prom_start, testing, burning_p+rom, soft_reset18 -1 -16657 -8531 DEADBEEF 00000001initialized, exception, alive, present, running, prom_start, testing, burning_p+rom, soft_reset...ENTITY statusEntity Type Status E_ptr1 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 12462 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 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



4 4 80000000 00000001 Cmd_entry at: 0001B6D0 x -> jug_gci_entity+9B8, line 692 Cfg_entry at: 0001D2D4 x -> jug_gci_entity+25BC, line 1569 Slot_entry at: 0001DD10 x -> jug_gci_entity+2FF8, line 19395 5 80000000 00000001 Cmd_entry at: 0004E944 x -> jug_giza_entity+6C, line 367 Cfg_entry at: 0004E9E2 x -> jug_giza_entity+10A, line 397 Slot_entry at: 0004E98A x -> jug_giza_entity+B2, line 3817 1234 00000000 00000001 Cmd_entry at: 0001A6F4 x -> iop_test_entity+4, line 29 Cfg_entry at: 0001A7BA x -> iop_test_entity+CA, line 62 Slot_entry at: 0001A832 x -> iop_test_entity+142, line 74...CHANNEL status:Channel Entity Type Priority Status E_ptr1 4 0 0 80000000 000CAD3C initialized2 4 0 0 80000000 000C6F1E initialized3 4 0 0 80000000 000C2362 initialized35 4 0 0 80000000 000CADC6 initializedas:


dump_iop_meters

dump_iop_meters 8-

PurposeThis request displays the meters maintained by the IOP Environment Services (ES) in the IOP.

Display Form

Command-Line Formdump_iop_meters

ExplanationThe dump_iop_meters request displays information about the current IOP.

N O T E

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.

------------------------------- dump_iop_meters ------------------------------No arguments required. Press ENTER to continue.


dump_iop_meters

ExamplesIn 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 Failed_syserr 0 Bgnd_calls 557551932 Bgnd_time 0 Bgnd_avg 0 Timer_call 1079161 Time 2145319 Timer_avg 1 Dma_calls 24016 Dma_byte 49184768 Dma_time 37178Byte_avg 2048 Dma_time_avg 1 Cmd_send 7768 Cmd_recv 7764 Host_busy 0 Interrupts 13022

ENTITY meters at 0003A2EC Entity: 0

Calls Time Avg Max Commands 130 254 128 621 Bgnd_callback 0 0 0 0 Timer_callback 1084969 2145322 129 1486 Interrupts 0 0 0 0

Entity: 1 Calls Time Avg Max

Commands 7636 28027 240 480 Bgnd_callback 0 0 0 0 Timer_callback 0 0 0 0 Interrupts 13022 69229 348 5997

Entity: 2....as:


dump_iop_meters


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 disk2 - Communications3 - Cartridge tape4 - GCI SCSI5 - Giza (message passing protocol)

Bgnd_callback Information about background callbacks.

Timer_callback Information about timer callbacks.

Cmd_sendCmd_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.


dump_lap_meters

dump_lap_meters 8-

PurposeThis request displays the LAPB protocol meters. LAPB stands for Link Access Prorocol–Balanced, the link-level protocol for X.25.

Display Form

Command-Line Formdump_lap_meters channel_name

Arguments* channel_name RequiredThe name of a LAPB channel from which meters are being dumped.

ExplanationThe 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.

------------------------------- dump_lap_meters ------------------------------channel_name:


dump_lap_meters

ExamplesIn the following example, the dump_lap_meters request displays LAPB metering information.

as: dump_lap_meters phx***** LAP METERS *****interrupts = 2621966dsl_interrupts = 1input_interrupts = 1346993output_interrupts = 1291494timeouts = 39xmit_timeouts = 0frames_sent = 1304571frames_rcvd = 1433412chars_sent = 225816896chars_rcvd = 43692087read_waits = 776538write_waits = 263220crc_errors = 3rej_frames_rcvd = 772timer_recoveries = 89aborts_rcvd = 56as: dump_lap_meters cac_s2***** LAP METERS *****interrupts = 2492731dsl_interrupts = 4input_interrupts = 1086891output_interrupts = 1104842timeouts = 1xmit_timeouts = 0frames_sent = 1106811frames_rcvd = 1091424chars_sent = 10659418chars_rcvd = 16440040read_waits = 478658write_waits = 0timer_recoveries = 80input_int_time (msec) = 1350045.00msec per input int = 1.24msec per input frame = 1.24

output_int_time (msec) = 594396.40msec per output int = 0.54msec per output frame = 0.54as:


dump_lcb

dump_lcb 8-

PurposeThis request enables you to examine the control block of a LAPB channel. LAPB stands for Link Access Prorocol–Balanced, the link-level protocol for X.25. lcb stands for LAPB_control_block.

Display Form

Command-Line Formdump_lcb channel_name

[-long]

Arguments* channel_name Required The name of the LAPB channel control block to examine.

* -longIf -long is set to yes, the request’s 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.

ExamplesThe 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 stratnetlap_dfr_interval$ = 15***** LCB DUMP *****LCB addr = 816F4320

----------------------------------- dump_lcb --------------------------------- channel_name: -long: no


dump_lcb

state = Info_xferaddrs: cr = 1 cs = 3 rr = 3 rs = 1Node type is DCE.loopback_mode = -1baud_rate = 56000t1 = 3073 n2 = 5 k = 7t2 = 0config_flags: defer_dsl_dropframe_size = 517bufs_per_frame = 8max_output_bufs = 40recv_low_wat = 9recv_overflow = 0recv_bufs = 41input_bufs = 41dfr_cnt = 0dfr_pm_action = 0dfr_pm_code = 0dfr_last_time = 0 (80-01-01 00:00:00 edt)dfr_msg =Vs = 6 Vr = 1 As = 1 Ar = 6xfer_flags:flags:trace_mode = onfree_bufs = 40free_bufp = 80091E00as:

The following table describes the fields in the dump_lcb request’s output.

(Page 1 of 2)

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 addressCS is the command send addressRR is the response receive addressRS 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.


dump_lcb

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, Vr—The sequence state variablesAs, Ar—The 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

(Page 2 of 2)

Field Description


dump_lock

dump_lock 8-

PurposeThe dump_lock command displays information on a specific kernel database lock or locks, as well as associated meters.

Display Form

Command-Line Formdump_lock [address] [-name lock_star_name] [-member [member_lock_star_name]] [-brief] [-meters]

Arguments* -addressDisplays the locks for the specified address.

* -name lock_star_nameDisplays 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.

---------------------------------- dump_lock --------------------------------- address: -name: -member: -brief: yes -meters: no


dump_lock

* -no_brief <CYCLE> Displays additional information about each lock.

* -meters <CYCLE> Displays lock usage meters of the lock being displayed. By default, these meters are not displayed.

ExplanationThe dump_lock request displays the system locks.

ExamplesIn the following example, the dump_lock request displays lock information for the module.

as: dump_lock lock name address type lock state num locks--------- ------- ---- ---------- ---------

Lock List Header C1016140 single unlocked 326wired lock cow stomach C1016280 single unlocked 34paged lock cow stomach C10163C0 single unlocked 330wired lock queue C1016500 single unlocked 6169paged lock queue C1016640 single unlocked 2448986Wired Heap 0 C1016780 single unlocked 1515239process_creation_lock C10168C0 single unlocked 432762unique_id_lock C1016A00 single unlocked 196801config table C1016B40 single unlocked 39858Loop locks 0 C1016C80 single unlocked 197302I/O Heap 0 C1017A80 single unlocked 1549hardware history table C101E200 group unlocked 776062maint int C101F240 single unlocked 18552mem_test_page C10202C0 single unlocked 0....Total Locks: 179532515Minimum Cost: 18296.465 seconds of cpu timeas:

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 List Header lock_wordp: C0803180 -> 0000x lock_state: unlocked type: 1 (single) flags: wired pool: -1 spin_limit: 0 (0.000 seconds)


dump_lock

Lock info at C1016280 name: wired lock cow stomach lock_wordp: C0804180 -> 0000x lock_state: unlocked type: 1 (single) flags: wired pool: -1 spin_limit: foreverLock info at C10163C0 name: paged lock cow stomach lock_wordp: C0805180 -> 0000x lock_state: unlocked type: 1 (single) flags: wired pool: -1 spin_limit: 128 (0.002 seconds)....as:

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 C10203C0Lock info at C10203C0 name: recc_md_recc_mand_channel_lock lock_wordp: C080AF80 -> 0000x lock_state: unlocked type: 1 (single) flags: wired pool: -1 spin_limit: 0 (0.000 seconds)as:

In the following example, the dump_lock request displays information about the system group lock.

as: dump_lock -member system*lock name address type lock state num locks--------- ------- ---- ---------- ---------

system C0AD49C0 member unlocked 98552 system_default C0B0D080 member unlocked 1

Total Locks: 0Minimum Cost: 0.000 seconds of cpu timeas:


dump_lock

In the following example, the dump_lock request displays detailed information about the system lock.

as: dump_lock -name systemLock info at C0AD49C0 name: system lock_wordp: C080FF00 -> 0000x lock_state: unlocked type: 0 (member) flags: pool: -1 group_lock_infop: C0AD0180as:

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 -metersLock 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.


dump_lock

The following table describes the fields that appear in the output of the preceding examples.

Related InformationFor more information about locks, see the description of the lock_meters and lock_summary requests.

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.


dump_mt

dump_mt 8-

PurposeOn 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

Command-Line Formdump_mt [-long]

Arguments* -long <CYCLE> Displays more detailed information about the memory table.

ExplanationOn 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.

------------------------------------- dump_mt -----------------------------------long: on


dump_mt

ExamplesIn the following example, the dump_mt request displays memory table information for an XA/R-series module.

as: dump_mtConfigured memory 65536 pages, 256MB.

4 memories configured, 1 present.Pages present: 65536

Slot Defined Paired Size Address Defined Defined Wireable Partner with duplex address

20 21 21 256MB. 0MB. yes none no21 20 20 256MB. 0MB. yes none yes22 23 -1 0MB. missing no none23 22 -1 0MB. missing no noneas:

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)

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.


dump_mt

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: 80E929C0 Number of memories: 4 Maximum memory: 131072 pages, 512MB Present memory: 65536 pages, 256MB User limit: NONE Boot memory type: FREEWAY-256MB Config lock ptr: 80E92BC0 Flags: initialized,

MEMORY #1 Slot: 20 Duplex slot: 21 Duplex memory #: 2 Size: 256MB Base address: 0MB Memory type: FREEWAY-256MB Flags: present,def duplex,testedMEMORY #2 Slot: 21 Duplex slot: 20 Duplex memory #: 1

Size: 256MB Base address: 0MB Memory type: FREEWAY-256MB Flags: present,def duplex,wireable,testedMEMORY #3 Slot: 22 Duplex slot: 23 Duplex memory #: 0 Size: 0MB Base address: -1 Memory type: UNKNOWN Flags: missing....as:

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.

(Page 2 of 2)

Column Description


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:


dump_net_info

dump_net_info 8-

PurposeDisplays StrataNET status information for a system.

Display Form

Command-Line Formdump_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]

------------------------------- 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


dump_net_info

Arguments* -system_name system_nameSpecifies 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_nameSpecifies 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_nameSpecifies 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_numberSpecifies 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 <CYCLE> Displays the network client table.

* -ngt <CYCLE> Displays the network gateway table.

* -nrt <CYCLE> Displays the network routing table.

* -ngt_calls <CYCLE> Displays the calls made to the network gateway table.

* -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.


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.

ExplanationThe dump_net_info request displays information about the current status of StrataNET for a module, system, or entire network.

ExamplesIn 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: 197Sys 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....


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: 110445285 Size Messages % of Total 6: 17294538 15.65 7: 21135416 19.13 8: 29718818 26.90 9: 29132363 26.37....

The following table describes the columns that appear in the MODULES section of the output of the preceding example.

The following table describes the columns that appear in the SYSTEMS section of the output of the preceding example.

Column Description

Mod The module number

NetAdr The module’s 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

(Page 1 of 2)

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


dump_net_info

Related InformationFor 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.

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 F’s. 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

(Page 2 of 2)

Column Description


dump_net_tids

dump_net_tids 8-

PurposeThis request displays transaction IDs (TIDS) for StrataLINK stations on a module.

Display Form

Command-Line Formdump_net_tids [station_numbers ids] [-all] [-full]

Arguments* station_numbers idsThe 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 (1–255), 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.

--------------------------------- dump_net_tids --------------------------------station_numbers: -all: no-full: no


dump_net_tids

ExplanationThe 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.

ExamplesIn 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 1111111111111111as:


dump_net_tids


Related InformationFor 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.

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


dump_nst

dump_nst 8-

PurposeThis request displays the net socket table (NST) for a StrataLINK or StrataNET connection on a module.

Display Form

Command-Line Formdump_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.

----------------------------------- dump_nst ---------------------------------socket_numbers: -header: no-full: no-long: no-reset: no-all: no


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.

ExplanationSockets 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.


dump_nst

ExamplesIn 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 for most information }{dump_rst Reserved Socket Table}{dump_prt Pending Request Table}as:

Related InformationFor 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.


dump_poll_select

dump_poll_select 8-

PurposeThis request displays the state of a poll/select line or a poll/select terminal.

Display Form

Command-Line Formdump_poll_select channel_name[-address address]

Arguments* channel_name RequiredThe name of the channel that you want information about. Do not include the number sign (#) in the channel name.

* -address addressThe two-character address of a terminal that you want to display information about. The terminal must be open.

ExplanationIf 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.

------------------------------- dump_poll_select -------------------------------channel_name: -address:


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.

ExamplesIn 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: aa (6161x) group_address: (0404x)


dump_poll_select

poll_address: aa (6161x) select_address: aa (6161x)

n_channels: 1 poll_timeouts: 0 max_input_msg_size: 0 max_output_msg_size: 0 flags: single_device single_subchp: 001BF656 terminal #2 terminal_address: ab (6162x) group_address: (0404x) poll_address: ab (6162x) select_address: ab (6162x) n_channels: 1 poll_timeouts: 4 last_poll_try: 0B82FACA (64 seconds) max_input_msg_size: 0 max_output_msg_size: 0 flags: broken single_device single_subchp: 001B7618 first_subchp: 001BF656 last_subchp: 001B7618 uart_status: 41 flags: output_complete input_available

control_buf_output input_subchp: 00000001 input_bufp: 001C17AA input_type: 1 (eot) input_expected_for: 00000001 next_terminal: 1 n_broken_terminals: 1 next_poll_subchp: 00000001 first_poll_subchp: 00000001 last_poll_subchp: 00000001 poll_subchp: 00000001 output_subchp: 00000001 output_bufp: 00000001 first_output_subchp: 00000001 last_output_subchp: 00000001 trace_datap: 00000001 trace_data_n_entries: 0 trace_enabled: false (at 001C179A) interrupt_count: 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)


dump_poll_select

Subdevices for entry 4: (none) Subdevices for entry 5: (none)

Subdevices for entry 9: (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: 1as:


dump_poll_select

The following table describes the most important fields that appear in the output of the preceding example.

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.


dump_porte

dump_porte 8-

PurposeThis request displays information about the port table entry (PORTE) specified on the analyzed module or process.

Display Form

Command-Line Formdump_porte address[-name port_name] [-number port_number] [-brief] [-no_format_driver_entries]

* addressThe 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_nameThe 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.

----------------------------------- dump_porte ---------------------------------address: -name:-number:-brief: no-format_driver_entries: yes


dump_porte

* -number port_numberThe 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 <CYCLE>Displays summary information as output.

* -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.

ExplanationThe 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.

ExamplesIn 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 5PORT 5 at C0DA1500Portname: terminalPathname: %es#os_telnet_m19.5Type: window terminalFlags: attached,open,hold_attachment,logging,read_logging write_logging,hold_opening,port_accounting system_port,count_down_driverAccess mode: sequentialI/O type: output


dump_porte

log_port: 20process_id: 0113CFB8info_ptr: C1B3FDC0dvtep: C0B54880port_id: 5user_info_ptr: C0BCFCC0forms_info_ptr: 00000001tv: 110 (Open Window)user_tv: 110 (Open Window)tasking_info_ptr: 7FFA9FC0accounting_info_ptr: 7FFA9FA0time_limit: -1conflict_count: 0character_set: latin_1shift_mode: singlepte_ptr: C1ABD980amte_ptr: 00000001tv_driver_tep: C112AD00

--- SAFE STORAGE at C0BCFCC0window_hdl 7FF2A000screen_hdl 7FF2A054dil_driver_tep C1124F00

--- WINDOW at 7FF2A000sp.next 00000001sp.prev 00000001sp.window viewport ul 0:0, lr 24:79sp.background_attrs 0000xsp.Flags:sp.visible_region_list 00000001owner 7FF2A054top_pane 00000001bottom_pane 00000001current_pane 00000001win_flags: window_no_user_heapport_id 5current_io_pane 00000001displaytype_list 00000001global_dt_text_heap 00000001saved_form_list 00000001global_disptype_alloc_vec C08728C0free_pane_list 00000001uid 0next_pane_uid 16first_free_displaytype -32768lang_info_ptr 00000001out_notation: hex_notation_char ascii/60 undisplayable_notation_mode 0


dump_porte

--- SCREEN at 7FF2A054fm_config &iwm_open_user_window+108 (C083E648)dil_ptr term_dil_vector (C0864BA0)window_alloc_vec FMSwm_alloc_vector (C08728C0)device_dcs 1desired_image_ptr 00000000ttp 00000001

--- WCB at C1B3FDC0w.sp.next 00000001w.sp.prev 00000001w.sp.window viewport ul 0:0, lr 24:80w.sp.background_attrs 0000xw.sp.Flags: visiblew.sp.visible_region_list C1589F80 ...->element[0].view ul 0:0, lr 24:80w.owner C1893680w.top_pane C1632C00w.bottom_pane C1632C00w.current_pane C1632C00w.win_flags: window_no_user_heap window_line_pane_existsw.port_id 5w.current_io_pane C1632C00w.displaytype_list 00000001w.global_dt_text_heap 00000001w.saved_form_list 00000001w.global_disptype_alloc_vec C1893714w.free_pane_list 00000001w.uid 1w.next_pane_uid 16w.first_free_displaytype -32768w.lang_info_ptr C11E4F40w.out_notation: hex_notation_char ascii/60 undisplayable_notation_mode 0Flags: process_is_primary_user prompt_text_changed process_key_on_int interrupt_enable virtual_status_changed call_side_notifiedprocess_id 0113CFB8xevent_id C16FCE40xevent_count 38echo_table_hdl 00000001interrupt_table_hdl 00000001insert_default_hdl C1544600 (‘as’)virtual_status_line_hdl 00000001


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 0max_height 24min_width 0max_width 80input_mode GENERIC_INPUTFlags2: window_openref_count 1current_input_section 0cur_cursor_loc 23:0cur_cursor_format BLINKING_BLOCKbreak_action SIGNAL AND DISCARDkeystroke_info: reqs_disabled 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 input_options 00000000x ENTER_maskkeys 00000000x CANCEL_maskkeys 00000000x keyused -1 function_key 4sw_line_state: top_scroll_field 28 top_scroll_offset 0 scroll_lines 0 start_field -32768 end_field -32768


dump_porte

clr_rel_v_offset -1 clr_lines 0 end_input_loc 25 end_prompt_loc 0 lines_remaining 23 prev_size 0 lines_that_fit 1 cursor_format STEADY_BLOCK Flags: lm_data_on_pause lm_might_wrap attrs 00000000xtitle C199DBC0 (‘analyze_system’)read_form_region: num_panes 0 max_panes 0 rfpi_ptr 00000001 formid 0 paneid -32768last_input_request return (4)compatibility_info: flags: read_raw_index 0wait_state: wm_update NO_UPDATE_IN_PROGRESSwait_state_ids: sw_write_id -32768 sw_read_id -32768 control_id -32768cached_message_hdl C1795B80

--- PANE at C1632C00sp.next 00000001sp.prev 00000001sp.window viewport ul 0:0, lr 24:80sp.background_attrs 0000xsp.Flags: visiblesp.visible_region_list C16BD540 ...->element[0].view ul 0:0, lr 24:80owner C1B3FDC0parent_pane 00000001object_origin 0:0form C1232F40sw_screen_state_hdl 00000001CURSOR_field 9CURSOR_offset 0Flags: pane_iouid 0pane_image_hdl 00000001pane_image_ptr 00000001


dump_porte

--- FORM at C1232F40next 00000001owner_window C1B3FDC0owner_pane C1632C00display_list_alloc_vec C1893714field_list C1B7C880predef_displaytype_list 00000001predef_text_heap 00000001anon_displaytype_list 00000001anon_text_heap 00000001value_heap C1748680field_lines C170BF40field_flags C1714600uid 0first_field 11last_field 9State Flags:background_attribs 0000xrequired_field_attribs 0004x

Verified references of fields to string heaps.

--- FORM FIELD LIST

ID NEXT PREV rel av # or DT len loc datastate/flags -- ---- ---- --,--- -- - -- --- -- ---- ---------------

11 4 8 05,000 22 1 00 0004 0 0012 4 10 11 06,000 22 1 00 0004 0 002E 10 13 4 07,000 22 1 00 0004 0 0023....Verified handles to be between fence and end offsetsVerified free handle listVerified free block list

--- SCB at C1893680s.fm_config wm_config_ev_in_heap (C0864B40)s.dil_ptr term_dil_vector (C0864BA0)s.window_alloc_vec C1893714 (C1893714)s.device_dcs 1s.desired_image_ptr 00000001s.ttp C14DED80acb_hdl C1116D00access_layer_type TELNETfirst_meta 80xlast_meta 85xscreen viewport ul 0:0, lr 24:80top_window C1B3FDC0bottom_window C1B3FDC0current_window C1B3FDC0


dump_porte

status_messages C1A2E2C0terminal_state_hdl C237CD00Flags: dil_attached terminal_type_valid break_to_wmgr image_allocated login_slaveOutput_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 C1AEE200insert_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 00000001al_ptr tel_al_vector (E4B97080)dil_driver_tep C1124F00al_driver_tep C15BADC0max_input_len 300next_window_uid 1wmgr_state.cursor_loc 0:0open_action ALLOW CONNECTIONnum_procs_to_start 0original_user_name Joe_Smithallocation_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 15684til_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


dump_porte

update_last_field -32768 screen_wait_state_flags 0000xmeterp 00000001screen_vm_reg_ptr C23C6300screen_vm_reg_size 8460Flags2:

--- ACB at C1116D00scbp C1893680access_layer_type 1acb_lockp C1580580serverp C2379840 (os_telnet)dvtep C0B54880 (os_telnet_m19.5)acb_link.nextp 00000001acb_link.next_linksp 00000001acb_link.prevp 00000001acb_link.prev_linksp 00000001socketp C1537900in_bufsetp C1AEE200extra_bufp C16E5C80out_bufp_list.nextp 00000001....num_out_bufs 0num_in_bufs 3num_free_bufs 2conn_state CS_CONNECTEDrecv_state RS_NORMALxmit_state XS_NORMALacb_flags 22002000x acb_input_enabled acb_suppress_goahead acb_loginsocket_id 8acb_index 4acb_serv_flags 00000000xpeer_name 134.111.50.14,3225timers[0] 83dvtx 21til_ptr wm_til_vector (C08649A0)

Enabled kernel entries:

seq_read: s$yield_processor+10DC2C (line 326 in module seq_read_windowed)seq_write: s$yield_processor+10FE14 (line 191 in module seq_write_windowed)control: s$yield_processor+1017CC (line 972 in module control_windowed)close: s$yield_processor+100204 (line 335 in module close_windowed)read_form: s$yield_processor+110DBC (line 158 in module read_form_windowed)


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:


dump_protocol_names

dump_protocol_names 8-

PurposeThis request displays the names of the protocols configured for the analyzed module.

Display Form

Command-Line Formdump_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).

------------------------------ dump_protocol_names -----------------------------No arguments required. Press ENTER to continue.


dump_protocol_names

ExamplesIn 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_namesMax 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_ssas:


dump_prt

dump_prt 8-

PurposeThis request displays the StrataLINK or StrataNET pending request table (PRT) for a module.

Display Line Form

Command-Line Formdump_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.

------------------------------------- dump_prt ------------------------------------full: no-free: no-header: no


dump_prt

ExplanationThe 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.

ExamplesIn 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-113as:

Related InformationFor 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.


dump_pte

dump_pte 8-

PurposeThis request displays the process table entry (PTE) for the analyzed process, or any process for which the address argument is given.

Display Form

Command-Line Formdump_pte address[-match match_string] [-current_pte] [-all]

Arguments* addressThe 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_stringDisplays 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.

----------------------------------- dump_pte -----------------------------------address: -match: -current_pte: no-all: no


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.

ExplanationThe 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.


dump_pte

ExamplesIn 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: 255last_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


dump_pte

stop_timer_q.prevp: 00000001 stop_timer_q.nextp: 00000001user_fence_pgno: 259882 (3F72Ax)

fence_pages: 8 ustack_top_vpn: 261920 (3FF20x) ustack_bottom_vpn: 261929 (3FF29x)uheap_top_vpn: 1603 (00643x)

uheap_bottom_vpn: 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: 0B209000map_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: 7program_info_ptr: 820E0340

command_status: 0 () pi_flags: pi_mask (off): pi_welcome_mask (off):


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: 1interrupt_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: 1691cmi_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:


dump_pte

wait_time: 1132819 arrivals: 726 completions: 726 busy_time: 1132819 starts: 726 smi_process_int: space_time_product: 5322 pluses: 512 minuses: 512 smi_process_unsh_mem: space_time_product: -32412021168580 pluses: 1427smi_process_sh_mem:

space_time_product: 39001401469 pluses: 148 minuses: 148 smi_process_pf: space_time_product: 756561 pluses: 1636 minuses: 1636as:


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


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: 0as:

Related InformationSee the description of the dump_tdr request for related information.


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

Command-Line Formdump_queue_info [filename] [-address address] [-entry_detail] [-sqi_detail] [-afte_detail] [-free] [-full]

Arguments* filenameThe 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.

----------------------------- dump_queue_info -------------------------------- filename: -address: -entry_detail: no -sqi_detail: no -afte_detail: no -free: no -full: no


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 addressSpecifies 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.


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.)

ExplanationQueues 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 (LAN—for 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


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.


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 04FCAF40 4301F0A6 00000000 0 0 0 4 04FCAF70 054DF4E0

R 04FB1B30 4301D0A5 04B4A530 12 3 12 12 04FB1B60 00000001

R 048CFC20 060763B1 05C1A480 1 0 1 1 048CFC50 00000001


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


dump_queue_info

Example 2Example 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



ref count: 2







main_sqe_list: 04D82904: 054DF4E0 054DF4E0 0553D810 0553D810


--------- -- ----------- -------------------------------------------


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


- --------- --------- --------- -----------------------------------------

R 04FB1B30x 00000001x 04B4A530x 4301D0A5x John_Doe

messages: 12 replies: 3 flags:

highest: 12 total: 12 servers w/ access: 1


dump_queue_info

local_sqe_list: 04FB1B60: 04AA8410 04AA8420 0553D810 0553D820


--------- -- ----------- ----------------------------------------------

04AA8410x 0 1 7 server_done

05524FF0x 0 2 7 server_done

05505C00x 0 3 7 server_done


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 3Example 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



ref count: 2







main_sqe_list: 04D82904: 054DF4E0 054DF4E0 0553D810 0553D810

Pri Number Last at Pri Number Last at first_non_busyp: 054CDC70x


dump_queue_info

--- ------ --------- --- ------ ---------

10 0 00000001x 0 9 0553D810x

SQEp Pr Message ID Msg Length Flags

--------- -- ----------- ----------------------------------------------


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




04AD1B30x 0 6 7


SQE Space: 054E05C0x Req SQIp: 04FB1B30x John_Doe




.

.

.

0553D810x 0 12 7


SQE Space: 04ACDA00x Req SQIp: 04FB1B30x John_Doe

offset: 2816 (00000B00x) size: 256 ref cnt: 1



num_free_sqe: 1 num_free_sqe_space: 2 high_offset: 3328

free_sqe_list: 04D82918: 04FCDE80 04FCDE80 04FCDE80 04FCDE80

free_sqe_space_list: 04D82928: 04D82080 04D82080 054D05F0 054D05F0

free_space_list: 04D82948: 04D80B60 04D80B70 04D80B60 04D80B70

space_list: 04D82938: 04AD7190 04AD7190 04D7DAE0 04D7DAE0

sqi_list: 04D828F4: 04FCAF40 04FCAF60 04FB1B30 04FB1B50

last_sqi_notifiedp: 00000001x


- --------- --------- --------- ---------------------------------------

S 04FCAF40x 054DF4E0x 00000000x 4301F0A6x John_Doe

messages: 0 replies: 0 flags: is_server

highest: 0 total: 4


dump_queue_info


- --------- --------- --------- -------------------------------------

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



05524FF0x 0 2 7


SQE Space: 04AD7190x Req SQIp: 04FB1B30x John_Doe





05505C00x 0 3 7


SQE Space: 05510030x Req SQIp: 04FB1B30x John_Doe





Server done: false Srv SQIp: 04FCAF40x

SQE Space: 049397B0x Req SQIp: 04FB1B30x John_Doe




054CDC70x 0 5 7


SQE Space: 048C00F0x Req SQIp: 04FB1B30x John_Doe




04AD1B30x 0 6 7


SQE Space: 054E05C0x Req SQIp: 04FB1B30x John_Doe



time_stamp: 5 error_code: 0 .

.

.

.


dump_queue_info

0553D810x 0 12 7


SQE Space: 04ACDA00x Req SQIp: 04FB1B30x John_Doe

offset: 2816 (00000B00x) size: 256 ref cnt: 1



Example 4Example 4 presents information about a message queue file.

as: dump_queue_info tmqAFTE at 0550C1A0 for: %sys#dev>SysAdmin>John_Doe>test>tmq

file type: message queue file

ref count: 2

Queue Header @ 04D8D250x


-qe_list: 04D8D254: 05505F70 05505F70 054D6150 054D6150

Example 5Example 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


-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


dump_queue_info

-saved_server-fip: 00000001

-saved_server-process_id: 00000000

-tsip: 00000001

queue_entry 054D6150x

-links: 04D8D254: 00000001 04D8D254 05505F70 05505F70

-priority: 8

-priority_key: F700202B7DC8F1F3x

-saved_priority: 8

-saved_priority_key: F700202B7DC8F1F3x

-message_no: 2

-message_offset: 256

-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

-saved_server-fip: 00000001

-saved_server-process_id: 00000000

-tsip: 00000001


dump_r3270

dump_r3270 8-

PurposeThis request displays information about the specified 3270_remote channel.

Display Form

Command-Line Formdump_r3270 channel_name [-subch subchannel_address] [-interval time]

Arguments* channel_name RequiredThe 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_addressSpecifies 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 1–0.

* -interval secondsSpecifies 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.

---------------------------------- dump_r3270 --------------------------------channel_name: -subch:-interval:


dump_r3270

Example 1In 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


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


dump_r3270

Example 2In 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-0Subch 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)


dump_r3270

(Page 1 of 2)

Field Description



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_countnak_counttimeout_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


dump_r3270

Related InformationFor more information about 3270_remote support and emulation parameter values, see the manual VOS Communications Software: 3270 Support and 3270 Emulation (R026).

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

(Page 2 of 2)

Field Description


dump_r3270_trace

dump_r3270_trace 8-

PurposeThis request performs a link-level trace in addition to tracing information on the state of the line. This request displays information only if the channel’s 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

Command-Line Formdump_r3270_trace channel_name [-no_interactive]

Arguments* channel_name RequiredThe 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_interactiveSpecifies 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.

-------------------------------- dump_r3270_trace -------------------------------channel_name: -interactive: yes


dump_r3270_trace

ExamplesThe 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) (3) (4) (5) (6)

0.000 0.0000 239 r-done tally=1 (trans) 610.004 0.0043 239 start-w tally=1 () 370.008 0.0202 240 w-done tally=1 () 370.100 0.0921 241 timer_sim0.102 0.0018 241 out_pend0.146 0.0443 242 r-done tally=1 () 370.150 0.0031 242 start-w tally=9 () 37 FF 32 32 60 60 C1 C1 2D0.153 0.0036 243 w-done tally=9 () 37 FF 32 32 60 60 C1 C1 2D0.272 0.1189 244 r-done tally=1 (trans) 700.275 0.0027 244 start-w tally=249 (trans,stx,etx) 27 F5 C3 32 24 EF0.279 0.0043 245 w-done tally=249 (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


dump_r3270_trace

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.

(Page 2 of 2)

Action Description


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 InformationFor more information about 3270_remote support and emulation, see the manual VOS Communications Software: 3270 Support and 3270 Emulation (R026).


dump_rst

dump_rst 8-

PurposeThis request displays the StrataLINK and StrataNET reserved socket table (RST) on a module.

Display Form

Command-Line Formdump_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.

----------------------------------- dump_rst -----------------------------------rsv_socket_numbers: -all: no-full: no-long: no-header: no


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.


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.

ExamplesIn 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 Last Pendg Req Queue ----------- New Requests ----------- Busy SKT S-TID Len Max 1st Lst Received Rpts Queued %Qd Ignrd Sent --- ----- --- --- --- --- ----------- ----- -------- ---- ----- ------- 1 A62D 0 28 0 0 87205753 ***** 3927235 4% 0 61

Skt Last Event TID Other Response Group CTID ID Clnt-Srvr Stn Skt Type Seq Rsv Nxt Flags ---- ---- -------- --------- ----- ---- ---- --- --- ---- ----- 5 FFFF 81470260 0000-0000 0 0 -- 0 1 4 server(M2), input_wait


dump_rst

pid: 01118043x, process 67: Overseer.System (LinkServer5) 4 FFFF 81476CA0 0000-0000 0 0 -- 0 1 3 server(M2), input_wait pid: 01118042x, process 66: Overseer.System (LinkServer4) 3 FFFF 81476BE0 0000-0000 0 0 -- 0 1 2 server(M2),

input_wait pid: 01118041x, process 65: Overseer.System (LinkServer3) 2 FFFF 814768E0 0000-0000 0 0 -- 0 1 1 server(M2), input_wait pid: 01118040x, process 64: Overseer.System (LinkServer2) 1 FFFF 81470F80 0000-0000 0 0 -- 0 1 0 server(M2), input_wait pid: 0111803Fx, process 63: Overseer.System (LinkServer1)

RSV Last Pendg Req Queue ----------- New Requests ----------- Busy SKT S-TID Len Max 1st Lst Received Rpts Queued %Qd Ignrd Sent --- ----- --- --- --- --- ----------- ----- -------- ---- ----- ------- 13 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: 4as:

Related InformationFor 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.


dump_rsv_socket

dump_rsv_socket 8-

PurposeThis request displays information about the traffic on each StrataLINK and StrataNET socket in the analyzed module or dump.

Display Form

Command-Line Formdump_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.

--------------------------------- dump_rsv_socket ------------------------------rsv_socket_numbers:-all: no-full: no-long: no-reset: no


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.

* -resetTemporarily 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.


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

ExamplesIn 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 ----------- BusySKT 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-5as:


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 -longRSV 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 Last Event TID Other Response GroupCTID ID Clnt-Srvr Stn Skt Type Seq Rsv Nxt Flags

---- ---- -------- --------- ----- ---- ---- --- --- ---- ----- 5 FFFF 81470260 AF4C-D857 113 308 -- 0 1 4 server(M2), unclean, data_accepted pid: 01118043x, process 67: Overseer.System (LinkServer5) 4 FFFF 81476CA0 0000-0000 0 0 -- 0 1 3 server(M2), input_wait pid: 01118042x, process 66: Overseer.System (LinkServer4) 3 FFFF 81476BE0 0000-0000 0 0 -- 0 1 2 server(M2), input_wait pid: 01118041x, process 65: Overseer.System (LinkServer3) 2 FFFF 814768E0 0000-0000 0 0 -- 0 1 1 server(M2), input_wait pid: 01118040x, process 64: Overseer.System (LinkServer2) 1 FFFF 81470F80 0000-0000 0 0 -- 0 1 0 server(M2), input_wait pid: 0111803Fx, process 63: Overseer.System (LinkServer1)as:


dump_rsv_socket

The following table discribes the most important fields in the output of the preceding example.

Related InformationFor 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.

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.


dump_scheduler_queues

dump_scheduler_queues 8-

PurposeThis request displays information about the state of the queues maintained by the scheduler on the analyzed module or dump.

Display Form

Command-Line Formdump_scheduler_queues[-interval number]

Argument* -interval numberSpecifies 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.

ExplanationThe 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.

------------------------------- dump_scheduler_queues ---------------------------interval:



ExamplesIn the following example, the dump_scheduler_queues request displays information about the scheduler queues on a module.

N O T E

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 P# C P Q CT LEFT START RUN USERalarm 41 8 4 1 0.37 >999 59.5 Overseer (load_control.pm) 49 7 6 1 0.06 49.8 4.4 Overseer (oop.pm) 19 9 2 1 0.25 600.2 9.4 Maintenance_Utility () 5 9 2 1 **.** >999 4.1 Cache_Manager_Locker () 66 7 6 1 0.01 242.8 1.9 Overseer (oracle_tpo.pm) 67 7 6 1 0.39 165.4 1.1 Overseer (oracle_tpo.pm) 65 7 6 1 0.36 417.6 1.1 Overseer (oracle_tpo.pm) 4 9 2 1 **.** >999 7.6 Cache_Manager_Timer () 3 9 2 1 **.** >999 0.4 Cache_Manager_Post () 40 8 4 1 0.98 1.8 1.8 Overseer (mail_handler.pm) 33 8 4 1 0.29 253.8 80.3 Overseer (mail_handler.pm) 27 7 6 1 0.49 44.3 44.3 Overseer (watch_kernel.pm) 35 8 4 1 0.82 573.0 40.4 Overseer (mail_handler.pm) 39 6 10 1 2.00 809.2 44.9 Overseer (mh_notifier.pm) 279 8 5 4 3 1.55 7.2 0.0 Joe_Smith (office.pm)

28 7 6 1 0.49 742.5 742.5 Overseer (mail_handler.pm) 68 7 6 1 0.35 50.1 49.8 Overseer (oracle_tpo.pm) 23 9 2 1 0.31 78.2 34.8 Overseer (tp_overseer.pm) 45 5 10 1 1.87 >999 327.5 Overseer (cal_notifier.pm) 38 6 10 1 4.26 847.9 841.5 Overseer (mh_sorter.pm) 44 5 10 1 0.51 >999 >999 Overseer (oracle_tpo.pm)


(Page 1 of 2)

Field Description

QUEUE One of three types of queues for a process. The following table describes these queues.

P# The process number

C The CPU the process is running on

P The priority level



The following types of queues may be listed in the QUEUE column.

Q 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 process’s 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

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)

(Page 2 of 2)

Field Description


dump_socket

dump_socket 8-

PurposeThis request displays socket information for StrataLINK connections on a module.

Display Form

Command-Line Formdump_socket[socket_numbers] [-all] [-full] [-long]

Arguments* socket_numbersThe 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.

-------------------------------- dump_socket --------------------------------socket_numbers: -all: no-full: no-long: no


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.

ExplanationYou 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.

ExamplesIn the following example, the dump_socket request displays information about all active StrataLINK sockets on a module.

as: dump_socket -allSkt 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:


dump_socket

Related InformationFor 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.


dump_socket_info

dump_socket_info 8-

PurposeThis request displays information about StrataLINK and StrataNET sockets on a module.

Display Form

Command-Line Formdump_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]

------------------------------- 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


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 <CYCLE> Displays the net socket table (NST).

* -rsv_socket_able <CYCLE> Displays the reserved socket table (RST).

* -pending_request_table <CYCLE> Displays the pending request table (PRT).

* -net_tids <CYCLE> Displays all last server tids for a station.

* -all <CYCLE> Displays all tables.

* -header <CYCLE> Displays only header information for each table.

* -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.


dump_socket_info


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.


dump_socket_info

Figure 8-1. Socket Structures

NST

nstp$

1

3

2

7

6

4

5

11

10

8

9

13

12

nst_max_sockets$

HDR

RST

rstp$

1

3

2

63

62

67

66

64

65

rst_max_sockets$

Attached Socket Data

Attached RSV Socket Data

in stl nx gp prq

in stl nx

Skt 5

in stl nx

Skt 9

gp prq

RSV Skt 67

Skt 1 RSV Skt 1

VC Packet

VC Packet

STL

HDR

PRT

prtp$

prt_max_entry$

HDR


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.

ExamplesIn 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$) 004802A4xnst_max_socket$: 255lockp: 00006286locker_pid: 00000000lock_count: 1794496lock_cycles: 2108030client_requests: 81489slot_zero_requests: 0worry_rcvd: 0dead_sent: 5904tiderr_sent: 0iwait_sent: 0sockets attached: 1-15 21

Reserved Socket Table - RST at (rstp$) 00483EB4xrst_max_socket$: 100rst_max_queue_len$: 100rsv sockets attached: 1

Pending Request Table - PRT at (prtp$) 00484116xprt_max_entry$: 150nleft: 150min_left: 148free 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}


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 Last Pendg Req Queue ----------- New Requests ----------- Busy SKT S-TID Len Max 1st Lst Received Rpts Queued %Qd Ignrd Sent --- ----- --- --- --- --- ----------- ----- -------- ---- ----- ------- 2 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 26D2PRQ THREADING ERROR: prq_last (133) does not equal last (135).

RSV Last Pendg Req Queue ----------- New Requests ----------- Busy SKT S-TID Len Max 1st Lst Received Rpts Queued %Qd Ignrd Sent --- ----- --- --- --- --- ----------- ----- -------- ---- ----- ------- 38 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: 20as:


dump_socket_info

Related InformationFor 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.


dump_stream

dump_stream 8-

PurposeThis 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


dump_stream

Command-Line Formdump_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 addressDisplays 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 addressDisplays the sigs_s structure. Specify the address contained in the sth_sigs field of the sth.


dump_stream

* -osr addressDisplays 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 addressDisplays the polls_s structure. Specify the address contained in the sth_polls field of the sth.

* -dev addressDisplays the device structure. Use the address denoted by the info_ptr in the porte structure.

* -msg addressDisplays structures and contents of any messages contained in a streams queue.

* -sq addressDisplays the synchronization queue element structures for a msg or an osr structure.

* -sqh addressDisplays the synchronization queue head structures. These are also displayed with the -queue argument, unless the parent’s sqh structure is different from the queue’s.

* -stm_schedDumps 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_tableDumps 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.


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 stream’s 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_sizeSets 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_onlyWhen 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


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.

ExplanationThe 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.


dump_stream

Figure 8-2. VOS STREAMS I/O Data Structures

porte

device

read osr write osr ioctl osr

sthpoll osr

hash table

write queue read queue

write queue read queue

msg

msg

msg

streams cache


dump_stream

The VOS STREAMS data structures shown in Figure 8-2 are described in the following table.

Figure 8-3 illustrates the data structures used to synchronize different threads of execution accessing streams structures within the kernel.

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.


dump_stream

Figure 8-3. VOS STREAMS Data Structures That Synchronize Execution Threads

sq sq

write queuesqh

read queuesqh

mult_sqh

osr sq owner

sth

queue pair locking

module locking

module sqh

sq

sqh_parentsqh_parent

sqh_owner

sq_next sqh_next

sqh_prev

sqh_prev

sqh_parent

sqh_parent

write queuesqh

read queuesqh

sqh_parent

sq sq


dump_stream

The VOS STREAMS data structures shown in Figure 8-3 are described in the following table.

In addition to the mult_sqh, the queue sqh’s 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 sqh’s point to a third sqh. All acquisitions of this driver use the third sqh labeled module sqh.

ExamplesBefore 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.

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.


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.

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.

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

(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 porte’s 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.


dump_stream

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.

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

(Page 1 of 2)

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.

(Page 2 of 2)

Field Description


dump_stream

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.

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 tofinish.F_STH_READ_ERROR - The stream received an M_ERRORand all reads will fail.F_STH_WRITE_ERROR - The stream received an M_ERRORand 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 head’s 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

(Page 2 of 2)

Field Description


dump_stream

.

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.

Field Description

q_qinfo A pointer to the qinit structure for this queue. The qinit structure is described in the VOS Communications Software: STREAMS Programmer’s 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 head’s 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 won’t be enabled with a call to putq.QFULL - The queue’s 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 asopposed 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

(Page 1 of 2)

Field Description

b_next A pointer to the next message on the queue

b_prev A pointer to the previous message on the queue


dump_stream

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.

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.

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

(Page 2 of 2)

Field Description


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.

Description of the Output from dump_stream -stm_msg The following table describes the most important fields displayed by dump_stream -stm_msg.

Field Description

sq_next A pointer to the next sq waiting to acquire the synchronization queue. This pointer is the same as the synchronization queue’s 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

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


dump_stream

Description of the Output from dump_stream -timerq The following table describes the most important fields displayed by dump_stream -timerq.

Description of the Output from dump_stream -bufcallqThe following table describes the most important fields displayed by dump_stream -bufcallq.

Description of the Output from dump_stream -stm_schedThis 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

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

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


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)

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.


dump_stream

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_DAEMONDAEMON_QUICK_LOOPDRAIN_WORK_QDRAIN_WORK_Q_DAEMONENTER_STREAMSEXIT_STREAMSFINISH_STREAMS_INTERRUPT

Global meters

FINISH_STREAMS_INTERRUPT The number of times interrupt processing handled STREAMS work.


Meter Description


dump_stream

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_DONEIDLE_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.


Meter Description


dump_stream

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.


Meter Description


dump_stream

FREE_MBLK_CHUNK The number of times STREAMS has freed a block of STREAMS messages back to the system.

ALLOC_BPRI_LO_FAILSALLOC_BPRI_MED_FAILSALLOC_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_VMLLOC_NO_MBLK_BUFFERSALLOC_NO_IO_VMLLOC_NO_IO_BUFFERSALLOC_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_CALLBACKSBUFCALL_BPRI_MED_CALLBACKSBUFCALL_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.


Meter Description


dump_stream

Example 1The 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].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


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[EXPAND_MBLK_BUCKET[0]] = 52










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[1].ptep = C0BD8A00



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


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[ALLOC_MBLK_CHUNK] = 38

ppi[1].meters[UNBUFCALL_CALLS] = 130210


dump_stream

ppi[1].meters[CROSS_POOL_FREES] = 2039

ppi[1].meters[MSGPULLUP_CALLS] = 59335

Example 2The 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_desc Driver to read strlog output from.

Streams ‘telnet’ driver @ C17F3880 (modsw @ C17F3780):



modsw_desc OS Telnet Streams Driver

Streams ‘hrsd’ driver @ C17F3D40 (modsw @ C17F3C40): modsw_sq_level

SQLVL_QUEUEPAIR


modsw_desc Host Remote Streams Driver for IOAs

Streams ‘ip’ driver @ C1865340 (modsw @ C1865240): modsw_sq_level

SQLVL_QUEUE


modsw_desc STCP ip

modsw_meters[SQ_PUTNEXT_MISS] 2244







dump_stream

Streams ‘loop’ driver @ C1867700 (modsw @ C1867600): modsw_sq_level

SQLVL_MODULE


modsw_desc LOOPBACK Driver below IP

modsw_meters[SQ_PUT MISS] 462




Streams ‘raw’ module @ C1868D00 (modsw @ C1868C00): modsw_sq_level

SQLVL_MODULE


modsw_desc Raw module provides raw access to IP

Streams ‘udp’ driver @ C18695C0 (modsw @ C18694C0): modsw_sq_level

SQLVL_QUEUE


modsw_desc STCP udp






Streams ‘stcp’ driver @ C186BD00 (modsw @ C186BC00): modsw_sq_level

SQLVL_QUEUE


modsw_desc STCP tcp


modsw_meters[FINISH_STREAMS_INTERRUPT_MISS] 1







Streams ‘tpipe’ driver @ C18CA7C0 (modsw @ C18CA6C0):

modsw_sq_level SQLVL_MODULE


modsw_desc Telnet pipe driver

Streams ‘timod’ module @ C18CF8C0 (modsw @ C18CF7C0):



modsw_desc Streams TLI Module


dump_stream

Streams ‘lat_st’ driver @ C18E3600 (modsw @ C18E3500):


modsw_disable_ints ur uw

modsw_desc Window Term to TLI Multiplexor

Streams ‘tli_term’ driver @ C18E3BC0 (modsw @ C18E3AC0):



modsw_desc Window Term to TLI Multiplexor


Streams ‘ad’ driver @ C1EC3940 (modsw @ C1EC3840): modsw_sq_level

SQLVL_QUEUE


modsw_desc DLPI interface for DLMUX

modsw_meters[SQ_CHECK_AND_PUTNEXT MISS] 18375




Streams ‘adp’ module @ C1EC5680 (modsw @ C1EC5580): modsw_sq_level

SQLVL_QUEUE


modsw_desc DLPI conversion MODULE

Streams ‘arp’ module @ C1EC5F00 (modsw @ C1EC5E00): modsw_sq_level

SQLVL_QUEUE


modsw_desc STCP ARP MODULE

Streams ‘sosl_net_driver’ driver @ C1908200 (modsw @ C1908980):



modsw_desc STCP OSL mux

Streams ‘dkhs’ driver @ C191A0C0 (modsw @ C1919FC0): modsw_sq_level

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

Streams ‘dkux’ module @ C191A800 (modsw @ C191A700): modsw_sq_level

SQLVL_MODULE


modsw_desc Datakit DKUX Module


dump_stream

Streams ‘dkbk’ module @ C191B840 (modsw @ C191B740): modsw_sq_level

SQLVL_MODULE


modsw_desc Datakit DKBK Module

Streams ‘dkxqt’ driver @ C19254C0 (modsw @ C19253C0):

modsw_sq_level SQLVL_MODULE


modsw_desc Datakit DKXQT Driver

Streams ‘dkty_al’ driver @ C1925CC0 (modsw @ C1925BC0):



modsw_desc Datakit Terminal Access Driver

Streams ‘tnmod’ module @ C1765F40 (modsw @ C1765340):



modsw_desc STCP telnet module

Example 3The 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


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 4The 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 5The following request displays a specific STREAMS queue head.

as: dump_stream -sqh C162E9B0

SQH = C162E9B0 SQH_NEXT = 00000001 SQH_PREV = 00000001 SQH_FIRST = 00000001 SQH_LAST = 00000001 sqh_vos_lock = C0DD3C80 (locked by interrupt in process 508) sqh_refcnt = 1 sqh_meterp = C159F100


dump_stream

sqh_disable_interrupts = 0 sqh_sq_list_status_flags = 00x sqh_cpu_locked = -32

Example 6The 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 = C18CBB80

write_osrp = C18CE000

ioctl_osrp = C18CE180

poll_osrp = C18CE300

close_osrp = C18CE500

read_peekp = C18CB540

write_peekp = C18CB580

sth_ptr = C18CE800

STH = C18CE800

sth_flags = 00000000x

sth_polls = C18E45C0

sth_read_mode = 17

sth_write_mode = 1

sth_close_wait_timeout = 15000


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 READ SIDE

QUEUE = C18CE960 QUEUE = C18CE8C0

q_qinfo = C082D2B8 q_qinfo = C082D2F8

q_driver_tep = 00000000 q_driver_tep = 00000000

q_next = C18D05A0 q_next = 00000000

q_ptr = C18CE800 q_ptr = C18CE800

q_sqh_ptr = C18CE930 q_sqh_ptr = C18CE930

q_minpsz = 0 q_minpsz = 0

q_maxpsz = -1 q_maxpsz = -1

q_hiwat = 2048 q_hiwat = 8191

q_lowat = 1024 q_lowat = 6143

q_qlock = C0FBEA20 q_qlock = C0FBE9E0

Mblk Q Locked? no Mblk Q Locked? no

q_bandp = 00000000 q_bandp = 00000000

q_nbands = 0 q_nbands = 0

q_mem_pool = 0 q_mem_pool = 0

q_frozen = 0 q_frozen = 0

q_sq_full = 0 q_sq_full = 0

q_deferred_put_count = 0 q_deferred_put_count = 0

q_first = 00000000 q_first = 00000000

q_last = 00000000 q_last = 00000000

q_count = 0 q_count = 0

q_noenb = 0 q_noenb = 0

q_wantr = 1 q_wantr = 1

q_full = 0 q_full = 0

q_flag = 10x q_flag = 01x

QREADR set

QSAMESTR set

q_wantr set q_wantr set

Q Locked? no Q Locked? no

Svc Scheduled? no Svc Scheduled? no

NEXT LEVELS QUEUES


dump_stream

QUEUE Name: mi_timod


QUEUE = C18D05A0 QUEUE = C18D0500

q_qinfo = D33E9018 q_qinfo = D33E9068

q_driver_tep = C18CF8C0 q_driver_tep = C18CF8C0

q_next = C18CEBE0 q_next = C18CE8C0

q_ptr = C18D06C0 q_ptr = C18D06C0

q_sqh_ptr = C18D0570 q_sqh_ptr = C18D0570





q_qlock = C0FBEEA0 q_qlock = C0FBEE60


q_bandp = 00000000 q_bandp = 00000000






q_first = 00000000 q_first = 00000000

q_last = 00000000 q_last = 00000000






QREADR set

QSAMESTR set QSAMESTR set




NEXT LEVELS QUEUES

QUEUE Name: stcp


QUEUE = C18CEBE0 QUEUE = C18CEB40

q_qinfo = D337E818 q_qinfo = D337E8A8

q_driver_tep = C186BD00 q_driver_tep = C186BD00

q_next = 00000000 q_next = C18D0500

q_ptr = C18CEDC0 q_ptr = C18CEDC0

q_sqh_ptr = C18CEC50 q_sqh_ptr = C18CEBB0



q_hiwat = 98304 q_hiwat = 98304



dump_stream

q_qlock = C0FBEB20 q_qlock = C0FBEAE0


q_bandp = 00000000 q_bandp = 00000000






q_first = 00000000 q_first = 00000000

q_last = 00000000 q_last = 00000000






QREADR set

QSAMESTR set




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:


dump_stream

close: line 5295 in module iotv

read_raw: s$k_read_raw (kernel_trap_pa+17B38)

write_raw: s$k_write_raw (kernel_trap_pa+266D0)

set_no_wait_mode: line 1294 in module io_routines

set_wait_mode: line 1366 in module io_routines

start_logging: s$k_start_logging (kernel_trap_pa+20BE4)

stop_logging: s$k_stop_logging (kernel_trap_pa+212A0)

read_device_event: s$k_read_device_event (kernel_trap_pa+16FF8)

get_port_attachment: s$k_get_port_attachment (kernel_trap_pa+C8D8)

get_port_status: s$k_get_port_status (kernel_trap_pa+CCD4)

set_tasking_mode: line 1364 in module io_routines

get_port_info: line 553 in module io_routines

set_io_time_limit: line 1213 in module io_routines

poll: s$k_poll (kernel_trap_pa+314)

ioctl_str: s$k_str (kernel_trap_pa+54C)

peek: s$k_peek (kernel_trap_pa+DE0)

fdinsert: s$k_fdinsert (kernel_trap_pa+FC0)

getpmsg: s$k_getpmsg (kernel_trap_pa+BE0)

putpmsg: s$k_putpmsg (kernel_trap_pa+858)

Example 7The 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 = C18CE800

osr_ret_val = 0

osr_err = 0

osr_callback = sthi+2878, line 1344

osr_flags = 00000000x

osr_finished = TRUE

osr_state = 0

osr_istate = 0

osr_creds.cr_uid = 0

osr_creds.cr_gid = 0

osr_creds.sd_infop = 00000000


dump_stream

osr_bufcall_id = 00000000x

osr_type = READ

Read OSR Begin

osr_rw_total = 0000740Fx

osr_rw_flags = 00000000x

osr_rw_oia_argp = C18CB540x

osr_rw_oia_len = 00000000x

osr_ioctl_arg1 = 000503A4x

osr_ioctl_arg1_len = 00000000x

osr_ioctl_arg2 = 00000001x

osr_ioctl_arg2_len = 00000000x

Read OSR End

osr_time_limit = never

osr_xtrap = 00000000

osr_copy_mp = 00000000

osr_devp = C0E8D500

osr_sqhp = C18CE930

osr_dfreeq = 00000000

osr_ref_count = 0

osr_wait_lock = C0FBE320 (unlocked)

osr_acquires.num = 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 = 17

sth_write_mode = 1

sth_close_wait_timeout = 15000

sth_next = C186B400

sth_rq = C18CE8C0

sth_wq = C18CE960

sth_dev = 00BC0001x

sth_ref_cnt = 1

sth_dvtx = 1727 (stcp.st52_1)

sth_any_pse_mods_pushed = 1

sth_drv_priv = 0


dump_stream

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


QUEUE = C18CE960 QUEUE = C18CE8C0

q_qinfo = C082D2B8 q_qinfo = C082D2F8

q_driver_tep = 00000000 q_driver_tep = 00000000

q_next = C18D05A0 q_next = 00000000

q_ptr = C18CE800 q_ptr = C18CE800

q_ffcp = C18CEBE0 q_ffcp = 00000000

q_bfcp = 00000000 q_bfcp = C18CEB40

q_sqh_ptr = C18CE930 q_sqh_ptr = C18CE930





q_qlock = C0FBEA20 q_qlock = C0FBE9E0


q_bandp = 00000000 q_bandp = 00000000






q_first = 00000000 q_first = 00000000

q_last = 00000000 q_last = 00000000






QREADR set

QSAMESTR set




START OF SQH STRUCT

SQH = C18CE930


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 = -64

END OF SQH STRUCT

NEXT LEVELS QUEUES

QUEUE Name: mi_timod


QUEUE = C18D05A0 QUEUE = C18D0500

q_qinfo = D33E9018 q_qinfo = D33E9068

q_driver_tep = C18CF8C0 q_driver_tep = C18CF8C0

q_next = C18CEBE0 q_next = C18CE8C0

q_ptr = C18D06C0 q_ptr = C18D06C0

q_ffcp = C18CEBE0 q_ffcp = C18CE8C0

q_bfcp = C18CE960 q_bfcp = C18CEB40

q_sqh_ptr = C18D0570 q_sqh_ptr = C18D0570





q_qlock = C0FBEEA0 q_qlock = C0FBEE60


q_bandp = 00000000 q_bandp = 00000000






q_first = 00000000 q_first = 00000000

q_last = 00000000 q_last = 00000000






QREADR set

QSAMESTR set QSAMESTR set





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


QUEUE = C18CEBE0 QUEUE = C18CEB40

q_qinfo = D337E818 q_qinfo = D337E8A8

q_driver_tep = C186BD00 q_driver_tep = C186BD00

q_next = 00000000 q_next = C18D0500

q_ptr = C18CEDC0 q_ptr = C18CEDC0

q_ffcp = 00000000 q_ffcp = C18CE8C0

q_bfcp = C18CE960 q_bfcp = 00000000

q_sqh_ptr = C18CEC50 q_sqh_ptr = C18CEBB0



q_hiwat = 98304 q_hiwat = 98304


q_qlock = C0FBEB20 q_qlock = C0FBEAE0


q_bandp = 00000000 q_bandp = 00000000






q_first = 00000000 q_first = 00000000

q_last = 00000000 q_last = 00000000






QREADR set


dump_stream

QSAMESTR set




START OF SQH STRUCT

SQH_NEXT = 00000001 SQH_NEXT = 00000001

SQH_PREV = 00000001 SQH_PREV = 00000001

SQH_FIRST = 00000001 SQH_FIRST = 00000001

SQH_LAST = 00000001 SQH_LAST = 00000001

sqh_vos_lock = C0FBEAA0 sqh_vos_lock = C0FBEA60

sqh_refcnt = 1 sqh_refcnt = 1

sqh_meterp = C186BC40 sqh_meterp = C186BC40

disable ints = 0 disable ints = 0

sq_list_status_flags = 00x sq_list_status_flags = 00x

sqh_cpu_locked = -64 sqh_cpu_locked = -64

END OF SQH STRUCT

Related InformationSee the description of the search_streams request. For more information on VOS STREAMS, see the VOS Communications Software: STREAMS Programmer’s Guide (R306) and the IOA STREAMS Programmer’s Guide (R341).


dump_streams

dump_streams 8-

PurposeThe dump_streams request is a synonym for the previously described dump_stream request.


dump_syserr

dump_syserr 8-

PurposeThis request displays a buffer containing the most recent system error messages.

Display Form

Command-Line Formdump_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 numberDisplays 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.

----------------------------------- dump_syserr ---------------------------------all: o-last:-long: no

n


dump_syserr

ExplanationThe 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.

ExamplesIn 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



15:36:37 Process 0109891E, Overseer.System (Os.src_ctrl4F2A.0825153622BA), terminated.15:37:03 Process 0109891F, Overseer.System (Os.src_ctrl4F2A.082515370348), created.15:37:10 Process 0109891F, Overseer.System (Os.src_ctrl4F2A.082515370348), terminated.15:37:34 Process 01098920, Overseer.System (Os.src_ctrl4F2A.08251537346E), created.15:37:42 Process 01098920, Overseer.System (Os.src_ctrl4F2A.08251537346E), terminated.15:38:13 Process 01098921, Overseer.System (Os.src_ctrl4F2A.0825153813AF), created.15:38:22 Process 01098921, Overseer.System (Os.src_ctrl4F2A.0825153813AF), terminated.


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 to service07:34:54 tape 2202i 04/02/01/06 0 00000000 00000000 restored to service07:34:55 disk 2202i 04/01/01/01 EEEEE 00000000 00000000 restored to service07:35:10 bbc 8 add forcing dual initiation07:35:17 disk 2202i 06/01/01/01 EEEEE 00000000 00000000 restored to service07:35:17 tape 2202i 06/03/01/06 0 00000000 00000000 restored to service07:35:22 disk 0002i 06/01/01/03 EEEEE 00000000 00000015 device present07:35:22 tape 0002i 06/01/01/06 0 00000000 00000015 device present07:35:34 disk 0002i 04/04/01/05 EEEEE 00000000 00000015 device present07:35:41 tape 0002i 06/02/01/06 0 00000000 00000015 device present

as:


dump_tcb

dump_tcb 8-

PurposeThis 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

Command-Line Formdump_tcb channel_name[-address address] [-echo_table] [-enable_auto_echo]

Arguments* channel_nameThe 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 addressThe 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

------------------------------------ dump_tcb ----------------------------------channel_name: -address:-echo_table: no-enable_auto_echo: no


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.

ExplanationThe 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).

ExamplesIn the following example, the dump_tcb request displays information about the terminal control block for channel term.23.43.

as: dump_tcb term.23.43process ID 01132A14num input buffers 2num output buffers 1num col'n buffers 2conflict count 2channel number 11slot index 2slot number 4current line 1current line byte size 0chars_to_echo 0echoed_chars 0status: 80400000 0000 0000 00 listening initial_string_sentnumber of tabs 25modes 00080302 interrupt_key_enabled display_enable break_enabled output_flowoutput queued 0....next char to take 1


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 23cur n lines 1kill column 0kill line 23prompt chars ''continue chars '+'pause chars '--PAUSE--'first input buffer 004CD280last input buffer 004CE706first col'n buffer 0062FBA0cur col'n buffer 0062FBA0last col'n buffer 006095E4first active buffer 00000001last active buffer 00000001first inact buffer 00000001last inact buffer 00000001first echo buffer 004CEE12last echo buffer 004CEE12forms pointer 00000001forms text ptr 00000001forms values ptr 00000001field number 0code 0dwi.cur_char 0dwi.cur_size 0dwi.display_width 11111111111111111111111111110000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000old page faults 0input tally 30cur field byte offset 0input line cb ptr 005FBC92command line cb ptr 0062CC3Eline state dialedredisplay column 0open count 1clean point offset 0000clean point ptr 00000001dsl interrupts 2min collections 2max collections 10Break table: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFFbreak_effect 0protocol_ptr 00000001protocol_count 0


dump_tcb

form_buffer_size 0echo buffers queued 0top_window_size 0top_window_line 0top_window_column 0queued chars 0next queued char 1char queue ''type queue ''

form_abs_segs# of wired pages 0 0000 0000 0000 0000 rfi_offset 0000text_offset 0000values_offset 0000No error timeouttimers 45,0,0,47,0,0No runout deadlineNo hangup deadlineforms porte ptr 00000001config_data: baud 19200 stop_bits 1 parity oddlang info ptr 00552234echo_table_ptr 00000001enable_auto_echo_ptr 00000001init_cursor_row 0notify_if_zero 0fsi.config_info.ttep 001FBEE4fsi.config_info.current_config 0fsi.config_info.current_input_section 0fsi.config_info.last_col 79fsi.config_info.last_line 23fsi.config_info.last_page 1fsi.config_info.escape character ascii/60fsi.config_info.cursor format steady blockfsi.config_info.position_seq_len 7fsi.config_info.clear_mult_chars_len 64fsi.config_info.clear_eol_len 2fsi.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 0000fsi.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


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_cursorfsi.config_info.output_cap_flags: 80000000fsi.out_state.page 0fsi.out_state.reserved 0fsi.out_state.cp.valid_flags: 0000fsi.out_state.cp.flags: 0000....fsi.archaic_flags: 0000fsi.lines since pause 0fsi.saved_input_bytes ''working_kill_line 23working_kill_column 0as:


(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 andflow off char

The characters that the channel hardware uses for flow control

pause lines, The number of lines displayed before you see the -pause- message


dump_tcb

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.

(Page 2 of 3)

Fields Description


dump_tcb

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 006C534Aecho_table.version 1echo_table.characters(0) 0echo_table.characters(1) 0echo_table.characters(2) 0....echo_table.characters(255) 0echo_table.sequences(0) 0echo_table.sequences(1) 0....as:

Related InformationUse 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).

fsi.config_info.last_col

The last column number. Width is last_col+1.

fsi.config_info.last_line

The last line number. Height is last_line+1.

fsi.config_info.escapcharacter

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

(Page 3 of 3)

Fields Description


dump_tcbh

dump_tcbh 8-

PurposeThis request displays the terminal control block header (TCBH), which contains data used by the communications software.

Display Form

Command-Line Formdump_tcbh channel_name[-no_header] [-no_channels] [-locks] [-slot slot_number] [-channel channel_number]

Arguments* channel_nameThe 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.

------------------------------------ dump_tcbh ---------------------------------channel_name: -header: yes-channels: yes-locks: no-slot:-channel:


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_numberDisplays information about all channels of the communications controller in the specified slot.

* -channel channel_numberDisplays information about a specified channel on the communications controller specified with the -slot argument.

ExamplesIn 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 1

CONTROLLER IN SLOT 4

Lock address (virt) 80006088Lock address (phys) 80006088Vector number 130Global status 0000IOP No 1Interrupts 00000000Pending interrupts 00000000Comm buffer notify 00000000X25 buffer notify 00000000Being configured noTemporarily broken no


dump_tcbh

Processing error interrupt noModel C200 noModel K100 yesModel E593 noModel ENET noChannel Name CIP TCBP Type Status

OC17 81596A40 80085440 K111 07004A00 dsr dcdterm.17.0.2 815B6BC0 800857A0 K101 00000000tape.17.0 815B9920 00000001 UNKN 00000000tape.17.1 815B9A60 00000001 UNKN 00000000term.17.12.1 815B6D60 80085B00 K111 05004A00 dcdterm.17.12.2 815B6F00 80086000 K111 05000000 dcdterm.17.12.3 815B70A0 80086360 K111 05000000 dcdterm.17.12.4 815B7240 800866C0 K111 07004A00 dsr dcdenet.17.13 815B7460 8166EB00 K104 01000000 dsras:

The following table describes important fields that appear in the output of the preceding example.

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 field’s 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.


dump_tcbh

The following table describes columns in the channel information output.

The following table describes the abbreviations in the Status column.

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.

Status Column Abbreviation Description

cd Carrier detect

dcd Data carrier detect

dsr Data set ready

frm Framing error

int Interrupt

tbmt Transmit buffer empty


dump_tdr

dump_tdr 8-

PurposeThis request displays information about a task data region (TDR).

Display Form

Command-Line Formdump_tdr [-full] [-brief] [-task task_id]

Arguments* -full <CYCLE> Displays detailed information about one or more tasks.

* -brief <CYCLE> Displays limited information about one or more tasks.

* -task task_idSpecifies a task for which to dump the TDR entry; by default, the TDR entry for each task is dumped.

ExplanationTasking 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.

------------------------------------ dump_tdr -----------------------------------full: o-brief: no-task:

n


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 TDRE’s 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 TDRE TDRE TDRE

tdre_ptr_ptr


dump_tdr

ExamplesIn 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 33Using nonrunning process.Current process is 33, ptep 0492B780, Overseer.System (MailTransport1)as: dump_tdr

TDR @ 00845060

Flags:tasking_enabled ignore_preemption

n_tasks 3 current_task_num 1 n_static_tasks 3 max_n_tasks 3....

ready_list wait_list Task ID 1 @00845520 ready Task ID 3 @00845720 ready Task ID 2 @00845620 ready unready_list

Tasks: Num State saved_a6 term tid

1 ready 04723340 5 00000000-0000-0000 2 ready 0471B680 0 00000000-0000-0000 3 ready 04713680 0 00000000-0000-0000as:


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).


dump_tdr

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 1’s return stack starts.

stack_len A copy of the pdr.stack_len marking the stack length of task 1’s stack.

first_task_static_ptr The base address of task 1’s static area, which is obtained from the program module.

first_task_static_len The size of task 1’s 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

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.

(Page 2 of 3)

Field Description


dump_tdr

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.

(Page 3 of 3)

Field Description


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 entry’s 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 task’s stack frame pointer saved when the task last ran.

task_stack_base The position in the user stack which is the base of stack’s 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

First entry in the macro event structure. It is used to look up what the task is waiting on.


dump_tdr

wait_info.event_ count

Event count returned from the task’s 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.

(Page 2 of 2)

Field Description


dump_tpo

dump_tpo 8-

PurposeThis request displays information about the TPOverseer’s internal data structures.

Display Form

Command-Line Formdump_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.)

----------------------------------- dump_tpo --------------------------------structure: ll -match: -hash_tables: no -brief: yes

a


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.

ExplanationThis request displays values related to the TPOverseer.

ExamplesThe 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 @ 40C01030tp_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


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: 40D79FE0 40D79FE0 4144C4C0 4144C4C0 TSI free list num_entries: 5KWL list header: 40C010B0: 40FE8EC0 40FE8EC0 40FE8EC0 40FE8EC0 KWL free list num_entries: 1FLI list header: 40C010D8: 40FFC4A0 40FFC4A0 40FF6EB0 40FF6EB0 FLI free list num_entries: 3RRL list header: 40C01100: 40FCC600 40FCC600 40FED6E0 40FED6E0 RRL free list num_entries: 44RWL list header: 40C01128: 4144AE70 4144AE70 40FF2FF0 40FF2FF0 RWL free list num_entries: 4KRL list header: 40C01150: 40DDE7C0 40DDE7C0 40FD4AF0 40FD4AF0 KRL free list num_entries: 4GTID list header: 40C01178: 00000001 40C01178 00000001 40C01178 GTID free list num_entries: 0 num_precommitted_txns: 0 precommitted_gtid_list: 40C025A4: 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 TPOverseer’s 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: 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


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): 0num_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 40C025A4Structure tp_default_parameters @ 005FEB76 priority: 0 flags: noneStructure 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: 0000000000000000wait_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 00E2D920tlf_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: 00E42620Structure 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


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


dump_transaction

dump_transaction 8-

PurposeThis request displays information about a specific Transaction State Info (TSI) structure.

Display Form

Command-Line Formdump_transaction address[-brief] [-output_path file_name]

Arguments* address Required A standard analyze_system address string representing the TSI’s 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.


----------------------------- dump_transaction ------------------------------address: -brief: no -output_path:


dump_transaction

ExplanationThe dump_transaction request displays a single TSI structure and, optionally, a list of associated FLI structures.

ExamplesIn the following example, the dump_transaction request displays a TSI structure.

as: dump_transaction 80283740 -brief

Transaction_state_info: 80283740Transaction ID: 1F6EDF8B471116BD Commit ID: 0000000000000000Started on module: %se#m120 (71-17) at: 96-09-16 12:51:23 EDTStarted 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


dump_vm_pool_info

dump_vm_pool_info 8-

PurposeThis request displays information about the virtual memory pool on the analyzed module.

Display Form

Command-Line Formdump_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

-------------------------------- dump_vm_pool_info ------------------------------dump_free: es-dump_used: yes-header: no-by_tree: no-descending: no-show_links: no

y


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.

N O T E

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.

* -header <CYCLE>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.

ExplanationWhen 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.


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. ***

ExamplesThe 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 Owner C0923 12 (0000C) Streams MBLKS C092F 6 (00006) Streams Message Data C0935 8 (00008) Streams MBLKS

C093D 8 (00008) Streams Message Data C0980 8 (00008) pcp_stack C0988 16 (00010) I/O Heap 0 C0998 8 (00008) Comm Heap C09A0 288 (00120) net_buffer_pool_p$ C0AC0 32 (00020) I/O Heap 0 . . [... many lines removed ...] . ECE9A 28 (0001C) vterm.pm

ECEB6 28 (0001C) cache_manager_pages ECED2 11 (0000B) async_al.cp.pm ECEDD 284 (0011C) cache_manager_pages ECFF9 7 (00007) 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 ListStart Size OwnerC0945 58 (0003A) Merged Free BlockC0D3C 669 (0029D) Merged Free BlockC22B6 142640 (22D30) Merged Free Block


dump_vm_pool_info

E4FF4 12 (0000C) Merged Free BlockE51B0 31678 (07BBE) Merged Free BlockECDAA 6 (00006) 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: C1027340 Tail of block list: C0AF3C00 Root of used tree: C15961C8 Root of free tree: C1027F08 Lowest managed page: C0980 First page in main range: 00000 Highest managed page: ECFFF

Ultimate high page: FEFFF Pages managed: 181948

The following example illustrates the new, combined output.

as: dump_vm_pool_info -header

Virtual Memory Pool Header

Head of block list: C1027340 Tail of block list: C0AF3C00

Root of used tree: C15961C8 Root of free tree: C1027F08 Lowest managed page: C0980 First page in main range: 00000 Highest managed page: ECFFF Ultimate high page: FEFFF Pages managed: 181948

* Virtual Memory Pool * Size Flags Start Used Free (hex) OwnerC0923 12 (0000C) u Streams MBLKS C092F 6 (00006) u Streams Message Data C0935 8 (00008) u Streams MBLKS C093D 8 (00008) u Streams Message Data C0945 58 (0003A) f Merged Free Block C0980 8 (00008) u pcp_stack C0988 16 (00010) u I/O Heap 0 C0998 8 (00008) u Comm Heap C09A0 288 (00120) u net_buffer_pool_p$ C0AC0 32 (00020) u I/O Heap 0 C0AE0 16 (00010) u tape_buffers_p$

C0AF0 50 (00032) u Wired Heap 1


dump_vm_pool_info

[... many lines removed ...]

ECE9A 28 (0001C) u vterm.pmECEB6 28 (0001C) u cache_manager_pages

ECED2 11 (0000B) u async_al.cp.pm ECEDD 284 (0011C) u cache_manager_pages ECFF9 7 (00007) u Idle_3 fence/stack ------ ------ Total 6885 175063 Used 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 MBLKS C10273C0 C1027340 00000000 C092F 6 (00006) u Streams Message Data

C1586180 C10273C0 C1027340 C0935 8 (00008) u Streams MBLKS C1586200 C1586180 C10273C0 C093D 8 (00008) u Streams Message Data C15918C0 C1586200 C1586180 . .

.


ECFF5 1 (00001) u cache_manager_pages C153ED80 C153EF40 C1545500

ECFF6 1 (00001) u cache_manager_pages C153EBC0 C153ED80 C153EF40

ECFF7 1 (00001) u cache_manager_pages C10179C0 C153EBC0 C153ED80

ECFF8 1 (00001) u cache_manager_pages C0AF3C00 C10179C0 C153EBC0 ECFF9 7 (00007) u Idle_3 fence/stack 00000000 C0AF3C00 C10179C0 ------ ------ Total 6885 175063 Used Free


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 4–7 are on level 2, and nodes 8–15 are on level 3. The parent node’s key is always floor (my_key/2). An individual node’s 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. . .


. ECFF6 1 u cache_manager_pages C153ED80 C1545508 C10179C8 C1545888 63.


dump_vm_pool_info

ECFF7 1 u cache_manager_pagesC153EBC0 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 Nodes Density 0 1 1.000000 1 2 1.000000 2 4 1.000000 3 8 1.000000 4 16 1.000000 5 32 1.000000 6 64 1.000000 7 128 1.000000 8 128 0.500000 9 37 0.072266 10 29 0.028320 11 23 0.011230 12 12 0.002930 13 4 0.000488

Virtual Memory Pool Free Tree

Start Size Flags Owner This Left Right Parent Key

C0945 58 f Merged Free Block C15918C0 00000000 00000000 C112EF88 4. C0D3C 669 f Merged Free Block C112EF80 C15918C8 00000000 C1027F08 2. C22B6 142640 f Merged Free Block C1027F00 C112EF88 C15B2348 00000000 1. E4FF4 12 f Merged Free Block C101C5C0 00000000 00000000 C15B2348

6. E51B0 31678 f Merged Free Block C15B2340 C101C5C8 C1669F88 C1027F08 3. ECDAA 6 f Merged Free Block C1669F80 00000000 00000000 C15B2348 7.


dump_vm_pool_info

6 nodes on 3 levels

Level Nodes Density 0 1 1.000000

1 2 1.000000 2 3 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 Block E51B0 31678 f Merged Free Block E4FF4 12 f Merged Free Block C22B6 142640 f Merged Free Block C0D3C 669 f Merged Free Block C0945 58 f Merged Free Block

6 nodes on 3 levels


edit_vm_sizes

edit_vm_sizes 8-

PurposeThis 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.

C A U T I O N

Use this request only when instructed to do so by the CAC.

Display Form for XA/R-Series Modules

-------------------------------- as_edit_vm_sizes -------------------------------vm_size$tape_buffers: 6-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

1


edit_vm_sizes

Display Form for Continuum-Series Modules

Command-Line Formedit_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 numberThe 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 numberThe maximum number of pages the dump_disk and reload_disk commands use for dump disk I/O buffers. The default value is 2.

-------------------------------- as_edit_vm_sizes -------------------------------vm_size$tape_buffers: 6-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

1


edit_vm_sizes

* -vm_size$ui_abs_pages numberThe 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 numberOn 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 numberThe 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 numberThe 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 numberThe 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 numberThe 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 numberMaximum 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 numberMaximum 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 numberMaximum 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.


edit_vm_sizes

ExplanationBefore 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.

N O T E

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.


evaluate

evaluate 8-

PurposeThis request displays the hexadecimal value of the address specified in the address argument.

Display Form

Command-Line Formevaluate address

Arguments* addressThe 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.)

ExplanationYou 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.

ExamplesIn the following example, the evaluate request displays the address of an offset from the wired_heap$ external variable.

as: evaluate wired_heap$+10680C00106as:

------------------------------------ evaluate ----------------------------------address: *


evaluate

In the following example, the evaluate request works in a complementary fashion with the where request.

as: where 80C0010680C00106 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-50000000Aas:


event_count_meters

event_count_meters 8-

PurposeThis request displays the event count meters.

Display Form

Command-Line Formevent_count_meters[-first event] [-reset] [-no_report]

Arguments* -first eventSpecifies 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.

ExplanationAn 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

------------------------------ event_count_meters -----------------------------first:-reset: no-report: yes


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.

ExamplesIn 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 DELTA COUNT ATB /SEC NAME813C7880 26492511 47.8 20.9 socket for proc 0111802A813C4BE0 7720387 164.0 6.1 socket for proc 0111802980C10840 3836774 330.0 3.0 page_fault_event813C3CA0 2796241 452.8 2.2 socket for proc 01118026813C3BE0 1212203 1044.5 1.0 socket for proc 01118027813C0F40 655847 1930.6 0.5 socket for proc 0111802881658FA0 491879 2574.2 0.4 net_xmit80F539E0 429719 2946.5 0.3 device_event_for_tape.17.2813C7B40 305993 4138.0 0.2 socket for proc 0111802B813CF320 253366 4997.5 0.2 SERVER for overseer.one_way_serv 815D5100 231605 5467.0 0.2 net_xmit80C141A0 210758 6007.8 0.2 syserr_buffer_event8249ABE0 200815 6305.2 0.2 device_event_for_tape.17.682084980 193796 6533.6 0.2 device_event_for_tape.17.5813CF7C0 144114 8786.0 0.1 %es#m17>system>syserr_log_event81574BC0 125926 10055.0 0.0 net_xmit81743F00 104877 12073.1 0.0 socket for proc 0111803F80C103C0 99639 12707.7 0.0 stopped_process_event813D03C0 99442 12732.9 0.0 SERVER for batch.one_way_server_ 814AD680 84507 14983.2 0.0 socket for proc 0111802D8171A820 74283 17045.4 0.0 net_xmit81B232A0 54230 23348.4 0.0 net_xmit


event_count_meters

80F538A0 41181 30746.8 0.0 device_event_for_tape.17.1813CF620 22432 56445.5 0.0 ‘’80EC5080 20737 61059.3 0.0 TpOverseer Signal Event815B8420 19741 64139.9 0.0 socket for proc 0111802580EC47A0 18766 67472.3 0.0 TpOverseer Wait Event813CB700 17579 72028.3 0.0 ‘’816B7AE0 15925 79509.3 0.0 socket for proc 0111802C80C0FEA0 12377 102301.5 0.0 network_notify_event813C7C00 12084 104782.0 0.0 net_xmit815B8B00 11964 105833.0 0.0 socket for proc 0111801680EA1080 6394 198027.2 0.0 network change event80F51080 4491 281938.5 0.0 device_event_for_term.17.12.480F36AA0 4005 316151.3 0.0 %hq_net#d00>system>postoffice>registration.g+lobal.sysdb813C8F20 3566 355071.8 0.0 SERVER for overseer.server_queue80F5D440 3118 406089.2 0.0 net_xmit815511A0 1935 654359.7 0.0 socket for proc 011142DD81743E80 1658 763682.8 0.0 socket for proc 01114EBF.... 46053574 27.5 36.4 Total for 117 events.as:


Related InformationFor more information about events, see the descriptions of the dump_et and dump_events requests.

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.


find_string

find_string 8-

PurposeIn dump mode, this request enables you to search memory for specific string data.

Display Form

Command-Line Formfind_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.

ExamplesIn the following example, the find_string request displays the addresses for string matches found in a selected dump.

as: find_string Joe -no_hexASCII pattern ‘Joe’ found at address 8003B20E (kernel)ASCII pattern ‘Joe’ found at address 8003B38E (kernel)ASCII pattern ‘Joe’ found at address 8003B60E (kernel)....ASCII pattern ‘Joe’ found at address 3FF2718C (process 1060)....as:

----------------------------------- find_string --------------------------------search_string: -hex: yes


frame

frame 8-

PurposeThis request either sets the default stack frame address to the address specified or displays the default stack frame address.

Display Form

Command-Line Formframe address

Arguments* addressAn 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.

ExplanationThe 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 F’s, 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

------------------------------------- frame ------------------------------------address:


frame

Before issuing a frame request, you can issue the stack request to display the addresses from which to select the address value.

ExamplesThe 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 exampleUsing nonrunning process.Current process is 801, ptep 82146C40, John_Doe.Stratus (example)as: tracegive_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 80692AF8kernel_trap$ fp: 3FF78FC0 pc: 807CC0FC (s$k_sleep+5C) On-units at 807B4808s$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 80826760Trace 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 1400008080 8461FFE2 addu -30,r3,r100008084 A0310000 mov r1,r1700008088 8461FFE4 addu -28,r3,r10000808C A0300000 mov r1,r1600008090 6C00001A call +108(pc) =000080FC00008094 A0000000 nop


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 sign- extends 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 &se43FEA9F44 0 00096000 |..`. |as: d &sfe43FEA9F44 0 00096000 |..`. |as: d &sffe43FEA9F44 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: ..display_line (calc 96000x / 1024) 600

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 |..`. |


fstack

fstack 8-

PurposeThis request displays a forward stack trace.

Display Form

Command-Line Formfstack stack_address

Arguments* stack_address RequiredA stack frame address. Issue the trace request to obtain a value for this argument.

* -speculateThis 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.

------------------------------------- fstack ------------------------------------stack_address: -speculate: no


fstack

ExplanationUnlike 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.

C A U T I O N

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.

ExamplesIn 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 CPU28as: process 2400Using nonrunning process.Current process is 2400, ptep 81C4C9E0, Joe_Smith.Engas: tracegive_up_cpu fp: 3FF6FF50 pc: 80525124 (give_up_cpu_i+1564, line111)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 80635A98kernel_trap$ fp: 3FF78FC0 pc: 807A1848 (kernel_trap_i+16CB8)

On-units at 8078A768s$sleep fp: 3FEA9A40 pc: 806888A0 (task_control+4030, line 1121)s$sleep_glue fp: 3FEA9A80 pc: 0001AF20 (s$paged_glue+670)sleep fp: 3FEA9AC0 pc: 0001239C (sleep+9C, line 42)


fstack

main fp: 3FEA9B20 pc: 00008148 (t1+148, line 24)s$start_c_program fp: 3FEA9F60 pc: 00008574 (s_start_c_program+314, line+0)

On-units at 3FEA9B30start_user_program fp: 3FEA9F90 pc: 807E1C04 (start_user_program_i+3D4)

On-units at 80822D20Trace complete.as: fstack 3FEA9F90start_user_program fp: 3FEA9F90 pc: 807E1C04 (start_user_program_i+3D4)s$start_c_program fp: 3FEA9F60 pc: 000083A8 (s_start_c_program+148, line+8)s$allocate_glue fp: 3FEA9E00 pc: unknownCannot find any more forward frames.as:

Related InformationSee 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.


help

help 8-

PurposeThis request displays the available analyze_system requests.

Display Form

Command-Line Form help [-match string]

Arguments* -match stringDisplays all the analyze_system request names that contain string. If you omit this argument, all request names are displayed.

ExamplesIn the following example, the help request displays a list of the requests containing the word list.

as: help -match listget_list_headerlist_boardslist_breakslist_comm_dumpslist_diskslist_dumpslist_global_portslist_iop_dumpslist_paramslist_port_attachmentslist_transaction_tracelist_transactions

-------------------------------------- help -------------------------------------match:


interrupt_meters

interrupt_meters 8-

Purpose This request displays a breakdown of which devices are generating interrupts the interrupt meters.

Display Form

Command-Line Forminterrupt_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.


* -l7 <CYCLE> Specifies level-7 (highest priority) interrupts.

ExplanationAn 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

------------------------------ interrupt_meters -----------------------------reset: o-report: yes-l7: no

n


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.

ExamplesIn 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_metersMetering time: 0:45:00

Per-vector interrupt meters

VEC DEVICE INTERRUPTS AVG ms ATB ms #/SEC MAX ms >50ms 2 Slot-2 137546 0.09 19.83 50.4 25.63 0 4 Slot-4 12774 0.11 213.56 4.7 2.12 0 5 Slot-5 1364 0.03 2000.00 0.5 0.56 0 25 Recc-Console 1682 0.06 1621.88 0.6 0.40 0 29 System Timer 215967 0.14 12.63 79.2 3.08 0


interrupt_meters

Per-CPU interrupt meters

CPU INT_TYPE INTERRUPTS AVG ms ATB ms #/SEC 0 real ints 363211 0.12 7.51 133.1 1.6%

0 subtotal 363211 7.51 133.1 1 real ints 6119 0.12 445.82 2.2 0.0% 1 subtotal 6119 445.82 2.2 total 369330 7.39 135.4

Per-module interrupt step meters

INTERRUPTS AVG ms ATB ms #/SEC Busy 15970 0.08 170.82 5.9 Idle 860536 0.05 3.17 315.4 Total 876506 0.05 3.11 321.3as:

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 DEVICE INTERRUPTS AVG ms ATB ms #/SEC MAX ms >50ms 64 bad interrupt 24040 0.14 52785.32 0.0 0.44 0 66 maint 379 0.11 ********* 0.0 0.31 0 69 system timer 173361633 0.12 7.32 136.6 3658.13 35156 link-1 (18) 122148692 0.20 10.39 96.3 391.31 289157 link-2 (19) 122294062 0.20 10.38 96.4 313.61 321160 iop-1 (4,5) 16803432 0.45 75.52 13.2 1253.92 9161 iop-2 (6,7) 14155063 0.38 89.65 11.2 3796.91 71162 iop-3 (8,9) 43929652 0.38 28.89 34.6 209.18 53174 Disk Vector 2283 0.47 555829.60 0.0 1.50 0175 Disk Vector 33335 0.67 38066.87 0.0 260.99 1176 Disk Vector 73377 0.49 17293.69 0.0 87.78 6

Per-CPU interrupt meters

CPU INT_TYPE INTERRUPTS AVG ms ATB ms #/SEC 30 bad ints 23676987 53.59 18.7 30 null ints 215853825 5.88 170.1 30 real ints 99024708 0.18 12.81 78.0 1.4%30 subtotal 338555520 3.75 266.8

31 bad ints 26079628 48.66 20.6 31 null ints 203736074 6.23 160.6 31 real ints 139908696 0.22 9.07 110.3 2.4% 31 subtotal 369724398 3.43 291.4 29 bad ints 24037933 52.79 18.9 29 null ints 199444193 6.36 157.2 29 real ints 139558066 0.21 9.09 110.0 2.3%


interrupt_meters

29 subtotal 363040192 3.50 286.1 28 bad ints 24681218 51.41 19.4 28 null ints 220389631 5.76 173.7 28 real ints 114380884 0.18 11.09 90.1 1.7% 28 subtotal 359451733 3.53 283.3 total 1430771843 0.89 1127.5

Per-module interrupt step meters

INTERRUPTS AVG ms ATB ms #/SEC Busy 66016696 0.27 19.22 52.0 Idle 826873141 0.10 1.53 651.6 Total 892889837 0.12 1.42 703.6as:

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.


interrupt_meters

Related InformationFor more information about interrrupts, see the description of the sim_int_meters request.


list_boards

list_boards 8-

PurposeThis request displays information about a specified board, all boards of a specified type, or all of the boards in the analyzed module.

Display Form

Command-Line Formlist_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 numberThe 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.

--------------------------------- list_boards -----------------------------------long: o-slot:-board_type:-interval:

n


list_boards

* -interval numberDisplays 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.

ExamplesIn 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


list_boards

5 SCSI-ENET Controller K45000 533 39 13 0BU Bus ***** *** 0BA Bus A ***** *** 0BB Bus B ***** *** 0C0 Console Controller E59300 142 26 11 0C1 *Console Controller E59300 208 26 11 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 -longModule: %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 # 1 model number G805 Serial Number 10657 submodel number 0 revision 0 artwork rev 0

Subassembly # 2 model number G805 Serial Number 10658 submodel number 0 revision 0 artwork rev 0


list_boards

Subassembly # 3 model number G805 Serial Number 10669 submodel number 0 revision 0 artwork rev 0...Memory Array size 1536 iCache size 1024 dCache size 1024 Number cpus 2 Clock speed 180 Ecc Time 3 Ecc Address 00000000 Ecc Syndrome 0

Wedgewood info Subassembly record

Callaway Status 00000002 Subassembly # 7 Memory base 00000000 Model number M707 Memory size 512 Serial Number 11431 Callaway id 00000000 submodel number 0 Ecc time 00000000 revision 40 Ecc address 0 artwork rev 0 Ecc syndrome Ecc count

Callaway Status 00000002 Subassembly # 8 Memory base 00000000 Model number M707 Memory size 512 Serial Number 11613 Callaway id 00000000 submodel number 0 Ecc time 00000000 revision 40 Ecc address 0 artwork rev 0 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


list_boards

Array Size: 1536MB. Fault Data: No Faults

Subassembly IDs:

Number Subassemblies 10

Subassembly # 1 model number M707 Serial Number 10281 submodel number 0 revision 0 artwork rev 0

Subassembly # 2 model number G306 Serial Number 0 submodel number 0 revision 0 artwork rev 0...as:

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 -longModule: %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


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.

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.


list_disks

list_disks 8-

PurposeThis request displays information about the disk drives in the analyzed module or in the system containing the analyzed module.

Display Form

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.

ExplanationThe list_disks request displays information about disk drives on the analyzed module, or about all disks in the system.

ExamplesIn the following example, the list_disks request displays information about the disks on a module.

as: list_disks W Disk Name ldtep DDN Disk Device Ids status L m1 00502018 m1.0 1 22/01/01 23/01/01 duplexed,verify L m1_d1 00503918 m1_d1.0 3 25/01/01 24/01/01 duplexed,verify

---------------------------------- list_disks -----------------------------------all: on


list_disks

600 queue entries, 0 queued. Disk queue head @ 00228FB4as:

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 ldtep DDN Disk Device Ids status L m1 00502018 m1 1 22/01/01 23/01/01 duplexed,verify L m1_d1 00503918 m1_d1.0 3 25/01/01 24/01/01 uplexed,verify R m2 001F61EC R m2_d1 001F9938 600 queue entries, 0 queued. Disk queue head @ 0022AEA4as:

The following table describes the most important fields that appear in the output of the previous examples.

Field Description

W Where (local or remote)

L Local (on the current module)

R 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 disk’s 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


list_dumps

list_dumps 8-

PurposeThis request displays the path names of all the dump files in a directory on a module.

Display Form

Command-Line Formlist_dumps[-module module_name] [-dir path_name]

Arguments* -module module_nameThe module for which to list the dump files. The default is the user’s current module, where analyze_system is being run.

* -dir path_nameThe 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.

---------------------------------- list_dumps -----------------------------------module: -dir:


list_dumps

ExplanationThe 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.

ExamplesIn the following example, the list_dumps request lists the dump files available on a module.

as: list_dumpsDumps 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.dumpas:


list_file_activity

list_file_activity 8-

PurposeThis request displays cache manager I/O activity counts for each file, index, or directory.

Display Form

Command-Line Formlist_file_activity[-min_io_count number] [-min_write_count number]

Arguments* -min_io_count numberDisplays 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 numberDisplays 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.

ExplanationThe 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.

----------------------------- list_file_activity --------------------------------min_io_count: -min_write_count: 0

0


list_file_activity

ExamplesIn 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_activityFile activity from ADT:AxTE DSK I/O #WRITS #WRITS NODEADDR NUM COUNT STARTD PENDNG TYPE PATHNAMEC33A3A40 7 1 0 0 ADTE %es#sc3>products>stcp>1-364.71+00>srcC2D9EF40 7 1 0 0 ADTE %es#sc3>products>stcp>1-364.71+00C2D6AE80 4 2 1 0 ADTE %es#m9>system>postoffice>ship_+to_dir>misC0EFE380 11 3 0 0 ADTE %es#vpg>vos_pool>Joe_Smith>+installC2D48F80 4 11 6 0 AFTE %es#m9>system>tcp_os>telnet_lo+gs>tlog807a.98-06-02.1C0FCCAC0 4 11378 11345 0 AFTE %es#m9>system>accounting>raw_a+cct_log.98-06-02C0F94EC0 3 78 0 0 AFTE %es#libs>r13.4>base>incl>bio_s+csi.incl.cC2D642C0 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.pmC0C87B00 4 5 1 0 AFTE %es#m9>Overseer>22.outC0C86BC0 4 5 1 0 AFTE %es#m9>Overseer>21.outC0C86940 4 5 1 0 AFTE %es#m9>Overseer>20.outC0C85E40 4 5 1 0 AFTE %es#m9>Overseer>19.outC0C85900 4 5 1 0 AFTE %es#m9>Overseer>18.outC0BBC2C0 5 1884 408 0 ADTE %es#sc2C0BBAF40 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 150File activity from ADT:AxTE DSK I/O #WRITS #WRITS NODEADDR NUM COUNT STARTD PENDNG TYPE PATHNAMEC0FCCAC0 4 11378 11345 0 AFTE %es#m9>system>accounting>raw_a+cct_log.98-06-02C0E35440 4 374 308 0 ADTE %es#m9>system>tcp_os>telnet_lo+gsC0E23AC0 4 2711 1803 0 ADTE %es#m9>system>queues>batchC0E23900 4 491 292 0 ADTE %es#m9>system>queuesC0C9F880 4 160053 159138 0 ADTE %es#m9>system>accounting


list_file_activity

C0C99980 4 1824 0 0 AFTE %es#m9>system>kernel_loadable_+library>telnet_al.cp.pmC2DAD4C0 3 440 299 0 ADTE %es#libs>r13.4>fixesC2D839C0 2 2421 1022 0 AFTE %es#sc1>db_prog>src_ctrl>contro+l1.dbfC0BF0700 4 21497 9081 0 ADTE %es#m9>system>command_libraryC0BEF7C0 4 573 326 0 ADTE %es#m9>OverseerC0CA2100 4 18551 17710 0 AFTE %es#m9>system>overseer.one_way+_server_queueC0CA0AC0 4 6617 4384 0 AFTE %es#m9>system>overseer.server_+queueC0C97300 4 2934 0 0 AFTE %es#m9>system>kernel_loadable_+library>sos.pmC0CA80C0 8 310 0 0 AFTE %es#dsk14>r14.1>compiler_pool>+14.1.0.dev.bm_pl168k.pmC2D849C0 9 1536024 0 0 AFTE %es#sc4>db_prog>vos_cfg_idx.dbfC3570E40 4 937 72 0 ADTE %es#m9>system>db_prog_install_d+ir>rdbms>mesg...as:


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 manager’s 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


list_iop_dump_switch

list_iop_dump_switch 8-

PurposeThis request enables you to list dump types for one or all IOPs or IOAs on a module.

Display Form

Command-Line Formlist_iop_dump_switch iop_slot[-ioa_slot number]

Arguments* iop_slotThe 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 numberSpecifies 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.

ExplanationThe 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

--------------------------- list_iop_dump_switch ---------------------------------iop_slot: -ioa_slot:


list_iop_dump_switch

ExamplesIn 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 switch is DEVICE_ONLY. IOP 28 IOA 0 dump switch is NO_DUMP. IOP 28 IOA 1 dump switch is NO_DUMP. IOP 28 IOA 2 dump switch is NO_DUMP. IOP 28 IOA 3 dump switch is FULL_SYSTEM. IOP 28 IOA 4 dump switch is NO_DUMP. IOP 28 IOA 5 dump switch is DEVICE_ONLY. IOP 28 IOA 6 dump switch is NO_DUMP. IOP 28 IOA 7 dump switch is NO_DUMP. IOP 28 IOA 8 dump switch is IOP_AND_SINGLE_IOA. IOP 28 IOA 9 dump switch is NO_DUMP. IOP 28 IOA 10 dump switch is NO_DUMP. IOP 28 IOA 11 dump switch is IOP_AND_SELECTED_IOAS. IOP 28 IOA 12 dump switch is NO_DUMP. IOP 28 IOA 13 dump switch is NO_DUMP. IOP 28 IOA 14 dump switch is NO_DUMP. IOP 28 IOA 15 dump switch is NO_DUMP.as:

Related InformationFor information about changing dump switches, see the description of the change_iop_dump_switch request.


list_iop_dumps

list_iop_dumps 8-

PurposeThis request lists the IOP dump files on a module.

Display Form

Command-Line Formlist_iop_dumps[-module module_name] [-dir directory_path_name]

Arguments* -module module_nameThe name of the module for which you want to list IOP dumps. By default, the request uses the current module.

* -dir directory_path_nameSpecifies 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.

ExplanationIssue 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.

-------------------------------- list_iop_dumps ------------------------------ -module: -dir:


list_iop_dumps

Examples In the following example, the list_iop_dumps request lists the iop dumps on a module.

as: list_iop_dumpsDumps 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.dumpas:

Related InformationFor more information about the use_iop_dump request, see the description in this manual.


list_port_attachments

list_port_attachments 8-

PurposeThis request displays information about ports attached to the current process or in the current dump.

Display Form

Command-Line Formlist_port_attachments

ExplanationThe 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.

ExamplesIn the following example, the list_port_attachments request lists the port attachements on a module.

as: list_port_attachmentsPORT 1 at 3FF6AEE8Portname: default_inputType: unknownPorte indirects to port 5

PORT 2 at 3FF6AF20Portname: terminal_outputType: unknownPorte indirects to port 5

PORT 3 at 3FF6AF58

---------------------------- list_port_attachments ---------------------------No arguments required. Press ENTER to continue.


list_port_attachments

Portname: command_inputType: unknownPorte indirects to port 5

PORT 4 at 3FF6AF90Portname: default_outputType: unknownPorte indirects to port 5

PORT 5 at 80384DA0Portname: terminalPathname: %sys#os_telnet_m2.27Type: unknownFlags: attached,hold_attachment,no_wait,hold_opening network_attachment,tasking,port_accounting system_port,count_down_driverAccess mode: Unknown access mode #0I/O type: port not open

PORT 6 at 82446160Portname: _aaaY7bZ9ZLqa0KswPathname: %sys#m1>system>error_codes.textType: sequential fileFlags: attached,open,hold_attachment,hold_opening port_accountingAccess mode: indexedI/O type: input

PORT 7 at 82446220Portname: _aaaY7bZ9ZLqa0KsOPathname: %sys#m1>system>command_library>analyze_system.pmType: fixed fileFlags: attached,open,hold_attachment,hold_opening port_accounting,system_portAccess mode: randomI/O type: input....as:

Related InformationFor information about the list_port_attachments command, see its description in the VOS Commands Reference Manual (R098).


list_streams_params

list_streams_params 8-

Purpose This request displays the STREAMS parameters that you can change.

Display Form

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.

ExplanationIn 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).

--------------------------- list_streams_params ------------------------- param_name:


list_streams_params

The following are STREAMS parameters; a detailed explanation follows the list.

daemon wait timememory wait timeflush memory agebalance memory agestale memory agebufcall hysteresissys max heap thresholdsys max heap numeratorsys max heap denominLO max heap thresholdLO max heap numeratorLO max heap denominMED max heap thresholdMED max heap numeratorMED max heap denominHI max heap thresholdHI max heap numeratorHI max heap denominstreams canput limitstreams daemon factorstreams 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


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; /* 1 to 4095 */sys max heap denominator = 8; /* >= sys_numerator * 2 */

lo max heap threshold = 0;lo max head numerator = 1; /* 0 to 4095 */lo max heap denominator = 16; /* >= lo_numerator * 4 */

med max heap threshold = 0;med max heap numerator = 1; /* 0 to 4095 */med max heap denominator = 32; /* >= med_numerator * 4 */

hi max heap threshold = 0;hi max heap numerator = 1; /* 0 to 4095 */hi max heap denominator = 4; /* >= 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.


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;

elselo_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.


list_streams_params

ExamplesThe 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) 60000 ms

memory wait time (ms) (memory_wait_time) 10000 ms

flush memory age (ms) (flush_memory_age) 250 ms

balance memory age (sec) (balance_memory_age) 20

stale memory age (hrs) (stale_memory_age) 192

bufcall hysteresis (bufcall_hysteresis) 10000

sys max heap threshold (sys_threshold) 0

sys max heap numerator [1 - 4095] (sys_numerator) 1

sys max heap denomin [1 - (num*2)](sys_denominator) 8

LO max heap threshold (lo_threshold) 0

LO max heap numerator [0 - 4095] (lo_numerator) 1

LO max heap denomin [1 - (num*4)](lo_denominator) 16

MED max heap threshold (med_threshold) 0

MED max heap numerator [0 - 4095] (med_numerator) 1

MED max heap denomin [1 - (num*4)](med_denominator) 32

HI max heap threshold (hi_threshold) 0

HI max heap numerator [0 - 4095] (hi_numerator) 1

HI max heap denomin [1 - num] (hi_denominator) 4

streams canput limit [100] (canput_limit) 100

streams daemon factor (daemon_factor) 3

streams max daemons (max_daemons) 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) 61440


list_tp_params

list_tp_params 8-

PurposeThis request displays the values of various TP debugging and tuning parameters.

Display Form

Command-Line Formlist_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.

ExplanationThis 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.

------------------------------- list_tp_params -------------------------------param_name:


list_tp_params

ExamplesThe following example illustrates the use of the list_tp_params request.

as: list_tp_params

TP Parameters:

transaction abort priority [0-9] (abort_priority) 5transaction abort wait time (ms) (abort_wait_time) 5000 mslock manager [off/on] (lock_manager) ondeadlock detection [off/on/log] (deadlocks) onlock conflict detection (lock_conflicts) no_loggingmin lock conflict time (ms) (conflict_timeout) 5000 mssyserr action when logging (syserr_action) 2 (dont_display)performance diags (perf_diags) offsection tsi limit (sect_tsi_limit) 24section block limit (sect_blk_limit) 100max resv blks per record [1-10] (max_blks_per_rcd) 10max resv blks per key [1-4] (max_blks_per_key) 4max resv blks for seq file [1-9] (max_seq_blks) 9


list_transaction_trace

list_transaction_trace 8-

PurposeThis request displays information about the specified number of recently completed transactions.

Display Form

Command-Line Formlist_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.

----------------------------- list_transaction_trace ----------------------------number: 0-reverse: no

2


list_transaction_trace

ExamplesIn 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: 1C71274D01116B65 Process ID: 01118032 Transaction Committed: User initiated commit. (finished) Time completed: 95-02-13 16:21:17 EST

Transaction ID: 1C71274D01116B66 Process ID: 0111829C Transaction Committed: User initiated commit. (started) Time completed: 95-02-13 16:21:17 EST

Transaction ID: 1C71274D01116B66 Process ID: 0111829C Transaction Committed: User initiated commit. (finished) Time completed: 95-02-13 16:21:17 EST

Transaction ID: 1C71274D01116B67 Process ID: 0111829C Transaction Aborted: User initiated abort. Time completed: 95-02-13 16:21:18 ESTas:

Related InformationFor more information about transactions, see the descriptions of the dump_tpo, dump_transaction, list_transactions, transaction_meters, and transaction_meters requests.


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

Command-Line Formlist_transactions

¢ £ [-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.

---------------------------- list_transactions -------------------------------list_addr: -list:-started_before: -state: all -brief: yes -output_path:

list_addr-list


list_transactions

* -list <CYCLE> Specifies an internal queue. The values are as follows:

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.


ExplanationThis request displays a list of TSI structures and, optionally, a list of each of their associated FLI structures.

alldriver_listflush_list

free_tsi_listfree_wait_listidle_wait_list

module_wait_listphysical_wait_listtpo_work_list


list_transactions

ExamplesAn 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: 802A48E0 Transaction ID: 1F8C4F56471183DA Commit ID: 1F8C44C600008308 Started on module: %se#m120 (71-17) at: 96-10-08 20:44:06 EDT Started by process: 50 on module %se#m120 (71-17) (process ID: 47118032)

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: 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


list_transactions

Transaction_state_info: 80395C00 Transaction ID: 1F8C4F56471183DC Commit ID: 1F8C44C60000830A Started on module: %se#m120 (71-17) at: 96-10-08 20:44:06 EDT Started by process: 53 on module %se#m120 (71-17) (process ID: 47118035) 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: 80395C70: 00000001 80395C70 00000001 80395C70

Transaction_state_info: 802BFDE0 Transaction ID: 1F8C4F56471183DD Commit ID: 1F8C44C60000830B Started on module: %se#m120 (71-17) at: 96-10-08 20:44:06 EDT Started by process: 51 on module %se#m120 (71-17) (process ID: 47118033) 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: 802BFE50: 00000001 802BFE50 00000001 802BFE50

free_wait_list There are no transactions on the free_wait_list. physical_wait_list There are no transactions on the physical_wait_list. module_wait_list There are no transactions on the module_wait_list. idle_wait_list There are no transactions on the idle_wait_list.


lock_meters

lock_meters 8-

PurposeThis request displays information about all of the kernel locks.

Display Form

Command-Line Formlock_meters address [-name lock_star_name] [-member member_lock_star_name] [-reset] [-no_report]

Arguments* address RequiredThe address of a member, group, or single lock node.

* -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.

---------------------------------- lock_meters --------------------------------address: -name:-member:-reset: no-report: yes


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.

ExplanationThe 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.

ExamplesThe following examples show output from the lock_meters request.

Example 1The 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 2The 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


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 3The 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 4In 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.


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.

N O T E

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 2357:58:56 group info: n_write_locks 4084575 n_spins_for_lock_word 7 (0.00% of locks)

n_lock_word_failures 2(28.57 % of n_spins_for_lock_word)

write_meters:n_waits 40 (0.00% of locks)mean_wait_time 14.007 ms mean_time_to_lock 14.633 us (estimated)

total_time_to_lock 459.8 s (estimated)n_member_attaches 2042375

n_member_detaches 2042200 member info: n_write_locks 43081060 n_read_locks 35429104 n_try_locks 61137

n_try_lock_failures 9 (0.01% of n_try_locks)n_spins_for_lock_word 34042 (0.04% of locks)

n_lock_word_failures 2214 (6.50% of n_spins_for_lock_word) write_meters: n_waits 49302 (0.11% of locks) n_false_notifies 2174 (4.41% of n_waits) mean_wait_time 57.160 ms

mean_time_to_lock 79.893 us (estimated) total_time_to_lock 3441.9 s (estimated) read_meters: n_waits 25012 (0.07% of locks) n_false_notifies 591 (2.36% of n_waits) mean_wait_time 8.226 ms mean_time_to_lock 20.293 us (estimated) total_time_to_lock 719.0 s (estimated)


lock_meters

Related InformationSee the description of the dump_lock and lock_summary requests for related information on locks and lock meters.


lock_summary

lock_summary 8-

PurposeThis request displays an ordered summary of important kernel lock statistics.

Display Form

Command-Line Formlock_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

--------------------------------- lock_summary --------------------------------name: -member:-threshold: 1-reset: no -report: yes


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.

ExplanationThe 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.


lock_summary

ExamplesIn the following example, the lock_summary request displays a write lock summary report.

as: lock_summary

Write Lock Summary: % % Mean TimeLock 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:34Disk group group members 00315760 17.3 0.0 0.063 80:14:34Paged Heap single lock 005BF930 7.2 0.0 0.015 80:14:34Wired Heap single lock 00313D20 4.7 0.0 0.014 80:14:34IOP_vos_lock_22 single lock 0053E5A0 3.9 0.0 0.014 80:14:34IOP_iop_lock_22 single lock 0053E4A0 3.7 0.0 0.014 80:14:34Task Event group members 005C1A10 2.5 0.0 0.014 80:14:34Event Control group members 005BFAC0 2.4 0.0 0.041 80:14:34Disk Allocators single lock 005C1E40 1.3 0.0 0.017 80:14:34

Total write locks: 14358220Total write lock time: 594.7 sMean time/write lock: 0.041 ms

The following is an example of a read lock summary report.

Read Lock Summary: % % Mean TimeLock Name Lock Type Address Share Busy To Lock(ms) Metering Time----------- ------------- ------- ----- ----- ----------- -------------Event Control group members 005BFAC0 99.9 0.0 0.017 80:14:34

Total read locks: 403000Total read lock time: 7.1 sMean time/read lock: 0.018 msas:


lock_summary


Related InformationRefer to the description of the dump_lock and lock_summary requests for related information on locks and lock meters.

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.


log_alignment_faults

log_alignment_faults 8-

PurposeThis request logs all alignment faults on a module or those for a specified process.

Display Form

Command-Line Formlog_alignment_faults[ptep pte_pointer] [-mode] [-no_reset]

Arguments* ptep pte_pointerLogs 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.

----------------------------- log_alignment_faults -----------------------------ptep: -mode: on-reset: yes



ExplanationThe 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.

N O T E

It is easiest to debug alignment faults generated by an executing application if that application is compiled with -table. Otherwise, the compiler’s 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.



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 InformationSee 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).


match

match 8-

PurposeThis 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

Command-Line Formmatch match_string [-and string] [-or string] [-min_lines number] [-no_and_first]

Arguments* match_stringThe 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 stringDisplays lines that contain this string and the match string.

* -or stringDisplays lines that contain this string or the match string.

-------------------------------------- match -----------------------------------match_string: -and:-or:-min_lines: 1-and_first: yes


match

* -min_lines numberDisplays 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.

ExplanationThe match request displays matching lines of output from the request issued subsequent to match.

ExamplesIn 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 3FFAA000 process_heap_ptr 3FFAA060 user_heap_ptr 0048C000 pdr_heap_size 00040000as:

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 00008000as:


monitor_net_trace

monitor_net_trace 8-

PurposeThis request traces StrataLINK network activity over a period of time.

Display Form

Command-Line Formmonitor_net_trace[-scan_interval milliseconds] [-output_path path_name]

Arguments* -scan_interval millisecondsSpecifies how often the request is to collect tracing information. The default is 1000 milliseconds or 1 second.

* -output_path path_nameSpecifies 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.

ExplanationThe 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.

------------------------------ monitor_net_trace -----------------------------scan_interval: 000-output_path:

1


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.

ExamplesThe 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_traceTRACE MODE = auto_stop

A B C D E F G H I J K L 0 1 S O ACPT 372 M2 nreq 18106->31001 rpt 00 tid B61F-0000 #0001 8 1 S I NOM 106 M2 data 31003->18106 rpt 00 tid B61F-0000 #0001 15 2 S O ACPT 110 M2 nreq 18106->31001 rpt 00 tid B621-0000 #0001 21 2 S I NOM 92 M2 data 31003->18106 rpt 00 tid B621-0000 #0001 29 1 S O ACPT 334 M2 nreq 18106->31001 rpt 00 tid B622-0000 #0001 43 1 S I NOM 78 M2 data 31003->18106 rpt 00 tid B622-0000 #0001 50 2 S O ACPT 134 M2 nreq 18106->31001 rpt 00 tid B623-0000 #0001....as:

The following table describes the columns that appear in output of the preceding example.

(Page 1 of 4)

Column Description

A 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.

B The link or ring number, in the range from 1 to 8.

C The type of ring: subring (S) or backbone ring (B).

D The direction of data in relation to the reporting module: input (I) or output (O).


monitor_net_trace

E The reply status returned by VOS.NOM (no match): This value is normally traced for incoming packets becausethe trace occurs before the receiving link controller changes the packet statusto ACPT. A value NOM for an output packet trace means that no station onthe 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 despiterepeated retries. TMR (too many retries): The transmitting station has exceeded the board’serror retry threshold for a particular socket.DEAD: VOS is no longer running on the destination station.

F The length of the data portion of the packet.

G 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 identificationNS: notify shadow protocol, cross module event notification.ME: old message exchange protocol (prior to Release 11)LD: link diagnostics protocolTI: time protocolTU: tourist protocol, used to determine network topologyTR: trace control protocolHT: hardware self test protocolBM: boom protocol, network boomerang testingTF: test traffic protocolLB: link boot protocolUK: unknown packet type (for cross-release compatibility)

(Page 2 of 4)

Column Description


monitor_net_trace

H 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 whenthe 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 currentlywaiting for input.wory (worry) : Sent by a client to a server when the client has not received atimely answer. If the server is currently processing the request, it ignores thewory and sends the data packet. If a server has already replied to thenetwork transaction, it sends terr. If a client receives no response aftersending repeated wory packets, it reports a “worry timeout” to thesyserr_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 moduleschk/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 receivingstations)

(Page 3 of 4)

Column Description


monitor_net_trace

Stopping OutputWhen 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 OutputThe 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.

I 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

J The repeat switch. 1 indicates software and 2 indicates hardware.

K 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.

L The sequence number of the packet for disassembly and reassembly.

(Page 4 of 4)

Column Description


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 InformationFor more information on StrataLINK network tracing, see the descriptions of the display_net_trace and set_net_trace requests.


page_meters

page_meters 8-

PurposeThis request displays the page meters.

Display Form

Command-Line Formpage_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.


ExplanationAll 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.

---------------------------------- page_meters ---------------------------------reset: o-report: yes

n


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 module’s 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 page- fault 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.

ExamplesIn 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: 131072

Wired pages: 7476

Temp-wired pages: 2886

Free pages: 113396

Kernel in-memory pages: 744

Paged in-use pages: 7306

Total ATB/msec

Page faults: 1235193 145

Kernel page faults: 648 277348

Average page fault time: 1.34 msec


page_meters

Total ATB/msec

New pages: 556172 323

Reads: 773370 232

Disk: 66922 2685

Null: 577650 311

No I/O: 128798 1395

Reclaimed: 2918 61590

Writes: 495 363074

Posts: 67417 2665

Posts queued: 118 1523067

Max post queue depth: 2

Get memory Total ATB/msec

Free taken: 712272 252

memory waits: 0

Paging daemon Total ATB/msec

Evictions: 0

Evict writes: 0

Virtual buffer wires: 2616 68701

Virtual buffer unwires: 2452 73296

PMB inits: 1683 106786

PMB destroys: 1630 110258

PM disconnects: 10117 17764

Physical frames: 648274 277

Map clears: 943119 190

Clears w/trailers: 0

APTEs in use: 12920

APTE allocates: 790455 227

APTE frees: 777535 231

PME finds: 32960999 5

PME creates: 2492864 72

VM File Operations Total ATB/msec

Trailer activations: 9248 19433

Trailer deactivations: 8716 20619

Trailer connects: 12874 13960

Trailer disconnects: 12687 14165

Pages activated: 308481

Paging Partition

Total pages: 100000

Free pages: 94322

Minimum free pages: 82561


page_meters

PC Lock Meters

Lock count: 5154719

Unlock count: 5154718

Loop count: 26617

Average loop time: 1.19 msec

as:

The following table describes the most important fields in the output of the preceding example.

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.


pme_status

pme_status 8-

PurposeThis request displays information about the process map entry (PME) or entries of the current process on the analyzed module.

Display Form

Command-Line Form pme_status [vpn] [last_vpn] [-kernel]

Arguments* vpnThe 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_vpnThe 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.

----------------------------------- pme_status ---------------------------------vpn: last_vpn:-kernel: no


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).

ExamplesIn the following example, the pme_status request displays process map entry information for a module.

as: pme_status

Processing PMEs for pte @ C1AC0B80

PME APTE APTE MME MME

VPN Flags ACC Flags address rc flags address

00002 code M v 00007D81 1 C A 01026FDE

00003 code M v 000005D2 1 C A 01026FDF

00004 code M v 00005397 1 C A 01026FE0

00005 code v 01026FE1 1

00006 code v 01026FE3 1

00007 code v 01026FE4 1

00008 code v 01026FE5 1

00009 code v 01026FE6 1

0000A code M v 00006CFE 1 C A 01026FE7

0000B code M v 0000036C 1 C A 01026FE8

0000C code v 01026FE9 1

0000D code M v 0000229F 1 C A 01026FEA

0000E code M v 00006721 1 C A 01026FEB

0000F code v 01026FEC 1

00010 code v 01026FED 1

00011 code v 01026FEF 1

00012 code v 01026FF0 1

00013 code v 01026FF1 1

00014 code v 01026FF2 1

00015 code v 01026FF3 1

00016 code v 01026FF4 1

00017 code v 01026FF5 1

00018 code v 01026FF6 1

00019 code v 01026FF7 1

0001A code v 01026FF8 1

0001B code v 01026FF9 1

0001C code v 01026FFA 1

0001D code v 01026FFB 1

0001E code v 01026FFC 1

0001F code v 01026FFD 1

....

as:


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

APTE Flags Possible values are:B - shared bufferC - cache managerD - must dumpE - I/O errorF - forked pageM - memory assignedP - per process W - waiting k - kernel pageo - CPU patchv - 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

MME flags Possible values are:A - access code for page (XA/R-series modules only)C - connected I - I/O in progressM - modified P - page faultR - Release MMEU - user I/O requestW- wiredf - evict free u - usedw - write

address For in-memory pages, the disk address of the backing store


power_summary

power_summary 8-

PurposeThis request displays information about the power loading on the analyzed module and the communications buses.

Display Form

Command-Line Formpower_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.

ExplanationThe 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).

---------------------------------- power_summary --------------------------------long: on


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.

N O T E

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.

ExamplesIn 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 slot: 04 bulk_load = 261.20 or 54.4% of max 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.


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 SCSI Port SCSI


00 RS-485 Status Controll E575 0.0





06 Tape Drive DDS-2 DAT ( T701 40.0


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 DC Bulk Loading = A + C = 335.0 or18.6%of max of 1800.0 watts

Odd DC Bulk Loading = B + C = 65.0 or3.6%of max of 1800.0 watts

Total DC Bulk Loading = A + B + C = 400.0 or25.0%of max of 1600.0 watts

Even Cabinet AC Power = A + C + D = 459.0 or26.2%of max of 1750.0 watts

Odd Cabinet AC Power = B + C + D = 189.0 or10.8%of max of 1750.0 watts

Total Cabinet AC Power = 524.0


** BIO slot: 04 bulk_load = 360.00


process

process 8-

PurposeThis request sets the analyze_system addressing context for subsequent process-specific requests.

Display Form

Command-Line Formprocess process_number[-user user_name] [-process_name process_name]

Arguments* process_numberEither 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_nameThe 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_nameThe name of the process to be set as the analyzed process.

------------------------------------- process ----------------------------------process_number: -user:-process_name:


process

ExplanationThe 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.

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.

ExamplesIn 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:

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


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 user’s process.

as: process -user Smith


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


Current process is 5, ptep 001B9B22, PreLogin.System (pre-login)

as:

N O T E

The first line of information that this request displays shows the current state of the process as running or nonrunning.


quit


quit 8-

PurposeThis request exits the analyze_system command and returns to command level.

Display Form

Command-Line Formquit

ExplanationThe quit request exits the analyze_system command and returns to command level. Note that the analyze_system -quit argument has the same effect.

Related InformationFor information about the analyze_system -quit argument, see the description of the analyze_system command.

------------------------------------- quit -------------------------------------No arguments required. Press ENTER to continue.

scan_area

scan_area 8-

PurposeThis 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

Command-Line Formscan_area area_address[-heap heap_name] [-sort sort_order] [-memory_pool sort]

Arguments* area_addressThe 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.

------------------------------------ scan_area ---------------------------------area_address: -heap:-sort: size-memory_pool: 0


scan_area

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.

Value Description




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)

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


scan_area

ExplanationA 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.

ExamplesIn 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: C23F9170 (0122B170)

Last available: C2431FF0 (01263FF0)

Free bytes: 00015840

Max size: 0000203E

Free limit: 0003BFFE

Dead space: 01084140

Area size: 001DFEB0 (480 pages)

Bucket(1) 0-32 00000001 (00000000) Number in bucket: 0

Bucket(2) 33-64 C12604F0 (000924F0) Number in bucket: 22



Bucket(5) 129-256 C2329FB0 (0115BFB0) Number in bucket: 24

Bucket(6) 257-512 C22F2EB0 (01124EB0) Number in bucket: 8

Bucket(7) 513-1024 C21296F0 (00F5B6F0) Number in bucket: 1

Bucket(8) 1025-up C22F49F0 (011269F0) Number in bucket: 29

USED FREE


scan_area

DV 5664 000AF440 0 00000000 Device Table

GP 1 0003E040 0 00000000 Global Port

ES 183 0001C980 0 00000000 NCT System Entry

LC 430 000180C0 8 00000600 Lock Info

TY 318 00015E40 0 00000000 Terminal Type Component

PT 294 0000F7C0 14 00005900 PORT Entry Block

TV 168 0000E640 0 00000000 I/O Transfer Vector

AF 96 00007800 3 00000500 AFTE Block

FI 188 00005E00 3 00000280 File Info Block

VT 1 00004040 0 00000000 Virtual Circuit Table

KP 108 00003600 0 00000000 Key Position

AD 53 00003500 9 00001C00 ADTE Block

EM 20 00003200 0 00000000 NCT Module Entry

EI 54 000030C0 2 00000340 EITE Block

KE 4 00002FC0 0 00000000 Kernel Entry List

AX 58 00002B80 0 00000000 AXTE Block

DU 85 00002A80 2 00000A40 Device User

NM 84 00002940 0 00000000 Net Message Info

DF 1 00002040 0 00000000 Disk Addresses to free

FW 43 00002000 0 00000000 Firmware Data Structure

LG 14 00001F80 0 00000000 Language Info

TX 2 00001680 0 00000000 Transaction State Info

CX 1 00001300 0 00000000 Completed Transaction Info

QH 16 00000F40 0 00000000 Queue File Header

NC 1 00000D80 0 00000000 Net Client Table

QE 21 00000AC0 0 00000000 Queue File Message Entry

DB 11 00000A80 2 00001D40 Dir Buffer Info

....

-------- -------- -------- --------

8098 001917B0 84 00015840

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: C23F9170 (0122B170)

Last available: C2431FF0 (01263FF0)

Free bytes: 00016CC0

Max size: 0000203E

Free limit: 0003BFFE

Dead space: 01084140

Area size: 001DFEB0 (480 pages)


scan_area


Bucket(2) 33-64 C125DF70 (0008FF70) Number in bucket: 22


Bucket(4) 97-128 C23F4770 (01226770) Number in bucket: 2

Bucket(5) 129-256 C230DE30 (0113FE30) Number in bucket: 22

Bucket(6) 257-512 C22F2EB0 (01124EB0) Number in bucket: 7

Bucket(7) 513-1024 C232BBF0 (0115DBF0) Number in bucket: 3

Bucket(8) 1025-up C22F49F0 (011269F0) Number in bucket: 31

USED FREE

!! 0 00000000 1 00000080 Virgin Split Block

** 1 00000030 0 00000000 Permanent Heap Overhead Bl

ock

AC 2 00000280 0 00000000 Access Control Hash Table

AD 47 00002F00 4 00001600 ADTE Block

AF 96 00007800 2 00000380 AFTE Block

AX 58 00002B80 0 00000000 AXTE Block

CM 1 00000040 0 00000000 Command Meters

CP 0 00000000 11 00007700 Create Process Info

CS 2 00000380 0 00000000 Control Sizes

CX 1 00001300 0 00000000 Completed Transaction Info

DA 0 00000000 6 000024C0

DB 11 00000B00 1 00001C40 Dir Buffer Info

DF 1 00002040 0 00000000 Disk Addresses to free

DL 1 00000040 0 00000000 Device Table Ptr List

DP 31 000007C0 0 00000000 DVTE Parameters

DR 1 00000040 0 00000000 Dump Disk Table

DT 1 00000300 0 00000000 ADT Header

DU 85 00002A80 2 00000A40 Device User

DV 5664 000AF440 0 00000000 Device Table

EI 54 000030C0 2 00000240 EITE Block

EM 20 00003200 0 00000000 NCT Module Entry

ES 183 0001C980 0 00000000 NCT System Entry

FI 188 00005E00 1 00000080 File Info Block

FL 1 00000500 0 00000000 Transaction File Lock

....

-------- -------- -------- --------

8080 001909F0 87 00016600

as:


scan_area

The following table describes the fields that appear in the header output of the preceding examples.

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.

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


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).


scan_area

Related InformationFor 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.


scan_streams_msgs

scan_streams_msgs 8-

Purpose This request summarizes STREAMS message usage.

Display Form

Command-Line Form scan_streams_msgs [-sort string] [-memory_pool string] [-use_mh_q] [-leaks_only]

Arguments* -sortSpecifies how to sort the summarized output. It has the following values.

• size—Sort by the number of bytes allocated (descending). This is the default value.

• count—Sort by the number of messages allocated (descending).

• caller_PC—Sort by the program counter of the last allocate or free caller.

• q_qinfo—Sort by the q_qinfo value of the last queue_t node the message was put to.

• free_size—Sort by the number of bytes in the free caches.

• free_count—Sort by the number of messages in the free caches.

--------------------------- scan_streams_msgs ------------------------- -sort: size -memory_pool: all -use_mh_q: no -leaks_only: no


scan_streams_msgs

* -memory_poolSpecifies 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_qWhen 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_onlyWhen 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.

ExplanationThe 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)


scan_streams_msgs

Examplesas: scan_streams_msgs

Count Size Free Cnt Free Sz Caller; Q_INFO

10578 015F3900 0 00000000 ad_wfunc+12E4, line 758; 00000000

10157 01513E80 0 00000000 ad_dlmux+3E0, line 132; 00000000

17533 0066BB80 0 00000000 allocb+2B59, line 1833; tcp (FE853918)

19704 0039BA00 0 00000000 receive+D9C, line 671; 00000000

469 0004CC00 0 00000000 stcp_link_service+3464, line 1826; tcp

(FE853918)

1260 0003B100 0 00000000 open+50C, line 278; 00000000

1252 0003AB00 0 00000000 open+16F4, line 1272; 00000000

472 0002C400 0 00000000 allocb+2B59, line 1833; 00000000

827 00026C40 0 00000000 tcp_stream+1E70, line 646; 00000000

827 00026C40 0 00000000 tcp_stream+1F04, line 654; 00000000

826 00026B80 0 00000000 tcp_stream+1DF4, line 640; 00000000

740 00022B00 0 00000000 open+1794, line 1277; sth (C082D3B8)

667 0001F440 0 00000000 tcp_ip+35C, line 169; 00000000

667 0001F440 0 00000000 tcp_ip+3F8, line 180; 00000000

583 0001B540 0 00000000 fast+368, line 211; 00000000

583 0001B540 0 00000000 fast+404, line 217; 00000000

388 00018400 0 00000000 lat_al_buffers+71D, line 302; 00000000

512 00018000 0 00000000 open+1794, line 1277; 00000000

384 00012000 0 00000000 sthi+4D1D, line 3236; 00000000

384 00012000 0 00000000 sthi+4D59, line 3239; 00000000

388 0000C200 0 00000000 lat_al_buffers+765, line 315; tcp

(FE853918)

14 00007700 0 00000000 ad_dlmux+3E0, line 132; sth (C082D3B8)

6 00006300 0 00000000 arp_stream+207C, line 829; 00000000

125 00005DC0 0 00000000 sthi+4041, line 2551; tcp (FE853918)

125 00005DC0 0 00000000 sthi+4065, line 2558; 00000000

98 00004980 0 00000000 lat_ai_init+7F9, line 331; 00000000

97 000048C0 0 00000000 lat_ai_init+4D4, line 215; 00000000

4 00002280 0 00000000 stcp_link_service+34E0, line 1851;

00000000

10 00000A00 0 00000000 udp_stream+17B4, line 395; 00000000

9 00000900 0 00000000 lat_al_buffers+71C, line 302; 00000000

9 000006C0 0 00000000 close+A08, line 594; sth (C082D3B8)

9 00000480 0 00000000 lat_al_buffers+764, line 315; tcp

(FE853918)

5 000003C0 0 00000000 close+C98, line 671; sth (C082D3B8)

1 00000380 0 00000000 loop+B38, line 178; 00000000

1 000000C0 0 00000000 timech+441, line 219; 00000000

1 000000C0 0 00000000 timech+82D, line 369; 00000000

1 000000C0 0 00000000 gateway+64C, line 301; 00000000

1 000000C0 0 00000000 raw+9D8, line 210; 00000000

0 00000000 1232 00072040 00000000; 00000000


scan_streams_msgs

0 00000000 5 00002A80 vos_pse+39A9, line 2646; 00000000

0 00000000 171 00059640 vos_pse+39A9, line 2646; sth (C082D3B8)

0 00000000 1 00000180 vos_pse+5AA9, line 4365; 00000000

0 00000000 2 00000180 sth+31A4, line 2317; sth (C082D3B8)

0 00000000 1 000000C0 sthi+4311, line 2684; sth (C082D3B8)

0 00000000 2 00000180 sthi+4941, line 2988; 00000000

0 00000000 4 00000300 sthi+4941, line 2988; sth (C082D3B8)

0 00000000 11 00000840 sutl+3F48, line 2383; 00000000

0 00000000 8 00000600 sutl+3F48, line 2383; sth (C082D3B8)

0 00000000 1 000000C0 stcp_link_service+1C18, line 675;

FE8054C0

0 00000000 27 0000E580 stcp_link_service+3280, line 1761;

FE8054C0

0 00000000 2 00000180 abort+4B8, line 173; 00000000

0 00000000 7 000063C0 ack+F58, line 877; 00000000

0 00000000 2909 0015B840 ack+F58, line 877; tcp (FE853918)

0 00000000 2036 00439A00 ip_tcp+594, line 273; 00000000

0 00000000 175 00008340 ip_tcp+594, line 273; tcp (FE853958)

0 00000000 1 000000C0 receive+510, line 311; 00000000

0 00000000 49 000024C0 receive+540, line 320; 00000000

0 00000000 2 00000180 receive+6D0, line 422; 00000000

0 00000000 1 00000180 resend+1720, line 978; 00000000

0 00000000 7 000024C0 send+BB0, line 722; 00000000

0 00000000 17 00000CC0 tcb+9DC, line 398; 00000000

0 00000000 12 00000900 tcb+A08, line 403; 00000000

0 00000000 8 00000600 tcb+A34, line 408; 00000000

0 00000000 36 00001B00 tcb+121C, line 870; 00000000

0 00000000 20 00000F00 tcb+1240, line 876; 00000000

0 00000000 8 00000600 tcb+12F4, line 926; 00000000

0 00000000 2219 00068040 tcb+14E8, line 1029; 00000000

0 00000000 9 000006C0 tcb+1620, line 1071; 00000000

0 00000000 7 00000540 tcb+1644, line 1078; 00000000

0 00000000 66 00002300 tcb+1878, line 1281; tcp (FE853918)

0 00000000 1 000000C0 tcp_stream+62AC, line 2779; tcp (FE853918)

0 00000000 3 00000240 tcp_stream+6E24, line 3279; tcp (FE853958)

0 00000000 4 00000400 lat_al_buffers+12A4, line 826; 00000000

0 00000000 407 00019EC0 lat_al_buffers+13FC, line 862; 00000000

0 00000000 4 00002200 lat_st_lrput+3CC, line 120; 00000000

0 00000000 143 00006B00 lat_st_lrput+454, line 149; lat_streams

(FE87DA40)

0 00000000 27 0000E580 lat_st_lrsrv+1758, line 655; 00000000

0 00000000 2 00000180 lat_st_lrsrv+1758, line 655; lat_streams

(FE87DA40)

0 00000000 3 00000240 udp_receive+8A8, line 245; udp (FE8AB0B0)

0 00000000 8 00004400 udp_receive+B14, line 355; 00000000

0 00000000 2 00001100 icmp+1F28, line 1105; 00000000

0 00000000 13 000009C0 ip_stream+5944, line 2860; ip (FE8E7338)

0 00000000 4 00000540 ip_stream+59C0, line 2873; 00000000


scan_streams_msgs

0 00000000 1 000000C0 ip_stream+59C0, line 2873; ip (FE8E7338)

0 00000000 9 000006C0 ip_stream+5D2C, line 2987; ip (FE8E7338)

0 00000000 42 00016500 arp+C3C, line 595; 00000000

0 00000000 6 00000480 arp+C3C, line 595; arp (FE8F8150)

0 00000000 42 00001500 tnmod+29E4, line 1360; 00000000

0 00000000 1353 002CEC80 ad_dlmux+A30, line 437; 00000000

0 00000000 66 00023100 ad_dlmux+BA8, line 516; 00000000

0 00000000 1 00000880 ad_dlmux+1308, line 754; 00000000

0 00000000 438 000305C0 ad_wfunc+1360, line 777; 00000000

0 00000000 13 000009C0 ad_wfunc+1360, line 777; ad (FE9B42B8)

0 00000000 105664 01498E40 ad_wfunc+18E4, line 994; 00000000

0 00000000 10 00000780 ad_wfunc+18E4, line 994; udp (FE8AB080)

0 00000000 102945 012D98C0 ad_wfunc+18E4, line 994; ad (FE9B42B8)

-------- -------- -------- --------

69717 037913C0 220267 031DCAC0


sched_lock_meters

sched_lock_meters 8-

PurposeThis request displays the VOS kernel scheduler lock meters.

Display Form

Command-Line Formsched_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.


ExplanationThe 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

------------------------------ sched_lock_meters -----------------------------reset: o-report: yes

n


sched_lock_meters

analyze_system. To use the meters set since boot time, delete the file as_meter_file.

ExamplesIn the following example, the sched_lock_meters request displays the scheduler’s lock meters.

as: sched_lock_meters

Metering time 50:01:31

LOCK NAME LOCKS /SEC LOOPS /SEC %LOCKS AVG MS/SEC

sim interrupt 44460373 246.9 48092 0.3 0.1 0.01 0

event table master 34732012 192.9 24164 0.1 0.0 0.00 0

single event 34494726 191.5 394896 2.2 1.1 0.11 0

broadcast 75697 0.4 0 0.0 0.0 0.00 0

free_slot 88065 0.5 0 0.0 0.0 0.00 0

hash table 21590 0.1 0 0.0 0.0 0.00 0

shadow 11033 0.0 0 0.0 0.0 0.00 0

timed 40664 0.2 25 0.0 0.0 0.04 0

Pool 0

process master lock 104452132 580.0 57698 0.3 0.0 0.00 0

single process 104451962 580.0 846247 4.7 0.8 0.02 0

process queue 70086726 389.2 856477 4.8 1.2 0.04 0

alarm queue 9574129 53.2 5250 0.0 0.0 0.01 0

alarm clock queue 11575 0.0 0 0.0 0.0 0.00 0

task timer queue 11535 0.0 0 0.0 0.0 0.00 0

stopped process queue 6488 0.0 0 0.0 0.0 0.00 0

global lock 30 0.0 0 0.0 0.0 0.00 0

memory management 5162988 28.7 26641 0.1 0.5 1.20 0

as:


sched_lock_meters


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.


sched_meters

sched_meters 8-

PurposeThis request displays the scheduler meters.

Display Form

Command-Line Formsched_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.


ExplanationThe 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

--------------------------------- sched_meters --------------------------------reset: o-report: yes

n


sched_meters

analyze_system. To use the meters set since boot time, delete the file as_meter_file.

ExamplesIn the following example, the sched_meters request displays the scheduler meters.

as: sched_meters


POOL 0 METER COUNT ATB /SEC

short_waits 13868451 13.0 76.8

schedule_calls 87936 2054.1 0.5

schedule_int_calls 33772162 5.3 187.0

schedule_nops 1265135 142.8 7.0

process_switches 6187130 29.2 34.3

processes_created 1586 113890.9 0.0

tachy_meters:

new_binding 1500479 120.4 8.3

same_cpu 13369139 13.5 74.0

twin_timeout 7702 23452.5 0.0

offboard_timeout 0

scheduling interrupts:

start_idle_cpu 7512078 24.0 41.6

looped_waits 7883716 22.9 43.6

looped_waits_aborted 7883715 22.9 43.6

try_master_wait_abort 1 ********** 0.0

sleeps 5603 32238.3 0.0

CPU time distribution

CPU CPU SECONDS INCREMENTS ATB /SEC AVG INC BUSY

CPU0 7673.10 9741873 18.5 53.9 0.8 4.2%

CPU1 3827.66 5132450 35.2 28.4 0.7 2.1%

CPUavg 5750.38 7437161 24.3 41.2 0.8 3.2%

as:


sched_meters


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.


search_streams

search_streams 8-

PurposeThis 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

Command-Line Formsearch_streams[-process process_id] [-from process_id] [-to process_id]

Arguments* -process process_idSpecify 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_idSpecify 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_idSpecify a process ID for this argument and for the -from argument in order to display the open streams for a number of processes.

-------------------------------- search_streams -------------------------------process: -from:-to:


search_streams

ExplanationThe 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.

ExamplesIn 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


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


Current process is 263, ptep 8154C360, Smith.Eng (cello_server22)

%se#tcp_238 10

===========

DEVICE = 8026A400

READ_OSRP = 8154CA60

STH_OSR = 8154CA60

osrq_next = 8154D090

osrq_prev = 8154D090

osr_sth = 8154D060

osr_ret_val = 0

osr_err = 0


search_streams

osr_callback = sthi+24E0, line 505

osr_pid = 8026A400x


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_type = READ

Rd/Wr OSR Begin

osr_rw_total = 00007428x


osr_rw_oia_argp = 80F0FFC0x


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 = 8154CB60

STH_OSR = 8154CB60

osr is not queued

osr_sth = 8154D060

osr_ret_val = 0

osr_err = 0

osr_callback = 00000000x

osr_pid = 8026A400x


F_OSR_NOFREE set

osr_finished = FALSE

osr_state = 0


search_streams

osr_istate = 0

osr_creds.cr_ref = 0

....



osr_type = WRITE

Rd/Wr OSR Begin

osr_rw_total = 00000000x


osr_rw_oia_argp = 00000000x


Rd/Wr OSR End

....

IOCTL_OSRP = 8154CC60

STH_OSR = 8154CC60

as:

Related InformationSee the description of the dump_stream request. For more information about VOS STREAMS, see the VOS Communications Software: STREAMS Programmer’s Guide (R306) and the IOA STREAMS Programmer’s Guide (R341).


set_byte

set_byte 8-

PurposeThis request sets the value of one or more bytes in the current environment.

C A U T I O N


Display Form

Command-Line Formset_byte start_address data[-check check_values] [-io] [-physical]

Arguments* start_addressThe 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 RequiredA string of one or more hexadecimal data values, separated by spaces, to which consecutive bytes beginning at start_address are set.

----------------------------------- set_byte -----------------------------------start_address: data: -check: -io: no-physical: no

*


set_byte

* -check check_valuesA 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.

ExplanationThe 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.

ExamplesThe 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 fm to

00FD4000 00 01

00FD4001 00 02

00FD4002 00 03

as:


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 fm to

00FD4000 01 04

00FD4001 02 05

00FD4002 03 06

as:

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 04 should be 01 --- check failed.

as:


set_cache_pin_parameters

set_cache_pin_parameters 8-

PurposeThis request enables you to set the cache manager buffer pinning parameters.

Display Form

Command-Line Formset_cache_pin_parameters [-pin_priority pin_priority] [-pin_count pin_count] [-set_flag] [-clear_flag]

Arguments* -pin_priority pin_prioritySpecifies 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_countSpecifies 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.

--------------------------- set_cache_pin_parameters --------------------------pin_priority: -pin_count:-set_flag:-clear_flag:



* -set_flag <CYCLE> Sets the flag to enabled or raise_count.

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.

ExplanationThe 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 OperationThe 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.



Disk Cache Operation with PinningWhen 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 buffer’s 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 PinningUse 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 PinningGiven 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



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 InformationSee the descriptions of the display_cache_pin_parameters, dump_cache_info, and dump_cache requests.


set_comm_thresholds

set_comm_thresholds 8-

PurposeThis 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.

C A U T I O N


Display Form

------------------------------ set_comm_thresholds ------------------------------async_error_interval: 0 -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

6


set_comm_thresholds

Command-Line Formset_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 secondsSets the interval, in seconds, for all asynchronous communications. The default is 60.

* -async_error_threshold max_error_countSets the error count that can occur in the set time interval for all asynchronous communications. The default is 500.


set_comm_thresholds

* -bsc_error_interval secondsSets the interval, in seconds, for BSC, FTPS (SIAC/NASDAQ), and RJE 2780/3780. The default is 60.

* -bsc_error_threshold max_error_countSets 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 secondsSets the interval, in seconds, for FAS, SWIFT, and CHIPS. The default is 60.

* -eft_error_threshold max_error_countSets the error count that can occur in the set time interval for FAS, SWIFT, and CHIPS. The default is 500.

* -r3270_error_interval secondsSets the interval, in seconds, for 3270 Terminal Support. The default is 60.

* -r3270_error_threshold max_error_countSets the error count that can occur in the set time interval for 3270 Terminal Support. The default is 500.

* -h3270_error_interval secondsSets the interval, in seconds, for 3270 Emulation. The default is 60.

* -h3270_error_threshold max_error_countSets the error count that can occur in the set time interval for 3270 Emulation. The default is 500.

* -hasp_error_interval secondsSets the interval, in seconds, for RJE HASP. The default is 60.

* -hasp_error_threshold max_error_countSets the error count that can occur in the set time interval for RJE HASP. The default is 500.

* -sdlc_error_interval secondsSets the interval, in seconds, for host SDLC and remote SDLC. The default is 60.

* -sdlc_error_threshold max_error_countSets the error count that can occur in the set time interval for host SDLC and remote SDLC. The default is 500.

* -lap_error_interval secondsSets the interval, in seconds, for LAPB. The default is 60.


set_comm_thresholds

* -lap_error_threshold max_error_countSets the error count that can occur in the set time interval for LAPB. The default is 1000.

* -g_comm_error_interval secondsSets the interval, in seconds, for the Generic Communications (GCOMM) driver. The default is 60.

* -g_comm_error_threshold max_error_countSets the error count that can occur in the set time interval for the GCOMM driver. The default is 500.

* -ps_error_interval secondsSets the interval, in seconds, for Poll/Select. The default is 60.

* -ps_error_threshold max_error_countSets the error count that can occur in the set time interval for Poll/Select. The default is 500.

* -visa_error_interval secondsSets the interval, in seconds, for VISA 3270. The default is 60.

* -visa_error_threshold max_error_countSets the error count that can occur in the set time interval for VISA 3270. The default is 500.

* -uart_error_interval secondsSets the interval, in seconds, for all communications products. The default is 60.

* -uart_error_threshold max_error_countSets the error count that can occur in the set time interval for all communications products. The default is 25.

* -mpx_g_comm_error_interval secondsSets the interval, in seconds, for communications products using the MPX GCOMM driver. The default is 60.

* -mpx_g_comm_error_threshold max_error_countSets the error count that can occur in the set time interval for communication products using the MPX GCOMM driver. The default is 500.

ExplanationThe 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.


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.

C A U T I O N

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 channel’s 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)


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)

Arguments Protocols Affected

Errors

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

510011211

-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

1102010

-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

5111

-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

120

-hasp_error_interval -hasp_error_threshold

RJE HASP Data set lead changes Bad I/O block exit status

120

-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

52020

2030101020


set_comm_thresholds

-lap_error_interval -lap_error_threshold

LAPB 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

52020

20301020

-g_comm_error_interval -g_comm_error_threshold

GCOMM Data set lead changes CRC errors Receiver overruns (transfer errors) I/O block overruns Device errors

520

203010

-ps_error_interval -ps_error_threshold

Poll/Select Data set lead changes Bad I/O block exit status

120

-visa_error_interval -visa_error_threshold

VISA 3270 Data set lead changes Bad I/O block exit status

120

-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-TCPNETBIOS,SNAGDLCChannel attach,UCOMM

Bad I/O block exit status 10

(Page 2 of 2)

Arguments Protocols Affected

Errors

Type Count


set_instruction

set_instruction 8-

PurposeThis request sets the value of one or more instructions in the current environment.

C A U T I O N


Display Form

Command-Line Formset_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 RequiredA set of assembly language instructions enclosed in single quotes.

* -check check_valuesset of assembly language instructions enclosed in single quotes, to which consecutive instructions beginning at start_address are compared. If you

-------------------------------- set_instruction ---------------------------------start_address: instruction: -check:

*


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.

ExplanationThe 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.

ExampleThe 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:


set_longword

set_longword 8-

PurposeThis request sets the value of one or more longwords in the current environment.

C A U T I O N


Display Form

Command-Line Formset_longword start_address data[-check check_values] [-io] [-physical]

Arguments* start_addressThe 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 RequiredA string of one or more hexadecimal data values, separated by spaces, to which consecutive longwords beginning at start_address are set.

-------------------------------- set_longword ---------------------------------start_address: data: -check:-io: no-physical: no

*


set_longword

* -check check_valuesA 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.


* -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.

ExplanationThe 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.

ExamplesThe 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 from to

00FD4000 00010002 12345678

00FD4004 12340000 00ABCDEF

as:

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 from to

00FD4000 12345678 87654321

00FD4004 00ABCDEF 00FEDCBA

as:


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 87654321 should be 12345678 --- check failed.

as:


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

Command-Line Formset_meter_file [meter_file_path] [-default] [-long]

Arguments* meter_file_pathA 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.

* -defaultWhen 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.

-------------------------------- set_meter_file ------------------------------meter_file_path: -default: no-long: no


set_meter_file

* -longWhen 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.

ExplanationThis 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.

ExamplesThe 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: set_meter_file (process_dir)>asmf

as:

Related InformationFor information about displaying the file status of the current meter file, see the description of the display_meter_file_info request.


set_net_timeout

set_net_timeout 8-

PurposeThis request sets the time limit for a module to complete any StrataLINK or StrataNET network operation.

Display Form

Command-Line Formset_net_timeout num_minutes

Arguments* num_minutes RequiredThe number of minutes to set as the time-out limit to complete any network operations.

ExplanationA 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

--------------------------------- set_net_timeout ------------------------------num_minutes:


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.


set_net_trace

set_net_trace 8-

PurposeThis request determines when StrataLINK data is sent to the 4096 byte circular tracing buffer.

Display Form

Command-Line Formset_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_numberSpecifies 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.

----------------------------------- set_net_trace --------------------------------mode: o-station: 0-exclude_boom: no

g


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.

ExplanationThe 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 InformationFor more information about StrataLINK-related analyze_system requests, see the descriptions of the display_net_trace, monitor_net_trace and set_net_timeout requests.


set_streams_param

set_streams_param 8-

PurposeThis request allows you to change the value of an individual STREAMS parameter.

Display Form-

Command-Line Form set_streams_param param_name param_value

Arguments* param_name Required The short name of the STREAMS parameter to be changed.

* param_value Required The desired value of the STREAMS parameter to be changed.

ExplanationThe 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.

---------------------------- set_streams_param --------------------------------- param_name: param_value:


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


set_tape_buffer_mode

set_tape_buffer_mode 8-

PurposeThis request sets the buffer mode of a tape drive to streaming or start-stop mode.

Display Form

Command-Line Formset_tape_buffer_mode device_name buffer_mode

Arguments* device_name RequiredThe name of the tape that you want to set the buffer mode for.

* 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.

ExplanationVOS 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.

------------------------------ set_tape_buffer_mode ----------------------------device_name: buffer_mode: start_stop


set_tp_param

set_tp_param 8-

PurposeThis request modifies the values of a TP debugging/tuning parameter.

Display Form

Command-Line Formset_tp_param param_name

param_value

Arguments* param_name Required The name of the parameter whose value is to be displayed.

* param_value Required The value to which the parameter will be set.

ExplanationThis 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.

------------------------------- set_tp_param -----------------------------------param_name: param_value:


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.


set_tp_param

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 andwrite_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.




set_tp_param

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

syserr_actionvalue

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.




set_word

set_word 8-

PurposeThis request sets the value of one or more words in the current environment.

C A U T I O N


Display Form

Command-Line Formset_word start_address data[-check check_values] [-io] [-physical]

Arguments* start_addressThe 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 RequiredA string of one or more hexadecimal data values, separated by spaces, to which consecutive words beginning at start_address are set.

----------------------------------- set_word -----------------------------------start_address: data: -check: -io: no-physical: no

*


set_word

* -check check_valuesA 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.


* -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.

ExplanationThe 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.

ExamplesThe 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 from to00FD4000 0000 000100FD4002 0000 000200FD4004 0000 1234as:


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 from to00FD4000 0001 000500FD4002 0002 000600FD4004 1234 0007as:

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 0005 should be 0001 --- check failed.as:


setup_user_program

setup_user_program 8-

PurposeIn dump, program module (file), or partition mode, this request sets the path of a program module that has been moved or deleted.

Display Form

Command-Line Formsetup_user_program user_program_path_name

Arguments* user_program_path_nameThe 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.

ExplanationIn 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.

---------------------------- setup_user_program --------------------------------user_program_path_name:


sim_int_meters

sim_int_meters 8-

PurposeThis request displays the simulated interrupt meters.

Display Form

Command-Line Formsim_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.


ExplanationWhen 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.

-------------------------------- sim_int_meters ----------------------------------reset: o-report: yes

n


sim_int_meters

ExamplesIn the following example, the sim_int_meters request displays the simulated interrupt meters.

as: sim_int_meters

Metering time 353:45:54

HANDLER CALLS AVG TIME ATB LONGEST LONG

time_event_notify 43941 0.29 28983.27 1.25 0

check_dead_cpu 21220 0.10 60016.68 0.46 0

scheduler timer 6300078 0.16 202.15 3657.44 1

update_load_meters 1272493 0.20 1000.83 2.93 0

check_for_missing_ints 42439 0.76 30009.05 3.40 0

disk_run 127283 3.62 10005.69 865.54 1

iop_ring_checker 688 0.37 ********* 37.19 0

lcd_interrupt_handler 254530 1.83 5003.55 41.23 0

net_sip_timeout 253955 0.19 5014.88 2.03 0

net_retry_timeout 7764 0.25 164033.20 0.81 0

di_interrupt_check 79054 1.03 16109.93 233.69 0

di_disk_retry 160 14.07 ********* 2182.10 1

fastq_status_timeout 18151 0.43 70164.40 1.68 0

increment_free_counter 12713510 0.06 100.17 0.84 0

comm_interrupt, @351 61 2.18 ********* 3.27 0

Streams Timer 25882804 0.08 49.20 2.06 0

TCP: 1 Sec 1274125 0.11 999.55 0.95 0

TCP: 1 Min 21244 0.63 59948.88 2.14 0

TCP: 1/2 Sec 2546803 0.17 500.06 9.75 0

TCP: 1/5 Sec 84228 0.43 15120.32 5.13 0

TCP: Sim Intr - IP Input 736250 0.49 1729.78 17.01 0

TELNET Server rsrv int 132086 1.78 9641.85 265.08 0

TELNET ACB timer int 437 0.35 ********* 0.90 0

Total 51813304 0.13 24.58

Total simulated interrupt time: 6553.96 seconds, 0.51%

as:


sim_int_meters


Related InformationFor more information about metering interrupts, see the description of the interrupt_meters request.

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.


sleep

sleep 8-

PurposeThis request puts the analyze_system command to sleep for a specified period, after which VOS reactivates the analyze_system command.

Display Form

Command-Line Formsleep [-hours hours] [-minutes minutes] [-seconds seconds] [-until date_time] [-forever ]

Arguments* -hours hoursPuts the analyze_system command to sleep for the specified number of hours. By default, the value of hours is 0.

* -minutes minutesPuts the analyze_system command to sleep for the specified number of minutes. By default, the value of minutes is 0.

* -seconds secondsPuts the analyze_system command to sleep for the specified number of seconds. By default, the value of seconds is 0.

------------------------------------- sleep -------------------------------------hours: -minutes:-seconds:-until:-forever: no


sleep

* -until date_timePuts 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.

ExplanationThe 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 InformationFor 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.


stack

stack 8-

PurposeThis request displays the contents of the stack belonging to the analyzed process.

Display Form

Command-Line Form stack stack_address[-brief] [-on_units] [-pc code_address] [-task number] [-machine_conditions address] [-unwind_data]

Arguments* stack_addressThe 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.

------------------------------------- stack ------------------------------------stack_address: -brief: no-on_units: no-pc:-task:-machine_conditions: -unwind_data: no


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_addressOn 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 numberWhen 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 addressOn 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 condition’s 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.

ExplanationThe 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 condition’s 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,


stack

you need to specify additional information with the -pc or -machine_conditions argument, and possibly, the -unwind_data argument.

ExamplesIn 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.

N O T E

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))


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)

3 args:

Arg 1: r16 = 3FEA8108 -> 00000000

Arg 2: r17 = ******** -> ********

Arg 3: r18 = ******** -> ********


stack

ksliwat 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 -> ********

kslwait 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

ksuclnwt fp: 3FEA8450 pc: 000F32A8 (ksucln+3828, line 10344)

2 args:

Arg 1: r16 = ******** -> ********

Arg 2: r17 = ******** -> ********

ksucln fp: 3FEA8500 pc: 000F3414 (ksucln+3994, line 10374)

1 args:

Arg 1: r16 = ******** -> ********

ksbrdp fp: 3FEA86A0 pc: 000ED42C (ksb+2A7C, line 9815)


opirip fp: 3FEA9210 pc: 0082AF10 (opirip+430, line 10634)

3 args:

Arg 1: r16 = ******** -> ********

Arg 2: r17 = 00000000 -> ********

Arg 3: r18 = 00000000 -> ********

opidrv fp: 3FEA9570 pc: 0082A604 (opidrv+544, line 11304)

3 args:

Arg 1: r16 = 00000032 -> ********

Arg 2: r17 = 00000000 -> ********

Arg 3: r18 = 00000000 -> ********

sou2o 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

opimai fp: 3FEA98C0 pc: 000087DC (opimai+11C, line 102)

2 args:

Arg 1: r16 = ******** -> ********

Arg 2: r17 = 008CF9B0 -> 013C18E0


stack

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)


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


1247)



line 197)



On-units at 80692AF8



On-units at 807B4808






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)


298)

On-units at 3FEA98E0


line 190)


stack

On-units at 3FEA9B10



On-units at 80826760

Trace complete.

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


1247)

2 args:

Arg 1: r16 = 81B82780 -> 011280FB

Arg 2: r17 = 3FF6FF80 -> 0000002A



line 197)

2 args:

Arg 1: r16 = ******** -> ********

Arg 2: r17 = 3FF78FAE -> 043902A6




On unit for the anyother condition at 80692AF8:

flags: enabled, ^snap, ^system, ûse_frame, ^shared,

^do_goto, âllow_reraise

handler: atlantic_waf_and_sis+550

fcb_ptr: 00000001




On unit for the anyother condition at 807B4808:



handler: i860_kernel_trap_support+4FC

fcb_ptr: 00000001




stack



3 args:

Arg 1: r16 = 3FEA8108 -> 00000000

Arg 2: r17 = ******** -> ********

Arg 3: r18 = ******** -> ********


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 -> ********


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

...


298)


On unit for the error condition at 3FEA98E0:



handler: se_service_condition_wrap+64, line 74

fcb_ptr: 00000001


line 190)


On unit for the error condition at 3FEA9B10:



handler: s_crt_sigassert+964, line 390

fcb_ptr: 00000001

On unit for the zerodivide condition at 3FEA9B30:



handler: s_crt_sigassert+A38, line 440

fcb_ptr: 00000001

On unit for the overflow condition at 3FEA9B50:




stack


fcb_ptr: 00000001

On unit for the underflow condition at 3FEA9B70:




fcb_ptr: 00000001

On unit for the break condition at 3FEA9B90:



handler: s_crt_sigassert+B98, line 529

fcb_ptr: 00000001

On unit for the user_defined condition at 3FEA9BB0:

name: _crt_kill



handler: s_crt_sigassert+F1C, line 727

fcb_ptr: 00000001

...

On unit for the user_defined condition at 3FEA9DB0:

name: _C_SIGABRT



handler: s_crt_sigassert+964, line 390

fcb_ptr: 00000001



On unit for the tasktimer condition at 80826760:

flags: enabled, ^snap, ^system, ûse_frame, shared,


handler: task_control+2C70, line 830

fcb_ptr: 00000001

Trace complete.

as:


status

status 8-

PurposeThis request displays information about the current analyze_system environment, including version of VOS, the analyzed program module, and the analyze_system command.

Display Form

Command-Line Formstatus [-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.

------------------------------------ status ---------------------------------- -dump_pages: o -dump_page_hash_table: no -controller_pages: no -modified_pages: no -brief: no

n


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.

ExplanationIf 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.

ExamplesIn 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



binder options: cbtsm


status

analyze_system program module info:

pathname: %es#m17>system>command_library>analyze_system.pm

version: Release 13md

bound by: Installer.Installer



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


as: use_dump 1


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


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: 95-01-31.13:52:47

dumped at 95-01-31 14:52:47 EDT

dumped on %sys#m1

Operating System bound at 94-11-16 14:15:52 EDT

partition 4


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:


summary

summary 8-

PurposeThis request lists the process names, numbers, and state of processes on the analyzed module.

Display Form

Command-Line Formsummary [-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.

------------------------------------ summary ------------------------------------full: o-running: no-pp_pages: no

nn


summary

ExplanationThe 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.

ExamplesIn 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.



....

as:


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:


2) system.98-06-15.11:41:18.c.dump

as: use_dump 2


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.






Crash message:

as: summary -running

Crash message:

No frame address for process 1, CPU28.Idle on CPU28





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:


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.


5: Cache_Manager_Locker in locker_wait.


6: CPU29.Idle in schedule_interrupt_real.





27: Kernel_Utility in wait_pi_real.


28: Maintenance_Utility in wait_pi_real.


29: Diagnostic_Utility in wait_pi_real.


33: Diagnostic_Utility in wait_pi_real.


37: Qrun_Daemon in qrun_daemon.


38: Paging_Daemon in paging_daemon_sleep.


40: System (TPOverseer) in s$$k_wait_event_util_real.


41: System (LinkServer1) in wait_masked_pi_real.






....

as:


terminal_meters

terminal_meters 8-

PurposeThis request displays the terminal meters.

Display Form

Command-Line Formterminal_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 channelDisplays statistics about a specified terminal device and summary information about all terminal devices attached to a module.

* -histogram <CYCLE> Displays input and output terminal data traffic.

ExplanationThe terminal_meters request displays the terminal meters.

------------------------------- terminal_meters -------------------------------all: o-channel:-histogram: no

nAn


terminal_meters

ExamplesIn the following example, the terminal_meters request displays terminal meter information.

as: terminal_meters

Function Count ATB

total input characters 9764 130475.6

total host echoed chars 42870 29716.9

total z80 echoed chars 0 0.0

total output characters 13727081 92.8

average input size 2.7

average output size 54.2

total breaks 3 424654700.0

total dialups 97 13133650.0

total read waits 2715 469231.7

total write waits 3488 365242.0

total interrupts 59090 21559.7

total reads 3224 395150.1

total writes 232738 5473.8

as:


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.


tpq_meters

tpq_meters 8-

PurposeThis request displays information about queues and pseudoqueues used in transaction processing.

Display Form

Command-Line Formtpq_meters[-no_header] [-reset] [-full] [-queues] [-data] [-no_report]

¢ [time_interval]£ [-output_path file_name]��

Arguments* -no_header <CYCLE> Suppresses the display of header information. By default, the request displays header information.

-------------------------------- tpq_meters ------------------------------------no_header: o -reset: no -full: no -queues:-data:-report: yes -interval:-output_path:

nAn

-interval


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


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 display’s format.


ExplanationThis request displays information about queues and pseudoqueues.

ExamplesThe following example illustrates the use of the tpq_meters request without the -interval argument specified.

as: tpq_meters

time meter wait_time busy_time arrive start complete

1:04:41 driver 1 0 2513 2513 2513 1:04:41 idle_wait 0 0 0 0 0 1:04:41 tlf_flush 324 0 845 845 845 1:04:41 phy_wait 63 0 845 845 845 1:04:41 section 0 595 845 845 844 1:04:41 to_twa 23 120 844 843 843 1:04:41 log_in_twa 69 464 843 843 843 1:04:41 in_twa 37 309 843 843 843 1:04:41 to_file 10305 816 843 833 831 1:04:41 file_info 10328 52 831 816 816 1:04:41 log_infile 349 465 816 816 816 1:04:41 mod_wait 0 0 0 0 0

1:04:41 running 523 1656 858 858 856 1:04:41 rmt_running 0 0 0 0 0 1:04:41 hold_rlocks 3766 1510 870 867 865 1:04:41 hold_wlocks 3767 3658 870 867 863

1:04:41 waiting 95448 108837 3885 3775 3642 1:04:41 retrying 124279 0 6386 6143 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.


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.


trace

trace 8-

PurposeThis request displays the contents of the stack belonging to the analyzed process. The trace request is similar to the stack -brief request.

Display Form

Command-Line Formtrace stack_address[-no_brief] [-on_units] [-pc address] [-task number] [-machine_conditions conditions] [-unwind_data]

Arguments* stack_addressThe 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.

------------------------------------ trace -------------------------------------stack_address: -brief: yes-on_units: no-pc: -task: -machine_conditions: -unwind_data: no


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 addressOn 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 numberThe 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 conditionsOn 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 condition’s 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.

ExplanationThe 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 condition’s 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.


trace

ExamplesIn 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: trace00FF1E50 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_units00FF1E50 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:



handler: line 866 in module hydra_switch_process


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:



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:



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, ûse_frame, shared,


handler: s$preempt_task (line 803 in module task_control)

fcb_ptr: 00000001

Trace complete.

as:


transaction_meters

transaction_meters 8-

PurposeThis 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:


transaction_meters

Command-Line Formtransaction_meters[-set_metering] [-no_header] [-reset] [-no_report]

¢ [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.

-interval


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 display’s 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.


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.


ExplanationThis request displays the values of various TP meters.

ExamplesThe following example illustrates the use of the transaction_meters request with the -interval argument specified.

as: transaction_meters -interval

Transaction Processing Statistics metering time: 2:17:26 10sec 30sec 1min 5min 10min 1hr Total

Started 11 33 70 331 723 906 Committed 12 34 70 330 719 901 Completed 12 34 71 330 720 903 Lock aborts 0 0 0 2 3 5 priority 0 0 0 1 1 2 timeout 0 0 0 1 2 3 Lock Waits 0 5 8 94 204 233 Deadlocks 0 0 0 1 0 1 Modified Blocks 1 3 0 4 8 12

Max running 4810 4878 5513 7569 7569 8449Max hold_rlocks 10s 10s 11s 20s 20s 20s

Max hold_wlocks 13s 14s 14s 23s 23s 27s Max waiting 144 1507 1507 1603 1605 5005 Max retrying 142 897 897 1001 1020 4824 Max retries 1 2 2 8 8 8 Max aborts 0 0 0 1 1 1 Max rlocks 41 42 42 42 42 42 Max wlocks 140 147 147 147 147 147


use_block

use_block 8-

PurposeThis request places the analyze_system command in disk block mode.

Display Form

Command-Line Formuse_block block_number [-disk disk_name] [-read_partner] [-write_partner]

Arguments* block_number RequiredThe block number of disk block on the specified disk.

* -disk disk_nameSpecifies 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.

------------------------------------ use_block ----------------------------------block_number: -disk: master_disk-read_partner:-write_partner:


use_block

C A U T I O N

Writing a value to only one disk can have unpredictable consequences.

ExplanationThe 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.

ExamplesIn 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|


use_block

00000040 040 64756C65 00200029 66697273 74202F2F |dule. .)first //|

00000050 050 20202020 20202062 79206469 73706C61 | by displa|

00000060 060 795F6461 74655F74 696D6520 2D6C6F6E |y_date_time -lon|

00000070 070 676E0029 00206669 72737420 61732020 |gn.). first as |

00000080 080 20202020 20627920 616E616C 797A655F | by analyze_|

00000090 090 73797374 656D0020 003A6669 72737420 |system. .:first |

000000A0 0A0 61642020 20202020 20627920 616E616C |ad by anal|

....

as:

Related InformationFor 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).


use_dump

use_dump 8-

PurposeThis 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

Command-Line Formuse_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]

------------------------------------ use_dump ----------------------------------dump_number: dump_type: system-path_name:-file:-kernel_pm_dir:-disk:-partition:-next: no-previous: no-last: no-wait: no


use_dump

Arguments* dump_numberThe 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_nameThe 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_nameThe 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_dirThe 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_nameThe 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 numberThe 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).


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.

ExplanationAll 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


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 FormatThe 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

ExamplesIn 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


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:


use_file

use_file 8-

PurposeThis 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

Command-Line Formuse_file file_path_name

Arguments* file_path_name RequiredThe 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.

ExplanationThe 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.

N O T E

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.

------------------------------------ use_file ----------------------------------file_path_name:


use_file

ExampleIn the following example, the use_file request is set for a VOS program module.

as: use_file vos.pm


as:

Related InformationFor 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).


use_iop

use_iop 8-

PurposeThis request places the analyze_system command in IOP or IOA dump mode.

Display Form

Command-Line Formuse_iop iop_slot[-iop_no iop_number] [-iop_aux ] [-ioa ioa_number] [-file file_name]

Arguments* iop_slotThe 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_numberSpecifies 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.

------------------------------------ use_iop ----------------------------------iop_slot: -iop_no: -iop_aux: no -ioa: -file:


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_numberThe 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_nameSpecifies a file containing IOP firmware for the specified IOP or a file containing IOA firmware for the specified IOA.

ExplanationThe 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.

ExamplesIn 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:


use_iop

Related InformationFor 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.


use_iop_dump

use_iop_dump 8-

PurposeThis request selects an IOP dump.

Display Form

Command-Line Formuse_iop_dump dump_number[-path_name dump_path_name] [-next] [-prev]

Arguments* dump_numberThe 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_nameSpecifies 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.

--------------------------------- use_iop_dump ------------------------------- dump_number: -path_name: -next: no -previous: no


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.

ExplanationIssue 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.

ExamplesIn 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 InformationFor 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.


use_module

use_module 8-

PurposeThis request places the analyze_system command in module mode and specifies the module that will be analyzed by subsequent requests.

Display Form

Command-Line Formuse_module module_name

Arguments* module_nameThe name of the module that subsequent requests will analyze. The default value is the current module.

ExplanationUse the use_module request to specify the module that you want to analyze.

ExamplesIn the following example, the use_module request is set to a specified module.

as: use_module m7


as:

--------------------------------- use_module -----------------------------------module_name: current_module%


use_partition

use_partition 8-

PurposeThis request places the analyze_system command in partition mode and specifies the boot partition that will be analyzed by subsequent requests.

Display Form

Command-Line Formuse_partition partition_number[-disk master_disk_name]

Arguments* partition numberThe number of the boot partition that subsequent requests will analyze. The default is the current boot partition for the current module.

* -disk master_disk_nameThe 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.

ExplanationUse 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).

---------------------------------- use_partition -------------------------------partition_number: -disk: master_disk_name

current_boot_partition


use_partition

ExamplesIn 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


as:


variable

variable 8-

PurposeThis request defines a variable that can be used in subsequent requests or lists the values of all variables set thus far.

Display Form

Command-Line Formvariable variable_name value

Arguments* variable_nameA name to be used as a defined variable with the value specified in the value argument.

* valueThe value to be defined by variable_name.

ExplanationThe 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.

---------------------------------- variable ------------------------------------variable_name: value:


variable

ExamplesIn the following example, the variable request sets the variable rti to stand for real_terminal_io.

as: variable rti real_terminal_io

as:

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 InformationFor more information about the use of the variable request, see the section ‘‘Specifying Variable Names and Values’’ in Chapter 2.


walk

walk 8-

PurposeThis request searches for a specified set of objects and executes a request for each object.

Display Form

Command-Line Formwalk object command_line

Arguments* objectThe operating system object is always process.

* command_line RequiredAn analyze_system request line.

ExplanationThe 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.

------------------------------------ walk -------------------------------------object: rocesscommand_line:

p


walk

ExamplesIn the following example, the walk reqeust executes list_port_attachments for each process running on a module.

as: walk process list_port_attachments


Current process is 1, ptep C13151C0, CPU0.Idle (Idle_0)

default_input (1)

Indirects to terminal

terminal_output (2)


command_input (3)


default_output (4)


terminal (5)

Pathname: %swsle#os_telnet_m10.2

Type: window terminal

I/O type: output

Access mode: sequential

Attributes: 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’


Current process is 1, ptep 80C11540, CPU28.Idle (Idle_28)

Current process is 42, ptep 81C89C20, Overseer.System

(Os.src_ctrl.0418152545F2)


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 54, ptep 8144CC20, Overseer.System (LinkServer3)


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:


where

where 8-

PurposeThis request displays the object module name and the executing line number or address.

Display Form

Command-Line Formwhere address

Arguments* addressAn address expression. If you do not supply a value, analyze_system uses the address last referenced in similar requests.

ExplanationYou can specify any of the addressing formats described in Chapter 3 as a value for the where request.

ExamplesIn 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

------------------------------------ where -------------------------------------address: *


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 InformationFor more information about using the where request and addressing formats, see Chapter 3.


who

who 8-

PurposeThis request displays information about users and processes on the analyzed module.

Display Form

Command-Line Formwho [-user user_name] [-process_name name] [-cpu]

Arguments* -user user_nameSpecifies 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 nameSpecifies 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.

------------------------------------- who ---------------------------------------user: .*-process_name: *-cpu: no

*


who

ExplanationThe 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.

ExamplesIn 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)




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:


who

In the following example, the who request displays the number of processes assigned on a specified CPU.

as: who -cpu

CPU COUNT

0: 26

1: 15

as:


wired_memory_meters

wired_memory_meters 8-

PurposeThis request displays the wired memory meters.

Display Form

Command-Line Formwired_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.

ExplanationWired 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

------------------------------- wired_memory_meters -------------------------------reset: o-report: yes

n


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.

ExamplesIn the following example, the wired_memory_meters request displays wired memory meters for a module.

as: wired_memory_meters


OWNER COUNT MAX WIRES UNWIRES

kernel 3698 4601 691439 687741

disk cache 5394 26215 594811 589417

wired heap 6021 6021 6098 77

comm heap 10 10 10 0

link 39 39 39 0

disk 0 125 168516 168516

map 309 1267 789354 789045

I/O heap 34 34 34 0

HI I/O heap 832 832 832 0

iop tape 0 384 3156 3156

TOTAL 16337 2254289 2237952

mm.n_wired 4188

mm.n_temp_wired 12149

mm.TOTAL 16337

as:


wired_memory_meters

The following table describes the colums that appear in the output of the preceding example.

The following table describes the fields that appear in the output of the preceding example.

Related InformationFor more information about paging, see the description of the page_meters request.

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.

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.


wired_memory_meters


Appendix AAbbreviations Used by the

analyze_system CommandA-

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

ackadt adte afte apt apte atb axte bcbbme bmex bmt bp bsc cd cip cuxdcddde DDN ddte devx dqe dsl dsr dtrdvt dvte dvtep

acknowledgeactive directory tableactive directory table entryactive file table entryactive page tableactive page table entryaverage time betweenactive index table entryBSC control blockbuffer map entrybuffer map entry indexbit map tablebackward pointerbinary synchronouscarrier detectchannel info pointercontrol unit indexdata carrier detectdisk data entrydisk drive numberdisk data table entrydevice indexdisk queue entrydata set leaddata set readydata terminal readydevice tabledevice table entrydevice table entry pointer

eit eite epx et ete evid evx FLCK fp frm hashxiah idx intlapLAPB

lcb lddb ldt ldte ldtep mbx mbxp mmdata mme mt MTBF

executable image tableexecutable image table entryentry pointer indexevent tableevent table entryevent IDevent indexfile lockforward pointerframe errorhash indexI am hereindexinterruptlink access protocolLink Access Protocol, Balancedlap control blocklogin device databaselogin disk tablelogin disk table entrylogin disk table entry pointermailboxmailbox pointermemory manager datamemory map entrymemory tablemean time between failures

Abbreviations Used by the analyze_system Command A-1

Abbreviations Used by the analyze_system Command

naknct 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 rrrst

negative acknowledgenetwork client tablenetwork driver tablenetwork gateway tablenetwork routing tablenetwork socket tablelogical file lockoutput buffer pointeroverrun errorparity errorpage controlprimitive control programprocess data regionpage faultphysical file lockprogrammed interruptprocess IDprocess map blockprocess map entryport table entrypacket pool entryprocess pointerpending request queuepending request tableprocess table entryprocess table entry pointerpage table wordVOS programmed operatorsphysical page numberqueueread buffer activereceive not readyreceive readyreserved socket table

sip sle sqesqh

sqismbx UART

ui uid tbmt tcb tcbh tcbp tdr tid tpcb trlrp ttep tty tv vc vccrvcle vclm vct vcte vpi vpn vttvtte waf

station identification protocolStrataLINK entryserver queue entryserver queue header or streams queue headserver queue informationStrataLINK mailboxUniversal Asynchronous Receiver/TransmitterUniversal Interfaceunique IDtransmit buffer emptyterminal control blockterminal control block headerterminal control block pointertask data regiontask ID or transaction IDtape control blocktrailer pointerterminal type entry pointerterminal typetransfer vectorvirtual 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

Table A-1. Abbreviations (Page 2 of 2)

Abbreviation Description Abbreviation Description

A-2 VOS System Analysis Manual (R073)

Appendix BVOS Internal CommandsB-

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

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_attachmentslist_process_cmd_limitslist_systems (prelogin)load_kernel_program (privileged)login (prelogin)logoutmount_disk (privileged)move_dirmove_filereadyreenterreload_disk (privileged)remove_accessremove_default_accessremove_disk (privileged)remove_disk_pack (privileged)renamerestoresalvage_disk (privileged)select_duplex_disk (privileged)set_alignment_fault_modeset_bootload_time (privileged)set_date_time (privileged)set_default_time_zone (privileged)set_expiration_dateset_file_allocationset_implicit_lockingset_lock_wait_time (privileged)set_log_protected_file (privileged)

set_max_queue_depthset_object_audit (privileged)set_owner_accessset_pipe_fileset_priorityset_process_audit (privileged)set_process_lock_wait_timeset_readyset_safety_switchset_terminal_parametersset_text_fileset_time_zoneset_tp_default_parameters (privileged)set_tp_parametersset_transaction_file (privileged)setup_disk (privileged)setup_disk_pack (privileged)shutdown (privileged)start_disk_recovery (privileged)start_link (privileged)start_loggingstart_processstopstop_link (privileged)stop_loggingstop_processtruncate_fileuninitialize_disk (privileged)unlinkunload_kernel_program (privileged)update_channel_info (privileged)update_io_syserr (privileged)update_process_cmd_limitsuse_abbreviationsuse_message_fileverify_system_accesswhere_pathwho_locked

Table B-1. VOS Internal Commands (Page 2 of 2)

B-2 VOS System Analysis Manual (R073)

Requests That Are Described in Other Stratus Manuals

Appendix CRequests That Are Described

in Other Stratus ManualsC-

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 Programmer’s Guide (R220)

dump_chan_attach_ddb VOS Communications Software: 3270 Channel Attach Programmer’s Guide (R220)

dump_dkbk VOS Multiplexed Host Interface Administrator’s and Programmer’s Guide (R307)

dump_dkhs VOS Multiplexed Host Interface Administrator’s and Programmer’s Guide (R307)

dump_dkty VOS Multiplexed Host Interface Administrator’s and Programmer’s Guide (R307)

dump_dkux VOS Multiplexed Host Interface Administrator’s and Programmer’s Guide (R307)

dump_dkxqt VOS Multiplexed Host Interface Administrator’s and Programmer’s 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 Administrator’s and Programmer’s 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

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)

(Page 2 of 2)

Request Manual

C-2 VOS System Analysis Manual (R073)

Appendix DRequests That Are Obsolete or

for Stratus Use OnlyD-

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_requestsbd_breakbd_commbd_echobd_gobd_rawbiodriver_metersbreakcall_pcpcheck_comm_bufferscheck_kelcheck_listcheck_prom_codeclear_breakcomm_md_tracecreate_os_mapdisable_faultdisable_fault_insertiondisable_timer_faultdisplay_language_infodisplay_map_codesdisplay_periodic_test_timedisplay_tracedump_acbdump_acldump_async_ioadump_async_iop

dump_batch_overseerdump_bscdump_bsc_ioadump_call_requestsdump_cdtdump_clddump_commdump_comm_md dump_cpu_privatedump_ctape_datadump_ddedump_dma_tcbdump_dqedump_driverdump_eftdump_fault_infodump_fbedump_fidump_fmpidump_formdump_fsedump_gccbdump_giza_match_tabledump_h3270dump_hal_llcdump_hal_streamsdump_hal_timersdump_hasp

Requests That Are Obsolete or for Stratus Use Only D-1

Requests That Are Obsolete or for Stratus Use Only

dump_idpdump_imagedump_keldump_lat_acbdump_lat_asdump_lat_cbdump_lat_devdump_lat_glidump_lat_hidump_lat_hsdump_lat_lsdump_lat_nddump_lat_obdump_lat_qrdump_lat_sbdump_lat_sesdump_lat_sessionsdump_lcd_infodump_ldedump_lde_intdump_listdump_mapdump_message_queuedump_old_mctdump_overseerdump_packed_net_bufferdump_panedump_pcbdump_pick_datadump_pick_disk_datadump_pmtdump_poll_select_tracedump_ppedump_pscbdump_psi_datadump_psi_devdump_r3270dump_r3270_tracedump_rawfile_pooldump_remap_hash_tabledump_rfidump_rsedump_rsidump_rsn

dump_scbdump_scsi_tapedump_sledump_smbxdump_snadump_sna_ovrdump_sna_pass_thrudump_snadv_cbsdump_snasc_cbsdump_sqe_listdump_sqe_space_listdump_stape_ioa_ramdump_streams_areadump_tape_init_areadump_tbufdump_tcmddump_tcp_in_ifaddrdump_tdrvdump_tel_acbdump_tel_bufferdump_tel_gtidump_tel_serverdump_tsrvdump_ttedump_ucomm_bscdump_ucomm_h3270dump_ucomm_m3780dump_ucomm_udcbdump_wcbdump_windowdump_x25lctenable_faultenable_fault_insertionenable_periodic_testenable_timer_faultget_list_headergraph_module_usagelist_breakslist_scsi_deviceslist_tcp_xmt_queuesmonitor_rsepsi_monitorsave_profilescan_list


D-2 VOS System Analysis Manual (R073)


set_board_thresholdsset_breakset_dq_debug_modeset_dq_defaultssna_62_tracesna_appc_tracesna_history_tracesna_lu_tracesna_psna_tracesna_ssna_tracesna_t2_tracesna_t5_tracesnadv_history_tracesnasc_history_tracetimer_meters

tr_adpcbtr_ccbtr_dcbtr_lcbtr_lnkcbtr_mpxtr_sapcbtr_tablestr_traceucomm_monitor_bscucomm_monitor_h3270ucomm_monitor_m3780update_fault_infouse_bdwalk_list


Requests That Are Obsolete or for Stratus Use Only D-3


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

AAbbreviations, A-1Active directory table entry (ADTE), 8-82Active directory tables (ADT), 8-75Active file table entry (AFTE), 8-85, 8-517Active files, 8-517Active index table entry (AXTE), 8-85, 8-100,

8-517Active page table entry (APTE), 8-415Active processes, 8-498Address formats, 3-1

expression, 3-2external variable, 3-2hexadecimal, 3-2, 3-3indirect, 3-2, 3-11last display relative, 3-2, 3-12line numbers, 3-3object module code relative, 3-2, 3-7object module static relative, 3-2object module symtab relative, 3-2stack relative, 3-2symbolic, 3-4variable, 3-2

Address valueshexadecimal, 8-339megabyte of memory, 3-4memory page, 3-4

Alignment faultscompiling checking, 8-33Continuum-series modules, 8-33, 8-399

executable image table, 8-129logging, 8-398XA/R-series modules, 8-33, 8-399

analyze_system command, 8-2functionality, 1-1help for, 1-3invoking, 1-3modes of operation, 1-4prompt, 1-5, 2-1status of, 8-494uses, 1-2

Analyzed dump, 8-519definition of, 4-8

Analyzed module, 8-530definition of, 4-20

Analyzed process, 8-420definition of, 4-10, 4-22

as: prompt, 1-5, 2-1, 8-3as_meter_file file, 5-6Assembly language

disassemble request, 8-18listing example, 3-7

Asynchronous communications channels, 8-121

attach_default_output command, 2-7audit_admin command, 8-71

BBatteries

power failure, 8-362bind command, 8-44

bind maps, 3-5binder control file, 3-5

Boardslisting, 8-357power loading, 8-416

Boot partitionspecifying, 8-531

Buffer chainstypes, 8-125

Index-1

Index

Byte valuessetting, 8-445

CCache

disk, 8-115cache_meters request, 1-13, 8-4(calc) command function, 3-4Calculating addresses, 8-339Canceling requests, 2-4change_iop_dump_switch request, 1-8, 8-7Channels

information structure, 8-118managing, 8-302

check_area request, 1-12, 8-10IOP firmware mode, 4-19

check_boards requestdump mode, 4-11

C-language line parser, 8-3clone_command request, 1-6, 2-3, 8-14Code relative addressing

alternative method, 3-11Command level

returning to, 8-422Commands

analyze_system, 8-2audit_admin, 8-71bind, 8-44configure_comm_protocol, 8-455configure_firmware_types, 8-151,

8-206delete_file, 8-16display_disk_label, 8-531display_paging_usage, 8-498display_system_usage, 8-73display_tuning_parameters, 8-116external, 2-3internal, 2-2, 8-3, B-1list_devices, 8-119, 8-122, 8-191,

8-303list_port_attachments, 8-374network_client, 8-467reconfigure_memory, 8-177security_admin, 8-70set_scheduler_info, 8-246set_terminal_parameters, 8-306set_tuning_parameters, 8-76, 8-116update_channel_info, 8-119, 8-456

Communication requestsdump_queue_info, 1-11

Communications buffersdumping, 8-124

Communications busespower loading, 8-416

Communications channels, 8-118asynchronous, 8-121

Communications controller dump mode, 4-2, 4-3

list_comm_dumps requst, 4-3requests, 4-2use_comm_dump request, 4-3

Communications protocolserror thresholds, 8-452

Communications requestset_streams_param, 1-10

Communications requestschange_iop_dump_switch, 1-8display_net_trace, 1-8, 8-52dump_channel_info, 1-8, 8-118dump_channels, 1-9, 8-121dump_comm_buffers, 1-9, 8-124dump_firmware_names, 1-9dump_fw_table, 1-9dump_h3270, 1-9dump_iop_equip_table, 1-9dump_lcb, 1-9dump_net_info, 1-9, 1-9, 8-180dump_net_tids, 1-9, 8-185dump_nst, 1-9, 8-188dump_poll_select, 1-9, 8-191dump_protocol_names, 1-9, 8-206dump_prt, 1-9, 8-208dump_r3270, 1-9dump_r3270_trace, 1-9dump_rst, 1-9, 8-239dump_rsv_socket, 1-10, 8-242dump_socket, 1-10dump_socket_info, 1-10dump_stream, 1-10dump_streams, 1-10dump_tcb, 1-10, 8-302dump_tcbh, 1-10, 8-309list_iop_dump_switch, 1-10list_iop_dumps, 1-10list_streams_params, 1-10monitor_net_trace, 1-10, 8-403scan_streams_msgs, 1-10

Index-2 VOS System Analysis Manual (R073)

Index

search_streams, 1-10, 8-441set_comm_thresholds, 1-10, 8-452set_net_timeout, 1-10, 8-466set_net_trace, 1-10, 8-468use_iop_dump, 1-10

Compilingalignment faults checking, 8-33, 8-399

configure_comm_protocol command, 8-455

configure_firmware_types command, 8-151, 8-206

Continuum-series modulesalignment faults, 8-33, 8-399forward stack traces, 8-349stack traces, 8-488, 8-509user process memory, 7-10VOS shared memory space, 4-32

copy_dump command, 4-7CPU PROM files, 8-523

DData

displaying, 8-28(date) command function, 8-3Debugger, 8-48(decimal) command function, 3-3delete_dump request, 1-6, 8-16delete_file command, 8-16detach_default_output command, 2-7Devices

port table entry (PORTE), 8-197process using, 7-6

Directoriesactive table entries, 8-82active tables, 8-75listing activity, 8-367

directory_meters request, 1-13disassemble request, 1-6, 8-18

code relative addressing, 3-10display request, 8-19displaying instructions with, 6-7XA/R-series modules, 8-19

Disk block mode, 1-4, 4-2, 4-3requests, 4-2use_block request, 4-4, 8-516

Disk cache, 8-115

Disk drivesbuffers, 8-335listing, 8-363

Disk file system requestsdump_adt, 1-11dump_adte, 1-11dump_afte, 1-11dump_axte, 1-11dump_bmt, 1-11, 8-104dump_cache, 1-11dump_cache_info, 1-11list_disks, 1-11set_cache_pin_parameters, 1-11

disk_lock_meters request, 1-13, 8-20, 8-20resetting, 5-5

disk_meters request, 1-13, 8-23display command, 2-7display request, 1-6, 6-7, 8-28

code relative addressing, 3-10disassemble request, 8-19displaying unformatted data with, 6-1displaying variables with, 2-14dump mode, 4-11external variables, 6-4indirect addressing, 3-12partition mode, 4-34relative addressing, 3-12stack relative addressing, 3-16stack request, 8-488use_block request, 8-517where request, 8-538

display_alignment_faults request, 1-12, 8-32

log_alignment_faults request, 8-32, 8-400

specifying process for, 8-33display_cache_pin_parameters

request, 1-11, 8-35display_disk_label command

use_partition request, 8-531display_extensible_heap request, 1-12,

8-36display_file request, 1-6, 2-9, 8-40display_memory_usage request, 1-12, 7-8,

7-10, 8-43, 8-94, 8-425display_meter_file_info request, 1-13,

8-50

Index-3

Index

display_net_trace request, 1-8, 8-52monitor_net_trace request, 8-403set_net_trace request, 8-469

display_paging_usage command, 8-498display_pm request, 1-6, 3-5, 8-57

external variables, 6-4IOA firmware mode, 4-15IOP firmware mode, 4-19Module mode, 4-23

display_process_info request, 1-14, 8-64display_program_module command, 3-5,

6-4display_security_info request, 1-6, 8-70

audit_admin command, 8-71display_system_usage command, 8-73display_system_usage request, 1-6, 5-3,

8-72, 8-215display_tuning_parameters

command, 8-116display_vm_pool_info request

module mode, 4-32Displaying files, 2-7, 4-4

display command, 2-7display_file request, 2-9dump_syserr request, 2-11

Dump fileslisting, 8-366

Dump imagedefinition of, 4-7

Dump mode, 1-4, 4-2, 4-7check_boards request, 4-11display request, 4-11entering, 4-8find_string request, 4-12, 8-344finding data, 8-344list_dumps request, 4-8preparing to use, 4-8process request, 4-10requests, 4-2requirements for, 4-8, 8-521status request, 4-9, 8-495summary request, 8-499trace request, 4-10use_dump request, 4-8, 8-519use_iop request, 8-526who request, 4-10

Dump numbersdefinition of, 8-366

Dump partitiondefinition of, 4-7

Dump path names, 8-520dump_adt request, 1-11, 8-75dump_adte request, 1-11, 8-82dump_afte request, 1-11, 4-4, 8-85

processes, 7-5use_block request and, 8-517

dump_area request, 1-12, 8-92dump_axte request, 1-11, 4-5, 8-100

use_block request, 8-517dump_bmt request, 1-11, 8-104dump_bsc request, 1-8, 8-107dump_cache request, 1-11, 8-111, 8-111dump_cache_info request, 1-11, 8-115dump_chan_attach request, C-1dump_chan_attach_ddb request, C-1dump_channel_info request, 1-8, 8-118dump_channels request, 1-9, 5-2, 8-121

dump_tcb request, 8-303dump_tcbh request, 8-123

dump_comm_buffers request, 1-9, 8-124dump_dkbk request, C-1dump_dkhs request, C-1dump_dkty request, C-1dump_dkux request, C-1dump_dkxqt request, C-1dump_dvt request

processes, 7-6dump_eit request, 1-6, 8-129

finding processes with, 7-4dump_et request, 1-6, 8-134

processes, 7-5dump_events request, 1-7, 8-142dump_fi request

processes, 7-5dump_file command, 4-4dump_firmware_names request, 1-9, 8-146dump_fli request, 1-7, 8-148dump_fw_table request, 1-9, 8-151dump_giza request, 1-9, 8-153dump_h3270 request, 1-9, 8-156dump_index_block request, 4-7dump_ioa_adapt_mbox request, C-1dump_ioa_chan_mbox request, C-1dump_ioa_hdr request, C-1dump_ioa_pm_info request, C-1dump_ioa_xr_mbox request, C-1dump_iop_equip_table request, 1-9, 8-160


Index

dump_iop_meters request, 1-13, 8-163dump_k120_fw request, C-1dump_label request

partition mode, 4-34dump_lap_meters request, 1-13, 8-166dump_lcb request, 1-9, 8-168dump_lock request, 1-7, 5-2, 8-171dump_mpx_gccb request, C-1dump_mt request, 1-12, 8-176dump_net_info request, 1-9, 8-180dump_net_tids request, 1-9, 8-185dump_nst request, 1-9, 8-188dump_poll_select request, 1-9, 8-191dump_porte request, 1-7, 8-196, 8-197

and the dump_stream request, 8-267list_port_attachments

request, 8-197dump_protocol_names request, 1-9, 8-206dump_prt request, 1-9, 8-208dump_pte request, 1-7, 5-4, 7-3, 8-210, 8-215

processes, 7-5dump_queue_info request, 1-11, 8-217dump_r3270 request, 1-9, 8-229dump_r3270_trace request, 1-9, 8-235dump_rst request, 1-9, 8-239dump_rsv_socket request, 1-10, 8-242dump_scheduler_queues request, 1-7,

8-246dump_sdlc request, C-2dump_socket request, 1-10, 8-249dump_socket_info request, 1-10, 8-252dump_stream request, 1-10, 8-259

and the dump_porte request, 8-267and the list_port_attachments

request, 8-267dump_streams request, 1-10, 8-259, 8-298dump_syserr request, 1-7, 2-11, 8-299dump_tcb request, 1-10, 8-302

dump_channels request, 8-303dump_tcbh request, 8-303dump_tte request, 8-307list_devices command, 8-303list_port_attachments

request, 8-303set_terminal_parameters

command, 8-306dump_tcbh request, 1-10, 8-309

dump_channels request, 8-123dump_tcb request, 8-303

dump_tdr request, 1-12, 8-313dump_tpo request, 1-7, 8-320dump_transaction request, 1-7, 8-325dump_tte request

dump_tcb request, 8-307dump_ucomm request, C-2dump_ucomm_idle_q request, C-2dump_ucomm_timer_q request, C-2dump_ucomm_udcb request, C-2dump_ucomm_user_lcb request, C-2dump_vm_pool_info request, 1-12, 8-327Dumps

boot partition, 8-520deleting, 8-16displaying processes, 4-10displaying stack information, 4-10displaying status, 4-9IOP, 8-520kernel, 8-520numbers, 8-16program module, 8-520selecting, 4-8troubleshooting, 4-11

Ee$out_of_service error message, 8-456edit_vm_sizes request, 1-12, 8-335

use_partition request, 8-338Error messages

active, 8-299free, 8-299system, 8-299

evaluate request, 1-7, 8-339(calc) command function, 3-4(decimal) command function, 3-4(hexadecimal) command function, 3-4hexadecimal expressions, 3-4object module names, 3-7where request, 8-340

Event table (ET), 8-134event_count_meters request, 1-13, 8-341Events

dumping, 8-134, 8-142free list, 8-135kernel, 8-142process waiting, 7-5remote, 8-135

Index-5

Index

shadow, 8-139tasks and, 8-143

Executable image table (EIT), 8-129alignment faults, 8-129

Exiting analyze_system, 8-422Expressions

evaluating hexadecimal, 3-4Extensible heaps, 8-36External commands

clone_command request, 2-3, 8-14definition of, 2-1executing, 2-3login command, 2-3window terminal, 2-3

External variables, 3-2display request, 6-4display_pm request, 6-4displaying values in, 6-4listing, 8-58

FFans

failures, 8-362Fences

kernel stack, 8-48user stack, 8-48

File indexdisplaying contents of, 4-5

File mode. See Program module (file) modeFile partition, 8-104

bit map table, 8-104Files

active table entry (AFTE), 8-85displaying, 2-7, 4-4, 8-40listing activity, 8-367port table entry (PORTE), 8-197

Filtering outputmatch request, 2-4with request arguments, 2-5

find_string request, 1-7, 8-344dump mode, 4-12, 8-344

Firmwaredumping names, 8-146, 8-151dumping table, 8-151protocol names, 8-206

Forward stack tracedefinition of, 8-349

frame request, 1-12, 8-345stack relative addressing, 3-16

Framescurrent, 8-345

fstack request, 1-12, 8-348output varies by module, 8-349stack request, 8-349trace request, 8-348

HHeap requests

check_area, 1-12display_extensible_heap, 1-12dump_area, 1-12scan_area, 1-12

Heaps, 8-94buckets, 8-428calculating free space, 8-425check_area request, 8-10communications, 8-11, 8-37, 8-93, 8-424display_memory_usage request, 8-425displaying space in, 8-43dump_area request, 8-92dump_vm_pool_info, 1-12extensible, 8-36high I/O, 8-11, 8-37, 8-93, 8-424I/O, 8-37, 8-93internal structure, 8-10ioa, 8-11, 8-93, 8-424iop, 8-11, 8-93, 8-424old user, 8-424paged, 8-11, 8-37, 8-93, 8-424process data region, 8-11, 8-93, 8-424scan_area request, 8-423system, 8-36tags, 8-428user, 8-11, 8-93, 8-424wired, 8-11, 8-37, 8-93, 8-424

help command, 2-2help request, 1-7, 8-351

using, 1-3Hexadecimal address formats, 3-3Hexadecimal address values, 8-339(hexadecimal) command function, 3-3Hexadecimal expressions

evaluating, 3-4


Index

IIndexes

active table entries, 8-100active table entry, 8-85listing activity, 8-367

Indirect addressing, 3-11Instructions

displaying, 6-7setting, 6-7, 8-459

Internal commands, 8-3definition of, 2-1executing in analyze_system, 2-2external commands and, 2-3help command, 2-2listing, 2-2, B-1requests and, 2-3VOS, 8-3

Internal static relative addressing, 3-4interrupt_meters request, 1-13, 8-352Interrupts

displaying, 8-72IOA dump mode, 1-4, 4-2

list_iop_dumps request, 4-13requests, 4-2use_iop request, 4-13use_iop_dump request, 4-13

IOA firmware mode, 1-4, 4-2, 4-14display_pm request, 4-15list_boards request, 4-14requests, 4-2status request, 4-15use_iop request, 4-14

IOA modeuse_iop request, 8-372, 8-525, 8-528

IOP dump mode, 1-5, 4-2, 4-13, 4-16list_dumps request, 4-16requests, 4-2status request, 4-17use_dump request, 8-520use_iop request, 4-16

IOP firmware mode, 1-5, 4-2, 4-17check_area request, 4-19display_pm request, 4-19entering, 4-18list_boards request, 4-18requests, 4-2status request, 4-19use_iop request, 4-18

IOP modechange_iop_dump_switch request, 8-7list_iop_dump_switch request, 8-370use_iop request, 8-525

IOP requestsmodule mode, 4-16

IOPslist_iop_dumps request, 8-372use_iop_dump request, 8-528

KKernel

dumps, 8-520executable image table, 8-129heaps, 8-335program modules, 8-57

Llist_boards request, 1-7, 4-18, 8-357

in dump mode, 1-4IOA firmware mode, 4-14

list_comm_dumps requestcommunications controller dump

mode, 4-3list_devices command, 8-119, 8-122,

8-191dump_tcb request, 8-303

list_disks request, 1-11, 8-363dump mode, 8-366

list_dumps request, 1-7, 8-365dump mode, 4-8IOP dump mode, 4-16module mode, 8-366

list_file_activity request, 1-13, 8-367list_iop_dump_switch request, 1-10,

8-370list_iop_dumps request, 1-10, 8-372

IOA dump mode, 4-13list_port_attachments command, 8-374list_port_attachments request, 1-14,

8-197, 8-374and the dump_stream request, 8-267dump_tcb request, 8-303list_port_attachments

command, 8-374list_streams_params request, 1-10, 8-376list_tp_params request, 1-7, 8-381list_transaction_trace request, 1-7,

Index-7

Index

8-383list_transactions request, 1-7, 8-385lock_meters request, 1-13, 8-389lock_summary request, 1-13, 8-394Locks

summary request, 8-499log_alignment_faults request, 8-32,

8-398display_alignment_faults

request, 8-400Logged messages, 8-299Longword values

setting, 8-461Lost messages, 8-299

Mmatch request, 1-7, 8-401

effect on subsequent requests, 8-402using, 2-4

Memorychanging, 6-5changing on XA/R-series modules, 6-7displaying formatted data, 6-3displaying unformatted data, 6-1displaying user process, 7-7

Memory addressingmegabytes, 3-4pages, 3-4

Memory map entry (MME)displaying, 8-415

Memory pool, 8-11, 8-37, 8-94Memory requests

display_alignment_faults, 1-12, 8-32

display_memory_usage, 1-12, 8-43dump_eit, 8-129dump_mt, 1-12, 8-176dump_tdr, 1-12dump_vm_pool_info, 1-12, 8-327edit_vm_sizes, 1-12, 8-335set_byte, 8-445set_instruction, 8-459set_longword, 8-461set_word, 8-477

Memory tablesdumping, 8-176

Metering

as_meter_file, 5-6Metering fields

dump_pte request, 5-4Metering requests, 5-1

cache_meters, 1-13directory_meters, 1-13disk_lock_meters, 1-13disk_meters, 1-13display_cache_pin_parameters, 1-

11display_meter_file_info, 1-13display_system_usage, 5-3dump_channels, 5-2dump_iop_meters, 1-13dump_lap_meters, 1-13dump_lock, 5-2event_count_meters, 1-13interrupt_meters, 1-13list_file_activity, 1-13lock_meters, 1-13lock_summary, 1-13page_meters, 1-13sched_lock_meters, 1-13sched_meters, 1-13set_meter_file, 1-13sim_int_meters, 1-13terminal_meters, 1-13tpq_meters, 1-13wired_memory_meters, 1-13

Metersresetting, 5-4

Mode setting requestsuse_block, 1-14, 8-516use_dump, 1-14, 8-519use_file, 1-14, 8-523use_iop, 1-14, 8-372, 8-525, 8-528use_module, 1-14, 8-530use_partition, 1-14, 8-531

Modeschanging, 4-20communications controller dump, 4-2, 4-3disk block, 1-4, 4-2, 4-3dump, 1-4, 4-2, 4-7IOA dump, 1-4, 4-2IOA firmware, 1-4, 4-2, 4-14IOP dump, 1-5, 4-2, 4-13, 4-16IOP firmware, 1-5, 4-2, 4-17module, 1-5, 4-2, 4-20partition, 1-5, 4-3, 4-34


Index

program module (file), 1-5, 4-3, 4-35selecting, 4-2undefined, 1-5, 4-36

Module mode, 1-5, 4-2, 4-20default, 4-1display_pm request, 4-23display_vm_pool_info request, 4-32IOP requests, 4-16process request, 4-22requests, 4-2, 4-21use_module request, 8-530

monitor_net_trace request, 1-10, 8-403display_net_trace request, 8-403output anomalies, 8-407set_net_trace request, 8-469stopping output, 8-407

monitor_sdlc request, C-2monitor_sna request, C-2

NNetwork socket table (NST), 8-186network_client command

set_net_timout request, 8-467

OObject module code relative addressing, 3-7Object module names

display_pm request, 3-5display_program_module

command, 3-5evaluate request, 3-7

Object module static relative addressing, 3-11Object modules

displaying values in, 8-538maps, 8-47, 8-58

Obsolete requests, D-1Open file

process using, 7-5

PPage faults

displaying, 8-72page_meters request, 1-13, 8-409Paging partition

summary request, 8-498

Partition mode, 1-5, 4-3, 4-34

display request, 4-34dump_label request, 4-34requests, 4-3status request, 4-34use_partition request, 4-34, 8-531

Partitionsboot, 8-338, 8-520, 8-531disk, 8-338dump, 4-7file, 8-104

Pending request table (PRT)StrataLINK, 8-208

pme_status request, 1-14, 8-413Poll/select

dumping, 8-191terminal states, 8-192

Port table entry (PORTE), 8-196Ports

listing, 8-374Power

loading, 8-416recovery from failure, 8-362

power_summary request, 1-7, 8-416Process map entry (PME), 8-413

displaying, 8-415process request, 1-14, 4-10, 7-7, 8-419

dump mode, 4-10module mode, 4-22stack request, 8-487trace request, 8-509who process, 8-420

Process space, 4-34Process table entry (PTE), 8-210

walk request, 8-535Process table entry pointer (PTEP), 8-32,

8-398who request, 8-541

Processesanalyzed, 4-10, 8-420current, 8-420, 8-541data region, 8-48, 8-64, 8-424data region heap, 8-11, 8-93display_process_info request, 1-14,

8-64displaying descriptions of, 8-540displaying dumped, 4-10dump_afte request, 7-5dump_dvt request, 7-6dump_eit request, 7-4

Index-9

Index

dump_et request, 7-5dump_fi request, 7-5dump_pte request, 7-3, 7-5, 8-210executing a program, 7-4executing requests for, 8-535finding, 7-4IDs, 7-4, 8-215, 8-306list_port_attachments request, 1-14listing, 7-1locks, 8-499names, 8-419, 8-498numbers, 7-3, 8-215, 8-419, 8-498parent, 8-420pme_status request, 1-14, 8-413process request, 1-14, 7-7, 8-419selecting, 7-7setup_user_program request, 1-14sleep request, 1-14state, 7-6summary request, 1-14, 7-6, 8-498system usage, 8-72table entry pointer (PTEP), 7-3tasks and, 8-47, 8-314transaction ID, 8-384user, 8-420who request, 1-14, 7-1, 8-540

Program counter (PC)stack addresses, 8-487stacks, 8-509

Program module (file) mode, 1-5, 4-3, 4-35, 8-523

requests, 4-3use_file request, 4-35

Program modulesdisplay_pm request, 8-57dumps, 8-520finding process executing, 7-4kernel, 8-57setting paths to, 8-480status request, 8-494user, 8-57

Protocol namesdumping, 8-206

QQueues, 8-89

message and server, 8-217scheduler, 8-246

quit request, 1-8, 8-3, 8-422

Rreconfigure_memory command, 8-177Redirecting output, 2-6

attach_default_output command, 2-7

detach_default_output command, 2-7

start_logging command, 2-7stop_logging command, 2-7

Relative addressing, 3-12Requests

canceling, 2-4default address values, 3-3filtering output, 2-4listing, 8-351metering, 5-1obsolete, D-1redirecting output, 2-6

Reserved socket table (RST)StrataLINK, 8-239

Resetting metersas_meter_file file, 5-6

Running processes, 8-498

Ss$allocate subroutine, 8-47s$control_task subroutine, 8-316s$enable_tasking subroutine, 8-316s$free subroutine, 8-47s$get_paging_usage subroutine, 8-498s$open subroutine, 8-517s$set_task_priority subroutine, 8-317scan_area request, 1-12, 8-423scan_streams_msgs request, 1-10, 8-430sched_lock_meters request, 1-13, 8-435sched_meters request, 1-13, 8-438Scheduler queues, 8-246search_streams request, 1-10, 8-441

logging output, 8-442Security logging, 8-70security_admin command, 8-70set_byte request, 1-8, 6-6, 6-7, 8-445set_cache_pin_parameters

request, 1-11, 8-448


Index

set_comm_thresholds request, 1-10, 8-452set_instruction request, 1-8, 6-7, 8-459set_longword request, 1-8, 6-6, 6-7, 8-461set_meter_file request, 1-13, 8-464set_net_timeout request, 1-10, 8-466

network_client command, 8-467set_net_trace request, 1-10, 8-468

display_net_trace request, 8-469monitor_net_trace request, 8-469

set_scheduler_info command, 8-246set_streams_param request, 1-10, 8-470,

8-470set_tape_buffer_mode request, 1-15,

8-472set_terminal_parameters command

dump_tcb request, 8-306set_tp_param request, 1-8, 8-473set_tuning_parameters command, 8-116

active directory tables, 8-76set_word request, 1-8, 6-5, 6-7, 8-477Setting byte values, 8-445Setting instructions

versus data values, 6-7setup_user_program request, 1-14, 8-480sim_int_meters request, 1-13, 8-481sleep request, 1-14, 8-484sna_psna_trace request, C-2sna_ssna_trace request, C-2Sockets, 8-189, 8-240, 8-254

reserved, 8-239, 8-242structures, 8-255

Source code line numbersaddressing with, 3-3

Stack framedefinition of, 3-13

Stack relative addressing, 3-4frame request, 3-16

stack request, 1-12, 8-486display request, 8-488fstack request, 8-349process request, 8-487

StacksContinuum-series modules, 8-488, 8-509default address, 8-348default frame addresses, 8-345definition of, 3-13displaying, 3-13dumps, 4-10forward trace, 8-349

frame request, 1-12, 8-345fstack request, 1-12, 8-348on units, 8-487, 8-509program counter (PC), 8-487, 8-509relative addressing, 3-2space usage, 8-43stack request, 1-12, 8-486tasks and, 8-487, 8-509trace request, 1-12, 3-13, 8-508

Star namesin addresses, 3-4

start_logging command, 2-7, 8-3Static region

addresses, 3-2status request, 1-8, 8-494

dump mode, 4-9, 8-495IOA firmware mode, 4-15IOP dump mode, 4-17IOP firmware mode, 4-19partition mode, 4-34

stop_logging command, 2-7StrataLINK

circular tracing, 8-468network socket table (NST), 8-186pending request table (PRT), 8-208reserved socket table (RST), 8-239set_net_timout request, 8-466set_net_trace request, 8-468transaction IDs, 8-185

StrataLINK requestsdisplay_net_trace, 8-52dump_net_tids, 8-185dump_nst, 8-188dump_prt, 8-208dump_rst, 8-239dump_rsv_socket, 8-242dump_socket_info, 8-252monitor_net_trace, 8-403

StrataNETgateways, 8-181set_net_timeout request, 8-466setting timeouts, 8-466stations, 8-181

StrataNET requestsdump_net_info, 8-180dump_nst, 8-188dump_prt, 8-208dump_rst, 8-239dump_rsv_socket, 8-242

Index-11

Index

dump_socket_info, 8-252Streams. See VOS STREAMSStrings

matching, 8-401summary request, 1-14, 8-498

dump mode, 8-499module mode, 8-499processes, 7-6

Symbol tablerelative addressing, 3-2, 3-5

Symbolic address formats, 3-4Symbolic names

finding, 3-5syserr_log.(date) file, 2-11, 8-299System

error messages, 8-299heaps, 8-36usage, 8-72

Tt1_getstate request, C-2t1_getstats request, C-2t1_gettune request, C-2t1_lap_getstats request, C-2t1_lap_gettune request, C-2t1_wan_getstats request, C-2t1_wan_gettune request, C-2Tape drives

buffers, 8-335set_tape_buffer_mode request, 1-15,

8-472setting mode, 8-472

Task data region (TDR), 8-64dumping, 8-313

Task data region entry (TDRE), 8-314Tasks

dump_tdr request, 8-313events and, 8-143processes and, 8-47, 8-314stacks and, 8-487, 8-509task 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-502tpq_meters request, 1-13, 8-504trace request, 1-12, 3-13, 8-508

dump mode, 4-10fstack request, 8-348process request, 8-509

Transaction IDsStrataLINK, 8-185

transaction_meters request, 8-512Transactions

ID, 8-384listing, 8-383process ID, 8-384

UUndefined mode, 1-5, 4-3, 4-36update_channel_info command, 8-119,

8-456use_block request, 1-4, 1-14, 4-4, 8-516

active files, 8-517display request, 8-517dump_afte request, 8-517dump_axte request, 8-517

use_comm_dump requestcommunications controller dump

mode, 4-3use_dump request, 1-14, 8-519

dump mode, 4-8use_file request, 1-5, 1-14, 8-523

program module (file) mode, 4-35use_iop request, 1-4, 1-5, 1-14, 8-525

IOA dump mode, 4-13, 8-526IOA firmware mode, 4-14IOP dump mode, 4-16, 8-526IOP firmware mode, 4-18module mode, 8-526

use_iop_dump request, 1-10, 8-528IOA dump mode, 4-13

use_module request, 1-5, 1-14, 8-530use_partition request, 1-5, 1-14, 8-531

display_disk_label command, 8-531edit_vm_sizes request, 8-338partition mode, 4-34

User process memoryContinuum-series, 7-10displaying, 7-7XA/R-series, 7-8

User processs space, 4-34

VVariable names


Index

characteristics, 2-13specifying, 2-13, 8-533

variable request, 1-8, 2-14, 8-533Variable values

display request, 2-14specifying, 2-14, 8-533

Variablesaddresses in, 3-2external, 3-2

Virtual address space, 8-43displaying, 8-43

Virtual memory pools, 8-327VOS

status of, 8-494VOS program module (vos.pm)

XA/R-series, 4-23VOS shared memory space

Continuum-series modules, 4-32VOS STREAMS

data structures that synchronize execution threads, 8-266

dump_porte request, 8-197dump_stream request, 8-259input/output data structures, 8-264search_streams request, 8-441

VOS symbol tabledisplaying values in, 6-4

Wwalk request, 1-8, 8-535

process table entry (PTE), 8-535where request, 1-8, 8-538

code relative addressing, 3-10display request, 8-538evaluate request, 8-340

who request, 1-14, 4-10, 7-1, 8-540dump mode, 4-10process request, 8-420process table entry pointer (PTEP), 8-541

wired_memory_meters request, 1-13, 8-543Word values

setting, 8-477

XXA/R-series modules

alignment faults, 8-33, 8-399changing memory in, 6-7

disassemble request, 8-19forward stack traces, 8-349user process memory, 7-8VOS program module, 4-23

XA2000-series modulesforward stack traces, 8-349

Index-13

Index


Date post:	15-Jul-2016
Category:	Documents
Upload:	kennycheung
View:	76 times
Download:	13 times

VOS System Analysis Manual (r073-04)

Documents