Diagnostics and Testing

8/13/2019 Diagnostics and Testing

http://slidepdf.com/reader/full/diagnostics-and-testing 1/48

Diagnostics and Testing

DN9772298Issue 6-1 en

# Nokia Corporation 1 (48)

BSC3119

Nokia BSC/TCSM, Rel. S12, Product

Documentation, v.1



The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This document is intended for the useof Nokia's customers only for the purposes of the agreement under which the document issubmitted, and no part of it may be reproduced or transmitted in any form or means without the

prior written permission of Nokia. The document has been prepared to be used by professionaland properly trained personnel, and the customer assumes full responsibility when using it.Nokia welcomes customer comments as part of the process of continuous development andimprovement of the documentation.

The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding butshall be defined in the agreement made between Nokia and the customer. However, Nokia hasmade all reasonable efforts to ensure that the instructions contained in the document areadequate and free of material errors and omissions. Nokia will, if necessary, explain issueswhich may not be covered by the document.

Nokia's liability for any errors in the document is limited to the documentary correction of errors.NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENTOR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARYLOSSES), that might arise from the use of this document or the information in it.

This document and the product it describes are considered protected by copyright according tothe applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

Other product names mentioned in this document may be trademarks of their respectivecompanies, and they are mentioned for identification purposes only.

Copyright © Nokia Corporation 2007. All rights reserved.

2 (48) # Nokia Corporation DN9772298Issue 6-1 en




Contents

Contents 3

List of tables 5

List of figures 6

Summary of changes 7

1 Diagnostics and testing system 11

2 Diagnostic procedures in normal failure situations 132.1 How to repair a failure by replacing a plug-in unit 142.2 How to use partial tests when replacing plug-in units 15

3 Diagnostic procedures in special failure situations 17

4 Changes in unit states during a diagnosis 19

5 General initial conditions for diagnoses 215.1 Procedures in fault situations of the diagnostic system 21

6 Total and partial unit tests 236.1 General instructions on total and partial unit tests 24

7 Partial diagnoses 25

8 Operating instructions for partial unit tests 27

9 Diagnosing a unit 31

10 Diagnosing I/O devices 3510.1 Diagnosing a hard disk unit 3510.2 Diagnosing a cartridge tape unit 3610.3 Diagnosing a removable disk unit 36

11 Total testing after replacing a plug-in unit 37

12 Partial testing after replacing a plug-in unit 41

13 Fault localising based on unit-specific hardware alarms 4313.1 CLAB 4313.2 CLS 4313.3 ET 4313.4 MCMU 4413.5 BCSU 4513.6 MB 4513.7 OMU 4613.8 TCSM 46



Contents



14 Fault localising based on alarms from peripheral devices 4714.1 CTU 4714.2 FDU 4714.3 LPT 47

14.4 VDU 4714.5 WDU 47





List of tables

Table 1. Switching network diagnostics - M/CAC/MCMU/MCHU/SCU (SWCOP as

controller card) 25

Table 2. Processor diagnostics 26



List of tables



List of figures

Figure 1. Changes in unit states 19

Figure 2. Interdependencies between partial diagnoses in processor diagnostics 28

Figure 3. Interdependencies between partial diagnoses in switching networkdiagnostics 29





Summary of changes

Changes between document issues are cumulative. Therefore, the latest document

issue contains all changes made to previous issues.

Changes made between issues 6 –1 and 6 –0

Changed the appendices Fault localising based on unit-specific hardware alarms

and Fault localising based on alarms from peripheral devices into normal

chapters. Removed the alarms 1037, 1046, 1059, 2172, 2746, 2825 and 2826

from those chapters because they are not included in the S11 release.

Changes made between issues 6 –0 and 5 –2

Changed the structure of the document. The chapters were broken into smaller

pieces with one subject matter in one chapter.

Appendix Diagnostic program numbers was removed.

Diagnostics and testing system

Listed more clearly the ways of locating the plug-in unit failures.

Diagnostic procedures in normal failure situations

Changed the name of the chapter from Diagnostics in normal failure situations .

Corrected the name of the partial diagnosis from DMC to SYSB. Added sections

How to repair a failure by replacing a plug-in unit and How to use partial tests

when replacing plug-in units .

Diagnostic procedures in special failure situations

Changed the name of the chapter from Diagnostics in special failure situations .

Added references to alarm documentation and alarms to help locate faults in plug-

in units and failures in a power supply unit.



Summary of changes



General initial conditions for diagnoses

Changed the name of the chapter from Initial conditions for diagnoses . Added the

WTP and WTI commands. Changed the name of the subsection Fault situations

of diagnostic system to Procedures in fault situations of the diagnostic system .

Total and partial unit tests

Added the UDU command. Changed the name of the subsection Using a total or

partial unit test to General instructions on total and partial unit tests .

Partial diagnoses

Changed the name of the DMC partial diagnosis to SYSB in the table Processor

diagnostics . In the same table, corrected the list of plug-in unit types tested by the

SYSB and PROC partial diagnoses: removed plug-in units BEXT, DMADI, LSP,LSP-S, SWTST and TAPI and added the plug-in units SWCOP(-S) and HWAT.

