SOFTWARE CONFIGURATION MANAGEMENT main tasksUpgrading network element software in fly : minimum loss of telecommunication services
Safecopy handling of software builds
Extension of Software production system of NET in network elements
Rapid development in Telecommunications area: new features are implemented by using software, not very often hardware
Upgrading network element software in fly should be easy, cost effective and trouble free.
Minimum lost of telecommunication services during upgrade procedure
Safecopy handling of existing software build
Software production system in NTC is extended to network element: concepts concerning build contents and version mode are inherited to network element. These are utilized when verifying build contents and consistence after it has been transferred from production system toNE
/ CMNEI6GX.F10 /:
“One of the advantages of a computer-controlled telephone exchange is that new telecommunications technology can be introduced into exchanges already in use by replacing and modifying the software, without being forced to modify the hardware at all or by implementing merely some minor modifications.
The rapid development in telecommunications means that software must be modified comparatively often, and that the modification must be done in exchanges already in use. On the other hand, there is the requirement that the costs of such an operation should be as low as possible, and the degradation caused to teletraffic minimal.”
“The highly-developed operation and maintenance system of the DX 200, as well as its RAM-based computer units, lay the foundation for successful software updates by means of MML programs.
The software configuration management, which forms an integrated part of the DX 200 system, is responsible for these tasks.”
“The software configuration management integrated in the DX 200 system functions as a bridge between the software production management, which forms part of the software development and production system, and the DX 200 systems operating in the network.
The objects of software management in network elements are created directly and smoothly from the objects of development environment management. This means that tracing of software features or errors is easy all the way, and that the possibility of mix-up has been minimized.”
NOKIA NETWORKS
* E. Hintsala
Fallback copying and Support for Remote Backup
Installing corrections to existing software build
Automatic return
Support functions
Software architecture
Reference documentation
Contact information
NOKIA NETWORKS
* E. Hintsala
Main tasks
maintaining several builds in hard disk (usually there is need for running build, new build and safecopy build)
Information and management
safecopying build ( = fallback handling)
returning automatically (or manually) back to previous build in fatal fault situation.
deployment new build or corrections (TRIAL method, restart methods)
/ CMNEI6GX.F10 /:
“By means of software configuration management commands the user can deploy a new software build in the exchange, update an existing build, (e.g. by setting a change delivery) test new software before its deployment, and safecopy the software of the exchange.”
“These functions make it possible to under controlled conditions transfer, load, test and deploy totally new software, or a specified part of it, in the exchange. This is possible with all RAM-based computer and preprocessor units. In order to do this, the exchange can maintain several software builds on its hard disk at the same time, disk space allowing. A sufficient maximum configuration for everyday needs is three builds.”
NOKIA NETWORKS
* E. Hintsala
Software build (shortly "build") = collection of programs and files performing required functions of a system
Default build
The default build is the build which is loaded in the exchange in restart.
Running build
The running build means the build that has been loaded into a unit, which usually means the default build.
Active build
There may be two builds in same directory: the active build means the build in a directory whose load modules are default versions.
Status of the software build
Assistance value for maintaining several builds in hard disk: backup build (BU), new build (NW), fallback build (FB) and other builds (UT).
"Software build"
A software build is a functional entity in the system,composed of programs and files, which together with appropriate hardware performs the required functions. Software builds are composed of program build and data build.
"Default build"
The default build is the build which is loaded in the exchange in restart.The default build status must be BACKUP, NEW or FALLBACK. After the load, all default disk operations are directed at the default build.
"Running build"
The running build means the build that has been loaded into a unit, which usually means the default build.
"Active build"
The active build means the build in a directory whose load modules are default versions. If there is only one build in the directory, it is active. If the same directory has two builds, one of them is active and the other one is not. The default build and running build must be active.
“Status of the software build”
"Package"
Package is a another term for software build. It is a conservative term for build and is still used for example in command names and syntaxes
BACKUP (BU)
“A disk backup copy of a running build loaded into memory of computer units”. This build is usually defined as default. This is why it is also usually running build. The BACKUP build cannot be removed with build management commands.
FALLBACK (FB)
A build on disk which is a copy of BACKUP build, and which usually functions as the on-line safe copy of the exchange build. The exchange can be returned to the FALLBACK build with MML commands. It is also possible to allow automatic return from BU build to FB build, if BU build does not function properly.
NOKIA NETWORKS
* E. Hintsala
identity string that is used for identifying unambiguously the different software builds on the disk and in the memory of a network element
Usually the package identifier consists of the implementation identifier and the version data of the environment,
e.g. GX 1.10-0
Software package (shortly "package")
Package is a another term for software build. It is a conservative term for build and is still used for example in command names and syntaxes.
software configuration management file, SOMAFI
management file that contains management information of all builds created in the system
SOMAFI is located in SCMANA directory
Common for all builds
description list of the build's load modules and their versions.
The master file is located in the same directory as the build (BLCODE)
Each build has its own MAFILE
NEW (NW) A new build on disk that has been introduced in the exchange for testing and subsequent deployment. The subtree may also be empty. It is possible to allow automatic return to the BACKUP build from the NEW build, if the NEW does not function properly.
UNTITLED (UT) It is also possible for the status to be untitled. The system allows more than one builds to have this status. A delivery to the customer, however, does not contain any build the status of which is not defined.
UNDEFINED (UD) Status of build is UNDEFINED, if it has not been created, but its master file and possibly also load modules are copied to disk. There is no information of this build in in the software configuration management file. Some operations however are possible to direct to UD build (for example creation, verification, comparison).
"Software build identity"
Software builds are identified with the following information:
- Package identifier, which consists of application identifier of build (e.g. GX),
build version (e.g. 8.9-0) and correction identifier (e.g. 2).
- delivery name, that is, C-number (e.g. CNR12345) and delivery version (e.g. 1.2-0)
- application identifier and version of environment definitions (e.g. B3 2.5-0)
- identifier of change delivery last installed to build (e.g. SX061003)
In addition to the above, the build can be identified in the network element
by a name given to it in the creation.
"Software configuration management file SOMAFI"
The exchange has a software configuration management file that contains all management information of builds created in the exchange.
"Software package master file MAFILE"
Software builds always have a description list which contains the build's load modules and their versions. Each build has its own description list in BLCODE subdirectory. Possible another copy of MAFILE in LFILES is because of file conversion environment, but it is not updated by SW management.
NOKIA NETWORKS
* E. Hintsala
Hard Disk Drive
CDTEMP Change Delivery modules temporary directory
MMDIRE Man Machine Interface system directory
BLCODE Boot loadable code directory
LFILES Loadable files directory
CONVPR Conversion program directory
WEBFIL Web based management files ( Only A2 and B7 (B6?) => )
18.bin
information about local software builds
management of software builds in hard disk
fallback handling and support for remote backup
installation and management of change deliveries
automatic return to spare build when deployment of new build fails
new software build deployment
Service terminal program block (PACKET) for handling SOMAFI information in extreme conditions
NOKIA NETWORKS
* E. Hintsala
Information about software builds
Typical information needed is listing of all builds in system, listing build contents/version information.
Vital information is often obtained when inspecting build change history, comparing differencies of builds or verificating one build.
NOKIA NETWORKS
* E. Hintsala
Information of builds in disk
Software build information along data in SOMAFI, along builds (MAFILE:s) in disk and along data UNPACK file.
Detailed information of build
Software build handling change history
Information of SW management operations along data stored to PAHIFI file.
Comparing builds
comparison is made by comparing MAFILE information of two builds
Verifying build contents and consistence
Checks build contents = modules and their versions along MAFILE. Calculates and verifies checksums of load modules
Interrogating software information loaded in units.
Module versions are read from memory of each unit
When verifying software build, same actions are executed as in build creation. These actions are explained in Software build management section. The difference though is, that adding build data to SOMAFI file is not needed, of course.
Information of SW management operations is stored to PAHIFI file. Event of all operations are also saved to PAHIFI. PAHIFI file information may be inspected by using history output command
Software build contents is outputted along data in MAFILE. This is also MAFILE listing command.
Software build comparison is done by comparing MAFILE information of two builds.
Software build information is outputted along data in SOMAFI. If outputting is executed by using EX parameter, command also searches all MAFILE:s from disk to find out also uncreated builds. EX parameter also calculates and outputs used and free disk space. When outputting by using RUN parameter, command outputs build identification information of units from UNPACK file.
Interrogating software information loaded in units searches version information of load modules from load chain and/or from file catalog of unit and outputs information.
NOKIA NETWORKS
* E. Hintsala
C: ..... CREATE SOFTWARE PACKAGE
D: ..... DELETE SOFTWARE PACKAGE
B: ..... VERIFY SOFTWARE PACKAGE
L: ..... LIST SOFTWARE PACKAGE CONTENTS
M: ..... COMPARE SOFTWARE PACKAGES
* V: ..... INTERROGATE MODULE VERSION LOADED IN UNIT
* = most needed
WQB
The command is used to compare the contents of a given Software Package Master File (MAFILE) with the modules in the directory.
WQH
The command is used to output the history of the changes made in software packages.
WQL
The command is used to list the contents of a software package.
WQM
The command is used to compare the Software Package Master Files (MAFILEs) with each other and to output the differences detected.
WQO
The command is used to output the packages created in the exchange, the packages on the disk in the exchange and the software packages running in the units.
WQV
The command is used to list the version data of modules loaded into the unit. In A series command also lists the started actors in a Chorus unit.
NOKIA NETWORKS
* E. Hintsala
NAME . . . . . JUHLA
STATUS . . . . BU
DIRECTORY. . . PAKETTI
IPILIBGX.IMG 1.7-0 B3 2.6-0 OK OK
MODULEGA.IMG 1.3-0 B3 2.6-0 2.21-0 OK OK
ASCHANGA.IMG 1.3-0 B3 2.6-0 2.21-0 OK OK
VTERMDGX.IMG 5.11-0 B3 2.6-0 OK OK
VIDASTGX.IMG 3.1-0 B3 2.6-0 OK OK
VTCOMMQV.MML 1.21-0 B3 2.6-0 OK OK
VTCOMME1.MTF 1.21-0 B3 2.6-0 OK OK
VIFHANIF.MML 1.17-0 B3 2.6-0 OK OK
VIFHANE1.MTF 1.17-0 B3 2.6-0 OK OK
VT1FILGX.IMG 2.2-1 B3 2.6-0 2.21-0 OK OK
VIPARAGX.IMG 2.3-0 B3 2.6-0 2.21-0 OK OK
OMOLIBGX.IMG 2.11-0 B3 2.6-0 OK OK
.
.
.
SOFTWARE PACKAGE ADMINISTRATION COMMAND <WQ_>
< H;
INFLUENCE:
SX 5.14-2 0 CID000SX 4.1-0
PACKAGE CHANGED IN OMU 1996-06-24 12:22:29
INFLUENCE:
SX 5.14-1 CID000SX 4.1-0
SX 5.14-2 0 CID000SX 4.1-0
.
.
WQL:STAT=BU,;
EXECUTION STARTED
PACKAGE:
FILE VERSION FRZ-DATE ENVIRONMENT DEL.VER DIRE TYP S PAGE 1
MAFILEGX.IMG 1.5-0 95/11/13 M8 3.1-1 6.14-0 BLCODE C N
ASMANAGX.IMG 3.2-0 M8 3.1-1 BLCODE C Y
IPRECEGX.IMG 2.3-0 M8 3.1-1 BLCODE C Y
IPSENDGX.IMG 2.3-0 M8 3.1-1 BLCODE C Y
IPILIBGX.IMG 1.7-0 M8 3.1-1 BLCODE C Y
.
.
.
NEW PACKAGE (N): OLD PACKAGE (O):
---------------- ----------------
ENVIRONMENT. . M8 3.1-1 ENVIRONMENT. . MX 7.21-3
DELIVERY . . . CID30478 6.14-0 DELIVERY . . . CID30478 8.13-0
CD-ID. . . . . CD-ID. . . . .
ASMANAGX.IMG N:3.2-0
WQO:CR;
PACKAGE-ID (REP-ID) DELIVERY
M8 3.1-0 1 CID30478 6.14-0
MX080210
M8 3.1-0 1 CID30478 6.14-0
MX080210
MX 7.21-3 CID30478 8.13-0
MX 7.20-2 CID30678 8.16-0
WQV:OMU:A%;
APPARAG2.PAC 2.1-0 96/09/21 GSMENVM8.PAC 3.1-1 CID30478 6.14-0 3.1-0
ALARMPGX.PAC 3.4-0 97/02/13 GSMENVM8.PAC 3.1-1
ASYLIBGX.PAC 3.2-0 96/10/24 GSMENVM8.PAC 3.1-1
AITEXTGX.PAC 1.1-0 **/**/** GSMENVM8.PAC 3.1-1 CID30478 6.14-0 3.1-0
ALBLOCGX.PAC 1.4-0 **/**/** GSMENVM8.PAC 3.1-1 CID30478 6.14-0 3.1-0
AMTEXTGX.PAC 1.9-0 96/04/25 GSMENVM8.PAC 3.1-1 CNSTNT_F
ALEXTEGX.PAC 1.2-0 **/**/** GSMENVM8.PAC 3.1-1 CID30478 6.14-0 3.1-0
ALHIST
ASAUNI
AOTABL
AFTABL
ARTABL
.
.
.
Management of software builds
Typically there is need to maintain three or more different software builds on the hard disk of a network element.
Typical managing operations are build creation, deletion, selection and status changing.
Typically there is need for three or more different software builds on the hard disk of a network element: primary build (BU), fallback build (FB), new build (NW or UT). Also there may be several other software builds e.g. for test purposes or previous safecopy builds (UT or UD).
Typical managing operations are build creation, deletion, selection and attribute settings.
NOKIA NETWORKS
* E. Hintsala
Creating build
Creating build command checks build contents and verifies condition of its components. New build is also added to SOMAFI file.
Deleting build
Old unnecessary builds may be deleted by MML command: build is deleted from SOMAFI and files are deleted from disk
Setting default build
build is set to default by MML command. Setting default is done in SOMAFI file and it means that this build is loaded in next restart.
Switching active build in directory
After CD installation new build is switched active in directory, which means that it is loaded into units in next restart.
Changing statuses of builds
build statuses may be changed in SOMAFI. This has only administrative meaning.
After build modules are copied to disk, a new build is created by MML command. Creating command checks build contents: all modules listed in MAFILE file must be in disk and module versions must be same between module header information and MAFILE information. It also calculates checksums of modules and compares against checksum in module header information. New build is also added to SOMAFI file.
New build is set to default by MML command. Command changes default information in SOMAFI. Command also activates system restart (after confirmation) and this way default build is loaded into units.
Old unnecessary builds are deleted by MML command: modules are deleted from disk and build is removed from SOMAFI.
After CD installation new build is switched active in directory: Change Delivery modules are changed active in disk directory. Status, default build and active status are changed between builds in SOMAFI.
build statuses may be changed. For example after NW build is taken into use, it is changed from NW to BU by MML command. Statuses are changed in SOMAFI.
NOKIA NETWORKS
* E. Hintsala
Managing operations of software builds
Along build identification information build has name (free 8 characters) and status (BU, FB, NW, UT or UD).
Operations are directed to builds easily by using name or status
Only FB, BU or NW build can be default build (which is loaded in start-up)
FB
BU
NW
UT
WSR
WSR
WSR
WSC
WSC
WSS
WSS
UD
WKS
WSD
WQD
WQC
WQD
IBC,
MAS
BACKUP (BU)
“A disk backup copy of a running build loaded into memory of computer units”. This build is usually defined as default. This is why it is also usually running build. The BACKUP build cannot be removed with build management commands.
FALLBACK (FB)
A build on disk which is a copy of BACKUP build, and which usually functions as the on-line safe copy of the exchange build. The exchange can be returned to the FALLBACK build with MML commands. It is also possible to allow automatic return from BU build to FB build, if BU build does not function properly.
NEW (NW) A new build on disk that has been introduced in the exchange for testing and subsequent deployment. The subtree may also be empty. It is possible to allow automatic return to the BACKUP build from the NEW build, if the NEW does not function properly.
UNTITLED (UT) It is also possible for the status to be untitled. The system allows more than one builds to have this status. A delivery to the customer, however, does not contain any build thestatus of which is not defined.
UNDEFINED (UD) Status of build is UNDEFINED, if it has not been created, but its master file and possibly also load modules are copied to disk. There is no information of this build in in the software configuration management file. Some operations however are possible to direct to UD build (for example creation, verification, comparison).
Note: Currently SOMAFI can contain max 8 builds which also limits the amount of UT builds in the network element. Another limitation is disk quota.
NOKIA NETWORKS
* E. Hintsala
C: ..... CREATE SOFTWARE PACKAGE
D: ..... DELETE SOFTWARE PACKAGE
B: ..... VERIFY SOFTWARE PACKAGE
L: ..... LIST SOFTWARE PACKAGE CONTENTS
M: ..... COMPARE SOFTWARE PACKAGES
V: ..... INTERROGATE MODULE VERSION LOADED IN UNIT
WQC
WQD
The command is used for deleting a package from the SOMAFI file and, thereafter, the modules belonging to it. It is possible to choose between MAFILE based and directory based deleting. In MAFILE based deleting files are deleted only if they are not defined in another MAFILE file existing in the same directory.
NOKIA NETWORKS
* E. Hintsala
* D: ..... SELECT DEFAULT SOFTWARE PACKAGE
* C: ..... CHANGE STATUS OF TWO SOFTWARE PACKAGES
S: ..... SWITCH ACTIVE PACKAGE IN DIRECTORY
R: ..... ROLLBACK STATUSES OF CREATED PACKAGES
A: ..... ALLOW AUTOMATIC RETURN TO SPARE PACKAGE
B: ..... DENY AUTOMATIC RETURN TO SPARE PACKAGE
I; ..... INTERROGATE AUTOMATIC RETURN SETTINGS
* = most needed
WSD
The command changes the default software package of the network element and restarts the system with the chosen default package.
WSC
The command interchanges the status data of two software packages.
WSS
The command selects the active package of the directory. The package given as a parameter of the command becomes the active package of the directory. If the package in question was already active, the active package does not change.
WSR
The command normalizes the statuses of packages after a return to the package having the FB status has been necessary: the status of the FB package is changed to BU, the status of the package which functioned as BU is changed to NW and if there is a package with the NW status, this is changed to the UT status.
NOKIA NETWORKS
* E. Hintsala
MAFILEGX.IMG 1.5-0 B3 2.6-0 2.21-0 OK OK
IPILIBGX.IMG 1.7-0 B3 2.6-0 OK OK
MODULEGA.IMG 1.3-0 B3 2.6-0 2.21-0 OK OK
ASCHANGA.IMG 1.3-0 B3 2.6-0 2.21-0 OK OK
VTERMDGX.IMG 5.11-0 B3 2.6-0 OK OK
VIDASTGX.IMG 3.1-0 B3 2.6-0 OK OK
VTCOMMQV.MML 1.21-0 B3 2.6-0 OK OK
VTCOMME1.MTF 1.21-0 B3 2.6-0 OK OK
VIFHANIF.MML 1.17-0 B3 2.6-0 OK OK
VIFHANE1.MTF 1.17-0 B3 2.6-0 OK OK
VT1FILGX.IMG 2.2-1 B3 2.6-0 2.21-0 OK OK
VIPARAGX.IMG 2.3-0 B3 2.6-0 2.21-0 OK OK
OMOLIBGX.IMG 2.11-0 B3 2.6-0 OK OK
OSITUSGX.IMG 3.17-0 B3 2.6-0 OK OK
SYSMONGX.IMG 2.2-0 B3 2.6-0 OK OK
CLUCIFGX.IMG 3.9-0 B3 2.6-0 OK OK
MRSTREGX.IMG 2.2-0 B3 2.6-0 OK OK
HAPEROGX.IMG 1.3-0 B3 2.6-0 OK OK
.
.
.
/* IDENTIFY PRINTING MODE:
CONFIRM COMMAND EXECUTION: Y/N ? Y
PACKAGE TUHOA REMOVED FROM SOMAFI(S)
DO YOU WANT TO DELETE DIRECTORY POIS FROM DISKS ?
CONFIRM COMMAND EXECUTION: Y/N ? Y
/* PRESS 'S' TO STOP EXECUTION */
NOKIA NETWORKS
* E. Hintsala
DELETING DIRECTORY FROM DISKS:
.
.
.
.
.
.
.
.
.
SOFTWARE PACKAGE STATUS HANDLING COMMAND <WS_>
< D
FOR A MANUAL SOFTWARE UPDATE.
DATA UNITS:
PACKAGE IDENTIFICATION; */
WSD:STAT=NW:;
EXECUTION STARTED
STATUS OF NEW DEFAULT PACKAGE IS: NW
MMI SYSTEM READY 00-05-29 04:22:34
NOKIA NETWORKS
* E. Hintsala
Local Fallback copying of software
A consistent copy of BU-build to another directory in local hard disks
Consistent situation in disk files is achieved by dumping databases and preventing disk file updatings before starting copying
Copying from hard disk for example to DAT is not included in this feature
One command for whole fallback copying procedure (inside hard disk)
After semantic checks, main job is done in background by program block, MML is not needed after starting
As a result a new FB build is created or existing FB is updated
FB build may be taken into use by using WSD command or by automatic return
- All disk activities of running build BU are put in hold before copying and released after copying is finished. This is executed in all units that have disks with load modules (for example CHU has only charging data buffer files and is not handled).
- Existing FB can be updated by copying only changed (archive marked) or only data files.
- ASWDIR (Application Specific Working Directory) and optional user specified directories (if specified) are also copied.
- SOMAFI file (and also other SCMANA directory files) are copied to FB build.
- “Local copying” => copying for example to DAT tape must be done separately using MML commads of I/O system.
NOKIA NETWORKS
* E. Hintsala
Properties
Databases are dumped from memory to disk and database files are updated to disk not until copying is ready
File system updating to disk is also prevented in a consistent state (updatings under execution are done, new updatings are put to hold)
Concurrent copying in different disk units means less total copying time
Fast disk-to-disk copying inside one disk unit
Copying of all files listed in MAFILE
Copying of ASWDIR files, but not ASWDIR subdirectories!
Copying of user defined optional directories (with MML parameter)
VAD*.*, VAT*.* (in LFILES), *.EMM, *.CMD (in MMDIRE) , BOP*.* (in LFILES?) LICENCE and WEBFIL subdirectories as such are also copied as such
Copying in backround
Log files are created
Notices and alarms which tell about the progressing and possible failures.
Possibility to output full information about fallback build contents and copying procedure by means of MML
Preparations for restoring (for example SOMAFI, where FB is marked as default, is copied to SCMANA under FB build directory)
- New copying services (parallel copying between all disk units and fast disk-to-disk copying) are used.
- One command => no DUPHAN (disk file update preventing) or DBHAND (database disk update preventing) is needed: these actions are activated by fallback copying program block.
- Also ASWDIR contents and SOMAFI file are copied automatically to FB build.
- Background copying is started, monitored and if necessary, interrupted by MML commands.
- Alarms informing fallback copying in progress and also alarms in error case.
- User may specify 6 directories which contents is fully copied to FB build.
- When Change Note Management feature is used (Change Deliveries are installed), FB build may be updated along CD.
- Fallback copying utilizes Software Configuration Resource Management: simultaneous SW handling MML command execution is administrated and conflicting commands are prevented.
NOKIA NETWORKS
* E. Hintsala
Files in ASWDIR
DATA
Files in ASWDIR
ARCHIVE
Changed files from ASWDIR
Changed files after installation of CD (CD information of FB build is updated)
Files of user defined optional directories (6)
Previously there was only ALL and DATA options. In M7 and S5 releases ARCHIVE option came along. In B3 and M8 possibility to update CD to FB came along.
NOKIA NETWORKS
* E. Hintsala
S: ..... START FALLBACK COPYING
Q; ..... QUIT FALLBACK COPYING
I: ..... INTERROGATE FALLBACK COPYING
P: ..... DISPLAY FALLBACK LOGFILE
WKS
The command starts fallback copying as background execution in the hard disk from BU package to another directory. As a result new FB package is created (FULL type copying). Additionally it is possible to start background updating of existing FB package by copying all data marked files from BU to FB (DATA type copying). Yet another choice is to update only changed files from BU to FB (ARCHIVE type copying).
WKQ
WKI
The command for inquirying the phase of fallback copying which is under execution.
WKP
With the command it is possible to investigate some of the log files which are created during fallback copying. There is one log file for each fallback copying mode (3) and additionally two last versions of each. The log files are located in SCMANA subdirectory of hard disk. It is also possible to output log file contents of fallback copying which is still under execution.
NOKIA NETWORKS
* E. Hintsala
NOKIA NETWORKS
* E. Hintsala
WKP:FULL:TOTAL;
/* PRESS S TO STOP DISPLAYING */
TYPE: FULL DATE: 2000-05-29 TIME: 02:52:38:35 USER_ID: SYSTEM
PACKAGE NAME ....... KURSSI
FALLBACK COPY LOG HANDLING
STARTING DUMPING OF DATABASE
DUMPING OF DATABASE STARTED
FORMING COPY LISTS OF MAFILE FILES
DUMPING OF DATABASE STARTED
FALLBACK COPYING MAFILE FILES
FALLBACK COPYING ASWDIR FILES
UPDATING FALLBACK DATA IN SOMAFI
TERMINATING FALLBACK STATE OF DATABASE
TERMINATING FALLBACK STATE OF DATABASE
RESUMING DISK UPDATES OF DISKS
NON UNIT SPESIFIC PHASE:
OPERATIONS ENSURING RESTORE
UPDATING PACKAGE HISTORY
.
.
.
(FB build is
backup from memory)
61.bin
Semantic checks (is fallback copying possible ?)
Preventing disk updates of memory files in all disk units
Dumping of all databases and preventing their disk updates
Copying of MAFILE files, ASWDIR files and files of user defined directories in all units
Resuming of databases
Finishing touches of whole procedure
- Semantic checks include for example:
* SW Management resource reservation
* Database state checking
- Disk files are freezed in disk to consistent state and released after copying. Events taken place during fallback copying are updated from memory log to disk.
- Databases are set to backup state:
* database files are freezed to consistent state and
copied to disk
state
* after copying files are released and events are updated from log
to disk files.
- Copying includes all MAFILE files in all disk units, ASWDIR contents, SCMANA contents and
optional directories contents.
- Fallback log file is updated frequently during procedure.
- Finishing touches of procedure include for example log file updating, SOMAFI file and SCMANA directory safecopying and freeing resources (OS buffers, Software Configuration Management resource).
NOKIA NETWORKS
* E. Hintsala
Restore of fallback build
It is all manual, except automatic return from BU to FB (in IPA from A11 on? Or A10?)
At least in theory it is possible to happen several different error situations in which restoring is needed, for example:
some file is corrupted in disk
some directory is corrupted in disk
spare disk is broken (in DX200)
both disks are broken
Recovering depends on problem situation and may consist of:
Copying files or directories from working disk to problem disk (in theory, perhaps not in practise)
Changing FB build to default and restarting whole system (WSD does all this). This is the way to do it.
Returning part or all files from DAT and restarting whole system or part of it (very difficult)
- Restoring is usually totally manual: Setting FB active or copying of files from disk to disk or from DAT to disk and restarting units or whole system.
- In case of remote session it is possible to use ‘Automatic Return’ feature which automatically returns to previous build in case of error situation. Possible return cases are reset loop in OMU and remote connection malfunction.
- restore process can be automated using HIT/SOUP macros which are run in PC attached to the DX 200 network element
NOKIA NETWORKS
* E. Hintsala
- SOMAFI: The Software Configuration Management File contains information on software builds created in the exchange.
- FB*.LOG (FBLIST): Files (FB_FULL.LOG, FB_ARC.LOG, FB_DATA.LOG) contain detailed information about actions made during fallback copying software build.
-MAFILE:The Software Package Master File specifies all the files that belong to a software build.
- ENSURE: Software Package Fallback copying MML . With this MML fallback copying is started and interrupted. It is also possible to monitor progressing of fallback copying and output contents of fallback copying log file.
- SW5ADM: This program block takes care of fallback copying of software build. Copying takes place from BU build to to another directory. As a result FB build is created (FULL type fallback copying).
- SWFLIB: General use library offering synchronic services to Software Configuration Administra´tion program blocks
- IOFLIB: With I/O library routines program blocks outside IOESEB service block can use services of IOESEB.
- SOWADM: The Software Configuration Administration Program Block offers services necessary in handling and managing software builds. Apart from that, it supervises the validity of the software configuration of the exchange.
- DBSMAN: The Disk Updating System Management Program Block (DBSMAN) is a part of the multidatabase system, its purpose being to carry out the disk updating of the multidatabase system as quickly as possible and to enable copying of the database files from the disk into the main memory and vice versa.
- DBMANA: A general name for database managers which always have unique name. For example EQUIPM, HORROR.
- FEDSER program block provides upper level of memory file disk interface.
- ELGAME: Event Log Handling Program Block saves service requests to event log to DAT tape or disk drive. Service requests are handled by application program blocks and they have to inform ELGAME of theses requests.
- CPYMAN program block will offer asynchronous services for mass memory file copying and for reading disk directory directly. It is possible to copy from one to several files by single request. Files to copy can be identified by giving a list of files and subdirectories or using wild characters and leaving the searching of matching files to CPYMAN family.
NOKIA NETWORKS
* E. Hintsala
30220 Local Software Package Fallback copying
10193 Mass Memory File Copying
10413 Disk Updating System of Memory Files
30222 Software Configuration Management Resource Manager
30558 Support for remote Backup
NOKIA NETWORKS
* E. Hintsala
Compressing of copied files to local hard disks.
Cleaning of disk after transfer
NOKIA NETWORKS
* E. Hintsala
Information about fallback copied files is stored in transfer list (TRANSFER.LST) in every fallback copy
New transfer list is created during fallback copying if FULL copy is taken or list can not be found. In other cases existing list is updated
Transfer list is stored in FB build's SCMANA directory
Client can ask for support operations if fallback has been taken and transfer list exists
Files are compressed to OMU's hard disk to NMS_TEMP directory
Client itself moves files xxxyyy.ZIP to NMS
After transfer client informs system for finihing tasks compressed files and temporary directory are deleted from disk
If transfer was succesful, ZIP files and also TRANSFER.LST is deleted
NOKIA NETWORKS
* E. Hintsala
Message Interface
There is only message interface for using support for remote backup
three phase protocol
Preparation includes file compression and gathering compressed files to the NMS_TEMP directory's subdirectories
Readiness of preparation can be inquired with ready messages. If preparation is ready, names and locations of compressed files are returned to the client.
After transferring the compressed files, the client have to inform ending, so the NMS_TEMP directory and it's contents can be deleted. If the transfer was successful, the transfer list will be deleted, too.
NOKIA NETWORKS
* E. Hintsala
Updating existing build (instead of whole new build):
quicker = less work amount + minimum lost of telecommunication services
Customer does not want anything else but specific corrections between main releases
Installing only Change Deliveries designed well beforehand in NTC means also better customer support
Safe activation/deactivation of software corrections as well as exact information of installed CD:s
Number of delivered network elements is increasing and new features and error corrections must be delivered more and more
Updating existing build is quicker and means less work amount and minimum lost of telecommunication services
Customer does not want anything else but specific corrections between main releases. This is mainly because of possibility to otherwise ruin other features carefully tested (another choice would be to take a whole new software build with all corrections)
Installing only Change Deliveries designed well beforehand in NTC means also better customer support for example in fault detection situations: exact knowledge of versions of software modules remains.
Support for managing Change Deliveries in DX network element means controlled installing and safe activation/deactivation of software corrections as well as exact information of installed CD:s in network element
NOKIA NETWORKS
* E. Hintsala
Change Delivery (former CN set)
A Change Delivery is a document attached to the modified product at delivery to the customer. Typically, this shall contain:
one or several Change Notes
the product or the part of it which has been modified
instructions for the implementation of the modified product
the Manuals for the modified product”
Change note
notification of a change or modification in a product (equipment or a plug-in unit, software or hardware) sent to a customer
Change Delivery File Description List, CFLIST
File contains information of Change Notes and their contents (load modules and supplementary files) of a Change Delivery
change delivery ID (= the file name of the CFLIST)
change note IDs of the change delivery
the names and the versions of the modules included in that change delivery
"Change note"
A note sent to the customer about a change in the product (hardware product or plug-in unit; software or hardware). A change note should briefly describe the following: identification of old and new product (product code and version), what changes have been made to the product and why, and the effects of the changes on compatibility, installation and use. A change note can be used to repair both hardware and software faults. Change notes on hardware repairs alone are not covered by the feature.
"Change delivery"
A change delivery usually contains one or more change notes, and the commissioning and reference manuals of a changed product or part of it. With this feature, a change delivery means a software delivery into an existig build. It also contains load modules to repair faults and other possible files, such as documents.
“CFLIST”
The CFLIST file contains information of Change Notes and their contents (load modules and supplementary files) of a ChangeDelivery. File is disk work file of SW2ADM. File is copied by user to subdirectory CDTEMP under build main directory before installation. SW2ADM program block reads file when installing Change Delivery to DX network element and copies this file to ASWDIR-subdirectory.
NOKIA NETWORKS
* E. Hintsala
... CFLIST contents continues:
names of supplement files which are typically test instruction documents, CN description documents etc
Software Package Updates History File, HIFILE
File contains information of change deliveries and change notes installed to system
HIFILE contains information of all CD:s installed to specific release level build
Basic Information is same kind as in CFLIST file
Additionally there is information of old version of load module, build identification information (where CD is installed to), installation date, username and Change Delivery state (passive / created / active / removed)
“HIFILE”
The HIFILE contains information of change deliveries and change notes installed to system. File is ASCII file. File is a disk work file of SW2ADM -program block. File is located under build main directory in subdirectory ASWDIR in hard disk of DX network element. SW2ADM writes information of build, change delivery, change notes, old and new load modules, date etc. to file when change deliveries are installed. Change Deliveries have also state information in HIFILE. Possible states are PASSIVE, CREATED, ACTIVE and REMOVED. State information is updated during installation procedure.
NOKIA NETWORKS
* E. Hintsala
CD contents is described in CFLIST file
Installation of several CD:s can be included in same procedure (B4,S7 =>)
Load modules are copied from temporary directory to final directories during installation
Full information of the CDs/CNs and their installation is saved to the history file HIFILE.
All CFLIST:s included are copied to ASWDIR directory of build
New MAFILE with updated version information of changed modules is created (using old one as base). (Or mafile can be included in CD)
New build is created to same directory with existing build
Possibility to speed up creating if checking only changed modules is selected
This new build is activated by switching it active in directory and restarting units that have changed modules
build identification information is updated to those units that has not been changed
The latest installed CD:s can be removed by MML command
Possibility to return safely back to the old build.
The current build will always be up-to-date and well under Software Management.
CDs are carried out with floppy disks or DAT tape, where are all the changed modules and the CFLIST file.
Load modules are copied to right directories during installation: for example code to BLCODE, MML:s to MMDIRE etc.
Full information of the CDs/CNs as well as installation data (date, username, build information etc) is saved to the history file HIFILE. This information can be outputted by means of MML commands.
All CFLIST files as well as Supplement Files (installation instructions etc) included are copied to ASWDIR directory of build
New MAFILE with updated version information of changed modules is created (using old one as base).
New build is created to same directory with existing build: build contetnts is verified and new build identification information is updated in SOMAFI.
Possibility to speed up creating if checking only changed modules is selected as a parameter of create command.
This new build is activated by switching it active in directory and restarting units that have changed load modules
build identification information is updated to those units that has not been changed: it is not necessary to restart units only to get build identification information updated in them.
The latest installed CD:s can be removed by means of MML command and it is possible to return safely to the old build.
Software build identification information is also updated during the CD installation: so the current build will always be up-to-date and well under Software Management.
NOKIA NETWORKS
* E. Hintsala
Local Installation at the Site
Contents of the floppy disk(s) is copied to the temporary directory CDTEMP on the hard disks (1).
For maximum safety fallback copy is taken from the running build (WKS)
The CD:s are installed with MML command. (WNA, 2)
A new build is created to the same directory, where the current build is located. (WQC, 3)
The new build is changed as active.(WSS, 4)
The new build including installed CD:s is taken into use by restarting needed units.
Finally the package id is updated to those units that has not to be restarted (WNJ)
Change
Deliveries
1
2
4
3
Network element
- CD contents copying to CDTEMP directory supports also delivering CD by DAT or transferring files via O&M network. So, SW configuration management needs only change note to the CDTEMP directory.
- CD installation procedure provides safe return to old build, but for maximum safety FB may be taken before taking new build into use. This is useful in case of remote update: automatic return changes FB build into use if new build does not work.
- When CD:s are installed with command WNA:
* All CFLIST files specified in WNA command (*.CFL) are copied from CDTEMP to ASWDIR
* Load modules are copied from CDTEMP to correct directories of build
* New MAFILE is created by using old as a base and updating new module information into it
* History information of CD:s are updated to HIFILE file.
* It is also possible to deliver new MAFILE along CD. In this case new MAFILE is used. In this case only single CD can be installed during same procedure!
- When creating new build it is possible to select checking of only changed modules. This speeds up creating if existing build is already known to be ok. For maximum safety complete checking may be selected and in this case all load modules (old ones too) are checked.
- After new build is created, it is switched active in directory. Now it is ready for to be taken into use by restarting those units which include changed load modules.
- If new build does not work as desired, it is quite possible to return back to old build by activating it and restarting same units which were restarted when taking new build into use.
- Finally those units that do not have changed load modules may be updated along new build identification information by MML command => unnecessary restarting of units is not needed.
83.bin
A: ..... ADD CHANGE DELIVERY
D: ..... DELETE CHANGE DELIVERY
I: ..... INTERROGATE CHANGE DELIVERY
J: ..... UPDATE PACKAGE IDENTIFIER
WNA
The command WNA is used to install desired change deliveries from cdtemp directory to destination package. The name or status of the destination package and indexes of change deliveries (along dynamic guide) are identified in the command.
WND
The command WND is used to delete change deliveries which are in PASSIVE state from a package, and to delete the traces of an interrupted or failed change delivery installation. The destination package name is given as command parameter.
WNH
The command WNH is used to output the change delivery history data for one package at a time. The command parameters define the package name or status. It is also possible to identify several search key parameters. These parameters are: identifier of a change delivery or change note, change delivery state, the installation date and file name.
WNI
The command WNI is used to interrogate and to output change deliveries and their contents. The command includes parameters for directory/package name and change delivery identifier.
WNJ
The WNJ command is used to update the package identifier after the installation of a change delivery. With the command you can:
- update all the units that are not affected by the change delivery
- make a forced update to all units or a specific unit
- check the range of the changes without updating the package identifier.
NOKIA NETWORKS
* E. Hintsala
*
Automatic return to spare build when deployment of new build fails
Makes remote build handling operations safer
in remote software upgrade remote connection problems (time-out) do not cause the permanent malfunctioning of the switch
also possible to allow in case of reset loop of the OMU
Useful in case there is a lot of small network elements in the telecommunication network. In this case way remote operating is reasonable
Not very useful in case of large manned network elements nor in case of 2n OMU (remote connection always stays to one or the other unit)
Worl
NOKIA NETWORKS
* E. Hintsala
Properties
automatic return is made based on reset counter or timer and it is possible in following situations
During TRIAL configuration (NW => BU) DX200
After cutover (NW => BU), if the HOT restart does not work and also the WARM restart fails (DX200).
If there are more than 3 restarts within 10 minutes timeframe. When there are no units in TRIAL configuration (NW => BU or BU => FB).
Reset counters used in the automatic return are not updated during HOT and diagnostic restarts.
The automatic return does not happen during those types of restarts, even if it is allowed.
NOKIA NETWORKS
* E. Hintsala
Automatic return in case of reset loop
The reset counter of the default build is decremented during each OMU restart. Then it is also checked if the counter is in permitted range.
If reset counter decrements to zero (0) and the automatic return is allowed, the OMU’s initial loading changes the older build as a default and starts loading with it.
The rest of the units are restarted too, because they can not work with different build as used in OMU. Recovery checks and triggers this?
If the automatic return was done during TRIAL configuration, only OMU and the other TRIAL units are restarted with old build. So the resets do not disturb ongoing calls.
The reset counter is initialized to nominal value (3), when the OMU has been working long enough (10 or 15 minutes?). It is initialized also when the SW configuration management system starts to work and notices that the automatic return has happened.
NOKIA NETWORKS
* E. Hintsala
Automatic return in case of remote connection time-out
The timer has initial value which is user defined. Default value is 600 seconds.
Each time when OMU restarts it is checked, if the timed return is allowed. If it is allowed, the timer is set to decrease for the return.
If the automatic return is not disabled before timer expires, the OMU prepares the automatic return and restarts itself.
The rest of the units are restarted too, because they can not work with different build as used in OMU.
If the timed return was done during TRIAL configuration, only OMU and the other TRIAL units are restarted with old build. So the resets do not disturb ongoing calls.
The timer of the return must be cancelled, when the remote connection is established. This must be done with MML command by user in DX200. In I-HSPA it is done automatically by SOKERI (when OMS pings).
NOKIA NETWORKS
* E. Hintsala
D: ..... SELECT DEFAULT SOFTWARE PACKAGE
C: ..... CHANGE STATUS OF TWO SOFTWARE PACKAGES
S: ..... SWITCH ACTIVE PACKAGE IN DIRECTORY
R: ..... ROLLBACK STATUSES OF CREATED PACKAGES
A: ..... ALLOW AUTOMATIC RETURN TO SPARE PACKAGE
B: ..... DENY AUTOMATIC RETURN TO SPARE PACKAGE
I; ..... INTERROGATE AUTOMATIC RETURN SETTINGS
WSA
The command allows an automatic return to the spare package either from NW package to the package running under the BU status or from BU package to the package running under FB status.
WSB
The command denies the automatic return to spare package, either in time supervision or in both time supervision and because of reset cycle.
WSI
The command checks the allowed situations and methods of automatic return and the value of the timer.
NOKIA NETWORKS
* E. Hintsala
(Testing & and deployment of new SW build)
TRIAL configuration is functional split of network element with ORIGINAL and trial side TRIAL. One of these sides is the deployed side. The deployed side (mainly) handles the trafic.
Spare units as TRIAL configuration (roughly)
Sides are invisible for each other (when using logical addressing and with FUNLIB basic services). So they work independently. But physical addressing is not blocked, it works normally. Also FUNLIB has trial specific routines which can handle both trial and original side units.
What's
that@#$?!?
Splitted configuration
Check this
ORIGINAL SIDE
TRIAL SIDE
1. In the first box on the left we can see the network element in its normal "state". A SW build with BU -status is running in the NE.
2. In the second box trial configuration have now been created. The NE has been divided into two independently working sides which are called the original- and trial side. The build which was originally running in the NE is still running but now there is also another build running in the NE. The BU-build is running in the original side and the new build is running on the trial side.
Now it is possible to test the new build without disturbing traffic (redundancy of 2n and replaceable n+1 units is however lost).
The switching capacity resides on the original side until cutover is executed. Trial side will handle the traffic after cutover.
3. In the third box cutover has been executed and trial configuration has also been completed. The NE is no longer divided into two sides as the new SW build have been taken into use and is now the only running build in the NE.
4. Finally in the last box the SW build status have been changed to BU.
ORIGINAL SIDE = The name of a side in trial configuration where the original running SW build resides in.
TRIAL SIDE = The name of a side in trial configuration where the new SW build which is to be tested and taken into use is running in.
NOKIA NETWORKS
* E. Hintsala
Used in incompatible SW upgrades (not warm up compatible updates).*
For shortening downtime when taking new SW version into use in live NE.
Possibility to test the new SW version without disturbing normal switching capacity of the live NE (only unit restarts, alarms and MML commands, no test traffic).
Possibility to return back to original build easier and with smaller traffic interruptions (reversal cutover).
* In warm up compatible updates Change Delivery handling is used (DX200)
Change Delivery is installed to running SW BUILD's Directory
CD is activated first in disk and then loaded to SP units and taken in to use with switchovers -> No interruptions in traffic
* New SW Build can also be taken in to use by system restart (WSD – command)
NOKIA NETWORKS
* E. Hintsala
*
Differencies in A series Trial Configuration and B series "Tele-Trial" 1/2
In A series ORIGINAL side is permanently running with BU build and TRIAL is running with NW build (or optionally FB). In the cutover the TRIAL side (NW build) starts to handle traffic. There is no TELE side at all.
In B series TRIAL side is created with NW build and TELE side remains working with BU build. In the cutover, the NW build side is marked to be TELE and BU build side is marked to be TRIAL.
In A series there is not HOT restart in cutover. The necessary units are moved to new traffic handling side with recovery state transitions (WO-EX in old side ->TR-OU ->WO-EX in new side). The units which are not moved, are not restarted at all. The units that are move are restarted with new traffic side SW build.
In B series, the units that are not moving are HOT restarted in cutover. The units that are moved are TOT restarted with new traffic side SW build as in A series.
In A series the ATM messaging is independent in both sides: there is own switch fabric in each side, since both the messaging and switching use the same ATM platform. There is Ethernet message interface between OMU units for controlling of Trial etc.
in B series there is no switch fabric in the non-traffic side. There is MB message bus which is connected in all units.
NOKIA NETWORKS
* E. Hintsala
*
Differencies in A series Trial Configuration and B series "Tele/Trial" 2/2
In A series it is possible to move single units between sides: this enables test traffic in TRIAL side (if application supports this). When a unit is moved away from real traffic side, the traffic stops in the part of that unit ! No real traffic in TRIAL side.
In B series there is no switching in non-traffic side
In A series the ATM messaging is independent is both sides. So the messaging link between ORIGINAL and TRIAL sides is needed: there is ethernet messaging connection between OMU units (this is meant for special purposes only, for example controlling of Trial).
In B series the message bus is common for both sides
Both in A and B series the logical addressing does not cross the slice barrier, but physical addressing does.
In A series, the HMS bus is common for both sides, but HMS applications are allowed to communicate only with units in own side. HMS active master node follows the traffic side.
In A series the hard disk is mounted in the same OMU with HMS active master node. The non-traffic side uses the hard disk through ethernet link (this is not visible to disk service users).
In A series the TBU and redundant NIU (except NPS1P) unit cannot be splitted (both active and spare unit are always in traffic side).
NOKIA NETWORKS
* E. Hintsala
CORE (units)
BASE (units)
CUTOVER (units)
COMPLETE (units)
BASE (unit set)
2N and N+1 redundant units, which can be moved from original side to trial side without disturbing the traffic.
CUTOVER (trial configuration operation)
Instantaneous moving of switching capacity from one slice to another.
COMPLETE (trial configuration operation)
Completes trial configuration. All units from original side are moved to the trial side. The new SW version is taken into use and division of the network element is removed. If COMPLETE is chosen, the deployment status of trial side must be deployed.
NOKIA NETWORKS
* E. Hintsala
D: ..... DELETE TRIAL CONFIGURATION (WRD, WRC)
I: ..... INTERROGATE TRIAL CONFIGURATION (USI:ALL:BOTH)
M: ..... MODIFY TRIAL CONFIGURATION (WRA, WRR)
U: ..... MOVE SINGLE UNIT (N/A)
X: ..... EXECUTE CUTOVER (WRS, WRO)
W3C
Use this command to create trial configuration into network element. The creating of trial configuration divides the network element into two independent functional sides, and new SW build to be tested is loaded into the trial side. The basic trial configuration contains typically the spare units.
W3D
Use this command to remove trial configuration. When removing trial configuration it can be cancelled or completed. Cancelling means that trial configuration is interrupted without taking the new software into use, whereas competion provides a means of commitment to the new software version.
W3I
Use this command to interrogate trial configuration information. The content of the output depends on what kind of information is requested.
W3M
Use this command to modify the created trial side configuration in network element. When trial configuration is modified, the trial side is expanded/reduced to be the new named configuration.
W3U
Use this command to move a single computer unit to a named side. This command is used only in special situations, for example, when testing some nonredundant unit in trial side. Before command can be used, BASE configuration must exist.
W3X
Use this command to execute cutover in trial configuration. In cutover, all the nonredundant units and all the sn+ units are moved from the current deployed side to the new deployed side and they are reloaded with the SW build of the new deployed side. The corresponding amount of n+1 units that were in the SP-EX state before trial configuration are being left to the current deployed side (they are not restarted). All the others of n+1 units are moved to the new deployed side and they are reloaded with new SWbuild. The 2n units are left untouched (they are not restarted nor reloaded). The deployment statuses are changed between sides of the network element. In practice, the cutover causes a loss of ongoing switching capacity in the current deployed side of the network element. Switching capacity starts anew in the new deployed side after the moved units are loaded with the SW build of the new deployed side.
NOKIA NETWORKS
* E. Hintsala
OMU-WO
OMU-SP
OMU-WO
OMU-WO
and created in the disk beforehand
BU build always
BU
NOTICE!!!
When observing the following figures, keep in mind the unit set concepts which were previously illustrated. The figures are not totally accurate because BASE contains CORE and also these both contains OMU.
NOKIA NETWORKS
* E. Hintsala
OMU-WO
OMU-SP
OMU-WO
OMU-WO
OMU-WO
OMU-SP
ORIGINAL SIDE
TRIAL SIDE
(all the possible switching capacity in this unit breaks,
so some "unused" unit must be selected!!)
BU
BU
NW
NW
needed!!
Move n+1 and nonredundant units from ORIGINAL to TRIAL side.
Load those with NW build (this is what takes the time)
BU
NW
BU
NW
W3C:NW:BASE;
W3X:TRIAL;
W3D:COMPLETE;
UNIT-1
WO
UNIT-3
SP
UNIT-0
WO
UNIT-2
WO
UNIT-3
WO
UNIT-1
WO
UNIT-0
WO
UNIT-2
WO
UNIT-0
WO
UNIT-1
WO
UNIT-3
WO
UNIT-2
WO
UNIT-1
WO
UNIT-3
WO
UNIT-0
SP
UNIT-2
WO
W3C:NW:BASE;
W3X:TRIAL;
W3D:COMPLETE;
W3C:NW:BASE;
W3X:TRIAL;
W3D:COMPLETE;
W3X:ORIGINAL;
Yes
No
Name as ORIGINAL
Remove name TRIAL
Network element level traffic
Network element level traffic
Preparing phase (create new SW build, convert files in disk)
Testing of new SW build in TRIAL
New SW build in traffic (gradually)
New SW build accepted in use
Create TRIAL
Complete configuration
Reversal cutover
Feature Requirements Specification edition 2 in MDQ
Feature Implementation Principles edition 1 in MDQ
Feature Implementation Specification edition 2 in MDQ
(TRIAL home page (in IPA2800 Project Documents, Lotus Notes))
Server: eslns14t/ES1/NTC/Nokia
Customer documentation
(http://wwwdoc/draft/a3/en/REFERENCES/MMLS/W/W3/StartDN015993.htm)
(http://wwwdoc/draft/a3/en/INSTRUCTIONS/DN99557943/StartDN99557943.htm)
31020 Fault Management SAS
GUIDE
22.5.2002 Jukka Kuusenaho
This is unofficial guide of analysis rules of trial operations. These rules are picked from offical document 30335 FIMS.
Op
Param
Offered
in
- SP-EX CORE units
- SP-EX 2N outside CORE, SP-EX N+1units (this list can be empty)
- no TBU/NIS0P/NIS1P units
- all remaining units WO-EX/SP-EX/SE-NH
Units to be select:
- non WO CORE units
- non WO 2N units outside CORE, non WO N+1 units (this list can be empty)
- no TBU/NIS0P/NIS1P units
Other criteria
- NE_SPLIT = OFF
Note!!! Unit pair will be select if their state non WO
D
E
P
L
O
Y
OMU
Other criteria:
- NE_SPLIT = ON
Other criteria:
- NE_SPLIT = ON
- all remaining TRIAL units WO-EX/SP-EX/SE-NH??
Units to be select:
- BASE-CORE units of TRIAL
D
E
P
L
O
Y
BASE
Other criteria:
- NE_SPLIT = ON
- TRIAL OMU WO-EX
D
E
P
L
O
Y
CORE
Other criteria:
- NE_SPLIT = ON
- TRIAL OMU WO-EX
C
U
T
O
V
E
R
ORIG
- all non redundant and SN+ units
- those N+1 units which logical address don’t exist in TRIAL slice
Other criteria:
- NE_SPLIT = ON
- TRIAL has BASE units
Note: ORIG BASE will remains to the ORIG slice and those N+1 units which logical address exist in TRIAL slice.
Units to be select:
- all non redundant and SN+ units
- those N+1 units which logical address don’t exist in TRIAL slice
Other criteria:
- NE_SPLIT = ON
- TRIAL has BASE units
Note: ORIG BASE will be left to the ORIG slice and those N+1 units which logical address exist in TRIAL slice.
C
U
T
O
V
E
R
TRIAL
- all non redundant and SN+ units
- those N+1 units which logical address don’t exist in ORIG slice
Other criteria:
- NE_SPLIT = ON
- ORIG has BASE units
Note: TRIAL BASE will remains to the TRIAL slice and those N+1 units which logical address exist in ORIG slice.
Units to be select:
- all non redundant and SN+ units
- those N+1 units which logical address don’t exist in ORIG slice
Other criteria:
- NE_SPLIT = ON
- ORIG has BASE units
Note: ORIG BASE will be left to the ORIG slice and those N+1 units which logical address exist in TRIAL slice.
C
O
M
P
L
E
T
E
TRIAL
C
A
N
C
E
L
Other criteria:
- NE_SPLIT = ON
- both slices have BASE units
- Application program does not prevent the move
- unit is uppermost in hierarchy
- unit is non splittable (not TBU, NISxP)
Units to be select:
- as given in parameter
- both slices have BASE units
- Application program does not prevent the move
- unit is uppermost in hierarchy
- unit is non splittable (not TBU, NISxP)
M
O
V
E
TRIAL
Other criteria:
- NE_SPLIT = ON
- both slices have BASE units
- Application program does not prevent the move
- unit is uppermost in hierarchy
- unit is non splittable (not TBU, NISxP)
Units to be select:
- as given in parameter
- both slices have CORE units
- Application program does not prevent the move
- unit is uppermost in hierarchy
- unit is non splittable (not TBU, NISxP)
non WO = state <> WO-XX
The units which participate in some Trial operation can be defined as a sets.
Trial unit sets are:
OMU, CORE, BASE, CUTOVER and COMPLE.
· OMU set consist of single OMU.
· CORE set consist of OMU set, single OMU’s MXU, single SFU and single CACU/RSMU.
· BASE set consist of CORE set, 2N other side (2N units outside CORE) and N+1 spare units
· CUTOVER set consist of all SN+ units, both TBU’s, all NIS1P pair, all NIS0P pair, EHU and all non redundant units.
· COMPLETE set consist of the BASE units of the ORIG slice
Below are described unit sets in both A-releases.
SET
OMU set,
Spare 2n units
All spare 2n and n+1 units
CUTOVER
A2SU, GTPU, DMCU, TBU, NIS1P, NIS0P, NIP1, NIS0, NIS1, EHU
A2SU, TCU, TBU, NIS1P, NIS0P, NIP1, NIS0, NIS1, IWU, EHU
all sn+ units, TBU/NIS0P/NIS1P pair, all non redundant units
COMPLETE
Unit redundancy principles.
Different Software Configuration Management operations may update same builds and same SW management control files (SOMAFI, MAFILE)
Collisions of updating simultaneously same file or directing for example opposing operations to same build must be prevented.
Administration of operations under execution and permission request protocol is necessary
Request permission protocol is automatically executed by program blocks. However in fault situations there may be hanging reservations which must be released manually by MMLcommand.
Software Configuration Management resource handling is implemented by this feature. The task of the Resource Manager (HOKKUS) is to bookmark information of operations of Software Configuration Management and allow execution along condition table included. The goal is to prevent simultaneous execution of operations which would interfere each other. To reach this SW management program blocks have to ask permission for operations which they are starting to execute as well as inform resourse management when ending or terminating operation.
NOKIA NETWORKS
* E. Hintsala
Properties
Administration is handled by special program block HOKKUS which has also MML user interface (WX-MML)
Carefully specified Software Configuration Management operations do request permission for operation from HOKKUS program block when starting.
If operation is permitted, it is also reserved by HOKKUS.
If same operation or another one which is prohibited under execution of reserved one is requested by another user, permission is not given and requested operation stops to error.
It is however possible to execute simultaneous operations which do not interfere each other. This is administrated by using operations condition table which is implemented inside HOKKUS program block
NOKIA NETWORKS
* E. Hintsala
resource which is already reserved before attempted one
SOFHAN SOSTAT CNOTES ENSURE
WQC D/E WSA1 A2 C D R S WNA D J WKS WWW trial MAX
WQC - - - - - - - - - - + r - + 1
WQD/E - - - - - - - - - - + r - + 1
WWW - - + + - - - - + + + + - + 1
+ = resource reservation is allowed
- = resource reservation is not allowed
r = additional check is needed in order to check that operations are not directed to same builds
WSA1= automatic return in case of reset loop
WSA2= automatic return in case of reset loop and time limit
MAX = count of same operations simultaneously in execution
WWW = nonsimultaneous output operations of SOWADM (WQB, WQH, WQL and WQM)
trial = trial configuration
E: ..... RESERVE OPERATION RESOURCES
F: ..... RELEASE RESOURCE RESERVATION
WXE
With the command it is possible to make forced reserve of operation even it would not be possible along condition table. The command outputs also reservation situation of operation right after reservation.
WXF
With the command reservation of operation is released as forced. The command outputs also reservation situation of operation right after release.
WXI
With the command it is possible to inquire resource reservation information of specified or all operations. In the output there is information of reserved operations along request type in the form: family which made the reservation, time of the reservation and possible package identification information.
WXP
The command outputs condition table of specified or all operations in relation to other operations. The command is used for inverstigating which operations are permitted to execute simultaneously with other operations. In the output it is explained how operation is possible to execute if there would be other operations under execution.
NOKIA NETWORKS
* E. Hintsala
WKS:MODE=DATA::;
WXE:2:;
FREE RESOURCES : 0
WXI;
FREE RESOURCES : 0
FAMILY RESERVATION TIME SW-PACKAGE SW-PACKAGE
30A 2000-05-29 00:50:06.05 B3 2.6-0 6 B3 2.6-0 3
FREE RESOURCES : 0
1 .... 1B 2000-05-29 00:50:16.35 FORCED RESERVATION
ALL .. RELEASE ALL RESOURCES */
FREE RESOURCES : 1
WSA:TOBU:BOTH;
AUTOMATIC RETURN CAN CAUSE UNCONTROLLED CHANGE OF
DEFAULT PACKAGE.
/*** DX ERROR: 12917 RESERVING OF OPERATION OF SOFTWARE CONFIGURATION ADMINISTRATION IS NOT ALLOWED ***/
COMMAND EXECUTION FAILED
WXP:;
LIST OF OPERATIONS THAT HAVE INFLUENCE TO PERMISSION OF EXECUTION
OF ATTEMPTED OPERATION :
3 SWITCHING ACTIVE PACKAGE IN DIRECTORY : NO
4 ROLLBACK STATUSES OF SOFTWARE PACKAGES : NO
5 AUTOMATIC RETURN IN CASE OF RESET LOOP : YES
6 AUTOMATIC RETURN IN CASE OF TIME LIMIT : YES
7 CHANGE DELIVERY INSTALLATION : YES
8 CHANGE DELIVERY DELETION : YES
9 FALLBACK COPYING OF SOFTWARE PACKAGE : NO <= !!!!!!!!!!!!!!!!!!
10 SWITCHING STATUSES OF SOFTWARE PACKAGES : NO
11 SETTING DEFAULT PACKAGE : NO
12 UPDATE PACKAGE IDENTIFIER : YES
13 NONSIMULTANEOUS OUTPUT OPERATION : YES
TRIAL CONFIGURATION : YES
SOMLIB
A co-linked library, which is used to find information of the builds from SOMAFI.
SOMLIB is used by POSIX configuration in setting of the running link during the POSIX initialization.
SOMLIB is also used by boot loading.
Three routines:
get_directory_with_build_id_r returns the directory name for the build with the build id.
get_default_build_information_r seeks the default build from SOMAFI and returns the directory and the build identificationof the default build.
get_trial_state_r returns information about the trial status i.e. is trial on, is cutover on and on which side in case of trial configuration the caller is located in.
RUNNING
FAQ
1. From where does SOMLIB read SOMAFI from in different services?
SOMAFI is read always from disk when application is located in OMU and posix calls are used in implementation. The file is first opened for reading:
open("/shadows/SCMANA/SOMAFIGX.IMG", O_RDONLY, 0)
The path /shadows/SCMANA/SOMAFIGX.IMG refers to SOMAFI in own unit. SOMAFI is read from disk with (posix) read.
2. What happens if these services are called in other unit than OMU?
get_trial_state_r: NOT_IMPLEMENTED_EC is returned
get_default_build_information_r: package_info_inq_s is sent to SOWADM (sym_group_addr)
get_directory_with_build_id_r: if there is no disk there will be trouble, I think !!!
NOKIA NETWORKS
* E. Hintsala
Service terminal program block (PACKET)
Especially in test laboratory conditions Software Management MML commands often are too heavy and too difficult to use (they are designed for end-user and this is why functioning must be very reliable)
Patching SOMAFI straight to disk is often solution for this problem, but this sometimes leads to other problems like patching errors and updating errors to memory or to other disk units
PACKET service terminal extension provides safe and easy way to change Software build Configuration instead of patching SOMAFI
NOKIA NETWORKS
* E. Hintsala
PROPERTIES
SOMAFI file handling both in disk and in memory in selected disk unit
Straight command interface for changing most often used data like default build selection and status changes
Access for all datafields of SOMAFI via menu type guiding.
Input data semantic checking for datafields which has limited amount of prespecified values (like statuses BU, FB, NW, UT and UD).
SOMAFI contents and structure listing
PACKET is a Software Package Management service terminal extension programblock. The main objective for it is to help changing statuses of software builds, selecting default build and to edit SOMAFI records. Extension is primarily meant to be used in test laboratory conditions, where such wide safe requirements are not specified as in network elements which are in live use. PACKET also provides flexible choice for some Software build Management operations executed normally by MML commands. Flexible means here that MMI system need not to be in use and that MML type strict chekings and conditions in executing operation is not needed. This is why using of PACKET requires good knowledge of SW management operations and implementation principles. This is most evident when editing SOMAFI records, not so much when only for example selecting default build or only listing SOMAFI.
NOKIA NETWORKS
* E. Hintsala
/*** WARNING: If you do not know what you are doing
do not use PACKET use MML! ***/
PACKAGE HANDLING FIRST AID KIT
? ..... MENU
S ..... SET STATUS OF SOFTWARE PACKAGE IN SOMAFI
E ..... EDIT SOFTWARE PACKAGE RECORD IN SOMAFI
L ..... LIST SOMAFI FILE
C ..... CHECK SOMAFI FILE
Z ..... RETURN TO MAIN LEVEL
00-PAC>
D
Default package information is changed with this command. User specifies default package name or status and optionally index of OMU. As a default command is directed to both OMU:s. Command is possible to direct only to OMU units.
S
Package status is changed with this command. User specifies package name and status which is to be set. Command is possible to direct only to OMU units.
E
Package record in SOMAFI file is edited with this command. User specifies record number and optionally unit which SOMAFI is to be edited. As a default command is directed to OMU unit. Another disk unit containing SOMAFI file is also possible to be specified.
L
SOMAFI contents is outputted with this command. Record number is optional parameter.
C
Command checks that the OMU's and other disk-units SOMAFI record-fields are corresponding eachother. OMU SOMAFI's correspondence to MAFILE is also checked. As default, it checks that package-statuses are in allowed boundAries and that there is only one default package.
P
H
NOKIA NETWORKS
* E. Hintsala
00:PAC> ZZ1LR:1
SOMAFI RECORD NUMBER 1 :
78 00 4E 57 00 00 00 00 00 00 00 00 00 00 03 00 x.NW............
03 00 53 58 20 36 2E 37 2D 30 20 20 20 20 20 20 ..SX 6.7-0
20 20 20 20 20 20 42 53 43 36 37 00 00 00 00 00 BSC67.....
00 44 49 52 00 42 55 44 00 00 00 00 00 01 53 58 .DIR.BUD......SX
20 36 2E 33 2D 30 20 20 20 20 43 49 44 30 30 30 6.3-0 CID000
53 58 20 35 2E 32 2D 30 20 20 20 20 00 00 00 00 SX 5.2-0 ....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 ........
-------------------------------------------------------------------------
SOMAFI RECORD NUMBER 0 :
78 00 42 55 FF FF 00 00 00 00 00 00 00 00 00 00 x.BU............
03 00 42 33 20 32 2E 32 2D 30 20 20 20 20 20 20 ..B3 2.2-0
20 20 20 20 20 20 42 33 32 5F 32 5F 30 5F 55 35 B32_2_0_U5
00 44 49 52 00 49 49 52 49 53 00 00 00 01 42 33 .DIR.IIRIS....B3
20 32 2E 32 2D 30 20 20 20 20 43 4E 52 33 32 38 2.2-0 CNR328
32 34 20 32 2E 31 39 2D 30 20 20 20 00 00 00 00 24 2.19-0 ....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 ........
.
.
.
reset_counter_omu0 = 00 00 ..
reset_counter_omu1 = 03 00 ..
NOKIA NETWORKS
* E. Hintsala
Example: List SOMAFI file
with field explanation 2/2
package_id = 42 33 20 32 2E 32 2D 30 20 20 B3 2.2-0
20 20 20 20 20 20 20 20 20 20
dir_name = 42 33 32 5F 32 5F 30 5F 55 35 B32_2_0_U5
00 44 49 52 00 .DIR.
package_name = 49 49 52 49 53 00 00 00 IIRIS...
active = 01 .
environment = 42 33 20 32 2E 32 2D 30 20 20 B3 2.2-0
20 20
delivery = 43 4E 52 33 32 38 32 34 20 32 CNR32824 2
2E 31 39 2D 30 20 20 20 .19-0
fb_time = 00 00 00 00 00 00 00 00 ........
safecopied_units = 00 00 00 00 ....
reserv_aidu = 00 00 00 00 ....
trial_on = 00 .
cutover_on = 00 .
cd_id = 00 00 00 00 00 00 00 00 00 00 ..........
NOKIA NETWORKS
* E. Hintsala
00:PAC> Z1ER:0
/*** WARNING: If you do not know what you are doing
do not use PACKET use MML! ***/
SOMAFI RECORD NUMBER 0 :
78 00 42 55 FF FF 00 00 00 00 00 00 00 00 00 00 x.BU............
03 00 42 33 20 32 2E 32 2D 30 20 20 20 20 20 20 ..B3 2.2-0
20 20 20 20 20 20 42 33 32 5F 32 5F 30 5F 55 35 B32_2_0_U5
00 44 49 52 00 49 49 52 49 53 00 00 00 01 42 33 .DIR.IIRIS....B3
20 32 2E 32 2D 30 20 20 20 20 43 4E 52 33 32 38 2.2-0 CNR328
32 34 20 32 2E 31 39 2D 30 20 20 20 00 00 00 00 24 2.19-0 ....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 ........
CNTRL-C = Quit with/without Save
NOKIA NETWORKS
* E. Hintsala
00:PAC> Z1ERF:0
/*** WARNING: If you do not know what you are doing
do not use PACKET use MML! ***/
SOMAFI RECORD NUMBER : 0
package_id
dir_name
package_name
active
environment
delivery
fb_time
safecopied_units
reserv_aidu
cd_id
Select field with arrows and press enter. CNTRL-C = Quit with/without Save
NOKIA NETWORKS
* E. Hintsala
(pac_status is chosen:)
/*** WARNING: If you do not know what you are doing
do not use PACKET use MML! ***/
SOMAFI RECORD NUMBER : 0
pac_status = 42 55 BU
CNTRL-C = Quit with/without Save
TAB = Toggle between ASCII / hexadecimal input field
Status of the package Values: BU, FB, NW, UT, UD
NOKIA NETWORKS
* E. Hintsala
Software Configuration Management Feature Hierarchy
Note: The place of feature 30913 (Adaptation of software configuration management to A series) in the hierarchy is not necessarily the only possible place where it could be situated. It could also be put directly under feature 30223 or maybe also between features 30223 and 10373.
140.bin
WO-EX
traffic
SP-EX
traffic
WO-EX
ORIGINAL
traffic
WO-EX
TRIAL
Network element
level traffic
Network element
level traffic
Preparing phase
R
RW
R
R
For data
For data
UNIT-0
WO
UNIT-4
WO
UNIT-3
WO
UNIT-2
WO
UNIT-1
WO
UNIT-4
WO
UNIT-3
WO
UNIT-0
WO
UNIT-2
WO
UNIT-1
WO
UNIT-0
WO
UNIT-4
WO
UNIT-3
WO
UNIT-2
WO
UNIT-1
WO
UNIT-0
WO
UNIT-4
WO
UNIT-3
WO
UNIT-2
WO
UNIT-1
WO
30222
10219
10218
10238
30220
9937
30913
30905