Software Configuration Management: DN9770985 Issue 18-0

Software Configuration
Management
DN9770985
Issue 18-0
Confidential
Software Configuration Management
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Solutions and Networks customers only for the purposes of the agreement under
which the document is submitted, and no part of it may be used, reproduced, modified or trans-
mitted in any form or means without the prior written permission of Nokia Solutions and
Networks. The documentation has been prepared to be used by professional and properly
trained personnel, and the customer assumes full responsibility when using it. Nokia Solutions
and Networks welcomes customer comments as part of the process of continuous development
and improvement of the documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Solutions and Networks and the customer.
However, Nokia Solutions and Networks has made all reasonable efforts to ensure that the
instructions contained in the document are adequate and free of material errors and omissions.
Nokia Solutions and Networks will, if deemed necessary by Nokia Solutions and Networks,
explain issues which may not be covered by the document.
Nokia Solutions and Networks will correct errors in this documentation as soon as possible. IN
NO EVENT WILL Nokia Solutions and Networks BE LIABLE FOR ERRORS IN THIS DOCU-
MENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,
DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT
NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS
OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR
THE INFORMATION IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
NSN is a trademark of Nokia Solutions and Networks. Nokia is a registered trademark of Nokia
Corporation. Other product names mentioned in this document may be trademarks of their
respective owners, and they are mentioned for identification purposes only.
Copyright © 2013/12/9 Nokia Solutions and Networks. All rights reserved.
f Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources
of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle
this product and only after having carefully read the safety information applicable to this
product.
The safety information is provided in the Safety Information section in the “Legal, Safety
and Environmental Information” part of this document or documentation set.
Nokia Solutions and Networks is continually striving to reduce the adverse environmental effects
of its products and services. We would like to encourage you as our customers and users to join
us in working towards a cleaner, safer environment. Please recycle product packaging and
follow the recommendations for power use and proper disposal of our products and their compo-
nents.
If you should have questions regarding our Environmental Policy or any of the environmental
services we offer, please contact us at Nokia Solutions and Networks for any additional informa-
tion.
2 Id:0900d80580a4d7c6 DN9770985
Confidential Issue 18-0
Table of Contents
This document has 83 pages.
Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1 Software configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.1 Software configuration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Software builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Software build subdirectories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.2 Status of a SW build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.3 Disk file versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Update deliveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.1 New SW build deliveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.2 Change deliveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.3 Software update compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 Preparing the system for software update . . . . . . . . . . . . . . . . . . . . . . . 20

2.1 Before starting an update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Changing from the old SW build to the new one . . . . . . . . . . . . . . . . . . 21
3 Installing and deploying new software build. . . . . . . . . . . . . . . . . . . . . . 23

3.1 Creating directories and copying the SW build . . . . . . . . . . . . . . . . . . . 23
3.2 Converting and copying files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Creating SW build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Creating trial configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Making necessary modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Cutting over to a new SW build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7 Making final actions in update process . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Installing and deploying a change delivery . . . . . . . . . . . . . . . . . . . . . . 34
5 Updating embedded software of a computer or preprocessor plug-in unit

39
6 Updating embedded software of an ET plug-in unit. . . . . . . . . . . . . . . . 43
7 Updating embedded software of an SW256B plug-in unit . . . . . . . . . . . 46
8 Updating embedded software of an AS7-D plug-in unit. . . . . . . . . . . . . 49
9 Updating embedded software of an SWPRO-C plug-in unit . . . . . . . . . 52
10 Updating embedded software of a DCAR1- A/AB plug-in unit. . . . . . . . 55
11 Updating embedded software of an HWAT-B, CLAB-U/CLAB-UA, CL2TG-

U/CL3TG-U, CL2/CL3TG-UA and CL3TG-V/VA plug-in unit . . . . . . . . . 60
12 Updating embedded software of an ETP plug-in unit . . . . . . . . . . . . . . 66
13 Updating embedded software of an ETIP plug-in unit . . . . . . . . . . . . . . 71
14 Updating firmware of an SCSI hard disk . . . . . . . . . . . . . . . . . . . . . . . . 79
15 Deleting old SW builds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

15.1 Deleting SW build by using the name, status, or directory of the SW build
81
DN9770985 Id:0900d80580a4d7c6 3
Confidential
15.2 Deleting SW build from the SOMAFI . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4 Id:0900d80580a4d7c6 DN9770985
Confidential
List of Figures
Figure 1 Directory structure of the hard disk as seen from the SW build management
point of view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 2 Statuses of a created SW build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 3 The effects of a new SW build deployment on other SW builds . . . . . . 15
Figure 4 The effects of a change delivery deployment on other SW builds of the net-
work element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 5 Creating a trial configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
DN9770985 Id:0900d80580a4d7c6 5
Confidential
List of Tables
Table 1 Subdirectories of WEBFIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 2 eSW updating image names for different ETP types . . . . . . . . . . . . . . . 70
6 Id:0900d80580a4d7c6 DN9770985
Confidential
Software Configuration Management Summary of changes
Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
Changes made between issues 18-0 and 17-1

Chapter Updating embedded software of a DCAR1-A/AB plug-in unit has been added
to the document.
Specific file conversion steps are added to section Converting and copying files.
The procedures in chapter Updating embedded software of a computer or preprocessor
plug-in unit are updated to support CP1D plug-in units.
FTP server can be included also in MCMU is described in chapter Updating embedded
software of an ETP plug-in unit. Also the procedures of updating ETP eSW are updated.
Chapter Updating embedded software of an ETIP plug-in unit is added.

The safety information in this document has been revised on the basis of ANSI Z535.6-
2006 and ISO 3864-2:2004.

Editorial changes have been made.
DN9770985 Id:0900d805808f29ad 7
Confidential
Software configuration management Software Configuration Management
1 Software configuration management

Software configuration management gives an overall picture of how the software build
of a network element is managed and describes the following:
• why there are several software builds in a network element
• what a default build is
• what purpose the different software build statuses have
• how the different software build statuses can be changed
The information given is on a general level. More detailed instructions for updating your
software is delivered with the new software build. Change deliveries also come with
detailed instructions on the installation and deployment of that particular change deliv-
ery. For more information, see instructions on Safecopying.
g Installing a software update requires extensive user knowledge of and long-term user
experience with the DX200 system. In addition, the reader must know the presentation
mode of command descriptions and parameters as used in the DX system operating
instructions. For more information, see MML command syntax in Reading MML
Command Descriptions.
1.1 Software configuration information
g Not all network elements have all of the following features.
The DX200 system includes a Software Configuration Management system which

consists of several files and programs. All software builds of a network element belong
to the system. By using the functions of the Software Configuration Management you
can:
1. Manage software builds:
• create and delete software builds
• manage the statuses of software builds
• select the default software build
• make fallback copies of the software in the network element. For more infor-
mation, see instructions on Safecopying.
2. Install and deploy a new software build or update an existing build, and test new
software before deploying it:
• with trial configuration and cutover
• without trial configuration by restarting the network element
3. Obtain information on the software builds of the network element:
• a list of all builds
• all information on a specified build
• data on the versions of the program blocks loaded in the units
• verification of the build contents
• a list of differences between the builds
4. Manage and install change deliveries and deploy them either:
• by restarting the relevant units or
• by restarting the whole network element
8 Id:0900d805807e6d68 DN9770985
Confidential
Software Configuration Management Software configuration management
MML programs for Software Configuration Management

WN Change delivery handling
WQ Software package management
WS Software package status management
WR Software package deployment handling
These commands are needed in managing the deployment of those SW
build changes that need trial configuration in the network element.
WK Software package fallback handling
For more information, see instructions on Safecopying.
WX Software configuration resource handling
MML programs closely related to Software Configuration Management

DE File conversion handling
DU Disk update handling
IW Disk file and directory handling
IB I/O file backup
DB Database handling
IP Batch Copy Handling
1.2 Software builds

A software build is a collection of programs and files (that is, load modules) operating in
a required system. In the building system of the DX system software, identity data is
defined for both the SW build and the load modules. The identity data of the load
modules is explained in the software control list. The software compiles a MAFILE by
using the data stored in the control list. The MAFILE is transferred to the network
element together with the SW build. The identity data of the load modules are also
shown in the disk file header, from where the programs can read them and compare
them with the data stored in the MAFILE.
A new SW build brought into a network element can be either a new SW delivery, a
system-level upgrade, where the basic technology of the whole system is renewed with
regard to both hardware and software, or a software update. A software update can
again be either a delivery of a new SW build or a change delivery.
The software build stored on the disk of a network element can be:
• Running SW build
A running software build is the build that has been loaded into the unit. Usually, the
running software build has the backup build (BU) status, and simultaneously the
default software build and the active build status as well.
• Active SW build in the directory
In each directory, the active software build is the one whose load modules are
default versions. For more information, see Disk file versions. If there is only one
software build in the directory, it is the active build. If there are two software builds
in the same directory, only one of them is active. The default software build and the
running software build are usually active.
DN9770985 Id:0900d805807e6d68 9
Confidential
g When installing a change delivery, if you give the WSS command (Switch Active
Package in Directory) without restarting the network element, the running SW build
is not active and is not the default build.
• Default SW build
The default software build is loaded into the network element when the network
element is restarted. Thus, the default SW build is the one involved in the initial
loading. The status of the default software build has to be BU, NW, or FB (see Status
of a SW build). Usually, the default build has BU status but, for example, in the trial
configuration of a major software change, the default build is changed to NW build.
When forming the trial configuration, the NW build is set as the default build. Refer-
ence to the default build is maintained on the disk in a directory file that is common
to all SW builds. After loading, all default disk operations are directed to the default
SW build.
g After returning a fallback copy, the SW build has FB status.
Under normal conditions, the running SW build, the active build, and the default build
are the same.
The memory disk of a network element can contain several SW builds at the same time.
Each SW build is stored in its own directory. In a normal situation, there are at least two
SW builds, the running SW build (BU) and the fallback copy (FB). When the system is
being updated, there is also a third SW build, the NW build.
There can be some SW builds in the UT status and UD status stored on the disk of a
network element also. Usually, these are old SW builds that have not been removed
from the system.
The UT build can also be a new one. When installing a change delivery, the new SW
build is stored into the same directory as the running SW build (usually the BU build),
and the new build is set in the UT status. After that, the activity and the status of the
builds have to be switched by using the WSS command.
A software build brought into a network element can be:
• Update SW build
An update SW build is used to update the existing software of a network element.
• Correction SW build
A correction SW build contains corrections of detected faults.
1.2.1 Software build subdirectories

A software build consists of several files stored in different subdirectories:
10 Id:0900d805807e6d68 DN9770985
Confidential
ROOT
DIRECTORY
SCMANA A B C
- SOMAFI (SW Config. Management file)

- files common to all SW builds
SCMANA TMPDIR BLCODE MMDIRE LFILES CONVPR ASWDIR CDTEMP WEBFIL
- only in FB
build
CGI SCRIPT APPS HTDOCS ICONS GRAPHICS
Figure 1 Directory structure of the hard disk as seen from the SW build management
point of view
A, B, and C
These SW build directories contain the subdirectories of a SW build and build-specific
data. You can name the directories freely. However, it is recommended not to give them
names that contain SW build version data or delivery names. Usually, each directory
contains the data of one SW build. During a change delivery deployment, the files of
two SW builds are stored in the same directory.
SCMANA
The Software Configuration Management Directory (SCMANA) contains the files that
are in common use in SW build management. Do not change the name of the directory.
In the normal directory architecture, SW build directory does not contain SCMANA. The
SCMANA only occurs in the FB build when you take a fallback copy of the backup build.
TMPDIR
The Temporary Directory (TMPDIR) is an auxiliary directory for the SW build updating
procedure. The results of conversions are stored in the TMPDIR. When the update is
completed, the directory is deleted. The TMPDIR can be created within an old or a new
directory, depending on the current update situation. Usually, the TMPDIR is created in
a new directory. There can be several TMPDIR directories at the same time.
DN9770985 Id:0900d805807e6d68 11
Confidential
BLCODE
The Boot Loadable Code Directory (BLCODE) contains the program code and the
MAFILE of a SW build. It also contains some files specific to the system level. Do not
change the name of this directory.
MMDIRE
The Man Machine Interface System Directory (MMDIRE) contains the MML programs
(all MML programs of a SW build and their text files). Do not change the name of this
directory.
LFILES
The Loadable Files Directory (LFILES) contains the loadable delivery-specific files and
databases of a SW build. Do not change the name of this directory.
CONVPR
Conversion Program Directory
The Conversion Program Directory (CONVPR) contains the conversion programs. The
conversion programs are needed for the conversion runs performed during SW
updates. Do not change the name of this directory.
ASWDIR
The directory Application Specific Workfile Directory (ASWDIR) contains the work files
of the applications. Files created by the user or by the software are stored in this direc-
tory. The use of this directory varies according to the network element. For example, the
ASWDIR stores the history data of change deliveries. Do not change the name of this
directory.
CDTEMP
The Change Delivery Temporary File Store (CDTEMP) directory is used during the
change delivery installation. Do not change the names of this directory.
WEBFIL
This HTTP Server Root Directory and its subdirectories are used for Web Based Man-
agement of the network element. Some software configuration management actions can
be directed into these directories. Do not change the names of these directories. The
subdirectories of WEBFIL are as follows:
Directory Explanation
CGI Directory for CGI Applications
SCRIPT Directory for scripts related to web-based management
APPS Directory for applications related to web-based manage-
ment
HTDOCS Directory for HTML documents
ICONS Directory for icons used in web-based management
GRAPHICS Directory for graphics used in web-based management
Table 1 Subdirectories of WEBFIL
12 Id:0900d805807e6d68 DN9770985
Confidential
1.2.2 Status of a SW build

The hard disk of a network element can contain several SW builds at the same time.
Each SW build is stored in its own directory. In a normal situation, there are at least two
SW builds, the running SW build (BU) and the fallback copy (FB). When the system is
being updated, there is also a third SW build, the new (NW) build.
There can also be some SW builds in the UT status and UD status stored on the disk of
a network element. Usually, these are old SW builds that have not been removed from
the system.
The UT build can also be a new one. When installing a change delivery, the new SW
build is stored into the same directory as the running SW build (usually the BU build) and
the new build is set in the UT status. After that, the activity and the status of the builds
have to be switched with the WSS command.
Every SW build that is created by using the commands of software configuration man-
agement and stored on a disk has a certain working status. (See Figure Statuses of a
created SW build). The possible statuses are as follows:
BACKUP (BU)
BACKUP is the status of a SW build that is stored on a disk and normally defined as the
active, running SW build. The BU build is usually also the default build which means that
when the network element starts up, the initial loading system usually loads the BU
build. The BU build cannot be destroyed by using the SW build management com-
mands. Only one BU build can be stored on the disk at a time.
FALLBACK (FB)
FALLBACK is the status of a SW build that is a fallback copy of the BU build. In principle,
the FB build is the same as the BU build, except for that its data is from the copying
moment, which means that data updated in the BU build after the copying of the FB build
is missing. When the whole SW build is fallback copied (FULL parameter), that is, the
BU build is copied as the FB build, the status of the old FB build automatically changes
into UT. When a fallback copy is made either of all files marked DATA in the MAFILE or
only of changed files (ARCHIVE), the files are copied on top of the previous FB build.
You can make the system return to the FB build, when necessary, by using the WSD
command. The use of the FB build has to be resumed, for example, when the BU build
becomes corrupted.
Only one SW build on the disk can be in the FB status at a time.
NEW (NW)
NEW is the status of a new SW build on the disk. The NW build has been brought into
the network element first to be tested and then to be deployed. Only one SW build on
the disk can have the NW status at a time.
UNTITLED (UT)
UNTITLED is the status of a SW build stored on a disk. The system can contain several
SW builds that are in the UT status, and they can be stored in their own directories.
Usually, the SW builds which have the UT status are old ones, and they can be deleted.
However, often the change delivery introduces the update as an UT build in the same
directory as the BU build.
DN9770985 Id:0900d805807e6d68 13
Confidential
UNDEFINED (UD)
All the above mentioned SW builds have been created. There can also be some uncre-
ated SW builds on the disk. The status of an uncreated SW build is undefined.
SW builds that are in the UD status can only be referred to on the basis of the directory.
If there is more than one uncreated SW build in the directory, you need to give more
information to specify the build. When a new uncreated SW update build is copied to the
hard disk, the system automatically sets it to the UD status because the system needs
some way of defining it. The SW builds that are in the UD status are only visible in the
output commands. Several SW builds can be in the UD status on the disk at the same
time.
Changing the status of a SW build