Removed MTU from the list of peripheral devices because it is not used in BSC.

Operating instructions for partial unit tests

Changed the name of the chapter from Objective for partial unit tests . Corrected

the figure Interdependencies between partial diagnoses in processor diagnostics :

DMC test was changed into SYSB test.

Diagnosing a unit

Added the step Start a unit test and added a comment to the note that ET2E and

EC2Et plug-in units should be in the TE state before starting the test. Added steps

2 – 6.

Diagnosing I/O devices

Removed MTU from the list of peripheral devices because it is not used in BSC.

Added information that the functional status of the I/O device to be diagnosed

must be TE-ID. Removed the section Diagnosing a magnetic tape unit . Changed

the name of the subsection Diagnosing a floppy disk drive to Diagnosing a

removable disk unit .

Appendix Fault localising based on unit-specific hardware alarms

Modified the listing of the plug-in units: “CLG-x” was changed into “CLG (all

variants)”. The same changes were made to other similar cases.

CLS





Added the alarm 2172.

ET

Added the alarms 1037, 2737, 2738, 2746 and 2747. Added “AS7 (all variants)

or in the switching matrix” to alarm 2202.

MCMU


OMU


Appendix Fault localising based on alarms from peripheral devices

CTU

Added “CPxxxx” to alarms 1885 and 1886.

FDU

Corrected the name from FDD .

LPT

Added the alarms 2825 and 2826.

VDU

In the alarms 2403 and 2800, added “(all variants)” to SERO and added SCSIF.

WDU

Corrected the name from WDD . Added “CPxxxx” to alarms 2860 and 2861.

Removed DMADI and DMASI from the same alarms.



Summary of changes







1 Diagnostics and testing system

The first task of the diagnostics and testing system is to locate hardware failures

in the network element, with an accuracy equivalent to the maintenance

requirements. The second task is to verify that the hardware is functioning

properly.

If errors occur, the system generally informs you of the necessary actions by producing a text diagnosis with fixed headers.

The software automatically detects failures and produces a diagnostic report or an

alarm printout on them. One way to repair the fault is to replace the plug-in unit

that the report shows to be faulty. Another way is to determine the location of the

failure according to the instructions in the following sources:

. the outputs of the network element

. alarm descriptions and instructions

. troubleshooting instructions

. Instructions for replacing plug-in units

When you have repaired the fault, verify that the network element is in working

order by issuing a test command which activates the tests of the repaired unit.

After this, transfer the repaired unit into its normal working state so that it can

perform the tasks assigned to it.

The diagnostic work done by the system is directed to the functional units of the

system (total diagnoses) or to functional entities of the system as seen from the

point of view of diagnostics (partial diagnoses). A total diagnosis is divided into partial diagnoses and the partial diagnoses further into diagnostic programs. For

detailed descriptions of the specific commands in the command group UD, see

Diagnostics Handling .

The diagnostic system can be divided into a control part and an execution part.

The control part is located in the operation and maintenance computer OMU (or

when there is only one OMU which is under testing, in a CM type unit), whereas

the execution part is distributed among all functional units in the network

element.



Diagnostics and testing system







2 Diagnostic procedures in normal failure

situations

The diagnostic system function is activated when a diagnostic report with fixed

headers, like the one in the following example, is received:

DX220 DX220-BSC 2002-02-13 15:12:13D I A G N OS T I C R E P O R T

BCSU-0 1A089-00

PARTIAL DIAGNOSIS SYSB

DIAGNOSTIC PROGRAM 0008

DIAGNOSIS 0002

0 7 25 D I AG N OS I S E X E C UT E D - U N IT N O T O K

E N D O F D I AG N OS I S

D I A G N OS T I C R E P O R T

BCSU-0 1A089-00

PARTIAL DIAGNOSIS SYSB

DIAGNOSTIC PROGRAM 0008

DIAGNOSIS 0002

EXTRA INFO 1 00 01

EXTRA INFO 2 00 11

3 7 25 A C CU S ED P L UG I N U N IT S :

TYPE IN DEX LOCAT ION TRACK

MBIFT 001 1A089 -00 4

L O C A T IO N F I E L D:

+--------- -- RO W 1...64 DE CIMAL NUMB ER

! +--------- RACK A...Z AL PH ABE T! !+-------- HEIGHT 1...255 DECIMAL NUMBER

! ! ! + -- -- D IS PL AC EM EN T 0 .. .9 9 D EC IM AL N UM BE R

! !! !

NNCNNN-NN

The diagnostic report contains the following important fields:






LOCATION shows where a faulty plug-in unit subrack or cartridge is

located.

ROW shows which rack row is in question.

RACK shows the location of the rack in the rack row (A is thefirst rack from the left).

HEIGHT shows the height of the subrack or the shelf. The height

can be determined at the bottom end of the subrack, or the

shelf on a scale that you can find on the side of the rack.

DISPLACEMENT shows the subrack's or cartridge's displacement from the

left-hand side of the shelf.

