1 InputOutput Group 20 IOG 20 PDF

AXE System Testing 1
Input/Output Group 20, IOG 20

PREFACE
This book is intended to be used as a course material in the Ericsson

training program. The book is a training document and contains some
simplifications of any Ericsson system or tool.
The contents of this book are subject to revision without notice due to
continued development of the described systems and tools.
To be able to fully benefit from the contents of this book, the participants
should attend the course, which adds to this book exercises illustrating the
concepts, techniques and tools described.
Any comments on this book will be appreciated.
The Student Book is used in the following courses:
• LZU 108 1410
• LZU 108 1413
• LZU 108 1416
• LZU 108 1461
Responsibility
This Learning Product is prepared by:
MV/ETX/X/HCX
Table of Contents
1. Introduction to AXE IO System 5

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 SP-based IO Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Input/Output Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 HW components of an IOG 20 IO system . . . . . . . . . . . . . . . . . . . 7
1.5 IO Device Functions and Characteristics. . . . . . . . . . . . . . . . . . . 13
1.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2. Subsystems in the AXE IO System 17

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Subsystems in SP-based IO Systems . . . . . . . . . . . . . . . . . . . . . 17
2.3 Support Processor Subsystem (SPS) . . . . . . . . . . . . . . . . . . . . . 18
2.4 Man-machine Communication Subsystem (MCS). . . . . . . . . . . . 20
2.5 File Management Subsystem (FMS) . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Data Communication Subsystem, DCS . . . . . . . . . . . . . . . . . . . . 23
2.7 The Software Structure of the IO Subsystems. . . . . . . . . . . . . . . 27
2.8 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3. Hardware Structure 31
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Hardware structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Hardware configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Subracks and boards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 LED’s and Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4. FMS applications 43
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 FMS Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Storage medium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 File attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1
IOG 20
4.7 Operation of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.8 The duplicated file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.9 Corrupt Files and File Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.10 File protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.11 Infinite Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.12 File Process Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.13 Decompression of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.14 Command Log in AXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.15 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5. System Backup Handling 85

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2 Backup Functions of the CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.3 Command Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4 Backup of the SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6. MCS applications 107

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2 The functions of MCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3 Alarm Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.4 Routing of Printouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.5 Standby Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.6 Device Attendance Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.7 Alphanumeric Information on File . . . . . . . . . . . . . . . . . . . . . . . 127
6.8 MCS directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.9 The MCS Transaction Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.10 Command file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.11 IO device load regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.12 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
7. MCS - Command handling 141

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.2 AXE Command Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.3 Entry Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.4 Subcommands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7.5 Local Mode and CPT Commands . . . . . . . . . . . . . . . . . . . . . . . 146
7.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
2
Table of Contents
8. DCS Applications 149

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.2 General on Data Communication . . . . . . . . . . . . . . . . . . . . . . . 149
8.3 The OSI Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
8.4 General on DCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
8.5 DCS concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
8.6 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
8.7 Network Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.8 Connection of DCS ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
8.9 Definition of Port for AT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
8.10 Definition of Port for X.25 Data Link . . . . . . . . . . . . . . . . . . . . . 175
8.11 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
9. Support Processor Subsystem (SPS) 181

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
9.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
9.3 The Hardware of SPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
9.4 The Software Functions of SPS. . . . . . . . . . . . . . . . . . . . . . . . . 182
9.5 SP Hardware Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
9.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
10. Start of SPG 189

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
10.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
10.3 Start System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
10.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
10.5 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
10.6 Cold Start or Single Start of Both Nodes . . . . . . . . . . . . . . . . . . 196
10.7 Command Initiated Restart of Node . . . . . . . . . . . . . . . . . . . . . 197
10.8 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
3
IOG 20
4
1. Introduction to AXE IO System
Chapter Objectives
After completing this chapter the student will:
• Describe the two main tasks of the IO group
• Name the different units and buses that together constitute an IOG
20
• Explain the concepts node and link
• Explain the concept SPG and give the RP addresses used by the IO
system
• Explain the main usage of the hard disk drives, flexible disk drive
and optomagnetic disk drive
• Explain the main usage of data links in an IOG
Figure 1.1
Chapter Objectives
1.1 Introduction
This chapter gives an overview of the IO system IOG 20 in the AXE.
1.2 SP-based IO Systems

This book provides a description of SP-based IO Systems as suited to the
work of AXE system technicians. SP is an abbreviation for Support Proc-
essor, the separate processor that controls the IO system. The IO system
may be controlled by one or up to eight support processors.
Several variants of SP-based IO systems in AXE exist today:
IOG 11 A, IOG 11 B, IOG 1 C, IOG 11 B5, IOG 11 C5, IOMC, IOG 20 B-
P, IOG 20 B and IOG 20 C.
This book deals with IOG 20 B-P, IOG 20 B and IOG 20 C only. The
functionality of the IOG 20 and the variants of IOG 11 is similar. In some
cases this book will indicate when a certain function is unique for IOG 20,
as compared to IOG 11.
The three versions of IOG 20 are described in detail later, but they are, in
short two full size versions, for serial and parallel RP bus, and one com-
pact size version.
R1B 5
AXE IO System, IOG 20
Note that an IOG 20 and an IOG 11, theoretically may coexist in the same
switch, but its not recommended.
The description will include such general topics as:

• the subsystems included in SP-based IO Systems
• the hardware configuration
• supported external medias
• terminal definition
• the file system
• data links
• command handling and general operation procedures for SP-based IO
systems
• MCS Transaction Log
• Infinite files
• File Process Utility
As well as more advanced topics such as:

• external data link protocols
• inter-node communication in SPG
• CP-SP communication
• function change in SP
• SP backup
• SP co-processor dump
• hardware maintenance functions
• SP Trace System Log
• SP system parameters
• SP Restart Log
• SPS Event Log
• Direct File Output
• Start up of IOG 20
1.3 Input/Output Functions

The tasks of the AXE IO system can be generally described as follows:
Handling of data to and from the Central Processor, CP. Thus IOG 20 is
the IO interface to the world outside an AXE exchange. The data may be
alphanumeric, like printouts, commands and alarms, statistic and charging
data. The data may also be binary like software backups, etc.
Secondary storage (mass storage) of information on magnetic media, e.g.
hard disk, optical disk and flexible disk.
6 R1B
Introduction to AXE IO System
From the above considerations we see that the hardware of the IO system
must contain the following components:
• an interface to the Regional Processor Bus (RP Bus) for connection of
the IO to the central processor
• a processor with the necessary software to control the different units,
diagnose faults and to communicate with the CP
• external mass storage devices (hard disks, optical disks and flexible
disks)
• data links for both high speed and low speed traffic using both asyn-
chronous and synchronous transfer
• alphanumeric terminals for man-machine communication
As well as the above units, the IO group is also required to provide alarm
information on the alarm panels and alarm printer.
The alarm information concerns both internal alarms from APT, APZ and
the IOG itself, as well as external alarms (temperature, humidity, door
control, etc.).
Thus the IOG must also contain:

• an alarm printer - i.e. an alphanumeric terminal to which alarm print-
outs are automatically routed. A separate alarm printer is normally
defined (but any AT and slave printer can be used).
• an alarm interface to which alarm panels and external alarm sensors are
connected
1.4 HW components of an IOG 20 IO system

The above mentioned components are incorporated in IOG 20 as shown in
Figure 1.2. (It should be noticed that this is a simplified diagram with
regard to the IO device connections.)
R1B 7
RP-bus
CP
SP ICB SP
RPV/RPV2 RPV/RPV2
HD HD
AT AT
Alarm HD HD
paneI
ALI
External FD FD
alarm
AT, printer
OD OD
DL DL
AMTP
Figure 1.2
Example of an IOG 20 HW configuration
Figure 1.2 shows a standard IO configuration for the products IOG 20 B-P
and IOG 20 B. The differences between the variants of IOG 20 will be
covered later.
The interface to the RP bus is called the RP Bus Adapter VME (RPV or
RPV2).
The RPV acts as a regional processor, with its own unique RP address, that
is adapted to the task of communicating between the control unit in IOG
20 and the CP. The RPV converts the RP bus interface to a VME bus inter-
face.
8 R1B
RP-bus
CP
Ethernet
SP ICB SP
RP bus
RPV/RPV2 RPV/RPV2
HD HD
AT AT
HD HD
ALI
FD FD
AT, printer
VME bus OD OD
PC/AT
DL DL VSA
SCSI-2
AMTP
VSA - VME to SCSI-2 adapter
Figure 1.3
IOG 20 buses
Internally in the IOG 20 the interfaces VME bus, SCSI-2 bus, PC/AT and
Ethernet are used.
The Ethernet bus follows ISO 8802-2 and IEEE 802.2, 802.3.
SCSI-2 - Small Computer Systems Interface.
VME - VERSA Module Eurocards.
VSA - VME to SCSI-2 adapter.
R1B 9
P a r a ll e l R P SP
RPV VM E bus
bus
CP
S e ria l R P b u s
RPV2 SP
CP VM E bus
Figure 1.4
Interface between RP-bus and internal IOG bus
The RPV converts from a parallel RP bus interface while the RPV2 con-
verts from a serial RP bus to VME bus.
The control unit in IOG 20 is a processor called the Support Processor, or
SP for short.
The support processor in IOG 20 is based on the Motorola 68060 micro-
processor. The processor is called CPU60.
The CPU60 has an internal memory of 32 Mb. Furthermore, a certain
amount of data required by the SP is stored on the hard disks and used by
the SP when required.
The CP also contains a fairly large amount of software which is part of the
IO system. This is described more in detail later in the book.
As can be seen, the RPV (or RPV2) and SP are duplicated in the standard
IOG 20 configuration. This is done as a precaution against faults (HW or
SW) arising in one of the SP’s.
10 R1B
RP bus
CP
Node Node
ICB
SPG
Figure 1.5
Support Processor Group, SPG
The two SP’s in an IOG are connected by the Inter Computer Bus, ICB.
The ICB allows data to be transferred between the two SP’s. It is an Ether-
net bus.
The SP, file medias, and CP interface forms what is called a node.
The nodes in the duplicated configuration shown in Figure 1.2 are desig-
nated Node A and Node B.
The logical connection between the CP and SP, via the RPV (or RPV2)
and the RP bus, is called a Link.
The IO devices shown in the figure are the following:
AT Alphanumeric Terminal
AMTP Alphanumeric terminal over Ericsson MTP
ALI Alarm Interface
HD Hard Disk
FD Flexible Disk
DL Data Link
OD Optical Disk
An IOG 20 as described above - with two SP’s (or nodes) each controlling
a number of IO devices - is called a Support Processor Group, SPG. An
SPG and an Input output group, IOG, are equivalent concepts. An SPG
may only have two SP’s (or nodes).
R1B 11
A Support Processor Group is shown in Figure 1.5. Remember that the

nodes in a SPG contain independent processors. The situation is different
from in the central processors where the two sides are executing the same
code.
CP
RPB-A
RPB-B
Node Node Node Node
ICB ICB ICB ICB
Node Node Node Node
SPG-0 SPG-1 SPG-2 SPG-3
Figure 1.6
Multi SPG configuration
It is possible to connect up to four SPG’s to the CP, as is shown in Figure

1.6.
As can be seen from the figure, each SPG is numbered, with the first SPG
being designated SPG 0.
Most AXE exchanges with IOG 20 will require just one SPG, i.e. SPG 0,
whereas exchanges requiring very large amounts of output data storage
and transfer would require two or three SPG’s.
SPG 1, SPG 2, and SPG 3 provide basically separate processors for han-
dling such data. They thus relieve the workload of the SP’s in SPG 0
which can thus be used to handle the alphanumeric IO devices and alarms.
The data stored in SPG>0 is normally charging and statistics data which is
subsequently transferred to remote destinations on high speed data links.
Also if separate functions like Statistics subsystem or Remote Measure-
ment subsystem are used in the exchange it is recommended to locate them
to a separate SPG.
We will look more at this later when we examine the different possible
IOG configurations.
12 R1B
In SPG 0, the link at Node A is designated Link 0 and at Node B is desig-

nated Link 1.
In SPG 0, Link 0 has RP address RP-1, Link 1 has RP address RP-4.
In the other SPG’s the corresponding designations are:
SPG 1 Link 0 (RP-5) and Link 1 (RP-6)
SPG 2 Link 0 (RP-7) and Link 1 (RP-8)
SPG 3 Link 0 (RP-9) and Link 1 (RP-10).
Note: the reason for allocating RP addresses 1 and 4 to SPG 0 is the fol-
lowing: The central processor is designed to search for a backup file on RP
address 1 when doing a spontaneous reload. The RP-1 is therefore allo-
cated to the A-node of the SPG. The RP address 2 is dedicated for the
function change RP. The RP address 3 is dedicated for IOG 3 functions (it
was a requirement that IOG 3 and IOG 11 should be able to interwork in
the same switch). IOG 11 and IOG 20 may interwork in the same switch.
The next consecutive RP-4, is then selected for the B-node of the SPG.
1.5 IO Device Functions and Characteristics

The IO devices that may be connected to AXE, via the IO system, have
already been mentioned. They will now be examined in more detail.
Alphanumeric Terminal (AT) is the device used for man-machine com-
munication. The AT’s are thus used for sending commands and receiving
printouts.
An AT can be any type of asynchronous terminal, normally a personal
computer (PC) or a Work Station (WS). It can also be a line printer, e.g.
the alarm printer is also an AT.
The AT terminal may also be used for machine-machine communication.
Two examples are:
Alarm interface AT-1 is usually dedicated as an interface to the
external alarm connecter(s) and to the alarm
panel(s).
AUC interface When using an Authentication Centre in the GSM
mobile telephony network it may be connected
as an AT terminal.
There are a number of different communication programs for PC and WS,
for example FIOL (for DOS), WINFIOL or AXEUSE (for Windows) or
WIOL via TENUX (for UNIX).
Alphanumeric Terminal over Ericsson MTP (AMTP) is another device
used for man-machine communication. It has the same characteristics as
an AT but is used for terminals connected over a long distance. The AMTP
is connected over the Ericsson MTP protocol over the packet switched net-
work (X.25).
R1B 13
Whether to connect an AT or AMTP terminal is decided by the distance

and transmission facilities between the switch and the operator.
Alarm Interface (ALI) is the interface to which the alarm panels and
external alarm sensors are connected. Thus external alarm information is
sent to the SP, and internal and external alarm information sent to the
alarm panels, via this interface.
As we shall see when we look at the hardware configuration, the ALI is
connected to the SP in exactly the same manner as an AT device. It com-
municates with the SP via an AT device and is defined in the data as such.
The external alarm indications are then received by the IO system as ‘com-
mands’ and the orders to the alarm panel (turn on lamp, turn off bell) are
sent as ‘printouts’.
It should be noticed from Figure 1.2 that in the standard configuration the
ALI is usually only found in the A- node.
In the SP and CP reference packages, four AT devices are predefined in
the initial data:
AT-0 alarm printer
(operation)
AT-1 connected to the alarm interface, ALI
AT-4 normal AT for use once the IOG has been started
(maintenance)
AT-5 as AT-4 (or ALI in node if this exists)
Note: terminals of type Type Writer, TW, are not connected via IOG 20
but to the subscriber stages of the switch. These terminals are part of the
IO system but not described in this book.
Hard Disk (HD). The number of hard disks per node varies between the
different IOG 20 variants.
Each hard disk has a capacity of 2 or 4 Gb.
IOG 20 B-P and IOG 20 B hold 1-3 hard disks per node.
IOG 20 C holds 1 hard disk per node.
The HD unit is used to store many different kinds of information. It stores
backup of all software in the AXE switch (including base stations), CP and
SP exchange data, different logs, statistics data and charging data.
A central processor may reload from two sources: its own primary mem-
ory or from a hard disk.
The hard disks are connected to the SP via the SCSI-2 bus.
Flexible Disk (FD) is a mass storage unit for replaceable diskettes. The
diskette size is 3 1/2 inches and storage capacity is 1,44 Mb when format-
ted.
14 R1B
Two formats exist:

• the Ericsson-specific APN format
• MSDOS
Diskettes are used as moveable media. Examples of their use are the load-
ing of SP software at initial start of IOG 20 and the loading of command
files.
The CP reference dump can also be copied to hard disk from diskettes
prior to initial loading of the CP. However, optical disk is normally more
convenient for this due to the large number of diskettes otherwise required.
The flexible disk drive is connected to the SP via a PC/AT interface.
Diskette drive is not included in IOG 20 C.
Optical Disk (OD), the complete name is Optomagnetic Disk, is a mass-
storage unit for replaceable disks. The OD exists in two formats:
• 3 1/2 inch
The storing capacity of the 5 1/4” disk is 2x325 MB or 2x650 MB.
The storing capacity of the 3 1/2” is 1x640 MB.
The OD is readable, writeable and rewritable. Writing and rewriting is
realized by using the magnetic material on the disk. Before using the OD it
must be formatted.
Two formats exists:
• Ericsson-specific APN format
• the industry standard NSR02, or ISO 13346, complying to OSTA-UDF
(Optical Storage Technology Association-Universal Disk Format).
OD is mainly used for CP and SP backups but may also be used for charg-
ing and statistics data.
The opto disk drive is connected to the SP via an SCSI-2 bus and the VME
bus. In between the two buses is a converter named VSA, VME to SCSI
adapter. The reason the OD is not connected to the SCSI-2 bus, like HD, is
that it would slow down the access to HD.
IOG 20 B-P and IOG 20 B contains 3 1/2 or 5 1/4 inch OD.
IOG 20 C contains the 3 1/2 inch OD.
Data Links (DL) may be connected to the IOG via a number of different
interfaces and baud rates.
There are a number of different protocols implemented in IOG 20: the
Ericsson MTP, the File Transfer and Management, FTAM. An optional
protocol is the Direct Data Output, DDO.
R1B 15
Data links are used for transferring charging or statistics data or for alpha-
numeric terminal connection.
1.6 Chapter Summary

• the concept SP Based IO Systems in AXE includes IOMC, IOG 11A,
IOG 11 B, IOG 11 C, IOG 11 B5, IOG 11 C5, IOG 20 B-P, IOG 20 B
and IOG 20 C
• the IO system handles secondary storage medias, data links, terminal
interfaces for man-machine communication and RP-bus interface
• the IO system handles interfaces to external alarm sensors and to alarm
display
• the interface between the support processor and RP-bus is implemented
in the RPV/RPV2
• RPV interfaces to the parallel RP-bus
• RPV2 interfaces to the serial RP-bus
• the support processor in the IOG 20 is called CPU60
• one node includes one support processor
• one SPG includes two nodes
• one IO system includes one to four SPG’s
• it is possible to configure IOG 11 and IOG 20 in the same AXE
• the communication path between the CP and one node is called a Link
• each link (or node) is identified by one RP address
• the storage medias in IOG 20 are diskette, opto disk and hard disk
16 R1B
2. Subsystems in the AXE IO System
Chapter Objectives
After completing this chapter the student will be able to:
• Name the subsystems incorporated in AXE IO system
• Describe the main functions of each subsystem
• Give the names of the hardware units that are included in each sub-
system
• Give account of the formal product and function structure
Figure 2.1
Chapter Objectives
2.1 Introduction
This chapter describes the different subsystems that implements the IO
system in AXE. It also describes the formal structure of IO products and
functions.
2.2 Subsystems in SP-based IO Systems

The following subsystems belong to the AXE IO system:
SPS Support Processor Subsystem
MCS Man Machine Communication Subsystem
FMS File Management Subsystem
DCS Data Communication Subsystem
The Central Processor Test, CPT, is partly implemented in the IOG 20 and
partly in the central processor. It is not part of the IO system. CPT is part
of the Maintenance Subsystem, MAS.
The software of APT subsystems RMS and STS may also be executing in
the SP. They are not part of the IO system.
R1B 17
2.3 Support Processor Subsystem (SPS)

2.3.1 General
SPS implements the program control of the Support Processor, the SP-CP
communication function, maintenance functions for the nodes and links,
as well as several SPS operation functions.
SPS consists of the following components:
• the Support Processor (SP) with its operating system and buses
• the Regional Processor bus Adapters (RPV or RPV2)
• software for communication between CP and SP
• software for operation and maintenance and supervision functions for
the SPG
2.3.2 The Hardware of SPS
CP
SP ICB
SP
RPV/RPV2 RPV/RPV2
HD HD
AT AT
HD HD
ALI AT
FD FD
AT, printer
OD OD
AMTP
DL DL
Figure 2.2
SPS hardware
Support Processor, SP. The support processor is a real time computer

called CPU60. It is based on the Motorola M68060 processor.
At loading or reloading of an SP, PROM-stored bootstrap software is used
to initiate loading of the SP operating system and software into the pri-
mary memory of the SP from flexible disk, opto disk or hard disk. During
start up of IOG 20 the software is first transferred to the hard disk from a
number of diskettes, or from an opto disk.
The CPU60 board contains the interface towards the intercomputer bus,
ICB. The ICB is an Ethernet bus.
18 R1B
Subsystems in the AXE IO System
The CPU60 also contains a VME bus interface and a SCSI-2 bus interface.
P a r a lle l R P SP
RPV VM E bus
bus
CP
S e r ia l R P b u s
RPV2 SP
CP VM E bus
Figure 2.3
Interface CP-SP
The RPV, or RPV2, is the interface unit between the RP bus and the SP. It
transfers and receives messages to and from the CP. RPV interfaces to par-
allel RP-bus and RPV2 interfaces to serial RP-bus.
It consists basically of a microprocessor M68360 with its own operating
system. The software is stored on hard disk (as part of the SP system) and
downloaded to RPV/RPV2 at start-up.
The RPV is implemented on boards PROVME and DRPBU.
The RPV2 is implemented in board RPV2.
The IOG 20B-P is configured with RPV.
IOG 20B and IOG 20C are configured with RPV2.
2.3.3 The Software of SPS

The SPS software is situated in the processors CP, SP and RPV/RPV2.
In the SP the function blocks of all the subsystems are divided into soft-
ware units called modules. The modules are written in the real time, high
level language EriPascal. The CP software is written in PLEX-C or
ASA210C. The RPV/RPV2 software is written in C.
The operating system in the SP is named EriOS and in the RPV OSE.
OSE - Operating System Environment.
R1B 19
As mentioned above, the SPS contains the operating system of the SP and
software for handling both CP-SP communication, maintenance of the
nodes and links and a number of SPS operation functions.
2.3.4 CP-SP Communication

Communication between the SP and the CP partly follows the Open Sys-
tems Interconnection, OSI, model for data communication.
The CP regards the RPV’s as RP’s and chooses either one when sending
signals to a function block in the SP.
Normally the CP takes the direct path via the RPV, or RPV2, in the execu-
tive node, but can also access this node via the other RPV over the ICB if
necessary. A blocked or separated RPV in the executive node are exam-
ples of such a case. The SP would take the same path for communication
in the opposite direction.
The CP may communicate with either of the two nodes in a SPG, but most
functions are designed for communication with the executive node.
2.4 Man-machine Communication Subsystem

(MCS)
2.4.1 General
MCS supplies the man-machine interface for the AXE system.
MCS handles two types of information:
• Alphanumeric information (commands, printouts)
• Alarm information (internal, external)
The terminal interfaces belong to DCS as will be seen in the section on this
subsystem.
MCS interworks with all command receiving and printout generating
blocks. It also interworks with all SP and CP program blocks that generate
alarms.
20 R1B
2.4.2 The Hardware of MCS
CP
SP ICB SP
RPV/RPV2 RPV/RPV2
HD HD
AT AT
Alarm HD HD
paneI
ALI AT
FD FD
External
alarm AT, printer
OD OD
AMTP
DL DL
Figure 2.4
MCS hardware
The hardware of MCS consists of:

• alphanumeric terminals
• alarm interface, ALI
• external alarm connectors
• alarm panels
The alarm interface consist of two boards: ALCPU and ALEXP.
The MCS function block AT in the CP handles inputs and outputs to and
from the AT devices. AT block is software only. The AT devices them-
selves with the exception of the ALI are not part of the MCS hardware.
Any suitable asynchronous terminal can be connected to the IOG.
As will be seen later, the AT’s are physically connected to hardware inter-
faces belonging to subsystem DCS.
2.4.3 The Software of MCS

The software of MCS executes in CP, SP and EMRP.
The main functions of MCS software are:
R1B 21
• administration of alphanumeric data

• service functions for alphanumeric IO devices
• MCS transaction log
• MCS user directories (SP authority system)
• alphanumeric device block functions (AT, AF, AMTP, TW)
• administration of alarms (from CP and SP)
Note that the blocks of MCS are adapted to the FORLOPP function.
2.5 File Management Subsystem (FMS)

2.5.1 General
FMS incorporates hardware and software for handling the external mass
storage requirements of AXE.
The software of FMS executes both in the CP and the SP.
FMS interworks with SPS, MCS, DCS and a number of file users in other
different subsystems.
2.5.2 The Hardware of FMS
CP
SP ICB SP
RPV/RPV2 RPV/RPV2
HD HD
AT AT
HD HD
ALI AT
FD FD
AMTP AT, printer

OD OD
DL DL
VSA
Figure 2.5
FMS hardware
22 R1B
The hardware of FMS consists of:

• the hard disks, HD
• flexible disks, FD
• opto disks, OD
• VME to SCSI-2 bus interface board, VSA
The hard disks are connected to SP via an SCSI-2 bus.
The flexible disks are connected to SP via a PC/AT interface.
The opto disks are connected to SP via the VME bus which is converted to
SCSI-2 bus in the VSA. The reason for this is speed, the OD would slow
down the fast accesses towards the hard disk if they were connected to the
same bus.
VSA. The VSA board is an interface board between the VME bus and the
SCSI-2 bus. The board is used to connect the opto disk to the VME bus,
via the SCSI-2 interface. It is part of FMS.
The VSA board contains a Motorola MC68360 processor.
2.5.3 The Software of FMS

The software of FMS is divided between the CP and the SP. The software
handles:
• file functions, e.g. reading, writing or deleting data on file
• service functions, i.e. functions initiated by operator commands for
defining, removing, copying and renaming files, writing command
files, reading files and handling diskette and opto disc media
• file processing functions, i.e. functions for sending files over data links
or transferring them to opto or flexible disk, and removal
• the Command Log function for logging commands that manipulate
exchange data in the CP
• compression and decompression of files
• recovery of corrupt files
• file security functions
2.6 Data Communication Subsystem, DCS

2.6.1 General
The structure of DCS is based on the Open Systems Interconnection (OSI)
model, i.e. a layered structure for data communication that is in general
use today.
It is not absolutely necessary to know the principles of the OSI model for
normal operation of IOG 20.
R1B 23
DCS software executes in the SP and in the Line Unit Module, LUM. The
subsystem is different from the other three IO subsystems which exist in
both the CP and SP.
Data to/from AT’s or data links enters the AXE IO system via DCS func-
tions and is then transferred to either MCS or FMS within the SP.
DCS interworks with SPS, FMS and MCS.
DCS offers communication services and provides interfaces to data net-
work users.
It provides network services comparable to a stand-alone X.25 packet
switching system, which allows connection to external X.25 equipment
and X.25 networks.
The EX node provides a data communication interface towards external
connected equipment.
A CM is a logical concept. It defines logically the presence of DCS in the
node. In most cases it is correct to say that CM and node are equivalent
concepts.
The CM are numbered according to SPG number as follow:
SPG0, node A CM-1
SPG0, node B CM-2
SPG1, node A CM-17
SPG1, node B CM-18
SPG2, node A CM-33
SPG2, node B CM-34
SPG3, node A CM-49
SPG3, node B CM-50
DCS also provides an alphanumeric terminal interface based on X.28/
X.3/X.29 recommendations for the connection of asynchronous terminals
to synchronous X.25 equipment.
24 R1B
2.6.2 The Hardware of DCS
CP
SP ICB SP
RPV/RPV2 RPV/RPV2
HD HD
AT AT
HD HD
ALI AT
FD FD
AT, printer
OD OD
AMTP
DL DL
Figure 2.6
DCS hardware
The hardware of the Line Unit is the Line Unit Module, LUM, boards.
This is a mother board which can hold up to four daughter boards. The
daughter boards interface to terminals and data links. Each daughter board
has one port.
The LUM board contains a Motorola M68360 and M68060 processors.
R1B 25
E ach Line U nit M o dule, LU M , m ay

ho ld a m axim um of fo ur d aug hter
bo ards
D aughter boards:
V .24/V .28/V .35/V .36/X .21
G .703 E 0 (64 kb it/s)
G .703 E 1 (2M bit/s)
T -E thernet (not introduced

at this IO G 20 release)
T o external data connections
Figure 2.7
DCS hardware
2.6.3 The Software of DCS

The software of DCS consists primarily of:
• the communication protocols (X.25, X.28, X.3, X.29 and others) that
implements the OSI layers in the SP
• network services (such as addressing and routing in data communica-
tion networks)
• command receiving functions for DCS commands
• internal supervision functions for the DCS hardware and software
• statistics functions for DCS
The software is executing in the SP and in the LUM. The LUM software is
stored on hard disk (as part of the SP system).
If the Remote Measurement Subsystem is installed in the switch, the hard-
ware is connected via DCS. An X.25 link is used for controlling the meas-
urement instruments (which are also connected to the group switch).
26 R1B
2.7 The Software Structure of the IO Subsystems

2.7.1 General
From the above, we know that the software of SPS, MCS and FMS exist in
both the CP and the SP. The software of DCS is found only in the SP.
The figure below shows the software structure of the IO system.
CP Other subsystems in CP
FILES PRINTOUTS
READ WRITE COMMANDS ALARMS
FMS SPS MCS

File handling Supervision Commands, printouts,
alarms
CP - SP communication SPS
SP
FMS MCS, alarms DCS SPS

file handling commands Communication Supervision
file access Interfaces Operating system
printouts Network
Alarm External
OD FD HD panel alarms Data links, terminals
Figure 2.8
The software structure of the IO system
Both data links and terminals are connected to DCS hardware. A com-
mand entered from an AT is thus transferred via DCS hardware and soft-
ware to MCS software. The command must then be sent to MCS software
in the CP for analysis and is thus transferred by SPS to the CP.
In the CP, the command is transferred from SPS to MCS. From MCS the
command is forwarded to the command owning block in the normal man-
ner. If the command was, for instance, to define a file in FMS then the
command owning block in FMS would - via SPS - communicate with the
required FMS software in the SP in order to write on the hard disks.
R1B 27
2.7.2 CP software
The software belong to the IO system that is executing in the CP is written
in PLEX-C and ASA210C. A software unit in the CP is called a block.
2.7.3 SP software
The software executing in the SP is written in the programming language
EriPascal. In the SP software each software unit is called a module and
has its own unique name (compare to programs in RP and blocks in CP
and EMRP).
The module is the smallest unit which may be compiled in EriPascal.
One or more interrelated modules are grouped together into a function
block.
The function block concept in the SP is thus different to that in the CP. In
the software hierarchy, a module in the SP corresponds to the central (or
regional) software unit in a CP function block.
If a program in the SP has to be changed or corrected, the module has to be
recompiled. No correction system exists in the SP. If a module is changed
and recompiled only due to a fault correction (i.e. no change in function),
it is released in a so called Rapid Correction Note Issue, CNI. A Rapid
CNI may be compared to an approved program correction in CP, RP or
EMRP.
An IOG 20 system contains about 300 modules. The number of modules
varies from system to system.
2.7.4 EMRP software

The software units of the IO system in EMRP belongs to subsystem MCS.
The code is written in PLEX-M.
2.7.5 LUM software

The software of the Line Unit Modules belongs to subsystem DCS. The
software is located in module LUCHAR79 and stored in volumes
PROG_A and PROG_B. The software is booted from the hard disk when
deblocking the line unit (command ILBLE).
The code is written in C and the operating system in LUM is PsOS.
LUM has no program correction system.
2.7.6 RPV/RPV2 software

The software of RPV/RPV2 belongs to subsystem SPS. The software is
part of the SP system (module RPVFW or RPV2FW) and stored in vol-
umes PROG_A and PROG_B. The software is loaded to the RPV/RPV2 at
power on.
The code is written in C and the operating system is OSE.
RPV/RPV2 has no program correction system.
28 R1B
2.7.7 Functional and Product Structure of SP software

The functional structure follows the Early Design Process Improvement,
EDPI, concept. The system is divided in four levels:
FAM 101 - service ordering system
FAM 102 - node type
FAH 102 - configuration object
FAX 141 - telecom object
Examples of Configuration Objects included in IOG 20 are:
FAH 102 8001 Communication Platform
FAH 102 0102 CPSA
FAH 102 0103 Data Communication Statistics
FAH 102 0104 Data Communication Network Services
FAH 102 0105 Line Interface
FAH 102 0106 Upper Layer Interfaces
FAH 102 0107 FTAM
FAH 102 0108 File Management in AXE
FAH 102 0109 AXE Command Log
FAH 102 0110 Alphanumeric Handling
FAH 102 0111 Authority System
FAH 102 0112 Transaction Log
FAH 102 0113 Alpha services
FAH 102 0114 Alarm Handling
etc.
These in turn are divided in Telecom Objects.
Example:
• FAX 141 8105 - Alarm Administration in AXE10
• FAX 141 8024 - Transaction Log
The entire system contains about 110 Telecom Objects.
The product structure is divided in:
ANZ = subsystem
CNA = function block
COA = software unit
R1B 29
CAA 119, CAA 110 = module written in EriPascal