You can change the status of SW builds by using the commands of Software Package
Status Handling,WS command group. The best time to change the status of SW builds
is when the SW is being updated. Also, when a new FB copy is being made of the whole
BU build (FULL parameter), the status of the previous FB build changes to UT (WKS
command).
(Note: the WKS command creates a new SW build,

the status of BU build does not change)
Fallback copy (WKS)
Switch active package (WSS)
FB BU
Rollback statuses (WSR)
Rollback Change
statuses of status
(WSR) (WSC)
Fallback copy (WKS) Change of status (WSC)

with parameter
NW Switch active package (WSS) UT
FULL
Rollback statuses (WSR)
Figure 2 Statuses of a created SW build
Commands related to the states of SW builds

For instructions on the use of the commands presented in Figure Statuses of a created
SW build, see:
WKS Start fallback copying
WSC Change status of two created packages
14 Id:0900d805807e6d68 DN9770985
Confidential
WSS Switch active package in directory

WSR Rollback statuses of created packages.
In a redundant HLR, however, the WSD command can be used to activate even UT SW
builds directly. This use of the command is specific to the redundant HLR only.
Status of a SW build during a software update

The following two figures illustrate how the SW build status, its activity, and the default
build data change in update situations. The figures also show which build is run in each
situation.
• Deployment of a new SW build
The following figure shows the status of the SW builds stored in different directories,
when a new SW build is being deployed in the network element.
Situation Command Directory Active Traffic Trial

Status Default side side
Normal situation A NW x - - -
(a new SW build has been
created in the directory WQC B BU x x x -
with command WQC) C FB x - - -
OMU is added to the trial A NW x x - x
configuration (command WRA)
(default build becomes NW) WRA B BU x x x -
All other units are added to
trial configuration C FB x - - -
Cutover A NW x x x -
WRS B BU x - - x
C FB x - - -
Completing the trial A NW x x x -
configuration
WRC B BU x - - -
C FB x - - -
Change of status A BU x x x -
WSC B NW x - - -
C FB x - - -
Figure 3 The effects of a new SW build deployment on other SW builds
g The figure shows a situation where the network element has two OMUs. Adding an OMU
in the trial configuration (the WRA command), automatically makes the NW build the
default build in the current OMU, and the BU remains the default build of the traffic side
OMU. If the system has only one OMU and the OMU is added to the trial configuration,
only the NW is the default build.
• Deployment of a change delivery

The following figure shows the status of the SW builds stored in different directories
when a change delivery is being installed in the same directory as the BU build.
DN9770985 Id:0900d805807e6d68 15
Confidential
Situation Command Directory Active Running

Status Default
Normal situation A NW x - -
B BU x x x
C FB x - -
Installing a change delivery to the A NW x - -
same directory as the BU build (B) WNA
and creating a SW build B BU x x x
and UT - - -
(Change delivery could also be installed WQC
in the directory of the NW build) C FB x - -
Switch the active SW build A NW x - -
(BU becomes UT and UT becomes BU)
B UT - - x
WSS
BU x x -
C FB x - -
Deploy a change delivery by restarting A NW x - -
the selected units and by updating USU, USC,
the new SW build identity in the units WNJ and B UT - - -
BU x x x
UST
C FB x - -
Delete the old SW build A NW x - -
(the UT build from the B directory)
which brings the system back to the WQD B BU x x x
normal situation C FB x - -
Figure 4 The effects of a change delivery deployment on other SW builds of the

network element
1.2.3 Disk file versions

There can be several files of the same name in a directory, and the files have different
disk version numbers. In a SW build directory, however, the maximum number of disk
versions is two by default, and one of the versions is the default version.
It is not advisable to change the default value (2) because Software Configuration Man-
agement uses the file identity data in handling the SW builds, and it cannot recognise
two different disk files if they have the same name and the same identity code and
neither of them is the default version. The system is able to separate the default version
and the non-default versions from each other. The I/O system recognises both disk ver-
sions. The loading system and the disk update system recognise the default version
only.
The main purpose of the disk file versioning is to make it possible to introduce small
(compatible) software updates to a network element so that only a minimal amount of
disturbance is caused in the traffic. This means that the software that will be changed is
copied to the same directory as the currently loaded SW build, then the new software is
defined as the default version in the directory, and finally the changed parts are loaded
in the network element.
When the SW build is being changed, Software Configuration Management sets the
default version of the load module by using the identity data of the load module. This
means that you do not need to handle the disk version data of the files, since the
software manages them automatically.
16 Id:0900d805807e6d68 DN9770985
Confidential
1.3 Update deliveries

A software update is a general term referring to a software change deployed in a
network element that has already been delivered to a telecommunications operator. The
largest possible software update changes all the components of a SW build. The
smallest possible software update changes only one component of the software.
The types of software updates can be the following:
1. New SW build deliveries
• release-level upgrades (major updates)
• correction updates (minor updates)
• feature-level upgrades (minor updates)
2. Change deliveries
• correction updates (minor updates)
• feature-level upgrades (minor updates)
The deployment of a software update is affected by the functional compatibility and file
compatibility of the update and the SW build currently running in the network element.
From the software configuration management point of view, the new software is either
compatible or non-compatible with the old software. The files in the SW build are either
compatible or require conversion.
Update deliveries are delivered on removable media, for example, optical disks can be
used for this purpose.
1.3.1 New SW build deliveries

A new SW build can be delivered either as a completely new build, which results in a
release-level upgrade (major), or as an update to the old SW build (minor) meaning that
the old SW build can be copied as the base for the new build. Usually, the delivery of a
new SW build has the following characteristics:
• requires file conversion
• is brought as a NW build in a directory of its own
• is done through trial configuration
• causes interruptions in traffic
1.3.2 Change deliveries

A change delivery is usually preceded by a change delivery request. A change delivery
consists of one or more change notes. A change note explains the difference between
the old and the new product, the reason for the change, and the effects of the change
on the functions of the product. The change delivery is usually installed by using
commands specially designed for this purpose.
Sometimes in an exceptional situation a minor software update has to be introduced
resembling a change delivery in a network element. It has to be copied directly to the
same directory as the old SW build and set as the default version. These kinds of deliv-
eries are used in emergency situations, and they usually cause disturbance for SW con-
figuration management and some parts of the change delivery.
The characteristics of change delivery are the following:
• It is a correction of a detected fault, or introduction of a new feature to the existing
software.
DN9770985 Id:0900d805807e6d68 17
Confidential
• It contains new load modules, operating instructions, a change delivery description

list, and instructions for installation.
• It does not cause interrupts in traffic if it is warm-up compatible. However, if the
update requires a restart of the network element, there can be an interruption in the
traffic.
• It is functionally either warm-up compatible or requires the network element to be
restarted.
• It is installed in the running BU build, and file conversions are not necessary. A small
software update resembling a change delivery can also be made to the NW build,
for example, to aid the installation of a new SW build delivery. If there are no NW
builds running, it is possible to make a file conversion, if necessary. File conversions
are not allowed in running NW builds.
• It is created as a UT build into the directory of a BU build (or NW build). If that direc-
tory already contains a UT build, you first have to delete it by using the WQD
command. When updating the software, it is possible to have more than one version
of each file in the directory of the BU build (or NW build), but this is not recom-
mended.
Main installation tasks

Main installation tasks for a change delivery are the following:
• Copying the files for a change delivery to the CDTEMP directory of the current
software build.
• Making the actual installation by one MML command, which means that new load
modules are copied to right directories, new MAFILE (if not included in the delivery)
is created and the history information is updated. Several change deliveries can be
installed with one MML command.
• Creating a new software build for a change delivery with an MML command to the
same directory as the old build.
• Activating the new build with an MML command, in which new load modules are
changed from non-default to default versions.
• Activating the changes by restarting the corresponding units. New build id is updated
in the units during restarts.
• Updating the package id in the rest of the units by MML commands.
• Deleting the old build if the installed change delivery works properly.
1.3.3 Software update compatibility

In the perspective of SW configuration management, there are two kinds of SW updates:
• Compatible SW updates
• Non-compatible SW updates
There can be, however, some intermediate forms of non-compatible SW updates, which
can be used, for example, with the methods of installing a compatible SW update. For
detailed instructions, see the installation operating instructions of the relevant update
delivery.
Compatible SW update
The new software is purely functional and data-compatible. Taking compatible SW
update into use does not cause traffic disturbances. Telecommunication connections
can be created from computer units running the old software build to computer units
18 Id:0900d805807e6d68 DN9770985
Confidential
running the new software build. The update process is executed unit by unit by restarting
and switching over the units. During the software update installation, the old and the new
build can communicate with each other.
Non-compatible SW update
The new software is not functional or data-compatible in some parts of the software.
Non-compatible SW update has to be used simultaneously in all necessary computer
units. This requires restarting the whole system. Non-compatible software update
causes disturbances or total breakdown in the operating state (including telecommuni-
cation connections) of the network element. During the software update installation, the
old and the new software cannot communicate with each other.
DN9770985 Id:0900d805807e6d68 19
Confidential
Preparing the system for software update Software Configuration Management
2 Preparing the system for software update

A software update is a general term referring to a software change deployed in a
network element that has already been delivered to a telecommunications operator. The
largest possible software update is the one that changes all the components of a SW
build. The smallest possible software update changes only one component.
g The prerequisites are different for each release. Only the basic prerequisites that apply
to all updates are presented here.
2.1 Before starting an update

It is advisable to carry out the update during a period of low traffic.
Before starting an update, pay attention to the following issues:
Steps
1 Check the alarms (AHO)

Output the active alarms:
ZAHO;
If there are active alarms, find out what caused them. There must not be any active
alarms in the network element when you start the update.
2 Print out the old data

Print out data concerning the old SW build to make it easier to look at the situation after-
wards.
3 Make sure that the fallback copy (FB) of the BU build is up-to-date (WQH)
Use the WQH command to output the history data on the SW build changes.
Specify in the parameter the date from which the history data has to be reported. The
WQO command outputs data concerning the specified SW build.
4 Check the working states of the units (USI)

The computer units must be in normal working states (USI command), either in the WO-
EX or SP-EX state, and there must not be any FLTY (faulty unit) additional information.
The units can also be in the SE-NH state if the update does not effect those units.
For more information, see Recovery and Unit Work State Administration.
5 Make sure that the BU build is the default build (WQO)

Make sure that the BU build is the default build and that it has been loaded in all units:
ZWQO:CR;
In the printout, Y is marked in the Default column by the default SW build.
ZWQO:RUN;
20 Id:0900d8058050484f DN9770985
Confidential
Software Configuration Management Preparing the system for software update
If not all units have the default build loaded, give the reset command for those units that
have some other build loaded.
g Instead of using reset, you can first try the WNJ command, which updates in all units the
SW build identity that the OMU is using.
6 Check if the disk of the network element has space for a new build (WQO)
Check how much space there is on the disk:
ZWQO:EX;
You can free more space by deleting old builds that are not used any more, using the
WQD command.
Further information
For more instructions on software configuration management, see Installing and
deploying a change delivery and Deleting old SW builds.
2.2 Changing from the old SW build to the new one

Follow the steps below to change the old SW build to a new one.
Steps
1 Copy the new load modules in the directory as non-default versions (IWY and IBC)
Usually the load modules are copied as non-default versions when updating an old SW
build.
A disk file can be copied as the default version only in a created SW build. The disk file
has to be copied as a default, for example, when a last-minute conversion is performed
during the testing phase of the SW build delivery just before the cutover. It must be
copied in order to warm up the new SW build on the trial so that it recognises also the
updates that occurred on the traffic side.
2 Create the SW build (WQC)

Use the WQC command.
During the installation of a new software build delivery, the new build is created on the
disk as the NW build. The system automatically takes care of all checkings needed in
the creation process.
3 Set the SW build as the default build (WSD or WRA)

Set the SW build as the default build either by:
• using the select default software package WSD command, which is directed at the
SW build stored in the new directory or
• creating a trial configuration with the WRA command; testing the new SW build and
if the software functions correctly perform a cutover.
In both cases, the NW build is changed to the BU status (WSC command), and the
previous BU build assumes the NW status.
DN9770985 Id:0900d8058050484f 21
Confidential
Preparing the system for software update Software Configuration Management
The default build data applies to the whole SW build, and it is stored in the SOMAFI. The
I/O system uses this data when it refers to a disk directory.
Further information
For more instructions on software configuration management, see Installing and deploy-
ing new software build, Installing and deploying a change delivery, Deleting old SW
builds.
22 Id:0900d8058050484f DN9770985
Confidential
Software Configuration Management Installing and deploying new software build
3 Installing and deploying new software build

g Detailed instructions for making a software update are given in the installation manuals
of the relevant SW build. The instructions given here are examples, and they only
contain the basics of the update process. All software updates do not necessarily
include all the phases described here, and on the other hand, some updates require
more phases.
3.1 Creating directories and copying the SW build

The new SW build is usually copied to the network element at the site, and the new build
is introduced into the network element on DAT cassettes or removable media like USB
flash drives or MO-disks.
For more information, see Software builds.
When a whole new software build is delivered, the SW build is copied into the network
element as follows:
Steps
1 Copy the SW build and its directories to the network element

a) Copy the SW build and its directories from the DAT tape (IWY and IBC).
ZIWY:S:SYSTEM=<local>,UNIT=OMU,PATH=/,DRIVE=<DAT-drive
identifier e.g. CTU-N0>;
ZIWY:D:SYSTEM=<local>,UNIT=OMU,PATH=/,DRIVE=<system disk
e.g.WDU-S>;
ZIBC::SYSTEM=ALL,UNIT=ALL,SSN=<name of source file group>;
You do not need to create the directories separately, since the DAT tape already
includes a directory structure that is automatically copied into the network element
together with the SW build.
b) Copy the SW build and its directories from removable media like USB flash drives
or MO-disks (IWL).
• Create a new directory and subdirectories for it.
Create first a new directory and then subdirectories BLCODE, LFILES,
MMDIRE, CONVPR and ASWDIR in it.
Create also a temporary TMPDIR directory for conversions, if a temporary direc-
tory is used in the update process:
ZIWL::WSB,NODEF:<path>:<new_directory>,800,2,XY;
• Copy the SW build (commands IWY and IBC).
Copy the SW build, for example, the 'standard' build, into a new directory on the
system disk:
ZIWY:S:UNIT=OMU,PATH=/<subdirectory name>,DRIVE=<removable
drive identifier e.g. FDU-N0 or UMS-N0>;
ZIWY:D:UNIT=OMU,PATH=/<new directory>/<subdirectory name>,
DRIVE=WDU-S;
ZIBC;
If the update process includes conversions from the old SW build CONVPR
directory, copy the relevant conversions there with IWY and IBC commands.
DN9770985 Id:0900d805808f29af 23
Confidential
Installing and deploying new software build Software Configuration Management
2 Copy other necessary release-specific files (IWY and IBC)