TRACK shows the track number of the faulty plug-in unit in a

subrack or cartridge.

The diagnostic system aims at locating failures to an accuracy of one plug-in unit.

When this is not possible, the system produces a list of suspected plug-in unitsalong with the faulty one. The system lists the suspected plug-in units in the order

of probability.

The diagnostic system generates a diagnostic report after it has carried out a total

diagnosis of the functional unit. At the same time, the system transfers the faulty

functional unit into the out-of-use state (SE-OU). This makes it safe to replace the

plug-in units.

For more information, see Diagnosing a unit , Diagnosing I/O devices and

Diagnostic procedures in special failure situations.

2.1 How to repair a failure by replacing a plug-in unit

To repair a failure, replace the suspected plug-in unit in the manner described in

the instructions of Instructions for replacing plug-in units. If several plug-in units

are suspected of being faulty, start replacing plug-in units from the first one on the

list.

After replacing a plug-in unit, bring the unit back into the test state using the USC

command.

To make sure that the repair operation was successful, test the unit using the UDU

command. You can monitor the progress of testing with occasional enquiries (the

UDQ command) to the diagnostic system or via intermediate printouts that are

printed out on the alarm printer. The intermediate printouts give information

about the partial diagnoses. The total test of a unit may take from less than a

second up to half an hour, depending on the hardware configuration of the unit

(the duration can be multiplied by increasing the number of test repetitions

through file parameters).



http://-/?-

http://-/?-



If no faults are found in the total test, the following text is printed out on the

printer:

T O TA L D I AG N OS I S E X EC U TE D - U N IT O K

The message indicates that the system has registered the unit as operational.

2.2 How to use partial tests when replacing plug-inunits

When the list of suspected plug-in units is long, you can speed up the repair

operation by starting the partial test (instead of the total unit test) that detected the

fault. The name of the partial test is shown in the PARTIAL DIAGNOSIS NAME

field of the diagnostic report. If the diagnosis now shows that the unit is in

working order, it is likely that the repair action was successful. The system does,

however, leave the unit in the faulty (FLTY) functional state , from which you can

transfer it into the operational state by starting the total diagnosis for the unit with

the UDU command.

If replacing a plug-in unit does not help and the same diagnosis recurs, reinstall

the old plug-in unit where it was originally, and replace the next plug-in unit on

the list of suspected plug-in units.

In error situations, the total diagnosis of a unit ends in a diagnostic report or in an

alarm. But if you receive the message TOTAL DIAGNOSIS EXECUTED -UNIT OK, you can bring the unit from the test state (TE) back to its normal

working state (SP or WO) using the USC command.

For more information, see Instructions for replacing plug-in units and

Diagnosing a unit .










3 Diagnostic procedures in special failure

situations

If the system cannot perform the diagnosis for some reason, a text diagnosis is

printed out on the alarm printer. For example, a loop test of the voice

announcement generator (VANG) could fail because the loop cannot be

established. In such a case the diagnostic system cannot decide whether the testedunit is in working order or not. The text diagnoses resemble alarms in that they

have a number and fixed headings. The text diagnosis describes the observed

failure in words and often contains instructions. It can also contain a list of

suspected plug-in units, but not necessarily. Also alarm printouts give information

on the need for maintenance activities.

The repair actions that the alarms and text diagnoses call for are described in the

alarm descriptions. If you cannot locate the failure using diagnostic commands,

refer to the alarm printouts and alarm descriptions.

For instructions on printing out alarms, see Alarm administration .

If you need to locate a fault on the basis of alarms, see also Fault localising based

on unit-specific hardware alarms and Fault localising based on alarms from

peripheral devices.

Failures in a power supply unit can be located so accurately that you can repair

the fault immediately by replacing the faulty plug-in unit. For more information,

see Instructions for replacing plug-in units.

Alarm descriptions contains instructions also for cases when a unit has failed to

such extent that it is dead (for example, diagnostic report 3726).

For more information, see Diagnosing a unit , Diagnosing I/O devices and

Diagnostic procedures in normail failure situations.



Diagnostic procedures in special failure situations

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-







4 Changes in unit states during a

diagnosis

The following changes in the unit states are associated with automatically

executed diagnostics, see the figure below:

* Partial diagnosis does not find a fault and recovery has previously registered the

unit faulty.

Figure 1. Changes in unit states

1. The object of diagnostics is in the TE state.

2. At the start of the diagnostics, the IN TEST state data of the unit is placed

in the state file maintained by the recovery system, or the peripheral device

is transferred from the TE-ID state into the TE-AC state.

3. If a fault is located, the unit state changes to the SE-OU state.

TE

TEin test

TEfaulty

SEfaulty

Testbegins

Testbegins

Faultlocated

*

Total diagnosis does notfind a fault

Plug-in unitreplaced

COMMAND



Changes in unit states during a diagnosis



4. If the total test does not find a fault, the faulty (FLTY) flag of the unit is

cleared (if the system has set it on earlier) and the unit state changes to the

SP-EX state.

5. Finally, the control of the unit is returned to the recovery system.





5 General initial conditions for diagnoses

