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
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 SP-based IO Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Input/Output Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 HW components of an IOG 20 IO system . . . . . . . . . . . . . . . . . . . 7 IO Device Functions and Characteristics. . . . . . . . . . . . . . . . . . . 13 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
17
17 17 18 20 22 23 27 30
3. Hardware Structure
3.1 3.2 3.3 3.4 3.5 3.6 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subracks and boards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LEDs and Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31 31 32 35 38 41
4. FMS applications
4.1 4.2 4.3 4.4 4.5 4.6 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FMS Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Storage medium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . File attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
43 43 43 45 49 49
IOG 20
Operation of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The duplicated file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Corrupt Files and File Recovery . . . . . . . . . . . . . . . . . . . . . . . . . File protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Infinite Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . File Process Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Decompression of files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Log in AXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55 60 64 65 65 69 81 82 82
85
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Backup Functions of the CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Command Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Backup of the SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6. MCS applications
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12
107
107 107 109 120 125 126 127 130 133 138 139 140
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The functions of MCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alarm Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing of Printouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standby Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Device Attendance Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alphanumeric Information on File . . . . . . . . . . . . . . . . . . . . . . . MCS directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The MCS Transaction Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IO device load regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
141
141 141 143 145 146 148
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AXE Command Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entry Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subcommands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Mode and CPT Commands . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table of Contents
8. DCS Applications
8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11
149
149 149 150 152 153 160 163 170 171 175 179
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General on Data Communication . . . . . . . . . . . . . . . . . . . . . . . The OSI Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General on DCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DCS concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection of DCS ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition of Port for AT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition of Port for X.25 Data Link . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
181
181 181 181 182 183 188
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Hardware of SPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Software Functions of SPS. . . . . . . . . . . . . . . . . . . . . . . . . SP Hardware Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
189
189 189 190 191 192 196 197 198
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Start System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cold Start or Single Start of Both Nodes . . . . . . . . . . . . . . . . . . Command Initiated Restart of Node . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IOG 20
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.
R1B
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
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
R1B
From the above considerations we see that the hardware of the IO system must contain the following components:
external mass storage devices (hard disks, optical disks and flexible
disks)
data links for both high speed and low speed traffic using both asynchronous and synchronous transfer
an alarm printer - i.e. an alphanumeric terminal to which alarm printouts 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
R1B
RP-bus
CP
SP
ICB
SP
RPV/RPV2
HD AT HD AT HD ALI FD OD DL AMTP DL HD
RPV/RPV2
FD AT, printer OD
Figure 1.2
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 interface.
R1B
RP-bus
CP
Ethernet RP bus
RPV/RPV2
HD AT HD ALI FD OD DL HD HD AT
SP
ICB
SP
RPV/RPV2
FD AT, printer OD
VME bus
DL AMTP
PC/AT VSA
VSA - VME to SCSI-2 adapter
SCSI-2
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
CP
P a r a ll e l R P bus
RPV
VM E bus
SP
SP
Figure 1.4
The RPV converts from a parallel RP bus interface while the RPV2 converts 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 microprocessor. 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 SPs.
10
R1B
RP bus CP
Node ICB
Node
SPG
Figure 1.5
The two SPs in an IOG are connected by the Inter Computer Bus, ICB. The ICB allows data to be transferred between the two SPs. It is an Ethernet 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 designated 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 AMTP ALI HD FD DL OD Alphanumeric Terminal Alphanumeric terminal over Ericsson MTP Alarm Interface Hard Disk Flexible Disk Data Link Optical Disk
An IOG 20 as described above - with two SPs (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 SPs (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 ICB Node ICB Node Node ICB Node Node ICB Node
Node
SPG-0
Figure 1.6
SPG-1
SPG-2
SPG-3
It is possible to connect up to four SPGs 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 SPGs. SPG 1, SPG 2, and SPG 3 provide basically separate processors for handling such data. They thus relieve the workload of the SPs 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 Measurement 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 designated Link 1. In SPG 0, Link 0 has RP address RP-1, Link 1 has RP address RP-4. In the other SPGs the corresponding designations are: SPG 1 SPG 2 SPG 3 Link 0 (RP-5) and Link 1 (RP-6) Link 0 (RP-7) and Link 1 (RP-8) Link 0 (RP-9) and Link 1 (RP-10).
Note: the reason for allocating RP addresses 1 and 4 to SPG 0 is the following: 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 allocated 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.
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 communicates 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 commands 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 AT-1 AT-4 AT-5 alarm printer (operation) connected to the alarm interface, ALI normal AT for use once the IOG has been started (maintenance) 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 memory 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 formatted.
14
R1B
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 charging 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 alphanumeric terminal connection.
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 SPGs 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
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 subsystem 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.
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.2
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
CP
SP
ICB
SP
RPV/RPV2 HD AT
AT, printer
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 primary 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
The CPU60 also contains a VME bus interface and a SCSI-2 bus interface.
CP
P a r a lle l R P bus
RPV
VM E bus
SP
S e r ia l R P b u s CP RPV2 VM E bus
SP
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 parallel 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
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 Systems Interconnection, OSI, model for data communication. The CP regards the RPVs as RPs 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 executive 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 examples 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.
20
R1B
2.4.2
CP
SP
ICB
SP
RPV/RPV2 HD AT HD FD OD HD FD OD DL
AT AT, printer
Figure 2.4
MCS hardware
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 themselves 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 ATs are physically connected to hardware interfaces belonging to subsystem DCS.
2.4.3
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.2
CP
SP
ICB
SP
RPV/RPV2
HD HD
RPV/RPV2 AT
HD ALI FD OD HD AT AT, printer OD DL VSA
AT
FD
AMTP
DL
Figure 2.5
FMS hardware
22
R1B
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
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
compression and decompression of files recovery of corrupt files file security functions
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 ATs or data links enters the AXE IO system via DCS functions 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 network 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
CP
SP
ICB
SP
RPV/RPV2
HD HD
RPV/RPV2 AT
HD ALI FD OD HD AT AT, printer
AT
FD OD DL
AMTP 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
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 communication protocols (X.25, X.28, X.3, X.29 and others) that
implements the OSI layers in the SP
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 hardware is connected via DCS. An X.25 link is used for controlling the measurement instruments (which are also connected to the group switch).
26
R1B
CP FILES
READ WRITE
SPS Supervision
SP
CP - SP communication SPS
OD
FD
HD
Alarm panel
External alarms
Figure 2.8
Both data links and terminals are connected to DCS hardware. A command entered from an AT is thus transferred via DCS hardware and software 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 manner. 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 volumes 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
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 FMS MCS SPS ANZ 216 20 ANZ 217 20 ANZ 218 20 ANZ 219 20
MCS - man-machine communication subsystem handles terminal communication, the alarm system and printout routing
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
After completing this chapter the student will: 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.
R1B
31
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
32 single data links or 16 duplicated data links or a combination of this
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
24 single data links or 12 duplicated data links or a combination of this 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
34
R1B
Hardware Structure
ALEXP ALEXP ALCPU ALCPU LUM LUM LUM LUM LUM LUM LUM LUM DRPBU DRPBU PROVME VSA VSA HD1 drive HD3 drive HD3 drive CPU60
Figure 3.5
FD drive FD drive
3.4.2
3.4.1
Figure 3.6
Power Power
Power
SPVM subrack
R1B
35
3.4.3
HD drive HD drive
Figure 3.7
SPVCM subrack
Power Power
36
CPU60
VSA VSA
VSA VSA RPV2 RPV2 LUM LUM LUM LUM LUM ALEXP ALEXP ALCPU LUM LUM LUM LUM LUM LUM RPV2
CPU60 CPU60
Power
HD drive
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 intercomputer 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 interfaces to the opto disk drive. It interfaces to VME bus, SCSI-2 bus and power in the back plane.
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 interface, 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 interfaces 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 physical 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.
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
V.24/V.35/V.36/X.21 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 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 introduced 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 purpose 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 subrack. 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.
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)
Figure 3.9
Hardware Structure
RUN
BM
RUN : Green during normal operation Red during reset and halt
Figure 3.10
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 debugging 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
Figure 3.11
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
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
R1B
41
42
R1B
4. FMS applications
Chapter Objectives
After completing this chapter the student will: 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.
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 allocated 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.
NSR02, or ISO 13346, complying with the OSTA-UDF (Optical Storage 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 IN USE HEADS 9 VOLUME PROG_A OMFZLIBORD RELVOLUMSW EXCHVOLUME CALLVOLUME STATVOLUME END SECTS 512 STRACK 139 TRACKS 36441
TOTSIZE(KBALLOCSIZE(KB)SUBUNITS 2096744 20757776 SIZE(KB) 200000 100000 500000 400000 400000 475777
44
R1B
FMS applications
Sector size in bytes Number of sectors per track Number of tracks Number of heads for reading and writing Total memory available to user Total memory used by defined volumes Number of volumes 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.
Hard disk
node A
node B
Internal, single volumes Internal, duplicated volume over media border Internal, duplicated volume
Figure 4.2
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 duplicated volume of that node. If a difference between the contents of a duplicated 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 volume. 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 1 NODE1 A NODE2 B END DATE 991231 IO1 HD-1 IO2 HD-1 TOTSIZE(KB) 100000 SIZE1(KB) 100000 SIZE2(KB) 100000 USEDSIZE(KB 5528 LIMIT 99
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 command INVOL. Example of loading an external volume:
< INMCT:SPG=0; :INVOL:NODE=A,IO=OD-1; ORDERED :END; EXECUTED VOLUME LOADED EXECUTED VOLUME TRAINING END NODE A IO OD-1 FORMAT APN
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
Node A
Node B
Mandatory volumes
463+C&
Optional 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 SPGs.
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 Subsystem (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 volume 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 specific market requirements on alternative name exists. This volume is duplicated 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.
R1B
49
A composite file is a file that consists of a mainfile and one or more subfiles. 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 subfiles. 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 file
Main file
data data...
data data...
data data...
Sub files
Figure 4.4
A device file is a file identifying an external media where data to be written. 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:
50
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
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:
Figure 4.5
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 considered as a special case of sequential access.
Records with subfields: Key 1973 1988 Key Fiat Nissan Data Via Torino Nanjing road Data green white
year
Figure 4.6
carmake
address
colour
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 subfields.
52
R1B
FMS applications
4.6.3
Expansion factor
Write
Expansion factor
Write
Record length
Figure 4.7
R1B
53
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
Physical space on hard disk:
Blocking factor
block 3
block 4 Blocking factor n records Start of file block 1 block 2 End of file
Figure 4.8
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
In the example above a Central Processor backup file is created (all CP backup files are named RELFSWn). It is located in volume RELVOLUMSW. 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 volume. 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 FD0A1 FD0B1 OD0A1 OD0B1 END FCLASS DEV DEV DEV DEV SPG 0 0 0 0 VOL NODE A B A B IO FD-1 FD-1 OD-1 OD-1
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 512 4 TYPE NFIELDS SEQ 0 FCLASS DEV SUBFILES FD0A1-FDFILE1 FD0A1-FDFILE2 END SIZE 0 NKEYS 0 EXP 10 NUSERS
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 2048 TYPE SEQ BLK 4 NFIELDS 0 SIZE 16 NKEYS 0 EXP 64 NUSERS
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 OPIs 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 ALI FD OD DL
Figure 4.9
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 destination 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 FILE HDFILE DESTINATION FILE DATA FILE FDFILE END GEN 0 VOLUME TEST NODE A IO OD-1 GEN VOLUME NODE OMFZLIBORD IO -
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
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 operator terminal. Note that in the printout FILE DUMP the END OF BLOCK must be interpreted as end of record. It must not be confused with the blocking parameter (BLK) of the file.
W rite
R e sult
W rite
R e sult
Figure 4.10
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 normal 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 1 END NODE CM A 1 EX STATUS STATE WORKING NORMAL SB NODE CM STATUS STATE B 2 ISOLATED BLOCKED HDSTATE CORRUPT
The hard disk status may be printed with command IMCSP. The parameter 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:
R1B
61
Sector table
.......
File
Delete Write
Create
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.
Sector table
....... sector n ...
File
sector y
sector y ....
62
R1B
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
During the small and large update the hard disk status (parameter HDSTATE) is CORRUPT.
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 prohibit 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 command 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.
R1B
65
SP or CP file user
FMS
Mainfile: STATFILE
-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 created 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 command 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 TTFILE00 TTFILE01 TTFILE02 TRARFILE CMVNFILE TRDIPFILE END ACTIVESUB 0231 0001 0001 1201 0007 0763 NEXTSUB 0232 0002 0002 1202 0008 0764 NSUB 9999 9999 9999 9999 9999 9999 MAXSIZE MAXTIME 4096 4096 4096 512 1 1024 RELEASE NO NO NO YES YES YES COMP YES YES YES NO NO 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 automatically 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 outputs. 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 function 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.
-- " --
-- " --
-- " --
(MAX -9999)
Figure 4.14
68
R1B
FMS applications
Compressed data
-- " --
-- " --
-- " --
(MAX -9999)
Figure 4.15
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.
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 implemented. 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 function 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:
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
R1B
71
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; FILE PROCESS UTILITY SUBFILE LIST FILE = TTFILE00 DEST = TTFILEOD SUBFILE 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 END SIZE 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 TRANSF NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO DUMPED SEQNUM YES YES YES YES YES YES YES YES YES YES YES YES NO NO NO NO
STARTTIME
STOPTIME
FAILTIME
REASON
R1B
FMS applications
970605 1121
970605 1128
970605 1130
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 certain 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
automatically - initiated from IOG automatically - initiated from remote destination manually manual re-transfer of an already transferred subfile
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:
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 oclock 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 override 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:
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 automatically 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
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
Assume that subfiles are now being reported to FPU. FPU subfile list:
<INFSP:FILE=PERIODICACC,DEST=ODDEST; FILE PROCESS UTILITY SUBFILE LIST FILE=PERIODICACC SUBFILE 0001 0002 0003 SIZE 1000 1000 1000 DEST=ODDEST TRANSF NO NO NO DUMPED NO NO NO SEQNUM
76
R1B
FMS applications
NO NO NO NO
NO NO NO NO
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; FILE PROCESS UTILITY SUBFILE LIST FILE=PERIODICACC SUBFILE 0001 0002 0003 0004 0005 0006 0007 END SIZE 1000 1000 1000 1000 1000 1000 1000 DEST=ODDEST TRANSF NO NO NO NO NO NO NO DUMPED YES YES YES YES YES YES YES SEQNUM
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 volumes are loaded. Serial output is not possible. Command example for parallel transfer:
<INFMT:DEST=ODDEST,VOL1=ODVOLSIDE1,VOL2=ODSTAT;
4.12.6
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
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: PERIODICACC-0007 PERIODICACC-0007 PERIODICACC-0007 File in external file system: PERIODICACC.0007 PERIODICACC0007.0000 PERIODICACC-0007
78
R1B
FMS applications
In the first case the FMS file name is adapted to a file system where generations are supported. The mainfile name forms the file name in the external 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 concatenated 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: File in FMS: PERIODICACC-0007 PERIODICACC-0007 PERIODICACC-0007 File in external file system: PERACCTOWN.0007 PERACCTOWN0007.0000 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 connecting a file to a destination. Command example:
< INFDI:DEST=BC,EQUIP=MTP,FILEID1=PERACCTOWN, RULE1=1;
4.12.9
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:
(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 countdown 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
FLAM PKZIP
Command example:
:IMDCI:FILE1=COMPREL,FILE2=RELFSW99;
In the example above, all subfiles of the mainfile COMPREL are decompressed 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.1
Implementation
The function is administered by the FMS block LOGB in the CP.
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 supervision limit is exceeded, then an APZ alarm is issued
PROG_A and PROG_B, usually the only unduplicated volumes, contain the SP software, including RPV/RPV2 and LUM software and the SP system files. The SP trace log files are stored here as well
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
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
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
R1B
83
84
R1B
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.
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:
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 doesnt 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 RELVOLUMSW.
5.2.1
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 deactivated. The only CP backup is now stored on hard disk.
5.2.2
86
R1B
Mainfile RELFSWn
R5
Contents of RS and PS
Figure 5.2
The subfile R0 contains control data for administration of the other subfiles, 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 different 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:
R1B
87
5.2.3
Manual backup of CP
The manual backup of CP may be done towards:
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 information 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:
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 Output Times, Specify. Command example:
<SYBTS:TIME=0000,TDMI=240; <SYBUI:DISC;
In the example above the large automatic CP backup is performed at midnight 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 Reload CP RS, PS and DS Manual dump RELFSW2 RELFSW1 First File Range RELFSW0
Figure 5.3
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, depending 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;
First File Range
<SYTUC:SFR;
Second File Range
Figure 5.4
Command SYTUC can be used for name rotation of system backup files if RELFSW2 is newer than RELFSW0 and RELFSW0 is not empty. Command SYTUC is normally used after a manual dump to RELFSW2. See Figure 5.4.
R1B
91
<SYNIC;
First File Range
<SYNIC:SFR;
Second file Range
Figure 5.5
Command SYNIC can be used to change the file names when RELFSW2 is newer than RELFSW0 or when RELFSW0 is empty. SYNIC is normally only used at the first load of the exchange when, after the first manual 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 renaming files is preferably avoided, particularly in a live switch. This method is however very useful during installation test or in a test plant environment 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;
First File Range
RELFSW101 RELFSW102
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
ICB
RPV/RPV2 HD AT HD
ALI
SYACI SYCFI
SYMTP
FD OD
DL (via FPU)
Figure 5.7
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:
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:
(release terminal)
< SYACI:CON; :SYCFP; ORDERED
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
In the command example above all subfiles of file RELFSW3 are converted and input from diskette. The diskettes of course has to be changed in between giving the commands. The diskettes must be inserted in the diskette 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; <INFSI:FILE=RELFSW102-R1; <INFSI:FILE=RELFSW102-R2; <INFSI:FILE=RELFSW102-R3; <INFSI:FILE=RELFSW102-R4; <INFSI:FILE=RELFSW102-R5; <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:
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 loading. 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 AUT NTAZ NTCZ 1 10 LOAZ 0 INCL1 RELFSW0 INCL2 101 INCLA 97062 SUP 60
AT 0832
Here is a short explanation of the different parameters in the example: CLH NTAZ Can be set to AUT for automatic handling of the backup system or MAN for manual. Number of truncation attempts with RELFSW0. If this parameter is set to zero, the following two parameters are insignificant. 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. 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. 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. 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.
NTCZ
LOAZ
INCL1
INCL2
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. 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).
SUP
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 930429 1141 TYPE PS,RS DSSMALL DSLARGE COMANDLOG 000005 END ACTION LOADED LOADED LOADED RP 4 EM 0 DEV 1 RELOADFILE RELFSW0 SUBFILE R5 R1 R3
TRUNCATION 0
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 system will not reload. The alarm BACKUP INFORMATION FAULT is issued. The automatic reload function is turned on by command SYRBE.
5.2.8
R1B
99
Command example:
<SYBCI: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 following the OPI for the alarm above.
5.3.1
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 command 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 RELFSW3 SUBFILE R1 R2 R3 R4 R5 END IO TYPE DSSMALL DSSMALL DSLARGE DSLARGE PS,RS EXCHANGE TRX-C:9 APZ 211 11 R1 OUTPUTTIME 970302 1600 970302 1200 970302 0000 970301 0000 950302 1614 CURRENT YES NO YES NO YES COMMANDLOG 0010021 0010020 -
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 command 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
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 subfile.
5.3.3
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 OPIs, all named Command Log.......
5.3.4
The command example above starts with the creation of a new command log subfile with command SYCSI. After this the command log is activated. 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 subfiles 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 command 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.
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 memory 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 module 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. are usually stored in volume OMFZLIBORD. Examples of SP exchange data are port definitions, MCS transaction logging conditions, Network terminal numbers etc.
104
R1B
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 commands and subscriber services, ordered from a telephone set, are logged automatically
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 volumes PROG_A and PROG_B can be backed up on a FD or OD
R1B
105
106
R1B
6. MCS applications
Chapter Objectives
After completing this chapter the student will: 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.
R1B
107
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 analysis, location of command receiving block and transfer of command parameters, 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 printout 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 implemented 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 levels 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 (Alphanumeric 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 parameter 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 IDs 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 alphanumeric terminal. Commands may however also be executed from a prepared command file on hard disk or external media. The command file may be executed manually or automatically according to a time schedule.
Introduction
Error
Error
Alarm issue
Figure 6.2
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
alarm printouts, which are text printouts indicating what is wrong alarm classes and categories exchange identity alarm numbers date and time FORLOPP identities
110
R1B
MCS applications
A la rm c la s s
A la r m n u m b e r A la rm c a te g o ry s lo g a n E xchange header D a te T im e A la r m F id
1258
H 0 2 6 2 -0 0 0 1
A la rm te x t
Figure 6.3
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 oclock 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 category number (ALCATNO). The alarm categories and their ALCATNOs are as follows: 0 1 2 3-15 Data processing system Processors IO Device System dependent data, determined by the system projecting instance in question.
R1B
111
3 4 5 6 7 8 9 10 11 12-15
Switch Switching part Switching device Subscriber lines Spare Power alarm House alarm Alarm from subordinate exchange Cable alarm 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 ALCATNO 0 1 2 3 4 5 6 7 8 9 ... 14 15 END CATEGORY ALCAT APZ APZ APZ APT APT APT APT APT POWER EXT EXT EXT DATA DICAT 0&4 0&4 0&4 1&4 1&4 1&4 1&4 1&4 2&4 3&4 3&4 3&4
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 connected to DICAT 0 etc. See Figure 6.4.
112
R1B
MCS applications
3:rd...
AXE A1 A2 ATT
...13:th
AXE A1 A2 ATT
4 Display categories
5...
... 15
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 during 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 ACLNO 0 CLASS ACL A1 DATA ALDB YES TWB NO PRINTOUT YES
R1B
113
1 2 3 4 END
A2 A3 O1 O2
YES NO NO NO
NO NO NO NO
6.3.3
ALCPU
E xternal alarm sensor to E X R A N G 20. D evices E X A L 2 0 - 31
ALEXP
A larm panel, display categories 0-3. U S version categories 0-2. A larm panel, display categories 4-7. U S version categories 3-5. A larm panel, display categories 8-11. U S version categories 6-8. A larm panel, display categories 12-15. U S version categories 9-11.
SC A N interface categories 0-15. U S version categories 011. V .24 port to L U M port, 2400 baud V .24 port to fan, 2400 baud B us in backplane
P ow er -48 V
Figure 6.5
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 Connection 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 Anode 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.
Alarm on power system Burglar alarm on door and window Alarm on cooling system
EXAL0devices
Figure 6.6
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.
Iirvursvtrhr ! # % ' ! # " $ " $ # # $ $ " $ & " $ & ( % % & ! ! " " @Y 6G!qrvprir
&
& (
'
'
( @hpuqrvprpvs prpv
' ! !! !# !%
! !" !$ !& !(
!!
!!
!"
!"
!%
!%
!&
!&
!' "
"
"
"
"
Figure 6.7
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 connection 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 interface, 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 contact 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 command 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 ALARM ALARM ATTENDANCE END STATUS CATEGORY CLASS STATUS "HMBRG LOC 12.4/00/01" 0 1 2 3 4 5 6 7 .... O1 A2 A2 - - A2 - - .... N N N N N N N N .... 12 13 14 15 - - - N N N N
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 attendR1B 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
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
E X R A N G 20
Figure 6.8
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 supervision 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 correspond 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 category 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 sensors 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 updating of the hardware. In the opposite direction, when an external alarm sensor indicates a fault, the functions filter out non-persisting fault indications and send a signal containing alarm information to ALSA if the fault persists. 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 indicators and alarm panels depending on attendance. Block ALIM provides maintenance functions for the ALI. The block consists 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 information (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 ALIs 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 handles alarm information concerning faults in the SPG. Block ALCO stores the information for all SPG alarms in a list and initiates 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.
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 maximum 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 command 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 parameter 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
AT-0
AT -4
A T-2
IO d evice 1 D TY P E= FIR S T
IO d evice 2 D TY P E= N EX T
IO device 3 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 position 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.
IO device 1
IO device 2
IO device 3
Figure 6.10
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 categories. 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 printouts 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 priority (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 PCLs 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 PRCAs has been defined for each device using IOROL then the data must be entered into the device tables by the command 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
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 system 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 nonalarm 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 printouts. 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 alphanumeric 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 heartbeat 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, Spontaneous, Route. The function is handled by the block SEC2.
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 printout 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 categories 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 printouts 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 command IOIOP. The OPI IO Device Standby List, Change should be used when defining 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.
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;
The command must be given from the device that is to be attended/unattended. 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.
R1B
127
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 printouts 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
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 giving 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 subfiles 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 Alphanumeric Information to File should be used.
R1B
129
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. Shirley 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 command 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 Username (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
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
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 terminal/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 OPIs 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
AT
STDEP PRINTOUT CACLS .... EXROI PRINTOUT SYREI PRINTOUT LAFBP ALARM ... INFUI ...
AXE
Logfile on hard disk DATE TIME IO USER STDEP PRINTOUT CACLS .... DATE TIME IO USER EXROI PRINTOUT SYREI PRINTOUT DATE TIME IO USER LAFBP ALARM ... INFUI ... DATE TIME IO USER
AT
AMTP
Figure 6.12
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 categories, PRCA, if required
The transaction log files are composite sequential files. The files must be created before any logging conditions can be defined. Unlike the command 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 statistics 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 (activate) 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 recommended:
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 printout 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 continuously 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 categories 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 created. 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 indicates 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
R1B
135
Text file with commands and printouts to exclude: AGKDI Hard disk in IOG20, SPG0 EXRPI EXROI printout printout File PC or WS
Encryption
Figure 6.13
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 commands and printouts are excluded cannot be printed by command.
6.9.2
IO device date and time one command or part of command name e.g. CH for charging commands 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 CACLS .... DATE TIME IO USER EXROI PRINTOUT SYREI PRINTOUT DATE TIME IO USER LAFBP ALARM ... INFUI ... DATE TIME IO USER
AT
Figure 6.14
This is described in the operational instruction MCS Search in Transaction Log. Two types of searches exists, i.e. search on transactions concerning the terminal the search is ordered from and authorised search which gives a possibility 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.
6.9.3
Implementation
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.1
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 commands may fit into one record. The commands CACLP and STDEP are written to the file.
6.10.2
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
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 oclock 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, command log handling.
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.
6.11.1
Implementation
Block LRCIO.
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)
The PRCA is used to direct the printouts, such as the alarm list, to certain IO device(s)
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 criteria, such as IO device, date and time, one command or part of a command, one or a number of PRCAs, etc.
140
R1B
Chapter Objectives
After completing this chapter the student will: 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.
R1B
141
Alphanumeric terminal
Command AT
SP
CP
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 different entry commands in the AXE IO system.
a) AT
c) AT
b) AT
SPG0
CP
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
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 indicated 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 provided 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 commands 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 perform the necessary interface between the incoming commands/outgoing printouts and the user blocks.
R1B
143
In each subsystem each entry command corresponds to a different authority 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)
IMMCT
FMS
INMCT INMIT INMPT
MCS/DCS/RMS/STS
IMLCT IMLIT (F-category) 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 I is for P is for Change and Print Initiate and Print Print high authority middle authority 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 subcommands can now be given after the colon. Subcommands issued will be analysed 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 commands. 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 subcommand, 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 subcommands belonging to the original entry command then the entry command must be given again before it is possible to continue.
R1B
145
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 printouts directly from the SP.
Commands
AT SP CP
Printouts
Figure 7.4
Local mode
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 subcommands 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 initiate 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 modules - 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 operators 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 mentioned 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 LUs. 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.
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.
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 destination 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.
150
R1B
DCS Applications
USER
USER
7 6 5 4 3 2 1
PHYSICAL MEDIA
Figure 8.2
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 hardware. The other layers consist only of software. Each layer performs specific functions and is independent of the other layers, apart from a well-defined interface to the layers directly above and below. A layer can be changed without affecting the other layers, thus providing flexibility which, in turn, simplifies the interconnection of different datacom systems.
R1B
151
USER A
user data
USER B
7 6 5 4 3 2 1
user data user data user data user data user data user data user data
Figure 8.3
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 additional 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 corresponding 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 network 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 network, i.e. it gives the user access to the network services. It is, as such, the network communication program as seen from the users point of view.
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.1
Communication module
The Communication Module, CM, is a logical concept. The first node in SPG identifies the CM, as follows: SPG 0 SPG 1 SPG 2 SPG 3 node A = CM 1 node A = CM 17 node A = CM 33 node A = CM 49
The background to the CM numbering is the operating system. The operating 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; NODE CONFIGURATION STATUS SPG 0 NPAIR 1 END NODE CM A 1 EXSB STATUS STATE WORKING NORMAL NODE B CM 2 STATUS ISOLATED STATE BLOCKED HDSTATE CORRUPT
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
Power Power
CPU60 CPU60
ALEXP ALEXP ALCPU ALCPU LUM LUM LUM LUM LUM LUM LUM ESDCV ESDCV RPV2 RPV2 VSA
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 communication 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.
Figure 8.5
Power Power
R1B
CPU60 CPU60
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 Bnode of SPG2 and the A-node of SPG0 are defined. The line units are single (non redundant). A line unit can take the status:
ALEXP ALEXP ALCPU ALCPU LUM LUM LUM LUM LUM LUM LUM LUM ESDCV RPV2 RPV2 VSA VSA
Working Executive or Standby - WO/EX, WO/SB Manually Blocked - MBL Hardware Blocked - HBL Conditionally Blocked - CBL Automatically Blocked - ABL
155
If a higher security is required the line unit may be defined as a twin (or redundant) line unit.
SPG0 Node A
SPG0 Node B
LUM
LUM
LUM
LUM
LUM
LUM
LUM
Y-cable
Figure 8.6
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 automatically 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
LUM
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 EXnode.
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 communication interfaces, as below: V G E T V.24/V.35/V.36/X.21 G.703 E0 (64Kbps) G.703 E1 (2Mbps) 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 board
Screws
Daughter board
. . . .
. . . .
Each daughter board implements one physical port
Figure 8.7
LUM board
R1B
157
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
LUM
SPG0 Node A
Figure 8.8
SPG0 Node B
LUM
SPG1 Node A
LUM
SPG1 Node B
When defining a port not only layer 1 but also the layer 2 and 3 characteristics 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 Single Link Port, Initiate gives recommendations and explanations to all
158 R1B
LUM
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-disassembly 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:
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=H01; :ILLLI:NP=1-2-4-1-2,PROT=CPT/SDLC,ADDR=H86; :ILLLI:NP=1-2-4-1-3,PROT=CPT/SDLC,ADDR=HA9; :ILLLI:NP=1-2-4-1-4,PROT=CPT/SDLC,ADDR=HCD; : :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 logical 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 communication protocols cover layers 2-7.
CPT SW (CPTASP) MCS 7 6 5 4 3 2 1 V.25 bis/V.28 X.28/X.3 SDLC V.24/V.28 V.36 ATP
CP-SP communication
Users in SP
FMS
FTAM
Presenation (6)
Session (5)
RFC1006
TCP/ IP
Data Link (2)
E0
E1
Ethernet
Synchronous
Figure 8.9
The following types of interface standards are supported in IOG 20: Interface: Asynchronous transmission: Supported baudrates
160
R1B
DCS Applications
ITU-T V.24/V.28 (EIA RS 232 C) ITU-T V.25bis/V.28 Synchronous transmission: ITU-T V.24/V.28 (EIA RS 232 C) ITU-T V.35 ITU-T V.36 ITU-T V.25bis/V.28 ITU-T X.21 ITU-T G.703 E0 ITU-T G.703 E1 Ethernet V.24/V.28
2400 - 57 600 bits/s 2400 - 256 000 bits/s 2400 - 2 048 000 bits/s 2400 - 57 600 bits/s 2400 - 2 048 000 bits/s 64 000 bits/s 2 048 000 bits/s 10 240 000 bits/s
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). Implemented in V.24/V.35/V.36/X.21 INTERFACE daughter board.
V.35
Interface for interworking with V.35 modem. Implemented in V.24/V.35/V.36/X.21 INTERFACE daughter board.
V.36
Interface for interworking with V.36 modem. Implemented in V.24/V.35/V.36/X.21 INTERFACE daughter board.
X.21
X.21 interface is used for the connection of high speed synchronous data links in public data networks Implemented in V.24/V.35/V.36/X.21 INTERFACE 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
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:
8.6.3
Layer 3
Layer three in the OSI model is the network layer. Here AXE supports three protocols:
162
R1B
DCS Applications
8.6.4
Layer 4-7
Layers 4 to 7 implements the transport, session, presentation and application 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:
In the example above the session port for accessing the Ericsson MTP protocol 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 protocol is used. The locally connected terminals connects via Asynchronous Terminal Protocol, 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.
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 network. 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 Direction, ND, which corresponds to the area code in the telephone network: NTN =ND + internal digits
Computer NTN=65392
NTN=9873
NTN=905
NTN=94
Alphanumeric terminal
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 origin, BO. All ports in IOG 20 used for connection of AT devices are assigned network 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 protocol to be used. The destination is translated to a NTN number, its a oneto-one relation, with command ILDNI. The relation is printed with command 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;
NP= 1- 2- 1- 4
R1B
165
76 END
NEWODA=
Command descriptions: ILRAI ILDAP ILNAI The command defines number analysis data for a given number direction, ND. The command gives a printout of number analysis data for one or all number directions. The command is used to define a name for a predefined NTN and insert the name and NTN in the addressing by name analysis. The command is used to print the addressing by name analysis data. Destination to network terminal relation. Destination to network terminal relation. Assigns a NTN to a network port, dedicated line. 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 analysis 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 NTN=65392
ROT=75
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 commands 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. The command is used to change route data for an existing route. The command is used to print route data. Removal of route data. The command defines a routing case with its associated routes. The command prints routing cases. 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
168
R1B
DCS Applications
IOG20
Figure 8.12
Command example:
:ILPCI:NTNA=1012104,NTNB=1015100;
In the example above the network terminal number 1012104, which represents 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 Terminal Protocol OSI layer 7, and then passed on to MCS. The circuits are printed with command ILPCP and removed with command 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 priority 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 statically allocated ports (if such a link was using PCM media - or was converted 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 Network 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.
170
R1B
DCS Applications
In order to define a port, a series of commands must be given. The procedure 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 terminal 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 communication 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 necessary 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 customer. 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.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
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
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 earlier in the section on addressing).
:ILTEI:NTN=ntn,NP=np;
8.9.5
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
The connection is now made between the NP (NTNA) and the SP (NTNB) by the command ILPCI.
8.9.7
IOG local mode operators are also registered separately in the User Directory. Authority EFH is the normal command authority given to local mode users. (No entry is required in the Communication Directory).
8.9.8
8.9.9
174
R1B
DCS Applications
<SAAII:SAE=344,NI=ni;
8.9.10
R1B
175
In our case, the destination is the Session Port for Message Transfer Protocol (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 destination AOM it would be defined using an AOM command.
Computer NTN=150
IOG20
ROT=1
AMTP-n
Figure 8.14
For traffic in the opposite direction, it follows that, at the OMC, the Network 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
8.10.2
176
R1B
DCS Applications
:ILSLI:NP=np,RATE=rate,PROT=X25/V36;
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
8.10.4
(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
8.10.6
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 alphanumeric 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
8.10.8
8.10.9
8.10.10
8.10.11
8.10.12
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;
The file would now be routed through the network to destination in the ILDNI command.
The basic concepts in DCS are the Ports, the Line Units, the Line Module 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
Chapter Objectives
After completing this chapter the student will: 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 hardware 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
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.
system kernel (system executive) SP hardware administration loading function node communication SP statistics CP-SP communication 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 different processes contained in the program modules, time supervision for sending periodic signals, and administration of the primary memory.
182
R1B
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.2
R1B
183
SP HARDWARE DATA SPG 0 NODE A NAME ADDR ACIA 25 BNA DISK_SC DISK_SC CONFIGURATIO MEMORY SCSI FDC FDI FDIADM EBA_VSA DESCR SPARE INDEX STD **** 1 00FA **** 1 **** 1 **** 4 **** 1 WSU **** 1 **** 3 **** 1 **** 1 **** 1 **** 1 UFIELD T..113 -----H31001 O14001 IOG20 32 5 1 11F 1 1 1
UNIT VD-1 NA-1 HD-1 OD-1 CONFIG-1 WSU-1 SCSI-1 FD-1 FDI-1 FDIADM-1 VSA-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 programs 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
184
R1B
Default SP HW table
SP HW table
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 possible units in the IOG20. Default SP hardware data:
SP HARDWARE DATA SPG 0 NODE A NAME ADDR ACIA 25 BNA DISK_SC DISK_SC DISK_SC DISK_SC CONFIGURATIO MEMORY SCSI FDC DESCR SPARE INDEX STD **** 1 00FA **** 1 **** 1 **** 1 **** 1 **** 4 **** 1 WSU **** 1 **** 3 **** 1 UFIELD T..113 -----H31001 H31002 H31003 O14001 IOG20 32 5 1 11F
185
UNIT VD-1 NA-1 HD-1 HD-2 HD-3 OD-1 CONFIG-1 WSU-1 SCSI-1 FD-1
R1B
1 1 1
1 1 1
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 A A A A A A END UNIT VD-1 RPV-1 HD-1 NA-1 FD-1 OD-1 OPMODE READY READY READY READY READY READY
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 command 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 command 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 definition 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 Ericsson 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.
9.5.5
Implementation
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 SPHWTABLE 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
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
After completing this chapter the student will: 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 connected and tested then the first step in starting up the exchange is the starting 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 complicated 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 configurations 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 diskette 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 volumes 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 .
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 reinitialization 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 diskette or opto disk. One start system usually fits on two diskettes or one 3 .5 OD. Functions in start system:
DCS MCS (except a small part) CP-SP communication 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 communication via the network ports on the LUM boards. The only working terminals 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 system 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 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.
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 information 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 SPs 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 communication is started by entering a CTRL-E character from the local terminal. The loaded software allows commands to be given for:
performing the required function change in SP, i.e. loading the SP software to the relevant volumes on hard disk and creating the required system 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:
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 command FCSII which is given later. LNODE is used to say in which nodes 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 its 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 volume 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 SPs primary memory. Command FCSDL. The SDF lists the modules with revision status that are included in the system. 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 Measurement 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 system 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 system 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 nodes 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 its own system and an SSR for loading the remote nodes 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 during 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 contains the absolute addresses (tracks and sectors) of the modules in the system. When the system is later manually loaded using the reset switch, the loading 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;
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.
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 singly (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 command 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 CPs 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 copied 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 written directly on the disks and in the CP data. The command INFUI can always be used to adjust the CPs file table so that it corresponds to the file attributes defined on hard disk. This command is always performed automatically at a system restart of the CP.
or
<SYRSI:SPG=spg,NODE=node,RANK=RELOAD;
The above command can also be used to switch nodes in a parallel working 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
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 revision 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
Ericsson Telecom AB MV/ETX/X/HCX S-126 25 Stockholm, Sweden Telephone: +46 8 719 9222