The levels ANZ and CNA and COA are description levels - these products
contain documents, e.g. subsystem, function block and software unit
descriptions.
The CAA level consists of products, containing the program listings and
program code.
In the APZ source systems applicable to this book, the subsystems are
identified by the following designations:
DCS ANZ 216 20
FMS ANZ 217 20
MCS ANZ 218 20
SPS ANZ 219 20
2.8 Chapter Summary

• SPS - support processor subsystem handles CP-SP communication,
program execution, inter-node communication and HW maintenance
• FMS - file management subsystem handles storage and processing of
data on secondary media
• MCS - man-machine communication subsystem handles terminal com-
munication, the alarm system and printout routing
• DCS - data communication subsystem handles terminal interface, data
links, data protocols and data communication addressing, routing and
statistics
• SPG0 always contains SPS, FMS, MCS and DCS
• SPG1 to SPG3 always contains SPS, FMS and DCS
• all SPGs may optionally contain subsystems RMS and/or STS
• parts of subsystem MAS is always loaded in SPG0, this for the CPT
• SPS hardware includes the CPU60 and RPV/RPV2
• FMS hardware includes the OD, FD and HD drives
• MCS hardware includes the alarm interface boards
• DCS hardware includes the LUM boards with daughter boards
• all physical ports are located on daughter boards which are attached to
the LUM boards
• software executing in the support processor is written in EriPascal or C
• software executing in LUM and RPV/RPV2 is written in C
30 R1B
3. Hardware Structure
Chapter Objectives
• Briefly account for the main differences between IOG 20 B-P, IOG
20 B and IOG 20 C
• Describe briefly the function of each board in the SPVM, SPVM-P
and SPVCM subracks
Figure 3.1
Chapter Objectives
3.1 Introduction
This chapter describes the different hardware configurations that exist
within IOG 20. Also described are the different boards of the IO system.
3.2 Hardware structure
3.2.1 Introduction
This chapter will explain the differences between the hardware configura-
tions that exist in the SP-based IO systems IOG 20:
• IOG 20 B-P
• IOG 20 B
• IOG 20 C
Remember that a number of SP-based IO systems exist in the IOG11 fam-
ily: IOMC, IOG11A, IOG11B, IOG11C, IOG11B5 and IOG11C5. These
are not covered in this book.
All IO equipment is mounted in BYB 501 racks.
The IOG 20 rack contains one subrack:
SPVM-P in IOG 20 B-P
SPVM in IOG 20 B
SPVCM in IOG 20 C
R1B 31
3.3 Hardware configurations

3.3.1 IOG 20 B-P
Figure 3.2
IOG 20 B-P
The IOG 20 B-P interfaces towards the parallel RP bus (this is indicated
by the ‘P’).
The IOG 20 B-P theoretically has a maximum capacity of:
• 32 terminals or
32 single data links or
16 duplicated data links or a combination of this
3 hard disks per node (2 or 4 Gb)
• 1 flexible disk per node
• 1x5 1/4 or 1x3 1/2 inch opto disk per node
• 32 external alarm connections per node
• 4 alarm panel interfaces per node
• 1 SCAN alarm interface per node
The IOG 20 B-P may be used as SPG>0 if the alarm interface boards are
removed.
Note: The 5 1/4 OD and 2GB HD will be phased out shortly.
32 R1B
Hardware Structure
3.3.2 IOG 20 B
Figure 3.3
IOG 20 B
The IOG 20 B interfaces towards the serial RP bus.

The IOG 20 B theoretically has a maximum capacity of:
• 32 terminals or
• 3 hard disks per node (2 or 4 Gbyte)
• 1 flexible disk per node
• 1x5 1/4 or 1x3 1/2 inch opto disk per node
• 32 external alarm connections per node
• 4 alarm panel interfaces per node
• 1 SCAN alarm interface per node
The IOG 20 B may be used as SPG>0 if the alarm interface boards are
removed.
Note: The 5 1/4 OD and 2GB HD will be phased out shortly.
R1B 33
3.3.3 IOG 20 C
Figure 3.4
IOG 20 C
The IOG 20 C interfaces towards the serial RP bus.

The IOG 20 C theoretically has a maximum capacity of:
• 24 terminals or
1 hard disk per node (2 or 4 Gb)
• 1x3 1/2 inch opto disk per node
• 32 external alarm connections
• 4 alarm panel interfaces
• 1 SCAN alarm interface
The IOG 20 C is never used as SPG>0, although this is technically possi-
ble.
34 R1B
Hardware Structure
3.4 Subracks and boards

The SPVM, SPVM-P and SPVCM subracks are electromagnetic shielded.
3.4.1 SPVM-P subrack IOG 20 B-P

An IOG 20 B-P consists of two SPVM-P subracks.
Power
CPU60
HD3 drive
HD1 drive
VSA
PROVME
DRPBU
LUM
LUM
LUM
LUM
ALCPU
ALEXP
OD drive (5 1/4” or
3 1/2”)
HD2 drive
FD drive
Figure 3.5
SPVM-P subrack
3.4.2 SPVM subrack IOG 20 B

An IOG 20 B consists of two SPVM subracks.
Power
CPU60
HD3 drive
HD1 drive
VSA
RPV2
ESDCV
LUM
LUM
LUM
LUM
ALCPU
ALEXP
OD drive (5 1/4” or
3 1/2”)
HD2 drive
FD drive
Figure 3.6
SPVM subrack
R1B 35
3.4.3 SPVCM subrack IOG 20 C

An IOG 20 C consists of one SPVCM subrack.
HD drive
Power
CPU60
VSA
RPV2
LUM
LUM
LUM
ALCPU
ALEXP
LUM
LUM
LUM
RPV2
VSA
CPU60
Power
HD drive
OD drive
OD drive
(3 1/2”)
(3 1/2”)
Figure 3.7
SPVCM subrack
3.4.4 Boards
Power - supplies power for all boards in the subracks via the backplane.
The power-feeding is connected to the front plane. Input power is 48 volts
and output power is +5 and +/-12 volts.
CPU60 - processor board with microprocessor M68060. The primary
memory on the board is 32 MB. The CPU60 interfaces to the intercom-
puter bus (Ethernet) via the front plane and to the SCSI-2 bus, power and
VME bus in the back plane. The CPU60 has two RS232 ports on the front
plane for connection of IO terminal. The RS232 ports communicates at
4800 baud.
FD/HD drive - this board contains both 3 1/2 inch diskette drive and hard
disk drive. It interfaces to the SCSI-2 bus and power in the backplane.
HD drive - this board contains one or two hard disks. It interfaces to the
SCSI-2 bus and power in the backplane.
OD drive 3 1/2 inch - this board contains one opto disk drive. It interfaces
towards the VSA board via a separate SCSI-2 bus in the back plane. It is
also power-fed in the backplane.
OD drive 5 1/4 inch - this board contains one opto disk drive. It interfaces
towards the VSA board via a separate SCSI-2 bus in the back plane. It is
also power-fed in the backplane.
VSA - this board converts VME bus to a separate SCSI-2 bus which inter-
faces to the opto disk drive. It interfaces to VME bus, SCSI-2 bus and
power in the back plane.
36 R1B
Hardware Structure
DRPBU - this board interfaces to the parallel RP bus in the front plane. In
the back plane it interfaces to the PROVME board, via an internal inter-
face, and to power.
PROVME - this board interfaces to the DRPBU board via an internal
interface. It interfaces to the VME bus and power supply in the back plane.
RPV2 - this board interfaces to the serial RP bus in the front plane. In the
back plane it interfaces to the VME bus and to power.
LUM - this board contains a microprocessor Motorola M68060. It inter-
faces to the ‘daughter boards’ V.24/V.35/V.36/X.21 INTERFACE, G.703
E0 INTERFACE and G.703 E1 INTERFACE via a connecter on the
board. It can hold four ‘daughter boards’, each of which controls one phys-
ical port. The boards are fitted on the LUM board with four screws.
The LUM mother board interfaces to the VME bus and power in the back
plane.
Each Line Unit Module, LUM,

holds four daughter boards.
A-node
V.24/V.28/V.35/V.36/X.21
G.703 E0 (64 kbit/s)
B-node
G.703 E1 (2Mbit/s)
T-Ethernet (not introduced

at this IOG20 release)
To external data connections
Figure 3.8
LUM board with daughter boards
V.24/V.35/V.36/X.21 INTERFACE daughter board - this boards imple-

ments one physical port towards a data link or terminal. It is fitted to the
LUM board with four screws and is power-fed from the LUM board. It
supplies the interfaces V.24, V.35, V.36 and X.21.
G.703 E0 INTERFACE daughter board - this boards implements one
physical port towards a data link or terminal. It is fitted to the LUM board
with four screws and is power-fed from the LUM board. It supplies the
interface G.703 E0 with a baudrate of 64 kbit/s.
G.703 E1 INTERFACE daughter board - this boards implements one
physical port towards a data link or terminal. It is fitted to the LUM board
R1B 37
with four screws and is power-fed from the LUM board. It supplies the
interface G.703 E1 with a baudrate of 2 Mbit/s.
T- Ethernet INTERFACE daughter board - this board is not intro-
duced as an orderable product at the first IOG 20 release.
ALCPU - Alarm interface board. This board has two V.24 ports which
interface to the LUM board and to the fan. The board has a SCAN input
and input of external alarm. The board is connected to VME bus and
power in the back plane.
ALEXP- This board has four outputs for control of alarm displays. The
board is controlled by board ALCPU.
ESDCV - EMC shield and Daisy Chain VME bus circuit board. The pur-
pose of the board is to fill empty positions in the SPVM subrack. This in
order to maintain the electromagnetic shield that the subrack forms. The
board also connections the VME bus in the back plane of the SPVM sub-
rack.
Empty positions may occur if the subrack is not fully equipped with LUM
boards or if the RP bus interface is serial with one RPV2 board instead of
the DRPBU and PROVME boards. Empty positions may also occur if only
one hard disk is installed in an IOG 20 B-P or IOG 20 B node.
3.5 LED’s and Buttons

In the IOG hardware there are a number of lamps (LED’s) indicating dif-
ferent states and faults that can occur in an IOG.
• Reset and restart switch buttons. The upper button restarts the support
processor when toggled once. When toggled twice it reloads the support
processor. The lower switch halts the execution of the SP when toggled
once, it generates a level 7 IRQ.
• Display for HW test (not used).
• The lower turning strap indicates the node address (Node A - 1,

node B - 2) and the upper, the SPG index (SPG0 - 0 and SPG1 - 1).
• LED indicators (see next picture)
• CPU port, RS232 interface with 4800 baud
• Ethernet interface (ICB)
Figure 3.9
LED’s and buttons CPU60 board
38 R1B
Hardware Structure
RUN BM • RUN : Green during normal operation

Red during reset and halt
• BM - Bus Master: Green if CPU60 is bus master

FAIL EX
• FAIL: Red if system failure
• EX: Green if node executive
Figure 3.10
LED’s on CPU60 board
There are also two flip buttons on the CPU60 board front. These buttons
should only be used in special situations. The lower button is for debug-
ging of SP programs. The upper (reset button) is for restarting (flip once)
or reloading (flip twice) of the SP.
A terminal can be connected straight in to the SP on the front of the
CPU60 board. This is referred to as a local terminal. From this terminal
only SP commands can be sent. There are two RS232 connections for this
but only the upper one is used.
A local terminal is, for instance, used at initial start of IOG 20.
Normally no terminal is connected to the CPU port.
R1B 39
Yellow LED indicates Maintenance interface alarm
Red LED indicates RPV/RPV2 restart
Red LED indicates link in separated state

Green LED indicates normal state
Green LED indicates RPV/RPV2 correct program execution
Yellow LED indicates data channel open, flashes during CP reload
DIP switch for RP bus address on board
Pushbutton for separation of link
Figure 3.11
LED’s and buttons PROVME/RPV2 board
BM RUN Right LED ‘RUN’ indicates: green - processor running, red - processor
halted
Left LED ‘BM’ indicates: flashing red - LUM is working normally

off - LUM is not defined or is manually blocked
One LED per port indicates port status:

Green - operational
Red - blocked or not defined
Yellow - automatically blocked
Flashing yellow - stand by
Figure 3.12
LED’s on LUM board
40 R1B
Hardware Structure
G reen LE D indicates system running
Y ellow LE D in dicates ongoing softw are update
R ed L E D indicates S C S I term ination pow er O K
Figure 3.13
LED’s on VSA board
3.6 Chapter Summary

• IOG 20 exists in three versions: IOG 20 B, IOG 20 B-P and IOG 20 C
• all three versions are two-node SPG’s
• IOG 20 B and IOG 20 C interface to the serial RP-bus
• IOG 20 B-P interfaces to the parallel RP-bus
• the subrack implementing IOG 20 B-P is SPVM-P
• the subrack implementing IOG 20 B is SPVM
• the subrack implementing IOG 20 C is SPVCM
• all IOG 20 subracks are build according to BYB501
• all three IOG 20 versions are use the M68060 microprocessor with 32
MB primary memory
• IOG 20 C has only one HD per node
• IOG 20 C has only one 3 1/2 OD per node
• IOG 20 C can have maximum three LUM boards per node
• IOG 20 B/-P can have maximum 3 HD’s and one 3 1/2 FD per node
• IOG 20 B/-P has maximum one 5 1/4 OD per node
• IOG 20 B/-P can have maximum four LUM boards per node
R1B 41
42 R1B
4. FMS applications
Chapter Objectives
• Name the basic concepts of FMS
• Know the different types of volumes in FMS and their use
• Describe the recommended contents of volumes PROG_A,
PROG_B, OMFZLIBORD and RELVOLUMSW
• Have knowledge about operational documents and commands
related to FMS
• Have knowledge about the Infinite Files function
Figure 4.1
Chapter Objectives
4.1 Introduction
This chapter describes the functions of the file management subsystem of
AXE. The chapter concentrates on media, volume and file handling and
file processing functions.
4.2 FMS Concepts

The basic concepts of FMS are:
• Storage Medium
• Volume
• File
4.3 Storage medium

Storage medium for external data storage consists of the hard disks, flexi-
ble disks and opto disks.
The media are divided in:

• external, or removable, media - flexible disks and opto disks
• internal media - hard disks
All media needs to be formatted, in which a number of sectors are allo-
cated on the medium. The sectors have different sizes on different media.
R1B 43
The sector size is 512 bytes on 2 and 4 GB hard disks.

The file system keeps a list of the sectors that are found to be faulty during
operation. If a sectors is found to be faulty during a write operation the
sector is mapped out and put in the faulty sectors list. Another sector is
selected for writing.
A diskette may have two different formats when used in AXE.
• APN - An Ericsson-specific format which is named after the processor
APN 167
• MSDOS - Microsoft Disk Operating System
One 3 1/2 inch diskette stores 1.44 MB.
An opto disk may have two different formats when used in AXE:
• APN is an Ericsson-specific format which is named after the processor
APN 167. This format is used for SP Software Backup and SP
Exchange data.
• NSR02, or ISO 13346, complying with the OSTA-UDF (Optical Stor-
age Technology Association-Universal Disk Format). This format is
supported by the Windows NT driver. This allows both reading and
writing of files, such as TT files, in the standard format from a PC
equipped with Windows NT.
The optical disks exists in the following sizes:
2x325 MB, 2x650 MB and 1x640 MB. The 2x325 MB and 2x650 MB
optical disks will be phased out shortly.
Note: the data links may in some cases be treated as external medias.
4.3.1 Operation
The commands for handling medias are INMEI, INMEP and INATP.
Below is an example of a 2 GB hard disk attributes:
: INMEP:IO=HD-1,NODE=A;
MEDIA ATTRIBUTES
STATUS SECTS STRACK TRACKS
IN USE 512 139 36441
HEADS TOTSIZE(KBALLOCSIZE(KB)SUBUNITS
9 2096744 20757776
VOLUME SIZE(KB)
PROG_A 200000
OMFZLIBORD 100000
RELVOLUMSW 500000
EXCHVOLUME 400000
CALLVOLUME 400000
STATVOLUME 475777
END
44 R1B
FMS applications
SECTS Sector size in bytes

STRACK Number of sectors per track
TRACKS Number of tracks
HEADS Number of heads for reading and writing
TOTSIZE Total memory available to user
ALLOCSIZE Total memory used by defined volumes
SUBUNITS Number of volumes
SIZE Defined size of each volume
The command INMEI is used to format external medias, this is described
in the following section. Formatting of internal volumes is only done at
start up of the IOG. The command ISMEI is used.
4.4 Volumes
The storage area on a medium can be divided into one or more volumes.
Volumes on hard disks can be defined as being a part of one disk or they
can cover several disks, the latter is called volume across media border.
A volume is identified by a volume name of 1 to 10 characters.
Some volumes have the same names in SPG0, SPG1, SPG2 and SPG3. In
this case the contents are not the same and these volumes are completely
independent of each other.
Flexible disk 3 1/2 inch Hard disk node A node B
External,
single volumes
Internal,
single volumes
Internal,
Opto disk 3 1/2 or duplicated
5 1/4 inch volume over
media border
Internal,
duplicated
volume
Figure 4.2
Volumes in AXE IO system
R1B 45
On a hard disk there is a maximum of 16 volumes. These volumes are

called internal volumes. One volume may cover a maximum of two hard
disks.
Volumes on flexible disks and opto disks are called external volumes.
External volumes can only have one volume per media, except 5 1/4” opto
disk which has one per side, and no volumes across media border. External
medias always have a one-to-one relation to volumes.
Internal volumes can be of two kinds:

• single
• duplicated
External volumes are single volumes.
A single volume is located only in one node.
A duplicated volume:
• is located in both nodes of an SPG, i.e. exists in two ‘copies’
• has a volume name of ten characters length
• the data in the duplicated volume is the same in both nodes in normal
operation
The reason for having duplicated volumes is security. When writing to a
file on a duplicated volume the data is physically written in both nodes of
the SPG. If the standby node is blocked nothing is written on the dupli-
cated volume of that node. If a difference between the contents of a dupli-
cated volume, between the nodes, is detected a recovery action is initiated.
This involves a restart of one of the nodes and an updating.
The data in the duplicated volumes is logically identical, not physically.
This means that the actual physical location on the hard disk may differ
between the nodes for a file in a duplicated volume.
Volume supervision. FMS has a supervision of the used space on a vol-
ume. The function issues the alarm VOLUME LIMIT EXCEEDED if the
supervision limit is passed. The supervision limit is set in percent of the
available volume space and the function is turned off by setting the limit to
0%.
Command example:
:INVOC:VOL=EXCHVOLUME,LIMIT=75;
In the example above the volume supervision of volume EXCHVOLUME
is set to 75%. If the volume is filled to more than 75% an alarm will be
issued.
4.4.1 Operation
The commands for handling volumes are INVOP, INVEP, INVOI,
INVOL and INVOC.
46 R1B
FMS applications
Command example:
:INVOP:VOL=OMFZLIBORD;
VOLUME ATTRIBUTES INTERNAL
REV DATE TOTSIZE(KB) USEDSIZE(KB LIMIT
1 991231 100000 5528 99
NODE1 IO1 SIZE1(KB)
A HD-1 100000
NODE2 IO2 SIZE2(KB)
B HD-1 100000
END
Example of formatting an opto disk:
< INMCT:SPG=0;
:INMEI:NODE=A,IO=OD-1,FORMAT=APN,VOL=TRAINING;
ORDERED
:END;
EXECUTED
VOLUME/MEDIA INITIATED
EXECUTED
NODE IO VOLUME FORMAT
A OD-1 TRAINING APN
END
Note: For diskette IO=FD-1
The volume name is written on the diskette or opto disk. The Support
Processor keeps no record of these volumes. Therefore, before working
with a diskette or an opto disk the volume table of contents (VTOC) has to
be loaded into the system. This is loading the volume and done with com-
mand INVOL.
Example of loading an external volume:
< INMCT:SPG=0;
:INVOL:NODE=A,IO=OD-1;
ORDERED
:END;
EXECUTED
VOLUME LOADED
EXECUTED
VOLUME NODE IO FORMAT
TRAINING A OD-1 APN
END
Before removing a diskette or opto disk, the volume must be unloaded
using the command INVOE. If this is not done, the device cannot be used
for another diskette or opto disk.
R1B 47
The formatting of hard disk and definition of volumes is not part of the
ordinary operation and maintenance activities of the IO system.
4.4.2 Standard internal volumes

The following system defined volumes are always found on the hard disks
in IOG20:
• PROG_A
• PROG_B
• OMFZLIBORD
• RELVOLUMSW
Node A Node B
Mandatory
volumes
463+C% 463+C&
31*>0-&36( Optional
31*>0-&36(
volumes
6)0:30917; 6)0:30917;
)<',:3091) )<',:3091)
',%6:3091) ',%6:3091)
78%8:3091) 78%8:3091)
0-78:3091) 0-78:3091)
Figure 4.3
Standard internal volumes
The volumes are shown in Figure 4.3. In addition to these, some market
dependent volumes are usually defined for charging and statistics data
The volumes PROG_A and PROG_B are unduplicated, and usually the
only unduplicated volumes. PROG_A is located in node A and PROG_B
in node B. The volumes contain SP software, including RPV/RPV2 and
LUM software and the SP system files. If the SP Trace System function is
activated, the SP Trace logs are stored here.
The reason these volumes are unduplicated is that the SP software in two
different nodes need not be identical.
PROG_A and PROG_B reside in all SPG’s.
48 R1B
FMS applications
OMFZLIBORD is a duplicated volume for storage of SP system data. It

contains files for the SP exchange data and a series of logs and other files
used for SPG maintenance functions, as well as other files created by the
SP when required. SP exchange data for the Remote Measurement Subsys-
tem (RMS) and Statistics and Traffic measurement Subsystem (STS) are
also stored here if loaded.
OMFZLIBORD resides in all SPGs.
RELVOLUMSW is a duplicated volume for storage of Central Processor
back up files and the command log. If the switch is a mobile application
then the radio base station software is also stored in this volume. The vol-
ume is also used for temporary storage of SP software.
RELVOLUMSW resides only in SPG0.
A hard disk can contain up to sixteen volumes and usually some market
specific volumes are created on the disk.
The volume EXCHVOLUME is used as a default volume name if no spe-
cific market requirements on alternative name exists. This volume is dupli-
cated and is used for charging and statistics data.
The volume CHARVOLUME is often defined and used for charging
data. The volume is duplicated.
If defined, the volumes STATVOLUME or LISTVOLUME are used for
statistics data.
4.5 Files
Files are stored in volumes. A file contains data and is physically located
on one or more positions on the media (within a certain volume). A file
cannot be stored in two volumes at the same time. A file cannot start in
one volume and end in another.
A file is identified by a filename of 1 to 12 characters. A filename may
only be used once in an AXE system (exceptions to this rule exist).
Each file is divided in a number of records. Records are of predefined
lengths and, in certain file types, divided into subfields.
4.6 File attributes
4.6.1 File class

Files in FMS belong to one of three file classes:
• Simple - SPL
• Composite - CMP
• Device - DEV
A simple file is just a normal file.
R1B 49
A composite file is a file that consists of a mainfile and one or more sub-
files. The mainfile contains no data and operates as an ‘umbrella’ or
‘directory’ to the subfiles. All data in a composite file is stored in the sub-
files. There is no limit to the number of subfiles. A subfile name may be 1
to 12 characters long, if the subfile is located on hard disk. Subfile names
on other medias are shorter, see the command description for command
INFII.
Simple file data

data....
Composite Main file

file
data data data

data... data... data...
Sub files
Figure 4.4
Simple and composite file types
A device file is a file identifying an external media where data to be writ-

ten. One unique device file must be defined for each external medium
(more than one may be defined, but this is unnecessary).
Device files may be defined for devices of type:

• Flexible Disk drive
• Optical Disk drive
• Data Link
It is possible to define device files directed to SP primary memory, but this
is never done.
In SPG 0, the device file names should be defined as:

• FD0A1 for FD-1 in the A node
• FD0B1 for FD-1 in the B node
• OD0A1 for OD-1 in the A node
• OD0B1 for OD-1 in the B node
50 R1B
FMS applications
According to the file name convention the third character in the device file
name indicates the SPG index and the fourth character the node.
As an example: in SPG 3, the device file names should be defined as:

• FD3A1 for FD-1 in the A node
• FD3B1 for FD-1 in the B node
• OD3A1 for OD-1 in the A node
• OD3B1 for OD-1 in the B node
To identify the files on the external medias (FD/OD) the name of the
device file and the file name on the media must be specified. Example, to
identify a file called ANYFILE on a diskette in FD-1, node A, SPG0, then
the file must be referred to as FD0A1-ANYFILE. This is similar to the
designation of subfiles of a composite file on hard disk.
The device file naming is only a convention, they may be named in any
way.
Device files for data link is only used in conjunction with the Direct File
Output function and then named according to the function it serves.
4.6.2 File Type
File Type can be one of the following:

• Sequential (SEQ)
• Direct Access (DIR)
• Keyed Access (KEY)
Sequential Direct
access access
1
Record no. 1
Record no. 2
2
Read 3
3
4
4 from 5
5 top 6
6 down -
-
-
-
-
-
-
-
..or read Read
record record
no. 102 no. 765
Figure 4.5
Sequential and direct access file type
R1B 51
Sequential files are files written in chronological order. Each new record is
written in sequence after the previous one. Each record is numbered.
Reading of the records from a sequential file is done in the same order as
they were written, or according to record number.
Direct access files consist of a finite number of records where each record
is given a record number, just like sequential file. Reading and writing in
the file is done directly using the record number. Direct access can be con-
sidered as a special case of sequential access.
Read all
records with
Fiat
Records with subfields:

Key Key Data Data
1973 Fiat Via Torino green
1988 Nissan Nanjing road white
‘year’ ‘carmake’ ‘address’ ‘colour’
Figure 4.6
File class key
A key access file may be compared to a very simple data base. The reading
of a key file is not done specifying a certain record but by specifying a
‘search criteria’ or a key. An example is given in the Figure 4.6 above
where a read order to the file system could be interpreted as ‘read all
records with FIAT in keyfield number 2’. Another example could be ‘read
all records with a value larger than 1973 in keyfield 1’.
Only one search key may be specified in a read operation.
A key access file consist of a number of records with one or more sub-
fields.
52 R1B
FMS applications
The subfields may be of three different kinds:

• data
• key
• keyunique
The data subfields contains any kind of data. A read (or ‘search’) in the
file cannot be made in data subfields. A record may contain more than one
data subfield.
A key subfield contains data which can be used as search key when read-
ing a file. A record may contain more than one key subfield.
A keyunique subfield contains data which can be used as search key when
reading a file. The keyunique subfield contains data that is unique, i.e. no
other record may contain this data in this keyfield. A record may contain
more than one keyunique subfield.
Most files of type key only uses data and key subfields.
The combinations of file types and classes are the following:
Simple or composite files may be sequential, key or direct access.
Device files are sequential.
4.6.3 Record length, size and expansion factor
Write
Initial
size
Expansion Write
factor
Write
Expansion
factor
Record
length
Figure 4.7
R1B 53
File attributes size, expansion factor and record length
When defining a file the space allocated on the media is according to the
size attribute. The parameter indicates number of records.
When the initially allocated area is written, the file is expanded with the
number of records indicated in the expansion factor.
Note that the expansion factor may be overridden by the MAXSIZE
parameter in the Infinite Files function. See the Infinite Files section.
The record length indicates number of bytes per record. Which record
length is suitable depends on the format of the written data, i.e. on the
writing application. The suitable record length for a file can often be found
in the application information for the file-using application.
4.6.4 Blocking factor
Physical space on
hard disk:
block 3
block 4
Start of file End of file
Blocking factor
n records block 1
block 2
Figure 4.8
Physical allocation of a file on hard disk
The file is physically stored in a number of blocks. Each block is a number

of consecutive sectors on the media. A block consists of a number of
records. The blocking factor may be defined by command but the system
calculated default value is preferably used.
Note that there are files on the hard disk that are not divided into blocks
but are stored continuously on the hard disk. That is, they are stored in one
long block. Example of such files are the SP modules which are stored in
volumes PROG_A and PROG_B.
54 R1B
FMS applications
4.7 Operation of files

A new file is created with the command INFII. This is explained in the
OPI ‘SPG, File on Hard Disk, Define’. See also the OPI ‘FMS Output
Files, Definition Recommendations’.
A file must be given a unique name. Some names are system defined, oth-
erwise the name can be chosen either according to recommendations or at
random.
When a file is created on hard disk it must be put in a volume.
Example of creation of file on HD:
< INMCT:SPG=0;
:INFII:FILE=RELFSW2,VOL=RELVOLUMSW,
TYPE=SEQ,FCLASS=CMP,RLENGTH=2048,SIZE=16,EXP=64;
In the example above a Central Processor backup file is created (all CP
backup files are named RELFSWn). It is located in volume REL-
VOLUMSW.
The record length is 2048 bytes and the initial file size is 16 records. If this
size is reached (as it will be in this case) the subfiles will expand in steps
of 64 records.
When a device file is to be created the same command should be used but
with another parameter combination. This is explained in the OPI ‘SPG,
Device File, Define’. Here the file device must be given instead of the vol-
ume.
Example of creating a device file:
< INMCT:SPG=0;
:INFII:FILE=FD0A1,NODE=A,IO=FD-1,TYPE=SEQ,
FCLASS=DEV,RLENGTH=512,SIZE=0,EXP=10;
Remember that a device file is a file pointing out a device (i.e. FD, OD,
DL or Primary Memory in SP) where files are allocated. A file on a device
will come up as a subfile to that specific device file. The example below
shows the Ericsson recommendation of naming device files.
< INMCT:SPG=0;
:INFIP:FCLASS=DEV;
FMS FILE DATA
FILE FCLASS SPG VOL NODE IO
FD0A1 DEV 0 - A FD-1
FD0B1 DEV 0 - B FD-1
OD0A1 DEV 0 - A OD-1
OD0B1 DEV 0 - B OD-1
END
R1B 55
Note that the file names above are Ericsson conventions. When using the
function Direct File Output the device files will have other names.
It is only necessary to have one device file for each file device e.g. FD0A1
is a pointer to the flexible disk drive in node A and FD0B1 is a pointer to
the flexible disk drive in node B, etc. All files on a diskette in node A will
come up as subfiles to the device file FD0A1.
If the same diskette is used in node B the files will come up as subfiles to
FD0B1. The files thus have unique names on the diskette, e.g. FDFILE1,
but they must be addressed however by the full name, e.g.
FD0A1-FDFILE1.
Example of files on a diskette in node A:
< INMCT:SPG=0;
:INFIP:FILE=FD0A1;
FILE ATTRIBUTES
RLENGTH BLK SIZE EXP
512 4 0 10
TYPE NFIELDS NKEYS NUSERS
SEQ 0 0
FCLASS
DEV
SUBFILES
FD0A1-FDFILE1
FD0A1-FDFILE2
END
Here we see that two files FDFILE1 and FDFILE2 exist on the diskette.
It should be noticed that diskette and opto disk files are not subfiles to the
device files in the same sense as subfiles to a composite file on HD. Only
composite files have subfiles. They appear as subfiles here because of the
standard text SUBFILES in the printout format. Only the actual file name
but not the device file name is written on the disk/opto disk.
As seen above, to print the attributes of a file the command INFIP is
used. The command can print a list of all defined files, all files of a given
file class, all files in a given volume or data for a unique file.
A printout of the data for the CP backup file defined earlier is given below:
:INFIP:FILE=RELFSW2;
FILE ATTRIBUTES
RLENGTH BLK SIZE EXP
2048 4 16 64
TYPE NFIELDS NKEYS NUSERS

SEQ 0 0
56 R1B
FMS applications
FCLASS
CMP
SUBFILES
RELFSW2-R0
RELFSW2-R1
RELFSW2-R2
RELFSW2-R3
RELFSW2-R4
RELFSW2-R5
END
4.7.1 Removal of a File

A file can be removed with the command INFIR (for more information
see the OPI ‘SPG File, delete’).
A removed file may not be restored.
4.7.2 Copying of Files

Copying of files can either be done internally on hard disk or externally
between hard disk and moveable media or between two moveable medias.
The procedures are described in the OPI’s ‘FMS, Internal Files, Copy’,
‘FMS, Removable Media Files, Copy’ and ‘FMS, SPG to SPG, Files
Copy’.
Command INFIT is used to copy data stored in one file to another when
both files are stored on hard disk in the same SPG. The destination file
must be created in advance.
If files are to be copied between hard disks in different SPGs the command
IOFIT is used.
R1B 57
RPB-A
CP
RPB-B
SP ICB
RPV/RPV2
HD
AT
HD
Commands
ALI INFIT, IOFIT
FD
and INFET
OD
DL
Figure 4.9
External transfer of file information
Command example:
< INMCT:SPG=0;
:INFIT:FILE1=HDFILE1,FILE2=HDFILE2;
ORDERED
:END;
EXECUTED
FILE COPY INTERNAL
EXECUTED
SOURCE FILE DATA
FILE
HDFILE1
DESTINATION FILE DATA
FILE
HDFILE2
END
Command INFET is used to copy files between hard disk and movable
media, diskette or opto disk. The command is also used for copying a file
from one movable media to another. If copying to hard disk, the destina-
tion file must be created in advance.
Example of file copy from HD to OD:
< INMCT:SPG=0;
:INFET:FILE1=HDFILE,FILE2=FDFILE,NODE2=A,
58 R1B
FMS applications
IO2=OD-1;
ORDERED
:END;
FILE COPY EXTERNAL