A failure can only be diagnosed in a unit when it is in the test state (TE).

The recovery system must completely transfer the control of the unit to the

diagnostic system for the duration of the diagnosis.

In order to know the exact object of the test, the diagnostic system must have

access to the hardware description in the equipment database. The hardware

description shows the details of the unit down to each single plug-in unit. The

database is supplied, with all necessary data entered into it, together with the

software. If you modify the hardware (for example, by adding a plug-in unit), you

must update the hardware description accordingly.

Update the hardware description using the MML programs for hardware

description handling. The WTP command can be used to add a plug-in unit into

the equipment database, and the WTI command to list the description of units.

If the hardware description of a functional unit in the database is faulty, the resultsof the diagnostic system are inaccurate and even misleading.

5.1 Procedures in fault situations of the diagnosticsystem

You can take over the control and decision making in the diagnostic situation

with the UDS interrupt command if:

.

the diagnostic system functions incorrectly

. the diagnostic system is executing a diagnostic task the results of which

you do not need at the moment.

See Diagnosing a unit for instructions.



General initial conditions for diagnoses







6 Total and partial unit tests

You can activate the total diagnosis of a unit using the UDU command. The total

diagnosis consists of the consecutive execution of all diagnostic programs in the

unit until a fault is located or the unit is determined operational.

You can activate the partial test of a unit using the UDU command and the

partial diagnosis parameter. A partial diagnosis consists of theconsecutive execution of all diagnostic programs included in the partial diagnosis

in question (until a fault is located).

You can assign a priority to a diagnosis using the priority parameter with the

UDU command.

Functional description of total and partial unit tests

If the Diagnostic Program Block (DGTPRO) is idle when it receives a request to

perform a diagnostic job, it prepares the execution of the job and informs you that

the job has been started. There can be ten simultaneous tests active at the sametime. However, only one test per unit at a time can be active. The tests of OMU (if

there is only one OMU) and MB have been prioritized so that no other tests can

be active while these are being executed.

The printouts of diagnostic programs (the diagnostic report and the intermediate

printout on the execution of partial diagnoses) are directed to a logical file called

DIAGNOS. This file can be connected, for example, to an alarm printer.

If the Diagnostic Program Block queue is already busy executing a diagnostic

job, or if a problem arises at the preparation phase, the diagnostic process informs

you of the error. However, using the UDU command and the priority

parameter, you can place a diagnostic job at the head of a full queue and start the

job.

For more information, see Diagnosing a unit and Partial diagnoses.



Total and partial unit tests

http://-/?-

http://-/?-



6.1 General instructions on total and partial unit tests

Use the total diagnosis command to verify the fault repair actions when

. the list of plug-in units to be tested is short

. the execution time for the total diagnosis is short

. or when the unit has only one partial diagnosis.

The partial diagnosis command is best for verifying repair actions when, for

example

. the fault has been detected in the computer controlling the switching

network or in the switching network itself

. and when the list of suspected plug-in units is lengthy.

The name of the partial diagnosis that detected the fault is shown in the diagnostic

report.

Note

The diagnostic system does not regard a unit as operational until all its

diagnostic programs (the total diagnosis) have been executed successfully.

After you have performed a partial diagnosis, start the total diagnosis using the

UDU command.





7 Partial diagnoses

The system includes the following partial diagnoses and diagnostic programs,

grouped into subfunctions:

. power test

.

switching network diagnostics

. processor diagnostics

. diagnostics for timeslot-based units

. preprocessor diagnostics

. diagnostics for peripheral devices

. MB diagnostics

. diagnostics for clock equipment

Partial diagnoses and tested plug-in units are presented in the following tables.

Table 1. Switching network diagnostics - M/CAC/MCMU/MCHU/SCU

(SWCOP as controller card)

Partial diagnosis Diagnostic program

Plug-in unit types tested by

the partial diagnosis

WAT

Wired alarm partial diagnosis

Wired alarm test CLB, TG, TGFP MBIF_U,

MBIF_T of M or CAC

GSW

GSW partial diagnosis SWI partial

diagnosis

Accurate test for the network SWCOP, SWCSM, SWSPS

SPLRT

Partial diagnosis for serial-to-

parallel converter line receivers

Test for serial-to-parallel

converter line receivers

SWSPS, SWCOP, internal PCMs



Partial diagnoses



Table 2. Processor diagnostics

Partial diagnosis Diagnostic program

Plug-in unit types tested by

the partial diagnosis

CPU

CPU386 partial diagnosis

CPU386 test CPUxxx

RAM

RAM partial diagnosis

RAM test CPUxxx

SYSB

SYSB-86 circuit group partial

diagnosis

SYSB I test

SYSB II test

MBIF test

unit-specific subset of the

following AAL, AAL-S, AFS, AFS-

S, AS7 (all variants), MBIF (all

variants), SCSIF, SERO, SWCOP

(-S), HWAT

PROC

Processor partial diagnosis

(activated only by command)

CPU386 test

RAM test

SYSB I test

SYSB II test

MBIF test

CPUxxx

unit-specific subset of the