ZIWY;
ZIBC;
3 Copy all directories (IWY and IBC)

Copy all directories, except for the LFILES directory, from the system side to the backup
side.
ZIWY:S:UNIT=OMU,PATH=/<new directory>/<subdirectory name>,
DRIVE=WDU-S; (System)
ZIWY:D:UNIT=OMU,PATH=/<new directory>/<subdirectory name>,
DRIVE=WDU-B; (Backup)
ZIBC;
4 Copy other files (IWY and IBC)

If the TMPDIR is used in the update process, copy both the release-specific parameter
files needed for conversions and the other files from the new directory to the temporary
directory. Files to be copied are, for example, the MAFILE, MEFILE and DXPFIL. In
theIBC command parameter, you should specify the name of the file you want to copy
(or at least a part of the name, for example, MAF%).
ZIWY:S:UNIT=OMU,PATH=/<new
directory>/<subdirectory_name>,DRIVE=WDU-S;
ZIWY:D:UNIT=OMU,PATH=/<new directory>/TMPDIR,DRIVE=WDU-S;
ZIBC:,,MAF%,%;
5 Check the lengths of the DXPFILGX files (LP and PD)

Check the lengths of the DXPFILGX files stored in units that have disks, use the service
terminal commands LP and PD. The DXPFILGX includes, for example, the following file
lengths:
ZLP:P,MRS;
ZPD:LFILES;
If the PD command reports differences in file lengths, you have to find out what causes
the differences. If the differences cause no problems, update the contents of the
DXPFILGX file according to the actual file lengths:
ZPDU:LFILES;
6 Print the Readme.txt file (IWY and IBT)

Print the Readme.txt file if the MMDIRE directory contains one. The Readme file
contains information for example on how much memory each unit needs in order to
operate properly with the new SW build.
ZIWY:S:PATH=<new directory>,MMDIRE;
ZIBT:WDU,0,README,TXT,,200,,A;
24 Id:0900d805808f29af DN9770985
Confidential
3.2 Converting and copying files

Steps
1 Copy the new SW build files (IWY and IBC)

Copy the new SW build files that will be needed in the conversion into the TMPDIR
working directory of the system disk as default versions (MAFILE, MEFILE, DXPFIL,
NECONF and the new file templates, if necessary). In the following example, we copy
the MAFILE from the BLCODE directory to the working directory:
ZIWY:S:UNIT=OMU,PATH=/<new directory>/BLCODE,DRIVE=WDU-S;
ZIBC:,,MAFILEGX,IMG;
2 Prevent updates (DUP, DBP)

Prevent file updates to disk in all units and prevent all database updates (if databases
also need conversion):
ZDUP:<unit>;
ZDBP:<name of data base>,0;
3 Copy the necessary files from the old SW build to the new one
•
Use the copy command queue (IDE), if the system has one
Run the command queue IDE
Usually all other files are copied using the copy command queue, which means that
you have to specify the copy command queue you want to use.
Use PAR1 to define which directory is the source of the copying and PAR2 to specify
the destination directory.
ZIDE:,WDU,=,COPY<name of copy command-queue>:: PAR1="/old
directory/LFILES",PAR2="/new directory/LFILES".
The copy command queue can, for example, be as follows:
/* COPY COMMAND QUEUE FIN3 -> FIN4 RSU,210 */
/* SETTING PATHS */
ZIWY:S:UNIT=OMU,PATH=*1,DRIVE=WDU_S; (*1 refers to PAR1)
ZIWY:D:UNIT=OMU,PATH=*2,DRIVE=WDU_S; (*2 refers to PAR2)
* COPYING */
EM:ALEXTEGX; DEM:ALLAMPGX;
...
EC:DBD001GX; DEC:DBD002GX;
...
OR
DN9770985 Id:0900d805808f29af 25
Confidential
• Copy manually the necessary file (IWY and IBC)

If the system does not have the copy command queue (IDE), copy manually the
necessary files from the old SW build to the new one.
ZIWY:S:UNIT=OMU,PATH=/<old_directory>/<subdirectory name>,
DRIVE=WDU-S;
ZIWY:D:UNIT=OMU,PATH=/<new_directory>/<subdirectory name>,
DRIVE=WDU-S;
ZIBC:,,<name of the file to be copied>,%;
4 Run the necessary file conversions or the conversion command queue (IDE)
The conversion is run from the source SW build (usually BU) to the files in the working
directory (TMPDIR). For example:
ZIDE:WDU,0,<name of copy command queue>::PAR1="/<old
directory>/LFILES", PAR2="/<new_directory>/TMPDIR";
5 Run the database conversions (IWY, DEE)

ZIWY:S:UNIT=OMU,PATH=/<old directory>/<subdirectory
name>,DRIVE=WDU-S;
ZDEE:,:CONVPR,,:<name of conversion>:,LPTx;
6 Copy the other files (DEM)

Copy also those files, which do not need conversion, from the source build to the tem-
porary work directory with the command DEM.
ZDEM:<file name>;
7 Allow updating of both files and databases to the disk (DUR, DBR)
ZDUR:<unit>;
ZDBR:<database name>,0;
8 Copy the converted files, if using TMPDIR

If the TMPDIR directory was used in the conversion, copy the converted files from the
working directory to the LFILES directory of the new SW build. If the TMPDIR was not
used in the conversion, the files are already in the LFILES directory.
ZIWY:S:UNIT=OMU,PATH=/<new directory>/TMPDIR,DRIVE=WDU-S;
ZIWY:D:UNIT=OMU,PATH=/<new directory>/LFILES,DRIVE=WDU-S;
9 Copy the LFILES subdirectory (IWY)

Copy the LFILES subdirectory of the new directory from the system disk to the backup
disk.
ZIWY:S:UNIT=OMU,PATH=/<new directory>/LFILES,DRIVE=WDU-S;
(System)
26 Id:0900d805808f29af DN9770985
Confidential
ZIWY:D:UNIT=OMU,PATH=/<new directory>/LFILES,DRIVE=WDU-B;
(Backup)
ZIBC;
10 Destroy all files except the default files from the subdirectories in the new direc-
tory (IWD)
ZIWD:,:WSB,NODEF:<new directory>,<subdirectory name>:%,%,FF;
3.3 Creating SW build

Steps
1 Create the SW build and set it in the NW status (WQC)

The status of a new build has to be NEW (NW), because otherwise you cannot create a
trial configuration.
ZWQC:NAME=<new SW build>,PAID=<SW build identity>, DIRE=<new
directory>,STAT=NW,ENVI=<SW build environment>, DELI=<name and
version of the delivery>;
Further information
If the network element already has an NW build that is not needed any more, you can
destroy the build by using the WQD command, and then create a new SW build in the NW
status.
If the network element already has an NW build and you want to keep it, create the
newest build first in the UT status. In this case, you do not specify the status in the WQC
command, but the system automatically sets the new build in the UT status after creating
it.
When the creation is completed, you can exchange the statuses of the NW and the UT
build by using the WSC command.
3.4 Creating trial configuration

Before you start
1. Before you form a trial configuration, make sure that the units are in normal states
and copy or convert the PCMCON and SCDFLE files from the old SW build to the
new one. If the files have not been changed, copy them either by using the IWY and
IBC commands or the DEM command.
If the files have been changed, convert them by using the DEE command.
2. Create the trial configuration. The trial configuration can be created unit by unit, or
by using the default configuration (basic trial configuration) suggested by the system
(use parameter BASE). Usually the basic trial configuration is used.
DN9770985 Id:0900d805808f29af 27
Confidential
Steps
1 Add the OMU to the trial configuration (WRA)

Before the command is given, make sure that the default build has the BU status.
ZWRA:OMU;
The WRA command makes the NW build the default build and the OMU is restarted.
2 Add the backup main memory (MCHU 1) to the trial configuration (WRA)
ZWRA:MCHU,1;
Wait that the CM is up and running before you continue.
3 Add units to the trial configuration (WRA)

Next, add to the trial configuration the units which you want to add separately, without
using the basic trial configuration. (If there is no need for adding the units separately, it
is possible to give the command ZWRA:BASE; at this point.)
The unit is selected depending on which external connections you want to maintain
during the testing period. Leave on the traffic side the units of the external connections
that you want to keep.
ZWRA:<unit type>,<unit index>;
4 Add the rest of the units to the trial configuration (WRA)

ZWRA:BASE;
Further information
Add the units in the trial configuration in the order which is shown in figure Creating a
trial configuration.
28 Id:0900d805808f29af DN9770985
Confidential
State/command Traffic side
WO SP (spare)
Normal situation before a OMU

trial configuration is created CM-0 CM-1
<unit>-0 <unit>-2
<unit>-1
Trial side
After OMU has been added to CM-0 CM-1

trial side <unit>-0 <unit>-2 OMU
WRA:OMU; <unit>-1
After CM has been added to CM-0

trial side <unit>-0 <unit>-2 OMU
<unit>-1 CM-1
WRA:CM,1;
After the selected unit has been CM-0 OMU

added to trial side <unit>-0 CM-1
<unit>-1 <unit>-2
WRA:<unit type>,2;
Finally, add all the remaining units to the trial configuration

by using the base trial configuration.
(In the figure, there are no more units.)
Figure 5 Creating a trial configuration

You can also form a trial configuration by separately adding all selected units to the trial
configuration. Remember here, that when adding a N+1 backed up signalling unit to the
trial side, you can define the unit (on the traffic side in this phase) whose lines the sig-
nalling unit will start serving after a cutover. This makes the cutover happen more quickly
in that unit and its lines will also be back in the traffic transmitting mode sooner.
If necessary, you can remove units from the trial configuration. For example, when you
want to remove the Marker and Charging unit (MCHU-1) from the trial side, give the
command:
ZWRR:MCHU,1;
3.5 Making necessary modifications

Steps
1 Make all necessary changes to the new SW build in the trial configuration
Often some new features are introduced when changing from an old SW build to a new
one, and the update may cause changes that demand modifications in the new SW
build. You should make these changes when the new SW build is tested in the trial con-
figuration.
Before you carry out the update, print the same data as in the preparations phase, and
compare them with each other.
Make all necessary updates.
DN9770985 Id:0900d805808f29af 29
Confidential
2 Test the new SW build

Test the new SW build (MML output commands, partial unit diagnostics, etc.)
Remember that the equipment management (WT) commands must not be given while
the system has a trial configuration, because the configuration has to remain the same
on both, the traffic side and the trial side.
During the trial configuration, complete diagnostics cannot be run on a unit if the unit has
plug-in units with PCM line interfaces. This is because the plug-in units have not been
connected to the active switching network in this situation. But those parts of the diag-
nostics that do not test the interfaces operate in a normal manner.
3 If necessary, you can remove a unit from the trial configuration (WRR)
• Remove a unit from the trial configuration.
ZWRR:<unit type>;
4 You can also interrupt the testing and delete the trial configuration
If necessary, you can also interrupt the testing and delete the trial configuration (for
example, if faults occur on the traffic side).
Steps
a Destroy the trial configuration (WRD)

Note that you can give the WRD command only on the MML terminal of the trial side.
In addition, the trial side OMU has to have the NEWP additional information set. You
can perform the command in a controlled manner or in a forced manner. By default,
the destroying is carried out in a controlled manner, and this setting needs no
parameters.
ZWRD;
b Enter the 'complete new configuration' (WRC)

Enter the 'complete new configuration' command (WRC) to make sure that all addi-
tional information set during the trial configuration are zeroed and that the traffic side
is completed with the units transferred from the trial side.
ZWRC;
c Check that the modifying of disk is not prevented (DUD)

ZDUD:<unit to be checked>,<unit index>;
d Form the trial configuration again

If you want to form the trial configuration again, you have to first convert the
PCMCON and SCDFLE files (DEE) or copy them with the DEM command from the
BU build to the directory of the new SW build.
After this you can continue fromCreating trial configuration.
Further information
g Testing of an SW build stops only when the new software is deployed and taken into use
or if the trial configuration is deleted.
30 Id:0900d805808f29af DN9770985
Confidential
3.6 Cutting over to a new SW build

In the cutover process the trial side becomes the traffic side and the old traffic side turns
into the trial side.
Steps
1 Perform the cutover (WRS)

Note that you have to give the WRS command on the MML terminal of the trial side. The
OMU has to have the NEWP additional information set.
When you give this command, the traffic will be interrupted. After a short outage, the
network element starts handling teletraffic by using the new software.
ZWRS;
Expected outcome
After the command is given and the cutover has been performed, the new software
becomes responsible for handling actual telecommunications traffic in the network
element. In case of duplicated units, the responsibility is transferred from one unit to the
other, but if the unit type is backed up using the N+1 method, the new software is loaded
in the N units and only the unit which has NOSW additional information keeps the old
software.
2 Test that the new software operates correctly

Test that the new software operates correctly when transmitting traffic. Make test calls
and check that analyses, charging, and general traffic function as they should; you can
make printouts, for instance.
3 Transfer the rest of the units to the traffic side (WRC)

When you have made sure that the new software functions faultlessly, and that you can
stop the testing and clear the trial configuration, transfer the rest of the units to the traffic
side.
ZWRC;
g You can return to using the old SW build (command WSD), in which case the default build
changes and the whole system is restarted.
ZWSD:STAT=BU;
4 Return to the old build, if necessary

If the new software does not function well enough, return to the old build. Then you can
continue testing the new software or stop the testing, if that is necessary.
a) Cancel the cutover and return to the old software (WRO)
ZWRO;
b) Continue testing the new software
If necessary, continue testing the new software (test the MML output commands,
partial diagnostics in the units, etc.).
DN9770985 Id:0900d805808f29af 31
Confidential
c) If you stop the testing, destroy the trial configuration (WRD)

ZWRD;
d) Give the complete configuration command (WRC)
Finally, give the complete configuration command, which makes sure that all addi-
tional information that appeared during the trial phase will be deleted:
ZWRC;
3.7 Making final actions in update process

Preparing the system for software update
Installing and deploying a change delivery
Deleting old SW builds
Steps
1 Exchange the BU and NW statuses (WSC)

ZWSC:STAT=BU:NAME=<new SW build>;
2 Make a fallback copy