EXECUTED
SOURCE FILE DATA GEN VOLUME NODE IO

FILE - OMFZLIBORD - -
HDFILE
DESTINATION FILE DATA GEN VOLUME NODE IO

FILE 0 TEST A OD-1
FDFILE
END
Note that since parameters NODE and IO are given in the command, the
device file name (OD0A1) should not be used here. The copied file will
have the name FDFILE on the diskette. To read this file from the diskette
(command IOFAT), the name OD0A1-FDFILE must of course be used.
If a file is copied from hard disk to diskette or opto disk the record length
of the device file should be the same as the record length of the hard disk
file. If this differs from 512 bytes a new device file should first be defined.
Note: a keyed access file cannot be copied to external media.
4.7.3 Operator read/write files

All files can of course be read and written by software in the system. There
is however a tool to read and write files by operator (MML) commands.
The reading and writing may only be done towards sequential files (SEQ).
Command example:
<IOAFT:FILE=CRYSTAL-XUJING;
TRANSFER TO FILE
:data to file;
:data to file;
:data to file;
(EOT)
END
In the example above data is written to the subfile XUJING of the mainfile
CRYSTAL.
Command example:
<IOFAT:FILE=CRYSTAL-XUJING;
FILE DUMP
R1B 59
CRYSTAL-XUJING;
data to file
END OF BLOCK 0
data to file
END OF BLOCK 1
END
In the example above the data in subfile XUJING is printed on the opera-
tor terminal.
Note that in the printout FILE DUMP the END OF BLOCK must be inter-
preted as end of record. It must not be confused with the blocking parame-
ter (BLK) of the file.
4.8 The duplicated file system

The duplicated file system makes sure that the data in a duplicated volume
is identical in both nodes.
F ile syste m F ile syste m

e xe cutive sta ndby
w orking node w orking node
D uplica te d D uplica te d
volum e a re a volum e a re a
F ile F ile
W rite R e sult W rite R e sult
D uplica te d W rite D uplica te d

file syste m file syste m
R e sult
R e sult
W rite W rite orde r

to file (from
C P or S P )
Figure 4.10
Writing to a file in a duplicated volume
When writing to a file in a duplicated volume the write order is duplicated

in the executive node and distributed to the standby node. The write results
are collected and compared in the executive node.
60 R1B
FMS applications
If the data contents of the duplicated volumes in the standby node happen
to be different from the data in the executive node, then the system will
initiate a recovery activity. The data in a duplicated volume is in all nor-
mal cases identical in executive and standby node. The reason why the
data would be different could for example be if the standby node has been
blocked for some time or because of a file system error.
Command example:
:IMCSP;
NODE CONFIGURATION STATUS
SPG
0
NPAIR EX SB
NODE CM STATUS STATE NODE CM STATUS STATE HDSTATE
1 A 1 WORKING NORMAL B 2 ISOLATED BLOCKED CORRUPT
END
The hard disk status may be printed with command IMCSP. The parame-
ter HDSTATE can take the values CORRUPT or CONSISTENT. Both
states will require an update. If the duplicated volumes are updated
(equal), which is the normal state, the HDSTATE parameter is excluded
from the printout.
The recovery actions that may be taken are two:

• large update
• small update
In the large update all data (of unknown status) in the duplicated volumes
in the standby node is deleted. After this all the files are written from the
executive node to the standby node. This is done via the ICB bus. The cop-
ying is load regulated (with reference to the load of the executive node)
and the copying speed therefore varies.
The file system is works as normal in the executive side during the update,
this means users of the file system in SP or CP are unaffected by the updat-
ing activity.
The fact that the duplicated volumes in the standby node are erased during
the large update is a reason to be careful in operating the system when it is
updating. Under no circumstances must a standby node where the dupli-
cated volumes are not fully updated be forced in as executive.
In the small update the differences between the duplicated volumes in the
executive and standby node are updated towards the standby node.
R1B 61
File system File system

executive standby
working node blocked node
Duplicated Duplicated
volume area volume area
File Sector table File
.......
Write sector n
Delete Create ...
sector y
file system ... file system
Delete Create Orders to

file system
Write (from CP or
SP)
Figure 4.11
Blocked node
The small update is done using the so called Sector Map. When the
standby node goes blocked a Sector Map is created in the executive node.
The table is stored in the primary memory of the SP and is discarded at SP
restart.
All sectors that are changed in the executive node are recorded in this
table. The table is finite, i.e. has a limited size.
File system File system

executive node standby node
Updating small
volume area volume area
File Sector table File
.......
sector n
... sector n sector y
sector y
file system .... file system
62 R1B
FMS applications
Figure 4.12
Small update
The small update updates the duplicated volumes in the standby node
according to the sector table, i.e. the changed sectors are written to the
standby node.
The small update will be performed when a valid sector map exists and:
• when deblocking the standby node or
• at manual SP restart or
• at spontaneous restart without response from the standby node
The large update will be performed when deblocking the standby node in
the following cases:
• at serious faults in the duplicated file system
• a restart in executive node has occurred (sector map discarded, cannot
perform small update).
R1B 63
Node status during small update:

:IMCSP;
SPG
0
NPAIR EX SB
1 A 1 WORKING NORMAL B 2 ISOLATED UPDATING S CORRUPT
END
During the small and large update the hard disk status (parameter
HDSTATE) is CORRUPT.
4.9 Corrupt Files and File Recovery

This function is needed to correct corruptions detected in keyed files on
the hard disk. The function does not detect corruptions in sequential or
direct access files.
A file of class key is physically implemented in a data file and a directory
file. The directory file is a ‘map’ which facilitates the search with keys.
The data file contains the records of the file.
When writing a key file both components are updated. If a SP restart or a
fault in the file system occurs in between the updating of the two compo-
nents the contents of them does not match.
When a keyed file has been detected as having become corrupt, the file
recovery function issues the alarm CORRUPT FILE WARNING, indicat-
ing which file is corrupt.
The file is considered as corrupt if:

• it was open during a restart and
• the file system has reported problems to open or access the file
The operator must first block the file with the command INFBI to pro-
hibit reading and writing into the file and then enter the command INREI
to recover the file. The command INREI will initiate recovery of a corrupt
keyed file by logical copying. The directory component of the file is then
rewritten on the basis of the data component.
After the command INFBI to block the file is entered, the alarm FILE
BLOCKED is issued to indicate that the file is blocked.
At the completion of successful recovery of a corrupted file, the file is
either optionally automatically deblocked, which is specified in the com-
mand INREI, or deblocked by command INFBE. As a result of this an
alarm ceasing is issued to indicate that the file is now unblocked. If the
64 R1B
FMS applications
recovery of the file is unsuccessful, then the file remains blocked until the
operator manually deblocks the file.
The result printout states the success or failure of the recovery of the file.
The command INMFP prints the list of files currently in recovery, blocked
or corrupted.
The File Recovery function is implemented in the RECFILE module.
4.10 File protection

Most files in the file system may be accessed with operator commands.
These files may be created, deleted, copied, renamed etc. with ordinary
commands.
It may in some cases be necessary to block the access to some of these
files by operators. This is done with the file protection function.
Files included in this table may not be changed or removed in any way by
operator commands. The table is specified with commands INPFI and
INPFR and printed with command INPFP.
Command example:
<INPFI:FILE=TRARFILE;
In the example above the file TRARFILE is added to the file protection
table.
Note: the commands for the file protection function are preferably defined
as having a high grade of security in the CP authority system.
4.11 Infinite Files

The function infinite sequential files provides a file user with a virtual file
of infinite size by dividing the file into a predefined number of subfiles.
The infinite file function optionally compresses the file according to the
FLAM method.
R1B 65
SP or CP file user
Write to file STATFILE FMS
Mainfile: STATFILE
Subfiles:
STATFILE-0001
STATFILE-0002
STATFILE-0003
STATFILE-0004
STATFILE-0005
-0001 -0002 -0003 -0004 -0005 .....
Figure 4.13
Infinite files
The user of the file writes towards the mainfile. The infinite file functions
distributes the data to subfiles belonging to the mainfile thus giving the
user the impression that it is writing to the mainfile. The subfiles are cre-
ated by the infinite files function.
Writing is always done to the active subfile, the previous subfile is closed
and the next subfile is waiting to receive data.
The size of the subfiles and the number of subfiles are defined by com-
mand IOIFI. The subfiles are named sequentially with a four digit subfile
name. When the last subfile is reached the infinite files will redirect the
data flow to the first subfile again (-0001). This subfile must by then be
transferred and deleted, i.e. the subfile name -0001 must be free to use a
second time. This will normally be the case due to storage considerations;
if all subfiles are still on hard disk the volume would be full.
The infinite files will create subfiles in an infinite sequence stepping from
-0001 to the highest subfile number (defined by command, usually -9999),
and back to subfile -0001 again.
If the subfile that infinite files attempts to create already exist, the infinite
files function will halt and issue the alarm INFINTE FILE END
WARNING. Infinite files never overwrites data.
An existing composite file is defined as infinite with command IOIFI.
66 R1B
FMS applications
Command examples:
<IOIFP;
FILE ATTRIBUTE INFINITE SEQUENTIAL FILE
FILE ACTIVESUB NEXTSUB NSUB MAXSIZE MAXTIME RELEASE COMP
TTFILE00 0231 0232 9999 4096 NO YES
TTFILE01 0001 0002 9999 4096 NO YES
TTFILE02 0001 0002 9999 4096 NO YES
TRARFILE 1201 1202 9999 512 YES NO
CMVNFILE 0007 0008 9999 1 YES NO
TRDIPFILE 0763 0764 9999 1024 YES YES
END
< INMCT:SPG=0;
:INFII:FILE=TTOPFILE,VOL=EXCHVOLUME,RLENGTH=2048,
TYPE=SEQ,SIZE=20,FCLASS=CMP,EXP=5;
:END;
< IOIFI:FILE=TTOPFILE,NSUB=9999,MAXSIZE=40,
MAXTIME=15,COMP=YES;
In this example the composite file TTOPFILE is defined as infinite. It can
have a maximum number of 9999 subfiles. The data in the subfiles will be
compressed with the FLAM compression method.
Note: the compression of data is not default in the infinite file function.
When subfile -0001 is full, i.e. has reached its maximum size (here 40
records) or if 15 minutes have passed before this, the subfile is automati-
cally closed. The storing of data continues in subfile -0002. When storage
starts in a subfile, the next subfile is automatically created to be used when
the first subfile is closed, and so on up to subfile -9999.
If the command parameter MAXSIZE is omitted, then the subfile will
close after 15 minutes. If the parameter MAXTIME is also omitted then the
expansion factor in command INFII must be set to zero for infinite files
(EXP=0), otherwise the subfile will continue to expand indefinitely.
A third parameter, RELEASE, is used for files receiving data in batch out-
puts. RELEASE=YES is used to ensure that the whole output goes into one
subfile. When the parameter RELEASE is set to YES the switch to the next
subfile is not done until the MAXTIME and/or MAXSIZE criterias are
fulfilled and a release order is sent from the file user. If parameter
RELEASE is omitted it takes the default value NO.
Different file users handles their files differently. Some users seizes their
file after restart and never release. An example is the Toll Ticketing func-
tion in the charging subsystem, CHS.
Other file users makes a seizure, writes to the file and then release it.
Examples of such functions are most statistic functions in OMS. Another
example is the command output of call counters. For these files the release
parameter is preferably set to YES.
R1B 67
Note: setting the release parameter to yes for files with continuous output,
like the toll ticketing files, would be fatal. Since the toll ticketing function
never releases the file, the infinite files would never make a subfile switch.
The subfile would grow infinitely and the volume would eventually fill up,
causing a traffic stoppage.
-0064
Deleted
-0065
SUBFILE -0066
Reported to FPU -- " -- -0067
-- " -- -0068
Active subfile
-- " -- -0069 Data
Next subfile -- " -- -0070
(MAX -9999)
Figure 4.14
Infinite files without data compression
68 R1B
FMS applications
-0064
Deleted
-0065
Compressed
data
SUBFILE -0066
Reported to FPU -- " -- -0067
-- " -- -0068
Active subfile
-- " -- -0069 Data
Next subfile -- " -- -0070
Uncompressed
data
(MAX -9999)
Figure 4.15
Infinite files with compression
The infinite files function may compress the data in the subfiles with the
FLAM compression method. This is defined with parameter COMP in the
IOIFI command. The purpose with compressing the data is to save space
on hard disk (and possibly opto disk) and to save time when transferring
over data link.
4.11.1 Implementation
The infinite files function is implemented in CP block FIE for command
handling and modules INFFILECMD and INFFILEINT in the SP.
4.12 File Process Utility

4.12.1 General
The AXE system contains a number of functions which output data
towards the IO system. These include functions in the charging subsystem,
like Accounting, Pulse Metering, Toll Ticketing, Call Specification etc.
These also include statistics and recording functions like Traffic Disper-
sion Measurement, Statistics subsystem, All Circuits Busy on Route and
many others such as command log and CP backup functions.
Some of these functions store their data on hard disk infinitely while other
data needs to be transferred for further processing outside AXE. Example
of data that may need to be transferred is the data from the above men-
tioned functions. The statistics and recording results needs to be trans-
ferred to an operation and maintenance centre and the charging data to a
billing centre.
R1B 69
The handling of this data requires:

• transfer of data to external media
• removal of data from hard disk
These are the tasks of the File Process Utility function.
The procedures of the File Process Utility are described in several opera-
tional instructions, all named ‘File Process Utility, ....’.
The transfer of data to external media can be done to three different

medias:
• transfer over data link with Ericsson MTP
• transfer over data link with FTAM
• transfer to opto disk
Note: market systems may exist where the FTAM protocol is not imple-
mented.
The removal from hard disk is done according to certain removal criterias,
depending on transfer method.
File Process Utility usually interworks closely with the Infinite Files func-
tion in that the Infinite Files reports all subfiles which are full to FPU. FPU
also interworks with the command log but may actually be used for any
kind of files.
FPU operates in SPG0, SPG1, SPG2 and SPG3 (if installed).
Although FPU is mostly used to transfer charging and statistics data from
the AXE to a remote centre, it may be used for any file transfer to and
from the AXE IO system.
An example: when sending SP or CP backups to the IO system from
remote, for remote function change, FPU is used.
4.12.2 FPU concepts
A few concepts must be clarified before looking at the commands:

• FPU destinations
• Equipment type
• Subfile list
• Sequence number
Transferring a file or subfile to or from somewhere is in FPU referred to as
transferring it to a destination. A destination is a logical concept to which
a file or mainfile must be connected. To be connected to a destination is to
be processed by the FPU function.
One file/mainfile may be connected to more than one destinations (up to
16) and one destination may have more than one file connected to it.
70 R1B
FMS applications
A file/mainfile is connected to a destination by command INFDI.

FPU destinations:
<INFDP;
FILE PROCESS UTILITY
DESTINATION LIST
SPG DEST
0 TTFILEOD
0 AOM
1 STATDEST
END
The destinations may be of one of three equipment types:

• NOLINK
• MTP
• FTAM
The equipment type NOLINK indicates that the files connected to a desti-
nation of this equipment type will be transferred to opto disk.
The equipment type MTP indicates that the files connected to a destination
of this equipment type will be transferred over data link with the Ericsson
MTP protocol. The file may however also be transferred to opto disk.
The equipment type FTAM indicates that the files connected to a destina-
tion of this equipment type will be transferred over data link with the
FTAM protocol. The file may however also be transferred to opto disk.
If a destination is of equipment type MTP or FTAM it must be defined in
subsystem DCS with command ILDNI.
Subfile list. When connecting a mainfile to a destination a subfile list is
created. When a subfile belonging to this mainfile is reported to FPU it
will be listed in the subfile list. The reporting of a subfile to FPU is usually
done by the infinite files function but may also be done by the command
log function.
With the commands INFSI and INFUE subfiles may manually be
reported to, or removed from, the FPU subfile list.
The fact that a mainfile connected to a FPU destination has a subfile, does
not necessarily mean that this subfile is reported to the FPU subfile list.
R1B 71
The subfile list records a number of parameters for each subfile:

• subfile name
• subfile size in records
• time of reporting to FPU
• whether the subfiles has been sent to opto disc
• the sequence number
• when the file was transferred over data link automatically
• when the file was transferred over data link manually
• a fault code if the data link transfer failed
The subfile list is printed with command INFSP which has two different
formats.
Example of subfile list:
< INFSP:FILE=TTFILE00,DEST=TTFILEOD;
SUBFILE LIST
FILE = TTFILE00 DEST = TTFILEOD
SUBFILE SIZE TRANSF DUMPED SEQNUM
2351 1000 NO YES
2352 1000 NO YES
2353 1000 NO YES
2354 1000 NO YES
2355 1000 NO YES
2356 1000 NO YES
2357 1000 NO YES
2358 1000 NO YES
2359 1000 NO YES
2360 1000 NO YES
2361 1000 NO YES
2362 1000 NO YES
2363 1000 NO NO
2364 1000 NO NO
2365 1000 NO NO
2366 1000 NO NO
END
FPU subfile data:
<INFSP:FILE=TTFILE00-2362,DEST=TTFILEOD;
SUBFILE DATA
FILE = TTFILE00 SUBFILE = 2362 DEST = TTFILEOD
GENERATION SIZE SEQNUM

- 1000
STATUS STARTTIME STOPTIME FAILTIME REASON
72 R1B
FMS applications
DEFINITION 970605 1121

MAN TRANS
AUT TRANS
DUMP1 970605 1128 970605 1130
DUMP2
END
Sequence number. The sequence number parameter is still in the printout
but is not used when dumping to an opto disk. It is used in IOG11 when
dumping to magnetic tape to keep track of which subfiles belongs to a cer-
tain magnetic tape. Although the use of the magnetic tape is not supported
in IOG20, the parameter SEQNUM still exists for compatibility reasons.
In the example it can be seen that the subfiles -2351 to -2362 are dumped
to an OD.
The subfiles -2363 to -2366 are not dumped at all and the reason is that
these have been reported to FPU after execution of the INFMT command.
4.12.3 Transfer over data link with Ericsson MTP
The link transfer with the Ericsson MTP protocol may be performed in
four different ways:
• automatically - initiated from IOG
• automatically - initiated from remote destination
• manually
• manual re-transfer of an already transferred subfile
Automatic Transfer initiated from IOG
Command example:
< INFDI:FILE=SPFILE01,DEST=BC,EQUIP=MTP;
In the example above the mainfile SPFILE01 is connected to a destination
BC of equipment type MTP, i.e. data link with Ericsson MTP protocol.
Subfiles belonging to mainfile SPFILE01 may when reported to FPU be
sent over a data link with the Ericsson MTP protocol.
The automatic transfer of the subfiles from IOG with Ericsson MTP, may
be performed in two ways:
• immediate transfer
• transfer at a certain time
An immediate transfer is done when a subfile is reported to the FPU sub-
file list. This is usually done automatically by the Infinite files. It may also
be done by the command log function or by command (see above).
FPU then transfers all reported subfiles to the specified destination as soon
as possible.
R1B 73
If transfer at a certain time is required a so called FPU Time Slot must

be defined. The time slot defines two hours of the day during which data is
transferred.
Command example:
<INFPC:DEST=BC,TIME1=0600,TIME2=0800,SPG=0;
In the example above the automatic sending of subfiles to destination BC
over Ericsson MTP will be done between six and eight o’clock in the
morning.
The time slot may be overridden by command INFOI. When command
INFOI is given for a certain destination all non-transferred subfiles in the
FPU subfile list (for this destination) are transferred immediately.
Command example:
<INFOI:DEST=BC,OVERRIDE=ON,SPG=0;
The INFOI command can also halt all transfer over data link to a certain
destination, irrespective of the time slot.
Command example:
<INFOI:DEST=BC,OVERRIDE=OFF,SPG=0;
Normal time slot function is restored by command INFOE, time slot over-
ride end.
Command example:
<INFOE:DEST=BC,SPG=0;
Automatic Transfer initiated from remote
When the remote side initiates the sending over data link (with Ericsson
MTP) it is called polling.
Command example:
<INFDI:FILE=ICIFILE01,DEST=BC,EQUIP=MTP,POLL;
For polling, the parameter POLL is included in command INFDI.
In the example above the subfiles belonging to mainfile ICIFILE01 may
be polled from destination BC over Ericsson MTP. Only subfiles in the
FPU subfile list may be polled, not all subfiles belonging to mainfile
ICIFILE01.
FPU time slots are irrelevant for polled transfer. The transfer cannot be
affected from the IOG side (apart from blocking the data link).
Manual transfer
The manual transfer over data link with Ericsson MTP may be done in two
74 R1B
FMS applications
directions:
• from IOG to remote
• from remote to IOG
Command example:
<INFDI:FILE=SPFILE01,DEST=BC,EQUIP=MTP;
<INFTI:FILE=SPFILE01-2076,DEST=BC;
In the example above the subfile SPFILE01-2076 is transferred from IOG
to destination BC over Ericsson MTP.
Command example:
<INFDI:FILE=SPFILE01,DEST=BC,EQUIP=MTP;
<INFTI:FILE=SPFILE01,DEST=BC;
In the example above all subfiles belonging to SPFILE01 which are
reported to FPU are transferred from IOG to destination BC over Ericsson
MTP.
Command example:
<INFDI:FILE=RELFSW2,DEST=AOM,EQUIP=MTP;
<INFTI:FILE=RELFSW2-R5,DEST=AOM,REVERSE;
In the example above the subfile RELFSW2-R5 is transferred from an
operation and maintenance centre to IOG. The operation and maintenance
centre is destination AOM.
The mainfile RELFSW2 must exist on the hard disk.
A manually initiated file transfer may be interrupted by command INFTE.
The OPI to be used for manual transfer over a data link is called ‘File
Process Utility, Manual File Transfer, Start’.
Manual re-transfer of an already transferred subfile
Manual re-transfer may be performed on subfiles that already has been
sent once over data link with Ericsson MTP. Whether a certain subfile has
been sent or not can be seen in the FPU subfile list.
Both subfiles that are sent manually, automatically from IOG or automati-
cally from the remote destination (polled) may be re-transferred.
The re-transfer transfers not only the subfile indicated in the command but
all subfiles reported to the FPU subfile list after the indicated subfile. This
is referred to as a roll-back.
Command example:
<INFRI:FILE=SPFILE01-2076,DEST=BC;
R1B 75
Assume that subfiles SPFILE01-2042 to -2081 are reported to the FPU

subfile list and transferred over data link. The subfiles SPFILE01-2076 to
-2081 will be re-transferred to destination BC.
4.12.4 Transfer over data link with FTAM

File transfer and Management, FTAM, is an industry standard protocol.
The link transfer with the FTAM protocol may be performed in two differ-
ent ways:
• automatically - initiated from IOG
• automatically - initiated from remote
The file connected to FPU must be defined as a virtual file in FTAM.
Automatic Transfer initiated from IOG
In this case the FTAM in the IOG acts as initiator.
Command example:
<INFDI:FILE=TRDIPFILE,DEST=AOM,EQUIP=FTAM;
Automatic Transfer initiated from remote
In this case the FTAM in the IOG acts as responder.
Command example:
<INFDI:FILE=TRDIPFILE,DEST=AOM,EQUIP=FTAM,POLL;
4.12.5 Dumping to opto disk

Dumping of subfiles with FPU to opto disk is always done manually.
The command INFMT is used and requires that a formatted opto disk is
inserted and the volume is loaded.
Command example, connection of a file to a destination with equipment
type nolink:
<INFDI:FILE=PERIODICACC,DEST=ODDEST,EQUIP=NOLINK;
Assume that subfiles are now being reported to FPU.
FPU subfile list:
<INFSP:FILE=PERIODICACC,DEST=ODDEST;
SUBFILE LIST
FILE=PERIODICACC DEST=ODDEST

0001 1000 NO NO
0002 1000 NO NO
0003 1000 NO NO
76 R1B
FMS applications
0004 1000 NO NO
0005 1000 NO NO
0006 1000 NO NO
0007 1000 NO NO
END
Command example, transfer of subfiles to an opto disk:
<INFMT:DEST=ODDEST,VOL1=ODVOLSIDE1;
In the example above all reported and non-dumped subfiles of all files
connected to destination ODDEST will now be copied to the opto disk
having the volume name ODVOLSIDE1. In our example we assume that
the only file connected to destination ODDEST is PERIODICACC.
FPU subfile list:
<INFSP:FILE=PERIODICACC,DEST=ODDEST;
SUBFILE LIST
FILE=PERIODICACC DEST=ODDEST

0001 1000 NO YES
0002 1000 NO YES
0003 1000 NO YES
0004 1000 NO YES
0005 1000 NO YES
0006 1000 NO YES
0007 1000 NO YES
END
The manual dumping to an opto disk may also be done in parallel, towards
two medias at the same time. This is called duplicated output and requires
that two different opto disks are inserted, one in each node, and the vol-
umes are loaded. Serial output is not possible.
Command example for parallel transfer:
<INFMT:DEST=ODDEST,VOL1=ODVOLSIDE1,VOL2=ODSTAT;
4.12.6 Copying to Data Link and OD

If both transfer and dumping of subfiles is required, then two separate des-
tinations must be defined, as shown in the following example:
<INFDI:FILE=TTFILE,DEST=TTFILEOD,EQUIP=NOLINK;
<INFDI:FILE=TTFILE,DEST=HQ,EQUIP=FTAM;
The removal conditions should be based on the dumping condition to
ensure no removal of the subfiles before a manual dump has been made.
R1B 77
Also, when more than one destination is defined, the removal conditions
relate to the first defined destination. Thus INFDI for destination
TTFILEOD must be given first in this case. If INFDI for the data link was
given first then the subfiles would not be removed even after the dump.
In the above example, transfer of the subfiles via data link does not affect
the removal of the subfiles from hard disk. They will only be removed
according to the removal conditions after the subfiles have been dumped
to opto disk.
4.12.7 Copying to Data Link or OD

FPU output can be defined so that the subfiles can be transferred either
over a data link or to a opto disk. This would allow the subfiles to be
dumped to OD if a data link failed.
If we require both transfer and dumping, independently of each other, then
two separate destinations must be defined with INFDI as described above.
To define an output for transfer to destination HQ or dumping to opto disk
the data is defined as follows:
<INFDI:FILE=TTFILE,DEST=HQ,EQUIP=FTAM;
With EQUIP=FTAM, the default case, transfer is possible to both data link
or opto disk.
If the data link failed, the subfiles could now be dumped instead to opto
disk using:
<INFMT:DEST=HQ,VOL1=ANYVOL;
In the above case where EQUIP=FTAM is used, copying to opto disk
would only be defined as a backup to the data link in case this failed.
4.12.8 Renaming of files

The file process utility may rename the subfiles when transferring them.
The renaming is usually done in order to identify the origin of the subfiles,
i.e. the filename is changed according to the switch they originates from.
An adjustment is also made in order to comply to other file systems than in
FMS. Since the concept of a composite file is AXE-specific, the mainfile
and subfile names are merged to one file name.
Below are three examples of adaptation of a file name to an external file
system:
File in FMS: File in external file system:
PERIODICACC-0007 PERIODICACC.0007
PERIODICACC-0007 PERIODICACC0007.0000
PERIODICACC-0007 PERIODICACC-0007
78 R1B
FMS applications
In the first case the FMS file name is adapted to a file system where gener-
ations are supported. The mainfile name forms the file name in the exter-
nal file system and the subfile name are converted to file generation.
In the second case the FMS file name is adapted to a file system where
generations are supported. The mainfile and subfiles names are concate-
nated forming the file name in the external file system. The generation is
set to zeroes.
In the third case the external file system supports the same file structure as
in FMS. The file name is kept.
In addition to this adjustment a renaming may be done:
PERIODICACC-0007 PERACCTOWN.0007
PERIODICACC-0007 PERACCTOWN0007.0000
PERIODICACC-0007 PERACCTOWN-0007
In the example above the file is renamed to indicate from which switch the
files originate, TOWN.
Which renaming method is defined with command INFDI, when connect-
ing a file to a destination.
Command example:
< INFDI:DEST=BC,EQUIP=MTP,FILEID1=PERACCTOWN,
RULE1=1;
PERIODICACC-0007 PERACCTOWN.0007
Command example:
RULE1=2;
PERIODICACC-0007 PERACCTOWN0007.0000
Command example:
RULE1=3;
PERIODICACC-0007 PERACCTOWN-0007
4.12.9 Automatic Removal of subfiles

Once the subfile is safely transferred (or dumped) over data link or to opto
disk, the subfiles must be removed to free the space on the hard disk.
R1B 79
The removing of the subfiles is handled by FPU only for equipment types
NOLINK and MTP, i.e. if opto disk or data link with Ericsson MTP is
used.
If a data link with FTAM is used the removal of the subfiles from the IOG
hard disk is controlled and performed from remote via FTAM.
If the removal of the subfiles is handled by FPU it is controlled by two
parameters:
• removal conditions
• removal time
The removal of a subfile is done if both the removal conditions and
removal time are met.
The removal conditions depends on the equipment type of the destina-
tion, i.e. the way the data has been transferred.
The possible removal conditions are:
Equipment type: Removal condition:
NOLINK DUMP
DUPL
MTP AUTO
MAN
(No removal conditions are set for equipment type FTAM.)
The removal time is the time after which the subfiles may be removed.
The time is specified in hours and minutes. The time is calculated from the
time when the subfiles are reported to the FPU subfile list. So the count-
down starts when the subfile is reported to FPU, not when the subfile is
transferred over link or dumped to opto disk (which is done after the
reporting).
Note: this may be changed by a deferred constant!
The removal conditions and time are set by command INFCC.
Command example:
< INFDI:FILE=ICIFILE02,DEST=BILLING,EQUIP=MTP;
< INFCC:FILE=ICIFILE02,TRANSCOND=AUTO,
REMOVE=02400;
The subfiles of the file ICIFILE02 will be deleted from the hard disk 24
hours after they are reported to FPU, but only if the subfiles have been
automatically transferred over data link.
Command example:
< INFDI:FILE=TRACAFILE,DEST=OD,EQUIP=NOLINK;
< INFCC:FILE=TRACAFILE,DUMPCOND=DUPL;
80 R1B
FMS applications
The subfiles of the file TRACAFILE will be deleted from the hard disk
when the subfiles have been copied to opto disk twice.
The setting of the removal times for frequently output data must be done
calculating the traffic of the switch. The wish to keep the data on hard disk
as long as possible, for security, must be weighted against the need for
new hard disk space for new data.
If the telephony traffic and data output is high the removal times must be
set shorter.
4.12.10 Printout Commands for FPU

The following printout commands are useful when working with FPU:
<INFDP; to get defined FPU destinations
<INFDP: DEST=dest; to get files for destination
<INFUP; to get the files defined for FPU
<INFUP:FILE=file; to get FPU data for a file (e.g removal data)
<INFSP:FILE=file,DEST=dest; to see which subfiles have been
reported, transferred, dumped and removed from hard disk.
The OPI used for automatic transfer of subfiles over data links is called
‘File Process Utility, File and Destination, Define’.
The OPI used when transferring to OD is called ‘File Process Utility,
Removable Media, Single Dumping/parallel Duplication’.
4.13 Decompression of files

When receiving files from outside the AXE into the IO system these files
may in some cases be compressed, this usually to speed up the transfer
over data link. Examples of such files may be CP backups or SP backups
downloaded to the IO system via data link for a remote function change.
IOG 20 supports two decompression methods:

• FLAM
• PKZIP
Command example:
:IMDCI:FILE1=COMPREL,FILE2=RELFSW99;
In the example above, all subfiles of the mainfile COMPREL are decom-
pressed into mainfile RELFSW99. The original compressed subfiles are
kept on hard disk. The destination mainfile RELFSW99 must be created
before hand.
Which subfiles in a mainfile are to be compressed can be printed with
command INCMP.
Command example:
R1B 81
:IMDCP:METHODS;
In the example above all available decompression methods are listed.
Command example:
:IMDCP:STATUS;
In the example above all ongoing decompressions are listed.
An ongoing decompression may be interrupted with command IMDCE.
Note that the compression of files may in IOG20 only be done with the
FLAM compression method and only when using infinite files.
4.14 Command Log in AXE

The Command Log function is for logging subscriber commands (from
keysets) and operator commands that manipulate exchange data in the CP.
The log is used to restore the data store in the CP after a reload with all the
data logged between the last data dump and the reload. The function is
activated and deactivated by operator command.
The function is administered by the FMS block LOGB in the CP.
4.15 Chapter Summary