following AAL, AAL-S, AFS, AFS-

S, AS7 (all variants), MBIF (all

variants), SCSIF, SERO, SWIF,

SWCOP(-S), HWAT

Each timeslot-based unit has one partial diagnosis, which is named after the name

of the equipment.

However, for PCU there are four partial diagnoses (PCUC, PCUD, PCUL and

PCUT) that test the PCU.

Each preprocessor has one partial diagnosis, which is named after the name of the

plug-in unit.

The peripherals (WDU, LPT, VDU, CTU) have no partial diagnoses. They are

always subject to total diagnosis.

The diagnostics of the MB consists of the MB partial diagnosis.

The CLS unit (clock equipment) has a partial diagnosis named after the device.

For more information, see Operating instructions for partial unit tests and Total

and partial unit tests.



http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-



8 Operating instructions for partial unit

tests

The objective of a partial diagnosis is:

. to accelerate repair actions

. to make it possible to test an object which is smaller than the functional

unit

. to give the user an idea of the scope of the test and of the tested unit parts

as the test progresses

Partial diagnoses are thus not intended for screening the faults, where you would

execute various partial diagnoses and try to deduce the location of the fault on the

basis of the results. This kind of screening is mostly included in the diagnostic

programs as a built-in function, where the analysis part of the programs locates

the fault.

Screening of faults can be done in two cases.

Firstly, you can sometimes get further confirmation of the location of the fault by

activating a partial diagnosis that is not executed in the total test. This is because

the diagnostic system usually executes partial diagnoses and diagnostic programs

up until the first failure. However, any result achieved in this manner is usually of

little value.

Secondly, screening of faults with partial diagnosis commands can be done when

a fault arises in the switching network interface of units connected to the

switching network, such as ET, CNFC, LSA.

In such cases, you can apply the SPLRT partial diagnosis for the switching

network. When you are using the SPLRT partial diagnosis, the units connected to

the switching network must be in the normal working state (WO).






Execution order of partial tests

One of the principles of the diagnostic system is to test the remaining parts on the

basis of parts that have previously been determined operational. Therefore, the

execution order of partial diagnoses within a total diagnosis bears certain

significance. The following figures illustrate the dependency of the execution

order on partial diagnoses according to subfunctions. At the bottom of each figure

is the basis on which the execution of the upper tests is built.

Processor diagnostics

Figure 2. Interdependencies between partial diagnoses in processor diagnostics

The figure above shows, for instance, that the partial diagnosis PROC

corresponds to the CPU, RAM and SYSB partial diagnoses. The basic default for

processor diagnostics is that the unit is able to execute its own diagnostic

programs.

Switching network diagnosis

PROCtest

SYSB test

RAM test

CPU test

Basic defaults





Figure 3. Interdependencies between partial diagnoses in switching network

diagnostics

In this figure, the diagnostics of the switching network have been presented so

that it has been separated from the processor test. The figure should, however, beinterpreted as if it were completely above the processor diagnostics.

The test of the serial-to-parallel converter line receiver in the switching network

(SPLRT) may find a fault not only in the plug-in units, but also in the internal

PCM circuits (cables) and devices connected to them. It is capable of detecting a

large part of the failures in the switching network interface of a device connected

to the switching network by an internal PCM circuit.

There are special instructions for failure cases of this kind in Alarm descriptions ,

which describes each of the text diagnoses.

For more information, see Partial diagnoses.

SPLRT test

GSW0test

GSW1test

GSW2test

GSW3test

GSW test

CME test

SMI test

WAT test




http://-/?-

http://-/?-







9 Diagnosing a unit

Diagnose units according to the following procedure.

Steps

1. Start a unit test

Before you start

Note

ET2E/EC2ET

If you are running the diagnosis for one of the ET units of an ET2E or EC2ET

plug-in unit (applies to all variants), do not make any changes to the other ET

on the same plug-in unit when the diagnosis is running, since the diagnosis

and the changes in the ET parameters fail in this case. For example, do not use

the commands of the YE or US command group while running the diagnosis.

Before starting the test, make sure that the ET2E or the EC2ET plug-in unit is

in the TE state.

a. Check the unit state (USI)

First check the unit state using the USI command. If the unit is in

the TE state, you can start the test. If it is not, change the unit state to

TE using the USC command.

For details about the commands in the command group US, see

Working State and Restart Handling . For details about unit state

changes, see Recovery and Unit Working State Administration .

b. Start the total test of a unit (UDU)

ZUDU:<unit identification>:<partial test>:

<priority>;

For detailed instructions on the syntax and parameters of the

command UDU, see Diagnostics Handling .

Further information



Diagnosing a unit



Example Start the total test

Start the total test of Marker unit M-0 (where 0 is the unit index).

ZUDU:M,0;

Example Start a partial test

Start the RAM partial test on HLRU pair number 1, unit index 1, as a priority job.

ZUDU:HLRU,1,1:RAM:PRI;

2. Interrogate partial unit tests (UDI)

Use the UDI command to interrogate which partial tests have been defined

for a unit or an I/O device.

In the execution printout, the TOTAL column after a partial diagnosis