See instructions on safecopying.
3 Verify the SW build (WQB

Verify the SW build, that is check with command WQB that a comparison can be run.
4 Check that disk updating is not prevented in any unit (DUD)

ZDUD:<unit to be checked>;
5 Check the time slot states in the external routes (RCI)

Use the RCI command.
6 If you have used a temporary directory, destroy it (IWD, IWM)

ZIWD:,:WS,NODEF:<new directory>,TMPDIR:%,%;
ZIWM:,:WS,NODEF:<new directory>:TMPDIR;
7 Destroy all non-default versions (IWD)

Destroy all non-default versions from the subdirectories (CONVPR,MMDIRE, BLCODE
and LFILES) of the new directory:
ZIWD:,:WSB,NODEF:<new directory>,<subdirectory name>:%,%,FF;
32 Id:0900d805808f29af DN9770985
Confidential
8 Test that changeovers function properly

If you want you can test that changeovers function properly. Change the states of some
units.
ZUSC:<unit type>, <unit index>: <working state>;
9 Destroy the old SW build (WQD)

Destroy the old SW build (currently having status NW) if it is not needed any more.
ZWQD:STAT=NW: MAFILE;
Further information
When the LAN device integration feature is used, update the Ethernet LAN switches
according to the instructions in Updating the software package of a LAN switch in Inte-
grated LAN Administration. Otherwise, see the instructions in Updating software image
to ESA12, ESA24, ESB20, ESB20-A, and ESB26 Ethernet switches.
DN9770985 Id:0900d805808f29af 33
Confidential
Installing and deploying a change delivery Software Configuration Management
4 Installing and deploying a change delivery

g You can find detailed instructions for the deployment of a change delivery in the instal-
lation instructions of the relevant change delivery. Instructions given here are examples
and they only contain the basics of a deployment process. Not all change deliveries
include all the phases described here, and some updates require more phases.
Steps

2 If there is no CDTEMP directory in the directory of the running SW build, create it

(IWL)
ZIWL::WSB::CDTEMP,800,2,XY;
3 Copy the update software in the CDTEMP directory of the running SW build
Before you start

It is possible to install more than one change delivery at a time. Remember, however,
that they must be installed in the same order as they were copied to the CDTEMP direc-
tory. Therefore, make sure that the change deliveries are copied to the CDTEMP direc-
tory in the right order.
If, however, you are installing several change deliveries which have MAFILEs included,
they have to be installed separately.
a) Define the subdirectories on the removable media as the source of copying (S) by
using the IWY command.
If you copy from removable media, define the subdirectories on the removable
media as the source of copying (S):
ZIWY:S:UNIT=OMU,PATH=/,DRIVE=<removable media like FDU-N0 or
UMS-N0>;
Define the CDTEMP directory as the destination (D):
ZIWY:D:UNIT=OMU,PATH=-CDTEMP,DRIVE=WDU-S;
Copy the files:
ZIBC;
b) Copy the files from DAT tapes (IPS).
If you copy from DAT tapes, use the IPS command to copy the files from the tape
to the disk.
ZIPS:<”source unit”>,CTU-<x>,/,,<source set name>:OMU,WDU-S,-
CDTEMP,,,:DIR=INC;
4 Delete the other SW build from the directory, if needed (WQD)

ZWQD:NAME=<SW build name>:MAFILE;
5 Verify the SW build (WQB)

ZWQB:NAME=<SW build name>;
34 Id:0900d805807dc142 DN9770985
Confidential
Software Configuration Management Installing and deploying a change delivery
6 Install the change delivery (WNA)

You can enter more than one index (separated with the '&' character) if you install
several change deliveries at the same time.
ZWNA:NAME=<destination package name>:<change delivery index>;
7 Create the SW build in the same directory as the running build (WQC)
Give the new build a name that is different from the name of the running build. Set the
status of the new build to 'UT'.
ZWQC:NAME=<name of new SW build>,DIRE=<destination build
directory>,STAT=UT;
8 Change the active build (WSS)

The new build (whose status has been changed to 'UT') becomes the active build in the
directory and its status changes from UT to BU (or NW).
ZWSS:NAME=<name of new SW build>;
g With the WNJ MML command, it is possible to check the width of the change delivery:
ZWNJ:CHECK:STAT=<BU or NW>;
With this command, you can check which units must be restarted to load the changed
load modules and in which units it is enough only to update the package identifier.
9 Introduce the NEWP additional information (new package unit) into the OMU
(UST)
The NEWP additional information is used when the new SW build is loaded into the units
and when the units are restarted. The NEWP information controls the loading process
so that the new software is loaded into a unit from a unit that has the NEWP additional
information set on, for example, from the OMU, CM, or spare CM. The new software is
always loaded from the unit that has been defined as the loading source for that partic-
ular unit.
ZUST:OMU:S-NEWP;
10 Set the NEWP additional information to the spare side of those units that are
affected by the change delivery (UST)
ZUST:CM,1:S-NEWP;
11 Load the new SW build into the network element unit by unit (USU, USC)
Observe the network element functions after each loading procedure and after each swi-
tchover always make sure that the units using the new software operate properly before
you continue the deployment process. If long-term disturbances occur in the operation
of the network element, return to the old software.
a) Restart the spare side OMU (USU)
ZUSU:OMU,1:C=DSK;
DN9770985 Id:0900d805807dc142 35
Confidential
b) Perform the switchover of the OMU (USC)

ZUSC:OMU,1:WO;
c) Restart the spare side OMU (USU)
ZUSU:OMU,0:C=DSK;
d) Restart the spare side MCHU (USU)
g In this example before the switchover, the spare side MCHU is MCHU-1. After the
switchover, it is MCHU-0.
If necessary, use the USI:MCHU; command to find out which is the spare side.
ZUSU:MCHU,1:C=DSK;
e) Perform the switchover of the MCHU (USC)
ZUSC:MCHU,1:WO;
f) Set the NEWP additional information into the spare MCHU (UST)
ZUST:MCHU,0:S-NEWP;
g) Restart the spare side MCHU (USU)
In the C=DSK parameter, you can define whether the files are loaded from the disk
in case of a restart.
ZUSU:MCHU,0:C=DSK;
12 Start also the other units into which you want to load the change delivery (UST,
USU, USC)
Repeat the steps below for each unit:
a) Set the NEWP additional information to the spare unit (UST)
Note that in this example the spare side index is 1.
ZUST:<unit>,1:S-NEWP;
b) Restart the spare unit (USU)
ZUSU:<unit>,1:C=DSK;
c) Perform the switchover (USC)
Note that before the switchover, the spare side index is 1. After the switchover, it is 0.
ZUSC:<unit>,0:SP;
d) Set the NEWP additional information to the spare unit (UST)
ZUST:<unit>,0:S-NEWP;
e) Restart the spare unit (USU)
13 Test whether the new software functions properly in traffic transmission

Make different test calls. Focus the testing on those parts of the network element in
which the change delivery has changed something. If you have just installed a correction
build, ensure that the fault does not occur any more.
14 If the new software functions properly, continue from the next step below
If the new software does not function properly, return to the old SW build:
a) Change the active build in the directory (WSS)
The status of the old build changes from 'UT' to 'BU' (or to 'NW'):
ZWSS:NAME=<name of old SW build>;
The old build is now the default build.
36 Id:0900d805807dc142 DN9770985
Confidential
Software Configuration Management Installing and deploying a change delivery
b) Restart the spare side OMU (USU)

ZUSU:OMU,1:C=DSK;
c) Perform the switchover of the OMU (USC)
ZUSC:OMU,1:WO;
d) Restart the spare side OMU (USU)
ZUSU:OMU,0:C=DSK;
e) Restart the spare side MCHU (USU)
Note that in this example the spare side is MCHU-1.
ZUSU:MCHU,1:C=DSK;
f) Perform a switchover for the MCHU (USC)
After the switchover, the spare side is MCHU-0.
ZUSC:MCHU,1:WO;
g) Restart the spare side MCHU (USU)
ZUSU:MCHU,0:C=DSK;
Restart the OMU and the spare side SCU and perform a switchover for the SCU.
Finally, restart the SCU now on the spare side.
h) Start also the other units in which you want to return to the old SW build
Repeat the following steps for each unit:
• Restart the spare unit (USU):
• Perform the switchover (USC):
ZUSC:<unit>,1:WO;
• Restart the spare unit (USU):
i) Delete the NEWP additional information from all units (UST)
ZUST:<unit>,<index>:C-NEWP;
j) Update the SW build identity, if necessary (WNJ)
ZWNJ:FORCE:NAME=<name of old SW build>;
k) Delete the change delivery and the new SW build (WND)
ZWND:NAME=<name of new SW build>;
ZWQD:NAME=<name of new SW build>:MAFILE;
l) You have now returned to the old SW build. Do not go through steps 17–20
15 After you have made sure that the new software functions properly, follow the
instructions given in the following steps below
16 Delete the NEWP additional information from all units (UST, WRC)
• Delete them separately from each unit (UST)
ZUST:<unit>,<index>:C-NEWP;
• Delete them simultaneously from all units (WRC)
ZWRC;
17 Update the software build identifier (WNJ)

ZWNJ:UPDATE:NAME=<name of new SW build>;
DN9770985 Id:0900d805807dc142 37
Confidential

19 Delete the old SW build (WQD)

Delete the old SW build, that is, the UT build which can be found in the same directory
as the BU build or the NW build, after making sure that it is not needed any more.
Further information
For more information on installing a change delivery, see the installation instructions of
the relevant change delivery.
38 Id:0900d805807dc142 DN9770985
Confidential
Software Configuration Management Updating embedded software of a computer or prepro-
cessor plug-in unit
5 Updating embedded software of a computer

or preprocessor plug-in unit
The embedded software (eSW) of a computer and a preprocessor plug-in unit is needed
to initialize the hardware and perform an initial loading of the system software build
during unit startup. You can check the eSW version and update the eSW with the Boot
Package Handling, WD Command Group. The eSW images are programmed into the
unit's FLASH memory and are managed as plug-in unit type-specific entities. The eSW
file names start with the first three characters as BOP and AEM for DMX OS plug-in units
or PBO for Chorus OS plug-in units.
All plug-in units should contain eSW that is compatible with the existing software build
when they are delivered.
An eSW update is necessary in the following cases:
• A Change Delivery contains a new eSW for one or more plug-in unit types.
• A new eSW has been instructed to be taken into use during a software build
upgrade.
• A separate, earlier or newly delivered plug-in unit needs eSW updating. For
example, when a faulty plug-in unit needs to be replaced with a new one: the new
unit's eSW version in the flash memory must be different from that of the other plug-
in units of the same type in the network element.
Before you start

1. We recommended that you use the same eSW version in all plug- in units of the
same type. You can get a list of all updatable computer and preprocessor plug-in
units of the same type that have been equipped and configured into the network
element by entering the following MML command:
ZWDI:PT=<plug-in unit type>;
For all features of the command group, see Embedded Software Handling, WD
Command Group.
2. Unless otherwise instructed, update the eSW while still running the old software
build in case of a software build upgrade. Unless otherwise instructed, the new eSW
is located in the LFILES directory of the new software build, and the location can be
defined using the DI parameter of the MML commands.
3. Unless otherwise instructed, copy the new eSW version to the LFILES directory of
the active software build in case of a Change Delivery.
4. When updating the eSW, the corresponding functional unit must be in the TE-EX
working state.
Note that the Embedded Software Handling, WD Command Group allows the handling
of more than one plug-in unit at a time, for example, plug-in units of a functional unit or
all plug-in units of the network element. When specifying a large amount of units to be
updated, however, you have to be aware of the consequences if something goes wrong.
For example, if a unit needs to be restarted during the programming of the flash memory,
the eSW becomes corrupted and the plug-in unit malfunctions. In this case, contact your
local Customer Service Center for advice.
DN9770985 Id:0900d80580900a63 39
Confidential
Updating embedded software of a computer or prepro- Software Configuration Management
cessor plug-in unit
Steps
1 Compare the eSW versions (WDI)

Compare the eSW version in the flash memory of the plug-in unit to the corresponding
eSW version on disk. The plug-in unit type and index (PT and PI parameters) do not
have to be given if the functional unit type and index (UT and UI parameters) explicitly
identify the plug-in unit. The location of the new eSW with DI parameter does not have
to be given if the new eSW is located in the LFILES directory of the active software build.
g The unit working state is optional and can be all states in default.
ZWDI:UT=<unit type>,UI=<unit index>,PT=<plug—in unit

type>,PI=<plug—in unit index>,ST=<unit work state>,SW=<software
type>:DI=<directory path>;
Semantic error messages

If a semantic error occurs, the system provides you with the correct syntax. In this situ-
ation, you need to delete all the parameters and commands you entered, and then re-
enter the command. If you enter a parameter (for example, UT or PT) but don’t provide
any value (for example, UT=, or PT=,), it will list all types of functional units or plug-in
units. The correct syntax or possible parameter values are provided by pressing ENTER
after giving a command letter, parameter name, the “:” block separator, or the “,” param-
eter separator.
Expected outcome
• eSW version in the flash memory differs from the version in LFILES (disk file). If you
want to update the eSW, continue to the next step.
• When inquiring the BIOS/FPGA/BACKUPBIOS for a CP816_A plug-in unit, the
result should be ‘NOT SUPPORTED.’
• If there is no DCAR1-A when inquiring the PFPGA version, the result should be ‘SP
FLASH DOES NOT EXIST.’
Unexpected outcome
• If the result is that the IMG in the Flash disk is the same with the memory file,you do
not need to update the eSW for this unit.
• If the result is 'NO CONNECTION', check if the corresponding working state of the
functional unit is TE-EX, WO-EX, or SP-EX and try again.
• If the result is 'WRONG PIU TYPE', check if the plug-in unit data is correctly config-
ured and try again.
• If the result is 'NOK' or 'UNKNOWN', do not continue to the next step. Contact your
2 Update eSW from the disk to flash memory of the plug-in unit (WDI, WDR)
Note that while updating the eSW, do not try to reset the network element or any of its
computer units before the update is successfully finished.
40 Id:0900d80580900a63 DN9770985
Confidential
Software Configuration Management Updating embedded software of a computer or prepro-
cessor plug-in unit
a Repeat Step 1 (WDI)
b Program eSW (WDR)

The same as Step 1, but use the command WDR instead of WDI.
ZWDR:UT=<unit type>,UI=<unit index>,PT=<plug—in unit
type>,PI=<plug—in unit index>,ST=<unit work
state>,SW=<software type>:DI=<directory
path>/FN=<directory path+filename>;
c Repeat Step 1 (WDI)
g For CP1D-A plug-in units, the FPGA/PFPGA version in the output is always the
version of the running FPGA/PFPGA eSW. The version of the newly updated
FPGA/PFPGA eSW is displayed only after cold restart.
Semantic error messages

If a semantic error occurs, the system provides you with the correct syntax. In this situ-
ation, you need to delete all the parameters and commands you entered, and then re-
enter the command. If you enter a parameter (for example, UT or PT) but don’t provide
any value (for example, UT=, or PT=,), it will list all types of functional units or plug-in
units. The correct syntax or possible parameter values are provided by pressing ENTER
after giving a command letter, parameter name, the “:” block separator, or the “,” param-
eter separator.
Expected outcome
• The update succeeded and the eSW version in the flash memory is updated and is
now the same as on disk.
• When inquiring the BIOS/FPGA/BACKUPBIOS for a CP816_A plug-in unit, the
result should be ‘NOT SUPPORTED.’
• If there is no DCAR1-A when inquiring the PFPGA version, the result should be ‘SP
FLASH DOES NOT EXIST.’
Unexpected outcome
• If the result is 'FLASH IMAGE SAME', you do not need to update the eSW for this
unit.
3 If you updated the eSW, restart the unit (USU)