• Storage medium, volume and file are the basic FMS concepts
• The storage medium consists of the hard disks, flexible disks and opto
disks
• Internal volumes are volumes located on a hard disk
• External volumes are volumes located on a flexible disk or opto disk
• FMS has a supervision of the used space on a volume. If the supervi-
sion limit is exceeded, then an APZ alarm is issued
• PROG_A, PROG_B, OMFZLIBORD and RELVOLUMSW are system
defined volumes. The rest of the volumes are market dependent
• PROG_A and PROG_B, usually the only unduplicated volumes, con-
tain the SP software, including RPV/RPV2 and LUM software and the
SP system files. The SP trace log files are stored here as well
• OMFZLIBORD is a duplicated volume, which contains the SP
exchange data and a series of logs and other files used by the mainte-
nance functions, as well as other files created by the SP when required
• RELVOLUMSW is a duplicated volume, which contains the Central
Processor back up files and the command log
• The data in a duplicated volume is identical in both nodes
• In large update all data in the duplicated volumes is transferred, via the
ICB, from the executive node to the standby node
• In small update only the differences between the duplicated volumes is
82 R1B
FMS applications
transferred, via the ICB, from the executive node to the standby node
• Three file types exist, namely sequential (SEQ), direct access (DIR)
and keyed access (KEY)
• Three file classes exist, namely simple (SPL), composite (CMP) and
device (DEV)
• A file has a unique name and belongs to a volume
• A file can be copied internally hard to hard disk or externally between
hard disk and moveable media or between to moveable medias
• Corrupt key files can be recovered by the operator
• The infinite file function will create subfiles in an infinite sequence
stepping from -0001 to the highest subfile number, usually -9999, and
back to subfile -0001 again
• The infinite file function may compress the data in the subfiles. The
compression saves space on the hard disk and time when transferring
• File process utility (FPU) administers the transfer of data from the hard
disk to an external media and removal of data from the hard disk
• Example of files defined in FPU: toll ticketing, pulse metering, call
specification, accounting, different statistics files, etc.
• The transfer of data to the external media can be done over data link
with Ericsson MTP or FTAM or transferred locally to an opto disk
• Subfiles can be decompressed by operator command
R1B 83
84 R1B
5. System Backup Handling
Chapter Objectives
After completing this chapter the student will be able to:
• Perform a manual CP backup with the help of the relevant OPI
• Be familiar with the commands for rotating the file names for CP
backups and for changing the file names of these dumps
• Explain and carry out a Conversion of System Backup files from
external media or data link
• Explain the purpose and function of the command log
• Explain how the reloading of the CP is done and how this can be
controlled by operator
Figure 5.1
Chapter Objectives
5.1 Introduction
This chapter deals with the backup storage and handling of CP and SP
backups.
The CP and SP backups together contains all software and data in the AXE
system.
Other software which is stored in the AXE IO system but is not part of
AXE could for example be radio base software. This kind of software is
not described here.
5.2 Backup Functions of the CP

A CP backup consists of:
• CP, RP, EMRP, EMRP-D, RP-D and RPG/RPG2 software
• Data stored variables, i.e. exchange data
• CP reference store
CP backups may stored in two places in the AXE system:
• In primary memory of CP (Backup in Main Store)
• On hard disk
When stored in primary memory of CP the backup is located in DS or PS
depending on APZ version. This is called Backup In Main Store.
R1B 85
The reason to store a backup in CP primary memory is the short times for
backing up and for reload. The drawbacks are that about twice as much
primary memory is needed in the CP and that the backup doesn’t survive a
power reset. Backup in main store must always be combined with a
backup on hard disk.
The primary memory may hold only one backup copy.
When stored on hard disk the CP backup copies are stored in composite
sequential files with predefined names. The CP backup files are always
stored in volume RELVOLUMSW. The limitation to the number of CP
backup files that may be stored on the hard disk is the size of volume REL-
VOLUMSW.
5.2.1 CP Backup in Main Store

The CP backup in Main Store is an optional function which is not neces-
sarily used. The backup may have two different formats:
• CP full backup
• CP backup of data store
The full backup is a copy of the entire dump.
The backup of Data Store stores only the contents of Data Store.
Command example:
< SYBMS:STORE=DS;
With the above command the backup in Main Store is limited to keep a
backup copy of the data store only.
Command example:
<SYBMS:STORE=NONE;
With the above command the backup in Main Store function is deacti-
vated. The only CP backup is now stored on hard disk.
5.2.2 CP Backup on hard disk

A backup file is a composite file with six subfiles named R0, R1, R2, R3,
R4 and R5. The name of a backup file is standardized to RELFSWn,
where n=0 - 127.
86 R1B
System Backup Handling
Mainfile RELFSWn Subfiles:
R0 Control data
R1
Charging data, small backup, DS
R2
R3
Reload marked variables, large backup, DS
R4
R5 Contents of RS and PS
RS - Reference Store
PS - Program Store
DS - Data Store
Figure 5.2
CP backup file on hard disk
The subfile R0 contains control data for administration of the other sub-
files, such as information indicating the subfiles to be loaded in the event
of a reload. The CP dump header is stored in this subfile.
The subfiles R1 and R2 contain charging data, mostly private meters. The
automatic backup operation alternates between the two subfiles where the
older version is overwritten with new data. These data are dumped at small
automatic backups. In case of a reload the newest small dump will be
loaded into the system.
The subfiles R3 and R4 contain reload marked variables, i.e. variables to
be loaded in conjunction with a reload. This file stores the exchange data
of the system. R3 and R4 contain different versions of data dumped at dif-
ferent times at large automatic backups. For security reasons the older
large dump will be loaded into the system if an automatic reload occur as
it is less likely to contain a data fault that may have caused the reload.
The subfile R5 contains a copy of the Program Store (PS) and Reference
Store (RS) which are only dumped at manual dumps. This is usually the
largest subfile. R5 is always loaded at a reload.
CP backups may be output in two ways:

• Manually by command
• Automatically according to a predefined time schedule
R1B 87
5.2.3 Manual backup of CP
The manual backup of CP may be done towards:

• primary memory and hard disk or
• hard disk
Manual backup of the CP must always be done when a size alteration,
functional change or a program correction in the CP has been performed.
Manual updating of the system backup files is also recommended to be
done as a routine job.
The command SYBUP dumps the CP backup to hard disk, and to primary
memory if the backup in main store function is active.
Note that the program store of the CP does not only store CP software but
RP, EMRP, RP-D, EMRP-D and RPG/RPG2 software. All this is part of
the CP backup.
Command example:
<SYBMS:STORE=ALL;
<SYBUP:FILE=RELFSW3;
In the example above the CP backup is stored in primary memory and on
file RELFSW3 on hard disk.
Command example:
<SYBMS:STORE=NONE;
<SYBUP:FILE=RELFSW6;
In the example above the CP backup is stored in file RELFSW6 in volume
RELVOLUMSW on the hard disk.
The manual CP backup may be done towards any of the files on hard disk,
except file RELFSW0 or files in the second file range, SFR (see below).
File RELFSW0 is the default reload file and must therefore always be
intact.
If a backup is done towards a file which contains a CP backup, the old
backup is overwritten.
It is important to dump some types of data regularly so that the informa-
tion will not be lost in the event of a serious failure (stoppage). This is
done by the automatic CP backup function.
5.2.4 Automatic CP backup
The automatic CP backups are output to:

• CP primary memory and file RELFSW0 or
• file RELFSW0
88 R1B
Whether the CP primary memory is updated or not depends on whether the

backup in main store function is activated.
There are two types of automatic CP backups:

• small
• large
Charging information, i.e. call meter values, changes all the time. This
charging data is dumped in small backup.
Note that charging data of type Toll Ticketing, Call Specification or
Immediate Call Itemisation is NOT part of the small CP backup.
Data which are normally changed by command and which change only
occasionally are dumped at large backups. These data are changed, for
example, when an operator connects a new customer line, adds a trunk line
or change an alarm threshold.
A change of this kind can also be done by a customer using a subscriber
service, e.g. ordering a wake up call. When making these types of changes,
the values of the so called reload marked variables are altered. These
reload marked variables are dumped at a large automatic dump. This type
of dump is normally performed once a day.
The automatic CP backup is always performed towards file RELFSW0.
The reason is that this is the default reload file (the system may reload
from other files, see below).
The automatic CP backup is performed at times specified by command
SYBTS in the operational instruction ‘Backup Information Dump Out-
put Times, Specify’.
Command example:
<SYBTS:TIME=0000,TDMI=240;
<SYBUI:DISC;
In the example above the large automatic CP backup is performed at mid-
night and the small once every fourth hour. This is a common way of
defining the automatic CP backup. This is of course market dependent.
The automatic dumping function has to be activated by command SYBUI
and deactivated by SYBUE.
5.2.5 CP Backup Handling

The CP backup files on hard disk are divided in two ranges, the first and
second file range.
• First file range, FFR, includes the files RELFSW0 - RELFSW99
• Second file range, SFR, includes the files RELFSW100 - RELFSW127
Usually about three files (i.e. CP backups) are kept in each file range. This
is depending on the available hard disk space in volume RELVOLUMSW.
R1B 89
The reason for keeping two file ranges is security. The second file range
contains older version of the CP backup while the first file range contains
newer. The reload function in the CP may select backups files from the
second file range if backup files reloaded from the first file range prove to
be corrupt.
HD node A and B, SPG0

Automatic dump
RELFSW0
Reload
CP RELFSW1 First
File Range
RS, PS
Manual dump
and DS
RELFSW2
RELFSW100
Second
RELFSW101 File Range
RELFSW102
Figure 5.3
Manual and automatic CP backup
The automatic CP backup is done towards file RELFSW0. Thus

RELFSW0 is always kept up to date with the latest information. This file
is usually also loaded in case of an automatic reload.
The selection of which file(s) will be reloaded at an automatic reload is
described below in the next section.
A manually initiated dump creates a new backup generation. This dump
will overwrite one of the backup files, RELFSW1 or RELFSW2, depend-
ing on the parameter value used when ordering the dump. Normally the
manual dump is made on the oldest backup file, i.e. RELFSW2 (see Figure
5.3).
Note that a manual backup cannot be made towards the second file range.
With commands the file names can be rotated and changed so that, for
instance, the latest manual dump file will be renamed RELFSW0 and
become the automatic backup file.
90 R1B
<SYTUC; RELFSW0
First
File Range RELFSW1
RELFSW2
<SYTUC:SFR; RELFSW100
Second
File Range RELFSW101
RELFSW102
Figure 5.4
Rotation of CP backup files on hard disk
Command SYTUC can be used for name rotation of system backup files if
RELFSW2 is newer than RELFSW0 and RELFSW0 is not empty. Com-
mand SYTUC is normally used after a manual dump to RELFSW2. See
Figure 5.4.
R1B 91
<SYNIC; RELFSW0
First
File Range RELFSW1
RELFSW2
<SYNIC:SFR; RELFSW100
Second
file Range RELFSW101
RELFSW102
Figure 5.5
Rotation of CP backup files on hard disk
Command SYNIC can be used to change the file names when RELFSW2
is newer than RELFSW0 or when RELFSW0 is empty. SYNIC is nor-
mally only used at the first load of the exchange when, after the first man-
ual dump, RELFSW2 is renamed RELFSW0. Figure 5.5.
There is a third way of rotating the files. With command INFIC the
backup files can change names or be given any name. This way of renam-
ing files is preferably avoided, particularly in a ‘live’ switch. This method
is however very useful during installation test or in a test plant environ-
ment where the conditions for sending the commands SYTUC or SYNIC
are not satisfied.
Command example:
< INMCT:SPG=0;
:INFIC:FILE1=RELFSW0,FILE2=RELFSWX;
:INFIC:FILE1=RELFSW2,FILE2=RELFSW0;
:INFIC:FILE1=RELFSWX,FILE2=RELFSW2;
:END;
This example could have been where an older generation has been loaded
into RELFSW2 from an opto disk, but is required to be in RELFSW0. In
this case commands SYTUC and SYNIC could not be used.
92 R1B
Note that the commands SYTUC and SYNIC are part of the system backup
functions and can only be used with the files with names RELFSWn.
<SYSFT; RELFSW0
First
RELFSW1
File Range
RELFSW2
RELFSW100
Second
RELFSW101
File Range
Old contents
RELFSW102
are overwritten
Figure 5.6
Transfer of CP backup from first to second file range
The command SYSFT will copy RELFSW1 from the FFR to the highest
consecutive number in the second file range. The old CP backup in the
destination file will be overwritten.
Command example:
<SYSFT;
Note that a manual backup cannot be performed towards the second file
range. The command SYSFT is the only way to write a CP backup file in
the second file range.
With the command SYBFP it is possible to check which CP backups exist
on hard disk or in primary memory.
Command example:
<SYBFP:MS;
In the example above data related to the backup in main store is printed.
Command example:
<SYBFP:FILE;
R1B 93
In the example above data related to the backup files on hard disk is
printed.
5.2.6 CP backup transfer to/from IOG
RP bus A
CP RP bus B
SYBUP
SP ICB
RPV/RPV2
HD
AT
HD SYACI SYMTP
SYCFI
ALI
FD
OD
DL
(via FPU)
Figure 5.7
CP backup conversion to/from external media
The CP backup may be transferred to and from the AXE system in three
different ways:
• via external media opto disk
• via external media diskette
• via data link
The conversion to opto disk is done by command SYMTP. One side of an
opto disk is usually enough space to store more than one CP dump. The
CP backup is converted to six separate files which are named according to
what is specified in the command.
The output conversion may be done in two ways:

• full backup
• ‘economic’ backup
The full backup contains all six subfiles while the economic contains sub-
files R0 and R5, the youngest of R1, R2 and the oldest of R3, R4. The eco-
nomic CP backup contains four subfiles.
94 R1B
Command example:
< SYMTP:SPG=0,DIR=OUT,ECO,FILE1=RELFSW3,
FILE2=DUMP3,NODE=B,IO2=0D-1;
In the command example above the subfiles RELFSW3-R0, -R1, -R4 and
-R5 are output to the opto disk in the B-node. The volume of this opto disk
must be loaded. The files on the opto disk will be named DUMP3R0,
DUMP3R1, DUMP3R4 and DUMP3R5.
Command example:
< SYMTP:SPG=0,DIR=IN,FILE1=RELFSW101,FILE2=RELFP7,
NODE=A,IO2=OD-1;
In the command example above the files RELFP7R0, RELFP7R1,
RELFP7R2, RELFP7R3, RELFP7R4 and RELFP7R5 are input from the
opto disk in the A-node. The volume of this opto disk must be loaded. The
files on the hard disk will be RELFSW101-R0, -R1, -R2, -R3, -R4 and -
R5.
The conversion to/from flexible disk is done with the commands SYACI
and SYCFI. A flexible disk has a storage capacity of 1.44 MB therefore it
takes many diskettes to store a CP backup.
The output conversion may be done in two ways:

• full backup
• ‘economic’ backup
The full backup contains all six subfiles while the economic contains sub-
files R0 and R5, the youngest of R1, R2 and the oldest of R3, R4. The eco-
nomic backup contains four subfiles.
Command example:
< SYACI:SPG=0;
:SYCFI:FILE=RELFSW3,DIR=OUT,IO=FD-1,NODE=B;
:SYCFP;
ORDERED
(release terminal)
< SYACI:CON;
:SYCFP;
ORDERED
(this sequence is repeated for all diskettes)
END
In the command example above all subfiles of file RELFSW3 is converted
and output to diskette. The diskette of course has to be changed in between
giving the commands. The result printout tells us when to replace the dis-
R1B 95
kette or when the backup is finished. The sequence of the diskettes is

important and they must therefore be carefully labelled.
Command example:
< SYACI:SPG=0;
:SYCFI:FILE=RELFSW3,DIR=IN,IO=FD-1,NODE=A;
:SYCFP;
ORDERED
..
< SYACI:CON;
:SYCFP;
ORDERED
(this sequence is repeated for all diskettes)
END
In the command example above all subfiles of file RELFSW3 are con-
verted and input from diskette. The diskettes of course has to be changed
in between giving the commands. The diskettes must be inserted in the dis-
kette drive in the correct sequence.
The transfer to/from a data link can be done via protocols Ericsson MTP
or FTAM. The sender or receiver of the files is the File Process Utility.
Command example:
<INFDI:DEST=DUMPDEST,EQUIP=MTP,FILE=RELFSW102;
<INFSI:FILE=RELFSW102-R0;
<INFTI:FILE=RELFSW102,DEST=DUMPDEST;
In the command example above the main file RELFSW102 (belonging to
the second file range) is connected to FPU. The subfiles are reported to the
FPU subfile list and finally sent over the link with a manual transfer.
The subfiles may of course be polled from the remote end, or transferred
using the FTAM protocol. Which method to used is specified by the
INFDI command.
Note: the procedures are explained in the operational instruction ‘System
Backup Copy from Hard Disk to Removable Media, Convert’
5.2.7 Automatic CP reload

Automatic CP reload happens if a serious software of data error has been
detected by the system. If the ordinary recovery action does not remedy
96 R1B
the fault the system may reload a CP backup. An automatic CP reload will
cause a temporary traffic stoppage in the switch.
An automatic CP reload may be done from two medias:

• CP primary memory
• Hard disk
The reload from CP primary memory is selected as the first alternative.
A prerequisite is that the backup in Main Store function is activated.
If the CP backup in primary memory consists of data store only, the auto-
matic reload is always started with a check summing of the executing PS/
RS. If the checksum is OK the DS is reloaded from primary memory. If
the checksum is not OK the automatic reload is performed from hard disk
(of PS, RS and DS).
If the first alternative fails or if the backup in main store is not activated,
the system will continue by reloading from hard disk.
The reload from hard disk is per default done via link 0 in the SPG0. The
central processor is hard-coded to search its backup via RP address 1. If
the communication towards RP address 1 fails the system will search on
RP addresses 4, 2, 3, 5, 6, 7, and 8 in sequence.
If communication is established with RP address 1 but no reload file is
found then the reload is considered failed and no further search on other
RP addresses will be performed.
The default selection of reload file is RELFSW0 on RP address 1.
There is however a range of possibilities for controlling the reloading
function by command SYGPS. Among other things it is possible to con-
trol whether or not the relevant command log subfiles shall be loaded
when loading a dump.
The operator can also include the second group (SFR) among the reload
files. These files will be taken if none of the first files (FFR) result in a
successful reload (the time between two reloads exceeds a limit set by
command). The complete function is controlled and handled by command
SYGPS, which is used to specify the handling of the reloading. The auto-
matic function, which loads the command log automatically, can be
totally switched off by using the parameter SYGPS:CLH=MAN;. If this
command is used, the command log is handled manually in the same way
as in older APZ versions. However, if parameter CLH=AUT is chosen, a
large number of parameters affect the reload as well as how the command
log is handled.
The first reload from the file is always done with the youngest reload file
and the complete command log. Note that a reload from the Main Store
does not affect this function. This means that an unsuccessful reload
attempt from Main Store does not affect this function.
R1B 97
If a second reload is done within the supervision time stated by parameter

SUP, the parameters set by command SYGPS control the selection of next
reload file as well as the handling of the command log. The reload
attempts after the first one are controlled by the parameters in command
SYGPS. An example is given to explain how the parameters control load-
ing. The stored data in the function can be printed with command SYGPP.
The command and printout example below shows the printout with some
parameters loaded.
System backup generation handling:
<SYGPP;
BACKUP GENERATION HANDLING PARAMETERS
CLH NTAZ NTCZ LOAZ INCL1 INCL2 INCLA SUP

AUT 1 10 0 RELFSW0 101 97062 60
LAST RELOADED FILE

NAME CREATED AT
RELFSW0 970618 0832
END
Here is a short explanation of the different parameters in the example:
CLH Can be set to AUT for automatic handling of the backup
system or MAN for manual.
NTAZ Number of truncation attempts with RELFSW0. If this
parameter is set to zero, the following two parameters are
insignificant.
NTCZ Number of additional commands to be truncated at each
reload attempt. This parameter is set to 10 in the example.
This means that 10 commands from the latest command
log file are truncated (not loaded) for each retry.
LOAZ Log subfile omission attempt with RELFSW0. The
parameter can be used to indicate that the command log
subfile should be omitted completely (=2), that the
youngest subfile should be omitted (=1) or that there
should be no omission at all (=0). The last value is
default.
INCL1 This parameter indicates the reload file or files which
should be included from the first group (First File Range).
Either RELFSW0 or ANY is specified.
INCL2 Determines which files from the Second File Range
should be included in reload attempts. Either NONE or a
value from 100 to 127 is specified. In the example, 101 is
specified, which means that RELFSW100 and 101 are
tried.
98 R1B
INCLA This is a parameter which can “age check” the reload

files. This means that no files older than the parameter are
used.
SUP Supervision time in minutes between reloads. If the time
is exceeded, the reload is regarded as successful. The
parameter should be set to 60 minutes (should not be
changed unless recommended by an APZ expert).
Command SYBRP can be used to show the extent of the latest reload, and
also to see which reload file was loaded. An example of a printout can be
seen below.
System backup reloading information:
<SYBRP;
SYSTEM RELOADING INFORMATION
RELOADTIME RP EM DEV RELOADFILE

930429 1141 4 0 1 RELFSW0
TYPE ACTION SOURCE OUTPUTTIME SUBFILE

PS,RS LOADED FILE MEDIUM 930318 0832 R5
DSSMALL LOADED FILE MEDIUM 930318 0832 R1
DSLARGE LOADED FILE MEDIUM 930318 0832 R3
COMANDLOG TRUNCATION OMISSION

000005 0 NONE
END
During a function change in the CP the automatic reload function may be
turned off by command SYRBI.
Command example:
<SYRBI;
In the example above the automatic reload function is turned off. The sys-
tem will not reload. The alarm BACKUP INFORMATION FAULT is
issued.
The automatic reload function is turned on by command SYRBE.
5.2.8 System backup check

Each subfile of a CP backup consist of one or more sectors. This sector
concept is not to be mixed up with the sector concept of FMS where each
media is divided in sectors.
When output each sector of the CP backup subfile is check summed and
the check sum is written in the sector. This check sum is calculated and
written at backup (manual or automatic). In order to verify the accuracy of
a particular backup copy there is a function that reads the subfiles, calcu-
lates a check sum and compares to the checksum stored on hard disk.
R1B 99
Command example:
<SYBCI:FILE=RELFSW101;
A backup check is made of the CP backup in file RELFSW101.
5.2.9 Hanging backup

The output of CP backup is supervised by the backup function. If the
backup would for some reason hang this is indicated by the system by an
alarm BACKUP INFORMATION FAULT. The supervision is active for
both manual and automatic CP backups.
Command example:
<SYBHP;
The printout above will tell whether the CP backup function is hanging
and which block was last doing its backup. The alarm is remedied by fol-
lowing the OPI for the alarm above.
5.3 Command Log

The automatic large CP backup updates the CP backup in file RELFSW0
according to the executing system. If a reload would occur in between the
updating of the backup, the exchange data which was loaded since the last
large backup will be lost. The command log is used to avoid such losses of
exchange data.
The command log is also used when the CP is separated, this in order to
log the possible differences between the executive and standby side. This
is described under section Command Log During Function Change below.
5.3.1 Output of command log data to file

The command log in the exchange logs certain commands and subscriber
services ordered from a telephone set (these services are translated into
commands). The command description tells us whether a command is
logged or not. Changes in the exchange data are automatically stored in the
command log file in the form of commands.
The command log file is named RELCMDHDF and defined in volume
RELVOLUMSW. It is may have up to 9999 999 subfiles. Each subfile
consists of command log information between two large data dumps in file
RELFSW0.
A new subfile is created for every large automatic CP backup that is per-
formed. The subfile belongs uniquely to one particular subfile (-R3 or R4)
of one particular CP backup (RELFSWn).
The logging follows a sequence, example:

• Large CP backup i s made to subfile RELFSW0-R3. A new empty
command log subfile, RELCMDHDF-0100230, is created and
100 R1B
‘attached’ to -R3.
• The exchange data is modified and subscriber services are activated and
deactivated. The commands are stored in subfile -0100230.
• A large backup is made to subfile RELFSW0-R4. A new empty com-
mand log subfile, RELCMDHDF-0100231, is created and ‘attached’ to
-R4.
• The exchange data is modified and subscriber services are activated and
deactivated. The commands are stored in subfile -0100231.
By following this sequence the system will create and attach one and only
one command log subfile to each and every CP backup subfile -R3 or -R4.
The relation can be seen in the printout SYSTEM BACKUP FILES.
System backup files
<SYBFP:FILE=RELFSW3;
ORDERED
SYSTEM BACKUP FILES
FILE IO EXCHANGE
RELFSW3 - TRX-C:9 APZ 211 11 R1
SUBFILE TYPE OUTPUTTIME CURRENT COMMANDLOG

R1 DSSMALL 970302 1600 YES -
R2 DSSMALL 970302 1200 NO -
R3 DSLARGE 970302 0000 YES 0010021
R4 DSLARGE 970301 0000 NO 0010020
R5 PS,RS 950302 1614 YES -
END
If a reload occurs the backup file RELFSW0, with the later small dump
and the older large dump, will be loaded into the system again.
In order to restore the system to the situation before the reload both com-
mand log subfiles (attached to backup subfiles -R3 and -R4) must be
loaded into the system. The reason is that it is always the older large data
dump that is loaded.
5.3.2 Command log when separating CP sides

New subfiles of the command log file RELCMDHDF may also be created
when the central processor is separated during a functional change. A new
subfile is created if the CP is separated and CP-SB side is not fault
marked.
The command log subfile will record all data changing commands in the
CP executive side, i.e. all differences between the executive and standby
side. If a switch back to old system (stored in the SB side) would occur the
operator has a possibility to updated the old system (now in EX side) with
the new data.
R1B 101
Example:
A CNI shall be loaded in a switch. The CNI consist of a new block.
The new block is loaded with command FCSUL and furax table is loaded
with command FCTAL.
The new software is switched in with FCSUC. Data from the old version of
the block is converted and stored in the new block. The CP is separated
with the old block in the SB side and the new block in the EX side.
A new command log subfile is created.
After the switch, one hundred subscribers are changing their subscriber
services (activating/deactivating). All this is logged in the command log
subfile.
A software fault occurs in the EX side. The system automatically switches
back the old system. EX becomes SB and SB becomes EX. All changes in
subscriber services are lost.
The operator updates the new EX-side by executing the command log sub-
file.
5.3.3 Loading of command log to system

The loading of the commands of the command log subfiles into the system
may be done:
• as a part of the reload or
• manually
If loading the command log as a part of the reload, this is specified in the
command SYGPS, parameters CLH, NTAZ, NTCZ and LOAZ. See pre-
vious section in this chapter.
If loading the commands in the command log subfiles manually the oper-
ator must first of all decide which of the two applicable command log sub-
files is the older and newer. This is done by command SYBFP. After this
the command log subfiles are read in the sequence older-newer.
Command example, manual loading of command log subfile:
<IOCMC:STATE=PASSIVE;
<IOCMI:FILE=RELCMDHDF-0100230,PROC=E;
<IOCMI:FILE=RELCMDHDF-0100231,PROC=E;
<IOCMC:STATE=ACTIVE;
Before giving the command IOCMI, the Command Reading Table for
delayed action commands must be passivated by use of command IOCMC:
This command will prevent command reading from any other source than
the command log.
The table should be reactivated after the commands in the command log
have been executed.
102 R1B
The procedures of the Command Log are described in several OPI’s, all
named ‘Command Log......’.
5.3.4 Operation of command log

Start of command log
Command example:
<SYCSI;
<SYCLI;
The command example above starts with the creation of a new command
log subfile with command SYCSI. After this the command log is acti-
vated.
Removal of command log subfiles
The main file RELCMDHDF may have up to 9 999 999 subfiles. Some of
these are relevant for the CP backups and some are not. If a CP backup
file, e.g. RELFSW5, is overwritten then the two related command log sub-
files are of less relevance.
The command log function uses the File Process Utility function to handle
its subfiles after they have lost relevance to the CP backups on the hard
disks, both the first and second file range. When this happens the com-
mand log reports the command log subfiles to the FPU subfile list. From
this list the subfiles may be transferred to external media and eventually
removed from hard disk.
The criteria for reporting a subfile to file processes utility is that the subfile
(R3 or R4) shall be overwritten by an automatic large backup, by a manual
backup or by a dump transfer with command SYSFT.
The mainfile RELCMDHDF must be connected to as FPU destination.
Command example:
<INFDI:DEST=CLOGDEST,EQUIP=NOLINK,FILE=RELCMDHDF;
<INFCC:FILE=RELCMDHDF,REMOVE=04800;
In the example above the command log subfiles are removed from hard
disk 48 hours after they are reported to FPU.
5.4 Backup of the SP

5.4.1 Differences between CP and SP backup
The function of the SP backup is somewhat different from the CP backup.
When changing the contents of an executing CP dump, these changes only
take place in the primary memory of the CP. This may be the loading of
some corrections, the function change of a new block, modification of
exchange data or activation of a subscriber service.
Once the contents of the CP is changed we make a backup of it towards the
CP primary memory or towards hard disk.
R1B 103
The architecture of the system in the SP is different. When making a

change to the SP dump the SP backup on the hard disk is always updated
automatically. This may be the function change of an upgraded module or
the definition of a new terminal.
In the SP there is no function for storing the contents of the primary mem-
ory to hard disk, no function comparable to the CP automatic or manual
backup.
In fact the handling of both software and exchange data in the SP and CP
are fundamentally different. Assume that three CP backups of the same
system are stored on the hard disk. This means that we have three copies
of each and every block and program in CP, RP, EMRP, RPG, RP-D etc.
stored on the hard disk. There is also three copies of the exchange data
stored on the hard disk: three B-number tables, three charging analyses
etc.
If the SP has three versions of the same system installed (i.e. three SP
backups on the hard disk), then each software unit (module) is still only
stored once on the hard disk. Also for the SP exchange data this is only
stored once on the hard disk. All installed SP systems (on hard disk) have
the same exchange data.
A reload in the CP may change the CP exchange data, a reload in the SP
does not change the SP exchange data.
5.4.2 SP backup components
The SP backup consists of four components:

• SP software (including RPV/RPV2 and LUM software)
• SP exchange data
• System description file
• The SP software is located to a number of number modules. Each mod-
ule is stored in one individual file on volumes PROG_A and PROG_B.
The LUM and RPV/RPV2 software is part of the SP backup as modules
in the SP system.
• The SP exchange data files contain SP exchange data definitions. These
are usually stored in volume OMFZLIBORD. Examples of SP
exchange data are port definitions, MCS transaction logging conditions,
Network terminal numbers etc.
• The system description file contains a description of the system. This
file is never stored on hard disk but is created when doing the backup
towards external media.
104 R1B
5.5 Chapter Summary

• The name of the CP backup file is RELFSWn (n=0 - 127)
• RELFSWn is a composite file with 6 subfiles
• Two types of dumps exist, the manual and the automatic.
• When manual dump DS, PS and RS are dumped
• Two types of automatic dumps exist, the large and the small dump
• At large dump, the reload marked variables are dumped while in the
small dump the charging data is dumped
• The backup files should be in the right chronological order
• The CP backup can be transferred to/from the IOG via an external
media or via data link
• The CP can reload an older generation backup file
• The file RELCMDHDF is the command log file, where certain com-
mands and subscriber services, ordered from a telephone set, are logged
automatically
• A new command log subfile is created at every large automatic dump
and when ever the function change commands FCSEI/ FCSUC are
given
• The command log recommended to be defined in FPU
• The CP is able to reload even older generation backup files and the
command log subfiles automatically. The operator can decide this by
command
• The SP software (including RPV/RPV2 and LUM software) from vol-
umes PROG_A and PROG_B can be backed up on a FD or OD
• The SP exchange data from OMFZLIBORD volume can be backed up
on FD
R1B 105
106 R1B
6. MCS applications
Chapter Objectives
• Recall the main functions MCS
• Describe the alarm handling function in MCS
• Define data for routing of printouts to IO devices
• Understand how user authority data is used
• Write and execute command log
Figure 6.1
Chapter Objectives
6.1 Introduction
This chapter covers the functions and commands of the man-machine
communication subsystem.
6.2 The functions of MCS

The hardware of MCS was described in chapter 2, i.e. the alarm interface
to which the alarm panels and external alarm sensors are connected.
MCS, however, consists mainly of software. The main functions provided
by this software will be looked at below.
The MCS software resides both in the CP and in the SP.
The complete MCS software is only installed in SPG0. In SPG1, SPG2
and SPG3 only a part of the MCS software is loaded.
R1B 107
The main functions of MCS are:

• Administration of alphanumeric data (commands and printouts)
• Administration of alarms
• Printout routing
• Device attendance
• Authority system
• MCS directories
• Alphanumeric device communication
• IO device blocks
• MCS transaction log
• Command file
Administration of alphanumeric data includes command syntax analy-
sis, location of command receiving block and transfer of command param-
eters, check of device and/or user authority, selection/seizure/release of
device, selection of standby device, assembly of printouts with data from
user blocks.
Administration of alarms is carried out by the alarm functions in MCS.
These contain all the functions for receiving, indicating, transmitting and
acknowledging alarms.
Printout routing. Specification of standby devices, specification of print-
out paths.
Another printout routing function which is not used, is implemented in the
MCS Directories.
IO Device attendance. This function is used to indicate whether a certain
IO device, or the switch, is staffed.
The authority system. In order to increase the security of the operation of
an AXE switch an authority system is implemented. The authority system
handles users and terminals and may assign different authorities based on
this.
A parallel authority system which is used only in special cases is imple-
mented in the MCS Directories.
MCS directories
The MCS directories are implemented in the SP only. They form an
authority and printout routing system. The function is only partly used.
The directories are used when defining terminals and when defining users
for the Local Mode operation with command MCLOC.
Alphanumeric device communication looks after the communication
between the IO device blocks in CP and the device driver programs in
DCS in the SP. The communication between CP-SP is handled by SPS in
the lower four levels of the OSI communication model. MCS provides lev-
els five to seven in OSI for command/printout sessions.
108 R1B
MCS applications
Device blocks are functions that are specific for each type of device and
are not handled by the device drivers in the SP. Reception of user identity/
password, queuing of printouts to busy devices and alphanumeric output to
file are examples of these functions. Four device blocks exist: AT (Alpha-
numeric Terminal), AF (Alphanumeric File), TW (Type Writer) and
AMTP (Alphanumeric transfer using Message Transfer Protocol). The
name of the device block plus a device individual is used as the IO param-
eter and is thus the name of the specific device.
MCS transaction log. The MCS transaction log is used to log transactions
on the alphanumeric terminals. Commands, printouts and logon ID’s are
logged. The MCS transaction log logs transactions on TW/AT and AMTP
devices, but not on AF devices and not on the CPU port of the IOG20.
Command file. Commands are usually executed manually from an alpha-
numeric terminal. Commands may however also be executed from a pre-
pared command file on hard disk or external media. The command file
may be executed manually or automatically according to a time schedule.
6.3 Alarm Handling
6.3.1 Introduction
AXE
Error
Error
remedied
Error
M anual
intervention
Alarm Alarm
issue cease
Alarm
issue External
alarm issue
MCS
Alarm list
.....
....
.......
Figure 6.2
Alarm handling in AXE
Each situation in AXE which gives rise to an operational disturbance of