indicates whether the partial diagnosis belongs to a total diagnosis or not. If

a partial diagnosis does not belong to a total diagnosis, you can start it only

by using an MML command.

In addition, the execution printout contains a list that shows which plug-in

unit types are tested by which of the partial diagnoses.

The plug-in unit types and the names of partial diagnoses are retrieved

from the files in the diagnostics system.

ZUDI:<unit type>,<unit index>;

Further information

Example Interrogate the partial unit tests of OMU

Interrogate the partial tests of OMU.

ZUDI:OMU;

Here is an example of the printout:

DX 220 DX220-LAB 2002-02-13 15:12:13

D I AG N OS T IC S F O R U N IT O M U

T ES T T OT AL P LU G- IN U NI TS

PROC NO C P3 86_V MBIF_T DMADI SERO

CPU YES CP3 86_V

RAM YES CP3 86_V

DMC YES CP3 86_V MBIF_T DMADI SERO

WAT YES MBI F_T A AL_S





COCEN Y ES COCEN

CENEX NO COCEN

ASS YES ASS_S

AS7 YES AS7_U

AFS YES AFS_SC O M M A ND E X E C U TE D

3. Interrogate current tests (UDQ)

One of the features of the diagnostic system is that it diagnoses the faults in

as many as ten units at a time. The diagnostic system, however, uses

critical resources which force the diagnosis jobs in consecutive order. The

system may respond that it is busy when given a diagnosis activation

command.

The UDQ command can be used to enquire about the reservation status of

the diagnostic system, and about the currently active jobs, with an accuracy

down to the partial diagnosis and the unit.

The execution printout of the command shows which diagnosis jobs are

queuing for execution.

The command shows you all the active tests at that moment.

ZUDQ;

4. List faulty units in the system

Use the UDL command for listing faulty units to get a list of the functional

units in the system that have been registered as faulty (FLTY).

If there are faulty units, they must be handled one at a time. For testing,

transfer the unit to the TE state with the USC command. Then start the

diagnostics with the UDU command.

ZUDL;

As the default, the system lists all faulty units. If you want a list of the

faulty computer units only, use the COMP parameter value.

Expected outcome

An example of the printout:

DX 220 DX220-LAB 2002-02-13 15:12:13

F A UL T Y U N IT S I N S Y ST E M

UNIT WORKING STATE MAIN UNIT

SSU-0-0 WO-EX



Diagnosing a unit



L PT-1 BL-SY OM U

L PT-2 BL-SY OM U

L PT-3 BL-SY OM U

L PT-4 BL-SY OM U

L PT-5 BL-SY OM UL PT-6 BL-SY OM U

L PT-7 BL-SY OM U

V DU-2 BL-SY OM U

V DU-3 BL-SY OM U

V DU-4 BL-SY OM U

V DU-5 BL-SY OM U

V DU-6 BL-SY OM U

V DU-7 BL-SY OM U

C O M M A ND E X E C U TE D

5. Display diagnostic report history

Just as with alarms, you can display the diagnostic report history.

Further information

Example Display the diagnostic report history of OMU

ZUDH:OMU::2003–01–01:;

6. Stop current tests

You may need to use the stop command if the system is occupied with a

diagnosis job whose results are not needed at the moment, or if thediagnostics system is not functioning properly. You can interrupt a

diagnosis job in progress with the UDS command.

ZUDS:<unit type>,<unit index>;

Further information

Example Stop the current tests of OMU

Stop the current tests of OMU.

ZUDS:OMU;

Further information

For more information, see Diagnosing I/O devices and Fault localising based on

unit-specific hardware alarms.



http://-/?-

http://-/?-

http://-/?-

http://-/?-



10 Diagnosing I/O devices

Start the diagnostics for a peripheral device WDU, FDU, VDU, LPT, CTU and its

processor interface using the UDD command.

The functional status of the I/O equipment which is to be diagnosed must be TE-

ID (change the state using the ISC command).

For further information about the syntax and parameter explanations of the

command group UD, see Diagnostics Handling . For further information about the

other commands needed in diagnosing peripheral device, see I/O Device Working

States (IS) .

For more information, see Diagnosing a unit and Fault localising based on unit-

specific hardware alarms.

10.1 Diagnosing a hard disk unitSteps

1. Diagnose a hard disk unit

Activate the diagnostics for the OMU hard disk unit 0 with the following

command:

ZUDD:OMU:WDU,0;

With the following command, on the other hand, you can activate thediagnostics for the statistical unit 0 in hard disk unit 1.

ZUDD:STU,0:WDU,1;



Diagnosing I/O devices

http://-/?-

http://-/?-

http://-/?-

http://-/?-



10.2 Diagnosing a cartridge tape unit

Steps

1. Diagnose a cartridge tape unit (UDD)

a. Make sure that there is a tape inserted in the CTU. The tape must not

be full and it must be a formatted tape.

b. Activate the diagnosis for the CTU-1 located in OMU.

ZUDD:OMU:CTU,1;

10.3 Diagnosing a removable disk unit

Steps

1. Diagnose a removable disk unit

