R1B 311

15.Start of SPG
15.1 Introduction
This chapter describes the procedure and functions of the initial startup of
the AXE IO system.
Figure 15.1
Chapter Objectives
15.2 General
Once all hardware has been installed in the exchange and the cabling con-
nected and tested then the first step in starting up the exchange is the start-
ing of the IOG20. Once this is running then the APZ can be started using
the functions of the IOG.
Starting an IOG20 implies starting up the nodes of each SPG in the IOG.
Note: Start of an SPG involves function change procedures. This chapter
has been written to be sufficient for an understanding of function change at
start up of an SPG. Function change is covered in more detail in chapter
14.
Starting up a node can be divided into two phases:
the SP initiation phase, where the hard disks are formatted, the volumes
defined and SP exchange data files are loaded to hard disk.
the function change phase, where the SP, RPV and LUM software is
loaded to the volumes PROG_A/B and a system is created and
Chapter Objectives
After completing this chapter the student will:
Describe the occasions when an SPG or node has to be started
List the different parts of the software package required at startup
of an SPG
Explain briefly the contents of each part of the software package
Explain briefly the concepts System Description File and System
File
Explain the concepts small system and large system with regard to
SP function change
Carry out a cold start of an SPG using OPI SPG, Start
AXE IO System, IOG20, EN/LZT 101 135
312 R1B
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
the hard disks and can be manually reloaded by command SYRSI or by
using the reset button on the CPU60 board.
However, it may happen during operation that both the nodes of an SPG
must be started again for some reason, e.g. because of a change in the
number of hard disks. This would mean a reconfiguration of the hard
disks, thus requiring a new start up of each node in turn. This is called
reinitialisation of the hard disks. Unlike the case of a cold start, one node
the executive, is always working.
Starting both nodes in turn when the exchange is in traffic is a more com-
plicated process than a cold start, as the nodes cannot run in parallel until
they have both been reconfigured and started. In this case the standby node
must be started first and as the nodes have different hard disk configura-
tions no updating from the executive node to the newly started node can
take place.
Thus all relevant charging data must be dumped from hard disk to OD or
sent over a data link, and a conversion of the CP backup file to OD or dis-
kette should be made, just before the newly started node is switched to
executive by command. The information previously dumped, charging
data and CP backup, is then copied back to the new executive node.
The previous executive node (presently standby) can then be reconfigured
and started and when it is deblocked a long updating of its disks will take
place from the new executive node.
A simpler case to handle is the case of a hardware fault in one of the hard
disks. This would mean that a disk in just one node has to be reinitialised.
The amount of work required for this job would depend on whether or not
the faulty disk contained the SP software, i.e. volumes PROG_A/B and
OMFZLIBORD.
If the disk contained these volumes - normally HD-1 - then the node would
have to be started up, i.e. SP initiation and the function change would have
to be performed. If not, then it would be sufficient to just format the new
hard disk and define the required volumes, i.e no function change would
be required. On deblocking of the node the contents of any duplicated vol-
umes would be transferred from the executive node during the updating
phase.
Start up of an SPG, both in the installation phase and in the operational
phase of an IOG20, it is covered in the OPI SPG, START .
Start of SPG
R1B 313
15.3 Start System
There are two types of systems that can execute in a IOG20 node.
large, or ordinary, SP system
start system
The ordinary SP System is the system that executes in normal operation.
The ordinary SP system always stored on hard disk and reloaded from
there.
The Start System is used only during startup or during hard disk reinitial-
ization and recovery of IO system stoppage, as described above. The start
system is a small system that contains only a limited set of functions.
Start systems are never stored on hard disk but reloaded directly from dis-
kette or opto disk. One start system usually fits on two diskettes or one 3
.5 OD.
Functions in start system:
Node communication (ICB)
File system
SP function change
SPHWTABLE
Functions not in start system:
DCS
MCS (except a small part)
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 commu-
nication via the network ports on the LUM boards. The only working ter-
minals are the ones connected to the CPU port (board CPU60). There is no
CP-SP communication.
Note that the SP function change in an ordinary system and in the start sys-
tem differs slightly.
AXE IO System, IOG20, EN/LZT 101 135
314 R1B
15.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
the hard disks
the software package for the IOG
an asynchronous terminal set for 4800 bit rate connected to the CPU
board of node A in the SPG that is to be started. If a single node is to be
started then the terminal shall be connected to this node.
Such a terminal is called a local terminal. The terminal is connected on
the front of CPU60 board. There are two ports with the same function.
The software package for IOG20 consists of a number of diskettes or opto
disk(s), as follows:
One or two diskettes, or one OD, labelled STARTSn. If there are two
diskettes they will be labelled STARTSn_BOOT and STARTSn_FILE,
where n is the version of the STARTS diskette.
A diskette, or OD, labelled SP_INITD_n containing the SP exchange
data for the SPG. The destination volume for the data is given on the
disk label.
A number of diskettes, or one OD, labelled TRANSP_n containing the
program modules and system description file for the SP system (the
large system). This includes the LUM and RPV/RPV2 software.
Here, n is the sequence number in which the disks are to be loaded. The
software is loaded into the volumes PROG_A and PROG_B.
Note: The SP exchange data and the program modules are stored on one
OD while the start system on another.
15.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.
Start of SPG
R1B 315
The bootblock is a small area on the STARTSn disk reserved for the infor-
mation containing a pointer to the so called System Start Information,
SSI, file on the disk.
The SSI contains the disk addresses (tracks and sectors) of the modules
that are to be loaded. Using this information the bootstrap program loads
the modules of the start system into the SP's primary memory.
After a successful loading from STARTSn diskette or OD a message will
be received saying that the bootblock has been read from Index 01 or 02
respectively.
A restart of the node will take place after a few minutes and the printout
SP INITIAL SYSTEM RESTARTED will be obtained. The communica-
tion is started by entering a CTRL-E character from the local terminal.
The loaded software allows commands to be given for:
entering SP initiation mode, formatting the hard disks, preparing the
system defined volumes on the hard disk and loading the SP exchange
data to these volumes
performing the required function change in SP, i.e. loading the SP soft-
ware to the relevant volumes on hard disk and creating the required sys-
tem that will be installed and loaded to the SP
The command ISMCT is given to enter SP initiation mode.
ISMCT is a path building command to the own SP. Its purpose is to stop
the following "dangerous" commands from being used by mistake:
ISMCT must be given first to start an initiating procedure.
In SP initiation mode commands are given for:
formatting or reformatting the hard disk(s). There is no need to specify
faulty sectors manually. Command ISMEI.
creating the volumes according to the work order. Command ISVOI.
Note: Creation of the volumes and the subsequent work can be done when
local terminal is in Buffer mode. If contact is lost in Buffer mode, return to
TTY and enter semicolon and ENTER. Then return to Buffer mode.
The command END is used to exit initiation mode.
The SP_INITD_n disk is now inserted in FD-1 or OD-1 and the command
SYSBT is given to load the SP Exchange Data files on the OMFZLI-
BORD volume.
Note: The above step is only really required when starting both nodes. If
only one node is to be started, then these files will be copied from the
duplicated volume when the node is deblocked.
The next step is to perform the function change in the SP, i.e. loading of
the SP modules and creation and installation of the system.
AXE IO System, IOG20, EN/LZT 101 135
316 R1B
The function change at cold start or start of one node differs somewhat
from a normal function change (as it is described in chapter 14). During
normal function change, the CP is normally working and the SPG must be
fault free - we have a so called large, or ordinary, system. At cold start
the start system is used.
A short description of each function change command is given below as
applicable to the start of an SPG, i.e. a function change in a start system:
The function change is started with the command FCSPI.
<FCSPI;
The node or nodes that are to be loaded with the software are defined next.
Command FCSLS.
In this command, the parameter LNODE (local node) applies to the com-
mand FCSII which is given later. LNODE is used to say in which node's
hard disks the so called System Start Information (SSI) file is to be created
by FCSII. (The SSI contains the disk addresses of the modules to be
loaded and is used for loading the node from it's own hard disk).
The parameters RNODE (remote node) and RSNODE (remote source
node) apply to the command FCSRI, given later, which creates the two
remote installation files (RIF & SSR) for each node. The files are stored
on hard disk in RSNODE.
RNODE is the remote node that is to be loaded and RSNODE is the node
that loads the remote node.
In our case, only one node will later be loaded, node A, and this node must
be able to load node B if required, so the command would be written as:
<FCSLS:LNODE=A,RNODE=B,RSNODE=A;
The next step is to transfer all the software modules from the transport
media (one optical disk or several diskettes TRANSP_n) to the program
volume, in this case PROG_A. Command FCSSL.
The disks are inserted and loaded from FD-1 or OD-1 to destination vol-
ume by the command. The diskettes do not have to be loaded in numerical
order, but this is advisable as it is obviously very important to load all the
TRANSP_n diskettes.
Command example:
<FCSSL:IO=OD-1,IONODE=A;
The TRANSP_01 disk is now inserted again in FD-1 to enable the System
Description File (SDF) to be loaded to the SP's primary memory. Com-
mand FCSDL.
The SDF lists the modules with revision status that are included in the sys-
tem.
It also describes how each module is to be loaded from HD to the SP (i.e.
boot-loaded by the PROM Bootstrap or file-loaded by FMS software once
Start of SPG
R1B 317
this has been booted). In normal IOG20 applications the modules are
boot-loaded. In applications containing extra software - e.g. Remote Meas-
urement Subsystem and Statistics Subsystem - then the extra modules may
possibly be file-loaded. Normally all modules are boot-loaded.
The System Description File also sets values for the deferred constants in
the programs.
Command example:
<FCSDL:IO=OD-1,IONODE=A;
The TRANSP_01 diskette is then removed from FD-1 or OD-1.
The System File (.SYS) is created next. Command FCSSI.
This file is created using the SDF, but it also contains the FMS addresses
(i.e. volumes and files) of the program modules on the hard disk. Thus
information for both boot loading and file loading is contained in the sys-
tem file.
It takes about 10 minutes to create the system (.SYS) file, which is then
stored in PROG_A in our case.
Command example:
<FCSSI;
The next step is to create the Remote Installation Files (RIF and SSR)
for the node. These files are normally created by FCSSI, but in a small sys-
tem they have to be created separately. Command FCSRI.
These files are to allow a node (here called remote source) to reload the
other node (here called remote) when the latter is unable to reload from its
own hard disk. The loading is then via the Inter Computer Bus (ICB).
The remote and remote source nodes are not defined by FCSRI as this
command has no parameters. The remote and remote source nodes are the
nodes defined earlier by the parameters RNODE and RSNODE respec-
tively in the command FCSLS.
The remote node will request the remote source node to load it and thus
this node must contain information saying which system is to be loaded to
the remote node. When RIF is asked by the remote node to be loaded, it
uses that node's designation to determine which system is to be used. The
system name corresponds to a file name that is used as an address to SSR.
SSR is, in effect, the required SSI for the remote node, and can thus be
used to load that node. Thus each node contains an SSI for loading it's own
system and an SSR for loading the remote node's system. The systems are
normally the same, of course, in both nodes, but do not have to be.
The remote installation files take about 10 minutes to create. They are
stored in PROG_A in our case.
Command example:
AXE IO System, IOG20, EN/LZT 101 135
318 R1B
<FCSRI;
The next step is to install the system. Again, installation of a system dur-
ing function change would normally be done by the command FCSSI, but
in a small system has to be performed separately. Command FCSII.
Installing the system implies creating the SSI and storing the address to
this file in the bootblock area on hard disk in the node(s) specified earlier
by parameter LNODE in command FCSLS - node A in our case.
The SSI is needed for all types of reloading, manual or automatic. It con-
tains the absolute addresses (tracks and sectors) of the modules in the sys-
tem.
When the system is later manually loaded using the reset switch, the load-
ing is similar to that of loading the STARTSn diskette mentioned earlier.
The PROM-ed Bootstrap reads the bootblock from Index xx, i.e. from the
PROG_A or PROG_B volumes, and this gives the address to the SSI. The
SSI in its turn gives the absolute addresses to the program modules on the
hard disk so that these can be loaded to the SP.
It takes about 5 minutes to install the system. The SSI file is stored in
PROG_A in our case.
<FCSII;
The function change is now ended using command FCSPE.
<FCSPE;
Once the function change is complete then the software contained in the
newly installed system is reloaded to the SP by flicking the reset switch
twice.
The local terminal connection can now be removed if required.
The node status can now be checked by the normal command IMCSP. The
entry command IMMCT must be used first. Before giving the commands
from a local terminal press carriage return to gain contact with the system.
(The same commands can now be given from any other AT connected to
the IOG).
The standby node status should now be SB - ISOLATED/BLOCKED
The next step would be to deblock the node so that it will be updated from
the executive node.
<BLSNE:SPG=spg,NODE=standby;
During the deblocking the node states will be reloading, diagnosing,
updating, reloaded and normal. During the updating phase all files in the
duplicated volumes will be copied over from the executive node.
It should be noted that the updating must be a large update to transfer over
all the contents of the duplicated volumes from the executive to standby
node.
Start of SPG
R1B 319
15.6 Cold Start or Single Start of Both Nodes
Whenever both nodes are started, all files belonging to the duplicated vol-
ume OMFZLIBORD are loaded from one of the SP_INITD_n diskettes or
from the OD. Other files are later created in this volume by the SP pro-
grams as and when required. (An example is the list of file attributes
defined by INFII).
In the case of starting just one node as described above, all files belonging
to the other duplicated volumes are created during the updating of the node
from the executive node.
In the case of a cold start of an SPG, or when starting both the nodes sin-
gly (reinitialisation of the hard disks in both nodes), all files belonging to
the other duplicated volumes - e.g. the CP backup files - must be defined
by the operation staff. This can be done using a command file or by direct
use of the command INFII. Some comments on these cases are given
below:
As the CP is normally not running at a cold start of an SPG, then the com-
mand INFII and its entry command will have to be entered from the local
terminal or an AT using local mode. The attributes of the defined files will
in this case be written directly on the relevant hard disks of both nodes.
Once the CP is started the file attributes are copied to the CP's file table at
the CP system restart. Data about each defined file is thus stored both in
the CP software and on hard disk.
If the CP is running during reinitialisation of the disks in both nodes, then
the files would be defined in the first node to be started before this is
switched to executive. On starting the second node the files would be cop-
ied over from the executive node during updating.
If the CP is running, files should always be defined from an alphanumeric
terminal connected to a LUM board. In this way the file attributes are writ-
ten directly on the disks and in the CP data.
The command INFUI can always be used to adjust the CP's file table so
that it corresponds to the file attributes defined on hard disk. This com-
mand is always performed automatically at a system restart of the CP.
15.7 Command Initiated Restart of Node
A restart or a reload of a node can be performed by the command SYRSI.
(It is always better to perform restarts/reloads by command instead of
using the reset switch).
<SYRSI:SPG=spg,NODE=node,RANK=SMALL;
or
<SYRSI:SPG=spg,NODE=node,RANK=RELOAD;
AXE IO System, IOG20, EN/LZT 101 135
320 R1B
The above command can also be used to switch nodes in a parallel work-
ing system by ordering the restart in the executive node. If a switch is
desired the command IMEXS is however better.
This will cause a node switch followed by the restart in the new standby
node.
15.8 Chapter Summary
Starting up a node can be divided into the SP Initiation phase and the
Function Change phase
In the SP Initiation phase, the hard disks are formattted, the volumes are
defined and SP Exchange data files are loaded.
In the Function Change phase, the SP, RPV and LUM software are
loaded to the volumes PROG_A/B and a system is created and
installed.
There are two types of systems that can execute in a IOG20 node. The
large or ordinary SP System and the small or Start System.
The ordinary SP System is the system that executes in normal operation
The Start System is used only during start up or during recovery of IO
system stoppage.
The Start System contains only a limited set of functions.
The Start System is not stored on the hard disk but is reloaded directly
from opto disk oe diskettes.
The System Discription File (.SDF) lists the modules with their revi-
sion status that are included in the system.
The System File (.SYS) contains the same information as the SDF but it
also contains the FMS addresses of the program modules on the hard
disk.