significance or which requires manual intervention generates an alarm. An
R1B 109
alarm may also be an observation alarm, i.e. an alarm that is not issued to
indicate a fault but to indicate that a manual intervention has taken place.
All subsystems in AXE generates alarms.
Alarms may also originate outside the AXE system. These alarms are then
related to power, cooling, fans or attached to doors and windows of the
building. These are called external alarms.
The functions for receiving, storing, transmitting, and acknowledging
alarms are located in MCS. MCS provides an interface to the operation
staff for alarm information.
MCS provides interfaces in both the CP and SP for internally generated
alarms.
An AXE alarm is issued when the fault or error happens, and ceases when
the fault disappears or is remedied. Some alarms must be manually ceased
by command.
6.3.2 AXE alarm concepts

Below some important concepts of the AXE alarm system are listed
below.
Alarm list. All alarms, internal or external, are reported to an alarm list
when they are issued. The alarms are removed from the list when they
cease. The alarm list is printed by command ALLIP.
The fact that the alarm is removed from the alarm list when the alarm
ceases makes the alarm list a record of the present alarm status of the
switch. There is no alarm recording functionality of the alarm list.
For each alarm the alarm list stores:

• alarm printouts, which are text printouts indicating what is wrong
• alarm classes and categories
• exchange identity
• alarm numbers
• date and time
• FORLOPP identities
Alarm numbers are unique identifiers for alarms.
110 R1B
MCS applications
A la r m n u m b e r
A la rm
c la s s A la rm
c a te g o ry D a te T im e A la r m F id
E xchange
s lo g a n header
A 2 /A P Z "H M B R G L O C 1 2 .4 /0 0 /0 1 " 0 1 3 9 7 0 4 2 5 1258 H ’0 2 6 2 -0 0 0 1

EM G FAULT
EMG U N IT STATE
RSS0 S T R -B C BLO C K
A la rm te x t
Figure 6.3
Example of an alarm in the alarm list
The alarm list may be printed out automatically at regular intervals. The
alarm list has a printout category of 36 and the printout is routed according
to this. The intervals are defined by command ALLTC.
Command example:
<ALLTC:TIME=0800,TIME2=1700;
In the example above the alarm list is defined to be printed at eight and
five o’clock every day. The times are printed with command ALLTP.
The alarm list has a finite size which is defined by a size alteration in the
system. If the alarm list is full when an alarm is reported an alarm list
overflow counter is stepped. The overflow counter is printed at the top of
the alarm list.
Alarm category. An alarm category indicates from which part of the AXE
system the alarm comes from. An alarm always has an alarm category.
There are 16 alarm categories in the AXE system. Each alarm category is
assigned a number, 0-15, see below. This is referred to as the alarm cate-
gory number (ALCATNO).
The alarm categories and their ALCATNOs are as follows:
0 Data processing system
1 Processors
2´ IO Device
3-15 System dependent data, determined by the system projecting
instance in question.
Normally, however, alarm categories 3-15 have the following meanings:
R1B 111
3 Switch
4 Switching part
5 Switching device
6 Subscriber lines
7 Spare
8 Power alarm
9 House alarm
10 Alarm from subordinate exchange
11 Cable alarm
12-15 Spare
Further, the alarm category slogan (ALCAT), is also associated with each
alarm. It is the alarm category slogan which appears in the alarm printout
under the heading Alarm Category. The slogans are APZ, APT, POWER,
and EXT.
Example of alarm and display categories:
<ALACP;
ALARM CATEGORY DATA
ALCATNO ALCAT DICAT

0 APZ 0&4
1 APZ 0&4
2 APZ 0&4
3 APT 1&4
4 APT 1&4
5 APT 1&4
6 APT 1&4
7 APT 1&4
8 POWER 2&4
9 EXT 3&4
...
14 EXT 3&4
15 EXT 3&4
END
To each alarm category one or more display categories can be connected.
A display category (DICAT) corresponds to a physical position (lamp) on
an alarm panel. DICATs 0-3 corresponds to the primary alarm panel, and
DICATs 4-15 corresponds to one position on each of up to 12 secondary
alarm panels.The relation between alarm category number, alarm category
slogan and display category is defined and printed by commands ALACC
and ALACP.
As DICAT 0 always corresponds to APZ ALCATNOs 0-2 must be con-
nected to DICAT 0 etc. See Figure 6.4.
112 R1B
MCS applications
Alarm categories
First alarm
panel 2:nd alarm panel 3:rd... ...13:th
APZ APT POW EXT OBS AXE AXE AXE
A1 O1 A1 A1 A1
A2 O2 ATT A2 ATT A2 ATT A2 ATT
0 1 2 3 4 5... ... 15
Display
categories
Figure 6.4
Display categories
Alarm class. The alarm class of an alarm indicates the seriousness of the
fault. There are five alarm classes in AXE: A1, A2, A3, O1 and O2. Alarm
class A1 is the most serious, the recommendation is that alarms of this
class must be acted upon immediately. Alarm class A2 must be acted upon
immediately during office hours and alarm class 3 must be acted upon dur-
ing office hours.
Observation alarms are used to indicate that a manual intervention is done.
Examples of manual interventions that generates observation alarms is the
manual blocking of a regional processor or the manual blocking of a TSM.
To each alarm class an alarm class number is defined. The alarm class
numbers are 0-4. For each alarm class it is defined whether:
• the bell on the alarm display shall ring at alarm issue
• the bell on the IO device shall ring at alarm issue
• the alarm shall be automatically printed on the alarm printer at issue
Now days the IO device is usually a PC and the ringing of a bell on the IO
device is irrelevant, this was used with printers with bells.
The alarm class definitions are controlled by commands ALCLC and
printed by command ALCLP.
Example of alarm class definitions:
<ALCLP;
ALARM CLASS DATA
ACLNO ACL ALDB TWB PRINTOUT

0 A1 YES NO YES
R1B 113
1 A2 YES NO YES
2 A3 NO NO YES
3 O1 NO NO YES
4 O2 NO NO YES
END
6.3.3 Connection of alarm interface

The alarm interface is the hardware and software that interfaces the alarm
panels and external alarm connectors to the IO system. Hardware-wise the
ALI is implemented in a physical port on a LUM board and in the ALCPU
and ALEXP boards in the SPVM subrack.
ALCPU ALEXP
A larm panel, display
E xternal alarm sensor to categories 0-3.
E X R A N G 20. D evices U S version categories 0-2.
E X A L 2 0 - 31
A larm panel, display
categories 4-7.
U S version categories 3-5.
SC A N interface
categories 0-15.
U S version categories 0- A larm panel, display
11. categories 8-11.
U S version categories 6-8.
V .24 port to L U M port,

2400 baud A larm panel, display
categories 12-15.
V .24 port to fan, 2400 U S version categories 9-11.
baud
B us in backplane P ow er -48 V
Figure 6.5
Alarm interface, ALI
A maximum of two alarm interfaces may be defined in one exchange, one

per node in SPG0.
The alarm interface is installed using the OPI ‘Handling of ALI’. The
ALI is defined with its functions as an AT device using the OPI ‘Connec-
tion of ALI’.
Command example:
<ALALI:ALI=0,IO=AT-1,EXAL=0,ALDI;
<ALBLE:ALI=0;
In the example above an alarm interface, ALI-0, is connected in the A-
node of SPG0. It is defined as AT-1, one or more alarm panels are to be
114 R1B
MCS applications
connected and it connects to external alarm receivers 0-31, i.e. devices

EXAL2-0&&-31. Finally the alarm interface is deblocked.
Command example:
<ALALI:ALI=1,IO=AT-5,EXAL=1;
<ALBLE:ALI=1;
In the example above a second alarm interface, ALI-1, is connected in the
B-node of SPG0. It is defined as AT-5, no alarm panel is connected and it
connects to external alarm receivers 32-63.
The alarm interface definitions are printed with command ALALP.
External alarms. External alarms are used to connect things like power,
cooling, fans or burglar alarms to the AXE alarm system. The external
alarms are connected via external alarm connectors. These are connector
fields which may be located in two places: either centrally in the SPG or
remotely in the EMRP stage.
The connector fields consists of a number of pin-pairs. To issue an alarm
requires that the pins in a pair are either connected or separated, depending
on how the external alarm connector is defined.
The external alarm connector in the EMRP stage is implemented in the
EXALI board. The external alarm sensors are defined as EXAL0 devices.
EXAL2- Remote stages

Central
devices, (subscriber stage
switch EXRANG20 or base stations)
IOG20 alarm Alarm on
sensor cooling
EXAL0-
system
devices,
EXALI
board
Alarm on
power
system
Burglar
alarm on Alarm on
door and cooling
window EXAL0- system
devices
Alarm on
cooling Alarm on
system power
system
Figure 6.6
External alarm sensors in AXE
R1B 115
The external alarm sensors centrally in the SPG are implemented in the
EXRANG20 connector. The external alarm sensors are defined as EXAL2
devices.
1XPEHUVLQWKHILJXUHDUH
(; $/GHYLFHQXPEHUV

(DFKGHYLFHFRQVLVWRIWZR

FRQQHFWRUSLQV

&DEOHWR$/&38

ERDUG
Figure 6.7
EXAL2 devices in EXRANG20 alarm sensor
The external alarms are handled by commands ALRDL, ALEXL,

ALEXI, ALEXP, ALEXR and ALALI.
Command example:
< ALRDL:DEV=EXAL0-5,CAW1=”POWER ALARM”,
CAW2=”POWER UNIT 3”,AC=0,RTIME=5;
< ALEXI:DEV=EXAL0-5;
< ALEXL:DEV=EXAL0-5,PRCA=63,ACL=A3,ALCAT=8;
< BLEAE:DEV=EXAL0-5;
In the command example above an external alarm sensor located remotely
is defined. The sensor is activated by contact between the two pins in the
alarm sensor. The alarm printout will be repeated every five minutes if the
alarm condition stays (contact between pins).
Command example:
<ALRDL:DEV=EXAL2-31,AC=1,MR,CAW1=”FIRE ALARM”;
<ALEXI:DEV=EXAL2-31;
<ALEXL:DEV=EXAL2-31,ACL=A1,ALCAT=15;
<BLEAE:DEV=EXAL2-31;
In the command example above an external alarm sensor located centrally
is defined. The sensor is activated by interrupting the connection between
116 R1B
MCS applications
the two pins of the alarm sensor. The external alarm must be manually
reset by command ALEXR.
External alarms are defined using the OPI ‘External Alarm Connect’.
Scan interface. A separate physical interface is also provided for connec-
tion of external scanning equipment - the Scanning Interface provided by
the SCAN connector on board ALCPU in the ALI. Similar information as
is given in the alarm status printout see below, can be scanned at this inter-
face, but only four alarm classes are given for each alarm category.
Attendance is also given here as well as Exchange Alarm information.
Exchange Alarm is issued only via the Scanning Interface in the ALI. It
occurs directly at power failure to the CP or after eight minutes of no con-
tact between the ALI and the CP.
Command example:
<ALALI:ALI=0,IO=AT-1,EXAL=0,SCAN,ALDI;
<ALBLE:ALI=0;
In the example above an alarm interface, ALI-0, with SCAN interface is
connected in the A-node of SPG0. It is defined as AT-1, one or more alarm
panels is to be connected and it connects to external alarm receivers 0-31,
i.e. devices EXAL2-0&&-31. Finally the alarm interface is deblocked.
The scan category and alarm category number relation is defined by com-
mand ALSCC and printed by command ALSCP.
Heart beat. A heart beat signalling may be activated from the AXE to a
remote O&M centre (AOM). The purpose is of course that if the AXE
malfunctions the O&M centre will be informed by the fact that the heart
beat signalling stops. The heart beat itself is the printout HB which is
routed according to its printout category 35 to an AMTP device, i.e. an
alphanumeric terminal over data link. Since the heartbeat printout will
lock the terminal it is important that it is dedicated for the reception of
heart beat signals.
The heart beat signal is sent every 60 seconds.
Commands for operating the function are: ALHBI and ALHBE.
Alarm status is a printout with printout category 47. If the function is
activated it is sent continuously to an OMC over data link. The printout
routing is defined to send the information both when the exchange is
attended and unattended, see example below.
ALARM STATUS "HMBRG LOC 12.4/00/01"
ALARM CATEGORY 0 1 2 3 4 5 6 7 .... 12 13 14 15
ALARM CLASS O1 A2 A2 - - A2 - - .... - - - -
ATTENDANCE STATUS N N N N N N N N .... N N N N
END
The printout is a list of all ongoing alarms in the exchange. Only alarm
category numbers (0-15) and alarm classes (A1, A2, A3, O1 or O2) for
each category are given for the alarms. The printout also contains attend-
R1B 117
ance information for each alarm category - in principle, attendance for the
exchange.
A new printout is sent each time the status changes. Thus when command
IODAC is given at the exchange the alarm status changes and the printout
is sent to the OMC. It is through this information that the OMC staff know
that an exchange is attended or unattended.
The sending of the alarm status printout must be activated by command
ALSTI. The alarm status can be printed manually by command ALSTP.
6.3.4 Alarm system implementation

The alarm function is handled by the blocks ALA, ALSA, AL, ALIM,
EXAL0, EXAL2, ALCO, in the CP and module ALARMADM in the SP.
ALA is the central block in the MCS alarm handling function. It receives
alarm information signals from the supervision blocks (user blocks) in the
different subsystems. It also receives alarm information from the block
ALSA concerning external alarms. The signals from these alarm generat-
ing blocks includes alarm class, alarm category and detailed information
about the error or fault.
A LA
A larm s from user

blocks in C P
A LS A
A LC O E X A L2 E XA L0
CP
SP
A LA R M A D M A LC PU E XA LI
A larm s from user

blocks in SP G E X R A N G 20
E xternal alarm s E xternal alarm s

connected centrally connected rem otely
in SP G in EM G
Figure 6.8
Alarm system implementation
When ALA receives such a signal it seizes the alarm printer and writes the
label for the alarm printout. It then links the alarm printer to the supervi-
sion block and this in turn sends the rest of the alarm printout to the
printer. ALA then writes END in the printout and releases the terminal.
118 R1B
MCS applications
ALA informs block AL of the changed alarm status so that AL can make
the necessary changes on the alarm panel(s).
Block ALSA handles alarm printouts for external and observation alarms,
and the functions for connection, disconnection blocking, deblocking of
external alarm receivers. The receivers are contained in the ALI and corre-
spond to the external alarm sensors.
The block contains a table of the connected external alarm sensors, and a
table for alarm status, alarm resetting conditions, alarm class, alarm cate-
gory and printout strings for these. All the above information is set by
commands (see below).
When an external alarm is to be issued or ceased ALSA acts as a normal
user to the block ALA, as described above.
Blocks EXAL0 and EXAL2 both work as interfaces between the external
alarm sensors and the block ALSA. EXAL2 is the interface used when
using SP based IO systems. It uses the same hardware, ALI, as block AL.
Block EXAL0 is not part of SP based IO systems - it is used for alarm sen-
sors connected at EMRP, board EXALI.
The main functions of both these blocks are the translation of signals from
ALSA concerning changes of data for external alarm receivers and updat-
ing of the hardware. In the opposite direction, when an external alarm sen-
sor indicates a fault, the functions filter out non-persisting fault indications
and send a signal containing alarm information to ALSA if the fault per-
sists.
Block AL controls the alarm panels and scanning interface (SCAN). It
receives changes in alarm status from block ALA. The lamp on the alarm
panel is not extinguished until no alarms of that class and category remain.
The block also contains the function for control of the attendance indica-
tors and alarm panels depending on attendance.
Block ALIM provides maintenance functions for the ALI. The block con-
sists of software in the CP and the hardware of the ALI. The ALI controls
the alarm panels and scanning interface by receiving signals from block
AL.
If the CP stops for some reason, no alarms can be issued in the exchange
or sent to the OMC. In this case, the ALI will alone generate alarm infor-
mation (the Exchange Alarm) to the alarm panel and over the Scanning
Interface to the OMC. The Exchange Alarm is the final channel provided
by the Scanning Interface.
The ALI can also contain receivers for the information detected by the
external alarm sensors.The information received is sent to block EXAL2.
ALIM has the following functions:
• storing the equipment alternatives of each ALI
• supervising the ALI’s and issuing alarms on ALI fault detection
• isolating and testing of ALI functions.
R1B 119
ALCO is the final alarm handling block in the CP. ALCO receives alarm
information from the module ALARMADM in the SP. ALCO thus han-
dles alarm information concerning faults in the SPG.
Block ALCO stores the information for all SPG alarms in a list and initi-
ates and ceases alarms in the same way as any other alarm user, as
described above. It thus works with block ALA in a similar way to ALSA
when this block administrates external alarms.
Module ALARMADM is the interface in the SP to all alarm generating
blocks in the SPG. Faults occurring in the SPG are detected and analysed
by maintenance functions in the SPG itself and alarm information is sent
to ALARMADM. The information is transferred to the ALCO block in the
CP as described above.
6.4 Routing of Printouts
6.4.1 General
The assembly of printouts from the user blocks is one of the group of
alphanumerical administration (ANA) functions. This function is handled
by block AOT.
It should be born in mind when reading the following text that by IO
device is also meant:
• alphanumeric file device, i.e. AF device
• data link (with corresponding IO device), i.e. AMTP device.
6.4.2 How Printouts are routed

Each automatically initiated printout is assigned to one of a number of
Printout Categories, PRCA, at the software design stage.
128 printout categories are defined in the system, but normally a maxi-
mum of 64 are used.
These printout categories are used to direct spontaneous printouts - such as
alarm printouts - and other types of automatically initiated printouts - such
as the alarm list, etc. - to certain IO devices.
Answer printouts and result printouts (after ORDERED) are normally
routed automatically back to the terminal from which the initiating com-
mand was given. For these types of printouts no printout category is
assigned.
Certain printouts, however, e.g. statistics, can be routed without using
printout categories. A number of commands include an IO or IO2 parame-
ter which allows diversion of answer printouts or result printouts to
another IO device. In this case, by IO device is meant AT or AF devices.
Answer printouts diverted in this way become result printouts on the new
device.
120 R1B
MCS applications
Certain printouts can be routed using either printout category or the IO

parameter in the initiating command. Printout of call meter values is an
example of such an output.
6.4.3 Definition of Printout Routings using PRCA

By use of the command IOROL, the different printout categories are
linked to one or more IO devices.
Up to 32 printout categories can be given in the same command and these
can be linked to up to 12 IO devices. The printouts belonging to the
PRCA’s can be output simultaneously on a maximum of eight devices.
These devices are then said to be arranged in a device chain.
Each PRCA or group of PRCA’s can be connected to a device group con-
sisting of up to maximum four device chains. Thus the PRCA’s can be
linked to up to twelve IO devices, but only a maximum of eight devices
are allowed to receive the printouts simultaneously. This is done by defin-
ing the conditions accordingly.
The device chains are defined by command. All chains belonging to the
same printout category or printout category group thus form the device
group.
<IOROL:PRCA=0&&31,IO=AT-0,DTYPE=FIRST;
<IOROL:PRCA=0&&31,IO=AT-4,DTYPE=NEXT;
<IOROL:PRCA=0&&31,IO=AT-2,DTYPE=NEXT;
A T-2
AT-0 AT -4
IO d evice 1 IO d evice 2 IO device 3

D TY P E= FIR S T D TY P E= N EX T D T Y P E= N EX T
Figure 6.9
Device chain
The parameter DTYPE in the command IOROL is used to define the posi-
tion of each device in the device chain. The command must be given once
for each device.
For the first device, DTYPE has the value FIRST, for the second and
third devices, DTYPE has the value NEXT.
R1B 121
The sequential order in which the devices are specified will determine
whether the device is the 2nd or 3rd device in a chain.
DTYPE=STB
DTYPE=STB
HD
AT-10
AFFILE-2
AT-2
AT-0 AT-4
IO device 1 IO device 2 IO device 3
Figure 6.10
Device chain with standby devices
For each device a standby device can be defined. DTYPE has the value
STB for a standby device.
Thus, in a chain of maximum size, the command IOROL must be given
six times: once for each device and once for each standby device. The
PRCA parameter is only given the first time i.e when DTYPE=FIRST is
specified.
The parameter COND in IOROL is used to define which of the devices in
the chain or chains is to receive the printout linked to the printout catego-
ries.
For each DTYPE, the device is assigned a value for the parameter COND,
as follows:
0 means that printouts will also be routed to the next
device in the chain.
1 means that the printout will only be routed to the
next device in the chain if the device (with
COND=1) is unattended (attendance: see below.)
2 means that printouts are never sent to the next
device in the chain.
It should be noted that the when defining the third device in the chain, the
parameter COND can be omitted as this is the last device.
When defining a standby device - DTYPE=STB - then the parameter
COND may not be given.
122 R1B
MCS applications
Thus whereas parameter DTYPE is used to define the chain, COND is used
to define which device(s) in the chain receive the printout.
Two further parameters of command IOROL are required to complete the
printout routing definition: CLASSA and CLASSUA. These parameters are
assigned to each device to determine which printouts belonging to the
printout category(ies) shall be output. This is done by using the printout
class, PCL, concept.
As well as belonging to a printout category, automatically initiated print-
outs are assigned a printout class. Some printouts have several printout
classes, see example below.
PCL-0 for spontaneous printouts that are not alarms:
ALARM CLASS, ACLPRINTOUT CLASS, PCL
A1 1
A2 2
A3 3
O1 4
O2 5
PCL can have the values 0-5 and these are defined as follows:
• PCL-0 is for automatically initiated printouts that are not alarms
• PCL-1 to PCL-5 are for alarm printouts, PCL-1 being the highest prior-
ity (A1 alarms) and PCL-5 being the lowest (O2 alarms).
An example of printout classes for alarm printouts is shown in Figure 6.4.
When defining the devices in the chain, each device is assigned those
PCL’s for which a printout shall be output on the device. This is done by
means of the parameters CLASSA or CLASSUA.
CLASSA refers to Attended devices and CLASSUA refers to Unattended
devices.
Thus when a printout is routed to a device, a check is made to see if the
PCL for the printout agrees with the CLASSA or CLASSUA value for the
device.
It should be noted that if CLASSA or CLASSUA is not specified, then all
printout classes will be output. CLASSA=6 or CLASSUA=6 can also be
specified. This means that no printouts will be output.
The parameter NOSYST can be given to indicate that no system defined
standby device exists for that device. If the parameter is not specified, the
default value is that, in addition to any specified standby device, the device
also has a system standby.
All the above parameters belong to the command IOROL. Once the data
for a given PRCA or PRCA’s has been defined for each device using
IOROL then the data must be entered into the device tables by the com-
mand IOROI.
R1B 123
A new printout category cannot be routed by IOROL until the previously

defined data has been inserted into the tables by IOROI.
6.4.4 Example of Printout Routing Definition

Command example:
< IOROL:PRCA=10,IO=AT-7,DTYPE=FIRST,CLASSA=0&&5,
CLASSUA=0&&5,COND=0;
< IOROL:IO=AT-5,DTYPE=STB,CLASSA=0&&5,
CLASSUA=0&&5;
< IOROL:IO=AT-9,DTYPE=NEXT,CLASSA=0&&2,
CLASSUA=0&&2,COND=1;
< IOROL:IO=AT-15,DTYPE=NEXT,CLASSA=1,CLASSUA=6;
< IOROL:IO=AF-3,DTYPE=STB;
In the above example, a chain is defined for three IO devices: AT-7, AT-9
and AT-15.
AT-7 is the alarm printer in the exchange, AT-9 is an alarm printer in the
day OMC and AT-15 is an alarm printer in the night OMC.
(Both AT-9 and AT-15 are accessed here via data links connected to X.28
ports for alphanumeric terminals, thus IO=AT-n and the remote AT
‘belongs’ to the exchange. If using links connected to X.25 ports then
IO=AMTP-n (data link using MTP) and the IO terminal is any suitable
output device belonging to the OMC.
Two standby devices are defined: AT-5 for device AT-7 and AF-3 for
AT-15.
As NOSYST is not defined, then the three devices in the chain have a sys-
tem standby as a final backup.
Printouts belonging to printout category 10 are always routed to AT-7 and
AT-9 and are routed to AT-15 if AT-9 is unattended.
On AT-7 (and standby AT-5) printouts of all printout classes are printed
including all alarm printouts even if the device is unattended.
On AT-9, only printouts of classes 0-2 are printed, thus including non-
alarm printouts and alarm printouts of class A1 and A2 only. The printouts
are output even if the device is unattended.
On AT-15, only printouts of class 1 are printed, i.e. only A1 alarm print-
outs. The printouts are output only if the device is attended.
It should be noted that the standby device to AT-15 is AF-3, an alphanu-
meric file device. The printouts routed here are stored in a predefined file
on hard disk. The concepts attended/unattended have no meaning here: all
printouts will be stored.
This type of device will be looked at in the next section.
124 R1B
MCS applications
When working with the definition of printout routing data, quite complex
solutions are sometimes required - especially when routing of alarms to
different Operational and Maintenance Centres is required. The automatic
printout of alarm status - indicating changes in ongoing alarms - and heart-
beat supervision signals from the CP are also routed to the OMC.
It is important to follow the relevant OPI when defining printout routings.
The definition of printout routings is covered in the OPI ‘Printouts, Spon-
taneous, Route’.
The function is handled by the block SEC2.
6.5 Standby Devices

All terminals may break down or go in operational for some reason. The
background to having standby devices is simply that a backup is needed if
the ordinary terminal goes out of operation.
Standby devices for alphanumeric devices can be defined in several differ-
ent ways:
• by use of the command IOROL
• by use of the command IOSBC
• by use of the command IOSYC
The command IOROL has been covered above in the section Routing of
Printouts. One standby device can be defined per device to which a print-
out is routed (DTYPE=STB).
It should be noted that a device defined as standby device by IOROL is
only standby for those printouts belonging to these particular printout cate-
gories and will not act as standby for any printout categories.
Also, spontaneous printouts with printout categories will be diverted to the
system standby if no suitable standby has been defined by IOROL, or if
the standby cannot receive the printouts due its being unattended.
The command IOSBC allows up to three standby devices to be defined for
a given device. Function parameter is defined as ALPHA.
A standby device defined by IOSBC will act as standby for result print-
outs only.
By result printouts are meant printouts obtained after receiving ORDERED
or answer printouts that have been diverted to another device by means of
an IO parameter in the initiating command.
Printouts routed on the basis of printout category will not be handled by
this type of standby device.
It should be noted, however, that a standby device defined by IOSBC may
not be allowed to receive all printouts diverted to it. The user programs
issuing the printout may contain parameters governing this.
R1B 125
The standby devices defined by command IOSBC can be checked by com-

mand IOIOP.
The OPI ‘IO Device Standby List, Change’ should be used when defin-
ing standby devices for alpha terminals.
The command IOSYC is used for the definition of the System Standby
device. The system standby can be any normally defined AT, AF or
AMTP device. Once defined, the system standby cannot be removed, but
the actual IO device can be changed by use of command IOSYC.
The system standby can be suppressed for spontaneous printouts routed on
printout category - as has been shown earlier - by use of the parameter
NOSYST in the command IOROL.
The system standby device can be printed out by use of the command
IOSYP.
6.5.1 Detachable IO devices

A detachable IO device is a temporary device attached to a permanently
connected line. A strapping plug in the device connector replaces the IO
device when this is detached. These devices are defined with the parameter
DET in the command IOIOI.
A detachable IO device cannot be defined as a standby device by any of
the above commands.
6.6 Device Attendance Status

An alphanumeric IO device can have status attended or unattended. The
status is an implication of whether or not the device is monitored by oper-
ation and maintenance staff.
Attendance is set by command IODAC and the intention is that when the
operator starts working in the switch he/she starts by defining the terminal
as attended. Likewise the terminal is defined as unattended when the oper-
ator leaves.
A device that has been inserted in a printout routing path (commands
IOROL, IOROI) does not automatically receive the printouts belonging
to the relevant printout category. It is the attendance status of the device
that decides if the printout shall be sent to the device or not.
The definition of the printout routing indicates which printouts are to be
printed if the device is attended or if the device is unattended. The values
of command parameter CLASSA say which printout classes may be
printed if the device is attended and the values of CLASSUA determine
the same for unattended devices.
Control rooms - i.e. the exchange - also have attendance status. If a control
room has status attended then all relevant alarms will be sent to the alarm
panel in the control room.
126 R1B
MCS applications
If unattended then the alarm panel will not receive any alarms - it will be,
in effect, switched off.
Alarms status printout and heart beat information is constantly sent via a
data link to the OMC using printout categories 47 and 35 even if the
exchange is unattended. The alarm status printout also contains attendance
information. Thus visual information on alarm status at all supervised
exchanges is always available at the OMC independent of control room
attendance status at the different exchanges.
Attendance for a device is defined by the command
<IODAC:ATT;
Unattendance is defined by the command
<IODAC;
The command must be given from the device that is to be attended/unat-
tended.
To simplify matters, devices can have so called common attendance. This
is defined for the devices when they are defined, by the command:
<IOIOI:IO=AT-4,COMMATT;
When changing the attendance status of a common attendance IO device
by use of command IODAC, all other common attendance IO devices will
also change status.
The attendance status is also indicated by the ‘ATT’ lamp on the alarm
panel.
When changing attendance status the OPI ‘Change of Attendance Status
for Control Room and IO Device’ should be used.
6.7 Alphanumeric Information on File
6.7.1 General
Printouts can be routed to a number of alphanumeric devices, either locally
in the exchange or over a data link to an operation and maintenance centre,
OMC.
However, some printouts are so long that they are often unsuitable for out-
put on an alpha device. Such printouts - e.g. statistics, CP error interrupts,
the printouts received in connection with the execution of command files,
etc. - sometimes occupy IO devices unnecessarily.
Other types of printouts must be stored at the exchange and may even be
required at another location, e.g. an OMC, either directly or at some later
time.
For all these types of printouts it is convenient to output the information
directly to a file on hard disk.
R1B 127
Command example:
<IOIOI:IO=AF-3;
<IOAFC:FILE=AFFILE-3,IO=AF-3;
AT
AXE
Printout
....
... HD
...
.
File=AFFILE-3
Figure 6.11
Alphanumeric file
This file, containing alphanumeric information, is called an alphanumeric

file. The file has to be defined and a corresponding alphanumeric file
device has to be defined in the MCS block AF in the CP, to allow print-
outs to be routed or directed by command to the file.
The advantages of using an alphanumeric file to store printouts are:
It avoids occupying IO devices with long printouts.
The file is easy to use. It can be copied with INFIT or INFET, read with
IOFAT, and sent over a data link from hard disk using File Process Utility,
FPU. It speeds up the execution of a command file.
6.7.2 Definition of Alphanumeric File Device

The alphanumeric file must first be defined. Normally the file name
AFFILE is used but any name can be specified.
The file must be a sequential file on hard disk, and may be simple or com-
posite.
The record length should be at least 160 bytes (exchange dependent, the
same length as the printout buffer in AF), but could be made longer, e.g.
512 bytes.
When the file has been defined the next step is to define the alphanumeric
file device. The device type is AF.
The device is defined with command IOIOI.
128 R1B
MCS applications
On definition of an AF device, a subfile of file AFFILE corresponding to

the device number is automatically created. Thus on defining device AF-3,
subfile AFFILE-3 is created on the hard disk.
Automatically initiated printouts, e.g. alarms, can now be routed to the AF
device and will be stored in the subfile.
By command directed printouts is meant result printouts received in
answer to a printout command or the printout obtained at the execution of
a command file. These printouts are directed to another device when giv-
ing the initial command, e.g.:
<EXEMP:RP=ALL,EM=ALL,IO=AF-12;
The example above diverts the printout to AF-12, i.e. to subfile
AFFILE-12.
As mentioned at the beginning of this section, the parent file for the sub-
files does not have to be called AFFILE. Even the subfile identifiers do not
have to be the same as the AF device numbers i.e. the default values.
The file can be defined as having another name (but the same record
length) and the subfile names can be changed from the default values.
Both of these definitions are performed by the command IOAFC, e.g.:
<IOAFC:IO=AF-8,FILE=AFFILE-PHILIP;
to change the default value of the subfile from AFFILE-8 to
AFFILE-PHILIP, or:
<IOAFC:IO=AF-14,FILE=PRINTFILE-ROBIN;
to define the subfile PRINTFILE-ROBIN to receive outputs diverted to
device AF-14. The file PRINTFILE must previously have been defined.
Thus both AFFILE and/or any other suitable file defined by command
IOAFC can be used.
It is recommended that for occasional printouts the subfiles should be of
the form AFFILE-”own-signature”.
The command IOAFP is used to print the existing links between AF
devices and alphanumeric files.
When working with AF devices and files the OPI ‘Printout of Alphanu-
meric Information to File’ should be used.
R1B 129
6.8 MCS directories

MCS directories form an authority and printout routing system. The func-
tion is only used partly. The directories are used when defining terminals
and when defining users for the Local Mode operation with command
MCLOC.
The MCS directories are three:

• user
• communication
• list
The MCS user directory comprises a list of the users in a system. This is
a function that mirrors the user definition in the CP (see above) and there-
fore is not used. There are however some users that have to be defined:
• All terminals connected to the system are defined as users
• when using the local mode with command MCLOC a user defined in
the MCS user directory must be specified
Command example:
< IMLCT:SPG=0;
:MCDCI:DIR=USER,NAME=SHIRLEY,AUTH=A&B&C&D&E;
:MCDCI:DIR=USER,NAME=NAUKO,AUTH=F&G,PASSW=IOG3;
:MCDBE:DIR=USER,NAME=SHIRLEY;
:MCDBE:DIR=USER,NAME=NAUKO;
:END;
In the command example above a user SHIRLEY is defined, the user is
given the authority to issue commands of SP authorities from A to E. Shir-
ley does not use a password.
The second user NAUKO has the command authority G and F and has a
password defined.
The authority for the user defines the authority to issue certain commands.
All SP commands have a command category from A to G. This is similar
to the CP command categories.
The above defined users NAUKO and SHIRLEY may be used with com-
mand MCLOC.
The MCS communication directory comprises a list of the input/outputs
to the system. All ports in DCS used for alphanumeric terminals are
defined here.
< IMLCT:SPG=0;
: MCDCI:DIR=COM,NAME=T1012101,NTN=1012101,
AUTO=YES,SUPRV=NO,QUEUE=YES;
: MCDBE:DIR=COM,NAME=T1012101;
: END;
130 R1B
MCS applications
In the command example above a network port, identified by the network

terminal number, NTN, is defined in the communication directory. The
port has automatic logon which means that no user identity of password is
required when issuing commands. All network ports are always defined as
having automatic logon, if a user identification procedure is required this
is handled by the CP authority system.
A more detailed example of the definition of a network port for terminal
communication is given below.
The MCS list directory is a printout routing function which is never used.
The CP implemented routing of printouts with command IOROL is
always used.
Local mode user authority verification must take place in the SP because,
when accessing the system in local mode, only the SP is accessed, thus the
authority check must be made there.
When defining a port, authority data for the port must be inserted into the
Communication Directory. The data includes user NAME, an AUTO
logon parameter, the network terminal number (parameter NTN) of the
port and supervision (parameter SUPRV) and queuing data (parameter
QUEUE).
Data for the port must also be inserted into the User Directory. The data
includes user NAME and permissible command Authority (parameter
AUTH).
In the Communication Directory, any name can be used for the port and is
normally defined as TNTN, i.e. T followed by the NTN of the port. Auto
logon is entered as YES, and the NTN of the port is given.
In the User Directory, the port name (e.g. TNTN) is again defined as the
user name, and command authority is normally set to E (i.e. only those
subcommands having Authority E - see command descriptions - are
allowed from the terminal connected to the port).
As AUTO logon is defined as YES any port user bypasses the authority
control associated with the SP and verification takes place in the CP.
An addition to the above port data must be made for users who are
allowed to access the SP in local mode.
To access local mode on any terminal a user is required to give a User-
name (USR) and Password (PSW) in the access command.
Before this can be done, a name and password for each local mode user
must be inserted in the User Directory. Initially, default values for USR
and PSW exist in the User Directory, but these can be removed after all
local mode users have been assigned individual names and passwords.
To access local mode the command MCLOC is used and can be given from
any terminal:
< MCLOC:USR=NAUKO,PSW=IOG3;
R1B 131
6.8.1 Definition of Terminal Data

An example of SP authority verification used in connection with port defi-
nition is given below:
Port definition: port 1-2-2-1 => NTN=1012201
Communication Directory:
: MCDCI:DIR=COM,NAME=T1012201,NTN=1012201,
User Directory:
: MCDCI:DIR=USER,NAME=T1012201,AUTH=E;
Any user can now access the CP from the terminal connected to this port.
User authority verification, if any, will be carried out by the CP.
6.8.2 Definition of User Data

To further allow an individual user to access the SP in local mode via any
such defined port, an entry of the user’s name and password must now be
made in User Directory, e.g.:
: MCDCI:DIR=USER,NAME=URSULA,
PASSWORD=USCHI,AUTH=EFH;
In this case, a user using the above name and password can now use
MCLOC to access the SP in local mode from any terminal.
Having made local mode access, commands having authorities E, F and H
in the SP can now be given.
It should be noted that the above entry is not required if the default user
and password are left in the User Directory for all local mode users to use.
If required, the default user - and any other user - can be removed from the
User Directory by command MCDCR.
It should be also be noted that even if user authority is applied to a port
(i.e. AUTO=NO in Communication Directory, NAME and PASSWORD
defined in User Directory) then any user who has a name and password
defined in User Directory can access the system via this port using own
name and password. It is thus impossible to limit the use of a given termi-
nal/port to an individual user.
All entries in the two directories must be deblocked, i.e. activated, by use
of the command MCDBE.
The entries in the two directories can be printed with command MCDCP.
The defined passwords are not shown in the printouts.
The OPI’s which include the definition of user authority verification in the
SP are:
‘Connection of Alphanumeric Terminal, SP-Connected’.
‘Change of Directories in MCS’.
132 R1B
MCS applications
6.9 The MCS Transaction Log

The MCS Transaction Log is an optional function which stores informa-
tion about different command and printout transactions, i.e. logging of the
operator communication.
The transaction log does not log transactions on devices of type alphanu-
meric file (AF) or towards CPU port.
STDEP
AT PRINTOUT
CACLS AXE Logfile on hard disk
....
DATE TIME IO USER
STDEP
EXROI PRINTOUT
AT PRINTOUT CACLS
SYREI ....
PRINTOUT
DATE TIME IO USER
EXROI
LAFBP PRINTOUT
AMTP ALARM SYREI
... PRINTOUT
INFUI
DATE TIME IO USER
...
LAFBP
ALARM
...
INFUI
...
DATE TIME IO USER
Figure 6.12
MCS transaction log
A transaction log file can be defined to log data according to one of the
following types of logging criteria:
• Logging of all IO device transactions excluding certain printout catego-
ries, PRCA, if required
• Logging of all commands and result printouts on IO devices (like above
but without spontaneous printouts like alarms)
• Logging of printouts by printout category, PRCA
• Logging of log on attempts to IO devices
Only one of the listed types of logging criteria can be defined per log file.
In addition to this an exclusion may be added to each logging criteria:
• Exclusion of certain commands in combination with logging criteria
Up to five log files can be active at the same time. Each file must have a
unique name.
R1B 133
The transaction log files are composite sequential files. The files must be
created before any logging conditions can be defined. Unlike the com-
mand log file, the transaction log files are not system dependent and can
have any name.
The transaction log files are normally defined in the volumes where statis-
tics data is recorded. The volume is preferably duplicated and must have a
certain size as the transaction log may store huge amounts of alphanumeric
data.
The operational instruction ‘MCS Transaction Log’ describes how to set
up, change and remove logging conditions and also how to deblock (acti-
vate) the log.
How to set up the MCS transaction log is market dependent and it may be
configured according to the local needs. A few things could be recom-
mended:
• Never log the transactions of the terminal which is connected to the
alarm interface. This device sends out ‘printouts’ which are orders to
the alarm panel and receives ‘commands’ which are input from the
external alarm interface. This information is not alphanumeric and is an
unnecessary waste of space in the log.
• Never log the transactions on a IO device which is connected to an
authentication centre in the GSM mobile network. The traffic on such
an IO device is very high and consists of ‘garbage’ from an alphanu-
meric point of view.
• Exclude the printout category for the heart beat printout, HB. If the
heart beat function is active this printout is emitted continuously. The
printout category is parameter set in block ALA, usually 35.
• In some markets the logging of the restart data and system restart print-
out is kept in a log of its own. Since this log contains very little data it
may be stored for a long time on the hard disk and can therefore serve
as a record when measuring the ISP. The printout category is 32 and
this includes CP, EMRP and RP restart as well as Error Interrupt in
APZ 212 20.
The logging of this printout is then preferably excluded from other logs.
• If the alarm status function is used (i.e. the alarm status printout is con-
tinuously sent to operation and maintenance centre), that printout is
preferably excluded. The printout category is 47.
Command example:
< IMLCT:SPG=0;
: MCTLS:FILE=TLOG,FILEDUR=72,IO=AT-0&AT-2&AT-4&
AT-5,XPRCA=32&35&47;
: MCTLS:FILE=TLOGRESTART,FILEDUR=240,PRCA=32;
: MCTLS:FILE=TLOGON,FILEDUR=120,LOGONS;
: MCTBE:FILE=TLOG;
: MCTBE:FILE=TLOGRESTART;
: MCTBE:FILE=TLOGON;
134 R1B
MCS applications
: END;
Command example of setting logging conditions. The first condition logs
all commands, printouts and alarms except the alarms of printout catego-
ries 32, 35 and 47. The second logs restart data only. The third logging
condition is only relevant if the authority system is used.
The log is deactivated by the command MCTBI.
The transaction log files are composite files with the record length 256
bytes. The function automatically creates a new subfile every hour. The
command parameter FILEDUR determine the file duration in hours, i.e.
the number of subfiles to be used. A maximum of 250 subfiles can be cre-
ated. When the specified time has expired the oldest subfile is deleted.
Thus, every hour, one new subfile is created and one is deleted, which
implies that the number of simultaneously kept subfiles, in one mainfile,
never exceeds the file duration value.
The subfile name indicates which time period the subfile contains logging
data for. The log subfile name construction is “ymmddhh” where “y” indi-
cates year, “mm” indicates month, “dd” day and “hh” hour.
By using File Process Utility, FPU, the transaction log subfiles can be sent
automatically to an operation and maintenance centre via data link.
The infinite files function is never used with MCS Transaction Log.
6.9.1 Exclusion of certain commands and printouts from log-

ging
An administration may chose to exclude certain commands and printouts
from being logged by the MCS transaction log. This is performed by creat-
ing a text file in AXE-external environment (WS or PC) which lists the
commands and printouts to be excluded.
R1B 135
Text file with commands and

printouts to exclude:
AGKDI
Hard disk in IOG20, SPG0 PC or WS
EXRPI
EXROI
printout
printout
File
Encryption
Figure 6.13
Exclusion of printouts and commands
This file is loaded in SPG0 and encrypted before being stored on the hard
disk. This file is read by the MCS Transaction Log after restart and the
indicated commands and printouts excluded.
Since the file is encrypted there is no way to read the file and which com-
mands and printouts are excluded cannot be printed by command.
6.9.2 Search in Transaction Log

The search in the transaction log is performed according to one or more of
the following criteria.
• IO device
• date and time
• one command or part of command name e.g. “CH” for charging com-
mands beginning with CH
• all printouts
• one or a number of printout categories
• a specific user
• logon attempts
136 R1B
MCS applications
AT
AXE Logfile on hard disk
DATE TIME IO USER
STDEP
PRINTOUT
AT
CACLS
....
DATE TIME IO USER
EXROI
PRINTOUT
AMTP
SYREI
PRINTOUT
STDEP
PRINTOUT DATE TIME IO USER
CACLS EXROI LAFBP
.... PRINTOUT LAFBP ALARM
SYREI ALARM ...
PRINTOUT ... INFUI
INFUI ...
... DATE TIME IO USER
Figure 6.14
Search in transaction log
This is described in the operational instruction “MCS Search in Transac-

tion Log”.
Two types of searches exists, i.e. search on transactions concerning the ter-
minal the search is ordered from and authorised search which gives a pos-
sibility to search on any transaction made on any terminal.
Example of search in transaction log:
< IMLCT:SPG=0;
: MCSTP:FILE=file,COMMAND=”CH”,STIME=1000,
ETIME=1200;
ORDERED
: END;
This command will give a printout of all commands beginning with “CH”
(charging commands) sent from this terminal between 10:00 and 12:00 the
current day.
Example of authorised search in transaction log:
< IMLCT:SPG=0;
: MCSAP:FILE=TRLOG1FILE,LOGONS,IO1=AT-2&&-4,
IO2=AMTP-2,ETIME=1200;
R1B 137
ORDERED
: END;
This command will give a printout of all logon attempts (successful and
unsuccessful) from the terminals AT-2, AT-3 and AT-4 from midnight to
12:00 the current day. The search result will be printed on terminal
AMTP-2.
The function is handled by the four modules TLOG, TLOGADM, TLOGS
and TLOGSADM.
The file TLOGCOND on hard disk stores the logging conditions.
6.10 Command file

Commands are usually executed manually or automatically from a alpha-
numeric terminal. Commands may however also be executed from a pre-
pared command file on hard disk or external media. The command file
may be executed manually or automatically according to a time schedule.
The most important use of the command file is when executing a com-
mand log after a reload. All commands that have affected the exchange
data up until the reload are then stored in two of the subfiles to file RELC-
MDHDF.
6.10.1 Creation of command file

Command example:
< INCMT:SPG=0;
: INFII:FILE=COMMAND,SIZE=5,EXP=5,RLENGTH=128,
TYPE=SEQ,FCLASS=CMP,VOL=EXCHVOLUME;
: END;
< IOAFT:FILE=COMMAND;
< CACLP;
< STDEP=DEV=LI3-133;
In the example above the file COMMAND is created on hard disk. Each
record is defined to 128 bytes, this is to make sure that also very long com-
mands may fit into one record. The commands CACLP and STDEP are
written to the file.
6.10.2 Manual execution of command file

Command example (continued from above):
< IOCMI:FILE=COMMAND,PROC=D,IO2=AT-5;
(on AT-5:)
138 R1B
MCS applications
COMMAND READING STARTED

< CACLP; (...printout)
< STDEP:DEV=LI3-33; (...printout)
END OF COMMAND READING
In the example above the execution of the command file is started from
one terminal while the execution of the commands in the command file is
started on terminal AT-5. The process D is used which means that the
commands are printed on screen when executed, also process printouts,
answer printouts and result printouts are printed. The execution of the
command log will continue irrespective of any fault codes.
The process parameter can take values A, B, C, D and E. See the command
description for command IOCMI for description.
6.10.3 Automatic execution of command file

A command file may be executed automatically in two ways, either
according to a time schedule or automatically after a reload.
According to time schedule.
Command example:
< IOCMC:STATE=PASSIVE;
< IOCML:FILE=COMMAND,DATE=970401,TIME=0200,
PROCESS=B,IO2=AT-9,DAILY;
< IOCMC:STATE=ACTIVE;
In the example above the time schedule for command files is deactivated
and a time schedule for execution of command files is defined. After this
the execution of command files is activated again. The command file
COMMAND will be executed at two o’clock in the morning every day,
starting the first of April 1997. The commands will be executed on AT-9.
The execution will be done according to process B which means that the
execution is halted if a fault code is received from the system.
The command log time schedule, and its status, is printed with command
IOCMP.
Automatically after a reload.
This option is valid only for command log subfiles.
This function is controlled by command SYGPS, parameter CLH, com-
mand log handling.
6.11 IO device load regulation

The load regulation of IO devices is used to regulate the output of print-
outs depending on the central processor load. The load regulation is con-
trolled by block LOAS. The different priority levels are similar to the
priority levels of a subscriber or of an incoming route, parameter PRI.
R1B 139
Command example:
<IOLRC:IO=AT-5,PRI=EMERGENCY;
In the example above the priority of IO device AT-5 is set to the highest,
emergency, indicating no load regulation at all. The definitions are printed
by command IOLRP.
Block LRCIO.

• The MCS software resides both in the CP and in the SP
• Some of the main functions of MCS are: administration of commands
printouts and alarms, printout routing, authority system, MCS directo-
ries, MCS transaction log, etc.
• There are two types of alarms internal and external
• There are five alarm classes A1, A2, A3, O1 and O2 and sixteen alarm
categories (0-15)
• Each automatically initiated printout is assigned a printout category
(PRCA)
• The PRCA is used to direct the printouts, such as the alarm list, to cer-
tain IO device(s)
• Device chain is a chain of maximum eight devices receiving different
PRCA’s simultaneously
• Each PRCA or group of PRCA’s can be connected to a device group
consisting of maximum four device chains
• MCS transaction log stores information about different command and
printout transactions
• Logging criteria for the MCS transaction log: logging of all IO device
transactions, logging of printouts by PRCA, logging attempts to IO
devices
• Search in MCS transaction log is performed according to several crite-
ria, such as IO device, date and time, one command or part of a com-
mand, one or a number of PRCA’s, etc.
140 R1B
7. MCS - Command handling
Chapter Objectives
• Explain the purpose of the entry commands used with IOG 20
• Name the entry commands for the different subsystems
Figure 7.1
Chapter Objectives
7.1 Introduction
This chapter describes command handling in AXE.
7.2 AXE Command Handling

The AXE operator interface is implemented in a number of commands.
Most of the commands follows the five-character MML standard. The
software that implements the commands is located in the CP, SP and in
firmware in the maintenance unit in the CP.
In the AXE system there is a distinction between the commands that are
implemented in software that exist in the CP and those commands which
are handled by software in the SP. Or, putting it in a slightly simplified
way, one must distinguish between CP commands and SP commands.
All commands that are implemented in the CP - for both APT and APZ
blocks - are given in the normal way in accordance with the rules of the
man-machine language. IOG 20 is transparent for these commands and for
the answer printouts received. This is shown in Figure 7.2.
R1B 141
SP CP
Alphanumeric terminal
Command
AT
Printout
Figure 7.2
Handling of CP commands
When a command is to be executed in an SP - in any SPG connected to the

CP - the CP must first be told that this is the case. To do this, one must
give a special so called entry command which opens a dialogue between
the operator terminal and the required SPG. There are a number of differ-
ent entry commands in the AXE IO system.
Entry Entry
a) c)
command command
AT SPG0 CP AT SPG0 CP
Printout Printout
b) Subcommand
SPG1
AT CP
SPG0
Printout d) Subcommand
AT
SPG0 CP
Printout
SPG1
Figure 7.3
SP command handling
a) Entry command and printout, SPG0
b) Subcommand and printout, SPG0
c) Entry command and printout, SPG1
d) Subcommand and printout, SPG1
142 R1B
MCS - Command handling
Note that terminals may be connected to LUM in SPG0 only. SPG1 does
not contain subsystem MCS.
Whether a command is implemented in CP or SP is in many cases indi-
cated in the command description. The operator usually knows this by
heart.
The entry command is also called a path building command i.e. it is used
to set up a path from the CP to the required command receiving block in
the required SPG for the following command sequence. The dialogue is
then carried out from the terminal side using so called subcommands.
Command example:
<IMMCT:SPG=1;
This entry command builds a path from the CP to SPG 1.
Entry commands are analysed in the normal manner by the ANA blocks in
the CP. Thus user authority and terminal authority verification can be pro-
vided by the ANA blocks for these commands.
Each entry command owns a given set of subcommands, so once an entry
command has been given correctly any of these subcommands can be
entered. During the dialogue with a certain entry command no other com-
mands can be given but the sub commands belonging to this particular
entry command.
The subcommands thus pass from the SP to the CP where they are directed
to the required SPG. The handling of the subcommands in the CP depends
on the entry command.
The printouts are sent back to the terminal on the same path.
An exception to the above (Figure 7.3 b) is the special case of certain large
result printouts received from the SP in own SPG. These can be sent
directly to the terminal from the SP without going via the CP in order to
gain CP capacity.
For MCS, DCS and several SPS user function blocks in the SP, a group of
MCS modules in the SP (MESSTRANS, COMANA and PRINTSERV)
have the same function in the SP as the ANA blocks in the CP. They per-
form the necessary interface between the incoming commands/outgoing
printouts and the user blocks.
7.3 Entry Commands