If the software build is not going to be upgraded, restart the unit in which the eSW is
updated:
ZUSU:<unit type>,<unit index>::C=TOT;
Expected outcome
The unit restarts to the TE-EX working state.
DN9770985 Id:0900d80580900a63 41
Confidential
Updating embedded software of a computer or prepro- Software Configuration Management
cessor plug-in unit
Unexpected outcome
The updated unit fails to restart. Contact your local Customer Service Center for advice.
42 Id:0900d80580900a63 DN9770985
Confidential
Software Configuration Management Updating embedded software of an ET plug-in unit
6 Updating embedded software of an ET plug-

in unit
The embedded software (eSW) of the ET is needed to initialize hardware and perform
an initial loading of the system software build during the unit startup. You can check the
eSW version with the DPP MML command and update the eSW with the WDE MML
command. The eSW images are programmed into the unit's FLASH memory and are
managed as plug-in unit specific entities. The eSW file names start with the first three
characters as EA2. All ET plug-in units contain eSW that is compatible with the existing
software build when they are delivered.
• A Change Delivery contains a new eSW for one or more ET plug-in unit types.
upgrade.
• A separate, earlier or newly delivered ET plug-in unit needs eSW updating. For
example, when a faulty ET plug-in unit needs to be replaced with a new one, the new
unit's eSW version in the flash memory differs from that of the other plug-in units of
the same type in the network element.
Before you start

1. We recommend that you use the same eSW version in all ET plug- in units. You can
get a list of all updatable ET plug-in units of the same type that have been equipped
and configured into the network element by entering the following MML command:
ZWTI:P:ET;
2. Unless otherwise instructed, update eSW while still running the old software build in
case of a software build upgrade. Unless otherwise instructed, the new eSW is
located in the LFILES directory of the new software build.
the active software build in case of a change delivery.
4. If the change delivery contains updates to EA2RAMQA, QK, Q8, and Q9, these
software must be updated first to the following variants:
• ET2E-T(C)
• ET2E-TB(C)
• ET2A-T
• ET2A-TB
5. Update the EA2ROMQX boot software of the ETs.
6. Restart the ET plug-in units after the new software versions have been copied to the
OMU/LFILES directory. Restart is required to load new EA2RAM eSW to the ET
units. After the restart, check if the new EA2RAM SW versions have been loaded
correctly to the ET units with DPP MML command:
ZDPP:<control_computer>,<comp_index>:ET,<et_index>:CID;
Note that the Embedded Software Handling, WD Command Group allows the handling
of more than one ET plug-in unit at a time, for example, all ET plug-in units of the network
element. The smallest unit of the update is a plug-in unit, which consists of two functional
ET units with consecutive unit indices. The even index is always the smaller number of
the two indices.
When specifying a large amount of units to be updated, however, you must be aware of
the consequences if something goes wrong. For example, if a unit needs to be restarted
DN9770985 Id:0900d80580900a68 43
Confidential
Updating embedded software of an ET plug-in unit Software Configuration Management
during the programming of the flash memory, the eSW becomes corrupted and the ET
plug-in unit malfunctions. In this case, contact your local Customer Service Center for
advice.
Steps
1 Compare the eSW versions (DPP, IWX)

Compare the eSW version in the flash memory of the ET plug-in unit to corresponding
eSW version on the disk.
ZDPP:<control_computer>,<comp_index>:ET,<et_index>:CID;
ZIWX:,OMU:WS,DEF:LFILES,:EA2%%;
Expected outcome:
The eSW version in the flash memory differs from the version in LFILES (disk file). If you
Unexpected outcome:
If the eSW version of the flash memory is the same as the that in LFILES, you do not
need to update the eSW for this unit.
2 Update the eSW from disk to flash memory of the ET plug-in unit (WDE)
a Repeat Step 1 to compare the eSW version in the disk files with the version in
the flash memory (DPP, IWX)
b Set the ET to be updated to the TE-EX state (USC)

ZUSC:ET,<et_index>:BL;
ZUSC:ET,<et_index>:TE;
c Program the eSW (WDE)

ZWDE:ET,<min_et_index>,<max_et_index>:;
Expected outcome:
The update succeeded and the eSW version in the flash memory was updated and
now is the same as on the disk.
Unexpected outcome:
If the result is NOK or UNKNOWN, do not continue to the next step. Contact your
3 Change the state of the updated ET back to the WO-EX state (USC)
ZUSC:ET,<et_index>:WO;
4 Check if the ET is in the WO-EX state (USI)

ZUSI:ET,<et_index>;
44 Id:0900d80580900a68 DN9770985
Confidential
Software Configuration Management Updating embedded software of an ET plug-in unit
5 Check if the new eSW version has been successfully updated to the flash memory
and now is the same as on the disk. Check also if the new EA2RAM SW versions
have been loaded correctly to the ET units (DPP / IWX)
Repeat Step 1.
DN9770985 Id:0900d80580900a68 45
Confidential
Updating embedded software of an SW256B plug-in Software Configuration Management
unit
7 Updating embedded software of an SW256B

plug-in unit
The embedded software (eSW) of the SW256B is needed to initialize the hardware and
perform an initial loading of the system software build during the unit startup. You can
check the eSW version with the DPX MML command and update the eSW with the WDG
MML command. The eSW images are programmed into the unit's FLASH memory and
are managed as plug-in unit specific entities. The eSW file names start with the first
three characters as S1W.
• A Change Delivery contains a new eSW for one or more SW256B plug-in unit types.
upgrade.
• A separate, earlier or newly delivered SW256B plug-in unit needs eSW updating.
For example, when a faulty SW256B plug-in unit is to be replaced with a new one,
the new unit's eSW version in flash memory will differ from that of the other plug-in
units of the same type in the network element.
Before you start

1. We recommend that you use the same eSW version in all SW256B plug-in units.
You can get a list of all updatable SW256B plug-in units of the same type that have
been equipped and configured into the network element by entering the following
MML command:
ZWTI:P:GSW,<gsw_index>;
build in case of a software build upgrade. The new eSW is located in the LFILES
directory of the new software build.
4. Before updating the SW256B plug-in units, check if the switching network control
preprocessor, the SWCOP and SWSETSQZ files version is 2.20-0 or newer in both
SWCOP plug-in units. The version of the SWSETQZ can be checked with the fol-
lowing MML command:
ZDPP:<control_computer>,<comp_index>:<SWCOP,>,<piu_index>:CI
D;
When updating the eSW, the corresponding functional unit (M/CMM) must be in the
TE- EX working state.
The Embedded Software Handling, WD Command Group allows the handling of more
than one SW256B plug-in unit at a time, for example, all SW256B plug-in units of the
specified switch. The smallest unit of the update is all the plug-in units of SW256B of the
specified switch. When specifying a large amount of units to be updated, however, you
must be aware of the consequences if something goes wrong. For example, if a unit has
to be restarted during the programming of the flash memory, repeat all the steps of the
eSW update. The update of eight SW256B plug-in units can take up to 45 minutes so
we recommend you to update the SW256B plug-in units during low traffic hours.
46 Id:0900d80580900bac DN9770985
Confidential
Software Configuration Management Updating embedded software of an SW256B plug-in
unit
Steps
1 Compare the eSW versions (DPX, IWX)

Compare the eSW version in the flash memory of the SW256B plug-in unit to the corre-
sponding eSW version on the disk.
ZDPX:GSW, <gsw_index>:SW256B,:CID;
ZIWX:,OMU:WS,DEF:LFILES,:S1W%,%;
Expected outcome
The eSW version in the flash memory differs from the version in LFILES (disk file). If you
Unexpected outcome
If the eSW version in the flash memory is the same as that in LFILES, you do not need
to update the eSW for this unit.
2 Update the eSW from the disk to the flash memory of the SW256B plug-in unit
(WDG)
a Repeat Step 1 to compare the eSW version in the disk file to the version in the
flash memory (DPX, IWX)
b Program the eSW (WDG)

ZWDG:GSW, <gsw_index>:SW256B;
Expected outcome
The update succeeded and the eSW version in the flash memory is updated and
now is the same as on the disk.
Unexpected outcome
• If the result is NOK or UNKNOWN, do not continue to the next step. Contact your
• If the result is BACKUP BLOCK NOT OK, UPDATE IT FIRST, use the backup
parameter value 'BCK' to copy the eSW version of the primary block to the
backup block.
ZWDG:GSW, <gsw_index>:SW256B:BCK;
Then repeat Step 2.
3 Change the state of the corresponding functional unit to WO-EX (USC)

ZUSC:<control_computer>,<comp_index>:WO;
4 Check if the corresponding functional unit is in the WO-EX state (USI)

ZUSI:<control_computer>,<comp_index>;
DN9770985 Id:0900d80580900bac 47
Confidential
Updating embedded software of an SW256B plug-in Software Configuration Management
unit
5 Check if the new eSW version has been successfully updated to the flash memory
and now is the same as on disk (DPX / IWX)
Repeat Step 1.
48 Id:0900d80580900bac DN9770985
Confidential
Software Configuration Management Updating embedded software of an AS7-D plug-in unit
8 Updating embedded software of an AS7-D

plug-in unit
The embedded software (eSW) of an AS7-D plug-in unit is needed to initialize the
hardware and perform an initial loading of the system software build during the unit
startup. You can check the eSW version with the DPX command and update the eSW
with the WDH command. The eSW images are programmed into unit's FLASH memory
and are managed as plug-in unit type-specific entities.
Before you start

1. We recommend that you use the same eSW version in all plug- in units of the same
type. You can check where and how many AS7-D plug-in units the network element
has with the following MML command:
AS7-D plug-in unit: ZWTI:P::AS7_D;
2. You can get the AS7_D plug-in unit eSW version by entering the following
command:
ZDPX:<unit type>,[<unit index>]:<preprocessor type>,
<preprocessor number>:CID;
3. Unless otherwise instructed, update eSW while still running the old software build in
case of a software build upgrade. The new eSW is located in the LFILES directory
of the new software build.
5. When updating the eSW, the corresponding functional unit should be in the TE-EX
working state.
Steps
1 Compare the eSW versions (DPX)

eSW version on disk.
ZDPX:UT=<unit type>,UI=<unit index>,PT=<plug—in unit
type>,PI=<plug-in unit index>:(<FCD>);
Expected outcome
If the MML execution is successful, you can see the eSW version of the plug-in unit. If
the eSW version in the flash memory is different form the disk version, continue to the
next step.
DPX:OMU,0:AS7,0:CID;
BSC3i KEKKOLA 2009-05-05 10:46:16
OMU AS7-00
DMX SUPPORT FPGA

ACTIVE IMAGE: PRIMARY (700d)
PRIMARY IMAGE: CID NOT AVAILABLE
DISK IMAGE: CID NOT AVAILABLE
DN9770985 Id:0900d80580900be7 49
Confidential
Updating embedded software of an AS7-D plug-in unit Software Configuration Management
FPGA IMAGE: AD7FPGPY.PAC 1.5-0 09/02/13 PL
PIU BOOT SW: BOPASDGX.PAC 1.5-0 08/07/07

DISK IMAGE: BOPASDGX.PAC 1.6-0 08/08/22
( AD7BOPPY.PAC 1.6-0 08/08/22 PLAENVBD.PAC )
PROG PACKAGE IDENTIFICATION CODE PACKAGE AREA
CID: AD7LAPPY.PAC 1.21-0 09/01/22 3FEA.2F10...3FEE.A214
COMMAND EXECUTED
Unexpected outcome
• The MML execution fails and ends to timeout.
2 Update eSW from the disk to flash memory of the plug-in unit (WDH)
the flash memory (DPX)
b Program the eSW (WDH)

