Note: The 235-XXX-XXX manuals do not provide maintenance
procedures for the repair of equipment (for
example, tape drives or disk drives) manufactured
by vendors other than AT&T. To identify the
appropriate maintenance manual for each unit of
such vendor equipment, refer to Section 3 of AT&T
235-001-001, Documentation Description and Ordering
Guide. This guide only provides the vendor's
address associated to the unit in question, not the
procedures used to repair the faulty equipment.
This document describes the maintenance concepts and built-in
maintenance capabilities of the 5ESS(R) switch. The information
is necessary to perform system evaluation and maintenance. To
be adequately prepared to maintain the 5ESS switch, the
following prerequisites are recommended for maintenance
personnel:
a. Must be familiar with telephone equipment and terminology.
b. Must complete maintenance training on the 5ESS switch.
c. Must be familiar with the information in the following
manual(s):
o AT&T 235-100-125, System Description 5E6 and Later
o AT&T 235-900-106, Product Specification 5E6
o AT&T 235-900-107, Product Specification 5E7
o AT&T 235-900-108, Product Specification 5E8.
o AT&T 235-900-109, Product Specification 5E9(1).
Note: These manuals also contain a section
concerning Environmental Specifications
(physical specifications) that can be useful
to maintenance personnel.
Product rating for the 5E2(2), 5E3, 5E4, and 5E5 software
releases has been changed to Discontinued Availability (DA).
Effective with Issue 7.00, all information on the DA rated
software releases is being removed from this document.
This document is updated to provide coverage for the 5E7 (Issue
5.00), 5E8 (Issues 6.00 and 6.01), and 5E9(1) (Issue 7.00)
software releases. Sections .RM 1.2.2/, .RM 1.2.3/, and .RM 1.2.4/,
respectively, contain update information on these software
releases.
Note: The 5E2(2) through 5E5 information is removed in
Issue 7.00 of this document. (See statement
relative to DA rating of software releases at the
beginning Section .RM 1.2.1/.)
For the 5E7 software release, Issue 5.00 of this document was
updated for the following reasons:
o Removed information on the 5E2(1) software release from all
sections. [All 5E2(1) offices have been retrofitted to a
later software release.]
o Updated Table .AW TA/.
o Changed information on the Call Monitor feature is Sections
2 and 3.
o Updated information on the Office Data Base Editor (ODBE)
is Section 3.
o Updated information on the Access Editor (ACCED) is Section
3.
o Updated information on the Current Update Data Base and
History File Editor (UPedcud) is Section 3.
o Made screen corrections, added screen abbreviations, and
added command descriptions on Trunk and Line Work Station
(TLWS) Task Selection Pages for 5E2(2) through 5E6 software
releases in Section 3.
o Added information on TLWS Task Selection Pages for the 5E7
software release in Section 3.
Note: Information on TLWS task selection pages and
commands is completely rewritten in Issue 7.00
of this document.
o Reorganized and reformatted information on Generic
Utilities to present information on this tool in a more
descriptive format as opposed to the redundant Input/Output
message data included in previous issues.
o Added the master control center (MCC) Page Location Guide
to the Introduction subsection in Section 4.
Note: In Issue 7.00, the title of the Introduction
subsection is changed to Introduction to MCC
Pages.
o Updated, added, and deleted text and screen displays in
Subsections 5E2(2) through 5E6. These updates, additions,
and deletions were the result of in-depth reviews for
accuracy of all MCC page displays and associated text by
BTL developers.
o Added the 5E7 Subsection to Section 4. The 5E7 Subsection
contains the MCC page displays that changed with the 5E7
software release.
o Made minor corrections to text, tables, and figures
throughout the document.
Note: The 5E2(2) through 5E5 information is removed in
Issue 7.00 of this document. (See statement
relative to DA rating of software releases at the
beginning Section .RM 1.2.1/.)
For the 5E8 software release, Issues 6.00 and 6.01 of this
document were updated for the following reasons:
o Updated Table .AW TA/.
o Updated information on Software Release
Retrofit/Update/Large Terminal Growth in Section 2.
o Updated information on Access Editor (ACCED) in Section 3.
o Added information on Common Network Interface Data Base
Consolidator (CNIDBOC) in Section 3.
o Updated information on BROWSE in Section 3.
o Updated information on Generic Access Package (GRASP) in
Section 3.
o Updated information on the Operation Support System (OSS)
Routine Exercises (REX) Scheduler Program in Section 3.
o Added information on the Automatic REX Scheduler in Section
3.
o Added information on the 108-type test line in Section 3.
o Added information on basic rate interface (BRI) access to
the 108-type test line in Section 3.
o Added information on Trunk and Line Work Station (TLWS)
Task Selection Pages for the 5E8 software release in
Section 3.
Note: Information on TLWS task selection pages and
commands is completely rewritten in Issue 7.00
of this document.
o Updated the Generic Utilities information in Section 3 to
add commands for two new 5E8 processors, Integrated Digital
Carrier Unit (IDCU) and Integrated Digital Carrier Unit
Loop Side Interface (IDCULSI).
o Updated information in Table .AW TAD/, Directory of Service
Centers.
o Updated information in Table .AW TAE/, Directory of Service
Support Organizations.
o Updated the master control center (MCC) Page Location Guide
in the Introduction subsection of Section 4. The update
included adding all MCC pages in the 5E8 subsection.
Note: In Issue 7.00, the title of the Introduction
subsection is changed to Introduction to MCC
Pages.
o Updated the general description of the 1000 SM Page Index
page in 5E2(2) through 5E7 subsections.
o Updated information on MCC Page 105/106 in the 5E2(2)
subsection.
o Updated information on MCC Page 1950 in the 5E5 subsection.
o Updated information on MCC Pages 115 (CM2 version), 116,
and 1950 in the 5E6 subsection.
o Updated information on MCC Pages 110, 116, 123, 125,
1800,X, 1850, and 1851 in the 5E7 subsection.
o Removed information on MCC Page 1950 from the 5E7
Subsection. (The update to the 1950 page in the 5E6
Subsection applies to 5E6 and later software releases.)
o Added the 5E8 Subsection to Section 4. The 5E8 Subsection
contains the MCC page displays that were added with or
changed with the 5E8 software release.
o Made minor corrections to text, tables, and figures
throughout the document.
This document is updated to Issue 7.00B, May 1994, to add
the results of call failures in Section .RM 3.5.1.10/, Call
Monitor Reports.
This document is updated to Issue 7.00A, December 1993, for
the following reasons:
o To remove the requirement for circuit packs to
be tested on site
o To add the DGR state to MCC page 118
o To update information on MCC pages 1521,XX and
1522,XX,Y.
o To add a note for the user to insert RC/V view 8.3
if it does not exist.
For the 5E9(1) software release, Issue 7.00 of this document is
updated for the following reasons:
o Update Table .AW TA/.
o Update information on the Call Monitor in Sections 2 and 3.
o Update Single Process Purge and Selective Initialization
information in Section 2 to include wideband calls.
o Add information on the automatic trunk test scheduler
(ATTS) in Section 3.
o Update Trunk and Line Work Station (TLWS) information in
Section 3 for 32 test positions in 5E9(1) and to include
test position resources and resource assignment.
o Update line and trunk testing information in Section 3 to
include wideband calls.
o Change the format of information on TLWS Task Selection
Pages in Section 3 to eliminate redundancy and reduce the
number of text pages.
o Add 5E9(1) examples of all TLWS pages to reflect new page
layout and command changes and add information on new
5E9(1) Pages 5000,3 (line), 5000,3 (trunk), 8000, 9000,1,
9000,2, and 9201.
o Add information on input message editing and history in
Section 3.
o Add information on the Ring Generic Access Package (RGRASP)
in Section 3.
o Add information on the Automated Circuit Pack Return Tag
(RTAG) tool in Section 3.
o Add information on the Automated Static ODD (SODD) Audit in
Section 3.
o Update the master control center (MCC) Page Location Guide
in the Introduction to MCC Pages (formerly Introduction)
subsection of Section 4. The update includes removing
references to the 5E2(2) through 5E5 software releases and
adding references for all MCC pages included in the 5E9(1)
subsection.
o Remove subsections 5E2(2) through 5E5 in Section 4 and move
to the 5E6 subsection all MCC page displays valid for 5E6
(or 5E6 and later) that were previously included in
subsections 5E2(2) through 5E5.
o Add the 5E9(1) subsection to Section 4. The 5E9(1)
subsection contains MCC page displays that were added with
or changed with the 5E9(1) software release.
o Make minor corrections to text, tables, and figures
throughout the document.
The information in this document is applicable to all switches
equipped with 5E6 and later software releases. When text
applies to a specific software release, the applicable software
release is indicated.
When new software releases are developed that affect this
document, updates will be made. Also, this document is
utilizing an issue number.
The overall structure is outlined as follows:
1. Section 1--Introduction: This section summarizes the
type of information contained in the document, gives
the purpose of this information, and defines its
organization. In addition, this section identifies
the three maintenance manuals provided for maintenance
and explains the function of each.
2. Section 2--Maintenance Philosophy: This section
describes the following maintenance capabilities of
the 5ESS switch:
o Maintenance overview.
o Remote maintenance capabilities.
o Central office maintenance plan.
o System evaluation and maintenance stimuli.
o Maintenance tasks:
a. Scheduled routine maintenance
b. Nonscheduled routine maintenance
c. Corrective maintenance tasks
d. System recovery
e. Operator Services Position System (OSPS)
maintenance
f. Maintenance of vendor equipment.
o Line unit trouble clearing guide.
o Trunk and line maintenance:
a. Per-call tests
b. Routine line and trunk tests
c. Tests provided
d. Call monitor.
o Recent change (RC), field, and software release
retrofit/update.
o Change notices (CN).
3. Section 3--Maintenance Tools: This section describes
the following maintenance tools available for use in
the 5ESS switch:
o Display administration process (DAP)/Non-DAP
terminal.
o MCC.
o Supplementary trunk and line work station
(STLWS).
o TLWS.
o Trunk and line maintenance.
o Test access unit (TAU).
o Directly connected test unit (DCTU).
o Remote office test line (ROTL).
o TLWS task selection page displays.
o Recent change/verify (RC/V).
o Screen program user's guide.
o How to use input/output (I/O) messages.
o Office data base editor (ODBE).
o Access editor (ACCED).
o Common network interface data base consolidator
(CNIDBOC).
o Automated circuit pack return tag (RTAG) tool.
o Software debugging and troubleshooting tools.
o Generic utilities.
o System log files.
o Diagnostics:
-- Diagnostic types
-- Diagnostic input/output messages
-- Routine exercises (REX)
-- Operation Support System (OSS) REX scheduler
program
-- Automatic REX scheduler.
o How to use switching module (SM) peripheral Fault
Recovery Message (Verbose Mode).
o Routine tests.
o How to use office backup schedules.
o Circuit pack handling procedures.
o Spare circuit packs.
o Circuit pack repair service and return
procedures.
o Dynamic Audits.
o Static Audits.
o How to use program record and program map
documents.
o How to use program change document, symbol
address cross-reference index, and function
address program record (PR) name cross-reference
index.
o TR303 Integrated Digital Carrier Unit (IDCU)
remote terminal provisioning.
4. Section 4--MCC Page Display: This section contains a
detailed description of the page displays of the 5ESS
switch MCC video terminal and the MCC Page Location
Guide which can be used to locate specific page
displays for specific 5E6 and later software releases.
Section 4 is divided into five subsections as follows:
o Section .RM 4.2/: Covers the introduction to the MCC
page displays
o Section .RM 4.3/: Covers the 5E6 software release
o Section .RM 4.4/: Covers the 5E7 software release
o Section .RM 4.5/: Covers the 5E8 software release
o Section .RM 4.6/: Covers the 5E9(1) software release.
Since this document has been developed to describe maintenance
concepts and maintenance capabilities for the 5ESS switch, it is
appropriate to identify the manuals that contain the procedures
used to maintain the switch.
1. AT&T 235-105-210, Routine Operations and Maintenance
Procedures: Contains the descriptive material and
detailed procedures for routine operations and
maintenance of the 5ESS switch. The following is a
list of the sections in this document:
o Equipment Test List (ETL)
o Operations (system control functions)
o Memory Alteration Description
o Memory Alteration Procedures
o Abnormal Input Message Acknowledgments
o Fan and Alarm Tests
o Moving Head Disk (MHD) Procedures
o Miscellaneous Routine Procedures
o ROTL
o Routine Exercise Procedures.
The AT&T 235-105-210 also has a job aid for O&M
Checklist which must be ordered separately (see AT&T
235-001-001, Documentation Description and Ordering
Guide).
Note: Refer to Table .AW TA/ for a complete list of
the operation and maintenance procedures
included in AT&T 235-105-210.
2. AT&T 235-105-220, Corrective Maintenance Procedures:
Contains three sections as follows:
o Hardware - Maintenance Procedures: This section
contains a series of task-oriented corrective
maintenance procedures that can be used by
personnel who are involved in maintaining various
hardware units and circuits of the 5ESS switch.
Also, some procedures are used to resolve
subscribing customer service complaints.
o Office Dependent Data - Maintenance Procedures:
This section contains a series of task-oriented
corrective maintenance procedures that can be
used to maintain and repair office dependent data
(ODD) associated with the switch.
o Supporting Information: This section contains a
tabular list that describes all the diagnostic
phase descriptions and a Basic Rate Interface
(BRI) trouble-shooting diagram.
The AT&T 235-105-220 also has a group of job aids for
the TLWS poke commands which must be ordered
separately (see AT&T 235-001-001, Documentation
Description and Ordering Guide).
Note: Refer to Table .AW TA/ for a complete list of
the operation and maintenance procedures
included in AT&T 235-105-220.
3. AT&T 235-105-250, System Recovery: Contains the
descriptive material and detailed procedures of the
software and hardware recovery capabilities of the
5ESS switch. Both automatic and manual recovery
capabilities are covered. The following is a list
identifying what is covered in this manual:
o System Recovery Description: In the 5ESS switch,
system recovery uses the concept of a network of
independent processors to localize recovery
actions. The major processors involved are the
administrative module (AM), communication module
processor (CMP) (added in the 5E6 software
release), and the individual SMs. When a fault
exists, fault recovery attempts to reconfigure
the system to provide full system service
(primarily by excluding the faulty unit).
Several levels of recovery are available, and the
system can automatically escalate to higher and
broader levels if initial attempts fail. The
higher recovery levels often include processor
initializations.
This section describes the various recovery
levels (and their impact) when used in the
different processors. The strategy of
reconfiguration and escalation to higher recovery
levels is also covered, as is the mapping between
manual commands and internal recovery levels.
o System Recovery Procedures: The procedures
provided in this section are used to clear system
failures which prevent the 5ESS switch from
restoring itself automatically. Also, procedures
are provided for analyzing the AM and SM
initializations.
Note: Refer to Table .AW TA/ for a complete list
of the operation and maintenance
procedures included in AT&T 235-
105-250.
4. AT&T 235-105-119, Maintenance Guide Utilizing OMS5:
This document provides information related to
utilization of the OMS5 program. The OMS5 program
summarizes the receive-only printer (ROP) output into
a readable format. This program provides the
maintenance personnel with an easy way to analyze how
the office is performing. After analyzing the OMS5
program summary, the maintenance personnel should use
the Corrective and Routine Maintenance Manuals (listed
previously) with this manual to correct faults that
occur in the switch.
The OMS5 program runs on the switching control center
(SCC) minicomputer. The tape that contains the OMS5
program can be obtained via the order number AT&T
235-105-120. This maintenance guide and the OMS5
program can only be used via the SCC.
The producers of this manual are constantly striving to improve
quality and usability. Please use the enclosed user feedback
form [REF. .RM 1.9/] for your comments and to advise us of any
errors. If the form is missing or your comments will not fit, you
can write to the following address:
AT&T NETWORK SYSTEMS
Quality Department
2400 Reynolda Road
Winston-Salem, NC 27106
Please include the issue number and/or date of the manual, your
complete mailing address, and telephone number. We will attempt
to answer all correspondence within 30 days, informing you of
the disposition of your comments.
You may also call our Documentation HOT LINE if you need an
immediate answer to a documentation question. This HOT LINE is
not intended to eliminate the use of the user feedback form, but
rather to enhance the comment process. The HOTLINE number is
1-800-334-0404 and it is available from 7:30 a.m. to 4:30 p.m.
Eastern time (within North Carolina, dial 1-910-727-6681).
Outside of those hours, the line is served by an answering
machine. You can leave a message on the answering machine and
someone will return your call the following business day.
Also, document users who have access to UNIX(R) system
electronic mail facilities may send comments via electronic
mail. The electronic address is att!wrddo!hotline5. Please
make sure that the document title, number, and issue number are
included in the mail along with the sender's name, phone number,
and address.
This manual is distributed by the AT&T Customer Information
Center in Indianapolis, Indiana. Most operating telephone
companies should place orders through their documentation
coordinator. Some companies may allow customers to order
directly from the Customer Information Center; however, the
majority do not. Companies that use documentation coordinators
to manage their orders receive a significant discount. If you do
not know the name/number of the documentation coordinator for
your company, you may call 1-800-432-6600 to obtain the name and
telephone number.
Customers not represented by a documentation coordinator and
AT&T employees can order the documentation for the 5ESS switch
directly from the AT&T Customer Information Center. Proper
billing information must be provided. These orders may be
mailed to:
AT&T Customer Information Center
Order Entry
2855 N. Franklin Road
Indianapolis, IN 46219
Orders may also be called in on 1-800-432-6600 or faxed in on
1-317-322-6484.
Technical assistance for the 5ESS switch can be obtained by
calling the Regional Technical Assistance Center (RTAC) at
1-800-225-RTAC. This telephone number is monitored 24
hours a day, 7 days a week. During regular business hours,
your call will be answered by your local RTAC. Outside of
normal business hours, all calls will be answered at a
centralized technical assistance center where service-affecting
problems will be dispatched immediately to your local RTAC.
All other problems will be referred to your local RTAC on the
next regular business day.
How Are We Doing?
\
\
Document Title: SYSTEM MAINTENANCE REQUIREMENTS AND TOOLS
Document Number: AT&T 235-105-110 Issue Number: 7.00
Publication Date: November 1993
AT&T welcomes your feedback on this document. Your comments can
be of great value in helping us improve our documentation.
1. Please rate the effectiveness of this document in the following areas:
4
____________________________________________________________________
| | | | | | Not |
| | Excellent | Good | Fair | Poor | Applicable |
|______________________|___________|______|______|______|____________|
| Ease of Use | | | | | ///////// |
|______________________|___________|______|______|______|____________|
| Clarity | | | | | ///////// |
|______________________|___________|______|______|______|____________|
| Completeness | | | | | ///////// |
|______________________|___________|______|______|______|____________|
| Accuracy | | | | | ///////// |
|______________________|___________|______|______|______|____________|
| Organization | | | | | ///////// |
|______________________|___________|______|______|______|____________|
| Appearance | | | | | ///////// |
|______________________|___________|______|______|______|____________|
| Examples | | | | | |
|______________________|___________|______|______|______|____________|
| Illustrations | | | | | ///////// |
|______________________|___________|______|______|______|____________|
| Overall Satisfaction | | | | | ///////// |
|______________________|___________|______|______|______|____________|
2. Please check the ways you feel we could improve this document:
[] Improve the [] Make it more concise/brief
overview/introduction
[] Add more step-by-step
[] Improve the table of procedures/tutorials
contents
[] Add more troubleshooting information
[] Improve the organization
[] Make it less technical
[] Include more figures
[] Add more/better quick reference
[] Add more examples aids
[] Add more detail [] Improve the index
Please provide details for the suggested improvement._________________
______________________________________________________________________
3. What did you like most about this document?
______________________________________________________________________
______________________________________________________________________
4. Feel free to write any comments below or on an attached sheet.
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
If we may contact you concerning your comments, please complete the
following:
Name: ______________________________ Telephone Number: (___)__________
Company/Organization: ___________________ Date: ______________
Address: ______________________________________________________________
When you have completed this form, please fold, tape, and return to the
following address or Fax to: 910-727-3043.
DOCUMENTATION SERVICES
2400 Reynolda Road
Winston-Salem, NC 27199-2029
The following is a list of manuals that the user should be aware
of when reading this document:
o AT&T 235-600-700, 5ESS Switch Input Messages Manual
o AT&T 235-600-750, 5ESS Switch Output Messages Manual
o AT&T 235-105-119, Maintenance Guide Utilizing OMS5
o AT&T 235-105-210, Routine Operations and Maintenance
Procedures
o AT&T 235-105-220, Corrective Maintenance Procedures
o AT&T 235-105-250, System Recovery
o AT&T 235-600-104, Translations Data 5E6
o AT&T 235-600-105, Translations Data 5E7
o AT&T 235-600-106, Translations Data 5E8
o AT&T 235-600-107, Translations Data 5E9
o AT&T 235-600-400, Audits Manual
o AT&T 235-600-500, Asserts Manual
o AT&T 235-600-510, Software Analysis Guide
o AT&T 235-600-601, Processor Recovery Messages
o AT&T 235-900-106, Product Specification 5E6
o AT&T 235-900-107, Product Specification 5E7
o AT&T 235-900-108, Product Specification 5E8.
o AT&T 235-900-109, Product Specification 5E9(1).
Note: Other manuals not identified previously that can be
helpful to the customer are listed in AT&T 235-
000-000, Numerical Index - Division 235. This
index is for informational purposes only. Site
documents should be ordered from the applicable H-
drawing. If you do not have a copy of this index,
it can be ordered from the Customer Information
Center in Indianapolis, Indiana.
The 5ESS(R) switch is supported by many built-in maintenance
aids:
o Simplified human interface system
o System status displays
o Combined audible and visual alarm system
o Automatic routine testing of circuitry
o Routine exercise (REX) capability
o Automatic fault detection and recovery
o Manual testing capability
o Remote maintenance capability
o Duplication of common control equipment
o Compact physical size.
The MCC is the primary communication link between on-site
maintenance personnel and the 5ESS switch. The MCC provides the
interface capability for administrative and maintenance tasks.
The major components of the MCC (Figure .AW G1/) consist of the
following:
o A video display terminal with keyboard
o A receive-only printer (ROP) (optional)
o A key telephone set with loudspeaker
o A test access unit (TAU).
Page displays on the video display terminal provide the status
and control information needed to perform maintenance tasks.
Maintenance requests are input using the keyboard. The ROP
provides a hardcopy of input and output messages. Thus, a
record is available for future reference. The key telephone set
is used to communicate with work areas outside the office. This
telephone set can be used independently of the 5ESS switch,
thereby ensuring outside communication if an office outage
occurs. A loudspeaker is provided for communication at times
when maintenance personnel need the use of both hands. The TAU
provides telephone jacks that enable communications with other
work areas in the office. In addition, TAU provides access to
trunks and lines for maintenance activities.
The real-time system status is shown at the MCC video terminal
on the second and third lines of the page display. (See
Figure .AW G2/.) Thus, the occurrence of any abnormal conditions
is displayed immediately. The MCC status display must be valid
at all times. This requires monitoring of the time indicator to
ensure reliable display indications. The time-of-day indicator
(24-hour clock) at the top right of the video display is
incremented every 5 seconds. Observation of this time indicator
helps to determine if the display interface is operating. If
the indicator is not changing, the interface is not working, and
the entire video display is invalid. Figure .AW G2/ is an example of
the MCC page display design.
Whenever an alarm condition occurs, an audible/visual alarm is
activated to ensure that maintenance personnel are informed even
if the MCC terminal is not being monitored. To make it easier
for maintenance personnel to quickly locate off-normal
conditions on the video displays, various video attributes such
as reverse video, flashing, intensity, and color (optional) are
used in addition to text. The particular combination of these
attributes depends on the maintenance ``state.'' Refer to
Table .AW TAG/ for additional information on the most commonly used
MCC states and their video characteristics. When an alarm condition
occurs, the severity of the alarm is indicated by the level
indicator (CRITICAL, MAJOR, or MINOR) backlighting in the
summary status area at the top of each display. Each alarm
level (CRIT, MAJ, or MIN) also has its own distinct sound. The
unit indicator that represents the particular area of alarm
condition (for example, OVERLOAD or BLDG/PWR) flashes until the
alarm is retired. To retire the audio/visual alarms, depress
the ALM RLS function key. Once the alarm is retired, the level
indicator returns to normal video and the unit indicator stops
flashing. The alarm level color remains until the MCC page
associated with the unit has been displayed. At this point, the
unit indicator goes to black on cyan which indicates the problem
still exists but is being investigated. When the condition
causing the alarm is corrected, the unit indicator returns to
normal video.
Automatic routine tests are checks and tests run automatically
on a prescheduled basis to verify the integrity of a circuit, a
unit, or the entire system. The system has built-in self-checks
which constantly check parity, framing, and protocol of words
and messages. In addition, periodic routine exercises are run.
These exercises verify the complete integrity of all units
including both the operational and the maintenance-related parts
of units. Per-call tests are run on a line every time it is
used. Table .AW TB/ provides a list of automatic routine tests,
intervals, and functions. Audits are also run to check software
programs. Audits are run periodically and during slack call
processing periods. The Call Monitor makes test calls for
periodic analysis to detect the loss of call processing
functionality.
The MCC enhances the manual testing capabilities of the system.
Diagnostics can be run using the keyword at the MCC to input the
appropriate messages. If the appropriate input message is not
known, the user can enter the dgn:keyword?, where the keyword
for example could be ``luhlsc'' and the symbol ``?'' indicates
help when an appropriate input message is desired. Figure .AW G3/ is
an example of how the help command can be used. The first help
command gives the complete input message, and the second help
command gives the options associated with the input message.
User's actions are indicated in bold type.
In addition, many block diagram-type page displays (that is, MCC
page displays -- see Section .RM 4.2/) are available to help in
locating and identifying faults. The TAU provides a means of
connecting test equipment to various lines and trunks. Direct
connection and terminal access jacks are contained in the TAU.
Section .RM 3./ contains a description of TAU.
The duplication of common control equipment permits switching
from a faulty unit which is active to a standby unit. Thus, the
faulty unit can be taken out of service (OOS) and repaired
without impairing the switching capability of the office.
Maintenance of the system can be performed remotely by
operational support systems (OSS), located at the remote
switching control center (SCC). The MCC human interface
capabilities are available at the remote SCC. This includes the
video display, input/output, and alarm control capabilities.
The trunk and line work station (TLWS) TAU is not provided at
the remote SCC.
The objective of this maintenance plan is to identify both
hardware and software faults in the 5ESS switch before they
reach a service-affecting level. If this maintenance plan is
followed, customer complaints can be reduced to a minimum and be
a useful indication of the switch performance. If customer
complaints suddenly increase in a normal office, the complaints
can provide information useful in identifying problems and their
causes. Therefore, customer complaints can help identify the
following:
Complaint location:
o Switching module (SM) or group of SMs
o Remote switching module (RSM)
o Line unit (LU) or group of line units.
Complaint type:
o Plain old telephone service (POTS)
o Private branch exchange (PBX)
o Features
o No dial tone
o Call cutoff.
Complaint cause:
o Software update
o Change notice (CN) Application
o Unusual office activity
o Cable cut
o Nondiagnosable hardware fault.
If unusual or unresolved conditions and complaints cannot be
resolved at the local level, contact your next level of
technical support.
Until such time as the customer complaint rate is under control,
the number of customer complaints received is not an accurate
indication of switch performance. A more accurate accounting
can be achieved through the monitoring of the operational test
failures (OTFs) and the grid fabric failures.
ROP Analysis: Periodic checks should be made using the daily
reports to determine whether or not hardware faults are
occurring. AT&T 235-105-220, Corrective Maintenance Procedures,
can be used to identify the hardware involved in the following
instances (except for the line removal reports; they are covered
in this manual):
o Unit diagnostic (routine exercise) failure
o Grid fabric failures
o OTFs -- Set the verbose mode periodically to allow printing
of these messages
o Per-call test failures (PCTFs)
o Machine detected interoffice irregularities (MDIIs)
o Line removals.
Action: If any of the previous conditions occur, then go to the
appropriate section in this manual for a more complete
description and the appropriate action.
Note: If you are unable to resolve the errors after
referencing the section and documents mentioned,
then contact the next level of technical support.
ROP Analysis: Periodic checks using AT&T 235-070-100, Traffic
and Plant Measurements, Appendix 1 of Administration and
Engineering Guidelines, should be made to detect if large
numbers of the following types of messages have occurred:
o Manual action asserts
o Audits
o Interrupts [for example, single-process purges (SPP) is a
first-level interrupt].
Action: Set the print log status periodically to print these
types of messages. Upon receiving a repetition of these, refer
to AT&T 235-600-500, Asserts Manual, and AT&T 235-600-400,
Audits Manual, for the proper action to take.
Note: If you are unable to resolve the errors after
referencing the document mentioned, then contact
the next level of technical support.
Remember, initializations can cause codes 5, 7, 8, etc.,
customer complaints, so frequently check the ROP for indications
of trouble. For more information on initializations, refer to
AT&T 235-105-250, System Recovery, which has some general
information about system recovery/initialization.
Office Backup Methods: There are four levels of backup for the
5ESS switch disk drives. These levels are as follows:
a. Memory to primary disk backup
b. UNIX(R) Real-Time Reliable (RTR) operating system root
partition to backup-root partition backup
c. Office dependent data (ODD) backup to tape
d. Full office backup to tape.
For detailed procedures covering the disk drives, refer to the
Memory Allocation Procedures in AT&T 235-105-210. For
information on Backup Schedules and Guidelines, refer to
Subsection .RM 3.23.7/ in this manual.
Program update is the process that activates orderly program
changes in the switching equipment software. The changes are
made to solve a system problem. The following two types of
program updates are available:
o Official Fixes: Software updates
o Emergency Fixes: Temporary measurement plan (TMP) software
updates.
In-service offices receive most software fixes via software
updates.
The following list of operations should be adhered to when
applying software updates:
1. In a post-turnover office, when it is not in a retrofit or
restart mode, the Operating Telephone Company (OTC) is
responsible for obtaining and applying all applicable
software updates.
2. Maintain software updates to the current Software Change
Administration and Notification System (SCANS) level.
3. Follow the software update's special and soak instructions
exactly. In an in-service office, remember to SOAK all
software updates for at least a full day.
4. Some software updates require a boot of the administrative
module (AM) or a craft initialization in order to make
portions work properly; therefore, the application of the
software update should be carefully monitored by the
Switching Control Center System (SCCS) or site personnel
until it is complete.
5. When a software update requires a boot, always perform the
boot during a low-traffic period.
6. If a software update fails during application (apply, soak,
and/or official), and the situation cannot be resolved,
escalate to the next level of technical support.
Warning: DO NOT remove files such as ``Cud'' and
``.pupstat,'' or any file in ``/etc/bwm''
without first consulting with Electronic
Switching Assistance Center (ESAC), Regional
Technical Assistance Center (RTAC), or Customer
Technical Support (CTS) Organization.
This section represents some preventive maintenance procedures
needed to keep the 5ESS switch operating efficiently.
The fan filters in the 5ESS switch frames and moving head disks
(MHDs) should be checked periodically. A dirty filter will not
allow adequate air to circulate within the equipment and could
lead to early failure in the hardware.
For information regarding replacement frequency and replacement
procedures for both frame fans and MHD fans, refer to AT&T 235-
105-210, Routine Operations and Maintenance Procedures.
Review the REX output messages daily to see if any failures have
occurred. Normally, if a diagnostic failure occurs during REX,
that hardware will remain OOS and must be manually diagnosed and
restored to service.
This is a very important action to conscientiously perform. If
one side of a duplex unit fails REX diagnostics, it is not
restored. If the other side of this unit takes a fault, there
is no way to recover and the unit will be in duplex failure
mode. It is easy to see how critical this would be if the unit
was important to call processing.
Check the ROP Reference Guide section of AT&T 235-105-119,
Maintenance Guide Utilizing OMS5, for canceled or needed
REORGANIZATION messages. Determine why the relation
reorganization failed. If unable to locate the trouble or
resolve it, escalate to the next level of technical support.
All critical system status indications are provided locally and
remotely. The MCC provides real-time system status summary
indications, control and display capabilities, and human
interface. These capabilities are also remoted to the remote
switching control center. System status and alarm indications
are displayed on the remote switching control center critical
indicator panel.
The status display provides a comprehensive presentation of
system conditions including the following:
o Alarms and other abnormalities
o Abnormal load conditions
o Significant control in effect
o Individual unit status.
The status display is made up of abbreviated name displays of
each monitored unit or condition. Normal operating conditions
are displayed in dynamic (light on dark) text. Trouble
conditions are displayed in steady bold reverse video (dark
letters on enlarged bright background) or a color combination.
All alarm conditions are displayed by a unit indicator such as -
AM, SM, and a level indicator - (CRITICAL, MAJOR, or MINOR).
An audible indication is also sounded as follows:
o In minor alarm conditions, the minor alarm horn sounds (if
office is equipped).
o For major alarm conditions, the audible alarm chimes at a
slow rate.
o For critical alarm conditions, the audible alarm chimes at
a fast rate.
There are two system alarm release modes: automatic alarm
release and manual alarm release. If the system is in the
automatic alarm release mode, the audible alarm and the flashing
alarm conditions are released 5 seconds after initialization.
If the system is in the manual alarm release mode, the audible
alarm and flashing alarm conditions are released by operating
the ALM RLS function key on the video terminal keyboard. Minor
audible alarms are retired after 5 seconds in either mode.
Released alarms and controls in effect remain in the alarm
condition until the system has been restored to normal operating
condition. The alarm release mode is changed via a maintenance
command available on display Page 105/106, 116, or an input
message. Table .AW TC/ lists MCC status indicators and their
meanings.
Note: A display administration process (DAP) terminal
must be used to access the control and display
portion of the MCC or remote switching control
center video display. The DAP terminal can be used
to perform any command that is needed to maintain
the switch (for example, poke command 330 on MCC
display Page 1240 restores MSGS 0 to service).
These terminals are defined in the data base, and a
number (office dependent) of DAPs can be assigned.
A maximum of eight DAP terminals for 5E6 or sixteen
DAP terminals for 5E7 and later can be used
simultaneously per switch.
Non-DAP terminals enable the user to perform the
same functions as DAP terminals except for being
able to access and display the MCC page displays.
The non-DAP terminals use message mode commands to
maintain the switch (for example, input message,
RST:MSGS=0).
The control and display portion of the MCC or remote switching
control center video display is used to monitor at a subsystem
level. Control and display consists of many separate pages that
can be displayed individually. Each page shows the operating
condition and a menu of possible input commands for a particular
subsystem. Figure .AW G4/ shows a control and display page. The
display conventions used for equipment status are also used for
all control and display page displays. An index page is
provided to allow quick access to any of the control and display
pages during trouble situations. A message page is used
whenever control and display information is not required (that
is, the display of system status is all that is desired). This
avoids confusion, since the display provides only the system
status and input message information when the blank page is
used. (Figure .AW G2/ shows the video display as it appears with the
blank page display.)
The input message area is used for inputting human interface
messages. Refer to Section .RM 3./ of this document for details of
how to use input messages.
Any deviation from normal system operating conditions produces a
printout on the MCC or remote switching control center. The
printout contains all data relevant to the condition, diagnostic
results, and a list (by priority) of suspected faulty circuit
boards. Periodic traffic and plant summaries are also printed
on the printer. All of these printouts are important in
determining system status, with diagnostic information and
circuit board lists being of primary importance to maintenance
personnel. The printer should be connected whenever maintenance
is being performed in the office. For detailed analysis of
printouts, refer to AT&T 235-600-750, Output Messages Manual.
Routine maintenance is performed on a specified schedule to
secure maximum performance of the total network. Since peak
load periods and features are different from office to office,
some tests (for example, REX test) may not have specific test
schedules that are best for all of the offices. In this
situation, the equipment test list (ETL) can be very helpful in
giving references to procedures and recommended time intervals
to perform these types of tests.
Refer to AT&T 235-105-210, Routine Operations and Maintenance
Procedures, for the 5ESS switch routine maintenance schedules
(residing in the ETL). More importantly, this manual contains
descriptive and detailed procedures for the schedules listed in
the ETL.
Nonscheduled routine maintenance procedures are basically those
procedures that are not listed on the ETL. The following list
contains some of the nonscheduled operations:
o System Control Functions:
a. Loading automatic message accounting (AMA) tapes
b. Set/change date and time
c. Alarm system assignments.
o Call Trace Procedures:
a. Nuisance call trace
b. Interoffice call trace
c. Utility call trace.
o Miscellaneous Routine Procedures:
a. Bring up AMA teleprocessing system (AMATPS)
b. Bring up central trunk test unit (CTTU)
c. Bring up Engineering Administration Data Acquisition
System (EADAS).
o Memory Alteration Procedures:
a. Request software update summary
b. Obtain ODD backup schedule
c. Load software updates from tape.
For the complete list of nonscheduled routine operations, refer
to AT&T 235-105-210, Routine Operations and Maintenance
Procedures.
The video display pages are used together with the system status
display and ROP output messages to isolate a hardware trouble to
a specific unit. Then the system's diagnostic and grid exercise
programs are used to pinpoint the trouble to the specific
circuit pack(s) as described in Section .RM 2.5.3.2/, Hardware Repair
Procedure (following). Also, a simplified trouble location
procedure is shown in Figure .AW G5/.
Note: Periods of AM insanity may affect MCC display and
functional capabilities.
Automatic trouble location is an integral part of the diagnostic
and grid exercise programs in the 5ESS switch environment.
These programs are designed to test functions at the circuit
pack (board) level. Therefore, most test failures can pinpoint
the fault to a small number of circuit packs.
The diagnostic and grid exercise programs maintain a list (by
priority) of suspect circuit packs at each test point in the
diagnostic. During execution, this list expands and contracts
as testing shifts attention among the hardware. Upon the first
failure, the current circuit pack list is converted to a
suspected faulty equipment list containing location information
and printed on the ROP. Combined use of this list and the frame
and shelf-mounted designation strips provide direct access to
suspect circuit packs. The trouble repair procedures in AT&T
235-105-220, Corrective Maintenance Procedures, should be used
to replace the faulty circuit pack. A sample faulty equipment
list printout is shown in Figure .AW G6/.
For each circuit pack, the following information is given:
o AISLE: Aisle equipment frame location within the office.
o MODULE: Switching module number.
o CABINET: Cabinet type and number.
o CODE: Circuit pack number.
o FORM: Equipment forms. A form can be one of two types as
follows:
a. Series number with carrier pack
b. Issue number with micro code.
o EQL: Equipment physical location [for example, 53-016
(where 53 = vertical distance, in inches, of the circuit
above the floor and 016 = horizontal distance of circuit
from LEFT edge of bay in 1/8-inch increments)]. A third
field [53-016-XX, where XX = depth (in the unit) in 1/10-
inch increments] is also included.
o TYPE: Helper unit.
Note: When a note (for example, 8) appears in this
column, refer to the ``TLP (Trouble Locating
Process) NOTE APPENDIX'' in AT&T 235-600-750,
Output Messages Manual.
o DGN: Diagnose.
o LUHLSC: Line unit high-level service circuit.
Another maintenance tool available to maintenance personnel for
locating trouble is the utility call trace. Utility call trace
allows users to do the following:
o Snapshot the hardware path representing a call connection.
o Trace all connections of a call.
o Trigger a call trace with a utility break point.
o Print the path of the call through the switch in diagnostic
format on the ROP and show it on the MCC screen.
Craft and/or maintenance personnel can also use utility call
trace to trace test calls. For example, to troubleshoot
customer complaints, a test call can be traced to or from the
customer to see what hardware is in use.
In the 5ESS switch, data base inconsistencies can be identified
by asserts and audits. The results of the asserts and audits
can be sent to the system log file and/or the ROP. Audits and
asserts are used in the 5ESS switch to verify and check the
validity of software data structures such as the ODD and
equipment configuration data (ECD) in the AM. Data base repair
procedures are provided in AT&T 235-105-220, Corrective
Maintenance Procedures.
Reconfiguration is necessary to prevent faulty hardware from
affecting system processing. Equipment can be reconfigured
either automatically or manually. Basically, reconfiguration
consists of the following:
o Appointing other hardware to assume functions of the faulty
hardware
o Removing traffic from the faulty hardware
o Removing faulty hardware from service
o Updating system status with appropriate alarms, indicators,
printouts, etc.
Since the 5ESS switch varies in size and equipment usage, the
recovery procedures vary in complexity. The large office
obviously has a wider range of reconfiguration possibilities
since it contains more hardware. Fault recovery is performed at
a subsystem level whenever possible. Only the fault-associated
subsystem(s) is affected during recovery.
When a hardware fault is identified, the system begins automatic
recovery procedures. If the system is in good operating
condition prior to the fault and the fault is not catastrophic,
automatic recovery should restore normal processing. Automatic
recovery performs all the reconfiguration and initialization
processes necessary to correct the problem. Automatic recovery
restores the system in the great majority of all faults.
Manual reconfiguration is used in the repair of a unit following
automatic recovery or if automatic recovery does not place the
faulty unit OOS and restore processing. Most manual
reconfiguration is done from the MCC or the remote maintenance
center (if provided). There are several numeric input commands
on the control and display pages that can be entered from the
terminal keyboard. They are as follows:
o REMOVE: This series of commands (2XX and 2XXX) reroutes
traffic from the affected unit and places the unit OOS.
o RESTORE: This series of commands (3XX and 3XXX) diagnoses
the unit to determine if it is capable of operating. If
diagnostic returns all tests passed (ATP) or conditional
all tests passed (CATP), the unit will be restored to
service. Otherwise, the unit is left OOS.
o SWITCH: This series of commands (4XX and 4XXX) causes all
traffic and processing to be switched to the mate
controller.
o DIAGNOSE: This series of commands (5XX and 5XXX) requests
diagnostics to be run on specified unit(s). The unit
remains out of service until manual restoral to service is
requested.
o FORCE: This series of commands (4XX and 4XXX)
unconditionally forces operation to the desired unit and
puts the mate unit OOS Forced Unavailable.
All of these commands are entered conditionally, and the system
enables them. The video page display for each unit has a menu
of commands (and input codes) available for that unit. If the
system is experiencing problems, it may not honor these input
requests. Unconditional options and manual overrides are
provided for these cases. The amount of direct control
available depends on the type of unit involved.
Fully duplicated (duplex) units [for example, message switch
control unit (MSCU), office network timing complex (ONTC), and
module controller/time slot interchanger (MCTSI)] contain
control/display (CD) packs with several status light-emitting
diodes (LEDs) and manual reconfiguration switches. The CD packs
such as the SN412, SN516, and the TN1077 all contain four
switches and five LEDs which provide and display the following
capabilities:
o ON: A momentary pushbutton switch used to power up the
unit.
o OFF: A momentary pushbutton switch used to power down the
unit only if that unit is not in service or is unavailable.
o RST/ROS: A rocker switch used to request a unit be
restored to service or conditionally removed from service.
o MOR: A momentary manual override switch. Whenever this
switch is simultaneously depressed with the OFF switch,
power is turned off regardless of the hardware state (ACT,
STBY, or OOS).
o OFF: A red LED that lights whenever unit power is off.
o ALM: A red LED that lights whenever there is a power fault
on the unit (fuse or converter alarm). Note that in the
alarm state, all power may not be off in the unit. Once
maintenance personnel power down the unit for repairs, the
OFF LED lights and the ALM LED goes off.
o OOS: A yellow LED controlled by the system. This LED
lights whenever the unit is out of service.
o RQIP: A green LED controlled by the system. This LED
lights whenever a request to restore or remove a unit from
service has been received by the system. If this request
is denied or fails, this LED flashes for 5 to 6 seconds.
The LED goes off when the requested action has been
completed.
o ROS: A green LED that lights whenever the restore/request
out-of-service (RST/ROS) switch is in the ROS position.
Figure .AW G7/ shows an example of the SN412/SN516 CD pack.
Table .AW TD/ summarizes duplex control and display pack features for
the 5ESS switch.
Unduplicated (simplex) units are not equipped with control and
display packs. All simplex requests (RST, ROS, etc.) are input
via an input message. Simplex status [request in progress
(RQIP, OOS, etc.)] is displayed and printed at the MCC or SCC.
The AT&T 3B20D computer units are equipped with the TN5 AM C/D
pack shown in Figure .AW G8/. This pack is equipped with an
additional alarm cutoff/test (ACO/T) LED and switch that the
SN412 and SN516 packs do not have.
Unit controller conditions must be known at all times. This
information is needed to define system status. Four general
status states have been defined for the 5ESS switch unit
controllers. They are active, standby, out of service, and
unavailable. Table .AW TE/ summarizes basic controller states. At
times, it is necessary to know how, or why, a controller entered
a particular state. A set of state-qualifiers has been
developed to further define a controller state. A combination
of qualifiers may be required to specifically define a state.
Table .AW TF/ shows qualifiers used and sample applications in the
5ESS switch.
All duplex subsystems follow the same general methods of manual
reconfiguration. Reconfiguration is accomplished by manual
inputs at the MCC or remote maintenance center and/or the unit
control and display circuit pack. Since simplex units are
unique, they cannot be reconfigured as such. Therefore, circuit
board replacement is the method of restoring simplex units.
The other part of system recovery is initialization. Serious
system difficulties may be caused by equipment (hardware)
troubles, difficulties in executing the program (software), or
by human error.
Caution: If the system is failing to process calls
properly (is not able to complete test calls,
etc.), the system should be automatically
attempting to recover itself by taking automatic
emergency actions. This should be indicated to
office personnel by status indicators,
printouts, switching of system controllers, etc.
If automatic emergency actions do not restore
normal system processing and control, manual
emergency actions or system recovery procedures
will be required.
The distributed processing architecture of the 5ESS switch
employs many autonomous processors. The main processing units
are the AM, the Communication Module Processor (CMP), and the
individual SMs. Initialization can treat these processors both
independently and collectively. Therefore, the following four
types of initialization have been defined:
o AM Initialization: This is an initialization of the AM.
o CMP Initialization: This is an initialization of the CMP
(added in 5E6).
o SM Initialization: This is an initialization of the SM.
o System Initialization: This is a complete initialization
of the AM, the CMP, and the SMs.
Note: Although slightly different actions can take place
at each level in the AM, CMP (added in 5E6), and
SMs, the overview of the philosophy and objectives
of the initializations are the same. The various
levels of recovery, their attributes, and recovery
time estimates for individual SMs, the CMP, and the
AM are explained in Table .AW TG/.
In any case, the stimulus of an initialization is the failure of
a check that indicates if the integrity of a processor or data
base is questionable. Initialization is caused by a signal
which is generated when the hardware or software detects an
error (resets). It can also be caused by manually inputting
initialization requests (interrupts) at the video terminal
keyboard. An initialization consists of some or all of the
following:
o Restoring processor(s) to a good software state
o Restoring the periphery to a good software state
o Aborting certain activities
o Zeroing or setting temporary data to a known good state
o Reloading the memory from disk file.
Not all of the preceding actions are performed on every
initialization. An initialization can be more or less drastic
depending on which and how many of the preceding routines are
performed. The degree of initialization is determined by the
system level count. The level count is incremented each time a
recovery attempt fails within a predetermined time lapse. The
higher the level count, the more drastic the recovery actions
become.
After an initialization occurs, an initialization timing
interval exists for a short period of time. If no other
initializations occur within this time interval, the level count
will be reset to zero. For detailed information on
initializations and recovery procedures for the 5ESS switch,
refer to AT&T 235-105-250, System Recovery.
This is the lowest level of software initialization. It is
performed automatically in response to audit features, user
program defensive check failures (asserts), and restarting from
maintenance interrupts. Action associated with this level may
be as follows:
o Localized initialization of user-owned global data
o Scheduling elevated audits
o Logging failure information.
Control flow is then returned to the previously interrupted
point.
The single-process purge (SPP) level is used whenever an error
is detected which is severe enough to make it unsafe to return
to the point of interrupt. The initialization action varies
somewhat with the processing environment, but the primary
objective is to restore a software configuration that can
support resumption of normal processing. In general, the
recovery actions associated with an SPP are as follows:
o The running process or task is killed and, if essential,
reinitialized.
o Any global data being used by the process is restored.
o Any hardware or software resources are recovered.
o Any associated processes are informed.
o Control is reestablished at a ``safe point.''
o Failure information is logged.
Some recovery may be performed on a deferred basis by audits
requested by the purge. In terms of call processing, if the
current process is associated with a call, the call will be
idled and the subscriber given reorder or dial tone. Wideband
calls will be idled if the process is associated with a wideband
call.
Directed audits are used as an initialization action whenever
inconsistencies are discovered in critical data structures such
that continued operation is not possible. This level is
generally invoked from either an audit or a user program
defensive check failure (assert). The action taken is to audit,
in an unsegmented mode, enough data to ensure that system
operation can resume, and to schedule on a deferred basis any
additionally required audit activity. Restart from a directed
audit is generally via a single-process purge of the current
process. Again, failure information is logged. If the running
process was associated with a call, the call will be idled and
the subscriber given reorder or dial tone.
This is a full initialization of a single AM kernel process.
All dynamic nonshared data is initialized or audited. All data
shared among known processes is audited. In 5E6 and later
software releases, common channel signaling is suspended during
this short initialization.
A selective initialization (SI) is a high-level initialization
(although it is the lowest level processor-wide recovery
action). This initialization can be performed automatically due
to recovery actions or manually by maintenance personnel. The
basic actions of an SI in the various processors are described
as follows:
o In the AM, an SI includes an unconditional bootstrap for
all static text and data for both the UNIX RTR operating
system and the 5ESS switch application processes. Then,
all dynamic data is either initialized or audited (OOS
hardware status and stable calls are preserved). Call
processing functions in this processor are suspended during
this time interval, but stable calls are preserved.
o In the CMP (5E6 and later software releases), an SI does
not include any hashsum checks or pumps. All dynamic data
is either initialized or audited. Call processing
functions are suspended during this interval, but stable
calls are preserved.
o In the SM, an SI does not include any hashsum checks or
pumps. All dynamic data is either initialized or audited,
preserving OOS hardware status and most stable calls
(certain connections that would appear to be stable are
disconnected due to their more complex dynamic data or
ongoing message interaction with the switch, that is, 3-
and 6-way calls and AP data links). Call processing
functions within the initializing processor are suspended
during the initialization interval. A manual SM selective
initialization with an unconditional full pump is available
(though it has additional affects on the SM of longer
downtime and, possibly, a few lost stable calls due to the
pump use of time slots).
Note: Stable calls over SM selective initialization
include wideband.
Options to back out temporary recent changes and program updates
are supplied when pumps are involved in the previous processors.
A full initialization (FI) is the highest software level of
processor-wide recovery actions. The FI can be performed
automatically due to recovery actions or manually by maintenance
personnel. There are several types of FI which can be used (for
example, power up FI and FI with pump) each of which changes the
severity of recovery action. Every FI will initialize hardware
at some level even though it is mainly a software
initialization. Different hardware levels will be seen
depending on the processor being initialized. The basic actions
of an FI in the various processors are described as follows:
o In the AM, an FI includes an unconditional bootstrap of all
static text and data for both UNIX RTR operating system and
the 5ESS switch application processes. Then, all dynamic
data is initialized. When the AM undergoes an FI, the
hardware level selected can cause the loss of stable calls
routed through the time multiplexed switch (TMS). During
the initialization of the AM, the SMs are supplying dial
tone and giving reorder to the customers or processing
intra-processor SM calls if the stand-alone option is
utilized. In 5E6 and later software releases, call
processing will be maintained during an AM FI except at the
highest hardware level, which reinitializes the TMS. New
CCS calls will be inhibited until the CNI Ring is
initialized.
o In the CMP (5E6 and later software releases), an FI does
not affect stable calls although any transient calls being
processed at the time of the FI will be lost. The FI
includes a conditional partial pump of any static text or
data that fails to pass a hashsum check against a disk copy
of the hashsum tables. All dynamic data is initialized.
Both manual and automatic full CMP initialization with an
unconditional pump can be invoked.
o In the SM, an FI includes a conditional partial pump of any
static text or data that fails to pass a hashsum check
against a disk copy of the hashsum tables. Then, all
dynamic data is initialized. Depending on the type of FI,
an FI will also be performed on the SM's peripheral
hardware and software. Any transient and stable calls being
processed by the processor undergoing the full
initialization or on connected peripherals will be lost. A
manual SM full initialization with an unconditional pump is
available.
Options to back out temporary recent changes and program updates
are supplied on any pump of the various processors. Office
bring-up and dead-start situations use a manual system-wide FI
(that is, AM, CMP, and all SMs).
A postmortem dump is normally printed via the ROP to permit
analysis of the cause of the system troubles; however,
postmortem dumps can be logged in the postmortem dump log
(PMLOG) or the DAYLOG file. The output message class (MSGCLS)
is used by the maintenance personnel to specify where the
postmortem dumps are to be sent, that is, to the physical device
(ROP) or the software device (PMLOG or DAYLOG). Output consists
of all data relevant to the trouble, such as the following:
o Value of program counter at time of occurrence
o Value of latched address and data bus
o System process that last had control
o Values of internal control registers
o Stack area values of last system process
o Contents of register area for last system process
o Contents of all error registers which indicate the source
of the error(s)
o Contents of counters used for escalation to higher levels
of initialization.
An SM postmortem dump is normally sent to the ROP approximately
1 to 5 minutes after the system has gained sanity. The first
report to indicate an SM initialization has been started is the
high-level initialization report. The first line is as follows:
REPT SM=a INITIALIZATION TRIGGER=bb EVENT=cc
Refer to AT&T 235-600-750, Output Messages Manual, for details
concerning the REPT SM message.
Efforts should be made to analyze the cause of the
initialization and to verify that the SM recovers properly.
When the SM recovers, analyze the postmortem dump and any
related error reports. The related reports will have the same
event numbers.
If the postmortem dump is not printed automatically, it is
possible to obtain the postmortem dump by using the input
command:
OP:POSTMORT,SM=a [,OFL] [,SPP] [,EVENT] [,ESCAL] [,RCVY] [,DCF];
Refer to AT&T 235-600-750, Output Messages Manual, for details
concerning the OP:POSTMORT,SM message.
The postmortem dump report contains information about type and
source of the interrupt that occurred in the SM controller and
the resulting level of initialization. This report has two
possible formats, the shortest of which is normally printed on
the ROP, while the extended version is stored in the log file
DAYLOG.
The log file DAYLOG is kept in general to locate severe software
faults. The contents of the file can be dumped by entering the
following message for 5E6 and later software releases:
OP:LOG:LG="DAYLOG"[:[DATE=b[&&c],][TIME=d[&&c],][KW="f",][ID=g,]
[MSGCLS=l|TYPE=h,][LIMIT=i,][,CLASS=j|,DEVICE="k"]];
Refer to AT&T 235-600-750, Output Messages Manual, for details
of this message.
The short version of the previously mentioned SM postmortem dump
reports has the following format:
REPT SM=a,b HWLVL=c SWLVL=d e f g EVENT=h i
j-ERR FAILING ADDR=k PROCESS:BG=r,s,t CM=u,v FG=w,x,y z
[,TYPE=h] [,LIMT=i] [,CLASS=j|,DEVICE=k]]
The extended version from the log file DAYLOG looks as follows:
REPT SM=a,b HWLVL=c SWLVL=d EVENT=h i
e f g
j-ERR FAIL-ADDR=k l-m DATA-BUS=n TIME=o:p.q
PROCESS: BG=r,s,t CM=u,v FG=w,x,y z
ORIG-HW-STATUS: a : b c d a : b c d
FINAL-HW-STATUS: a : b c d a : b c d
PREVIOUS TYPE/COUNT: e f
SHADOW TYPE/COUNT: g h
AUX DATA: m n o p
ESCALATION-COUNTS: i j k l
Refer to AT&T 235-600-750, Output Messages Manual, for details
of the REPT SM message.
In addition to the postmortem dump reports, related error
reports should be analyzed to locate the fault. Related error
reports will have the same event number. Examples of related
error reports are illustrated as follows:
o INIT SM=a LVL=b SUMMARY EVENT=g ...
o INIT SM=a,b LVL=c OSDS-M EVENT=f g
o REPT SM=a DLI HW REGS EVENT=g ...
o REPT SM=a SP HW REGS EVENT=b ...
o REPT SM=a TSI HW REGS EVENT=c ...
o REPT SM=a CI b HW REGS EVENT=c ...
o REPT SM=a PI b HW REGS EVENT=c ...
o REPT SM=a RLI b HW REGS EVENT=c ...
o REPT SM=a MC b HW REGS EVENT=c ...
Suppressing 5-Minute Automatic Dumps: The input command
RLS:POSTMORT,SM=a; (MML format) may be used to suppress the 5-
minute automatic dump. The command also clears the postmortem
area; otherwise, the area will be cleared automatically 1 hour
after the initialization.
Error Source of Interrupt: In the report REPT SM=a,b HWLVL=c
SWLVL=d e f EVENT=h i, field ``e'' reports hardware subunit
which triggered the interrupt, and field `` f '' indicates the
source of the error that caused the interrupt (see AT&T 235-
600-750, Output Messages Manual).
A CMP postmortem dump contains information about the error(s)
that caused the CMP to take recovery action. Information is
sent to the ROP, usually within 1 to 5 minutes after the system
has gained sanity, and is displayed in several types of output
messages beginning as follows:
REPT:CMP INIT:CMP REPT CMP= POSTMORT
For additional information on these messages, refer to AT&T
235-600-750, Output Messages Manual.
If the postmortem dump is not printed automatically, it can be
requested via the following input message:
OP:POSTMORT,CMP,[EVENT][,RCVY][,DCF];
To suppress the 5-minute automatic dumps, enter the input
command beginning as follows:
RLS:POSTMORT,CMP=a;
For details of both messages, refer to AT&T 235-600-700, Input
Messages Manual.
Note that the ``RLS'' message ``unlocks'' the area where
postmortem area is stored, that is, allows it to be overwritten
with information about subsequent postmortems. Otherwise, the
system preserves postmortem information for an hour.
There may be additional error reports and status dumps that
provide more information about the error(s). They will have the
same event numbers as the postmortem dumps. Some information is
stored in a log file on disk. To display information from the
log file, enter the following message:
OP:LOG:LG="DAYLOG"[:[DATE=b[&&c],][TIME=d[&&c],][KW="f",][ID=g,]
[MSGCLS=l|TYPE=h,][LIMIT=i,][,CLASS=j|,DEVICE="k"]];
For details, refer to AT&T 235-600-700, Input Messages Manual.
Try to analyze the cause of the initialization and verify that
the CMP recovers properly.
Software in the various peripheral controllers of the
communication module (CM) produces several types of postmortem
dumps. Each is identified by the controller which produced it.
All have the following form:
REPT:POST MORTEM a EVENTNO=b
The peripheral controllers which produce postmortem dumps for
both CM1 and CM2 are as follows:
o CLNK = Communication Link
o MSCU= Message Switch Control Unit
o MMP = Module Message Processor
o PPC = Peripheral Pump Controller
o FPC = Foundation Peripheral Controller
o TMS = Time Multiplexed Switch
o CMP = Communication Module Processor (for software releases
5E6 and later).
The basic format of the postmortem dumps on the units listed
previously is as follows:
REPT:POST MORTEM a EVENTNO=b
cccccccc
The variable field definitions are as follows:
o a = hardware identity (for example, MSCU=0)
o b = decimal number indicating the event number
o c = hexadecimal array of eight digits in a sequence of
eight words and in four lines.
Each of the hardware identities listed previously is explained
in detail in AT&T 235-600-750, Output Messages Manual.
The postmortem dump report for the TMS hardware identity is an
exception to the general format that the other hardware
identities follow. The format for TMS is as follows:
REPT POST MORTEM DUMP TMS=a EVENTNO=b
c c c c c c c c
The variable field ``cccccccc'' can appear more than once;
however, the most useful information is contained in the first
four words.
With the various postmortem dump reports, an autonomous dump on
the Network Clock is possible. The layout of this report is as
follows:
DUMP NC a b c
NETWORK CLOCK a CCB/CLRT REGISTERS X'
dddddddd
This message can be used to identify the exact problem according
to the bits that are set as shown in the format description.
For details of this message, refer to AT&T 235-600-750, Output
Messages Manual.
Note: Information concerning the register layouts for the
registers referred to in the error reports (in the
log files) can be obtained from the Appendixes
section of AT&T 235-600-750, Output Messages
Manual.
Two types of interrupts may occur in the AM. These interrupts
are indicated by either a REPT CU a ERROR INTERRUPT or a REPT CU
a MAINTENANCE INTERRUPT report. When either of these reports
are printed on the ROP, more information about the interrupt is
written in a log file. The AM uses three error log files:
memory history log (MEMLOG), error interrupt handler log
(ERLOG), and automatic postmortem log (PMLOG). Entries in the
MEMLOG file and the ERLOG file are generated with an REPT CU
interrupt report. Entries in the PMLOG file are generated
following a system initialization and are accompanied by an REPT
CU interrupt report.
Each log file entry has a sequence number associated with it.
Since all three log files use the same sequence counter, the
order in which a set of entries occurs can be determined from
the sequence numbers. These numbers appear in the REPT CU
interrupt report. Each entry has a date and time stamp to
relate log entries to other printouts. Therefore, it is
important to save the ROP output of the last 12 hours prior to a
REPT CU interrupt report to be able to extract any data that
might be useful for error analysis.
Memory Error Types: When a MEMLOG report must be analyzed, the
type of memory error can be indicated in the report.
Descriptions of these errors are as follows.
o ERROR A: An OR of internal memory hardware checks resulted
in error detection. If this occurs in the active control
unit, a stop-and-switch occurs. At least one bit is set in
error register 1 (ER1) bits 0-11 or 22. In the trapped
address register (TAR), the bits 28 and 29 are both reset.
o ERROR B: An out-of-range address is detected. The bits
0-11 and 22 in ER1, plus the bits 28 and 29 of TAR are all
reset.
o ERROR C: The Hamming check circuitry detected a multibit
uncorrectable error during a system access of memory. TAR
bit 29 is set.
o ERROR D: A correctable data parity of Hamming check error
or uncorrectable refresh error is detected (during system
access or refresh access). TAR bit 28 is set.
Error Interrupts: Normally error interrupts are nonfatal
errors, detected by the system in either the on-line or standby
control unit. However, they can escalate to a processor switch
or an initialization if preset thresholds are exceeded. When an
error interrupt occurs, the information printed on the ROP or
contained in the log files can be used for error analysis. The
log file information should be saved in case the next level of
technical support is needed.
The error interrupts can be classified into the following three
areas:
1. Less serious hardware errors (for example, memory errors,
input/output errors, or refresh parity)
2. Errors related to standby CU in a duplex (active/standby)
configuration
3. Software-related errors.
When error interrupts occur, the associated information is
written in one of the following error log files:
o MEMLOG
o ERLOG.
If the REPT CU a ERROR INTERRUPT b c is output, the ``a''
indicates the control unit side 0 or 1; the ``b'' indicates the
interrupt type; and the ``c'' indicates the sequence number
under which supplementary data is available in the particular
log file. Therefore, when log file output is requested, this
sequence number should be specified for the parameter ``KW'' in
the input command:
OP:LOG:LG=a[:DATA,DATE=b[&&c]] [,TIME=d[&&e]] [,KW=f] [,ID=g]
[,TYPE=h] [,LIMT=i] [,CLASS=j|,DEVICE=k]];
The variable ``a'' equals the log file name (that is, MEMLOG or
ERLOG).
Maintenance Interrupts: Maintenance interrupts are output after
a system initialization. These reports indicate that a
maintenance reset function (MRF) has occurred. The postmortem
dump, normally printed automatically or requested via OP:LOG: a
message, can be used to determine the problem. The variable
``a'' in this situation equals PMLOG. See AT&T 235-600-750,
Output Messages Manual, for details of the OP:LOG: a message.
The postmortem dump is used to determine the reason for a
particular initialization. The data provided consists of most
of the critical hardware registers from both control units and
some nonhardware type of information dealing with the past and
present configuration of the AM. The start of an initialization
is usually indicated by the following reports:
o REPT CU a MAINTENANCE INTERRUPT (where a = the member
number)
o REPT PHASE IN PROGRESS
o START OF CU a RECOVERY (where a = the member number).
Normally, the first report printed is the START OF CU a RECOVERY
report. The MAINTENANCE INTERRUPT indicates the associated log
entry in the PMLOG. The AM postmortem dump is subdivided into
the following sections:
Note: The AM postmortem dump sections are described in
AT&T 235-600-750, Output Messages Manual.
o Heading: The PMLOG reports are either labeled MAINTENANCE
INTERRUPT or POSTMORTEM DUMP. The header POSTMORTEM DUMP
will appear in a manually requested initialization and
sometimes when the initialization was started due to the
application software.
o Initialization message: This section indicates the source
of initialization, the on-line processor at the time of
initialization, the processor actually involved in the
initialization, and the recovery action that took place.
Also, the source of the request is indicated (by the SOURCE
field): hardware, software, or manually requested. Note,
this source does not indicate the problem source.
o Requested initialization parameters.
o EAI buffer.
o Timer.
o General registers.
o Faulty CU registers.
o Interrupt stack saved state.
o Off-line registers.
o Main store registers.
o Real-time clock.
The faulty control unit registers, timers, and the main store
registers are primarily of interest when the initialization is a
hardware request. When the initialization is software
requested, the requested initialization parameters and the
general registers are of interest. The initialization message
should be analyzed for both types of initialization.
Postmortem Analysis: When a postmortem dump is generated, the
response would be a REPT CU a MAINTENANCE INTERRUPT b report,
where ``b'' indicates the sequence number belonging to the
postmortem dump entry in the PMLOG file. When not printed, the
postmortem dump can be requested via the OP:LOG:LG="PMLOG",KW=a;
(a = the sequence number). Refer to AT&T 235-600-700, Input
Messages Manual, for details of the OP:LOG message.
The Operating Service Position System (OSPS) maintenance is
provided by AM software, switching module processor (SMP)
software, and firmware located in the link adapter unit (LAU),
the video display terminal (VDT), the basic services terminal
(BST), and the combined services terminal (CST). The OSPS
maintenance, through software in the areas of system
initialization (SI) and recovery, terminal maintenance (TM), and
the human/machine interface, support OSPS maintenance in the
following areas:
o OSPS operator positions (VDTs, BSTs, and CSTs)
o Data links [Directory Assistance System/Computer (DAS/C),
Real-Time Rating System (RTRS), etc.]
o Remote alarms
o Miscellaneous OSPS features [automatic charge quotation
(AUTOQUOTE), busy line verify (BLV), etc.].
Refer to the following manuals when performing OSPS maintenance:
o AT&T 250-505-100, OSPS Description and Procedures
o AT&T 250-505-11X, OSPS Maintenance and Growth (X = manual
number associated to the applicable software release)
o AT&T 250-520-100, OSPS Directory Assistance/Listing
Services Basic Services Terminal, Description and Operation
o AT&T 250-520-105, OSPS Toll and Assistance Video Display
Terminal, Description and Operation
o AT&T 250-520-110, OSPS Combined Services Terminal,
Description and Operation.
Refer to AT&T 235-001-001, Documentation Description and
Ordering Guide, for the complete list of OSPS manuals.
The 235-XXX-XXX manuals do not provide maintenance procedures
for the repair of equipment manufactured by vendors other than
AT&T (for example, tape drives and disk drives). To identify
the appropriate maintenance manual for each unit of such vendor
equipment, refer to Section 3 of AT&T 235-001-001, Documentation
Description and Ordering Guide.
The objective of this section is to provide a working knowledge
of LU architecture, necessary to understand and resolve complex
LU problems.
Note: This subsection contains only the introductory
information concerning LU problems. Refer to AT&T
235-105-220, Corrective Maintenance Procedures,
for the procedures needed to resolve the LU
failures.
Currently there are three types of 5ESS switch analog LU in use.
These LUs are referred to as the Model 1 LU, the Model 2 LU, and
the Model 3 LU.
The Model 1 LU is a 2-shelf unit and, when fully equipped, it
contains 48 circuit packs and two (-48 V to 5 V) DC power
converters. The Model 1 LU grids contain three circuit packs
each.
The Model 2 LU is also a 2-shelf unit and, when fully equipped,
contains 38 circuit packs and two (-48 V to 5 V) DC power
converters. The Model 2 LU grids contain two circuit packs
each.
The Model 3 LU is a 2-shelf unit. When Model 3 is fully
equipped, it contains 40 circuit packs and two DC power
converters. The Model 3 LU consists of 10 grids. Each grid
consists of two circuit packs.
The Model 1, Model 2, and Model 3 LUs are fused identically. At
the power distribution bay, one 20-amp fuse for each LU is used
to provide -48 V DC power to the SM cabinet local fuse panel.
Twelve 70-type fuses, at the local fuse panel, are assigned to
distribute -48 V to each LU.
The LU is a peripheral unit and is located in the SM. Up to
eight LUs may be assigned to one SM. The most important
function that an LU has to perform is to connect an analog
subscriber line to the 5ESS switch. To accomplish this, the
line must be connected to a channel. The analog voice then is
converted to pulse code modulation (PCM) digital data, and the
PCM digital data is then put on a peripheral time slot.
One fully equipped LU:
o Model 1 or Model 2: Has the capability of serving 512
subscribers
o Model 3: Has the capability of serving 640 subscribers.
With 64 peripheral time slots available to each LU:
o Model 1 or Model 2: Has a ratio of 512 lines to 64 time
slots, or a concentration ratio of 8:1.
o Model 3: Has a ratio of 640 lines to 64 time slots, or a
concentration ratio of 10:1.
Any condition that causes an LU service group to be removed from
service, also causes the line to channel concentration ratio of
that LU to be changed (for example, in a Model 2 LU, it changes
from 8:1 to 16:1). This will usually result in slow dial tone,
no dial tone, or incoming calls going to recorder. To avoid
customer complaints, it is recommended that LU service groups
not be removed from service during heavy traffic hours. If a
service group is forced OOS automatically, by peripheral fault
recovery, it should be treated as a service-affecting condition
and repaired and restored to service as soon as possible.
Each LU is controlled by a peripheral interface control bus
(PICB). Also, each LU is connected to a peripheral interface
data bus (PIDB). The PIDB is used to send and receive PCM
digital voice time slots, between the LU and the time slot
interchanger (TSI). Each LU is assigned a total of 64
peripheral voice time slots, 32 time slots for each service
group. There are also 32 channels in each LU service group.
The 64 LU channels are dedicated to the 64 PIDB time slots.
Each LU grid services 64 subscribers. When a grid in the Model
1 LU is removed from service, 64 subscribers are removed from
service. The grid in Model 2 and Model 3 LUs can be removed
from service at the half-grid level. When a Model 2 or Model 3
LU half grid is removed from service, 32 subscribers are removed
from service.
Any LU grid OOS condition is service affecting and should be
resolved as soon as possible. See AT&T 235-105-220, Corrective
Maintenance Procedures, for details on restoring OOS grids to
service.
The LU A-LINKs are wired paths between the first and second
stage switches in LU grids. If an A-LINK is OOS, a path is not
available through the concentrator grid network. An
accumulation of OOS A-LINKs can cause network blockage and can
be service affecting. To avoid subscriber complaints, OOS A-
LINKs should be restored to service as soon as possible. See
AT&T 235-105-220, Corrective Maintenance Procedures, for details
on restoring OOS A-LINKs to service.
The LU hardware is not duplicated. If an LU function is out of
service, that function is unavailable for call processing. If
operational test failures (OTFs) are occurring or REX grid
fabric exerciser failures are being reported, the affected LU is
being forced to complete calls with defective hardware. This
can be service affecting and a source of subscriber complaints.
A grid fabric exerciser fault in the grid of LU Model 1 or
halfgrid of LU Models 2 or 3 changes its MCC display state to
degraded (DGR).
In summary, restore OOS hardware to service as soon as possible.
Take action to resolve operational test failures and grid fabric
exercise faults. Refer to AT&T 235-105-220, Corrective
Maintenance Procedures, for assistance in resolving LU faults.
Any LU fault that cannot be resolved at the local level should
be supported by the next level of technical support.
The terminal maintenance subsystem is designed to detect faults
in lines, trunks, and associated equipment. Fault detection is
performed either automatically or manually by software
controlled tests. Testing is performed locally by utilizing the
TLWS capabilities. Remote testing can be implemented from
centralized test systems such as the following:
o Local Test Desk (LTD)
o Mechanized Loop Test (MLT)
o Remote maintenance center, for example, SCCS
o Centralized Automatic Reporting on Trunks (CAROT) System
o Centralized Trunk Test Unit (CTTU).
These remote test positions have powerful testing capabilities
to supplement the local TLWS.
Per-call testing by call processing software is a primary means
of line fault detection. A number of these tests are performed
on every call processed by the 5ESS switch. Per-call tests are
performed independently on both the originating and terminating
sides of the call. In addition, tests are done at one of three
phases of a normal call. These are as follows:
a. Origination: Origination is the interval between the
calling party off-hook detection and talking path
connection.
b. Termination: Termination is the interval from when the
called party line is determined to be idle to when one of
the following occurs:
o Calling customer goes on-hook
o A talking path connection is broken down.
c. Disconnect: Disconnect is the interval between customer
on-hook and line restoration to idle.
When a per-call test detects a failure, all data associated with
the call is sent to terminal maintenance for a test failure that
indicates a trouble on the line. Trouble indications within the
line unit are referred to switch maintenance. The problem is
then analyzed, and a decision is made on what course of action
is to be taken. This could result in any of several maintenance
actions such as diagnostic tests, changing equipment status
states, or a system alarm.
Routine tests are periodic maintenance checks run by the
terminal maintenance subsystem. These tests are used to assure
trunk and line integrity. Routine tests are run on circuits
that are assumed to be in good operating condition. These tests
can be initiated either automatically or manually.
Flexible scheduling of automatic trunk testing is possible
through automatic progression testing (APT). In APT, a test
history keeps track of information concerning the tests. This
allows interruptions of the testing cycle when the trunks are
needed for service. When traffic subsides, the testing resumes
where it left off. Test results are analyzed and displayed
locally and/or at a remote testing location.
Routine trunk tests can be classified as operational or
transmission tests. Operational testing of trunks encompasses
the following objectives:
o Verify the operational characteristics of interface and
carrier facilities and distant central office equipment.
o Verify the end-to-end ability to detect and send signaling
and supervision.
o Routinely exercise the interface circuits in a distant
central office.
A trunk error analysis (TERA) analyzes MDIIs that result from
trunk or universal tone decoder failures. The results (pass or
fail) of trunk operational tests are also routed to TERA. When
TERA determines that a trunk or universal tone decoder is
experiencing a high-error rate, recovery actions are initiated.
The recovery actions can consist of an output message, or, when
applicable, an operational test on an outgoing trunk. Refer to
AT&T 235-105-119, Maintenance Guide Utilizing OMS5, for details
of how to use TERA. For information about the activation of
TERA, refer to the appropriate RC manual (AT&T 235-118-XXX,
where XXX = manual number associated to the applicable software
release. See AT&T 235-000-000, Numerical Index -- Division 235
and Associated Documents, for specific manual numbers) that
contains the RC symbolic view name RC_TERA.
The 5ESS switch supports incoming test calls for operational
tests. The operational test for lines is the automatic line
insulation test (ALIT). The ALIT is an automatic test system
that scans lines and identifies faults before they affect normal
service.
Many tests and functions are provided to aid in trunk and line
testing. These include the standard test line (TL) and
functions used in previous switching systems.
The routine test facilities provided include the following:
o 100TL (Balance)
o 101TL (Communication)
o 102TL (Milliwatt)
o 103TL (Signal supervisory)
o 104TL (Transmission measuring and noise checking)
o 105TL (Automatic transmission test line)
o Synchronous test line
o Nonsynchronous test line
o Permanent-busy test line
o Touch-tone dialing test line
o Open circuit test line.
The per-call tests (lines only) are as follows:
a. Origination of calling party:
o False cross and ground test
o Power cross
o Continuity check.
b. Termination of called party:
o False cross and ground test
o Power cross
o 20-Hz ringing current
o Loop resistance to detect pretrip
o Continuity check.
c. Disconnect:
o Restore verify.
The Call Monitor provides an early detection mechanism for loss
of call processing functionality when all other system
indicators appear normal. The Call Monitor reports to the craft
by ROP and an alarm indicator on MISC Page 116 when a failure in
call completion analysis occurs. The ROP output is in the form
of a REPT CALLMON 5- or 15-minute report. The ROP output
message has either a major, minor, or no alarm.
The failure criteria is defined as follows:
o For the 5-minute report, failure occurs if more than 50
percent of the total calls attempted in a 5-minute period
are not passed.
o For the 15-minute report, failure occurs if more than 90
percent of the total calls attempted in a 15-minute period
are not passed.
The major alarm criteria is defined as follows:
o For the 5-minute report, a major alarm occurs if 40 percent
or more of the total tests are ``operational test
failures.''
o For the 15-minute report, a major alarm occurs if 50
percent or more of the total tests are ``operational test
failures.''
The minor alarm criteria is defined as follows:
o For both the 5- and 15-minute reports, a minor alarm occurs
if 70 percent or more of the total tests are
``indeterminate'' plus ``not attempted'' failures.
If no alarm criteria is met, no alarm will be printed with
either analysis report.
The Call Monitor will perform separate analyses for common
channel signaling (CCS) test calls (if equipped) along with
non-CCS test calls. It utilizes the Terminal Maintenance APT
functionality to make these operational test calls. Non-CCS
test calls are based on the default APT test for the trunk group
in the AM ODD. All CCS test calls use the Voice Path Assurance
(VPA) continuity test.
For 5E9(1) and later, ability to inhibit the Call Monitor on a
per-trunk-group basis is provided by a new field in the static
AM ODD relation RT_TRKG. The new field, ``callmon_inh'', is
populated from recent change trunk view 5.1 (as is the existing
field for inhibiting APT). If APT is inhibited, then the Call
Monitor must be inhibited.
The monitor routinely cycles through the AM ODD for trunk groups
and selects trunk groups to use for making the test calls. A
test call will be attempted every 30 seconds.
The monitor can be inhibited as well as requested to print the
past 15-minute history and print per-test call results (verbose
mode). The alarm indicator on MISC Page 116 can also be
retired.
Additional information on the Call Monitor is provided in
Sections .RM 3./ and .RM 4.2/ of this document and in AT&T 235-105-210,
Routine Operations and Maintenance Procedures.
Recent change (RC) is a system function that allows maintenance
personnel access to the 5ESS switch data base. Recent change is
used to add to or delete from the data base. Also, recent
change is used to update or verify the data base using a
select/mask format. The data base for the 5ESS switch supports
a relational data base with the following methods of access:
o Recent change/verify (RC/V)
o Office data administration (ODA)
o Office record programs (called views because they are
user-oriented)
o Remote memory administration system (RMAS).
For details concerning the recent change and verify subsystem,
refer to Section .RM 3.10/ of this manual.
Field update is the process of activating orderly program
changes in the 5ESS switch software. In-service offices receive
most official software changes in the form of software updates.
The software update originates as a program enhancement or as a
fix for a problem within the software release. Function, file,
and byte replacement are the three types of software updates
provided. The 5ESS switch software updates usually replace
entire sections of program software as compared to the word-by-
word changes of other Electronic Switching Systems.
Aiding in the updating of a 5ESS switch are three external
interfaces to the program update subsystem. These three
interfaces provide for the generation, distribution, and
activation of software updates. The interfaces are as follows:
o A Programmer Support System (PSS)
o A SCANS
o Remote maintenance center (for example, SCCS).
The PSS originates program updates via the generation and
initial distribution of software updates. After a software
update has been composed, tested, and approved at the PSS, it is
assigned a software update identification number and transmitted
to SCANS. In an emergency (such as SCANS outage), a software
update could be transmitted from the PSS over a data link
directly to the office if the situation requires immediate
action to maintain switching system integrity. Craft and/or
maintenance personnel at the remote SCC or 5ESS switch would
have to make a verbal request to the program update coordinator
at the PSS. The coordinator would set up the emergency data
link (from the PSS to the 5ESS switch) and manually transmit the
software update, after maintenance personnel primes the 5ESS
switch for reception of the software update files.
The SCANS is an AT&T time-shared computer system for
distributing software updates. It is usually accessed by
maintenance personnel at the remote SCC work station using the
No. 2 remote SCC computer to receive and record the software
updates. The SCANS can also be accessed by maintenance
personnel at the local office. The SCANS should be checked
prior to inserting or activating any software updates to ensure
that they have not been canceled or changed.
The remote SCC provides for remote activation of software
updates at a 5ESS switch. It uses a 1200-baud dial-up terminal
to access SCANS and activates the program update subsystem to
apply the software update. Communication between the remote SCC
and the program update subsystem is via the maintenance channel.
It is not necessary to have maintenance personnel present at the
local office to aid in the activation of the software update(s).
Although software updates are usually activated by the remote
switching control center, they may also be activated locally
through the MCC video terminal for one or more of the following
reasons:
a. The remote SCC option is not carried by the 5ESS switch
being accessed.
b. The remote SCC (if the option is carried) is down, and a
software update must be activated to maintain switching
integrity.
Note: Reasons (a) and (b) require that a 1200-baud
terminal be present at the 5ESS switch. The
terminal must be full duplex, be capable of
printing at least 80 characters per line, and
must have a 212A-type data set. This terminal
is used to access SCANS and poll the SCANS
data base for relevant software updates.
c. Local control of the software update activation is desired.
This carries the following two options:
1. The entire activation procedure (including access of
SCANS) is to be done locally.
2. The remote SCC accesses SCANS and turns control of the
activation over to local personnel at the MCC.
The software update activation responsibility between AT&T and a
switch owner (normally an OTC) is as follows:
a. During preturnover (new office), retrofit, and restart
intervals, the AT&T installer is responsible for obtaining
and activating all current software updates in the SCANS
data base which apply to that office.
b. At all other times, in a working office (when not in a
retrofit or restart mode), the switch owner or the remote
switching control center is responsible for obtaining and
implementing all applicable software updates.
Regular field updates are done in a timely and orderly fashion
through software updates. Unexpected problems with the software
release can occur that require immediate correction, not
allowing time for the normal software update development and
issue processes. Emergency fixes are accomplished on a word-
by-word basis under direction of the AT&T Customer Technical
Support (CTS) Organization.
Emergency fixes are assigned a sequential craft number similar
to the software update number. The program update subsystem
provides emergency fixes with the same status and options as
software updates (that is, make temporary, make permanent,
backout). Emergency fixes specify the address to be changed,
the new data to be inserted, and the old data to be matched.
Emergency fixes are also known as address-data couplets.
As with software updates, most emergency fixes are activated
remotely from the remote SCC. Communication between the remote
and local program update subsystem is via the maintenance
channel. It is not necessary to have maintenance personnel
present at the local office to aid in the activation of the fix.
Emergency fixes may also be activated locally through the MCC if
the following occurs:
a. The 5ESS switch does not carry the remote SCC option.
b. The remote SCC (if the option is carried) is down, and the
fix must be activated to maintain switching system
integrity.
c. Local control of the fix is desired.
Software release retrofit refers to the software and procedures
used to replace the resident software release text and data
bases [ECD, ODD, and System Generation (SG)] in an operational
5ESS switch with new software release text and evolved data
bases.
Software release update refers to the software and procedures
used to replace the resident software release text in an
operational 5ESS switch. Software release update allows for
replacement of text for installation of a software update
(formerly BWM) consolidation load or a software point load
release. Software release update does not include evolution and
replacement of the SG or ODD data bases. Although there is no
ECD evolution, the application of point load specific keystroke
files to the ECD is allowed.
Large terminal growth (LTG) refers to the software and
procedures used to add large quantities of lines and trunks to
an operational 5ESS switch by evolution and replacement of the
ODD data base. It does not include replacement of the software
release text, ECD, or SG data bases.
Software release retrofit, software release update, and LTG are
referred to collectively as software release transitions. New
software release text and data bases are delivered to the office
on magnetic tapes supplied by AT&T. Recent change activity
should be kept to a minimum or stopped, if possible, for 2 weeks
prior to a software release retrofit or LTG. Prior to all
transitions, a copy of the existing software release should be
saved on spare disk packs or magnetic tapes. In some cases,
associated hardware and/or read-only memory (ROM) circuit pack
changes may be required prior to starting the transition
process. When the transition process begins, however, all
essential duplex and simplex equipment must be operational.
Although stable 2-port circuit-switched calls are saved over a
software release transition initialization, a software release
transition should be planned for a low-traffic period to
minimize the number of calls that might be affected by call
processing interruptions. The types of calls not saved during a
software release transition initialization include calls
involving more than two ports, such as calls using conference
circuits. Transient calls (that is, originating, dialing,
ringing, calls on hold, calls being forwarded/transferred,
etc.), packet calls, and test calls are also not saved.
For detailed information concerning software release retrofit
procedures, refer to AT&T 235-105-24X (X = manual number
associated with applicable software release). For detailed
information concerning software release update procedures, refer
to AT&T 235-105-34X (X = manual number associated with
applicable software release). For detailed information
concerning LTG procedures, refer to AT&T 235-105-44X (X = manual
number associated with applicable software release). For
additional information, refer to AT&T 235-000-000, Numerical
Index - Division 235 and Associated Documents.
Note: The Design Change Management System (DCMS) data
base is not restricted to only covering the CNs for
the 5ESS switch. This data base provides CN
coverage for all of the AT&T Network Systems
products.
The DCMS data base is the official vehicle for notification of
product changes (that is, CNs) for all of the AT&T Network
System products. Also, this data base notifies the customer of
service enhancements that can be purchased. The DCMS data base
service is free to the customers.
The following information concerning CNs is provided to the
customer by DCMS:
1. DOCUMENTATION on the changes that are made to AT&T Network
Systems products. Documentation is in the form of a
product change notice (PCN). A PCN is issued for each
change. The PCN document consists of the following:
a. Product being changed
b. Reason for the change
c. Description of the change
d. Effect that the change will have on the customer's
operations during implementation
e. Affected product drawings and their titles
f. A comparison of the markings that the product will
bear before and after the change
g. Other miscellaneous information.
2. APPLICATION STATUS REPORTS that track and report on the
status of the implementation of these changes in the
offices that employ affected products. Application status
reports are compiled interactively. The reports illustrate
the current status of the offices that are affected by
product changes. The status reports can be obtained in a
standard format or can be customized on an ad hoc basis to
meet the DCMS user's specific needs.
3. HISTORICAL INFORMATION by CN, office, or product once the
implementation process has been completed. Historical
information is available on an ad hoc basis. The DCMS data
base covers CN office implementations made by an AT&T
installation group from 1983 to the present date.
The DCMS user's manual explains how to use the menu driven DCMS
data base. The manual is distributed by the National CN
Engineering Group located at the AT&T Southwestern Region. With
a proper ID number and login, customers can obtain an on-line
version of the manual. For additional information, call the
telephone number shown in the address for Southwestern Region as
follows:
AT&T Southwestern Region
Department NF93D6T00
1111 Woods Mill Road
Ballwin, Missouri 63011
(314) 891-2930
The DAP terminal can be used to perform all commands/functions
that are needed to maintain the switch. A maximum of 8 DAP
terminals for 5E6 or 16 for 5E7 and later can be accessed.
These terminals are defined in the data base. The master
control center (MCC), trunk and line work station (TLWS) (TLWS
is mode of MCC), supplementary TLWS [with the exception of being
able to access the emergency action interface (EAI) page
display] are DAP-type terminals.
Non-DAP terminals can be used to perform the same functions that
the DAP terminals perform with the exception of being able to
access the MCC page displays. When using a non-DAP terminal,
input messages (message function mode) must be entered to
maintain the switch. No input commands (for example, poke
commands) can be entered from a non-DAP terminal.
The MCC uses four function keys. When one of these keys (Figure
.AW G9/) is depressed, the system performs the corresponding function.
The keys are as follows:
o ALM RLS: Alarm release
o CMD/MSG: Input command or input message
o NORM DISP: Normal display
o EA DISP: Emergency action display [can only be performed
from the MCC or switching control center (SCC)].
When the system is in the manual retire mode, the ALM RLS
function key releases audible and visual alarm indications
(CRITICAL, MAJOR, or MINOR, and flashing indicators). Flashing
indicators go to steady reverse video when retired.
Note: The minor alarm audible is self-releasing after 5
seconds, but its visual indication must be released
manually.
The command/message (CMD/MSG) function key configures the MCC to
accept either input CMDs or input MSGs. The key acts as a
toggle and allows input in one mode or the other. The user may
switch between either mode after acknowledgment of the
previously entered message. Any unexecuted data in either area
is lost if a switch is made before an acknowledgment is
received. Unexecuted data in the input message area is normally
saved until an intercharacter time-out occurs. If a time-out
occurs before the message is completed, all data is lost. The
position of the cursor on the video display indicates which
input mode the MCC is in. The cursor resides in the input
message line area while in the MSG mode. If the MCC is in the
CMD mode, the cursor resides at the CMD entry area (at the top
left of the control and display area). Whenever the display is
brought on-line or a new page is selected, the input mode will
remain unchanged.
The NORM DISP function key places a page controlled from the
administrative module (AM) on the display. The page displayed
will be the previously displayed page. Depressing the NORM DISP
key again will redraw a clean display without aborting any
processes in progress.
The EA DISP function key enables emergency action mode and
displays the EAI page on the screen. This page is used during a
system emergency for system recovery functions. Depressing the
EA DISP function key again will abort all incompletely entered
actions and redraw the emergency action interface page display.
Note: The emergency action mode can only be enabled from
the MCC or SCC.
Most other keyboard keys are used in a normal fashion to enter
numeric codes, input messages, and alphanumeric responses to the
system. Their input is respective to the symbol designated on
the key. Certain keys are used for line administration as
explained in the remainder of this section.
The following procedure may be used to access an MCC page
display:
1. Select a normal system display page by depressing the NORM
DISP function key.
2. If the maintenance terminal is not in the command mode,
depress the CMD MSG function key.
Note: When in the command mode, the CMD:_ prompt is
displayed and the cursor is positioned in the
command input area in the upper left-hand
portion of the display.
3. Enter the desired MCC page number (for example, 100 - Page
Index display) that is to be displayed.
A capability is provided to specify in their equipment
configuration data base (ECD) getty forms the page that is to be
displayed automatically on each display device following a
terminal restore (for example, initialization, system boot, or
remove/restore). The process that initializes a page specified
in the ECD must be connected to a port. Therefore, not every
page in the system can be displayed automatically following a
terminal restore. The following list contains the page names
and port numbers of the system pages that may be specified in an
ECD getty form:
Pagename Portid
CPDP 17
INDEX 17
CDUP 17
For applications not desiring a specific display upon a terminal
restore, the common processor display page (CPDP) is the default
page for the maintenance terminals. If another system page is
requested and displayed, depressing the NORM DISP function key
causes the last page requested to be displayed again. The
following procedure can be used to specify the initial page for
a display device.
1. At the maintenance terminal, invoke RC/V by entering 199.
2. Fill in the necessary information to initiate an update of
the getty form for the desired display device. Procedures
for updating data base forms are explained in the ECD/SG
Data Base Manuals [for example, AT&T 235-600-306 for 5E6,
AT&T 235-600-307 for 5E7, AT&T 235-600-308 for 5E8, and
AT&T 235-600-309 for 5E9(1)].
3. When the getty form is displayed, enter the name of the
initial page desired in the pagename field and the port
number of the process that initializes the page in the
portid field.
4. After updating the getty form, remove and restore the
device for which the getty form was updated.
One of the following methods can be used to switch one or more
switchable devices [that is, the receive-only printer (ROP)
and/or maintenance terminal] to an alternate peripheral
controller:
a. Input message SW:PORTSW, refer to the AT&T 235-600-700 for
details.
Note: The port switch must be in the AUTO position.
b. Poke input command (401 - PORTSW, 402 - ROP, or 403 - MCRT)
illustrated on the 111/112 - AM, AM Peripherals page
display.
Note: The port switch must be in the AUTO position.
c. Flip the port switch associated with the switchable device
to either 0 or 1. (0 = peripheral controller 0, 1 =
peripheral controller 1).
Note: In either of these two positions, the port
switch cannot be reconfigured using the
previous two methods.
The MCC provides the ability to select a control and display
page at any time. The index display is brought into the control
and display area by entering 100 (into the CMD entry area) and
executing it. The 100 index page consists of a list of possible
MCC control and display pages. Those pages not shown are
requested by entry from other pages in a meaningful hierarchy
relationship. Then, the needed page can be selected by entering
the page identifier in the command area and executing it.
The 100 index page does not list the per-SM pages. The 1000
page is the index into the per-SM pages. Also, any one of the
SM-related display pages can be accessed from any page display.
For example, to reach the status display of SM 24, you would
enter 1010,24, 1190,24, 1800,24, or 141. It is possible to
enter a page identifier in the command (CMD) entry area if the
appropriate page identifiers are known. The page index display
can be used to determine the appropriate page identifier.
A display page can be selected by entering its unique 3-, 4-, or
6-digit identifier. All display page commands begin with the
number 1. For example, 100 is the INDEX display. Identifiers
105 through 116 are directly related to the SUMMARY STATUS AREA
indicators. The page number for the page can be derived from
the physical position of the indicator. For example, BLDG/PWR
is the fifth summary status indicator; its display page is 105.
The SM is the fourteenth indicator; its associated page is 114.
As was noted earlier, the system emergency page, corresponding
to the SYS EMER indicator, is to be displayed by depressing the
EA DISP function key. Page displays are not provided for
alarm-level indicators. Other pages are assigned the remaining
identifiers grouped on a functional basis, where possible.
Whenever the MCC terminal is brought on-line from an off-line
state, the terminal will display the identification line, the
status summary indicators, the emergency action page, and the
input message entry area. The time-of-day indicator should be
checked immediately to determine display validity.
Options are provided on the maintenance terminal to turn the
terminal features on or off. To set these options, see the
user's guide for the specific type of terminal being used. Set
the options (if available) as listed in Figure .AW G10/.
Options are provided on the ROP to turn the terminal features on
or off. To set these options, see the user's guide for the
specific type of terminal being used. Set the options (if
available) as listed in Figure .AW G11/:
Note: Systems equipped with the TELETYPE(R) 5310
teleprinter and related equipment have the
capability of suspending output to the ROP
temporarily. Pressing the BREAK key on the printer
will suspend output for 2 minutes or until the
BREAK key is pressed again, whichever occurs first.
The HERE IS key will do the same.
Maintenance commands provided on the MCC displays are entered
via numeric codes. The desired code(s) is found in the control
and display page menu listing of possible input commands. Any
command to be entered must be selected from a list currently
displayed or be a page selection command. The input sequence is
as follows:
1. Make sure the MCC is in CMD input mode.
2. Find code of desired command on the display.
3. Enter correct numeric code using the semicolon (;) to
execute input commands or messages.
4. Execute by depressing either of the following:
a. ; (semicolon)
b. ENTER key
c. RETURN key.
The system acknowledges the input request. Section .RM 3.12/, H0W TO
USE INPUT/OUTPUT MESSAGES, explains system responses to input
messages.
The primary function of the EAI is to provide manual recovery
capabilities during periods of system emergency. This interface
enables configuring a working system when normal recovery
procedures prove inadequate. The emergency page has a menu of
control and initialization functions that can be forced on the
system. Each function is defined and input by a 2-digit command
code. The codes are shown with their associated functions on
the display. These functions can be used to do the following:
o Recover from duplex-processor failures
o Disable the sanity timer
o Disable hardware checks
o Boot the system from other devices.
The conventions used for displaying data and selecting functions
are similar to those used by other control and display pages.
Due to the crucial functions provided, maintenance personnel
must be familiar with these commands and their use.
Note: There is a sequence of EAI commands that can reduce
downtime during periods of system emergency. This
command sequence, the 42!9!54 and 42!9!50 pokes,
will execute a full office initialization (FOI)
with full pump of the SMs and CMPs (5E6 and later)
in two parts. The 42!9!54 poke must be entered
first and will cause a full initialization of the
AM, including CNI Ring (if equipped) and CMPs.
When the AM has completed the initialization
process, the 42!9!50 poke must be entered next
within 30 minutes of the entry of the 42!9!54. The
42!9!50 poke will perform a full initialization
with full pump of all SMs sequentially by SM type.
If the 42!9!50 poke is entered before the 42!9!54
or after the 30-minute window, the initialization
of the SMs will not occur. Refer to AT&T 235-105-
250, System Recovery, for detailed procedures on
the use of this poke sequence and for information
and procedures on other FOI variations.
An in-progress FOI can be cancelled by executing
pokes 42!q!50 or 42!Q!50. The execution of these
pokes will result in the cancellation of the SMs
marked for full initialization with or without
pump. The pending initialization of one or more
SMs can be cancelled by input command
INIT:SM=a[&&b],NOINIT;. See AT&T 235-600-700,
Input Messages Manual, for additional information
on this command.
The EAI circuit pack in the AM must be a TN983. The TN983
circuit pack is located in equipment location (EQL) 102 in the
input/output processor (IOP) Basic Unit Shelf located in the
processor control cabinet (PCC). The TN983 provides the
capability to store the last application parameter used for a
recovery action.
Note: If a TN83B circuit pack (used in 5E3 and earlier)
is currently equipped in EQL 102, provisions must
be made to replace this circuit pack with the
TN983.
The EA DISP function key on the MCC keyboard is used to display
the emergency action page. When the EA DISP function key is
depressed, it will bring the emergency action page into the
control and display area of MCC. This page is available for
selection at all times.
Note: When the system emergency action page is present on
the MCC, the only way to remove it is to depress
the NORM DISP function key on the MCC keyboard.
Depressing the EA DISP function key again will clear unexecuted
input actions and redraw the emergency action display page.
After requesting the emergency action display page, the video
terminal digit indicator must be checked to ensure a valid
display. The video terminal indicator is located in the upper
center portion of the display (Figure .AW G12/). The video terminal
digit indicator consists of the maintenance teletypewriter
(MTTY) or maintenance cathode ray tube/terminal (MCRT) followed
by a numeric digit displayed in dynamic text. The digit is
incremented every 2 seconds by the peripheral controller (PC).
If this indicator is not displayed and is not incrementing, the
entire display is invalid. Once the validity of the display is
determined, other indicators are used to qualify EAI and
emergency functions. Table .AW TH/ summarizes these indicators.
Note: The rest of the indicators on the display are valid
only for EAIs indicating all seems well (ASW).
The EAI indicators reflect the progress of the emergency action.
The emergency action is progressing successfully if the ASW
indication is present (Figure .AW G12/).
The control unit (CU) status area is located at the upper left
portion of the EAI page display (Figure .AW G12/). This area informs
the maintenance personnel which of the CUs is active and which
is on- or off-line. The term CU refers to the control unit or
the processor of the AM.
At the upper right portion of the EAI page display is the
processor recovery message (PRM) area (Figure .AW G12/). The PRMs
display the systems coded failure/success recovery information.
The PRMs change continuously during an initialization,
reflecting the current state.
Emergency functions are entered by typing the appropriate 2-
digit command code and executing it. Table .AW TI/ provides a list of
the EAI commands with a description of their actions. For more
details of how to use these functions, refer to AT&T 235-105-
250, System Recovery. The carriage return is used to execute
emergency functions.
The menu commands can be grouped into the following three
categories:
o Commands 10 through 15: These commands have a direct and
immediate effect on the system. Some commands force the AM
into a particular configuration and some release a forced
configuration.
o Commands 20 through 43: These commands are preparation
commands that specify certain conditions prior to a system
initialization. These conditions do not take effect until
an initialization command is given.
o Commands 50 through 56: These are the initialization
commands. These commands cause the conditions that were
specified previously with commands 20 through 43 to take
effect.
The severity of the initialization increases with the
command number (command 54 has the greatest impact). The
system can automatically trigger commands 50 through 53
during an initialization.
Command 54 can only be triggered manually and causes an AM
and a possible CM initialization. This takes these
processors completely off-line, and call processing is
disabled for a short period of time.
Commands 55 and 56 are normally required during the initial
installation interval or when an initialization from tape
is required due to a massive corruption of disk data.
During this tape load, the system is off-line and call
processing is disabled for a considerable period of time.
The 51 through 56 commands when entered on the command line
cause the system to immediately enter an emergency action
mode.
Once the emergency action has completed, the system is
restored (automatically) to a stable state and call
processing resumes. The EAI page display disappears and
the MCC Page Display 111/112, AM Peripherals, is
automatically displayed.
Commands from the EAI page display should only be used
under the direction of your technical assistance group.
Improper use of the commands on the EAI page can have a
very negative impact on the integrity of the system.
Each command executed is acknowledged either OK or NG. This
acknowledgment appears adjacent to the command entry area in the
top left line of the display. After entering a command, the
input and response are displayed until the next character is
typed. Errors may be erased a character at a time by pressing
the backspace key or by pressing CTRL h.
The STLWS terminal is a DAP-type terminal which means
maintenance personnel can perform the same functions or commands
from the STLWS that can be performed from the MCC (with the
exception of being able to access the EAI page display). Refer
to Section .RM 3.1.1/ for additional information on DAP.
The trunk and line work station (TLWS) is an interactive menu
interface used to test, monitor, or measure trunks and lines.
The TLWS is a mode of the MCC or STLWS and has either eight (5E8
and earlier) or 32 [5E9(1) and later] software controlled test
positions. The test positions are used to access other menu
pages which are used to perform the actual testing. The other
menu pages display information needed to perform TLWS
operations. One TLWS terminal can utilize all test positions.
The status of test positions may be checked from the Test
Position Summary page (5E8 and earlier) or Test Position Summary
Screen pages [5E9(1) and later] to determine which test
positions are in use and which ones are available. The basic
equipment used for trunk/line testing includes the following:
o A video display terminal
o A key telephone set with a speaker
o A test access unit
o A ROP.
Following are some of the operations that may be performed using
the TLWS:
o Controlling lines and trunks being tested
o Monitoring a short circuit
o Measuring/sending frequencies
o Making continuous metallic measurements
o Providing remove or restore commands used for testing.
The basic input sequence for starting a test procedure in the
menu mode is as follows:
o Make sure the STLWS is in CMD input mode.
o Find command of desired test in the task selection display
area.
o Enter correct numeric code plus additional information (if
required).
o Execute by depressing the return key.
The TLWS is used to test lines and trunks, make measurements,
and monitor calls. This testing can be done in either the menu
mode or the command mode. There are five basic steps in trunk
and line testing. They are as follows:
o Seize/access a test position
o Seize line or trunk
o Perform one or more tests
o Release line or trunk
o Release test position.
Note: Only individual trunks can be seized and tested.
Wideband test calls are not supported.
The TLWS software feature provides access to a menu-type
interactive test system and (in 5E9(1) and later) MML input
commands which allow a user to select a trunk or line for
testing and to choose the type of test to be performed on the
item selected. These functions, as well as that of performing
the actual tests, are conducted at test positions. For 5E8 and
earlier software releases, eight test positions (numbered 1
through 8) are available for test purposes. For 5E9(1) and
later, 32 test positions (numbered 1 through 32) are available.
Associated with each test position are the resources commonly
used to test 5ESS(R) switch terminations. The test position
resources are separated into two groups as follows:
o Directly associated resources: These resources are
directly associated with the test position throughout its
use and are those that are commonly used in testing.
Directly associated resources include the talk and monitor
(T&M) phone, 101 test line callback access, and the
alternating current (AC) and direct current (DC) jack
terminations.
o As needed resources: These resources are associated with
the test position on an as-needed basis during testing.
This group includes the directly connected test unit
(DCTU), the transmission test facility (TTF), and the
integrated services test facility (ISTF).
For 5E8 and earlier software releases, the set of resources
associated with a test position is determined by the device ID
(devid) of the computer terminal being used to perform the
testing. The association is performed by matching the
terminal's device ID to the device ID key of the RLtlwsr tuple
in the ODD.
In 5E9(1) and later software releases, the capability is
provided to allow the user to choose the set of resources to be
directly associated with the test position for the duration of
testing.
The arrangement implemented by this capability creates a pool of
usable resource sets (RLtlwsr relations) from which the user
chooses one of the sets and assigns it to the test position.
The assignment is made when the test position is seized by
either command SET:WSPOS[,TP=X][,ID=Y]; or poke 161,X[,Y] and
the RLtlwsr tuple ID is entered (by default or manually) as the
value for Y. (In both commands, X = TP number and Y = the
RLtlwsr tuple ID.) The set of resources chosen is associated
with that particular test position until the position is
released.
For 5E8 and earlier, the status of all 8 test positions is shown
on Page 160, Test Position Summary, a single page. Effective
with the 5E9(1) software release, Page 160 is revised and
renamed Test Position Status Summary. The revised Page 160
lists the 32 test positions for 5E9(1) along with the ID for
each. Also included on revised Page 160 is command 160,Z (where
Z = screen number) that is used to display the four Test
Position Summary Screen pages (Pages 160,1, 160,2, 160,3, and
160,4). The Summary Screen pages show status information for
the 32 test positions. Each page shows status for eight test
positions: Page 160,1 for test positions 1-8, Page 160,2 for
test positions 9-16, Page 160,3 for test positions 17-24, and
160,4 for test positions 25-32.
To display Page 160, Test Position Summary (5E8 and earlier) or
Test Position Status Summary [5E9(1) and later], enter command
160. For 5E9(1) and later, enter command 160,Z from Page 160 to
display the desired Test Position Summary Screen page.
Examples of Page 160 for 5E8 and earlier and Page 160,2 for
5E9(1) and later are shown in Figures .AW G13/ and .AW G15/, respectively.
Once a test position is seized, the line or trunk data for that
test position will be displayed in the status box of the Test
Position Summary page or appropriate Test Position Summary
Screen page. The status box contains the following information
for each test position:
o Test position number
o TLWS location
o Identification field (TLWS number)
o Line/trunk data (DN/TKGMN)
o Test type (or test access)
o T&M phone status.
The absence of data in the status box for a particular test
position indicates that the test position has not been seized
and is available for use.
When a command is entered at the keyboard, it will be displayed
to the right of the CMD: symbol located in the upper left
portion of the screen on Page 160 and the other TLWS pages.
Figure .AW G13/ is an example of Page 160 for 5E8 and earlier which
shows the status box and the eight test positions. The absence
of status information indicates that all test positions are
available for use.
Figure .AW G14/ is an example of Page 160 for 5E9(1) and later which
shows the 32 test positions and associated Test Position Summary
Screens. In this example, ID information appears for test
positions 5 and 17 indicating that these positions are not
available.
Also shown are the commands to select and release a test
position and the command to display a specific Test Position
Summary Screen page.
Figure .AW G15/ is an example of Test Position Summary Screen 160,2
for 5E9(1) and later which shows the status box for test
positions 9 through 16. The absence of status information
indicates that these test positions are available for use.
Any test position shown as available on Pages 160 or 160,Z may
be seized by a user. In 5E8 and earlier, the command used to
seize a test position is 16X (where X = TP number). In 5E9(1)
and later, MML input command SET:WSPOS[,TP=X][,ID=Y]; or poke
161,X[,Y] (where X = TP number and Y = the RLtlwsr tuple ID) may
be used. If all test positions are in use, it will be necessary
to try again later.
All the test positions can be used at the same time.
Note: When a test position is requested and the value for
option Y is not specified, a default value for that
terminal is entered. If the default is null, an
error message is output. The user must then
request the test position with the RLtlwsr tuple ID
(Y value) specified, or the test position will not
be seized.
When a test position is seized in 5E8 and earlier software
releases, task selection Page 4000,X, SEIZE LINE/TRUNK/INCOMING
CALL, is automatically displayed. In 5E9(1) and later, Page
8000, TASK SELECTION, is displayed from which a user selects
Page 4000,X.
At this point, the next action is to seize a line or trunk.
Page 4000,X lists the different types of seizure commands for
both lines and trunks. In 5E8 and earlier software releases,
these commands are located in the lower left area of the page in
the task command area. In 5E9(1) and later, the task command
area occupies the entire left side of the page. Test results
are then displayed in the response area of the TLWS page Figures
.AW G16/ and .AW G17/ show examples of the command and response areas. (See
Table .AW TJ/ for the page numbers that are associated with the
particular software release used in the switch.)
In 5E8 and earlier, the major categories of tests that can be
performed using the TLWS are displayed on each individual task
selection (menu) page. In 5E9(1) and later, the major test
categories are shown on Page 8000, Task Selection, a new page
for 5E9(1).
The individual menu pages list the possible tests that may be
performed along with the command to execute that test. The task
selection/menu pages all have the same basic format (see Figures
.AW G16/ and .AW G17/). The section of the task selection/menu page that
contains the commands used to perform tests is different for
trunks and lines. Table .AW TJ/ contains a list of all available task
selection/menu pages.
Note: Task selections 9200 on Page 9000 (5E8 and earlier)
and 9200 and 9201 on Page 9000,1 [5E9(1) and later]
support testing of digital subscriber lines and
customer premises equipment (CPE) for the
integrated services digital network (ISDN).
Figure .AW G16/ shows the TLWS page layout for 5E8 and earlier
software releases and identifies the areas where certain
information appears. The major test categories appear on this
version of the page. (The specific tests and their commands
have been omitted for simplification.)
Figure .AW G17/ shows the TLWS page layout for 5E9(1) and later and
identifies the areas where certain information appears. The
major test categories do not appear on the 5E9(1) version. (The
specific tests and their commands have been omitted for
simplification.)
After seizing a line or trunk and displaying a task
selection/menu page, the user can choose the type of test to
execute. The status/response messages of the task selection
pages will be updated as the test is executed. When the test
has finished running a message, the results of the test will be
displayed in the response area block. If any problems have been
encountered during the test, a related error message will be
displayed on the error message line.
This test is to monitor a trunk using the menu mode. The
following is a step-by-step example of how to monitor a trunk.
1. While in the menu mode of the MCC or STLWS, enter menu
command 160 to access the TLWS test system.
Response: In 5E8 and earlier, the Test Position Summary
page is displayed showing available test
positions and the status of other test
positions. In 5E9(1) and later, the Test
Position Status Summary page is displayed. This
page lists the 32 test positions and provides
the 160,Z command that can be used to display
availability and status information for the test
positions.
Where: Z = Screen number (160,1, 160,2,
160,3, or 160,4)
2. Enter menu command 16X (5E8 and earlier) or 161,X[,Y]
[5E9(1) and later] to seize a test position.
Where: X = Test position number.
Note: The 4000 series commands are automatically
displayed after seizing a test position.
3. To display the list of commands for transmission-type test,
enter menu command 5000; or to skip task selection Page
5000, enter menu command 4301 and connect the talk and
monitor phone to the seized trunk.
Response: MONITOR is backlighted in the response block of
Page 5000, and T&M telephone set rings.
4. Take T&M phone off-hook and listen for conversation, off-
hook, or some type of suspected trouble.
5. Take appropriate action per local practice.
6. If no further testing will be performed on the trunk, enter
menu command 4999 to release the seized trunk.
7. When all TLWS testing is completed, for 5E8 and earlier,
enter menu command 20X on MCC Page 160 to release the test
position. For 5E9(1) and later, enter menu command 201,X
on MCC Pages 160 or 160,Z to release the test position.
Where: X = Test position number and Z = screen number.
8. STOP. You have completed this test.
If there is a problem that keeps the test from completing
correctly, an error message will be displayed on the screen in
one of the special fields provided for error messages. There
are also messages which explain what kept the test from running
correctly. The message will usually be printed on the error
message line which is above the status block. Information
related to an error may also be displayed in the response area
or on the command/action line. The command/action line displays
the command being executed, the test position number, and the
action that is taking place. The command is displayed in a
command mode format.
For a complete description of each error message, see the TLWS
Appendix or TLWS Progress and Error Reports Appendix in AT&T
235-600-750, Output Messages Manual.
After the test is finished and no more tests are to be done on
the seized line or trunk, it should be released. To release the
line or trunk, enter 4999. The line or trunk may also be
released by releasing the test position. There is a default
time limit on the release of a line or trunk. If there are no
actions on a seized line or trunk for 5 minutes, it will
automatically be released.
The last thing to do when a test session is over is to release
the test position(s) used. In 5E8 and earlier software
releases, a test position can only be released from Page 160.
In 5E9(1) and later software releases, a test position can be
released from Page 160 or from any of the four Page 160,Z pages.
To release a test position, return to Page 160 or Page 160,Z by
entering 160 or 160,Z, as appropriate. In 5E8 and earlier,
release the test position by entering 20X. In 5E9(1) and later,
release the test position by entering 201,X.
Where: X = Test position number to be released and Z =
screen number.
At this point, the test session is over.
Note: When a test position is left idle for 1 hour, the
test position is automatically released.
There are two types of trunk tests: interactive and
noninteractive. The noninteractive test always does the same
thing, and the maintenance personnel has no control over the
test. The interactive trunk test requires manual action from the
maintenance personnel to control the test. Usually, the
maintenance personnel on each end of the trunk run a series of
interactive tests to resolve the problem(s).
Note: Trunk tests are performed on a single-trunk basis.
Wideband test calls are not supported.
Transmission Test Calls
Test equipment is required at both the incoming and outgoing
ends for implementing transmission test calls. The actual
measured results are compared against the normal required
characteristics for a particular type trunk being tested.
The following transmission test calls are provided on the
system:
o 100
o 101
o 102
o 104
o 105.
Operational Test Calls
Operational test calls provide a pass/fail indication rather
than a measured value. All the tests except Code Answer Test
Line (CATL) only need test equipment at the outgoing side of the
test call. A predefined sequence of signaling events and tones
are used to test the trunk at the outgoing side of the test.
The following operational test calls are provided on the system:
o Permanent-busy
o Synchronous
o Nonsynchronous
o 103-type test line
o CATL-AAD2 or ATEMA.
Loopback Test Calls
The Digital Service Unit-2 (DSU2) Integrated Services Test
Function (ISTF) peripheral provides a digital-circuit transmit
and loopback capability to test digital trunks. The transmit
service sends an outgoing test signal and, through the use of a
digital loopback, receives back test data. The loopback service
takes bits (test signal) from the input channel and places them
on the output channel either directly [noninverting (LBK)] or
with their polarity changed [inverting (LBKINV)].
Effective with a software update in the 5E8 software release
time frame, the time slot interchanger (TSI) in 5E6 and later
offices also can be used for LBK. The ISTF is still used for
LBKINV.
Note: The LBK test line for ISDN trunking meets the
functional requirements announced in the ANSI(R)
standard T1.206-1988 (Digital Exchanges and PBXs -
Digital Circuit Loopback Test Line). The ANSI
standard designates the test line as a 108-type test
line.
The 5ESS switch 108-type test line deviates in one
minor detail from the ANSI standard in that time-
out is currently fixed at 1 hour (in the event the
caller fails to disconnect), whereas the ANSI
specification calls for a time-out period that can
be set by the operating company.
Procedures for implementing the 108-type test line capabilities
of ISTF are documented in AT&T 235-105-210, Routine Operations
and Maintenance Procedures.
The following loopback test calls are provided on the system:
o LBK/108-type test line
o LBKINV.
Following are descriptions of the transmission test calls:
o 100 - Balance: The incoming side sends a 1004-Hz tone at 0
dBm for 5.5 seconds followed by a quiet termination. The
outgoing side does a 1-way loss and noise measurement of
the trunk with the tone.
o 101 - Communication: The outgoing side calls the number of
the T&M phone in another office. At the incoming side, the
T&M phone will ring and be connected to the trunk under
test. Testing can then be completed.
Note: The T&M is not supported for wideband calls.
o 102 - Milliwatt: The incoming side sends a 1004-Hz tone at
0 dBm and the outgoing side does a 1-way loss measurement
test.
o 104 - Transmission Measuring and Noise Checking: Provides
a test termination for 2-way loss and 2-way noise. The
outgoing side sends a 1004-Hz tone, and the incoming side
measures the loss and noise. Then the incoming side sends
a 1004-Hz tone, and the outgoing side measures the loss and
noise.
o 105 - Automatic Transmission Measuring Test Line: Provides
far-end access to a responder and permits 2-way loss and
noise measurements to be made on trunks from a near-end
office equipped with a Remote Office Test Line (ROTL) and
responder.
Following are descriptions of the operational test calls:
o Permanent-Busy: The incoming side sends a busy signal.
o Synchronous: The outgoing side sends at least one complete
cycle but less than three cycles of audible ringing
followed by a silent interval. The incoming side sends
OFF-HOOK/ON-HOOK transitions.
o Nonsynchronous: This test is similar to the synchronous
test but runs faster because it is a less exhaustive test.
o 103-type Test Line: This test provides a connection to a
supervisory and signaling test circuit for overall testing
of these features on intertoll trunks (equipped with ring
forward features) which can be reached by an automatic
trunk test frame or by dialing manually.
o CATL - AAD2 or ATEMA: The incoming side returns 0 to 3
complete cycles of audible ringing and a tone while the
outgoing side detects the tone.
Following are descriptions of LBK/108-type test line and LBKINV
test calls:
o LBK/108-type test line: The LBK test line provides a
dialable, 4-wire test line capability that accepts binary
signals (bits) and loops back received octets (eight bits)
from a digital circuit to test digital carrier voice and
data trunk facilities.
o LBKINV: The operation of the LBKINV test line is the same
as that of the LBK except that the polarity of each bit is
changed in the loopback service. For example, an input bit
that is a ``1'' is placed on the output channel as a ``0''.
Note: Loopback tests are supported on a single-trunk
basis. Wideband test calls are not supported.
The following manual trunk testing features are available at the
TLWS:
o Seize/release a trunk
o Test trunk using T&M phone
o Send OFF-HOOK/ON-HOOK
o Manually set up call
o Monitor a busy port
o Connect trunk to a AC/DC jack
o Connect trunk to transmission test facility (TTF)
o Remove trunks
Caution: If a digital facility interface (DFI) is
unconditionally removed, the unit will be
taken out of service (OOS) along with all
of the voice/signaling trunks associated
with that DFI.
o Restore trunks
Caution: If a DFI is OOS and a restoral command for
a trunk (associated with that DFI) is
issued before the DFI restoral command,
audits will show inconsistencies between
the hardware status of the DFI and the port
status of the trunk.
o Get status of trunks
o Seize incoming call (101 test)
o Perform transmission test
o Perform operational test
o Perform loopback/108-type test line tests.
The automatic progression testing (APT) runs operational tests
and code answer test line (CATL) tests on trunks on a specified
schedule. The APT tests can determine only if the test passed
or failed, not the actual measured characteristics of the trunk.
If a trunk fails a test, the test will be repeated; and if it
fails again, it will be placed OOS. However, if an excessive
number of trunks are OOS, the trunk will remain in service.
Note: The APT is disabled in a 5ESS(R) switch for
AUTOPLEX(R) System 1000.
The APT has the following ten parameters which may be
programmed:
o The starting time in hours
o The starting time in minutes
o The length of time for test to run
o Each of the 7 days of the week.
The automatic trunk test scheduler (ATTS) is used primarily for
automatic trunk testing in a 5ESS switch for AUTOPLEX System
1000. (The ATTS is a secured feature that can be purchased
independently for use in regular 5ESS switch applications.) The
ATTS feature provides the ability to schedule routine testing on
a periodic basis and is capable of supporting multiple,
independent schedules of test sessions. Features of the ATTS
include the following:
o Programmable scheduling of tests including ability to add,
modify, and delete test sessions
o Automatic logging of test results
o Optional real-time printing of test results
o Report generation
o Flexible test session control such as skipping, linking,
etc.
Refer to AT&T 235-105-210, Routine Operations and Maintenance
Procedures, for additional information on ATTS and procedures
for its use.
Maintenance personnel may also be allowed to enter
administrative functions using input messages. Emergency
situations may make it necessary for a trunk or group of trunks
to be removed from service. A trunk may also be manually placed
back in service under certain conditions regardless of its
status.
Conditional and unconditional removals on trunks involved in
wideband calls operate the same as for trunks involved in DS0
calls.
The following administrative functions are provided by the TLWS:
o Removing trunks from service
o Restoring trunks to service
o Unconditionally replacing failed trunks to service
o Requesting trunk status.
The testing, operations, provisioning, and administration system
(TOPAS) is an operation support system developed to provide
centralized trunk maintenance and administration for trunks
terminating on 5ESS switch -- ``toll configurations'' in the
AT&T Communications network. The TOPAS and 5ESS switch
capabilities are as follows:
o Preservice testing, trouble isolation, and repair
verification via remote measurement system - digital 3
(RMS-D3).
o Current status of all trunks on the 5ESS switch through
trunk state change reports from the 5ESS switch and
periodic audits.
o Direct facility failure reports from the 5ESS switch to
facility administrative surveillance system (FAST).
Basically, this feature provides the craft at TOPAS with a set
of TTY input and output messages that enables communication with
the 5ESS switch to perform trunk maintenance.
These operational trunk tests can be initiated as follows:
o Manually via the input messages TST:TRK or TST:WSAUTO and
the TLWS poke commands on menu page 5400,2.
The TST:TRK input message can be used to request automatic
operational or transmission tests on individual trunks, a
range of trunks in a trunk group, or an entire trunk group.
Refer to AT&T 235-600-700, Input Messages Manual, for
details. If the test type and directory number are omitted
from the TST:TRK message, the default values (obtained in
the Automatic Trunk Test Table) are used to implement the
test.
The TST:WSAUTO input message can be used to perform TLWS
automatic tests through the menu interface. The trunk
being tested must have been seized via the CONN:WSLINE,
CONN:WSTRK, or CONN:WSIC input message. The specified test
position must have previously been selected with the
SET:WSPOS input message. Refer to AT&T 235-600-700, Input
Messages Manual, for details of these messages.
o Automatically via the trunk error analysis (TERA) or
automatic progression test (APT) capabilities.
When TERA or APT initiates a trunk test, the default test
type and trunk group number are obtained from the Automatic
Trunk Test Table. The Automatic Trunk Test Table contains
the default test type and trunk group number for each trunk
group.
For details of this feature, refer to AT&T 235-190-115, Local
and Toll System Features.
The RMS-D3 is a microprocessor based system providing message
trunk testing and maintenance of digital and analog switched
circuits. The testing of switched circuits via RMS-D3 is
controlled by TOPAS. The 5ESS switch hardware interface to
RMS-D3 consists of a control link (X.25 level 3) and a T1
interface. The commands from RMS-D3 as well as responses
transmitted by the 5ESS switch utilize the control link. The T1
interface provides access to the RMS-D3 test ports. The 5ESS
switch provides the following capabilities for RMS-D3:
o Route 104, 105, 109, and 606 calls to RMS-D3 ports.
o Route 101 test position calls from RMS-D3 ports and reroute
them to the TLWS if these ports are busy.
o Ability to originate test calls from RMS-D3 -- test call
with outpulsing or without outpulsing, signaling test
access with outpulsing or without outpulsing, monitor
connection, split talk access, and out-tandem connection.
o Mapping of trunk groups and test position numbers, RMS-D3
test access trunks and test position numbers, TOPAS test
position number and status (attended/unattended).
o Ability to reconfigure RMS-D3 test access trunks to meet
testing needs during any given time.
For details of this feature, refer to AT&T 235-190-115, Local
and Toll System Features.
The Call Monitor allows for the early detection of loss of call
processing when all other system indicators appear normal. It
requires a global digital service unit (GDSU) equipped with TTF
responder circuits. The Call Monitor also requires ISTF
hardware for performing digital loopback test calls. The Call
Monitor reports to the craft by ROP and an alarm indicator on
MISC Page 116 when a failure in call completion analysis occurs.
The ROP output is in the form of a REPT CALLMON 5- or 15-minute
report. The ROP output message has either a major, minor, or no
alarm.
The failure criteria are defined as follows:
o For the 5-minute report, failure occurs if more than 50
percent of the total calls attempted in a 5-minute period
are not passed.
o For the 15-minute report, failure occurs if more than 90
percent of the total calls attempted in a 15-minute period
are not passed.
The major alarm criteria are defined as follows:
o For the 5-minute report, a major alarm occurs if 40 percent
or more of the total tests are ``operational test
failures.''
o For the 15-minute report, a major alarm occurs if 50
percent or more of the total tests are ``operational test
failures.''
The minor alarm criteria are defined as follows:
o For both the 5- and 15-minute reports, a minor alarm occurs
if 70 percent or more of the total tests are
``indeterminate'' plus ``not attempted'' failures.
If no alarm criteria are met, no alarm is printed with either
analysis report.
The body of the REPT CALLMON message is as follows:
**********************************************************************
REPT CALLMON CURRENT [5 or 15] MINUTE REPORT
CALLMON PRINTMODE = [NORMAL or VERBOSE]
CALLMON STATE = ALLOWED
NON-CCS TEST CALL COMPLETION SUMMARY
PASSED FAILED INDETERMINATE NOT-ATTEMPTED LAST-TRKG-PASSED
a b c d e
CCS TEST CALL COMPLETION SUMMARY
PASSED FAILED INDETERMINATE NOT-ATTEMPTED LAST-TRKG-PASSED
f g h i j
TOP FIVE HIGHRUNNER FAILURE TYPES
FAILURE-CODE NUMBER-OF-OCCURRENCES
H'k l
H'm n
H'o p
H'q r
H's t
**********************************************************************
where the lowercase letters are decimal numbers (except for
failure codes which are in hexadecimal).
The range of valid trunk group decimal numbers in the data base
is 0 - 2001. The monitor uses the decimal value 2002 (values e
and j in the previous message example) to indicate that no trunk
group has passed a test call since the last time the monitor was
initialized.
The Call Monitor performs separate analyses for common channel
signaling (CCS) test calls (if equipped) along with non-CCS test
calls. It utilizes the terminal maintenance (TM) APT
functionality to make these operational test calls. Non-CCS
test calls are based on the default APT test for the trunk group
in the AM ODD relations RT_TRKG and TM_ATTT. All CCS test calls
use the voice path assurance (VPA) continuity test.
For 5E9(1) and later, ability to inhibit the Call Monitor on a
per-trunk-group basis is provided by a new field in the static
AM ODD relation RT_TRKG. The new field, ``callmon_inh'', is
populated from recent change trunk view 5.1 (as is the existing
field for inhibiting APT). If APT is inhibited, then the Call
Monitor must be inhibited.
Note: APT is disabled in a 5ESS(R)-2000 switch for
AUTOPLEX System 1000.
The monitor routinely cycles through the AM ODD relation RT_TRKG
and selects trunk groups to use for making the test calls. A
test call is attempted every 30 seconds unless CCS is equipped,
in which case two test calls (non-CCS and CCS) are attempted.
It is recommended that telephone company personnel set up their
APT schedule to allow testing on at least one trunk group from
each possible SM. This maximizes the benefit from this feature.
The monitor keeps an ever changing list of possible trunk groups
to select from in case it does not find a testable trunk group
at the 30-second entry as it continues to step through the ODD.
This guarantees that the monitor always has a trunk to test.
The monitor can be inhibited or requested to print the past 15-
minute history and the per-test call results (verbose mode).
The CALL MONITOR indicator on MISC Page 116 shows whether the
Call Monitor is inhibited or allowed. Entering command 601 from
this page generates the message INH:CALLMON which inhibits the
call monitor from making test calls and performing call
completion analyses. This also clears the monitor's history
data. Command 701 generates the message ALW:CALLMON which
allows the monitor to start the cycle of making test calls and
performing call completion analyses. Command 801 generates the
message RTR:CALLMON,ALARM which retires the alarm indicator in
the Call Monitor box. Command 901 generates the message
OP:CALLMON which prints the OP CALLMON message on the ROP. The
body of the message is identical to the REPT CALLMON message
except for the first line which is as follows:
M OP CALLMON PAST 15 MINUTE REPORT
The verbose mode may be entered by typing SET:CALLMON,VERBOSE.
The per-test call results is printed in the form of a REPT
CALLMON message.
The body of the verbose-mode message is as follows:
**********************************************************************
REPT CALLMON VERBOSE TEST CALL
SM = a PORT = b
TRUNK GROUP = c MEMBER = d
SIGNALING TYPE = e TEST TYPE = f
RESULT = g
RETURN CODE = h
**********************************************************************
where a, c, d, e, and f are decimal numbers, b and h are
hexadecimal numbers, and g is a character string. To clear the
verbose mode, enter CLR:CALLMON,VERBOSE.
In the event the REPT CALLMON CURRENT [5 or 15] MINUTE REPORT
message is printed, the data to analyze is the call completion
summary. The failure indicates a less than expected call
completion percentage (50 percent in the current 5 minutes or 90
percent in the current 15 minutes). The number of ``failed''
tests is of most importance because this indicates a possible
call processing, hardware, or network problem. The CCS data (if
equipped) should be compared with non-CCS data to determine if a
common problem exists or if the problem is related only to CCS.
The OP:CALLMON input message (poke 901 on MCC Page 116) can be
typed to compare the past 15 minutes worth of data. Also, the
``LAST_TRKG-PASSED'' field indicates the last trunk group to
pass a test call. If the number 2002 appears in the field, no
tests have passed since the monitor was last initialized. A
manual trunk test can be performed on this trunk group.
Note: The Call Monitor reports failures if the AM, CMP,
CNI, or critical SM(s) undergo recoveries or
initializations.
If failures are caused by ``indeterminate'' or ``not-attempted''
calls, the high-runner failure codes can indicate the reason for
the problem. Because of the nature of the Call Monitor's
interface with TM APT, it is possible that the failures are TM
related; meaning that the front-end setup of a test call could
have failed due to one of many reasons. This results in no idle
trunk member being hunted and verbose output messages printing
the null value for SM (0), port (0), and member (4096). In
these cases, the monitor should not be interpreted as having
detected a loss of call processing functionality. This is the
reason for variable alarm levels.
Following are typical reasons for indeterminate failures:
o TM ABORT: These types of errors occur if TM times out
waiting for a message, TM is interrupted while waiting for
a message, a route failure occurs when routing for a
logical test port (LTP), or an invalid state is
encountered.
o TM INTERNAL: This error can occur when TM fails to send
the route request for the test equipment.
o BAD TEST RESULT: Internal program error.
Following are typical reasons for not attempted failures:
o RESOURCE: These types of errors occur if TM cannot route
to the LTP due to busy or reorder, TTF hardware is out of
service or unavailable, test equipment failure, inability
to allocate tone decoder, failure to reserve equipment, or
other equipment allocation errors.
o BAD DATA: The ODD related to APT may be invalid.
o DSIG OFF NORMAL: Direct signaling capability is
unavailable (for CCS).
o TSIG OFF NORMAL: Trunk signaling capability is unavailable
(for CCS).
o CNI INIT IN PROGRESS: The CNI initialization is in
progress.
If it is determined that failure reports are TM in nature,
inspect the GDSU status on MCC Page 110X,Y (where X is the GDSU
number and Y is the SM number). Make sure the TTFCOM circuits
are in service and pass diagnostics. If they are in service,
turn on the verbose mode to identify specific trunk groups that
are failing and perform a manual operational trunk test,
TST:TRK,TKGMN-x-y, (where x is the trunk group number and y is
any valid in-service/idle member found in the ODD). The TST:TRK
operation gives additional details as to the exact problem,
whether it be TM or call processing related.
Other reasons for operational test failures include trip
failure, pre-trip failure, activation failure, plain old
telephone service (POTS) glare, outpulse failure, and high and
dry. For CCS-related operational test failures, refer to AT&T
235-190-120, Common Channel Signaling Service Features.
Under certain circumstances, the Call Monitor skips test calls
which are not counted as part of the 5- and 15-minute analysis.
These fall under the category of ``no test'' when monitored
under verbose mode and include the following:
o AM MIN MODE: The AM is in Min Mode.
o ASSERT: Internal Assert failure.
o CNI MIN MODE: The CNI is in Min Mode.
o NO IN-SERVICE IDLE MEMBER FOUND: Trunk under test is OOS
(automatic or manual) or all busy.
Operational test failures are the most severe problem and may
indicate a true call processing, hardware, or network problem.
If the number of ``failures'' is the reason for the alarmed
report, analyze the high-runner failure types and turn on the
verbose mode to identify specific trunk groups. A manual
operational trunk test can then be performed to obtain
additional information.
For details on interpreting the input and output messages used
with the Call Monitor feature, refer to AT&T 235-600-700, Input
Messages Manual, and AT&T 235-600-750, Output Messages Manual.
There are two types of line tests: interactive and
noninteractive. The only noninteractive test done is the line
insulation test (LIT). The LIT can be run automatically or
manually. This test uses metallic access to do the measurements
and does not actually place a call on the line. All other line
tests are interactive tests and are initiated either locally or
remotely.
Deferred maintenance for the LU A-Links is provided which allows
the switch to operate normally with a few A-links OOS. The
SET:ALINK a b c d e DEFR input message places the A-link into
the OOS deferred state (see AT&T 235-600-700, Input Messages
Manual, for details). Maintenance activity can be scheduled at
a more convenient time.
Following are some of the manual line tests available from the
TLWS:
o Seize/release a line
o Send receiver off-hook tone
o Ring the line under test
o Monitor busy port
o Connect a line to a DC jack
o Connect a line to an AC jack
o Connect a line to the TTF
o Connect a circuit to the 101 test line
o Perform a line insulation test
o Remove/restore lines (ports)
o Get the status of lines.
Some of the operations available through the TTF are as follows:
o Measure noise
o Measure level
o Measure broadband
o Measure echo return-loss
o Measure singing return-loss
o Measure singing return-loss high
o Send tones at specific level and frequency
o Apply open termination
o Apply quiet termination.
Some of the operations available through the DSU2 ISTF
loopback/108-type test line are as follows:
o Provide ISTF loopback terminations
o Send a pseudo-random bit pattern
o Receive and monitor a pseudo-random bit pattern.
Effective with the 5E8 software release, a user can measure the
integrity of digital data being transmitted on BRI lines between
the CPE and the switch by placing test calls to a 108-type test
line.
Operations available through BRI access to the 108-type test
line include the following:
o Provide TSI loopback terminations
o Send a pseudo-random bit pattern
o Receive and measure a pseudo-random bit pattern
o Perform continuity test of BRI path
o Verify signaling operation of the D-channel.
Additional information on feature, BRI access to the 108-type
test line, and procedures for its use are included in AT&T 235-
105-220, Corrective Maintenance Procedures.
The automatic test for lines is the automatic line insulation
test (ALIT). An ALIT uses the line insulation circuit in the
modular metallic service unit (MMSU) and the metallic
connections provided by the MMSU to the lines in the line unit
to detect gradual cable deterioration. An ALIT may be inhibited
on a line-by-line basis using the RC/V subsystem. The number of
ALIT circuits should be engineered to make it possible to test
all of the lines in the office in about 8 hours. For maximum
efficiency of the testing session, all of the available ALIT
circuits are used in parallel. There are four types of ALIT
tests. These tests are as follows:
o Foreign electromotive force (FEMF)
o Short circuit and ring to ground (SRG)
o Tip and ring to ground (TRG)
o All of the previous.
Maintenance personnel are allowed to enter administrative
functions using input messages. Emergency situations may make
it necessary for a line to be removed from service and placed in
one of several specific out-of-service (OOS) states. If the
line is busy, it is camped-on and waits for control. The
message seized is displayed in the test area when the line is
free for testing. When the line is camped-on, the maintenance
personnel cannot perform any test requests. Only the busy-
monitor or monitor busy and idle commands can be used during the
camped-on period if the maintenance personnel wants to ``listen
in.'' If the maintenance personnel does not want to wait for
the line to become available, a release command can be performed
at this time. An alternative to entering a release command is
to enter new line data at the same test position. When new data
is entered, the old test in progress is automatically torn down.
In the test area, the message ONLY MNTR BUSY (5E6) or DO MNTR
BUSY [4600] OR B&I [4601] ONLY (5E7 and later) is displayed.
All other test requests cause an error message. If the control
of the line is not obtained within 5 minutes, a message in the
test area, RL - FAILED TO OBTAIN BUSY PORT is displayed. When
the line becomes available for testing, the graphic
representation is changed from CAMPED ON to SEIZED. Only one
test position at a time is able to access a specific line. In
other words, two test positions cannot access the same line.
Camping on to a line that is being tested at another test
position is not allowed. A message is displayed in the test
area stating that the line just entered is already being tested.
The following administrative functions are provided by the TLWS:
o Removing line from service
o Restoring line to service
o Unconditionally restoring failed line to service
o Line status is displayed when line is seized
o Line identification [line equipment number (LEN) or
directory number (DN)] is displayed when line is seized.
There are several functions of the TLWS that deal with both
trunks and lines. Some of these functions are as follows:
o Talk and monitor
o Retiring alarms
o Routing messages
o Scheduling tests
o Outputting general information
o Outputting machine detected interoffice irregularity (MDII)
reports
o Restoring trunks.
Note: All of the previous functions can be performed from
the STLWS terminal.
The talk and monitor phone is used to connect to a trunk or line
in order to test the circuit. No test equipment is used between
the talk and monitor phone and the circuit under test when it is
used from the TLWS. This operation would normally be done to
call the maintenance personnel in another office or to monitor a
trunk or line. The talk and monitor phone is the terminating
end of the 101 test line call. When the far-end craft and/or
maintenance person dials the 101 test line directory number, the
call terminates at the talk and monitor phone. If the near-end
person requests transmission testing on the 101 test line call,
the connection is put in the monitor mode for monitoring
interactive test.
Note: Talk and monitor is not supported for wideband
calls.
To verify the operation of the ISTF loopback feature, the craft
can place an interoffice call to the 108-type test line which
has the inverting option (LBKINV). If the loopback feature is
operational, the squelch of the data stream should be clearly
audible.
Alarms can be turned off at the STLWS by depressing the alarm
release (ALM RLS) function key. Status display alarm
indications remain until the alarm condition is repaired.
Output messages can be routed to the TLWS or to the remote
switching control center, depending on whether the TLWS office
is staffed.
A routine test scheduler is provided for APT and ALIT.
Maintenance personnel can override the routine test scheduler by
entering new parameters for the test session. The new
parameters are for the next session only. The automatic
scheduler then returns to the preprogrammed schedules for test
sessions.
Many types of information can be requested and received at the
TLWS. The information can then be printed at the ROP. Some
requests are as follows:
o List of carrier group alarm (CGA) trunks
o CGA member number
o Member number of active CGAs
o Number of active CGAs
o Perform conversion of equipment identifiers
o Convert member number to equipment number
o Conversions between DNs and LENs.
Due to emergencies or intensive test sessions, MDII reports may
need to be stopped temporarily. Therefore, the maintenance
personnel can control the MDII reports by entering the input
message INH:MDII (see AT&T 235-600-700, Input Messages Manual,
for details). When the user desires to have the MDII reports
printed again, enter the input message ALW:MDII (see AT&T
235-600-700 for details).
If the user desires to change the device(s) that receive the
MDII reports, the ECD (classdef) must be changed to reflect the
desired device. Refer to AT&T 235-600-30X, ECD Data Base
Manual, where X = the manual number associated to the applicable
software release. See AT&T 235-000-000, Numerical Index -
Division 235 and Associated Documents, for the complete list of
the ECD data base manuals.
When a trunk or group of trunks is restored conditionally by the
maintenance personnel, the default test call is run. The
default trunk test information (for example, the test type and
trunk group number) is stored in the Automatic Trunk Test Table.
If the test fails, the trunk or trunk group may or may not
remain OOS. The trunk remains OOS if the OOS trunk group
threshold has been exceeded.
The miscellaneous test commands associated with the TLWS menu
can be grouped by function and are used to perform operations on
specific lines or trunks. The commands must be entered from
task selection Page 9000 (5E8 and earlier) or Pages 9000,1 and
9000,2 [5E9(1) and later]. (Refer to Table .AW TJ/ for examples of
Pages 9000, 9000,1 and 9000,2 and to Section .RM 3.9.3/ for
descriptions of commands appearing on each page.
The test access unit (TAU) is of specific interest to the TLWS
user. The TAU provides several plug-in jacks. These jacks are
used in conjunction with portable test equipment and system
software control to gain trunk or line access and perform tests.
The following jacks are provided:
o TEL A and TEL B - to the interframe communications circuit
(TEL=telephone)
o TEL A MON and TEL B MON - to the interframe communications
circuit (TEL=telephone)
o DIRECT ACCESS 1 and DIRECT ACCESS 2 - for direct connection
o ANALOG ACCESS 1 and ANALOG ACCESS 2 - each with S, R, and
ear & mouth (E&M) jacks for analog connection (S=send,
R=receive)
o Four spare jacks for future applications.
The directly connected test unit (DCTU) is a test set that is
integrated into the 5ESS switch to provide basic metallic tests.
These tests can be performed by the DCTU without using the
portable test equipment. Any analog line, universal digital
subscriber line (UDSL), or 2-wire trunk that terminates
metallically to the switch can be tested. Control of the DCTU
is via commands entered at the TLWS which identifies the
particular line or trunk under test from previous seize line or
trunk requests. Measurements requested at the TLWS are taken by
the DCTU and transmitted back to the TLWS for display on the
terminal.
The Remote Office Test Line (ROTL) feature allows interoffice
trunk testing automatically from a Centralized Automatic
Reporting on Trunks (CAROT) system. The CAROT system is a
computerized system that accesses and tests trunks for a maximum
of 14 offices simultaneously. The 5ESS switch ROTL supports the
following capabilities:
o Transmission tests - 100, 102, and 105 test lines
o Connection appraisal - 100, 102, and 105 test lines
o Security callback
o Trunk make-busy and restore
o Trunk status request
o Balance and long-term test.
The 100, 102, and 105 test lines are at the far end of the
trunk. Transmission test calls and connection appraisal calls
are placed via ROTL toward the distant test lines. The ROTL
supports test calls toward the indicated test lines by providing
trunk access and seizure, and outpulsing of the digits necessary
to reach the test line. Also, a tone detection capability is
provided that recognizes when the indicated test line has
answered the test call.
The transmission tests listed previously can also be performed
locally by using the TST:TRK input message.
The ROTL functions consist of answering calls from the CAROT
controller, receiving information in the form of multifrequency
(MF) digits, and causing trunks to be accessed and attached to
the responder for transmission measurements.
Note: ROTL initiated trunk testing is denied on
trunks assigned to a 5ESS switch for AUTOPLEX
System 1000 traffic.
Refer to AT&T 235-105-210, Routine Operations and Maintenance
Procedures, for details concerning the hardware functions, trunk
conditioning, test performed by ROTL, and the ODD requirements.
Table .AW TJ/ lists each TLWS task selection, the TLWS page number,
the applicable 5E6 and later software release, and the figure
number that show an example of each page.
This section contains the TLWS task selection pages for 5E6 and
later software releases. All commands shown on these task
selection pages are listed and described in Section .RM 3.9.3/.
See Figures .AW G18/, .AW G19/, and .AW G20/.
See Figures .AW G21/, .AW G22/, and .AW G23/.
See Figures .AW G24/ and .AW G25/.
See Figures .AW G26/ and .AW G27/.
See Figure .AW G28/.
See Figures .AW G29/, .AW G30/, and .AW G31/.
See Figures .AW G32/ and .AW G33/.
See Figure .AW G34/.
See Figures .AW G35/ and .AW G36/.
See Figures .AW G37/, .AW G38/, and .AW G39/.
See Figures .AW G40/ and .AW G41/.
See Figures .AW G42/, .AW G43/, and .AW G44/.
See Figures .AW G45/ and .AW G46/.
See Figures .AW G47/, .AW G48/, and .AW G49/.
See Figures .AW G50/, .AW G51/, and .AW G52/.
See Figures .AW G53/, .AW G54/, and .AW G55/.
See Figures .AW G56/ and .AW G57/.
See Figures .AW G58/ and .AW G59/.
See Figures .AW G60/ and .AW G61/.
See Figures .AW G62/ and .AW G63/.
See Figures .AW G64/ and .AW G65/.
See Figures .AW G66/ and .AW G67/.
See Figures .AW G68/, .AW G69/, and .AW G70/.
See Figure .AW G71/.
See Figures .AW G72/ and .AW G73/.
See Figure .AW G74/.
See Figure .AW G75/.
See Figures .AW G76/, .AW G77/, and .AW G78/.
See Figure .AW G79/.
This section contains a listing and brief description of each
5E6 and later TLWS command. Commands are listed in numerical
order.
2
CMD RESULT
2000 The seized line or trunk is removed; state changed to OOS.
TST:WSAUTO,TP=Z,RMV
21XX The CPEXX is removed from service. [For 5E6 - 5E8, only valid
for CPEs which support testing. For 5E9(1) and later, valid
for standard BRI CPEs and custom multipoint CPEs which
support testing.]
TST:WSCPE,TP=Z,TEST=RMV,CPE=XX
3000 The seized line or trunk is diagnosed, restored if diagnostic
passes, and is released from TLWS control; state changed to IS.
TST:WSAUTO,TP=Z,RST
31XX The CPEXX is restored to service. [For 5E6 - 5E8, only valid
for CPEs which support testing. For 5E9(1) and later, valid
for standard BRI CPEs and custom multipoint CPEs which
support testing.]
TST:WSCPE,TP=Z,TEST=RST,CPE=XX
4001,X DN X is seized.
CONN:WSLINE,TP=Z,DN=X
4002,X LEN X is seized.
CONN:WSLINE,TP=Z,LEN=AA,BB,CC,DD,EE,FF
4003,X SLEN X is seized.
CONN:WSLINE,TP=Z,SLEN=AA,GG,HH,II
4004,X MLHG X is seized.
CONN:WSLINE,TP=Z,MLHG=JJ,KK
4005,X LCEN X is seized.
CONN:WSLINE,TP=Z,LCEN=AA,LL,MM,NN
4006,X AP X is seized.
CONN:WSLINE,TP=Z,AP=OO,PP
4007,X DN member X is seized.
CONN:WSLINE,TP=Z,DN=QQ,KK
4008,X ILEN X is seized.
CONN:WSLINE,TP=Z,ILEN=AA,RR,SS,TT
or
CONN:WSTRK,TP=Z,ILEN=CC,LL,MM,NN
4101,X TG X is seized.
CONN:WSTRK,TP=Z,TG=X
4102,X TKGMN X is seized.
CONN:WSTRK,TP=Z,TKGMN=AA,BB
4103,X TEN X is seized.
CONN:WSTRK,TP=Z,TEN=CC,DD,EE,FF,GG
4104,X DEN X is seized.
CONN:WSTRK,TP=Z,DEN=CC,HH,II,JJ
4105 The next member of TG is seized.
CONN:WSTRK,TP=Z,NEXTMEM
CMD RESULT
4106,X RAF X is seized.
CONN:WSTRK,TP=Z,RAF=CC,KK,BB
Note: Variables for commands 4002,X, 4003,X,
4004,X, 4005,X, 4006,X, 4007,X, 4008,X, 4102,X,
4103,X, 4104,X, and 4106,X are defined at the end of
this listing.
4200 Incoming 101TL call is seized.
CONN:WSIC,TP=Z
4300 Talk and monitor (T&M) phone is disconnected.
DISC:WSPHONE,TP=Z
4301 T&M phone is connected.
CONN:WSPHONE,TP=Z
4302 The mode of the T&M phone connected to the indicated test
position
(TP) is set to talk so the user can talk and listen.
SET:WSPHONE,TP=Z,MODE=TALK
4303 The mode of the T&M phone connected to the indicated TP
is set to monitor so the user can only listen.
SET:WSPHONE,TP=Z,MODE=MNTR
4304 The mode of the T&M phone connected to the indicated TP
is set to on hold.
SET:WSPHONE,TP=Z,MODE=TEST
4305,X The digits X are used for outpulsing to the remote T&M
phone.
SET:WSPHONE,TP=Z,MODE=OVER,DN=X
4400 The digits for outpulsing are cleared.
CLR:WSOPD,TP=Z
4401,X The digits X are set to be used for outpulsing and/or
are outpulsed over the seized trunk.
SET:WSOPD,TP=Z,OPD=X
4500 The frequency and level at a particular TLWS TP are
cleared.
CLR:WSFREQ,TP=Z
4501,X,Y The frequency is set to X and/or the level is set to -Y
to be used later with TST:WSSEND.
SET:WSFREQ,TP=Z,FREQ=X,LVN=Y
4502,X,Y The frequency is set to X and/or the level is set to +Y
to be used later with TST:WSSEND.
SET:WSFREQ,TP=Z,FREQ=X,LVP=Y
4503,V,W,X,Y User defined default values are set; termination
is set to V, block size is set to W, channel is set to X,
and test equipment is set to Y. Values are to be
used later with TST:WSDGTL,USERDEF (DSL).
SET:WSDGTL,TP=Z,TERM=V,BLKSZ=W,CHAN=X,TESTEQ=Y
4504,V,W User defined default values are set; termination is set
to V and block size is set to W. Values are to be
used later with TST:WSDGTL,USERDEF (TRUNK).
SET:WSDGTL,TP=Z,TERM=V,BLKSZ=W,TRUNK
CMD RESULT
4505 The values for TERM, BLKSZ, CHAN, and TESTEQ are cleared.
CLR:WSDGTL,TP=Z
4600 The audio of a busy line or trunk is monitored from the
T&M phone.
TST:WSMNTR,TP=Z,MODE=BUSY
4601 The audio of a busy or idle line or trunk is monitored
from the T&M phone.
TST:WSMNTR,TP=Z,MODE=IDLE
4800 The line or trunk most recently requested for seizure on
the TP is reseized.
CONN:WSLINE,TP=Z
or
CONN:WSTRK,TP=Z
or
CONN:WSPORT,TP=Z (5E8 and later)
4999 The seized line or trunk is released.
DISC:WSLINE,TP=Z
or
DISC:WSTRK,TP=Z
or
DISC:WSPORT,TP=Z (5E8 and later)
5001 Tone is sent over seized line or trunk.
TST:WSSEND,TP=Z,TEST=SEND
5002,X,Y Tone at frequency X is sent at level -Y over seized
line or trunk.
TST:WSSEND,TP=Z,SEND,FREQ=X,LVN=Y
5003,X,Y Tone at frequency X is sent at level +Y over seized
line or trunk.
TST:WSSEND,TP=Z,SEND,FREQ=X,LVP=Y
5004 Tone of 404 Hz is sent at level 0 over seized line or
trunk.
TST:WSSEND,TP=Z,SEND,FREQ=404,LVP=0
5005 Tone of 1004 Hz is sent at level 0 over seized line or
trunk.
TST:WSSEND,TP=Z,SEND,FREQ=1004,LVP=0
5006 Tone of 2804 Hz is sent at level 0 over seized line or
trunk.
TST:WSSEND,TP=Z,SEND,FREQ=2804,LVP=0
5007 The open termination test is sent over seized trunk.
TST:WSSEND,TP=Z,TEST=OPEN
5008 The quiet termination test is sent over seized trunk.
TST:WSSEND,TP=Z,TEST=QUIET
5031 Digital loopback test is run on seized line or trunk
using default values.
TST:WSDGTL,TP=Z
5032,X,Y,Z (5E8 and earlier) Digital loopback test is run on seized
line using termination X, block size Y, and channel Z.
TST:WSDGTL,TP=P,TERM=X,BLKSZ=Y,CHAN=Z
5032,W,X,Y (5E9(1) and later) Digital loopback test is run on seized
line using termination W, block size X, and channel Y.
TST:WSDGTL,TP=P,TERM=W,BLKSZ=X,CHAN=Y
5033,X,Y Digital loopback test is run on seized trunk using
termination X and block size Y.
TST:WSDGTL,TP=Z,TERM=X,BLKSZ=Y
CMD RESULT
5034 Digital loopback test is run on seized line or trunk
using default values defined and preset by the user.
TST:WSDGTL,TP=Z,USERDEF
5035,Z Test equipment ID of selected channel is displayed.
TST:WSDGTL,TP=Y,TESTEQ=Z
5100 The composite measurement is done on the seized line or
trunk.
TST:WSMEAS,TP=Z,TEST=MEASURE
5101 The broadband level is measured on the seized line or
trunk.
TST:WSMEAS,TP=Z,TEST=BBAND
5102 The far-to-near noise level is measured on the seized
line or trunk.
TST:WSMEAS,TP=Z,TEST=NOISE
5103 The far-to-near level at 1004 Hz -16 dB is measured on
the seized line or trunk.
TST:WSMEAS,TP=Z,TEST=NWT
5104 The echo-return loss is measured on the seized line or
trunk.
TST:WSMEAS,TP=Z,TEST=ERL
5105 The singing-return loss is measured on the seized line
or trunk.
TST:WSMEAS,TP=Z,TEST=SRL
5106 The singing-return loss, high, is measured on the seized
line or trunk.
TST:WSMEAS,TP=Z,TEST=SRLHI
5201 The receiver off-hook test is run on the seized line.
TST:WSSUPV,TP=Z,TEST=ROH
5202 The ring test is run on the seized line.
TST:WSSUPV,TP=Z,TEST=RING
5203 The trunk on-hook test is run on the seized trunk.
TST:WSSUPV,TP=Z,TEST=ON
5204 The trunk off-hook test is run on the seized trunk.
TST:WSSUPV,TP=Z,TEST=OFF
5205 The wink test is run on the seized trunk.
TST:WSSUPV,TP=Z,TEST=WINK
5206 The quick wink test is run on the seized trunk.
TST:WSSUPV,TP=Z,TEST=QWINK
5207,X The digital service unit 2 - recorded announcement
function (DSU2-RAF) phrase X is played.
TST:WSSUPV,TP=Z,TEST=PHRASE,PHRASE=X
5208,W,X,Y,Z The DSU2-RAF announcement is played with application W,
header announcement X, tail announcement Y, and
inflection Z.
TST:WSSUPV,TP=P,
TEST=ANN,APPL=W,HANN=X,TANN=Y,INFL=Z
5209 The defense switch network preemption tone test is run
on the seized line.
TST:WSSUPV,TP=Z,TEST=PPTONE
5210,W,X,Y,Z The DSU2-RAF dial-through announcement test is run with
application W, header announcement X, tail announcement
Y, and inflection Z.
TST:WSSUPV,TP=P,
TEST=DTA,APPL=W,HANN=X,TANN=Y,INFL=Z
CMD RESULT
5212 The network termination 1 mismatch test is run on
the seized line.
TST:WSSUPV,TP=Z,TEST=MSMTCH
5221 The ringback test is run on the seized trunk.
TST:WSSUPV,TP=Z,TEST=RNGBK
5222 The operator attached signal test is run on the
seized trunk.
TST:WSSUPV,TP=Z,TEST=OPAT
5223 The operator released signal test is run on the
seized trunk.
TST:WSSUPV,TP=Z,TEST=OPRL
5224 The coin collect signal test is run on the seized
trunk.
TST:WSSUPV,TP=Z,TEST=CNCL
5225 The coin return signal test is run on the seized
trunk.
TST:WSSUPV,TP=Z,TEST=CNRT
5226 The coin collect and operator released signal test
is run on the seized trunk.
TST:WSSUPV,TP=Z,TEST=CCOR
53XX,Y,Z An interactive digital test with a loopback
established at CPEXX is performed using block size Y
on channel Z (only valid for CPEs that support
testing).
TST:WSCPE,TP=P,TEST=LPBK,CPE=XX,BLKSZ=Y,CHAN=Z
5401 The line insulation test (LIT) is performed on the
seized line.
TST:WSAUTO,TP=Z,LIT
5402 The automatic digital subscriber line (DSL) test is
run on the seized line using default values.
TST:WSAUTO,TP=Z,TSTDSL
5403,V,W,X,Y,Z The automatic DSL test is run on the seized line
using termination V, duration W, block size X,
channel Y, and acceptable bit error rate Z.
TST:WSAUTO,TP=P,TSTDSL,TERM=V,DUR=W,BLKSZ=X,
CHAN=Y,ABER=Z
5404 The automatic line evaluation (ALE) session is run on
the seized line, and error counts are reported.
TST:WSAUTO,TP=Z,ALE=ALL,REPT
5405 The automatic trunk test is run on the seized trunk
using default values.
TST:WSAUTO,TP=Z,TSTTRK
5406,X The automatic trunk test of type X is run on the
seized trunk.
TST:WSAUTO,TP=Z,TSTTRK,TYPE=X
5407,X,Y The automatic trunk test of type X using outpulse
digits Y is run on the seized trunk.
TST:WSAUTO,TP=Z,TSTTRK,TYPE=X,OPD=Y
5408 The seized line or trunk is diagnosed.
TST:WSAUTO,TP=Z,DGN
5409,W,X,Y,Z The automatic trunk test is run on the seized trunk
using type W, outpulse digits X, duration Y, and
block size Z.
TST:WSAUTO,TP=P,TSTTRK,TYPE=W,OPD=X,DUR=Y,BLKSZ=Z
5410 The automatic DSL fault sectionalization test is run
on the seized line using default values.
TST:WSAUTO,TP=Z,TSTDSL,SECT
CMD RESULT
5411,T,W,X,Y,Z The automatic DSL fault sectionalization test
is run on the seized line using termination T,
duration W, block size X, channel Y, and acceptable
bit error rate Z.
TST:WSAUTO,TP=P,
TSTDSL,SECT,TERM=T,DUR=W,BLKSZ=X,CHAN=Y,ABER=Z
5411,S,T,W,X,Y,Z The automatic DSL fault sectionalization test is
run on the seized line using termination S,
duration T, block size W, channel X, mode Y, and
acceptable bit error rate Z.
TST:WSAUTO,TP=P,
TSTDSL,SECT,TERM=S,DUR=T,BLKSZ=W,CHAN=X,
MODE=Y,ABER=Z
5412,X,Y The ALE session is run on type X using option Y.
TST:WSAUTO,TP=Z,ALE=X,Y
5413,X The automatic DSL cyclic redundancy check (CRC)
test is run on the seized line for duration X.
TST:WSAUTO,TP=Z,TSTDSL,TEST=CRC,DUR=X
5413,X,Y The automatic DSL CRC test type X is run on the
seized line for duration Y.
TST:WSAUTO,TP=Z,TSTDSL,TEST=X,DUR=Y
5414 The network termination 1 mismatch test is run on
the seized line.
TST:WSAUTO,TP=Z,TSTDSL,TEST=MSMTCH
5415 An in-progress call trace is requested on the
port known to the TLWS
(SEIZED, CAMPED, or UNDER TEST).
TST:WSAUTO,TP=Z,IPCT
5601 The voltage, resistance, and capacitance tests
are performed on the seized line or trunk.
TST:WSMET,TP=Z,TEST=ALL
5602 The voltage test is performed on the seized line or
trunk.
TST:WSMET,TP=Z,TEST=V
5603 The resistance test is performed on the seized line
or trunk.
TST:WSMET,TP=Z,TEST=R
5604 The capacitance test is performed on the seized
line or trunk.
TST:WSMET,TP=Z,TEST=C
5605 The distance-to-open test is performed on the seized
line.
TST:WSMET,TP=Z,TEST=DIST
5606 The ringer count test is performed on the seized line.
TST:WSMET,TP=Z,TEST=RINGER
5607 The home totalizer test is performed on the seized
line.
TST:WSMET,TP=Z,TEST=HT
5608 The detect coin test is performed on the seized line.
TST:WSMET,TP=Z,TEST=DC
5609 The collect coin test is performed on the seized
line.
TST:WSMET,TP=Z,TEST=CC
5610 The return coin test is performed on the seized
line.
TST:WSMET,TP=Z,TEST=RC
5611 The monitor-for-short test is performed on the
seized line.
TST:WSMET,TP=Z,TEST=SHORT
CMD RESULT
5612 The pair gain test controller (PGTC) is added into the metallic
connection on the seized port.
TST:WSMET,TP=Z,TEST=PGTC
5801 The seized line or trunk is connected to the test access unit (TAU)
jack AC1 for digital testing.
CONN:WSJACK,TP=Z,JACK=AC1
5802 The seized line or trunk is connected to TAU jack AC2 for
digital testing.
CONN:WSJACK,TP=Z,JACK=AC2
5803 The seized line or trunk is connected to TAU jack DC1 for
metallic testing.
CONN:WSJACK,TP=Z,JACK=DC1
5804 The seized line or trunk is connected to TAU jack DC2 for
metallic testing.
CONN:WSJACK,TP=Z,JACK=DC2
5990 The test is stopped, and all associated testing hardware is
released.
RLS:WSTST,TP=Z
5999 Any test that is running on the seized line or trunk is stopped.
STP:WSTST,TP=Z
9200 The CPE information for the line seized is displayed on the
TLWS screen.
TST:WSCPE,TP=Z,TEST=CPE
9201 The USPID information for the line seized is displayed on the
TLWS screen.
TST:WSCPE,TP=Z,TEST=USPID
9500 The test results from the specified TLWS test position are
printed immediately or with [,LOG] option set for automatic
printing.
OP:WSDATA,TP=Z
9600 The testing status of TLWS test position Z is printed.
OP:WSSTAT,TP=Z
9601 The testing status of all TLWS test positions is printed.
OP:WSSTAT
9602 All default values defined and preset by the user are displayed.
OP:WSDATA,TP=Z,USERDEF
9700 The CPE information along with information about CPE
provisioned for service on the DSL is printed.
TST:WSCPE,TP=Z,TEST=PRINT
The variables for commands 4002,X, 4003,X, 4004,X, 4005,X, 4006,X,
4007,X, and 4008,X (Line) are as follows:
AA=SM KK=MEM
BB=LU LL=ISLU
CC=GR MM=LNGRP
DD=BD NN=LCN
EE=SW OO=AP
FF=LV PP=RL
GG=DCLU QQ=DN
HH=RT RR=IDCU
II=Line SS=RT or DS1
JJ=GRP TT=LT or DS0
The variables for Commands 4008,X (Trunk), 4102,X, 4103,X, 4104,X,
and 4106,X are as follows:
AA=GRP HH=DLTU
BB=MEM II=DFI
CC=SM JJ=CH
DD=TU KK=RAF
EE=SG LL=IDCU
FF=BD MM=RT or DS1
GG=CKT NN=LT or DS0
The recent change/verify (RC/V) system is a function that allows
maintenance personnel access to the 5ESS switch data base. The
RC/V system is used to: add to, delete from, update, or verify
the data base. A stand-alone RC/V subsystem is provided at the
5ESS switch. Therefore, operation support system (OSS)
interfaces are not required to use RC/V capabilities. The
stand-alone RC/V enables craft and/or maintenance personnel to
change or verify the data base using video displays and menu
selection. For detailed information applicable to recent
change/verify procedures [AT&T 235-118-XXX (XXX = manual number
associated to applicable software release)], refer to AT&T 235-
000-000, Numerical Index - Division 235 and Associated
Documents.
The screen program allows the craft to run office data base
editor (ODBE), access editor (ACCED), and UNIX(R) operating
system shell via the SCC data link or at the MCC terminal. For
offices that have 5E7 and later software releases, the screen
program allows the craft to run the Common Network Interface
Data Base Consolidator (CNIDBOC). For offices that have 5E9(1)
and later software releases, the screen program allows the craft
to run the Automated Circuit Pack Return Tag (RTAG) tool. Also,
the screen program provides page-at-a-time output filtering for
ODBE, ACCED, UNIX operating system shell, CNIDBOC, and RTAG from
other terminals in the office.
At the SCC, MCC, or STLWS terminal, enter poke command 194 to
activate the screen program. Also, the screen program can be
activated via the input message RCV:MENU:SCREEN.
Note: If the user enters the RCV:MENU:SCREEN from a
terminal that accepts poke commands, a rejection
message appears indicating that the poke command
194 should be used instead of the RCV:MENU:SCREEN
message.
Main Menu Display Page
After the user enters the poke command/input message
successfully, the main menu page is displayed (see Figures .AW G80/,
.AW G81/, and .AW G82/). Select the desired program, by entering the
appropriate command [where o = ODBE, a = ACCED, u = UNIX
program, c = CNIDBOC (for 5E7 and later) or r = RTAG (for 5E9(1)
and later]. To exit the screen program, enter Q. Once a
desired program has been selected, the user can begin entering
commands on the terminal.
Running programs from the screen program is similar to running
programs directly from the UNIX program. However, some
differences do exist and are explained in the following
sections.
Entering Special Characters
Certain characters cannot be directly entered from all types of
terminals in the office. The following identifies characters
that need a 2-character representation.
**********************************************************************
DESIRED ENTER TWO
CHARACTER CHARACTER REPRESENTATION
--------- -----------------------
; \\:
_ \\-
! \\1
$ \\s
& \\8
@ \\a
? \\/
\\ \\\\
**********************************************************************
Paging and Scrolling
The screen program displays the user's entries and the responses
on the terminal starting from the top of the screen and working
towards the bottom. When the user has filled the screen, the
screen program scrolls (that is, rewriting the affected lines)
the display upward. Scrolling automatically stops so the user
can review any line that was not visible since the last user
input command. When scrolling stops for this reason, the
message shown in Figure .AW G83/ is displayed:
At this point, the user can enter NP, RUN, or wait for the 2-
minute timeout.
If NP is entered or the 2-minute timeout occurs, the screen
continues to scroll again until either the display fills with
new lines (the *MORE* prompt is displayed) or until the output
is complete (whichever occurs first).
If RUN is entered, the screen continues to scroll again until
the output is complete.
Clear Screen
If the user desires to clear the display screen and have the
output to fill in the screen from the top, enter CS.
Note: The CS cannot be used when user is in the main menu
mode or when output is paused with the *MORE*
prompt.
Break Program in Progress
The user can send a break signal to stop the program running
(via the screen program) by entering BREAK.
Note: The BREAK cannot be used when user is in the main
menu mode or when output is paused with the *MORE*
prompt.
Exiting Screen Program
Note: The user cannot exit the screen program when in the
main menu mode or when the output is being paused
with the *MORE* prompt.
The user can exit the screen program by doing the following:
1. Entering Q or EOF to return to main menu
2. Entering Q to exit the screen program.
Abort Screen Program
The user can abort the program being run by the screen program
as follows:
a. If the *MORE* prompt displayed, enter RUN.
b. If the program is ``not'' at the *MORE* prompt or if RUN
has been entered, enter either Q or EOF.
Depending on the state of the program aborted, in about 2
minutes the screen program will either return the user to the
main menu or exit entirely.
When using the screen program, do not attempt to direct any
output to the terminal by redirecting to the UNIX program port
name. If user needs to direct output to the terminal, use the
``1pr'' UNIX program command as follows:
date | 1pr ttyv #
When using the UNIX operating system shell from within the
screen program, do not run interactive programs (that is,
Ibrowse, apprc, genbkup, ODBE, rcvecd, rcvsg, ACCED, CNIDBOC, or
RTAG). These interactive programs are not compatible with the
screen program when running directly from the UNIX operating
system shell. However, we know that ODBE, ACCED, CNIDBOC, and
RTAG can be run from the screen program's main menu.
Note: The ``ed'' editor can be used with the screen
program.
If the user accessed the screen program via poke command 194,
other display pages cannot be accessed until the user exits the
screen program.
The following message can appear when exiting the screen
program:
UNRECOVERABLE FAULT
This response indicates some event (such as the TTY channel
detecting errors) that the screen program was unable to
compensate for, occurred.
The input message area is used to enter human-interface input
messages. These messages are comprised of alphanumeric
abbreviations instructing the system to perform required tasks.
DGN:MCTSI=1-1,RPT=5,TLP; is a sample message. It instructs the
switch to diagnose the module controller unit 1 in interface
module 1, repeat the diagnostic five times, and provide a
trouble location process (TLP) printout.
The basic method for inputting a message is to enter it on the
bottom line of the input message area and execute it with the
semicolon (;). An acknowledgment is returned by the system
within seconds from the time the semicolon was entered. At the
time the acknowledgment is issued, the message with
acknowledgment is scrolled up one line to clear the bottom line
for the entry of an input message. It is also printed on the
ROP. The cursor is then automatically repositioned at the start
of the bottom line for entry of the next input message. The
message display page may be used to display the message(s) in
the control and display portion of the video display terminal.
When the message display page is not displayed, the message with
acknowledgment continues to be displayed on the next to the
bottom line until another message is executed or the next output
message is printed. When the display message page is used, the
message with acknowledgment is printed on the ROP and scrolled
into the control and display area.
Message input formats may be selected by using different end-
of-line characters for input messages. The placement of the
cursor on the input line is dependent upon what message input
format has been selected. Different input formats are possible
by using various end-of-line characters. They are as follows:
a. ; (MML) executes (and terminates) all types of input
formats.
b. ! (MML) continues message that is more than one line long.
Multiple line input messages may be entered by using the forward
exclamation point (!) at the end of each command line. The
message can be terminated after the last line with the semicolon
(;). This format causes the input subsystem to save all the
information entered by each message line and then act on the
saved data after the final message line is entered. Once an
input message line has been entered, the procedure for entering
another line is the same as the one for messages using the
exclamation point. When the last message line is entered, the
message lines are placed sequentially into the output stream and
printed.
The capability to erase or cancel characters just entered
(versus characters repeated) is provided. Input the underscore
(_) character or backspace for each character back to and
including the character to be erased or canceled. The entering
of the underscore or backspace once a message has been executed
(end-of-line character entered) is prohibited. The input
message entry area is cleared and any incomplete input format in
progress canceled by entering <del> key on the input line. A
single-input line can be restarted (cleared of input entered) at
any time by entering the @ character. The input cleared by
these functions will not be printed on the ROP. The RETURN and
ENTER keys will be accepted in place of the exclamation (!) or
semicolon (;) and echo the characters when used. Table .AW TK/
explains line administration and end-of-line characters.
Effective with the 5E9(1) software release, input message
editing and history are provided by the system. A history
mechanism maintains a list of up to 200 input commands that have
been previously entered and saved on a given terminal. These
saved commands can be recalled, edited, and then reexecuted.
Commands saved in the list can be recalled by number or with a
search string. The last command also can be recalled directly.
Once a command is recalled, the user can append or substitute
until the desired new command is constructed. The new command
can then be executed.
The User Guidelines section in AT&T 235-600-700, 5ESS Switch
Input Messages Manual, Volume 1, contains detailed information
on input message editing and history.
When a valid command is executed, it is sent to the subsystem
that performs the function. If a command does not meet the
following criteria, the NG acknowledgment is displayed.
o Is not from the page currently displayed
o Is not a valid page selection command
o Cannot be executed with the current system configuration.
If the subsystem is unable to perform the function because of a
lack of system resources, the RL acknowledgment is displayed.
When a subsystem accepts the requested command and is able to
start the function, a PF acknowledgment is displayed to indicate
that the completion results of the function are forthcoming on
the printer. At the time the PF is displayed, a message
identifying the action requested and its origin is printed on
the printer. The NG, RL, and PF are displayed within seconds
from the time of execution of the command. The command with
acknowledgment is displayed on line 4, column 25. When the MSG
(message) input mode is selected, the MCC is placed in a state
for entering a human-interface input message. While in this
mode, the system performs timing checks for the interval between
characters. This interval is 45 seconds. If an expected
character is not input within this interval, a ?T acknowledgment
is issued, the line is scrolled up one, and the cursor is
repositioned at the start of the input message entry line.
Several additional acknowledgments are used to signify syntax,
unit selection, and execution errors as defined in AT&T 235-
600-700, Input Messages Manual, Volume 1, User Guidelines
section. Two possible conditions that prevent an input mode
(CMD or MSG) from being selected are a duplex-processor failure
or a failure of the interface between the AT&T 3B20 computer and
the video display terminal.
A help feature is provided on input messages that provides the
following:
o Improved error messages in cases where syntax or semantic
errors are found on entered messages.
o Help on input messages formats, including argument type and
range.
o Prompting for entering input messages.
For more information on how to get help, how to get prompted for
keywords or parameters, and how to terminate help, refer to AT&T
235-600-700, Input Messages Manual, Volume 1, User Guidelines
section.
Any deviation from normal system operating conditions produces a
printout on the MCC or remote switching control center. The
printout contains all data relevant to the condition, diagnostic
results, and a list (by priority) of suspected faulty circuit
boards. Periodic traffic and plant summaries are also printed
on the ROP. All of these printouts are important in determining
system status, with diagnostic information and circuit board
lists being of primary importance to maintenance personnel. The
printer should be connected whenever maintenance is being
performed in the office. For detailed analysis of printouts,
refer to AT&T 235-600-750, Output Messages Manual.
This section describes the ODBE at a high level. For a more
detailed description or before using ODBE, refer to AT&T 235-
105-220, Corrective Maintenance Procedures.
The ODBE is a tool which allows maintenance personnel to make
manual changes to the 5ESS switch data base. Information is
stored in the data base in relations which are groups of
predefined, associated attributes. Each instance of data in a
relation is referred to as a tuple. Relations, tuples, and
attributes can be viewed as a table (the table being a relation)
where each item (row) in the table is a tuple, and each column
in the table is an attribute. The ODBE manipulates this
relational data base structure. Refer to AT&T 235-600-10X (X =
manual number associated to applicable software release),
Translations Data Manuals, for details concerning the attribute
and relation names, attribute and relation descriptions,
population rules for each attribute, and other applicable
information. Refer to AT&T 235-000-000, Numerical Index -
Division 235 and Associated Documents, for the complete list of
AT&T 235-600-10X, Translations Data Manuals.
Caution: By using ODBE, it is possible to update, delete,
or insert information into ODD relations which
is critical to the operation of the 5ESS switch.
Improper use of ODBE can be service affecting.
Before updating, deleting, or inserting
information into a base relation, consult local
supervision concerning policy.
The ODBE offers a user the ability to create, inspect, and
modify the contents of the data base in an interactive mode. It
is driven by data definition information which is contained in
the 5ESS switch data dictionaries and accessed through the data
base manager (DBM) interface. This interface permits the user
to review, update, insert, and delete information in the data
base one tuple at a time. Any relation defined in the data
dictionaries can be inspected and modified.
The ODBE is controlled by input from the RC/V, TLWS, STLWS, or
the MCC (Page 194) video display terminals. The output data is
displayed at the terminal where input is entered and cannot be
displayed on the ROP.
The input message, RCV:MENU:[DATA,]ODBE;, is used to access the
ODBE function on the terminal.
Note: The keyword DATA in the input message is optional.
If the switch accepts the input message, the system
responds with a printout follows (PF) followed by
an output message, OFFICE DATA BASE EDITOR. A
password may optionally be required to use ODBE.
When using ODBE, the response of the user to a given prompt
is usually a data base defined name, an encoded choice from a
menu of options, or an ODBE special character.
The ODBE is a finite state process and, as such, has a set of
states, inputs, and resulting states. Following are the
possible ODBE states:
1. Enter processor number (the highest state)
2. Enter relation name
3. Enter tuple operation
4. Enter primary key
5. Enter attribute value (the lowest state).
Special characters have a meaning only if they are the first
character in a user response. All special characters and
their meanings can be found in AT&T 235-105-220, Corrective
Maintenance Procedures.
The most commonly used special characters include an
exclamation (!), which lifts the user to the next higher
state (for example, ``Enter Primary Key'' to ``Enter Tuple
Operation''), control-d, which exits ODBE (that is,
depressing CTRL and d keys simultaneously will end the ODBE
session), and a question (?) which will display valid
possible responses for that state. When possible user values
are listed in the following sections, special character
entries will not generally be listed.
When data is input into ODBE, white space (blanks, tabs, new
lines, etc.,) is ignored and only delimits item values.
White space may be input as an item value by placing the
entire value in double quote characters (" "). This holds
true whether the input is interactive or from a bulk input
file.
In the Enter Processor Number state of ODBE, the user is
prompted for the processor/module number where the data in
question resides. Following is a list of possible responses
to the prompt:
o 1-192 for the SM number
o 193 for the AM (5E6 and later software releases)
o 194-205 for the primary CMP number (5E6 and later
software releases)
o 206-217 for the mate CMP number (5E6 and later software
releases)
o ALL for redundant tuple read.
Note: The ``ALL'' response refers to an ODBE
feature that allows the user to examine
redundant or partitioned tuples across all
SM processors. Upon selecting the ``ALL''
option, the user is prompted for the
relation name and then a key value. All
tuples that match this key across all SMs
is written to a user-specified file. This
feature is useful for debugging split
translations when one SM has inconsistent
data in association to other SMs.
In the Enter Relation Name state of ODBE, the user is
prompted for the base relation name. See AT&T 235-105-220,
Corrective Maintenance Procedures, for additional details
concerning these responses. Following is a list of possible
responses to the prompt:
1. Valid relation name. (When a relation name is entered,
ODBE goes into the Enter Tuple Operation state.)
2. PARAMETER to edit parameters. Parameters are global
variables which are used for ODD sizing, ODD
engineering, and other office-specific information.
Caution: Extreme caution is required when using
this option.
3. STORAGE to modify storage table relations (5E7 and
later). This option is used to read or insert tuples of
a storage table relation.
Caution: Extreme caution is required when using
this option.
After entering STORAGE, the user will be prompted for a
Storage Table Name. (Upon accepting a valid Storage
Table Name, ODBE goes into the Enter Tuple Operation
state.)
4. OVWTODD to overwrite data (5E6). This option is used
when it is necessary to modify data in the ODD or
Control ODD.
Caution: Extreme caution is required when using
this option. Misuse of this option
could be SEVERELY detrimental to the
operation of that particular processor
on the switch. THIS OPTION SHOULD BE
USED IN EMERGENCY SITUATIONS ONLY.
In the Enter Tuple Operation state of ODBE, the user is
prompted for the data operation to be performed. Valid tuple
operations at this level depend on what was entered at the
Enter Relation Name prompt.
1. If a valid relation name was entered, then the valid
tuple operations are as follows:
o I: Insert or add a new tuple.
o R: Review or display a tuple.
o U: Update or modify a tuple.
o D: Delete or remove a tuple.
o W: Write a tuple to a file.
o BI: Batch Insert or add tuples from a file.
Caution: Batch Insert of files larger than
1000 tuples must be split into
smaller files. Large files can
time out during processing, and
also require RC/V logging to be
inhibited. It is very important
not to allow RC/V while logging is
inhibited.
o BR: Batch Review or output a relation to a file.
o BW: Batch Write (write tuples into specified
file).
o VIRT: Display information about a virtual
relation. (This command is only valid for virtual
relations in 5E7 and later software releases).
2. If PARAMETER was entered, ODBE will prompt for the
parameter name. After ODBE accepts a valid parameter
name, the valid parameter operations are as follows:
o R: Review or display a parameter.
o U: Update a parameter.
o BR: Batch Review parameters to a file.
3. If STORAGE was entered (5E7 and later software
releases), the valid tuple operations are as follows:
o I: Insert or add a new tuple.
o R: Review (display a tuple without entering the
generated key).
o BI: Batch Insert (add generated key tuples from a
file).
o BR: Batch Review (output generated key tuples from
a file).
o GKR: Generated Key Review (display a tuple with
the generated key specified).
o GKVIRT: Display the parent relations of a storage
table relation.
4. If OVWTODD was entered (5E6 software release), then the
only valid tuple operation is the following:
o ODDOVWT: ODD Overwrite (overwrites data in ODD or
Control ODD).
Tuple operations BI, BW, and BR prompt for the UNIX operating
system filename in which to print the date or in which the
data is stored. Tuple operations VIRT and GKVIRT print
information to the terminal screen then prompt for another
tuple operation. The tuple operation ODDOVWT prompts for the
memory type, the ODD address, and associated data to be
overwritten. For all other tuple operations, ODBE enters the
Enter Primary Key state.
In the Enter Primary Key state of ODBE, the user is prompted
by name for the components of the key which uniquely defines
a tuple in the relation. The only valid response to the
Enter Primary Key prompt is a valid primary key value.
Upon entering a valid primary key value, ODBE goes into the
Enter Attribute Value state.
In the Enter Attribute Value state of ODBE, the user is
prompted for an attribute value by name. Possible responses
to the prompt are as follows:
o A valid attribute value.
o A ``<'' to go back to the previous attribute.
o A ``>'' to skip remaining items and complete whatever
tuple operation you are involved in
o A plus (+) to list attributes.
This is the lowest level in ODBE. After entering the
attribute values, the user may return to a higher level by
entering an exclamation (!) or exit ODBE by entering a
``control-d''.
ACCED is an interactive tool which allows the craft to
manually locate, investigate, and correct data base
corruption, and to reorganize hashed relations.
Caution: Misuse of ACCED could result in premature
exhaustion of data base memory.
ACCED is invoked via input message RCV:MENU:ACCED or by
typing the full path to ACCED from the UNIX system shell.
ACCED can also be executed via the screen program
(RCV:MENU:SCREEN) or MCC Page 194. Information on the screen
program and MCC Page 194 can be found in Section .RM 3.11/ of this
document.
Upon access to ACCED, the craft enters into an interactive
session of prompts and responses.
Effective with the 5E7 software release, the ACCED tool is
enhanced to include six data base utility operations: REVIEW,
SCAN, OVERWRITE, DESTROY, REORG, and HASHSIM. The ACCED data
base utilities allow craft to locate, investigate, and
correct data corruption without manually performing the
extensive, error-prone calculations required in the past.
The HASHSIM operation is used for hashing simulation to
determine optimal hashing parameters for reorganizing hashed
relations.
The enhanced ACCED gives the user capabilities to do the
following:
o Review head table, intermediate data pages (IDP), and
data pages (DP) of a relation.
o Review memory and disk office dependent data (ODD) by
block ID or by address.
o Review the run-time access dictionary for a relation,
including past, current, future, and ODD versions.
o Review information about a relation, such as its tuple
size, tuple address, IDP information, and DP
information.
o Scan a relation for corruption by searching for
unreadable tuples.
o Overwrite one, two, or four bytes of data at a given
memory or disk address.
o Destroy an entire relation, an IDP in a relation, or a
DP in a relation.
o Manually reorganize relations of access types DBACC_GK
and DBACC_HASH.
o Simulate hashing a relation of access type DBACC_GK or
DBACC_HASH to help determine optimal parameters for a
manual reorganization.
When ACCED is entered, the craft specifies one of the six
data base utility operations. All six operations are
permitted on the AM, SM, and the active side of the CMP.
Only the REVIEW operation is available on standby CMP because
ODD data on the standby side may not be current. Each
operation, in turn, has its own submenu. The user
interactively traverses ACCED's menu hierarchy to perform
operations on the data base. Four concurrent ACCED processes
can be run at any time in a processor (AM/SM/CMP).
Following is an overview of each ACCED operation. Refer to
AT&T 235-105-220, Corrective Maintenance Procedures, for
additional information on ACCED operations and procedures for
their use.
When REVIEW is selected from the main menu, ACCED prompts the
user for the relation name and the item to review. Following
are possible things to review:
o Head table: The head table option is displayed only for
relations with head tables (all but 1-level indexed
relations). When head table is selected for review,
ACCED prompts for the starting relative address and
number of bytes to review. The address is relative to
the beginning of the head table, so address 0 (zero) is
the start of the head table. Results of the review are
dumped to the screen and routed to the ROP and Switching
Control Center System (SCCS) if output message (OM)
printing is on.
o IDP or DP: The IDP option is displayed only for
relations with IDPs (3-level indexed relations). When
IDP (or DP) is selected for review, ACCED prompts for
the intermediate data page number (or data page number),
the starting relative address, and the number of bytes
to review. The address is relative to the beginning of
the IDP (or DP), so address 0 (zero) is the start of the
IDP (or DP). Results of the review are dumped to the
screen and routed to the ROP and SCCS if OM printing is
on.
o Access dictionary: When the access dictionary is
selected for review, ACCED prompts for the version to
review; current, any, or ODD. For current and ODD
versions, the appropriate access dictionary is dumped to
the screen and routed to the ROP and SCCS if OM printing
is on. For any version, the craft must provide an index
into the access dictionary array. The access dictionary
of the given index is dumped. The craft can use this
feature to dump the past version of the access
dictionary (referred to as ``acc_bidx'' in the access
dictionary) or the future version (referred to as
``acc_nidx'').
o Data at a specified memory address: When data at a
memory address is selected for review, ACCED prompts for
the memory type, the starting physical address, and the
number of bytes to review. It is important to note that
the address is absolute. Results of the review are
dumped to the screen and routed to the ROP and SCCS if
OM printing is on.
o Data within a specified memory block: When data within
a memory block is selected for review, ACCED prompts for
the block ID, the starting relative address within the
block, the number of bytes to review, and the memory
type. The address is relative to the beginning of the
block, so address 0 (zero) is the start of the block.
Results of the review are dumped to the screen and
routed to the ROP and SCCS if OM printing is on.
o Tuple information: When tuple information is selected
for review, ACCED prompts for the tuple key of interest.
ACCED supplies the following information for that tuple:
IDP number, IDP address, IDP block ID, DP number, DP
address, DP block ID, tuple address, physical tuple
size, logical tuple size, and memory type. The IDP
information is provided only for 3-level indexed
relations. The information is dumped to the screen and
routed to the ROP and SCCS if OM printing is on.
When SCAN is selected at the main menu, ACCED prompts for the
relation name, the starting IDP (if appropriate), and the
starting DP. Then, ACCED begins reading tuples from that
point until it reaches the end of the relation or until it
finds a bad tuple. When data corruption is found, the
following information is furnished for the corrupted tuple:
IDP number, IDP block ID, DP number, DP block ID, tuple
address, and physical tuple size. The IDP information is
provided only for 3-level indexed relations. The information
is dumped to the screen and routed to the ROP and SCCS if OM
printing is on.
When OVERWRITE is selected at the main menu, ACCED prompts
for the memory type, the length of overwrite (one, two, or
four bytes), the starting physical address, the current
memory contents for that location and length, and the new
data. The user must know the current memory contents before
ACCED will permit the overwrite to continue. The results of
the overwrite are dumped to the screen and always routed to
the ROP and SCCS.
It is important to note the following:
1. Recent Change (RC) must be inhibited before overwriting
memory to avoid possible ODD splits. An RC can be
inhibited by typing input message INH:RC.
2. The OVERWRITE operation is not logged for all
processors, so an ODD backup is required immediately
after the change.
3. OVERWRITE is permitted only on the active side of the
CMP. To update the standby side of the CMP, a soft
switch (which does a physical memory copy) is required
immediately after the backup.
When DESTROY is selected at the main menu, ACCED prompts for
the relation name and for whether to destroy the whole
relation, an IDP (if the relation is 3-level indexed), or a
DP. If the whole relation is to be destroyed, then the head
table block ID in its access method common dictionary is
zeroed out. If an IDP is to be destroyed, ACCED prompts for
the IDP number whose entry in the head table is subsequently
zeroed out. If a DP is to be destroyed, ACCED prompts for
the DP number whose entry in the head table (or IDP if 3-
level indexed) is subsequently zeroed out. The DESTROY is
reported to the screen and always routed to the ROP and SCCS.
It is important to note the following:
1. Recent Change (RC) must be inhibited before destroying
memory to avoid possible ODD splits. An RC can be
inhibited by typing input message INH:RC.
2. The DESTROY operation is logged for the CMP so the
standby CMP will be updated through continuous roll-
forward. The DESTROY operation is not logged on
processors other than the CMP.
An ODD backup is required immediately after a DESTROY on
all processors, except CMP. But, backup is recommended
for all processors.
When REORG is selected at the main menu, ACCED prompts for
the relation name and checks to see if the relation is hashed
(that is, access type DBACC_GK or DBACC_HASH). If the
relation is not hashed, ACCED prompts for another relation
name. If the relation is hashed, the access method common
dictionary and dictionary for DBACC_GK or DBACC_HASH are
displayed for the craft (they are not printed on the ROP).
Then, ACCED asks if a hashing simulation is desired before
manual reorganization is performed, and, if so, runs HASHSIM
(described under Hashsim Operation, following). Whether or
not HASHSIM is run, ACCED now prompts for the following
reorganization parameters: foldtype (if relation not
optimized), linear probe depth, head table size, data page
size (DBACC_HASH relation only), and TMAX.
Note: Data page size must not exceed 2 KB unless the
physical tuple size is a power of 2. This
guarantees that no tuple will cross a data page
boundary which would violate the memory
protection mechanism.
ACCED first runs a conditional reorganization, that is, it
looks to see if enough memory exists in the ODD segment to
accommodate the reorganization. If enough memory exists, the
reorganization continues. If there is a memory shortage, a
warning message is displayed stating that ODD growth is
desirable, and ACCED asks if an unconditional reorganization
is desired. If so, a warning message is displayed stating
that unconditional reorganization may fail, and
reorganization continues. If reorganization succeeds, the
access dictionaries that are dumped represent the new access
dictionaries resulting from reorganization. If
reorganization fails, no reorganization is done, and the
access dictionaries that are dumped represent the access
dictionaries that would have resulted from reorganization had
it not failed. The access dictionaries are routed to the ROP
and SCCS if OM printing is on.
After an automatic reorganization failure, HASHSIM is used by
the craft to determine optimal parameter values to be used in
a manual reorganization of the relation. In this scheme, the
craft is prompted to provide information about the relation
to be simulated; such as the processor the relation resides
on and the name of the relation. A batch review is performed
to generate an American standard code for information
interchange (ASCII) data file. Then, a file is generated
that contains the folded keys of the relation. The newly
created folded key file, along with some additional access
dictionary information for the relation being simulated, will
be made available to the UNIX system ACCED process to run the
simulation. The additional access dictionary information
specified by the craft through prompts include the following:
(range of) maximum number of tuples (TMAX), (range of) data
page sizes (for access type DBACC_HASH only), foldtype
(nonoptimized relations only), and probe depth.
Simulator output will be sent to the craft via the terminal
or selectively to the ROP and will contain the following
information about each simulation executed:
o Tuple size used
o TMAX value used
o Data page size used
o Head page size required
o Number of data pages required for each stage in
multistage hashing
o TPAG value that was calculated
o Number of tuples that would end up in overflow
o Load factor
o Average search time that would exist if these values
were used in the manual reorganization of the relation
o Maximum search time that would exist if these values
were used in the manual reorganization of the relation
o A score based on all these results.
The craft would then evaluate those simulations having the
lowest scores to determine which parameters should be used in
the manual reorganization of the relation.
Manual reorganization is a process by which the craft, using
ACCED, can name a specific relation and attempt to reorganize
it any number of times.
ACCED has the same relationship with automatic reorganization
that ODBE does to recent change.
Caution: ACCED is an interactive tool which allows
investigation, reorganization, or destruction
of relations in the 5ESS switch data base.
There is an automatic reorganization program
which runs once a day to find and reorganize
hashed relations which have gotten
excessively into secondary overflow. When
the automatic reorganizing program cannot
resolve the overflow, it is necessary to use
ACCED to reduce the overflow. When ACCED is
used, it should be used by a person with
sufficient technical training and detailed
knowledge of the relational data base
structure. Any misuse could result in
premature exhaustion of the data base memory
area.
In manual reorganization, the craft can manually set rel_dsze
(data page size), rel_hsze (head page size), and rel_tmax
(maximum number of tuples) for a specific relation and try
any number of times to reorganize (refer to AT&T 235-105-220,
Corrective Maintenance Procedures). At times, it is useful
to use manual reorganization on relations that hash poorly
and cannot be reorganized easily.
An RC_OEINFO cannot be reorganized automatically; it must be
reorganized manually. The processor number must be ``193''
(in software releases 5E6 and later) when accessing RC_OEINFO
via ACCED.
Refer to AT&T 235-105-220, Corrective Maintenance Procedures,
for a detailed overview and procedures for performing a
manual reorganization of hashed relations via ACCED.
The CNIDBOC is a menu-driven interactive UNIX system process
which incorporates the Functional Listing, Recent Change
(RC), and disk verification and modification of individual
fields of RC structures. It is used by Common Network
Interface (CNI) applications for emergency purposes, such as
field troubleshooting or if the application's RC interface to
CNI becomes inoperable.
For 5E6 and later software releases, the CNIDBOC is accessed
from the TLWS or RC/V terminal by entering the following
input message:
rcv:menu:cnidboc
For 5E7 and later software release, the CNIDBOC also can be
accessed from the screen program (MCC Page 194) by entering
menu option ``c'' (Section .RM 3.11/, Screen Program User's
Guide).
AT&T 235-105-220, Corrective Maintenance Procedures, contains
additional information on CNIDBOC and procedures for its use.
Effective with the 5E9(1) software release, the Automated
Circuit Pact Return Tag tool allows a user to display and
print recent diagnostic faults and to interactively generate
the Returned Circuit Pack Tag used in returning defective
circuit packs to AT&T for repair.
The Automated Circuit Pack Return Tag tool can be invoked as
follows:
o From the UNIX system terminal, enter "/usr/bin/rtag;" at
the prompt.
o From the TLWS terminal, enter "RCV:MENU:RTAG;" at the
prompt.
o From the MCC terminal, enter poke command 194 to access
the screen program and then select option "r" RTAG.
Also, a user can enter command "RCV:MENU:SCREEN;" to
access the screen program. For detailed information
about poke command 194 and the screen program, refer to
Section .RM 3.11/ of this document.
Procedures for using the Automated Circuit Pack Return Tag
tool are documented in AT&T 235-105-220, Corrective
Maintenance Procedures.
This subsection contains information describing the
application of a group of tools that can be useful for
debugging and troubleshooting 5ESS switch software running on
the AT&T 3B20 Duplex (3B20D) Computer.
These tools offer a user the ability to view and change
application text and data residing in the computer's
processor, memory, and disks.
Information is given on the use of the following tools:
o BROWSE
o File System Debugger (FSDB)
o Generic Access Package (GRASP)
o Ring Generic Access Package (RGRASP)
o IBROWSE
o IDUMP (interactive dump utility)
o UPEDCUD [current update data base (CUD) and history file
editor].
Caution: The tools described in this subsection allow
changes to be made to low-level operations of
the AM. Improper use of these tools can be
service affecting. Before implementing any
of the functionabilities provided, consult
local supervision concerning policy. It is
recommended that the implementation of any of
these programs be discussed with the
technical assistance organization prior to
starting the procedure.
The browse program is a data base debugger which allows a
user to interactively peruse low-level access (LLA) data
bases, formatted output of user data, and LLA internal
structures. It is also used to:
o Verify data
o Find corrupted structures
o Gather information
o Repair damage.
The support computer versions of browse examine files in the
Software Demand Paging (SDP) address space format, files in
loadf format, and ordinary files. The AT&T 3B20D computer
version examines files in all of the previously mentioned
formats and incore copies of loadf and ordinary files.
Under the Bourne shell, the browse program is invoked by
entering:
browse [%][+-]name
where:
+ indicates name is an ordinary file.
- indicates name is a loadf file.
% indicates named ordinary file or loadf file resides
in core (AT&T 3B20D computer only).
If name is not preceded by a + or -, name is in SDP address
space format.
If % is used, name must have one of the following forms:
ecd pmdb <filename>,<index>,<segno> <segname>,<segno>
where:
ecd = ECD incore data base (segment name defined in
header file <init_btdb.h>).
pmdb = Plant measurement incore data base (segment
name defined in header file <init_btdb.h>).
filename = Segment names associated with the file system.
index = Segment names associated with the file system.
segname = A 32-bit number by which the system names
segment.
segno = Index of the segment in the virtual address
space.
The program has read only permission to the file, data base,
or segment.
Under the MML shell, the browse program is invoked by
entering:
RCV:MENU:DATA,BROWSE;
The browse program may be invoked from any craft terminal
except the MTTY or SCC.
Specification of a data base is the same as in the Bourne
shell but must be done via the browse command db (see Browse
subheading, Printing, Subsection .RM 3.17.2.5/). Table .AW TL/
summarizes the invocation modes.
Browse accepts commands from standard input as follows:
<expr><cmd><str>
An expression <expr> has the syntax shown as follows:
<expr> ::
<expr> <op> <expr>
| <constant>
| /<format> <values>/
| ?<format> <values>?
| ( <expr> )
<op> ::
+ | - | * | / | % | , | ;
<constant> ::
<decimal digits>
|0<octal digits>
|0x<hex digits>
|<char>
|.
|$
The operators and digit strings have their standard meanings.
Because printing, searching, and division share the slash
character, that character's use as an operator may require
enclosure in parentheses to avoid ambiguity.
A <char> is a C-language character representation as shown in
the following chart. Therefore, '8'-060-o prints 010 because
the value of character '8' is 070.
______________________________
| '\\0' | ' '| '@'| '_' |
| '\\01' | '!'| 'A'| 'a' |
| '\\02' | '"'| 'B'| 'b' |
| '\\03' | '#'| 'C'| 'c' |
| '\\04' | '$'| 'D'| 'd' |
| '\\05' | '%'| 'E'| 'e' |
| '\\06' | '&'| 'F'| 'f' |
| '\\07' | '\\'| 'G'| 'g' |
| '\\b' | '('| 'H'| 'h' |
| '\\t' | ')'| 'I'| 'i' |
| '\\n' | '*'| 'J'| 'j' |
| '\\013 | '+'| 'K'| 'k' |
| '\ | ','| 'L'| 'l' |
| '\\r' | '_'| 'M'| 'm' |
| '\\016'| '.'| 'N'| 'n' |
| '\\017'| '/'| 'O'| 'o' |
| '\\020'| '0'| 'P'| 'p' |
| '\\021'| '1'| 'Q'| 'q' |
| '\\022'| '2'| 'R'| 'r' |
| '\\023'| '3'| 'S'| 's' |
| '\\024'| '4'| 'T'| 't' |
| '\\025'| '5'| 'U'| 'u' |
| '\\026'| '6'| 'V'| 'v' |
| '\\027'| '7'| 'W'| 'w' |
| '\\030'| '8'| 'X'| 'x' |
| '\\031'| '9'| 'Y'| 'y' |
| '\\032'| ':'| 'Z'| 'z' |
| '\\033'| ';'| '['| '{' |
| '\\034'| '<''| '\\'| '|' |
| '\\035'| '='| ']'| '}' |
| '\\036'| '>'| '^'| '~' |
| '\\037'| '?'| '_'| '\\177'|
|_______|______|______|________|
An item enclosed in slashes (/) is the next address with
given values; an item enclosed in question marks (?) is the
previous address with the given values; wraparound applies to
searching in both directions. Therefore, /d 8/ locates the
next short integer, 8. The previous integer 8 is located
with ?d 8?. The value does not have to match the format: /d
010/ locates the next 8. The value can also be an
expression; for example, /d '8'-060/ also locates the next 8.
An empty <format><value> list refers to the list specified
previously.
The dot (.) is the current address; the dollar sign ($) is
the number of bytes in the file or address space. (Because
browse addressing is zero based, $-1 is the highest address.)
Evaluation is left-to-right, with the only precedence
established by parentheses. All computations are performed
with long operands.
A slash (/) following an expression prints data base
information at the address equal to the value of the
expression. The address formats following the slash control
printing and have the syntax shown as follows:
<aformat> ::
<item>
| <item> <aformat>
<item> ::
<term>
| <count> <term>
<term> ::
( <aformat> )
| [ <aformat> ]
| < <aformat> >
| { <aformat> }
| <byteformat>
| <memformat>
| <numformat>
| <specialformat>
| <userformat>
| "any characters"
<byteformat> ::
'a | 'c | 'd | 'o | 'u | 'x | b | c
<memformat> ::
.<C structure member identifier>
<numformat> ::
D | d | I | i | O | o | U | u | X | x
<specialformat> ::
A | B | C | H | L | Q | R | S | T | r | s
<userformat> ::
E | F | G | J | K | M | N | P | V | W | Y | Z
<count> ::
Positive decimal number
The format letters and grouping characters have the meanings
shown in Tables .AW TM/ and .AW TN/, respectively.
Format items enclosed in parentheses[( )] establish the scope
of a count. A count in front of an item is equivalent to
repeating that item the given number of times. For example,
2(DX3(bc)) is equivalent to DXbcbcbcDXbcbcbc.
Format items enclosed in square brackets ([ ]) indicate that
the item refers to an address offset from the start of the
current record. The square brackets are useful for display
of variable length data definition language (DDL) constructs
(vectors and strings), which are stored offset from the fixed
portion of a record.
Format items enclosed in corner brackets (< >) suppress the
printing of their corresponding values. For example, to
examine the first three characters of a 10-character array
and the following integer, use ./3c<7c>d.
Format items enclosed in braces ({ }) apply the format to the
address given by the value at the current address. Thus, /R
prints a record header at the current address; /{R} prints a
record header indirect from the current address.
The equal sign (=) prints in I format the current location
(that is, current address plus current offset). Therefore,
the command ./100(5X"\\n"=":\\t") prints 100 lines of
hexadecimal dump format, and each line is preceded by the
address of the first word on the line.
Nonreserved capital letters (those in <userformat>) may be
given definitions. For example, stating J DbbX defines a new
format J which prints a long decimal, two bytes, and a long
hexadecimal. The reserved format I is also settable. You
may examine ITEMIDs in decimal, octal, unsigned, or
hexadecimal by setting I to D, O, U, or X, respectively; the
initial format is hexadecimal. The I format also controls
current address printing, the i format, and ITEMID fields in
structures.
The format associated with K applies to the key portion of
the buckets of hash and btree access methods; the initial
format is nb, where n equals KEYMAX, the LLA #define constant
giving the maximum storage allowed for keys. If the K format
is empty, then the B and T formats print only the bucket and
node headers, respectively. In this instance, the T format
indents the headers to reflect the depth of each node in the
tree.
Arithmetic and character formats print individual bytes. The
formats d, 'o, and 'x print a byte in decimal, octal, and
hexadecimal, respectively. The b format prints a byte in the
last arithmetic byte format entered; the initial format is
octal. The formats 'a and 'c print a byte in ASCII mnemonic
form and C-language form, respectively. The ASCII mnemonics
are those established in the file /usr/pub/ascii. The c
format prints a byte in the last character format entered;
the initial format is ASCII mnemonic (see the following
chart).
___________________
| nul| sp| @| _ |
| soh| ! | A| a |
| stx| " | B| b |
| etx| # | C| c |
| eot| $ | D| d |
| enq| % | E| e |
| ack| & | F| f |
| bel| ' | G| g |
| bs | ( | H| h |
| ht | ) | I| i |
| nl | * | J| j |
| vt | + | K| k |
| np | , | L| l |
| cr | - | M| m |
| so | . | N| n |
| si | / | O| o |
| dle| 0 | P| p |
| dc1| 1 | Q| q |
| dc2| 2 | R| r |
| dc3| 3 | S| s |
| dc4| 4 | T| t |
| nak| 5 | U| u |
| syn| 6 | V| v |
| etb| 7 | W| w |
| can| 8 | X| x |
| em | 9 | Y| y |
| sub| : | Z| z |
| esc| ; | [| { |
| fs | < | \\| | |
| gs | = | ]| } |
| rs | > | ^| ~ |
| us | ? | _| del|
|____|____|___|_____|
Browse echoes literal text between double quotes ("). The
backslash (\\) affects the escape sequence shown in Table .AW TO/.
Browse prints strings with the s format using the same
conventions.
A slash (/) following an expression causes data base
information to print at the address equal to the value of the
expression. The formats following the slash control
printing.
Printing data base information depends on two automatically
calculated values: the current address and the current
offset. Each format item prints the information at its
target location, which is the current offset from the current
address. A slash following an expression establishes the
value of the expression as the current address and sets the
current offset to zero. Generally, each format letter
increments the current offset by the number of bytes it
prints (Table .AW TM/), and a carriage return alone increments the
current address by the current offset. The effect of these
computations is that stringing together format items prints
sequentially through the data base. An example formatted
printout is shown in Figure .AW G84/ which illustrates printing
seven items starting at address 100.
Browse prints the address followed by a colon (:) and then
the information from the data base in the indicated format.
The vertical lines in the diagram show the relationship
between format item and printed value. Pressing carriage
return again yields:
114: 692 11 xc1 b c d e
if the fields starting at 114 have values one more than their
corresponding fields starting at 100.
Four exceptions to the description of address calculations
are as follows:
o Linked structures buckets, rid blocks, queues/stacks,
and sets (formats B, L, Q, and S, respectively): In
these formats, the computation of the current offset is
made so that the next item printed is the next structure
on the linked list, not the next sequence of logically
contiguous bytes. If 044 is the address of the first
set, the command 044/3S prints the first three sets.
Use right recursive format definition for these formats.
If J is defined as SJ, the command 044/J prints all the
sets.
o Items in square brackets or braces: The items within
square brackets are used to calculate a new target
location offset from the current record by the value in
the target location. To get a current record, use R
format. The items within braces are used to calculate a
new target location at the address given the current
address itself. Printing begins at the new target
location obtained by the indirection. The altered
offset has effect only within the brackets or braces.
An item enclosed in brackets is treated as having length
sizeof(int); an item enclosed in braces has length
sizeof(ITEMID). Figure .AW G85/ is an example of a location
printed with R format. It indicates that the user area
of the record begins at address 100 in the data base.
The [2c] prints two characters at offset 10 (the value
at 104) from address 100 (the start of the record). The
format item X following the [2c] resumes printing at 106
as though the bracketed item were a simple integer
field. In this example, the command 100/{c}[2c]X4c is
equivalent to the consecutive commands 691/c and
104/[2c]X4c. The indirect formats are useful for
printing LLA vectors, which consist of fixed and
variable portions. The variable portions are located at
positions determined by the fixed portion.
o Btree access method (format T): The T format prints (in
depth-first order) the subtree with root at the current
address. The T format changes neither current address
nor current offset.
o Formats for symbolic record printing: If an r2a process
is started via the dd command, then at the address of a
record, the r format prints all record members and their
values. A dot (.) followed by a name prints only the
names and values of record members with matching names.
In either case, current address and offset are not
affected.
Browse commands take the following form:
<expr> <command> <parameters>
In the following list, default addresses are enclosed in
braces and are not part of the command.
< [name]
The < command causes browse to interpret a trailing
string as a filename from which input is accepted.
If the command itself appears in the named file,
browse places the new file on a stack and switches
input to the new file. An end of file (EOF) pops
the stack. A missing name causes a switch to
standard input.
> name
The > command interprets a trailing string as a
filename or a shell command to which standard
output is directed. If the trailing string starts
with an !, then it names a shell command;
otherwise, a file. The special name stderr
redirects output to stderr instead of to a file.
If the trailing string is omitted, output returns
to standard output. An interrupt redirects output
to standard output unless a previous redirection
was to stderr.
>> name
The >> command is the same as >, except that output
is appended to the file.
{.}/<formats>
The `` / '' command prints the locations in the
data base starting at the given address in the
given formats. Available formats are given in
Table .AW TM/ along with the number of bytes each
represents.
{.}#/<formats> <value list>/
The patch command substitutes the values in the
given list in the indicated formats for the values
at the given address. The value list is a space-
separated list of expressions, each of which must
correspond to a printing item in the format. The s
format patches a number of bytes equal to the
length of the string following the format. For a
patch, browse prints:
<addrs>: <old value list> <- <new value list>
The format letter controls message printing. The s
format patches a variable number of bytes and care
must be taken with its use.
{last}=<format>
An equal sign (=) between an expression and a
format controls expression value printing. The
format may be any letter in <pformat> except s. In
the character format, non-ASCII values are printed
in octal; ASCII characters are printed either as
C-language constants or as ASCII mnemonics
(depending on the last given 'a or 'c format). An
octal format forces a leading zero in the print; a
hexadecimal format, a leading 0x. Thus, 4+6*2=x
prints 0x14.
!<string>
Submits the string to the shell.
<cap> [string]
Capital letter commands associate the letter with
the trailing string. Appearances of the capital
letter in formats are replaced by the associated
string. The replacement is recursive; appearances
of defined capitals may appear in other capital
commands. Left or circular recursion in formats
leads to disaster. If the trailing string is
omitted, the current value of the macro letter is
reported; if the string is whitespace, the macro is
cleared.
db [name]
If a name follows the data base command, then
browse disconnects any currently attached data base
and attempts to attach the named data base with no
permission to patch.
If no string follows the db command, then the
currently attached data base name and its access
permissions are printed. [The code (#) indicates
permission to patch.]
dbp [name]
If a name follows the data base patch command, then
browse disconnects any currently attached data base
and attempts to attach the named data base with
permission to patch. If no name follows the dbp
command, then browse toggles the access permission
of the currently attached data base. In either
case, dbp reports the currently attached data base
and its access permissions.
dd [name][tabstops]
If a name follows the data dictionary command, then
browse starts the named dictionary process. This
process, which must be generated by record to ascii
program generator (r2agen), provides symbolic
information about records. With a data dictionary
process, the user may print entire records by
member name and value via the r format, print
single or related sets of record members with their
values via the .name format, and patch single
record members by name. The data dictionary
process also augments the R, S, and A formats by
including the record, set, and access method names,
respectively. The name may be followed with a
number, interpreted as the number of tab positions
after which to place values. This number is
helpful in formatting values in record prints. If
the dd command is not given a name, then it reports
the name and tab stop of the current process.
The data dictionary processes that are available
for use with the ECD and SG data bases are ecd-aux
and sg-aux, respectively.
files
Reports the stack of input files, most recent last.
frame size
Sets the frame size for the internal pager. For an
SDP address space, the frame size must be a
multiple of the page size with which the space was
generated.
g/<formats> <value list>/<command>
The global command searches the addresses in the
data base which have the given values and performs
the given command at those addresses. More than
one command may be given on succeeding lines if a
backslash terminates the previous line. The value
list is a space-separated list of expressions, each
of which must correspond to a printing item in the
format. The delimiting slashes may be uniformly
replaced by any other character except backslash.
For example,
g/X<4c>d 0x210 6/ .+8#/d 8/
looks for addresses that contain a long 0x210, any
four characters, and a short 6. It then patches
the 6 to an 8. Note that there are two printing
formats (X and d) and two values (0x210 and 6).
Because the values may be expressions, the 0x210 of
the previous example could be replaced by
(256*2)+16.
h
Reports the address of the LLA header structure.
help
Prints a summary of commands and formats.
macinfo
Reports the values of the user-settable format
letters.
q
Disconnects a currently attached data base and
exits. A q command is equivalent to an end of tape
(EOT) (control-d) when there are no files from a <
command on the input file stack.
r/<formats> <value list>/<command>
Given a trailing string composed of a format and a
list of values, the record command searches the
data base for the occurrence of values in a record
and executes the given command when a match is
found. The match is located at the beginning of
the record. Multiple commands may be given on
succeeding lines when the previous line ends in a
backslash. The formats and values are the same as
in the global search request. The default command
prints the RIDs of matching records; an empty
format/value list matches any record. Therefore,
the command "r /r" matches all records (the first
r) and prints (/) them symbolically (the second r).
The following error messages result from improper commands
and do not terminate the browse session. All other messages
are fatal and result from internal or other errors from which
there is no recovery (for example, inability to read a file
after a proper and successful open).
``bad alignment''
illegal data-type alignment (for example, int at odd address)
``bad byte format''
format letter following ' not a,c,d,o,u,x
``bad expression''
illegal expression construction (for example, missing operand)
``bad format''
illegal format (attempt to set I to other than D,O,U,X;
bad count field, attempt print from nonmacro letter)
``bad frame size''
frame size not a multiple of page size
``bad grouping''
(), [], <>, or {} not balanced
``bad id''
address negative
``<adrs> : bad id''
address out of bounds
``bad operand''
nonnumeric operand in expression
``bad recdisp information''
incorrect information from auxiliary process
``bad segment specification''
incorrect segment specified for incore attach
``bad string''
string does not begin with a "
``can't allocate frames''
frame size too large
``can't connect <name>''
data base <name> nonexistent or no permissions to <name>
``can't establish pipe''
cannot get pipe descriptor for ! command
``can't execute''
cannot execute named auxiliary process
``can't fork dd process''
fork failed before execution of auxiliary process
``can't fork''
cannot fork before execution of process named in ! command
``can't get segment''
getseg call failed on incore segment
``can't malloc space for search''
search command too complicated
``can't open file''
cannot connect to named file with +
``can't open input pipe''
cannot get pipe descriptor for <! command
``can't open input file''
trouble getting to command file for input
``can't read control structure''
cannot connect to file as a loadf file
``can't read control structure''
cannot connect to file as a loadf file
``can't read in get_c''
trouble with auxiliary process
``can't seek in data base''
file or loadf file corrupted
``can't seek to control structure''
bad loadf file
``dd process out of sync''
nonsense messages from auxiliary process
``id out of range''
address greater than file size
``improper value list''
value list in search or patch not of form /<formats><values>/
``line too long''
command line more than 80 characters
``lost out child''
a process spawned by the ! command has disappeared
``missing value list''
no values follow formats in search or patch command
``no closing <char>''
delimiters not balanced in search or patch command
``no data dictionary process''
the r format requires an auxiliary process
``no data base attached''
a command requires a data base for its completion
``no match''
search failed to find values
``no permission to patch''
patch command attempted before dbp command issued
``no remembered command''
!! given before !<command>
``no remembered search string''
// given before /<format> <value list>/
``non-C character constant''
a C-character constant not enclosed in single quotes (')
``read error after fork''
auxiliary process gives/sends bad initial information
``search unsuccessful''
search command failed to find values in data base
``<adrs> not bucket''
structure at <adrs> not a bucket
``<adrs> not a head''
structure at <adrs> not a dml header
``<adrs> not rec head, not indirect to one''
<adrs> not a RID
``<adrs> not a rid block header''
structure at <adrs> not a rid block
``<adrs> not queue or stack''
structure at <adrs> not an access method queue or stack
``<adrs> not set header''
structure at <adrs> not a set
``shared SDP not supported''
cannot connect with %<name>
``too many input files''
system limit reached on open input files
``unable to get segment code''
data base not associated with segment name
``unable to open <name> for getseg''
data base <name> nonexistent or no permissions to <name>
``unable to open output file <name>''
> or >> command unable to open or create file
``unbalanced patch delimiter''
delimiters on /<format> <value list>/ in patch command
not balanced
``unknown character format''
encountered byte format other than 'a,'c,'d,'o,'u,'x
``unknown enum name''
auxiliary process has incorrect enumeration name list
``unknown reply''
auxiliary process sends incorrect initial information
``unsupported member type for formatted patch''
patching with auxiliary process is restricted to the
following types: char, enum, int, link, long, owner,
short, string, unsigned
``wrong packet type in get_c''
bad communication from auxiliary process
``zero or negative record length''
bad communication from auxiliary process
Warning: The fsdb should NEVER be used on a mounted
file system unless absolutely necessary, and
it should not be used on any file system that
the user cannot afford to lose completely!
When modifying a mounted file system it is
necessary to modify BOTH the disk copy and
any related global data maintained by the
File Manager (FMGR). It is virtually
impossible to be CERTAIN that everything has
been modified correctly. Failure to
CORRECTLY modify BOTH the FMGR and the disk
copy of the file system may necessitate a
system reboot, a boot from backup, or a
complete Load Disk From Tape (LDFT)
procedure.
The fsdb command is a tool which provides a convenient means
of examining and correcting data within a file system,
special device type file, such as /dev/vtoc, or any file.
Contained in fsdb are conversions that translate block and
i-numbers into their corresponding disk addresses. Also
included are mnemonic offsets which are used to access
different parts of an i-node. These features simplify
correcting control block entries or descending the file
system tree.
The fsdb is normally invoked through the UNIX operating
system shell by specifying the command name, fsdb, followed
by the name of the file system or special device file to be
examined. For example, to examine the ``etc'' file system,
the command would be as follows:
fsdb /dev/etc <return>.
If the target for examination is a special device file such
as /dev/vtoc, fsdb must be invoked as follows:
fsdb /dev/vtoc - <return>.
Several error checking routines to verify i-node and block
addresses are contained in fsdb. These are disabled, if
necessary, by invoking fsdb with the optional ``-'' argument
or by using the 0 symbol. (The fsdb reads i-size entries
from the superblock of the file system in order to perform
these checks.) In the command for examination of a special
device file (see previous example), the ``-'' at the end of
the input string disables error checking. This is necessary
because vtoc is not a file system, so there is no superblock
for fsdb to read.
Numbers are considered decimal by default. Octal numbers
must be prefixed with a zero (0). Hexadecimal numbers must
be prefixed by either x or 0x and must be terminated with a
colon (:). During any assignment operation, numbers are
checked for a possible truncation error due to a size
mismatch between source and destination.
Since fsdb reads a block at a time, it handles both raw and
block I/O. A buffer routine retains commonly used blocks of
data and reduces the number of read system calls. Some
assignment operations result in a delayed write-through of
the corresponding block.
The symbols recognized by fsdb are as follows:
i Converts from i-number to i-node address.
b Converts to block address.
d Directory slot offset.
+,-,*,/ Address arithmetic.
q Quit.
>,< Saves, restores an address.
new-line Increments current address.
= Numerical assignment.
Note: This symbol must be entered
without spaces, and the assignment
must be terminated with a colon (:).
+= Incremental assignment.
-= Decremental assignment.
=" Character string assignment.
0 (zero) Error checking flip-flop.
p General print facilities.
f File print facility.
B Byte mode.
W Word mode.
S Half-word mode.
! Escapes to shell.
The print facilities generate a formatted output in various
styles. The current address is normalized to an appropriate
boundary before printing begins. It advances with the
printing and is left at the address of the last item printed.
To terminate the output at any time, use the delete
character. If a number follows the p symbol, that many
entries are printed. A check is made to detect block
overflows since logically sequential blocks are generally not
physically sequential. If a count of zero is used, all
entries to the end of the current block are printed. These
print options are available:
i Prints as i-nodes.
d Prints as directories.
o Prints as octal half-words.
e Prints as decimal words.
c Prints as ASCII characters.
b Prints as hexadecimal bytes.
h Prints as hexadecimal words.
The f symbol prints data blocks associated with the current
i-node. (Blocks are numbered starting with zero.) The
desired print option letter follows the block number, or the
f symbol. Checks are made for special devices and for
nonzero block pointers.
Dots, tabs, and spaces are used as function delimiters but
are not necessary. A line containing only a new-line
character increments the current address by the size of the
data type last printed. That is, the address is set to the
next byte, word, half-word, directory entry, or i-node,
allowing you to step through a region of a file system.
Information is printed in a format appropriate to the data
type. Bytes, words, and double words are displayed with the
hexadecimal address followed by the value in the hexadecimal
and decimal. The symbol '.B' or ' is appended to the
address for byte and half-word values, respectively.
Directories are printed as a directory slot offset followed
by the decimal i-number and the character representation of
the entry name. I-nodes are printed with the labeled fields
describing each element.
The following mnemonics are used for i-node examination and
refer to the current working i-node:
md Mode.
ln Link count.
uid User ID numbers.
gid Group ID number.
sz File size.
a# Data block numbers (0-7).
at Access time.
mt Modification time.
maj Device class number.
min Logical device ID number.
The following are examples of fsdb command use:
386i Prints i-number 386 in an i-node format.
This now becomes the current working i-
node.
ln=4 Changes the link count for the working
i-node to 4.
ln=+1 Increments the link count by 1.
falc Prints, in ASCII, block one of the file
associated with the working i-node.
a0b.p0x10:h Prints the first 16 words of the file in
hexadecimal for which a0 is the starting
block number.
2i.fd Prints the first 32 directory entries for
the root i-node of this file system.
d5i.fc Changes the current i-node to the i-node
associated with the fifth directory. The
first 512 bytes of the file are then
printed in ASCII.
1b.p0o Prints the superblock of this file system
in octal.
2i.a0b.d7=3 Changes the i-number for the seventh
directory slot in the root directory to
3. (This example shows how several
operations can be combined on one command
line.)
d7.nm="name" Changes the name field in the directory
slot to the given string. Quotes are
optional when used with nm if the first
character is alphabetic.
GRASP in the AT&T 3B20D computer is a single-user utility
system and is a subsystem of the software release of UNIX
Real-Time Reliable (RTR) operating system software. The
GRASP tools allow software maintenance personnel to observe
the behavior of UNIX RTR operating system software in an
operational environment. GRASP aids in the analysis of
software faults and is a means of observing the flow of
system software in order to isolate software bugs. It is
intended to be used to gather information on known problems
rather than to detect or correct problems.
GRASP is controlled by input from any maintenance terminal or
from the SCC. GRASP output appears on the ROP and on the
controlling (INPUT) terminal.
Caution: Although GRASP can be used by the craft, care
should be exercised. Improper use of GRASP
can result in program mutilation or excessive
utilization of system resources.
GRASP capabilities consist of the following:
o Data Transfer Functions: The COPY, DUMP, and LOAD
commands allow the user to move, print, and write data
to addressable system locations.
o Breakpoints: The WHEN command allows the user to
execute instruction and perform utility functions when
the program flow reaches or matches a specified
condition.
o Breakpoint Manipulation Commands: These commands allow
the GRASP user to create, enable, disable, view, and
remove breakpoints.
o Override Commands: These commands enable the user to
override GRASP default time limits.
o Trace: The primary function of the trace feature is to
indicate the flow of execution around a target event;
for example, branch instruction.
GRASP uses the UN615 dual access utility circuit (DUC) or the
UN21 utility circuit (UC) hardware to access the AT&T 3B20D
computer. Breakpoint functions appear the same with either
the DUC or UC.
If the DUC or UC is not installed in the AT&T 3B20D computer,
fails during use, or the Field Test Set (FTS) is installed,
GRASP clears all affected breakpoints and invalidates the
trace mechanism. All other GRASP features are still
available. In addition, GRASP rejects all new
breakpoint/trace definitions that would require DUC or UC.
Note: The FTS is a separate debugging processor that
can be connected to the DUC only. When the FTS
is connected, it appears to the computer that
the DUC is not installed.
When a working utility circuit is reinstalled, GRASP must be
notified of the change by the INIT:UC input message. After
receipt of this input message, GRASP again allows trace and
hardware breakpoint definitions.
In UNIX RTR Operating System, Release 6, the enhanced GRASP
(EGRASP) feature is available in the AT&T 3B20D computer.
This feature is provided as an alternative to the FTS for
real-time software debugging. EGRASP is a resident software
package that provides on-line real-time software debugging
capabilities. It supports an interface to the UN615 DUC to
provide all of the existing GRASP functions, in addition to
the new trace and matching functions. It also provides the
capability to place multiple breakpoints in code, to read and
write memory registers, and to dump the contents of memory.
All GRASP command examples given here are in Man Machine
Language (MML).
Table .AW TP/ lists the 5ESS switch input messages that move,
print, and with certain restrictions, write data into any
addressable location in the system. See the UNIX RTR
Operating System Input/Output Messages Manuals for details on
any specific input message and for system responses.
Breakpoints detect the existence of a set of specified
conditions on the machine. The definition of a breakpoint
has two parts: (1) description of conditions that are to be
matched and (2) list of actions (maximum of five action
clauses) to take place when the match occurs.
The WHEN command starts a list of GRASP commands that are
performed when a specified breakpoint condition exists.
The list must be terminated with the END:WHEN command which
is not counted as a part of the action list itself and does
not count against the limit of five action clauses. (In MML,
the complete list of WHEN commands is terminated with a
semicolon``;''. Individual clauses within the list are
terminated with an exclamation point ``!''.)
After a WHEN command, with its conditions and action list, is
entered successfully, the breakpoint is assigned a number by
GRASP. The breakpoint is then referred to exclusively by its
number. Up to twenty different breakpoints can be defined in
the system at any time. The numbers assigned to breakpoints
during a debugging session are not reused. However, the
RESET option to the CLR:UTIL command is used to restart the
breakpoint number at one after clearing the currently defined
breakpoints.
GRASP prints two output messages in response to a breakpoint
definition after the print follows (PF) is given. The first
message assigns a number to the breakpoint. This message
should appear soon after the PF. The second message confirms
that the breakpoint was set up successfully or indicates that
the breakpoint was aborted and gives the reason. This should
occur within one minute.
When a breakpoint fires, its action list is executed
sequentially. The INH:UTILFLAG ME command, if used, can be
anywhere in the work list without affecting the rest of the
actions being executed in the action list for that firing of
the breakpoint. A count of the number of times the
breakpoint has fired is kept. Each time the breakpoint
fires, FIRENUM increases by one. All output generated by the
action list is labeled with the breakpoint number and the
firing number as shown in the following example.
Breakpoint Definition
WHEN: UID=h'112, ADDR=h': W!
DUMP: REG=PA!
DUMP: ADDR=h'20130!
END: WHEN;
Output Produced When Breakpoint Fires
REPT GRASP BREAKPOINT FIRED
UTILID = h'112 PID = ________ BREAKPOINT = 1 FIRENUM =1
REGISTER: CONTENTS(h'):
PA: h'00005286
DUMP REG COMPL #G1
ADDRESS(h'): CONTENTS OF MEMORY(h'):
20130: 0000016A
DUMP ADDR h'20130 COMPL #G2
Breakpoints that fire on execution of an instruction are
called software breakpoints because of the way they are
implemented. The breakpoint itself is an instruction that
transfers control to GRASP when it is executed. See the UNIX
RTR Operating System Input Messages Manual, (303-082, MML)
WHEN:UID or WHEN:PID (Generic 2) for details. One exception
is when the action list contains any command that controls or
affects the transfer trace (see Transfer Trace in Section
.RM 3.17.4.7.2/). When the transfer trace is affected, the
breakpoint is implemented in hardware rather than software.
Starting the transfer trace is implemented in software for
execution (EXC) breakpoints.
Software breakpoints are set up [at the location specified by
the utility identification (UID) or process identification
(PID), and ADDR keywords of the WHEN command] as soon as
possible after the breakpoint is defined. The OPCODE itself
is not changed until the breakpoint is allowed.
Processes are described by the UID or PID and, in some cases,
a user process name. However, more than one process can be
active with the same UID and process name. When this
happens, GRASP sets up the first breakpoint in one of the
matching processes at random. If another breakpoint is
defined for the same UID or process name, GRASP sets up the
breakpoint in the same process as the first.
If a process on the machine does not match the described
conditions, the breakpoint is not set up. However, some
commands (listed in Table .AW TP/ and labeled ``immediate'') can be
used outside a breakpoint.
The OPC parameter is required on software breakpoints to
ensure that the user knows what he is doing. Severe problems
occur if a breakpoint is accidentally set up in the data
portion of an instruction.
When the breakpoint is set up, the second of the breakpoint
messages is actually printed. The message indicates either
that the breakpoint was set up successfully or, if
unsuccessful, the reason for its failure.
Because the breakpoint OPCODE is not placed until the
breakpoint is allowed, an inhibited software breakpoint does
not fire and does not use any machine resources.
Because of the way software breakpoints are implemented, the
breakpoint fires before the instruction where it is placed
executes. The instruction in the original text is saved
before it is overwritten by the breakpoint instruction. Only
after the breakpoint fires and the action list is executed,
is the displaced instruction executed. Execution then
resumes with the instruction following the displaced one.
For hardware implemented breakpoints, the breakpoint fires
after the instruction where it is placed executes.
Table .AW TQ/ summarizes the breakpoint implementation types (H -
hardware, S - software), which depend on two factors:
breakpoint mode (EXC - execution, R - read, W - write, or RW
- read write) and the presence or absence of trace commands
in the action list.
Breakpoints that fire on accesses of data are implemented
with hardware using matchers on either the UN21 UC, UN61 DUC,
or UN615 DUC. Hardware breakpoint functions appear, to the
user, to be identical with either the UC or DUC.
To set up a hardware breakpoint, GRASP configures the
matchers that are needed and supplies the values that are to
be matched. The circuitry continually compares the values
with what is taking place on the machine. If the breakpoint
is enabled, the breakpoint fires when all the matchers
specified during setup match. If a hardware breakpoint is
disabled, the hardware passively tries to match but does not
interrupt processing on the machine. Disabled hardware
breakpoints do not use any resources of the machine.
Because the amount of hardware on the utility circuit is
limited, a maximum of four hardware breakpoints can be
defined at one time. Because the trace also uses hardware
matchers, fewer breakpoints are available while a trace is
defined.
If the particular matchers needed are not available, it is
possible to have fewer than four hardware items defined but
have a command rejected for lack of resources. This is
generally true when using an address range. Only one matcher
on the utility circuit can be set up to match on a range of
addresses. A second command requesting an address range is
rejected even though a breakpoint using a single address is
accepted.
Following is a hardware breakpoint example and the resulting
system response. See the appropriate input or output message
in AT&T 235-600-700 or AT&T 235-600-750, Input Messages
Manual and Output Messages Manual, respectively, for specific
details.
Breakpoint Definition
WHEN:PID=65536, ADDR=h'A0000 - h'A00FF ;RW!
DUMP:REG=PA!
END: WHEN!
System Response
WHEN PID 65536 ADDR X'A0000 STARTED HARD 18 #G5
WHEN PID 65536 ADDR X'A0000 COMPL DISABLED 18 #G6
A breakpoint can be defined to fire upon receiving an active
external event backplane signal. This is implemented using a
hardware trigger and the DUC matcher. If the condition
matcher is already being used for a trace, a trigger
allocation error results if an attempt is made to define a
condition breakpoint.
The condition breakpoint fires immediately upon receipt of
the external event regardless of an executing process. The
processor can in fact be idle when this occurs. In this
event, any register copy and load commands inside the
breakpoint action list deal directly with the current machine
registers, which may be of limited value. If a process is
running when the breakpoint fires, register copy and loads
deal with the saved values of the interrupted process. This
feature would be most useful when some external analysis
equipment, such as a logic analyzer, triggers the event. The
breakpoint will continue to fire if not inhibited inside the
action list as long as the external event signal is active.
Following is a condition breakpoint example and the resulting
system response:
Breakpoint Definition
WHEN:COND=E!
DUMP:REG=PA!
INH:UTILFLAG=ME!
END:WHEN;
System Response
WHEN COND E STARTED HARD 1 #G5
WHEN COND E COMPL DISABLED 1 #G6
Breakpoints can be allowed or inhibited from firing,
their definitions can be cleared, and a summary of all
breakpoints can be printed. The commands to manipulate
breakpoints are given in Table .AW TR/. See the appropriate
input or output message in AT&T 235-600-700 or AT&T
235-600-750, Input Messages Manual and Output Messages
Manual, respectively, for details on any specific input
message and for system responses.
The input message, IN:DTIME, overrides the GRASP default
dynamic real-time limit. See the appropriate input or
output message in AT&T 235-600-700 or AT&T 235-600-750,
Input Messages Manual and Output Messages Manual,
respectively, for details on any specific input message
and for system responses.
If GRASP uses all of the time it is allowed according to
the value of the dynamic real-time limit, an output
message is printed indicating that all GRASP breakpoints
were inhibited. The breakpoints must be selectively
reallowed.
The output message REPT GRASP DYNAMIC RESET indicates
that a GRASP real-time limit override has expired and
has been reset to the normal installation default value.
GRASP supports a trace feature which permits the user to
record and view the flow of program execution on the machine.
The trace can be used in either of two ways: (1) to record
the events leading to a target event or (2) to record program
flow following a target event.
Note: The trace memory for the DUC is larger than the
memory for the UC. The UN615 DUC holds 8192
entries, the UN61 DUC holds 2048, but the UC
holds only 256 entries.
This section describes trace states and transitions,
discusses trace hardware issues, and gives details on trace
options.
States and Transitions
The five operations available to trace program flow and the
commands to implement these operations are shown in Table .AW TS/.
Any of these operations can be done as immediate operations.
Only the commands to start and stop the trace are allowed in
breakpoint action lists.
The trace can be in any one of the following states:
o Undefined
o New
o Running
o Stopped
o Dumped.
Before any trace command is executed, the trace state is
checked and the command is rejected if it is logically
incorrect for the trace state. The allowed transitions are
shown in Figure .AW G86/.
For trace commands in breakpoint action lists, only minimal
state checking is done when the breakpoint is defined. A
command to start the trace is rejected if the trace is
undefined. The full state check is done only at the time the
breakpoint fires and the action list is executed. Rejected
trace commands do not affect the rest of the action list
processing.
The trace operations fall into two classes, slow and fast,
according to the amount of data they move to or from the
utility circuit. The slow operations initialize the trace
and dump its memory. These operations currently take over 20
milliseconds and are performed at execution priority level 3.
The other operations are fast and add little time when used
in breakpoint action lists.
Hardware Issues
The trace is controlled by one of four utility circuit
triggers depending on trace type. As long as a trace is
defined, one of the utility circuit triggers is unavailable
for breakpoints. The trigger used is also the one that
allows a range of data addresses to be matched. When a trace
is defined, the range matcher is unavailable and vice versa.
This special trigger is marked with an asterisk in the output
from the OP:UTIL input command for easy identification.
Hardware implemented execution breakpoints differ from
software implemented execution breakpoints in one respect.
That is, the breakpoint action list for a software
implemented breakpoint is executed before the instruction
where the breakpoint is set up. For a hardware
implementation, the action list is executed after the
instruction. This should be kept in mind when defining the
breakpoint and interpreting its output.
Because only one matcher that traps the execution of an
address is available on the utility circuit, only one
execution breakpoint that controls the trace can be defined
at one time. Starting a trace from an execution (EXC) mode
breakpoint allows control of the transfer trace with two
execution breakpoints.
In summary, when a trace is defined:
o The data access range matcher is unavailable for
breakpoints.
o Only three data access breakpoints (at most) can be
defined depending on trace type (two if an execution
breakpoint controls the trace).
Trace Options
Several options are available to tailor the exact type of
information that is recorded in the trace memory. These
options are described in the following paragraphs.
UID Trace
With this type of trace, the output indicates every
process switch including those to the kernel and the
special processes. For more details on how to read the
trace output, see the Subsection .RM 3.17.4.7.4/,
Interpreting Trace Output Formats.
Because the trace memory is limited, the duration of the
trace is inversely proportional to the amount of detail
recorded. One way to get a long history of activity is
to restrict the trace to store only the UIDs of the
processes that run. This gives a good, long picture but
little resolution.
Transfer Trace
An alternate method (which is the default) is to store
the addresses involved in every nonsequential change in
execution flow. That is, for every branch, jump, call,
and return instruction, the address of the instruction
(or from address) and the destination (or to address)
are recorded. In addition, whenever a change in process
occurs, the new process UID is recorded so the to and
from address can be interpreted in context. This gives
more detail than the UID-only option.
Data History Trace
The data history mode allows recording of the program
data accesses. Each time a data access occurs, the
trace memory records the data, the data address, a
read/write flag, and the current program address. When
an address range is specified on the INIT:UMEM input
message, the block matcher is used and the trace only
records data when a memory location within the range is
accessed.
By using a UID comparator, the trace can be limited to a
unique process.
Simultaneous Data History and Transfer Trace
A simultaneous data history and transfer trace records
all data associated with a data history trace and a
transfer trace with the exception of a load or store
flag indicating data accesses. The data history and
transfer trace data are previously described. Each time
a nonsequential program instruction is fetched, the
UN615 DUC board receives a signal from the AT&T 3B20D
computer. When an address range is specified on the
INIT:UMEM input message, the block matcher is used and
the trace only records data when a read instruction, a
write instruction or a transfer occurs within the
address range.
Function Trace
The function trace memory mode records software function
changes. The AT&T 3B20D computer native instructions,
SAVE and RETURN, are set up using OPCODE matchers and
any other conditions established by the INIT:UMEM input
message. When a SAVE instruction is executed, the CALL
address (the previous program address), the SAVE
address, and the current UID value are recorded.
Execution of RETURN instruction allows trace memory to
record the RETURN address (the current program address),
the following program address, and the current UID
value.
When using an address range with function trace, the
range specified must be matchable with a DUC address
matcher. This is more restricted than UID, transfer,
data history, or simultaneous data history and transfer
traces (these traces use the block matcher and can
therefore match on any specified address range). In
order to use the address matcher for an address range,
the starting and ending addresses must be of a form
where the leftmost hex digits of both are equal, and the
rightmost digits of the starting address are all ``0''
and the rightmost digits of the ending address are ``F
'' (for example, 0x123000 - 0x123FFF or 0x10000 -
0x1FFFF). A function trace uses two triggers.
Function With Parameters Trace
The trace of functions with parameters records call
instruction address, save instruction address, and
parameters pushed on the stack. The stack address and
stack size may be specified with the INIT:UMEM input
message. If these values are not supplied, default
values will be used. Unlike the function trace, return
instructions will not be recorded. The ADDR key word
may not be used with function and parameter traces to
restrict the address range of function calls which are
recorded. This is due to the difficulty in resolving
which stack writes are due to function calls outside of
an address range which would not be recorded.
An address matcher is used to detect stack writes. If a
stack address and stack size are specified, they must
specify an address range as described in the previous
section. For example, the default stack address is
0x6A0000 and stack size is 0x1000. This specifies an
address range of 0x6A0000 through 0x6A0FFF. A function
with parameters trace uses two triggers.
Simultaneous Data History and Function With Parameter
Trace
The simultaneous trace of data and functions with
parameters trace records data history trace information
(with the exception of the read/write flag) and function
with parameter trace information. The data history and
function with parameters traces were described in
previous paragraphs.
As with the previous trace type, if a stack address and
range are specified, they must describe a range that can
be matched with an address matcher. In addition, if a
data history address range is specified, it too must be
of this form (for example, 0x2000 - 0x2FFF). This trace
uses three triggers.
UID Restriction
A trace can be restricted to trace only while a
particular process is running using the UID option. The
UID specified on the input message is the pcode of the
process to be traced. Any copy of the process with that
pcode is traced; and since the UID recorded whenever the
process changes includes the dct slot, multiple
incarnations of a pfile can be distinguished.
ADDR - Address Range Selection
The ADDR keyword limits program tracing to the access of
a specific word of memory or to a given range of
addresses. When a trace uses the block matcher, any
address range can be specified. This is the case for
UID, transfer, data history, and simultaneous data
history and transfer trace.
The function trace uses an address matcher to implement
the ADDR range. This is more restricted and is
described in the function trace section. The ADDR
keyword is not implemented for function with parameter
traces. For simultaneous data history and function with
parameter traces, the ADDR keyword uses an address
matcher to specify the data history address range.
Stop When Full Versus Circular
The trace can be set up either to automatically stop
tracing when the memory fills up or to trace
indefinitely, always replacing the old data with the
new. This pair of options is used to set up the various
scenarios of tracing as described in the next section.
The options are independent of the type of data stored.
If the STOP FULL option is chosen, an output message is
printed indicating that the trace stopped for that
reason.
Stop Trace on Condition
The COND keyword may be specified along with any
combination of E, M, and S to stop a running trace if
one of the following conditions occurs:
E: Stop the trace if an external event occurs.
This is triggered by the external event
backplane signal on the DUC board.
S: Stop the trace if a hardware stop-and-switch
occurs.
M: Stop the trace if a hardware maintenance reset
function occurs.
The condition matcher uses another trigger for trace.
The following paragraphs describe the most common trace
scenarios. The trace input messages and associated output
messages are shown in the Table .AW TT/.
See the appropriate input or output message in AT&T
235-600-700 or AT&T 235-600-750, Input Messages Manual and
Output Messages Manual, respectively, for details on any
specific input message and for system responses.
Before Trace
To record the sequence of execution that precedes a known
event, do the following:
1. Decide what type of trace to use. There are seven trace
types:
o UID Trace
o Transfer Trace
o Data History Trace
o Simultaneous Data History and Transfer Trace
o Function Trace
o Function With Parameters Trace
o Simultaneous Data History and Function With
Parameter Trace.
2. Decide whether to restrict the trace to a particular UID
or PID or to allow all processes to be traced. These
decisions depend on the scope of the problem being
debugged (system wide versus internal to a process) and
the length of history needed.
3. Start the trace in the circular mode and define a
breakpoint to trap the target event and stop the trace.
When the breakpoint fires and the trace stops, the
history leading up to the event will be in the trace
memory.
After Trace
To see the sequence of execution that occurs after a target
event, do the following:
1. Decide what type of trace to use. There are seven trace
types:
o UID Trace
o Transfer Trace
o Data History Trace
o Simultaneous Data History and Transfer Trace
o Function Trace
o Function With Parameters Trace
o Simultaneous Data History and Function With
Parameter Trace.
2. Decide whether to restrict the trace to a particular UID
or PID or to allow all processes to be traced. Another
option is to restrict the trace to a particular PID.
3. Configure the trace to stop when trace memory is full.
4. Define a breakpoint to trap the target event and start
the trace.
Between Trace
A trace can be set up to record data between two target
events (up to the memory limit of the utility circuit
installed). The breakpoint used to trap one target event
starts the trace and another breakpoint defined for the other
event stops the trace. To record this information, do the
following:
o Use the STOP FULL option on the INIT command to indicate
whether any data gets lost because of the finite size of
the trace memory. The data lost, if any, is the new
data. If the new data is needed, repeat the trace in
the CIRCULAR mode. In the circular mode, the old data
is lost, preserving the new data.
o Use the UID option to restrict the trace to those
processes from a particular pfile or the PID option to
restrict the trace to a particular process incarnation.
o Because of utility circuit hardware restrictions, choose
the two breakpoints carefully.
o An execution breakpoint that starts the trace is
implemented in software.
UID and Transfer Output Formats
The trace memory dumped by the OP:UMEM command is printed in
order, oldest to newest, row by row. Every entry is one of
three types as follows:
o utility id marked with U,
o from address marked with F,
o or to address marked with T.
The utility id entries are 24-bit hexadecimal numbers that
are presented in the format shown as follows. The rightmost
12 bits (3 hexadecimal digits) are the process pcode. The
leftmost 8 bits (2 hexadecimal digits) are the dct slot. The
remaining hexadecimal digit is unused.
23 16 15 12 11 0
__________________________________
| | | |
| | | |
| | | |
|__________|________|______________|
dct slot unused pcode
(8) (4) (12)
Utility id Print Format
A process identification (pid) consists of a dct slot or
index (of which the higher order byte is always zero) and an
incarnation count as shown as follows.
31 16 15 870
___________________________________
| | | |
| | | |
| | | |
|________________|________|_________|
incarnation dct slot
count (16)
(16)
Process id
An easy correspondence can be made between the trace UID
entries and the pids if the pids are expressed in
hexadecimal. In kernel processes, the
OP:STATUS:PROCESS, ALLKERNS;
command prints out the dct slot directly; however, it is in
decimal and must be converted.
The address entries are all virtual addresses within the
process indicated by the most recent preceding UID entry in
the trace memory. Any from address is the address of a
branch, jump, call, or return instruction that was executed.
The following to address is the address to which control
transferred. Occasionally two to addresses will be recorded
adjacent to each other. This implies that the first to
address itself caused a transfer of control (not an uncommon
occurrence in compiler generated code). Between any to, from
pair, the code was executed without branching.
Note: Although the disassembler decodes the a1 OPCODE
as a 4-byte return instruction, the microcode
(and hence the trace output) treats it
differently. The a1 is really a 2-byte no-op
instruction. The actual return instruction is
the 2-byte 7b instruction. As a result, the
from address recorded for a return will be the
address of the 7b -- 2 bytes beyond the return
indicated in the disassembly listing.
Typically with the UN21 utility circuit, several to and from
addresses precede the first UID entry in a transfer trace.
If it is important to know (but not obvious) what process
they belong to, rerun the same trace scenario with the STORE
UID option on the INIT:UMEM command. Working backwards from
the end of the two dumps, UID entries can be matched to
determine the UID of the early transfers in the first trace.
Data History Trace Format
The data history trace records the program address at which a
specified address is being accessed, the data address, a read
or write flag, and the data value. The format for this trace
is displayed in the following example.
DATA HISTORY TRACE
PROGRAM DATA
ADDRESS ADDRESS DATA
000076 3c0034 <- 00000004
00005e 3c0034 -> 00000004
00007c 3c0034 -> 00000004
000090 020068 <- 61000000
The leftmost column contains the program address accessing a
specified memory address or address within a specified range
of memory addresses. The center column contains the data
address, and the rightmost column contains the data value. A
read operation on the data address is indicated by a right
arrow -> and a write operation by a left arrow <-.
Function Trace Format
The function trace records calls and returns, the address
branched to, and the utility ID. A sample of the output is
as follows.
FUNCTION TRACE
CALL OR SAVE OR
RETURN ADD. RETURN-TO ADDR. UID
0000a8 call 000248 00000900c0
000272 call 000420 00000900c0
000260 reto 000276 00000900c0
000300 reto 0000ac 00000900c0
Output lines contain keywords, call or reto, in the second
column to indicate a call or return. Calls and their
respective returns are indented equal amounts to reflect
nesting. For calls, the first column contains the address of
the call instruction. The third column contains the save
address branched to. For returns, the first column contains
the address of the return instruction, and the third column
lists the program address being branched to. The fourth
column contains the utility ID for both calls and returns.
Simultaneous Transfer Trace and Data History Format
This trace records transfer trace and data history trace. A
sample of the output is given as follows.
SIMULTANEOUS TRANSFER AND DATA HISTORY TRACE
PROG ADD DATA ADD DATA VALUE
FROM-ADD goto TO-ADD UID
000026 020010 ? 61000000
00002e 020011 ? 00620000
.
.
.
00029a goto 00029c u=0x17d (282fa0)
000029e 6a0190 ? 000001a6
The indented output represents data history. The lines not
indented represent program transfer trace data. The left
column of the program trace is the from program address. The
middle column is the to program address, and the right column
is the uid of the to address. The data history's left column
is the program address. The middle column is the data
address, and the right column is the data. With the
simultaneous transfer and data history trace, it is not
possible to know whether the data history trace is a read or
a write, thus a question mark is inserted in data history
trace output.
Function With Parameter Trace Format
The function with parameter trace records function calls and
full-word data write accesses on the process stack. A sample
of the output follows.
FUNCTION TRACE WITH PARAMETERS PASSED
CALL ADD SAVE ADD PARAMETERS/AUTOMATICS
000120 0002d4 (0x00000019)
0001a0 000258 (0x0000000a,0x00000020,
0x00000000,0x00000002)
000280 0002a0 ?(0x0000000,0x00000002)
The left column provides the program address of the call
instruction. The next column contains the save instruction
address. The remaining one or more columns enclosed within
parentheses contain the parameter(s) pushed; where the last
parameter pushed appears first in the list. The automatics
from the previous function may also appear with the
parameters. When it is unclear which parameters were pushed
on the stack, a ``?'' precedes the left parenthesis.
Simultaneous Data History and Function Trace Format
This trace records the data history and function trace. A
sample of the output is given as follows.
SIMULTANEOUS DATA HISTORY AND FUNCTION TRACE FORMAT
PROG ADD DATA ADD DATA VALUE (data history)
CALL ADD SAVE ADD PARAMETERS/AUTOMATICS (function)
0000a4 0001d8 ?(0x00000005,0x00000045)
000d0 0001a8 ?(0x00000002,0x00000063)
000112 020038 ? 0x00000045
00011c 02003c ? 0x61000000
000126 020040 ? 0x00034567
The indented output is the function call with its parameters.
Among these parameters, the automatics from the previous
function may also appear. The left column is the call
instruction address. The next column is the save instruction
address. The next column is the parameter pushed, and the
rightmost column is an automatic from the previous function.
The unindented output is the data history for the data range
specified. The left column is the program address. The
middle column is the data address, and the right column is
the data value. The left arrow, <-, means that the data was
written. The right arrow, ->, means that the data was read.
Table .AW TU/ lists information about the UNIX RTR operating system
processes.
RGRASP, a troubleshooting tool with an MML interface , is a
single-user utility system for the Common Network Interface
(CNI) ring nodes. The user interface is based on the GRASP
tool found in the AM. However, several major differences
exist, and the user should be familiar with RGRASP
capabilities before using the tool.
No new hardware is required for the RGRASP tool.
Caution: Although RGRASP can be used by the craft,
care should be exercised. Improper use of
RGRASP can result in program mutilation or
excessive utilization of system resources,
both of which can lead to call processing
down time.
The current implementation consists of four processes; three
in the AM and the fourth (monitor) in the DLN AP. The four
processes are as follows:
o RGP_KER: This is a UNIX system process kernel for the
feature. It acts as the interface between the AM
(RGP_CFT and RGP_PRT) and the ring node (monitor)
processes. This process has to be killed-off in order
to install the new version if it is updated via software
update procedures.
o RGP_CFT: This is a UNIX system process called to handle
input messages from the craft shell. It parses and
performs some preliminary checks on the input command
and then relays it to the RGP_KER process for further
processing.
o RGP_PRT: This is a UNIX system process that handles
printing of output. Message class SWM01 is used for the
output.
o Monitor: This is a system process that performs the
actual operations required to handle breakpoints, memory
dumping, and memory loading. It communicates with the
RGP_KER process.
RGRASP capabilities consist of the following:
o READ memory in a ring node with the DUMP:RUTIL command.
o WRITE memory in a ring node with the LOAD:RUTIL command.
o Perform actions on breakpoints in ring node memory as
follows:
-- Set breakpoints in ring node memory with the
WHEN:RUTIL command.
-- Determine status of breakpoints with the OP:RUTIL
and OP:RUTILFLAG commands.
-- Temporarily disable breakpoints with the INH:RUTIL
and INH:RUTILFLAG commands.
-- Completely remove breakpoints with the CLR:RUTIL
and CLR:RUTILFLAG commands.
-- Enable/allow breakpoints with the ALW:RUTIL and
ALW:RUTILFLAG commands.
For detailed explanations, refer to AT&T 235-600-700, Input
Messages Manual and AT&T 235-600-750, Output Messages Manual.
Initial Setup
Determine the address in memory that requires investigation
by using the latest PR/PK listings provided. In other cases,
these addresses may be provided by a field support
organization.
Determine which processor will be looked at (the DLN has an
active and a standby processor). Use command OP:SLK or poke
MCC Page 118 to determine this.
Setting Breakpoints
As a precaution, set breakpoints in only one processor at a
time.
Before setting a breakpoint in a program, the opcode code
(OPC) must be known. Verify the OPC by using the DUMP:RUTIL
command to dump the memory at the breakpoint address. If the
expected OPC does not match the dump output, then the
listings don't match the memory. At this point, don't go any
further until the discrepancy is resolved.
One possible explanation for the discrepancy is that the node
software is out of date. To eliminate this possibility,
remove and restore the target node (node to be breakpointed)
to make sure that the newest version of the code has been
pumped from the disk. Use the RMV:LN and RST:LN commands or
MCC Page 118 pokes to achieve this. After the node has been
pumped, try dumping the breakpoint address again. If it
doesn't match up now, the listing is out of date. In this
case, stop and get a current listing before proceeding.
To set a breakpoint at address h'XXXXXX which has an opcode
of h'YYYY, use the following command:
< WHEN:RUTIL=32-2,AP,ADDR=h'XXXXXX,OPC=h'YYYY;
After the command is entered, the user is prompted for the
action list. It is best to use the most current WHEN:RUTIL
manual page to see all the possible actions. A single
breakpoint may execute up to 25 commands in its action list
when hit.
Only 25 action list commands are possible in any one
processor. For example, if one breakpoint contained 15
action list commands, then only 10 more action list commands
are available for other breakpoints in the same processor.
The action list must be terminated by the WHEN:END command.
As with GRASP, there need not be any commands in the action
list except WHEN:END. It may be useful to know whether or
not a piece of code was being executed.
Initially all breakpoints are inhibited. Use the ALW:RUTIL
command to allow all breakpoints in a given ring node or the
ALW:RUTILFLAG to allow an individual breakpoint.
Only five breakpoints can be set in any one ring node
processor.
Loading memory may drastically change program execution. If
memory is not correctly loaded, it can interrupt or degrade
service (for example, lose calls).
The RGRASP tool has write permission to all parts of
available memory. This makes the tool very powerful but also
dangerous. Since OPC checking is not performed, it is
possible to type in the wrong address and overwrite good data
with bad data. If this should occur and the original
contents cannot be loaded, the ring node should be removed
and restored (pumped) to get back an original disk copy. Use
the RMV:LN and RST:LN commands to remove and restore data.
After a load, use the DUMP:RUTIL to verify the new contents
in memory.
Registers can only be loaded during breakpoint action lists.
Dumping memory is a fairly straight forward and safe
operation. All that is required is the address to dump. The
current implementation allows 468 bytes of hexadecimal output
to be dumped in one operation with the DUMP:RUTIL command. A
user may dump memory either higher or lower than the starting
address, or a range of addresses may be specified.
Registers can only be read during breakpoint action lists.
Ibrowse is an interactive tool that examines files containing
a dump of UNIX RTR operating system physical memory. On the
AT&T 3B20D computer, this file is usually /dev/pmem for the
currently running processes, or /dev/ofln for the contents of
the off-line memory. Locations in the address space of any
process in memory can be displayed. Ibrowse also provides
facilities for examining core dump files, as well as
primitives to display ordinary unstructured files. These
types of operation allow the use of Ibrowse as an on-line
debugging aid as well as a static debugger.
To execute Ibrowse, enter the command:
ibrowse [file]
File should contain the contents of physical memory.
Following is a listing of Ibrowse commands:
buf Turns on internal memory management
(default).
db file Examines the contents of file.
null n Sets value for termination of indirect
formats (initially 0).
pn n Treats subsequent addresses from the
perspective of process n.
pn k Switches to kernel's address space.
pn p Uses physical addressing - no virtual
address translation is performed. This
mode is also used for examining unstructured files.
pn c Treats currently attached file as a core
dump file.
pn Displays current process.
sup Switches to supervisor address space.
sym pfile Uses the symbols from pfile to allow
symbolic addressing.
user Switches to user address space.
vtop n Converts virtual address to physical.
The db command informs Ibrowse of the file containing the
physical memory spectrum. For example, db /dev/pmem causes
Ibrowse to reference the physical memory driver for
subsequent requests. Entering this command is equivalent to
invoking ibrowse with the name of the physical memory file as
its argument.
The db command without an argument causes Ibrowse to name the
current physical memory file.
After a physical memory file is specified, Ibrowse can then
display virtual addresses. Initially, these addresses are
interpreted within the kernel's address space. A command for
changing to the address space of any process in memory is
described as follows.
Display commands in Ibrowse are of the form:
addr/format
Address can be a number, arithmetic expression, search
string, or variable name enclosed in quotes (for example,
``buffer''+30 is a legal address).
If the `` / '' in a display command is replaced by `` = '',
Ibrowse evaluates an arbitrary arithmetic expression to
determine an address. The address is then printed, rather
than its contents. This allows Ibrowse to be used as a
calculator. The command:
([3+5]/[2*1])*8=X
displays the result of the calculation in hexadecimal (0x20).
A format consists of a concatenation of the following
symbols:
a Name of variable at address.
b Byte.
c Character.
'd, d, D Decimal of 1, 2, and 4 bytes,
respectively.
'o. o. O Octal of 1, 2, and 4 bytes, respectively.
s Null terminated string.
'u, u, U Unsigned decimal of 1, 2, and 4 bytes,
respectively.
'x, x, X Hexadecimal of 1, 2, and 4 bytes,
respectively.
In addition, any format descriptor preceded by a number
causes that descriptor to be used the specified number of
times. For example, transfer vectors are stored at virtual
address 0x760000 in the kernel. The command:
0x760000/10X
displays the first ten entries in this segment as long
hexadecimal numbers.
Segment descriptor entries (SDE) reside at address 0x1a000 in
the kernel. The command:
0x1a0000/XX'd'ddddd'd'dXXX
displays the fields of the first sde structure in this
segment.
Internally, Ibrowse supports three concepts useful in
displaying structured data:
o A current address
o A next address
o A current format.
After a display command, the current address (available as
``.'' in address calculations) is set to the first address
displayed (0x1a0000 in the example). The next address is set
to the first address following the last item displayed
(0x1a0020). The current format is set to the format used in
the display. Successive carriage returns after a display
cause Ibrowse to use the current format to display the
information starting at the next address. Therefore, similar
structures stored in consecutive memory locations are easily
displayed.
The formats commonly used to display data from memory have
been described previously. For each format, Ibrowse prints
one value for each format entry using a tab separator.
Additional format components that allow a more structured
display are shown in Table .AW TV/.
Ibrowse initially interprets addresses as references to the
kernel's address space. The command:
pn N
references the address space of process N for successive
displays. The command:
pn k
returns to kernel space, while:
pn
reminds the user of the current address space.
Ibrowse also directly addresses physical memory. The command:
pn p
enters physical addressing.
All UNIX system processes run at the supervision level, and
the sup and user commands are excluded.
To peruse core dump files with Ibrowse, enter the command:
pn c
This command treats the currently attached file as a
formatted core dump. The data, text, stack, etc., of the
late process may then be accessed with virtual addresses as
though the process were still in memory.
A virtual address may be converted to the physical address by
entering the command:
vtop N
This returns the physical address corresponding to the
virtual address N.
Ibrowse searches forward or backward for a particular
sequence of values in the current address space. The search
pattern consists of two parts: a format and a sequence of
values. Ibrowse uses each format letter to determine the
size of the corresponding value in the value list. For
example, when the following pattern is specified:
/2X2x 1 2 3 4/
Ibrowse scans forward in the current address space searching
for a sequence of 12 bytes containing a long 1, long 2, short
3, and short 4, respectively. The same sequence enclosed in
question marks causes Ibrowse to search backwards for the
sequence. (Note that the values still appear in ascending
memory locations.)
When in virtual addressing mode, Ibrowse limits its searches
to the current segment. Therefore, if the current address is
x760008, a forward search examines locations x760008 to
x780000 first, followed by locations x760000 to x760008. In
physical addressing, the entire range of the physical memory
file is examined.
The command:
sym [pfile]
reads the symbol table of the pfile. Functions and external
variables maybe subsequently referenced by name. The symbol
section of the pfile must be swabbed correctly; otherwise,
Ibrowse will report ``symbol not found''.
For example, consider checking the file manager's tasks. The
information needed, located in the tasktab array, consists of
four word entries. The following commands display the first
eight entries in the table:
pn 4 /* enter fmgr's address
space */
sym /bootfiles/fmprc /* attach to current file
manager. */
* (it may be necessary to run
* 3bswab to examine the symbols
* on the 3b) */
``tasktab''/8(4X=) /* quoted string causes symbol
lookup */
To find the virtual address of the i-node table, enter:
``i-nodes''=X
Occasionally, it is useful to convert a virtual address into
a symbolic name (for example, looking up a program address).
Ibrowse provides a special format (a) for this translation.
If, for example, the address of the i-nodes previous array
was x1000, the command:
x1010=a
prints the string ``i-nodes+16'' (the offset is always
decimal).
To avoid excessive reads of the current file, Ibrowse
maintains a cache of recently accessed memory areas. To
adjust the size of pages used for this memory management
(initially 512 bytes), use the command:
framesize n
To disable buffering completely, use the command:
nobuf
The nobuf command is useful when examining volatile locations
on a running machine. To restore buffering to its initial
512-byte frame size, use the command:
buf
Ibrowse overwrites contiguous memory locations with a set of
values. At present, however, the physical memory driver
(/dev/pmem) does not support writing, so the feature may be
unusable on a running AT&T 3B20D computer. If the driver is
changed to allow writes, or if there is reason to modify an
off-line dump, patching is straightforward.
The core file must be reattached with permission to patch by
entering the command:
dbp [file]
Modifications then take the form:
addr#``format value1 value2 ...''
The supplied values are written in memory beginning at the
addressed location. As with searches, the format determines
the size of each supplied value. As a result, 3X is
equivalent to 3D or DXD, etc.; each value in the value list
determines its own radix. For example, to replace three
transfer vectors beginning at location 760010 with 120, 130
and 140, the patch command is:
x760010#``3X 120 130 140''
When a line begins with an exclamation point (!), Ibrowse
invokes the shell for the remainder of the line.
The q command terminates Ibrowse.
Ibrowse stores some formats as macros. Macro names are drawn
from the set of capital letters unused by Ibrowse (Ibrowse
uses D, I, U, O, and X at present). A macro is defined by
entering the letter, a space, and the desired format string.
Entering the letter alone gives the current definition of the
macro (if any). The following examples clarify both the use
of macros and the additional format facilities.
Example 1
The command:
P 5(4X=)
defines a macro P which prints 20 hexadecimal longs, four to
a line. Each line is preceded by the address of the first
word on the line. (The ``='' issues a newline, then prints
the address.) The macro P is then used in formats in the same
way as any predefined letter.
The command:
x76000/2P
prints the first forty transfer vectors.
Example 2
Macros can be recursive. A recursive macro is useful when
used in conjunction with the indirect addressing capability
of the curly braces. If a program has a binary tree
consisting of the following structures:
struct btree
{
char title[40] ;
struct btree *left ;
struct btree *right ;
}
the macro:
B 40c{B}{B}
effects a preorder traversal of the tree. An in-order
traversal of the same tree is accomplished with the [mark]
and [skip] feature:
B [40]{B}[ka][-44]s['a]{B}
This macro skips the character string, displays the left
subtree, marks where it is (ready to print the right
subtree), jumps back to the start of the title, displays it
as a string, and finally jumps back and displays the right
subtree.
Note: Use the null command note to set the termination
criteria for an empty child if it is other than
the default zero.
Example 3
On the AT&T 3B20D computer, a stack entry has the following
format:
struct stack
{
int args[NARGS]; /* arguments to function -
variable number. */
int ret_addr; /* return address. */
int *oargp; /* old argument pointer */
int *ofp ; /* old frame pointer -
points to caller's local
* data.
*/
int save[10] /* 10 words of save
information */
int locals[NLOC] /* local variables for
function. */
}
Given the address of the top (that is, most recent) stack
entry's local variables, a macro to format a stack trace is
defined as:
S [-52]=a{XX}{S}
This macro skips back to the parent's return address, prints
the current location and the function's name (=a), prints the
first two arguments ({XX}), and recurses ({S}). The current
program address is not on the stack and must be obtained from
the save state in the processes' pcb.
Example 4
The structure:
struct xyzzy
{
long good ;
char dull [2000] ;
long better ;
}
can be viewed with the macro:
Z "good "D<2000c>"better "D
The resulting output lines have the following form:
good (goodva11) better (betterva11)
good (goodva12) better (betterva12)
. . . .
. . . .
. . . .
Ibrowse redirects I/O to or from a file.
The command:
> [file]
directs subsequent output to the named file. If file is not
specified, stdout is used. Redirection is terminated by an
interrupt or a line containing only a ``>''.
The command:
>> file
appends to an existing file.
The command:
< [file]
takes a set of commands from the specified file (or stdin if
no file is specified). The <[file] command is useful when
reading in a file of predefined macros.
File can be replaced with a shell escape to allow redirection
to or from a command. For example,
> !fgrep ffffffff
0/50(4X=)
> /* terminate redirection */
locates the -1's in the first 400 words.
The idump is a tool which allows a user to dump parts of
common object format files for interactive examination of
their contents. It can be used for:
o A.out files (the output of the AT&T 3B20D linkage
editor, 3bld)
o Pfiles and shared libraries (the output of the AT&T
3B20D linkage edit process, 3bldp)
o Minimal files (the output of file extraction, fextract)
o Update files (the output of overwrite generator, ogen)
o Simple object files (the output of the AT&T 3B20D C-
language compiler, 3bcc).
Idump also permits the examination of multiple object files
by specifying on the command line either a list of files or
an archive that contains object file members.
Under the Bourne shell, idump is invoked by entering the command:
idump [file...]
Table .AW TW/ provides a listing of the idump commands and their
output.
An example of the use of the idump m command is as follows:
m g -- Open the next object file in argument list and
dump the file header.
If the m is used alone, explanations for all the commands
available in idump are listed.
The idump returns an exit code of zero. If an interrupt
signal is received, idump returns to its command mode.
Note: Normally, idump is used in the interactive mode.
Idump should NOT be executed through the craft
shell except as described as follows.
Idump may be executed via the craft shell by using the
EXC:ENVIR:UPROC command. Special steps must be taken with
UNIX system commands, however, to make interactive
communications with the user possible.
One method that can be used to execute an interactive
command, such as idump, via the craft shell is shown in the
following example:
<INPUT>
EXC:ENVIR:UPROC,FN="/bin/sh",ARGS("-c","/usr/bin/idump /bin/date<<!<lf>
t main<lf>
q<lf>
!")<CR>
PF
<OUTPUT>
<
M EXC ENVIR UPROC /tmp/dumper COMPLETED
CURRENT FILE: /bin/date Sat Sep 8 02:27:49 1984
F_AR32W F_LSYMS F_LNNO F_EXEC F_RELFLG
Magic Nscns Time/Date Symptr Nsyms Opthdr
Flags
00550 17 0x1ba016f5 0x00002800 549 0x0fec
0x020f
:
Symndx Name Value Scnum Type Sclass Numaux
[ 16] main 0x00000048 1 ()INT EXT 1
s/u/e tag=0 fcn size=0x788 lptr=0x0 endx=22 tv=0
:
In the previous example, the Bourne shell (UNIX operating
system shell) is called to execute by the
EXC:ENVIR:UPROC,FN="/bin/sh" portion of the command line.
The argument list follows the command name and is of the
general format, ARGS("arg1","arg2",..."argN")!. In the
example, the first argument, "-c", is an argument to the UNIX
operating system shell (/bin/sh) program. This argument
instructs the UNIX operating system shell to interpret the
next argument as if it were a string of characters from a
terminal. The effect is a UNIX operating system terminal
that executes a single command line. The EXC:ENVIR command
limits the line to a maximum of 63 characters.
The second argument, which begins with "usr/bin/idump and
terminates several lines later with !"), constitutes the
string being passed by the UNIX operating system shell
program. Typically, the idump program reads commands from
the terminal in an interactive mode with the user.
Noninteractive UNIX system commands to be processed by idump
can be made interactive by passing them in the second
argument string in the form of a here document.
As the name implies, the here document commands are read from
``here'' rather than the terminal. Some characteristics of a
here document are as follows:
o A here document begins with the sequence, <<!, and
terminates with the next occurrence of ! at the start
of a line. The use of ! is arbitrary; any character can
be substituted in its place.
o Each line within the here document represents a command;
in this case to idump.
o Each line within the here document is terminated with a
<lf> (line feed) rather than a <cr> (carriage return).
o A <cr> is a statement terminator which indicates the end
of an input message to the craft shell.
In the previous input/output example, the symbol table entry
for symbol main of process "/bin/date" was specified in the
EXC:ENVIR command line as "t main".
Sometimes it is convenient to place command strings into
files called scripts, and then execute the script. Following
are three examples which show the creation of executable
scripts:
Example 1:
<INPUT>
EXC:ENVIR:UPROC,FN="/bin/sh",ARGS("-c","/bin/echo '/usr/bin/idump<<!
\\\\n\\$2 \\$3\\\\nq\\\\n'>>/tmp/dumper")!
PF
<OUTPUT>
< M EXC ENVIR UPROC /bin/sh COMPLETED
Example 1 illustrates the use of ``/bin/echo'' to create a
file, /tmp/dumper, via the craft shell. In this example, the
``/bin/sh'' program is passed a string in argument 2 by the
use of the ``-c'' argument. Argument 2 contains the
following:
a. The command, /bin/echo, used to echo its output into a
file named /tmp/dumper. The entire string inside the
single quotes, ', is redirected into tmp dumper.
b. The symbol, >>, directs the output into a file, in this
case /tmp/dumper. The use of the double > appends the
output to any existing text in /tmp/dumper. A single >
overwrites any existing contents in /tmp/dumper.
c. A single backslash, \\, hides the meaning of special
characters from the UNIX operating system shell.
Example 2:
<INPUT>
DUMP:FILE:ALL=FN="/tmp/dumper"
PF
<OUTPUT>
< M 09 DUMP FILE ALL COMPLETED
/usr/bin/idump $1<<!
$2 $3
q
!
Example 2 illustrates the use of the DUMP:FILE command to
examine the contents of the newly created file, /tmp/dumper.
Dumper contains the pathname to the idump command followed by
$1 and the beginning of a here document. Run time arguments
to be passed from the command line to idump are represented
by $1, $2, and $3.
The name of the file to be acted upon will be contained in
$1. Arguments to idump will be contained in $2 and $3.
Example 3:
<INPUT>
<ALW:FILESYS:ACCESS=700,FN="/tmp/dumper"
PF
<OUTPUT>
<
M ALW FILESYS ACCESS COMPLETED
Example 3 illustrates the use of ALW:FILESYS:ACCESS to make
"/tmp/dumper" executable.
Note: Caution should be exercised in writing and using
scripts. Only persons thoroughly familiar with
shell programming should write scripts. Also,
scripts should not be executed out of crontab
unless approved by a high-level support.
The script created in the dumper execution command (see the
following) can be executed using EXC:ENVIR. In this case,
arguments are passed to /tmp/dumper in the argument list of
the EXC:ENVIR message as follows:
a. ``/bin/date'' will be substituted for $1 in
``/tmp/dumper''.
b. ``t'' will be substituted for $2 in ``/tmp/dumper''.
c. ``main'' will be substituted for $3 in ``/tmp/dumper''.
Therefore, /user/bin/idump is passed the command, ``/t
main'', inside the here document of ``/tmp/dumper''. The
result is, idump outputs the symbol table entry for function,
main.
An example of script execution as described previously is as
follows:
<DUMPER EXECUTION>
EXC:ENVIR:UPROC=FN="/tmp/dumper",ARGS("/bin/date","t","main")!
PF
<
<DUMPER OUTPUT>
M EXC ENVIR UPROC /tmp/dumper COMPLETED
CURRENT FILE: /bin/date Sat Sep 8 02:27:49 1984
F_AR32W F_LSYMS F_LNNO F_EXEC F_RELFLG
Magic Nscns Time/Date Symptr Nsyms Opthdr
Flags
00550 17 0x1ba016f5 0x00002800 549 0x0fec
0x020f
:
Symndx Name Value Scnum Type Sclass Numaux
[ 16] main 0x00000048 1 ()INT EXT 1
s/u/e tag=0 fcn size=0x788 lptr=0x0 endx=22 tv=0
:
The UPedcud is an interactive, menu-driven tool which allows
a user to read, edit, or alter the contents of the CUD and
History files maintained in the 5ESS switch by the Program
Update subsystem.
From the contents of the CUD entry, a user can verify what
type of change was applied to which file for a particular
BWM. The status of that particular BWM can be determined
from the contents of the history file.
Warning: This tool overwrites data in system files.
Incorrect use of this command will result in
the removal of needed information. If a
change to either the CUD or History File is
necessary, it should be made to a copy of the
file; not to the original. Changes should
not be made to original files without the
concurrence of the AT&T Customer Technical
Support (CTS) Organization.
Before using the UPedcud tool, make sure that
Program Update commands are not executing.
The UPedcud will affect Program Update and
could cause a disruption of service.
Changes which have been agreed to by the CTS Organization and
entered are made to a buffered copy of the CUD or History
file. They are not made in the permanent copy until the w
command has been entered to update that level of the editor.
UPedcud offers ten major menus and a number of submenus. The
major menus are as follows:
o Password
o Program Update File Editor
o CUD Header Editor
o CUD Item Display
o CUD Item Editor
o History File Main Menu
o History Header Item Editor
o History File Item Editor
o Dependent Files -- History Header Item Editor
o Dependent Files -- History File Item Editor.
UPedcud menus and submenus are presented to the user on a
scrolling screen display. A given menu page is always
displayed in its entirety. The UPedcud menu structure is
shown in Figure .AW G87/.
The number of greater than symbols shown near the left top of
the display for a particular menu or submenu indicates the
level at which that item resides in the editor. For example,
the CUD Item Display is in the first level and shows > [see
Figure .AW G97/ (Example 1)]. The CUD Item Editor menu and
submenus are in the second level and show >> (see Figures .AW G98/
and .AW G99/). Third and fourth levels are indicated on the
screens in the same manner.
Level three is the History File menu page from which level
four options can be selected (see Figure .AW G102/).
As each major menu item is quit, the user is returned to the
next higher level in the editor until the Program Update File
Editor is reached. Quitting the Program Update File Editor
returns the user to the Bourne shell.
A user password is required for access to the UPedcud
program. The password requirement serves as an additional
check to prevent accidental modification of files. Passwords
may be obtained from the CTS Organization.
When the command /no5text/prc/UPedcud is entered at the
Bourne shell prompt, the password menu will appear as shown
in Figure .AW G88/.
When the password has been successfully entered, the Program
Update File Editor menu is displayed showing the two types of
data that can be accessed:
1. CUD header
2. CUD item.
Figure .AW G89/ shows an example of the Program Update File Editor
display.
Option number 1 from the Program Update File Editor menu
calls up the CUD Header Editor menu which displays some of
the information stored in the CUD file header. This
information is as follows:
1. The number of CUD entries
2. The pointer to the end of CUD
3. The number of the last system update recorded in
CUD
4. The number of the last BWM header sequence
recorded in CUD
5 - 16. The number of temporary overwrites (Temps) to the
SM, CMP, MSHG, and SM peripherals. The number of
Temps for each is shown for standard, loaded, and
basic configurations.
17 - 22. The pump map used during SM or CMP pump. (The SM
pump map includes peripheral targets.) The SM or
CMP pump map is shown for standard, loaded, and
basic configurations.
The CUD Header Editor menu allows a user to edit or view
information stored in the CUD file header as follows:
o Edit package sequence numbers stored in CUD header
(option s)
o Edit names of the last three official BWMs which are
permitted to be backed out. These names are used by the
back out last official 3 deep (BOLO3) feature (option l)
o View system patch addresses (option a)
o Edit the BWM table (option t)
o View CUD and History record sizes (option d).
If the BWM package is backed out, the number of CUD entries
is reduced by the number of temps backed out. The last
update number is not reduced. If the BWM package is
reapplied, the number of CUD entries starts at the reduced
number and the last update number from its current value.
Option t is used to edit the BWM table of 20 slots which is
created in the CUD header to store the information of the
first 20 BWMs contained in the CUD file. The BWM table is
created to avoid the sequential search of the CUD file for a
particular BWM.
When the CUD Header Editor menu is quit, the user is returned
to the Program Update File Editor menu. An example of the
CUD Header Editor menu that is displayed when the user
selects option number 1 from the Program Update File Editor
menu is shown in Figure .AW G90/.
Each entry in the BWM table contains the name of a BWM and
the file offset to the beginning of its last CUD entry.
Figure .AW G91/ is an example of the screen display which shows
this information. The BWM names (in chronological order) are
shown the first column of each entry. The second column is
the file offset to the beginning of the BWMs last CUD entry.
This information is critical and should not be changed.
Option d displays the sizes of various records in CUD and
History files. This is a display only option, and changes
cannot be made. Figure .AW G92/ is an example of the information
displayed when option d is entered.
The package sequence numbers for current BWMs can be
displayed and edited by selecting option s from the CUD
Header Editor menu.
Each sequence number on the display corresponds to a loadable
package. The name of the loadable package referenced by each
sequence number will be displayed at the prompt line as the
sequence number is selected. In Figure .AW G93/, the name of the
27th loadable package, ``GLISDNEDLS'', is displayed in the
line prompting for a new sequence number. The number of
loadable packages changes from one software release to
another.
An example of the package sequence numbers display is shown
in Figure .AW G93/.
To support the BOLO3 feature, names of the last three
official BWMs can be displayed and edited by selecting option
1 from the CUD Header Editor Menu. An example is shown in
Figure .AW G94/.
Option a from the CUD Header Editor displays pumpable
peripheral OSsyspatch addresses. Each address number in the
submenu corresponds to an image. The submenu includes all
the SM, CMP, and peripheral (pumpable or nonpumpable)
targets. Figure .AW G95/ is an example of the OSsyspatch address
display for the 5E6 and 5E7 software releases.
Following is a list of address numbers and corresponding
images for the 5E6 and 5E7 software releases:
Address No. Peripheral Image
1 ISLU (Integrated services line unit)
2 PH2A (128-channel protocol handler with ACCESS image)
3 LDSU (Local digital service unit)
4 RAF Recorded announcement function)
5 ISTF Integrated services test function)
6 PH2G (128-channel protocol handler with GATEWY image)
7 ODMA (Operational direct memory access)
8 PH3C (Common image 128 channel protocol handler)
9 OIOP (Operational input/output processor)
10 PI (Protocol interpreter)
11 HDSU (DSU2 diagnostic image)
12 DDMA (PH2 Direct Memory Access Processor
diagnostic image)
13 Standard SM
14 Loaded SM
15 Basic SM
16 CMP AP
17 CMP MSGH
Figure .AW G96/ is an example of the OSsyspatch address display for
5E8 and later software releases.
Following is a list of address numbers and corresponding
images for 5E8 and later software releases:
Address No. Peripheral Image
1 ISLU (Integrated services line unit)
2 IDCU CCP (Integrated Digital Carrier Unit Common
Control Processor)
3 IDCU LSI (Integrated Digital Carrier Unit Loop
Side Interface)
4 IDCU DLP (Integrated Digital Carrier Unit Data
Link Processor)
5 LDSU (Local digital service unit)
6 RAF Recorded announcement function)
7 ISTF Integrated services test function)
8 PH2A (128-channel protocol handler with ACCESS image)
9 PH2G (128-channel protocol handler with GATEWY image)
10 ODMA (Operational direct memory access)
11 PH3C (Common image 128 channel protocol handler)
12 OIOP (Operational input/output processor)
13 PI (Protocol interpreter)
14 HDSU (DSU2 diagnostic image)
15 DDMA (PH2 Direct Memory Access Processor
diagnostic image)
16 Standard SM
17 Loaded SM
18 Basic SM
19 CMP AP
20 CMP MSGH
Option number 2 from the Program Update File Editor menu
calls up the CUD Item Display menu. The CUD Item Display
main menu shows a listing of up to 10 CUD entry summaries.
If a CUD contains more than 10 entry summaries, initially the
last 10 will be displayed. Regardless of which CUD entry
summaries are included in the window of displayed items, they
will always be numbered 1 through 10 on the display. The
number of the CUD item starting the list and the total number
of CUD items are identified on the screen above the listing.
Figure .AW G97/ (Example 1) shows the CUD Item Display menu.
Notice that 10 CUD entry summaries are listed, starting with
#18 (and going through number 27). In the display, however,
they appear as numbers 1 through 10.
Unless the first or last CUD item appears in the listing of
items being displayed, the user can move the window either
forward or backward to examine other entries. If the first
item is displayed, the window can only be moved forward (f is
the only move option). Vice versa, if the last item is
displayed, the window can only be moved backward (b is the
only move option). In Figure .AW G97/ (Example 1), 10 CUD items
are listed starting with #18. Since, the last CUD item
(number 27) is included in the listing, b is shown as the
only move option. Accordingly, the screen shows that b has
been entered to move the window backward. Figure .AW G97/ (Example
2) shows the screen display with the window moved backward 10
entries (the default quantity). The listing now starts with
CUD item #8 (and goes through number 17). Since neither the
first or last CUD item is included in this display listing,
the user can move the window either forward or backward (f or
b are move options). A user wanting to get from the display
shown in Figure .AW G97/ (Example 2) to one that includes CUD item
number 26 would enter f to move the window forward and press
return to default the forward movement to 10 entries. A
screen display would then appear with summary data for Cud
items #18 through 27 as shown in Figure .AW G97/ (Example 3).
The CUD Item Display will show all SM configurations as
changed regardless of whether or not the particular image is
used in the office.
In addition to offering forward and backward movement
options, the CUD Item Display main menu allows the user to
either quit and return to the Program Update File Editor menu
or go down another level in the editor for more detailed
examination of specific CUD items.
The next level down from the CUD Item Display menu is the CUD
Item Editor menu.
From the CUD Item Display menu, a user can access additional
information about a specific CUD item by entering the screen
number of the item at the system prompt, <Enter option or Cud
entry number to examine:. For example, in the screen display
shown in Figure .AW G97/ (Example 3), the user has entered 9 (to
examine CUD item 26). When 9 is entered, the Cud Item Editor
menu displays a numeric listing of data fields with detailed
information about CUD item #9.
An example of the CUD Item Editor menu screen display for CUD
item #1 is shown in Figure .AW G98/.
In the CUD Item Editor menu, all data fields for a particular
CUD item are displayed in a readable format, including
English descriptions for the status bits. The user can
modify the data in any field by entering the number for that
field at the system prompt, >>Enter option or field number to
modify:.
Note: It is strongly advised that NO changes be made
to a CUD item without the concurrence of the CTS
Organization.
When a field number has been entered for modification, a
submenu for that field, if there is one, is presented;
otherwise, it is a toggle.
From the submenu, the user can change the value of the field
and return to the CUD Item Editor menu. If no change is
desired, pressing the return key will return the user to the
CUD Item Editor menu by default without changes being made.
If it is a toggle, the user can select the number and its
value will be changed.
Figure .AW G99/ is the submenu shown when field number 2, Update
type:, is selected for modification in 5E6 and 5E7.
Figure .AW G100/ is the submenu shown when field number 2, Update
type:, is selected for modification in 5E8 and later.
The affected SM list submenu is accessed by selecting option
s Show affected SM(s) from CUD Item 1 menu. An example of
the affected SM list is shown in Figure .AW G101/.
One level down from the CUD Item Editor Menu is the History
File Main Menu which offers four options as shown in Figure
.AW G102/.
The History File Main Menu allows a user to access the
history file header (choice #1), the history file item
(choice #2), the dependent file's history file header (choice
#3), and the dependent file's history file item (choice #4).
Menu displays of choices #3 and #4 are identical to displays
of choices #1 and #2, respectively. The difference is that
choices #1 and #2 edit the history file while choices #3 and
#4 use the dependent file's history file as input.
To edit the history header information, the user would select
1, Edit history file header information from the History File
Main Menu. If the dependent file's history file is targeted,
3, Edit dependent file history file header information,
should be selected instead. Figure .AW G103/ shows an example of
the History Header Editor Menu when 1 is selected. If 3 is
selected, the only difference in the display is the first
line in the screen which would read ``Cud Item #1 Dependent
File History File Header''.
A submenu of file update type, as shown in Figure .AW G104/, is
displayed when the user enters 7 at the prompt >>>>Enter
option or History header field number to modify.
In the History File Item Editor Menu the fields of a CUD
item's associated history file are displayed in a readable
form. A 1-line summary of the CUD item is included at the
top of the menu. English descriptions are given for the
transaction types and the status flags.
To select a history file for examination, from the CUD Item
Editor Menu enter h, Show history files, followed by 2 from
the History File Main Menu. An example of the History File
menu that will be displayed is shown in Figure .AW G105/. Note
that if the CUD item specifies both a history file and a
dependency file, only a history file can be displayed.
Dependency file examination is described in Section
.RM 3.17.8.2.8/.
Note: Although the History File Item Editor menu is
actually four levels down in the editor, screen
displays of this menu indicate 3 levels down
(see Figure .AW G105/).
The user may modify any of the fields by inputting the
appropriate field number at the system prompt, >>>Enter
option or History field number to modify:.
Note: Changes should not be made to history files
without the concurrence of the CTS Organization.
Figure .AW G106/ is the display for field 6, Transaction type:.
The transaction type must not be changed. To do so will
cause the Program Update subsystem to be (or not be)
expecting certain temporary files associated with this BWM.
Figure .AW G107/ is the display for field 7, Status flags:.
These status flags indicate the current status of the BWM
associated with this history file.
Figure .AW G108/ is an example the Function Names and Addresses
screen that is displayed when option f is entered.
Generic utilities are resident, real-time software debugging
tools which support a set of commands to aid maintenance
personnel with the verification, localization, and temporary
correction of application programs running in some 5ESS
switch processors such as the CMP, CMPMSG, FPC, IDCU,
IDCULSI, ISLUCC, MMP, PH2/1, PH3, PI, PPC, and SM.
Caution: The improper application of generic utility
programs can be service affecting. Before
implementing any of the generic utility
functions, consult local supervision
concerning policy. It is recommended that
the implementation of any generic utility
program be discussed with the Electronic
Switching Assistance Center (ESAC) prior to
starting the procedure.
The 5ESS switch generic utilities allow a user to do the
following:
o To dynamically display the target processor's memory as
hexadecimal output or in a disassembled format.
o To temporarily overwrite the target processor's memory.
o To copy data from one memory location to another
location in the target processor's memory.
o To combine a series of UT input commands into a single
command clause.
o To perform comparisons of data and alter UT command
selection based on the comparison. This is the IF and
ELSE commands which can also be nested.
o To do limited conversions of a function name or global
symbol to an address or location for symbolic debugging.
o To temporarily store data and constants through the use
of utility variables.
o To call or execute a function in the target processor
and pass up to 20 bytes of data as parameters.
o To change the operational flow of a program by
performing a GOTO operation.
o To routinely perform a user defined set of UT commands
on a TIMED basis.
o To perform a user defined set of UT commands at specific
user defined points in the target processor's
operational text.
o To utilize the scripting capability to create a file on
the UNIX operating system using the MCC terminal.
Not all of the features and capabilities listed are
maintained by UT for all of the supported processors. The UT
input and output manual pages must be used to determine which
commands, options, and software releases are supported for
each processor.
The implementation of generic utilities commands is
controlled by the following:
o The input of UT commands by maintenance personnel via
the MCC or a corresponding terminal.
o The firing of UT breakpoints which have been set by
maintenance personnel.
o The sequencing of a UT TIMED WHEN clause that has been
scheduled by maintenance personnel to run after some
time delay.
o The initiation of fault recovery operations in the
switch which can inhibit or remove UT WHEN commands.
All UT output data or error messages are printed on the ROP
and displayed on the originating video terminal.
All generic utility input commands are entered manually by
maintenance personnel at the MCC or a corresponding terminal.
The commands are input as either an immediate command,
immediate clause, or a WHEN command clause. Following is a
description of each type:
o An immediate command is any single UT input command
(except the WHEN command) which is entered by the user.
Upon entry, the command is validated for errors. If no
errors are found, the command is executed, an output
message is printed at the ROP and calling TTY, and the
command is removed from the target processor. If an
error is found, the same process is followed except the
command is not executed. It should also be noted that
real-time breaks may occur and are acceptable during the
execution of an immediate command.
o An immediate clause is any group of UT input commands
(except WHEN commands) which are entered by the user.
The operation of the immediate clause is the same as an
immediate command except each operation is performed on
the entire clause. This means that upon entry, the
entire clause must pass validation to be executed, and
each command will then be executed. If any single
command of the clause does not pass validation, the
entire clause will not be executed and a single error
message is printed on the ROP and calling TTY. It
should also be noted that real-time breaks may occur and
are acceptable during the execution of an immediate
clause.
o A WHEN command clause is a single WHEN command or any
group of commands that start with a WHEN command. The
operation of a WHEN command clause is different from
either an immediate command or immediate clause because
the command, or entire clause, is stored in the target
processor's memory for later execution, provided no
errors are found in the validation phase. If a WHEN
command clause passes validation, it is stored in an
inhibited state. This means a second command must be
used to enable the clause. Following are definitions of
the two types of WHEN command clauses which can be
formed:
1. A WHEN breakpoint clause sets up a software
interrupt in the target processor which allows UT
to execute the given sequence of commands at
specific points in the application code. It should
be noted that real-time breaks are not acceptable
during the execution of a breakpoint clause.
2. A timed WHEN clause sets up a cyclical timer in the
target processor which allows UT to execute the
given sequence of commands on a scheduled basis.
It should be noted that real-time breaks may occur
and are acceptable during the execution of a timed
WHEN clause.
In order to use the generic utility commands, an
understanding of how the commands are formatted in the input
manual pages is required. Table .AW TX/ can be referenced to
determine the conventions, definitions, and symbols used for
formatting input commands.
Generic utility (UT) commands consist of an action verb,
identification field(s), and optional data field(s). Several
commands which are executed sequentially can be strung
together. All commands, which are part of a string of
commands, except the last one must be terminated with a
``!''. The last command should be the END command and must
terminate with ``;'' (MML format).
All UT input commands are very similar in format. The basic
UT input command format is action verb:UT:processor
ID,optional parameters,message terminator.
Following is an example of the DUMP:UT:CMP input message
syntax format which is similar to that used in all of the UT
input manual pages:
DUMP:UT:CMP=0,{MATE|PRIM}[,DIS][,EA][,L=a],
{ADDR=b|REG=c|REGS|UVAR=d|GVAR="e"}
[,INDIR=f][,OFF=g[-g][-g]]{!|;}
A breakdown of the format syntax in this example is as
follows:
o DUMP is the action verb which indicates the action
requested by the user and to be performed by UT.
o UT is always present in generic utility input commands.
It serves as one of the identifiers of the input
message.
o CMP=0 identifies the processor where the operation is to
take place. This identifier can be used with other
qualifiers to further describe which physical unit is
the target of the operation (for example, MATE, PRIM).
o MATE or PRIM is a required parameter for this UT input
message. The user must use one of these qualifiers.
The field converts a logical processor into a physical
location. This field is not always used in all UT
messages; but when it is there, it must be filled in.
o DIS, EA, L, INDIR, and OFF are optional parameters used
in this UT input message. These fields allow the user
to further define the type of information retrieved, the
format of the output, or the starting location of the
operation. The optional fields are always defaulted to
a value, and not all optional parameters can be used at
one time.
o ADDR, GVAR, REG, REGS, and UVAR are addressig field
identifiers used to determine where the information is
going to or coming from. The addressing field is
required in almost all of the UT input messages, but the
identifiers used will vary from message to message.
o The ``!'' or ``;'' is used to end each UT input command.
One of these symbols is required for each message. The
``!'' terminates the input message and also indicates
that the message is part of an on-going clause. The
``;'' indicates that this is the absolute end of the
message or clause.
Based on this format, an example of a valid input command
could be as follows:
DUMP:UT:CMP=0,PRIM,GVAR="INsynch",EA;
This example would print in hexadecimal the effective
starting address of the global symbol INsynch (in this case a
function) from the active or primary CMP to the ROP and
calling TTY.
There are many more combinations of commands which can be
created, all of which have their own uses and abilities.
Some of the options, however, are only valid when used in
combination with other commands.
Refer to AT&T 235-600-700, Input Messages Manual, Volume 1,
User Guidelines section, for additional information on
command format.
The generic utilities consist of 13 commands (action verbs)
which are separated into 5 functional categories as follows:
1. Data Transfer Commands include the following:
o DUMP
o LOAD
o COPY.
2. Conditional Commands include the following:
o IF
o ELSE
o ENDIF.
3. The When Command is as follows:
o WHEN.
4. When Controlling Commands include the following:
o ALW (allow)
o INH (inhibit)
o OP (operational status)
o CLR (clear)
o END.
5. Execute Command is as follows:
o EXC (execute).
Data transfer commands allow the user to move, print, and
write data to addressable system locations. Data transfer
commands are described as follows:
Dump Command
The DUMP command is used to print the contents of one or
more sequential memory locations, microprocessor registers,
or utility variables in the specified processor. The
dumping of the microprocessor registers (due to the dynamic
nature of these registers) can only be performed inside UT
breakpoint clauses. The length of dumps is always provided
in bytes, but the maximum dump length will change for each
of the different processors supported. The output is
printed in hexadecimal (the default case) but can be
printed in a disassembled (string) format. There are two
basic differences in the gathering of data which need to be
noted. They are as follows:
1. When a dump is performed outside a breakpoint clause,
real-time breaks are taken after each message is
formatted. This means the dumping of data (which does
not fit in one message) is not a snap shot of the
memory to be dumped but a gathering of the requested
data over a period of time. This is acceptable for
dumping information which is not real dynamic such as
the operational text of a function.
2. When a dump is performed inside a breakpoint clause,
real-time breaks are not taken. This means that the
dumping of requested data is a true snapshot.
However, the amount of data dumped in a breakpoint is
limited to less than 2000 bytes. The processing of a
breakpoint causes UT to store all output messages for
that clause in an output buffer (2000 byte) which is
then printed out as a deferred operation. All
messages formatted are placed here; not just the data
being dumped. Therefore, the real length limit must
include the overhead of each message when included in
a breakpoint clause. This approach is very useful
when dumping dynamic data or data which is only
accessible during breakpoint clauses.
Load Command
The LOAD command allows the user to overwrite memory in
increments of long word, word, or byte sizes. The user
specifies the start address (where the load shall begin)
and the size of the values (1 to 4 bytes per value) to be
loaded. The maximum total length per command (in bytes) is
dependent on the target processor. The length (L) divided
by the SIZE of each value provides the number of values
expected. However, it is illegal to have a remainder. As
part of the overwrite operation, most of the target
processor's write protection is removed. Thus, the user is
allowed to overwrite almost anything in memory. There are
obvious exceptions however, such as read-only memory (ROM)
which is addressable, but physically cannot be written. A
load complete message is printed for each successful
operation, unless the load is part of a WHEN command
clause. Copy Command
The COPY command is used to transfer data from one internal
processor location (that is, absolute address, register,
variable, utility variable, or symbolic address) to
another, move constants to an internal location, and to
increment, decrement, or multiply the value.
The COPY command consists of three sets of parameters of
which the third set is optional. In the first set, the
user specifies the destination address. The second set, or
second and third sets, allow the user to supply the value
to be transferred or give a description of where to find
the values. The COPY command is in fact an assignment
statement in the form of (A = B [(+|-|*)C], where A, B, and
C are the three sets of parameters. The user invokes the
``PLUS'' option by typing PLUS on the command line. This
causes the data from the third parameter to be added to
data from the second parameter. Likewise, the ``MINUS''
option is invoked by typing MINUS on the command line, but
data from the third parameter is subtracted from the second
parameter. The ``MULTIPLY'' option is invoked by typing
MULTIPLY on the command line, but data from the third field
is multiplied by the second field. The parameters can be a
combination of absolute addresses, registers of the
microprocessor, utility variables (UVAR), symbolic
addresses, or constants. Following are two different forms
of operation which need to be noted:
1. When a COPY command is performed outside a breakpoint
clause, options which deal with the microprocessor
registers are not allowed. A copy completed message
is printed for each successful operation.
2. When a COPY command is performed inside a breakpoint
clause, all available operations are valid, but no
copy completed message is printed.
The COPY command is limited to four bytes of data copied
per command. During the overwrite operations, most of the
write protections are removed. Thus, the user can transfer
data to almost anywhere. This command then allows for the
transfer of data based on dynamic addresses.
Conditional commands allow the user to make comparisons of
data of up to four bytes per test and optionally execute a
list of UT commands if the comparison is true. The
conditional commands also provide the ability to execute a
separate list of UT commands if the comparison is false. The
basic form of the conditionals is as follows: if the tested
condition is true, perform the following user defined list of
UT commands, else perform a secondary list of user defined UT
commands.
Conditional commands can also be nested, which allows the
user to have several conditions evaluated before executing
the list of UT commands. The conditional commands are
described as follows:
IF Command
The IF command allows the user to set up a comparison of
two values. Both values are user defined and can be
constants, data, addresses, registers, and more. The
comparison is also user defined and can be one of the
following types; equal to, greater than, greater than equal
to, less than, or less than equal to. The IF command does
not print any messages, but it allows a list of UT input
commands to be performed when the condition is tested and
is found to be true. It should be noted that the
comparison is made with sign-extended logic, and not all
command options are allowed outside a breakpoint clause
(basically the microprocessor registers).
ELSE Command
The ELSE command allows the user to establish an alternate
list of UT commands to be executed whenever the comparison
performed in the associated IF command is found to be
false. This command is only used in conjunction with the
IF command.
ENDIF Command
The ENDIF command allows the user to continue entering
utility commands that are not associated with the IF or
ELSE condition of a command clause. Nesting of IF, ELSE,
and ENDIF commands is allowed, and the only limit to the
amount of nesting is the maximum of 45 commands total in
any single processor. The nesting of the conditional
commands can be shown by the following:
if (A > B)
then if (A < C)
dump data (X)
else (A >= C)
dump data (Y)
copy data (A to address P)
endif
else
copy data (1 plus counter to address counter)
endif
The WHEN command gives a user the ability to sequence through
a defined list of UT commands at a given point in the
application code or at an approximate time interval. The
generic utilities provide for two types of WHEN commands;
WHEN BREAKPOINT and TIMED WHEN which are defined as follows:
WHEN Breakpoint Command
WHEN breakpoint clauses allow maintenance personnel to
interrupt the application code of a process in the target
processor, execute a predefined sequence of UT commands,
and resume execution of the process with minimal effect to
the real time of the process. A WHEN command can be placed
at any memory location in random access memory (RAM), but
it must be placed at the start of any executable
instruction for it to work. For memory protection, the
value at the desired address in RAM is compared with what
the user provides as the value of the OPCODE. If the
comparison is false, the WHEN command will be removed and
an error message is printed.
After a valid WHEN clause is entered by maintenance
personnel, it is stored in memory in an inhibited state.
While the clause is in the inhibited state, the breakpoint
(trap instruction) has not been placed in memory at the
specified location, and none of the commands of the clause
can be executed. Maintenance personnel must use the ALW
command to enable the breakpoint.
The ALW command places the trap instruction in the
specified memory location and marks the state of the WHEN
command to active. This means that any time the
microprocessor executes the trap instruction located at
this address, the following events occur:
1. Microprocessor registers are saved by the operating
system. This allows UT to access the data contained
in these registers at the time the exception occurred.
After UT has processed the breakpoint, the registers
are used to return the operational flow of the code
back to the original point of the trap instruction.
2. Maskable interrupts are blocked during the processing
of the UT WHEN clause.
3. Generic utilities determines which breakpoint has been
hit and sequences through the list of UT commands
contained in the WHEN clause.
4. Output messages formatted by this sequence of UT
commands are placed in an output buffer maintained by
the UT process. The buffer is currently limited in
size (2000 bytes), so care must be taken to prevent an
overflow of information. This buffer cannot be
unloaded when UT is processing a breakpoint.
The placement of the breakpoint determines what data is
available and how to access it. The OPCODE, which is
replaced by the breakpoint, is not executed until the WHEN
breakpoint clause has been performed. Thus, if data is
dumped from a location defined by a dynamic pointer, the
breakpoint cannot be placed at the address of the
instruction which sets up the pointer.
Timed WHEN Command
Timed WHEN clauses allow maintenance personnel to execute a
predefined sequence of UT commands at a user defined
interval of time. Timed WHEN commands operate with a
cyclical timer at the processor's normal level of operation
and do not operate at interrupt level.
After a WHEN clause is entered by maintenance personnel, it
is stored in memory in an inhibited state. While the
clause is in the inhibited state, the cyclical timer has
not been established, and none of the commands of the
clause can be executed. Maintenance personnel must use the
ALW command to enable the timed WHEN.
The ALW command sets up a cyclical timer with the operating
system for the specified length of time and marks the state
of the WHEN command to active. This means that when the
time interval is reached, a message is sent to the UT
process indicating a timed WHEN needs to be processed.
Generic utilities determine which timed WHEN has fired and
sequences through the list of UT commands contained in the
WHEN clause. As part of timed WHEN processing, the UT code
does not have access to the microprocessor registers, and
dumped data is taken over a period of time (not a snapshot
of the data).
Once a WHEN breakpoint command or a timed WHEN command is
allowed, it remains active until one of the following events
occurs:
a. The WHEN clause has been executed the number of times
the user specified (refer to the HIT option described in
this section under Command Parameters).
b. The user clears or inhibits the WHEN clause (refer to
the CLR and INH commands described in this section under
WHEN Controlling Commands).
c. The generic utilities audit has removed the breakpoint
because an error has occurred in the storage of the WHEN
command clause.
d. Pumping of the particular SM, CMP, or PH3 containing the
WHEN removes all WHEN commands in the processor.
e. As part of a selective initialization or a single
process purge of generic utilities, all timed WHEN
commands in the processor are inhibited. The craft
needs to allow the timed WHEN commands to use them
again.
f. As part of a full initialization, all timed WHEN
commands are cleared from the processor. If these timed
WHENs are needed, the craft must reenter the command
clause.
g. For 5E6 and later, if a CMP soft switch occurs, UT
follows these rules:
o All breakpoints in the old active CMP are moved to
the new active CMP and maintained in their current
state.
o All breakpoints in the old standby CMP will be
removed and not moved to the new standby CMP. If
these breakpoints are needed, the craft must
reenter the command clause.
h. As part of a selective initialization of a CMP, UT
performs an inhibit operation on any active WHEN command
in the processor. The craft needs to allow the
breakpoints to use them again.
i. As part of a full initialization of a CMP, UT performs a
clear operation on any WHEN command in the processor.
If these breakpoints are needed, the craft must reenter
the command clause.
j. For 5E7 and later, as part of a selective initialization
of an SM or a PH3, UT performs an inhibit operation on
any active WHEN command in the processor. The craft
needs to allow the breakpoints to use them again.
k. For 5E7 and later, as part of a full initialization of
an SM or a PH3, UT performs a clear operation on any
WHEN command in the processor. If these breakpoints are
needed, the craft must reenter the command clause.
The WHEN controlling commands enable the user to
allow/enable, inhibit, clear/remove, and view the operational
status of one or more WHEN commands in the target processors.
These commands may be entered within a WHEN clause to
manipulate other WHEN clauses. The WHEN controlling commands
are allow (ALW), clear (CLR), inhibit (INH), operational
status (OP), and END and are described as follows:
ALW Command
The ALW command enables a single WHEN clause or all WHEN
clauses that are in the inhibited state in the target
processors. Following are two basic types of operations
which can be performed:
1. When the ALW command enables a WHEN breakpoint
command, a trap instruction is placed at the address
defined in the WHEN command. Checks are performed to
make sure the OPCODE expected at the given address
matches what is truly in memory. If the check does
not pass, an error message is printed and the WHEN
command will be removed by the UT audit. If the trap
is placed in memory, whenever the trap instruction is
hit by the microprocessor, the list of commands
associated with the WHEN command will be executed.
2. When the ALW command enables a TIMED WHEN command, a
cyclical timer is started. Whenever the timer
expires, a message to perform the list of commands
associated with the WHEN command is sent to the UT
process. A TIMED WHEN cannot be allowed inside a WHEN
breakpoint clause due to operating system constraints.
CLR Command
The CLR command removes a single WHEN clause or all WHEN
clauses from the target processors regardless of their
current state. Following are two basic operations which
can be performed:
1. When the CLR command removes a WHEN breakpoint
command, the WHEN cannot be reenabled; it must be
typed in again by the user. If the WHEN command was
inhibited at the time of the clear operation, the WHEN
is only removed from UT's knowledge. If the WHEN
command was active, the correct OPCODE is placed back
into the operational code at the address defined in
the WHEN command, and then UT's knowledge of the WHEN
is removed.
2. When the CLR command removes a TIMED WHEN command, the
WHEN cannot be reenabled; it must be typed in again by
the user. If the WHEN command was inhibited at the
time of the clear operation, the WHEN is only removed
from UT's knowledge. If the WHEN command was active,
the cyclical timer is retired and then UT's knowledge
of the WHEN is removed.
INH Command
The INH command disables a single WHEN clause or all WHEN
clauses that are in the active state in the target
processors. Following are two basic operations which can be
performed:
1. When the INH command disables a WHEN breakpoint
command, the correct OPCODE is placed back into the
operational code at the address defined in the WHEN
command. The WHEN command clause, however, is left in
the UT memory and can be reenabled with another ALW
command. The WHEN breakpoint command is then
effectively ignored at this point.
2. When the INH command disables a TIMED WHEN command,
the cyclical timer is deleted. The WHEN command
clause, however, is left in the UT memory and can be
reenabled with another ALW command. A TIMED WHEN
command cannot be inhibited inside of a WHEN
breakpoint clause due to operating system constraints.
OP Command
The OP command causes an output list of the status
(inhibited or active) of a single WHEN clause or all WHEN
clauses contained in the target processor's memory. The
output lists the status, WHEN identification, hit count,
and some detailed information of the WHEN such as the
defined address of the WHEN.
END Command
The END command is used to signify the end of a utility
request. The END command is only used as the last command
of a clause and must terminate with a ``;''. However, the
user may terminate any clause with any other UT input
command, but the terminator must be a ``;''.
The execute command is EXC and is described as follows:
EXC Command
There are two different forms of the EXC command which can
be used in the supported processors. The two forms are
identified by the indicators CALL and GOTO and are
described as follows:
1. The EXC command which performs the CALL option allows
the user to enter a function name to make a function
call while passing up to 20 bytes of data. The user
is responsible for determining the correct parameters
and the order in which to pass them. The returned
data of the function is printed and saved. It should
be noted that the execute command can handle a
function returning any type of data (for example, the
function returns a short, pointer to a structure,
long, etc.). A check is performed to make sure the
function being called is truly a function.
2. The EXC command which performs the GOTO option allows
for an immediate jump of the microprocessor to a user
defined absolute address. This command is only valid
inside a WHEN breakpoint clause.
The processor identification (ID) refers to the particular
5ESS switch processor on which program analyses are being
performed. Following (in alphabetical order) is a listing of
possible processor IDs and the processor associated with
each.
PROCESSOR ID PROCESSOR
CMP Communication Module Processor
CMPMSG Communication Module Processor Message Handler
FPC Foundation Peripheral Controller
IDCU Integrated Digital Carrier Unit
IDCULSI Integrated Digital Carrier Unit Loop Side Interface
ISLUCC Integrated Service Line Unit Common Controller
MMP Module Message Processor
PH2/1 Packet Switch Unit Protocol Handler (Model 1 & 2)
PH3 Packet Switch Unit Protocol Handler (Model 3)
PI Peripheral Interface
PPC Pump Peripheral Controller
SM Switching Module
Some generic utility commands are used to analyze programs in
all 5ESS switch processors, while others are used with only a
few. Table .AW TY/ shows the 13 UT commands, the processors which
support each command, and the software release with which the
support became effective.
The UT command parameters, which include optional data fields
and the required addressing modes, vary depending upon the
command (action verb) being used and the processor being
analyzed. Following is a listing of UT command parameters
and a description of each:
2
PARAMETER DESCRIPTION
ADDR: This specifies a physical address at which the
action is to take place. The starting address can be
modified in some commands by using indirections and
offsets.
ARG: This specifies the number of arguments or parameters
to be passed as 2-byte numbers to a function.
CALL: This identifier indicates the function, whose name
is specified by the symbol contained in FUNC, will be
called by the UT process in the specified processor.
A check is performed to make sure the symbol is a
function.
DIS: This causes the data to be dumped in a disassembled
format instead of straight hexadecimal output. The
disassembly of the data is performed based on the type of
microprocessor used in the target processor. Two
different forms of disassembly can be produced. The
first is based on the MOTOROLA(R) 680XX instruction set,
and the second is based on the INTEL(R) 80X86
microprocessor. This option causes the processor to
route the raw memory data to one of the disassemblers
which are located in the AM. The AM receives raw data
from the processor, disassembles it, stores the output in
an AM buffer, and then prints it at the ROP and the
calling TTY.
EA: This indicates that the data to be used (that is,
dumped, copied, or compared) is the determined effective
starting address of the operation instead of the contents
of the address.
EQ: This is a key word identifier which indicates equal
to. It is used in the COPY command to separate the
source and destination parameters. Data identified
to the right of ``EQ'' is transferred to the location
identified at the left of ``EQ''.
In the IF command, ``EQ'' is the type of condition to be
performed.
FOREVER: This indicates that the WHEN command, once it has
been allowed, will not be removed by the UT process based
on the number of times it has been utilized. When this
option is used, the WHEN command is only removed or
inhibited by fault recovery actions or another manual
UT input WHEN controlling command.
FUNC: This indicates that the function is specified
symbolically (for example, FUNC = "function name").
Must be entered as a string of up to 15 characters
enclosed in double quotes.
GE: This is a key word identifier which indicates the
condition to be evaluated is greater than or equal to.
GOTO: This identifier indicates that a C-statement GOTO will be
performed. This option is only allowed in conjunction with
a WHEN breakpoint, and the jump will be from the address of
the breakpoint to the address defined by the ADDR field of
the EXC command.
GT: This is a key word identifier which indicates the
condition to be evaluated is greater than.
GVAR: This is the global variable which indicates that the
address is specified symbolically (for example, GVAR =
"function name"). Must be entered as a string of up to 15
characters enclosed in double quotes.
HIT: This is the hit option which accepts a number as an input
parameter. This number is used by UT in the target
processor to indicate the number of times a WHEN command
can be utilized before it is automatically inhibited by the
UT process. The primary use of this option is to provide
a method which prevents UT from using too much of a
processor's real time which can cause fault recovery
actions to take place.
INDIR: This is the indirection option which accepts a number
as an input parameter. This number is used by UT to
indicate the number of levels of indirection. The
definition of a level of indirection is to take the
contents of an address and use the contents as a pointer.
Thus, one level of indirection means UT will go to the
address defined by the contents of the address of the main
level. If more than one level of indirection is indicated,
the second level will be determined based on the first level
(that is, a pointer points to a pointer).
IO: This key word accepts a number as an input parameter. The
number indicates the particular input/output port to be used
in the operation. An 8-bit length is imposed on any
operation performed on an IO port.
L: This option specifies the length (in bytes) of the
action to be taken.
LE: This is a key word identifier which indicates the
condition to be evaluated is less than or equal to.
LT: This is a key word identifier which indicates the
condition to be evaluated is less than.
MATE: This is a key word which causes the action to occur
only to the standby processor. In fully duplex units (such
as the SM), the operation is actually performed on the
active unit by doing reads/writes across the update bus.
In units which are duplex but do not have an update bus
(such as the CMP), the entire action is performed on the
standby unit.
MINUS: This is one of the optional keywords used in the COPY
command. This indicator causes the data defined in the
source field of the command to be subtracted by the data
defined in the optional third field of the command before
the copy of data is performed.
MULTIPLY: This is one of the optional keywords used in the COPY
command. This indicator causes the data defined in the
source field of the command to be multiplied by the
optional third field of the command before the copy of
data is performed.
MSK: This is the mask option which accepts a number as an
input parameter. This number specifies the value to be
``anded'' with the final result before evaluating the
conditional statement.
NE: This is a key word identifier which indicates the
condition to be evaluated is not equal to.
NOPRINT: This keyword causes the suppression of two messages which
would normally be printed every time an active WHEN command
was processed by UT. The messages are the WHEN STARTED
and WHEN COMPLETED messages. However, commands
contained in the WHEN command clause may still print
messages (for example, the DUMP command). The use of
this option reduces ROP messages and speeds up the
processing of WHEN command clauses.
OFF: This is the offset option which accepts a number as an
input parameter. This number specifies the number of bytes
to be added to the address contained in the message before
determining the final starting address for the action.
For the WHEN command, offsets are added to the address of
a function (determined symbolically) to determine the final
address of the breakpoint (this is a description of relative
offsets). In any other UT command, an offset is illegal
unless an indirection is indicated. The offset in these
commands is added to the data found at each level of
indirection.
OPC: This is the OPCODE option which accepts a number as an
input parameter. This number is expected to be a match to
the OPCODE instruction found in the target processor's
memory at the given address. The OPCODE must be a 2-byte
value. If this parameter does not provide a match, the
WHEN command will not be accepted
by UT in the target processor.
PARM: This is the parameter option used to supply the data
needed by a function which is being called by the user.
All parameters must be 2 bytes each. If more than one
parameter is to be entered, they should be entered as a list
separated by dashes (maximum of 10 values). If the
parameters are long words or addresses, two adjacent values
are combined by UT. The order of the 2 bytes combined will
change with the type of processor (see AT&T 235-600-700,
Input Messages Manual, for details). If a function
needing parameters is called, but insufficient or no
parameters are provided, the parameters will be taken from
the stack UT is currently running on.
PLUS: This is one of the optional keywords used in the COPY
command. This indicator causes the data defined in the
optional third field of the command to be added to the
source field of the command before the copy of data is
performed.
PRIM: This is a key word which causes the action to occur
only to the active processor. This key word is used by UT
to indicate the CMP which is logically active. Output
messages printed will indicate which physical CMP is
active.
REG: This key word accepts the symbol of a single MC680XX
microprocessor as an input parameter. The symbol identifies
which register is to be acted upon. A set of dummy
registers is used for the operation if the command is not
part of a WHEN breakpoint clause.
REGS: This key word specifies that the contents of all the
MC680XX microprocessor registers be dumped. A set of
dummy registers is used for the operation if the command
is not part of a WHEN breakpoint clause.
SIZE: This key word accepts a number as an input parameter.
This number is used to define the size of each value
(number of bytes) to be written into the target processor's
memory. The size of each value (long word, word, or byte)
must be constant for the message.
TIME: This key word accepts a number as an input parameter.
The number is in milliseconds and defines the time interval
between successive executions of this timed WHEN clause.
UTIL: This key word indicates that the operation is to be
performed on all WHEN command clauses in the specified
processor.
UTILFLAG: This key word accepts a number as an input parameter.
The number is a unique label which identifies a WHEN
command in the specified processor. Checks are performed
to make sure the label is unique.
UVAR: This key word accepts a number as an input parameter.
The number is an index (starting at zero) of an array of
longs in the specified processor's memory. This memory is
owned by UT and can be used by maintenance personnel as a
temporary storage location.
VAL: This is the value option used to provide the data or
constant to be used in the operation. If more than one
value is to be entered, they should be entered as a list
separated by dashes. The number of values allowed in the
list varies from message to message.
Refer to AT&T 235-600-700, Input Messages Manual, for details
on specific input messages and AT&T 235-600-750, Output
Messages Manual, for system responses.
The scripting capability allows the user to create a file on
the UNIX operating system using the MCC terminal. The file,
created in advance consisting of WHEN-clause sequences, would
be executed at a later time from the MCC terminal. The
following is a typical scripting scenario.
a. The user creates a file (a series of UNIX operating
system commands) similar to the following:
IN: FILESYS: DIR, DN "/tmp/script";
IN: FILE: APND, FN "/tmp/script", LINE 1!
"/cft/bin/pdshl "WHEN:UT: SM=1, ADDR=X'51008, OPC=h' 321A,
UTILFLAG=0 ;
IN: FILE: APND, FN "/tmp/script", LINE 2!
"/cft/bin/pdshl "ALW:UT: SM=1,UTILFLAG=0 ;
IN: FILE: APND, FN "/tmp/script", LINE 3!
"/cft/bin/pdshl "INH:UT: SM=1, UTILFLAG=0 ;
IN: FILE: APND, FN "/tmp/script", LINE 4!
"/cft/bin/pdshl "OP:UT: SM=1, UTILFLAG=0 ;
b. The file is enabled by typing the following command:
ALW:FILESYS:ACCESS "755", FN "/tmp/script";
c. The user can now execute the file from the MCC terminal
by typing the following command:
EXC:ENVIR:UPROC, FN "/tmp/script";
where ``tmp'' represents the complete path to the file,
and ``script'' is the filename. The EXC command
executes the file which, in turn, executes the input
commands in the file.
d. The following command removes the file:
CLR:FILESYS:FILE, FN "/tmp/script";
There are also commands to delete, replace, and append
lines to a file. For additional information, refer to
AT&T 235-600-700, Input Messages Manual.
In the 5ESS switch, hardware and software errors generate
reports or messages. These reports come in several forms
[for example, audits, asserts, or processor recovery messages
(PRM)] and generally provide information about what has
happened. The reports, with the exception of PRMS, may be
printed at the ROP, collected in a log file, or both. The
PRMs may only be printed at the ROP. The message class of
the report determines its handling or disposition.
The purpose of the log files is to reduce the number of
messages being printed at the ROP and still maintain gathered
information. The log files can be used for:
o Detecting and correcting transient errors before they
cause system outages. For example, AM correctable
memory errors can occur at an increasing rate over many
days. This problem can be detected by studying the log
file entries and making corrections to errors before
they occur at a rate high enough to cause automatic
recovery actions.
Note: Transient errors are usually not detected
by diagnostics because of their transient
nature. However, sufficient information
exists in the log file entry to determine
the cause.
o Determining the sequence of events that led to an
initialization or maintenance interrupt. Each event in
a log file has time-of-day information and sequence
numbers. A study of this data can help determine
possible machine problems. For example, if multiple
errors caused an excessive error rate and triggered an
initialization, the sequence numbers indicate the order
of occurrence and the time stamp can verify that the
occurrence was sufficiently short to cause the
initialization.
Entries from several log files may have to be pieced together
to give a chronological order of events. Recreating the
order of events is most easily accomplished by examining
printouts of all the appropriate log files.
There are two basic forms of log files in the 5ESS switch:
UNIX RTR system log files and log files for the rest of the
switch. A number of UNIX RTR system log files (for example,
CONFLOG, MEMLOG, and PMLOG) contain specific types of
messages. The MEMLOG file, which is the memory history file
for the AM, contains supplementary data for memory error
interrupts. The log files for the rest of the switch may or
may not contain specific material. For example, log files
such as RCLOG and ECDLOG contain specific information, but
this is not true of the DAYLOG file. The DAYLOG file
contains information from all of the SMs and attached
peripherals (for example, PSUPH), the CMP (added in 5E6), and
most of the application error reports from the AM (for
example, application audit failures).
The log files are defined in the classdef and device forms in
the ECD. All log files in 5E6 and later software releases
are contained in the directory, /log/log.
Any entry made in a log file is an indication of trouble.
Often a report will be printed on the ROP indicating the
problem. However, maintenance personnel would have to look
in the DAYLOG file for a detailed reason for the report. For
example, a defensive check failure will print on the ROP, but
associated stack traces, stack frames, and register dumps
would be stored in the DAYLOG file.
Log files are constrained by size limitations. The size of
log files is handled in one of two ways depending on the type
of file:
1. UNIX RTR system log files are limited in size to prevent
system overflow. When a log file is first created, the
file is called XXXXX1, where XXXXX stands for the log
name. When half of the disk space is used, the contents
of XXXXX1 are copied into XXXXX0. The most recent
information is again stored in XXXXX1. When all the
disk space is used, the ``1-part'' is again copied into
the ``0-part'' overwriting the oldest data. This
process will continue indefinitely.
2. In 5E6 and later software releases, the DAYLOG file will
be handled like a UNIX RTR system file. This means that
the most recent information is contained in DAYLOG1, and
older information is contained in DAYLOG0.
To help maintenance personnel determine if minor problems
exist in the switch, a set of messages can be used to operate
on the log files. Following is a basic list of
functionalities provided and the commands to use for each:
1. View the entire log file or its specific parts:
Commands give a user the ability to view a file on the
basis of time (starting time and ending time are used),
view certain message classes, or view reports coming
from a particular unit (for example, SM=3).
Combinations of options can also be requested. The
OP:LOG command can be used in all software releases for
the UNIX RTR system log files and for the DAYLOG log
file in 5E6 and later software releases.
The correct syntax and detailed information about
command parameters can be found in AT&T 235-600-700,
Input Messages Manual. Care should be taken when
printing these files on the ROP because some files can
hold over 1800 reports. When this many reports are
being printed, messages for the current time frame may
not be seen for some time.
2. Determine routing status of message classes: The
routing status of message classes can be determined by
using the OP:LPS:MSGCLS command. This command outputs
the current log/print status of all or specific message
classes. It can also be used to determine where all
message classes are being sent [as can poke command 902
on MCC Display Page 110]. See AT&T 235-600-700, Input
Messages Manual, for detailed information about this
command.
3. Change routing status of message classes: The routing
status of message classes can be changed by using the
CHG:LPS command. This command permits a user to define
where the reports will be sent [for example, logged,
printed, both logged and printed, or neither (in which
case the message is discarded in the generating
module)]. The routing status can be changed on all
messages or on specific message classes.
4. Use OP:STATUS:DATA,LISTDIR command to obtain
information: The command OP:STATUS:DATA,LISTDIR can be
used to obtain a list of files in a directory, their
current sizes, and other information. The list of files
produced may include some with the name rmfxxxx, where
xxxx is any number. These files are generated when the
AM is not sane enough to write to the log files. After
these files are examined, they should be removed by
using the CLR:FILESYS:FILE command.
Refer to AT&T 235-600-700, Input Messages Manual, for
detailed information on syntax, parameters, and format
for both the OP:STATUS:DATA and CLR:FILESYS:FILE
commands.
A core dump takes place if certain faults occur or if a
termination message requests one. Core dumps are images of
the run-time state of processes that have been placed on disk
in the /cdmp directory (or in a user defined directory
specified by the termination message).
Generally, a core dump implies an abnormal process
termination. A core dump should be investigated to determine
the cause of termination. Each site should save the core
dump files when log files are saved, or as often as
necessary. Core dump files must be removed periodically to
allow enough space for future core dumps.
Note: Files in the cdmp directory may not be useful to
the office personnel. However, these files
should be saved (just as log files and ROP
output are saved) for forwarding to the
technical assistance organization, if necessary.
Diagnostic maintenance programs are integrated into the 5ESS
switch hardware and software to provide self-diagnosis and
trouble-locating capabilities for hardware faults. The
diagnostics programs are controlled by the maintenance fault
recovery, maintenance personnel, and routine exercises. Once
the diagnostic has been initiated the unit will be removed
from service and tested. When fault indications are found
and the correct input message options are used, information
will be printed which identifies the board or circuit that
needs replacing. This is known as the trouble location
procedure (TLP). The TLP provides a fast method for
determining the cause of a hardware fault and therefore, its
correction. After the trouble has been repaired, the unit
can then be restored. This is done automatically by
autonomous recovery actions or manually by maintenance
personnel.
To better understand the actions of diagnostics in the
system, some of the following sections are separated into
diagnostics in the UNIX RTR operating system area, and
diagnostics in the CM and SM.
Diagnostics can be invoked from three separate sources;
maintenance fault recovery (FR), craft requests, and routine
exercises (REX). The FR requests are made when operational
errors are detected and identified in a particular hardware
unit. These are called automatic (AUTO) requests. Craft
requests via input messages on the MCC generate manual (MAN)
requests. REX generates both AUTO and MAN diagnostic
requests. The OSS REX Scheduler program generates AUTO
requests, while a REX request by craft generates a MAN
diagnostic request.
The type of request (AUTO, MAN, or REX) determines a
particular set of diagnostic test phases to be run. Each
hardware unit type has a unique set of test phases and
execution options dependent on request type. Information on
specific hardware units is contained in AT&T 235-105-220,
Corrective Maintenance Procedures.
The automatic diagnostics process schedules diagnostic and
restorals of units not brought up at boot (initialization)
time and when units are removed through fault recovery
actions. When the diagnostic is run as part of a fault
recovery action, one of two basic actions occurs.
o The unit passes the diagnostic testing and is restored
to service. This is indicated by some form of a restore
completed message, although these messages will have
various forms for the different units.
o The unit fails the diagnostic testing and is not
restored to service. As part of this failure,
information will be printed on the ROP indicating the
failing phase and the hardware that is most probably
bad. This automatically provides maintenance personnel
with the information needed to recover from a hardware
failure without having to perform the diagnostics
manually. As indicated previously, the output messages
which provide this information will have various forms
for the different units.
The diagnostics which are run automatically utilize the same
commands that craft personnel would use for manually
diagnosing the units. The commands use enough of the
diagnostic options to provide the needed information without
the craft having to run it manually, such as the TLP option.
All of these options will be discussed in the Manual
Diagnostics section of this document (following) and in
greater detail in the appropriate pages of AT&T 235-600-700,
Input Messages Manual.
Manual diagnostics provides the maintenance personnel the
ability to force specific options of diagnostic commands or
control diagnostics when automatic recovery actions are
inhibited. These commands will be split into two categories:
AM diagnostic commands and the rest of the system diagnostic
commands.
The basic form of the diagnostic input message is as follows:
DGN:unit=a,subunit=b;
For input/output processor (IOP) and disk file controller
(DFC) diagnostics where no subunit is specified, the basic
input messages are as follows:
DGN:IOP=a:<optional key words>
or
DGN:DFC=a:<optional key words>.
(Optional key words are defined in AT&T 235-600-700, Input
Messages Manual, and under the following full command
format example).
When each of these commands is entered, the named unit and
all units under it in the diagnostic hierarchy will be
tested. Table .AW TZ/ shows the diagnostic hierarchy. The subunit
designation is optional and is used only when a specific
subunit of the CU (control unit) is being diagnosed.
In addition to the basic diagnostic input message, eight
optional parameters may be specified. The full command
format is:
DGN:unit=a[,subunit=b][:[RPT=c][,RAW][,UCL]
[,REX|,DEX]][,[PH=d[&&e]][,CONT][,TLP][,f]];
Descriptions of the optional fields are as follows:
o RPT= (Repeat). Indicates the diagnostic should be
repeated c times. The maximum is 256.
Note: The RPT option does not override early
terminations. The UCL should also be
specified if the diagnostic terminates.
o RAW= Indicates the diagnostic results of every phase
should be printed. If all tests pass, this fact is
printed. If any failures occur, data from up to 100
failing tests is printed. If you do not use the RAW
option, only the first five failures per phase are
printed.
o UCL= (Unconditional). Indicates the diagnostic should
be unconditionally executed with no early terminations.
The basic diagnostic contains many early termination
points. If one of these points is reached and previous
tests have failed, the diagnostic does not continue.
This may occur for two reasons:
o Data obtained from the previous tests is sufficient
to uncover the problem.
o If previous tests have failed, going further may be
dangerous.
Caution: The UCL option should not be specified
unless absolutely necessary since there
is a risk of the diagnostic structure or
the operating system crashing.
o REX= (Routine exercise). Requests that automatic and
routine exercise phases within the specified range be
run. If no range is specified, all automatic and
routine exercise phases are run.
o DEX= (Demand exercise). Requests that automatic,
routine, and demand exercise phases within the specified
range be run. If no range is specified, all automatic,
routine, and demand exercise phases are run. Variable d
specifies the phase or range of phases.
o PH= (Phase). Requests either a particular phase or a
range of phases (in the form first-last). This may be a
subset of the automatic phases and/or a demand phase or
phases. Using the PH option is the only way that demand
phases can be run. See AT&T 235-105-220, Corrective
Maintenance Procedures, for the complete list of phases
(that is, routine demand phases and supplementary demand
phases for IOP, CU, and DFC).
o CONT= (Controller). Specifies that subunits under the
requested unit (and subunit) are not to be diagnosed.
Due to limitations in the DFC and IOP drivers, the CONT
option is the default for DFC and IOP diagnostic (DGN)
requests. The CONT option is also available for the
direct memory access (DMA) subunit of the CU.
o TLP= (Trouble location process). Generates a circuit
pack list if failures are detected by the diagnostic.
Note: The UCL and TLP options should not be
specified together because a TLP output of
reduced accuracy can be produced.
Within the diagnostic system, demand phase selection allows
pinpointing problems or potential problem areas. Demand
phases are optional and test specific units and subunits
within the diagnostic hierarchy. The following guidelines may
be helpful in understanding the demand diagnostics:
o A phase is marked as demand because it takes a long time
to run, requires manual intervention, or should not be
run automatically. The demand phase, when requested,
tests part of the unit specified.
o Diagnostic demand phases are grouped in the same
hierarchy as other diagnostics (CU, DFC, and IOP).
o Demand phases are normally requested when standard
routine diagnostics do not locate the problem area or
can be requested as part of a preventive maintenance
plan.
o Some phases take up to 40 minutes to complete.
o Some demand diagnostics require special procedures
(refer to AT&T 235-105-220, Corrective Maintenance
Procedures).
This demand diagnostic phase needs some special attention.
When invoked with the EX input command, main store controller
(MASC) phase 95 accepts input parameters from EX:LDPARM. The
MASC phase 95 allows the user to supply the address range to
be tested on the MASC (default is entire address range); the
data pattern and complement (default=0xffffffff and
complement=0x0000000); and the refresh rate, 2 ms standard or
4 ms extended (default). To execute MASC phase 95, use the
following procedure:
1. Determine the address range of the main store arrays
(MASAs) to be tested by using the information shown in
Table .AW TAC/. The MASC 0 starting address is X'0. End
addresses are determined by the number and type of
MASAs.
2. Using the STANDBY or OOS CU, enter:
EX:CU=a,MASC=b:<optional key words>,PH=95,TLP;
where a = control unit (0 or 1) and
b = main store controller (0 or 1).
(Optional key words are defined in AT&T 235-600-700,
Input Messages Manual.)
The machine responds with a message that the diagnostic
started and gives a task (or slot) number.
3. Enter:
EX:LDPARM:CU=a,MASC=b:,SA=H'[starting address],
EA=H'[ending address]REF=4,PAT=H'5A5A5A5A;
Other good choices for PAT value are as follows:
A5A5A5A5
FFFFFFFF
0
Use the information shown in Table .AW TAC/ for starting and
ending address.
The machine responds with a message indicating the
chosen parameters and runs the diagnostic.
4. If the diagnostic fails, use the information generated
by the TLP option to correct the problem. Rerun phase
95 diagnostics starting with Step 2.
5. Restore the CU (RST:CU), softswitch (SW:CU), and run the
same diagnostic sequence on the other CU.
Diagnostic requests must be inhibited (always denied) while a
field update is applied to the diagnostic files. Stop
entering manual requests and perform the following procedure
to inhibit automatic requests:
1. Enter: INH:DMQ:SRC=a,TINH=b,AINH=c; to inhibit (always
deny) automatic diagnostics. The options have the
following meanings:
SRC a= The source of the requests to be denied.
This may be either ADP, REX, or ALL.
TINH b= The number of minutes the inhibit is in
effect. The default is infinity.
AINH c= The number of minutes between warning
messages informing the user that an
inhibit is in effect. The default is a
message every 5 minutes.
2. Observe the following warning message:
Warning: DGN:INHIBIT a ACTIVE,REMAINING TIME n MIN
or, for an infinite inhibit, DGN:INHIBIT a ACTIVE.
3. The inhibit may be deactivated manually by entering the
following commands:
Enter: ALW:DMQ:SRC=a;
4. Observe the following output message indicating that the
inhibit is deactivated: ALW DGN ENABLED a
Only automatic diagnostics may be inhibited. A request to
inhibit a manual source is denied, and the following message
is output:
INH CAN'T INHIBIT A MANUAL SOURCE - source.
Also, only a limited number of inhibits may be active at one
time. If this limit is reached, further inhibit requests
result in the following message:
INH TOO MANY ACTIVE INHIBITS.
In this case, another source must be allowed or the ALL
source must be used in place of all currently active
inhibits.
To obtain information on the status of a diagnostic, enter:
OP:DMQ;
The output from this command indicates the slot number [the
number on the far left in the sample from OP:DMQ; (Figure
.AW G109/)] and the queue assigned to a particular job. Slots that
are inactive (are not assigned to either queue) are not
displayed.
It may be necessary to cancel a request in the waiting queue
or to abort a request in the active queue if:
o The request was entered by mistake.
o A request of high importance is in the waiting queue,
and an active queue must be cleared to make room.
o An interactive diagnostic is to be executed.
o The active and waiting queues of all requests must be
cleared for the field update of diagnostic files.
This is the procedure to use when aborting or canceling a
request.
1. Enter OP:DMQ;
The output from this command indicates the slot number
and queue assigned to a particular job. (See Figure .AW G109/
for an example of this output.)
Note: Slots that are inactive (not assigned to
either the active or waiting queues) are
not displayed.
The source in the output message may be (but is not
limited to) one of the following:
o ADP: Automatic diagnostic process.
o MAN: Manual requests input by the user.
o PSM: Power switch monitor. This request is either
a remove request on a unit when the request-out-
of-service (ROS) key on the unit power switch is
activated or a restore request when the ROS key is
released. The PSM requests are classified as
manual.
o REX: Routine exercise.
2. To abort a job in the active queue or to cancel it from
the waiting queue:
Enter STOP or STP:DMQ:[unit=a,subunit=b][,ACTIVE|,WAITING];
(Valid units and subunits are defined in AT&T 235-600-700,
Input Messages Manual.)
It is necessary to remove and restore units when applying a
hardware change or when you wish to prevent automatic
restoration of a unit you suspect may be faulty.
To remove a unit, enter:
RMV:unit=a;
To restore a unit, enter:
RST:unit=a:UCL:DATA,CONT;
When a unit is removed from service or restored to service,
all units under it in the hierarchy are also affected.
However, if the CONT option is specified for the restore, the
subunits are not affected. If a diagnostic is available for
a unit, it is executed before the unit is restored unless the
UCL option is specified. The restore is denied if the
diagnostic fails. An entire CU must be restored and removed
at the same time; its subunits may not be handled separately.
Subunits in the DFC and IOP may not be restored unless all
units above them in the hierarchy are restored.
Occasionally hardware change notices (CN) that require a
change in the diagnostic program are issued to the field.
These CNs specify changes to the unit control block (UCB)
that must be entered into the equipment configuration data
base (ECD). These changes should be implemented with the
following procedure:
1. Enter RMV:unit=a; to remove the affected unit from
service.
2. If the affected unit is a CU, activate key 13 on the
emergency action display page. This deactivates any CU
force that is in effect.
3. Install any updates to the diagnostic program using
standard field update procedures.
4. To diagnose the affected unit and verify that it is ATP,
enter:
DGN:unit=a:<optional key words>,TLP;
(Optional key words are defined in AT&T 235-600-700,
Input Messages Manual.)
5. Install the new hardware.
6. Update the UCB for the affected unit using the recent
change and verify (RC/V) system. (See the RECENT
CHANGE/VERIFY section (Section .RM 3.10/) in this manual to
identify the correct RC/V manual to reference.) Four
separate transactions are required. Each transaction
requires entries to the trbegin, ucb, and trend pages.
The transactions are as follows:
(a) Change the unit status from OOS or unavailable
(UNAV) to unequipped (UNEQ).
(b) Change the unit UCB fields to the values as the CN
directs.
(c) Change the unit status from UNEQ to GROW.
(d) Change the unit status from GROW to OOS.
7. To diagnose the unit and verify that the change was
installed correctly, enter the following:
DGN:unit=a:<optional key words>,TLP;
(Optional key words are defined in AT&T 235-600-700,
Input Messages Manual.)
8. Activate the recent change to the UCB using the activate
RC/V page.
9. To restore the unit to service, enter the following:
RST:unit=a:DATA,TLP,CONT;
Note: If the change is applied to more than one
unit, all steps should be completed for
each unit before beginning work on the next
unit.
The CM and SM diagnostic operations differ from that of the
AM described previously. The following is a high level
description of the operations of the CM and SM diagnostic
functions. Detailed information on specific hardware modules
can be found in AT&T 235-105-220, Corrective Maintenance
Procedures, and AT&T 235-105-210, Routine Operations and
Maintenance Procedures.
Demand diagnostics refer to test phases of a particular
hardware unit type that are not normally run by either MAN or
AUTO requests from all sources. These phases are usually
very time consuming and in most cases only useful in finding
a small percentage of unusual hardware failures. These
demand phases can only be invoked by craft requests that
specify a specific range of test phases.
For example, if a hardware unit has five test phases numbered
1 through 5, and phases 2 and 4 are demand phases, only
phases 1, 3, and 5 would execute under normal circumstances.
To force the execution of the demand phases, the craft must
enter a message on the MCC of the following form:
DGN:unit=x-y-z,PH=1&&5;
With this input message, all five diagnostic test phases will
execute, including the demand phases.
When the craft desires to execute a diagnostic on a CM or SM
hardware unit, a message of the following form is entered on
the MCC:
DGN:unit=x-y-z,PH=a&&b,TLP;
The verb DGN requests that a diagnostic be executed. UNIT
denotes the unit name of the circuit to be diagnosed,
followed by the unit number. The PH qualifier is an option.
If specified, only the diagnostic test phases a through b are
executed. If not specified, all non demand phases are
executed. The TLP qualifier requests that if a diagnostic
test fails, the Trouble Location Procedure (TLP) report that
identifies the suspected faulty equipment be printed on the
ROP. Specific details for all CM and SM hardware unit
diagnostics are contained in AT&T 235-600-700, Input Messages
Manual.
Each SM may have up to eight diagnostics in a running or
waiting state due to requests from any or all sources. To
view the diagnostic status of a particular SM, the following
message is entered at the MCC:
OP:DMQ,SM=[SM number 1-192];
A report of the following form will be printed on the ROP:
OP DMQ SM 107 LAST RECORD
ACTION UNIT SOURCE STATUS
RST MCTSI=1-0 AUTO RUNNING
DGN TAC=1-0-1 MAN WAITING
The report heading either indicates CM for Control Module or
the Switch Module number. In this case, the report is for SM
107. The report indicates the action being taken. In this
example, the two actions are a restoral (RST) and a
diagnostic (DGN). The unit name and number are contained in
the UNIT column. The source of the requested action is shown
in the SOURCE field. The sources are AUTO and MAN in this
example. The STATUS indicates whether the action is either
RUNNING or WAITING.
It may at times be necessary to have the craft intervene and
stop one or more queued or running diagnostics. A two step
procedure is required to accomplish this. First, the craft
needs to get a dump of the diagnostic queue for the CM or SM
in which the diagnostic is to be stopped. This is done by
entering the following message on the MCC:
For the CM,
OP:DMQ,CM;
For the SM,
OP:DMQ,SM=[SM number 1-192];
A range of SMs is also possible with this command by
specifying two SM numbers separated by &&.
The report generated will show the status of all running and
waiting diagnostics for the CM or selected SM(s). Both
running and waiting diagnostics may be stopped. The craft
then decides which diagnostic is to be stopped, and enters a
message of the following type:
STP:DGN,unit=x-y-z;
The unit name and number are obtained from the previous DMQ
report.
Note: The STP:DGN command will not stop diagnostics
that are running as a result of a restore done
on a piece of hardware. For example, suppose a
conditional restore was done on a protocol
handler (PH). An OP:DMQ on the SM that contains
the PH will show a restore (RST) action is
running on that PH. The ROP will proceed to
show diagnostics that are running as a result of
the restore. To stop the process, the craft
should enter STP:RST,unit=x-y-z; or STP:unit=x-
y-z;. These commands are valid for both SM and
CM processes.
When the diagnostic stops, a message will print on the ROP
indicating this fact, and the MCC page display for the
selected unit will change its status display from OOST to
OOS. The unit will be left in the OOS state after a STP
command is executed. If the STP command does not stop the
desired diagnostic, the following command will always
terminate it:
ABT:DGN,unit=x-y-z;
Use this command with caution. It will always eliminate the
requested diagnostic, but does so in a brute force way,
causing several audit and assert reports to print on the ROP.
After the ABT completes, the hardware unit will likewise be
left in the OOS state.
Whenever a hardware unit is to be removed from service by the
craft for any reason, the following message is entered on the
MCC:
RMV:unit=x-y-z[,UCL];
If the hardware unit is actively involved in a call, the
request will be denied, unless the UCL option is included. A
UCL removal request always removes the hardware from service;
however, calls set up using the affected hardware will be
torn down, causing one or more lost calls. The UCL option
should only be used when the customer is willing to accept
this service affecting action.
Whenever a hardware unit is to be restored to service by the
craft, the following message format is entered on the MCC:
RST:unit=x-y-z[,STBY][,UCL];
If the hardware is a duplex unit, having two duplicate,
redundant circuits, either capable of providing its intended
function, the inclusion of the STBY option will restore the
requested unit to its standby state. In this case, the mate
unit will be providing the intended service. The standby
unit is ready to take over control of the active unit at any
time it is needed. Omission of the STBY option, results in
the selected unit being restored to the active role and the
mate unit being made standby.
A normal restoral request will execute the hardware circuit
diagnostic, and if all diagnostic tests pass, the unit is
restored to its active, in-service state. Including the UCL
option, omits the diagnostic execution and directly restores
the unit to its active, in-service state.
Occasionally, hardware changes which are packaged and
distributed as Change Notices (CN) require changes in the
associated diagnostic program. These CNs specify changes to
the Change Level Indicator (CLI) for the hardware circuit and
must be coordinated with the new diagnostic program update.
The details for coordinating the hardware and software
changes are found in AT&T 235-105-231, Hardware Growth
Procedures.
If an automatic or manual diagnostic encounters trouble, a
message is output. There are three basic scenarios for this
procedure.
When a unit is automatically removed from service, a major
alarm is sounded and a message is output to the MCC and ROP.
A diagnostic is automatically requested by the ADP with the
TLP option specified. You may verify that a diagnostic is in
progress by entering OP:DMQ;.
If no diagnostic is in progress, begin one by entering
RST:unit=a:DATA,TLP;.
A TLP circuit pack list will be produced.
At the completion of a routine automatic diagnostic (that is,
REX), a summary table is printed. Any units that have failed
are marked some tests failed (STF), and a TLP circuit pack
list is produced.
Manual diagnostics also produce an output message. If the
TLP option was specified, as is recommended, a TLP circuit
pack list is also produced.
The failed test data in the output message and the TLP
circuit pack list are your tools for locating and correcting
trouble.
The diagnostic output message consists of a header line
followed by the failed test data (if failures occurred).
(See Figure .AW G110/ printout of diagnostic failure.) The header
line identifies the unit (for the CU and subunit), the phase
number, and the phase results as described in Table .AW TAA/. If
there are test failures or if all available tests are not
run, the number of test failures and the conditional test
result words appear in parentheses on the header line. The
two conditional test result words are 64 bits numbered from 0
to 63 starting from the right. When a bit is set, it
indicates why some or all of the phase tests were not run.
See Table .AW TAB/ for explanation of conditional test results.
If there are test failures, the header line is followed by a
5-column failing test display. The TEST column identifies
the failing test numbers in the phase. Unless the RAW option
was specified on the diagnostic request, only the first five
failing tests will be printed. The MASK column indicates
which bits are actually included in the test. A one in the
MASK means that bit is part of the test. The ACTUAL column
displays the results read from the hardware under test. The
EXPECTED column displays the expected results. The MISMATCH
column indicates which bits failed the test.
The data in the MISMATCH column is derived from the ACTUAL,
MASK, and EXPECTED data in the following manner. First, the
ACTUAL and EXPECTED data are EXCLUSIVE ORed, which yields a
one in the bits that are not in agreement. Second, the
results of the EXCLUSIVE OR are logically ANDed with the MASK
to filter out disagreeing bits not included in the test. The
ACTUAL, MASK, and EXPECTED data are not available for some
AT&T 3B20D computer peripheral unit diagnostics. When this
is the case, ``N/A'' (not available) is printed for the
ACTUAL, MASK, and EXPECTED data.
Failure data for faults detected in main store is also output
in the form of a histogram. (See Figure .AW G111/ for an example.)
A data pattern is 40 bits wide: 32 data bits, 4 hamming
bits, and 4 parity bits. The address spectrum is divided
among several memory arrays (circuit packs) as shown in Table
.AW TAC/. When the data pattern read back from the store does not
match the one that was written, a failure has occurred.
Memory testing stops after the first 100 faults are detected.
A detailed failure analysis is output for the first fault.
This includes the failing address, expected value, received
value, mismatch for both the data and parity bits, and a dump
of three main store controller registers. The number of
addresses that failed and a list of the first five failing
addresses is next followed by the memory failure histogram
which shows:
o For each data, hamming, or parity bit, how many times
the bit failed as a 0 and how many times the bit failed
as a 1
o For each address bit, how many times the bit failed as a
0 and how many times it failed as a 1
o How many multibit errors were detected
o How many error-logic failures were detected (single
bit-error indication on a multibit error).
The numbers in these columns can be used to determine the
location and extent of the problem. For example, in the DATA
FAIL columns, a 1 indicates a single memory-cell failure and
a 100 indicates a fault on a data signal path. If the counts
for a particular bit are approximately equal, the bit is
probably good. But, if on all failures a particular bit
always has the same value, then the bit is stuck at that
value.
Note: The upper address bits select the memory array.
They usually appear as stuck bits, because the
effect of a fault is usually isolated to one
memory array circuit pack.
In the example shown in Figure .AW G111/, data bit 24 is stuck at 0
but only when address bit 2 is 0. The address bit is the
array half-select. Therefore, since the main store under
test contains TN14s, the fault is that the data bit 24-signal
path is stuck at 0 for the A-half of memory array 2.
The TLP option of the DGN command produces a list of
suspected faulty circuit packs when a diagnostic fails. A
circuit pack list is output after the diagnostic has
completed. Figure .AW G112/ is a sample TLP circuit pack list.
The pack most likely to be faulty is listed at the top
followed by other suspected packs in descending order. For
each pack, the following information is given:
o Code (circuit pack type)
o EQL (equipment location) (for example, 60-042, where 60
= vertical coordinate in the cabinet and 042 =
horizontal coordinate in the cabinet)
o SD (schematic drawing) number and the FS and symbol
(SYM) number within the SD
o Unit in which the circuit pack resides (if not the unit
under diagnosis)
o WT (Weight) on a scale from 1 to 10 with the circuit
packs most likely to be faulty given a 10.
Note: If the note field is nonzero, consult AT&T 235-
600-750, Output Messages Manual, for further
information.
At various points within the diagnostic control structure,
audits are performed to verify that all is well. These
include verification that:
o Called functions do not give bad return codes.
o Needed system resources are available.
o Necessary files can be opened and read or executed.
o Hardware errors have not occurred.
o Illegal operations are not attempted.
If an audit fails, a report is printed on the maintenance
terminals. You should respond to an audit report as detailed
in the following procedure:
1. If a test fails prior to an audit failure, clear the
problem indicated by the test failure. This may also
clear the audit failure.
2. Consult AT&T 235-600-750, Output Messages Manual, to
determine the reason for the audit failure. It may be
due to a situation you can control. For example, an
attempt to execute a nonexistent diagnostic phase would
cause an audit failure.
3. Save the printout pertaining to the diagnostic request
and return it to your technical assistance organization.
4. Consult AT&T 235-600-750, Output Messages Manual, to see
if any additional data should be collected and returned
to your technical assistance organization.
An audit failure within the DIAMON appears as follows:
REPT DIAMON ERROR = a ERRNO = b
The numbers following ``ERROR='' and ``ERRNO='' are system
error numbers. The meanings of these error numbers are
defined in AT&T 235-600-750, Output Messages Manual.
Whenever a hardware unit diagnostic is executed by the craft
or through a fault recovery (FR) request, several output
messages are printed on the ROP giving the results of the
requested diagnostic.
Whenever a hardware diagnostic is completed successfully,
messages of the following format are printed on the ROP:
DGN UNIT=x-y-z COMPLETED ATP PH a
This message indicates that Phase (PH) a of the diagnostic
completed successfully, having All Tests Pass (ATP). One
message of this format is printed for each test phase that
completes successfully.
At the completion of all diagnostic test phases, the
following message is printed on the ROP:
DGN UNIT=x-y-z COMPLETED ATP
This message indicates that the hardware unit diagnostic has
completed its execution, and that all tests that were
executed were done so successfully.
Whenever a hardware unit diagnostic fails any diagnostic test
phase, the following messages are printed on the ROP:
DGN UNIT=x-y-z STF PH a SEG b TEST c MM H'hhhh
This message indicates that Phase a, Segment b, Test c
failed. The MisMatch (MM) field gives the test data for the
indicated test. Further details of the use of the MM data is
found in AT&T 235-105-220, Corrective Maintenance Procedures.
DGN UNIT=x-y-z COMPLETED STF PH e
This message indicates that the Phase (PH) e completed
execution, and that Some Tests Failed (STF) during its
execution.
DGN UNIT=x-y-z COMPLETED STF
When all requested test phases have completed execution, this
message is printed to indicate that the requested diagnostic
has completed; and that during its course of execution, one
or more tests have failed.
Whenever hardware unit diagnostic program is executed and any
test fails, a hardware fault has been detected. If the
Trouble Location Procedure (TLP) option has been included in
the diagnostic input message, and a hardware failure is
found, a TLP list is printed on the ROP indicating the
suspected faulty equipment for the diagnostic test phase that
failed. Figure .AW G113/ is a sample TLP list for a diagnostic
failure.
The intent of the TLP report is to give the location in the
switching office of the hardware unit that failed the
diagnostic. The AISLE is the equipment aisle, the MODULE is
the switch module, in this example, SM number 10. The
CABINET gives the cabinet number of the specified switch
module, in this case, LTP 2. CODE refers to the circuit pack
code that is at fault. The EQL is the equipment location in
the specified CABINET. The first number is the vertical
distance in inches from the floor to the faulty circuit pack.
The second number is the horizontal distance in eighths of an
inch from the left side of the specified cabinet. These
dimensions are rubber stamped on the equipment cabinets. The
TYPE field specifies the circuit under test as ---, ONL
meaning an on line interfacing circuit, or HLP for a helper
circuit. If some additional information is required, such as
specific repair procedures or precautions, the NOTE field
will contain a number. This number is defined in AT&T 235-
600-750, Output Messages Manual, Appendix.
The routine exercise capability provides the following:
o Scheduling of the routine diagnostics for hardware units
of all SMs
o Scheduling of the routine diagnostics for the CM based
hardware units
o Enhanced scheduling flexibility
o Control for the previous schedulers
o An improved craft interface
o Scheduling of electronics loop segregation (ELS) tests
and fabric tests of grids.
The purpose of REX is to routinely schedule testing in the CM
and/or SMs, in order to detect latent faults present in in-
service units. In other words, REX is an automatic scheduler
of tests. The types of tests that REX schedules are
dependent upon the module type (CM or SM).
a. In the CM, two types of tests are available for
scheduling. They are full and partial diagnostics. See
the descriptions that follow:
o Full diagnostic (DGN): Results in a conditional
restore request including the trouble location
process (TLP) option. For details of the TLP
option, refer to the TLP subsection within this
manual.
o Partial Diagnostic (switch): Results in a soft
switch of the pump peripheral controller (PPC), the
foundation peripheral controller (FPC), the office
network and timing complex (ONTC), and effective
with the 5E6 software release, the communication
module processor (CMP). No diagnostics are
executed.
b. In the SM, three types of tests can be specified:
o Full Diagnostics: Same results as indicated for CM.
o Fabric Exerciser (FAB): Tests the operation of the
gated-diode crosspoints (GDX) in the line unit (LU)
concentrator grids or grid boards. It requests a
path to each crosspoint to be tested by calling
peripheral control (PC) path hunt routines. A
series of tests are then performed on the
crosspoint and its associated path using a high-
level service circuit (HLSC).
o ELS: Tests customer lines to determine a suitable
network balance necessary to reduce the amount of
potential echoing in the transmission path. Office
data is updated, as needed, storing the proper
balance network value to be used in call setup.
Each module has its own REX schedule. A schedule is defined
as the start time and duration for each test type along with
a verbose option flag. The REX schedule resides in the
office dependent data (ODD) data base and can be changed
and/or displayed via recent change/verify (RC/V) mechanisms.
The REX program obtains the schedule from the ODD relation
``rlRXSCHD'' for the current day at midnight. Therefore, if
the REX schedule is modified, the new schedule is not
effective until the midnight following the change.
Also, REX provides the ability to turn off the REX schedule
without modifying the data base. This can be accomplished by
putting a module test type in an inhibit state via the
INH:REX command. The inhibit state remains active until it
is removed via the ALW:REX command. The inhibit status is
printed automatically at midnight so that the craft can keep
track of what modules have been inhibited or what modules
have individual units inhibited for test.
REX can be inhibited or allowed for a range of SMs with one
input message. Prior to the implementation of this
capability, REX had to be inhibited or allowed by entering a
message for each specific SM. The following input messages
illustrate a range of SMs being set up to allow and inhibit
REX:
o ALW:REX,SM=1&&20;
o INH:REX,SM=1&&20;
Two CM models are included in the 5ESS switch architecture:
communication module, model 1 (CM1) for configurations up to
48 SMs and communication module, model 2 (CM2) for
configurations up to 192 SMs. For the CM, REX schedules full
diagnostics for the message switch (MSGS) and the ONTC.
Growable units, that is, module message processors (MMP), are
scheduled as they become fully operational in the ODD data
base.
In both CM1 and CM2, the MSGS consists of the message switch
control unit (MSCU), the PPC, the FPC, the MMPs, and
effective with the 5E6 software release, the CMP.
o For the CM1, the ONTC consists of the link interface
(LI), the network clock (NC), the message interface
(MI), the time multiplexed switch (TMS), and the dual
link interfaces (DLI).
o For CM2, the dual message interface (DMI) replaces both
the MI and the LI to account for both the dual and
single fabric configurations of the TMS. The role of
the NC, TMS, and DLIs remains the same for CM2 as in
CM1.
In the SMs, the module controller/time slot interchange
(MCTSI) and its associated peripheral units are scheduled for
full diagnostics. The number and types of peripheral units
scheduled are based on how the SM is equipped.
Certain precautions must be observed when constructing a REX
schedule for the CM and SMs. The CM REX should not be
scheduled to run at the same time as the AT&T 3B20D REX
because all active CM diagnostics are aborted when a soft
switch of the Control Units (CU) is executed. This could
leave the ONTC or MSGS in a simplex configuration.
The SM REX schedule must be planned so that DGN, FAB, and ELS
tests do not run concurrently. Overlapping of these tests
results in resource contention which may abort some
exercises, cause tests to be skipped, or leave equipment out
of service.
For 5E7 and earlier software releases, a C-language based
program called the Operations Support System (OSS) REX
Scheduler Program is available to assist field technicians
with the construction of a viable REX schedule. Although
intended for use in the SCCS environment, the OSS REX
Scheduler Program will run on any UNIX operating system.
Customers may obtain the OSS REX Scheduler Program from the
Customer Information Center by paying shipping charges only.
Effective with the 5E8 software release, the new Automatic
REX Scheduler feature can be used to calculate and update the
REX schedule. This feature, which is integrated into the
5ESS switch software, performs the same logical function as
the OSS REX Scheduler Program. For more detailed
information, refer to Section .RM 3.20.5/, OSS REX Scheduler
Program, and Section .RM 3.20.6/, Automatic REX Scheduler.
AT&T 235-105-210, Routine Operations and Maintenance
Procedures, devotes an entire section to REX, the OSS REX
Scheduler Program, and the Automatic REX Scheduler. The
following list identifies what is covered:
o Purpose of REX
o REX Scheduling
o REX manual commands
o REX automatic scheduling
o REX MCC pages
o REX scheduling algorithms
o REX scheduling recommendations
o REX scheduling conflicts
o OSS REX Scheduler Program
o Automatic REX Scheduler
o Diagnostic failures
o Initiate REX scheduling
o Analyze EXC REX output message
o Stop test types of REX
o Request summary of valid REX test types
o Analyze OP REX (DGN, FAB) printout
o Analyze OP REX (ELS) printout
o Request REX status of CM and SM(s)
o Analyze OP REXINH output message
o List units that are inhibited for REX
o Analyze OP REXINH unit output message
o Inhibit valid test types for REX
o Inhibit scheduling of DGN REX test for a unit
o Allow one or all valid test types of REX
o Allow scheduling of a unit for REX DGN test
o Execute OSS REX Scheduler Program.
The OSS REX Scheduler Program is a non-switch resident,
support-system based program developed to ease the process of
customizing a REX schedule for 5E7 and earlier central
offices. (For 5E8 and later offices, see Section .RM 3.20.6/,
Automatic REX Scheduler.)
The process of customizing a REX schedule is divided into
four major phases as follows:
1. Data Collection: The user is prompted for pertinent
central office equipage data that is needed to create a
REX schedule.
2. Data Processing: The program uses formulas and
algorithms designed to reduce resource contention and
generates a REX schedule tailored to the configuration
of each central office.
3. Recent Change Script Generation: The program creates a
recent change file (valid for 5E6 and 5E7 software
releases) that can be executed from the SCC using the
SEND:OFC command. This allows the user to observe
message acceptance or rejection and to stop and restart
message transmission using available SEND:OFC command
options. The contents of the recent change APPTEXT file
will cause the 5ESS switch to update recent change views
8.1 and 8.3 automatically.
For example, SCC command
send:ofc;channel five.smtc, file rex.five!
will send the APPTEXT recent change messages in file
``rex.five'' to the central office over its second
maintenance channel.
Note: To prevent loss of messages on the logging
channel, the SCC should use a recent change
channel (if available) or a second
maintenance channel to execute the recent
change file.
4. REX Schedule Output: The program also generates a
printout of the REX schedule that resembles RC/V Views
8.1 and 8.3. If you elect not to use the recent change
script generated previously, this printout simplifies
the process of transcribing data from the schedule into
the 5ESS switch data base. It also reduces the
likelihood of input errors.
The OSS REX Scheduler Program has the following three
limitations:
1. Number of Switching Modules: The program cannot create
a viable schedule for central offices with more than 80
switching modules. This limitation is due primarily to
time frame considerations.
2. Number of LUs and ISLUs Per SM: For the reason cited
previously, the program cannot create a REX schedule for
central offices that have:
o Switching Modules with more than 5 ISLUs, or
o Switching Modules with 4 ISLUs and more than 1 LU, or
o Switching Modules with 3 ISLUs and more than 4 LUs.
3. Number of GDSU/TTF Responders (TN304B): The maximum
number of SMs concurrently executing ELS tests cannot
exceed the total number of TTF responders available for
testing. The program reserves one TTF responder for
ROTL and trunk testing and then schedules as many SMs as
possible for ELS testing. It creates an ELS overflow
list to identify the SMs that could not be scheduled for
the required number of hours. For these cases, one
alternative is to extend the duration of REX by either
starting it earlier or letting it run longer. The
office should also consider adding a responder board.
For additional information on the OSS REX Scheduler Program
and procedures for its use, refer to AT&T 235-105-210,
Routine Operations and Maintenance Procedures.
The Automatic REX Scheduler, a 5E8 software release feature,
eliminates the need to manually construct a REX schedule for
the central office.
The tool performs a data base read of the ODD to determine
office equipage and uses this information to construct an
optimum REX schedule. The Automatic REX Scheduler offers
several options including automatic updating of RC/V views
8.1 and 8.3 and printing of the REX schedule on the ROP.
Note: Verify that RC/V view 8.3 exists before
executing the Automatic REX Scheduler with the
update (UPD) option. If RC/V view 8.3 does not
exist (as with a newly grown SM), it must be
inserted or the Automatic Rex Scheduler will fail.
The basic command, entered at the MCC or TLWS, is as follows:
EXC:SCHED,[ALL|REX|ALIT];
where the choices in brackets indicate the scheduling
desired, whether REX, ALIT, or ALL (both). Details of input
and output messages to the ROP are shown in AT&T 235-600-700,
Input Messages Manual, and AT&T 235-600-750, Output Messages
Manual.
Options allow the user to specify (1) the days of the week
for which REX is to be scheduled, (2) the REX start time, and
(3) the REX duration. The user also may specify ALIT end
time and duration, along with the option to update the ODD
with the new REX schedule. When options are not specified,
the program will use a set of default options.
Default options are as follows:
REX REX runs 7 days a week, beginning at midnight and
running for 6 hours.
CM REX The CM REX begins at 1:00 a.m. and runs for 5
hours.
Note: ALIT runs every day, regardless of
options.
One of the goals of the Automatic REX Scheduler is to
construct a REX schedule that will result in the testing of
all equipment in the central office within a one-week period.
If this is not possible, the program informs the user how
much of the equipment (stated in percent) will be diagnosed
within a week (if the UPDATE option is specified, the new
schedule will go into effect anyway). The user may wish to
try different values for the number of days and hours allowed
for REX testing in order to achieve more complete REX
coverage.
The Automatic REX Scheduler also informs the user if SM REX
and ALIT overlap or if CM and AM REX schedules overlap.
(This will not happen unless the user-specified options
override the default options.)
The ROP output shows the calculated REX schedule for each day
of the week, listing all of the SMs that will be tested on
any given day. This list is generated for each REX type
(DGN, FAB, and ELS). The REX and ALIT start times and
duration, which remain constant for each day of the week, are
printed at the top of each form.
The Automatic REX Scheduler should be used for all installing
offices, after equipment growth that changes the office
configuration, or if there is a change in the number of days
or hours available for REX testing. The scheduler may be
invoked any number of times to try various combinations of
REX days and hours because changes to the REX schedule take
effect only at midnight. For example, a change to the REX
schedule made at 10:00 p.m. will not go into effect until the
following day.
For additional information on the Automatic REX Scheduler and
procedures for its use, refer to AT&T 235-105-210, Routine
Operations and Maintenance Procedures.
There are several changes in the philosophy of printing
switch maintenance for IM (SMIM) peripheral fault recovery
(PFR) messages. Originally, all SMIM PFR output messages
were printed at the ROP, including those indicating that no
recovery action had taken place (``ANALYSIS ONLY''). Through
analysis of various field sites, approximately 80 to 90
percent of all PFR output messages contained a recovery
action of ``ANALYSIS ONLY.'' For 192 SM offices, this would
result in PFR consuming 10 percent of AM real time for the
printing of ``ANALYSIS ONLY.'' One of the objectives of the
SMIM large office enhancements capability is to decrease the
AM real-time usage for printing of PFR output messages to
under 1 percent of total AM real time. The changes made to
SMIM output message processing are as follows:
a. Only alarmed (minor, major, critical) PFR output
messages are printed at the ROP.
b. All PFR output messages sent to the AM are logged.
c. The PFR output messages with recovery actions of
``ANALYSIS ONLY'' and ``NO RECOVERY ACTION TAKEN'' are
not sent to the AM. The remaining messages are logged.
d. The PFR output messages are separated by peripheral unit
type into unique message classes. This allows
maintenance personnel to control routing of PFR output
messages based on unit type.
e. Summary output messages can be used to alert maintenance
personnel of units experiencing transient peripheral
errors that do not cause a recovery action to be taken.
Information contained in the following sections can help
maintenance personnel track faulty or marginal hardware
through the use of summary output messages and message
classes. The following input/output commands can be used to
track faulty hardware:
o The input message command OP:PERPH,SM[=a&&b][,CLR],SUM=c;
is used to request a summary of peripheral transient
errors on SMs. This command also can be used to clear
error counts in a given SM.
o The input message command SET:PERPH,SM=a[&&b],VERBOSE;
requests that the verbose status in a single SM or a
range of SMs be set.
o The input message command CLR:PERPH,SM=a[&&b],VERBOSE;
is used to clear the verbose status in a single SM or a
range of SMs.
o The output message OP PERPH SM=a SUM=UNIT SUMMARY NOT
AVAILABLE provides a response to the OP:PERPH,SUM=UNIT
command. It indicates there is no summary data from the
indicated SM due to lack of response from the SM.
o The output message OP PERPH SYSTEM UNIT ERROR SUMMARY
provides a systemwide SM peripheral transient error
summary and gives an overall indication of transient
errors that occurred on peripherals in a given SM. This
message does not provide counts for all peripheral
errors, but only for those errors that do not cause a
recovery action to be taken on a circuit.
o The output message OP PERPH SYSTEM ERROR SUMMARY
provides a summary of transient peripheral errors that
have occurred on SM peripheral units. This message
gives an overall indication of transient errors that
have occurred on the SM(s).
Refer to AT&T 235-600-700, Input Messages Manual, and AT&T
235-600-750, Output Messages Manual, for a complete
explanation of each message listed.
The method for investigating peripheral problems is designed
to work in a step-by-step procedural fashion. By using both
the system error summary and unit error summary output
messages, maintenance personnel can obtain a ``pattern'' of
where errors are occurring.
1. First, it needs to be determined which SMs are taking
peripheral errors. This information is printed daily at
7:00 a.m. in the system error summary output message, at
which time the system wide error counts are also
cleared. The automatic system error summary message
contains counts for only the 20 SMs which have taken the
most errors in the last 24 hours. To get error counts
for all of the SMs in the system, enter the following
message:
OP:PERPH,SM,SUM=SYS;
Figure .AW G114/ is an example of the resulting output
message.
It is important to remember that these error counts
reflect only the errors which have occurred since 7:00
a.m. If the ERRCNT column is blank for an SM, that
means that the information was not available because the
SM was not able to communicate with the AM.
From this information, the SMs which are taking the most
peripheral errors can be found. These are the ones
which should be targeted for investigation.
If only a certain range of SMs needs to be examined, the
range can be specified in the OP:PERPH input message
when entered as follows:
OP:PERPH,SM=1&&20,SUM=SYS;
This gives a summary for all SMs between 1 and 20.
2. Next, find out which kind of peripherals on the SMs are
taking the errors by entering the following command:
OP:PERPH,SM=a[&&b],SUM=UNIT;
This command can be entered to specify each SM or a
range of SMs. Error counts in the SM are not cleared
automatically; they are cleared by maintenance personnel
using the CLR option (as shown in Step 6).
Figure .AW G115/ is an example of the report from each SM.
In this example, the line unit (LU) would be the unit to
target for investigation.
3. Set the message class to print for the unit targeted for
investigation by entering the following command:
CHG:LPS,MSGCLS=HW_MON,PRINT=ON;
All the unit type message classes are logged by default,
so the previous command allows all the messages for that
unit type to be printed, as well as logged. If it is
desired to have the messages only printed and not
logged, enter the following command:
CHG:LPS,MSGCLS=a,PRINT=ON,LOG=OFF;
4. At this point, the peripheral error messages will be
seen when an error results in a recovery action on that
peripheral (for example, a remove and restore of the
peripheral).
To see all peripheral error messages for the unit being
investigated, use the following command for the SMs
targeted in Step 1.
Note: Do not set the VERBOSE mode in more than 10
SMs; this will cause the loss of ROP
messages by increasing the number of
messages going to the AM.
SET:PERPH,SM=a[&&b],VERBOSE;
The VERBOSE mode also can be set with poke 412 on MCC
Page 1800 (Inhibit and Recovery Control) causing display
message PFR MSG VERBOSE to backlight.
5. If the problem units are taking control interface (CI)
errors or time slot interchanger (TSI) PIDB parity
errors, it is also useful to inhibit brevity control in
the targeted SMs with the following command, due to the
large number of messages which these types of errors
generate. This allows more messages to go to the AM.
Brevity control should not be inhibited for more than 10
SMs, otherwise messages to the ROP may be lost.
INH:BREVC,SM=a[&&b];
Poke 609 on MCC Page 1800 also can be used to inhibit
the SM brevity control.
6. Wait for the desired information to come out on the ROP.
Once the investigation is completed and problems are
cleared, the controls should be returned back to their
default state as follows:
ALW:BREVC,SM=a[&&b],VERBOSE; or poke 709 on Page 1800
CLR:PERPH,SM=a[&&b],VERBOSE; or poke 512 on Page 1800
CHG:LPS,MSGCLS=a,PRINT=OFF,LOG=ON;
If more than one message class was changed, the
following command can be used to restore the previous
message class status:
CHG:LPS,MSGCLS=ALL,FROMBKUP;
The error counts on a per-unit basis can be cleared in
the SM using the following command, to see new patterns
as they emerge:
OP:PERPH,SM=a[&&b],CLR,SUM=UNIT;
For 5E6 and later software releases, HW_MON is the message
class for all peripheral units.
Suppose that TSI DI-ERR-BUFF errors have been coming out
occasionally, but the peripherals which are the source of the
problem are unknown.
1. First, one needs to determine which SMs are taking
peripheral errors. Enter the following command to get
the counts for all the SMs in the system:
OP:PERPH,SM,SUM=SYS;
The resulting output message is shown in Figure .AW G116/.
From this information, it can be seen that SMs 8 and 10
should be targeted for investigation.
2. Find out which kind of peripherals on these SMs are
taking the errors. Enter the following commands:
OP:PERPH,SM=8,SUM=UNIT;
OP:PERPH,SM=10,SUM=UNIT;
OP:PERPH,SM=3,SUM=UNIT;
Figure .AW G117/ is an example of the report from each SM.
From this information, it is determined that the
peripherals to be investigated are the DCLU, LU, and
DLTU.
3. For the 5E6 software release, set the message class to
print for all peripheral units. Enter the following
command:
CHG:LPS,MSGCLS=HW_MON,PRINT=ON,LOG=OFF;
For 5E7 and later software releases, enter the following
command:
CHG:LPS,MSGCLS=PFR_MON,PRINT=ON,LOG=OFF;
4. In order to see