SPS maintenance and reconfiguration functions have just one entry com-
mand. Certain operation functions in SPS make use of a command receiv-
ing block in MCS and thus use entry commands belonging to MCS/DCS.
The commands used for DCS/MCS are general entry commands that
would also be used for addressing functions belonging to Remote Meas-
urement Subsystem (RMS) and Statistics Traffic Measurement Subsystem
(STS) if these were loaded.
R1B 143
In each subsystem each entry command corresponds to a different author-

ity level: high, middle and low.
High authority entry commands allow all subcommands for the subsystem
to be entered.
Middle authority commands allow a limited number of subcommands to
be entered.
Low authority commands allow only print subcommands to be entered.
The entry commands for each of the subsystems are listed below:
SPS (maintenance) FMS MCS/DCS/RMS/STS
IMMCT INMCT IMLCT
INMIT IMLIT (F-category)
INMPT IMLPT (E-category)
All new subcommands being developed in IOG 20 are located under entry
commands IMLCT, IMLIT and IMLPT.
The fourth character of the commands:
C is for Change and Print high authority
I is for Initiate and Print middle authority
P is for Print low authority
When an entry command is given correctly, the system answers by
prompting a colon. Command example:
<IMMCT:SPG=1;
:
:END;
EXECUTED
<
In the example above a dialogue is started towards SPG1 and subcom-
mands can now be given after the colon. Subcommands issued will be ana-
lysed in SPG1. A dialogue is terminated by command END and the
ordinary prompt is used.
A dialogue may also be temporarily terminated by an @-character. The
dialogue is resumed by a EOT character which is for example sent by
function key F1 in FIOL.
Command example:
<IMMCT:SPG=2;
:
:@
144 R1B
< INTERRUPTED COMMAND IMMCT

<(EOT)
: RE-ENTRY TO COMMAND IMMCT
:
:END;
EXECUTED
<
In the example above the dialogue towards SPG2 is temporarily suspended

by a @-character and after that resumed by an EOT character. Finally the
dialogue is terminated by command END.
A further entry command not previously mentioned is the command
ISMCT.
This is a special entry command which is only used at start up of an IOG
20 - so called cold start. This command is implemented in the start system
only and is not part of an ordinary IOG 20 system.
The ISMCT command will only be accepted during the start up phase and
therefore is not used for basic operation and maintenance.
7.4 Subcommands
To each of the entry commands belongs a set of subcommands. These are
also found in the Command Descriptions in the B-Module.
When a subcommand is entered with the necessary parameters (if any)
answer printouts are received in exactly the same way as with CP com-
mands. After each of these printouts a new colon is given so that a new
subcommand can be entered, and so on.
To end the dialogue the subcommand END must be given.
After this subcommand the communication returns to the CP and the ready
mark is obtained. Normal CP commands can now be given. A new entry
command must be given if a new session between the CP and an SPG is to
be initiated.
Then the procedure printout ORDERED is received in answer to a subcom-
mand, the dialogue must first be terminated before the terminal can be
released. Thus the subcommand END must be used.
After receiving printout EXECUTED the terminal can be released and the
result printout obtained.
As the dialogue has been terminated, if one wishes to continue with sub-
commands belonging to the original entry command then the entry com-
mand must be given again before it is possible to continue.
R1B 145
7.5 Local Mode and CPT Commands

As has been seen so far, all commands concerned with an SP - entry and
subcommands - are sent to the CP from the SP. The subcommands are
directed by the CP back to the SP or to an SP in another SPG. However,
the possibility exists to send commands to the SP which do not go on to
the CP, but are handled directly by the SP.
If commands are to be handled directly in the SP then:

• the commands must be implemented in the SP
• the SP must be accessed by an operator working in local mode
Using local mode the operator access the SP directly and receives print-
outs directly from the SP.
Commands
AT
SP CP
Printouts
Figure 7.4
Local mode
An SP is accessed in local mode in two ways:

• connecting a terminal to the CPU port
• using the path building command MCLOC
One can access the SP in local mode at any time, even if the CP is running,
but obviously there is no reason to do this. The number of commands that
can be addressed to the SP alone are limited. Not all MCS and FMS sub-
commands can be handled by SP functions alone. Also certain functions
that can be handled by the SP alone are not authorized in local mode if the
CP is available.
The main use of local mode is to be able to access the SP when the CP is
unavailable for some reason.
Thus, if the CP should become seriously faulty and IO commands are not
accepted, then access to the system using local mode must be used to initi-
ate a recovery process.
146 R1B
Within the SP software exists part of the CPT function (Central Processor
Test system). This software - a number of Maintenance Subsystem mod-
ules - allows us to access CPT hardware in the CP in order to facilitate
testing and loading of the CP from hard disk.
To do this we must use a set of CPT commands. To be able to give CPT
commands the SP must be accessed in local mode.
To use local mode a command is used: MCLOC. Access in local mode can
be made from any terminal having authority for this command.
At loss of contact with the CP for any reason the messages:
CP UNAVAILABLE, ENTER EXIT OR MCLOC or
CP SB UNAVAILABLE, ENTER EXIT OR MCLOC
is given. The command MCLOC will always be accepted provided that the
SP is running. The sequence is given below:
<MCLOC:USR=XUJING,PSW=CRYSTAL;
:
:EXIT;
EXECUTED
<
USR and PSW correspond to the operator’s user name and password
defined in the MCS User Directory.
A master user and password are defined in the initial data but can be
removed by the administration.
Commands can now be given to the support processor in the own SPG. It
should be noted that MCS, DCS, STS or RMS subcommands require no
entry command when issued in local mode.
The subsystem FMS has its own specific entry command and thus with
this subsystem the entry command must be given when FMS is to be
accessed in local mode.
The subsystem SPS is not accessible when accessing the SP in local mode
in the above manner.
Local mode can also be attained by making use of the local terminal men-
tioned earlier. If, for instance, all Line Units are blocked then no access
can be made to the system.
A terminal connected to the CPU60 board in the SP could be used to give
SP commands to deblock the LU’s.
When entering local mode using a local terminal then the command
MCLOC is not required.
All four subsystems can be accessed in this case. The entry commands for
SPS and FMS can be given without the SPG parameter.
R1B 147
The AT must be working with capital letters in this case. If contact is lost
during a command sequence, then the terminal must be switched to TTY
mode and semicolon entered. On reception of the ready mark return to
buffer mode.
An important difference to notice between normal mode and local mode of
access is that when a terminal has to be released in local mode then the
command EXIT must be used. To return to local mode the command
MCLOC must be used again.
It is not usually necessary, however, to release a terminal on receiving
ORDERED when accessing in local mode. This depends on the command
used.
When working with a local terminal or with suitable authority on an IO
terminal the command HELP can be used to print all commands that can
be used in local mode.
7.6 Chapter Summary

• Entry command is given to open a dialogue with a specific subsystem
in a specific SPG
• IMMCT is the entry command for SPS
• INMCT is the entry command for FMS
• IMLCT is the entry command for MCS/DCS/RMS/STS
• Commands given in normal mode are sent to the CP from the SP
• Commands given in local mode, are not sent to the CP, but are handled
directly by the SP
148 R1B
8. DCS Applications
Chapter Objectives
After completing this chapter the student will be familiar with:
• The structure of DCS with line units and ports
• The commands and HW implementation
• The interfaces and protocols supported in IOG 20
• How to define a terminal in the AXE system
• How to define a data link
Figure 8.1
Chapter Objectives
8.1 Introduction
This chapter describes the different functions of the data communication
subsystem, DCS. DCS functions are also described in the next chapter.
8.2 General on Data Communication

Before looking at DCS it may be a good idea to recap certain basic con-
cepts in data communication.
A data link is basically used to connect two computers together so that
data can be transferred between them.
A terminal connected to a computer is also connected via a type of data
link.
The communicating hardware in the computer/ terminal is called the phys-
ical interface.
The rules for addressing, establishing sessions, exchanging data and mes-
sages between computers is called a protocol.
The interfaces and protocols used depend to a certain extent on the type of
data transfer: Asynchronous or Synchronous.
Asynchronous transfer means that both ends of the transmission have
independent clocks (of the same frequency). The characters (or data) are
sent one by one with each character preceded by a start bit and followed by
a stop bit or bits. Most terminals (e.g. PC or WS) are asynchronous.
R1B 149
Synchronous transfer means that the transmission is controlled from the

sending end. The data is sent in packets of several bytes. These packets are
preceded by a number of synchronizing characters (flags) and some layer
specific overheads.
The predominant method of synchronous data transfer is in packet
switched networks. Here the data is packed into packets, each with an
address label, which are sent individually over the network. At the destina-
tion the packets are unpacked and the data reassembled to original form.
Standardized interfaces and protocols has been defined by ITU-T and
other standardization forums.
Data Terminal Equipment, DTE, is usually a terminal or a computer.
Data Circuit Terminating Equipment, DCE, is usually a network or a
modem.
8.3 The OSI Reference Model

A standard model for data communication has been defined by the Interna-
tional Standards Organization, ISO. This standard is called the OSI Refer-
ence Model, where OSI stands for Open Systems Intercommunication.
OSI is a logical structure in which the functions required for the data trans-
fer have been broken down into seven distinct layers each of which com-
municates with the corresponding layer at the remote end of the
connection. By protocol is meant the rules for the handshaking communi-
cation between the corresponding layers. A protocol may be implemented
on one layer or more.
The OSI model itself does not specify any protocols or interfaces.
The model with the seven layers is often referred to as the ‘OSI-stack’.
150 R1B
DCS Applications
USER USER
7 APPLICATION APPLICATION
6 PRESENTATION PRESENTATION
5 SESSION SESSION
4 TRANSPORT TRANSPORT
3 NETWORK NETWORK
2 LINK LINK
1 PHYSICAL PHYSICAL
PHYSICAL MEDIA
Figure 8.2
Open Systems Interconnection model
In the OSI model, the users (i.e. programs) at either end of the physical
connection are connected via the seven layers as shown in Figure 8.2. The
physical layer, is normally implemented in hardware only, but in some
cases - e.g. IOG 20 - software exists to support and supervise the hard-
ware. The other layers consist only of software.
Each layer performs specific functions and is independent of the other lay-
ers, apart from a well-defined interface to the layers directly above and
below. A layer can be changed without affecting the other layers, thus pro-
viding flexibility which, in turn, simplifies the interconnection of different
datacom systems.
R1B 151
USER A user data USER B
7 user data
APPLICATION APPLICATION
6 user data
PRESENTATION PRESENTATION
5
SESSION user data SESSION
4
TRANSPORT user data TRANSPORT
3
NETWORK user data NETWORK
2
LINK user data LINK
1
PHYSICAL user data PHYSICAL
Layer specific overhead
Figure 8.3
Sending of data or message from A to B
Each layer provides a service to the layer above. A message from a user
program arrives at layer 7 where control information is prefixed by the
protocol for use by layer 7 at the other end. The message with this addi-
tional data is sent on to layer 6 where more information is prefixed and
then the message is sent on to layer 5 and so on.
At the receiving end, the control information is removed by each corre-
sponding layer until the original message can be sent by level 7 to the
required user. The layers are thus transparent for the data being sent from
user to user.
Layers 1-4 are used to set up a path from one user to another - they are net-
work dependent. Layers 5-7 define and maintain the communication
between the users - they are application dependent.
Layer 7 functions as an interface between the user programs and the net-
work, i.e. it gives the user access to the network services. It is, as such, the
network communication program as seen from the user’s point of view.
8.4 General on DCS

DCS is used for three functions in the AXE system:
• terminal communication
• data link communication
• CPT link communication (in some APZ versions)
152 R1B
DCS Applications
Note that terminals may also be connected to an AXE exchange via MCS,
this in the case of terminals connected to EMRP.
Note that the CPT communication is not done via DCS but via RPS, for
some versions of APZ 211. Most versions of APZ 212 use DCS for CPT
communication.
CPT - Central Processor Test.
8.5 DCS concepts

The basic concepts in DCS are:
• Communication Module
• Line Module
• Line Unit
• Ports
8.5.1 Communication module

The Communication Module, CM, is a logical concept. The first node in
SPG identifies the CM, as follows:
SPG 0 node A = CM 1
SPG 1 node A = CM 17
The background to the CM numbering is the operating system. The operat-
ing system supports up to 96 nodes possibly including CM-1 to CM-16 in
SPG0. In AXE each SPG always has two nodes. The same effect can be
seen in the file system where each node has the same index as the CM.
The numbering of CMs is only important in one context: the CM number
is used when numbering the Line Units and the Ports to which the ATs
and data links are connected.
Node status is printed with command IMCSP:
:IMCSP;
SPG
0
NPAIR EXSB
1 A 1 WORKING NORMAL B 2 ISOLATED BLOCKED CORRUPT
END
R1B 153
The result printout includes the CM number corresponding to each node.

A node in an SPG is either executive or standby.
NP = CM-LM-LU-NP
PP = CM-LM-LU-PP
LU - Line Unit PP, NP - ports
HD3 drive HD2 drive
HD1 drive FD drive

Power
CPU60
VSA
RPV2
ESDCV
LUM
LUM
LUM
LUM
ALCPU
ALEXP
OD drive (5 1/4”)
Figure 8.4
DCS hardware
8.5.2 Line module

The Line Module, LM, could hardware-wise be compared to the physical
grouping of all LUMs located in the same node.
The line module is designated as CM-LM, where CM is the communica-
tion module of the A-node in the SPG.
The line module is LM=1 in the A-node and LM=2 in the B-node.
Example: the line module in the B-node of SPG1 is LM=17-2.
The LM has no status and there is no command for defining the LM in
IOG 20.
8.5.3 Line unit