ZWDH:UT=<unit type>,UI=<unit index>,PT=<plug—in unit
type>,PI=<plug—in unit index>:(<FCD>);
c Repeat Step 1 to check if the two eSW versions are the same (DPX)
It is possible to update more than one AS7-D plug-in unit with one WDH command. Here
are the possibilities:
EMBEDDED SOFTWARE HANDLING COMMAND <WD_>< H:
/*
SPECIFY A SET OF AS7-D PLUG-IN UNITS:
A SINGLE AS7-D PLUG-IN UNIT:

UT ......... FUNCTIONAL UNIT TYPE
UI ......... FUNCTIONAL UNIT INDEX
PT ......... PLUG-IN UNIT TYPE
PI ......... PLUG-IN UNIT INDEX (optional)
ALL AS7-D PLUG-IN UNITS OF A SPECIFIED FUNCTIONAL UNIT:
ALL AS7-D PLUG-IN UNITS
Example
Only the BCSU-0's AS7_D eSW version is updated:
ZWDH:UT=BCSU,UI=0,PT=AS7_D,PI=1;
All the AS7_D's eSW version is updated:
ZWDH:PT=AS7_D;
50 Id:0900d80580900be7 DN9770985
Confidential
Software Configuration Management Updating embedded software of an AS7-D plug-in unit
Expected outcome
The update succeeded and the eSW version in the flash memory was updated and is
Unexpected outcome
unit.
functional unit is TE-EX, WO-EX, or SP-EX, and try again.
ured and try again.

ZUSU:<unit type>,<unit index>:C=TOT;
Expected outcome
Unexpected outcome
The unit fails to restart. Contact your local Customer Service Center for advice.
DN9770985 Id:0900d80580900be7 51
Confidential
Updating embedded software of an SWPRO-C plug-in Software Configuration Management
unit
9 Updating embedded software of an SWPRO-

C plug-in unit
The embedded software (eSW) of an SWPRO-C plug-in unit is needed to initialize the
startup. You can check the eSW version with the DPX command and update the eSW
with the WDH command. The eSW images are programmed into the unit's FLASH
memory and are managed as plug-in unit type-specific entities.
All plug-in units should contain eSW that is compatible with the existing software build
when they are delivered.
upgrade.
• A separate, earlier or newly delivered plug-in unit needs eSW updating.
Note that the update is necessary only when the eSW versions of the plug-in units
are different, if the eSW versions of the faulty and new plug-in units are the same,
the update is not needed.
Before you start

type. You can check where and how many SWPRO-C plug-in units the network
element has with the following MML command:
SWPRO-C plug-in unit: ZWTI:P::SWPRO_C;
2. You can get the SWPRO-C plug-in unit eSW version by entering the following
command:
ZDPX:<unit type>,[<unit index>]:<preprocessor type>,
<preprocessor number>:CID;
3. You can get the eSW versions in the LFILES directory with the DDE command. The
eSW is by default loaded from LFILES directory of the active SW build on the disk.
To inquire the eSW versions of the SWPRO-C plug-in unit in the LFILES directory
of the active SW build on the disk, execute the following command:
ZDDE:OMU:"ZLP:M,MAS;","MXP:W0-LFILES/D1XRADGX.IMG","XP:W0-
LFILES/D1XADVGX.IMG","XP:W0-LFILES/PP4BOPPZ.IMG";
the active software build in case of a Change Delivery.
working state.
Steps
1 Compare the eSW versions (DPX)

52 Id:0900d80580900be8 DN9770985
Confidential
Software Configuration Management Updating embedded software of an SWPRO-C plug-in
unit
ZDPX:UT=<unit type>,UI=<unit index>,PT=<plug—in unit

Expected outcome
If the MML execution is successful, you can see the eSW version of the plug-in unit.If
next step
BSC3i KEKKOLA 2009-05-05 10:36:16
DPX:MCMU,0:SWPRO,0:CID;
MCMU-0 SWPRO-00
DMX SUPPORT FPGA

ACTIVE IMAGE: PRIMARY (700d)
PRIMARY IMAGE: D1XADVGX.PAC 1.1-0 08/05/12 PLAENVBD.PAC
DISK IMAGE: D1XADVGX.PAC 1.1-0 08/05/12 PLAENVBD.PAC
FPGA IMAGE: PP4FPGPZ.PAC 1.12-0 08/05/26
PIU BOOT SW: BOPSWCGX.PAC 1.9-0 08/11/06

DISK IMAGE: BOPSWCGX.PAC 1.10-0 08/12/31
( PP4BOPPZ.PAC 1.2-0 08/12/29 PLAENVBD.PAC )
PROG PACKAGE IDENTIFICATION CODE PACKAGE AREA
PPLIST63.PAC 1.1-T 07/09/21 PLAENVBD.P 3FD1.8CA4...3FD2.0BFC
COMMAND EXECUTED
Unexpected outcome
• The MML execution fails and ends to timeout.
a Repeat Step 1 to compare the eSW version in the disk file to the version in the
flash memory (DPX)

c Repeat Step 1 to check if the two eSW versions are the same (DPX)
It is possible to update more than one SWPRO-C plug-in unit with one WDH MML
command. Here are the possibilities:
o EMBEDDED SOFTWARE HANDLING COMMAND <WD_>
< H:
o
o /*
SPECIFY A SET OF PLUG-IN UNITS:
DN9770985 Id:0900d80580900be8 53
Confidential
Updating embedded software of an SWPRO-C plug-in Software Configuration Management
unit
o
o A SINGLE PLUG-IN UNIT:
ALL PLUG-IN UNITS OF A SPECIFIED FUNCTIONAL UNIT:
ALL PLUG-IN UNITS
Example
Only the MCMU-0's SWPRO-C eSW version is updated:
ZWDH:UT=MCMU,UI=0,PT=SWPRO_C,PI=1;
All the SWPRO-C's eSW versions are updated:
ZWDH:PT=SWPRO_C;
Expected outcome
The update succeeded and the eSW version in the flash memory is updated and is now
the same as on the disk.
Unexpected outcome
unit.
ured and try again.

Expected outcome
The unit restarts to TE-EX working state.
Unexpected outcome
54 Id:0900d80580900be8 DN9770985
Confidential
Software Configuration Management Updating embedded software of a DCAR1- A/AB plug-
in unit
10 Updating embedded software of a DCAR1-

A/AB plug-in unit
The embedded software (eSW) of a DCAR1-A/AB plug-in unit is needed to initialize the
startup. You can check the eSW version with the WDI command and update the eSW
with the WDR command. When checking and updating the version, you must use param-
eter PT. The eSW images are programmed into unit's FLASH memory and are
managed as plug-in unit type-specific entities.
g The new DCAR1-AB (C112390) is exactly the same as the older DCAR1-A (C111148)
but the external SAS- and PCIe-connectors have been removed from the front panel as
they are not needed in BSC. The new DCAR1-AB and the old DCAR1-A are fully
replaceable with each other. In the BSC equipment database, they are both created as
DCAR1-A.
Before you start

type. You can check where and how many DCAR1-A/AB plug-in units the network
element has with the following MML command:
DCAR1-A plug-in unit: ZWTI:P::DCAR1_A;
2. You can get the DCAR1-A/AB plug-in unit eSW version by entering the following
command:
ZWDI:UT=<unit type>,UI=<unit index>,PT=<plug-in unit
type>,PI=<plug-in unit index>,SW=<software type>:DI<directory
path>;
3. You can get the eSW versions in the LFILES directory with the DDE command. The
eSW is by default loaded from the LFILES directory of the active SW build on the
disk. To inquire the eSW versions of the DCAR1-A/AB plug-in unit in the LFILES
directory of the active SW build on the disk, execute the following command:
ZDDE:OMU:”ZLP:M,MAS;”,”MXP:W0-LFILES/BURTPBGX.IMG”;
Steps
1 Check the eSW versions (WDI)

Check the eSW version in the flash memory of the plug-in unit to the corresponding eSW
version on the disk.
ZWDI:UT=<unit type>,UI=<unit index>,PT=<plug—in unit
type>,PI=<plug-in unit index>,SW=<software type>:DI=<directory
path>;
DN9770985 Id:0900d805809a5754 55
Confidential
Updating embedded software of a DCAR1- A/AB plug- Software Configuration Management
in unit
Expected outcome
If you used the INTEL board, it will show the ‘SPI FLASH NOT EXIST.’ This is normal
because INTEL’s board does not have the SPI flash which offers inquire and update by
the user.
WDI:UT=OMU,UI=1,PT=DCAR1_A,PI=0;
EXECUTION STARTED
1 VALID PLUG-IN UNITS FOUND
EXECUTION STARTED AT 2013-01-31 15:36:40
/*** NOTE !! ***/
PFPGA VERSION IS ALWAYS THE RUNNING VERSION.

ONLY AFTER COLD RESTART, THE NEWLY UPDATED PFPGA VERSION COULD
BE DISPLAYED.
0% DONE, PLEASE WAIT 0 H, 2 MIN AND 20 SEC

FUNCTIONAL PLUG-IN UNIT PCI BRIDGE FPGA: FLASH MEMORY

UNIT TYPE INDEX DISK FILE
---------- ------------ -----------------------------
OMU-1 DCAR1_A-0 SPI FLASH NOT EXIST
COMMAND EXECUTED
• If you used the XILINX board, it will show normally.

MAIN LEVEL COMMAND <___>
<ZWDI:UT-OMU,UI=0,PT=DCAR1_A,PI=0;
LOADING PROGRAM VERSION 12.27-0
EXECUTION STARTED
/*** NOTE !! ***/

BE DISPLAYED.

56 Id:0900d805809a5754 DN9770985
Confidential
in unit
FUNCTIONAL PLUG-IN UNIT PCI BRIDGE FPGA: FLASH MEMORY

UNIT TYPE INDEX DISK FILE
---------- ------------ -----------------------------
OMU-0 DCAR1_A-0 BURTPBGX.PAC 1.8-0 11/11/30 BDA7CCF9
BURTPBGX.PAC 1.5-0 11/04/27 B0673B9F
COMMAND EXECUTED
Unexpected outcome
• If the result is ‘NO CONNECTION,’ check if the corresponding working state of the
functional unit is TE-EX, WO-EX, or SP-EX then try again. Additionally, check if the
hardware works normally
• If the result is ‘SPI FLASH NOT EXIST,’ the SPI flash may be broken if you used the
XILINX board.
• If the result is ‘WRONG PIU TYPE,’ check if the plug-in unit data is correctly config-
ured then try again.
2 Update eSW from the disk to flash memory of the plug-in unit (WDR)
a Repeat Step 1 to check the eSW version in the disk files with the version in the
flash memory (WDI)
b Program the eSW (WDR)

ZWDR:UT=<unit type>,UI=<unit index>,PT=<plug—in unit
type>,PI=<plug—in unit index>,SW=<software
type>:DI=<directory path>/FN=<directory path + filename>;
c Repeat Step 1 to check if the two eSW versions are the same (WDI)
Expected outcome
The update succeeded and the eSW version in the flash memory was updated and is
• If you used the INTEL board, it will show the ‘SPI FLASH NOT EXIST.’ This is normal
because INTEL’s board does not have the SPI flash which offers inquire and update
by the user.
WDR:UT=OMU,UI=1,PT=DCAR1_A,PI=0::FCD;
EXECUTION STARTED
CONFIRM COMMAND EXECUTION: Y/N ? Y
/*** NOTE !! ***/

BE DIPLAYED.
0% DONE, PLEASE WAIT 0 H, 9 MUN AND 20 SEC
DN9770985 Id:0900d805809a5754 57
Confidential
Updating embedded software of a DCAR1- A/AB plug- Software Configuration Management
in unit
FUNCTIONAL PLUG-IN UNIT

UNIT TYPE INDEX RESULT
---------- ------------
OMU-1 DCAR1_A-0 SPI FLASH NOT EXIST
COMMAND EXECUTED
• If you used the XLINX board, it will show normally.
EMBEDDED SOFTWARE HANDLING COMMAND <WD_>
<ZWDR:UT=OMU,UI=0,PT=DCAR1_A,PI=0::FCD
EXECUTION STARTED
/*** NOTE !! ***/

NOT BE DISPLAYED.


---------- ------------
OMU-0 DCAR1_A-0 UPDATED
COMMAND EXECUTED
Unexpected outcome
• If the result is 'FLASH IMAGE SAME,’ you do not need to update the eSW for this
unit.
• If the result is 'NO CONNECTION,’ check if the corresponding working state of the
functional unit is TE-EX, WO-EX, or SP-EX, then try again. Additionally, check if the
hardware works normally.
58 Id:0900d805809a5754 DN9770985
Confidential
in unit
• If the result is 'SPI FLASH NOT EXIST,’ the SPI flash may be broken if you used the
XILINX board.
• If the result is 'WRONG PIU TYPE,’ check if the plug-in unit data is correctly config-
ured then try again.
• If the result is ‘NOK' or 'UNKNOWN,’ contact your local Customer Service Center for
advice.
DN9770985 Id:0900d805809a5754 59
Confidential
Updating embedded software of an HWAT-B, CLAB- Software Configuration Management
U/CLAB-UA, CL2TG-U/CL3TG-U, CL2/CL3TG-UA and
11 Updating embedded software of an HWAT-B,

CLAB-U/CLAB-UA, CL2TG-U/CL3TG-U,
CL2/CL3TG-UA and CL3TG-V/VA plug-in unit
The embedded software (eSW) of an HWAT-B, CLAB-U/CLAB-UA, CL2TG-U/CL3TG-
U, CL2/CL3TG-UA and CL3TG-V/VA plug-in unit is needed to initialize the hardware
and perform an initial loading of the system software build during the unit startup. You
can check the eSW version with the DPP command and update the eSW with the WDH
command. The eSW images are programmed into the unit's FLASH memory and are
managed as plug-in unit type-specific entities.
upgrade.
• A separate, earlier or newly delivered plug-in unit needs eSW updating.
Note that the update is necessary only when the eSW versions of the plug-in units
are different, if the eSW versions of the faulty and new plug-in units are the same,
the update is not needed.
Before you start

type. You can check where and how many plug-in units the network element has
with the following MML command:
HWAT-B plug-in unit: ZWTI:P::HWAT_B;
CLAB-U plug-in unit: ZWTI:P::CLAUB_U;
CLAB-UA plug-in unit ZWTI:P::CLAB_UA;
CL2TG-U plug-in unit: ZWTI:P::CL2TG_U;
CL3TG-U plug-in unit: ZWTI:P::CL3TG_U;
CL2TG-UA plug-in unit ZWTI:P::CL2TG_UA;
CL3TG-UA plug-in unit ZWTI:P::CL3TG_UA;
CL3TG-V plug-in unit ZWTI:P::CL3TG_V;
CL3TG-VA plug-in unit ZWTI:P::CL3TG_VA;
2. You can get the eSW version of the plug-in unit by entering the following command:
ZDPP:<unit type>, [<subscriber stage> | <pair number>], [<unit
index>]: <preprocessor type>, <preprocessor number>: ( CID |
PID, [<program identification> | ALL def ] );
CL2/3TG-U plug-in units:

ZDPP:CLS,0:CL2TG,0:CID;
TCSM3i CL2/3TG-U plug-in units:

ZDPP:TCSM,145:CL3TG,1:CID;
HWAT-B plug-in unit:

ZDPP:OMU,1:HWAT,1:CID:;
60 Id:0900d8058090e78c DN9770985
Confidential
Software Configuration Management Updating embedded software of an HWAT-B, CLAB-
g The state of the HWAT-B plug-in unit must be WO-EX, otherwise the version inquiry
does not work.
CLAB-U/UA plug-in unit:

ZDPP:OMU,1:CLAB,1:CID:;
3. You can get the eSW versions in the LFILES directory by entering the DDE
command:
g The eSW is by default loaded from the LFILES directory of the active SW build on
the disk.
To inquire the eSW versions for the CL2TG-U or CL3TG-U in the LFILES directory
of the active SW build on the disk, execute the following command:
ZDDE:OMU,1:"ZLP:M,MAS;","MXP:W0-LFILES/CLTPGMGU.IMG";
To inquire the eSW versions for the CLAB-U/UA in the LFILES directory of the active
SW build on the disk, execute the following command:
ZDDE:OMU,1:"ZLP:M,MAS;","MXP:W0-LFILES/CLBPGMGU.IMG";
To inquire the eSW versions for the HWAT-B in the LFILES directory of the active
SW build on the disk, execute the following command:
ZDDE:OMU,1:"ZLP:M,MAS;","MXP:W0-LFILES/HATGENGB.IMG";
working state.
Steps
1 Compare the eSW versions (DPP)

ZDPP:UT=<unit type>,UI=<unit index>,PT=<plug—in unit
Expected outcome
If the MML execution is successful, you can see the eSW version of the plug-in unit. If
next step.
CL2/3TG-U, CL2/CL3TG-UA and CL3TG-V/VA DPP command printout:
/* IDENTIFY ID TYPE : CID / PID */
DPP:CLS,0:CL2TG,0:CID;
MSCi HARJU 2009-02-16 12:14:49
DN9770985 Id:0900d8058090e78c 61
Confidential
CLS-0 CL2TG-0
PROGRAM PACKAGE IDENTIFICATION
ROM SW:CLTPGMGU.IMG 1.2-0 09/02/13 (PRIMARY)
FPGA REVISION:2 (PRIMARY)

CPLD USERCODE:0002
COMMAND EXECUTED
TCSM3i CL2/3TG-U plug-in units:

DPP:TCSM,145:CL3TG,1:CID;
BSC3i KEKKOLA 2009-06-01 09:36:46
TCSM-145 CL3TG-1
ROM SW:CLTPGMGU.PAC 1.10-0 09/05/11 (PRIMARY)

CPLD USERCODE:0001
COMMAND EXECUTED
HWAT-B DPP command printout:

DPP:OMU:HWAT,1:CID:;
MSCi HARJU 2009-02-16 12:17:17
OMU HWAT-1
RAM SW:HATGENGX.IMG 8.8-0 09/02/13

ROM SW:HATGENGB.IMG 1.8-0 09/02/13 (PRIMARY)

CPLD USERCODE:0002
COMMAND EXECUTED
CLAB-U/UA DPP command printout:

DPP:OMU,1:CLAB,1:CID;
MSCi VESALA 2009-02-16 12:18:27
62 Id:0900d8058090e78c DN9770985
Confidential
OMU-1 CLAB-1
ROM SW:CLBPGMGU.IMG 1.8-0 09/02/13 (PRIMARY)
FPGA REVISION: 2(PRIMARY)

CPLD USERCODE:0002
COMMAND EXECUTED
Unexpected outcome
The MML execution fails and ends to timeout.
CL2/3TG-U, CL2/CL3TG-UA and CL3TG-V/VA DDP command printout:

DPP:CLS,0:CL2TG,0
DPP:CLS,0:CL2TG,0:CID;
MSCi HARJU 2009-02-16 12:26:40
CLS-0 CL2TG-0
ROM SW:
/*** DX ERROR: 10112 ***/
/*** MESSAGE TIME-OUT ***/
COMMAND EXECUTION ABORTED
HWAT-B DPP command printout:

DPP:OMU:HWAT,1:CID;
MSCi HARJU 2009-02-16 12:29:46
OMU HWAT-1
RAM SW:
/*** DX ERROR: 10112 ***/
ROM SW:
/*** DX ERROR: 10112 ***/
DN9770985 Id:0900d8058090e78c 63
Confidential
CLAB-U/UA DPP command printout:

< DPP:OMU,1:CLAB,1:CID;
MSCi VESALA 2009-02-16 12:34:37
OMU-1 CLAB-1
ROM SW:
/*** DX ERROR: 10112 ***/
w NOTICE: before using the WDH command, the unit states must be as follows:
– CLAB-U/UA: CLAB state is TE-EX
– HWAT-B: the corresponding OMU state is TE-EX
– CLS: CLS state is TE-EX
the flash memory (DPP)

The same as Step 1, but use the command WDH instead of DPP.
c Repeat Step 1 to check if the two eSW versions are the same (DPP)
g Note that it is possible to update more than one plug-in unit with one WDH MML
command. Here are the possibilities:
EMBEDDED SOFTWARE HANDLING COMMAND <WD_>