a. Make sure that there is a formatted disk inserted in the FDU.

b. Activate the diagnosis for the FDU-1 located in OMU.

ZUDD:OMU:FDU,1;





11 Total testing after replacing a plug-in unit

Before you start

If you have already replaced the plug-in unit, you can test the unit with the

following procedure.

For more information, see Instructions for replacing plug-in units.

Steps

1. List the faulty units (UDL)

As a default, the system lists all faulty units. If you want a list of faulty

computer units only, use the COMP parameter value.

ZUDL;

Expected outcome

An example of the printout:

F A UL T Y U N IT S I N S Y ST E M

UNIT WORKING STATE MAIN UNIT

SSU-0-0 WO-EX

LPT-1 BL-SY OM U

LPT-2 BL-SY OM U

LPT-3 BL-SY OM U

LPT-4 BL-SY OM U

LPT-5 BL-SY OM U

LPT-6 BL-SY OM U

LPT-7 BL-SY OM UVDU-2 BL-SY OM U

VDU-3 BL-SY OM U

VDU-4 BL-SY OM U

VDU-5 BL-SY OM U

VDU-6 BL-SY OM U

VDU-7 BL-SY OM U


2. Check the unit state (USI)



Total testing after replacing a plug-in unit



Use the USI command. If the unit is in TE state, you can start the test.

ZUSI:<unit identification>:<configuration>:<name of

remote station>;

3. Bring the unit back into TE state (USC)

If the unit is not in TE state, bring the unit back into TE test state by using

the USC command.

ZUSC:<unit identification>:<working state>,

<transition control>:<code load mode>,<file load

mode>;

4. Start the test of a unit (UDU)


<priority>;

5. Monitor the test progress (UDQ)

You can enquire directly to the diagnostic system or via intermediate

printouts that are printed out on the alarm printer that give information

about the partial diagnoses. The total test of a unit may take from less than

1 second to up to 30 minutes, depending on the hardware configuration of

the unit (the duration can be multiplied by increasing the number of test

repetitions through file parameters).

The interrogate current tests command shows you all the active tests at that

moment.

ZUDQ;

If no faults are found in the total test, the following text is printed out on

the printer:

T O TA L D I AG N OS I S E X EC U TE D - U N IT O K

The message indicates that the system has registered the unit as

operational.

Further information

For more information, see Functional description of total and partial unit

tests.



http://-/?-

http://-/?-

http://-/?-

http://-/?-



6. Display the diagnostic report history (UDH)

Just as with alarms, you can display the diagnostic report history.

ZUDH;

Further information

Example Display the diagnostic report history of OMU

ZUDH:OMU::2003–01–01:;

7. Stop the current tests (UDS)

You may need to use this command if the system is occupied with a

diagnostic job whose results are not needed at the moment, or if the

diagnostics system is not functioning properly.

ZUDS:<unit type>;

Further information

Example Stop the current tests of OMU

Stop the current tests of OMU.

ZUDS:OMU;

Further information

For more information, see Total and partial unit tests and Fault localising based

on unit-specific hardware alarms.



Total testing after replacing a plug-in unit

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-

http://-/?-







12 Partial testing after replacing a plug-in

unit

When the list of suspected plug-in units is long, you can speed up the repair

operation by starting, instead of the total unit test, the partial test that detected the

fault.

The name of the partial test is shown in the PARTIAL DIAGNOSIS NAME field

of the diagnostic report. If the diagnosis now shows that the unit is in working

order, it is likely that the repair action was successful.

Steps

1. Interrogate partial tests (UDI)

In the execution printout, the TOTAL column after a partial diagnosis

indicates whether the partial diagnosis belongs to a total diagnosis or not. If

a partial diagnosis does not belong to a total diagnosis, you can start it only by using an MML command. In addition, the execution printout contains a

list that shows which plug-in unit types are tested by each of the partial

diagnoses. The plug-in unit types and the names of partial diagnoses are

retrieved from the files in the diagnostics system.

ZUDI:<unit type>;

Example Interrogate partial unit tests of OMU

Interrogate the partial tests of OMU.

ZUDI:OMU;

Here is an example of the printout:

D I AG N OS T IC S F O R U N IT O M U

T ES T T OT AL P LU G- IN U NI TS

PROC NO C P386_V MBIF_T DMADI SERO

CPU YES C P3 86_V

RAM YES C P3 86_V

DMC YES C P3 86_V MBIF_T DMADI SERO



Partial testing after replacing a plug-in unit



WAT YES MBIF_ T AAL _S

COCEN Y ES COC EN

CENEX NO COC EN

ASS YES ASS_S

AS7 YES AS7_UAFS YES AFS_S


2. Start the test of a unit (UDU)

Transfer the unit from the functional state faulty (FLTY) into the

operational state by starting the total diagnosis for the unit.


<priority>;

Further information

If replacing a plug-in unit does not help and the same diagnosis recurs, re-

install the old plug-in unit where it was originally, and replace the next

plug-in unit on the list of suspected plug-in units.

3. Bring unit back to normal state (USC)