The Line unit, LU, is implemented in the LUM board hardware. One line
unit is implemented in one or two LUM boards and controls one to four
ports. Each line unit contains a processor which loads its software from the
main store. The module LUCHAR79 is the software of the LUM.
A line unit can be redundant (twin) or non redundant (single).
Each node may have three or four line units depending on IOG 20 version.
The line units are designated as CM-LM-LU. Example: the third line unit
in the B-node of SPG1 is LU=17-2-3.
154 R1B
DCS Applications
Each line unit has its own VME-bus address. The address is the same as
the line unit index and is strapped on the LUM board. The only allowed
strapping addresses are 1, 2, 3 and 4 from left to right.
HD3 drive HD2 drive Line Units 1, 2, 3 and 4
HD1 drive FD drive

Power
CPU60
VSA
RPV2
ESDCV
LUM
LUM
LUM
LUM
ALCPU
ALEXP
OD drive (5 1/4”)
Figure 8.5
Line unit addressing
Command examples:
<IMLCT:SPG=2;
:ILLUI:LU=33-2-1,CHAR=79;
:END;
<IMLCT:SPG=0;
:ILLUI:LU=1-1-4,CHAR=79;
:END;
In the command examples above the line units 1 and 4, located in the B-
node of SPG2 and the A-node of SPG0 are defined. The line units are sin-
gle (non redundant).
A line unit can take the status:
• Working Executive or Standby - WO/EX, WO/SB
• Manually Blocked - MBL
• Hardware Blocked - HBL
• Conditionally Blocked - CBL
• Automatically Blocked - ABL
The status of the line units is printed with command ILLUP.
R1B 155
If a higher security is required the line unit may be defined as a twin (or
redundant) line unit.
SPG0 SPG0
Node A Node B
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
‘Y’-cable
Figure 8.6
Twin line unit
In a twin (or redundant) line unit, two line units in different nodes of one
SPG, are defined as one line unit. The purpose of having twin line units is
security. If something would malfunction in one node the traffic is auto-
matically switched over to the line unit in the other node. When the IOG
20 is started up, line units 1-1-1 and 1-1-2 are already twinned with the
line units 1-2-1 and 1-2-2 respectively.
Example: LU= 1-1-3 and LU=1-2-3 could be defined as being one twin
line unit.
Command example:
<IMLCT:SPG=0;
:ILLUI:LU=1-1-3,CHAR=79,TWIN;
:ILBLE:LU=1-1-3;
:ILBLE:LU=1-2-3;
:END;
In the command example above the logical line unit 1-1-3 is defined as
twin and the physical line units, 1-1-3 and 1-2-3 are deblocked.
156 R1B
DCS Applications
A logical line unit can be defined, as it can be seen above, deleted or

printed and is used when the ports are defined. Ports are always related to
the logical line unit, thus LU=1-1-3 should be used when defining ports in
the above example.
A physical line unit can be blocked or deblocked as it can be seen above
It is recommended, to always deblock first, the line unit located in the EX-
node.
8.5.4 Port
The ports of DCS implements the interface towards data links, terminals
or CPT.
The ports are implemented on daughter boards attached to the LUM board.
There are four kinds of daughter boards, implementing different communi-
cation interfaces, as below:
V V.24/V.35/V.36/X.21
G G.703 E0 (64Kbps)
E G.703 E1 (2Mbps)
T Ethernet ***
*** Note: The optional ethernet connection (“T”), is not introduced as an
orderable product at the first IOG 20 release.
Each LUM board holds four ports.
Mother Screws
board
Daughter
board
.
.
. . .
. .
.
Each daughter board
implements
one physical port
Figure 8.7
LUM board
R1B 157
The port concept is divided into:

• Single link port
• Logical link port
• network port
The concepts are partly overlapping.
A single link port, SLP, is a port located on a logical line unit (redundant
or not) with one logical link defined to it. A single link port is identified as
a network port (see below).
A logical link port, LLP, is a port to a logical link. There are one or more
logical links on a physical port. A logical link port is identified by
LLP=CM-LM-LU-PP-LLP. This type of port is only used for CPT ports.
A network port, NP, is a physical port with one or more logical links
defined to it. Single Link ports and Logical Link ports are Network ports.
A network port is identified by NP=CM-LM-LU-SLP or NP=CM-LM-
LU-PP-LLP.
Example: the port NP=17-1-4-4 is the fourth port of the line unit number e
in SPG1.
PP = 17-1-1-1
PP = 1-1-1-1
PP = 17-1-3-4
PP = 1-2-1-1
PP = 1-2-4-4 PP = 17-2-4-1
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
SPG0 SPG0 SPG1 SPG1

Node A Node B Node A Node B
Figure 8.8
Port designation SPG0, SPG1
When defining a port not only layer 1 but also the layer 2 and 3 character-
istics are specified. There are a number of different parameters related to
the three layers that may be modified for each port or link. The OPI ‘Sin-
gle Link Port, Initiate’ gives recommendations and explanations to all
158 R1B
DCS Applications
parameters. Each parameter is always given a default value when defining

the port.
Command example:
<IMLCT:SPG=0;
:ILSLI:NP=1-1-4-4,RATE=19200,PROT=X28/V24;
:ILSLC:NP=1-1-4-4,PAD=6-1&1-0;
:END;
In the command example above the single link port 1-1-4-4 is defined.
Note that the command uses parameter NP, network port, to identify the
SLP. The layer 1 hardware interface is V.24/V.28 and the baudrate is
19200 baud. X.28 and X.3 are used on layer 3. The packet assembly-disas-
sembly parameters 6 and 1 are given the values 1 and 0.
Command example:
<IMLCT:SPG=2;
:ILSLI:NP=33-1-2-1,RATE=2048000,PROT=X25DTE/V36;
:ILSLC:NP=33-1-2-1,TC=1-16;
:END;
In the command example above the single link port 33-1-2-1 is defined
with a baudrate of 2 Mbps. Layer 1 is a V.36 interface, layer 2 is HDLC/
LAPB and layer 3 is X.25 working as a Data Terminal Equipment. Logical
channels 1 to 16 are defined as two-way channels.
The ports are blocked and deblocked by commands ILBLI and ILBLE,
and removed by command ILSLR.
A port may have the following status:

• Working, WO
• Automatically block, AB
• Conditionally blocked, CB
• Manually blocked, MB
• Hardware blocked, HB
The port parameters and status are printed by command ILNPP.
Command example (CPT ports):
<IMLCT:SPG=0;
:ILLLI:PP=1-2-4-1,RATE=64000,PROT=SDLC/V36;
:ILLLI:NP=1-2-4-1-1,PROT=CPT/SDLC,ADDR=H’01;
:ILLLI:NP=1-2-4-1-2,PROT=CPT/SDLC,ADDR=H’86;
:ILLLI:NP=1-2-4-1-3,PROT=CPT/SDLC,ADDR=H’A9;
:ILLLI:NP=1-2-4-1-4,PROT=CPT/SDLC,ADDR=H’CD;
:
:ILLLC:PP=1-2-4-1,ACCESS=LEASED;
:END;
In the command example above the physical port 1-2-4-1 is defined with
baudrate 64 000 bit/s.
R1B 159
The logical link ports 1-2-4-1-1, 1-2-4-1-2, 1-2-4-1-3 and 1-2-4-1-4 are
defined SDLC interface. Layers 3 and above are controlled by the Central
Processor Test function.
Note that the command ILLLC may change the characteristics of the logi-
cal link ports or physical ports (related to CPT ports).
The ports are blocked and deblocked by commands ILLBI and ILLBE,
and removed by command ILLLR.
The status of logical link ports is printed by command ILNPP.
8.6 Implementation
Modules PORTADM, LME, CMMAN and LUMAN. Files CMFILE,
LUFILEx and PEFILEx on hard disk (x indicates the SPG number).
8.6.1 Layer 1, interfaces

The interfaces provide layer 1 in the OSI reference model. The communi-
cation protocols cover layers 2-7.
CPT SW (CPTASP) CP-SP communication
MCS FMS
Users in SP
7 ATP
Ericsson MTP FTAM
6 Presenation (6)
X.29
5 Session (5)
4 X.224 RFC1006
3 X.28/X.3 X.25
Network (3)
TCP/ IP
Data Link (2)
2 SDLC HDLC / LAPB
1 V.25 bis/V.28 V.24/V.28 V.36 V.35 X.21 E0 E1 Ethernet
V.24/V.28 V.25 bis/V.28

DCS
Asynchronous Synchronous
Figure 8.9
AXE IOG 20 protocols and interfaces
The following types of interface standards are supported in IOG 20:

Interface: Supported baudrates
Asynchronous transmission:
160 R1B
DCS Applications
ITU-T V.24/V.28 (EIA RS 232 C) 2400 - 57 600 bits/s

ITU-T V.25bis/V.28 2400 - 57 600 bits/s
Synchronous transmission:
ITU-T V.24/V.28 (EIA RS 232 C) 2400 - 57 600 bits/s
ITU-T V.35 2400 - 256 000 bits/s
ITU-T V.36 2400 - 2 048 000 bits/s
ITU-T V.25bis/V.28 2400 - 57 600 bits/s
ITU-T X.21 2400 - 2 048 000 bits/s
ITU-T G.703 E0 64 000 bits/s
ITU-T G.703 E1 2 048 000 bits/s
Ethernet 10 240 000 bits/s
V.24/V.28 interface is used for the connection of asynchronous ter

minals or other synchronous connections, either locally or
via modem. V.24 identifies the physical layout of the
connector (pins) and V.28 the electrical characteristics.
Implemented in V.24/V.35/V.36/X.21 INTERFACE
daughter board.
V.25bis/V.28 is for the connection of asynchronous or synchronous ter
minals via modem (dial-in/dial out procedures). V.25 bis
identifies the automatic calling and/or answering proce
dures and V.28 the electrical characteristics (V.24 circuits
are used).

daughter board.
V.35 Interface for interworking with V.35 modem.

daughter board.
V.36 Interface for interworking with V.36 modem.
daughter board.
X.21 X.21 interface is used for the connection of high speed
synchronous data links in public data networks

daughter board.
R1B 161
G.703 E0 is used for the connection of a 64 kbit/s PCM data link

over the PCM network. (After connection through a PCM
multiplexer the data occupies one channel in a 2 Mbit
PCM line and can be connected to GSD).
Implemented in G.703 E0 INTERFACE daughter
board.
G.703 E1 is used for the connection of a 2 Mbit/s PCM data link
over the PCM network.
Implemented in G.703 E1 INTERFACE daughter
board.
Ethernet is not introduced as an orderable product at the first
IOG 20 release.
8.6.2 Layer 2
Layer two in the OSI model is the Link layer. It provides reliable transfer
across the physical links. It establishes the beginning and the end of blocks
of data (with synchronisation), error detection and link flow control.
On layer2, three protocols are supported by the AXE system:

• SDLC (only for CPT ports)
• LAPB
• IP (Internet Protocol)
The Synchronous data link communication protocol, SDLC, is a stand-
ard which in AXE is only used with Central Processor Test, CPT.
The Link Access Procedure Balanced Mode protocol, LAPB. This pro-
tocol is used together with X.25. LAPB is similar to High Level Data Link
Control, HDLC.
8.6.3 Layer 3
Layer three in the OSI model is the network layer. Here AXE supports
three protocols:
• X.25
• X28/X.3
• TCP (Transport Control Protocol)
The X.25 protocol is a packet switching protocol used by Ericsson MTP
and FTAM.
Asynchronous terminals access the IOG 20 via protocols X.28/X.3. The
asynchronous data from a terminal uses the X.28 protocol to access a
Packet Assembly/Disassembly (PAD)-function based on X.3 protocol.
162 R1B
DCS Applications
8.6.4 Layer 4-7

Layers 4 to 7 implements the transport, session, presentation and applica-
tion layers (like MTP and FTAM).
A Session Port is a software protocol in DCS. Session ports can be

defined for the following protocols in AXE:
• X.224
• X.29
• Ericsson MTP
A session port is addressed by a network terminal number.
Command example:
:ILSPI:SP=MTP,NTN=9837648844;
In the example above the session port for accessing the Ericsson MTP pro-
tocol is given the address NTN=9837648844.
The session ports are printed with command ILSPP and removed with
command ILSPR.
Layers 4-7 implements the protocols X.29, ATP, X.224, Ericsson MTP,
and FTAM in IOG 20.
For file transfer to/from AXE the protocols Ericsson MTP and FTAM are
used.
For command/printout transfer over data link the Ericsson MTP proto-
col is used.
The locally connected terminals connects via Asynchronous Terminal Pro-
tocol, ATP. ATP is the protocol used to interpret the control characters
entered by the terminal operator during command sessions e.g.,<<CR>>,
<<ESC>>, EOT>>.
A number of applications use FTAM or MTP protocols for file transfer.
File Process Utility (FPU) uses Ericsson MTP or FTAM for file transfer.
Direct File Output (DFO) uses Ericsson MTP for file transfer.
8.7 Network Services

Many services are available, of which four will be discussed here:
• Addressing
• Routing
• Permanent/Hot Virtual Circuits and Direct Call
• Access/priority
R1B 163
8.7.1 Addressing
Basically, a network user is identified by a Network Terminal Number,
NTN.
An NTN could be compared to a telephone number in the telephone net-
work. Each country has its own numbering plan for NTN, just as they have
for telephone numbers.
An NTN has up to 15 digits, including of the prefix, called Number Direc-
tion, ND, which corresponds to the area code in the telephone network:
NTN =ND + internal digits
Data network Computer

nodes NTN=65392
NTN=9873
NTN=905
NTN=94
Terminating function,
example X.29 or MTP
NTN=830968 Alphanumeric terminal
Figure 8.10
Addressing in data network
Structured number plans are used with routing cases and routes as in the
case of the B-Number Analysis tables for telephone traffic. The DCS digit
analysis may be compared to the B-number analysis table in TCS, where
the Origin for digit analysis, ODA, is the equivalent to the B-number ori-
gin, BO.
All ports in IOG 20 used for connection of AT devices are assigned net-
work terminal numbers.
Selection by name is an optional facility within the addressing service. By
this function, a name-to-address conversion facility allows the use of a
name, consisting of an alphanumerical identifier, instead of the NTN in the
selection information.
164 R1B
DCS Applications
The indicated name is translated into an NTN in a table common to all

users connected to the IOG. The table is created and modified by operator
commands.
FPU destination. When File Process Utility uses a data link it identifies
the data link by a destination. This destination is defined by command
INFDI and may be of equipment type MTP or FTAM, defining the proto-
col to be used. The destination is translated to a NTN number, it’s a one-
to-one relation, with command ILDNI. The relation is printed with com-
mand ILDNP.
Traffic Direction, TRD. This concept is used for statistics purposes. It is
similar to the concept off Traffic Destination, TRD, in TCS. The traffic
direction is a figure that is defined to identify a certain area or destination
in the data network.
Command example:
:ILTDI:TRD=150,ODA=6,ND=76;
The definitions are removed with ILTDR.
Example of number analysis:
DCS DIGIT ANALYSIS
ODA=0
ND
1011101 DTE NP= 1- 1- 1- 1

1011102 DTE NP= 1- 1- 1- 2
1011103 DTE NP= 1- 1- 1- 3
1011203 DTE NP= 1- 1- 2- 3
1011204 DTE NP= 1- 1- 2- 4
1012101 DTE NP= 1- 2- 1- 1
.....
1012104 DTE NP= 1- 2- 1- 4
1015100 X29
1015200 MTP
ODA=6
ND
7631 NEWODA= 0
7632 NEWODA= 0
7633 NEWODA= 0
7634 RC=127
7635 RC=127
....
7638 RC=127
7639 RC=127
ODA=99
ND
R1B 165
76 NEWODA= 6
END
Command descriptions:
ILRAI The command defines number analysis data for a
given number direction, ND.
ILDAP The command gives a printout of number analysis
data for one or all number directions.
ILNAI The command is used to define a name for a pre-
defined NTN and insert the name and NTN in the
addressing by name analysis.
ILNAP The command is used to print the addressing by
name analysis data.
ILDNI Destination to network terminal relation.
ILDNP Destination to network terminal relation.
ILTEI Assigns a NTN to a network port, dedicated line.
ILTEP Prints NTN and terminals.
8.7.2 Routing
Routing of switched data traffic through the network is based on the NTN
address described above. The NTN is used to access a remote user, or a
name can be used if the selection by name facility is used.
The NTN is first analysed in the called address number analysis. The anal-
ysis is carried out by means of the number direction, ND, and indicates if
the called NTN is locally defined (terminating) or has to be reached by an
outgoing route. See fig. 9.11.
166 R1B
DCS Applications
Computer
Computer NTN=65392
NTN=42
ROT=76
ROT=75
ND=653:
RC=9, ROT=76, NP=1-2-3-1
ROT=75, NP=1-1-4-4
Figure 8.11
DCS routing
In the former case, the called NTN can correspond to either a terminal
reached by a dedicated line connected to a local Network Port in the
packet switch or to an internal software function within the packet switch.
In the latter case, a routing case, RC, is indicated. Each RC corresponds
to a unique destination directly connected to the own exchange, i.e. packet
switch. Each RC contains a list of routes toward the given destination.
Each route is identified by a routing number, ROT.
A routing case should include at least two routes. The first route defined in
the list is the primary. The other routes are alternative routes in case a call
cannot be established over the primary route.
A route may use one or several physical circuits, i.e. physical ports with
data links. To each route we thus define the network ports corresponding
to the data links in the route. A route should have at least two ports
defined. For a given route, the ports are chosen in the order that they are
defined.
After the called address, RC and route analyses, an idle network port is
thus chosen for the call. The destination (called) NTN complete with ND
is inserted by the network layer protocol into the message, together with
the calling NTN and sent on into the network.
The analysis can now be repeated at each switch in the network until the
final analysis at the terminating switch.
To define the data tables required for the analysis, the following com-
mands are used:
R1B 167
ILROI The command defines a new route and inserts one

or more network ports into the route. It also inserts
network ports into an existing route.
ILROC The command is used to change route data for an
existing route.
ILROP The command is used to print route data.
ILROR Removal of route data.
ILRCI The command defines a routing case with its asso-
ciated routes.
ILRCP The command prints routing cases.
ILRCR Removal of routing cases.
The OPI to be used when defining, changing or removing routing data is
"DCS Address and Routing Analysis, Initiate".
Modules CALLCONTROL/NETMAN handles the routing analysis and
module PSSADM handles the commands for defining and printing of
address and routing analysis data.
8.7.3 Permanent/Hot Virtual Circuits and Direct Calls

A Permanent Virtual Circuit, PVC, is a circuit set up between two net
work ports, NP.
A PVC is, as the name implies, a virtual circuit that is always connected
between predefined users through the CM.
A Hot Virtual Circuit, HVC, is a circuit set up between a network port,
NP, and a session port.
A HVC is a virtual circuit that is connected automatically between pre-
defined users only when one of the users wants to use the circuit (compare
Hotline).
168 R1B
DCS Applications
IOG20
X.29,
NTN=1015100
Hot virtual circuit
X.28/X.3 AT-7
NTN=1012104
V.24 physical interface
Figure 8.12
Hot virtual circuit
Command example:
:ILPCI:NTNA=1012104,NTNB=1015100;
In the example above the network terminal number 1012104, which repre-
sents a terminal is connected to the network terminal number 1015100,
which represents the X.29 protocol in IOG 20. Each time a terminal sets
up a call towards DCS, i.e. when the operator starts using the terminal, a
connection will be established to the X.29 protocol. From there on the data
sent from the AT will be switched further on to the Asynchronous Termi-
nal Protocol OSI layer 7, and then passed on to MCS.
The circuits are printed with command ILPCP and removed with com-
mand ILPCR.
An example of a Hot Virtual Circuit is found in the definition of a port for
connection of an alphanumeric terminal. The network port and associated
X.28/X.3 protocols have to be connected to the Session Port X.29.
Direct call. The direct call function enables the setting up of a Switched
Virtual Circuit, SVC. The function assigns a B-side address (command
parameter DCALL) to the A-side address (command parameter NTN).
Command example:
:ILDII:NTN=9873562,DCALL=2984655;
The direct call function is removed from a certain NTN by command
ILDIR and printed with command ILTEP.
R1B 169
8.7.4 Access control

The access control may be incoming or outgoing calls from a certain
address (NTN). It is also controls the priority of the data calls.
Command example:
:ILACC:NTN=763539,PRI=3-4;
In the example above, calls from NTN=763539 are given the default prior-
ity 3 and the maximum priority 4. The priority ranges from 1 to 4.
Command example:
:ILACC:NTN=82,ICB=YES;
In the example above the incoming calls are barred to NTN=82.
The access control is printed with command ILACP.
8.7.5 Dedicated Lines

It should be noted that not all traffic is switched through the network using
routing functions.
In some cases, the data link is connected instead as a dedicated line - a
fixed direct line between the two ends (usually called ‘leased lines’ when
hired from a network operator).
This type of link thus uses a dedicated line connecting two so called stati-
cally allocated ports (if such a link was using PCM media - or was con-
verted to PCM at an AXE exchange - then the link would be
semi-permanently connected through the digital group switch).
In this simpler case, instead of performing route analysis to obtain the Net-
work Port for a suitable data link, the home switch must obtain the
required port in some other way. As every destination is identified by its
unique NTN, it follows that a relationship must be defined between the
destination NTN and the required port in the home switch.
When data is to be sent, the destination NTN will be specified - as in the
case with switching - but as no route analysis data exists for this address,
the NTN will now simply point to the Network Port at which the required
data link is connected.
Data sent via this port will arrive automatically at the required destination.
In an IOG 20, the relationship between destination NTN and home port is
defined by the command ILTEI. In effect, by this command, the home
Network Port is assigned the NTN of the required destination.
8.8 Connection of DCS ports

The procedure for the definition of an Alphanumeric Terminal, AT, is
described below. The definition of an alphanumeric terminal involves both
subsystems MCS and DCS and is performed both in CP and SP.
170 R1B
DCS Applications
In order to define a port, a series of commands must be given. The proce-

dure differs somewhat depending on whether the port is to be defined for
1) alphanumeric terminal, AT, or 2) data link.
In case 1) it should be realized that the AT can be located remotely at an
OMC and access the IOG via modems over leased lines or via a circuit
switched data network using secure access control such as user groups
(e.g. X.21 protocol). The port is still defined for an alphanumeric termi-
nal accessing X.28 protocol. The device is type AT, i.e. IO=AT-n.
In case 2) when a port is defined as being for a data link this implies a link
using X.25 protocol in the packet switched network. Such a data link can
be used for alphanumeric or file transport.
When used for alphanumeric transport, the device type in the exchange is
the data link itself and must be specified as AMTP (Alphanumeric com-
munication using MTP) in the relevant commands, i.e. IO=AMTP-n.
When defining a port the command parameters refer sometimes to (NP)
and sometimes to (PP). This depends on whether the action performed by
the command refers to the logical entity (NP) or the physical entity (PP).
As four ports is the maximum that is allowed per LU, it may also be neces-
sary at some stage to define a new Line Unit.
8.8.1 General
After initial start of IOG 20 line units 1-1-1 and 1-1-2 are already defined
and twinned with the line units 1-2-1 and 1-2-2 respectively. Further LUs
can be defined in the Data Transcript loaded after start up of the CP. The
number of LUs defined depends on the number required by the customer.
The ports 1-1-1-1, 1-1-1-2, 1-1-2-1 and 1-1-2-2 are defined in the initial
data. More ports can be defined in the DT at the requirement of the cus-
tomer.
These defined ports correspond to:

• AT-0, the alarm printer, 4800 bits/s
• AT-1, the alarm interface, 2400 bits/s
• AT-4, an AT device defined for 9600 bits/s
• AT-5, an AT device defined for 19200 bits/s.
8.9 Definition of Port for AT

To define a port for an AT the OPI: ‘Alphanumeric Terminal in SPG,
Connect’ should be followed. This OPI in turn refers to other OPIs.
8.9.1 Line Unit

Command example:
<IMLCT:SPG=0;
:ILLUP:LU=CM-LM-LU;
R1B 171
Check the line unit status. If the LU required is not defined, define it.
8.9.2 Network port

Command example:
:ILSLI:NP=np,RATE=rate,PROT=X28/V24;
The port is defined with protocol X.28/X.3 and physical interface V.24/
V.28.
The default values for the X.3 transmission parameters assigned to the port
on definition are printed. (The bit rate value assigned by command ILSLI
is marked with an ‘*’ in the text and shall not be altered).
:ILNPP:NP=np,DETAIL;
The actual values are obtained with command ILNPP with parameter
DETAIL for a given existing port.
:ILSLC:NP=np,PAD=pad,PRIV=priv;
The default values of the packed-assembly-disassembly, PAD, and private
PRIV parameters are changed.
8.9.3 Test of port

The Physical Port is now tested using one of three possible loop tests
according to the OPI.
Loop 1 is used to test the internal DCS path as far as the port, i.e. when no
data link is connected.
:ILLTI:PORT=pp,LOOP=1;
8.9.4 Network Terminal Number

The next step is to assign a Network Terminal Number, NTN, to the net-
work port.
172 R1B
DCS Applications
NP = 1 - 1 - 4 - 1 NTN = 1 01 1 4 01
NP, PP
Line unit
Line module
Communication module
Always ‘1’
NP = 1 - 2 - 3 - 4 NTN = 1 01 2 3 04
NP, PP
Line unit
Line module
Communication module
Always ‘1’
Figure 8.13
Network terminal number convention
For ports defined for ATs, the value for parameter NTN consists of seven
digits and is constructed according to Figure 8.13. Note that this is the
internal number within the own IOG. (NTNs used for accessing remote
destinations over data links are constructed differently, as mentioned ear-
lier in the section on addressing).
:ILTEI:NTN=ntn,NP=np;
8.9.5 Deblock the Port

The next step is to deblock the NP. The port was manually blocked but
now becomes automatically blocked as no AT is connected.
:ILBLE:NP=np;
The connection of the AT to the packet switched network via X.28/X.3/
X.29 protocols has been covered above. The relevant diagram is given in
Figure 8.9.
8.9.6 Hot virtual circuit to X.29 Protocol

The Network Port has now to be linked to the X.29 protocol (Session Port)
via a Hot Virtual Circuit.
First the pre-defined NTN for the X.29 protocol has to be determined by a
printout:
:ILSPP;
Check which address (NTN) is assigned to the X.29 session port.
:ILPCI:NTNA=ntna,NTNB=ntnb;
R1B 173
The connection is now made between the NP (NTNA) and the SP (NTNB)
by the command ILPCI.
8.9.7 Insertion in User and Communication Directories

The terminal to be connected to the port must now be inserted in the two
MCS directories User and Communication.
In the Communication Directory the entry name (e.g. TNTN) for the ter-
minal and the NTN for the port are registered, together with data indicat-
ing that automatic logon is to take place on the terminal. Session
supervision and printout queuing are also defined.
In the User Directory the entry name (TNTN) and authority E for the ter-
minal is entered.
This procedure is followed below. The NTN of the port is assumed to be
1011203.
Insertion of a terminal in Communication Directory:
:MCDCI:DIR=COM,NAME=T1011203,NTN=1011203,
Insertion of a terminal in User Directory:
:MCDCI:DIR=USER,NAME=T1011203,AUTH=E;
Check the entries:
:MCDCP:DIR=COM;
:MCDCP:DIR=USER;
Deblock the entries:
:MCDBE:DIR=COM,NAME=T1011203;
:MCDBE:DIR=USER,NAME=T1011203;
IOG local mode operators are also registered separately in the User Direc-
tory. Authority EFH is the normal command authority given to local mode
users. (No entry is required in the Communication Directory).
8.9.8 Connect Terminal to NTN

The identity of the terminal to be connected to the NTN is defined:
:MCDVI:IO=AT-n,NTN=1011203;
:END;
8.9.9 Size Alteration Events

Check SAE 344 (Records in block ASCP = the number of session chan-
nels toward DCS for alpha terminals, i.e. the number of simultaneous com-
mand/printout sessions required).
<SAAEP:SAE=344;
If necessary, increase the size:
174 R1B
DCS Applications
<SAAII:SAE=344,NI=ni;
Check the IO device data records in the CP:
<SAAEP:SAE=800,BLOCK=AT;
<SAAII:SAE=800,BLOCK=AT,NI=ni;
8.9.10 Define the IO device data in the CP

<IOIOI:IO=AT-n;
8.10 Definition of Port for X.25 Data Link

The definition of a port for an X.25 data link is done in a similar manner to
that for an alpha terminal given above. However, several new commands
are required for data link ports, while - as shown below - the IO device
related commands are not required for file transfer applications.
Note that data links may be defined in SPG0, SPG1, SPG2 and SPG3
while alphanumeric terminals may be defined in SPG0 only.
In the procedure followed below, a port is to be defined in the IOG at the
exchange for an X.25 data link connected to an Operation & Maintenance
Centre (OMC).
At the OMC the link can terminate in an IO device or an AOM (a commu-
nication computer which switches between different exchanges) or some
other such device. These would normally be used for alphanumeric com-
munication, but could also be used for receiving files.
The link could also terminate in another computer (including an SP-based
IO system) used for sending/receiving files over the link. Whatever type of
DTE was used at the OMC, however, it would have to contain software for
X.25 and Ericsson MTP or FTAM protocols in OSI layers 2-7.
In the case described below, the link will terminate at an AOM in the
OMC.
Whatever type of equipment exists at the OMC, an address (NTN) must
exist there so that a path can be established to it from the IOG 20 at the
exchange. The same is true in the opposite direction.
As stated earlier, traffic over X.25 data links is either switched through the
data network - analysis of the destination NTN being used to route and set
up a path through the net - or sent via a dedicated line, using the destina-
tion NTN to directly point out the required Network Port in the home
switch.
In the case described below, the port defined will be for a data link of the
dedicated line type. This method requires that the NTN assigned to the
Network Port in the home IOG is the destination NTN. This is done using
command ILTEI.
R1B 175
In our case, the destination is the Session Port for Message Transfer Pro-
tocol (MTP) at the OMC. Each Session Port in a network is given its own
NTN. In IOG 20 this is done by use of the command ILSPI. At the desti-
nation AOM it would be defined using an AOM command.
Session port Computer

MTP NTN=150
NTN=250
ROT=1
IOG20
ROT=2
Routing in IOG20:
ND=15,RC=1
ROT=1
ROT=2 AMTP-n
Figure 8.14
Addressing in data network
For traffic in the opposite direction, it follows that, at the OMC, the Net-
work Port for the data link must be assigned the NTN of the MTP Session
Port at the home IOG.
The port defined below is a port in the home IOG. It will be a low speed
link: 19200 bit/s. The port is a single link port, SLP.
A corresponding Network Port must be defined in the DTE at the OMC,
using AOM commands.
Several OPIs exist for connection of data links to an IOG 20.
The connection below is performed in accordance with the OPI ‘ OMC
Using Message Transfer Protocol, Connect’
8.10.1 Line Unit Status

<IMLCT:SPG=spg;
:ILLUP:LU=ALL;
If the LU required is not defined, define it.
8.10.2 Define the Port

Command example:
176 R1B
DCS Applications
:ILSLI:NP=np,RATE=rate,PROT=X25/V36;
The port is defined using protocol X.25 and interface V.36.
:ILNPP:NP=np,DETAIL;
:ILSLC:NP=np,TC=1-64;
All channels are defined as two-way channels.
X.25 data links contain many separate channels where each user is given
its own channel. TC: Interval range for the number of two way logical
channels - i.e. separate communication channels - in the link. Maximum
4095 separate channels can exist in the one link.
8.10.3 Test the port

The physical port is now tested.
:ILLTI:PORT=pp,LOOP=1;
8.10.4 Network Terminal Number

As no switching to the destination exists in this case, the next step is to
assign the NTN of the destination (SP for MTP) to the Network Port. For
this example, assume this value is 150.
:ILTEI:NTN=150,NP=np;
(Note: the actual value of the destination NTN, if unknown, must be
obtained from the staff at the OMC.) This example is using a dedicated
line, not via routing data.
8.10.5 Deblock the Port

:ILBLE:NP=np;
8.10.6 Define the MTP Session Port

In this example, this NTN in the home IOG is assumed to be 250 as in Fig-
ure 8.14.
Check if the Session Port for MTP in home IOG is defined.
:ILSPP;
:ILSPI:SP=MTP,NTN=250;
The Network Port for the data link at the destination would now be
assigned this value using the relevant AOM command.
The next step depends on whether the data link is to be used for alphanu-
meric communication, file transfer or Direct File Output.
The first two cases are covered here. For the case Direct File Output see
the corresponding OPI.
R1B 177
8.10.7 Data Link used for Alphanumeric Communication:

(Compare the definition of a port for alphanumeric devices described
above.)
8.10.8 Assign Terminal Identity to the Port

The IO device associated with the port is defined. Here, the IO device is of
type AMTP as it is an X.25 data link accessing MTP protocol with alpha-
numeric information. (AMTP - Alphanumeric communication using
MTP.) The command links the IO device to the Network Port’s NTN.
:MCDVI:IO=AMTP-n,NTN=150;
:END;
8.10.9 Size Alteration Events

<SAAEP:SAE=344;
<SAAII:SAE=344,NI=ni;
8.10.10 Define the IO device data in the CP

