____________________________________________________
o \__ \_ _ \_________ \_ O
. _/ \_/ _/ __________/ | __/
+----\ | \ | \ | \----+
: \_______l_______/\________________/\_______________/ :
+ -------------------------+ Psyclone '96 +------------------------- +
ş M M ş
| E Trashed Print-out Interpretation E |
ş D D ş
+ ----------------------------- LONDON ----------------------------- +
This is for you first time trashers who run up to the bin, stuff all
the papers into a bag and then run home yelping with joy. All those
computer printouts that are produced by the TXE exchange equipment and
then promptly discarded by bt, despite being of interest to most phreakers
cannot be fully understood without a certain key knowledge. This knowledge
is now in your possesion.
Introduction
============
This file contains information on how to "decode" the letters and
numbers found on the most common of TXE exchange printouts, for me these
are : PRINT RECORD, SOFTWARE REPORT, DATA FOR SYMPTOM and some printed
lists of archives. There are probably others floating around, but the
majority of it is dealt with in here.
The following information also involves other files, so if you wanna
find out more about these systems (and the TXE4 exchange) then look out
for other MED releases. Main abbreviations used are as follows:
TXE4 : Telephone Exchange Electronic 4. Replaced the TXS/TXK/TXE2/TXE3
exchanges and was replaced by the TXD exchanges.
TXEE : Telephone Exchange Electronic Enhanced. TXE4 with Enhancement
upgrage.
MMI : Man Machine Interface. Equipment interface for engineers. Driven by
Man Machine Language (MML) commands.
FP : Functional Processor.
SMF : System Manager Facility.
CMH : Call Monitoring Handler.
SCH : Set-up Call Handler.
CDF : Charge Determination Facility.
In the TXE exchange the SMF initiates all the printouts via each of
the system printers, these are controlled by either MMI options or they
are automatically triggered by the system status, so basically they
constantly spawn reams of paper. The only reason they are printed out is
to get a hard copy of the data for reference, after a brief storage
period they are discarded.
The data which is automatically printed is as follows :
-Provision/cessation bulk meter readings
-Print record
-Software report
-Hardware fault
-Archiving of data
Provision/Cessation Bulk Meter Reading :-
======================================
Whenever a customers line is provided or ceased, a printout is
initiated from the particular SMF currently being used for the MMI
transaction. This is printed out, and then disposed of, thus reincarnating
it as trash.
Example printout for a normal line :
11/06/95 WED 11:34:14 SEQ NO: 218
PROVISION BULK METER READINGS
Directory number : 9991234
PBX suffix : 0
Non-item count : 351
Non-item units : 5952
Item count : 1351
Item units : 346951
END OF REPORT
Example printout for a PBX line :
11/06/95 WED 11:47:05 SEQ: 223
CESSATION BULK METER READINGS
Directory number : 9991235
PBX suffix : 2
Non-item count : 2398
Non-item units : 609144
Item count : 2374
Item units : 609148
END OF REPORT
Explanation :-
For both the examples, the figures in the first line show the date, time,
and sequence number. The sequence number is incremented on each provision
or cessation or any other MMI transaction.
Directory number - is the combined exchange code and customer's number.
PBX suffix - is shown as 0 for non-pbx customers or the line number for
pbx customers.
Non-item count - is the number of calls not requiring itemisation that
have been made from the directory number.
Non-item units - is the number of units accrued from the non-itemised call
count for the directory number.
Item count - is the number of calls requiring itemisation that have been
made from the directory number.
Item units - is the number of units accrued from the itemisation call
count for the directory number.
Print Record :-
============
A print record can be generated for a number of reasons. It is not a
fault printout but is used to record specific incidents. If the system
detects one of the following things then it automatically prints :-
-Printer meter check
-Calling line indication failure
-Invalid/unidentified number dialled
-Ineffective call
-Extra long call
-Call made from spare line
-Nominated outgoing number call
-Nominated line indication
Incorporated within the print record is some info on the following :-
-Any reasons for itemisation (1-6)
-Qualifier status (1-6)
-Subs category (1-3)
-Call type group (1)
-Local print reasons (1-10)
The numbers next to the conditions are the number of options (different
reasons). In the print record to show which of the options are relevant
the character Y is printed, and to show which of the options are not
relevant a + is printed. You can see this in the example...
Typical printout :
PRINT RECORD NNI xxxxxxx 09/96 00:40:53
NN 16700661 /000 DIALLED DIGITS 6708170 REVENUE GROUP 101
START 09/06 00:40:40 DURATION 00:00:12.58 LINKED Unlinked FREEPHONE N
HANDLING CHARGE 000 DURATION CHARGE 0000001 BULK NON-ITEM N
TARIFF GROUP 01 CHARGE BAND 01
ITEMISATION REASONS +++Y++ QUALIFIER ++++++ SUBS CATG ++Y CALL TYPE GP 0
LOCAL PRINT REASONS +++++++++Y
END
Explanation :-
NNI : Network Node Identity }
09/06 : day/month } Line 1
00:40:53 : Time - middle of night !? }
NN1816700661 : National Number (01816700661) }
PBX Suffix (000=not applicable) }
Dialled digits : Dialled digits from 6700661 } Line 2
(670 8170) }
Revenue group 101 : Revenue number for a local call }
Duration : How long the call was, measured in }
hours minutes, seconds and milliseconds. }
Linked/Unlinked : Tells you if the charge records for a } Line 3
call are linked (first linking and last) }
or unlinked. }
Freephone N : if costing cash or not. }
Handling charge 000 : Shows the call handling charge }
in units. }
Duration charge : shows the length of the call in }
units. } Line 4
Bulk non-item N : Used to show if the calls are }
itemised or not. Strangely 'nuff }
Y = not itemised and }
N = itemised ... }
Tariff group : Shows calling line's tariff group } Line 5
Show variable information dependant on type of call, }
customer and system requirements. The active options } Lines 6
are shown by the character Y. } and 7
In the print records where it has +++Y+++ or +Y++++ or sumthing like
that it is just telling you which options are in use. If there is no Y in
the line of +'s then none of the options have been used. I have made this
nice little table to make it nice and easy to decode all the +'s and Y's
for ya.
ITEMISATION REASONS Y+++++ : Nominated outgoing number call
ITEMISATION REASONS +Y++++ : Part bill required
ITEMISATION REASONS ++Y+++ : Long duration
ITEMISATION REASONS +++Y++ : Customer requested
ITEMISATION REASONS ++++Y+ : Admin requested
ITEMISATION REASONS +++++Y : Admin requested for all customers /
designated cicuits
QUALIFIER Y+++++ : Ineffective calls
QUALIFIER +Y++++ : Incoming calls
QUALIFIER ++Y+++ : Invalid dialled digits
QUALIFIER +++Y++ : CLI failure
QUALIFIER ++++Y+ : Printer meter check
QUALIFIER +++++Y : No CSA pulse
SUBS CATG Y++ : White meter active
SUBS CATG +Y+ : Itemisation billing levels
SUBS CATG ++Y : All calls itemised
LOCAL PRINT REASONS Y+++++++++ : White meter
LOCAL PRINT REASONS +Y++++++++ : No CSA
LOCAL PRINT REASONS ++Y+++++++ : Printer meter check
LOCAL PRINT REASONS +++Y++++++ : CLI failure
LOCAL PRINT REASONS ++++Y+++++ : Invalid dialled digits
LOCAL PRINT REASONS +++++Y++++ : Ineffective calls
LOCAL PRINT REASONS ++++++Y+++ : Long duration
LOCAL PRINT REASONS +++++++Y++ : Calls made on a spare line
LOCAL PRINT REASONS ++++++++Y+ : Nominated outgoing number
LOCAL PRINT REASONS +++++++++Y : Monitored line indication
So there! Now you can see what the useless piles of paper mean!
Sofware reports :-
===============
In every FP, an area of software is specially dedicated to fault
detection, classification, and interfacing with it's alarm card. Processors
can detect a fault in either of these :-
-FP and any of it's dependants (eg. CMH/CEL)
-Any associated FP (eg. SCH)
In the first case FP, detects a fault in its own program/data or that
of its dependants. The software within FP can detect the fault and then
convert it into a symptom. The fault symptom is passed on to the
classification software which classifies the fault type and, if possible,
reconfigures the hardware eg OS Faulty. In the case of most software
detected faults, a reload of the program is requested from SMF. The FP
will always signal the fault symptom to the SMF for possible printout
(software report or hardware fault printout). A functional processor can
also detect, via the software routines, a fault in the program/data of an
associated FP. As its own symptom handling software will be unable to
classify this type of fault, the symptom is passed on to the SMF for
symptom processing.
The software also interfaces with its associated alarm card to allow
hardware detected faults to be registered.
Software Fault printout format is as follows:
SOFTWARE REPORT (A) NNI 9991234 18/09 11:13:55
SOURCE SMF_A STATUS CATEGORY 004 ALARM DEFERRED SYMPTOM ID 183
CL CL 5.7 item.pas 478
Call originated from a spare line
09 12 0B 0D 26 41 23 03 07 FF FF 00 00 34 02 03 F3 FF FF FF FF FF FF
END
Explaination :-
SOFTWARE REPORT : Report title }
(A) : Printer (A or B) }
NNI : Seven digit number identifying the }
network node } Line 1
18/09 : Date on which fault is detected }
(day/month) }
11:13:55 : Time of day (24 hour clock) }
(hours:mins:secs) }
SOURCE : Reporting FP identity (ie SMF A) }
STATUS CATEGORY : System error code (a number between }
0 and 255) }
ALARM : Alarm level (ie prompt, deferred or }
no alarm) } Line 2
SYMPTOM ID : A number between 0 and 65535 used }
with the system error code to }
determine the details required on }
the fault report. }
TASK IDENTIFIER : Up to 30 characters which may }
identify the software task which is } Line 3
the source of the fault report. }
EXPLAINATORY TEXTS : This line of text wlil indicate the }
cause of the detected fault. In the }
case of the example a call has been } Line 4
made from a line which the }
enhancement equipment has shown to }
be spare. }
HEXADECIMAL DATA : Up to 26 bytes of data in hexadecimal }
code. If more than 26 bytes are }
produced by the software routine which } Line 5
generated the symptom, the extra bytes }
are printed out after line 8. }
END : end of report. } Line 6
For the example used in this text, to find the identity of the
calling line which made the call it will be necessary to decode part of
the line of hexadecimal data.
The source of this software report is the SMF and the symptom
identity number is 183. The symptom number lists the hexadecimal bytes of
the message in order.
Bytes 0 to 4 Date and time of seizure (month day hrs mins secs)
Bytes 5 to 10 National Number (with each byte reversed)
Bytes 11 and 12 PBX suffix (will be 00 if not a PBX line)
Bytes 13 to 22 Dialled digits (followed by FF empty bytes)
The most important items are the national number and the PBX suffix.
The national number is quoted as being formatted in accordance with ES10,
as are the dialled digits. Put simply, this means that the bytes must be
read by reversing the order of the digits in each byte. Also, the prefix
of 0 will be missing from the number.
From the printout, bytes 5 to 10 are: 41 23 03 07 FF FF. Therefore
the originator of the call was 014-32-3070, the character F being used to
fill spaces not required. Although not specified, any PBX suffix will be
encoded in hexadecimal and must be read in reverse byte order. So if the
printout showed the suffix to be: 0C 00, this would be line 12 of the PBX.
Not all printout analysis can be carried out in this way. In some
cases, it will be necessary to refer to a fault dictionary. Here is
another example of a software report:-
Analysis of Software Report using the Fault Dictionary
SOFTWARE REPORT (A) NNI 9991234 23/09 09:35:43
SOURCE SCH1A STATUS CATEGORY 005 ALARM DEFERRED SYMPTOM ID 74
SCH_FSM_TASK
Calling Line Identification Failure
FF FF 01 0F 73 00 00 01 5A 02 0B 16 00 00 14 12 83 67 91 31 00 5A 5A 5A
END
DATA FOR SYMPTOM 74
FF FF 01 0F 73 00 00 01 5A 02 0B 16 00 00 14 12 83 67 91 31 00 5A 5A 5A
07 04 03 02 04 07 06 03 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F
0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 01 04 D3 99 00 00 5A 04 00 0A
0F 0F 00 00 0F 06 A2 07 10 21 53 FF AA 01 FF FF 00 00 00 00 5A 5A 5A 5A
To find more information on the faults, reference can be made to the
Faults Dictionary document, this provides explanatory text on various
details such as the symptom id's. In the above case, the engineer would
refer to symptom identity 74, under the SCH section of the fault
dictionary. Having established that the enhancement equipment has been
unable to identify the calling line you may consult the fault dictionary
for further information on the fault. For example, byte 6 tells us this is
an own exchange call and bytes 14 to 16 contain the identity of the line
from which the call was made (EN 121384).
Nearly all software reports will be dealt with in one of these two
ways. The fault dictionary will list the information required either under
the symptom identity number for the relevant section or in an appendix to
that section.
SOFTWARE REPORT (A) NNI 9999032 23/08 16:59:36
SOURCE CMH1B STATUS CATEGORY 013 ALARM PROMPT SYMPTOM ID 180
cmh_cel: one_sec_cel_check
voting error in CEL error word
01 00 48 02 00
END
Referring to the CMH section of the fault dictionary, symptom
identity 180, the bytes of the message are listed.
Byte 0 CEL identity
Byte 1 Exchange type (see Appendix R)
Bytes 3 & 2 Error Word 1 (see Appendix H)
Byte 4 Error Word 2 (see Appendix H)
From the printout, byte 0 is 01 (CEL number 1) and byte 1 is 00 (RD
exchange). Bytes 3 and 2 need to be changed into a bit format:
Byte 3 = 02 Byte 2 = 48, therefore the bits are :
0000 0010 0100 1000
The bits number from right to left, starting at bit number 0. So bits
3, 6 and 9 are at logic 1. To evaluate these bits you must look in
Appendix H of the faults dictionary, where it can be read that they
indicate an LBa error, a PKa error and a PS13Sa error. In this example it
is reasonable to assume that a fault exists on plane 1 of the U value
connected to CEL 1. Error codes are also listed.
Sometimes when a fault symptom is classified within the symptom
handling software, more than one fault option may be a possibility. If
this happens then more than one hardware/software fault report is printed
but all printouts are given the same time and are printed consecutively.
Hardware Fault Printout
=======================
Hardware fault printouts can be instigated by the Alarm Card
associated with each FP and also by software reload requests.
The printouts take the following format:
HARDWARE FAULT (A) NNI 9998031 29/07 15:28:17
SOURCE CMH1A STATUS CATEGORY 011 ALARM PROMPT SYMPTOM ID 8
RESOURCE NAME FAN NUMBER 001 PARENT _____ NUMBER __
OLD STATUS IN_SERVICE NEW STATUS OS_FAULTY
RACK SCH CMH 1 SHELF D POSITION 023
FAN failure detected by hardware
END
Interpretation:-
HARDWARE FAULT : Report title }
(A) : Printer (A or B) }
NNI : Seven digit number identifying the } Line 1
network node }
29/07 : Date (day/month) }
15:28:17 : Time (hrs:mins:secs in 24 hr clock) }
SOURCE : FP identity (ie CMH 1A) }
STATUS CATEGORY : System error code (between 0 and 255) }
ALARM : Alarm level (prompt, deferred or no }
alarm } Line 2
SYMPTOM ID : A number between 0 and 65535 used by }
the SMF to determine details required }
on the fault report. }
RESOURCE NAME : Six character name of faulty unit }
NUMBER 001 : Resource number of faulty unit } Line 3
PARENT : Identity of parent resource }
NUMBER : Number of parent resource }
OLD STATUS : Unit status prior to detection of the }
fault } Line 4
NEW STATUS : Current status (after detection) }
RACK : SCH CMH 1 }
SHELF : D } Line 5
POSITION : 023 }
EXPLANATORY TEXT : Each symptom is unique to a particular }
event within the TXEE and has a line }
of explanatory text associated with }
it. The text is significant as a } Line 6
detected fault may have been caused in }
one of several ways - how it was }
detected may help in fault diagnosis. }
HEXADECIMAL DATA : Up to 26 bytes of data can be printed, }
if more than 26 are produced by the }
software routine which generated the }
symptom, extra bytes are printed out } Line 7
after line 8 (END). As in this case, a }
hardware fault will not always result }
in any bytes of data being produced. }
END : End of report } Line 8
Generation of printouts:
In the event of the alarm card detecting a hardware fault, an error
word is sent from the alarm card to the FP. The error word signals the
status of the peripheral hardware to the FP ie fans, temperature sensors,
DC-DC converters etc. The FP sends fault symptom to the SMF which controls
the hardware fault printout. When the fault is cleared the new status is
signalled as before and another printout is generated to indicate the new
status. See examples below:
HARDWARE FAULT (A) NNI 9998031 29/07 15:12:04
SOURCE CMH1A STATUS CATEGORY 011 ALARM, PROMPT SYMPTOM ID 8
RESOURCE NAME FAN NUMBER 001 PARENT _____ NUMBER __
OLD STATUS IN_SERVICE NEW STATUS OS_FAULTY
RACK SCH CMH 1 SHELF D POSITION 023
FAN failure detected by hardware
END
HARDWARE FAULT (A) NNI 9998031 29/07 15:12:07
SOURCE CMH1A STATUS CATEGORY 012 ALARM NO ALARM SYMPTOM ID 9
RESOURCE NAME FAN NUMBER 011 PARENT _____ NUMBER __
OLD STATUS OS_FAULTY NEW STATUS IN_SERVICE
RACK SCH CMH 1 SHELF D POSITION 023
FAN recovery detected by hardware
END
A hardware fault can be produced to inform users of the status of a
particular FP if a reload has been requested. This forms part of a reload
printout sequence, as shown below. Note that in practise other printouts
may occur to interupt the sequence.
HARDWARE FAULT (A) NNI 9998031 29/07 14:35:40
SOURCE SMF_A STATUS CATEGORY 013 ALARM NO_ALARM SYMPTOM ID 219
RESOURCE NAME CMH1A NUMBER __ PARENT _____ NUMBER __
OLD STATUS OS_RELOAD NEW STATUS OS_RELOAD
RACK SCH CMH 1 SHELF D POSITION 035
Functional Processor has requested a reload
00 48 00 00 00 50 50 50 50 50 C7 C7 C7 C7 C7 C7 C7 C7 C7 C7
END
HARDWARE FAULT (A) NNI 9998031 29/07 14:35:46
SOURCE SMF_A STATUS CATEGORY 014 ALARM NO_ALARM SYMPTOM ID 220
RESOURCE NAME CMH1A NUMBER __ PARENT _____ NUMBER __
OLD STATUS OS_RELOAD NEW STATUS OS_RELOAD
RACK SCH CMH 1 SHELF D POSITION 035
Functional Processor reload commencing
00 79 00 00
END
HARDWARE FAULT (A) NNI 9998031 29/07 14:46:40
SOURCE SMF_A STATUS CATEGORY 013 ALARM NO_ALARM SYMPTOM ID 336
RESOURCE NAME CMH1A NUMBER __ PARENT _____ NUMBER __
OLD STATUS OS_STARTUP NEW STATUS IN_SERVICE
RACK SCH CMH 1 SHELF D POSITION 035
Reload of Functional Processor completed
00 3D 00 00
END
HARDWARE FAULT (A) NNI 9998031 29/07 14:46:43
SOURCE SMF_A STATUS CATEGORY 013 ALARM NO_ALARM SYMPTOM ID 25
RESOURCE NAME CMH1A NUMBER __ PARENT _____ NUMBER __
OLD STATUS IN_SERVICE NEW STATUS IN_SERVICE
RACK SCH CMH 1 SHELF D POSITION 035
An FP completed alignment
00 3F 00 00
END
BSEACH Reports
==============
BSEARCH is a nightly routine, comparing the TXEE exchange line data
base with the TXE4 Cyclic Store using the associated equipment number in
the TXEE exchange Line Data base as the search data. This is basically to
check that all the line states are ok, if a fault is detected printouts
will be triggered. There follows 6 examples of different types of BSEARCH
printouts.
1. This report shows the first DN used in the BSEARCH period.
13/08 THU 00:35:06 SEQ NO: 2013
BSEARCH
-------
First DN of the search period : 4321234 suffix 0
End of report
2. This report tells us that in X time slot of EN 151413, the TXEE
Exchange Line Data does not compare with the TXE4 C/S data 9314 56700.
13/08 THU 00:35:29 SEQ NO: 2013
BSEARCH
-------
EN 151413 X slot routine check failed.
TXEE data is DN 4321234 suffix 0
C/S data is 9314 567000
End of report
3. This report tells us that X time slot of EN 141312 was not found in the
TXE4 C/S data.
13/08 THU 00:35:41 SEQ NO: 2013
BSEARCH
-------
EN 141312 X slot routine check failed.
TXEE data is DN 4321234 suffix 0
End of report
4. The above BSEARCH report (3) is normally followed by Software Report No
498. This states that the EN held by the TXEE Exchage Line Data base is
out of range for the TXE4 exchange.
SOFTWARE REPORT (B) NNI 9998031 13/08 00:35:41
SOURCE SMF_B STATUS CATEGORY 014 ALARM NO_ALARM SYMPTOM ID 498
MMI 5.28 dsrch.pas 4131
MCU failed to find EN that TXEE holds
01 00
END
5. Stop Reports tell us what the last DN in the BSEARCH period is.
13/08 THU 00:36:56 SEQ NO: 2013
BSEARCH
-------
Last DN of the search period : 4327123 suffix 0
End of report
6. When the number of BSEARCH failures exceeds the theshold set in the
"BSEARCH Menu General Maintenance" a deferred alarm is raised and the
following printout is triggered.
SOFTWARE REPORT (B) NNI 9998031 13/08 00:36:57
SOURCE SMF_B STATUS CATEGORY 014 ALARM DEFERRED SYMPTOM ID 500
MMI 5.28 dsrch.pas 2726
No of TXE/MCU misalignment errors exceeded threshold.
0A 00
END