When you receive the message TOTAL DIAGNOSIS EXECUTED - UNIT OK

bring the unit from the test state (TE) back to its normal working state (SP

or WO).

ZUSC:<unit identification>:<working state>,

<transition control>:<code load mode>,<file load

mode>;





13 Fault localising based on unit-specific

hardware alarms

13.1 CLAB

Alarm number Possible faulty plug-in units

2761 CLAB, SBUS

13.2 CLS


1630 CLG (all variants), CLCP, CLxTG (all variants)

2057 CLxTG (all variants), strappings

2630 CLPM

2632 CLG (all variants), CLOS, CLxTG (all variants)

2633 CLG (all variants), CLPM, CLxTG (all variants)

2634 Power supply, CLxTG (all variants)

2635 CLOS, CLPM, CLCP

2636 CLG (all variants), CLxTG (all variants)





13.3 ET


1901 ET1E (all variants), ET2E (all variants), ECET

2039 ET1E (all variants)



Fault localising based on unit-specific hardware alarms



2202 ET1E (all variants), ET2E (all variants), ECET, FRAL, IR/

TR, AFS (all variants), AS7 (all variants) or in the

switching matrix

2203 ET1E (all variants), FRAL, IR/TR 2205 ET2E (all variants)

2402 ET1E (all variants), FRAL, AFS (all variants) or in the

switching network

2737 EC2ET (all variants)



13.4 MCMU


1001 all CPU units

1002 all CPU units

1003 all CPU units

1010 all CPU units, SWIF, SWTST, SWCOP (all variants),

MBIF (all variants)

1044 SWCM, SWM, P/S, S/P, SWCL, MPTL, SWTST,

SWCOP (all variants), SWCSM, SWSPS, SW64B

1045 all CPU units, SWCM, SW64B

1047 SWCOP (all variants), SWCSM, SWSPS

1048 SWCOP (all variants), SWCSM, SWSPS

1058 SMUX

2005 all CPU units

2033 CLG (all variants), CLB, MPTL

2044 all CPU units, SWCM, SWM, P/S, S/P, SWCL, MPTL,

SWCOP (all variants), SWCSM, SWSPS, SW64B

2045 all CPU units, SWCM, SWCSM, SW64B

2050 SWCSM, SWSPS, SW64B

2052 SWCSM, CLAB, SW64B

2053 SWCOP (all variants)

2054 all CPU units

2058 SMUX

2079 AS7 (all variants), SWCOP (all variants), SWCSM,

SWSPS, SW64B

2252 AS7 (all variants), SWCSM, SWSPS

2426 all CPU units





2755 MBIF (all variants), CLxTG (all variants), CLAB

2756 Cartridge power supply

2757 MBIF (all variants), CLxTG (all variants), CLAB

13.5 BCSU


1001 all CPU units

1002 all CPU units

1003 all CPU units

1010 all CPU units, AFS (all variants), MBIF (all variants)

1072 AS7 (all variants)

1260 AC25 (all variants), AS7 (all variants)

1400 AFS (all variants)



2005 all CPU units

2054 all CPU units

2079 AS7 (all variants), SWCOP (all variants), SWCSM,

SWSPS

2137 AS7 (all variants), AC25 (all variants)

2138 AS7 (all variants), AC25 (all variants), AFS (all variants)2139 AS7 (all variants), AC25 (all variants), AFS (all variants)

2141 AS7 (all variants), AC25 (all variants), AFS (all variants)

2142 AS7 (all variants), AC25 (all variants), AFS (all variants)

2406 AFS (all variants)

2426 all CPU units

2202 ET1E, ET2E, AFS (all variants)

2402 ET1E, AFS (all variants)

13.6 MB


1015 MBIF (all variants)



2031 MBIF (all variants), CLG (all variants), CLB, CLAB,

CLxTG (all variants)



Fault localising based on unit-specific hardware alarms



13.7 OMU


1001 all CPU units1002 all CPU units

1003 all CPU units




2005 all CPU units






2252 AS7 (all variants) or in the switching matrix

2426 all CPU units

2760 HWAT

13.8 TCSM

Alarm number Possible faulty plug-in units2202 ET2A, ET2E

2205 ET2A, ET2E

2950 TRCO

2952 ET2A, ET2E, TR12, TR16





14 Fault localising based on alarms from

peripheral devices

14.1 CTU


1885 SCSIF, CTAD, CTU, CPxxxx

1886 SCSIF, CTAD, CTU, CPxxxx

2870 PSC4

14.2 FDU

No alarms.

14.3 LPT


2403 SERO

14.4 VDU

Alarm number Possible faulty plug-in units2403 SERO (all variants), SCSIF

2800 SERO (all variants), SCSIF

14.5 WDU



Fault localising based on alarms from peripheral devices




2860 SCSIF, WDAD, WDU, CPxxxx

2861 WDAD, SCSIF, WDU, PSC4, CPxxxx

2870 PSC4


Date post:	04-Jun-2018
Category:	Documents
Upload:	taranehhayeh2006
View:	218 times
Download:	0 times

Diagnostics and Testing

Documents