<IOIOI:IO=AMTP-n;
8.10.11 Route alarm status information and heart beat to OMC

The system alarm status printout (category 47) is sent to inform the OMC
about alarm status and operator attendance at the exchange.
Heart beat printouts, with category 35, are sent to the OMC from the CP to
indicate that the CP is functioning normally.
In the command IOROL, IO is the data link, AMTP. DTYPE=FIRST and
NOSYST must be used. This implies that no standby nor system standby
device (AT, AMTP or AF) may be used for alarm status and heart beat
signals.
<IOROL:PRCA=35&47,IO=AMTP-n,DTYPE=FIRST,NOSYST,
CLASSA=0&1,CLASSUA=0&1;
<IOROI:PRCA=35&47;
8.10.12 Data Link used for File Transfer

If the data link is to be used for file transfer then the IO device commands
given above (i.e. Data Link used for Alpha Communication) beginning
with command MCDVI are not required. After the command ILSPI the
sequence is as follows:
Initiate the Destination-Remote NTN relationship for the port
The destination must be connected to the NTN for the remote user (here
MTP) accessed via the data link.
<IMCLT:SPG=spg;
:ILDNI:DEST=dest,NTN=150;
178 R1B
DCS Applications
Using destination name (DEST) to get the destination NTN, the file is then
- in our example - sent on a dedicated line directly to the OMC from a port
having the same NTN as the destination.
If the destination AOM was to be reached by routing through the network
the following routing data would have to be defined as follows.
The NP in the home IOG is NP=1-2-2-1.
Define route:
<IMLCT:SPG=0;
:ILROI:NP=1-2-2-1,ROT=1;
Define routing case:
:ILRCI:ROT=1,RC=1;
Define Number Direction for Routing Case:
:ILRAI:ND=15,RC=1;
The file would now be routed through the network to destination in the
ILDNI command.

• The main functions in DCS are the terminal, data link and the CPT link
communication
• The basic concepts in DCS are the Ports, the Line Units, the Line Mod-
ule and the Communication Module
• Four ports can be connected to a LUM board
• The LU can be defined as Single or Twin Line Unit
• The recommendations of the OSI Reference Model are followed
• The following interface standards are supported in IOG 20: V.24/V.28,
V.25bis/V.28, V.35, V.36, X.21, G.703 E0, and G.703E1
• The maximum speed for data transfer via Data Link is 2Mbit/s
• The main Network Services are: Permanent/Hot Virtual Circuits and
Direct Call, Addressing, Routing and Access/Priority
R1B 179
180 R1B
9. Support Processor Subsystem
(SPS)
Chapter Objectives
• Know the hardware units included in SPS
Figure 9.1
Chapter Objectives
9.1 Introduction
This chapter describes functions in the support processor subsystem.
9.2 General
SPS is central to the work of the IOG in that SPS software implements the
program control of the Support Processor, the SP-CP communication
function and nearly all the maintenance functions for the SPG.
SPS has been looked at briefly in chapter two and three where the hard-
ware of the subsystem was described. In this chapter the above mentioned
software functions of SPS will be looked at in some detail. A brief recap of
chapter two is given first.
SPS consists of:

• the SPs with their operating system software
• software and hardware for SP-CP communication
• software and hardware for inter-node communication
• software for the SP function change and backup
• software for maintenance of the nodes and links
• software for SP operation functions
9.3 The Hardware of SPS

The hardware consists of the CPU60, and the RPV or RPV2.
The CPU60 implements the support processor. It is built of the CPU60
board. The board contains, among other things, a MC68060 processor, 32
MB of DRAM, a boot PROM and interface circuits.
R1B 181
At loading or reloading of an SP, the PROM-stored boot strap program

(called Bootstrap) is used to initiate loading of the SP operating system
and software into the primary memory of the SP from the hard disk.
The RPV, or RPV2, is the interface unit between the RP bus and the SP.
It contains a microprocessor, primary memory and boot software stored in
a PROM. The software for the RPV, or RPV2, is stored on hard disk and
read to the RPV/RPV2 at power on.
The RPV is implemented in the boards PROVME and DRPBU.
The RPV2 is implemented in board RPV2.
The main function of the RPV is to send and receive RP signals to and
from the CP and SP. CP-SP signalling will be looked at in chapter 10,
CP-SP Communication.
9.4 The Software Functions of SPS

The SPS software is situated in both the CP, SP and RPV/RPV2. In the SP
the software of SPS and the other subsystems consists of a series of Eri-
Pascal modules. The modules are often grouped into function blocks.
The software in the RPV/RP2 is written in C.
The SPS software functions are listed below:

• system kernel (system executive)
• SP hardware administration
• loading function
• node communication
• SP statistics
• maintenance functions
• SPS event log
• SP exchange data administration
• SP function change and SP software module handling
• SP trace system
• SP hardware administration
• SP restart log
• SP system parameter Handling
• SP co-processor dump
The system kernel administers the program execution in the SP.
The tasks of this function include supervision of signals between the dif-
ferent processes contained in the program modules, time supervision for
sending periodic signals, and administration of the primary memory.
182 R1B
Support Processor Subsystem (SPS)
Loading of SP modules from hard disk, starting of the software system and
restarts of SP software are also handled by the system executive.
The kernel is part of the EriOS.
SP HW administration administers devices connected to the SP such as
hard disks, flexible disks, etc.
Before an application program (e.g. in CHS) can perform any operations -
reading/writing on hard disk - the device administrator must be informed.
(Note that alphanumeric devices and data links are handled by subsystems
MCS and DCS).
Loading function is a complement to the PROM-stored bootstrap and the
loading function in the system kernel mentioned above. Briefly, it allows
modules to be designated as external so that they are only loaded from HD
to the primary memory when required.
The loading function is a part of EriOS.
Node communication is the function that supports the distribution of the
control system into two separate SPs (node A and B). It allows application
software functions to be partly located in one node, partly in the other, or
to be wholly located in both nodes.
The application processes can communicate via the Inter Computer Bus,
ICB. This function is implemented in both HW (on CPU60) and SW in
function block ENCS, Ethernet Network Communication System.
CP-SP communication will be covered separately in chapter 12.
SP statistics, Maintenance functions and SPS event log will be covered
separately in chapter 13.
SP exchange data administration, SP function change and SP software
module handling (including SP Backup) will be covered separately in
chapter 14.
The remaining functions are covered below.
9.5 SP Hardware Administration
9.5.1 General
The SP hardware administration function keeps a list of some of the hard-
ware installed in an SPG. This information is required by the HW driver
programs for operation and maintenance of each node.
9.5.2 The SP Hardware Table

The SP Hardware Table contains data for the hardware configuration in
the node. There is one table for each node.
Example of an SP hardware table:
:IMHWP:NODE=A;
R1B 183
SP HARDWARE DATA
SPG NODE
0 A
UNIT NAME ADDR DESCR SPARE INDEX UFIELD

VD-1 ACIA 25 STD **** 1 T..113
NA-1 BNA 00FA **** 1 ------
HD-1 DISK_SC **** 1 H31001
OD-1 DISK_SC **** 4 O14001
CONFIG-1 CONFIGURATIO **** 1 IOG20
WSU-1 MEMORY WSU **** 1 32
SCSI-1 SCSI **** 3 5
FD-1 FDC **** 1 1 11F
FDI-1 FDI **** 1 1
FDIADM-1 FDIADM **** 1 1
VSA-1 EBA_VSA **** 1 1
END
The hardware table is loaded to the primary memory when the modules are
loaded from PROG_A or PROG_B at node reload. The hardware driver
programs in each node read the data in the table at each reload to find out
which, and how many, hardware units they have to drive.
The information in the hardware table is of special use to the driver pro-
grams during diagnostics and repair checks, when carrying out orders for
hardware tests. This will be covered in chapter 13 in the section on SP
diagnostics.
The hardware table may need to be changed from time to time, as and
when units are added to, or removed from, the node. This has to be done
by operator command. Each time a change has been made in the hardware
table, the node has to be reloaded to get the new table into the primary
memory.
The data in the hardware table for each unit is fairly complex and this
leads to an unusually complex command format. Therefore, to simplify the
handling of the table, a set of default data is already defined for each unit.
Thus, when making changes in the hardware table, only the name of the
unit has to be given. The rest of the data is fetched from the default data.
The default data is stored in a second table: the SP Hardware Default
Table.
9.5.3 SP Hardware Default Table

This table is created from the data in the module SPHWTABLE by the
module SPHWADM the first time it receives one of the HW administra-
tion commands. The default table is then stored in the volume OMFZLI-
BORD.
184 R1B
Command
Hard disk IMHWP
A-node Volume Volume
PROG_A OMFZLIBORD
Default SP HW SP HW
SP HW table table
table
Primary Commands
memory IMHWI,
A-node IMHWC
Executing
SP HW
table
Figure 9.2
SP hardware table
At start up of an SPG, the hardware tables for each node and the default
table are thus identical. Those units that are not included in the actual
nodes must be removed from the hardware tables.
Thus in a working IOG20, the default table has the same format as the
hardware tables, but normally contains data about more units than those
found in the hardware tables. It contains default information for all possi-
ble units in the IOG20.
Default SP hardware data:
SP HARDWARE DATA
SPG NODE
0 A
UNIT NAME ADDR DESCR SPARE INDEX UFIELD

VD-1 ACIA 25 STD **** 1 T..113
NA-1 BNA 00FA **** 1 ------
HD-1 DISK_SC **** 1 H31001
HD-2 DISK_SC **** 1 H31002
HD-3 DISK_SC **** 1 H31003
OD-1 DISK_SC **** 4 O14001
CONFIG-1 CONFIGURATIO **** 1 IOG20
WSU-1 MEMORY WSU **** 1 32
SCSI-1 SCSI **** 3 5
FD-1 FDC **** 1 1 11F
R1B 185
FDI-1 FDI **** 1 1

FDIADM-1 FDIADM **** 1 1
VSA-1 EBA_VSA **** 1 1
END
A simple printout of the hardware connected is obtained in the IO UNIT
MODES printout from command INIOP. The printout lists the units in the
node an their status (parameter OPMODE). The status may be READY or
BLOCKED. The status is controlled automatically by the system or by
commands BLSUI and BLSUE.
IO units:
:INIOP:NODE=A;
IO UNIT MODES
SPG
0
NODE UNIT OPMODE

A VD-1 READY
A RPV-1 READY
A HD-1 READY
A NA-1 READY
A FD-1 READY
A OD-1 READY
END
9.5.4 Operation
When the SPG is started, the hardware table must first be changed to
match the actual configuration. All changes in the hardware and hardware
default tables are made by commands. The procedures to be used are given
in the OPI: ‘Hardware in SP, Administration’.
The commands used are fully allocated in the SP and are assigned to the
path building command IMLCT.
To remove a hardware unit, e.g. OD-1, then the command IMHWR is used:
:IMHWR:NODE=B,UNIT=OD-1;
At a later stage it may be decided to add HD-3 to each node. Data for these
must be added to the hardware table for each node.
To add a new hardware unit or units, e.g. HD-3, the command IMHWI is
used:
:IMHWI:NODE=A,UNIT=HD-3;
After the command IMHWI a reload must be initiated in the influenced
node.
186 R1B
To print the data defined in the hardware table for a given node, the com-
mand IMHWP is used:
:IMHWP:NODE=A;
This gives the printout SP HARDWARE DATA, see Figure 9.2 for an
example.
It may happen that a new unit that does not have any data defined in the
module SPHWADM has to be added to the SPG. This means that no data
for the unit exists in the hardware default table.
The command IMHWI cannot be used alone in this case. If given, the com-
mand will result in a fault code and printout UNIT NOT DEFINED. This
means that the unit has to be defined first in the default table.
To define a unit in the default table the command IMHWL is used. The def-
inition is rather complex because of the nature of the data. However, it
should be remembered that this command is only given very rarely, and if
the command is needed the parameters would be supplied to site by Erics-
son together with the hardware unit(s).
After the command IMHWL has been given successfully, the command
IMHWI can then be given.
A more likely case than the above is the case of the default data for a unit
being incorrect and having to be changed, or when a unit is replaced by a
unit with different data. Changes to the data in the default table are made
by the command IMHWC. The parameters are the same as for the command
IMHWL and would be supplied by Ericsson.
An example is given below:
: IMHWC:NODE=A,UNIT=HD-3,NAME="DISK_SC",
UFIELD="H31001",INDEX=3;
Here, the default data for HD-3 has been changed.
An explanation of the parameters is given in the command descriptions
and the adaptation direction in the B-module. The adaptation direction is a
key document when defining the SP Hardware table.
The function is handled by the function block SPHWADM which consists
of two modules: SPHWADM and SPHWTABLE.
The module SPHWADM administers the function. The module SPH-
WTABLE contains a table called the SP Hardware Table. This table thus
exists in the primary memory and in the volumes PROG_A and PROG_B
on the hard disks. The module SPHWTABLE also contains an interface
that enables reading and writing in the table on hard disk.
The files SPHWADAPT0 and SPHWUNITS0 in volume OMFZLIBORD
are used to store the SP hardware table in SPG0. The last character in the
file name identifies the SPG.
R1B 187
9.6 Chapter Summary

• The hardware in SPS consists of the CPU60 and RPV or RPV2.
• Some of the main SPS software functions are: system kernel, loading
administration, node and CP-SP communication, maintenance func-
tions, SPS event log, SP exchange data administration, etc.
• The SP Hardware Administration function keeps a list of the hardware
installed in a SPG.
• The SP Hardware Table contains data of the hardware configuration in
the node.
• The SP Hardware Default Table is created automatically by
SPHWADM the first time it receives one of the hardware administra-
tion commands, and is stored in volume OMFZLIBORD.
• At start-up of an SPG, the hardware tables for each node and the default
table are identical.
188 R1B
10.Start of SPG
Chapter Objectives
• List the different parts of the software package required at startup
of an SPG
• Carry out a cold start of an SPG using OPI ‘SPG, Start’
Figure 10.1
Chapter Objectives
10.1 Introduction
This chapter describes the procedure and functions of the initial startup of
the AXE IO system.
10.2 General
Once all hardware has been installed in the exchange and the cabling con-
nected and tested then the first step in starting up the exchange is the start-
ing of the IOG20. Once this is running then the APZ can be started using
the functions of the IOG.
Starting an IOG20 implies starting up the nodes of each SPG in the IOG.
Note: Start of an SPG involves function change procedures. This chapter
has been written to be sufficient for an understanding of function change at
start up of an SPG. Function change is covered in more detail in chapter
14.
Starting up a node can be divided into two phases:

• the SP initiation phase, where the hard disks are formatted, the volumes
defined and SP exchange data files are loaded to hard disk.
• the function change phase, where the SP, RPV and LUM software is
loaded to the volumes PROG_A/B and a system is created and
installed.
Starting IOG20 from scratch is often called cold start.
Cold start of IOG20 normally only takes place during the installation of
an AXE exchange. It is extremely rare that a new cold start must be made
because of a fault once the IOG is in operation. This is because of the
duplication of the SPs and the fact that the software of each SP is stored on
R1B 189
the hard disks and can be manually reloaded by command SYRSI or by

using the reset button on the CPU60 board.
However, it may happen during operation that both the nodes of an SPG
must be started again for some reason, e.g. because of a change in the
number of hard disks. This would mean a reconfiguration of the hard
disks, thus requiring a new start up of each node in turn. This is called
reinitialisation of the hard disks. Unlike the case of a cold start, one node
the executive, is always working.
Starting both nodes in turn when the exchange is in traffic is a more com-
plicated process than a cold start, as the nodes cannot run in parallel until
they have both been reconfigured and started. In this case the standby node
must be started first and as the nodes have different hard disk configura-
tions no updating from the executive node to the newly started node can
take place.
Thus all relevant charging data must be dumped from hard disk to OD or
sent over a data link, and a conversion of the CP backup file to OD or dis-
kette should be made, just before the newly started node is switched to
executive by command. The information previously dumped, charging
data and CP backup, is then copied back to the new executive node.
The previous executive node (presently standby) can then be reconfigured
and started and when it is deblocked a long updating of its disks will take
place from the new executive node.
A simpler case to handle is the case of a hardware fault in one of the hard
disks. This would mean that a disk in just one node has to be reinitialised.
The amount of work required for this job would depend on whether or not
the faulty disk contained the SP software, i.e. volumes PROG_A/B and
OMFZLIBORD.
If the disk contained these volumes - normally HD-1 - then the node would
have to be started up, i.e. SP initiation and the function change would have
to be performed. If not, then it would be sufficient to just format the new
hard disk and define the required volumes, i.e no function change would
be required. On deblocking of the node the contents of any duplicated vol-
umes would be transferred from the executive node during the updating
phase.
Start up of an SPG, both in the installation phase and in the operational
phase of an IOG20, it is covered in the OPI ’SPG, START ’.
10.3 Start System

There are two types of systems that can execute in a IOG20 node.
• ‘large’, or ordinary, SP system
• start system
190 R1B
Start of SPG
The ordinary SP System is the system that executes in normal operation.

The ordinary SP system always stored on hard disk and reloaded from
there.
The Start System is used only during startup or during hard disk reinitial-
ization and recovery of IO system stoppage, as described above. The start
system is a ‘small’ system that contains only a limited set of functions.
Start systems are never stored on hard disk but reloaded directly from dis-
kette or opto disk. One start system usually fits on two diskettes or one 3
.5’’ OD.
Functions in start system:

• Node communication (ICB)
• File system
• SP function change
• SPHWTABLE
Functions not in start system:

• DCS
• MCS (except a small part)
• SPHWADM
• SP Exchange data administration (except a small part which supports
the command SYSBT)
• FPU
• Infinite files
• SP backup
• SP restart logging
• SPS event log
• SP system parameter handling
This means that in an IOG with the start system loaded there is no commu-
nication via the network ports on the LUM boards. The only working ter-
minals are the ones connected to the CPU port (board CPU60). There is no
CP-SP communication.
Note that the SP function change in an ordinary system and in the start sys-
tem differs slightly.
10.4 Requirements
The requirements for starting up the IOG once the hardware is installed are
as follows:
• a work order containing data about the volumes that are to be created on
R1B 191
the hard disks

• the software package for the IOG
• an asynchronous terminal set for 4800 bit rate connected to the CPU
board of node A in the SPG that is to be started. If a single node is to be
started then the terminal shall be connected to this node.
Such a terminal is called a local terminal. The terminal is connected on
the front of CPU60 board. There are two ports with the same function.
The software package for IOG20 consists of a number of diskettes or opto
disk(s), as follows:
• One or two diskettes, or one OD, labelled STARTSn. If there are two
diskettes they will be labelled STARTSn_BOOT and STARTSn_FILE,
where n is the version of the STARTS diskette.
• A diskette, or OD, labelled SP_INITD_n containing the SP exchange
data for the SPG. The destination volume for the data is given on the
disk label.
• A number of diskettes, or one OD, labelled TRANSP_n containing the
program modules and system description file for the SP system (the
‘large’ system). This includes the LUM and RPV/RPV2 software.
Here, n is the sequence number in which the disks are to be loaded. The
software is loaded into the volumes PROG_A and PROG_B.
Note: The SP exchange data and the program modules are stored on one
OD while the start system on another.
10.5 Procedure
As mentioned earlier the procedure differs slightly depending on whether
a cold start of the SPG is to be performed at installation, OPI ’SPG,
START ’, or whether one or both nodes are to be started singly during
operation, as described above. The latter case is described in the OPI
‘SPG In Single Node, Start’.
A summary is given below for the second case, where one node is started.
In the summary, node B is working as executive and node A has to be
started after the replacement of the hard disk containing the SP software.
The local terminal is first connected to the CPU60 board in the node to be
started and set for TTY (teletype) mode and capital letters.
After inserting the disk STARTSn in FD-1, or OD-1, for the node, the
reset switch is flicked twice. A loading program called Bootstrap, on a
PROM on the CPU60 board, then reads the bootblock from the FD/OD to
SP primary memory.
The bootblock is a small area on the STARTSn disk reserved for the infor-
mation containing a pointer to the so called System Start Information,
SSI, file on the disk.
192 R1B
Start of SPG
The SSI contains the disk addresses (tracks and sectors) of the modules
that are to be loaded. Using this information the bootstrap program loads
the modules of the start system into the SP’s primary memory.
After a successful loading from STARTSn diskette or OD a message will
be received saying that the bootblock has been read from Index 01 or 02
respectively.
A restart of the node will take place after a few minutes and the printout
SP INITIAL SYSTEM RESTARTED will be obtained. The communi-
cation is started by entering a ‘CTRL-E’ character from the local terminal.
The loaded software allows commands to be given for:
• entering SP initiation mode, formatting the hard disks, preparing the
system defined volumes on the hard disk and loading the SP exchange
data to these volumes
• performing the required function change in SP, i.e. loading the SP soft-
ware to the relevant volumes on hard disk and creating the required sys-
tem that will be installed and loaded to the SP
The command ISMCT is given to enter SP initiation mode.
ISMCT is a path building command to the own SP. Its purpose is to stop
the following "dangerous" commands from being used by mistake:
ISMCT must be given first to start an initiating procedure.
In SP initiation mode commands are given for:
• formatting or reformatting the hard disk(s). There is no need to specify
faulty sectors manually. Command ISMEI.
• creating the volumes according to the work order. Command ISVOI.
Note: Creation of the volumes and the subsequent work can be done when
local terminal is in Buffer mode. If contact is lost in Buffer mode, return to
TTY and enter semicolon and ENTER. Then return to Buffer mode.
The command END is used to exit initiation mode.
The SP_INITD_n disk is now inserted in FD-1 or OD-1 and the command
SYSBT is given to load the SP Exchange Data files on the OMFZLI-
BORD volume.
Note: The above step is only really required when starting both nodes. If
only one node is to be started, then these files will be copied from the
duplicated volume when the node is deblocked.
The next step is to perform the function change in the SP, i.e. loading of
the SP modules and creation and installation of the system.
The function change at cold start or start of one node differs somewhat
from a normal function change (as it is described in chapter 14). During
normal function change, the CP is normally working and the SPG must be
fault free - we have a so called ‘large’, or ordinary, system. At cold start
the start system is used.
R1B 193
A short description of each function change command is given below as

applicable to the start of an SPG, i.e. a function change in a start system:
The function change is started with the command FCSPI.
<FCSPI;
The node or nodes that are to be loaded with the software are defined next.
Command FCSLS.
In this command, the parameter LNODE (local node) applies to the com-
mand FCSII which is given later. LNODE is used to say in which node’s
hard disks the so called System Start Information (SSI) file is to be created
by FCSII. (The SSI contains the disk addresses of the modules to be
loaded and is used for loading the node from it’s own hard disk).
The parameters RNODE (remote node) and RSNODE (remote source node)
apply to the command FCSRI, given later, which creates the two remote
installation files (RIF & SSR) for each node. The files are stored on hard
disk in RSNODE.
RNODE is the remote node that is to be loaded and RSNODE is the node
that loads the remote node.
In our case, only one node will later be loaded, node A, and this node must
be able to load node B if required, so the command would be written as:
<FCSLS:LNODE=A,RNODE=B,RSNODE=A;
The next step is to transfer all the software modules from the transport
media (one optical disk or several diskettes TRANSP_n) to the program
volume, in this case PROG_A. Command FCSSL.
The disks are inserted and loaded from FD-1 or OD-1 to destination vol-
ume by the command. The diskettes do not have to be loaded in numerical
order, but this is advisable as it is obviously very important to load all the
TRANSP_n diskettes.
Command example:
<FCSSL:IO=OD-1,IONODE=A;
The TRANSP_01 disk is now inserted again in FD-1 to enable the System
Description File (SDF) to be loaded to the SP’s primary memory. Com-
mand FCSDL.
The SDF lists the modules with revision status that are included in the sys-
tem.
It also describes how each module is to be loaded from HD to the SP (i.e.
boot-loaded by the PROM Bootstrap or file-loaded by FMS software once
this has been booted). In normal IOG20 applications the modules are
boot-loaded. In applications containing extra software - e.g. Remote Meas-
urement Subsystem and Statistics Subsystem - then the extra modules may
possibly be file-loaded. Normally all modules are boot-loaded.
194 R1B
Start of SPG
The System Description File also sets values for the deferred constants in
the programs.
Command example:
<FCSDL:IO=OD-1,IONODE=A;
The TRANSP_01 diskette is then removed from FD-1 or OD-1.
The System File (.SYS) is created next. Command FCSSI.
This file is created using the SDF, but it also contains the FMS addresses
(i.e. volumes and files) of the program modules on the hard disk. Thus
information for both boot loading and file loading is contained in the sys-
tem file.
It takes about 10 minutes to create the system (.SYS) file, which is then
stored in PROG_A in our case.
Command example:
<FCSSI;
The next step is to create the Remote Installation Files (RIF and SSR)
for the node. These files are normally created by FCSSI, but in a small sys-
tem they have to be created separately. Command FCSRI.
These files are to allow a node (here called remote source) to reload the
other node (here called remote) when the latter is unable to reload from its
own hard disk. The loading is then via the Inter Computer Bus (ICB).
The remote and remote source nodes are not defined by FCSRI as this
command has no parameters. The remote and remote source nodes are the
nodes defined earlier by the parameters RNODE and RSNODE respectively
in the command FCSLS.
The remote node will request the remote source node to load it and thus
this node must contain information saying which system is to be loaded to
the remote node. When RIF is asked by the remote node to be loaded, it
uses that node’s designation to determine which system is to be used. The
system name corresponds to a file name that is used as an address to SSR.
SSR is, in effect, the required SSI for the remote node, and can thus be
used to load that node. Thus each node contains an SSI for loading it’s own
system and an SSR for loading the remote node’s system. The systems are
normally the same, of course, in both nodes, but do not have to be.
The remote installation files take about 10 minutes to create. They are
stored in PROG_A in our case.
Command example:
<FCSRI;
The next step is to install the system. Again, installation of a system dur-
ing function change would normally be done by the command FCSSI,
but in a small system has to be performed separately. Command FCSII.
R1B 195
Installing the system implies creating the SSI and storing the address to
this file in the bootblock area on hard disk in the node(s) specified earlier
by parameter LNODE in command FCSLS - node A in our case.
The SSI is needed for all types of reloading, manual or automatic. It con-
tains the absolute addresses (tracks and sectors) of the modules in the sys-
tem.
When the system is later manually loaded using the reset switch, the load-
ing is similar to that of loading the STARTSn diskette mentioned earlier.
The PROM-ed Bootstrap reads the bootblock from Index xx, i.e. from the
PROG_A or PROG_B volumes, and this gives the address to the SSI. The
SSI in its turn gives the absolute addresses to the program modules on the
hard disk so that these can be loaded to the SP.
It takes about 5 minutes to install the system. The SSI file is stored in
PROG_A in our case.
<FCSII;
The function change is now ended using command FCSPE.
<FCSPE;
Once the function change is complete then the software contained in the
newly installed system is reloaded to the SP by flicking the reset switch
twice.
The local terminal connection can now be removed if required.
The node status can now be checked by the normal command IMCSP. The
entry command IMMCT must be used first. Before giving the commands
from a local terminal press carriage return to gain contact with the system.
(The same commands can now be given from any other AT connected to
the IOG).
The standby node status should now be SB - ISOLATED/BLOCKED
The next step would be to deblock the node so that it will be updated from
the executive node.
<BLSNE:SPG=spg,NODE=standby;
During the deblocking the node states will be reloading, diagnosing,
updating, reloaded and normal. During the updating phase all files in the
duplicated volumes will be copied over from the executive node.
It should be noted that the updating must be a large update to transfer over
all the contents of the duplicated volumes from the executive to standby
node.
10.6 Cold Start or Single Start of Both Nodes

Whenever both nodes are started, all files belonging to the duplicated vol-
ume OMFZLIBORD are loaded from one of the SP_INITD_n diskettes or
from the OD. Other files are later created in this volume by the SP pro-
196 R1B
Start of SPG
grams as and when required. (An example is the list of file attributes
defined by INFII).
In the case of starting just one node as described above, all files belonging
to the other duplicated volumes are created during the updating of the node
from the executive node.
In the case of a cold start of an SPG, or when starting both the nodes sin-
gly (reinitialisation of the hard disks in both nodes), all files belonging to
the other duplicated volumes - e.g. the CP backup files - must be defined
by the operation staff. This can be done using a command file or by direct
use of the command INFII. Some comments on these cases are given
below:
As the CP is normally not running at a cold start of an SPG, then the com-
mand INFII and its entry command will have to be entered from the
local terminal or an AT using local mode. The attributes of the defined
files will in this case be written directly on the relevant hard disks of both
nodes.
Once the CP is started the file attributes are copied to the CP’s file table at
the CP system restart. Data about each defined file is thus stored both in
the CP software and on hard disk.
If the CP is running during reinitialisation of the disks in both nodes, then
the files would be defined in the first node to be started before this is
switched to executive. On starting the second node the files would be cop-
ied over from the executive node during updating.
If the CP is running, files should always be defined from an alphanumeric
terminal connected to a LUM board. In this way the file attributes are writ-
ten directly on the disks and in the CP data.
The command INFUI can always be used to adjust the CP’s file table so
that it corresponds to the file attributes defined on hard disk. This com-
mand is always performed automatically at a system restart of the CP.
10.7 Command Initiated Restart of Node

A restart or a reload of a node can be performed by the command SYRSI.
(It is always better to perform restarts/reloads by command instead of
using the reset switch).
<SYRSI:SPG=spg,NODE=node,RANK=SMALL;
or
<SYRSI:SPG=spg,NODE=node,RANK=RELOAD;
The above command can also be used to switch nodes in a parallel work-
ing system by ordering the restart in the executive node. If a switch is
desired the command IMEXS is however better.
This will cause a node switch followed by the restart in the new standby
node.
R1B 197

• Starting up a node can be divided into the SP Initiation phase and the
Function Change phase
• In the SP Initiation phase, the hard disks are formattted, the volumes are
defined and SP Exchange data files are loaded.
• In the Function Change phase, the SP, RPV and LUM software are
loaded to the volumes PROG_A/B and a system is created and
installed.
• There are two types of systems that can execute in a IOG20 node. The
‘large’ or ordinary SP System and the ‘small’ or Start System.
• The ordinary SP System is the system that executes in normal operation
• The Start System is used only during start up or during recovery of IO
system stoppage.
• The Start System contains only a limited set of functions.
• The Start System is not stored on the hard disk but is reloaded directly
from opto disk oe diskettes.
• The System Discription File (.SDF) lists the modules with their revi-
sion status that are included in the system.
• The System File (.SYS) contains the same information as the SDF but it
also contains the FMS addresses of the program modules on the hard
disk.
198 R1B
Subject to alterations without prior notice. Printed in Sweden.
Ericsson Telecom AB
MV/ETX/X/HCX
S-126 25 Stockholm, Sweden
Telephone: +46 8 719 9222 EN/LZT 101 1611 R1C
© Ericsson Telecom AB

1 InputOutput Group 20 IOG 20 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 InputOutput Group 20 IOG 20 PDF

Uploaded by

Copyright:

Available Formats

AXE System Testing 1

Input/Output Group 20, IOG 20

This book is intended to be used as a course material in the Ericsson

1. Introduction to AXE IO System 5

2. Subsystems in the AXE IO System 17

4.7 Operation of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5. System Backup Handling 85

6. MCS applications 107

7. MCS - Command handling 141

8. DCS Applications 149

9. Support Processor Subsystem (SPS) 181

10. Start of SPG 189

1.2 SP-based IO Systems

The description will include such general topics as:

As well as more advanced topics such as:

1.3 Input/Output Functions

Thus the IOG must also contain:

1.4 HW components of an IOG 20 IO system

A Support Processor Group is shown in Figure 1.5. Remember that the

Node Node Node Node

ICB ICB ICB ICB

Node Node Node Node

SPG-0 SPG-1 SPG-2 SPG-3

It is possible to connect up to four SPG’s to the CP, as is shown in Figure

In SPG 0, the link at Node A is designated Link 0 and at Node B is desig-

1.5 IO Device Functions and Characteristics

Whether to connect an AT or AMTP terminal is decided by the distance

Two formats exist:

1.6 Chapter Summary

2.2 Subsystems in SP-based IO Systems

2.3 Support Processor Subsystem (SPS)

2.3.2 The Hardware of SPS

Support Processor, SP. The support processor is a real time computer

2.3.3 The Software of SPS

2.3.4 CP-SP Communication

2.4 Man-machine Communication Subsystem

2.4.2 The Hardware of MCS

The hardware of MCS consists of:

2.4.3 The Software of MCS

• administration of alphanumeric data

2.5 File Management Subsystem (FMS)

2.5.2 The Hardware of FMS

AMTP AT, printer

The hardware of FMS consists of:

2.5.3 The Software of FMS

2.6 Data Communication Subsystem, DCS

2.6.2 The Hardware of DCS

E ach Line U nit M o dule, LU M , m ay

V .24/V .28/V .35/V .36/X .21

G .703 E 0 (64 kb it/s)

G .703 E 1 (2M bit/s)

T -E thernet (not introduced

T o external data connections

2.6.3 The Software of DCS

2.7 The Software Structure of the IO Subsystems

FMS SPS MCS

FMS MCS, alarms DCS SPS

2.7.4 EMRP software

2.7.5 LUM software

2.7.6 RPV/RPV2 software

2.7.7 Functional and Product Structure of SP software

CAA 119, CAA 110 = module written in EriPascal

2.8 Chapter Summary