< H:
/*
SPECIFY A SET OF PLUG-IN UNITS:
A SINGLE PLUG-IN UNIT:

64 Id:0900d8058090e78c DN9770985
Confidential

ALL PLUG-IN UNITS OF A SPECIFIED FUNCTIONAL UNIT:
ALL PLUG-IN UNITS
Example
HWAT-B eSW update WDH command:
ZWDH:UT=OMU,UI=0,PT=HWAT_B,PI=1;
CL2/3TG-U eSW update WDH command:
ZWDH:UT=CLS,UI=0,PT=CL3TG_U,PI=1;
CL2/3TG-UA eSW update WDH command:
ZWDH:UT=CLS,UI=0,PT=CL3TG_UA,PI=1;
CL3TG-V/A eSW update WDH command:
ZWDH:UT=CLS,UI=0,PT=CL3TG_V,PI=1;
CLAB-U eSW update WDH command:
ZWDH:UT=CLAB,UI=0,PT=CLAB_U,PI=1;
CLAB-UA eSW update WDH command:
ZWDH:UT=CLAB,UI=0,PT=CLAB_UA,PI=1;
Expected outcome
The update is successful. The eSW version in the flash memory is updated and is now
the same as on disk.
Unexpected outcome
unit.
• If the result is 'NO RESPONSE FROM PLUG-IN UNIT', check if the corresponding
working state of the functional unit is TE-EX, WO-EX, or SP-EX and try again.
ured and try again.

Expected outcome
Unexpected outcome
DN9770985 Id:0900d8058090e78c 65
Confidential
Updating embedded software of an ETP plug-in unit Software Configuration Management
12 Updating embedded software of an ETP plug-

in unit
The embedded software (eSW) of an ETP plug-in unit is needed to initialize the
startup. You can check the eSW version with the WDM command and update the eSW
with the WDL command. The eSW images are programmed into the unit's FLASH
memory and are managed as plug-in unit type-specific entities.
All the ETP plug-in units should contain eSW that is compatible with the existing
• A change delivery contains a new eSW for one or more plug-in unit types.
upgrade.
• A separate, earlier or newly delivered ETP plug-in unit needs eSW updating. For
example, when a faulty ETP plug-in unit needs to be replaced with a new one, the
new unit's eSW version in flash memory is different from that of the other plug-in
Before you start

1. We recommend that you use the same eSW version in all ETP plug- in units. You
can get a list of all updatable ETP plug-in units of the same type that have been
equipped and configured into the network element by entering the following MML
command:
ZWTI:P:<unit_type>;
For example: ZWTI:P:ETPE;
directory of the new software build, unless otherwise instructed.
working state.
5. The eSW is transferred from the LFILES directory to the ETP plug-in unit via the
BSC internal LAN. There must be a valid user ID and profile defined (MMI System
Authority Handling, IA Command Group) to allow the ETP to access the FTP server
in the OMU or MCMU. The user profile that the ETP is using must have the FTP AND
SFTP ACCESSIBILITY specified as W : ACCESS WITH READ AND WRITE PER-
MISSIONS.
For example: ZIAA:PROFILE::::FTP=W;
than one ETP plug-in unit at a time, for example, all ETP plug-in units of the network
element. When specifying a large number of units to be updated, however, you must be
aware of the consequences if something goes wrong. For example, if a unit needs to be
restarted during the programming of the flash memory, the eSW becomes corrupted and
the ETP plug-in unit malfunctions. In this case, contact your local Customer Service
Center for advice.
66 Id:0900d80580900be9 DN9770985
Confidential
Software Configuration Management Updating embedded software of an ETP plug-in unit
Steps
1 Check the eSW versions of an ETP plug-in unit (WDM)

Check the current eSW versions in the primary and secondary flash memories of the
ETP plug-in unit.
ZWDM:UT=<unit_type>,UI=<unit_index>,MODE=<update_mode>;
a Check the eSW version in the primary flash memory

ZWDM:UT=<unit_type>,UI=<unit_index>,MODE=ACTIVE;
For example: ZWDM:UT=ETPE-0,UI=0,MODE=ACTIVE;
b Check the eSW version in the secondary flash memory

ZWDM:UT=<unit_type>,UI=<unit_index>,MODE=STANDBY;
For example: ZWDM:UT=ETPA,UI=0,MODE=STANDBY;
g The default mode is ACTIVE if the update mode parameter is not set.
Expected outcome
The current eSW version in the flash memory is printed out. If you want to update the
eSW, continue to the next step.
ZWDM:UT=ETPE-0,UI=0,MODE=ACTIVE;
EXECUTION STARTED
FUNCTIONAL PLUG-IN UNIT BOOT PACKAGE: FLASH MEMORY

UNIT TYPE INDEX
----------- ------------- -----------------------------------
ETPE-0-0 ETP-0 GGNETPET.PAC 1.52-0 10/09/10 PLAENVBE.PAC 3.3-5
COMMAND EXECUTED
2 Set the ETP plug-in unit to be updated to the TE-EX state (USC)
ZUSC:<unit_type>,<unit_index>:TE,FCD;
3 Update eSW from disk to flash memories of the ETP plug-in unit (WDL)
a Update the eSW of the ETP to the secondary flash memory (WDL)
ZWDL:UT=<unit_type>,UI=<unit_index>,SERVER=<FTP/SFTP_server_
IP>,SW=<eSW_img_path_and_name>,MODE=STANDBY:;
For example:
DN9770985 Id:0900d80580900be9 67
Confidential
ZWDL:UT=ETPA,UI=0,SERVER=10.16.135.235,SW=W0-
LFILES/GGNETPAA.IMG,MODE=STANDBY;
b Switch over between the primary and secondary flash memories of the ETP
(WDS/USU)
• If BSC runs on EP2.1 or higher software level and the ETP has GGNET* 2.7-0
or newer software in the flash, use the WDS command to switch the updated flash
as primary flash on the ETP.
ZWDS:UT=<functional unit type>,UI=<functional unit
index>,PT=<plug-in unit type>,PI=<plug-in unit index>:;
• If BSC runs on software level lower than EP2.1 or if the ETP has GGNET* 2.6-
0 or older software, then ETP card restart with C=TOT option is required to
switch the updated flash as primary flash on the ETP.
ZUSU:UT=<unit_ type>,UI=<unit_index>:C=TOT;
After this the updated flash with new eSW should become the primary flash of the
ETP.
c Repeat eSW update command as in substep a) to the other flash of the ETP
(WDL).
g For the FTP/SFTP server IP address, check the OMU or MCMU IP address.
If the IP address tag is already configured with the QRP MML command (FTP for the
ETPE, ETPT and ETPA units while SFTP for the ETPC unit), the following command
can be used to update the eSW:
ZWDL:UT=<unit_type>,UI=<unit_index>,MODE=STANDBY;
Expected outcome
The update succeeded and all relative files are downloaded successfully.
ZWDL:UT=ETPE-0,UI=0,SERVER=10.16.136.235,SW=W0-
LFILES/GGNETPET.IMG,MODE=STANDBY,;
EXECUTION STARTED

68 Id:0900d80580900be9 DN9770985
Confidential
Software Configuration Management Updating embedded software of an ETP plug-in unit


----------- ------------- -------
ETPE-0-0 ETP-0 SUCCESS
COMMAND EXECUTED
Unexpected outcome
If the error is BAD USERNAME OR PASSWORD, a valid user profile with rights to the
FTP server must be configured for ETP. If the update fails with other errors, please
contact your local Customer Service Center for advice.
ZWDL:UT=ETPT-2,UI=0,SERVER=10.14.14.20,SW=W0-
LFILES/GGNETPET.IMG,MODE=STANDBY;
EXECUTION STARTED


----------- ------------- -------
ETPT-2-0 ETP-0 BAD USERNAME OR PASSWORD
COMMAND EXECUTED
4 Change the state of the updated ETP back to WO-EX (USC)

ZUSC:<unit type>,<unit index>:WO,FCD;
5 Check if the ETP is in the WO-EX state (USI)

ZUSI:<unit type>,<unit index>;
DN9770985 Id:0900d80580900be9 69
Confidential
6 Check if the new eSW has been successfully updated to the flash memories and
is now the same as on the disk
Repeat Step 1.
g You can find eSW updating image names for different ETP types in .
Unit Plug-in unit IMG

ETPA ETP-A GGNETPAA.IMG
ETPA ETP GGNETPAB.IMG
ETPC ETP-A GGNETPCC.IMG
ETPE ETP GGNETPET.IMG
ETPT ETP GGNETPET.IMG
Table 2 eSW updating image names for different ETP types
70 Id:0900d80580900be9 DN9770985
Confidential
Software Configuration Management Updating embedded software of an ETIP plug-in unit
13 Updating embedded software of an ETIP

plug-in unit
You can check the eSW version with the WDK command and update the eSW with the
WDJ command. The eSW images from the hard disk default software build BLCODE
directory to the flash memory of ETIP functional units. The software is divided into two
categories: applications (APPL) and Board Support Package (BSP). BSP consists of
three modules: LNX71C02 (kernel), LNXFPG02 (FPGA-bit image), and LNXUBO02
(loader). All BSP modules in the ETIP should originate from the same software build, in
other words, have software build specific versions. When updating applications, only
modules which versions in the ETIP differ from versions on disk are updated.
The command supports the update of a single ETIP unit by giving the unit index, all ETIP
units in the network element by not giving the specific unit index, and a single ETIP unit
in a TCSM network element. The user can choose which eSW to update by setting the
SW parameter. If the SW parameter value is equal all, this means the user chooses to
update several types of eSW files (FPGA, LOADER, KERNEL, BACKUPFPGA, BACK-
UPLOADER, BACKUPKERNEL, and APPL).
All the ETIP plug-in units should contain eSW that is compatible with the existing
• A change delivery contains a new eSW for one or more plug-in unit types.
upgrade.
• A separate, earlier or newly delivered ETIP plug-in unit needs eSW updating. For
example, when a faulty ETIP plug-in unit needs to be replaced with a new one, the
new unit's eSW version in flash memory is different from that of the other plug-in
Before you start

1. The command is accepted only when the ETIP functional unit is in TE-EX working
state. You can use the following command to list the ETIP working states:
ZUSI:ETIP;
g However when updated through TCSM, the ETIP functional unit should be in WO-
EX working state.
2. We recommend that you should update the LNXBurner module which is responsible
for downloading the eSW and writing the eSW to ETIP flash. The LNXBurner module
eSW image is called LNX71BGX. You can update the LNXBurner by setting the SW
parameter as APPL. Remember to restart the ETIP after the update. The command
is as follows:
ZWDJ:UT=ETIP,UI=0,SW=APPL;
3. By giving the FTP server IP parameter, the modules are loaded via FTP. The feature
requires IP network between OMU and ETIP units. Thus before you load module via
FTP, make sure that FTP works normally.
build in case of a software build upgrade. The new eSW is located in the BLCODE
directory of the new software build, unless otherwise instructed.
DN9770985 Id:0900d8058094b2f0 71
Confidential
Updating embedded software of an ETIP plug-in unit Software Configuration Management
5. Unless otherwise instructed, copy the new version of eSW to the BLCODE directory
of the active software build in case of a change delivery.
than one ETIP plug-in unit at a time, for example, all ETIP plug-in units of the network
element. When specifying a large number of units to be updated, however, you must be
aware of the consequences if something goes wrong. For example, if a unit needs to be
restarted during the programming of the flash memory, the eSW becomes corrupted and
the ETIP plug-in unit malfunctions. In this case, contact your local Customer Service
Center for advice.
Steps
1 Check the eSW versions of an ETIP plug-in unit (WDK)

Check the current eSW versions in the primary and secondary flash memories of the
ETIP plug-in unit.
ZWDK:UT=<unit_type>,UI=<unit_index>
Expected outcome
The current eSW version in the flash memory is printed out. If you want to update the
eSW, continue to the next step.
ZWDK:UT=ETIP,UI=0;
EXECUTION STARTED

----------- ------------- -----------------------------------
ETIP-0 LNX71C02.PAC 2.44-0 (PRIMARY)
ETIP-0 LNXFPG02.PAC 2.44-0 (PRIMARY)
ETIP-0 LNXUBO02.PAC 2.44-0 (PRIMARY)
ETIP-0 LNX6F8G1.PAC 2.9-0
ETIP-0 LNX701G1.PAC 2.4-0
ETIP-0 LNX70AG1.PAC 3.1-0
ETIP-0 LNX70BG1.PAC 2.6-0
ETIP-0 LNX70DG1.PAC 2.5-0
ETIP-0 LNX70EG1.PAC 2.7-0
72 Id:0900d8058094b2f0 DN9770985
Confidential
ETIP-0 LNX70FG1.PAC 2.14-0

ETIP-0 LNX71BG1.PAC 2.23-0
ETIP-0 LNX90AG1.PAC 2.5-0
ETIP-0 LNX91FG1.PAC 1.10-0
ETIP-0 LNX71C02.PAC 2.34-0 (SECONDARY)
ETIP-0 LNXFPG02.PAC 2.34-0 (SECONDARY)
ETIP-0 LNXUBO02.PAC 2.34-0 (SECONDARY)
ETIP-0 ETIP1_A-0 DONE
EXECUTION STARTED
2 Update eSW from disk to flash memories of the ETIP plug-in unit (WDJ)
a Set the ETIP to be updated to the TE-EX state (USC)

ZUSC:<unit_type>,<unit_index>:TE,FCD;
g To update the eSW of an ETIP unit in a TCSM network element, both ETIP and
TCSM should be in the WO-EX state.
b Update the eSW of the ETIP (WDJ)

• A single ETIP unit
ZWDJ:<unit_type>,<unit_index>,<software images>,<FTP
server IP>;
For example:
ZWDJ:UT=ETIP,UI=0,SW=ALL,SERVER=10.0.20.3;
• All ETIP units
ZWDJ:<unit_type>,<software images>,<FTP server IP>;
For example:
ZWDJ:UT=ETIP,SW=FPGA,SERVER=10.0.20.3;
ZWDJ:UT=ETIP,SW=ALL,SERVER=10.0.20.3;
• A single ETIP unit in a TCSM network element
ZWDJ:<unit_type>,<unit_index>,<network element
type>,<network element index>,<software images>,<FTP server
IP>;
For example:
ZWDJ:UT=ETIP,UI=0,NT=TCSM,NI=0,SW=ALL,SERVER=10.0.20.3;
DN9770985 Id:0900d8058094b2f0 73
Confidential
Expected outcome
EXECUTION STARTED

1 UNITS STARTED, PLEASE WAIT AT LEAST 30 SECONDS ...

----------- ------------- -------
ETIP-0 LNX6F8G1.PAC 2.9-0 DOWNLOADED
ETIP-0 LNX701G1.PAC 2.5-0 DOWNLOADED
ETIP-0 LNX70AG1.PAC 4.4-0 DOWNLOADED
ETIP-0 LNX70BG1.PAC 2.13-0 DOWNLOADED
ETIP-0 LNX70DG1.PAC 2.5-0 DOWNLOADED
ETIP-0 LNX70EG1.PAC 2.8-0 DOWNLOADED
ETIP-0 LNX70FG1.PAC 2.17-0 DOWNLOADED
ETIP-0 LNX71BG1.PAC 2.26-0 DOWNLOADED
ETIP-0 LNX90AG1.PAC 2.5-0 DOWNLOADED
ETIP-0 LNX91FG1.PAC 1.10-0 DOWNLOADED
ETIP-0 ETIP1_A-0 DOWNLOAD READY
COMMAND EXECUTED
74 Id:0900d8058094b2f0 DN9770985
Confidential
ZWDJ:UT=ETIP,UI=0,SW=ALL;
EXECUTION STARTED
FPGA UPDATE START AT 2012-05-25 11:21:36

1 UNITS STARTED, PLEASE WAIT AT LEAST 17 MINUTES ...
PLEASE WAIT AT LEAST 16 MINUTES AND 30 SECONDS MORE ...
PLEASE WAIT AT LEAST 16 MINUTES MORE ...

----------- ------------- -------
1 UNITS HANDLED
1 UNITS SUCCEEDED
LOADER UPDATE START AT 2012-05-25 11:25:50


----------- ------------- -------
ETIP-0 ETIP1_A-0 LOADER DOWNLOAD READY
1 UNITS HANDLED
1 UNITS SUCCEEDED
KERNEL UPDATE START AT 2012-05-25 11:26:00

1 UNITS STARTED, PLEASE WAIT AT LEAST 1 HOURS AND 0 MINUTES
...
DN9770985 Id:0900d8058094b2f0 75
Confidential


----------- ------------- -------
1 UNITS HANDLED
1 UNITS SUCCEEDED
APPL UPDATE START AT 2012-05-25 11:40:32


----------- ------------- -------
ETIP-0 ETIP1_A-0 NO DOWNLOADS NEEDED
1 UNITS HANDLED
1 UNITS SUCCEEDED
BACKUPFPGA UPDATE START

76 Id:0900d8058094b2f0 DN9770985
Confidential


----------- ------------- -------
1 UNITS HANDLED
1 UNITS SUCCEEDED
BACKUPLOADER UPDATE START

1 UNITS STARTED, PLEASE WAIT AT LEAST 1 MINUTES AND 30
SECONDS ...

----------- ------------- -------
1 UNITS HANDLED
1 UNITS SUCCEEDED
BACKUPKERNEL UPDATE START

1 UNITS STARTED, PLEASE WAIT AT LEAST 1 HOURS AND 0 MINUTES
...
DN9770985 Id:0900d8058094b2f0 77
Confidential


----------- ------------- -------
1 UNITS HANDLED
1 UNITS SUCCEEDED
COMMAND EXECUTED
3 Restart the ETIP unit (USU)

ZUSU:<unit>,0,C=DSK;
4 Check if the new eSW has been successfully updated to the flash memories and
is now the same as on the disk
Repeat Step 1.
78 Id:0900d8058094b2f0 DN9770985
Confidential
Software Configuration Management Updating firmware of an SCSI hard disk
14 Updating firmware of an SCSI hard disk

The firmware of the SCSI hard disk is needed to initialize the hardware and to coordinate
the components on the disk. You can check the firmware version with the WDV MML
command and update the firmware with the WDW MML command. The firmware images
are programmed into the disk's flash memory.
g The WDW MML command only supports the SCSI hard disk type MBA3xxxNP. The cor-
responding firmware name is WDUFRMGX.IMG.
Before you start

1. Unless otherwise instructed, update the firmware while the old software build is still
running in case of a software build upgrade. The new firmware is located in the
LFILES directory of the new software build.
2. Unless otherwise instructed, copy the new firmware version to the LFILES directory
of the active software build in case of a change delivery.
3. When updating the firmware, the corresponding SCSI hard disk should be in BL-US
working state.
The WDW MML command only supports updating the firmware of SCSI hard disks one
by one. However, when you specify an SCSI hard disk to update, you must be aware of
the consequences if something goes wrong. For example, if a unit needs to be restarted
during the programming of the flash memory, the firmware becomes corrupted and the
SCSI hard disk malfunctions. In this case, contact your local Customer Service Center
for advice.
Steps
1 Check the firmware version of the SCSI hard disk (WDV)

Check the current firmware version in the flash memory of the SCSI hard disk.
ZWDV:UT=<unit type>,DT=<I/O unit type>,DE=<I/O unit index>;
Example:
ZWDV:UT=OMU,DT=WDU,DE=0;
Expected outcome
The current firmware version in the flash memory is printed out. The firmware version of
the flash memory differs from the version in the disk file. If you want to update the firm-
ware, continue with the next step.
Unexpected outcome
• If the firmware version in the flash memory is the same as the one in the disk file,
you do not need to update the firmware for this SCSI disk. Continue checking the
firmware version of other SCSI disks.
• If the result is 'NOT SUPPORTED', you need to check whether the SCSI disk type
is MBA3xxxNP.
• If the type is not MBA3xxxNP, you do not need to update the firmware for this
SCSI hard disk.
• If the type is MBA3xxxNP, contact your local Customer Service Center for
advice.
DN9770985 Id:0900d805808b0638 79
Confidential
Updating firmware of an SCSI hard disk Software Configuration Management
2 Update the firmware from disk to flash memory of the SCSI hard disk (WDW)
a Set the SCSI hard disk to be updated to the BL-US state (ISC)
ZISC:,<unit_type>:<I/O unit type><I/O unit index>:BL-US;
Example:
ZISC:,OMU:WDU,0:BL-US;
b Set the FBAN information for the SCSI hard disk (IST)
ZIST:,<unit_type>:<I/O unit type><I/O unit index>:S-FBAN;
Example:
ZIST:,OMU:WDU,0:S-FBAN;
Check that the FBAN flag is set on.
Example:
ZISI:,<unit_type>:<I/O unit type><I/O unit index>:;
c Update the firmware of the SCSI hard disk (WDW)

ZWDW:UT=<unit type>,DT=<I/O unit type>,DE=<I/O unit index>;
Example:
ZWDW:UT=OMU,DT=WDU,DE=0;
d Repeat Step 1 to check if the two firmware versions are the same (WDV)
Expected outcome:
The update is successful and the firmware version in the flash memory is updated and
is now the same as the one on disk.
Unexpected outcome:
If the result is 'UPDATE FAILED', do not continue with the next step. Contact your local
Customer Service Center for advice.
3 Clear the FBAN info from the SCSI hard disk (IST)
ZIST:,<unit_type>:<I/O unit type><I/O unit index>:C-FBAN;
Example:
ZIST:,OMU:WDU,0:C-FBAN;
4 Set the SCSI hard disk back to the WO-BU state (ISC)
ZISC:,<unit_type>:<I/O unit type><I/O unit index>:WO-ID;
ZISC:,<unit_type>:<I/O unit type><I/O unit index>:WO-BU;
Examples:
ZISC:,OMU:WDU,0:WO-ID;
ZISC:,OMU:WDU,0:WO-BU;
80 Id:0900d805808b0638 DN9770985
Confidential
Software Configuration Management Deleting old SW builds
15 Deleting old SW builds

You can delete old and useless SW builds from a directory by using the WQD command.
If there are two builds in the directory, the build must not be active. The status of the SW
build must not be 'BU'.
You can delete the SW build either by using the name, status, or directory of the SW
build to specify the build you want to delete.
15.1 Deleting SW build by using the name, status, or directory

of the SW build
You can delete a software build by specifying its name, status, or directory.
Steps
1 Delete the SW build (WQD)

Use the name, status, or directory of the SW build to specify the build you want to delete.
ZWQD:STAT=<SW build status>:MAFILE;
If the build does not have a name, or its status is not 'UT' or 'BU', you have to use the
DIRE parameter to specify the target build.
ZWQD:DIRE=<directory name>:MAFILE;
If there are two SW builds in the directory, the following question appears:
DIRECTORY CONTAINS TWO PACKAGES:
PACKAGE 1 PACKAGE 2
NAME...........X0230 NAME...........X0230CD1
STATUS.........NW STATUS.........UT
DIRECTORY......X0_2_3_0 DIRECTORY......X0_2_3_0
PACKAGE ID.....X0 2.3-0 PACKAGE ID.....X0 2.3-1
ENVIRONMENT....X0 2.3-0 ENVIRONMENT....X0 2.3-0
DELIVERY.......CNR58448 18.22-0 DELIVERY.......CNR58448 18.22-0
CDID........... CDID...........
ACTIVE PACKAGE CAN NOT BE REMOVED
DO YOU WANT TO REMOVE PACKAGE X0230 FROM SOMAFI(S) ?
CONFIRM COMMAND EXECUTION: Y/N ?

• If you want to delete both SW builds, enter Y (Yes), otherwise enter N (No).
• If you have answered 'Y' for the previous question, the program asks you to confirm
whether the directory is deleted from the disks. Enter 'Y'.
2 Delete SW build only from one unit (WQD)

Give the name, status, or directory and the destination unit in the following command:
DN9770985 Id:0900d80580713625 81
Confidential
Deleting old SW builds Software Configuration Management
ZWQD:NAME=<SW build name>:MAFILE:MASU=<destination unit>;

A build with the 'UT' status cannot be deleted this way. If you want to delete a build with
'UT' status, use the name to specify the build you want to delete.
3 Remove the build from SOMAFI(S) (Y)

Enter 'Y' when the program asks you whether you want to remove the build from
SOMAFI(S).
4 Confirm the deletion (Y)

Confirm if the build is deleted from the disks. Enter 'Y'.
Further information
g In this case, you cannot activate the software build again, unless you have a backup
copy on some other media (for example, on a DDS tape).
15.2 Deleting SW build from the SOMAFI

You can take a SW build out of service by deleting its data from the Software Configu-
ration Management File (SOMAFI). After that, the status of the SW build becomes 'UD'
and it can be returned to use, if necessary.
Use the same command to delete a SW build from the SOMAFI as you use to delete a
SW build, but when the system asks if you want to delete the files, answer 'No'.
For general information on software builds, see Software builds.
Steps
1 Delete a build (WQD)

You can use either the name, status (if the status is 'NW' or 'FB'), or directory of the SW
build to specify the build you want to delete. It is also possible to use either DIRE or
MAFILE deleting mode.
For example, give the name to specify the build and the MAFILE deleting mode:
If you want to delete the SW build only from one unit, give the destination unit in the fol-
lowing command:
ZWQD:NAME=<SW build name>:MAFILE:MASU=<destination unit>;
2 Remove the build from SOMAFI(S) (Y)

The program asks you whether you want to remove the build from SOMAFI(S). Enter 'Y'.
3 Do not confirm the deletion from the disks (N)

Do not confirm to delete the build from the disks. Enter 'N'.
82 Id:0900d80580713625 DN9770985
Confidential
Software Configuration Management Deleting old SW builds
Further information
After this operation, the status of the build becomes 'UD' and you activate the build
again, if needed, by creating it with the WQC command.
DN9770985 Id:0900d80580713625 83
Confidential

Software Configuration Management: DN9770985 Issue 18-0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Configuration Management: DN9770985 Issue 18-0

Uploaded by

Copyright:

Available Formats

Software Configuration

f Important Notice on Product Safety

1 Software configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Preparing the system for software update . . . . . . . . . . . . . . . . . . . . . . . 20

3 Installing and deploying new software build. . . . . . . . . . . . . . . . . . . . . . 23

4 Installing and deploying a change delivery . . . . . . . . . . . . . . . . . . . . . . 34

5 Updating embedded software of a computer or preprocessor plug-in unit

6 Updating embedded software of an ET plug-in unit. . . . . . . . . . . . . . . . 43

7 Updating embedded software of an SW256B plug-in unit . . . . . . . . . . . 46

8 Updating embedded software of an AS7-D plug-in unit. . . . . . . . . . . . . 49

9 Updating embedded software of an SWPRO-C plug-in unit . . . . . . . . . 52

10 Updating embedded software of a DCAR1- A/AB plug-in unit. . . . . . . . 55

11 Updating embedded software of an HWAT-B, CLAB-U/CLAB-UA, CL2TG-

12 Updating embedded software of an ETP plug-in unit . . . . . . . . . . . . . . 66

13 Updating embedded software of an ETIP plug-in unit . . . . . . . . . . . . . . 71

14 Updating firmware of an SCSI hard disk . . . . . . . . . . . . . . . . . . . . . . . . 79

15 Deleting old SW builds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

15.2 Deleting SW build from the SOMAFI . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Changes made between issues 18-0 and 17-1

Changes made between issues 17-1 and 17-0

Changes made between issues 17-0 and 16-0

1 Software configuration management

1.1 Software configuration information

g Not all network elements have all of the following features.

The DX200 system includes a Software Configuration Management system which

MML programs for Software Configuration Management

MML programs closely related to Software Configuration Management

1.2 Software builds

g After returning a fallback copy, the SW build has FB status.

1.2.1 Software build subdirectories

- SOMAFI (SW Config. Management file)

SCMANA TMPDIR BLCODE MMDIRE LFILES CONVPR ASWDIR CDTEMP WEBFIL

CGI SCRIPT APPS HTDOCS ICONS GRAPHICS

Table 1 Subdirectories of WEBFIL

1.2.2 Status of a SW build

Changing the status of a SW build

(Note: the WKS command creates a new SW build,

Rollback statuses (WSR)

Fallback copy (WKS) Change of status (WSC)

Rollback statuses (WSR)

Figure 2 Statuses of a created SW build

Commands related to the states of SW builds

WSS Switch active package in directory

Status of a SW build during a software update

Situation Command Directory Active Traffic Trial

Figure 3 The effects of a new SW build deployment on other SW builds

• Deployment of a change delivery

Situation Command Directory Active Running

Figure 4 The effects of a change delivery deployment on other SW builds of the

1.2.3 Disk file versions

1.3 Update deliveries

1.3.1 New SW build deliveries

1.3.2 Change deliveries

• It contains new load modules, operating instructions, a change delivery description

Main installation tasks

1.3.3 Software update compatibility

2 Preparing the system for software update

2.1 Before starting an update

1 Check the alarms (AHO)

2 Print out the old data

4 Check the working states of the units (USI)

5 Make sure that the BU build is the default build (WQO)