Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Phreaking Technical System Info :: 5essmnt.txt

HUGE 5ESS Manual!




       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 all peripheral error messages for the
          unit which are being investigated, use the following
          command for the SMs which were targeted in Step 1.
          (Remember:  The VERBOSE mode should not be set in more
          than 10 SMs, or this will cause the loss of ROP messages
          by increasing the number of messages going to the AM.)

             SET:PERPH,SM=8,VERBOSE;

             SET:PERPH,SM=10,VERBOSE;

             SET:PERPH,SM=3,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. Inhibit brevity control in the SMs with the following
          command.  (Again, this should not be done for more than
          10 SMs, otherwise messages to the ROP could be lost.)

             INH:BREVC,SM=3;

             INH:BREVC,SM=8;

             INH:BREVC,SM=10;

          Poke 609 on MCC Page 1800 also can be used to inhibit
          the SM brevity control.

       6. Now, wait for the desired information to come out on the
          ROP.  Once the investigation is finished and problems
          are cleared, the control should be returned to their
          default state as follows:

            a. Allow brevity control:

                 o  ALW:BREVC,SM=3;

                 o  ALW:BREVC,SM=8;

                 o  ALW:BREVC,SM=10;

            b. Clear the verbose mode:

                 o  CLR:PERPH,SM=8,VERBOSE;

                 o  CLR:PERPH,SM=10,VERBOSE;

                 o  CLR:PERPH,SM=3,VERBOSE;

            c. Set the message classes back to their default
               logging state by use of the following command:

                 o  CHG:LPS,MSGCLS=ALL,FROM BKUP

            d. The error counts in all the SMs that are on a per-
               unit basis in the SM can be cleared using the
               following command, in order to see new patterns as
               they emerge.

                 o  OP:PERPH,SM=1&&16,CLR,SUM=UNIT;

     While the volume of teletypewriter (TTY) output messages
     generated from within the integrated services digital network
     (ISDN) peripherals is expected to be modest, the total
     equipage in a medium-to-large size 5ESS switch may be very
     large with a correspondingly high potential for a large
     quantity of output messages.  The possibility of generating
     such a high volume of messages makes it necessary to throttle
     port processor messages unless maintenance personnel
     specifically requests them.  Therefore, separate print
     controls are provided for each of the ISDN peripheral units.

     The various input messages for peripheral print control are
     listed as follows (in MML).  Refer to AT&T 235-600-700, Input
     Messages Manual, and AT&T 235-600-750, Output Messages
     Manual, for a complete explanation of these messages.

       o  CHG:PRNTMODE=a, SM=b, {PSUPH=b | PI | PP};

          This input command is used to change the print control
          status of the specified peripheral.  If the print mode
          is set to ``ON,'' output messages from the specified
          unit are logged in the AM as they occur.  If the print
          mode is set to ``OFF'' (the default), output messages
          are not sent to the AM for logging or printing.  When
          the print mode is off, output messages are temporarily
          logged within the unit itself and may be retrieved via
          the ``HISTORY'' option or the OP:HISTORY input message.

       o  OP:HISTORY, {PSUPH=a | CHNG=a | MCTSI=a,PI} [,PRNTMODE=a];

          When history is requested, the output messages logged in
          the specified unit are printed on the ROP.  This input
          command also provides the option of changing the print
          mode status (see the CHG:PRNTMODE command described
          previously).

       o  OP:POSTMORT, MCTSI=a,PP;

          This input command requests port processor postmortem
          reports to be printed on the ROP.  Postmortem reports
          consist of those output messages that were logged in the
          port processor at the time of the initialization.  Refer
          to the OP:POSTMORT and RLS:POSTMORT messages in the
          input message manual for the complete explanations.

       o  OP:STATUS, {PSUPH=b | CHNG=b | MCTSI=b,PI};

          This input command requests summary information for the
          specified unit.  The status information printed on the
          ROP includes print mode status, overload status, and
          initialization summary information.

       Note:   The descriptive text and detailed procedures
               within AT&T 235-105-210, Routine Operations and
               Maintenance Procedures, can be very helpful when
               maintenance personnel are concerned with the
               routine operations of the 5ESS switch.

     Routine tests are run by the terminal maintenance subsystem
     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 implemented 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 at a remote testing location.

          Note:  The APT is disabled in a 5ESS switch for
                 AUTOPLEX System 1000.

     The ATTS is primarily used to automatically test trunks for a
     5ESS switch for AUTOPLEX System 1000.  (The ATTS is a secured
     feature that can be purchased independently for use in regular
     5ESS switch applicatioins.) The ATTS schedules routine testing
     on a periodic basis and is capable of supporting multiple,
     independent schedules of test sessions.  See Section .RM 3.5.1.6.2/
     for additional information on ATTS.

     Routine tests can be classified as operational or
     transmission and encompass the following objectives:

       a. Verify the operational characteristics of interface and
          carrier facilities and distant office equipment.

       b. Verify the end-to-end ability to detect and send
          signaling and supervision.

       c. Routinely exercise the interface circuits in a distant
          office.

       d. Verify the operational characteristics of digital
          carrier voice and data trunk facilities through the use
          of a digital-circuit loopback and transmit capability
          (loopback/108-type test line).

     One of several test actions can be selected for each trunk.
     The 5ESS switch supports incoming test calls for operational
     tests.  The automatic line insulation test (ALIT) is the
     operational test for lines.  The ALIT is an automatic test
     system that scans lines and identifies faults before they
     become service affecting.

     The 5ESS switch performs all the functions of the 105-type
     test line and responder.  Manual transmission tests utilize
     the AC and DC jacks and portable test equipment to accomplish
     transmission testing.  This testing is performed at the TLWS.
     Refer to Section .RM 2.7/ of this manual for more details
     concerning the different transmission tests that can be
     implemented via the TLWS.
     This backup is done any time changes to the office text or
     data are made permanent.  This includes software updates and
     data base recent changes.  The data base recent changes
     consist of office dependent data (ODD) and equipment
     configuration data (ECD).  It consists of saving the changes
     from memory to MHD 0 and 1.  When the memory changes have
     been made permanent, they are available on disk for automatic
     recovery situations which require booting.
     This backup is performed prior to making changes permanent to
     data, program, or other files in the UNIX RTR operating
     system root partitions (dev/root, /dev/db, /dev/etc, and
     /dev/boot).  These changes are the result of software updates
     or ECD recent changes.  The term primary partitions refers to
     the root partitions.  This backup activity depends on the
     frequency of changes made to the root partitions.  It is not
     necessary to perform this backup for every change made to the
     root partitions.  This backup consists of copying the
     partitions from the primary to backup partitions and is
     included in the full office backup procedures.  Files in
     these partitions are identified by pathnames that begin with
     something other than /no5text.

     Normally, system operation is performed from the files in the
     root partitions.  This is indicated by the emergency action
     interface page having item 31 (BACKUP-ROOT) cleared.
     Backup-root partitions are used only for recovery situations.
     This means that if backup-root is used to perform recovery
     operations, the required corrections should be made to the
     root partitions and control of the system must be returned to
     the root partitions.  No recent changes or software updates
     should ever be applied to the system while it is running on
     the backup-root partitions.
     Introduction:  Backup disks contain all software required to
     provide an operational 5ESS switch.  A backup disk may be
     saved external to the disk drives (shelf copy).  Shelf copies
     are made from each of the disk drives in the system on a
     scheduled basis.  These shelf copies are referred to as MHD 0
     and MHD 1 shelf copies.  Backups of MHD 0 or 1 are also
     referred to as primary/boot disk copies.  The certified disk
     is another type of shelf backup.  This is a primary disk
     which has recently been used to boot the AM in the root
     partitions and has, therefore, been proven to be valid.

     MHD 0/1 Shelf Disks:  Shelf disks are copies of the MHD 0 or
     MHD 1 disk drive contents.  The shelf disks should be labeled
     for identification and kept in a safe place for system
     recovery use in the event that data in both primary drives
     becomes mutilated.  Refer to the Memory Alteration Procedures
     (in AT&T 235-105-210, Routine Operations and Maintenance
     Procedures) for details on making shelf copies. Shelf copies
     of MHD 0/1 should not be made more frequently than once a
     week per drive.  The backup schedule should take into
     consideration the number of changes made to office data and
     programs since the last backup.
     When a disk pack is removed from MHD 0 or MHD 1 to make a
     shelf backup disk, it must be replaced with a disk pack
     currently used as a shelf copy.  The replacement disk pack
     should be the oldest shelf copy made from the other disk
     drive.  The backup disk packs should be alternated between
     disk drives to provide the disk pack rotation.  Currently,
     offices employing Century Data System disk drives cannot
     perform this shelf backup rotation procedure.  At least one
     shelf copy from each disk drive must be maintained at all
     times.  The sequence described here provides one shelf copy
     from one of the drives and two copies from the other drive.
     Each time a backup copy is made, it should be made from the
     disk drive which currently has only one shelf copy.
     The certified disk is a primary disk copy which has recently
     been used to boot the AM in the root configuration.  Once the
     system is stable after a UNIX RTR operating system level 3 or
     greater initialization, the disk used in the boot sequence is
     used as the latest certified disk.  The backup procedure for
     this disk is covered in the Memory Alteration Procedures
     section in AT&T 235-105-210, Routine Operations and
     Maintenance Procedures.
     The ODD backup to tape is a backup of the office data base
     and the AT&T 3B20D computer data base on one tape.  The ODD
     tape will contain the current working data base in the
     following partitions:

          /dev/db
          /dev/no5odd1 or /dev/no5odd2
          /dev/no5odd1 or /dev/no5odd2

     The set of data base partitions to be backed up depends on
     the contents of the /no5text/rcv/aimrc file.
     The scheduling of various backup levels is determined by
     local practices based on the following guidelines.
     Memory to primary disk backup should be scheduled based on
     recent change and software update activity.  Scheduled
     intervals for disk backup may vary; they can be performed as
     often as daily, or as infrequently as monthly.
     The UNIX RTR operating system root partitions backup should
     be based on root partition changes associated with the ECD
     and software update activity.  The primary partitions should
     be copied to the backup partitions before ECD and/or software
     updates are made permanent.  This backup activity is not
     required for individual changes but should be done for sets
     of changes.  If there is a number of software updates which
     affect the root partitions, the root partitions should be
     copied to backup-root and the software updates should be
     applied.  However, if all software update changes were made
     to files with pathnames beginning with /no5text, then this
     type of backup is not needed.  The no5text partition does not
     have a backup partition on the disk.
     Shelf copies of MHD 0/1 should not be made more frequently
     than weekly on a per-drive basis.  The schedule for making
     shelf copies should consider the frequency of changes made to
     the data base (ODD or ECD) and the number of software updates
     installed since the last backup.
     Whenever the AM requires booting, the disk pack used to
     perform the boot process should be made the latest certified
     disk.  This guarantees a bootable backup shelf copy.  The
     replacement disk pack should be the oldest shelf copy of a
     certified disk.

     The minimum number of shelf backup disk packs is four.  Three
     are required to rotate backup disks between disk drives for
     the detection of head alignment problems between the drives.
     One disk is required for the certified disk.  Additional
     shelf backup disk packs may be maintained, if desired (for
     example, it may be desired to maintain additional certified
     disks).
     The frequency of the ODD backup to tape will depend on how
     often an ODD backup (from main store to disk) is performed in
     the particular office.  The ODD backups should be performed
     on a regular basis.  The appropriate time to schedule an ODD
     disk image backup to tape is before an ODD backup.  This will
     allow the maximum soak period for the ODD disk image before
     it is written to tape.  Also, whenever the ECD has been
     altered, the ODD backup to tape should not be used.  The full
     office to tape backup should be used instead.  This is
     because the ODD backup to tape does not cover the ECD.  All
     ODD disk image backup tapes made between two full office to
     tape backups should be saved.  Then, when a new ODD backup
     tape is made after a full office backup, the oldest ODD disk
     image backup tape made since the previous office backup
     should be discarded first.  The following schedule for ODD
     backup to tape is recommended:

       a. If an ODD backup is performed daily, the ODD disk image
          backup should be done once a week.

       b. If an ODD backup is performed twice a week, the ODD disk
          image backup should be done once every 2 weeks.

       c. If an ODD backup is performed weekly, the ODD disk image
          backup should be done once a month.

     In any event, an ODD disk image backup should be done at
     least once a month and no more than once a week.  In addition
     to the ODD backup to tape, ODD recovery from tape procedures
     are provided in AT&T 235-105-210, Routine Operations and
     Maintenance Procedures, and AT&T 235-105-250, System
     Recovery.
     The full office backup to tape consists of all the text and
     data partitions required to recover an office to a call
     processing state.  Two tapes are required, one tape for the
     text and one for the data base data.

     The full office backup tapes should be made based on the
     following considerations:

       a. Office backup tapes should be made when the number of
          permanent software updates in the office reaches a point
          that makes it desirable to backup the software changes
          to tape.  The number of software updates is office
          dependent but should not be more than 25.

       b. Office backup tapes should be made when there is
          text/data base coupling that results from a recent
          change or software update change.  The coupling and the
          need to make an office backup should be specified in the
          software update documentation.

       c. Office backup tapes should be made whenever the office
          experiences a UNIX RTR operating system level 3 or
          higher initialization.  The backup should be done after
          the system stabilizes and the disks are duplexed.

       d. After a software release retrofit, a set of office
          backup tapes should be made of the new software release.
          Once the office is committed to the new software
          release, the old software release backup tapes should be
          purged from the office in approximately 2 weeks.  Also,
          the new software release tapes that were used to boot
          the office during the software release retrofit should
          be kept as certified tapes until they are no longer
          usable as backup tapes.

     The purpose of ODD backup is to provide a sound basis for
     recovery by allowing the system to recover quickly from a
     boot or pump.  The changes to the ODD may be introduced by
     regular recent change, customer-originated recent change
     (CORC), maintenance, and ODBE.

     Backup of the ODD makes the current memory image (that is,
     in-core contents) of the ODD permanent on disk.  The ODD in
     the AM and in all the SMs will be backed up during this
     operation.
     Origination for ODD backup is under local control.  Local
     control is required for the following reasons:

       a. The ODD backup is run ``on demand.''

       b. After the first initialization of the office, the
          dynamic head blocks stored in the ODD must be backed up.

     The frequency of ODD backup depends on the disk space
     allocated to log regular recent changes and CORCs, and the
     number of these changes in the system.  The percentage of
     disk log capacity may be obtained by using the OP:LOGSTAT
     message.  In addition to showing the percentage, the output
     message will also indicate the number of regular recent
     changes and CORCs in the disk log.

     It is recommended that the ODD be backed up weekly or
     whenever the disk log contains 80 percent of the changes that
     can be restored in 1 hour.  To avoid recent change
     performance degradation, the backup should be run in off-peak
     hours when system load and recent change input are minimal.
     When the disk log files reach 80 percent of the changes that
     can be restored in 1 hour, an alarmed output message notifies
     local maintenance personnel.

     When an ODD backup is in progress, CORCs are blocked, and the
     subscriber receives reorder tone.  Similarly, if an attempt
     to perform an ODD backup is initiated while a recent change
     is in progress or when the EXC:ODDRCVY=ALL; message is in
     progress, the backup request is denied.
     The ODD backup requires disk space for two copies of the
     entire ODD in addition to the official copy.  The first copy
     is used as a working copy for the file update during backup;
     while the other copy is considered a ``save'' copy.
     Errors may be introduced during an ODD backup operation.
     These errors may be due to bad or lost messages, buffer
     overwrites, etc.

     All processes used during an ODD backup are automatically
     released if a failure occurs.  If the backup fails, a manual
     restart of the ODD backup operation should correct the
     problem.  If not, a more serious system malfunction may be
     indicated, and technical assistance should be obtained from
     your AT&T Network Systems Regional Technical Assistance
     Center (RTAC).

     The ODD backup does not interface directly with any of the
     levels of software recovery.  If a processor or the system
     has an initialization during an ODD backup, the ODD backup is
     normally aborted with no damage done to the official ODD
     files.  The ODD backup can be restarted at another time.
     After the initialization, a recent change recovery must be
     performed to reinstate the lost recent changes and CORCs.
     A stable or transient clear backs out all recent changes and
     CORCs entered since the last ODD backup.  This is because
     system initialization restores the memory version of the ODD
     with the disk version created by the most recent ODD backup.
     The ODD recovery consists of reapplying the backed-out recent
     changes and CORCs.  Records of the recent changes and CORCs
     are logged in disk files during the updating process.  The
     ODD recovery provides all features needed by maintenance
     personnel to recover the ODD.

     The EXC:ODDRCVY input message is usually generated
     automatically after a system initialization is completed.
     The output message generated is prefixed with an ``A'' to
     indicate that the ODD recovery was automatically started.

     Manual recovery is needed after all craft-initiated system
     initializations.  Manual recovery is also needed after
     automatic initializations when the system integrity monitor
     determines that the ODD recovery may be faulty.  When manual
     intervention is needed, the EXC ODDRCVY NOT STARTED alarm
     message is dumped to indicate that the automatic recovery was
     not started and that a manual ODD recovery is needed.  All
     recent change activity is blocked until the command has been
     completed.

     If a manual recovery is needed and the OP:LOGSTAT message is
     run, the OP LOGSTAT output message displays a reminder that
     the ODD recovery has not been performed since the system
     initialization occurred.
     Semiconductor devices are constructed to withstand mechanical
     shocks and drops of a limited nature.  However, they are not
     indestructible and excessive shocks may shorten their life
     expectancy and/or change their electrical characteristics.

       o  The integrated circuit (IC) packs and their film
          circuits are usually more susceptible to mechanical
          shock than conventional circuit packs due to their
          multiplicity of components and construction.

       o  Damage may result from dirt and other contaminants that
          wear down the gold contacts.  Once the gold plating has
          been worn off or scratched, an oxidized film may form on
          the exposed copper.  This film may cause electrical
          noise in the circuit and, if undisturbed for a long
          time, could open the circuit.

       o  Semiconductor devices and circuit packs in general are
          sensitive to static charges.  Circuit pack IC damage can
          be attributed to a discharge of static electricity.

       o  For a person to feel the discharge of static
          electricity, a minimum voltage level of 1,500 to 3,500
          volts must exist.  A person walking across a floor can
          generate electrostatic voltages in excess of 12,000
          volts.

       o  Tests have shown that ICs can be damaged by discharges
          of 100 to 200 volts.

       o  Since electrostatic discharges contain little or no
          current, there is no personal safety hazard.

       o  In addition to electrostatic discharge resulting from an
          ungrounded person touching a circuit pack, static
          charges may result from other sources.  If a piece of
          plastic is placed near one end of a circuit pack lying
          on an insulated table top, it can direct its charge into
          the circuit pack.

       o  Identifying damage due to electrostatic discharge can be
          difficult, as in many cases physical damage cannot be
          seen.  A circuit pack or semiconductor device which has
          been exposed to an electrostatic discharge may:

            a. Not be affected, that is, work perfectly with
               normal life expectancy

            b. Function normally, but with reduced life expectancy

            c. Function erratically at times

            d. Stop functioning altogether.

     Circuit packs are shipped from the factory in corrugated
     containers which are specially designed to prevent static
     buildup. Most 5ESS switch circuit packs are shipped in pink
     antistatic bags. Warning labels are placed on bags and
     cartons of static sensitive devices.
     Circuit packs shall be stored in their original factory
     shipping container. Do not break the seal on this container
     until ready to use the circuit pack.
     When returning circuit packs to AT&T locations, ship the
     packs in the shipping materials in which they were originally
     packed. The packaging material of new packs received may be
     used to return the old packs. To facilitate quick repair of
     defective circuit packs, firmly string tie a completed
     information tag to the hole above the faceplate of the pack.
     Circuit packs are shipped with a blank information tag.
     Circuit pack information tags can be ordered from:

        AT&T Consumer Products
        Installation Stock-keeping
        P.O. Box 265
        West Chicago, Il 60185

     Defective circuit pack information tags must be completed and
     string tied to the circuit pack. Packing should take place at
     a static-free work station. Place the circuit pack in a pink
     antistatic bag or carton before placing in a regular box.
     A properly grounded antistatic wrist strap must be worn when
     handling any circuit pack. The following general guidelines
     should be followed when handling circuit packs:

       o  The power should be turned off before inserting or
          removing a plug-in circuit pack, unless specified by
          test requirements.

       o  Carry the pack (in packing materials) to replacement
          site before removing it from packaging. Do not remove
          the pack from the box and walk with it.

       o  Avoid unnecessary removal of circuit packs.

       o  Before replacing a circuit pack, check the
          identification code to ensure the proper pack is being
          used.

     Grounded antistatic wrist straps must be worn for all circuit
     pack handling. The alligator clip connector of the wrist
     strap must be connected to a bare metal frame ground. The
     wrist strap must contact the skin and is not to be worn over
     clothing. If a static sensitive pack has already been found
     faulty, do not ignore requirements for handling static
     sensitive packs.  Continued mishandling may create other,
     more serious, problems with the pack. The following
     guidelines should be followed to protect circuit packs from
     electrostatic discharge damage:

       o  A grounded person must never hand an unprotected circuit
          pack to an ungrounded second person. A static discharge
          from the ungrounded person through the circuit pack to
          the grounded person could cause an electrostatic
          discharge failure. All persons and equipment at a work
          location must be at the same common ground potential to
          be static safe.

       o  Do not rub or wipe circuit packs containing ICs.

       o  Work areas must be kept clear of common plastics,
          because they are a major source of static electricity.
          When handled, these plastics produce a static charge
          that will not readily dissipate when grounded. These
          common plastics must not make direct contact with ICs or
          circuit packs. Common plastic materials in this
          classification include polystyrene (styrofoam) packing
          containers, clear plastic bags, plastic drinking cups,
          food wrappers, notebooks, and nonconductive plastic
          solder suckers. The plastic insulation on small hand
          tools does not represent a static hazard.

       o  Put circuit pack into antistatic bag or carton
          immediately upon removing it from a frame.

       o  Keep adhesive tape (scotch, masking, etc.) away from
          sensitive devices.

       o  Do not wax the equipment aisles in the central office.

       o  Maintain relative humidity above the 20 percent level.

       o  When soldering static-sensitive semiconductor devices,
          the soldering iron must be grounded to the work table
          which must also be earth grounded. Individuals should
          also wear an antistatic wrist strap so that all items
          contacted are at the same potential.

       o  Verify that the resistance between the wrist strap and
          its connector plug is 1 megohm +-10 percent at least
          once every week of use.

       o  Make sure that both male and female connectors are
          clean.

       o  Make sure the circuit pack is aligned with the guide.

       o  Never force the circuit pack.

       o  If unusual resistance is felt, determine and correct the
          cause before inserting the pack.

       o  Avoid letting any components of a circuit pack scrape
          the adjacent packs.

     The following documents can be ordered from the Customer
     Information Center through your document coordinator by
     document number.

       o  AT&T 802-001-180:  Protective Grounding Systems --
          General Grounding Requirements for Common Systems in
          Central Offices, Radio Stations, and Other Structures

       o  AT&T 802-001-196:  Protective Grounding Systems --
          General Grounding Requirement for Data Processing
          Computer Installation

     Achieving a high level of hardware reliability in the 5ESS
     switch requires that each office maintain a stock of spare
     circuit packs.  Circuit packs are thoroughly tested by AT&T
     prior to shipment and therefore do not require site testing.

     Observe the following guidelines for maintaining a stock of
     spare circuit packs:

       o  Ensure that instructions for the proper handling and
          storing of circuit packs are adhered to.  (These
          instructions are described in Section .RM 3.24/ of this
          document.)

       o  Establish a circuit pack inventory log (Figure .AW G118/) to
          track all circuit packs including those used for
          troubleshooting.
     A Repair Service and Return (RS&R) is a maintenance support
     service which provides repair services for all 5ESS switch
     equipment owned by the customer.  The 5ESS switch repair
     procedures are outlined as follows.  Please note that the
     list of service centers and corresponding procedures for
     readily returnable material and nonreadily returnable
     material are independent of each other.  The following
     subparagraphs contain the return procedures for readily
     returnable and nonreadily returnable materials, respectively.
       1. The 5ESS switch readily returnable material includes
          circuit packs and plug-ins located in the SM, the CM,
          and the processor control cabinets (PCC) of the AM.

       2. The Master Item File and/or Regional Control File
          provide repair locations for 5ESS switch readily
          returnable material.  Readily returnable material should
          be shipped directly to the specified repair location to
          receive the optimal replacement interval.  Both the
          Master Item File and the Regional Control File are
          available from the nearest service center, listed in
          Table .AW TAD/.

       3. The RS&R repair interval is 14 days from receipt of
          defective material to shipment of repaired material.

       4. All defective material submitted for repair should be
          shipped with a completed RS&R form and a completed
          ``5ESS Switch Returned Circuit Pack Tag.''  The RS&R
          forms are typically customer provided.  AT&T RS&R forms
          can be obtained from the Customer Information Center,
          SD-44-326.

          Effective with the 5E9(1) software release, the
          Automated Circuit Pack Return Tag Tool can be used to
          generate the Returned Circuit Pack Tag.  Refer to
          Section .RM 3.16/ of this document for additional information
          about this tool.  For detailed procedures on its use,
          refer to AT&T 235-105-220, Corrective Maintenance
          Procedures.

       5. Customers will be notified by mail in cases where
          material is unrepairable or is uneconomical to repair.
          Any material disposal occurs as specified by the
          customer.  If defective material is under warranty,
          unrepairable material will automatically be replaced.

       6. Equivalent replacements will only be shipped to
          customers if the availability of repair parts is
          expected to exceed the 14-day interval.

       7. All repaired material receives a warranty equal to the
          remainder of the 2-year new equipment warranty or 6
          months, whichever is longer.

       8. Repair during the warranty period is provided at no
          charge to the customer.  Current post warranty repair
          prices for readily returnable material can be obtained
          from your AT&T Network Systems Representative upon
          request.

       1. The 5ESS switch nonreadily returnable material consists
          of all equipment (including pluggable packs) located in
          the tape cabinet and the disk cabinets of the AM,
          terminals, printers, cable rack, and office framework.

       2. Repair of nonreadily returnable material is performed by
          Service Support Center (SSC) personnel during normal
          business hours, Monday through Friday, 8:00 a.m. to 4:00
          p.m.

       3. Emergency SSC service outside normal business hours,
          Monday through Friday, 8:00 a.m. to 4:00 p.m., is
          billable to the customer unless a maintenance contract
          applies.  Emergency service is billable at a minimum of
          4 hours labor.  Maintenance contracts are available from
          AT&T - Network Systems SSC for the entire office or
          specific units as specified.  All SSC servicing of post
          warranty equipment is billable as incurred unless
          covered by a maintenance contract.

       4. Table .AW TAE/ provides a list of designated SSCs.  The
          nearest SSC should always be contacted as repair
          assistance is needed.

       5. Repair resolution of nonreadily returnable material is
          customized per occurrence as the resolution could take
          several forms, such as a phone call
          diagnosis/resolution, AT&T personnel on site for repair,
          or submission of unit or portion of equipment to a
          specified AT&T location for repair.

       6. If resolution requires shipment of any material to AT&T
          for repair as determined by AT&T personnel, existing
          RS&R routines should be utilized.  The normal SSC repair
          interval is 28 days upon receipt of defective material
          to shipment of repaired material or equivalent
          replacement by the SSC.

       7. All repaired products receive a warranty equal to the
          remainder of the 2-year new equipment warranty or 6
          months, whichever is longer.

     Figure .AW G119/ summarizes maintenance support services available
     from AT&T - Network Systems for the 5ESS switch.

     Specific information regarding the Spares Exchange Service
     (SES)-5/SES-5 PLUS services is provided in the following
     subsection (Spares Exchange Service For 5ESS Switch
     Equipment).  Sparing recommendations for 5ESS switch
     equipment is provided in ED-5D133-01.  This document can be
     obtained from the Customer Information Center in
     Indianapolis, Indiana.

     For additional information or technical assistance, please
     contact your AT&T Network Systems Regional Technical
     Assistance Center or the AT&T Account Executive serving your
     company.

     The SES-5 and SES-5 PLUS services are additional service
     offerings intended to be maintenance support services.  Their
     primary purpose is to meet a customer's need for immediate
     replacement material while minimizing total inventory.  They
     are available to domestic customers with 5ESS switches that
     are in service or turned over to the customer.

     Generally, SES-5 and SES-5 PLUS can exchange all AT&T
     manufactured spare material normally required to support a
     5ESS switch and the embedded AT&T 3B20D Computer.  All
     material is new or can be reconditioned/refurbished to new to
     meet AT&T Network Systems high-quality standards.  The spare
     material covered is considered to be ``readily returnable''
     material (for example, circuit packs and plug-ins; not disk
     drives).

     The SES-5 PLUS service does not replace the SES-5 service.
     The SES-5 PLUS offers the customer a fixed annual
     subscription fee for easier billing administration during
     both the warranty and the post-warranty period.  The SES-5
     PLUS service is offered at a yearly subscription price based
     on the number of switching modules deployed.  The host SM and
     the RSM subscription fees are identical. In order to qualify
     for SES-5 PLUS service, the customer must agree to have all
     SMs under contract.

     The SES-5 and SES-5 PLUS services are intended to be
     maintenance support services.  They are not intended to be
     the vehicle for obtaining large quantities of materials
     associated with establishment of central stocks.  Orders to
     establish central stocks should be entered under normal
     ordering routines.
     To utilize the services, customers must obtain account
     numbers.  It is recommended that the customer obtain one
     account number per 5ESS switch location.  To obtain an
     account number, the regional sales offices for the customer's
     area can help them complete an Account Requisition Form.  The
     purpose of this process is to establish a customer's account
     against which he may issue orders for replacement parts.

     The primary information requested is as follows:

       o  Company name, office name, and address

       o  Authorized ``Ship to'' address (can be restricted to one
          location or multiple locations)

       o  A customer order number

       o  Customer accounting data

       o  Customer approval.

     The local sales office writes the customer and confirms
     establishment of the account number.  This letter provides
     basic information on the service and advises the customer
     that since the account number is used for ordering purposes,
     it should only be provided to those who are authorized to use
     it.
     To obtain an exchange under either SES-5 or SES-5 PLUS, call
     the toll-free number, 1-800-325-9890.

     Upon receipt of a call, personnel confirms the customer's
     eligibility to use the service by requesting their account
     number.

     Customers are requested to provide the following information
     when calling in the order:

       o  Account number

       o  Office name and ``Ship to'' address

       o  Item description and quantity

       o  Required ``on job'' date

       o  CLEI code (Obtained for part to be exchanged)

       o  Shipping instructions

       o  Caller name and number.

     On emergency orders, customers are provided appropriate
     shipping information by the transportation organization
     shipping the material.
     The delivery of replacement circuit packs is controlled by
     the customer.  Accordingly, it is the responsibility of the
     calling party to specify the date by which the replacement
     pack must be delivered.  It is expected that emergency
     deliveries are requested only at such times as the urgency of
     the situation dictates, such as when no replacement on site
     is available.
     The following list contains the different types of delivery
     intervals available for circuit packs or other plug-in units.
     Use the number 800-325-9890 to find out what the charge is
     for each of these delivery intervals.

       o  SES-5:

            a. Normal service (2- to 7-day service)

            b. Emergency service (24-hour service)

            c. Critical service (less than 24-hour service).

       o  SES-5 PLUS: A yearly subscription fee is charged per SM
          billed monthly.

     The following items apply to the charges for the replacement
     of plug-ins under both SES-5 and SES-5 PLUS services:

       o  Under warranty material exchanged not abused - No charge

       o  Out of warranty material exchanged not abused and
          repairable/updatable - Call 800-325-9890 for price per
          plug-in unit

       o  In or out of warranty material exchanged abused - Stock
          order price (800-325-9890)

       o  Material not exchanged within 30 days - Stock order
          price (800-325-9890).

     The customer shall return the defective material to Goddard,
     Kansas, within thirty (30) days of receipt of the
     replacement, along with a ``Returned Material
     Authorization.''  The returned package postmark is used to
     verify the timeliness of the return.

     The Returned Material Authorization has been prepopulated
     with all information on file.  The customer must complete
     only the shaded portion of the form which requests the
     following:

       o  Quantity of parts being returned

       o  Customer signature

       o  Date

       o  How defective part was shipped

       o  Product number (CLEI code)

       o  Weight and number of cartons shipped.

     AT&T replacement material is shipped in reusable cartons.  It
     is requested that customers use these cartons to return the
     defective units.  When these cartons are not used, it is the
     responsibility of the customers to use packaging materials
     that adequately protect the equipment.  The customer is also
     supplied with a preprinted return label which facilitates the
     return procedure.

     All SES-5 return material should be mailed to this address
     for proper billing and crediting:

           AT&T Technologies
           SES-5/Dock 44
           21999 W. Highway 54
           Goddard, Kansas 67052

     The individual General Sales Agreements cover the
     specifics of each customer's warranty; however, the
     following general guidelines are represented.

       o  During warranty periods, the replacement material
          carries a warranty equal to the remainder of the
          warranty period applicable to the material per
          contract with AT&T, or 6-months, whichever is
          longer.

       o  During post warranty periods, the replacement
          material carries a 6-month warranty if the
          customer pays the replacement price for AT&T
          manufactured material.  If, however, the customer
          purchases material at the new stock order price
          through SES-5, the material carries the new
          product warranty.

     An audit is a program that verifies software memory for
     consistency of data.  The audit program checks the data base
     for lost hardware data and broken links between data
     structures.  In other words, audits are used to detect and
     recover software data errors before the switch's performance
     is affected.

     Application audits are administered by the audits subsystem.
     System audits are administered by the dmert subsystem.  (See
     AT&T 235-600-400, Audits Manual, for a description of this
     subsystem.)

     When an audit finds an error in the data base, it immediately
     begins to correct the software data error.  If the audit
     cannot fix the problem, it is because the error is extensive
     and higher level audits are necessary, or because the data
     has an inconsistency that must be repaired manually via
     recent change (RC) or the office data base editor (ODBE).
     The use of ODBE is explained in Section .RM 3.13/.

       Note:   The RC is the preferred method.

     Routine audits are scheduled to run automatically in a
     continuous repetitive pattern.  Scheduled audits run in a
     continuous repetitive pattern.  Also, an audit can be run
     manually by entering an input message (except in the PH or
     PI) or as a result of defensive check failures (see asserts
     section that follows).

     Audits are run at a low priority to minimize any interference
     with operational functions vital to call processing.
       Note:   This section is for general information only,
               refer to AT&T 235-600-400, Audits Manual, for
               the audits applicable to the 5ESS switch.

     An audit that runs successfully and does not find any problem
     will not cause a printout.  Only those audits that fail will
     cause a printout.  Figure .AW G120/ is an example of a typical UNIX
     RTR operating system audit failure.

     All audit failure printouts contain the letters AUD as
     illustrated in Figure .AW G120/.
     Audit failures are normally logged in the AUDLOG and DAYLOG
     log files.

       o  AUDLOG: The AUDLOG log file contains the system audit
          failures that are run under the UNIX RTR operating
          system environment.  The user can dump the AUDLOG log
          file by entering the OP:LOG:AUDLOG input message (refer
          to AT&T 235-600-700, Input Messages Manual, for
          details).  Only UNIX RTR operating system audit failures
          are logged in the AUDLOG log file.

       o  DAYLOG: The DAYLOG log file contains the audits (for
          example, application audits) that run under the
          operating system for distributed switching (OSDS)
          environment.  Audits logged in the DAYLOG log file are
          of the message class LAUDIT. The user must specify
          message class AUDTFST to retrieve the audits, because
          DAYLOG contains other message classes.  Use the
          OP:LOG:LG=DAYLOG input message to dump the audits.
          (Refer to AT&T 235-600-700, Input Messages Manual, for
          details.)

     The term environment means which processor and which
     operating system within the processor caused the audit
     failure to print.  The audit environments are as follows:

       o  AM: UNIX RTR operating system

       o  AM: OSDS-operating kernel process (OKP)

       o  AM: OSDS-switching module kernel process (SMKP)

       o  SM: OSDS

       o  CMP: OSDS

       o  PH: OSDS

       o  PI: OSDS

     The UNIX RTR operating system audits are also known as system
     audits.  These audits run under control of the system
     integrity monitor (SIM).  The SIM is responsible for the
     integrity of the software that controls the AM hardware.  The
     SIM schedules and dispatches audits in the UNIX RTR operating
     system environment.
     Audits that run under control of OSDS are called application
     audits.  In this case, an application means that it is not
     part of the UNIX RTR operating system.  Application software
     makes the system implement jobs it was intended to perform.
     Operating system software provides the environment where the
     application software runs.  The OSDS software is part of the
     5ESS switch application software.

     All OSDS audits, in the AM, run under two environments:

       o  OKP: Administers the call processing operations

       o  SMKP: Administers the switch maintenance functions.

     Audits that occur in the SMs run under control of OSDS-
     switching module (OSDS-M).  The OSDS-M administers call
     processing and maintenance functions in the SMs.  These
     audits identify the SM number where audit failures occurred.
     Audits that occur in the primary or mate CMP run under the
     control of OSDS.  The OSDS administers call processing and
     maintenance functions on the CMP.  The audits identify the
     CMP (primary or mate) where audit failures occurred.
     Audits that occur in the PH/PIs run under the control of
     OSDS-switching module (OSDS-M).  The OSDS-M administers call
     processing and maintenance functions in the PH/PIs.  These
     audits identify the PH/PI number where audit failures
     occurred.
       Note:   AT&T 235-600-400, Audits Manual, identifies the
               action for audits requiring manual action.

     The OSDS application audits have an identifier that indicates
     manual action is required.  A manual action required audit is
     identified by the letter ``A''.  Figure .AW G121/ is an example of
     an audit requiring manual action.

     An audit with the letter ``A'' is not usually self-
     correcting.  Manual action must be made to the office data
     base.

     Whenever a manual action audit appears, make a note and save
     the printout for analysis.  If this problem is not resolved
     by local maintenance personnel, escalate to the technical
     assistance organization.
     Audits that do not have the letter ``A'' at the left side of
     the printout are considered to be nonmanual action audits.

     When nonmanual action audits occur, the maintenance personnel
     should be concerned with the quantity of audits dumped.  One
     or two failures of the same audit on an infrequent basis
     should not require any special attention by the maintenance
     personnel.  However, when the same audit fails continuously,
     special attention is required.

     If the audit is failing continuously, determine the location
     and source of the audit.  If a single SM is printing streams
     of audit failures, a problem may exist in the office data
     base or in the hardware (of the specific SM).  Figure .AW G122/ is
     an example of a nonmanual action audit.

     Asserts, also called defensive checks, are small segments of
     code within programs or processes that check the validity of
     data during system operation.  Each time a program reaches a
     defensive check, a test is made to determine if the assertion
     is true.  If it is true (for example, an index is within its
     specified range), no action is taken and the program
     continues. If the assertion is false (for example, a resource
     in one data block is marked as ``idle'' while the same
     resource in another data block is marked as ``in use''), an
     assert failure exists.  The program calls the assert handler
     to report the failure and the assert handler then initiates
     the appropriate action.

     Asserts perform various kinds of checks, including:

       o  Range checks on pointers, global data, and function
          arguments to ensure that reads and writes occur within
          restricted ranges.

       o  Redundancy checks made on duplicate copies of data
          stored at different locations to detect memory
          mutilation.

       o  Point-to/point-back linkage checks to prevent network
          data structure corruption.

       o  Consistency checks between logically related blocks of
          data.

       o  Message acknowledgment checks to ensure that static and
          dynamic data agree.

       o  Return code checks to detect bad return values from
          function calls.

     The assert handler cannot correct the error directly.  After
     an error is discovered and reported, the assert may trigger
     an audit or other corrective action via the assert handler
     (DCF asserts), or it may print a message to the ROP
     requesting repairs be made to the switch ODD (manual action
     assert).
     The assert handler is the software that is called when a
     defensive check fails.  The assert handler is responsible for
     the reporting and the recovery of an assert.  When an
     assertion is evaluated as false, an assert macro calls the
     assert handler to process the assert failure.  The assert
     handler dumps related data and schedules the necessary
     recovery actions by doing one or more of the following:

       o  Dump data relevant to the error.  This includes
          process-related data and data specified by the assert
          macro, including stack traces and stack frames (see AT&T
          235-600-510, Software Analysis Guide, for message
          analysis information).

       o  Invoke audits

       o  Initiate single-process purges

       o  Initiate selective initialization

       o  Initiate a call for manual action

       o  Escalate/de-escalate the requested recovery action.

     This type of assert points to a problem that requires manual
     action.  The switch does not correct the problem that caused
     this assert.  In the illustration shown in Figure .AW G123/, the
     letter ``A'' located at the left of the second line of the
     printout indicates manual action is required.

     AT&T 235-600-500, Asserts Manual, identifies the asserts
     requiring manual action and details the steps to be taken to
     correct the problem.
     Both audits and asserts operate in the same data base and
     perform dynamic verification of the data (that is, data is
     checked for validity as it is used by the system).  However,
     audits and asserts are different, and the following list
     indicates the differences between audits and asserts:

       o  Audits are external programs that operate on other
          programs and data.

       o  Asserts are small bits of software code that are inside
          the program and operate on programs and data in which
          they reside.

     Audits detect errors and recover lost resources; asserts
     detect errors but cannot recover lost resources.  Asserts
     perform a passive or defensive check for errors or problems.
     An assert failure such as invoking an audit can trigger a
     fault-correction procedure separate from the assert itself.
     The RTA DCF assert failure does not fit the pattern of most
     asserts.  This assert does not have a 5-digit failure number
     and does not appear in the assert message summary.  It is
     logged in the DAYLOG log file under message class LDCF.
     Figure .AW G124/ illustrates the RTA DCF error message.

     Most of the time this assert reflects a problem in the data
     base that is covered by a 5-digit assert.  This means the
     problem is probably going to be reported twice. Some problems
     can be reported by an RTA DCF error that does not show up any
     other way.  Therefore, this assert should be watched for
     excessive occurrences.
     The assert summary message prints every 15 minutes and
     contains a list of the assert failures that have occurred
     during that interval.  If no failures have occurred, no
     summary is printed.

     The assert code is printed along with the number of
     occurrences of the assert and the number of discarded assert
     messages.  When a large number of assert messages are
     generated within a 15-minute interval, a number of these
     messages can be discarded to prevent needless repetition.
     Assert messages are discarded if brevity control is allowed
     (brevity control is normally allowed).  If brevity control is
     inhibited, an attempt is made to print all assert messages.

     In Figure .AW G125/, assert number 22184 occurred 3 times, and
     messages from one event were discarded and an attempt is made
     to print two of these events.  Assert number 23439 occurred
     twice, and messages from one were discarded.  Each discarded
     assert includes several related messages (for example, SPP,
     RPI, related stack trace/frame messages) all with the same
     event number.

     The SPP asserts are logged with all of the other SPP
     interrupt messages in the DAYLOG log file under the LSPPIN
     message class.

     The RPI asserts are logged with all of the other RPI
     interrupt messages in the DAYLOG log file under the message
     class LDCF.

     For 5E6 and later software releases, the summary message is
     printed and not logged.

     The DCF SPP assert stimulus message is printed and not
     logged.  The associated assert messages are logged in the
     DAYLOG log file under the INT-MON message class.

     The DCF RPI assert stimulus message is printed and not
     logged. The associated assert messages are logged in the
     DAYLOG log file under the ASRT-MON message class.

     Manual action assert messages are printed and not logged.
     The assert status can be determined by examining switch
     output messages.

     To retrieve the logged messages associated with a stimulus
     message with event number xxxx an OP:LOG:LG=DAYLOG,
     KV=``EVENT=xxxx''...  command would be input from the MCC or
     a TLWS to dump all logged events associated with event number
     xxxx.

     For 5E6 and later software releases, DCF assert stimulus
     messages are printed and not logged.  The remaining DCF
     assert messages are logged.
     Be aware of any assert that repeats regularly, whether or not
     the assert calls for manual action.  This indicates a hard or
     solid problem.

     Any time a ``manual action required'' assert occurs, the
     failure should be resolved.  Manual action asserts occur when
     there is an inconsistency in the data base that cannot be
     resolved by an initialization.
     When analyzing assert failures, use AT&T 235-600-500, Asserts
     Manual, and AT&T 235-600-510, Software Analysis Guide.
     While not all asserts utilize them, there are five basic
     assert messages from the AM, an SM or a CMP that may be
     printed on the ROP (see Figures .AW G126/, .AW G127/, and .AW G128/).  The
     messages printed are determined by which assert macro
     originated the assert.  The five messages are as follows:

        Stimulus Message   Contains general information about
                           the DCF, including failing address
                           of the function, event number, etc.

        Stack Trace        Contains the address where the
                           function itself failed and the
                           addresses of functions preceding
                           the failing function.

        Stack Frame        There are two stack frames output
                           to the ROP.  One belongs to the
                           failing function and the other to
                           the function that called the
                           failing function.

        Data Dumps         Optional hexadecimal data dumps
                           specified by the programmer.

     Figure .AW G126/ is an example of an AM assert printout.

     Figure .AW G127/ is an example of an SM assert printout.

     Figure .AW G128/ is an example of a CMP assert printout.

     The packet interface (PI) and protocol handler (PH) asserts
     are two types of Defensive Check Failures that do not use all
     five messages.  Their output messages consist of a combined
     stimulus and stack trace message (See Figures .AW G129/, .AW G130/, and
     .AW G131/).

     In the PH, the packet switching data structures LLCB, ALCB,
     and/or LCCB that are implicated during a nonreturning assert
     are also dumped.  These types of assert messages are normally
     logged and not printed on the ROP.  Beginning with the 5E6
     software release, the ROP Message Volume Reduction
     Capabilities will restrict assert output in general to the
     stimulus message unless complete output is requested.

     Figure .AW G129/ is an example of a packet interface assert
     message.

     Figure .AW G130/ is an example of a protocol handler 2 assert
     message.

     Figure .AW G131/ is an example of a protocol handler 3 assert
     message.

     See the Assert Analysis section of the Software Analysis
     Guide for a complete description of these assert messages.
     Effective with the 5E9(1) software release, the existing
     switch-resident ODD Population Rule Audit is replaced by the
     Automated SODD Audit, a version that allows the operating
     company to maintain a cleaner data base.  The new audit is
     automatically generated from the Population Rule Language,
     version 5.0, (PRL5) data base population rule source files,
     ensuring completeness and accuracy.

     There are three modes of Automated SODD Audit execution as
     follows:

       o  Full Audit:  The full audit validates the ODD with
          respect to a 149-relation set of population rules.  The
          Automated SODD Audit executes in a continuous loop,
          auditing the 149 relations from beginning to end in an
          on-going review of data.  The audit starts and suspends
          itself according to a schedule selected by the craft.
          Each time the audit resumes execution, it begins where
          the previous execution was suspended.

          When the audit is first deployed, a 7-day, 24-hour
          schedule is set up automatically.  The craft can change
          this schedule to one more suitable to a particular
          office.  Because of the thoroughness of the audit, a
          single cycle through the full audit may take several
          weeks.

       o  Incremental Audit:  The incremental audit automatically
          executes after each successful ODD backup (BKUP:ODD).
          It validates data base transactions (both RCs and CORCs)
          input since the previous BKUP:ODD.

       o  Entity Audit:  The craft can request immediate execution
          of the audit.  Such requests typically limit the scope
          of an audit to a particular processor and relation, or
          to a particular data base entity such as a line, trunk,
          multiline hunt group, or trunk group.

     Each audit execution produces a summary message that
     indicates how many errors were found.  Additionally, each
     audit execution produces a detailed log of individual error
     conditions.  The high-runner error conditions are documented
     by special error messages.  Other error conditions are
     documented by mechanically generated error messages.  Tools
     are provided to output this detailed error log.
     When deployed, the full audit is automatically started with a
     24-hour-a-day, 7-day-a-week schedule.  The craft may alter
     that schedule by using the SCHED:AUD input message.  Refer to
     AT&T 235-600-700, Input Messages Manual, for explanations of
     input message variables.

     Refer to AT&T 235-105-210, Routine Operations and Maintenance
     Procedures, for detailed procedures pertaining to the
     Automated SODD Audit.
     The incremental log-file-directed audit is automatically
     scheduled for execution after each successful BKUP:ODD
     command.  When the craft establishes the backup schedule by
     using the BKUP:ODD command, the incremental audit schedule is
     implicitly established.
     The craft may elect to investigate subscriber complaints by
     running the Automated SODD Audit on a specific entity, such
     as a subscriber line or trunk.  This is accomplished by
     entering input message EXC:AUD=SODD to request immediate
     execution of this entity audit.  The resulting error log file
     is then analyzed to determine if the subscriber trouble is
     data related.
     Input messages INH:AUD=SODD,FULL and INH:AUD=SODD,INCR are
     used, respectively, to inhibit execution of the explicitly
     scheduled full audit and the implicitly scheduled log-file-
     directed incremental audit.

     These audits are reallowed by entering input messages
     ALW:AUD=SODD,FULL and ALW:AUD=SODD,INCR, respectively.
     To determine the current status of the audit, enter input
     message REPT:AUD=SODD.  The status includes an indication of
     which audits are active, which entity is currently being
     audited, how far along the audits are, and so forth.
     Each audit execution concludes with a summary message
     indicating how many errors were detected.  To obtain the
     contents of an existing error log generated by a previously
     executed full or incremental audit, enter input message
     OP:AUD=SODD,ERRLOG.  After investigating the reported error,
     make any necessary data base corrections using RC (and ODBE
     when needed).  Then request an entity audit to verify the
     corrections.

     Refer to AT&T 235-105-220, Corrective Maintenance Procedures,
     for detailed information on analyzing error reports and
     making data base corrections.
     The STP:AUD=SODD,FULL command stops the current execution of
     the full audit, and the STP:AUD=SODD,INCR command stops the
     current execution of the incremental audit.  Properly
     formatted, the STP:AUD=SODD command stops execution of all
     (full, incremental, and entity) running audits.  If multiple
     entity audits are running, each is stopped individually.

     If the STP:AUD=SODD,FULL command has been used, the
     EXC:AUD=SODD,FULL command can be used to restart the full
     audit (provided the schedule allows it).  Otherwise, at the
     next scheduled time, the full audit will restart from where
     it left off.

     If the incremental audit is stopped, it does not restart
     until after the next backup is completed.  Hence, some of the
     transactions from the first log file that were not audited
     may not get audited.  If the STP:AUD=SODD,INCR command has
     been used, the EXC:AUD=SODD,INCR command may be used to
     restart the incremental audit before the next backup begins.
     The source and disassembly listing files of the system are
     contained in the PRs.  The naming concept for PRs is defined
     as follows:

       o  The complete name is in capital letters.

       o  The first part of the name is the processor (SM/AM) on
          which the code is executed.

       o  The second part of the name is the subsystem
          process/software module.

       o  The two parts are divided by a colon ``:''.

     The following is an example of a PR name reflecting the
     guidelines defined previously (processor:subsystem product):

                  SM:FCPOTS

     The PRs are available only in the form of microfiche.
     Therefore, the user must use a microfiche viewer to read the
     PRs.  Remember, some users refer to microfiche as ``fiche''.
     The first page of the PR is the cover sheet containing the
     system name, PR name, PR descriptive title, software release
     issue, PR number, date of issue, page count, and the
     proprietary message.
     The PR document can be divided into the following seven
     sections:

       1. Prologue (optional)

       2. PR section index

       3. Global header index

       4. Local header files

       5. Function index

       6. Main body (source listing and disassemblies)

       7. Epilogue (optional).

     If a prologue is provided, it can be used to supply a variety
     of information to the user (for example, instructions,
     program's functions).  Remember, this section is optional.
     The Section Name appears in either the upper left-hand corner
     or in the center of the first page of each section.  If
     presented in the left-hand corner, the section name appears
     directly below the PR name.  The PR name appears on the upper
     left-hand corner of every page of the PR document.  The PR
     title description (from the cover page) also appears in the
     lower left-hand corner of every page of the PR document.

     There is an exception to this rule, concerning the Main Body
     section where the function name (instead of the section name)
     appears in the upper left-hand corner of the first page of
     the function listing.
     The global header files contain definitions of program
     constants and data structures which may be shared.

     The global header file section follows the PR section index.
     It contains the names of all global header files referenced
     in the PR document and the PK document in which it is found.
     If no global header files are used within the program, the
     word ``NONE'' appears after the words ``GLOBAL HEADER
     FILES''.
     These declarations are declared by the ``include'' statement
     in the program where they are to be used.  See the
     ``include'' statement that follows:

           !include <hdr/as/ASmacros.h>

     Symbols ``< >'' indicate a global header file named
     hdr/as/ASmacros.h.  The ``#include'' gives the complete
     pathname of the file.  It must be included as a part of each
     function in which it is to be used.
     All global header files are documented in the PK cross-
     reference indexes.  These indexes are named: symbol address
     cross-reference index and function address PR name cross-
     reference index.  These indexes are covered later in the
     section.
     Local header files contain private definitions and data
     structures for a particular program.  Local header files
     appear after the last page of the global header file section.
     It defines all the local header files declared by the program
     as well as the listing of the sources for local headers.  If
     no local header files are used in the program, the word
     ``NONE'' appears after the words ``LOCAL HEADER FILES:''.
     The local header files are defined in the local header
     section and are declared within the function where they are
     used.  The declaration is performed with the ``#include''
     statement.  See the following example.

           include  <fc/hdr/FC1st_stag.h>

     In this example, the ``< >'' indicates a local header file
     named fc/hdr/FC1st_stag.h..  The statement indicates this
     file is to be used as a part of the process in which it was
     declared.  Remember, the complete pathname must be specified.
     Local header files are defined within the ``LOCAL HEADER
     FILES'' section of the program where they are used.

       o  These files are arranged alphabetically by the local
          header filename within the specific section.

       o  The name of each local header file appears in the upper
          left-hand corner, directly below the section name of
          each page on which it is documented.

     Global header files can be distinguished from local header
     files by the placement of the ``hdr'' directory in the
     pathname.  When the ``hdr'' is the first directory in the
     path, the header file is global.  When the ``hdr'' is the
     second directory in the pathname, the file is local.  See the
     following example.

                             HEADER FILES

                   Global and Local Header File Differences

                          Global - hdr/xxx/xxxxxx.h
                          Local  - xxx/hdr/xxxxxx.h

     The function index section provides an index to all of the
     functions that make up a particular PR.  The functions are
     sorted by their assembly language starting address and
     function name within the PR.

     The index is presented in a 2-section format.  The first
     section, Figure .AW G132/, is sorted by ``name'' and the second,
     Figure .AW G133/, by ``address.''  The first column indicates how
     the functions are sorted.

       o  The name sort section shows the functions sorted
          alphabetically by name.  The first column in this
          section lists the function name, the second column lists
          the starting address, and the third is the PR document
          page number.

       o  The second section is sorted by starting address.  The
          format for this section is the same as outlined
          previously, except the first and second columns are
          swapped.

     The main body contains the functions which make up the
     program.  Each function has the ``C'' language source code
     listing in one section followed by the disassembled listing
     in the next section.

       o  Functions are arranged numerically in the main body
          section by their physical address.

       o  The function's name is listed at the top of the first
          page of each function description.

     Functions can be distinguished from macros by the name.  A
     macro name can/may not be all capital letters, and a function
     has only the subsystem abbreviation capitalized.  The
     remainder of the name is in lowercase letters.  (See
     following examples.)

          Function            FCdig_coll( )

          Macro               FCGETPORT( )

     Disassembly statements associated with a function begin at
     the top of the next page after the last right-hand brace
     ``}'' of the source code listing for that function.

     The fields of the disassembly listing portion of the function
     (Figure .AW G134/) are as follows:

       o  First field:  LINE NUMBER -- The numbers in [n] brackets
          are break points (expand function).

       o  Second field:  LOCATION -- This field contains the
          hexadecimal address of the first byte of the instruction
          offset from the beginning of the memory block containing
          the function.

       o  Third field:  CONTENTS -- This field is made up of three
          subfields and contains the hexadecimal encoding of the
          instruction.  All three subfields are not always used.

       o  Fourth field:  INSTRUCTION -- This field contains the
          instruction mnemonics.

       o  Fifth field:  INSTRUCTION OPERANDS -- This field
          contains the instruction labels or operands.

     Both the ``C'' language and the disassembly portions of a
     function have decimal numbers within [n] brackets.  The
     numbers relate specific ``C'' source lines to their
     disassembled counterparts as follows:

       o  Function line numbers always begin with number one [1]
          starting at the first left-hand brace ``{'' of the
          function.

       o  Lines are numbered consecutively until the last right-
          hand brace ``}'' of the function.

       o  The numbers within brackets [n] provide a convenient
          reference point between the ``C'' and disassembled code.

     Figures .AW G135/ and .AW G136/ illustrate a portion of both the ``C''
     source and disassembled code for the function FCann_id of
     program SM:FCTN_ANN.  The line numbers can be used to
     reference between the two listings as follows:

       o  Line [5] of the ``C'' source code indicates a function
          call to PHrel passing the symbol FCPATHO as an argument.

            a. Within the disassembled listing line [5], the first
               statement is a move.

            b. The next instruction is move long (move L),

            c. Followed by a jump to subroutine (jsr),

            d. And finally an add long (add L).

     The epilogue is an optional section of the program record.

     When included, this section provides:

       o  Printable data files used by the program

       o  Explanatory comments.

     The PKs contain information on the global headers, symbol,
     function, address information, and PR cross-reference.  The
     naming format for the PK documents is as follows:

       o  Unlike the PRs, only part of the title is capitalized.

       o  The first part of the name identifies the processor.
          This part is capitalized.

       o  The second part of the name identifies the process_name.
          This part can be made up of partially capitalized
          letters or no capital letters at all.

       o  The two parts are separated by a colon``:''.

                     processor:process_name

                            SM:FCimp

     The first page of the PK is the cover sheet.

     The global header information is defined in a set of PKs.

     The PK document is organized as follows:

       o  Global Header PKs are presented alphabetically and
          numerically (for example, A through E is represented in
          PK-100).

       o  SYMBOL ADDRESS CROSS-REFERENCE INDEX and the FUNCTION
          ADDRESS PR NAME CROSS-REFERENCE INDEX are provided for
          all products that can be updated by function replacement
          (for example, OKP and IM.out).

            Note:   The SYMBOL ADDRESS CROSS-REFERENCE INDEX
                    and the FUNCTION ADDRESS PR NAME CROSS-
                    REFERENCE INDEX are orderable as a set of
                    PKs (PK number is PK-5DXXXXX-YY).  These
                    indexes are reissued with every point load.
                    All telephone companies on standing order
                    for group 80 automatically receive these
                    indexes.

     The header file section can be identified by locating the
     filenames listed at the far right portion of the second and
     third lines of the microfiche page header.  These filenames
     are in alphabetical order.  To find where the file is on the
     microfiche page, look at the page index area (G09 - lower
     right-hand display area -- see Figure .AW G137/).  The header files
     can be identified as the files that end with ``.h''.

     From illustration shown in Figure .AW G137/, the first entry on
     Page 99 contains the information on the symbol tag (line P#
     99/tag   .... B06), and Page 100 starts the header file
     section with the file ASmacros.h in area C06.  These header
     files define the symbols listed in the Global Header File
     External Symbol Table.
     The symbol address cross-reference section can be identified
     by looking at the microfiche page header and the index area
     (G09) for the filenames ending with M.  See the
     illustration in Figure .AW G138/ for the example of the G09 symbol
     address cross-reference list.

     The program change (PC) documents for the 5ESS switch are
     issued with each consolidation load (that is, with each new
     software release).  The PC document describes all changes
     applied by these software updates since the first issue of
     PRs and PKs.  The PC document is intended to be used in
     conjunction with the PRs and PKs as a supplementary update.
     The PC document only contains 5ESS switch code changes and
     does not include any changes produced for the UNIX RTR
     computer system.

     The attributes of the PC document are as follows:

       o  An index is supplied that is sorted by the software
          update number, and indicates associated PR number, PR
          name, changed function names, PC issue, and the section
          of the document where the function listing appears.

       o  Contains all changed functions since the last release of
          the PR documentation.

       o  The PC document is cumulative.  Previous issues are
          contained in each release.

       o  If more than one change affects the same function, only
          the most current copy of the function appears in the
          document.

       o  The microfiche produced is based on an individual PR.
          One PR per page or pages of microfiche.

       o  Global headers are not included in the PC document;
          however, their affect upon the functions are included by
          the listing and disassembly contained in the document.

     The PCs are issued for every point load (PC number is PC-
     5DXXXXX-YY). Also, the telephone companies on standing order
     for PRs and PKs automatically receive the PCs.
     The SYMBOL ADDRESS CROSS-REFERENCE INDEX is a document that
     provides a way to convert an external symbol within a bound
     product to its starting address.  The external symbols
     defined are functions, arrays, structures, and variables.
     The information is sorted two ways.  The first sort is keyed
     by address (left two columns).  The second sort is keyed by
     function (right two columns).
     The primary application of this document is for analysis of
     addresses printed on the ROP.  For this application, the user
     scans the address sort looking for an address that is greater
     than the failing address.  Once the address is found, the
     user must back up one entry to find the starting address of
     the symbol containing the desired address and the symbol's
     name.  To determine the PR document that contains a function,
     refer to the FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX.
     To determine the PR document that contains a symbol (that is,
     not a function), refer to the SYMBOL ADDRESS CROSS-REFERENCE
     INDEX.
     The address information contained in this document is correct
     for any office that applies the standard software updates.
     If a craft software update is applied, the address
     information can be skewed by the size of the function added
     in the CFT software update.

     If an entry in this document is in doubt, the definitive
     answer can always be obtained from the 5ESS switch.  The
     UPD:FTRC command can provide this information.
     The FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX provides a
     way to convert an address within a bound product to the PR
     document that contains the source code of that address.  The
     document defines all external functions within the bound
     product, their starting address, and the PR document that
     contains that specific function.
     The information is sorted three ways.  The first sort is
     keyed by address (left three columns).  The second sort is
     keyed by function (middle three columns).  The third sort is
     keyed by PR name (right three columns).
     The primary application of the FUNCTION ADDRESS PR NAME
     CROSS-REFERENCE INDEX is for analysis of addresses printed on
     the ROP.  For this application, the user scans the address
     sort looking for an address that is greater than the failing
     address.  Once the address is found, the user must back up
     one entry to find the starting address of the function
     containing the desired address, the function's name, and the
     PR that contains the source for that specific function.  The
     function index in the appropriate PR is consulted to
     determine which microfiche page contains the source code for
     the function being analyzed.
     The address information contained in this document is correct
     for any office that applies the standard software updates.
     If a craft software update is applied, the address
     information can be skewed by the size of the function added
     in the CFT software update.

     If an entry in this document is in doubt, the definitive
     answer can always be obtained from the 5ESS switch.  The
     UPD:FTRC command can provide this information.
     The SYMBOL ADDRESS CROSS-REFERENCE and FUNCTION ADDRESS PR
     NAME CROSS-REFERENCE INDEXES, when used with the appropriate
     PR document, can guide a user from an address printed on the
     ROP to the associated source code.  This guide is only
     applicable for addresses from OKP and IM.out.  The address
     information assumes that no CFT software updates have been
     added to the switch.  Figure .AW G139/ shows how the cross-
     reference indexes can be used.

       Note:   This example pertains to IM.out, but the steps
               are the same for OKP.

       1. An assert has occurred, and the associated stack
          information has printed on the ROP or has been retrieved
          from the DAYLOG.  Review the first line of the assert
          message to determine the process that asserted (refer to
          the 21200 assert message display in Figure .AW G139/).  The
          display shows OSDSM, which indicates the assert came
          from IM.out (line 1 on Figure .AW G139/).

       2. Extract the list of processes that were on the stack by
          analyzing the USER stack (refer to line 8 of Figure .AW G139/
          ``000CF6D2'').  The USER stack defines all of the open
          function calls that existed at the time of the assert.
          An analysis of the actions performed by these functions
          provide details concerning the status of the process at
          the time of the assert.  The address closest to the word
          ``USER'' (that is, 000CF6D2) is the most recent
          function.  Other functions are represented in reverse
          chronological order, left to right.

       3. To determine the function of an address on the USER
          stack, consult the SYMBOL ADDRESS CROSS-REFERENCE INDEX
          that is sorted by address.  The list is analyzed until
          an address greater than the address in question is
          located.  The function containing the address in
          question is the function previous to the address just
          located.  Refer to the IM.out locations (by address)
          display shown in Figure .AW G140/ (address 0x000CF6D2 is
          between 0 x000cf548 and 0x000cf714).

            Note:   The address in the SYMBOL ADDRESS CROSS-
                    REFERENCE INDEX is the starting address of
                    a function.  The address in question is
                    from the middle of a function.  To locate a
                    function, locate the starting address of
                    the next function, then back up one entry.

       4. Refer to the FUNCTION ADDRESS PR NAME CROSS-REFERENCE
          INDEX sorted by function for the appropriate product.
          Find the function located in the previous step.  The
          number to the left of the function name is the PR number
          which contains the source code.  Refer to the FUNCTION
          ADDRESS PR NAME CROSS-REFERENCE INDEX sorted by function
          name display shown in Figure .AW G141/ [look for PR name (that
          is, AM:IMFPUMP): DBstg2ex].

       5. Refer to the index page of the microfiche within the
          appropriate PR.  Locate the page that contains the
          FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX.  Go to
          that page and look up the function name that had been
          previously found.  This gives the microfiche page of the
          source code for the function.

     The TR303 IDCU remote terminal (RT) is available for 5E8 and
     later software releases.  Provisioning of the TR303 RT is the
     process by which selected system parameters and end user
     subscription data are transferred from the 5ESS switch into a
     TR303 RT.  This is done automatically by the switch whenever
     a change is detected in the switch's copy of the provisioned
     data.  In order to maintain the integrity of provisioned data
     in the RT, the data is refreshed once daily.  A failure
     reporting mechanism is provided to aid in troubleshooting
     provisioning problems and to offer a way to provision all or
     a subset of the data on demand.
     When a TR303 RT is ``grown in,'' field 164 in RC view 18.15
     determines whether or not the switch is responsible for RT
     provisioning.  If field 164 is set to N, the switch will not
     provision any data into the RT.  It is assumed that some
     other Operations System (OS) provisions the RT with data
     consistent with the corresponding 5ESS switch line assignment
     data.  If the field is set to Y, the switch is responsible
     for provisioning all global, DS1, and line assignment data
     into the RT.  If field 164 in RC view 18.15 is updated from N
     to Y, then the input message EXC:RT,PROV,TYPE=ALL must be
     used to provision the RT.  The 5ESS switch will not
     automatically provision the RT upon the commitment of the
     update.
     When the 5ESS switch data base is updated via RC or ODBE, an
     automatic provisioning operation is invoked if the changed
     data is also kept in the RT.  This automatic provisioning
     operation collects the necessary data, formats it according
     to the TR303 interface specification, and sends it to the RT.
     If this operation is unsuccessful because of a transient
     problem [for example, embedded operations channel (EOC) is
     OOS, RT has resource limitations, switch is in an overload
     condition, etc.], the switch stops the current provisioning
     operation and tries again 15 minutes later.  The provisioning
     operation is retried every 15 minutes until it is successful.
     If the provisioning operation is unsuccessful because of a
     nontransient type of error (for example, 5ESS switch data
     base corruption or RT responds with an unexpected failure to
     a provisioning request), the provisioning operation is
     aborted and is not subject to the 15-minute retry scheme.
     Nontransient types of failures are reported to the ROP if
     provisioning reporting is enabled.

     In addition to data base updates, there are several other
     stimuli that cause the switch to provision selected
     parameters into the RT.  These include but are not limited to
     the following:

       o  EOC Recovery from Duplex Fail:  All global and DS1
          parameters are provisioned when the RT's EOC channels
          are restored from a duplex fail state.

       o  System Clock Change:  When the system clock changes for
          any reason, the new local time is provisioned into the
          RT.

       o  RT Provisioning Request:  When the RT requests to be
          reprovisioned via a memory corruption alarm, the switch
          provisions all of the data into the RT.

     In order to maintain the integrity of provisioned data in the
     RT, a routine provisioning operation begins 15 minutes after
     midnight in every SM that has a TR303 remote terminal
     assigned.  The routine provisioning operation sequentially
     steps through all TR303 RTs on the SM and refreshes system-
     level parameters per DS1 and line parameters.  Provisioning
     status messages and individual failure messages are sent to
     the ROP during this operation if provisioning reporting is
     enabled.
     The failure report is available to report provisioning
     failures to the ROP.  The failure report shows the operation
     that was attempted as well as the specific reason for the
     failure.  Reporting can be enabled/disabled on a per-SM as
     well as a per-RT basis.  The default state for reporting is
     disabled.  Failure reporting must specifically be enabled via
     input message ALW:RT,PROV,REPT.  The INH:RT,PROV,REPT command
     is used to disable reporting.  The OP:RT,PROV input message
     is used to get the current reporting state for a given RT.
     Refer to AT&T 235-600-700, Input Messages Manual, for
     information on the use of these commands.
     If for some reason it is believed that the provisioned data
     is out of sync with the switch data, an input message is
     available to cause the switch to refresh on demand, either a
     subset or all of the data in the RT.  The EXC:RT,PROV input
     message causes the switch to immediately try to provision the
     selected data and report the results.  The argument (TYPE=a)
     used in the input message specifies the subset of data to be
     provisioned.  Arguments are as follows:

       o  ALL:  All provisioned data is refreshed.  An RT
          identifier must be provided.

       o  GLOBAL:  Only RT global and DS1-related data is
          refreshed.  An RT identifier must be provided.

       o  IFAC:  Only DS1-related data is refreshed.  An RT
          identifier must be provided.

       o  LINE:  Only data for a single line is refreshed.  A line
          identifier must be provided.

     Refer to AT&T 235-600-700, Input Messages Manual, for
     details.
     When the RT sends a ``memory corruption'' alarm to the
     switch, the switch reprovisions the RT immediately.  This
     should be a rare event, caused by a field technician clearing
     the RT's memory.  The other RT alarm that affects
     provisioning is a ``memory mismatch'' alarm.  This is an
     indication of an internal RT memory failure which cannot be
     cleared automatically.  While in this state, it is unlikely
     that any provisioning operations would be successful.
     Therefore, all provisioning operations are inhibited for that
     RT while it has an active ``memory mismatch'' alarm.  The
     OP:RT,PROV input message described previously also retrieves
     this inhibit status.  When the alarm is cleared via a
     ``memory mismatch clear'' indication from the RT, the inhibit
     is removed.  However, this is not an indication to
     reprovision the RT.  Any service order changes that are
     processed while in the ``memory mismatch'' alarm state
     results in the provisioning operations being deferred.  These
     operations should begin within 15 minutes of the alarm being
     cleared.
     When a TR303 line is assigned, it is placed in the Circuit
     Administration - Provisioning state (OOS CADN DSBLD PROV).
     It remains in this state until the line parameters are
     successfully provisioned into the RT.  Since provisioning is
     normally done immediately following line assignment, the line
     should only be in this state for a few seconds.  However, if
     the EOC is OOS or if the RT responds to the provisioning
     request with an error, the line may stay in the CADN state
     until the error condition is cleared.  The OP:LIST,LINES,CADN
     input message can be used to find lines stuck in the CADN
     state, an indication of potential provisioning problems.
     Some TR303 channel units that the switch does not know how to
     provision are used for nailups/hairpins.  These ``specials''
     are either provisioned locally or provisioned remotely
     through an OS that communicates directly with the RT.  To
     avoid having the switch overwrite this data with its own
     subscription data, a field in RC view 1.6 is used to mark
     lines so that provisioning knows not to touch these specific
     line terminations.  Field ``TR303 NAILUP'' is added to the
     analog line assignment RC view 1.6 to indicate whether or not
     the switch is responsible for provisioning this line.  If the
     field is set to Y, the switch will not provision the line
     termination data for this line, and the line can only be used
     for a nailup/hairpin.  If the field is set to N, the switch
     provisions the line termination data for this line.  In
     either case, Y or N, the switch provisions the time slot
     cross-connection data provided in the nailup/hairpin view (RC
     view 7.11).

     See AT&T 235-105-220, Corrective Maintenance Procedures, and
     AT&T 235-105-210, Routine Operations and Maintenance
     Procedures, for TR303 RT provisioning procedures.

     This section contains the Introduction to MCC Pages subsection
     and the MCC Page Displays subsections for 5E6 and later software
     releases.

       Note:   Product rating for the 5E2(2), 5E3, 5E4, and 5E5
               software releases has been changed to Discontinued
               Availability (DA).  Effective with Issue 7.00 of
               this document, all MCC page displays valid for 5E6
               (or 5E6 and later) previously included in
               subsections for software releases rated DA have
               been moved to the 5E6 subsection.

     This section provides detailed descriptions of the page displays
     of the 5ESS(R) switch master control center (MCC) video
     terminal.  Only the maintenance displays are covered in this
     document. The following page displays are either not covered in
     this section or not covered in this manual:

       o  EMERGENCY ACTION PAGE: Information on the emergency action
          interface (EAI) page can be found in Section .RM 3.2.4/ of this
          manual.

       o  124 - GENERIC RETROFIT: The GENERIC RETROFIT page and its
          two argument pages (ARGSPG1 and ARGSPG2) provide commands
          to perform Software Release Retrofit, Software Release
          Update, and Large Terminal Growth (LTG) transitions on the
          night of retrofit.  The 124 page also shows the status of
          the transitions and displays error messages when abnormal
          conditions occur.

          The 124 page should be used only during software release
          transitions.  Refer to the following manuals for a detailed
          description of the GENERIC RETROFIT page and procedures for
          its use:

            -- AT&T 235-105-24X, Software Release Retrofit Procedures

            -- AT&T 235-105-34X, Software Release Update Procedures

            -- AT&T 235-105-44X, Large Terminal Growth Procedures.

       o  16X, 160,Z, and 161,X - TRUNK AND LINE MAINTENANCE:
          Information on the TLWS, a subsystem of the MCC, can be
          found in Section .RM 3.4/ of this manual.

       o  193 - VERIFY TEXT: Information on the VFYTXT page can be
          found in Section 5 of AT&T 235-105-210, Routine Operations
          and Maintenance Procedures.

       o  194 - SCREEN PROGRAM USER'S GUIDE: Information on the
          Screen Program User's Guide can be found in Section .RM 3.11/ of
          this manual.

       o  195 - GENERIC BACKUP: Information on the GENBACKUP page can
          be found in Sections 4 and 5 of AT&T 235-105-210, Routine
          Operations and Maintenance Procedures; Section 4 contains
          descriptive information on generic backup of disks and
          tapes, and Section 5 contains procedures.

       o  196 - ODD RC/V: Information on office dependent data (ODD)
          can be found in AT&T 235-600-100, Translations Data Manual.
          Also, all recent change/verify (RC/V) views are described
          in AT&T 235-118-2XX (XX = manual number associated to the
          applicable software release), Recent Change Procedural
          Manuals.  Refer to AT&T 235-000-000, Numerical Index -
          Division 235 and Associated Documents, for the complete
          list of RC/V manuals.

       o  198 - SG RC/V and 199 - ECD RC/V: Information on equipment
          configuration data/system generation (ECD/SG) RC/V can be
          found in AT&T 235-600-30X (X = manual number associated to
          the applicable software release), ECD/SG Data Base Manual.
          Refer to AT&T 235-000-000, Numerical Index - Division 235
          and Associated Documents, for the complete list of ECD/SG
          manuals.

     The following information is provided for each page display
     covered in this section:

       1. Statement of purpose.

       2. General information about the display, including the chain
          of events in the hierarchy generated by off-normal
          conditions, if applicable.

       3. Detailed descriptions of complex or unusual indicators.

       4. Illustration of the display with an explanation of
          abbreviations used.

       5. Maintenance menu commands available from the display,
          including any available options which are shown in
          brackets, such as [,UCL] (unconditional).

     Table .AW TAF/, MCC Page Location Guide, can be used for locating
     information on specific MCC pages for specific 5E6 and later
     software releases.  All MCC page displays included in this
     document are listed in the page location guide in numerical
     order by page poke number.

     General

     The following describes several sections that comprise each page
     display (Figure .AW G142/).

     Office Data (Line 1)

     The top line contains the office name and type (from the
     equipment configuration data base), the software release and
     issue, terminal ID, the current date, and a 24-hour clock. This
     information is present on all MCC displays.

     Summary Status Area (Lines 2 and 3)

     Lines 2 and 3 contain the SUMMARY STATUS indicators, which are
     present on all MCC displays. These indicators provide summary
     status of hardware units and software actions in the system.

     The first indicator, SYS EMER (system emergency), flashes when
     the AM loses sanity. The craft should use the EAI (emergency
     action interface) display if this occurs, which is obtained by
     depressing the EA DISP function key on the auxiliary keypad of
     the MCC.

     The next three indicators, CRITICAL, MAJOR, and MINOR, are used
     to show the level of an alarm. When an alarm occurs, the
     indicator for the alarm (for example, BLDG/PWR) starts flashing.
     At the same time, the alarm level indicator backlights to show
     the level, but does not flash. When an alarm is retired, the
     alarm-level indicator returns to normal video; the alarm
     indicator stops flashing, but still remains backlighted.

     The eighth indicator, SYS NORM (system normal), is backlighted
     when there are no off-normal conditions in the system.

     There is a direct correlation between the other indicators and
     the associated display page number. For example, the associated
     page display for the tenth indicator, SYS INH (system inhibits),
     is 110 - SYSTEM INHIBITS.  Information on the other indicators
     is provided in the descriptions of the associated page displays.

     Command and Page Identifier

     The fourth line has five sections. When the MCC is in the
     command mode, CMD appears at the left-hand margin and the cursor
     is positioned immediately after it for command input. Following
     the command input area is an acknowledgment area. The
     acknowledgments that appear here only show whether the input
     command is valid. The next area is used to give execution status
     of the request. The last area on this line contains the page
     number and title; if not, enter 100 for page index.

     Display Region

     Lines 5 through 22 usually contain the text and graphics for the
     display. There are exceptions to this rule. For example,
     displaying 120 - MESSAGES page allows input and output messages
     to scroll into this region. Maintenance and paging commands, if
     any, are usually along the left-hand margin. On a few displays,
     they are across the top because of space restrictions. The first
     digit of the maintenance commands implies the action to be
     taken, as follows:

               First Digit
               of Command               Type of Action

                   1                    Display a page
                   2                    Remove a unit from service
                   3                    Restore a unit to service
                   4                    Switch units or set software control
                   5                    Diagnose a unit or clear software
                                        control
                   6                    Inhibit software control
                   7                    Allow software control
                   8                    Control/display commands
                   9                    Output or initialization control

     Input/Output Message Region

     Line 23 to the bottom of the screen is a normal input/output
     message region. Input messages are entered from the bottom line.
     Input and output messages scroll up from the bottom line of this
     region.
     A 5ESS switch office can be supplied with an MCC video terminal
     that has a black and white display or an optional 5-color (plus
     black and white) display. The most commonly used states in the
     5ESS switch and their video characteristics are listed in
     Table .AW TAG/.

     Black and White Terminals

     On black and white terminals, the general guidelines used in
     selecting the states are as follows:

       o  White on black:  Normal conditions (for example, active or
          unequipped)

       o  Black on white (reverse video):  Off-normal conditions and
          acknowledged alarms (for example, out of service or
          unavailable)

       o  Flashing black on white:  Unacknowledged alarms and severe
          off-normal conditions (for example, critical major and
          minor alarms in the summary status area, a fire alarm or
          isolated SM).

     Color Terminals

     For color terminals, the guidelines used are as follows:

       o  White on black:  Normal conditions (for summary or
          informational indicators)

       o  Green background:  Used for active or predominately active
          units

       o  Cyan background:  Off-normal unalarmed conditions (for
          summary indicators)

       o  White background:  Minor acknowledged alarms, low-severity
          off-normal conditions, and standby units

       o  Yellow background:  Major acknowledged alarms and medium-
          severity off-normal conditions

       o  Red background:  Critical acknowledged alarms and high-
          severity off-normal conditions

       o  Flashing:  Unacknowledged alarms and extremely severe off-
          normal conditions.

     This subsection contains the master control center (MCC) page
     displays and their descriptions that are effective with or
     changed with the 5E6 software release.

     In addition, product rating for the 5E2(2), 5E3, 5E4, and 5E5
     software releases has been changed to Discontinued Availability
     (DA).  All MCC page displays valid for 5E6 (or 5E6 and later)
     previously included in those subsections were moved to the 5E6
     subsection.

     Refer to Table .AW TAF/ for a complete listing of MCC page displays.
     The purpose of the SSA page is to provide the summary status of
     hardware units and software actions in the system.
     The first indicator, system emergency (SYS EMER), flashes when
     the AM loses sanity or when the system initializes. Under either
     of these conditions, the craft should use the Emergency Action
     Interface (EAI) display. The Emergency Action Interface can be
     accessed by depressing the EA DISP function key on the auxiliary
     keypad of the master control center (MCC).

     The next three indicators, CRITICAL, MAJOR, and MINOR are used
     to show the level of an alarm. When an alarm occurs, the
     indicator for the alarm (for example, BLDG/PWR) starts flashing.
     At the same time, CRITICAL, MAJOR, or MINOR will backlight to
     show the level, but these indicators do not flash. When an alarm
     is retired, the CRITICAL, MAJOR, or MINOR indicators will return
     to normal video; the alarm indicator will stop flashing but will
     still be backlighted in the color of the alarm level. When the
     appropriate MCC page is displayed (for example, 105 for
     BLDG/PWR), the alarm indicator will backlight in cyan.

     The fifth and sixth indicators, BLDG/PWR and BLDG INH are driven
     by the combined Page 105/106 (see Figure .AW G145/).  Notice the
     direct correlation between the indicator position and the
     associated display page number.

     For CKT LIM, see MCC Page 107 - CIRCUIT LIMIT (Figure .AW G146/).

     The system normal (SYS NORM) indicator is backlighted when there
     are no off-normal conditions in the system.

     For Overload, see MCC Page 109 - Overload (Figures .AW G147/ and
     .AW G148/).

     For SYS INH, see MCC Page 110 - System Inhibit (Figure .AW G149/).

     For AM and AM PERPH, see MCC Page 111/112 - AM, AM Peripherals
     (Figure .AW G150/).

     For OS Links, see MCC Page 113 - Operations Systems Links
     (Figure .AW G151/).

     For SM, see MCC Page 114 - Equipped SM Status Summary
     (Figure .AW G152/).

     For CM, see MCC Page 115 - CM Summary (Figures .AW G153/ and .AW G154/).

     For MISC, see MCC Page 116 - Miscellaneous (Figure .AW G155/).

     Figure .AW G143/ shows the SUMMARY STATUS AREA. These system
     indicators are presented on all MCC displays. In this example,
     there are no off-normal conditions, which is shown by the SYS
     NORM indicator.

     The purpose of the 100 Page Index is to provide an index of main
     system pages.
     This index is a listing of primary maintenance displays and is
     also an entry point into other subsystem displays, such as trunk
     and line maintenance, equipment configuration data (ECD), and
     office dependent data recent change and verify (ODD RC/V).

     The per-switching module (SM) pages are not shown on this
     display.  The SMs have their own index (1000 - SM PAGE INDEX).

     There is a direct correlation between the page numbers of Pages
     105 through 116 (except 108) and the physical position of the
     status summary indicators in the SUMMARY STATUS AREA.  For
     example, the fifth status summary indicator in the SUMMARY
     STATUS AREA (from left to right) is BLDG/PWR.  Its associated
     display is 105 - BLDG/PWR & ALARM CONTROLS.  Some of the status
     summary indicators do not have an associated display page.
     These are listed on the index as ``NOT ASSIGNED.''  This is a
     built-in trouble-locating shortcut.  The page number for an
     alarm can be derived from the alarmed indicator's position
     without going to this display, although this display is always
     available.

     Information on ODD can be found in AT&T 235-600-104,
     Translations Data Manual.  Also, all RC/V views are described in
     AT&T 235-118-2XX (XX = manual number associated to the
     applicable software release), Recent Change Procedural Manuals.
     Refer to AT&T 235-000-000, Numerical Index - Division 235 and
     Associated Documents, for the complete list of RC/V manuals.

     Information on equipment configuration data/system generation
     (ECD/SG) RC/V can be found in AT&T 235-600-30X (X = manual
     number associated to the applicable software release), ECD/SG
     Data Base Manual.  Refer to AT&T 235-000-000, Numerical Index -
     Division 235 and Associated Documents, for the complete list of
     ECD/SG manuals.

     Pages 196, 198, and 199 (RC/V pages) do not appear when the 100
     Page Index page is displayed at the switching control center
     (SCC) because the RC/V pages cannot be displayed at that
     location.

     Pages 118 (CNI STATUS) and 1211 (NETWORK CLOCK) are shown
     depending on switch configuration.

     Figure .AW G144/ shows an example of the 100 Page Index.

     The commands on this page can be entered from any display page,
     under normal operation. Also, any available per-SM display can
     be accessed. See 1000 - SM PAGE INDEX (Figure .AW G196/) for details.
 2
       CMD     RESULT

       100     PAGE INDEX is displayed
     105/106   BUILDING/POWER AND ALARM CONTROLS page is displayed
       107     CIRCUIT LIMIT page is displayed
       109     OVERLOAD page is displayed
       110     SYSTEM INHIBITS page is displayed
     111/112   AM, AM PERIPHERALS page is displayed
       113     OPERATIONS SYSTEMS LINKS page is displayed
       114     EQUIPPED SM STATUS SUMMARY page is displayed
       115     COMMUNICATION MODULE SUMMARY page is displayed
       116     MISCELLANEOUS page is displayed
       117     IOP APPLICATION PROCESSOR DATA LINKS page is displayed
       118     COMMON NETWORK INTERFACE FRAME AND COMMON CHANNEL
               SIGNALING LINK STATUS page is displayed
       119     MISCELLANEOUS ALARMS page is displayed
       120     MESSAGES page is displayed
       121     IOP 0 & 1 page is displayed
       122     IOP 2 & 3 page is displayed
       123     DISK FILE SYSTEM ACCESS DFC 0-1 page is displayed
       124     GENERIC RETROFIT page is displayed
       125     DISK FILE SYSTEM ACCESS DFC 2-3 page is displayed
       126     DFSA PERFORMANCE DFC 0-1 page is displayed
       127     MTIB page is displayed
       128     DFSA PERFORMANCE DFC 2-3 page is displayed
       129     DEFENSE SERVICES NETWORK NM EXCEPTION page is displayed
       130     NM EXCEPTION page is displayed
       131     CALL TRACE MENU page is displayed
       160     TRUNK AND LINE MAINTENANCE INDEX is displayed
       178     AUTO SPARE DISK page is displayed
       179     DISK CONFIGURATION page is displayed
       180     DISK CONFIGURATION page is displayed
       181     OFFLINE SM 1-48 STATUS SUMMARY page is displayed
       182     OFFLINE SM 49-96 STATUS SUMMARY page is displayed
       183     OFFLINE SM 97-144 STATUS SUMMARY page is displayed
       184     OFFLINE SM 145-192 STATUS SUMMARY page is displayed
       190     C/D UPDATE page is displayed
       191     OS STATUS page is displayed
       193     VERIFY TEXT page is displayed
       194     SCREEN page is displayed
       195     GENBACKUP page is displayed
       196     ODD RC/V is started. NOT FOR USE FROM SCC
       197     CUTOVER page is displayed
       198     SG RC/V is started. NOT FOR USE FROM SCC
       199     ECD RC/V is started. NOT FOR USE FROM SCC
      1000     SM PAGE INDEX page is displayed
      1209     ONTC 0 & 1 page is displayed
      1210     MI/NC 0 & 1 page is displayed
      1211     NETWORK CLOCK page is displayed
      1220     TMS 0 & 1 SUMMARY page is displayed
      1240     MSGS 0 SUMMARY page is displayed
      1250     MSGS 1 SUMMARY page is displayed
      1260     CLNK SUMMARY page is displayed
      1271     REX STATUS page is displayed
      1850     CMP INHIBIT AND RECOVERY CONTROL page is displayed
      1940     EASY BWM INSTALLATION page is displayed
      1950     PROGRAM UPDATE MAINTENANCE MENU page is displayed
      1960     BWM INSTALLATION page is displayed
      1999     STATE DEFINITIONS page is displayed


     The purpose of the 105/106 display page is to summarize
     building/power alarm status and assignment, to provide
     inhibit/allow controls for building alarms, and to provide
     controls for alarm retire mode.
     Building Alarms 02-27 and their alarm levels are office
     assignable. Doors, windows, humidity, etc., are typical types of
     applications. The alarm level and text in these indicators are
     initially filled in using a TTY input message.
     [CHG:ALM,BPSC=building alarm number (2 through 27), TAG=text to
     be filled in, LVL=CR, MJ, MN, or IF.] Once these indicators are
     filled in, they are protected from loss if the system is booted.

     When an alarm indicator is normal, it is displayed in normal
     video (white on black).

     When an alarm condition is present and it is not inhibited, the
     respective display indicator will backlight, except for the FIRE
     indicator. The FIRE indicator flashes in addition to the
     backlighting. In the SUMMARY STATUS AREA, the associated alarm
     level (CRITICAL, MAJOR, or MINOR) will backlight, and BLDG/PWR
     will start flashing. Also, an audible alarm will be sounded.

     When an alarm is inhibited, the respective indicator will have
     "INH" written in and will be backlighted; BLDG INH in the
     SUMMARY STATUS AREA will also backlight.

     The 105/106 Page is accessed by either 105 which maps to the
     fifth critical indicator (BLDG/PWR) of the SUMMARY STATUS AREA,
     or 106 which maps to the sixth critical indicator (BLDG INH).

     Building alarms 02-27 are the only alarms on this page which can
     be inhibited by the craft. Any other inhibit present would be
     the result of a system inhibit.

     The indicator near the top right-hand portion of the display
     shows the retire mode (MANUAL or AUTOMATIC). Manual mode
     requires craft action (depressing the alarm retire key on the
     MCC) to stop CRITICAL and MAJOR alarms from flashing and to shut
     off the audible alarms. Automatic mode shuts off the audible
     alarms after 5 seconds.

     Figure .AW G145/ is an example of the 105/106 display page which shows
     off-normal building and power conditions. The indicator PDF FUSE
     shows a system inhibit.  Indicator 05 shows a major alarm caused
     by a failure in the air-conditioning system. Indicator 09 shows
     the door is inhibited from triggering a building alarm.  The
     office is in the automatic retire mode, as shown in the top
     right-hand area of the display.

     Commands are provided to select retire mode and to inhibit/allow
     building alarms 02-27. Also, all available pages can be accessed
     from the 105/106 display page.

     CMD   RESULT

     6XX   Building Alarm XX is inhibited (INH:ALM,BPSC=XX)
     7XX   Building Alarm XX is allowed (ALW:ALM,BPSC=XX)
     800   Automatic Alarm Retire Mode is enabled (SET:ALMMDE=AUTO)
     801   Manual Alarm Retire Mode is enabled (SET:ALMMDE=MAN)

     The 107 display page provides a listing of trunk groups that
     have exceeded their automatic maintenance limit (AML).
     If all the trunk groups are normal, no trunk group numbers are
     shown on the display.

     When a trunk group's automatic maintenance limit is exceeded,
     the trunk group number is listed. In the SUMMARY STATUS AREA,
     the CKT LIM indicator will be backlighted and flashing. The
     associated alarm level (CRITICAL, MAJOR, or MINOR), will also be
     backlighted, as applicable.

     This display lists the trunk group number(s) of the first 20
     trunk groups out of service, in numeric order.

     When more than 20 trunk groups are out of service, the word
     "EXCESSIVE" will be backlighted at the bottom of the listing.
     Entering the output list command will give a complete listing of
     all out-of-service trunks at the receive-only printer (ROP).

     Figure .AW G146/ is an example of the 107 display page which shows an
     excessive amount of trunk groups out of service. The command 900
     could be entered to get a complete listing.

     A command is provided to output the complete list of out-of-
     service trunk groups.

     All available paging commands can be entered from this display.

     CMD   RESULT

     900   Trunk Group Circuit Limit Listing is printed at the ROP
           (OP:AML) [,TG=a] where a is a specific trunk group number

     The 109 display page provides an indication of resource or
     real-time overloads in the administrative module (AM),
     communication module processor (CMP), and SM(s), and it provides
     commands to inhibit or allow essential service protection (ESP).
     Any AM, SM, or CMP overload conditions are shown on the 109
     display page. The SM and CMP overload information is provided on
     a summary basis.  If an SM overload occurs, the SM number and
     type will be displayed in the indicator and backlighted. If more
     than 16 SMs are in overload, a note will appear, partially
     backlighted, indicating how many SMs are overloaded.  For a
     complete list of SMs in overload, the 900 command should be
     entered.  If a CMP overload occurs, the CMP number and whether
     it is the primary (P) or mate (M) is shown.

     Details on an SM overload can be obtained by entering the
     DISPLAY SM X OVERLOAD INFO command shown on the display.
     Likewise, details on an overloaded CMP can be obtained by
     entering the DISPLAY PRIM CMP X OVERLOAD INFO or DISPLAY MATE
     CMP X OVERLOAD INFO.

     The REALTIME overload indicators will contain NONE, MINOR,
     MAJOR, or CRIT (critical) to show the severity of the overload.
     NONE means no overload exists. MINOR and MAJOR are different
     levels of real-time overloads.  CRIT is only used for SMs and is
     the most severe type of overload.

     The only craft action which can be taken during overload
     conditions is to reduce or eliminate input messages/maintenance
     commands. All other actions are initiated by the system.

     For RESOURCE overloads, either NONE or the name of the resource
     will be displayed. The monitored resources are as follows:

       o  MCB - Message Control Block

       o  PCB - Process Control Block

       o  RCV - Tone Receivers (SM only)

       o  SCB - Stack Control Block

       o  TCB - Timer Control Block

       o  PKB - Packet Buffers [operator services position system
          (OSPS) SMs only]

       o  PSU - Packet Switch Unit (Packet Switching SMs only)

       o  ADB - Analog Data Block (SM only)

       o  APB - Associated Process Block (SM only)

       o  BRCSDB - Business and Residence Custom Services (BRCS) Data
          Block (SM only)

       o  CBDB - Call Buildup Data Block (SM only)

       o  CCBCOM - Channel Control Block (SM only)

       o  CHDB - Channel Data Block (SM only)

       o  CLDB - Calling Leg Data Block (SM only)

       o  DALB - D-Channel Application Linkage Block (SM only)

       o  DIB - Data Interface Block (SM only)

       o  DISPDB - Display Data Block (SM only)

       o  MDB - Model Data Block (SM only)

       o  MSG - Message Overflow (because of PIC overload)

       o  PHDB - Path Data Block (SM only)

       o  SCMDB - Shared Call Model Data Block (SM only)

       o  TSDB - Time Slot Data Block (SM only)

       o  PSIB - X-25 Packet Input Buffer (SM only)

       o  IAQ - CMP Input Queue (CMP only).

     Essential Service Protection is normally inhibited. Therefore,
     the INHIBITED text is not backlighted. When allowed, it gives
     preferential treatment to designated lines (for example,
     hospitals, police, fire departments, etc.) during periods of
     overload.

     If there is a network management control on to prevent overloads
     in this office, the ``SEE PAGE 130'' indicator will show up and
     be backlighted.

     An overload will cause the OVERLOAD indicator at the top of the
     screen to backlight. The associated alarm level (CRITICAL,
     MAJOR, or MINOR) will also backlight, if applicable.

     Figure  .AW G147/ shows an example of the 109 display page with
     specific AM overload information. It also shows up to 16 of the
     SMs and up to 8 of the CMPs that are in overload. The note
     EXCESSIVE is displayed and backlighted because there are greater
     than 16 SMs in overload. The actual number of SMs in overload
     (20) is displayed.

     The AM information box contains information regarding real-time
     and resource overloads in the AM.

     The information provided on Page 109 for the SMs is the SM
     number and type.  For additional information on a specific SM,
     the poke 1300,X is used (where X is the number of the SM).

     Similar to the SM, the CMP has limited information provided on
     Page 109 as shown in Figure .AW G148/.  The information shown is the
     number of the CMP and whether the CMP is the primary or the
     mate.  For more specific information regarding a specific CMP,
     the pokes 1370,X for the primary CMP and 1371,X for the mate CMP
     (where X is the number of the CMP) are used.

     Commands are provided to inhibit and allow ESP, to output a list
     of all SMs that are overloaded, and to obtain detailed
     information on an SM overload condition.

     In addition to these commands, any available paging command can
     be entered from Display Page 109.

      CMD     RESULT

      600     Essential Service Protection is inhibited (INH:ESP)
      700     Essential Service Protection is allowed (ALW:ESP)
      900     Output list of SMs in overload on the ROP (OP:OVRLD:ALL)
     1300,X   SM X Overload Information is displayed
     1370,X   Primary CMP X overload information is displayed
     1371,X   Mate CMP X overload information is displayed

     The 110 display page provides a list of system and AM inhibits
     and provides maintenance menu commands for selected inhibits.
     A SYSTEM inhibit applies to the AM and all SMs.  An AM inhibit
     applies only to the AM. Unless stated otherwise, all inhibit
     requests are assumed to be phase-protected.

     Each inhibit indicator on this display has three distinct
     sections: the top line, the description, and the commands-
     available line.

     The top line in each box shows the box number. This line is
     displayed in normal video, and the field to the right of the box
     number is blank unless an inhibit has been requested by the
     craft. If an inhibit has been requested, INH, SET, MON, or CHG
     is displayed to the right of the box number, as appropriate, and
     the top line is backlighted. (For the remainder of the 110
     display page description, the result of any of these operations
     is referred to as an inhibit.) The presence of this text and
     backlighting combination means the system has recorded the
     inhibit request. It does not mean the inhibit is in effect.

     Most of the inhibit/allow and set/clear commands are effective
     immediately after the request. For these cases, all areas of the
     indicator backlight together and one of the 3-character phrases
     (INH, SET, MON, or CHG) will appear.  However, in a few cases,
     the status will change independent of the request. An example of
     this is shown in box 21. The behavior of each indicator is
     explained in the Indicators section on the next several pages.

     The middle two lines of the indicator is the inhibit
     description. These two lines show the name of the inhibit as
     well as whether or not an inhibit is in effect. Inhibits can be
     caused by system or craft-initiated actions. When an inhibit is
     in effect, this section will be backlighted. In the SUMMARY
     STATUS AREA, the SYS INH indicator will be backlighted.

     The return of the top line to normal video means that a valid
     request to allow (or clear) an inhibit has been accepted. A
     valid allow request will also cause any text in the area to the
     right of the box number to be blanked.

     The last line of each indicator shows which menu commands, if
     any, are available from the display. For example, at the bottom
     of box 17 the numbers ``6 7 9'' appear. The ``6'' means this
     item can be inhibited by entering 617, the ``7'' means it can be
     allowed by entering 717, and the ``9'' designates output is
     available with 917. On color MCCs, there is also color mapping
     from the commands shown on the left of the display to the
     numbers in the boxes. Boxes without commands listed are
     inhibited only by the system or from manual action independent
     of this display page.

     Following is the correspondence between the number key and the
     action taken:

        Number   Action

          4      Set
          5      Clear
          6      Inhibit
          7      Allow
          9      Output

     This paragraph describes the individual indicators and their
     behavior.

     Box 00 - Box 00 is not currently used.

     Box 01 - Message Class Brevity Control

     This indicator shows whether or not the automatic output message
     class brevity control is inhibited. Brevity control is used to
     restrict the generation of certain application output messages
     for both the AM and equipped SMs. Inhibiting message class
     brevity control permits normally suppressed messages to go to
     the ROP or the log file.

     The message class brevity control inhibit must be entered with
     the TTY input message INH:BREVC,MSGCLS=a. Since a named MSGCLS
     is required, a menu command is not provided. Inhibiting brevity
     control for one or more MSGCLSs may cause increased
     communication link traffic which can degrade call processing
     performance and capacity. (See AT&T 235-600-700, Input Messages
     Manual.) The request will display INH when recorded. This
     inhibit will take effect immediately with the request.

     Entering allow command 701 generates the message
     ALW:BREVC,MSGCLS=ALL. The request will clear the text INH when
     recorded. This allow will take effect immediately with the
     request.

     This inhibit is cleared by any high-level AM initialization.

     Box 02 - Message Class Log/Print Status

     The box 02 indicates that at least one message class has the
     log/print status that is different from the backup status.

     To change the log/print status for one or all message classes,
     enter input message CHG:LPS,MSGCLS={a|ALL} with additional
     parameters.  (See the AT&T 235-600-700, Input Messages Manual.)
     The request will display CHG when recorded. This change will
     take effect immediately with the request.

     Entering the menu command 902 generates the input message
     OP:LPS,MSGCLS=ALL and causes the status of the message classes
     to be printed at the ROP.

     Box 03 - MDII Reporting

     The machine-detected interoffice irregularity (MDII) indicator
     is backlighted when one or more MDIIs are inhibited. The
     inhibits are generated by the TTY input message INH:MDII with
     additional parameters. When the inhibit is invoked, it
     suppresses the printing of MDIIs for the trunk group(s)
     specified by the input message. The request will display INH
     when recorded. This inhibit will take effect immediately with
     the request.

     Entering the 903 command generates the message OP:MDII, which
     causes a listing of all suppressed trunk MDIIs to be printed at
     the ROP.

     Box 04 - Manual Recent Change

     This indicator shows whether or not manual entering of recent
     changes is inhibited.

     When the command 604 is entered, the message INH:RC is
     generated. The request will display INH when recorded. This
     inhibit will take effect immediately with the request.

     The allow command 704 generates the message ALW:RC. The request
     will clear the text INH when recorded.

     Since the Automatic Customer Station Rearrangement (ACSR)
     feature depends upon Recent Change, if Recent Change is
     inhibited, ACSR is also inhibited.  During manual inhibits of
     Recent Change, the RC box (box 04) is illuminated and the
     customer-originated recent changes (CORC) box (box 05) is
     partially illuminated.

     Box 05 - Customer-Originated Recent Change

     The box 05 indicator shows whether CORC are inhibited.

     Box 05 is shared by CORCs and the ACSR feature.  Since the ACSR
     feature depends upon Recent Change, if Recent Change is
     inhibited, ACSR is also inhibited.  During manual inhibits of
     Recent Change, the RC box (box 04) is illuminated and the CORC
     box (box 05) is partially illuminated.

     When a 905 command is entered, ACSR queuing is inhibited and
     CORCs are allowed.

     Box 06 - Recent Change Logging

     The box 06 indicator shows whether or not the logging of
     manually entered recent changes for all processors is inhibited.
     This does not include customer-originated recent changes. Recent
     Change logging may be inhibited in the event logging is causing
     a problem, thereby allowing recent changes to be entered.
     Unlogged changes are lost after a boot.

     Entering the command 606 generates the message INH:RCLOG.  The
     request will display INH when recorded. This inhibit will take
     effect immediately with the request.

     Entering the command 706 generates the message ALW:RCLOG.  The
     request will clear the text INH when recorded.

     Box 07 - Box 7 is not currently used.

     Box 08 - Communication Link Normalization

     If a fault occurs in one or more SM communication links, the
     system will automatically try to restore the link(s) on a
     periodic basis. This inhibit will suppress this action when
     active.

     Entering command 608 will generate the message INH:CLNORM.  The
     request will display INH when recorded. This inhibit will take
     effect immediately with the request.

     When the command 708 is entered, it generates the message
     ALW:CLNORM. The request will clear the text INH when recorded.

     Since attempts to restore CLNKS are periodic, there may be a
     delay from the time an allow or inhibit request is recorded
     until the allow or inhibit is recognized.

     Box 09 - Centralized Automatic Message Accounting (CAMA)
     Suspension

     The box 09 indicator shows whether or not calls are being routed
     through the CAMA operator number identification (ONI) process
     for billing. Since inhibiting this indicator causes lost
     revenue, a minor alarm is sounded when the inhibit is invoked.

     Entering the command 609 generates the message INH:CAMAONI.  The
     request will display INH when recorded. This inhibit will take
     effect immediately with the request.

     Entering the command 709 generates the message ALW:CAMAONI.  The
     request will clear the text INH when recorded.

     Box 10 - Trunk Hold

     The box 10 indicator shows whether or not one or more trunk
     groups are being monitored.

     To monitor one or more trunk groups, the input message MON:TRUNK
     must be entered. The request will display MON when recorded.
     This monitoring will take effect immediately with the request.

     The system looks for stop-go signaling failures in members of
     monitored group(s). If a failure occurs, the member is held
     off-hook and out of service for the craft to determine the
     nature of the failure.

     The input message CLR:TRUNK is entered to remove the stop-go
     signaling.

       Warning:   This message will return all members back to
                  service, even if they failed.  The request will
                  clear the text MON when recorded.

     Entering the 910 command generates the input message OP:TRUNK,
     which causes a listing of all trunk groups and members being
     monitored to be printed at the ROP.

     Boxes 11 Through 15 -  Boxes 11 through 15 are not currently
     used.

     Box 16 - Routine Audits

     The box 16 indicator shows if the automatic routine execution of
     one or both AM application audit cycles (OKP or SMKP) are
     inhibited.

     The only way to obtain a single audit inhibit is via a TTY input
     message in the message mode. (See INH:AUD=a,ENV=b in AT&T 235-
     600-700, Input Messages Manual.) Single inhibits are not phase-
     protected.

     Entering the 616 command requests the inhibit of all audits and
     generates the message INH:AUD=CYCLE,ENV. The request will
     display INH when recorded. The request state does not
     necessarily imply that the inhibit is in effect. Normally, the
     status will follow the request within a short period of time.

     If the 716 command is entered, the message ALW:AUD=CYCLE,ENV is
     sent. The request will clear the text INH when recorded. The
     request state does not necessarily imply that the inhibit has
     been cleared. Normally, the status will follow the request
     within a short period of time.

     The command 916 (OP:AUD,STATUS=ALL,ENV=a) can be entered to get
     a ROP listing of routine audit status for the application AM.

     Box 17 - Routine Exercises

     The box 17 indicator shows if any or all of the application
     routine hardware exercises are inhibited in the communications
     module (CM).  Inhibits for routine exercises are effective for
     only one exercise session. If the tests are in progress when the
     message is received, the inhibit will not take place until the
     next session.

     Routine exercises are scheduled to run at specific times (for
     example, daily at midnight). If inhibited exercises are allowed
     after the scheduled time, the exercises are not started until
     the next scheduled session.

     When 617 is entered, the message INH:REX,CM is generated, which
     inhibits all application CM routine exercises. The request will
     display INH when recorded. This inhibit will take effect
     immediately with the request.

     If the command 717 is entered, the message ALW:REX,CM is
     generated, which allows all application CM routine exercises.
     The request will clear the text INH when recorded.

     Entering the command 917 sends the message OP:REXINH,CM, which
     generates a status listing at the ROP.

       Note:   These are application routine exercises and are
               different from the routine exercises for the AM, as
               shown on the EAI display.

     Box 18 - Software Checks

     The box 18 indicator reflects whether or not the AM application
     software checks have been inhibited. The AM software checks and
     the application software checks are different, but are
     controlled together from manual commands.

     The box 18 indicator can only be controlled from the EAI or TTY
     input message INH:SFTCHK.  This inhibit will prevent internal
     software checks from causing initializations. The request will
     display INH when recorded.

     If the status is inhibited without being requested, the inhibit
     was automatically applied by the system.

     A request to allow software checks, ALW:SFTCHK, will clear the
     text INH when recorded.

     Box 19 - Min-Mode

     The box 19 indicator shows the states of application min-mode.
     When this box is backlighted, no call processing functions are
     allowed in the AM. This is only used in extreme emergencies to
     prevent customer actions from interfering with machine
     operations.

     Min-mode is invoked and deleted via EAI application pokes ``M''
     and ``N,'' respectively.

     The request will display INH when recorded. This inhibit will
     take effect immediately with the request following the next
     major AM initialization.

     The request will clear the text INH when recorded and take
     effect on the next major AM initialization.

     Box 20 - Message Brevity Control

     The box 20 indicator gives inhibit status of message brevity
     control for all messages originating from the application
     processes in the AM only.

     Entering inhibit command 620 generates the message INH:BREVC,AM.
     The request will display INH when recorded. This inhibit will
     take effect immediately with the request.

     Entering the allow command 720 generates ALW:BREVC,AM. The
     request will clear the text INH when recorded.

     This inhibit is cleared by any high-level AM initialization.

     Box 21 - Recent Change Backout

     The box 21 indicator shows whether or not uncommitted (recently
     entered) AM recent changes are loaded or backed out. Backout can
     only occur as a result of an AM high-level initialization.

     The description portion shows when the recent changes are
     actually backed out or loaded. If the backout is in progress, a
     number will appear on the third line of the box showing the
     progress of the backout. From 200 down to 100 is CORC backout;
     200 meaning CORC is still fully backed out, and 100 meaning CORC
     is fully rolled forward. From 100 down to 0 is RC backout; 100
     meaning RC is still fully backed out, and 0 meaning RC is fully
     rolled forward. Recent changes can be backed out only in
     conjunction with a high-level initialization.

     Recent changes should be backed out if a recent change is
     suspected to be the cause of an AM performance problem.

     When the command 421 is entered, the message SET:BACKOUT,RC,AM
     is generated. The request will display SET when recorded. The
     request state does not necessarily imply that the set is in
     effect.

     When the command 521 is entered, the message CLR:BACKOUT,RC,AM
     is sent. The request will clear the text SET when recorded. The
     request state does not imply that the backout has been cleared.

     Boxes 22 Through 27 -  Boxes 22 through 27 are not currently
     used.

     Figure .AW G149/ is an example of the 110 page display which shows one
     system inhibit set and two AM inhibits set. Routine Exercises in
     box 17 has been inhibited. Box 21 shows RC BACKOUT is currently
     set and has been partially backed out (80%). However, the top
     line is normal video and there is no SET text after the 21. This
     indicates that the craft does not desire the recent changes to
     be kept out.

     In addition to the following commands, all available display
     commands can be accessed from Display Page 110.
 2

     CMD   RESULT

     421   RC Backout (AM) is set (SET:BACKOUT,RC,AM)
     521   RC Backout (AM) is cleared (CLR:BACKOUT,RC,AM)
     604   Manual RC is inhibited (INH:RC)
     606   RC Logging is inhibited (INH:RCLOG)
     608   CLNK Normalization is inhibited (INH:CLNORM)
     609   CAMA is inhibited (suspended) (INH:CAMAONI)
     616   Routine Audits (AM) are inhibited (INH:AUD=CYCLE,ENV)
     617   Routine Exercises (CM) are inhibited (INH:REX,CM)
     620   Message Brevity Control (AM) is inhibited (INH:BREVC,AM)
     701   Message Class Brevity Control is allowed (ALW:BREVC,MSGCLS=ALL)
     704   Manual RC is allowed (ALW:RC)
     706   RC Logging is allowed (ALW:RCLOG)
     708   CLNK Normalization is allowed (ALW:CLNORM)
     709   CAMA is allowed (no longer suspended) (ALW:CAMAONI)
     716   Routine Audits (AM) are allowed (ALW:AUD=CYCLE,ENV)
     717   Routine Exercises (CM) are allowed (ALW:REX,CM)
     720   Message Brevity Control (AM) is allowed (ALW:BREVC,AM)
     902   Message Class Log/Print Status is output (OP:LPS<MSGCLS=ALL)
     903   MDII Report is output (OP:MDII)
     905   CORC Status is output (OP:STAT,CORC,ACSR)
     910   Trunk Hold list is output (OP:TRUNK)
     916   Routine Audits (AM) are output (OP:AUD,STATUS=ALL,ENV)
     917   Routine Exercises (CM) are output (OP:REXINH,CM)


     The purpose of the 111/112 display page is to report status of
     the AM and its peripherals.
     The AM is an AT&T 3B20 duplex computer. In addition to the AM
     and peripheral indicators on this display, there are additional
     indicators for Page 121 - IOP 0 & 1, Page 122 - IOP 2 & 3, Page
     123 - DISK FILE SYSTEM ACCESS for DFC 0-1, Page 125 - DISK FILE
     SYSTEM ACCESS for DFC 2-3, and Page 113 - OPERATIONS SYSTEMS
     LINKS. If common network interface (CNI) is equipped, there is
     also an indicator pointing to Page 118 - CNI FRAME AND CCS LINK
     STATUS.

     An off-normal condition on this page will cause the AM or AM
     PERPH indicator at the top of the screen to backlight. An off-
     normal condition in an MHD (Page 123) will backlight the ``SEE
     PAGE 123'' indicator and the AM PERPH at the top of the screen.
     Also, an off-normal condition in an MHD (Page 125) will
     backlight the ``SEE PAGE 125'' indicator and the AM PERPH at the
     top of the screen.  An off-normal condition on Page 121 will
     backlight the ``SEE PAGE 121'' indicator(s) and the AM PERPH at
     the top of the screen. An off-normal condition on Page 122 will
     backlight the ``SEE PAGE 122'' indicator(s) and the AM PERPH at
     the top of the screen. An off-normal condition on Page 118 will
     backlight the ``SEE PAGE 118'' indicator and the AM PERPH at the
     top of the screen if CNI is equipped. An off-normal condition in
     the SCCs will cause the ``TO SCC 0'' or ``TO SCC 1'' indicator
     to backlight, and the OS LINKS indicator at the top of the
     screen will backlight. In all these cases, the appropriate alarm
     level (CRITICAL, MAJOR, or MINOR) will also backlight, if
     applicable.

     Figure .AW G150/ shows various off-normal conditions in the AM and its
     peripherals.

     The CSU 1 and AM 1 are unavailable. This caused the AM indicator
     at the top of the screen to backlight. An MHD on Page 123 is out
     of service, causing the SEE PAGE 123 to backlight, and there is
     a problem on Page 121 with some device or devices connected to
     IOP controller 0. These two conditions have caused the AM PERPH
     indicator at the top of the screen to backlight. Also, SCC 1 is
     either out of service, unavailable, or being initialized, which
     is shown by backlighting in the TO SCC 1 indicator at the bottom
     right-hand portion of the display. This off-normal SCC condition
     caused the OS LINKS indicator at the top of the screen to
     backlight.

     The 111/112 page provides commands to remove, restore, diagnose,
     and switch the various units. Also, output commands are
     available for out-of-service and diagnostic listings.

     All available displays can be accessed from the 111/112 page.
 2

     CMD   RESULT                        CMD   RESULT

     20X   AM X is removed               30X   AM X is restored
           (RMV:CU=X)                          (RST:CU=X)[,UCL]
     21X   DFC X is removed              31X   DFC X is restored
           (RMV:DFC=X)                         (RST:DFC=X)[,UCL]
     23X   IOP X is removed              33X   IOP X is restored
           (RMV:IOP=X)                         (RST:IOP=X)[,UCL]
     24X   MTTYC X is removed            34X   MTTYC X is restored
           (RMV:MTTYC=X)                       (RST:MTTYC=X)[,UCL]
     25X   MTTY X is removed             35X   MTTY X is restored
           (RMV:MTTY=X)                        (RST:MTTY=X)[,UCL]
     26X   ROP X is removed              36X   ROP X is restored
           (RMV:ROP=X)                         (RST:ROP=X)[,UCL]
     50X   AM X is diagnosed             400   AM is switched
           (DGN:CU=X)[,UCL]                    (SW:CU)
     51X   DFC X is diagnosed            401   PORTSW is switched
           (DGN:DFC=X)[,UCL][,CONT]            (SW:PORTSW)
     53X   IOP X is diagnosed            402   ROP is switched
           (DGN:IOP=X)[,CONT][,UCL]            (SW:PORTSW:ROP)
     54X   MTTYC X is diagnosed          403   MTTY is switched
           (DGN:MTTYC=X)[,UCL][,CONT]          (SW:PORTSW:MTTY)
     404   OOS units are listed at ROP
           (OP:CFGSTAT,OOS)
     405   Diagnostic request queue is
           output at ROP, including
           restore/remove requests
           (OP:DMQ,AM)


     The 113 display page provides a listing of Operations Systems
     links and their status.
     There are various types of Operations Systems which can be
     linked to an office.  These systems provide additional services
     to an office. Some of the systems which may appear on this
     display are discussed in the following paragraphs.

     The Automatic Message Accounting Data Link (AMADL) connects the
     Automatic Message Accounting Teleprocessing System (AMATPS) with
     a Revenue Accounting Office (RAO). The AMATPS assembles billing
     data.

     The Centralized Automatic Reporting on Trunks (CAROT)
     automatically accesses and tests trunks.

     The Centralized Trunk Test Unit (CTTU) is a test position for
     remote trunk and line testing.

     The Engineering and Administration Data Acquisition System
     (EADAS) collects, stores, and analyzes the traffic data.

     The Mechanized Loop Testing System Generation 2 (MLT2) is used
     for testing and analyzing the condition of customer loops for
     the Automated Repair Service Bureau (ARSB).

     The No. 2 Service Evaluation System (NO2SES) provides large
     volume service evaluation and incorrect answer supervision
     identification.

     The Operator Services Position System Recent Change (OSPSRC)
     link provides restricted recent change/verify access to OSPS
     data on the 5ESS(R) switch.

     The Remote Memory Administration System (RMAS) provides standard
     recent change/verify access. It prints office records, provides
     on-line growth capability for many recent changes, and provides
     an on-line error-checking capability.

     The Software Change Administration and Notification System 2
     (SCANS2) is used to transmit Broadcast Warning Messages (BWMs)
     to both the office and the Switching Control Center (SCC).

     The No. 2 SCC provides facilities to administer, monitor,
     control, and maintain the 5ESS switch from a remote, centralized
     location.

     The Testing, Operations, Provisioning, and Administration System
     (TOPAS) link provides centralized trunk maintenance and
     administration for trunks terminating on 5ESS switch toll
     configurations.

     There are several columns of information shown for each system.
     The first column, OS, is the standard link abbreviation (for
     example, AMADL2). The next column, LINK, shows whether the link
     is primary or secondary. The TYPE column shows whether the link
     is dedicated or dial-up. The DEVICE column contains the
     abbreviation of the peripheral device and the status of the
     link. The PC NAME is the name of the peripheral controller for
     the assigned peripheral device. This column is for information
     only. It does not show status. Status for the peripheral
     controllers is found on 121 - IOP 0 and 1 or 122 - IOP 2 and 3.
     The last two columns, TIME BUFF and DATA BUFF are used to show
     time and data buffer overflows. These columns are not applicable
     (N/A) to many of the systems.

     Any off-normal condition on this page will cause the OS LINK
     indicator at the top of the screen to backlight. The appropriate
     alarm level indicator (CRITICAL, MAJOR, or MINOR) will
     backlight, if applicable.

     The operations systems links vary from one office to another.
     Figure .AW G151/ shows SCC 1 is unavailable, which can be determined
     from the backlighted indicator and accompanying status text
     (UNAV).

     Commands are available to remove and restore the SCCs.

     All available displays are also accessible from the 113 display
     page.

     CMD   RESULT

     200   SCC 0 is removed (RMV:SCC=0)
     201   SCC 1 is removed (RMV:SCC=1)
     300   SCC 0 is restored (RST:SCC=0,UCL)
     301   SCC 1 is restored (RST:SCC=1,UCL)

     The purpose of the 114 page is to provide a summary of all
     equipped switching modules (SM) and their operational states.
     Each equipped SM has a unique indicator on the 114 display. The
     indicator has two distinct sections:

       o  SM NUMBER: There may be gaps in SM numbering for a
          particular office.  To provide flexibility in office
          numbering schemes, the SM numbers are not necessarily
          assigned sequentially. If an SM is not equipped, it is not
          listed. An example of this is shown in the 114 page example
          (Figure .AW G152/) by the blank indicators between SM 12 and SM
          20, SM 20 and SM 24, etc.

       o  SM TYPE: This is a 1-character designation to show how an
          SM is being used. For example, an L is an LSM which is a
          local switching module.

     When a new alarm condition on an SM happens, the SM indicator
     will begin flashing. The ALM RLS key will not stop the flashing.
     The color of the flashing may not reflect the new alarm if the
     previously recorded condition is of higher priority. To stop the
     flashing, the craft should display the 1010 Page for that SM.
     There is also a command to retire the flashing (999). This is
     mainly provided for situations such as during installation when
     SMs are being grown in and many SMs are displaying recurrent
     error conditions.  For further details on any SM recovery
     related activity or SM inhibits, the craft would enter 1800,X to
     display the SM X INHIBIT AND RECOVERY CONTROL page. This is the
     SM control page for emergency action.

     A lower level summary page for observing up to 48 SMs
     simultaneously can be requested by entering 141 (SMs 1 - 48),
     142 (SMs 49 - 96), 143 (SMs 97 - 144), or 144 (SMs 145 - 192).

     For details on any backlighted SM, the craft would enter 1010,X
     to display the SM X STATUS page. This page can be accessed
     during SM X initialization or if SM X is isolated, but the only
     status that will fill in are the SM STAT and RELATED PAGES
     boxes.

     In Figure .AW G152/, LSMs 1, 3, and 6 and HSM 10 and RSMs 48 and 120
     are backlighted due to an off-normal condition in each.

     All available paging commands can be entered from the 114
     display page.

       CMD     RESULT

       141     SM 1 - 48 page is displayed
       142     SM 49 - 96 page is displayed
       143     SM 97 - 144 page is displayed
       144     SM 145 - 192 page is displayed
       999     SM flashing is retired
      1000     SM INDEX page is displayed
     1010,X    SM X STATUS page is displayed
     1600,SZ   SITE Z STATUS page is displayed
      1610     REMOTE SITE INDEX page is displayed

     The purpose of the 115 display page is to provide a summary of
     off-normal status for the hardware units and links which control
     AM to SM(s) communication and provide paths for all circuit
     switched calls.
     The 115 display page has two separate and distinct versions.
     The first version (Figure .AW G153/) is for offices with communication
     module model 2 (CM2) hardware. The second version (Figure .AW G154/)
     is for offices with CM1 hardware.

     The 115 page provides overall status for MSGS 0, MSGS 1, MI/NC 0
     (MI/LI/NC 0 for CM1), MI/NC 1 (MI/LI/NC 1 for CM1), TMS 0, TMS
     1, communication links for the SMs, fan and fan fuse alarms for
     the ONTCs (for the MSGSs and TMSs for CM1), the status of the
     hardware check inhibit request bit, and the status of the
     MI/NC/TMSs (MI/LI/NC/TMSs for CM1) functioning as a group
     (ONTCCOM).

     The ONTCCOM 0 includes MI 0 (LI 0 in CM1), NC 0, and TMS 0.  The
     ONTC 0 includes ONTCCOM 0 and all DLIs on side 0.  The ONTCCOM 1
     includes MI 1 (LI 1 in CM1), NC 1, and TMS 1.  The ONTC 1
     includes ONTCCOM 1 and all DLIs on side 1.

     If an MSGS, MI/NC (MI/LI/NC in CM1), or TMSLNK has an off-normal
     condition (out of service not family of equipment, unavailable,
     hardware checks inhibited, or off-normal software status), the
     appropriate indicator with the page number of the MCC page with
     the detailed information is backlighted. The phrase ``SEE PAGE
     XXXX IF BACKLIT'' is backlighted when any of the boxes are
     backlighted to point out that the numbers in the boxes are the
     page numbers to request.

       Note:   The 1210 boxes are backlighted only for NC
               reference or oscillator problems.

     The CLNKS indicator is a summary of the equipped SM
     communication links status which is detailed on Page 1260.

     The CLNKS are not TMS links. The TMS links are part of the TMS.
     Communication links consist of several components, one of which
     is the TMSLNK.

     The indicator in the center, CM HDWCHK INH REQ, only appears on
     the page if the data delivery request automatic hardware check
     bit is set (due to automatic escalation or manual request).  It
     indicates that there is an inhibit request for all CM hardware
     checks. This means that at the next high-level AM
     initialization, all application hardware checks will be
     inhibited. This bit can be manually set and cleared by the input
     messages INH:HDWCHK and ALW:HDWCHK, respectively. Note that
     allowing hardware checks on all the CM units individually will
     not clear the bit, and this indicator will remain on the page.

     The backlighted indicator indicates the page necessary for
     acting on the problem.  As an example, the box with 1242
     indicated is backlighted in the page example shown in Figure .AW G153/
     because a module message processor (MMP) on Display Page 1242 is
     shown as out of service (OOS).  The MMP out of service is also
     reflected on the MSGS 0 Page 1240, but going to 1240 would not
     be the final step to see and act on the problem so the MSGS 0
     box with 1240 indicated is not backlighted. If a foundation
     peripheral controller (FPC) or pump peripheral controller (PPC)
     was out of service also, then the MSGS 0 box would backlight as
     shown in Figure .AW G154/. The purpose of this strategy is to get the
     craft directly to the problem with minimum paging.  Therefore,
     if the 1240 (MSGS 0) box and the 1241 (or 1242) were both
     backlighted, an out of service (not family of equipment), an
     unavailable, an out-of-service power, or an unavailable power
     condition would exist in an MMP, FPC, PPC, or CMP and an MSCU.

     The TMS 0 and 1 boxes (indicating Page 1220) will never
     backlight. If a TMS is OOS, it would be due to the whole ONTC
     being OOS or UNV; therefore, 1209 is the appropriate page to
     display.

     The indicator FPC DPLF is displayed to signal FPC duplex failure
     or CM ISOL is displayed to indicate manual CM isolation.  A
     separate indicator is displayed to indicate if the data delivery
     manual CM isolation request bit is set.

     The 115 page display example in Figure .AW G153/ shows problems in
     MI/NC 1, MSGS 0, TMS 0, CLNKS, and ONTC 1. Further information
     on these problems would be found on display 1210 - MI/NC 0 & 1,
     1242 - MSGS 0 - COMMUNITIES 2 - 7, 1221 - TMS 0 TMS LINKS 002 -
     063, 1260 - CLNK SUMMARY, and 1209 - ONTC 0 & 1. There is a fan
     alarm on ONTC 0 and the ONTC 1 Fan Fuse Alarm is inhibited. The
     CM isolation indicator is showing that CM isolation is in
     effect.  Also, the hardware check inhibit request bit is set.

     Figure .AW G154/ is an example of the 115 summary display that shows
     problems in MI/LI/NC 1, MSGS 0, TMS 0, CLNKS, and ONTC 0.
     Further information on these problems would be found on displays
     1210 - MI/LI/NC 0 & 1, 1240 - MSGS 0 SUMMARY, 1221 - TMS 0 - TMS
     LINKS 002 - 063, 1260 - CLNK SUMMARY, and 1209 - ONTC 0 & 1.
     There is a fan alarm on MSGS 0 and the TMS 0 fan fuse alarm is
     inhibited.  The indicator is signaling that FPC duplex failure
     is in effect.

     There are no menu commands on the 115 display page. Commands for
     removing, restoring, diagnosing, etc., are listed on the related
     pages. There are no menu commands on the displays for fans or
     fan fuses. For fans or fan fuses, see CLR:FANALM in AT&T 235-
     600-700, Input Messages Manual.

     All available display commands can be entered from the 115
     display page.
     The 116 display page provides status for various
     units/activities which do not fall under any other grouping.
     The External Sanity Monitor (ESM) has indicators for alarm,
     inhibit, and power. If an alarm or an inhibit is present, the
     appropriate indicator will backlight. If power is off, the POWER
     indicator will backlight and the word OFF will be displayed.

     The CALL MONITOR indicator shows whether the Call Monitor is
     inhibited or allowed.  Entering the command 601 generates the
     message INH:CALLMON which will inhibit the monitor from making
     test calls and performing call completion analysis.  This also
     clears the monitor's history data.  The command 701 generates
     the message ALW:CALLMON which allows the monitor to start the
     cycle of making test calls and performing call completion
     analysis.  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 generates the
     OP CALLMON PAST 15 MINUTE REPORT on the ROP.

     The indicators FRAME FUSE and FRAME FAN are for the
     miscellaneous frame.  If a fuse or fan alarm is present on the
     miscellaneous frame, the corresponding indicator will backlight.
     The fuse must be replaced to correct the frame fuse alarm.  The
     fan must be restored to operating condition to correct the frame
     fan alarm.  The input command CLR:FANALM,MFFAN can be entered to
     clear the frame fan alarm after the alarm condition is fixed.
     If a system inhibit is present, the word INH will be displayed
     and backlighted to the right of the indicator label.  The fuse
     and fan alarms can only be inhibited by the system.  An inhibit
     means a scan point is chattering.  The input command
     ALW:ALM,MFFAN can be entered to allow the scan point after the
     chattering problem is fixed.

     The indicator GENERIC RETROFIT will backlight and change to
     GENERIC RETROFIT ACTIVE when software release (generic) retrofit
     is in progress.

     The indicator ODD EVOL will backlight and change to ODD EVOL ACT
     when ODD Evolution is in progress.  THE ODD Evolution is
     initiated by the command BKUP:ODD,ODDEVOL and stays in effect
     until the actual software release cutover takes place.

     The indicator OSPS EVOL will backlight and change to OSPS EVOL
     ACT when OSPS Evolution is in progress.  The OSPS Evolution is
     initiated by the command BKUP:ODD,ODDEVOL if the office has an
     OSPS configuration active.  It stays in effect until the actual
     software release cutover takes place.

     The RC BACKUP indicator normally shows NORMAL on the right part
     of the indicator. If RC Backup fails in the AM, the text NORMAL
     changes to FAILURE and the entire indicator backlights.

     The MISCELLANEOUS ALARMS indicator has two subindicators: ALARM
     and INHIBIT.  These subindicators are backlighted for any alarm
     and/or inhibit conditions present on the MISCELLANEOUS ALARMS
     display.  For additional information, enter command 119.

     The next indicator, MTIB, will backlight if an off-normal
     condition exists on the MTIB display. Enter command 127 for
     further details.

     In the CUTOVER indicator, the word ACTIVE will backlight if an
     off-normal condition exists on the CUTOVER display (cutover
     enabled, for example). Further information can be found on
     display 197 - CUTOVER.

     Any off-normal condition will cause the MISC indicator in the
     SUMMARY STATUS AREA at the top of the screen to backlight.

     Figure .AW G155/ is an example of the 116 display page which shows an
     alarm and an inhibit present on 119 - MISCELLANEOUS ALARMS.
     There is also something off-normal on Page 127 - MTIB STATUS.
     These have caused the MISC status summary indicator at the top
     of the screen to backlight.

     Commands are provided to inhibit and allow the ESM and to clear
     (retire) the exit pilot lamps.  Commands are also provided to
     inhibit and allow the call monitor, output the past 15-minute
     interval history for the call monitor, and retire a call monitor
     alarm.

     Also, all available displays can be accessed from the 116
     display page.

     CMD   RESULT

     600   External Sanity Monitor is inhibited (INH:ALM,ESM)
     601   Call Monitor is inhibited (INH:CALLMON)
     700   External Sanity Monitor is allowed (ALW:ALM,ESM)
     701   Call Monitor is allowed (ALW:CALLMON)
     800   Exit Pilot Lamps are cleared (retired) (CLR:LAMPS)
     801   Call Monitor alarm is retired (RTR:CALLMON,ALARM)
     901   Call Monitor history is output (OP:CALLMON)

     The purpose of the 117 page display is to provide a summary of
     information associated with the application processor data links
     (APDL).
     The 113 page indicates that maintenance personnel can display
     the 117 page, if desired.

     The following items contain detailed information concerning each
     field in the 117 page display:

       o  LINK:  This field identifies the link by name (for example,
          APDL01).  The 01 attached to the APDL is the link number of
          the link that is added to tuple relation RLCMAPDATA.  The
          link number is between 1 and 6 that corresponds to the
          number assigned to that link via RC/V view 24.1.

       o  PORT:  This field indicates the data link connected to the
          administrative module-input/output processor (AM-IOP).

       o  MODULE:  This field indicates the data link is connected to
          the AM-IOP.

       o  DEVICE:  This field identifies the PC port and the hardware
          status. The possible states are as follows: active (ACT),
          out of service (OOS), initialization (INIT), or growth
          (GROW).  Also, the UCB of the SDL is indicated.  For
          example, in SDL 42 OOS, 42 is the UCB of the SDL.

       o  PC NAME:  This field identifies the PC on which the port is
          located.  For application processor (AP) data links, there
          is only one port per PC.

       o  SITE_ID:  This field identifies the AP to which the link is
          connected (also known as the AP).  The SITE_ID number
          matches the key field on RC/V view 24.1.

       o  SESSION:  This field indicates the BX.25 session status
          over a given link.  The possible states are as follows:
          connected (CONN), disconnected (DISC), or initialization
          (INIT).

     Figure .AW G156/ shows an example of the 117 page display.

     Any of the available page displays can be accessed from the 117
     page display.

     CMD       RESULT

     121        Peripheral controller status is displayed -- IOP 0 & 1
     122        Peripheral controller status is displayed -- IOP 2 & 3

     The purpose of the 118 page is to provide status and maintenance
     commands for the common network interface ring peripheral
     controller nodes (RPCN), link nodes (LN), and direct link nodes
     (DLN).
     The function of the DLN (an optional capability) is to relieve
     the AM real-time capacity constraint caused by common channel
     signaling (CCS).  This is accomplished by moving CCS signaling
     message processing from the AM to the DLN.  The DLN is equipped
     as two independent simplex ring nodes operating in
     active/standby mode; meaning, one DLN is active, while the other
     is in the standby mode ready to be switched to active.  Call-
     related signaling messages are routed onto the ring to the DLN
     instead of the existing ring peripheral controller (RPC).  Ring
     maintenance, link security, and administrative messages are
     still processed in the AM via the RPC.

     When the DLN option is equipped, the common network interface
     (CNI) frame has a physical limitation of five LNs per group.
     The DLNs are assigned to LN member position 2 in both groups 00
     and 32 and are indicated ``DLN.''  Also, the signaling link
     status LN(00/32)-2 is blank.

     The 118 page is divided into three basic areas.  The box at the
     left side of the display is the status indicator and reflects
     the overall CNI status.  The status displayed here can be one of
     the following (where DSIG = direct signaling, TSIG = trunk
     signaling, and TCAP = transaction capability):

       o  DSIG ACT:  If the GLDSSPEED is 48 and office is equipped
          with 4.8 kbps links, or if the GLDSSPEED is 560 and office
          is equipped with 56 kbps links, the status indicator block
          will contain ``DSIG ACT'' (indicating the appropriate links
          are active).

       o  DSIG OOS:  If the GLDSSPEED is 48 and the office is
          equipped with 4.8 kbps links, or if the GLDSSPEED is 560
          and the office is equipped with 56 kbps links, and the link
          (4.8 kbps or 56 kbps) is OOS, the status indicator block
          will contain ``DSIG OOS''.

       o  DSIG UNEQ:  If the GLDSSPEED is 48 and the office is only
          equipped with 56 kbps links, or if the GLDSSPEED is 560 and
          the office is only equipped with 4.8 kbps, the status
          indicator block will contain ``DSIG UNEQ''.

       o  TSIG ACT:  If the RLPCIPRT relation has tuples populated
          and one of the available links is active, the status
          indicator block will contain ``TSIG ACT''.

       o  TSIG OOS:  If the RLPCIPRT relation has tuples populated
          and all available links are OOS, the status indicator block
          will contain ``TSIG OOS''.

       o  TSIG UNEQ:  If the RLPCIPRT relation has no tuples
          populated, the status indicator block will contain ``TSIG
          UNEQ''.

       o  TCAP ACT:  If the RLDS_APP relation has tuples populated
          and the 56 kbps links are active, the status indicator
          block will contain ``TCAP ACT''.

       o  TCAP OOS:  If the RLDS_APP relation has tuples populated
          and the 56 kbps links are OOS, the status indicator block
          will contain ``TCAP OOS''.

       o  TCAP UNEQ:  If the RLDS_APP relation has no tuples
          populated, the status indicator block will contain ``TCAP
          UNEQ''.

     During CNI ring initializations, the DSIG, TSIG, and TCAP
     indicators in the STATUS box will show INIT.  When the status is
     INIT, no other information on the display page can be considered
     accurate until the initialization has completed.

     The box in the middle of the display shows the node status.
     There are two columns within this area; the first column is the
     major status of the nodes, and the second column is the minor
     status of the nodes.  The major status can be one of five
     states:

       o  ACT:  This indicates that the RPCN, LN, or DLN is active.

       o  OOS:  This indicates that the RPCN, LN, or DLN is out of
          service.

       o  STBY:  This indicates that the RPCN, LN, or DLN is in
          standby.

       o  GROW:  This indicates that the RPCN, LN, and DLN is in the
          growth state.

       o  UNEQ:  This indicates that the node is unequipped.

     The minor status can be one of four states:

       o  ISO:  This indicates that the node is isolated.

       o  BISO:  This indicates that the node is beginning isolation.

       o  EISO:  This indicates that isolation is ending.

       o  NORM:  This indicates that the node is normal.

     The boxes on the right side of the display provide the link
     status.  The first column in the link status area shows the 11-
     character far-end CLLI code of the link.  The second column is
     the major state, the third column is the minor state, and the
     fourth column is the processor outage (PRO) received status.

     The major status can be one of three states:

       o  AVAL:  This indicates that the link is available.

       o  UNAL:  This indicates that the link is not available.

       o  UNEQ:  This indicates that the link is unequipped.

     The minor status can be one of six states:

       o  IS:  This indicates that the link is in service.

       o  OOS:  This indicates that the link is OOS.

       o  MOOS:  This indicates that the link is in a manual OOS
          state.

       o  GROW:  This indicates that the link is in the growth state.

       o  TEST:  This indicates that the link is being tested.

       o  UNAV:  This indicates that the link is not available.

     The PRO RCVD column is an indication of a processor outage
     received from the signal transfer point and is either YES or NO.

     Any off-normal condition in the middle section of the page (the
     RPCNs or the LNs) will cause the SEE PAGE 118 indicator on the
     111/112 page to be backlighted.  In the SUMMARY STATUS AREA, the
     AM PERPH critical indicator and the alarm level (CRITICAL,
     MAJOR, or MINOR), if applicable, will be backlighted.

     Two additional status indicators are the ring status indicator
     (RSI) and the automatic ring recovery (ARR) shown as follows:

       1. Ring Status Indicator:

          This indicator appears at the top left-hand side of the 118
          page under the system alarm indicators.  Its purpose is to
          show the state of the CNI ring.  The following lists the
          possible values and their meanings:

            o  ACTIVE:  The CNI ring has all nodes active.

            o  DOWN:  The CNI ring has a critical problem and no CCS
               call processing can be completed.

            o  ISOLATED SEGMENT:  The ring has one or more nodes
               under diagnostics which requires a quarantine or
               isolation of the node.

            o  RESTORING:  Indicates that the node is being pumped
               and should soon go ACT.

            o  CONFIGURING:  The ring has just RESTORED a node and
               the ring is propagating the token to allow the node
               back into service with the rest of the ring.

       2. Automatic Ring Recovery (ARR):

          The ARR indicators are not seen on the 118 page until a
          node is faulted.  Once a node is down and ARR attempts to
          recover the node, the appropriate indicator will light.
          The ARR has three indicators which will appear at the
          bottom left hand corner of the 118 page just under the
          diagnostic pokes.  The indicators will show the type of
          recovery being done and which node is currently being
          worked on.  If more than one node is down, then an OP:DMQ
          may be performed at the bottom of the MCC to see if the
          node has been queued for restoral by ARR.  The following is
          the possible outputs of each indicator.

            a. First Indicator outputs are as follows:

                 o  ARR UCL:  The ARR will attempt to restore the
                    node without running diagnostics.

                 o  ARR COND:  The ARR will attempt to restore the
                    node but will run diagnostics first.

                 o  CNR UCL:  The ARR has detected that a duplex
                    failure has occurred and that restoration of the
                    node will be done without running diagnostics.

                 o  CNR COND:  The ARR has detected that a duplex
                    failure has occurred and that the node will be
                    run under diagnostics before restoration.

            b. Second Indicator outputs are as follows:

                 o  ARR RSTRT:  The ARR is restarting the node.  This
                    indicator can be lighted at the same time any of
                    the preceding indicators are on.

                 o  CNR RSTRT:  The ARR has detected the duplex
                    failure and is restarting the node.  This
                    indicator can also be lighted at the same time
                    any of the preceding indicators are lighted.

            c. Third Indicator outputs are as follows:

                 o  ACNR UCL:  The ARR has detected the duplex
                    failure of the Direct Link Nodes (DLNs).  An
                    unconditional restoral will be performed on the
                    DLN listed.

                 o  ACNR COND:  The same as ACNR UCL except that ARR
                    will run diagnostics before restoring the node.

                 o  ACNR RSTRT:  The same as CNR RSTRT except this
                    indicator deals with the restart of the DLN node
                    only.

     Figure .AW G157/ shows an example of the 118 page.

     The frame status for the DLNs are divided into two categories.
     The ``aaaa'' field illustrates the major states of the DLN, and
     the ``bbbb'' field illustrates the minor states.

     The 118 page provides commands to remove, restore, and diagnose
     the RPCNs and the DLNs and to output any off-normal conditions
     for the ring or the signal link.

     All available displays can be accessed from the 118 page.

 2
      CMD    RESULT

     20XX    RPCN XX is removed from service (RMV:RPCNXX=0)
             (XX can only be 00 or 32)
     21XXY   LNXX Y is removed from service (RMV:LNXX=Y)
             (XX can only be 00 or 32 and Y can only be 1 through 6)
     22XX2   DLNXX 2 is removed from service (RMV:LNXX=2)
             (XX can only be 00 or 32)
     30XX    RPCNXX is restored to service conditionally [or unconditionally]
             (RST:RPCNXX=0,RAW,TLP)[,UCL]
             (XX can only be 00 or 32)
     31XXY   LNXXY is restored to service conditionally [or unconditionally]
             (RST:LNXX=Y,RAW,TLP)[,UCL]
             (XX can only be 00 or 32 and Y can only be 1 through 6)
     32XX2   DLNXX 2 is restored to service conditionally [or unconditionally]
             (RST:LNXX=2,RAW,TLP)[,UCL]
             (XX can only be 00 or 32)
     50XX    RPCN XX is diagnosed (DGN:RPCNXX=0,RAW,TLP)[,RPT=a][,PH=b[&&c]]
             (XX can only be 00 or 32)
             a is the number of times the diagnose is to be repeated
             b is the phase
             b&&c is the range of phases to be performed
     51XXY   LNXX Y is diagnosed (DGN:LNXX=Y,RAW,TLP)[,RPT=a][,PH=b[&&c]]
             (XX can only be 00 or 32 and Y can only be 1 through 6)
             a is the number of times the diagnose is to be repeated
             b is the phase
             b&&c is the range of phases to be performed
     52XX2   DLNXX 2 is diagnosed (DGN:LNXX=2,RAW,TLP)[,RPT=a][,PH=b[&&c]]
             (XX can only be 00 or 32)
             a is the number of times the diagnose is to be repeated
             b is the phase
             b&&c is the range of phases to be performed
      900    Status of a RING is printed (OP:RING:DETD)
      901    Status of the signaling links is printed (OP:SLK=ALL,DEST=1)

     The 119 display page summarizes status and assignment and
     provides inhibit/allow controls for miscellaneous alarms.
     Miscellaneous Alarms and their alarm levels are office
     assignable. The alarm level and text in these indicators are
     initially filled in using a TTY input message
     (CHG:ALM,MISC=miscellaneous alarm number, TAG=text to be filled
     in, LVL=CR, MJ, MN, or IF).  Once these indicators are filled
     in, they are protected from loss if the system is booted.

     When an alarm condition occurs and is not inhibited, the
     respective display indicator backlights to the TROUBLE state.
     This in turn causes ALARM to backlight in the Miscellaneous
     Alarms Indicator on Page 116. In the SUMMARY STATUS AREA, the
     associated alarm level (CRITICAL, MAJOR, or MINOR) will
     backlight, and MISC will start flashing. Also, an audible alarm
     will be sounded.

     When an alarm is inhibited, the respective indicator will show
     INH, and the INH will be backlighted. On Page 116, INHIBIT in
     the Miscellaneous Alarms Indicator will also backlight. The MISC
     indicator at the top of the screen will backlight to the TROUBLE
     state.

     Figure .AW G158/ is an example of the 119 display page in which
     indicator 03 shows a major alarm caused by a failure in the MFT
     bay. Indicator 06 shows the SLC P/M 1 is inhibited from
     triggering an alarm.

     Commands are provided to inhibit and allow the miscellaneous
     alarms.

     All available displays are accessible from the 119 display page.

     CMD   RESULT

     6XX   Miscellaneous Alarm XX is inhibited (INH:ALM,MISC=XX)
     7XX   Miscellaneous Alarm XX is allowed (ALW:ALM,MISC=XX)

     Display Page 120 provides full-page TTY message viewing.
     When Page 120 is displayed, TTY messages scroll into the region
     normally used for displays.

     Figure .AW G159/ is an example of the 120 display page.

     There are no commands for the 120 page.
     The purpose of the 121 and 122 pages is to provide status and
     assignment of all input/output processor (IOP) peripheral
     control devices.
     The displays for IOP 0 and 1 and IOP 2 and 3 are very similar.

     Each IOP has 16 slots for peripheral control devices. Any or all
     of these slots can be assigned.

     In the example shown in Figure .AW G160/, scanner and signal
     distributor controller (SCSDC) 4 and SCSDC 6 are out of service.
     This causes the SEE PAGE 121 indicator on Page 111/112 to
     backlight, which in turn backlights the AM PERPH indicator at
     the top of the display.

     There are no maintenance commands available from the display for
     the IOP PC devices. To remove, restore, or diagnose a device,
     the appropriate TTY input message must be entered instead.

     Remove messages have the form RMV:dev=a, where a is the device
     number. For example, to remove MTTYC 0, the input message is
     RMV:MTTYC=0.

     Restore and diagnose messages are the same, except for the verb.
     For example, to diagnose SCSDC 4, the input message is
     DGN:SCSDC=4.

     All available page commands can be entered from the 121 and 122
     display pages.
     The purpose of the 123 display page is to provide status and
     maintenance commands for two disk file controllers (DFC) and up
     to 16 moving head disks (MHD).  It also provides status and
     commands for disk independent operation (DIOP) when both
     essential disks are lost and status of the Auto MHD
     Configuration feature.

     A 5ESS switch office can have Storage Module Device (SMD) only,
     Small Computer Systems Interface (SCSI) only, or a combination
     of SMD and SCSI disk subsystem.

     If there are more than two DFCs in the system, a second DFSA
     page, Page 125 is used.  The format of the 125 page is the same
     as the 123 except the AUTO MHD CONFIGURATION status is not
     shown; it appears only on Page 123.
     The 123 page has three separate and distinct functions.

     The first function of this page is to provide status and
     maintenance commands for DFCs 0 and 1 and associated MHDs (up to
     16).  If the system is equipped with SCSI, this page also
     provides status and maintenance commands for SCSI buses (SBUS)
     (up to 4).

     The second function is to provide status and commands during
     DIOP.  When both of the MHDs that are marked essential (E) go
     out of service, this page is automatically displayed.  This is
     called full DIOP.  The appropriate menu commands to use under
     these circumstances are the 600 series of commands.  When in
     full DIOP (Figure .AW G162/), a 620 command will appear which will
     allow the MHD to be reloaded from tape without bringing down
     call processing during the reading of the tape.  When the MHD
     has been reloaded, a minimum of a 52 boot is required.  The
     other 600 series commands, with the exception of the 699 poke,
     may be used also when not in DIOP.  The 699 poke works only in
     full DIOP.  The 602 poke to restore the DFC controller requires
     UCL when the system is in full DIOP.  Neither the 602 or 604
     poke will restore associated subunits (MHDs) to prevent
     accidental disk restoral during disk maintenance.

     If only one of the essential MHDs goes out of service, the MHDs
     are in simplex operation (Figure .AW G161/), but the page is not
     automatically displayed.

     During full DIOP, the area at the bottom of the page between the
     two horizontal lines will display output messages for the 600
     series menu commands.

     The third function of the 123 page is to provide for the display
     of the Automatic MHD Configuration feature.  The AUTO MHD
     CONFIGURATION  data displayed on 123 page is a summary status of
     information from Pages 178, Auto Spare Disk, and 179, Disk
     Configuration.

     Possible values of the Automatic MHD Configuration feature are
     as follows:

       a. AUTO MHD CONFIGURATION READY:  The feature is armed and
          ready to run if needed.

       b. SEE PAGE 179, CONFIG MHDs ...:  The listed MHDs have been
          reconfigured; see Page 179 for more data.

       c. AUTO MHD CONFIGURATION OFF:  The feature is turned off.

       d. MHD CONFIG INHIBITED, SEE PAGE 178:  The feature is blocked
          on one or more MHDs or the entire office; see Page 178 for
          more data.

       e. MHD CONFIG IN PROGRESS, SEE PAGE 178:  An MHD configuration
          is in progress; see Page 178 for more data.

     There are two columns of notations on the right side of each of
     the MHD status columns.  The first of the two columns contains
     one of two letters:

       o  Y - (Yes):  This means the MHD was diagnosed or restored
          since the last system initialization and appears to be
          usable.

       o  N - (No):  This means the MHD was not diagnosed or restored
          since the last system initialization and does not appear to
          be usable.

     The second column contains the letter E which signifies that the
     associated MHD is essential.

     The upper two display fields, OPTION LEVEL and CURRENT LEVEL,
     inform the user of the optional disk independent operation
     feature level selected for the operating system and the current
     disk independent operation state the operating system is in.

     The OPTION LEVEL displayed will be one of the following:

      NODIOP    Disk independent operation feature is not selected.

      DIOP      Conditional disk independent operation is selected.

      UCLDIOP   Unconditional disk independent operation is selected.

     The CURRENT LEVEL displayed will be one of the following:

      NORMAL         Normal operating system without disk independent
                     operation mode.

      SIMPLEX        Operating system running with at least one essential
                     MHD out of service.

      DUPLEX         Operating system is running with all duplex essential
                     MHDs active.

      CONDITIONAL    Operating system is in conditional disk independent
      DIOP           operation mode with the last remaining duplex
                     essential MHD about to be removed from service.

      FULL DIOP      Operating system in running with a duplex essential
                     pair of MHDs out of service.

     For each unit displayed, the following information is shown.

       1. Major state of the unit

       2. Minor state of the unit (if available)

       3. Usability of the unit (Y = usable, N = unusable)

       4. Essential status of the unit (E = essential, M = manually
          nonremovable, blank = nonessential)

       5. Microcode status (Firmware of Pumpcode) for the DFC

       6. Overload status of a DFC.

     Figure .AW G161/ shows the simplex version of the disk file system
     access page for an office with SMD only.  In this example, one
     of the essential MHDs (MHD 1) is OOS, so the current level is
     marked as SIMPLEX. The OOS MHD caused the AM PERPH indicator at
     the top of the page to be backlighted.  The automatic MHD
     configuration feature is ready.

     When the simplex mode is entered, the system begins to lock
     essential, nonswappable processes from disk into core (AM
     memory).  Upon completion of the locking process, the system
     will print the message, REPT DIOP SIMPLEX PROCESSING COMPLETED.
     If the system has problems in locking the essential processes
     into core, it will print the message, REPT DIOP SIMPLEX UNSWAP
     FAILURE PID=xx (xx = utility ID of process that failed to lock
     into memory).  This message will reprint every 5 minutes until
     the locking process is completed.

     Figure .AW G162/ shows the FULL DIOP version.

     Figure .AW G163/ shows the simplex version of the disk file system
     access page for an office with SCSI only or with both SMD and
     SCSI.

     The only difference between the SCSI-DFSA and SMD-DFSA versions
     of the 123 page is the addition of ``SBUS 0 SBUS 2'' under DFC
     0, ``SBUS 1 SBUS 3'' under DFC 1 on the SCSI version, and the
     604 command for RST/RMV SBUS.

     Commands are provided to remove, restore, and diagnose the MHDs
     and to take appropriate actions on the MHDs when one or more
     essential MHDs are out of service.

     All available displays can be accessed from the 123 page.

 2
            CMD          RESULT

            2XX          MHD XX is removed from service
                         (RMV:MHD=XX)
            3XX          MHD XX is restored to service
                         (RST:MHD=XX)
            5XX          MHD XX is diagnosed
                         (DGN:MHD=XX)
     600,n [v] [s|new]   MHD n is formatted (initialized)
                         (INIT:MHD=n)
                         v=VFY. Verify option to be used (default=no verify
                         option).
                         s=Track number or range of tracks to be initialized
                         (default=all tracks).  The track number or range
                         of tracks and the ``new'' option can only be used
                         for SMD MHD.
         601,n [s]       MHD n is verified
                         (VFY:MHD=n)
                         where s represents either:
                               t=XX (XX is track number or range of tracks
                               to be verified)
                               (default=all tracks for SMD MHD)
                         or
                               b=XX (XX is block number or range of blocks
                               to be verified)
                               (default=all blocks for SCSI MHD)
                         (For example: 601,0 b=80&&100 will cause the
                         VFY MHD function to be invoked for MHD 0 and
                         will verify blocks 80 through 100 for SCSI MHD).
         602,n [a]       DFC n controller only is restored
                         a=UCL
                         (RST:DFC=n,CONT)
       603,n [t|fn]      Dump MHD n defect table
                         t=Defect table to be dumped:MFGR,COMB,TEMP,
                         ALL,(default=COMB).
                         fn=Full pathname of a file, in double quotes,
                         that the MFGR defect table is to be written to
                         (DUMP:MHD=n:DEFECT)
        604,n {opt}      RESTORE or REMOVE SBUS
                         {opt} ``RST'' or ``RMV''
                         (RST:SBUS=n,CONT)
                         (RMV:SBUS=n)
                         Note: For SBUS RST, UCL option is required
                         in full DIOP.
          677,n t        EIR (Enhanced Information Report) PRINT
                         n=DFC unit number
                         t=EIR format.  Valid values are ``n''=turn off
                         EIR PRINT
                         ``l''=long EIR report format, ``s''=short EIR
                         report format
           6XX,h         HELP OPTION
                         Give help for 600 series commands

            CMD          RESULT

            688          Clears the buffer
            699          Aborts the menu command that is presently in
                         progress

                            Note:  The 699 poke works only while the
                            system disk is in full DIOP.  It is not
                            effective in normal or simplex modes.

        620,n td a       Loads MHD n from tape drive td using sequence a
                         td=Tape device name
                         a=BOTH,GEN,DBONLY or CONT.

                            Note:  The 620 poke appears only while
                            the system disk is in full DIOP.  It is not
                            effective in normal or simplex modes.


       Note:   The 600 series commands work while the system disk
               is in full DIOP except that poke 602 (DFC
               controller only restore) requires UCL.

     The purpose of the 125 display page is to provide status and
     maintenance commands for two disk file controllers (DFC) and up
     to 16 moving head disks (MHD).  It also provides status and
     commands for disk independent operation (DIOP) when both
     essential disks are lost.

     A 5ESS switch office can have SMD only, SCSI only, or a
     combination of SMD and SCSI disk subsystem.

     The 125 page exists only when there are more than two DFCs in
     the system.

     The format of the 125 page is the same as the 123 except the
     AUTO MHD CONFIGURATION status is not shown; it appears only on
     Page 123.
     The 125 page has two separate and distinct functions.

     The first function of this page is to provide status and
     maintenance commands for DFCs 2 and 3 and associated MHDs (up to
     16).  If the system is equipped with SCSI, this page also
     provides status and commands for SCSI buses (SBUS) (up to 4).

     The second function is to provide status and commands during
     DIOP.  When in full DIOP, the 125 page will be accessible.  The
     620 poke (reload from tape option) will only work on the 123
     page.  The other 600 series commands, with the exception of the
     699 poke, may be used also when not in DIOP.  The 699 poke works
     only in full DIOP.  The 602 poke to restore the DFC controller
     requires UCL when the system is in full DIOP.  Neither the 602
     or 604 poke will restore associated subunits (MHDs) to prevent
     accidental disk restoral during disk maintenance.

     If only one of the essential MHDs goes out of service, the MHDs
     are in simplex operation (Figure .AW G164/), but the page is not
     automatically displayed.

     During full DIOP, the area at the bottom of the page between the
     two horizontal lines will display output messages for the 600
     series menu commands.

     There are two columns of notations on the right side of each of
     the MHD status columns.  The first of the two columns contains
     one of two letters:

       o  Y (Yes):  This means the MHD was diagnosed or restored
          since the last system initialization and appears to be
          usable.

       o  N (No):  This means the MHD was not diagnosed or restored
          since the last system initialization and does not appear to
          be usable.

     The second column contains the letter E which signifies that the
     associated MHD is essential.

     Figure .AW G164/ shows the simplex version of the disk file system
     access page for an office with SMD only. In this example, one of
     the essential MHDs (MHD 17) has gone out of service, so the
     current level is marked as SIMPLEX. The OOS MHD caused the AM
     PERPH indicator at the top of the page to be backlighted.

     When the simplex mode is entered, the system begins to lock
     essential, nonswappable processes from disk into core (AM
     memory).  Upon completion of the locking process, the system
     will print the message, REPT DIOP SIMPLEX PROCESSING COMPLETED.
     If the system has problems in locking the essential processes
     into core, it will print the message, REPT DIOP SIMPLEX UNSWAP
     FAILURE PID=xx (xx = utility ID of process that failed to lock
     into memory).  This message will reprint every 5 minutes until
     the locking process is completed.

     Figure .AW G165/ shows the simplex version of the disk file system
     access page for an office with SCSI only or with both SMD and
     SCSI.

     The only difference between the SCSI-DFSA and SMD-DFSA versions
     of the 125 page is the addition of ``SBUS 0 SBUS 2'' under DFC
     2, ``SBUS 1 SBUS 3'' under DFC 3 on the SCSI version, and the
     604 command to RST/RMV SBUS.

     Commands are provided to remove, restore, and diagnose the MHDs
     and to take appropriate actions on the MHDs when one or more
     essential MHDs are out of service.

     All available displays can be accessed from the 125 page.

 2
            CMD          RESULT

            2XX          MHD XX is removed from service
                         (RMV:MHD=XX)
            3XX          MHD XX is restored to service
                         (RST:MHD=XX)
            5XX          MHD XX is diagnosed
                         (DGN:MHD=XX)
     600,n [v] [s|new]   MHD n is formatted (initialized)
                         (INIT:MHD=n)
                         v=VFY. Verify option to be used (default=no
                         verify option).
                         s=Track number or range of tracks to be initialized
                         (default=all tracks).  The track number or range
                         of tracks and the ``new'' option can only be used
                        for SMD MHD.
         601,n [s]       MHD n is verified
                         (VFY:MHD=n)
                         where s represents either:
                               t=XX (XX is track number or range of
                               tracks to be verified)
                               (default=all tracks for SMD MHD)
                         or
                               b=XX (XX is block number or range of blocks
                               to be verified)
                               (default=all blocks for SCSI MHD)
                         (For example: 601,0 b=80&&100 will cause
                         the VFY MHD function to be invoked for MHD 0 and
                         will verify blocks 80 through 100 for SCSI MHD).
         602,n [a]       DFC n controller only is restored
                         a=UCL
                         (RST:DFC=n,CONT)
       603,n [t|fn]      Dump MHD n defect table
                         t=Defect table to be dumped:MFGR,COMB,TEMP,
                         ALL,(default=COMB).
                         fn=Full pathname of a file, in double quotes,
                         that the MFGR defect table is to be written to
                         (DUMP:MHD=n:DEFECT)
        604,n {opt}      RESTORE or REMOVE SBUS
                         {opt} ``RST'' or ``RMV''
                         (RST:SBUS=n,CONT)
                         (RMV:SBUS=n)
                         Note: For SBUS RST, UCL option is required
                         in full DIOP.
          677,n t        EIR (Enhanced Information Report) PRINT
                         n=DFC unit number
                         t=EIR format.  Valid values are ``n''=turn off
                         EIR PRINT
                         ``l''=long EIR report format, ``s''=short EIR
                         report format
           6XX,h         HELP OPTION
                         Give help for 600 series commands

            CMD          RESULT

            688          Clears the buffer
            699          Aborts the menu command that is presently in progress

                            Note:  The 699 poke works only while
                            the system disk is in full DIOP.  It is not
                            effective in normal or simplex modes.

        620,n td a       Loads MHD n from tape drive td using sequence a
                         td=Tape device name
                         a=BOTH,GEN,DBONLY or CONT.

                            Note:  The 620 poke appears only while
                            the system disk is in full DIOP.  It is not
                            effective in normal or simplex modes.


       Note:   The 600 series commands work while the system disk
               is in full DIOP except that poke 602 (DFC
               controller only restore) requires UCL.

     The 126 display page provides the optional disk access
     performance data for the AT&T 3B20D computer.

     A 5ESS switch office can have SMD only, SCSI only, or a
     combination of SMD and SCSI disk subsystem.

     There are a maximum of two DFCs on a DFSA performance page.  If
     there are more than two DFCs in the system, a second DFSA
     performance page (Page 128) is used.

     The 126 page can show either SMD-DFSA or SCSI-DFSA, depending on
     the feature option of the operational office.

     With the SCSI feature, the DFSA performance data is not
     available when the operating system is in disk independent
     operation (DIOP) mode.

     Meanings of the performance fields displayed are as follows:

       o  CMP:  Jobs completed by the DFC for the unit.  This field
          is normalized to show the number of jobs that were
          completed per second.

       o  AVG:  The Average size of the jobs completed for a unit
          (number of disk blocks).

       o  MAX:  The maximum size of a job completed in a time
          interval (number of disk blocks).

     Figure .AW G166/ shows an example of the 126 display page for an
     office with SMD only.

     Figure .AW G167/ shows an example of the 126 page with mixed SMD and
     SCSI DFCs.

     The DFC fields are the sum of the individual MHD fields
     associated with the DFC.  For SCSI DFC, the SBUS fields are the
     sum of all the MHD fields associated with this SBUS.

       CMD     RESULT

     622,S,T   Performance updates are displayed
               S=number of seconds between statistic updates.  Valid number
               of seconds is between 1 and 60.  Performance updates will occur
               20 times, then will be automatically turned off.  If S is
               defaulted, then performance updates are turned off.
               T=number of seconds that the performance updates will last.
       688     The 3-line communication area at the bottom of the page
               is cleared.
      6XX,h    HELP OPTION
               Give help for 600 series commands

     The 127 display page shows status and connections for the
     metallic test interconnect bus (MTIB).
     The MTIB is used for multiple metallic service units (MSU).  Any
     SM which is equipped with the multiple MSU will have all the
     MTIB connections. The MTIB CONNECTIONS indicator shows which SMs
     are equipped with this unit.

     When an off-normal condition occurs, the MTIB XX indicator
     backlights and the MTIB indicator on Page 116 - MISCELLANEOUS
     backlights. In the SUMMARY STATUS AREA, the critical indicator
     MISC will backlight, as well as the alarm level (CRITICAL,
     MAJOR, or MINOR) if applicable.

     In the example shown in Figure .AW G168/, MTIB 5 is out of service.
     The MTIB CONNECTIONS indicator shows SM 120 uses the MTIBs for
     the multiple Metallic Service Unit capability. Any SMs shown
     have all the MTIBs.

     Commands are provided to remove, restore, and diagnose the MTIB
     connections.

     All available displays can be accessed from Display Page 127.

     CMD   RESULT

     2XX   MTIB XX is removed (RMV:MTIB=XX) [,UCL]
     3XX   MTIB XX is restored (RST:MTIB=XX) [,UCL]
     5XX   MTIB XX is diagnosed
           (DGN:MTIB=XX,RAW,TLP) [,UCL]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of
           phases to be performed

     The 128 display page provides the optional disk access
     performance data for the AT&T 3B20D computer.

     A 5ESS switch office can have SMD only, SCSI only, or a
     combination of SMD and SCSI disk subsystem.

     There are a maximum of two DFCs on a DFSA performance page.
     This page is used only when there are more than two DFCs in the
     system.

     The 128 page can show either SMD-DFSA or SCSI-DFSA, depending on
     the feature option of the operational office.

     With SCSI feature, the DFSA performance data is not available
     when the operating system is in disk independent operation
     (DIOP) mode.

     Meanings of the performance fields displayed are as follows:

       o  CMP:  Jobs completed by the DFC for the unit.  This field
          is normalized to show the number of jobs that were
          completed per second.

       o  AVG:  The Average size of the jobs completed for a unit
          (number of disk blocks).

       o  MAX:  The maximum size of a job completed in a time
          interval (number of disk blocks).

     Figure .AW G169/ shows an example of the 128 display page with full
     SCSI DFCs.

       CMD     RESULT

     622,S,T   Performance updates are displayed
               S=number of seconds between statistic updates.  Valid number
               of seconds is between 1 and 60.  Performance updates will occur
               20 times, then will be automatically turned off.  If S is
               defaulted, then performance updates are turned off.
               T=number of seconds that the performance updates will last.
       688     The 3-line communication area at the bottom of the page is
               cleared.
      6XX,h    HELP OPTION
               Give help for 600 series commands

     The 129 page is a network management (NM) status page for a 5ESS
     switch with the AUTOVON capability.
     The 129 page display consists of indicators and data for the
     AUTOVON capability.  An indicator is similar to a LED, the state
     is either ``ON'' or ``OFF.'' The ``ON'' state identifies the
     corresponding event has occurred and it is indicated by reverse
     video.  The ``OFF'' state identifies the absence of
     corresponding event and it is indicated on by normal video.  The
     indicators are updated every 30 seconds.

     The data items on the 129 page display are the traffic
     measurements consisting of peg counts, usage counts, and
     overflow counts.  These counts are a portion of the NM 5-minute
     surveillance data and reflect the traffic measurements in the
     most recent 5-minute interval.  They are updated every 5
     minutes.

     The summary blocks marked as NM and OPERATION consist of the
     following indicators:

       o  DCCR is turned on when one or more destination code
          cancellations (DCC) have been initiated for routine level
          traffic.  If no DCC is applied at the 5ESS switch, the DCC
          indicator is off.

       o  DCCA is turned on when one or more DCCs are applied for all
          traffic.  After all DCCs are removed at all precedence
          levels, the DCCA indicator goes off.  Both DCCR and DCCA
          may be turned on, indicating at least one DCC is applied to
          all traffic and at least one for routine traffic.

       o  ARCR is turned on when one or more alternate route
          cancellations (ARC) are activated at the switch for routine
          level traffic.  When all ARCs are removed, the ARCR
          indicator is turned off.

       o  ARCA is turned on when one or more ARCs are activated at
          the switch for routine level traffic.  When all ARCs at all
          precedence levels are removed, the ARCA indicator is turned
          off.

       o  ESP is turned on if the essential service protection (ESP)
          is triggered at the switch; otherwise, the ESP indicator
          stays off.

       o  MC1 is turned on when the switching system is in a machine
          congestion level 1 (MC1) condition.  The MC1 is an
          indication of system overload.

       o  MC2 is turned on when the switching system is in a machine
          congestion level 2 (MC2) condition.  The MC2 is an
          indication of severe system overload.

       o  RSM is turned on when one or more remote switching module
          (RSM) outages exist.

     The NM and OPERATION status indicators represent occurrence of
     events related to network management and system operation.  When
     an indicator is seen in reverse video (that is, in the ON
     state), detailed information may be obtained by entering the
     appropriate TTY messages and reviewing related MCC page
     displays.  Indicators in these two blocks are updated every 30
     seconds.

     The CIRCUIT block area indicates the traffic data for universal
     tone decoders (UTD).

       o  UTDMU illustrates the maintenance-usage of UTDs.  The UTDs
          are scanned for maintenance busy every 10 seconds.  The
          count is incremented by one on busy condition.

       o  UTDTU represents the total traffic usage of UTDs.  The UTDs
          are also scanned every 10 seconds to accumulate the usage
          count.

       o  UTDTO illustrates the total number of attempts to UTDs
          equipped for the switch.

     The data in the CIRCUIT block area illustrates the traffic load
     to common circuits.  It suggests the level of load on tone
     decoders.  These counts are used in conjunction with the
     operation indicators to signal the event of overload.  These
     counts are the first indication of network congestion.

     The TRAFFIC block area displays the peg counts of eight types of
     traffic.  In terms of direction, calls are of four types:
     incoming, originating, outgoing, and terminating calls.  In
     terms of call connections, they are divided into four types:
     tandem (trunk to trunk), intrasystem (line to line), inbound
     (trunk to line), and outbound (line to trunk).

       o  INC illustrates the number of incoming calls.

       o  OUT illustrates the number of outgoing calls.

       o  ORG illustrates the number of originations.

       o  TRM illustrates the number of calls that terminate in this
          switch.

       o  TT (trunk to trunk) illustrates the number of tandem calls.
          The value in this field indicates the level of pressure of
          through-switched traffic.  If tandem traffic peaks, ARC may
          be applied at the distant switch to get relief.

       o  TL (trunk to line) illustrates the number of inbound calls.

       o  LL (line to line) illustrates the number of intrasystem
          calls.

       o  LT (line to trunk) illustrates the number of outbound
          calls.

     The DELAY block area contains information concerning service
     response felt by distant switches and subscribers.  These counts
     suggest the performance of the system and the severity of
     overload.

       o  TRK indicates the percentage of the total sample of the
          start dial delay (that is, receiver attached delay)
          exceeding the 3-second threshold.  A high number in this
          field means that other offices are experiencing slow
          response from this office.  This delay increases the time
          necessary to establish a talking path through the network.

       o  LINE indicates the percentage of total sample of dial tone
          delay exceeding the threshold.  When this field peaks,
          subscribers are experiencing delays in originating calls.

     The TRUNK block area provides the NM managers with outgoing
     attempts per circuit per hour (ACH), outgoing connections per
     circuit per hour (CCH), and maintenance usage (MU) of trunk
     groups selected by the NM managers.  Each display box within the
     TRUNK block area illustrates the traffic and maintenance status
     for a trunk group.  The box consists of a display field (trunk
     group number) and three indicators (ACH, CCH, MU).  The trunk
     group number is displayed on the upper portion of the box.  The
     indicators are located in the lower portion of the box.  The
     video state of the indicators identify the level of MU, ACH, and
     CCH of the trunk group number identified in the display field
     (upper portion of the box).  The five possible states of an
     indicator are as follows:

     STATE   VIDEO DISPLAY                  RANGE

       1     Blank Display   Below threshold 1
       2     Green Steady    Between threshold 1 and threshold 2
       3     Yellow Steady   Between threshold 2 and threshold 3
       4     Red Steady      Between threshold 3 and threshold 4
       5     Red Wink        Above threshold 4

     Default value for all thresholds are reset by the software
     controlling the display at each system initialization.  However,
     all of the threshold values can be examined and modified by TTY
     command.  The following display illustrates the default values:

           THRESHOLD 1   THRESHOLD 2   THRESHOLD 3   THRESHOLD 4

     MU        40%           50%           85%           99%
     ACH        4             8            12            16
     CCH        4             8            12            16

     Indicators on the TRUNK block area are updated every 5 minutes.
     During the course of an update, only those indicators that have
     changed to a new state since the last update are refreshed.  A
     trunk group can be brought up in the display box and removed
     from the display via a TTY command.  Refer to AT&T 235-600-700,
     Input Messages Manual, for details of the input message.

     The OFFICE display area identifies the name of the 5ESS switch
     (with AUTOVON) being monitored.

     The TIME display area identifies the local time at the 5ESS
     switch being monitored.

     Figure .AW G170/ shows an example of the 129 page display.

     The abbreviations shown on the 129 page display are explained in the
     text describing this page.

     Any of the available page displays can be accessed from the 129
     page display.
     The 130 display page provides status of the manual and automatic
     NM system controls and status of NM circuit conditions. Also, it
     provides a command to get a listing of all NM controls.
     When there is an overload in the system there are manual or
     automatic controls that can be put on the system by Network
     Management. The 130 page shows the status of these controls,
     either YES or NO.

     Any controls on this page that are YES will cause an indicator
     that refers to this page to appear and be backlighted on Page
     109 - OVERLOAD. In the STATUS SUMMARY AREA at the top of the
     screen, the OVERLOAD status summary indicator will be
     backlighted. This page also has a reference back to Page 109
     that is displayed all the time.

       Note:   The status of DELAYED READINESS is always blank
               because the feature is not implemented.

     Figure .AW G171/ shows there is a manual control on the TRUNK GROUP,
     and transmit (XMT) of dynamic overload control (DOC) is allowed
     (ALW).

     The command on this page is provided to print a listing of any
     NM controls that are YES. Also, any available paging commands
     can be entered from this display.

     CMD   RESULT

     900   Any YES NM controls are output (OP:NMPGE)

     The 131 page display is a menu page that contains a list of call
     trace poke commands.
     An indicator SEE PAGE 132 on the 131 menu page shows the
     maintenance personnel which hardware call trace page (132
     through 139 or 150) to access for the details of the call trace.

     The 131 menu page gives the user the ability to invoke a trace
     by simply entering a poke value followed by a number or a set of
     numbers.  For example, 401,2220001 where 401 is the poke for a
     utility hardware call trace, with a DN (that is, 2220001) being
     the input option.

     When tracing ISDN circuit switched lines, the channel to be
     traced should be included in the input.  If no channel is
     specified, then the default action is to trace the D-channel.
     See pokes 401 and 405 for input requirements.

     The SA option is used to specify which subaddress of a DN with
     multiple call appearances to trace.  Specifying SA=ALL will
     result in Page 150 being populated with the status of all valid
     subaddresses for the given input.  If the SA option is used, the
     channel option should be omitted.

     To trace packet switched calls, the PKT variable is included in
     the following poke commands:  401, 404, 405, and 410.

     Figure .AW G172/ shows an example of the 131 page display.

     All of the poke commands that can be invoked by the maintenance
     personnel appear on the 131 page display.  Also, any available
     page display can be accessed from the 131 menu page.
     The 132 page is a continuation of the 131 menu page and consists
     of a list of call trace poke commands.
     A ``SEE PAGE'' indicator on the 132 menu page shows the
     maintenance personnel which hardware call trace page (133-140,
     150) to access for the details of the call trace.

     The 132 menu page gives the user the ability to invoke a trace
     by simply entering a poke value followed by an option or a set
     of numbers.  For example, to trace the active loop of the B1
     channel of the operator position terminal 1-135, the poke would
     be 418,1,135,loop=0,ch=B1.

     Figure .AW G173/ shows an example of the 132 page display.

     Refer to the 131 menu page for all of the poke commands that can
     be invoked by the maintenance personnel.  Also, any available
     page display can be accessed from the 131 menu page.
     The hardware call trace page displays (133 through 138) show the
     hardware paths of calls requested to be traced.
     The 133 through 138 pages allow the LCEN and ISLU information to
     be displayed.

     The ISLU information includes the type of circuit switched
     service (for example, voice or data) and a B-channel identifier
     (B1, B2, or ON HOLD).  The ``ON HOLD'' indicates that no B-
     channel is allocated for the call.

     These call trace pages (133 through 138) illustrate the hardware
     path(s) involved with the call.  This is a valuable trouble-
     shooting aid; the hardware path and dynamic data structures can
     be found for a failed call.

     Figure .AW G174/ is an example of an ISDN Hardware Call Trace.

     Figure .AW G175/ is an example of an ISDN BRCS Hardware Call Trace.

     Figure .AW G176/ is an example of a Multipoint DSL Hardware Call
     Trace.

     Figure .AW G177/ is an example of an OSPS OPT Hardware Call Trace.

     Figure .AW G178/ is an example of a PBX DID on SLC(R) Carrier Hardware
     Call Trace.

     Refer to 131 - Call Trace Menu display (Figure .AW G172/) for the
     complete list of call traces that can be invoked (by poke
     commands) from the 133 through 138 page displays.  Also, all
     available page displays can be invoked from the 133 through 138
     page displays.
     The 139 packet switch call trace page displays the hardware and
     software information describing a specified packet switch
     digital service line (DSL).
     Poke commands are provided on this page display to allow the
     user to observe the following:

       o  Return to the utility call trace menu page (131).  An
          indicator in the upper left-hand corner of the 139 page
          display (Figure .AW G179/) directs the user to the 131 menu page.

       o  View the active logical channels associated with the
          particular port.  There are 16 views of this page display.
          Each view displays 8 active logical channels for the trace.
          The poke 9XX allows the user to specify which view is to be
          displayed.  An indicator in the upper right-hand corner of
          the 139 page display identifies the total active logical
          channel numbers (LCN) to view.  The summary information is
          filled in starting with view 1 of the 139 page display.

       o  Print the entire summary to the ROP.  Poke 920 is provided
          to allow the user to dump the entire trace summary to the
          ROP.

       o  Hex dump to the ROP of a specific access line control block
          (ALCB) or the logical channel control blocks (LCCB)
          associated with the LCN.  Poke 930 allows the user to dump
          two data structures to the ROP (depending on the value of X).

            a. If X=ALCB, the ALCB associated with the packet call
               trace is printed on the ROP.

            b. If X=1-127 (specific LCN), the LCCB associated with
               the LCN is printed on the ROP.

       o  Hex dump to the ROP of all collected data associated with
          the trace.  Poke 940 allows the user to print the following
          data on the ROP:

            a. DCCB -- D-Channel Control Block

            b. LLCB -- Logical Link Control Block

            c. ALCB -- Access Link Control Block

            d. LCCB -- Logical Channel Control Block

            e. PTSB -- PIDB Time Slot Block

            f. DPB -- D-Channel Port Block

            g. PORTLA -- Port Linkage Area.

       o  View the hardware connection of the port.  An indicator in
          the upper right-hand corner of the 139 page display directs
          the user to the 140 page display where the hardware
          connection of the trace can be viewed.

     Figure .AW G179/ shows an example of the 139 page display.

     The following poke commands are provided on the 139 page
     display.

      CMD    RESULT

      9XX    (X=00-08) Next view in sets of 8 LCNs
      920    Print entire summary to ROP
     930,X   (X=LCN|ALCB) Hex dump of specific LCCB (X=LCN) or ALCB
      940    Hex dump of all collected data to ROP

     The purpose of the 140 page display is to show the hardware
     connections for the packet call trace and circuit switch D-
     channel call trace.
     The 140 page display has two versions:

       1. The PSU Direct Connect hardware call trace illustrates:

            o  DN or Multipoint DSL

            o  LCEN  [LCEN includes the SM number, the line unit (LU)
               number, the line group (LG) number, and the line card
               (LC) number.]

            o  PKT  (``PKT'' appears in the block where the channel
               type and number are located indicating the hardware
               connections are for a packet switch call trace.)

            o  Channel type and number (B1, B2, or D types)

            o  DPIDB number

            o  DPIDB time slot.

       2. The PSU Cut-through hardware call trace illustrates:

            o  DN

            o  LCEN (LCEN includes the SM number, the LU number, the
               LG number, and the LC number.)

            o  Channel type and number (B1, B2, or D type)

            o  PIDB number

            o  PIDB time slot from the ISLU to the DI

            o  PTS number from the DI to the TSI

            o  PTS number from the TSI to the DI

            o  PIDB number and time slot from the TSI to the DI.

     Figure .AW G180/ is an example of a circuit switched D-Channel trace
     of a Multipoint DSL.

       Note:   The PDB(ts) abbreviation on the 140 page display
               actually means protocol handler data bus (PHDB).
               The PDB(ts) abbreviation appears on the page
               display because an internal software process is
               also named PHDB.

     Figure .AW G181/ is an example of an X.75' packet switched cut-through
     hardware call trace.

     Any available displays can be accessed from the 140 page.
     The purpose of the 141 through 144 display pages is to provide a
     more detailed summary status of groups of 48 SMs on one display.
     Displays 141, 142, 143, and 144 are very similar. Each one can
     display summary status of up to 48 SMs. Page 141 displays status
     for SMs 1 through 48, Page 142 displays summary status for SMs
     49 through 96, Page 143 displays status for SMs 97 through 144,
     and Page 144 displays summary status for SMs 145 through 192.

     Each equipped SM has a unique indicator on these displays. Each
     indicator has three distinct sections:

       o  SM NUMBER:  There may be gaps in SM numbering for a
          particular office.  To provide flexibility in office
          numbering schemes, the SM numbers are not necessarily
          assigned sequentially. If an SM is not equipped, it is not
          shown. An example of this is shown in the 141 page example
          (Figure .AW G182/) by the blank indicators between SM 12 and SM
          20, SM 20 and SM 24, etc.

       o  SM TYPE:  There is a 3-character acronym to show how an SM
          is being used. For example, an LSM is a local switching
          module.

       o  SM STATUS PHRASE:  This is a 10-character, maximum, phrase
          which describes the most significant off-normal condition
          in the SM.  During initialization, the status phrase will
          give the current initialization progress type.  Table .AW TAH/
          lists status phrases in order of priority and gives the
          color and an explanation for each phrase.  Included are new
          phrases which were added with the 5E6 software release
          (INIT ISOL, HSM STALN, CMP ISOL, HSM ISOL).  For detailed
          information on SM progress markers, see AT&T 235-105-250,
          System Recovery.

     If more than one off-normal condition exists in an SM, a ``+''
     will appear to the right of the status phrase (SMs 1, 5, and 48
     in Figure .AW G182/).  A complete list of active off-normal conditions
     can be output via menu command 900.

     In addition to this page, the status phrase is shown on all
     per-SM pages.

     When a new alarm condition on an SM occurs, the SM indicator
     will begin flashing. The ALM RLS key will not stop the flashing.
     The color of the flashing will reflect the new alarm only if the
     newly recorded condition is of higher or equal priority to the
     previous condition. To stop the flashing, the craft should
     display the 1010 page for that SM. There is also a command to
     retire the flashing for the range of SMs associated with the
     page being displayed - 999. This is mainly provided for
     situations such as during installation when SMs are being grown
     and many SMs are displaying recurrent error conditions.

     The backlighted note about the DLIs appears whenever an ONTC is
     out of service or unavailable. The DLIs are under the
     maintenance control of the ONTCs, thus all DLIs on a side are
     affected when the ONTC of that side is off-normal.

     For further details on any SM recovery-related activity or SM
     inhibits, the craft would enter 1800,X to display the SM X
     INHIBIT AND RECOVERY CONTROL page. This is the SMs control page
     for emergency action.

     For details on circuits out of service or hardware in a
     particular SM, the craft would enter 1010,X to display the SM X
     STATUS page. This page can be accessed during the initialization
     of SM X or if SM X is isolated, but the only status that will
     fill in are the SM STAT and RELATED PAGES boxes.

     For details on ONTC circuits out of service, the craft would
     enter 115 to display the COMMUNICATION MODULE SUMMARY page.

     In the example of the 141 page shown in Figure .AW G182/, SM 1, which
     is an LSM, has several off-normal conditions. The ``+''
     indicates that there is more than one off-normal condition.  For
     the most critical condition, inhibits are set.  Both SM 3 and 10
     have circuits out of service.  The SM 5, an RSM, has a hash
     error plus other off-normal conditions.  The SM 06, another LSM,
     is isolated. This indicator would be flashing in the display,
     which cannot be shown here.  The SM 48, another RSM, has a
     building power alarm plus other off-normal conditions.  There is
     an off-normal condition in ONTC 1 causing all the DLIs on Side 1
     to be off-normal.

     All available displays can be accessed from the 141 through 144
     display pages.

       CMD     RESULT

       900     The off-normal report is output for the SMs associated with
               the page
               (OP:SYSSTAT,SM=a&&b) [,LSM] [,HSM] [,RSM] [,UCL]
               where a&&b is the range of SMs associated with the page
               being displayed
       999     SM flashing is retired for the range of SMs associated
               with the page
     1010,X    SM X STATUS page is displayed
      1271     SM 1 - 48 REX SUMMARY page is displayed
     1600,SZ   SITE Z STATUS page is displayed
     1800,X    SM X INHIBIT AND RECOVERY CONTROL page is displayed

     The 150 page display provides a list of nonidle (that is,
     talking, held, and alerting) subaddress, line card equipment
     number (LCEN), and channel of a particular directory
     number/multiline hunt group number (DN/MLHG).
     A maximum of 16 subaddresses can be assigned per DN or MLHG.

     All subaddresses, LCENs, and channel numbers sharing a
     particular DN can be displayed by entering 401,DN,SA=ALL.  The
     status of subaddresses displayed can be determined by the status
     indicators located at the lower left-hand corner of the 150 page
     display.  If the subaddress is ``ACTIVE,'' the data (that is,
     subaddress, LCEN, channel), is backlighted in green; if the
     subaddress is ``ON HOLD,'' the data is backlighted in blue; and
     if the subaddress is ``IDLE,'' the data is backlighted in white.
     The ``ON HOLD'' calls can be traced by utility call trace if the
     SA option is used.

     Shared analog lines are assigned to subaddress zero.  These are
     marked by an asterisk on the display page.

     After the 150 page has been populated with the shared call
     appearance of a DN/MLHG, the data should be identified, for
     example (00 2-5-15-10-B1) is: 00 = SA (subaddress number), 2 =
     SM number, 5 = ISLU/RISLU number, 15 = line group, 10 = line
     card, and B1 = CH (channel number) (indicating the line is in
     use - active).

     Concerning shared call appearance (more than one terminal could
     use the same DN and subaddress), if traced from the subaddress
     and only one terminal is using the DN and subaddress, the MCC
     displays the DN version of the 150 page (not the MLHG version).
     If more than one terminal is using the same DN and subaddress
     (bridging) at the same time, only the controller is illustrated
     on the 150 page.  However, when the call is traced from the
     controller, all bridging parties are illustrated on the 133
     through 138 page displays.

     Multiline hunt group call trace uses the 150 page to display the
     call appearance for a specific multiline hunt group member.  The
     MLHG number is displayed instead of the DN located at the upper
     middle portion of the 150 page display.  The user can implement
     an MLHG call trace by entering 404,MLHG,SA (SA = subaddress).

     For more information concerning the call traces implemented, the
     150 page display illustrates associated page displays that have
     more details of the trace.  The associated page displays can be
     identified in the upper right-hand corner of the 150 page
     display.

     Figure .AW G183/ shows an example of the 150 page display.

     The following four poke commands can be used to initiate a
     trace.

       o  401,DN,SA=SUBADDRESS  (SA = 00 TO 15) - Traces a specific
          subaddress of a particular DN.

       o  404,MLHG,SA=SUBADDRESS - Traces a specific subaddress of a
          particular MLHG.

       o  401,DN,SA=ALL - Populates the 150 page with all of the
          nonidle subaddresses, equipment numbers, and channels of a
          particular DN.

       o  404,MLHG,SA=ALL - Populates the 150 page with all of the
          nonidle subaddresses, equipment numbers, and channels of a
          particular MLHG.

     The purpose of the 178 page display is to provide pokes for the
     disk reconfiguration feature and to show any reconfiguration
     actions that are in-progress.
     Commands and information provided on the 178 page are useful in
     the recovery of one or more failed MHDs.   Certain automatic
     disk configuration data from this page is displayed on the 123
     page, Disk File System Access.

     Figure .AW G184/ shows an example of the 178 page in the normal state.

     Figure .AW G185/ shows an example of the 178 page when a replacement
     (MHD 14) is being configured for MHD 0.

     The 178 page provides commands to allow or inhibit automatic
     disk configuration on one or more MHDs or on the entire office.

     Commands are also provided to generate a printout of the current
     configuration, configure a replacement MHD for one that is
     defective, and normalize the configuration on a per-MHD basis or
     on the entire office.

     CMD   RESULT

     4XX   Replacement for MHD XX is configured
     6XX   Automatic disk configuration is allowed on MHD XX
     699   Automatic disk configuration is allowed on entire office
     7XX   Automatic disk configuration is inhibited on MHD XX
     799   Automatic disk configuration is inhibited on entire office
     8XX   MHD XX is normalized
     899   Entire MHD configuration is normalized
     900   Spare disk configuration is output

     The purpose of the 179 page display is to show configuration
     relations of physical MHDs to logical MHD sets.  Also displayed
     on this page are the MHDs that have been reconfigured, MHDs that
     are the active system disks, and MHDs that are the spare disks.
     A list of reconfigured MHDs also appears on 123 page, Disk File
     System Access.
     Page 179 shows related MHD(s) for each logical MHD set (for
     example, duplmhd) defined in the equipment configuration data
     (ECD).

     Figure .AW G186/ shows the normal state of Page 179.

     Figure .AW G187/ shows that MHDs 0 and 14 have been reconfigured.  At
     this time, MHDs 1 and 14 are the system disks and MHDs 0 and 15
     are the spare disks.

     There are no menu commands on the 179 page display.
     The purpose of the 180 page display is to show configuration
     relations of physical MHDs to logical MHD sets.
     Display Page 180 shows related MHD(s) for each logical MHD set
     (for example, duplmhd or dupmhd) defined in the equipment
     configuration data (ECD).

     Figure .AW G188/ shows the normal state of Display Page 180.

     There are no menu commands on the 180 display page.
     The 181 through 184 page displays provide off-line switch module
     processor (SMP) and peripheral pump status plus off-line pump
     commands for software releases and translations.

     The off-line status for each equipped (see the following SM
     number range for each page) is contained in four fields. The
     ``aaa'' field is the SM type, the ``bbb'' field is the SM
     number, the ``c'' field is the active side of the SM, and the
     ``ddddddddd'' field is the off-line SM status phrase.
     Each page, 181 - 184, is divided into two basic areas. The top
     area contains commands to control off-line pumping and restore
     peripherals. The area at the bottom provides off-line pump
     status on up to 48 SMs or peripherals.

     The off-line SM status pages consist of four different screens
     to display the status for up to 192 SMs. These pages are
     numbered as MCC Page 181, 182, 183, and 184. Each page can
     display off-line SM status for up to 48 SMs. Page 181
     (Figure .AW G189/) displays status for SMs 1-48, Page 182
     (Figure .AW G190/) displays status for SMs 49-96, Page 183
     (Figure .AW G191/) displays status for SMs 97-144, and Page 184
     (Figure .AW G192/) displays status for SMs 145-192.

     Each equipped SM has a unique status indicator block on these
     display pages. Each indicator block has four distinct fields, SM
     type, SM number, active side of SM, and off-line SM status
     phrase.  Status is indicated in the following form,
     aaabbb,cddddddddd

     where:

                aaa = SM type
                bbb = SM number
                  c = Active side of SM
          ddddddddd = Off-line SM status phrase.

     SM type is as follows:

            LSM (local SM)
            RSM (remote SM)
            HSM (host SM)
            ORM (optically remoted SM)
            TRM (2-mile optically remoted SM)
            blank (unknown, default).

     SM number on page:

        181 = Any number in the range 1-48
        182 = Any number in the range 49-96
        183 = Any number in the range 97-144
        184 = Any number in the range 145-192.

     Active side of SM = 0 or 1.

     Off-line SM status phrase is one of the following:

       o  OPUMPHLDn:  Indicates an off-line pump hold, nth attempt.

       o  OPUMPn:  Indicates off-line pumping, nth attempt.

       o  OHASHCKn:  Indicates off-line pump hashsum check, nth
          attempt.

       o  OPUMPFAIL:  Indicates failure to pump an off-line SM.

       o  OVRFYn:  Indicates off-line verifying nth check for
          completion.

       o  OVRFIED:  Indicates off-line verification is complete.

       o  OVFYFAIL:  Indicates that off-line verification failed.

       o  MATE PUMP:  Indicates a successful pump or verify.

       o  OPUMPERFn:  Indicates off-line pump of peripheral n.

       o  OPERFFAIL:  Indicates failure of an off-line peripheral
          pump.

       o  OPERF OOD: Indicates off-line peripheral is out of date.

       o  ORST:  Indicates that a duplex peripheral is restoring.

       o  ORSTFAIL:  Indicates failure to restore a peripheral.

       o  STANDBY:  Indicates mate is in standby.

       o  MATE OOD:  Indicates mate is out of date.

       o  UPDATING:  Indicates mate is off-line pumping.

     During non-off-line pump intervals, these pages will display the
     status of SM mate memory. The mate memory indications, which are
     also shown on Page 1800, are STANDBY, MATE OOD, or MATE PUMP.

     When an SM is being pumped, the status of mate memory on Page
     1800 shows UPDATING when the pumping starts.  If the pump is
     successful, the next status indicated is MATE PUMPED or, if it
     fails, status of the mate memory shows OOD (out of date).

     If failure occurs during off-line pumping, the SM Off-line Pump
     System Process retries a maximum of three partial pumps.

     Examples of MCC Pages 181, 182, 183, and 184 are shown
     respectively in Figures .AW G189/, .AW G190/, .AW G191/, and .AW G192/.

     Pages 181 through 184 provide commands to start pumping SMs,
     stop pumping SMs, start pumping peripherals, restore
     peripherals, and output off-line pump.

     All available displays can be accessed from Pages 181 through
     184.

 2
     CMD    RESULT (See Note)

     2000   Start off-line pump on equipped SMs = 1-192
            (ST:OPUMP,SM=1&&192,OFLDISK,VFY,PERF)
     200X   Start off-line pump on SM = X (ST:OPUMP,SM=X,OFLDISK,VFY,PERF)
     20XX   Start off-line pump on SM = XX (ST:OPUMP,SM=XX,OFLDISK,VFY,PERF)
     2XXX   Start off-line pump on SM = XXX (ST:OPUMP,SM=XXX,OFLDISK,VFY,PERF)
     3000   Stop off-line pump on SMs = 1-192 (STP:OPUMP,SM=1&&192)
     300X   Stop off-line pump on SM = X (STP:OPUMP,SM=X)
     30XX   Stop off-line pump on SM = XX (STP:OPUMP,SM=XX)
     3XXX   Stop off-line pump on SM = XXX (STP:OPUMP,SM=XXX)
     4000   Start off-line pump on peripherals of SMs = 1-192
            (ST:OPUMP,SM=1&&192,PERF)
     400X   Start off-line pump on peripherals of SM = X (ST:OPUMP,SM=X,PERF)
     40XX   Start off-line pump on peripherals of SM = XX
            (ST:OPUMP,SM=XX,PERF)
     4XXX   Start off-line pump on peripherals of SM = XXX
            (ST:OPUMP,SM=XXX,PERF)
     5000   Restore peripherals on SMs = 1-192 (RST:PERF,SM=1&&192)
     500X   Restore peripherals on SM = X (RST:PERF,SM=X)
     50XX   Restore peripherals on SM = XX (RST:PERF,SM=XX)
     5XXX   Restore peripherals on SM = XXX (RST:PERF,SM=XXX)
     600X   OP OPUMP on SM = X (OP:OPUMP,SM=X)
     60XX   OP OPUMP on SM = XX (OP:OPUMP,SM=XX)
     6XXX   OP OPUMP on SM = XXX (OP:OPUMP,SM=XXX)


       Note:   X = 1-9 (Page 181)
                    XX = 10-48 (Page 181)
                    XX = 49-96 (Page 182)
                    XX = 97-99 (Page 183)
                   XXX = 100-144 (Page 183)
                   XXX = 145-192 (Page 184)

     The 190 display page provides commands to update/restart
     individual craft processes in lieu of a craft init (15 on the
     EAI display), which would update/restart all the craft
     processes.
     The entire 190 display page consists of commands as follows:

       o  800 - UPDATE C/D GLOBAL MENU command is used to activate a
          new menu of the displays and maintenance commands (menu.x).

       o  801 - UPDATE C/D STATE TRANSLATION command is used to
          activate a new table of states available for the displays
          (trantab.x and trantab.xc).

       o  802 - RESTART ULARP restarts the UNIX system Level
          Automatic Restart Process. This process controls the order
          in which UNIX system level processes are started/restarted.

       o  803 - RESTART CSOP restarts the Coordinator of Spooler
          Output Processes.  This handles the flow of the TTY
          messages. It directs the messages to the appropriate
          devices, sorts them, and generates other actions resulting
          from the messages.

       o  804 - RESTART RTS restarts the Real Time Status process.
          This process monitors the status of the units shown on
          111/112 - AM/AM PERPH and the SCC, if equipped. It can be
          used if there is a suspected problem with status updates to
          Page 111/112.

       o  805 - RESTART DAP restarts the Display Administration
          Process.  DAP controls the displays.

       o  806 - RESTART CIA restarts the Critical Indicator
          Administrator.  The CIA interfaces the SUMMARY STATUS
          INDICATORS on the displays to the Critical Indicator Panel
          at the SCC, if the SCC is hooked up.

       o  807 - RESTART POKER(S) causes a new poker to be created for
          each maintenance display terminal. The poker is the
          interface from the display terminal to DAP. This command
          could be used if a single maintenance display terminal is
          locked out.

       o  808 - RESTART CFTSHL(S) restarts the craft shell. This can
          be used if TTY input messages cannot be entered.

       o  810 - SCC COLOR sets the SCC terminal to color.  This
          command only works from the SCC. If entered from any other
          terminal, a no good (NG) is returned.

       o  811 - SCC B/W sets the SCC terminal to black and white.
          This command, like 810, only works from the SCC.

     Figure .AW G193/ is an example of the Control/Display page.

     The entire display is commands. In addition to these, any
     available paging command can be entered from the 190 display
     page.

     CMD   RESULT

     800   C/D Global Menu is updated
     801   C/D State Translation is updated
     802   ACP is restarted
     803   CSOP is restarted
     804   RTS is restarted
     805   DAP is restarted
     806   CIA is restarted
     807   POKER(S) is (are) restarted
     808   CFTSHL(S) is (are) restarted
     810   SCC terminal is set to color
     811   SCC terminal is set to black and white

     The 191 display page shows operating system resource usage.
     The 191 display page shows AM resource usage. This page is not
     updated unless one of the refresh rate menu commands is entered
     from the master control center (MCC). After a refresh rate is
     selected, the display will be updated according to the rate and
     then will time out or can be halted by entering the FREEZE
     command.

     The data on the 191 display page can be used to find what real
     time impact a process has on the system as it is activated. It
     also shows any resource approaching or at overload. If any
     overload occurs and requires craft action, there will be
     corresponding output messages detailing the action to be taken.
     On color MCCs, the bar graphs on the graphic portion of the page
     are color coded to show the utilization.

     The level of utilization colors used on the bar graphs are as
     follows:

       o  GREEN:  For normal utilization

       o  MAGENTA:  For heavy, but not overloaded utilization

       o  RED:  For any resource approaching overload or at overload.

     There are four refresh rates available for monitoring resource
     usage as follows:

       o  FREEZE:  No refresh (halt refresh)

       o  1 SECOND:  Refreshes once per second or 20 seconds

       o  5 SECONDS:  Refreshes once every 5 seconds for a maximum of
          10 minutes

       o  30 SECONDS:  Refreshes once every 30 seconds for a maximum
          of 2 hours.

     Indicators shown under the DISPLAY RATE are as follows:

       o  SPN:  Process number (hexadecimal) of the last supervisor
          process dispatched

       o  SWAPI:  Number of segments swapped in since last refresh (0
          unless page or page table utilization goes to 100 percent)

       o  SWAPO:  Number of segments swapped out since last refresh
          (0 unless page or page table utilization goes to 100
          percent)

       o  STIME:  Number of 10-millisecond timer intervals accrued to
          supervisor processes since last refresh (should be
          approximately 100 times the display rate)

       o  KTIME:  Number of 10-millisecond timer intervals accrued to
          kernel and special processes since last refresh

       o  KPTIME:  Number of 10-millisecond timer intervals accrued
          to all kernel processes since last refresh.

     The following resource types are used on the 191 page:

       o  MSG:  Message blocks in use

       o  DCT:  Number of active processes in the system

       o  SDT:  Number of segments in use (must be at least three
          times the number of active processes)

       o  PDT:  Physical pages in use (swapping will occur when all
          physical pages are in use)

       o  PDT1:  Physical pages in use in memory module 1 (These
          pages are never swapped out and are free only when the
          process which owns the pages terminates.  This field is
          only displayed on 3B20 machines equipped with the EMM
          feature.)

       o  PGT:  Page tables in use

       o  SSZ:  Swappable memory utilization (shows amount of
          available swap space used)

       o  SDK:  Disk swap block utilization (shows amount of
          available disk swap blocks used).

     The screen in Figure .AW G194/ is not currently being updated (shown
     by FREEZE in reverse video). The data in the numeric and graphic
     indicators shows usage from an earlier display refresh request.

     CMD   RESULT

     500   Display refresh is halted
     501   Display is refreshed every second for 20 seconds
     505   Display is refreshed every 5 seconds for a maximum of 10 minutes
     530   Display is refreshed every 30 seconds for a maximum of 2 hours

     The 197 display page provides status and commands for cutover.
     Cutover/cutback is the transfer of lines from one switching
     system to another.  When cutover is active, an indicator to the
     right of the OFFICE STATE indicator will say CUTOVER ACTIVE and
     be backlighted. On Page 116 - MISCELLANEOUS, the CUTOVER ACTIVE
     indicator will be backlighted. In the SUMMARY STATUS AREA, the
     MISC critical indicator will be backlighted.

     The ENABLE STATE indicator contains one of the following
     phrases:

       o  NONE

       o  PRECUT

       o  POSTCUT.

     The OFFICE STATE indicator will contain one of the following
     phrases:

       o  PRECUT

       o  POSTCUT.

     The CUTOVER/CUTBACK EXECUTION STATUS indicator has the following
     possibilities:

       o  MIGRATION COMPLETE

       o  ENABLE CUTOVER FIRST

       o  ENABLE CUTBACK FIRST

       o  ACTIVATE CUTOVER PROGRAM

       o  NO SM'S READY TO MIGRATE

       o  NOT ALL SM'S MIGRATING.

     Refer to AT&T 235-105-200 for specifics in using this display
     page.

     Figure .AW G195/ shows cutover/cutback has been completed.

     In addition to the following commands, any available paging
     command can be entered from this display.

     CMD   RESULT

     600   Cutover is enabled (EXC:CO:CMD=ENCUT)
     601   Cutover is executed (EXC:CO:CMD=CUT)
     602   Cutover is aborted (EXC:CO:CMD=ABORT)
     700   Cutback is enabled (EXC:CO:CMD=ENCBK)
     701   Cutback is executed (EXC:CO:CMD=CUTBK)

     The SM Page Index page provides an index to the SM and remote
     switching module/remote integrated services line unit
     (RSM/RISLU) pages.
     The 1000 page is an index to the primary SM/RSM/RISLU pages that
     directly have status reflected on the 1010 - SM X STATUS page.
     No status is displayed on the 1000 page.

     The page is divided into two parts. The first part displays all
     the pages that are valid for local switching modules (LSM), host
     switching modules (HSM), and RSMs/RISLUs. The second part
     displays the pages that are only valid for RSMs/RISLUs and
     remote sites.

     Some pages shown on the 1000 page reference additional pages
     that provide more detailed information.  These additional pages
     may not appear on the 1000 page.

     Most SM pages are specified using an SM number.  Some pages,
     however, are referenced by the site number of a remote site.
     For these pages (such as the 1600,SZ page), the ``S'' shown on
     the 1000 page is actually entered as part of the menu command.
     For example, entering ``1600,S3'' will display the status of
     RSMs/HSMs at Site 3.

     For all pages, once an SM page has been displayed for a
     particular SM, any other page for that SM may be requested
     without respecifying the SM number.

     The index shown in Figure .AW G196/ is a listing of the primary SM and
     SITE maintenance displays for the 5E6 software release.

     All available paging commands can be entered from this display.

 3
     LSM and HSM Pages

      CMD                             RESULT

     1010,X   SM X - STATUS page is displayed
     102Y,X   SM Y - LU X CONCENTRATOR page is displayed, if equipped
     103Y,X   SM X - LU Y SG 0 page is displayed, if equipped
     104Y,X   SM X - LU Y SG 1 page is displayed, if equipped
     105Y,X   SM X - TU Y SG 0 page is displayed, if equipped
     106Y,X   SM X - TU Y SG 1 page is displayed, if equipped
     107Y,X   SM X - DCTU Y page is displayed, if equipped
     108Y,X   SM X - LDSU Y SG 0 AND 1 page is displayed, if equipped
     109Y,X   SM X - RAF Y page is displayed, if equipped
     110Y,X   SM X - GDSU Y page is displayed, if equipped
     1110,X   SM X - ISTF page is displayed, if equipped
     112Y,X   SM X - DLTU Y page is displayed, if equipped
     113Y,X   SM X - MSU Y SG 0 page is displayed, if equipped
     114Y,X   SM X - MSU Y SG 1 page is displayed, if equipped
     115Y,X   SM X - DCLU Y page is displayed, if equipped
     1186,X   SM X PSU NETWORK page is displayed
     1190,X   SM X - MCTSI page is displayed
     1200,X   SM X - DLI/TMSLNK page is displayed
     1280,X   SM X - REX STATUS page is displayed
     1460,X   SM X - DATA LINK DSLS page is displayed, if equipped
      170Y    SM X ISLU Y NETWORK page is displayed
     1800,X   SM X - INHIBIT AND RECOVERY CONTROL page is displayed
     1900,X   SM X - CLNKS page is displayed

 4
     RSM/RISLU Pages

       CMD                                RESULT

     1160,X    SM X - MISC UNITS page is displayed, if equipped
     1170,X    SM X - RCLK page is displayed, if equipped
     1190,X    SM X - MCTSI/RLI page is displayed
     1400,X    SM X - RSM BLDG/PWR ALARMS page is displayed, if equipped
     1420,SZ   RISLU BLDG/PWR page is displayed
     145Y,X    RISLU DLTU Y page is displayed
     1600,X    SM X SITE STATUS page is displayed via SM number, if equipped
     1600,SZ   RSM/RISLU SITE STATUS page is displayed
      1610     RSM SITE INDEX page is displayed
      1615     ORM SITE INDEX page is displayed
     1620,SZ   RISLU SITE STATUS page is displayed
      1630     RISLU SITE INDEX page is displayed

     The 1010,X display page provides a summary and status of
     equipped hardware units in the SM and a summary of any
     miscellaneous activities in the SM.
     There are five separate versions of the 1010,X page as follows:

       o  Local Switching Module (LSM):  The LSM version has an MCTSI
          summary indicator and indicators for the Operating Service
          Position System (OSPS) terminal equipment and the RISLU
          circuits.  (See Figures .AW G197/ and .AW G198/ for examples of the LSM
          version.)

       o  Host Switching Module (HSM):  The HSM version has an MCTSI
          summary indicator and a remote switching module (RSM)
          indicator box for displaying all RSMs for which the HSM is
          responsible and the SITE where each of the RSMs is located.
          No status is given for the RSMs on this page.  (See
          Figure .AW G199/ for an example of the HSM version.)

       o  Remote Switching Module (RSM):  The RSM version has an
          MCTSI/RLI summary indicator, a BLDG/PWR ALARMS indicator
          (if equipped), the name of the SITE where the RSM is
          located, and the number of the HSM hosting the RSM.

          Each RSM has a SITE number from 001 through 174 associated
          with it.  Both LSMs and HSMs are always SITE 000. The SITE
          number is indicated on every SM page just under the SM
          Status box.  (See Figures .AW G200/ and .AW G201/ for examples of the
          RSM version.)

       o   Position Switching Module (PSM):  The PSM version has an
          MCTSI summary indicator and a RISLU indicator box for
          displaying all RISLUs that the PSM is responsible for and
          the SITE where the RISLUs are located.  No RISLU status is
          given on this page.  (Figure .AW G202/ is an example of the PSM
          version.)

       o  Optically Remoted Module (ORM):  The ORM version has an
          MCTSI summary indicator, a BLDG/PWR ALARMS indicator (if
          equipped), and the name of the SITE at which the ORM is
          located.

          Each ORM has a SITE number from 001 through 174 associated
          with it.  Both LSMs and HSMs are always SITE 000.  The SITE
          number is indicated on every SM page just below the SM
          Status box.  (Figure .AW G203/ is an example of the ORM version.)

     Every equipped SM has its highest priority status displayed in
     its SM STAT indicator.  This corresponds to the status shown on
     Pages 141 - 144.

     The RELATED PAGES box is blank unless there is an off-normal
     condition in the SM that is not otherwise indicated elsewhere on
     this page.  In some cases, this box shows a page(s) which will
     give more detailed information about the off-normal condition.

     The equipped hardware units vary from one SM to the next.  The
     only unit in every SM is the MCTSI.  Any equipped unit will be
     listed in the graphic boxes on the right-hand portion of the
     display.

     When an off-normal condition occurs, the indicator for the fault
     will backlight.  On Page 114 - EQUIPPED SM STATUS SUMMARY, the
     indicator for the SM will be backlighted; and on the appropriate
     141, 142, 143, or 144 page, the indicator for that SM will be
     backlighted and a descriptive phrase of the condition will be
     written.  In the SUMMARY STATUS AREA, the SM critical indicator
     and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable,
     will be backlighted.

     Some RSM/ORM sites do not have the BLDG/PWR ALARMS equipped. If
     this page is displayed for an RSM/ORM that is at a site which
     does not have the BLDG/PWR ALARMS equipped, or the BLDG/PWR
     ALARMS are associated with a different RSM/ORM at the same site,
     the 1010 page for that RSM/ORM will not show the BLDG/PWR ALARMS
     box.

     If the RSM/ORM has the BLDG/PWR ALARMS equipped and if any
     RSM/ORM alarm is inhibited, the INHIBIT indicator is
     backlighted. If there is an RSM/ORM BLDG/PWR alarm active, the
     ALARM indicator will be backlighted.  Further information can be
     found on display 1400 - SM X RSM/ORM BLDG/PWR ALARMS.

     The PSM is limited by real-time capacity to a maximum of 60
     operator positions.  A PSM can host up to five RISLUs (loaded to
     a collective total of 60 operator positions) with one active and
     one spare T1 span each.  This corresponds to 10 PIDBs for
     RISLUs, plus 2 PIDBs for the PSU shelf, and 3 PIDBs for
     announcements, for a total of less than 16 PIDBs per TSI.  The
     PSM is not time slot limited.  Note that a PSM is a dedicated SM
     and cannot contain any lines, trunks, service circuits, or test
     ports.  The following hardware items are engineered for the PSM:

       o  PSU

       o  DSU2-RAF

       o  DLTU-RH.

     A DSL_MAJOR or DSL_MINOR alarm indication is present in the SM
     STATUS box, and SEE 1460 is present in the RELATED PAGES box
     when the OSPS terminal equipment is OOS.  The 1460-DATA LINK
     DSLS page display provides the status of the OSPS terminal
     equipment.

     The following indicators are applicable to the RISLU equipment
     on the SM:

       o  The CKT_OOS SM STATUS phrase can refer to the OOS RISLU
          circuits.

       o  The RISLU UNIT SUMMARY indicator backlights when RISLU
          circuits are OOS or RISLU fan/fuse alarms are present.

       o  The RISLU digital line trunk unit (DLTU) summary indicator
          backlights when RISLU digital facility interfaces (DFI) are
          OOS or carrier group alarms (CGA) are present.

       o  The RISLU SITE BLDG/PWR ALARM indicators backlight if the
          alarms are off-normal at one or more RISLU sites hosted by
          a specific SM that monitors RISLU site alarms.

     If the SM is isolated or initializing, this display is
     available, but the only status that will fill in reliably is the
     SM STAT box and the RELATED PAGES box. The only per-SM displays
     available during these conditions are 1800,X - SM X INHIBITED &
     RECOVERY CONTROL, 1200,X - SM X DLI/TMSLNK, and 1900,X - SM X
     CLNKS. Also, 1600,X or 1600,SZ - SITE Z STATUS will be available
     if at least one of the RSMs at the site is not isolated.

     Figure .AW G197/ is an example of the LSM version that shows SM 115
     status.  In this example, the SM STAT box shows that SM 115 is
     in DSL MAJOR.  The ``+'' (following DSL MAJOR) indicates the
     presence of additional (less important) off-normal conditions.
     A complete list can be generated and output via the 900 menu
     command.  Additional information on the DSL MAJOR condition is
     available on the 1460 and 1800 pages as indicated in the RELATED
     PAGES box.

     The equipped hardware units are listed in the graphic portion
     (lower right area) of the display. In this area, an off-normal
     RISLU condition is reflected by the backlighted DLTU 0
     indicator.

     Figure .AW G198/ is an example of the LSM version.  In this example,
     SM 115 LSM status (DSL_MAJOR) indicates the DSL data link is
     OOS.  Pages 1460 and 1800 are referenced for additional
     information.

     Figure .AW G199/ is an example of the HSM version of the SM status
     display. In this display, the HSM is normal. This HSM is hosting
     four RSMs located at two different sites.

     Figure .AW G200/ is an example of the RSM version of the SM status
     display. In this example, DLTU 0 and MSU 0, SG 0 have some off-
     normal condition. Also, there is a building/power alarm.

     Figure .AW G201/ shows the RSM version of the SM status display with
     no building/power alarms equipped.  This SM has an off-normal
     condition in the remote clock unit and, one or more inhibits are
     set.  The ``+'' in the SM STAT box indicates the presence of
     additional (less important) off-normal conditions.  The user is
     directed to see Page 1800 for additional information.  A
     complete list can be generated and output via the 900 menu
     command.

     Figure .AW G202/ shows the PSM version of the SM status display.  The
     PSM has a RISLU which is equipped with building/power alarms and
     has a building/power alarm off normal.  Also, there is an off-
     normal state at RISLU site 502.

     Figure .AW G203/ shows the ORM version of the SM status page.  The ORM
     is equipped with the building/power alarms.  The ORM is
     displaying a HASH-ERR with the MCTSI memory.  The ``+'' in the
     SM STAT BOX indicating the presence of additional (less
     important) off-normal conditions.  Additional information is
     available on Pages 115 and 1800.  A complete list can be
     generated and output via the 900 menu command.

     A command is provided to output the off-normal report for the SM
     for which the 1010,X page is displayed.

     All available paging commands can be entered from the 1010,X
     display page.

     CMD   RESULT

     900   Output the off-normal report for the SM
           (OP:SYSSTAT,SM=SM#)

     The purpose of the 102X,Y page display is to illustrate the
     status of the equipped line unit (LU) concentrators and A-LINKs.
     The 102X,Y page has three distinct versions.  In each version,
     the ``X'' equals the line unit number and the ``Y'' equals the
     switching module number.  Each LU (models 1, 2, and 3) has an
     associated version of the 102X,Y display page.  The first
     version, for LU model 1, is for the regular LU concentrator.
     The second and third versions, illustrates that each grid is
     divided into two boards.  Status and maintenance commands are
     available for each board in the grid.

     The A-LINK indicator is a summary of any out-of-service A-LINKs.
     This indicator contains either the term OOS and is backlighted
     (if an A-LINK is OOS) or the term NORM and is not backlighted
     (all A-LINKs normal).

     The SM STAT box indicates the presence of an INHIBIT condition.
     The ``t'' in the SM STAT box indicates the presence of
     additional (less important) off-normal conditions.  A complete
     list can be generated and output via the 900 menu command.

     Figure .AW G204/ is an example of the LU model 1 version of the LU
     concentrator display.

     Figure .AW G205/ is an example of the LU model 2 version of the LU
     concentrator display.

     Figure .AW G206/ is an example of the LU model 3 version.

     Commands are provided to remove, restore, diagnose, and test
     (fabric exercise) the LU concentrator grids/grid boards.  Also,
     a command is provided to output a list of all out-of-service A-
     LINKs. All available page display commands can be entered from
     the 102X,Y page display.

 3
     Model 1 Version

     CMD   RESULT

     20X   Grid X is removed
           (RMV:GRID=SM#-LU#-X) [,UCL]
     30X   Grid X is restored
           (RST:GRID=SM#-LU#-X) [,UCL]
     50X   Grid X is diagnosed
           (DGN:GRID=SM#-LU#-X,RAW,TLP) [,UCL] [,GROW]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed
     51X   Grid X is tested
           (TST:GRID=SM#-LU#-X,RAW,TLP) [,UCL] [,AUD]
           [,PH=a|a&&b] a is the diagnostic phase or a&&b is the range
           of phases to be performed
     900   Out of service ALINKs are output
           (OP:CFGSTAT,SM=SM#,ALINKS)


 3
     Model 2 and Model 3 Versions

     CMD    RESULT

     200X   Board 0 of Grid X is removed
            (RMV:GRIDBD=SM#-LU#-X-0) [,UCL]
     201X   Board 1 of Grid X is removed
            (RMV:GRIDBD=SM#-LU#-X-1) [,UCL]
     300X   Board 0 of Grid X is restored
            (RST:GRIDBD=SM#-LU#-X-0) [,UCL]
     301X   Board 1 of Grid X is restored
            (RST:GRIDBD=SM#-LU#-X-1) [,UCL]
     500X   Board 0 of Grid X is diagnosed
            (DGN:GRIDBD=SM#-LU#-X-0,RAW,TLP) [,UCL] [,GROW]
            [,RPT] test will be repeated 32,767 times
            [,RPT=a] a is the number of times the test is to be repeated
            (1-32,767)
            [,PH-b|b&&c] b is the diagnostic phase or b&&c is the range
            of phases to be performed
     501X   Board 1 of Grid X is diagnosed
            (DGN:GRIDBD=SM#-LU#X-1,RAW,TLP) same options as 500X
     502X   Board 0 of Grid X is tested
            (TST:GRIDBD=SM#-LU#-X-0,RAW,TLP)
     503X   Board 1 of Grid X is tested
            (TST:GRIDBD=SM#-LU#-X-0,RAW,TLP)
     900    Out-of-service ALINKs are output
            (OP:CFGSTAT,SM=SM#,ALINKS)


     The purpose of the 103Y,X and 104Y,X display pages is to show
     status and commands for the equipped line units.
     The 103Y,X and 104Y,X displays are graphically identical. The
     differences are page numbers and titles.

     There are two separate versions of this page. The first version
     (Figure .AW G207/) is for the regular line unit.  This version has
     GDXCON and maintenance commands for it. The second version
     (Figure .AW G208/) does not have these commands.  The configuration is
     selected by software.

     When an off-normal condition occurs, the indicator for the
     condition will backlight. On 1010,X - SM X STATUS, the indicator
     for the line unit service group will backlight. On Page 114 -
     EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be
     backlighted; and on the appropriate 141, 142, 143, or 144 page,
     the indicator for that SM will be backlighted; and a descriptive
     phrase of the condition will be written, unless a more critical
     condition exists. In the SUMMARY STATUS AREA, the SM critical
     indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if
     applicable, will be backlighted.

     Figure .AW G207/ example is the regular version of the line unit
     display. The version is selected by system software and has
     GDXCON and maintenance commands for it.

     Figure .AW G208/ is the C1LU version of the line unit.

     Commands are provided to remove, restore, and diagnose the line
     unit circuits. On the regular version, there also is a switch
     command for the GDXCON.

     All available displays can be accessed from this page.

 3
     Both Versions

     CMD   RESULT

     2XX   Channel XX is removed
           (RMV:LUCHAN=SM#-LU#-SG#-XX) [,UCL]
     240   COMC is removed
           (RMV:LUCOMC=SM#-LU#-SG#) [,UCL]
     260   GDXACC is removed
           (RMV:GDXACC=SM#-LU#-SG#) [,UCL]
     27X   CHBD X is removed
           (RMV:LUCHBD=SM#-LU#-SG#-X) [,UCL]
     28X   HLSC X is removed
           (RMV:LUHLSC=SM#-LU#-SG#-X) [,UCL]
     3XX   Channel XX is restored
           (RST:LUCHAN=SM#-LU#-SG#-XX) [,UCL]
     340   COMC is restored
           (RST:LUCOMC=SM#-LU#-SG#) [,UCL]
     360   GDXACC is restored
           (RST:GDXACC=SM#-LU#-SG#) [,UCL]
     37X   CHBD X is restored
           (RST:LUCHBD=SM#-LU#-SG#-X) [,UCL]
     38X   HLSC X is restored
           (RST:LUHLSC=SM#-LU#-SG#-X) [,UCL]
     5XX   Channel XX is diagnosed
           (DGN:LUCHAN=SM#-LU#-SG#-XX,RAW,TLP) [,UCL] [,GROW]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to
           be repeated (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is
           the range of phases to be performed
     540   COMC is diagnosed
           (DGN:LUCOMC=SM#-LU#-SG#,RAW,TLP) same options as 5XX
     560   GDXACC is diagnosed
           (DGN:LUCOMC=SM#-LU#-SG#,RAW,TLP) same options as 5XX
     58X   HLSC X is diagnosed
           (DGN:LUHLSC=SM#-LU#-SG#-X,RAW,TLP) same options
           as 5XX

     Regular Version Only

     CMD   RESULT

     250   GDXCON is removed
           (RMV:GDXCON=SM#-LU#-SG#) [,UCL]
     350   GDXCON is restored
           (RST:GDXCON=SM#-LU#-SG#) [,UCL] [,STBY]
     450   GDXCON is switched
           (SW:GDXCON=SM#-LU#)
     550   GDXCON is diagnosed
           (DGN:GDXCON=SM#-LU#-SG#) same options as 5XX


     The purpose of the 105Y,X and 106Y,X displays is to show status
     and commands for the equipped trunk units.
     The 105Y and 106Y displays are graphically identical. The
     differences are page numbers and titles.

     When an off-normal condition occurs, the indicator for the
     condition will backlight. On Page 1010,X SM X STATUS, the
     indicator for the trunk unit service group will backlight. On
     Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM
     will backlight; and on the appropriate 141, 142, 143, or 144
     page, the indicator for that SM will backlight and a descriptive
     phrase of the condition will be written unless a more critical
     condition exists. In the SUMMARY STATUS AREA, the SM critical
     indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if
     applicable, will backlight.

     Figure .AW G209/ shows the trunk unit display for service group 0. The
     CHBD 2 is currently being diagnosed, which can be determined by
     the out-of-service transient (OOST). The diagnostic has already
     been completed on circuits 23 and 22, and they passed (they
     remain out-of-service family until the entire CHBD is finished).
     The diagnostic is currently up to circuit 21. Circuit 20 was
     OOSF before the diagnostics were started.

     Also, the SM STAT box shows that a circuit in this SM is out of
     service (CKT OOS).

     Commands are provided to remove, restore, and diagnose the trunk
     unit circuits.

     All available displays can be accessed from this page.

 2
     CMD   RESULT

     2XX   Circuit XX is removed
           (RMV:TEN=SM#-TU#-SG#-XX) [,UCL]
     280   CDI is removed
           (RMV:CDI=SM#-TU#-SG#) [,UCL]
     285   TAC is removed
           (RMV:TAC=SM#-TU#-SG#) [,UCL]
     29X   CHBD X is removed
           (RMV:TUCHBD=SM#-TU#-SG#-X) [,UCL]
     3XX   Circuit XX is restored
           (RST:TEN=SM#-TU#-SG#-XX) [,UCL]
     380   CDI is restored
           (RST:CDI=SM#-TU#-SG#) [,UCL]
     385   TAC is restored
           (RST:TAC=SM#-TU#-SG#) [,UCL]
     39X   CHBD X is restored
           (RST:TUCHBD=SM#-TU#-SG#-X) [,UCL]
     5XX   Circuit XX is diagnosed
           (DGN:TEN=SM#-TU#-SG#-XX,RAW,TLP) [,UCL] [,GROW]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed
     580   CDI is diagnosed
           (DGN:CDI=SM#-TU#-SG#,RAW,TLP) same options as 5XX
     585   TAC is diagnosed
           (DGN:TAC=SM#-TU#-SG#,RAW,TLP) same options as 5XX
     59X   CHBD X is diagnosed
           (DGN:TUCHBD=SM#-TU#-SG#-X,RAW,TLP) same options as 5XX


     The purpose of the 107Y,X display page is to show status and
     maintenance commands for the directly connected test unit
     (DCTU), if equipped.
     If an off-normal condition occurs in any of the DCTU circuits,
     the circuit indicator will backlight and have text explaining
     the nature of the off-normal condition. The DCTU indicator on
     1010 - SM X STATUS will backlight. On Page 114 - EQUIPPED SM
     STATUS SUMMARY, the indicator for that SM will be backlighted;
     and on the appropriate 141, 142, 143, or 144 page, the indicator
     for that SM will be backlighted and a descriptive phrase of the
     condition will be written, unless a more critical condition
     exists. In the SUMMARY STATUS AREA, the SM critical indicator
     and the alarm level (CRITICAL, MAJOR, or MINOR) if applicable,
     will be backlighted.

     Figure .AW G210/ shows all the units in the DCTU are active.

     Commands are provided to remove, restore, and diagnose the units
     on the display.

     All available displays can be accessed from this page.
 2

     CMD   RESULT

     2XX   DCTU Port XX is removed
           (RMV:DCTUPORT=SM#-DCTU#-XX) [,UCL]
     22X   PMU X is removed
           (RMV:PMU=SM#-DCTU#-X) [,UCL]
     230   DCTUCOM is removed
           (RMV:DCTUCOM=SM#-DCTU#) [,UCL]
     240   EAN is removed
           (RMV:EAN=SM#-DCTU#) [,UCL]
     3XX   DCTU Port XX is restored
           (RST:DCTUPORT=SM#-DCTU#-XX) [,UCL]
     32X   PMU X is restored
           (RST:PMU=SM#-DCTU#-X) [,UCL]
     330   DCTUCOM is restored
           (RST:DCTUCOM=SM#-DCTU#) [,UCL]
     340   EAN is restored
           (RST:EAN=SM#-DCTU#) [,UCL]
     5XX   DCTU Port XX is diagnosed
           (DGN:DCTUPORT=SM#-DCTU#-XX,RAW,TLP) [,UCL]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed
     52X   PMU X is diagnosed
           (DGN:PMU=SM#-DCTU#-X,RAW,TLP) same options as 5XX
     530   DCTUCOM is diagnosed
           (DGN:DCTUCOM=SM#-DCTU#,RAW,TLP) same options as 5XX and
           [,SVG] runs diagnostics on the entire service group, including
           the demand phases
     540   EAN is diagnosed
           (DGN:EAN=SM#-DCTU#,RAW,TLP) same options as 5XX


     The purpose of the 108Y,X display is to show status and commands
     for the equipped LDSUs.
     There are two separate and distinct versions of the 108Y - LDSU
     Y SG 0 and 1 page. The first version is the model 1 version
     (Figure .AW G211/). The model 1 version has LDSUCOMs in each service
     group and up to eight DSCs in each service group. The second
     version is the model 2 version (Figure .AW G212/). The model 2 version
     displays status for the LDSUs in each service group (no
     LDSUCOMs), displays which slot each is located in, and lists up
     to seven types of circuits and how many there are (no status is
     displayed) for each service group.

     When an off-normal condition occurs, the indicator for the
     condition will backlight. On Page 1010,X - SM X STATUS, the
     indicator for the LDSU service group will backlight. On Page 114
     - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be
     backlighted; and on the appropriate 141, 142, 143, or 144 page,
     the indicator for that SM will be backlighted and a descriptive
     phrase of the condition will be written, unless a more critical
     condition exists. In the SUMMARY STATUS AREA, the SM critical
     indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if
     applicable, will be backlighted.

     Figure .AW G211/ is the display for the model 1 version of the LDSU Y
     SG 0 and 1 page.  In this example, everything is active.

     Figure .AW G212/ shows the model 2 version of the LDSU Y SG 0 and 1
     page. In this display example, both service groups are active
     and both are located in slot 0. They each have 31 tone
     generators and 30 tone decoders.

     Commands are provided to remove, restore, and diagnose the LDSU
     circuits.

     All available displays can be accessed from this page.
 3

     Model 1 Version

     CMD   RESULT

     20X   LDSUCOM SG X is removed
           (RMV:LDSUCOM=SM#-X) [,UCL]
     21X   DSC X SG 0 is removed
           (RMV:DSC=SM#-DSU#-0-X) [,UCL]
     22X   DSC X SG 1 is removed
           (RMV:DSC=SM#-DSU#-1-X) [,UCL]
     30X   LDSUCOM SG X is restored
           (RST:LDSUCOM=SM#-X) [,UCL]
     31X   DSC X SG 0 is restored
           (RST:DSC=SM#-DSU#-0-X) [,UCL]
     32X   DSC X SG 1 is restored
           (RST:DSC=SM#-DSU#-1-X) [,UCL]
     50X   LDSUCOM SG X is diagnosed
           (DGN:LDSUCOM=SM#,SG#,RAW,TLP) [,UCL] [,GROW] [,SVG]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed
     51X   DSC X is diagnosed
           (DGN:DSC=SM#-DSU#-SG#-X,RAW,TLP) same options as 50X except SVG

 3

     Model 2 Version

     CMD   RESULT

     23X   LDSU SG X is removed from service
           (RMV:LDSU=SM#-DSU#-X) [,UCL]
     33X   LDSU SG X is restored to service
           (RST:LDSU=SM#-DSU#-X) [,UCL]
     53X   LDSU SG X is diagnosed
           (DGN:LDSU=SM#-DSU#-X,RAW,TLP) [,UCL]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be
           repeated (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed


     The 109Y,X display page shows the status and maintenance
     commands for the Recorded Announcement Function (RAF).  The page
     also indicates the associated memory board(s), its application,
     and the specific slot where the RAF board is located.
     There are three types of RAF: dial-through announcement (DTA),
     announcement (ANN), and coin detecting dial-through announcement
     (COIN). The types associated with the RAF are listed on the
     109Y,X page.  An RAF has at least one memory board.  The RAF
     application is indicated with the memory board on the page.

     Figure .AW G213/ is an example of the 109Y,X display page showing an
     RAF with DTA and OSPS-DA applications.

     Commands are provided to remove, restore, and diagnose the RAF
     connections.  Any available paging commands can be entered from
     this display page.

     CMD   RESULT

     200   RAF is removed (RMV:RAF=a-b)
     300   RAF is restored (RST:RAF=a-b)
     500   RAF is diagnosed (DGN:RAF=a-b,RAW,TLP)

     The purpose of the 110Y,X display page is to show status and
     commands for the equipped global digital service units (GDSU).
     The 110Y page displays status for both GDSU service groups.

     When an off-normal condition occurs, the indicator for the
     condition will backlight. On Page 1010,X - SM X STATUS, the
     indicator for the GDSU service group will backlight. On Page 114
     - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be
     backlighted; and on the appropriate 141, 142, 143, or 144 page,
     the indicator for that SM will be backlighted and a descriptive
     phrase of the condition will be written, unless a more critical
     condition exists. In the SUMMARY STATUS AREA, the SM critical
     indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if
     applicable, will be backlighted.

     Figure .AW G214/ is the display for GDSU SG 0 and GDSU SG 1.  In this
     example, SG 0, DSC 0 (a universal conference circuit), is out of
     service.  Also, the SM STAT box shows that one circuit of this
     SM is OOS (CKT OOS).

     Commands are provided to remove, restore, and diagnose the GDSU
     circuits.

     All available displays can be accessed from the 110Y page.

 2
     CMD   RESULT

     20X   GDSUCOM SG X is removed
           (RMV:GDSUCOM=SM#-GDSU#-X) [,UCL]
     21X   DSC X SG 0 is removed
           (RMV:DSC=SM#-GDSU#-0-X) [,UCL]
     22X   DSC X SG 1 is removed
           (RMV:DSC=SM#-GDSU#-1-X) [,UCL]
     30X   GDSUCOM SG X is restored
           (RST:GDSUCOM=SM#-GDSU#-X) [,UCL]
     31X   DSC X SG 0 is restored
           (RST:DSC=SM#-GDSU#-0-X) [,UCL]
     32X   DSC X SG 1 is restored
           (RST:DSC=SM#-GDSU#-1-X) [,UCL]
     50X   GDSUCOM SG X is diagnosed
           (DGN:GDSUCOM=SM#-GDSU#-X,RAW,TLP) [,UCL] [,GROW] [,SVG]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed
     51X   DSC X SG 0 is diagnosed
           (DGN:DSC=SG#-GDSU#-0-X,RAW,TLP) same options as 50X except SVG
     52X   DSC X SG 1 is diagnosed
           (DGN:DSC=SM#-GDSU#-1-X,RAW,TLP) same options as 50X except SVG


     The purpose of the 1110,X display page is to show status and
     commands for the integrated services test functions (ISTF).
     Page 1110 displays status for all ISTF 0-3 peripheral units in
     the given SM and shows status of the services and channels
     serving each unit.

     When an off-normal condition occurs, the indicator for the
     condition will backlight.  On Page 1010,X, SM X STATUS, there is
     exactly one box for an SM that has ISTF units.  As a result, the
     indicator for the ISTF will backlight, and SM X STAT will show
     CKT OOS.

     On Page 114, EQUIPPED SM STATUS SUMMARY, the indicator for the
     SM will be backlighted, for example, SM 1 shows 1L OUT (if X=1).
     On the appropriate Page 141, 142, 143, or 144, the indicator for
     that SM will be backlighted and a descriptive phrase of the
     condition will be written unless a more critical condition
     exists.  An example of a descriptive phrase is 1 LSM CKT OOS (if
     X=1).  In the SUMMARY STATUS AREA, the SM critical indicator and
     the appropriate alarm level (CRITICAL, MAJOR, or MINOR), if
     applicable, will be backlighted.

     Figure .AW G215/ is an example of the 1110,X page.  In this example,
     ISTF 2 is out of service, 0 channel is in use and 10 channels
     are available for LOOPBACK, 0 channel is in use and 3 channels
     are available for XMIT, and 0 channel is in use and 13 channels
     are available for ISTF 2.  The SM 001 STAT shows circuit out of
     service (CKT OOS) and the SM indicator is backlighted.

     Commands are provided to remove, restore, and diagnose ISTF
     circuits.

     All available page displays can be accessed from Page 1110.

     CMD   RESULT

     20X   ISTF unit X is removed
           (RMV:ISTF=SM#-X) [,UCL]
     30X   ISTF unit X is restored
           (RST:ISTF=SM#-X) [,UCL]
     50X   ISTF unit X is diagnosed
           (DGN:ISTF=SM#-X) [,[RAW] [,UCL] [,GROW] [,TLP]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times test is to be repeated
           (1-32,767)
           [,PH-d[&&e]] d is the diagnostic phase or d&&e is the
           range of phases to be performed

     The purpose of the 112Y,X display page is to show status and
     provide maintenance controls for DLTU Y and to report local,
     remote, and Alarm Indication Signal (AIS) Carrier Group Alarms
     (CGA).
     The 112Y,X display page has three separate versions.  The first
     version (Figures .AW G216/ and .AW G217/) is for Local Switching Modules
     (LSM).  The second version (Figures .AW G218/ and .AW G219/) is for Host
     Switching Modules (HSM).  The third version (Figures .AW G220/ and
     .AW G221/) is for Remote Switching Modules (RSM).

     All three versions have commands to remove, restore, and
     diagnose DFIs and to remove and restore FACs.  The second and
     third versions have an additional command to test FACs.  If the
     RSM is equipped with any inter-RSM Communication Link Digital
     Facilities Interfaces (CDFI), commands to remove and restore
     Remote Communication Links (RCL) will also be added.

     The DLTU provides direct interfaces to T1 lines.

     The 112Y,X page is designed into three sections.  The first
     section displays DFI specific information, the second shows T1
     Facility 0 information, and the third shows T1 Facility 1
     information.

     When an off-normal condition occurs in a DFI, the DFI indicator
     will backlight.  When a CGA occurs, an indicator appears in the
     CGA column associated with the DFI.  The indicator contains the
     letter L, R, or A (for local, remote, or AIS, respectively).  If
     one or more off-normal condition is present on this display, the
     DLTU Y indicator on Page 1010,X - SM X STATUS is backlighted. On
     Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM
     will be backlighted; and on the appropriate 141, 142, 143, or
     144 page, the indicator for that SM will be backlighted and a
     descriptive phrase of the condition will be written, unless a
     more critical condition exists. In the SUMMARY STATUS AREA, the
     SM critical indicator and the alarm level (CRITICAL, MAJOR, or
     MINOR), if applicable, will be backlighted.

     The HSM and RSM versions have information on the DFI displayed
     in the FAR END column which shows the connection at the
     ``other'' end.  Included will be the SM number, the DLTU number,
     the DFI number, and the FAC number within the DLTU.

     The HSM version also has two lines which appear in a box near
     the top of the display.  The first line is labeled RSM -> and
     will list all RSMs hosted by the HSM for which the page is being
     displayed.  The second line is labeled AT SITE -> and will show
     the sites of the RSMs listed on the first line.

     In the HSM and RSM versions, the DFI(s) carrying the control
     time slot is shown by an (*).  In the RSM version, the DFI
     receiving reference timing is shown by an (&).  The LSM version
     shows neither control time slot nor receive reference timing.

     Figure .AW G216/ is an example of the LSM Version of the 112Y,X Page
     which shows the TDFI 5 is out of service and there are CGAs in
     the group associated with TDFI 3, Facility 0, and TDFI 2,
     Facility 1.

     Figure .AW G217/ is an example of the LSM Version of the 112Y,X Page
     for a DLTU with only one T1 Facility.

     Figure .AW G218/ shows an example of the HSM version of the DLTU
     display. In this example, the HSM hosts RSM 192 at SITE 234 and
     RSM 124 at SITE 301.  The HDFI 1 and HDFI 3 are carrying control
     time slots (*).

     Figure .AW G219/ is an example of the HSM version of the DLTU display
     with only one T1 Facility.

     Figure .AW G220/ shows the RSM version of the DLTU display. In this
     example, RDFI 4 is OOS and a CGA is associated with RDFI 2,
     Facility 1. Also, the RCL associated with CDFI 5 is out-of-
     service family. The RDFI 1 and RDFI 3 are carrying control time
     slots (*).  The RDFI 1 and RDFI 2 are receiving reference timing
     (&).

     Figure .AW G221/ shows the RSM version of the DLTU display with only
     one T1 Facility.

     All three versions, LSM, HSM, and RSM, have commands to remove,
     restore, and diagnose DFIs and to remove and restore FACs.  The
     HSM and RSM versions have an additional command to test FACs.
     In addition, any available paging command can be entered from
     this display.


     LSM Version

      CMD    RESULT

     20XX    DFI XX is removed
             (RMV:DFI=SM#-DLTU#-XX) [,UCL]
     21XXY   T1FAC Y of DFI XX is removed
             (RMV:FAC=SM#-DLTU#-XX-Y) [,UCL]
     30XX    DFI XX is restored
             (RST:DFI=SM#-DLTU#-XX) [,UCL]
     31XXY   T1FAC Y of DFI XX is restored
             (RST:FAC=SM#-DLTU#-XX-Y) [,UCL]
     50XX    DFI XX is diagnosed
             (DGN:DFI=SM#-DLTU#-XX,RAW,TLP) [,UCL] [,GROW]
             [,RPT] test will be repeated 32,767 times
             [,RPT=a] a is the number of times the test is to be repeated
             (1-32,767)
             [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
             of phases to be performed

 4
     HSM Version

      CMD    RESULT

     20XX    DFI XX is removed
             (RMV:DFI=SM#-DLTU#-XX) [,UCL]
     21XXY   T1FAC Y of DFI XX is removed
             (RMV:FAC=SM#-DLTU#-XX-Y) [,UCL]
     30XX    DFI XX is restored
             (RST:DFI=SM#-DLTU#-XX) [,UCL]
     31XXY   T1FAC Y of DFI XX is restored
             (RST:FAC=SM#-DLTU#-XX-Y) [,UCL]
     50XX    DFI XX is diagnosed
             (DGN:DFI=SM#-DLTU#-XX,RAW,TLP) [,UCL] [,GROW]
             [,RPT] test will be repeated 32,767 times
             [,RPT=a] a is the number of times the test is to be repeated
             (1-32,767)
             [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
             of phases to be performed
     51XXY   T1FAC Y of DFI XX is tested
             (TST:FAC=SM#-DLTU#-XX-Y)
             [,RPT] test will be repeated 32,767 times
             [,RPT=a] a is the number of times the test is to be repeated
             (1-32,767)
             [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
             of phases to be performed


 4
     RSM Version

      CMD    RESULT

     20XX    DFI XX is removed
             (RMV:DFI=SM#-DLTU#-XX) [,UCL]
     21XXY   T1FAC Y of DFI XX is removed
             (RMV:FAC=SM#-DLTU#-XX-Y) [,UCL]
     22XXY   RCL XX of FAC Y is removed
             (RMV:RCL=SM#-DLTU#-XX-Y) [,UCL]
     30XX    DFI XX is restored
             (RST:DFI=SM#-DLTU#-XX) [,UCL]
     31XXY   T1FAC Y of DFI XX is restored
             (RST:FAC=SM#-DLTU#-XX-Y) [,UCL]
     32XXY   RCL XX of FAC Y is restored
             (RST:RCL=SM#-DLTU#-XX-Y [,UCL]
     50XX    DFI XX is diagnosed
             (DGN:DFI=SM#-DLTU#-XX,RAW,TLP) [,UCL] [,GROW]
             [,RPT] test will be repeated 32,767 times
             [,RPT=a] a is the number of times the test is to be repeated
             (1-32,767)
             [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
             of phases to be performed
     51XXY   T1FAC Y of DFI XX is tested
             (TST:FAC=SM#-DLTU#-XX-Y)
             [,RPT] test will be repeated 32,767 times
             [,RPT=a] a is the number of times the test is to be repeated
             (1-32,767)
             [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
             of phases to be performed


     The purpose of the 113Y/114Y,X page is to show units equipped,
     to show status, and to provide maintenance commands for MSU X
     and multiple MSU X.
     The 113Y/114Y,X page has two separate versions.  The first
     version (Figure .AW G222/) has one metallic test interface bus access
     (MTIBAX), four metallic access buses (MAB), and up to sixteen
     metallic service circuits. The second version (Figure .AW G223/) is
     the modular Metallic Service Unit (MSU) version and has four
     MTIBAXs, sixteen MABs, and up to thirty-two metallic service
     circuits.

     When an off-normal condition occurs in any MSU circuit, the
     circuit indicator will backlight. On Page 1010,X - SM X STATUS,
     the MSU Y SG 0 or SG 1 indicator will backlight. On Page 114 -
     EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be
     backlighted; and on the appropriate 141, 142, 143, or 144 page,
     the indicator for that SM will be backlighted and a descriptive
     phrase of the condition will be written, unless a more critical
     condition exists. In the SUMMARY STATUS AREA, the SM critical
     indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if
     applicable, will be backlighted.

     Figure .AW G222/ shows the regular version of the MSU display. This
     example shows some of the typical MSU circuits which can be
     equipped on an SM. There are no off-normal conditions.

     Figure .AW G223/ shows the modular MSU version of the MSU display
     page. There are no off-normal conditions in this example.

     Commands are provided to remove, restore, and diagnose various
     MSU circuits.

     All available displays can be accessed from the 113Y/114Y,X
     page.

 3
      Regular Version

     CMD    RESULT

     2XX    MAB XX is removed
            (RMV:MAB=SM#-MSU#-SG#-XX) [,UCL]
     220    MSUCOM is removed
            (RMV:MSUCOM=SM#-MSU#-SG#) [,UCL]
     221    PROTO is removed
            (RMV:PROTO=SM#-MSU#-SG#) [,UCL]
     240    MTIBAX 0 is removed
            (RMV:MTIBAX=SM#-MSU#-SG#-0) [,UCL]
     20XX   Circuit XX is removed
            (RMV:CKT=SM#-MSU#-SG#-XX) [,UCL]
     3XX    MAB XX is restored
            (RST:MAB=SM#-MSU#-SG#-XX) [,UCL]
     320    MSUCOM is restored
            (RST:MSUCOM=SM#-MSU#-SG#) [,UCL]
     321    PROTO is restored
            (RST:PROTO=SM#-MSU#-SG#) [,UCL]
     340    MTIBAX 0 is restored
            (RST:MTIBAX=SM#-MSU#-SG#-0) [,UCL]
     30XX   Circuit XX is restored
            (RST:CKT=SM#-MSU#-SG#-XX) [,UCL]
     5XX    MAB XX is diagnosed
            (DGN:MAB=SM#-MSU#-SG#-XX,RAW,TLP) [,UCL] [,GROW]
            [,RPT] test will be repeated 32,767 times
            [,RPT=a] a is the number of times the test is to be repeated
            (1-32,767)
            [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
            of phases to be performed
     520    MSUCOM is diagnosed
            (DGN:MSUCOM=SM#-MSU#-SG#,RAW,TLP)
            Same options as 5XX
     521    PROTO is diagnosed
            (DGN:PROTO=SM#-MSU#-SG#,RAW,TLP)
            Same options as 5XX, except GROW
     540    MTIBAX 0 is diagnosed
            (DGN:MTIBAX=SM#-MSU#-SG#-0,RAW,TLP)
            Same options as 5XX, except GROW
     50XX   Circuit XX is diagnosed
            (DGN:CKT=SM#-MSU#-SG#-XX,RAW,TLP)
            Same options as 5XX, except GROW


     Modular MSU Version

     CMD   RESULT

     24X   MTIBAX X is removed
           (RMV:MTIBAX=SM#-MSU#-SG#-X) [,UCL]
     34X   MTIBAX X is restored
           (RST:MTIBAX=SM#-MSU#-SG#-X) [,UCL]
     54X   MTIBAX X is diagnosed
           (DGN:MTIBAX=SM#-MSU#-SG#-X,RAW,TLP)
           Same options as 5XX, except GROW

     The purpose of the 115Y,X page is to show status summary and
     provide commands for the SLC Carrier DCLU SG 0 and 1 SDFIs, if
     equipped.
     If an off-normal condition occurs in any of the DCLU SDFI
     circuits, the circuit indicator will backlight and have text
     explaining the nature of the off-normal condition. The DCLU
     indicator on Page 1010 will backlighted. On Page 114, the
     indicator for that SM will be backlighted; and on the
     appropriate 141, 142, 143, or 144 page, the indicator for that
     SM will be backlighted and a descriptive phrase of the condition
     will be written, unless a more critical condition exists. In the
     SUMMARY STATUS AREA, the SM critical indicator and the alarm
     level (for example, MINOR) will backlight.  There are summary
     indicators for each of the associated RTs.

     Figure .AW G224/ shows all the SDFI units in SG 1 are active.  The SG
     0 has two OOS SDFIs (4 and 6). These are both connected to RT 1,
     and the RT 1 indicator reflects the OOS condition.

     The second number in the RT box (4768) is the subscriber loop
     carrier identification (SID).

     Commands are provided to remove, restore, and diagnose the
     equipped units. Also provided are paging commands for the
     associated RTs.
 2

     CMD    RESULT

     2XX    DCLU SDFI XX is removed
            (RMV:SDFI=SM#-DCLU#-XX) [,UCL]
     23X    DCLU SG X is removed
            (RMV:DCLU=SM#-DCLU#-X) [,UCL]
     3XX    DCLU SDFI XX is restored

            (RST:SDFI=SM#-DCLU#-XX) [,UCL]
     33X    DCLU SG X is restored
            (RST:DCLU=SM#-DCLU#-X) [,UCL]
     5XX    DCLU SDFI XX is diagnosed
            (DGN:SDFI=SM#-DCLU#-XX,RAW,TLP) [,UCL]
            [,RPT] test will be repeated 32,767 times
            [,RPT=a] a is the number of times the test is to be repeated
            (1-32,767)
            [,PH =b|b&&c]] b is the diagnostic phase or b&&c is the range
            of phases to be performed
     53X    DCLU SG X is diagnosed
            (DGN:DCLU=SG#-DCLU#-X,RAW,TLP) same options as 5XX
     131X   DCLU X RT 1 page is displayed
     132X   DCLU X RT 2 page is displayed
     133X   DCLU X RT 3 page is displayed
     134X   DCLU X RT 4 page is displayed
     135X   DCLU X RT 5 page is displayed
     136X   DCLU X RT 6 page is displayed


     The purpose of the 1160,X page display is to provide status and
     menu commands for miscellaneous hardware units in the remote
     switching module (RSM) and optically remoted module (ORM).
     The 1160,X page display (Figure .AW G225/) contains any miscellaneous
     units in an RSM/ORM which do not belong on any other per-SM
     page. Presently, the only unit contained on this page is the
     alarm and status circuit (ASC). If the RSM has been retrofitted,
     the indicator and commands will refer to the Remote Alarm Unit
     instead of the ASC.

     When an off-normal condition occurs, the indicator for the fault
     will backlight. The MISC indicator on Page 1010,X - SM X RSM/ORM
     STATUS will backlight.  On Page 114 - EQUIPPED SM STATUS
     SUMMARY, the indicator for that SM will be backlighted and on
     the appropriate 141, 142, 143, or 144 page, the indicator for
     that SM will be backlighted and a descriptive phrase of the
     condition will be written, unless a more critical condition
     exists. In the SUMMARY STATUS AREA, the SM critical indicator
     and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable,
     will be backlighted.

     Commands are provided to remove, restore, and diagnose any
     miscellaneous units which appear on the 1160,X page.

     CMD   RESULT

     200   Remove the Alarm and Status Circuit from service
           (RMV:ASC SM#) [,UCL]
     300   Restore the Alarm and Status Circuit to service
           (RST:ASC SM#) [,UCL]
     500   Diagnose the Alarm and Status Circuit
           (DGN:ASC SM#)

     The purpose of the 1170,X display page is to show status and
     provide maintenance commands for the remote clock, remote clock
     oscillator, remote clock cross-couples, remote clock oscillator
     cross-couples, and remote clock references.
     The 1170X page is only available on remote switching modules
     (RSM) and only on RSMs that are equipped with a remote clock
     (RCLK).

     The remote clock cross-couples (RCXC) show the link status
     between the two RCLKs.

     The remote clock oscillator cross-couples (RCOXC) show the link
     status between the remote clock oscillators (RCOSC) and the
     RCLKs.

     Only one reference per side can be in the active state at one
     time. The rest of the equipped references on that side will be
     in the standby state if they are not OOS.

     The RCLK mode is displayed in the RCLK indicators. There are
     four RCLK modes:

       o  FAST: This is used to obtain initial synchronization with
          the reference signal. The RCLK is scanning the incoming
          synchronization signal from the HSM at an accelerated rate.

       o  NORM: This mode means the T1 umbilical to the host SM (HSM)
          is up and the RCLK has obtained synchronization from the
          HSM.

       o  HOLD: The holdover mode is used when synchronization is
          lost. This is an off-normal mode.

       o  FREE: The free mode indicates initialization of an RCLK
          with no good reference signal. This is an off-normal mode.

     Figure .AW G226/ shows an example of the 1170,X display page in which
     RCLK 1 is out of service. This caused RCXC 0, RCXC 1, RCOXC 1,
     and RCREF 1 and 2 on SIDE 1 to be out-of-service family of
     equipment (OOSF). It also caused RCOSC 1 to go to standby (STBY)
     (if not already standby).

     Commands are provided to remove and restore the RCLK, RCOSC,
     RCXC, RCOXC, and RCREF, to diagnose the RCLKs, and to switch the
     RCLKs and the RCOSCs.

     All available displays can be accessed from the 1170X page.
 2

     CMD   RESULT

     20X   RCLK X is removed from service
           (RMV:RCLK=SM#-X) [,UCL]
     21X   RCOSC X is removed from service
           (RMV:RCOSC=SM#-X) [,UCL]
     22X   RCXC X is removed from service
           (RMV:RCXC=SM#-X) [,UCL]
     23X   RCOXC X is removed from service
           (RMV:RCOXC=SM#-X) [,UCL]
     24X   RCREF X is removed from service
           (RMV:RCREF=SM#-X) [,UCL]
     30X   RCLK X is restored to service
           (RST:RCLK=SM#-X) [,UCL] [,STBY]
     31X   RCOSC X is restored to service
           (RST:RCOSC=SM#-X) [,STBY]
     32X   RCXC X is restored to service
           (RST:RCXC=SM#-X)
     33X   RCOXC X is restored to service
           (RST:RCOXC=SM#-X) [,STBY]
     34X   RCREF X is restored to service
           (RST:RCREF=SM#-X) [,ACT | STBY]
     403   RCLK is switched
           (SW:RCLK=SM#)
     41X   RCOSC X is switched
           (SW:RCOSC=SM#-X)
     50X   RCLK X is diagnosed
           (DGN:RCLK=SM#-X,RAW,TLP) [,UCL] [,GROW]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of
           phases to be performed


     The purpose of Page 118Y,X (Y = shelf 0-5) is to provide status
     and maintenance commands for PHs, hardware type of PHs, status
     of channel groups, type of channel groups, and assignment of
     channel groups to PHs.
     The PSU Shelf MCC page display (one per PSU shelf) provides two
     tables.  The first table (PSUPH ASSIGNMENT STATUS) contains the
     16 individual PHs with their status.  The second table (CHANNEL
     GRP SUMMARY) contains the corresponding channel group type.  The
     PH status data of each of the PSU Shelf pages supplies the PH
     status summary of the PSU Network display (1186).  The PHs
     serving channel groups are marked active (ACT).  The PHs that
     are able to provide service but are not serving a channel group
     are marked standby (STBY).  The PHs that are removed from
     service are not available as spares and are marked out of
     service (OOS).  The PHs that are partially faulty may be marked
     degraded (DGRD), when there are no standby PHs, rather than
     being removed.  This allows the PH to be of partial service to
     its channel group.  For PHs that are out of service or degraded,
     the PH shelf summary is marked DGRD on the PSU Network page.  If
     possible, the channel groups of OOS PHs are moved to serviceable
     PHs.  When the supply of spare PHs is exhausted, a channel group
     associated with the OOS PH is removed from the PSUPH Assignment
     Status table, and the Channel Group number and type on the
     Channel Group Summary table is backlighted.  The shelf of that
     PH, in the PSUPH Status Summary box (on the PSU Network page),
     is marked DGRD and the entry of how many channel groups are not
     being serviced is incremented. Any other state displayed in PH
     status locations is required for a removable, diagnosable,
     growable, and inhibitable individual unit.

     The appropriate peripheral status block of the SM on the SM
     Status page is marked with PSU.  When any portion of the PSU is
     OOS, the block is backlighted.  If the status reported on the SM
     Status page or on any of the PSU display pages changes while
     being displayed, the appropriate indicators are updated with
     changed status.

     The 118Y,X page (Figure .AW G227/) is divided into three basic areas.
     The ``CHANNEL GRP SUMMARY'' block at the right side of the
     display indicates the channel group number, PH hardware type
     required by the channel group, and channel group type which can
     be one of the following:

       o  DSLG2 - Used for all Basic Digital Subscriber Line (DSL)
          and Extended DSL (EDSL) Applications (requires PH type 2)

       o  ISM2 - Inter-SM Packet Switching (requires PH type 2)

       o  TRK2 - Inter-Switch Packet Trunks (requires PH type 2)

       o  X75P2 - X.75' trunks (requires PH type 2)

       o  MIXED2 - More than one type of the application on a logical
          PH (requires PH type 2).

     The ``PSUPH ASSIGNMENT STATUS'' block in the middle of the page
     indicates the PH status, PH hardware type,  and channel group
     assignment to each PH.  The hardware equipage in a given PSU is
     designated by PH type.  When equipped, a PH is ACT (active) or
     STBY (standby). The third area of this display contains the ``SM
     STAT'' indicator block (with SITE number).  Also, below the SM
     status block, a list of commands exists for management of the
     PSUPH maintenance.

     Commands are provided to remove, restore, diagnose, and switch
     PHs shown on this page.

     The restore and switch commands also have a group (GRP) option
     that allows assignment of a specified channel group.  The GRP
     option is only allowed with the switch command when switching
     from a standby (STBY) PH to an active (ACT) PH.  The STBY PH is
     the one specified in the switch command, and the channel group
     of the ACT PH is specified in the GRP option (for example,
     SW:PSUPH=a-0-0-b,GRP=c, where PH number b is a STBY PH and GRP c
     is assigned to an ACT PH).

     When restoring PHs, the GRP option can be used to assign a
     specified channel group to the PH being restored (for example,
     RST:PSUPH=a-0-0-b,GRP=c, where PH number b is OOS, STBY or ACT,
     and GRP c is a channel group).  If the channel group specified
     cannot be switched or restored to PH, the command will fail and
     a message will print indicating why the command failed.

     Commands available for control of the multiple protocol handlers
     are as follows:

     CMD      RESULT

     2XX     Remove PSUPH XX (RMV:PSUPH=a-0-b-XX)
     3XX     Restore PSUPH XX (RST:PSUPH=a-0-b-XX)
     4XX     Switch PSUPH XX (SW:PSUPH=a-0-b-XX)
     5XX     Diagnose PSUPH XX (DGN:PSUPH=a-0-b-XX, RAW,TLP)

     The 1186,X page display provides the current PSU status, the
     PSUCOM status, and the PH shelf status summary.
     The PSU Network page display simultaneously shows the state of
     both PSUCOMs and a status summary of the PHs per PSU shelf. The
     PSUCOM is composed of the Control Fanout (CF), and each Data
     Fanout (DF) and Protocol Fanout (PF) of the equipped shelves of
     the same side.  The PSUCOM can be removed, restored, or switched
     as a single entity, and the status is noted on the MCC as a
     duplex SM peripheral controller.  The status summary of the PHs
     on this page is on a shelf basis, because any sparing of the PHs
     is performed on a shelf basis.  When any PH is removed from
     service or degraded, this page has the shelf of its residence
     marked degraded.  If the shelf should have more PHs removed than
     the shelf has spares to take the place of the PHs that are
     serving channel groups, the shelf is marked degraded and the
     count of channel groups not being serviced is displayed. The
     possible states of the PH shelves can be ``normal'' (all
     equipped PHs in service when the shelf is equipped),
     ``degraded,'' ``unequipped,'' and ``growth.''

     The PSUPH SUMMARY indicator box provides status for a maximum of
     16 PHs/shelves (indicating 1 spare PH/shelf).

     Figure .AW G228/ shows an example of the 1186,X page display.

     Commands are provided to remove, restore, diagnose, and switch
     PSUCOMs.  Also any PSU shelf and any available paging commands
     can be accessed from this page.  In the following commands, a =
     SM number.

     CMD    RESULT

     200    Removes PSUCOM 0 (RMV:PSUCOM=a-0-0)
     201    Removes PSUCOM 1 (RMV:PSUCOM=a-0-1)
     300    Restore PSUCOM 0 (RST:PSUCOM=a-0-0)
     301    Restore PSUCOM 1 (RST:PSUCOM=a-0-1)
     500    Diagnose PSUCOM 0 (DGN:PSUCOM=a-0-0,RAW,TLP)
     501    Diagnose PSUCOM 1 (DGN:PSUCOM=a-0-1,RAW,TLP)
     400    Switch control and state of active and standby PSUCOM
            (SW:PSUCOM=a-0)
     118X   Display PSU shelf X

     The purpose of the 1190,X page display is to show status and
     provide maintenance commands for the module controller time slot
     interchanger (MCTSI ), dual link interface (DLI), remote link
     interface (RLI), and bootstrapper (BTSR).
     The 1190,X page has two separate and distinct versions. The
     first version is for local switching modules (LSM) and host
     switching modules (HSM). This version shows DLIs). The second
     version is for remote switching module (RSM) and optically
     remoted module (ORM).  The RSM version has RLIs instead of DLIs.

     When an off-normal condition occurs, the indicator for the
     condition will backlight. On Page 1010,X, the MCTSI (MCTSI/RLI)
     indicator will backlight. On Page 114, the indicator for the SM
     will backlight; and on the appropriate 141, 142, 143, or 144
     page, the indicator for the SM will be backlighted, and a phrase
     describing the problem will be written, unless a more critical
     condition exists. In the SUMMARY STATUS AREA, the SM critical
     indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if
     applicable, will be backlighted.

     If the SM is isolated or initializing and this display is
     requested, it will display, but only the status of the DLIs will
     fill in and the SM X STAT indicator will say ISOLATED. The DLI
     status data is maintained in the AM and is available for
     display. The MCTSI, RLI, and bootstrapper (BTSR) status data is
     stored in the SM; and since it is isolated, the data cannot be
     accessed.

     The DLI status indicator block is divided into two sections: one
     for DLI status and the other is used to identify the presence of
     transmission rate converter unit (TRCU) hardware.  The TRCU
     portion of the indicator block does not indicate alarm status.

     Bootstrapper Information

     Poke commands for BTSR (for example, 202 BTSR) are rejected if
     the SMs are equipped with the SMP20 processor.  The SMP20
     processor is also referred to as the module controller/time slot
     interchange model 2 (MCTU2).  The poke commands for BTSR on the
     1190,X page are applicable only to non-SMP20 SMs.

     The BTSR status indicator block is not displayed on the 1190,X
     page when the SM is equipped with the SMP20 processor.
     Therefore, the BTSR status indicator block is only displayed for
     non-SMP20 processors (for example, SMP1/SMP12).

     Figure .AW G229/ is an example of the regular version of the MCTSI
     display which shows DLI 1 out-of-service family of equipment,
     due to ONTC 1 being unavailable.

     Figure .AW G230/ is an example of the ORM version of the MCTSI
     display.

     Commands are provided to remove, restore, and diagnose the
     MCTSI, BTSR, DLIs, and RLIs, to switch the MCTSI and RLI, and to
     force active the MCTSI.

     Any available paging commands can be entered from the 1190,X
     page.

 2
     CMD   RESULT

     20X   MCTSI X is removed
           (RMV:MCTSI=SM#-X) [,UCL]
     202   BTSR is removed
           (RMV:BTSR=SM#) [,UCL]

     21X   DLI X is removed
           (RMV:DLI=SM#-X) [,UCL]
     30X   MCTSI X is restored
           (RST:MCTSI=SM#-X) [,UCL] [,STBY]
     302   BTSR is restored
           (RST:BTSR=SM#) [,UCL]
     31X   DLI X is restored
           (RST:DLI=SM#-X) [,UCL]
     50X   MCTSI X is diagnosed
           (DGN:MCTSI=SM#-X,RAW,TLP) [,UCL] [,GROW]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed
     502   BTSR is diagnosed
           (DGN:BTSR=SM#,RAW,TLP)
           Same options as 50X
     51X   DLI X is diagnosed
           (DGN:ONTC=X,DLI,SM#,RAW,TLP) [,UCL]
           Same options as 50X
     40X   MCTSI X is forced active
           (SET:MCTSI=SM#-X,FRC)
     402   MCTSI force is cleared
           (CLR:MCTSI=SM#,FRC)
     403   MCTSI is switched
           (SW:MCTSI=SM#)


     The purpose of the 1200,X page is to show status for the DLIs
     and the TMSLNKs that are connected to each ONTCCOM on a per-SM
     basis and to provide maintenance commands for the DLIs.
     The 1200,X page has two separate and distinct versions. The
     first version is for offices with CM2 hardware, and the second
     is for offices with CM1 hardware.  The difference between the
     two versions is the note at the lower left of the display
     defining ONTCCOM.  In CM2, an ONTCCOM does not have an LI as
     part of its hardware.

     Also provided on the 1200,X page is a view of the DLIs and the
     TMSLNKs connecting a particular SM to the ONTCs.  It shows the
     status of ONTCCOMs 0 & 1, the TMSLNKs for the particular SM and
     their status, and the status of the DLIs for the SM.

     The 1200,X page indicates the presence of the transmission rate
     converter unit (TRCU) for ORM.  Alarm status of the TRCU
     hardware is not indicated on the 1200,X page.  However, if a DLI
     goes OOS, the TRCU hardware may be faulty.  Look on the ROP to
     see if the TRCU hardware appears on the suspected faulty
     equipment list.

     Figure .AW G231/ is the CM2 version of the DLI/TMSLNK display.  This
     example shows ONTCCOM 1 unavailable forced removed (UNV)
     resulting in DLI 1 and TMSLNKs 14 and 15 for side 1 out-of-
     service family of equipment (OOSF).  The ONTCCOM 0 is degraded-
     forced (DGRF).

     Figure .AW G232/ is the CM1 version of the DLI/TMSLNK display.  In
     this example, ONTCCOM 0 is degraded (DGR) minor and ONTCCOM 1 is
     active (ACT) major.  The DLI 0 is unavailable power (UNVP)
     causing the 0 side TMSLNKs 14 and 15 to be out-of-service family
     of equipment (OOSF).  The SM 6 is isolated.

     Figure .AW G233/ is an example of the CM1 version of the 1200,X page
     that shows the TRCU.

     Commands are provided for removing, restoring, diagnosing, and
     outputting the configuration status for the DLIs for the SM this
     page is being displayed for.

     All available display commands can be entered from the 1200,X
     page display.

     CMD   RESULT

     200   DLI 0 is removed
     201   DLI 1 is removed
     300   DLI 0 is restored
     301   DLI 1 is restored
     500   DLI 0 is diagnosed
     501   DLI 1 is diagnosed
     900   Status of DLI 0 is output
     901   Status of DLI 1 is output

     The purpose of the 1209 display page is to show maintenance
     states for ONTC 0 and 1 and provide maintenance commands for the
     ONTCs and ONTCCOMs and hardware check status for ONTC 0 and 1.
     The 1209 display page has two separate versions.  The first
     version (Figure .AW G234/) is for offices with CM2 hardware. The
     second version (Figure .AW G235/) is for offices with CM1 hardware.
     The difference between the two versions is the note at the lower
     left of the display defining ONTCCOM.  In CM2, an ONTCCOM does
     not have a link interface (LI) as part of its hardware.

     Fabric update is the updating of the intermodule communication
     paths between TMS links. This is accomplished by writing in the
     fabric (FAB) random access memories (RAM) of the TMS, on a per
     time slot basis, information stored in AM memory. When the FAB
     update is in progress, the FAB update indicator for the side
     that is being updated will appear and be backlighted above the
     appropriate ONTC.

     Figure .AW G234/ is the CM2 version of the ONTC display. This example
     shows ONTC 1 unavailable, ONTC 0 is degrade forced, and FAB
     update is in progress on ONTC 0.

     Figure .AW G235/ is the CM1 version of the ONTC display. In this
     display, ONTC 0 is degraded minor and ONTC 1 is active major.
     The ONTC 0 has its hardware checks inhibited and FAB update is
     in progress on ONTC 0.

     Commands are provided for removing, restoring, diagnosing, and
     outputting the configuration status for the ONTCs and the
     ONTCCOMs for inhibiting, allowing, and switching the ONTCs and
     for forcing the ONTCCOMs.

     All available display commands can be entered from the 1209
     display page.

 2
     CMD   RESULT

     60X   Hardware Checks are inhibited for ONTC X
           (INH:HDWCHK,ONTC=X)
     70X   Hardware Checks are allowed for ONTC X
           (ALW:HDWCHK,ONTC=X)
     20X   ONTC X is removed
           (RMV:ONTC=X) [,UCL]
     21X   ONTCCOM X is removed
           (RMV:ONTCCOM=X) [,UCL]
     30X   ONTC X is restored
           (RST:ONTC=X) [,UCL]
     31X   ONTCCOM X is restored
           (RST:ONTCCOM=X) [,UCL]
           Note: if UCL option is used on an in-service ONTCCOM
           that has any child units (DLIs, TMSLNKs) OOS, those
           OOS child units will be restored.
     50X   ONTC X is diagnosed
           (DGN:ONTC=X,RAW,TLP) [,UCL]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed
     51X   ONTCCOM X is diagnosed
           (DGN:ONTCCOM=X,RAW,TLP) [,UCL]
           Same options as 50X
           Note: Implicitly provides status output for all
           child DLIs/TMSLINKs.
     90X   Status of ONTC X is output
           (OP:CFGSTAT,ONTC=X)
     91X   Status of ONTCCOM X is output
           (OP:CFGSTAT,ONTCCOM=X)


     The purpose of the 1210 display page is to show cross-couples
     between MI/NC 0 and 1, to show the network clock mode, and to
     provide maintenance commands.
     The 1210 display page has two separate versions.  The first
     version (Figure .AW G236/) is for offices with CM2 hardware. The
     second version (Figure .AW G237/) is for offices with CM1 hardware.
     Status shown for an MI/NC is actually the status of the ONTCCOM
     (MI/NC/TMS - CM2 or MI/LI/NC/TMS - CM1), side 0 or 1. There is
     no separate status for the MI/NC (MI/LI/NC - CM1).

     In the CM2 version, the NC XCs (network clock cross-couples)
     show the link status between the two NCs. There is a note at the
     lower left of the display defining ONTCCOM as MI/NC/TMS (no LI).
     The CM1 can be equipped with a network clock model 1 (NC1)  or
     network clock model 2 (NC2).  The NC1 version shows the PRIMARY
     and SECONDARY T1 carriers and the reference status. Also, there
     is an indicator showing the status of the LI and showing
     connections from LI 0 to LI 1 and there is a note at the lower
     left of the display defining ONTCCOM which includes the LI
     (MI/LI/NC/TMS).

     The NC2 version shows a summary status of the network clock
     references, the network clock oscillators, and oscillator
     cross-couples with the SEE PAGE 1211 indicator.

     In the CM2 version, only the NC2 version can be used and the
     network clock cross-couples show the link status between the two
     NCs.

     Below the MI/NC indicators on the display, there are indicators
     which show the network clock modes. The modes which can be shown
     are as follows:

       o  FAST: The fast mode is used to obtain initial sync with the
          reference signal. This would be considered a normal mode.

       o  NORM: After synchronization is obtained, the network clock
          goes into the norm mode. The norm mode is almost the same
          as fast, except the tolerance for deviation from the
          reference signal is narrowed to reduce error.

       o  HOLD: The holdover mode is used when synchronization is
          lost. This is an off-normal mode.

       o  FREE: The free mode indicates initialization of the NC with
          no good reference signal. This is also an off-normal mode.

       o  OOS: The OOS (out-of-service) mode is also an off-normal
          mode. The mode is OOS whenever and only whenever the NC is
          OOS.

     When an off-normal condition occurs with the T1 carriers or NC
     XCs, the MI/NC 0 (MI/LI/NC 0 - CM1) or MI/NC 1 (MI/LI/NC 1 -
     CM1) indicator backlights on Page 115. This in turn causes the
     CM indicator in the SUMMARY STATUS AREA to backlight. The alarm
     level (CRITICAL, MAJOR, or MINOR) will also backlight, if
     applicable.

     Figure .AW G236/ is the CM2 version which shows MI/NC 1 out of
     service. The MI/NC status is actually the ONTCCOM status. No
     separate status is maintained for the MI/NCs. The SEE PAGE 1211
     is also backlighted to indicate something off-normal on the 1211
     page and indicates that this office has a network clock model 2.

     Figure .AW G237/ shows the CM1 version with MI/LI/NC 0 degraded. The
     MI/LI/NC status is actually the ONTCCOM status. No separate
     status is maintained for the MI/LI/NCs. This office is equipped
     with an NC 1, indicated by the PRIMARY/SECONDARY references on
     the display.

     Since the MI/NC (MI/LI/NC - CM1), and TMSs function as a group
     (ONTCCOM), maintenance commands on this display (remove,
     restore, force active, and configuration status output) are for
     the ONTCCOM with the exception of the diagnose commands for the
     MIs and NCs (and LIs for CM1). Also, there are remove, restore,
     configuration status output, inhibit, and allow commands for the
     NC XCs, and a switch command for the ONTC.  All available page
     commands can be entered from the 1210 display page.

 3
     CM2 Version

     CMD   RESULT

     20X   ONTCCOM X is removed
           (RMV:ONTCCOM=X) [,UCL]
     21X   Network Clock Cross-Couple X is removed (RMV:NCREF,XC=X)

     30X   ONTCCOM X is restored
           (RST:ONTCCOM=X) [,UCL] [,MAJOR/MINOR]
     31X   Network clock Cross-Couple X is restored (RST:NCREF,XC=X)

     40X   ONTCCOM X is forced active (RST:ONTCCOM=X,FRC)

     402   ONTCCOM force is cleared (CLR:FRC,ONTCCOM)

     403   ONTC is switched (SW:ONTC)

     51X   MI X is diagnosed
           (DGN:MI=X,RAW,TLP) [,UCL]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of
           phases to be performed
     52X   NC X is diagnosed
           (DGN:NC=X,RAW,TLP)
           Same options as 51X
     61X   Network Clock Cross-Couple X hardware checks are inhibited
           (INH:HDWCHK,NCREF,XC=X)
     71X   Network Clock Cross-Couple X hardware checks are allowed
           (ALW:HDWCHK,NCFEF,XC=X)
     90X   Output the configuration status of ONTCCOM X
           (OP:CFGSTAT,ONTCCOM=X)
     91X   Output the configuration status of NC XC X
           (OP:CFGSTAT,NCREF,XC=X)

     CM1 Version

     53X   LI X is diagnosed
           (DGN:LI=X,RAW,TLP) [,UCL]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed


     The purpose of the 1211 display page is to show cross-couples
     between network clock oscillator (NCOSC) 0 & 1. It also shows
     the status of the NCOSCs, the oscillator cross-couples, and the
     network clock references.
     The 1211 display page has two separate versions.  The first
     version (Figure .AW G238/) is the 24-channel version.  The second
     version (Figure .AW G239/) is the 30-channel version.

     The 1211 page is only available in offices with the network
     clock model 2 hardware.

     The oscillator cross-couples (OSCXC) show the link status
     between the NCOSCs.

     If anything on the 1211 page is off-normal and backlighted, the
     SEE PAGE 1211 indicator on the 1210 page will be backlighted
     cyan, and the MI/NC (MI/LI/NC CM1) 0 or 1 indicator on Page 115
     will be backlighted cyan.

     The NCOSC type is displayed in the NCOSC indicators. There are
     two oscillator types. They are medium stability (MED STAB) and
     high stability (HIGH STAB).

     The 24-channel version only allows three references per side.
     Only one reference per side can be in the active state at one
     time.  The rest of the equipped references on that side will be
     in the standby state if they are not off-normal (that is, OOS,
     OOSF, etc.).

     The 30-channel version allows eight references per side.  Again,
     only one reference per side can be active at one time.  Also,
     there is a column between the reference columns titled LOCATION.
     The information in the LOCATION column is made up of three
     columns of information, colon (:) separated.

     These are the SMs which the reference comes from, the DLTU unit
     number in the SM, and the DFI number which provides the clock
     reference. This order is spelled out in the note which resides
     under the LOCATION box.

     The 24-channel version does not have the LOCATION column because
     the references in a 24-channel office are bridged off of a D-4
     channel bank, whereas, in a 30-channel office, the references
     are bridged off of SMs. This LOCATION information is the only
     way the craft will know which SM, DLTU, and DFI to go to when
     there is a reference problem.

     Figure .AW G238/ shows the 24-channel version of the network clock
     page for network clock model 2 (NC2). This display shows the
     NCOSC 1 out of service. The NCOSC 1 being OOS causes OSCXC 0 to
     be out-of-service family of equipment (OOSF).  The OSCXC 1 and
     all of the equipped references on side 1 are OOSF due to ONTC 1
     being OOS.

     Figure .AW G239/ shows the 30-channel version on the network clock
     page. In this example, reference 3, side 1 is out of service
     because of a fault.

     The 1211 display page provides commands to remove, restore, and
     output the configuration status of the NCREFs, NCOSCs, and
     OSCXCs and to switch the NCREFs and the NCOSCs.

     All available display commands can be entered from the 1211
     display page.
 2

     CMD   RESULT

     22X   NCREF X (both sides) is removed
           (X=1 - 3 for 24-Chan.; X=1 - 8 for 30-Chan.)
           (RMV:NCREF,X)
     23X   NCOSC X is removed
           (RMV:NCOSC=X)
     24X   OSCXC X is removed
           (RMV:OSCXC=X)
     32X   NCFEF X (both sides) is restored
           (X=1 - 3 for 24-Chan.; X=1 - 8 for 30-Chan.)
           (RST:NCREF,X)
     33X   NCOSC X is restored
           (RST:NCOSC=X)
     34X   OSCXC X is restored
           (RST:OSCXC=X)
     42X   NCREF X (both sides) is switched
           (X=1 - 3 for 24-Chan.; X=1 - 8 for 30-Chan.)
           (SW:NCREF,X)
     43X   Side X NCOSC is switched
           (SW:NCOSC=X)
     9XY   Output the configuration status of Side X NCREF Y
           (1 - 3 for 24-Chan.; 1 - 8 for 30-Chan.)
           (OP:CFGSTAT,NCREF,Y=X)
     93X   Output the configuration status of Side X NCOSC
           (OP:CFGSTAT,NCOSC=X)
     94X   Output the configuration status of Side X OSCXC
           (OP:CFGSTAT,OSCXC=X)


     The purpose of the 1220 display page is to show status, to
     provide an index to the TMS LINK pages, and to provide
     maintenance commands for the TMSs.
     The 1220 page has two separate and distinct versions. The first
     version (Figure .AW G240/) is for offices with CM2 hardware. The
     second version (Figure .AW G241/) is for offices with CM1 hardware.
     The difference between the two versions is the note at the lower
     left of the display defining ONTCCOM (CM2 does not have a LI),
     the CM2 version shows a cross-couple between TMS 0 and TMS 1
     that the CM1 version does not have, and the CM1 version has TMS
     0 and 1 fan and fan fuse alarms and CM2 does not.

     Status shown for a TMS is actually the status of the ONTCCOM
     (MI/NC/TMS - CM2; MI/LI/NC/TMS - CM1), side 0 or 1. There is no
     separate status for the TMS.

     When an off-normal condition occurs in the ONTCs, the indicator
     on the 1220 page for the respective TMS backlights and CM
     backlights in the SUMMARY STATUS AREA. The associated alarm
     level (CRITICAL, MAJOR, or MINOR) will also backlight, if
     applicable.

     The TMS indicators on Display Page 115 will never be backlighted
     because there is no maintenance to be done from this page when
     something is off-normal.

     The index indicators on Display Page 1220 do not backlight when
     a TMS link goes off-normal because the craft is not directed to
     this page. The craft would be directed to the appropriate TMS
     LINK page from Page 115.

     Figure .AW G240/ shows the CM2 version of the TMS 0 and 1 SUMMARY
     page. This display example shows TMS 1 unavailable due to
     ONTCCOM 1 being unavailable, and TMS 0 is degraded forced due to
     ONTCCOM 0 being degraded forced.

     Figure .AW G241/ shows the CM1 version of the TMS 0 and 1 SUMMARY
     page. This display example shows the fan fuse alarm for TMS 0 is
     inhibited and TMS 0 is degraded.

     The maintenance commands shown are for the ONTCCOM, except for
     the diagnose commands which are provided for TMS.

     All available paging commands can be entered from the 1220
     display page.
 2

     CMD   RESULT

     20X   ONTCCOM X is removed
           (RMV:ONTCCOM=X) [,UCL]
     30X   ONTCCOM X is restored
           (RST:ONTCCOM=X) [,UCL] [,MAJOR/MINOR]
     40X   ONTCCOM X is forced active
           (SET:FRC,ONTCCOM=X)
     402   ONTCCOM force is cleared
           (CLR:FRC,ONTCCOM)
     403   ONTC is switched
           (SW:ONTC)
     51X   TMS X is diagnosed
           (DGN:TMS=X,RAW,TLP) [,UCL]
           [,RPT] test will be repeated 32,767 times
           [,RPT=a] a is the number of times the test is to be repeated
           (1-32,767)
           [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range
           of phases to be performed


     The purpose of the 1221 display page is to show status and
     maintenance commands for the TMS links.
     The 1221 through 1228 and 1231 through 1238 group of displays
     are very similar. The 1221 through 1228 group is for TMS 0, and
     the 1231 through 1238 group is for TMS 1.  Displays 1221 and
     1231 show status for 62 links each; the rest of the displays
     show status for 64 links each.

     When an off-normal condition occurs for a TMSLINK, the indicator
     for the link backlights, the appropriate page number indicator
     on Page 115 backlights, and CM backlights in the SUMMARY STATUS
     AREA. The associated alarm level (CRITICAL, MAJOR, or MINOR)
     will also backlight, if applicable. If a DLI is out of service,
     the SM number will backlight and the TMSLNKs to that SM will be
     out-of-service family of equipment.

     Figure .AW G242/ is an example of the 1221 page which shows TMS link
     18 out of service.  This causes the CM indicator at the top of
     the screen to backlight.

       Note:   The TMS links are part of the communication links
               (CLNKS), but the two types of links are not the
               same.

     The restore maintenance command for the TMS links are provided.
     The display command shown on the 1221 page example is of a
     related page. If both TMS links for an SM are out of service,
     action should be taken from the 1200 page for that SM, not from
     the TMS page.

     All available paging commands can be entered from the 1221
     display page.

     Pages 1221 Through 1228

     CMD    RESULT

     3XXX   TMS Link XXX on TMS 0 is restored
            (RST:TMSLNK=0-XXX)


     Pages 1231 Through 1238

     CMD    RESULT

     3XXX   TMS Link XXX on TMS 1 is restored
            (RST:TMSLNK=1-XXX)

     The purpose of the 1240 and 1250 Pages is to show status and
     provide maintenance commands for the message switches (MSGS).
     The 1240 Page is for MSGS 0, and the 1250 Page is for MSGS 1.
     The 1240 and 1250 pages have two separate and distinct versions.
     The first version (Figure .AW G243/) is for offices with CM2 hardware.
     The second version (Figure .AW G244/) is for offices with CM1
     hardware. One difference between the two versions is the
     reference to a connection to the MI/NC for the CM2 version
     versus to the MI/LI/NC for the CM1 version.  The CM2 has no LI.
     Another difference is the CM1 version has MSGS fan and fan fuse
     alarms and the CM2 version does not. The last difference is the
     CM2 version has inhibit and allow hardware checks for the MSCUs
     and the CM1 version does not.

     The displays for MSGS 0 and MSGS 1 are very similar.

     When an off-normal condition occurs in the CMP, FPC, or PPC
     (Pages 1241/1251), the SEE PAGE indicator backlights on Pages
     1240/1250, the 1241 or 1251 indicator on Page 115 backlights,
     and CM backlights in the SUMMARY STATUS AREA. The associated
     alarm level (CRITICAL, MAJOR, or MINOR) will also backlight, if
     applicable.

     When an off-normal condition occurs in an MMP (Pages 1242/1252
     and 1243/1253), the SEE PAGE indicator backlights on 1240/1250,
     the 1242, 1252, 1243, or 1253 indicator on the 115 Page
     backlights, and CM backlights in the SUMMARY STATUS AREA.  The
     associated alarm level (CRITICAL, MAJOR, or MINOR) will also
     backlight if applicable.

     Figure .AW G243/ is the CM2 version of the 1240/1250 page.  The SEE
     PAGE 1242 indicator is backlighted because an MMP on 1242 is out
     of service. This causes the 1242 indicator under the MSGS 0
     indicator to backlight on Page 115 - COMMUNICATION MODULE
     SUMMARY, which in turn causes the CM summary status indicator at
     the top of the screen to backlight.

     Figure .AW G244/ is the CM1 version of the 1240/1250 page.

     Commands are provided to remove, restore, diagnose, inhibit
     hardware checks, allow hardware checks, force, switch, and
     output the configuration status of the MSGS and its units. In
     addition, all available displays can be accessed from the 1240
     or 1250 display pages.
 3

           MSGS 0                               MSGS 1

     CMD   RESULT                         CMD   RESULT

     230   MSGS 0 is removed              231   MSGS 1 is removed
           (RMV:MSGS=0 [,UCL])                  (RMV:MSGS=1 [,UCL])
     260   MSCU 0 is removed              261   MSCU 1 is removed
           (RMV:MSCU=0 [,UCL])                  (RMV:MSCU=1 [,UCL])
     330   MSGS 0 is restored             331   MSGS 1 is restored
           (RST:MSGS=0 [,UCL])                  (RST:MSGS=1 [,UCL])
     360   MSCU 0 is restored             361   MSCU 1 is restored
           (RST:MSCU=0)                         (RST:MSCU=1)
     400   MSCU 0 is forced active        401   MSCU 1 is forced active
           (SET:FRC,MSCU=0)                     (SET:FRC,MSCU=1)
     402   MSCU force is cleared          402   MSCU force is cleared
           (CLR:FRC,MSCU)                       (CLR:FRC,MSCU)
     530   MSGS 0 is diagnosed            531   MSGS 1 is diagnosed
           (DGN:MSGS=0,RAW,TLP)                 (DGN:MSGS=1,RAW,TLP)
           [,UCL]                               [,UCL]
           [,RPT] test is run 32,767            [,RPT] test is run 32,767
           times                                times
           [,RPT=a] where a is the              [,RPT=a] where a is the
           number of times the test             number of times the test
           is to be repeated (1-32,767)         is to be repeated (1-32,767)
           [,PH=b|b&&c] where b is the          [,PH=b|b&&c where b is the
           phase or b&&c is the range           phase or b&&c is the range
           of phases to be performed            of phases to be performed

     560   MSCU 0 is diagnosed            561   MSCU 1 is diagnosed
           (DGN:MSCU=0,RAW,TLP)                 (DGN:MSCU=1,RAW,TLP)
           Same options as 530 plus             Same options as 531 plus
           [,GROW] diagnose                     [,GROW] diagnose
           growth hardware                      growth hardware
     660   Inhibit hardware checks        661   Inhibit hardware checks
           for MSCU 0                           for MSCU 1
           (INH:HDWCHK,MSCU=0)                  (INH:HDWCHK,MSCU=1)
     760   Allow hardware checks          761   Allow hardware checks
           for MSCU 0                           for MSCU 1
           (ALW:HDWCHK,MSCU=0)                  (ALW:HDWCHK,MSCU=1)
     930   Configuration status for       931   Configuration status for
           MSGS 0 is output                     MSGS 1 is output
           (OP:CFGSTAT,MSGS=0)                  (OP:CFGSTAT,MSGS=1)
     960   Configuration status for       961   Configuration status for
           MSCU 0 is output                     MSCU 1 is output
           (OP:CFGSTAT,MSCU=0)                  (OP:CFGSTAT,MSCU=1)


     The purpose of the 1241 and 1251 pages is to show status and
     provide maintenance commands for CMPs, PPCs, and FPCs.  The 1241
     page is for MSGS 0 communities 0, 1, 8, and 9.  The 1251 page is
     for MSGS 1 communities 0, 1, 8, and 9.
     The 1241 and 1251 pages have two separate and distinct versions.
     The first version (Figure .AW G245/) is for offices with CM2 hardware.
     The second version (Figure .AW G246/) is for offices with CM1
     hardware. The difference between the two versions is the
     location of the CMP.  The CMP is equipped in community 0 in the
     CM2 version and in community 1 in the CM1 version.

     The displays for MSGS 0 and MSGS 1 are very similar.

     When an off-normal condition occurs in the FPC or PPC, the
     indicator for the circuit backlights, the SEE PAGE 1241 (or
     1251) on 1240 (or 1250) backlights, the 1241 or 1251 indicator
     on Page 115 backlights, and the CM backlights in the SUMMARY
     STATUS AREA. The associated alarm level (CRITICAL, MAJOR, or
     MINOR) will also backlight, if applicable.

     When an off-normal condition occurs in a CMP, the indicator for
     the circuit backlights, the SEE PAGE 1850 indicator backlights,
     the SEE PAGE 1241/1251 indicators backlight on Page 1240/1250,
     the 1241 or 1251 indicator on the 115 page backlights, and the
     CM backlights in the SUMMARY STATUS AREA.  The associated alarm
     level (CRITICAL, MAJOR, or MINOR) will also backlight if
     applicable.

     Figure .AW G245/ is the CM2 version of the 1241/1251 page.

     Figure .AW G246/ is the CM1 version of the 1241/1251 page.

     Commands are provided to remove, restore, diagnose, inhibit
     hardware checks, allow hardware checks, switch, and output the
     configuration status of the CMPs, FPCs, or PPCs.  In addition,
     all available displays can be accessed from the 1241 or 1251
     display pages.
 3

           MSGS 0                               MSGS 1

     CMD   RESULT                         CMD   RESULT

     2XX   CMP XX is removed              2XX   CMP XX is removed
           (RMV:CMP=0-XX) [,UCL]                (RMV:CMP=1-XX) [,UCL]
     240   FPC 0 is removed               241   FPC 1 is removed
           (RMV:FPC=0)                          (RMV:FPC=1)
     250   PPC 0 is removed               251   PPC 1 is removed
           (RMV:PPC=0)                          (RMV:PPC=1)
     3XX   CMP XX is restored             3XX   CMP XX is restored
           (RST:CMP=0-XX) [,UCL][,STBY]         (RST:CMP=1-XX) [,UCL][,STBY]
     340   FPC 0 is restored              341   FPC 1 is restored
           (RST:FPC=0) [,UCL] [,STBY]           (RST:FPC=1) [,UCL] [,STBY]
     350   PPC 0 is restored              351   PPC 1 is restored
           (RST:PPC=0) [,UCL] [,STBY]           (RST:PPC=1) [,UCL] [,STBY]
     4XX   CMP XXs are switched           4XX   CMP XXs are switched
           (SW:CMP=0-XX) [,UCL]                 (SW:CMP=1-XX) [,UCL]
     440   FPCs are switched              441   FPCs are switched
           (SW:FPC)                             (SW:FPC)
     450   PPCs are switched              451   PPCs are switched
           (SW:PPC)                             (SW:PPC)
     5XX   CMP XX is diagnosed            5XX   CMP XX is diagnosed
           (DGN:CMP=0-XX,RAW,TLP)               (DGN:CMP=1-XX,RAW,TLP)
           [,UCL]                               [,UCL]
           [,RPT] test is run 32,767            [,RPT] test is run 32,767
           times                                times
           [,RPT=a] where a is the              [,RPT=a] where a is the
           number of times the test             number of times the test
           is to be repeated (1-32,767)         is to be repeated (1-32,767)
           [,PH=b|b&&c] where b is the          [,PH=b|b&&c] where b is the
           phase or b&&c is the range           phase or b&&c is the range
           of phases to be performed            of phases to be performed
           [,GROW] diagnose                     [,GROW] diagnose
           growth hardware                      growth hardware
     540   FPC 0 is diagnosed             541   FPC 1 is diagnosed
           (DGN:FPC=0,RAW,TLP)                  (DGN:FPC=1,RAW,TLP)
           Same options as 5XX                  Same options as 5XX
           except GROW                          except GROW
     550   PPC 0 is diagnosed             551   PPC 1 is diagnosed
           (DGN:PPC=0,RAW,TLP)                  (DGN:PPC=1,RAW,TLP)
           Same options as 5XX                  Same options as 5XX
           except GROW                          except GROW
     6XX   Inhibit hardware checks        6XX   Inhibit hardware checks
           for CMP XX                           for CMP XX
           (INH:HDWCHK,CMP=0-XX)                (INH:HDWCHK,CMP=1-XX)
     640   Inhibit hardware checks        641   Inhibit hardware checks
           for FPC 0                            for FPC 1
           (INH:HDWCHK,FPC=0)                   (INH:HDWCHK,FPC=1)
     650   Inhibit hardware checks        651   Inhibit hardware checks
           for PPC 0                            for PPC 1
           (INH:HDWCHK,PPC=0)                   (INH:HDWCHK,PPC=1)
     7XX   Allow hardware checks          7XX   Allow hardware checks
           for CMP XX                           for CMP XX
           (ALW:HDWCHK,CMP=0-XX)                (ALW:HDWCHK,CMP=1-XX)
     740   Allow hardware checks          741   Allow hardware checks
           for FPC 0                            for FPC 1
           (ALW:HDWCHK,FPC=0)                   (ALW:HDWCHK,FPC=1)
     750   Allow hardware checks          751   Allow hardware checks
           for PPC 0                            for PPC 1
           (ALW:HDWCHK,PPC=0)                   (ALW:HDWCHK,PPC=1)
     9XX   Configuration status for       9XX   Configuration status for
           (OP:CFGSTAT,CMP=0-XX)                (OP:CFGSTAT,CMP=1-XX)
     940   Configuration status for       941   Configuration status for
           FPC 0 is output                      FPC 1 is output
           (OP:CFGSTAT,FPC=0)                   (OP:CFGSTAT,FPC=1)
     950   Configuration status for       951   Configuration status for
           PPC 0 is output                      PPC 1 is output
           (OP:CFGSTAT,PPC=0)                   (OP:CFGSTAT,PPC=1)


     The purpose of the 1242, 1243, 1252, and 1253 pages is to show
     status and provide maintenance commands for the MSGS 0 and MSGS
     1 MMPs. The 1242 page is for MSGS 0 communities 2 through 7.
     The 1243 page is for MSGS 0 communities 10 through 15. The 1252
     page is for MSGS 1 communities 2 through 7. The 1253 page is for
     MSGS 1 communities 10 through 15.
     Although the 1242, 1243, 1252, and 1253 pages have two separate
     versions (CM1 and CM2), they are very similar in appearance and
     function.  The 1242 example shown in Figure .AW G247/ is for offices
     with CM2 hardware. The second version of the 1242 page is shown
     in Figure .AW G248/ and is for offices with CM1 hardware.  The
     difference between the two versions is the way the communities
     are equipped.

     The displays for COMMUNITIES 10 - 15 for MSGS 0 and MSGS 1 are
     very similar to the examples shown for COMMUNITIES 2 - 7.

     There are up to 48 MMPs across the 12 communities in each MSGS.
     The MMPs only appear on the displays if they are equipped.

     When an off-normal condition occurs, the indicator for the MMP
     backlights, the SEE PAGE 1242 (1243, 1252, or 1253) on 1240 (or
     1250) backlights, the 1242 (1243, 1252, or 1253) indicator on
     Page 115 backlights, and CM backlights in the SUMMARY STATUS
     AREA. The associated alarm level (CRITICAL, MAJOR, or MINOR)
     will also backlight, if applicable.

     Figure .AW G247/ is an example of the CM2 version of Page 1242, MSGS 0
     - COMMUNITIES 2 - 7.  In this example, MMP 02 is shown out-of-
     service power. This causes the SEE PAGE 1242 indicator on 1240
     to backlight and the 1242 indicator on Page 115 - COMMUNICATION
     MODULE SUMMARY to backlight which in turn causes the CM status
     summary indicator at the top of the screen to backlight.

     Figure .AW G248/ shows an example of the CM1 version of the MSGS 0 -
     COMMUNITIES 2 - 7 Page.  The MMP 2 is unavailable power.  The
     MMP 3 is active but has its hardware checks inhibited.

     Commands are provided to remove, restore, diagnose, inhibit
     hardware checks, allow hardware checks, and output the
     configuration status of the MMPs. In addition, all available
     displays can be accessed from the 1241, 1242, 1251, and 1252
     pages.
 3

           MSGS 0                               MSGS 1

     CMD   RESULT                         CMD   RESULT

     2XX   MMP XX is removed              2XX   MMP XX is removed
           (RMV:MMP=0-XX)                       (RMV:MMP=1-XX)
     3XX   MMP XX is restored             3XX   MMP XX is restored
           (RST:MMP=0-XX) [,UCL]                (RST:MMP=1-XX) [,UCL]
     5XX   MMP XX is diagnosed            5XX   MMP XX is diagnosed
           (DGN:MMP=0-XX,RAW,TLP)               (DGN:MMP=1-XX,RAW,TLP)
           [,UCL]                               [,UCL]
           [,RPT] test is run 32,767            [,RPT] test is run 32,767
           times                                times
           [,RPT=a] where a is the              [,RPT=a] where a is the
           number of times the test             number of times the test
           is to be repeated (1-32,767)         is to be repeated (1-32,767)
           [,PH=b|b&&c] where b is the          [,PH=b|b&&c] where b is the
           phase or b&&c is the range           phase or b&&c is the range
           of phases to be performed            of phases to be performed
           [,GROW] diagnose                     [,GROW] diagnose
           growth hardware                      growth hardware
     6XX   Inhibit hardware checks        6XX   Inhibit hardware checks
           for MMP XX                           for MMP XX
           (INH:HDWCHK,MMP=0-XX)                (INH:HDWCHK,MMP=1-XX)
     7XX   Allow hardware checks          7XX   Allow hardware checks
           for MMP XX                           for MMP XX
           (ALW:HDWCHK,MMP=0-XX)                (ALW:HDWCHK,MMP=1-XX)
     9XX   Configuration status for       9XX   Configuration status for
           MMP XX is output                     MMP XX is output
           (OP:CFGSTAT,MMP=0-XX)                (OP:CFGSTAT,MMP=1-XX)


     The 1260 page shows a summary status of the CLNKs for all
     equipped SMs (up to 192).
     If a CLNK is off normal, the appropriate SM number is
     backlighted.  If an SM is isolated, the SM number is backlighted
     and flashing (Figure .AW G249/).  For further information, enter
     1900,X to display the SM CLNK STATUS AND CONTROL page.  Pages
     1261-1264 are information only pages and should not be used for
     problem solving if an SM is backlighted.

     All available display commands can be entered from the 1260
     display page.
     The 1261 through 1264 display pages summarize all logical
     communication links to the SMs.
     The 1261 through 1264 displays for LOGICAL LINK MAPs 1 through 4
     are very similar. Page 1261 summarizes all logical communication
     links to SMs 1 through 48. Page 1262 summarizes all logical
     communication links to SMs 49 through 96. Page 1263 summarizes
     all logical communication links to SMs 97 through 144. Page 1264
     summarizes all logical communication links to SMs 145 through
     192.

     These pages (1261 through 1264) are information-only type pages.

     The links shown on the 1261 through 1264 pages are the logical
     communication links which 1900,X - SM X CLNKS displays the
     status of on a per-SM basis. The ONTC column is the ONTC the
     link is routed through, the MSGS column is the MSGS the link is
     routed through, and the MMP column shows the MMP type the link
     is routed through. A 0 in the MMP column means the MMP used
     works through the even time slots and a 1 in the MMP column
     means the MMP works through the odd time slots.

     In the Figure .AW G250/ Display Page 1261 example, no paths are shown
     for SM 6 which is isolated. Further information and maintenance
     commands for the links are found on the SM 6 CLNKS display.

     All available displays can be accessed from the 1261 through
     1264 pages.
     The 1271, 1272, 1273, and 1274 page displays provide summary
     status for routine exercises for the CM and the SMs as follow:

       o  1271 - SM 1 - 48 and CM REX SUMMARY

       o  1272 - SM 49 - 96 REX SUMMARY

       o  1273 - SM 97 - 144 REX SUMMARY

       o  1274 - SM 145 - 192 REX SUMMARY.

     The four REX SUMMARY pages are very similar. The first page,
     1271, provides REX summary status for the CM and for the first
     48 SMs. The second page, 1272, provides REX summary status for
     the next group of 48 SMs, SM 49 through 96.  The third page,
     1273, provides REX summary status for SMs 97 through 144.  The
     fourth page, 1274, provides REX summary status for SMs 145
     through 192.

     If an SM is equipped, the number for the SM appears on the
     appropriate REX SUMMARY page. If REX is not in progress or
     inhibited for one or more units or the entire SM, nothing more
     than the number is displayed. If REX is running on an SM, the
     status of IP is shown immediately to the right of the SM number;
     and further to the right, the type(s) of REX test(s) is
     displayed.  On color terminals, the indicator is black on green.
     If REX is inhibited for an SM, the status of INH appears
     immediately to the right of the SM number and the indicator for
     the SM is backlighted, black on white for black and white
     terminals, and blue on yellow for color terminals. The status of
     inhibit can mean that one or more units in the SM have been
     inhibited from running REX or that the whole SM is inhibited
     from running REX. Also, on Page 1010,X, the phrase SEE 1800 will
     appear (backlighted) in the RELATED PAGES box. On Page 114, the
     indicator for that SM will be backlighted; and on the
     appropriate 141, 142, 143, or 144 page, the indicator for that
     SM will be backlighted and the phrase INHIBITS will be written,
     unless a more critical condition exists.

     The three REX test types for an SM are as follows:

       o  DGN:  Full diagnostics. This results in a conditional
          restore request including the trouble location procedure
          (TLP) option.

       o  ELS:  Electric loop segregation. This tests customer lines
          to determine a suitable network balance necessary to reduce
          the amount of potential echoing in the transmission path.

       o  FAB:  Fabric exercise. This tests the operation of the
          gated diode crosspoints (GDX) in the line unit (LU)
          concentrator grid or grid board.

     For detailed status of SM REX schedules and any in progress
     units, 1280,X should be entered, where X is the SM number
     desired.

     For the CM, the appropriate REX types are as follows:

       o  DGN:  This is the same as for the SM.

       o  SWITCH:  Partial Diagnostic. This results in a soft switch
          of the PPC, the FPC, the CMP, and the ONTC. No diagnostics
          are executed.

     For detailed status of the CM REX schedule and any in progress
     units, enter 1290.

     The 1271 display page is the first of four REX Summary pages. In
     Figure .AW G251/, the summary for the CM shows that REX is in progress
     on some unit in the CM. The SM 2 has ELS and FAB in progress; SM
     4 has DGN and FAB inhibited; SM 7 has DGN in progress; SM 11 has
     DGN, ELS, and FAB inhibited; SM 20 has DGN inhibited, SM 24 has
     DGN and ELS in progress; and SM 48 has nothing inhibited or no
     test in progress.

     All available displays can be accessed from the 1271 through
     1274 display pages.
     The purpose of the 1280 page is to provide the status of REX in
     an SM on a per unit basis and to display the REX schedule for
     the SM.  Read the note under the MCC display on the previous
     page.
     The 1280 page shows all of the units equipped in the SM, for
     which it is being displayed, that REX will exercise.  Only one
     unit at a time may have REX in progress while any number of
     units at a time may have REX inhibited on those units.  If a
     unit shows the state of in progress (IP) or inhibited (INH), it
     reflects the state of DGN.  Both ELS and FAB do not specifically
     show up because they apply to the SM as a whole.

     The REX schedule displays the start time in hours and minutes
     and the duration of DGN, ELS, and FAB in hours.  It shows the
     setting of REX Verbose; Y if verbose is turned on, N if verbose
     is turned off.  For each day of the week, the schedule displays
     whether DGN, ELS, and FAB are scheduled to run for that day; F
     means full tests are scheduled and N means REX is not scheduled
     for that day on that SM.

     If REX is inhibited for the entire SM due to the input message
     INH:REX,SM=SM#, a note will appear at the upper right area of
     the page that says REX INHIBITED - SEE 1800 and it will be
     backlighted.

       Note:   If the module controller is an SMP20, the
               bootstrapper status is not displayed.  The SMP20
               processor is also referred to as the module
               controller/time slot interchange model 2 (MCTU2).
               For non-SMP20 SMs, the bootstrapper status will be
               displayed on the 1280 page display.

     Figure .AW G252/ is an example of the SM REX STATUS page.  In this
     display for SM 7, DGN starts at 12:30 a.m. (HRS=00, MINS=30) and
     runs for 2 hours.  The ELS starts at 2:30 a.m. (HRS=02, MINS=30)
     and runs for 2 hours.  FAB starts at 4:30 a.m. (HRS=04, MINS=30)
     and runs for 2 hours.  REX on line unit 0 is in progress and is
     inhibited on line unit 1.

     Commands are provided for executing DGN, ELS, or FAB REX and for
     outputting the status of REX for the SM for which the page is
     displayed.

     All available display commands can be entered from the 1280,X
     page.

     CMD   RESULT

     500   Execute (start) REX DGN
           (EXC:REX,SM=SM#,DGN)
     501   Execute (start) REX ELS
           (EXC:REX,SM=SM#,ELS)
     502   Execute (start) REX FAB
           (EXC:REX,SM=SM#,FAB)
     900   Output status of REX for the SM
           (OP:REX,SM=SM#)

     The purpose of the 1290 display page is to provide the status of
     REX for the CM and to display the REX schedule for the CM.
     The 1290 page shows the REX status for the ONTCs and the MSGSs.
     Only one unit will have REX in progress at a time, while any
     number of them may have REX inhibited.

     If a unit shows the state of in progress (IP), it reflects the
     state of DGN.  The 5ESS switch will cause the FPC, PPC, CMP, and
     ONTC to be soft switched but will not run any tests and will not
     cause any status to be displayed on the page.

     The REX schedule displays the start time in hours and minutes
     and the duration in hours. It shows the setting of REX Verbose,
     Y if verbose is turned on, N if verbose is turned off. For each
     day of the week, the schedule displays whether DGN is scheduled
     to run for that day; F means full diagnostic tests are
     scheduled, N means not scheduled, and P means partial test are
     scheduled (switch).

     If REX is inhibited for the entire CM due to the input message
     INH:REX,CM, a note will appear at the upper right area of the
     page that says REX INHIBITED - SEE 110 and it will be
     backlighted.

     Figure .AW G253/ shows REX in progress on MSGS 1. The schedule
     indicates that DGN is scheduled at half past midnight (HRS=00,
     MINS=30) and runs for 3 hours on Mondays, Wednesdays, and
     Fridays.  The REX verbose is turned on. On Saturday, a partial
     switch will be done.

     Commands are provided for executing full DGN exercises or
     partial DGN exercises (SWITCH) and for outputting the status of
     REX for the CM.

     All available displays can be accessed from the 1290 display
     page.

     CMD   RESULT

     500   Execute (start) full REX DGN
           (EXC:REX,CM,DGN)
     501   Execute (start) partial REX DGN
           (EXC:REX,CM,SWITCH)
     900   Output status of REX for the CM
           (OP:REX,CM)

     The purpose of the 131Y,X through 136Y,X pages is to show status
     for SLC 96 Carrier RTs, if equipped.
     The displays for RT1 through RT6 are very similar.

     There are several possible configurations for the RT pages. A
     typical configuration is shown in the 131Y,X - SM X - DCLU Y -
     RT1 example.

     If an off-normal condition occurs in any of the SDFIs, the
     corresponding SDFI indicator will be backlighted and have text
     written in. To the right of SDFI in the SDFI indicators is the
     SDFI number that indicator represents. Its associated facility
     is below the SDFI indicator box and will be backlighted if off-
     normal.

     Each facility (A, B, C, or D) has an associated SHELF indicator.
     If there is an off-normal condition in a shelf, the SHELF
     indicator will be backlighted.

     If a SHELF or SHELF GROUP is in an off-normal state, the RT
     indicator on the 115Y page will be backlighted, as will the DCLU
     indicator on the 1010 page, and the SM indicator on the 114
     page.  On the appropriate 141, 142, 143, or 144 page, the
     indicator for that SM will be backlighted and CKT OOS will be
     written.  In the SUMMARY STATUS AREA, the SM indicator and the
     alarm level will backlight.

     Facilities A and C each have a SHELF GROUP indicator. They can
     be configured with either their SHELF or SHELF GROUP, unless
     facility B or D are equipped. If B is equipped, facility A must
     be configured with a shelf. If facility D is equipped, facility
     C must be configured with a shelf.

     If a facility is off-normal (and all SDFI and SHELF indicators
     are normal), then the RT indicator on the 115Y page will be
     backlighted, as will the DCLU indicator on the 1010 page. If the
     FACOFFN option is turned off (CLR:S96,FACOFFN), the SM indicator
     on the 114 page will remain normal, as will the SM indicator on
     the 141, 142, 143, or 144 page.

     When facility P is replacing a facility, then the RT indicator
     on the 115Y page will be backlighted, as will the DCLU indicator
     on the 1010 page.  If the FACOFFN option is turned off
     (CLR:S96,FACOFFN), the SM indicator on the 114 page will remain
     normal, as will the SM indicator on the 141, 142, 143, or 144
     page.

     If the FACOFFN option is turned on (SET:S96,FACOFFN) and either
     an FAC is off-normal or facility P is replacing a facility, then
     the SM indicator on the 114 page will be backlighted, as will
     the SM indicator on the 141, 142, 143, or 144 page with an
     appropriate descriptive phrase (CKT OOS or SLC PLS).  In the
     SUMMARY STATUS AREA, the SM indicator and the alarm level will
     backlight.

     Facility P is a protection facility. If one of the equipped
     facilities is OOS but the shelf or shelf group is ACT, facility
     P will replace the OOS facility.  It may also replace a facility
     that is ACT (if there is a manual request or a problem at the
     RT).  Facility P is optional.

     To the left of shelf A is the PWR/MISC alarm indicator.  If
     there is a Power/Miscellaneous alarm at the RT, the indicator
     will be backlighted and either MJ (major) or MN (minor) will
     appear in the indicator.  The RT indicator on the 115Y page will
     be backlighted, as will the DCLU indicator on the 1010 page, and
     the SM indicator on the 114 page.  On the appropriate 141, 142,
     143, or 144 page, the indicator for that SM will be backlighted
     and BLDG/PWR will be written.  In the SUMMARY STATUS AREA, the
     SM indicator and the alarm level will backlight.

     The subscriber loop carrier identification number (SID) is
     displayed underneath the SHELF A indicator.

     Figure .AW G254/ shows RT1 has SDFI 4 out of service (OOS).  It is
     associated with facility B which is out-of-service family (OOSF)
     of equipment.  The SDFI 6 is OOS and its associated facility (C)
     and shelf group (CD) are OOSF. The protection facility (P) has
     taken over for facility B.

     There are no commands for the 131Y,X - 136Y,X pages, but all
     available displays can be accessed from this page.
     The purpose of the 1400,X page is to display building/power
     alarm status and assignment and the alarm retire mode.  It also
     provides inhibit/allow controls for building alarms and sets the
     alarm retire mode in the remote switching module (RSM).  In
     addition, the 1400,X page displays status and provides controls
     in the optically remoted module (ORM).
     When 1400,X is poked, the page display reflects either RSM data
     or ORM data.  If ``X'' is the number of an RSM, then RSM data is
     shown.  Conversely, if ``X'' is the number of an ORM, then ORM
     data is shown.

     The 1400,X page has three separate and distinct versions,
     depending on the hardware equipage in the RSM/ORM.  Version one
     (Figure .AW G255/) is displayed if 1400 is requested for an RSM/ORM
     equipped with both scan and distribute boards for the BLDG/PWR
     alarms and the alarm and status circuit (ASC).

     Version two (Figure .AW G256/) is displayed if 1400 is requested for
     an RSM/ORM equipped with a remote alarm unit and a metallic
     service unit or modular metallic service unit.  Version two is
     also displayed if 1400 is requested for an RSM/ORM equipped with
     scan boards for the BLDG/PWR Alarms but not the ASC.

     Version three (Figure .AW G257/) is displayed if 1400 is requested for
     an RSM/ORM equipped with an ASC but not the scan boards for the
     BLDG/PWR Alarms.

     If none of these hardware requirements are met, the page is not
     displayed if requested, and no BLDG/PWR ALARM indicators will be
     displayed on the 1010 page. If no RSM/ORM at the site meets
     these hardware requirements, no BLDG/PWR Alarm indicator will
     appear on the 1600 page.

     Building alarms 02-31 and their alarm levels are office
     assignable.  Doors, windows, humidity, etc., are typical types
     of applications.  The alarm level and text in these indicators
     are initially filled in using recent change and verify.  Once
     these indicators are filled in, they are protected from loss if
     the system is booted.

     A normal alarm indicator is displayed in normal video (white on
     black).

     Except for the FIRE indicator, when an alarm condition is
     present and it is not inhibited, the respective display
     indicator will backlight.  The FIRE indicator flashes in
     addition to becoming backlighted.  On Display Page 114 -
     EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be
     backlighted and flashing, and on the appropriate 141, 142, 143,
     or 144 page, the indicator for that SM will be backlighted and
     flashing, and the phrase CRIT ALM will be written.  In the
     SUMMARY STATUS AREA, the SM critical indicator will start
     flashing, and the alarm level indicator CRITICAL will be
     backlighted.  Also, an audible alarm will be sounded.  For alarm
     indicators other than FIRE, on Page 114, the indicator for that
     SM will be backlighted; and on the appropriate 141, 142, 143, or
     144 page, the indicator for that SM will be backlighted, and a
     descriptive phrase of the condition will be written unless a
     more critical condition exists. In the SUMMARY STATUS AREA, the
     SM indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if
     applicable, will be backlighted.

     When an alarm is inhibited, the respective indicator will have
     ``INH'' written in and will be backlighted; SM in the SUMMARY
     STATUS AREA will also backlight.  Building alarms 02-31 are the
     only alarms on the 1400 page that can be inhibited by the craft.

     The alarm retire mode indicator, if present, reflects the mode
     of the alarm retire function of the alarm lights and audibles at
     the RSM/ORM sites. If set to automatic, the audible alarms at
     the RSM site and alarm lights on the alarm and status panel
     retire automatically after a certain time period specified by an
     office definable parameter in the ODD for that RSM/ORM. If set
     to manual, the craft is required to manually retire the alarms
     by pressing the ALM RETIRE button on the RSM/ORM alarm and
     status panel.

     Figure .AW G255/ is an example of version one where an ORM is equipped
     with both scan and distribute boards for the BLDG/PWR alarms and
     the alarm and status circuit (ASC).

     In this example, indicator 05 shows a major alarm caused by a
     failure in the air conditioning system.  Indicator COM PWR shows
     that there is a commercial power failure.

     Figure .AW G256/ shows an example of version two in which an RSM is
     equipped only with the Building/Power Alarms (or the RSM is an
     earlier vintage equipped with a Remote Alarm Unit).  In this
     example, building alarm 9 is inhibited.

     Figure .AW G257/ is an example of version three where an RSM is
     equipped with the alarm and status panel but not equipped with
     scan boards for building/power alarms. In this example, the
     alarm retire mode is set to automatic.

     Commands are provided to inhibit/allow building alarms 02-31 and
     to set the ALARM RETIRE mode to automatic or manual.

     Also, all available pages can be accessed from the 1400 display
     page.

     CMD   RESULT

     6XX   RSM/ORM Building Alarm XX is inhibited
           (INH:ALM,RBPSC=XX,SM=SM#)
     7XX   RSM/ORM Building Alarm XX is allowed
           (ALW:ALM,RBPSC=XX,SM=SM#)
     800   Sets the Alarm Retire Mode to automatic
           (SET:ALMMDE=AUTO, RBPSC,SM=SM#)
     801   Sets the Alarm Retire Mode to manual
           (SET:ALMMDE=MAN,RBPSC,SM=SM#)

     The 1420 page display provides the status of the remote
     integrated services line unit (RISLU) site alarms.
     A maximum of eight RISLUs can be equipped per RISLU site.

     One RISLU per site is equipped with a remote alarm section
     (RAS).  Each RAS has 32 miscellaneous scan points, where up to
     30 of these scan points are office definable (02-31).  The first
     two scan point definitions are fixed (00 = Fire Alarm, and 01 =
     Fire Alarm Trouble).  Also, these scan points cannot be
     inhibited.

     In the RETIRE MODE indicator field, the term MANUAL appears when
     the poke command 801 is entered; and the term AUTOMATIC appears
     when the poke command 800 is entered.

     Figure .AW G258/ shows an example of the 1420 page display.

     The following commands inhibit, allow, and retire RISLU
     building/power alarms:

     CMD   RESULT

     6XX   Inhibit scan point XX (INH:ALM,RIBMSC=XX,SITE=a)
     7XX   Allow scan point XX (ALW:ALM,RIBMSC=XX,SITE=a)
     800   Scan point alarms retire automatically (SET:ALMMDE=AUTO,RAS,SITE=a)
     801   Scan point alarms require manual action to be retired
           (SET:ALMMDE=MAN,RAS,SITE=a)

     The 145Y page display [where ``Y'' is equal to the digital line
     trunk unit (DLTU) number (0 or 1)] provides the status of remote
     and host digital facility interfaces (DFI) and the status of the
     remote clocks.
     One RISLU digital line trunk unit (DLTU) can host two RISLUs.

     The ``*'' (located to the left of the first and third lines of
     data in the box on the right half of this page face) indicates
     these host DFIs are controlling the active RRCLK on the RISLU.
     Switching module 115 is hosting two RISLUs; therefore, two
     control facilities are indicated.

     A maximum of 16 host/remote RISLU DFI pairs can be equipped per
     RISLU DLTU.

     The 1451 display page can be accessed from the 1000 SM PAGE
     INDEX display page.  Also, the 170Y,X ISLU Y display page can be
     accessed from this display page.

     Figure .AW G259/ shows an example of the 1451 display page.

     The following commands can be used to remove, restore, and
     diagnose the RISLU clock and the host DFI.  All available
     displays can be accessed from this page.

     CMD    RESULT

     2YX    Remove RRCLK Y RISLU X (RMV:RRCLK=a-x-y, SCREEN=b)
     22XX   Remove DFIH XX (RMV:OF1H=a-b-XX)
     3YX    Restore RRCLK Y RISLU X (RST=RRCLK=a-x-y, SCREEN=b)
     32XX   Restore DFIH XX (RST=DF1H=a-b-xx)
     5YX    Diagnose RRCLK Y RISLU X (DGN=RRCXLK=a-x-y,RAW,TLP)
     52XX   Diagnose DFIH XX (DGN=DF1H=a-b-y,RAW,TLP)
     40X    Switch RRCLK RISLU X (SW=RRCLK=a-x, SCREEN=b)
     170Y   Display ISLU NETWORK Y

       Note:   The term basic rate interface (BRI) means the same
               thing as digital subscriber line (DSL).  This
               document uses DSL, because the 1460 page display
               does not identify BRI.

     The 1460 page display provides summary status of the Operator
     Services Position System (OSPS) data links on a per-SM basis.
     The 1460 page display is not normally accessed when DSLs are IN
     SERVICE.  Usually the 1460 page is accessed because of the
     following:

       o  DSL MAJOR or DSL MINOR alarm is indicated in the SM X
          STATUS indicator box on the 1010-SM X LSM STATUS page
          display.

       o  SEE 1460 is present in the RELATED PAGES box on the 1010-SM
          X LSM STATUS page.

     This page display provides the following:

       o  Which data link types are equipped in an SM.

            Note:   If no ports are equipped for a specific data
                    link in the SM, then no data link block
                    appears on the 1460 page display.

       o  Which data link types have ports OOS and the relative
          seriousness of the fault.  Each data link type has an
          associated indicator block.  If a block is backlighted red,
          a minor alarm is indicated; also, the term DSL_MINOR is
          displayed in the SM XXX STATUS indicator block.  If a block
          is flashing from red to white, a major alarm is indicated;
          also, the term DSL_MAJOR is displayed in the SM XXX STATUS
          indicator block.

       o  Which page display gives more details (for example,
          equipment numbers or states) concerning each data link type
          equipped in an SM.  On the 1460 page display (Figure .AW G260/),
          one of the data links represented is DAS/C with the
          associated page to see for more details (for example, SEE
          147000).  Where the first two zeros = the data link type
          (service class) and the last zero indicates the screen
          number of the specific service class.

     There are two types of data links (service classes) - simplex
     and duplex.  The following are simplex data links:

       Note:   The XDB data link is the only link that can be
               equipped with more than 16 ports.

       o  HOBICV

       o  HOBIS

       o  HOBICR

       o  AQ

       o  XDB.

     The following are duplex data links:

       o  DAS/C

       o  RAS

       o  RTRS

       o  MISLNK.

     The external information system (EIS) data link introduced in
     5E6 is an N+K data link group, where N+K is defined in the
     alarms section.

     Major and Minor Alarms

     For simplex data links, if more than 50 percent of the ports
     associated to a specific data link (per-SM) are OOS (out of
     service), a major alarm occurs.

     For simplex data links, if one but no more than 50 percent of
     the ports associated to the data link are OOS, a minor alarm
     occurs.

       Note:   If exactly 50 percent of the ports associated to a
               specific data link are OOS, a minor alarm occurs.

     For the duplex DAS/C and RTRS data links, the DAS and RTRS data
     links can be equipped with a maximum of two ports each.  If only
     one port is assigned to DAS/C or RTRS and the port is OOS, a
     major alarm occurs.  If two ports are assigned to DAS/C or RTRS
     and one port is OOS, a minor alarm occurs; and if both ports are
     OOS, a major alarm occurs.

     For the duplex RAS data link, a maximum of eight RISLUs can be
     equipped with RAS (that is, on a per-SM basis).  Each RISLU site
     can be assigned up to a maximum of two RAS data links,
     therefore, providing a maximum of 16 data links per SM.  A minor
     alarm occurs when at least one RAS data link is OOS, but all of
     the RISLU sites have at least one RAS link in service.  A major
     alarm occurs when at least one site has all RAS links OOS.  Some
     RISLU sites may only be equipped with one RAS link; when or if
     this link is OOS, a major alarm occurs.

     EIS Alarm Strategy

     The following terminology is used to define EIS data link alarm
     strategy for an SM:

     The set of EIS data links equipped on a specific SM and
     connected to a specific EIS is referred to as an ``EIS Call
     Processing Data link (CPDL) group.''  Each EIS CPDL group
     consists of (N+K) data links, where N and K are specified
     independently for each EIS CPDL group:

       1. N, indicating the minimum number of CPDLs that are needed
          to support the message traffic during the busy hour for the
          EIS CPDL group.

       2. K, the number of CPDLs providing surplus traffic capacity
          for the EIS CPDL group.

     The EIS data link summary status for an SM is defined as
     follows:

       o  DSL_NORMAL:  All EIS data links on the SM are in-service.

       o  DSL_MINOR:  At least one EIS data link equipped on the SM
          is out of service, but each EIS CPDL group has at least N
          EIS data links in-service.

       o  DSL_MAJOR:  At least one EIS CPDL group has fewer than N
          EIS data links in service.

     Figure .AW G260/ shows an example of the 1460 page display.

     Any available paging commands can be entered from this display.
     The 147YYZ page display provides the global port names, the DSL
     names, and the DSL status for all of the port assigned the data
     link type (for example, XDB).
     If you have not read the information concerning the 1460 page
     display, then do so, because it has information that is
     associated to the 147YYZ page display.

     The GLOBAL PORT NAME field contains the channel type (B1 or D)
     followed by the LCEN.  The LCEN (for example, 17-4-07-02)
     represents the following: 17 = SM, 4 = ISLU or RISLU, 07 = line
     group controller, and 02 = line card.

     The DSL NAME field contains the data link type (for example,
     XDB), external name identifiers, and associated link numbers.

     The DSL STATUS field contains the status of the DSLs.

     The SM XXX STAT indicator block provides the relative
     seriousness of the fault (major or minor alarm).

     The SCREEN Z SUMMARY indicator block identifies the number of
     screens available to be displayed.  More importantly, if any of
     the screen numbers are backlighted red, this means that one or
     more of the ports on that specific screen are OOS.

     The user can identify which screen of the data link is being
     reviewed by looking at the left-hand side of the 147YYZ page
     display under the SCREEN Z SUMMARY indicator.

     Figure .AW G261/ illustrates the XDB data link version of the 147YYZ
     page display [where ``YY'' equals the data link type (service
     class) and ``Z'' equals the screen of the specific data link
     type].  The XDB data link type is the only type that can be
     equipped with more than 16 ports.

     The 14707Z poke command gives the user the ability to choose the
     screen to be displayed (where ``Z'' = the screen number).  Also,
     any poke command can be entered from this display.
     The 1480,X page display provides the status of application
     processor (AP) digital subscriber lines (DSL) and associated
     session status.
     The AP LINK indicator field illustrates the AP index number and
     AP link number, for example, AP 04-01 (where 04 = AP index
     number and 01 = AP link number).

     The DSL LCEN indicator field illustrates the line unit (LU),
     line group controller (LGC), and line card (LC) numbers.  An
     example is, 001-0-12-24 [where 001 = Switch Module number, 0 =
     Line Unit number, 12 = Line Group number, and 24 = Line Card
     number].

     If all of the data links associated to an AP are out of service
     (OOS), the term DSL MAJOR appears in the SM XXX STATUS indicator
     block.  This means a major alarm has occurred, provided that the
     alarm request for the AP has been set to Y (YES) via RC/V view
     24.7.  If one or more but not all data links for an AP are OOS,
     the term DSL MINOR appears in the SM XXX STATUS indicator block.
     This means a minor alarm has occurred, provided that the alarm
     request for the AP has been set to Y (YES) via RC/V view 24.7.

     In the 5E7 software release, another alarm level, CRITICAL, is
     added, provided that the SM is attached to an E911 AP.  The AP
     data link alarm is elevated one level higher for the E911 AP
     links.  If all links for a given AP are OOS and the AP is an
     E911 AP, the term E911_CRIT will appear in the SM XXX STATUS
     box.  If at least one but not all links for a given AP are OOS
     and the AP is E911 AP, the term DSL MAJOR will appear in the SM
     XXX STATUS box.

     The SESSION indicator field illustrates the chain of events that
     occur when the AP data links are being assigned.  When this
     field contains DISC, the DSL is OOS, or the AP data link is not
     assigned.  When INIT appears in the SESSION field, level 3
     implementation has been completed; and when the implementation
     of the data link is complete (that is, level 4), the SESSION
     field contains the term CONN.  Also, the SESSION field can
     contain the term MAINT.  This occurs when the AP has requested a
     maintenance exercise.

     Figure .AW G262/ shows an example of the 1480,X page display.

     All available page display commands can be entered from the 1480
     page.

       CMD     RESULT

     200,X,Y   APX DATA LINK Y is removed (RMV:DATALINK,AP=a-b)
     300,X,Y   APX DATALINK Y is restored (RST:DATALINK,AP=a-b)

     The purpose of the 1600,SZ page is to show the status of all of
     the RSMs at a site and their associated HSMs and
     interconnections.
     The 1600,SZ page shows the RSMs that are located at a particular
     site. A site may have from one to four RSMs located at it. Each
     RSM may have a separate HSM hosting it or one HSM may host more
     than one of the RSMs up to hosting all four RSMs.

     The SITE STATUS page can be requested by craft using the SM
     number of any RSM at the site or by using the corresponding site
     number in 1600,SZ (where ``S'' is actually typed as part of the
     command and ``Z'' = site number).  The integrity of craft access
     to the page is enhanced since the page is available if craft can
     communicate to any of the RSMs at the site. The accuracy of the
     information shown on the page is not affected by failures in the
     T1 communication links unless, in addition, the RSMs become
     separated from each other. If all T1 communication links to the
     site fail, the page is not available.

     This display graphically shows the intercommunication link (ICL)
     groups between the RSMs; and on the right side of the page, the
     status of the ICL groups is displayed.

     The title of this page contains the number assigned to a site
     and the actual name of the site.

     An ICL is a single link between a pair of RSMs. The status
     displayed on the right, therefore, is a summary of each link
     group. The possible states a link group may have are as follows:

       o  ACT (Active):  All ICLs of the link group are in service.

       o  DGR  (Degraded):  At least one, but not all ICLs of the
          link group is out of service.

       o  MSEP (Manually Separated):  All ICLs of the link group are
          out of service due to a manual craft request.

       o  SEP (Separated):  All ICLs of the link group are out of
          service for any reason other than a craft request.

     Next to each RSM indicator is the timing mode indicator for that
     RSM. This indicator displays the means by which the RSM derives
     its timing. The RSMs will take their timing from whichever mode
     is the most stable. The possible timing modes are as follows:

       o  T1: The RSM is getting its timing over the T1 umbilical
          from the HSM.

       o  RCLK: This is the normal mode for the RSM which has the
          RCLK equipped as long as the RCLK is the most stable of the
          modes.

       o  ICL: This means that the RSM is getting its timing from
          another RSM over the ICL.

       o  FI: The RSM is isolated and separated (no T1 and no ICLs)
          and is generating its timing internally.

     If a site is equipped with building and power alarms, an
     indicator will be displayed on the left side of the page showing
     the BLDG/PWR ALARM status and to which RSM it is connected
     (Figure .AW G264/).

     If a site is equipped with a remote clock unit, an indicator
     will be displayed on the left side of the page showing the RCLK
     mode and to which RSM it is connected (Figure .AW G264/).

     Figure .AW G263/ is an example of the 1600,SZ page which shows status
     of SITE 2. SITE 2 has three RSMs which are hosted by two
     different HSMs. The Inter-Communication Links are all active.
     The RSM 192 is getting its timing from HSM 12 over the T1
     umbilical, and RSM 5 and 11 are getting their timing from RSM
     192.

     Figure .AW G264/ is an example of the SITE STATUS page which shows a
     site with both the remote clock and building/power alarms
     equipped. In this example, there is a building/power alarm
     active. Also, RSM 48 has an RCL circuit out of service, which
     caused the three ICL groups to it to be degraded. The RSM 48 is
     getting its timing from the remote clock which is in normal mode
     and the other three RSMs are ICL based, getting their timing
     from RSM 48 over the ICLs.

     All available displays can be accessed from the 1600 display
     page.
     The 1610 page display provides a list of remote switching
     modules and associated site numbers.
     The 1610 is an information only page which shows all remote
     sites associated with an office.

     The status of remote switching modules can be verified by typing
     1600,SZ (the ``S'' is actually typed as part of the command and
     ``Z'' = site number).

     Figure .AW G265/ is an example of the 1610 page.

     All available MCC page display commands can be entered from the
     1610 page display.
     The 1615 page display provides a list of the ORMs and their
     associated site numbers.
     The status of the ORMs can be verified by typing 1010,SM (where
     SM = SM number).

     Figure .AW G266/ is an example of the 1615 page.

     In the message 002 011 SITE 2 - ORM11 shown, 002: is the
     ORM site number, 011: is the SM number, and SITE 2 - ORM11:
     is the site name.

     All available MCC page display commands can be entered from the
     1615 page display.
     The 1620 page display provides the connections between the SM
     and RISLU site(s) and the status of each RISLU site(s).
     The BLDG/PWR ALARMS box of this page identifies the
     building/power alarm summary status and indicates which RISLU is
     hosting these alarms.

     The 1620 page display can be accessed from either the 1000 SM
     PAGE INDEX or 1630 RISLU SITE INDEX pages.

     Up to eight SMs and RISLUs can be displayed from the 1620 page.

     Figure .AW G267/ shows an example of the 1620 page display.

     The status of the building/power alarms for a particular RISLU
     site can be displayed by entering 1420,SZ, where ``S'' equals
     the actual letter ``S'' and ``Z'' equals the RISLU site number.
     Also, the associated ISLU network pages can be accessed by
     entering 170Y,X, result -- SM X ISLU Y NETWORK.
     The 1630 page display provides the list of RISLU sites on the
     SM.
     The 1630 page lists the number and name of each RISLU site.  The
     status of each RISLU site can be displayed from the 1630 page
     display, by entering 1620,SZ (where Z=RISLU site number) (the
     ``S'' is actually typed as part of the command).  The 1630 page
     display can be accessed from the 1000 SM PAGE INDEX display
     page.

     Figure .AW G268/ shows an example of the 1630 page.

     Any available paging commands can be entered from this display.
     The 170Y,X page display provides the ISLUCCs and ISLUCDs status
     and a summary status for the LG.
     The ISLU network display page simultaneously shows the state of
     both ISLUCCs and both ISLUCDs and a status summary of the LGs.
     The status of the ISLUCCs is noted on the MCC as duplex SM
     peripheral controllers.  When the ISLUCDs are running in a load
     shared configuration, the status indication for the CDs on the
     MCC display is ACTIVE-MAJOR/ACTIVE-MINOR.  If the CDs are not to
     run in a load shared configuration, the status indication for
     the CDs will be ACTIVE/STANDBY.  When load sharing is run, a
     request to conditionally remove a CD is displayed as ``CAMP''
     until all calls routed through the CD are terminated.  Then the
     CD is marked ``OOS.'' If the remove should time out or be
     stopped before all calls are terminated, the CD is marked
     ``ACT'' with no call loss.  When any LC or LGC is removed from
     service, the LG status summary displays the trouble by
     backlighting the unit number of the LG in which the OOS unit
     resides.

     The 170Y,X page display can be accessed from the 1000-SM page
     index and the 1620,SZ RISLU SITE STATUS pages.

     Figure .AW G269/ shows an example of the 170Y,X page display.

     Commands are provided to remove, restore, diagnose, switch the
     clock, and display ISLU LG page display concerning the ISLU
     network.

      CMD     RESULT

      20X     Removes ISLUCC X
      21X     Removes ISLUCD X
      30X     Restores ISLUCC X
      31X     Restores ISLUCD X
      50X     Diagnoses ISLUCC X
      51X     Diagnoses ISLUCD X
      40X     Switches ISLUCC X
      41X     Switches ISLUCD X
     170YZZ   Displays ISLU Y LG ZZ

     The 170Y,X page display provides information concerning the ISLU
     network and status of DFIs on the DLTU.
     The 170Y,X page display can be accessed from either the 1620-
     RISLU SITE X STATUS or the 1451-SM X-RISLU DLTU page.

     The 1701 page display indicates where the ISLU is located.  In
     this case, the figure illustrates that the ISLU is remoted to
     SITE 500.  This means that the ISLU is really an RISLU because
     the ISLU is remote.  The SITE number is indicated just below the
     SM STATUS box.

       Note:   This site is the site of the SM hosting the RISLU,
               not the RISLU site.

     A fan and fuse alarms indicator box gives the status of the
     alarms for the RISLU network.

     A duplex configuration exists for ISLUCC and ISLUCD.  That is,
     when ISLUCC 0 is active then ISLUCC 1 is on standby (backup),
     and the same is true for ISLUCD 0 and 1.  Each LG (maximum of
     16) can be connected to an ISLUCD circuit that is controlled by
     the ISLUCC.

     Figure .AW G270/ shows an example of the 170Y,X page display.

     Commands are provided to remove, restore, and diagnose the ISLU
     CC and CD circuits.  Any available paging commands can be
     entered from this page.

      CMD     RESULT

      20X     ISLUCC X is removed
      21X     ISLUCD X is removed
      30X     ISLUCC X is restored
      31X     ISLUCD X is restored
      40X     ISLUCC X is switched
      41X     ISLUCD X is switched
      50X     ISLUCC X is diagnosed
      51X     ISLUCD X is diagnosed
      145Y    RISLU DLTU Y is displayed
     170YXX   ISLU Y LG XX can be displayed
      171Y    ISLU Y SG XX (0 & 1) can be displayed

     The 170YZZ page display provides the LGC status and each LC
     status and type for the LG of the ISLU network.
     The ISLU LG display pages (one per LG) display the LGC status
     and individual LC status and type.  The data of each of the ISLU
     LG pages supplies the LG status entry in the summary of the ISLU
     Network display.  The possible states of the LGC and LCs will be
     ACT, CAMP, OOS, OOSFE, GROW, and UNEQ.  A new state customer
     deny (CDNY) applies for the LGC.  Two new states, spare (SPR)
     and designated spare (DSPR) apply for the LC.  When the LGC is
     unequipped, growing, or OOS, the LCs can be of the same state or
     OOSFE.  A request to conditionally remove an LGC is displayed as
     CAMP until all LCs can terminate and be marked OOS.  Once all
     the LCs are removed and marked OOSFE, the LGC is removed as well
     and marked OOS.  If the remove should time out or be stopped
     before all the LCs and LGC are removed, the LGC is marked CDNY.
     A request to conditionally remove an LC is displayed as CAMP
     until the LC call is terminated, upon which, the LC is marked
     OOS.  If the remove should time out or be stopped before the
     call is terminated, the LC is marked as before the remove
     request, active.  If any portion of the LCs or the LGC is OOS,
     the trouble is reflected on the LG status summary of the ISLU
     Network display by backlighting the unit number of the LG.

     The appropriate peripheral status block of the SM on the SM
     STATUS page is marked with the ISLU.  When any portion of the
     ISLU is OOS, the block is backlighted.  If the status reported
     on the SM status page or on any of the ISLU MCC display pages
     change while being displayed, the appropriate indicators are
     updated with the changed status.

     The 170YZZ page display can be accessed from the 170Y ISLU
     NETWORK page display.  An example of the 170YZZ page is shown in
     Figure .AW G271/.  Included in this example are the ANSI(R)
     U-Line Cards (AULC) and AULC spare (AUSP).

     Commands are provided to remove, restore, and diagnose the
     ISLULGCs and ISLULCs.  Any available paging commands can be
     entered from this page.

     CMD    RESULT

     200    Removes ISLULGC (RMV=ISLULGC=a-b-c)
     21XX   Removes ISLULC XX (RMV=ISLULC=a-b-c-XX)
     300    Restores ISLULGC (RST=ISLULGC=a-b-c)
     31XX   Restores ISLULC XX (RST=ISLULC=a-b-c-XX)
     500    Diagnoses ISLULGC (DGN=ISLULGC=a-b-c,RAW,TLP)
     51XX   Diagnoses ISLULC XX (DGN=ISLULC=a-b-c,RAW,TLP)

     The 171Y,X page display provides status and menu selection for
     the maintenance actions of the ISLUMAN, ISLURG, and ISLUHLSC.
     The last digit of the page number indicates the ISLU number (for
     example, 1712).  The ISLU numbers range from 1710 through 1717.

     This page (one per ISLU) displays the status of each ISLUHLSC,
     ISLUMAN, and ISLURG in both SGs 0 and 1.  The possible states of
     these indicators are ACT, CAMP, OOS, OOSFE, DGR, GROW, and UNEQ.
     When any of the circuits in an ISLU SG are in an off-normal
     state, the associated SG summary status indicator for that SG is
     backlighted.

     The 171Y,X page can be accessed from the 170Y - SM ISLU NETWORK
     page display.

     Figure .AW G272/ shows an example of the 171Y,X page display.

     Commands are provided to remove, restore, and diagnose the
     ISLUMAN, ISLUHLSC, and ISLURG of the SG.  Also, the ISLU Line
     Group page display can be requested.  Any available paging
     commands can be entered from this page.

      CMD     RESULT

      20XY    Removes ISLUMAN Y SG X (RMV=ISLUMAN=a-b-x-y)
      21XY    Removes ISLUHLSC Y SG X (RMV=ISLUHLSC=a-b-x-y)
      22X     Removes ISLURG SG X (RMV=ISLURG=a-b-x)
      30XY    Restores ISLUMAN Y SG X (RST=ISLUMAN=a-b-x-y)
      31XY    Restores ISLUHLSC Y SG X (RST=ISLUHLSC=a-b-x-y)
      32X     Restores ISLURG SG X (RST=ISLURG=a-b-x)
      50XY    Diagnoses ISLUMAN Y SG X (DGN=ISLUMAN=a-b-x-y,RAW,TLP)
      51XY    Diagnoses ISLUHLSC Y SG X (DGN=ISLUHLSC=a-b-x-y,RAW,TLP)
      52X     Diagnoses ISLURG SG X (DGN=ISLURG=a-b-x)
     170YZZ   Displays ISLU Y LG ZZ

     The 1800,X page provides inhibit and recovery status and control
     information for SM X.  It functions like an emergency action
     interface for the switching module (SM).
     When an inhibit is requested, the top third of the associated
     indicator will be backlighted to the INHIBIT state, and the text
     INH will appear in the corresponding box. When the inhibit is
     actually activated, the rest of the associated indicator will be
     backlighted to the INHIBIT state. On Page 114 - EQUIPPED SM
     STATUS SUMMARY, the indicator for that SM will be backlighted.
     On the appropriate 141, 142, 143, or 144 page, the indicator for
     that SM will be backlighted, and the phrase INHIBITS will be
     written unless a more critical condition exists. In the SUMMARY
     STATUS AREA, the SM critical indicator will be backlighted.

     Some of the boxes on the 1800,X page have numbers at the bottom
     of the box. These numbers show what commands are available from
     the display. For example, at the bottom of Box 02 the numbers
     ``6 7 9'' appear. The ``6'' means this item can be inhibited by
     entering  602, the ``7'' means it can be allowed by entering
     702, and the ``9'' means output is available with 902.  On color
     MCC terminals, there is also color mapping from the commands
     shown on the left of the display to the numbers in the boxes.

     In addition to the inhibit status indicators, there are
     indicators for the status of the module controller time slot
     interchangers (MCTSI) 0 and 1. When the MCTSIs are functioning
     normally, the active MCTSI is marked active (ACT). If an MCTSI
     is active forced, it is shown as ACTF and the other MCTSI is
     marked unavailable (UNAV). The conditions standby and out of
     service also apply to this display. During an initialization,
     the status of the inactive MCTSI cannot be precisely determined
     and the display will be blanked.

     There is also an indicator for the state of the mate memory.
     The possible states for the mate memory indicator are as
     follows:

       o  STANDBY: Mate memory has been updated.

       o  UPDATING: Mate memory update is in progress.

       o  OOD: Mate memory is out of date.

       o  PUMPED: Mate memory has been off-line pumped.

     During an initialization, the status of the mate memory cannot
     be precisely determined and the display will be blanked.  The
     lower area of the SM STAT indicator is for listing special
     abnormal conditions in the SM. The possible conditions shown in
     this area are as follows: GEN DIFF, ISOLATED, COMMLOST, SPEC
     GROW, STNDALONE, INIT PEND, and HASH ERR.
     This section describes the individual indicators and their
     behavior.

     Box 00 Routine Audits

     This indicator shows if the automatic execution of the SM audit
     cycle is inhibited.

     Entering the 600 command generates the command
     INH:AUD=CYCLE,SM=X and causes the top line of the indicator to
     be backlighted and the text INH to be written. This request is
     phase-protected. Single audits can also be inhibited via input
     messages, but they are not phase-protected.

     When the request is recorded, the description area of the box is
     backlighted. This area is backlighted if one or more of the SM
     audits are inhibited.

     Entering the command 700 generates the command
     ALW:AUD=CYCLE,SM=X and causes the indicator to return to normal
     video.

     The command 900 can be entered to get a ROP listing of routine
     audit status for the SM. This command generates the message
     OP:STATUS=ALL,AUD,SM=X.

     Box 01 Auto Pump

     When the 601 command is entered, it generates the command
     INH:PUMP,SM=X. This inhibits the automatic pump of the SM on a
     major initialization (except UNIX RTR system level D4). This
     inhibit is phase-protected.

     The 701 command generates ALW:PUMP,SM=X. This command must be
     entered to cancel the inhibit.

     Box 02 Routine Exercises

     This indicator shows if any or all of the routine exercises
     (other than unit exercises) in the SM are inhibited.

     Entering the command 602 generates the message INH:REX,SM=X.
     Entering the command 702 generates the message ALW:REX,SM=X. To
     print a status listing of routine exercises at the ROP, enter
     the 902 command (OP:REXINH,SM=X).

     Box 03 Manually Isolate

     When the 403 command is entered, it generates the message
     SET:ISOL,SM=X. This configures CLNK hardware to remove any level
     2 protocol or active links from service. The removal is
     unconditional, and the SM will remain isolated until the 503
     command is entered which generates the message CLR:ISOL,SM=X.

     Box 04 Software Checks

     This indicator reflects whether or not the AM application
     software checks are inhibited. If any software checks have been
     inhibited, the description section is backlighted.

     The command 604 generates the message INH:SFTCHK,SM=X and 704
     generates ALW:SFTCHK,SM=X.

     Box 05 Sanity Timer

     This box provides commands to inhibit and allow the sanity
     timer.

     The command 605 generates the message ORD:CPI=X,CMD=INH and 705
     generates ORD:CPI=X,CMD=ALW.

     Box 06 CORC Logging

     The command 606 generates the message INH:CORCLOG,SM=X which
     causes the Customer-Originated Recent Change (CORC) logging to
     be inhibited.

     Inhibiting customer-originated recent change logging should only
     be used when recent change logging is suspected to be causing a
     problem in the system.

     The command 706 generates the message ALW:CORCLOG,SM=X.

     Box 07 Recent Change Backout

     This indicator shows the status of recent change (RC) backout.
     If set, RCs will not be reentered following a high-level
     initialization.

     The description portion shows when the recent changes are
     actually backed out or loaded. If the backout is in progress, a
     number will appear on the third line of the box showing the
     progress of the backout. From 200 down to 100 is CORC backout;
     200 meaning CORC is still fully backed out, and 100 meaning CORC
     is fully rolled forward. From 100 down to 0 is RC backout; 100
     meaning RC is still fully backed out, and 0 meaning RC is fully
     rolled forward. Recent changes can be backed out only in
     conjunction with a high-level initialization.

     The command 407 generates the message SET:BACKOUT,RC,SM=X and
     507 generates CLR:BACKOUT,RC,SM=X.

     Box 08 Hardware Checks

     The command 608 (INH:HDWCHK,SM=X) causes all SM hardware checks
     to be inhibited. Note: The lower portion of this box is lighted
     only if all hardware checks have been inhibited.

     If hardware checks are allowed circuit by circuit, the indicator
     will not be cleared.

     The command 708 (ALW:HDWCHK,SM=X) allows all SM hardware checks.
     This will clear the backlighting of the box.

     Box 09 SM Brevity Controls

     Certain messages are normally suppressed from printing at the
     ROP. By inhibiting the controls, all SM output messages would be
     sent to the AM regardless of past message counts. Using this
     command can increase link traffic to the AM, and thus, can be
     service affecting.

     Inhibiting the brevity controls is achieved by entering command
     609 (INH:BREVC,SM=X). The controls can be returned to normal by
     entering the command 709 (ALW:BREVC,SM=X).

     Box 10 UPD Backout

     This indicator shows whether or not recently applied SM program
     updates are currently loaded or backed out.

     The description portion shows when the program updates are
     actually backed out or loaded. Program updates can be backed out
     or loaded only in conjunction with a high-level initialization.

     There are no menu commands for this box.

     Box 11 Min Mode (Full Init)

     This inhibit causes the SM to enter minimum mode and ignore all
     call processing. This inhibit should only be used in extreme
     emergencies, when all other normal recovery procedures have
     failed.

     When the 411 command is entered, the message SET:MINMODE,SM=X,FI
     is sent. This initiates a high-level init and inhibits software
     checks, hardware checks, routine exercises, and routine audits.
     In addition, output message brevity control is allowed.

     The only way to exit min mode is to enter the clear command or
     message. The 511 command generates the message
     CLR:MINMODE,SM=X,FI and causes a high-level init.

     Box 12 Peripheral Fault Recovery Message Verbose

     The command 412 (SET:PERPH,SM=X, VERBOSE) causes peripheral
     fault recovery (PFR) to send to the AM peripheral error messages
     that indicate that no recovery action has occurred in addition
     to messages that indicate that a peripheral error has caused
     recovery actions.

     The command 512 (CLR:PERPH,SM=X, VERBOSE) causes PFR to suppress
     the output of error reports. In the normal state, only output
     messages which indicate that a peripheral error has caused
     recovery actions on a circuit will be output.

     The messages will be logged or printed, depending on the state
     of the message class for each peripheral unit type.

     Box 13 Alarmed Message Discard

     This indicator shows if any output messages for this SM are
     being discarded.  Output messages of CRITICAL, MAJOR, MINOR, or
     MANUAL can be discarded by the input message CHG:MSGCNTL.  When
     this input message is entered, the box will be backlighted.

     Boxes 14 - 15 - Boxes 14 - 15 are currently not used.

     Figure .AW G273/ is an example of the 1800,X page which shows the SM 1
     sanity timer inhibited; MCTSI 0 is active and MCTSI 1 is in
     standby. The mate memory is out of date and 50 percent of the
     recent change has been backed out.

     Any available paging command can be entered from the 1800,X
     display page.

     Input messages for commands shown in boxes on the display are
     also described previously under the subheading, Indicators.
 2

     CMD   RESULT

     403   Manual Isolation of SM is set (SET:ISOL,SM=xxx)
     407   RC Backout is set (SET:BACKOUT,RC,SM=$S)
     411   Min Mode (FI) is set (SET:MINMODE,SM=$S,FI)
     412   Peripheral fault recovery message verbose is set
           (SET:PERPH,SM=$S,VERBOSE)
     420   MCTSI 0 is forced active (SET:MCTSI=XX-0,FRC)
     421   MCTSI 1 is forced active (SET:MCTSI=XX-1,FRC)
     422   Force of MCTSI is cleared (CLR:MCTSI=XX,FRC)
     503   Manual Isolation of SM is cleared (CLR:ISOL,SM=$S)
     507   RC Backout is cleared (CLR:BACKOUT,RC,SM=$S)
     511   Min Mode (FI) is cleared (CLR:MINMODE,RC,SM=$S,FI)
     512   Peripheral fault recovery message verbose is cleared
           (CLR:PERPH,SM=$S,VERBOSE)
     600   Routine Audits are inhibited (INH:AUD=CYCLE,SM=$S)
     601   Auto Pump is inhibited  (INH:PUMP,SM=$S)
     602   Routine Exercises are inhibited (INH:REX,SM=$S)
     604   Software Checks are inhibited (INH:SFTCHK,SM=$S)
     605   Sanity Timer is inhibited (ORD:CPI=$S,CMD=INH)
     606   CORC Logging is inhibited (INH:CORCLOG,SM=$S)
     608   All Hardware Checks are inhibited (INH:HDWCHK,SM=$S)
     609   Brevity Control for the SM is inhibited (INH:CREVC,SM=$S)
     700   Routine Audits are allowed (ALW:AUD=CYCLE,SM=$S)
     701   Auto Pump is allowed (ALW:PUMP,SM=$S)
     702   Routine Exercises are allowed (ALW:REX,SM=$S)
     704   Software Checks are allowed (ALW:SFTCHK,SM=$S)
     705   Sanity Timer is allowed (ORD:CPI=$S,CMD=ALW)
     706   CORC Logging is allowed (ALW:CORCLOG=$S,)
     708   All Hardware Checks are allowed (ALW:HDWCHK,SM=$S)
     709   Brevity Control for the SM is allowed (ALW:BREVC,SM=$S)
     900   Routine Audits are output (OP:STATUS=ALL,AUD,SM=$S)
     902   Routine Exercises are output (OP:REXINH,SM=$S)
     920   Selective initialization is requested (INIT:SM=X,SI)
     921   Selective initialization with pump is requested
           (INIT:SM=X,SI,PUMP)
     922   Full Initialization is requested (INIT:SM=X,FI)
     923   Full Initialization with pump is requested (INIT:SM=X,FI,PUMP)
     924   Forces the reset counter to level 12 or greater (guaranteeing a
           high-level init).  This poke does not require software sanity
           in the SM.  Poke 924 uses central processor intervention (CPI)
           to force the SM to reset, and the ROM reset handler forces the
           reset count to level 12 or greater.  The remainder of the init
           occurs normally (ORD:CPI=X,CMD=RESET).

           Note:  If the SM fails to respond to the FI PUMP and the SM
           appears to have lost sanity, use MP RESET (924 poke).  Also, if the
           SM is attempting to pump and is failing, then MP RESET may not help.


     The 1850 page provides status displays for both the primary and
     mate CMPs of the pair.  Also provided are menu commands to
     inhibit or allow hardware and software checks, routine audits,
     automatic pump, brevity control, and set and clear for recent
     change backout.  Requests for high-level initialization can be
     poked from the 1850 page.
     On the 1850 page display, each processor is identified by its
     CMP pair number and by its physical representation which
     includes the message switch side.  There is only one
     primary/mate CMP pair (0) for 5E6.

     During CMP initialization, the initialization status phrase
     progress marks will be displayed in the PRIM STAT portion of the
     screen along with the progress counter which shows the progress
     within a particular phase of the initialization.  The set of
     progress marks used will be different from the set used for the
     SMs pump and initialization sequences on MCC Page 1800,X.

     Table .AW TAI/ shows the CMP Off-Normal Status Phrases along with the
     priority, color, and an explanation of each.

     After initialization has completed, the current (highest) level
     CMP status will be displayed (just as with the SMs on the 1800,X
     page).  A ``+'' sign at the end of the status phrase indicates
     that more than one off-normal status exists.  The OP:SYSTAT
     input message or 800 poke command can be used to obtain
     additional off-normal status information.  Also, the current
     (highest) status of the MATE CMP will be displayed.  Additional
     status phrases are displayed in the other PRIM STAT and MATE
     STAT boxes along with the peripheral control data (PCD) status.

     Some of the boxes on the 1850 page have numbers at the bottom.
     These numbers show what commands are available from the display.
     For example, at the bottom of Box 00 the numbers ``6 7 9''
     appear. The ``6'' means this item can be inhibited by entering
     600, the ``7'' means it can be allowed by entering 700, and the
     ``9'' means output is available with 900.  On color MCC
     terminals, there is also color mapping from the commands shown
     on the left of the display to the numbers in the boxes.

     This section describes the individual indicators and their
     behavior.

     Box 00 - Routine Audits

     This indicator shows if the automatic execution of the CMP audit
     cycle is inhibited.

     Entering the 600 command generates the command INH:AUD[=a],CMP=b
     and causes the top line of the indicator to be backlighted and
     the text INH to be written. This request is phase-protected.
     Single audits can also be inhibited via input messages, but they
     are not phase-protected.

     When the request is recorded, the description area of the box is
     backlighted. This area is backlighted if one or more of the CMP
     audits are inhibited.

     Entering the command 700 generates the command ALW:AUD[=a],CMP=b
     and causes the indicator to return to normal video.

     The command 900 can be entered to get a ROP listing of routine
     audit status for the CMP. This command generates the message
     OP:STATUS[=a],AUD[=b],CMP=c.

     Box 01 - Auto Pump

     When the 601 command is entered, it generates the command
     INH:PUMP,CMP=a. This inhibits the automatic pump of the CMP on a
     major initialization (except UNIX RTR system level D4). This
     inhibit is phase-protected.

     The 701 command generates ALW:PUMP,CMP=a. This command must be
     entered to cancel the inhibit.

     Boxes 02 and 03 -  Boxes 02 and 03 currently are not used.

     Box 04 - Software Checks

     This indicator reflects whether or not the AM application
     software checks are inhibited. If any software checks have been
     inhibited, the description section is backlighted.

     The command 604 generates the message INH:SFTCHK,CMP=a and 704
     generates ALW:SFTCHK,CMP=a.

     Box 05 - Alarmed Messages Discarded

     The input message, CHG:MSGCNTL,CMP=a (where a is the CMP pair
     number), is associated with box 05.  This box will also
     backlight to indicate some type of alarmed messages (CRITICAL,
     MAJOR, MINOR, or MANUAL) are being discarded.

     Box 06 -  Box 06 is currently not used.

     Box 07 - Recent Change Backout

     This indicator shows the status of recent change (RC) backout.
     If set, RCs will not be reapplied following a full
     initialization.

     The description portion shows when the recent changes are
     actually backed out or applied.  A number indicating the status
     of a backout in progress will appear on the third line of the
     box.  From 200 down to 100 is CORC backout; 200 meaning CORC is
     still fully backed out, and 100 meaning CORC is fully rolled
     forward. From 100 down to 0 is RC backout; 100 meaning RC is
     still fully backed out, and 0 meaning RC is fully rolled
     forward. Recent changes can be backed out only in conjunction
     with a full initialization.

     The command 407 generates the message SET:BACKOUT,RC,CMP=a and
     507 generates CLR:BACKOUT,RC,CMP=a.

     Box 08 - Hardware Checks

     The command 208 (INH:HDWCHK,CMP=a) causes all CMP hardware
     checks to be inhibited.  The lower portion of this box is
     lighted only if all hardware checks have been inhibited.

     If hardware checks are allowed circuit by circuit, the indicator
     will not be cleared.

     The command 308 (ALW:HDWCHK,CMP=a) allows all CMP hardware
     checks. This will clear the backlighting of the box.

     Box 09 - CMP Brevity Controls

     Certain messages are normally suppressed from printing at the
     ROP. By inhibiting the controls, all CMP output messages would
     be sent to the AM regardless of past message counts. Using this
     command can increase link traffic to the AM, and thus, can be
     service affecting.

     Inhibiting the brevity controls is achieved by entering command
     609 (INH:BREVC,CMP=a).  The controls can be returned to normal
     by entering the command 709 (ALW:BREVC,CMP=a).

     Box 10 - UPD Backout

     This indicator shows whether or not recently applied CMP program
     updates are currently applied or backed out.

     The description portion shows when the program updates are
     actually backed out or applied. Program updates can be backed
     out or applied only in conjunction with a full initialization.

     There are no menu commands for this box.

     Box 11 - Min Mode

     This box is used to display whether or not the AM/CMPs are in
     minimum mode.
     The CMP 0 PRIM STAT box located in the top-middle portion of the
     screen can be updated with vartext for internal indicators.
     This box contains three subboxes:

       1. Top PRIM STAT box:  Left half is logical link map
          designation (0-0 or 1-0) and right half is PCD status.

       2. Middle PRIM STAT box:  Contains three lines of information:

            o  Initialization phrases and highest priority status
               phrases for PRIM CMP

            o  Initialization progress counter

            o  Initialization phrase trigger.

       3. Bottom PRIM STAT box:  Contains four lines:

            o  HASH ERR

            o  GEN DIFF

            o  SPEC GROW (Not Used)

            o  COMM LOST.

     The MATE STAT box, located in the lower middle portion of the
     screen, contains two subboxes:

       1. Top MATE STAT box:  The left half contains the logical link
          map designation (0-0 or 1-0) for the MATE CMP.  The right
          half displays the PCD status of the MATE CMP.

       2. Bottom MATE STAT box:  Contains initialization and status
          phrases for the MATE CMP.

     Figure .AW G274/ shows an example of the 1850 display page.

     Any available paging command can be entered from the 1850
     display page.

     All 600 and 700 level pokes are duplex commands which can only
     be entered from the primary (PRIM) CMP page (1850).

 2
     CMD   RESULT

     208   Inhibits hardware checks of CMP
           (INH:HDWCHK,CMP=a,PRIM)
     308   Allows hardware checks of CMP
           (ALW:HDWCHK,CMP=a,PRIM)
     407   Backout uncommitted recent changes of CMP
           (SET:BACKOUT,RC,CMP=a,PRIM)
     507   Clears recent changes from a CMP
           (CLR:BACKOUT,RC,CMP=a,PRIM)
     600   Audit cycle inhibited for CMPs
           (INH:AUD[=a],CMP=b)
     601   Inhibits automatic pump of CMPs on full initialization
           (INH:PUMP,CMP=a)
     604   Inhibits software error checks of CMPs
           (INH:SFTCHK,CMP=a)
     609   Inhibits automatic brevity control for CMPs
           (INH:BREVC,CMP=a)
     700   Audit cycle allowed for CMPs
           (ALW:AUD[=a],CMP=b)
     701   Allows automatic pump of CMPs
           (ALW:PUMP,CMP=a)
     704   Allows software error checks in CMPs
           (ALW:SFTCHK,CMP=a)
     709   Allows automatic brevity control for CMPs
           (ALW:BREVC,CMP=a)
     800   Requests off-normal reports for CMP status
           (OP:SYSSTAT,CMP=a)
     900   Requests audit status for CMP
           (OP:STATUS[=a],AUD[=b],CMP=c,PRIM)
     919   Requests purging initialization of selected CMP
           (INIT:CMP=a,PRIM,PGI)
     920   Requests selective initialization of selected CMP
           (INIT:CMP=a,PRIM,SI)
     922   Requests full initialization of selected CMP
           (INIT:CMP=a,PRIM,FI)
     923   Requests full initialization and pump of selected CMP
           (INIT:CMP=a,PRIM,FI,PUMP)


     The 1851 page is similar to the 1850 except that 600 and 700
     level pokes cannot be entered from the 1851 page.  Also, the
     1851 page has the 930 and 931 commands that the 1850 does not
     have.

     The 1851 page provides status displays for both the primary and
     mate CMP pair.  Also provided are menu commands to inhibit or
     allow hardware and software checks, routine audits, automatic
     pump, brevity control, and set and clear for recent change
     backout.  Requests for full initialization can be poked from the
     1851 page.
     On the 1851 page display, each processor is identified by its
     CMP pair number and by its physical representation which
     includes the message switch side.  There will be only one
     primary/mate CMP pair (0) for 5E6.

     During CMP initialization, the initialization status phrase
     progress marks will be displayed in the PRIM STAT portion of the
     screen along with the progress counter which shows the progress
     within a particular phase of the initialization.  The set of
     progress marks used will be different from the set used for the
     SMs pump and initialization sequences on MCC Page 1800,X.

     Table .AW TAJ/ shows the CMP Off-Normal Status Phrases along with the
     priority, color, and an explanation of each.

     After initialization has completed, the current (highest) level
     CMP status will be displayed (just as with the SMs on the 1800,X
     page).  A ``+'' sign at the end of the status phrase indicates
     that more than one off-normal status exists.  The OP:SYSTAT
     input message or 800 poke command can be used to obtain
     additional off-normal status information.  Also, the current
     (highest) status of the primary CMP will be displayed.
     Additional status phrases are displayed in the other PRIM STAT
     and MATE STAT boxes along with the PCD status.

     Some of the boxes on the 1851 page have numbers at the bottom.
     These numbers show what commands are available from the display.
     For example, at the bottom of Box 00 the number ``9'' appears.
     The ``9'' means output is available by entering 900.  On color
     MCC terminals, there is also color mapping from the commands
     shown on the left of the display to the numbers in the boxes.
     This section describes the individual indicators and their
     behavior.

     Box 00 - Routine Audits

     This indicator shows if the automatic execution of the CMP audit
     cycle is inhibited.

     The command 900 can be entered to get a ROP listing of routine
     audit status for the CMP. This command generates the message
     OP:STATUS[=a],AUD[=b],CMP=c.

     Box 01 - Auto Pump

     Commands to allow or inhibit automatic pump of the CMP must be
     entered from Page 1850.

     Boxes 02 and 03 -   Boxes 02 and 03 currently are not used.

     Box 04 - Software Checks

     Commands to allow or inhibit software checks of the CMP must be
     entered from Page 1850.

     Box 05 - Alarmed Messages Discarded

     The input message, CHG:MSGCNTL,CMP=a (where a is the CMP pair
     number), is associated with box 05.  This box will also
     backlight to indicate some type of alarmed messages (CRITICAL,
     MAJOR, MINOR, or MANUAL) are being discarded.

     Box 06 -  Box 06 is currently not used.

     Box 07 - Recent Change Backout

     This indicator shows the status of recent change (RC) backout.
     If set, RCs will not be reapplied following a full
     initialization.

     The description portion shows when the recent changes are
     actually backed out or applied.  If the backout is in progress,
     a number will appear on the third line of the box showing the
     progress of the backout. From 200 down to 100 is CORC backout;
     200 meaning CORC is still fully backed out, and 100 meaning CORC
     is fully rolled forward. From 100 down to 0 is RC backout; 100
     meaning RC is still fully backed out, and 0 meaning RC is fully
     rolled forward.  The RCs can be backed out only in conjunction
     with a full initialization.

     The command 407 generates the message SET:BACKOUT,RC,CMP=a and
     507 generates CLR:BACKOUT,RC,CMP=a.

     Box 08 - Hardware Checks

     The command 208 (INH:HDWCHK,CMP=a) causes all CMP hardware
     checks to be inhibited.

       Note:   The lower portion of this box is lighted only if
               all hardware checks have been inhibited.

     If hardware checks are allowed circuit by circuit, the indicator
     will not be cleared.

     The command 308 (ALW:HDWCHK,CMP=a) allows all CMP hardware
     checks. This will clear the backlighting of the box.

     Box 09 - CMP Brevity Controls

     Commands to allow or inhibit brevity control must be entered
     from Page 1850.

     Box 10 - UPD Backout

     This indicator shows whether or not recently applied CMP program
     updates are currently applied or backed out.

     The description portion shows when the program updates are
     actually backed out or applied. Program updates can be backed
     out or applied only in conjunction with a full initialization.

     There are no menu commands for this box.

     Box 11 - Min Mode

     This box is used to display whether or not the AM/CMPs are in
     minimum mode.
     The MATE STAT box located in the top-middle portion of the
     screen can be updated with vartext for internal indicators.
     This box contains three subboxes:

       1. Top MATE STAT box:  Left half is logical link map
          designation (0-0 or 1-0) and right half is PCD status.

       2. Middle MATE STAT box:  Contains three lines of information:

            o  Initialization phrases and highest priority status
               phrases for MATE CMP

            o  Initialization progress counter

            o  Initialization phrase trigger.

       3. Bottom MATE STAT box:  Contains four lines:

            o  HASH ERR

            o  GEN DIFF

            o  SPEC GROW (Not Used)

            o  COMM LOST.

     The PRIM STAT box, located in the lower middle portion of the
     screen, contains two subboxes:

       1. Top PRIM STAT box:  The left half contains the logical link
          map designation (0-0 or 1-0) for the PRIM CMP.  The right
          half displays the PCD status of the PRIM CMP.

       2. Bottom PRIM STAT box:  Contains initialization and status
          phrases for the PRIM CMP.

     Figure .AW G275/ shows an example of the 1851 display page.

     Any available paging command can be entered from the 1851
     display page.

 2
     CMD   RESULT

     208   Inhibits hardware checks of CMP
           (INH:HDWCHK,CMP=a,MATE)
     308   Allows hardware checks of CMP
           (ALW:HDWCHK,CMP=a,MATE)
     407   Backout uncommitted recent changes of CMP
           (SET:BACKOUT,RC,CMP=a,MATE)
     507   Clears recent changes from CMP
           (CLR:BACKOUT,RC,CMP=a,MATE)
     800   Requests off-normal reports for CMP status
           (OP:SYSTAT, CMP=a)
     900   Requests audit status for CMP
           (OP:STATUS[=a],AUD[=b],CMP=c,MATE)
     919   Requests purging initialization of selected CMP
           (INIT:CMP=a,MATE,PGI)
     920   Requests selective initialization of selected CMP
           (INIT:CMP=a,MATE,SI)
     922   Requests full initialization of selected CMP
           (INIT:CMP=a,MATE,FI)
     923   Requests full initialization and pump of selected CMP
           (INIT:CMP=a,MATE,FI,PUMP)
     930   Start off-line pump for specified mate CMP
           (ST:OPUMP,CMP=a,MATE)
     931   Stop off-line pump for specified mate CMP
           (STP:OPUMP,CMP=a,MATE)


     The purpose of the 1900,X page is to show status and to provide
     maintenance controls for SM X communication links (CLNKs).
     The 1900,X page shows the status of each CLNK to SM X and the
     status of the supporting hardware.  A CLNK path includes the
     office network timing complex (ONTC 0 or 1), the module message
     processor (MMP 0 or 1), and the message switch (MSGS 0 or 1).
     The CLNK numbers are derived from the hardware path.  The first
     digit is the ONTC number, the second is the MMP, and the third
     is the MSGS.  Figure .AW G276/ is an example of the CM2 version of the
     1900,X page.

     The status of the SM's dual link interfaces (DLI) is also
     displayed.  For a remote switching module (RSM), the host
     switching module (HSM) number and the status of the HSM's DLIs
     are displayed.  Figure .AW G277/ is an example of the RSM version of
     Page 1900,X.

     If the SM is an optically remoted module (ORM), the transmission
     rate converter unit (TRCU) hardware is identified in the
     ONTCCOM/DLI indicator block.  This indicator does not show the
     status of the TRCU hardware.  Figure .AW G278/ is an example of the
     ORM version of Page 1900,X.

     Two logical communication paths (0 and 1) are assigned
     dynamically to in-service physical links.  Physical CLNKs that
     are supporting a logical link are shown as active (ACT).  The
     logical to physical link assignments are displayed, along with
     the state of each physical link.

     The CLNKs that are not active will usually be in the IDLE state.
     This means that they are available if an active CLNK goes out of
     service (OOS), but would need to be configured before becoming
     active. The RSM CLNKs may be in the standby (STBY) state.  A
     STBY CLNK has already been configured, and will be made active
     if an ONTC switch occurs.  Active RSM CLNKs must pass through
     the major ONTC.

     The SM X STAT indicator on the display contains one of the SM
     summary status phases, as listed in the table following the
     description of Page 114 - EQUIPPED SM STATUS SUMMARY.  The
     CLNK-related off-normal conditions (OOS, simplex, or inhibited
     links) can cause the SM status to become ``CLNK OFFN.'' When
     such an off-normal condition exists, indicators for the affected
     units will backlight.  On Page 115 - COMMUNICATION MODULE
     SUMMARY, the CLNK indicator will backlight.  On Page 1260 - CLNK
     SUMMARY, the appropriate SM indicator will backlight.  If the SM
     is isolated, the CLNK indicator on Page 1260 will be flashing.
     In the SUMMARY STATUS AREA, the SM and CM critical indicators
     and the alarm level (CRITICAL, MAJOR, or MINOR), if any, will
     backlight.

     The 1900,X page differs slightly based on the communication
     module hardware vintage (CM1 or CM2).  For CM1, the note at the
     lower left of the display defining ONTCCOM will include the link
     interface (LI). This unit does not exist in CM2 offices.  The
     status of 8 CLNKs and 4 MMPs (two per MSGS side) will be
     displayed in offices equipped with dual MMPs.  Otherwise, only 4
     CLNKs and 2 MMPs will be shown.  Figure .AW G279/ is an example of the
     CM1 version of Page 1900,X.

     The 1900,X page provides commands to remove, restore, inhibit,
     allow, and output the configuration status of the communication
     links. In addition, any available paging command can be entered
     from this display.

     CMD    RESULT

     2XXX   CLNK XXX is removed
            (RMV:CLNK=SM#-X-X-X)
     3XXX   CLNK XXX is restored
            (RST:CLNK=SM#-X-X-X)
            (If a conflicting CLNK is already active, the restore will
            leave the designated CLNK in the IDLE or STBY state, not ACT.
            If the designated CLNK is already OOSF, the restore request
            will leave it in the OOSF state.)
     6XXX   CLNK XXX hardware checks are inhibited
            (INH:HDWCHK,CLNK=SM#-X-X-X)
     7XXX   CLNK XXX hardware checks are allowed
            (ALW:HDWCHK,CLNK=SM#-X-X-X)
     9XXX   Configuration status for CLNK XXX is output
            (OP:CFGSTAT,CLNK=SM#-X-X-X)

     The purpose of Page 1940 is to provide a simplified procedure
     for installing Broadcast Warning Messages (BWM) into the 5ESS
     switch.  The EASY BWM feature simplifies the BWM application
     process by freeing the user from entering commands and
     constantly having to monitor the progress of the BWM.
     The Easy BWM Installation page can be used to back out, install,
     or apply BWMs with a single command. The page also provides
     control of the soak interval timer. This user specified time
     will override the 24-hour default value.

     Several terms used in the commands which may be confusing are
     described as follows:

       o  Install:  To take an official BWM from the start command to
          the official command. The TEMP BWMs cannot be made
          official.

       o  Back Out:  To take a TEMP or craft BWM that is soaking and
          back it out of the system.

       o  Apply:  To take a TEMP or craft BWM from the start command
          to the soak command.

       o  Soak:  To leave a BWM in the system for a certain period of
          time so as to allow the update to have a chance to interact
          with other pieces of software in the system.

       o  Official:  To make a BWM permanent in the system.

     The 1940 page (Figure .AW G280/) is divided into two basic areas. The
     area in the middle of the page contains the poke commands used
     to control the BWM processes. These poke commands are discussed
     in the ``Commands'' paragraph. The area at the bottom of the
     page will provide a response indicating the progress of a BWM
     procedure or a summary of an error message if an error occurs
     during the execution of a command.  Also found in the bottom
     area are the names of the Install, Back Out, and Apply BWMs in
     addition to the value of the BWM Soak Interval Timer.

     Whenever Page 1940 is displayed, the values for Install BWM
     Name, Back Out BWM Name, Apply BWM Name, and BWM Soak Interval
     Timer will be populated with default information. The following
     describes each of these fields in detail.

     The Install BWM Name is the name of the BWM that should be
     inputed into the switch. The Install BWM Name can be changed
     with the 9810 poke command.

     The Back Out BWM Name is the name of the TEMP/craft BWM to be
     backed out before the next BWM is to be installed/applied.  If
     no BWM is in the soak state, the default value NONE will be
     displayed. To change the name of the BWM to be backed out, use
     the 9820 poke command.

     The Apply BWM Name is the name of the TEMP/craft BWM to be
     applied after the Install BWM is in the official state. This
     field always defaults to the value NONE. To change the name of
     the BWM to be applied, use the 9830 poke command.

     The BWM Soak Interval Timer is defaulted to 24 hours 00 minutes.
     This field will always be displayed. If the value needs to be
     changed, use the 9840 poke command.

     The middle of Page 1940 provides commands used to process BWMs.
     These commands are as follows:

     CMD              RESULT

     9800             Start Execution
     9810,(Y)         Change Install BWM Name
     9820,(Y)         Change Back Out BWM Name
     9830,(Y)         Change Apply BWM Name
     9840,HH,MM       Change BWM Soak Interval Timer
     9850,F           Dump Inst BWM File
     9860             Stop Execution
     9870             Stop After Soak

     The 9800 poke command starts the execution of the EASY BWM
     process. If the back out BWM is populated with a BWM name, it
     backs out that BWM, then it installs the install BWM, and if
     appropriate, applies the apply BWM. This poke command must not
     be entered before the install BWM name is populated (9810 poke
     command) with a valid BWM name.

     After execution is started on the 1940 page and its response
     line states that EASY BWM IS IN PROGRESS, the page is not
     updated until it completes successfully or runs into a failure.
     To find out the current status of BWMs look on Page 1960. The
     1960 page is kept up to date while the EASY BWM process is
     executing.

     The 9810 poke command populates the Install BWM Name. This BWM
     is the one which will be used as the install BWM. This field can
     contain any valid 6- or 10-character BWM name. This field MUST
     be populated for the EASY BWM process to work. If this BWM name
     is a TEMP BWM, then this BWM will not be made official and the
     Apply BWM will NOT be applied to the 5ESS switch.

     The 9810 poke command should always be the first poke command
     entered on the page. This is needed since this poke command
     initializes the page with default information, except for the
     data just entered. If the page is set up and this is the last
     poke command executed, the page will be initialized and the
     previous input will have to be reentered.

     The 9820 poke command will populate the Back Out BWM Name. This
     BWM is the one which will be backed out of the 5ESS switch when
     execution is started. This field is populated for the user and
     should never have to be changed by the user. This field can
     contain all valid BWM names except official BWMs (BWMs that
     start with BWM).

     The 9830 poke command will populate the Apply BWM Name. This BWM
     is the one that will be applied after the Install BWM is
     finished. This will NOT happen if the Install BWM is a TEMP BWM.
     In that case, the Apply BWM will NOT be applied to the 5ESS
     switch.  This field can contain all valid BWM names except
     official BWMs (BWMs that start with BWM).

     The 9840 poke command will allow the user to change the soak
     interval timer for the Install BWM.  Default value for the timer
     is 24 hours and 00 minutes.  The timer does not change until the
     soak section has been executed and the timer set.  At that time
     the EASY BWM process resets the soak interval timer to the value
     the user entered.

     The 9850 poke command will print (on the ROP) any American
     standard code for information interchange (ASCII) file
     associated with the Install BWM. This includes the MSGS and
     SCANS files.  To print the MSGS file for the Install BWM with
     this command, you would enter 9850,MSGS.

     The 9860 poke command will stop the execution of all commands on
     Page 1940 (see example outlined as follows). Execution will be
     stopped only after the current step in the current state is
     completed. This command is the same as the 9560 poke command on
     Page 1960.

     The 9870 poke command allows the user to stop the execution of
     the EASY BWM process after the Install BWM has started its soak
     section.  If this option is selected, the 9870 poke must have
     been entered causing the STOP AFTER SOAK status field to show
     ON, and the execution of EASY BWM will stop awaiting user input.
     To restart the EASY BWM process, reenter the 9800 poke. If the
     9870 poke was not entered, the STOP AFTER SOAK status field will
     show OFF, and the  EASY BWM process will not stop until
     execution has completed in full.  Note that the 9870 poke
     toggles the STOP AFTER SOAK option, so that if it was ON,
     entering the 9870 poke will cause it to turn OFF.  Also, if it
     was OFF, entering the 9870 poke will cause it to turn ON.

     An example using the 1940 page follows.  For this example,
     assume:

       o  TEMP BWM TMP88-6082 is soaking.

       o  Official BWM BWM88-0050 is to be installed.

       o  TEMP BWM TMP88-6089 is to be applied after the install BWM
          has finished.

       o  A soak time of 2 hours and 0 minutes is wanted for the
          Install BWM.

     The following is a list of steps that the user would take to
     accomplish this example:

                     ACTION                                  RESULT

  1.  Enter the 1940 poke command.          The 1940 page is displayed.
                                            The Back Out BWM field is
                                            populated with TMP88-6082,
                                            the rest of the page contains
                                            default information.

  2.  Enter the 9810,880050 poke command.   The Install BWM field is
                                            populated with BWM88-0050.

  3.  Enter the 9830,886089 poke command.   The Apply BWM field is
                                            populated with TMP88-6089.

  4.  Enter the 9840,2,0 poke command.      This will populate the soak
                                            interval timer with 2-00.

  5.  Enter the 9800 poke command.          This will start execution of the
                                            EASY BWM process.

     The 1950 display page provides commands to display BWM history,
     to recover backward and forward, to clear the BWM, and to back
     out the last official BWM.  The soak period for a BWM can be
     set/changed by the craft (poke 9700); the poke 9710 can be used
     to check the status of a specific BWM soak period; the poke 9720
     can be used to abort soak timer.
     PROGRAM UPDATE keeps an on-line log of the history of all BWMs
     installed against the current software release issue in a 5ESS
     switch office.

     The 9101,Y - BWM Y command causes the history of the specified
     BWM (Y = BWM name) to be printed at the ROP.

     9102 - OFC causes a history of all the BWMs, which have been
     made official, to be printed at the ROP.

     9103 - TEMP causes a history of all of the BWMs which are in the
     temporary state to be printed at the ROP.

     9104 - ALL causes the history of all BWMs in the active log to
     be printed at the ROP. This command can also accept the
     COMMAND,DATA! format. This is provided for 9104,BACKLOG which
     would print the history of all the BWMs in an archive log, and
     9104, SUM which prints a short summary of the BWMs.

     9200 - VERIFY INCONSISTENCY causes any update inconsistencies to
     be detected and printed at the ROP.

     9300 - RECOVER FORWARD reapplies all the temporary updates which
     are in the table of inconsistencies.

     9400 - RECOVER BACKWARD removes all the temporary updates
     causing inconsistencies starting from the very last one in the
     system to the first.

     9600,Y - CLEAR BWM Y causes the files in the specified BWM
     package (Y = BWM name) to be removed. (Used to free up disk
     space after the BWM is made official.)

     9650,X - EXPAND BWM causes the compressed files in the specified
     BWM package (X=BWM name) to be expanded.  (Used to expand a
     compressed BWM when the automatic expansion during a BWM
     download through SCANS or CSCANS was manually stopped or
     aborted.)

     9700,HH,MM - RESET TIMER to ``HH'' HOURS and ``MM'' MINUTES has
     two applications as follows:

       a. Make BWM official immediately:  The craft can make the BWM
          official immediately by entering the 9700,0,0 poke command
          after all of the commands have been executed via the soak
          poke command (9320 or 9420 on Page 1960).  This command
          allows the craft to bypass the soak period.

       b. Change time period of the soak:  After the craft has
          initialized the BWM soak period (via poke 9320 or 9420 on
          Page 1960), the time period of the soak can be changed by
          entering the 9700,HH,MM poke command.  The time period of
          the soak can only be changed after the soak period has been
          initialized.  If this occurs, the craft receives an error
          message indicating the soak has not been initialized.  Only
          one BWM can have its soak period set/changed at a time.

     9710 - PRINT TIMER INFORMATION (including completion time, start
     time, and if applicable, the time the soak period was changed)
     on the ROP.

     9720 - ABORT SOAK TIMER aborts the time that was reset
     previously.

     9900 - BACKOUT OFC backs out the last official BWM.  The name of
     the last official BWM is displayed on this display page in the
     ``LAST OFC BWM'' field.

     Figure .AW G281/ is an example of the 1950 page which shows that the
     display of the history of BWM90-0067 has been completed.

     The entire 1950 display page is commands. In addition to these,
     any available paging commands can be entered from the 1950
     display page.
 2

        CMD       RESULT

       9101,Y     Displays the history of BWM Y
                  (UPD:UPDDSPLY:BWM=Y)
        9102      Displays the history of all official BWMs
                  (UPD:UPDDSPLY,OFC)
        9103      Displays the history of all BWMs in the temporary state
                  (UPD:UPDDSPLY,TEMP)
        9104      Displays the history of all BWMs in the active log or
                  archive log
                  (UPD:UPDDSPLY,ALL)
                  [,BACKLOG] this displays the archive log BWM history
                  [,SUM] this displays a summary consisting of the last
                  official software update (BWMyy-nnnn), a list of active
                  craft software updates (CFTyy-nnnn), and the temporary
                  software update (TMPyy-nnnn), if one exists, and their
                  respective status
        9200      Displays any update inconsistencies
                  (UPD:VFYCON)
        9300      Reapplies all the temporary updates considered causing
                  inconsistencies
                  (UPD:RECOVERY,FRWD)
        9400      Removes all the temporary updates causing inconsistencies
                  (UPD:RECOVERY,BKWD)
       9600,Y     Removes the files in the specified BWM (or ALL for
                  all BWMs)
                  (UPD:CLRBWM:BWM=Y | ALL)
       9650,X     Expands the compressed files in the specified BWM (or
                  STOP to stop automatic expansion for the BWM that is
                  currently being downloaded through SCANS or CSCANS)
                  (UPD:EXPAND:UPNM=Y | STOP)
     9700,HH,MM   Resets timer for soak period to HH (HH = hour) and MM
                  (MM = minutes)
                  (UPD:RESET:TM=HH-MM)
        9710      Prints timer information (completion time, start time, and if
                  applicable, the time the soak period was changed is
                  printed on the ROP)
                  (UPD:PRINT:SKTM)
        9720      Aborts soak timer
                  (UPD:RESET:ABORT)
        9900      Backs out last BWM that was made official
                  (UPD:BOLO).


     The purpose of the 1960 display page is to provide commands for
     installing BWMs and to provide the status of the installation.
     The 1960 display consists of two parts. The upper part consists
     entirely of commands. The commands provide the ability to verify
     a BWM, display or print the contents of the message file in the
     BWM, or execute commands in the message file. The lower part of
     the display is the message file display area. The message file
     is a file in a BWM package which contains a set of craft input
     messages grouped in sections describing how to install the BWM.
     There are up to ten numbered lines for displaying the command
     lines of the message file.

     The craft can select and print the American standard code for
     information interchange (ASCII) files [via poke command 9260,F
     (F = Filename in BWM)] that are associated with a particular BWM
     on the ROP.  If the requested file is not an ASCII file, an
     error message is printed on the ROP.

     The 9010 - VERIFY command has a status indicator to its right
     which will show the status of the verification if 9010 has been
     entered. The three possible phrases for the status indicator are
     in progress (INPG), complete (CMPL), and abort (ABRT). If
     verifying the BWM fails, further information will be printed on
     the ROP.

     The SECTION EXECUTION STATUS area provides status indicators for
     each of the execution sections, except FILE, (that is, APPLY,
     SOAK, OFC, and BKOUT). If there is an error, the status
     indicator of the section which was executing will show the
     status ABRT and be backlighted. The error causing command line
     in the message file display area will also be backlighted (black
     on red for color terminals).

     An additional indicator -- timer in progress (TMPG) is displayed
     in the SOAK indicator block after soak timer is set.

     If all the command lines in the section being executed are
     successful, the status CMPL will be displayed in the appropriate
     status indicator (that is, APPLY=CMPL, SOAK=CMPL, and OFC=INPG)
     in the SECTION EXECUTION STATUS area.

     The RESPONSE indicator is used to display a summary of an error
     message if an error occurs during the execution of a command
     line.

     Further information can always be found printed at the ROP.

     Figure .AW G282/ is an example of the 1960 page display which shows
     that a BWM is being made official (name of the BWM is in the
     upper right-hand corner).

     In addition to the BWM installation commands, any available
     paging command may be entered from the 1960 display page.
 2

      CMD     RESULT

     9000,Y   Starts the updating software session using BWM Y
              (UPD:UPNAME:BWM=Y)
      9010    Verifies the BWM (UPD:VFYBWM)
      9560    Stops the execution of the BWM (STP:EXC,UPD)
     9565,Z   Resets the execution pointer in the message file to command
              line Z
              (UPD:RESET:LINE=Z)
      9570    Scrolls the message display area forward to the next window
              (UPD:NXTWNDW)
      9575    Scrolls the message display area backward to the previous
              window
              (UPD:PRVWNDW)
      9110    Displays the APPLY section of the BWM in the message display
              area
              (UPD:DISPLYUPD,APPLY)
      9120    Displays the SOAK section of the BWM in the message display
              area
              (UPD:DISPLYUPD,SOAK)
      9130    Displays the OFC section of the BWM in the message display area
              (UPD:DISPLYUPD,OFC)
      9140    Displays the BKOUT section of the BWM in the message display
              area
              (UPD:DISPLYUPD,BKOUT)
      9150    Displays the FILE section of the BWM in the message display
              area
              (UPD:DISPLYUPD,FILE)
      9210    Prints the APPLY section of the BWM at the ROP
              (UPD:PRINT,APPLY)
      9220    Prints the SOAK section of the BWM at the ROP (UPD:PRINT,SOAK)
      9230    Prints the OFC section of the BWM at the ROP (UPD:PRINT,OFC)

      9240    Prints the BKOUT section of the BWM at the ROP
              (UPD:PRINT,BKOUT)
      9250    Prints the whole sections of the BWM at the ROP
              (UPD:PRINT,FILE)
     9260,F   Prints the ASCII files that are associated with a particular
              BWM on the ROP
              (UPD:PRINT:BWMFILE,FN=F) where F = filename in BWM
      9310    Executes all APPLY command lines one by one
              (UPD:EXALL,APPLY)[,UCL]
      9320    Executes all SOAK command lines one by one (UPD:EXALL,SOAK)
      9330    Executes all OFC command lines one by one to make a BWM
              official
              (UPD:EXALL,OFC)[,UCL]
      9340    Executes all BKOUT command lines one by one to back out the
              BWM (used if the BWM fails) (UPD:EXALL,BKOUT)
      9410    Execute current APPLY command line (UPD:EXNXT,APPLY)
      9420    Execute current SOAK command line (UPD:EXNXT,SOAK)
      9430    Execute current OFC command line (UPD:EXNXT,OFC)
      9440    Execute current BKOUT command line (UPD:EXNXT,BKOUT)


     The 1999 page provides a reference for the use of video
     attributes for various maintenance states.
     The 1999 page is for information only. It does not indicate any
     existing conditions and it does not have any commands.

     The display is divided into sections for the SUMMARY STATUS AREA
     STATES, CIRCUIT STATES, and OTHER STATES.

     The SUMMARY STATUS AREA STATES are only used in the SUMMARY
     STATUS AREA.

     The CIRCUIT STATES are used for actual circuit status. These
     states always have accompanying text describing the condition.

     The OTHER STATES are used for summary-type indicators and for
     alarm unit indicators.

     Although different states are used in different areas, the
     guidelines listed in the 5ESS Switch States section of the
     manual are followed in each area.
     The meanings of the states are as follow:

     Summary Status Area States

       o  CRITICAL FLASH is used for unacknowledged (not yet retired)
          severe, service-affecting conditions. These alarms require
          immediate corrective action.

       o  CRITICAL STEADY is used for acknowledged (retired) CRITICAL
          ALARMS.

       o  MAJOR FLASH is used for unacknowledged serious disruptions
          to service or failure of important circuits. These alarms
          require immediate corrective action but are less urgent
          than critical alarms.

       o  MAJOR STEADY is used for acknowledged major alarms.

       o  MINOR FLASH is used for unacknowledged troubles that do not
          have a serious effect on service or for troubles in
          circuits which are not essential for call processing.

       o  MINOR STEADY is used for acknowledged minor alarms.

            Note:   The indicators CRITICAL, MAJOR, and MINOR do
                    not flash.  Only the actual area of the alarm
                    flashes. For example, the SM indicator flashes
                    if the alarm is due to a trouble or an off-
                    normal condition in an SM.

       o  UNALARMED OFF-NORMAL is used for unalarmed troubles.

       o  SYSTEM NORMAL is only used for the SYS NORM indicator and
          only when there are no off-normal conditions in the system.

       o  NORMAL is used for all the SUMMARY STATUS AREA indicators,
          except the SYS NORM indicator, when their respective area
          has no off-normal or trouble conditions. Such as, if the CM
          hardware has no trouble conditions or off-normal
          conditions, the CM indicator will be NORMAL.

     Circuit States

       o  ACT:  Active means the circuit is in service, available for
          normal use by the system.

       o  STBY:  Standby means a unit is ready, willing, able, and
          waiting to perform its intended function.

       o  OOS:  Out of service is used for units which have been
          removed from service and are no longer to be used by the
          system.

       o  UNV:  Unavailable (UNV) is used for units which the system
          is prevented from using. This condition is initiated by a
          craft action.

       o  UNEQ:  Unequipped is used to show units which are not
          installed.

       o  IDLE:  Idle is used for units that are available for
          service if needed, but would need to be configured first.

       o  INIT:  Initialization is used when a unit is being
          initialized.

       o  INH:  Inhibit means the action which would normally occur
          is inhibited from doing so.

       o  ACTF:  Active forced is used when one side of a duplex unit
          is forced to active, regardless. The other side of the
          duplex unit automatically becomes UNV. The ACTF state can
          only be initiated by a craft action. There may or may not
          be a fault in the ACTF unit.

       o  DGR:  Degraded is used for circuit groupings in which the
          overall circuitry is functioning normally, although one or
          more of the noncritical circuits in the grouping is out of
          service. (For example, this state is used for ONTC X, which
          includes MI/NC X, TMS X, and all DLIs on side X. If one of
          the DLIs fails, the ONTC becomes degraded.)

       o  DGRF:  Degraded forced is similar to ACTF, but there
          definitely is a noncritical fault.

       o  LMTD:  Limited is used when a circuit is currently active,
          but a nonservice-affecting request to remove the circuit
          has been camped on. The circuit will go out of service as
          soon as it is idle. This would normally appear on line unit
          and trunk unit circuits.

       o  TEST:  This state is used when an operational or functional
          test other than a diagnostic is being run on a unit. This
          is a form of testing which can run while a unit is in use
          (most frequently used for line unit concentrators).

       o  UNVP:  Unavailable power is used when a unit is unavailable
          due to no power to the unit due to a manual action (such as
          hitting the ``button'' to turn power off to the unit).

       o  UNVT:  Unavailable transient is a transient state, shown
          only to keep the craft informed as to what is happening. No
          action is required on the part of the craft.

       o  OOSP:  Out-of-service power is used when a unit is out of
          service due to no power to the unit due to faulty hardware
          (such as a blown fuse or converter failure).

       o  OOST:  Out-of-service transient is a transient state, shown
          only to keep the craft informed as to what is happening. No
          action is required on the part of the craft.

       o  OOSF:  Out-of-service family is used when a circuit goes
          out of service because its ``parent'' unit has gone out of
          service. For example, the MMPs in an MSGS would be OOSF if
          the control unit (MSCU) was out of service.

       o  DEFR:  Deferred is used to indicate an out-of-service unit
          whose return to service has intentionally been deferred.
          This state can only be entered by a craft action.

       o  GROW:  Growth is used while a new unit or capability is
          being added to the system.

       o  SGRO:  Special growth is a semioperational state used when
          an SM is being added to the system.

       o  CAMP:  Camp on is used when a unit is waiting for ownership
          of some resources.

       o  CDNY:  Customer Denied is used for circuit groupings in
          which the overall circuiting is functioning normally, but
          some customers are denied service.

     Other States

       o  SEVERE TROUBLE flashes and is used for fire alarms and
          isolated SMs.

       o  TROUBLE is used for off-normal alarm unit indicators
          (except fire) and for off-normal summary indicators.

       o  INHIBITS ON is used for summary-type indicators.

       o  OFF-NORMAL is used for least-significant off-normal
          conditions on Page 114.

       o  NORMAL is used for normal alarm unit and summary
          indicators.

     Figure .AW G283/ shows an example of the 1999 page.

     Any available paging command can be entered from the 1999
     display page.

     This subsection contains the master control center (MCC) page
     displays and their descriptions that changed with the 5E7
     software release.  There are no new page displays for 5E7.

     Refer to Table .AW TAF/ for a complete listing of MCC page displays.
     The purpose of the 100 page index is to provide an index of main
     system pages.
     This index is a listing of primary maintenance displays and is
     also an entry point into other subsystem displays, such as trunk
     and line maintenance, equipment configuration data (ECD), and
     office dependent data recent change and verify (ODD RC/V).

     The per-switching module (SM) pages are not shown on this
     display.  The SMs have their own index (1000 - SM PAGE INDEX).

     There is a direct correlation between the page numbers of Pages
     105 through 116 (except 108) and the physical position of the
     status summary indicators in the SUMMARY STATUS AREA.  For
     example, the fifth status summary indicator in the SUMMARY
     STATUS AREA (from left to right) is BLDG/PWR.  Its associated
     display is 105 - BLDG/PWR & ALARM CONTROLS.  Some of the status
     summary indicators do not have an associated display page.
     These are listed on the index as ``NOT ASSIGNED.''  This is a
     built-in trouble-locating shortcut.  The page number for an
     alarm can be derived from the alarmed indicator's position
     without going to this display, although this display is always
     available.

     Information on ODD can be found in AT&T 235-600-105,
     Translations Data Manual.  Also, all RC/V views are described in
     AT&T 235-118-2XX (XX = manual number associated to the
     applicable software release), Recent Change Procedural Manuals.
     Refer to AT&T 235-000-000, Numerical Index - Division 235 and
     Associated Documents, for the complete list of RC/V manuals.

     Information on equipment configuration data/system generation
     (ECD/SG) RC/V can be found in AT&T 235-600-30X (X = manual
     number associated to the applicable software release), ECD/SG
     Data Base Manual.  Refer to AT&T 235-000-000, Numerical Index -
     Division 235 and Associated Documents, for the complete list of
     ECD/SG manuals.

     Pages 196, 198, and 199 (RC/V pages) do not appear when the 100
     Page Index page is displayed at the switching control center
     (SCC) because the RC/V pages cannot be displayed at that
     location.

     Page 118 (CNI STATUS) is shown depending on switch
     configuration.

     Figure .AW G284/ shows an example of the 100 page index.

     The commands on this page can be entered from any display page,
     under normal operation. Also, any available per-SM display can
     be accessed. See 1000 - SM PAGE INDEX (Figure .AW G299/) for details.
 2

       CMD     RESULT

       100     PAGE INDEX is displayed
     105/106   BUILDING/POWER AND ALARM CONTROLS page is displayed
       107     CIRCUIT LIMIT page is displayed
       109     OVERLOAD page is displayed
       110     SYSTEM INHIBITS page is displayed
     111/112   AM, AM PERIPHERALS page is displayed
       113     OPERATIONS SYSTEMS LINKS page is displayed
       114     EQUIPPED SM STATUS SUMMARY page is displayed
       115     COMMUNICATION MODULE SUMMARY page is displayed
       116     MISCELLANEOUS page is displayed
       117     IOP APPLICATION PROCESSOR DATA LINKS page is displayed
       118     COMMON NETWORK INTERFACE FRAME AND COMMON CHANNEL
               SIGNALING LINK STATUS page is displayed
       119     MISCELLANEOUS ALARMS page is displayed
       120     MESSAGES page is displayed
       121     IOP 0 & 1 page is displayed
       122     IOP 2 & 3 page is displayed
       123     DISK FILE SYSTEM ACCESS DFC 0-1 page is displayed
       124     SOFTWARE RELEASE RETROFIT page is displayed
       125     DISK FILE SYSTEM ACCESS DFC 2-3 page is displayed
       126     DFSA PERFORMANCE DFC 0-1 page is displayed
       127     MTIB page is displayed
       128     DFSA PERFORMANCE DFC 2-3 page is displayed
       129     DEFENSE SERVICES NETWORK NM EXCEPTION page is displayed
       130     NM EXCEPTION page is displayed
       131     CALL TRACE MENU page is displayed
       160     TRUNK AND LINE MAINTENANCE INDEX is displayed
       178     AUTO SPARE DISK page is displayed
       179     DISK CONFIGURATION page is displayed
       180     DISK CONFIGURATION page is displayed
       181     OFFLINE SM 1-48 STATUS SUMMARY page is displayed
       182     OFFLINE SM 49-96 STATUS SUMMARY page is displayed
       183     OFFLINE SM 97-144 STATUS SUMMARY page is displayed
       184     OFFLINE SM 145-192 STATUS SUMMARY page is displayed
       190     C/D UPDATE page is displayed
       191     OS STATUS page is displayed
       193     VERIFY TEXT page is displayed
       194     SCREEN page is displayed
       195     GENBACKUP page is displayed
       196     ODD RC/V is started. NOT FOR USE FROM SCC
       197     CUTOVER page is displayed
       198     SG RC/V is started. NOT FOR USE FROM SCC
       199     ECD RC/V is started. NOT FOR USE FROM SCC
      1000     SM PAGE INDEX page is displayed
      1209     ONTC 0 & 1 page is displayed
      1210     MI/NC 0 & 1 page is displayed
      1220     TMS 0 & 1 SUMMARY page is displayed
      1240     MSGS 0 SUMMARY page is displayed
      1250     MSGS 1 SUMMARY page is displayed
      1260     CLNK SUMMARY page is displayed
      1271     REX STATUS page is displayed
      1850     CMP INHIBIT AND RECOVERY CONTROL page is displayed
      1940     EASY BWM INSTALLATION page is displayed
      1950     PROGRAM UPDATE MAINTENANCE MENU page is displayed
      1960     BWM INSTALLATION page is displayed
      1999     STATE DEFINITIONS page is displayed


     The 109 display page provides an indication of resource or
     real-time overloads in the administrative module (AM),
     communication module processor (CMP), and SM(s) and commands to
     inhibit or allow essential service protection (ESP).
     Any AM, SM, or CMP overload conditions are shown on the 109
     display page. The SM and CMP overload information is provided on
     a summary basis.  If an SM overload occurs, the SM number and
     type will be displayed in the indicator and backlighted. If more
     than 16 SMs are in overload, a note will appear, partially
     backlighted, indicating how many SMs are overloaded.  For a
     complete list of SMs in overload, the 900 command should be
     entered.  If a CMP overload occurs, the CMP number and whether
     it is the primary (P) or mate (M) is shown.

     Details on an SM overload can be obtained by entering the
     DISPLAY SM X OVERLOAD INFO command shown on the display.
     Likewise, details on an overloaded CMP can be obtained by
     entering the DISPLAY PRIM CMP X OVERLOAD INFO or DISPLAY MATE
     CMP X OVERLOAD INFO.

     The REALTIME overload indicators will contain NONE, MINOR,
     MAJOR, or CRIT to show the severity of the overload. NONE means
     no overload exists. MINOR and MAJOR are different levels of
     real-time overloads. CRIT (critical) is only used for SMs and is
     the most severe type of overload.

     The only craft action which can be taken during overload
     conditions is to reduce or eliminate input messages/maintenance
     commands. All other actions are initiated by the system.

     For RESOURCE overloads, either NONE or the name of the resource
     will be displayed. The monitored resources are as follows:

       o  MCB - Message Control Block

       o  PCB - Process Control Block

       o  RC/V - Tone Receivers (SM only)

       o  SCB - Stack Control Block

       o  TCB - Timer Control Block

       o  PKB - Packet Buffers [operator services position system
          (OSPS) SMs only]

       o  PSU - Packet Switch Unit (Packet Switching SMs only)

       o  ADB - Analog Data Block (SM only)

       o  APB - Associated Process Block (SM only)

       o  BRCSDB - Business and Residence Custom Services (BRCS) Data
          Block (SM only)

       o  CBDB - Call Buildup Data Block (SM only)

       o  CCBCOM - Channel Control Block (SM only)

       o  CHDB - Channel Data Block (SM only)

       o  CLDB - Calling Leg Data Block (SM only)

       o  DALB - D-Channel Application Linkage Block (SM only)

       o  DIB - Data Interface Block (SM only)

       o  DISPDB - Display Data Block (SM only)

       o  E911DB - Enhanced 911 Data Block (SM only)

       o  MDB - Model Data Block (SM only)

       o  MSG - Message Overflow (because of PIC overload)

       o  PHDB - Path Data Block (SM only)

       o  SCMDB - Shared Call Model Data Block (SM only)

       o  TSDB - Time Slot Data Block (SM only)

       o  PSIB - X-25 Packet Input Buffer (SM only)

       o  IAQ - CMP Input Queue (CMP only).

     Essential Service Protection is normally inhibited. Therefore,
     the INHIBITED text is not backlighted. When allowed, it gives
     preferential treatment to designated lines (for example,
     hospitals, police, fire departments, etc.) during periods of
     overload.

     If there is a network management control on, to prevent
     overloads in this office, the ``SEE PAGE 130'' indicator will
     show up and be backlighted.

     An overload will cause the OVERLOAD indicator at the top of the
     screen to backlight. The associated alarm level (CRITICAL,
     MAJOR, or MINOR) will also backlight, if applicable.

     The AM information box contains information regarding real-time
     and resource overloads in the AM.

     The information provided on Page 109 for the SMs is the SM
     number and type.  For additional information on a specific SM,
     the poke 1300,X is used (where X is the number of the SM).

     Figure .AW G285/ shows an example of the 109 display page with
     specific AM overload information. It also shows up to 16 of the
     SMs and up to 8 of the CMPs that are in overload. The note
     EXCESSIVE is displayed and backlighted because there are greater
     than 16 SMs in overload. The actual number of SMs in overload
     (20) is displayed.

     The SM overload information shows an overload for resource
     E911DB, Enhanced 911 Data Block, a new resource for 5E7.

     Similar to the SM, the CMP has limited information provided on
     Page 109 as shown in Figure .AW G286/.  The information shown is the
     number of the CMP and whether the CMP is the primary or the
     mate.  For more specific information regarding a specific CMP,
     pokes 1370,X for the primary CMP and 1371,X for the mate CMP
     (where X is the number of the CMP) are used.

     Commands are provided to inhibit and allow ESP, to output a list
     of all SMs that are overloaded, and to obtain detailed
     information on an SM overload condition.

     In addition to these commands, any available paging command can
     be entered from Display Page 109.

      CMD     RESULT

      600     Essential Service Protection is inhibited (INH:ESP)
      700     Essential Service Protection is allowed (ALW:ESP)
      900     Output list of SMs in overload on the ROP (OP:OVRLD:ALL)
     1300,X   SM X Overload Information is displayed
     1370,X   Primary CMP X overload information is displayed
     1371,X   Mate CMP X overload information is displayed

     The 110 display page provides a list of system and AM inhibits
     and provides maintenance menu commands for selected inhibits.
     A SYSTEM inhibit applies to the AM and all SMs.  An AM inhibit
     applies only to the AM. Unless stated otherwise, all inhibit
     requests are assumed to be phase-protected.

     Each inhibit indicator on this display has three distinct
     sections: the top line, the description, and the commands-
     available line.

     The top line in each box shows the box number. This line is
     displayed in normal video and the field to the right of the box
     number is blank unless an inhibit has been requested by the
     craft. If an inhibit has been requested, INH, SET, MON, or CHG
     is displayed to the right of the box number, as appropriate, and
     the top line is backlighted. (For the remainder of the 110
     display page description, the result of any of these operations
     is referred to as an inhibit.) The presence of this text and
     backlighting combination means the system has recorded the
     inhibit request. It does not mean the inhibit is in effect.

     Most of the inhibit/allow and set/clear commands are effective
     immediately after the request. For these cases, all areas of the
     indicator backlight together and one of the 3-character phrases
     (INH, SET, MON, or CHG) will appear.  However, in a few cases,
     the status will change independent of the request. An example of
     this is shown in box 21. The behavior of each indicator is
     explained in the Indicators section on the next several pages.

     The middle two lines of the indicator is the inhibit
     description. These two lines show the name of the inhibit as
     well as whether or not an inhibit is in effect. Inhibits can be
     caused by system or craft-initiated actions. When an inhibit is
     in effect, this section will be backlighted. In the SUMMARY
     STATUS AREA, the SYS INH indicator will be backlighted.

     The return of the top line to normal video means that a valid
     request to allow (or clear) an inhibit has been accepted. A
     valid allow request will also cause any text in the area to the
     right of the box number to be blanked.

     The last line of each indicator shows which menu commands, if
     any, are available from the display. For example, at the bottom
     of box 17 the numbers ``6 7 9'' appear. The ``6'' means this
     item can be inhibited by entering  617, the ``7'' means it can
     be allowed by entering  717, and the ``9'' designates output is
     available with  917. On color MCCs, there is also color mapping
     from the commands shown on the left of the display to the
     numbers in the boxes. Boxes without commands listed are
     inhibited only by the system or from manual action independent
     of this display page.

     Following is the correspondence between the number key and the
     action taken:

        Number   Action

          4      Set
          5      Clear
          6      Inhibit
          7      Allow
          9      Output

     This paragraph describes the individual indicators and their
     behavior.

     Box 00 - Box 00 is not currently used.

     Box 01 - Message Class Brevity Control

     This indicator shows whether or not the automatic output message
     class brevity control is inhibited. Brevity control is used to
     restrict the generation of certain application output messages
     for both the AM and equipped SMs. Inhibiting message class
     brevity control permits normally suppressed messages to go to
     the ROP or the log file.

     The message class brevity control inhibit must be entered with
     the teletypewriter (TTY) input message INH:BREVC,MSGCLS=a.
     Since a named MSGCLS is required, a menu command is not
     provided.  Inhibiting brevity control for one or more MSGCLSs
     may cause increased communication link traffic which can degrade
     call processing performance and capacity. (See AT&T 235-600-700,
     Input Messages Manual.) The request will display INH when
     recorded.  This inhibit will take effect immediately with the
     request.

     Entering allow command 701 generates the message
     ALW:BREVC,MSGCLS=ALL. The request will clear the text INH when
     recorded. This allow will take effect immediately with the
     request.

     This inhibit is cleared by any high-level AM initialization.

     Box 02 - Message Class Log/Print Status

     The box 02 indicates that at least one message class has the
     log/print status that is different from the backup status.

     To change the log/print status for one or all message classes,
     enter input message CHG:LPS,MSGCLS={a|ALL} with additional
     parameters.  (See AT&T 235-600-700, Input Messages Manual.)  The
     request will display CHG when recorded. This change will take
     effect immediately with the request.

     Entering the menu command 902 generates the input message
     OP:LPS,MSGCLS=ALL and causes the status of the message classes
     to be printed at the ROP.

     Box 03 - MDII Reporting

     The machine-detected interoffice irregularity (MDII) indicator
     is backlighted when one or more MDIIs are inhibited. The
     inhibits are generated by the TTY input message INH:MDII with
     additional parameters. When the inhibit is invoked, it
     suppresses the printing of MDIIs for the trunk group(s)
     specified by the input message. The request will display INH
     when recorded. This inhibit will take effect immediately with
     the request.

     Entering the 903 command generates the message OP:MDII, which
     causes a listing of all suppressed trunk MDIIs to be printed at
     the ROP.

     Box 04 - Manual Recent Change

     This indicator shows whether or not manual entering of recent
     changes is inhibited.

     When the command 604 is entered, the message INH:RC is
     generated. The request will display INH when recorded. This
     inhibit will take effect immediately with the request.

     The allow command 704 generates the message ALW:RC. The request
     will clear the text INH when recorded.

     Since the Automatic Customer Station Rearrangement (ACSR)
     feature depends upon Recent Change, if Recent Change is
     inhibited, ACSR is also inhibited.  During manual inhibits of
     Recent Change, the RC box (box 04) is illuminated and the CORC
     box (box 05) is partially illuminated.

     Box 05 - Customer-Originated Recent Change (CORC)

     The box 05 indicator shows whether CORCs are inhibited.

     Box 05 is shared by CORCs and the ACSR feature.  Since the ACSR
     feature depends upon Recent Change, if Recent Change is
     inhibited, ACSR is also inhibited.  During manual inhibits of
     Recent Change, the RC box (box 04) is illuminated and the CORC
     box (box 05) is partially illuminated.

     When a 905 command is entered, ACSR queuing is inhibited and
     CORCs are allowed.

     Box 06 - Recent Change Logging

     The box 06 indicator shows whether or not the logging of
     manually entered recent changes for all processors is inhibited.
     This does not include customer-originated recent changes. Recent
     Change logging may be inhibited in the event logging is causing
     a problem, thereby allowing recent changes to be entered.
     Unlogged changes are lost after a boot.

     Entering the command 606 generates the message INH:RCLOG. The
     request will display INH when recorded. This inhibit will take
     effect immediately with the request.

     Entering the command 706 generates the message ALW:RCLOG. The
     request will clear the text INH when recorded.

     Box 07 - Box 7 is not currently used.

     Box 08 - Communication Link Normalization

     If a fault occurs in one or more SM communication links, the
     system will automatically try to restore the link(s) on a
     periodic basis. This inhibit will suppress this action when
     active.

     Entering command 608 will generate the message INH:CLNORM. The
     request will display INH when recorded. This inhibit will take
     effect immediately with the request.

     When the command 708 is entered, it generates the message
     ALW:CLNORM. The request will clear the text INH when recorded.

     Since attempts to restore CLNKS are periodic, there may be a
     delay from the time an allow or inhibit request is recorded
     until the allow or inhibit is recognized.

     Box 09 - Centralized Automatic Message Accounting (CAMA)
     Suspension

     The box 09 indicator shows whether or not calls are being routed
     through the CAMA operator number identification (ONI) process
     for billing.  Since inhibiting this indicator causes lost
     revenue, a minor alarm is sounded when the inhibit is invoked.

     Entering the command 609 generates the message INH:CAMAONI. The
     request will display INH when recorded. This inhibit will take
     effect immediately with the request.

     Entering the command 709 generates the message ALW:CAMAONI. The
     request will clear the text INH when recorded.

     Box 10 - Trunk Hold

     The box 10 indicator shows whether or not one or more trunk
     groups are being monitored.

     To monitor one or more trunk groups, the input message MON:TRUNK
     must be entered. The request will display MON when recorded.
     This monitoring will take effect immediately with the request.

     The system looks for stop-go signaling failures in members of
     monitored group(s). If a failure occurs, the member is held
     off-hook and out of service for the craft to determine the
     nature of the failure.

     The input message CLR:TRUNK is entered to remove the stop-go
     signaling.

       Warning:   This message will return all members back to
                  service, even if they failed.  The request will
                  clear the text MON when recorded.

     Entering the 910 command generates the input message OP:TRUNK,
     which causes a listing of all trunk groups and members being
     monitored to be printed at the ROP.

     Boxes 11 Through 15 -  Boxes 11 through 15 are not currently
     used.

     Box 16 - Routine Audits

     The box 16 indicator shows if the automatic routine execution of
     one or both AM application audit cycles (OKP or SMKP) are
     inhibited.

     The only way to obtain a single audit inhibit is via a TTY input
     message in the message mode. (See INH:AUD=a,ENV=b in AT&T 235-
     600-700, Input Messages Manual.) Single inhibits are not phase
     protected.

     Entering the 616 command requests the inhibit of all audits and
     generates the message INH:AUD=CYCLE,ENV. The request will
     display INH when recorded. The request state does not
     necessarily imply that the inhibit is in effect. Normally, the
     status will follow the request within a short period of time.

     If the 716 command is entered, the message ALW:AUD=CYCLE,ENV is
     sent. The request will clear the text INH when recorded. The
     request state does not necessarily imply that the inhibit has
     been cleared. Normally, the status will follow the request
     within a short period of time.

     The command 916 (OP:AUD,STATUS=ALL,ENV=a) can be entered to get
     the ROP listing of routine audit status for the application AM.

     Box 17 - Routine Exercises

     The box 17 indicator shows if any or all of the application
     routine hardware exercises are inhibited in the communication
     module (CM).  Inhibits for routine exercises are effective for
     only one exercise session. If the tests are in progress when the
     message is received, the inhibit will not take place until the
     next session.

     Routine exercises are scheduled to run at specific times (for
     example, daily at midnight). If inhibited exercises are allowed
     after the scheduled time, the exercises are not started until
     the next scheduled session.

     When 617 is entered, the message INH:REX,CM is generated, which
     inhibits all application CM routine exercises. The request will
     display INH when recorded. This inhibit will take effect
     immediately with the request.

     If the command 717 is entered, the message ALW:REX,CM is
     generated, which allows all application CM routine exercises.
     The request will clear the text INH when recorded.

     Entering the command 917 sends the message OP:REXINH,CM, which
     generates a status listing at the ROP.

       Note:   These are application routine exercises and are
               different from the routine exercises for the AM, as
               shown on the EAI display.

     Box 18 - Software Checks

     The box 18 indicator reflects whether or not the AM application
     software checks have been inhibited. The AM software checks and
     the application software checks are different, but are
     controlled together from manual commands.

     The box 18 indicator can only be controlled from the EAI or TTY
     input message INH:SFTCHK.  This inhibit will prevent internal
     software checks from causing initializations.

     Entering the 618 command requests the inhibit of internal
     software checks and generates the message INH:SFTCHK.  The
     request will display INH when recorded.  The request state does
     not necessarily imply that  the inhibit is in effect.  Normally
     the status will follow the request within a short period of
     time.

     If the status is inhibited without being requested, the inhibit
     was automatically applied by the system.

     If the 718 command is entered, the message ALW:SFTCHK is sent.
     The request will clear the text INH when recorded.

     Box 19 - Min-Mode

     The box 19 indicator shows the states of application min-mode.
     When this box is backlighted, no call processing functions are
     allowed in the AM. This is only used in extreme emergencies to
     prevent customer actions from interfering with machine
     operations.

     Min-mode is invoked and deleted via EAI application pokes ``M''
     and ``N,'' respectively.

     The request will display INH when recorded. This inhibit will
     take effect immediately with the request following the next
     major AM initialization.

     The request will clear the text INH when recorded and take
     effect on the next major AM initialization.

     Box 20 - Message Brevity Control

     The box 20 indicator gives inhibit status of message brevity
     control for all messages originating from the application
     processes in the AM only.

     Entering inhibit command 620 generates the message INH:BREVC,AM.
     The request will display INH when recorded. This inhibit will
     take effect immediately with the request.

     Entering the allow command 720 generates ALW:BREVC,AM. The
     request will clear the text INH when recorded.

     This inhibit is cleared by any high-level AM initialization.

     Box 21 - Recent Change Backout

     The box 21 indicator shows whether or not uncommitted (recently
     entered) AM recent changes are loaded or backed out. Backout can
     only occur as a result of an AM high-level initialization.

     The description portion shows when the recent changes are
     actually backed out or loaded. If the backout is in progress, a
     number will appear on the third line of the box showing the
     progress of the backout. From 200 down to 100 is CORC backout;
     200 meaning CORC is still fully backed out and 100 meaning CORC
     is fully rolled forward. From 100 down to 0 is RC backout; 100
     meaning RC is still fully backed out and 0 meaning RC is fully
     rolled forward. Recent changes can be backed out only in
     conjunction with a high-level initialization.

     Recent changes should be backed out if a recent change is
     suspected to be the cause of an AM performance problem.

     When the command 421 is entered, the message SET:BACKOUT,RC,AM
     is generated. The request will display SET when recorded. The
     request state does not necessarily imply that the set is in
     effect.

     When the command 521 is entered, the message CLR:BACKOUT,RC,AM
     is sent. The request will clear the text SET when recorded. The
     request state does not imply that the backout has been cleared.

     Box 22 - Emergency Action Interface/Miscellaneous Checks

     The box 22 indicator shows if Emergency Action
     Interface/Miscellaneous checks are inhibited.  This box includes
     hardware and error interrupts inhibits from the Emergency Action
     Interface page and also error source inhibits.

     When one of the messages INH:ERRINT or INH:ERRSRC is input, it
     will cause the box to backlight.  This box will also backlight
     if error interrupt is inhibited on the Emergency Action
     Interface page.  Input messages ALW:ERRINT or ALW:ERRSRC will
     allow the respective inhibits.

       Note:   The lower portion of this box is lighted only if
               all error interrupt inhibits have been inhibited or
               error source inhibits are inhibited.  If error
               interrupt checks are allowed unit by unit, the
               indicator will not be cleared.

     When the command 922 is entered, the message OP:ERRCHK is sent.
     This generates a listing of the active inhibits.

     Box 23 - Routine Maintenance

     This indicator reflects whether or not a routine maintenance
     function is inhibited.  Should routine maintenance functions be
     inhibited for an extended period of time, various system
     resource availability and consistency may be adversely affected.

     This indicator monitors the AM's Generated Key Collection and
     Compression Routine inhibit status.  If the routine is
     inhibited, the description is backlighted.

     When the 623 command is entered, the message INH:GKCCR,AM is
     sent which requests that automatic executions of the Generated
     Key Collection and Compression Routine be inhibited.

     Entering command 723 generates the command ALW:GKCCR,AM which
     requests that automatic periodic execution of the Generated Key
     Collection and Compression Routine be allowed.

     Box 24 - Hardware Checks

     The box 24 indicator shows whether or not the AM/CM application
     hardware checks have been inhibited.  This indicator can only be
     controlled from the EAI or by TTY input message INH:HDWCHK.
     This inhibit will prevent maskable hardware faults from causing
     recovery.

     Entering the 624 command requests the inhibit of maskable
     hardware faults and generates the message INH:HDWCHK.  The
     request will display INH when recorded.  The request state does
     not necessarily imply that the inhibit is in effect, since the
     status will follow the request within a short period of time.

     If the status is inhibited without being requested, the inhibit
     was automatically applied to the system.

     When the 724 command is entered, the message ALW:HDWCHK is sent.
     The request will clear the text INH when recorded.

     Boxes 25 Through 27 -  Boxes 25 through 27 are not currently
     used.

     Figure .AW G287/ is an example of the 110 page display which shows one
     system inhibit set and two AM inhibits set. Routine Exercises in
     box 17 has been inhibited. Box 21 shows RC BACKOUT is currently
     set and has been partially backed out (80%). However, the top
     line is normal video and there is no SET text after the 21. This
     indicates that the craft does not desire the recent changes to
     be kept out.

     In addition to the following commands, all available display
     commands can be accessed from Display Page 110.
 2

     CMD   RESULT

     421   RC Backout (AM) is set (SET:BACKOUT,RC,AM)
     521   RC Backout (AM) is cleared (CLR:BACKOUT,RC,AM)
     604   Manual RC is inhibited (INH:RC)
     606   RC Logging is inhibited (INH:RCLOG)
     608   CLNK Normalization is inhibited (INH:CLNORM)
     609   CAMA is inhibited (suspended) (INH:CAMAONI)
     616   Routine Audits (AM) are inhibited (INH:AUD=CYCLE,ENV)
     617   Routine Exercises (CM) are inhibited (INH:REX,CM)
     618   Internal Software Checks are inhibited (INH:SFTCHK)
     620   Message Brevity Control (AM) is inhibited (INH:BREVC,AM)
     623   Routine Maintenance (AM) is inhibited; specifically,
           Generated Key Collection and Compression Routine (INH:GKCCR,AM)
     624   Internal Hardware Checks are inhibited (INH:HDWCHK)
     701   Message Class Brevity Control is allowed (ALW:BREVC,MSGCLS=ALL)
     704   Manual RC is allowed (ALW:RC)
     706   RC Logging is allowed (ALW:RCLOG)
     708   CLNK Normalization is allowed (ALW:CLNORM)
     709   CAMA is allowed (no longer suspended) (ALW:CAMAONI)
     716   Routine Audits (AM) are allowed (ALW:AUD=CYCLE,ENV)
     717   Routine Exercises (CM) are allowed (ALW:REX,CM)
     718   Internal Software Checks are allowed (ALW:SFTCHK)
     720   Message Brevity Control (AM) is allowed (ALW:BREVC,AM)
     723   Routine Maintenance (AM) is allowed; specifically,
           Generated Key Collection and Compression Routine (ALW:GKCCR,AM)
     724   Internal Hardware Checks are allowed (ALW:HDWCHK)
     902   Message Class Log/Print Status is output (OP:LPS<MSGCLS=ALL)
     903   MDII Report is output (OP:MDII)
     905   CORC Status is output (OP:STAT,CORC,ACSR)
     910   Trunk Hold list is output (OP:TRUNK)
     916   Routine Audits (AM) are output (OP:AUD,STATUS=ALL,ENV)
     917   Routine Exercises (CM) are output (OP:REXINH,CM)
     922   Listing of active inhibits is output (OP:ERRCHK)


     The purpose of the 115 display page is to provide a summary of
     off-normal status for the hardware units and links which support
     AM to SM(s) communication and provide paths for all circuit
     switched calls.
     The 115 display page has two separate and distinct versions.
     The first version (Figure .AW G288/) is for offices with communication
     module model 2 (CM2) hardware. The second version (Figure .AW G289/)
     is for offices with CM1 hardware.

     The 115 page provides overall status for MSGS 0, MSGS 1, MI/NC 0
     (MI/LI/NC 0 for CM1), MI/NC 1 (MI/LI/NC 1 for CM1), TMS 0, TMS
     1, communication links for the SMs, fan and fan fuse alarms for
     the ONTCs (for the MSGSs and TMSs for CM1), the status of the
     hardware check inhibit request bit, and the status of the
     MI/NC/TMSs (MI/LI/NC/TMSs for CM1) functioning as a group
     (ONTCCOM).

     The ONTCCOM 0 includes MI 0 (and LI 0 in CM1), NC 0, and TMS 0.
     The ONTC 0 includes ONTCCOM 0 and all DLIs on side 0.  The
     ONTCCOM 1 includes MI 1 (and LI 1 in CM1), NC 1, and TMS 1.  The
     ONTC 1 includes ONTCCOM 1 and all DLIs on side 1.

     If an MSGS, MI/NC (MI/LI/NC in CM1), or TMSLNK has an off-normal
     condition (out-of-service not family of equipment, unavailable,
     hardware checks inhibited), the appropriate indicator with the
     page number of the MCC page with the detailed information is
     backlighted. The phrase ``SEE PAGE XXXX IF BACKLIT'' is
     backlighted when any of the boxes are backlighted to point out
     that the numbers in the boxes are the page numbers to request.
     Note: The 1210 boxes are backlighted only for NC reference or
     oscillator problems.

     The CLNKS indicator is a summary of the equipped SM
     communication links status which is detailed on Page 1260.

     The CLNKs are not TMSLNKs.  A CLNK is a communication path
     between the AM and an SM which passes through an MSCU, MMP, TMS,
     TMSLNK, and DLI.  The TMSLNKs connect the TMS to the DLI.

     The backlighted indicator shows the page necessary for acting on
     the problem.  As an example, the box with 1242 indicated is
     backlighted in Figure .AW G288/ because a module message processor
     (MMP) on Display Page 1242 is shown as out of service (OOS).
     The MMP out of service is also reflected on the MSGS 0 Page
     1240, but going to 1240 would not be the final step to see and
     act on the problem so the MSGS 0 box with 1240 indicated is not
     backlighted. If a foundation peripheral controller (FPC) or pump
     peripheral controller (PPC) was out of service also, then the
     MSGS 0 box would backlight as shown in Figure .AW G289/. The purpose
     of this strategy is to get the craft directly to the problem
     with minimum paging.  Therefore, if the 1240 (MSGS 0) box and
     the 1241 (or 1242) were both backlighted, an out of service (not
     family of equipment), an unavailable, an out-of-service power,
     or an unavailable power condition would exist in an MMP and an
     FPC, PPC, or MSCU.

     The TMS 0 and 1 boxes (indicating Page 1220) will never
     backlight. If a TMS is OOS, it would be due to the whole ONTC
     being OOS or UNV; therefore, 1209 is the appropriate page to
     display.

     Figure .AW G288/ shows an example of the CM2 Version with problems in
     MI/NC 1, MSGS 0, TMS 0, CLNKS, and ONTC 1.  Further information
     on these problems would be found on display 1210 - MI/NC 0 & 1,
     1242 - MSGS 0 - COMMUNITIES 2 - 7, 1221 - TMS 0 TMS LINKS 002 -
     063, 1260 - CLNK SUMMARY, and 1209 - ONTC 0 & 1. There is a fan
     alarm on ONTC 0, and the ONTC 1 fan fuse alarm is inhibited.

     Figure .AW G289/ shows an example of the CM1 Version with problems in
     MI/LI/NC 1, MSGS 0, TMS 0, CLNKS, and ONTC 0.  Further
     information on these problems would be found on displays 1210 -
     MI/LI/NC 0 & 1, 1240 - MSGS 0 SUMMARY, 1221 - TMS 0 - TMS LINKS
     002 - 063, 1260 - CLNK SUMMARY, and 1209 - ONTC 0 & 1. There is
     a fan alarm on MSGS 0 and the TMS 0 fan fuse alarm is inhibited.
     The FPC DPLF indicator is signaling that FPC duplex failure is
     in effect.

     There are no menu commands on the 115 display page. Commands for
     removing, restoring, diagnosing, etc., are listed on the related
     pages. There are no menu commands on the displays for fans or
     fan fuses. For fans or fan fuses, see CLR:FANALM in AT&T 235-
     600-700, Input Messages Manual.

     All available display commands can be entered from the 115
     display page.
     The 116 display page provides status for various
     units/activities which do not fall under any other grouping.
     The External Sanity Monitor (ESM) has indicators for alarm,
     inhibit, and power. If an alarm or an inhibit is present, the
     appropriate indicator will backlight. If power is off, the POWER
     indicator will backlight and the word OFF will be displayed.

     The CALL MONITOR indicator shows whether the Call Monitor is
     inhibited or allowed.  Entering the command 601 generates the
     message INH:CALLMON which will inhibit the monitor from making
     test calls and performing call completion analysis.  This also
     clears the monitor's history data.  The command 701 generates
     the message ALW:CALLMON which allows the monitor to start the
     cycle of making test calls and performing call completion
     analysis.  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 generates the
     OP CALLMON PAST 15 MINUTE REPORT on the ROP.

     The indicators FRAME FUSE and FRAME FAN are for the
     miscellaneous frame.  If a fuse or fan alarm is present on the
     miscellaneous frame, the corresponding indicator will backlight.
     The fuse must be replaced to correct the frame fuse alarm.  The
     fan must be restored to operating condition to correct the frame
     fan alarm.  The input command CLR:FANALM,MFFAN can be entered to
     clear the frame fan alarm after the alarm condition is fixed.
     If a system inhibit is present, the word INH will be displayed
     and backlighted to the right of the indicator label.  The fuse
     and fan alarms can only be inhibited by the system.  An inhibit
     means a scan point is chattering.  The input command
     ALW:ALM,MFFAN can be entered to allow the scan point after the
     chattering problem is fixed.

     The indicator GENERIC RETROFIT will backlight and change to
     GENERIC RETROFIT ACTIVE when software release (generic) retrofit
     is in progress.

     The indicator ODD EVOL will backlight and change to ODD EVOL ACT
     when ODD Evolution is in progress. ODD Evolution is initiated by
     the command BKUP:ODD,ODDEVOL and stays in effect until the
     actual software release cutover takes place.

     The indicator OSPS EVOL will backlight and change to OSPS EVOL
     ACT when OSPS Evolution is in progress.  The OSPS Evolution is
     initiated by the command BKUP:ODD,ODDEVOL if the office has an
     OSPS configuration active.  It stays in effect until the actual
     software release cutover takes place.

     The indicator ODD WARNING will backlight when either the amount
     of ODD space being used has exceeded the engineering
     recommendations for the AM or the automatic relation engineering
     reorganization process has failed on one or more relations in
     the AM.  Entering the command 902 generates the input message
     OP:ODDWARN,AM which will generate the OP ODDWARN output message
     on the ROP.

     The RC BACKUP indicator normally says NORMAL on the right part
     of the indicator. If RC Backup fails in the AM, the text NORMAL
     changes to FAILURE and the entire indicator backlights.

     The MISCELLANEOUS ALARMS indicator has two subindicators: ALARM
     and INHIBIT.  These subindicators are backlighted for any alarm
     and/or inhibit conditions present on the MISCELLANEOUS ALARMS
     display.  For additional information, enter command 119.

     The next indicator, MTIB, will backlight if an off-normal
     condition exists on the MTIB display. Enter command 127 for
     further details.

     In the CUTOVER indicator, the word ACTIVE will backlight if an
     off-normal condition exists on the CUTOVER display (cutover
     enabled, for example). Further information can be found on
     display 197 - CUTOVER.

     Any off-normal condition will cause the MISC indicator in the
     SUMMARY STATUS AREA at the top of the screen to backlight.

     Figure .AW G290/ is an example of the 116 display page which shows an
     alarm and an inhibit present on 119 - MISCELLANEOUS ALARMS.
     There is also something off-normal on Page 127 - MTIB STATUS.
     These have caused the MISC status summary indicator at the top
     of the screen to backlight.

     Commands are provided to inhibit and allow the ESM and to clear
     (retire) the exit pilot lamps.  Commands are also provided to
     inhibit and allow the call monitor, output the past 15-minute
     interval history for the call monitor, and retire a call monitor
     alarm.

     Also, all available displays can be accessed from the 116
     display page.

     CMD   RESULT

     600   External Sanity Monitor is inhibited (INH:ALM,ESM)
     601   Call Monitor is inhibited (INH:CALLMON)
     700   External Sanity Monitor is allowed (ALW:ALM,ESM)
     701   Call Monitor is allowed (ALW:CALLMON)
     800   Exit Pilot Lamps are cleared (retired) (CLR:LAMPS)
     801   Call Monitor alarm is retired (RTR:CALLMON,ALARM)
     901   Call Monitor history is output (OP:CALLMON)
     902   ODD WARNING information is output (OP:ODDWARN,AM)

     The purpose of the 117 page display is to provide a summary of
     information associated with the application processor data links
     (APDL).
     The 113 page indicates that maintenance personnel can display
     the 117 page, if desired.

     The following items contain detailed information concerning each
     field in the 117 page display:

       o  LINK:  This field identifies the link by name (for example,
          APDL01).  The 01 attached to the APDL is the link number of
          the link that is added to tuple relation RLCMAPDATA.  The
          link number is between 1 and 6 that corresponds to the
          number assigned to that link via the RC/V view 24.1.

       o  PORT:  This field indicates the data link connected to the
          administrative module-input/output processor (AM-IOP).

       o  MODULE:  This field indicates the data link is connected to
          the AM-IOP.

       o  DEVICE:  This field ide