NN10470 305

Nortel Multiservice Data Manager
AdministrationFundamentals
NN10470-305
Document status: Standard
Document issue: 01.02
Document date: May 2007
Product release: 16.2
Job function: Administration and Security
Type: NTP
Language type: U.S. English
Sourced in Canada and the United States of America.
Copyright 2007 Nortel Networks. All Rights Reserved.
NORTEL, the Nortel logo and the Globemark are trademarks of Nortel Networks.
Contents
New in this release 9
Features 9
Other changes 9
Introduction 10
Multiservice Data Manager Run Time Environment 12
Multiservice Data Manager User Environment 12
Directory structure 13
/opt/MagellanNMS/loads/ 13
Default MDM user environment skeleton files 16
/opt/MagellanNMS/system/skel/.cshrc 17
Global environment variables 19
Mandatory variables 19
Optional variables 20
Environment setup scripts 20
/opt/MagellanNMS/bin/nmscsh 21
/opt/MagellanNMS/bin/nmssh 21
User session startup scripts 21
/opt/MagellanNMS/bin/nmssession 21
/opt/MagellanNMS/bin/nmstool 21
Disruptive Command Safeguard 22

About the Disruptive Command Safeguard feature 22
The /opt/MagellanNMS/cfg/DCS.cfg configuration file 23
File format 23
The default /opt/MagellanNMS/cfg/DCS.cfg file 24
Checking, enabling, and disabling the Disruptive Command Safeguard 24
Disruptive Command Safeguard menu 24
Fundamentals for configuring Multiservice Data Manager servers

for Multiservice Switch 25
Servers required to support Multiservice Switch network access, surveillance, and
provisioning access 26
Reasons for Multiservice Switch groups and guidelines for set up 26
Groups of nodes for network access 27

NN10470-305 01.02 Standard
16.2 May 2007
Copyright 2007, Nortel Networks Nortel Confidential
-4-
Contents
Grouping nodes for surveillance access 28

Guidelines to group nodes for surveillance access 30
User IDs and passwords 30
Grouping nodes, a simple example 32
Network administrative requirements 32
FMDR server redundancy for surveillance access 33
Distribution of servers among workstations on a LAN in big networks 34
Fundamentals for configuring Multiservice Data Manager servers

for Multiservice Provider Edge 36
Servers required to support Multiservice Provider Edge network access, surveillance,
and provisioning access 36
Reasons for groups and guidelines for set up 37
Groups of nodes for network access 38
Grouping nodes for surveillance access 39
At startup time 39
At run time 40
Guidelines for grouping nodes for surveillance access 40
Userids and passwords 40
NMDR servers and groups: 40
Grouping nodes, a simple example 41
Network administrative requirements 41
Group setup 41
NMDR server redundancy for surveillance access 42
Distribution of servers among workstations on a LAN 43
SNMP Proxy Agent (SPA) fundamentals 44
Interface with the MDM Server Manager 44
Interface with the Host Group Directory Server 45
Interface with the MDM Trap Server 45
SPA process name 46
UDP Port for requests 46
SNMP versions 46
Request types 46
Traps handling 48
Logs 48
Statistical logs 49
Multiservice Switch SDD file management 51

About SDD files 51
SDD files and provisioning applications 52
SDD files and surveillance applications 52
Manually generating model files 53
Fmsgetmod 53
Getsursdd 55

NN10470-305 01.02 Standard
16.2 May 2007
-5-
Contents
Shared memory 56
Determining the requirements for shared memory 56
Setting the amount of shared memory in the kernel 56
Network time synchronization 58

Overview of Network Time Synchronization (NTS) 58
What is NTS 58
What a workstation can have as a time server 60
What a workstation can have as a time client 62
How workstations synchronize the time with everything except DPN 63
How workstations synchronize the time with DPN 66
Maximum heap size 69

About the maximum heap size 69
The default /opt/MagellanNMS/lib/cfg/SharedJVM.cfg configuration file 70
File format 70
Monitoring the maximum heap size 70
Memory usage warning dialog 71
Multiservice Data Manager server maintenance fundamentals

overview 72
Server alarm distribution and workstation status probing
configuration 73
About server alarm distribution and workstation status probing 73
Workstation surveillance 75
Threshold configuration 75
Multinodal Naming Service domains 78

What MNS domains are used for 78
Guidelines for setting up level 2 MNSD domains 80
Multinodal Naming Service TCP/UDP port mappings 82

Mapping service names to TCP/UDP port numbers 82
Configuring TCP/UDP port numbers 82
Network access data mediation 84

Purpose of network data access mediation 84
Component criticality thresholds 86
NDAM deployment and configuration strategies 89
Subordinate GMDR server 89
NDAM authentication configuration 91
NDAM filterset file configuration 92
Multiservice Switch alarm clearing and storage 94

Types of Multiservice Switch 7400/15000/20000 alarm clearing 94
Local clear 95

NN10470-305 01.02 Standard
16.2 May 2007
-6-
Contents
Global clear 95
Global clear tool 96
How alarms from Multiservice Switch 7400/15000/20000 are collected and
stored 96
User interface customization fundamentals 97

Multiservice Data Manager user customization fundamentals 98
Access Control 98
Service Selection 99
Menu customization 99
User Preferences 99
Preference system directory structure 100
User preferences for Data Viewer 101
User preferences for Operational Command GUI 103
User preferences for MSS Shelf View 104
State preferences 104
Severity preferences 106
User preferences for Nodal Provisioning and Nodal Provisioning Template
Editor 108
Operator Client logging preferences 108
Resources for Multiservice Data Manager tools customization

fundamentals 109
About resources used by Multiservice Data Manager tools 109
Syntax of a resource definition statement 110
Predominance 111
Specificity 111
Location 112
How specificity and location affect predominance 113
Customizing resources for all users 113
Example 1, customizing resources for Network Viewer in the ND tools resource
file 114
Example 2, Customizing font resources in the Msm resource file 114
Setting font resources in the Msm resource file 116
Customizing resources for specific users 117
Setting resources for the Network Viewer in a common resource file 117
Setting resources for a single user in the .Xdefaults file 118
Setting resources for Network Viewer in the .Xdefaults file 118
Customizing resources in a command line 119
Useful utilities 119
Menu customization fundamentals 121

About menu items that can be customized 121
MDM window 122
Start Tool menus 123

NN10470-305 01.02 Standard
16.2 May 2007
-7-
Contents
Push-buttons in icon bars 124

Menu definition records 124
File syntax 124
Menu entry descriptions (including icon bar push-buttons) 127
Titles 131
Substitution variables in a Start Tool menu definition file 134
Useful OSF/Motif resources 135
Automatic search path 135
Finding menu definition files for the main window menus 136
Finding menu definition files for Start Tool menus 138
Where to find icon bar definition files for the Network Viewer icon bars 140
Customization examples 141
Example 1, Setting the startup options in a menu definition file 141
Example 2, Creating a submenu item that invokes a macro 142
Customizing menus for Shared Java and Operator Client tools 142
Launch menu customization for Operator Client 143
Mnemonics launchscript customization 144
Window plug-in customization 145
Tool menu customization 148
Customizing Data Viewer tools menu command entry 148
Customizing tools menu for SNMP devices 149
Customizing tools menus for Nodal Provisioning 149
Component Information Viewer diagnostics 150

Diagnostic menu management 150
Example 150
Component Information Viewer diagnostic utilities 152
execWithDest 152
execDPNCommand 153
execPPCommand 154
ppCompSelector 156
execWithIPAddr 156
snmpCmd macros 158

What you need to know 158
Runtime environment 158
Environment variables related to Scotty and TCL 159
snmpCmd macros 160
MIBs 160
Utilities 161
About snmpCmd macros 162
General command macros 162
Device-specific snmpCmd macros 164
What happens when you run an snmpCmd macro 165

NN10470-305 01.02 Standard
16.2 May 2007
-8-
Contents
Alarms in text format 169

About the rncsalarm utility 169
Command syntax 170
Helpsets for MPE devices 172

About customizing the MPE helpset 172
Command syntax 173

NN10470-305 01.02 Standard
16.2 May 2007
New in this release
The following sections detail whats new in Nortel Multiservice Data Manager
AdministrationFundamentals (NN10470-305) for release 16.2:
Features (page 9)
Other changes (page 9)
Features
There are no feature changes in this document release 16.2.
Other changes
See these sections for changes that are not feature-related:
All references to Nortel Multiservice Data Manager technical publications
were updated with new document numbers.

NN10470-305 01.02 Standard
16.2 May 2007
Introduction
Fundamental information for the administration of Nortel Multiservice Data
Manager (MDM) provides conceptual information and examples to support
the procedures used to administer Nortel Multiservice Data Manager
software.
Use these topics when you require additional information about the
procedures used to customize Nortel Multiservice Data Manager (MDM)
software. Customization refers to any alterations you are required to make to
tailor Nortel Multiservice Data Manager software to the specific needs of your
network.
Use the information in the sections listed below in conjunction with the
procedures located in Nortel Multiservice Data Manager Administration
(NN10470-303).
Conceptual information supporting the Nortel Multiservice Data Manager

administration tools is located in Nortel Multiservice Data Manager
AdministrationTools (NN10470-300).
Navigation
Multiservice Data Manager Run Time Environment (page 12)
Fundamentals for configuring Multiservice Data Manager servers for
Multiservice Switch (page 25)
Disruptive Command Safeguard (page 22)
Fundamentals for configuring Multiservice Data Manager servers for
Multiservice Provider Edge (page 36)
Multiservice Switch SDD file management (page 51)
Shared memory (page 56)
Network time synchronization (page 58)
Maximum heap size (page 69)

NN10470-305 01.02 Standard
16.2 May 2007
- 11 -
Introduction
Multiservice Data Manager server maintenance fundamentals overview

(page 72): Topics in this section provide supporting and conceptual
information about MDM server maintenance.
Server alarm distribution and workstation status probing configuration
(page 73)
Workstation surveillance (page 75)
Multinodal Naming Service domains (page 78)
Multinodal Naming Service TCP/UDP port mappings (page 82)
Network access data mediation (page 84)
Multiservice Switch alarm clearing and storage (page 94)
User interface customization fundamentals (page 97): Topics in this
section provide supporting information, conceptual information and
example procedures for customizing the MDM user interface.
Multiservice Data Manager user customization fundamentals (page 98)
fundamentals (page 109)
Menu customization fundamentals (page 121)
Component Information Viewer diagnostics (page 150)
snmpCmd macros (page 158)
Alarms in text format (page 169)
Helpsets for MPE devices (page 172)

NN10470-305 01.02 Standard
16.2 May 2007
Multiservice Data Manager Run Time
Environment
Use the information in this section to support any procedures related to the
run-time environment and the file and directory structure for Nortel
Multiservice Data Manager software. Procedures relating to the concepts
described here are located in Nortel Multiservice Data Manager
Administration (NN10470-303).
Navigation
Multiservice Data Manager User Environment (page 12)
Directory structure (page 13)
Default MDM user environment skeleton files (page 16)
Global environment variables (page 19)
Environment setup scripts (page 20)
User session startup scripts (page 21)
Multiservice Data Manager User Environment

Nortel Multiservice Data Manager software stores its executables in separate
directories from the workstations Multiservice Data Manager data and
configuration files, and from the Nortel Networks technical publications
(NTPs) for Multiservice Data Manager. This arrangement provides the
following advantages:
simplifies backup and restore operations
provides an efficient means of performing software upgrades and release
rollbacks
makes it easy to use NFS to deploy Multiservice Data Manager software
among workstations on a LAN
For a description of the directory structure, see Directory structure (page 13).

NN10470-305 01.02 Standard
16.2 May 2007
- 13 -
Multiservice Data Manager Run Time Environment
Multiservice Data Manager software includes a set of skeleton files which you
can copy into your home directory. When copied, these skeleton files
automatically set up Multiservice Data Manager environment variables, start
a session, and open the MDM window. For a description of these files, see
Default MDM user environment skeleton files (page 16).
For some existing accounts such as root, it is not always desirable to copy the
skeleton files into the accounts home directory. An example of this is when the
root account is used to manage workstations other than those used to run
Multiservice Data Manager. Multiservice Data Manager software includes
scripts that you can run from a command line or invoke in the set-up files of
the existing account to set up the variables and start a session. For
descriptions of these scripts, see Environment setup scripts (page 20) and
User session startup scripts (page 21).
To run properly, Multiservice Data Manager requires the setting of global

variables. For accounts into which the skeleton files are copied, these
variables are set automatically to their default values. Although some
variables are mandatory to allow Multiservice Data Manager to run properly,
others are optional. For descriptions of the mandatory and optional
environment variables, see Global environment variables (page 19).
Directory structure
The subdirectory /opt contains all Nortel Multiservice Data Manager software.
Sun recommends this subdirectory for all software other than that created by
Sun Microsystems Inc.
For an example of the directory structure for a workstation with Multiservice

Data Manager software load NMS110DaaS2400, see the figure Sample
directory structure (page 15).
The subdirectories of /opt/MagellanNMS and their contents are as follows:
/opt/MagellanNMS/loads/
This directory contains the installed Nortel Multiservice Data Manager
software loads. This directory can be exported as a read-only file system that
other workstations can mount by using the Network File System (NFS) to gain
access to the software.
/opt/MagellanNMS/bin
/opt/MagellanNMS/lib
/opt/MagellanNMS/system
/opt/MagellanNMS/doc
These directories are symbolic links that point to the current Multiservice Data
Manager software load. They provide access to the following subdirectories:
bin: Multiservice Data Manager executables and scripts

NN10470-305 01.02 Standard
16.2 May 2007
- 14 -
lib: libraries and configuration file templates. The files found in lib are the
original versions and must not be modified. Copy these files to the
/opt/MagellanNMS/cfg directory and modify the copied files. Main
subdirectories of lib are as follows:
app-defaults: multi-lingual resource files
cfg: template configuration files
macros: macros and sample source files
messages: multi-lingual message files
model/types: Network Model Schema
nrs: schema and script files for the Network Reporting System (NRS)
tsets/$LANG/toolsets/<product line>: multi-lingual toolsets menu files.
See LANG (page 19) for information on resolving the value of $LANG.
tsets/$LANG/tools/<application area>: multi-lingual Start Tool menu
files. See LANG (page 19) for information on resolving the value of
$LANG.
system: system installation and configuration files. Main subdirectories of
system are as follows:
config: scripts for the Multiservice Data Manager Software
Configuration tool
init: NMS load initialization scripts
inst: NMS load installation scripts
skel: NMS default user environment system set-up files
doc: documentation files
To use a different software load, these symbolic links are redirected to
point to the bin, lib, system, and doc directories for a different Multiservice
Data Manager software load.
/opt/MagellanNMS/ext/bin
/opt/MagellanNMS/ext/lib
These directories are local directories for second-party customization
packages for Nortel Multiservice Data Manager. These customization
packages contain software and configurations that extend Multiservice Data
Manager and its device support. Their subdirectories are similar to those
delivered by Multiservice Data Manager. Multiservice Data Manager tools and
servers recognize these directories as part of their standard search paths. For
example, the Network Model utility looks for customized schema description
files in the following order:
1 /opt/MagellanNMS/data/model/types (end-user or third-party
customization)

NN10470-305 01.02 Standard
16.2 May 2007
- 15 -
2 /opt/MagellanNMS/ext/lib/model/types (second-party customization)

3 schema directory delivered with Multiservice Data Manager,
/opt/MagellanNMS/lib/model/types
Like the main,/opt/MagellanNMS/bin and /opt/MagellanNMS/lib, consider

these directories as read-only because they contain Solaris package
controlled files.
Sample directory structure
Directories that are read-only to the MDM tools
/opt/
MagellanNMS/ (MDM Software)
loads/ (All MDM software loads)
NMS110DaaS2400/ (A specific software load)

bin/... (Executables and scripts)
lib/... (Libraries and templates)
system/... (Configuration, initialization, and
installation-specific files)
doc/... (NTPs and other documents)
... (Other software loads)
bin -> /opt/MagellanNMS/loads/NMS110DaaS2400/bin

lib -> /opt/MagellanNMS/loads/NMS110DaaS2400/lib
doc -> /opt/MagellanNMS/loads/NMS110DaaS2400/doc
system -> /opt/MagellanNMS/loads/NMS110DaaS2400/system
data/ (Local data files)

model/... (Network Model files)
PassportSchema/ (Multiservice Switch SDD files)
nrs/rdf/[ppe|ppc|dpn|custom] (RDFs for NRS)

... (Other data files)
cfg/ (Local configuration files)

private/... (System security files)
... (Other configuration files)
MagellanMDP/ (MDP software)
MagellanNTP/ (NTPs and context-sensitive

help information)
... (Other Nortel software such

as PPMM and other vendors
software)
Symbolic links to directories in the active load

NN10470-305 01.02 Standard
16.2 May 2007
- 16 -
/opt/MagellanNMS/data/
/opt/MagellanNMS/cfg/
These two directories contain the data files and configuration files that are
specific to the workstation. These two types of files are independent of the
Nortel Multiservice Data Manager software load.
Data files contain information manipulated by Multiservice Data Manager
software such as the network models for Fault, and the Service Data
Description (SDD) files. Main subdirectories of the data directory are as
follows:
model: Network Model related files
nrs: NRS data files
nvs: Network Viewer views and background maps
svm: Server Administration log and error files
Configuration files contain information used to configure the Multiservice
Data Manager workstation and optionally includes files that override some
of the other configurations (For example, Motif resource files and macro
files). Main subdirectories of the cfg directory are as follows:
PassportSchema: Nortel Multiservice Switch SDD and related files
app-defaults: customized resource files
macros: customized macros and Multiservice Data Manager-provided
macros
private: private Multiservice Data Manager configuration files
tsets: customized toolset and tools menu files
/opt/MagellanMDP
This directory contains the executables, utilities, schemas, spool, dump and
backup files for the Management Data Provider (MDP) software. This
directory is only present when the MDP software package is installed.
$HOME/MagellanNMS/
This is a subdirectory of a UNIX users home directory which contains the
user-specific Nortel Multiservice Data Manager configuration and preferences
files.
Default MDM user environment skeleton files

Nortel Multiservice Data Manager software includes skeleton files that can be
copied into the home directory of a UNIX account to provide the default
Multiservice Data Manager user environment. Multiservice Data Manager
provides the following scripts to do the copying:
/opt/MagellanNMS/bin/nmsuser to copy the skeleton files for a user
account

NN10470-305 01.02 Standard
16.2 May 2007
- 17 -
/opt/MagellanNMS/bin/rncsuser to copy the files for an RNCS user

account
The skeleton files are all located in directory /opt/MagellanNMS/system/skel.

To display a list of the files in this directory, enter the ls command with the -a
option. Because all of the filenames of the skeleton files begin with a period,
they are hidden unless you include the -a option.
After you copy the files into the users home directory, the files automatically
start a Multiservice Data Manager session and open a the MDM main window
when the user logs in. By default, these files provide the user with access to
the English language set of Multiservice Data Manager tools defined in file
/opt/MagellanNMS/lib/tsets/C/Full.tsets. You can select a different toolset by
setting the NMSTSETS environment variable in the user accounts set-up
files. For more information on customizing the toolsets and Start Tool menus,
see Nortel Multiservice Data Manager AdministrationTools (NN10470-300).
Not every user account needs the skeleton files listed in this section. The files
required depend on factors that include the type of shell associated with the
user account and the window manager.
The skeleton files and their contents are as follows:
/opt/MagellanNMS/system/skel/.cshrc
This file contains the startup script that sets up the shell environment and
Nortel Multiservice Data Manager environment variables for UNIX accounts
that run C-shell.See Global environment variables (page 19).
/opt/MagellanNMS/system/skel/.login
This file contains the login script for accounts that run C-shell and provides a
prompt to start up one of the installed window environments (SDK Motif,
OpenWin, or CDE), or to fall back on a plain console session, if none is
installed.
/opt/MagellanNMS/system/skel/.profile
This file contains the equivalent of the .cshrc and .login scripts combined for
accounts that run Bourne shell or Korn shell. For a description of the
environment variables that are set up in this file, see Global environment
variables (page 19).
/opt/MagellanNMS/system/skel/.Xdefaults
This file contains customized Motif resources. The initial contents of this file
provide for SDK Motif, a look and feel that is similar to release 9 NMS software.
/opt/MagellanNMS/system/skel/.mwmrc
This file defines the SDK Motif Window Manager menu, keyboard, and mouse
actions to correspond with those used in release 9 NMS.

NN10470-305 01.02 Standard
16.2 May 2007
- 18 -
/opt/MagellanNMS/system/skel/.modmap
This file defines X11 keyboard mappings for the user account.
/opt/MagellanNMS/system/skel/.xsession
This file contains a script that automatically
starts a Multiservice Data Manager session (runs nmssession)
opens a Multiservice Data Manager window (runs nmstool)
opens a console window on the desktop for user accounts that run the
SDK Motif Window Manager
The script also ensures that the MDM session and the main window are
removed at exit.
/opt/MagellanNMS/system/skel/.xinitrc
This file contains a script that automatically
starts a Multiservice Data Manager session (runs nmssession)
opens a Multiservice Data Manager window (runs nmstool)
pens a console window on the desktop for user accounts that run
OpenWin
The script also ensures that the session and main window are removed at exit.
/opt/MagellanNMS/system/skel/.dtprofile
This file contains a script that automatically starts a Nortel Multiservice Data
Manager session (runs nmssession) and opens a Multiservice Data Manager
window (runs nmstool) when a CDE session is started by sessionetc and
sessionexit scripts.
/opt/MagellanNMS/system/skel/.sessionetc
This file is automatically copied to directory ${HOME}/.dt/sessionetc when you
log in for the first time using CDE. This file ensures that nmssession and
nmstool are started.
/opt/MagellanNMS/system/skel/.sessionexit
This file is automatically copied to directory ${HOME}/.dt/sessionexit for a
CDE session when you log in for the first time using CDE to ensure that
nmssession and nmstool are terminated upon exit.

NN10470-305 01.02 Standard
16.2 May 2007
- 19 -
Global environment variables

To use Nortel Multiservice Data Manager software with the Solaris operating
system, you must set up several global environment variables to provide
access to Multiservice Data Manager executables and Motif resource files.
You can set up these variables by
entering the setenv command with the variable name and its new value as
arguments for accounts that run C-shell
entering the <variable>=<value> ; export <variable> commands for
accounts that run Bourne or Korn shell
inserting the variables into set-up files
running one of the two scripts described in Environment setup scripts
(page 20)
There are two sets of variables: mandatory variables you must set up for
Multiservice Data Manager software to perform correctly, and optional symbol
variables. The following sections describe these two sets of variables.
Mandatory variables
The following variables must be set for Nortel Multiservice Data Manager
software to operate correctly. In the skeleton files that are provided with the
software, these variables are set by file .cshrc for user accounts that use C-
shell or set-up file .profile for user accounts that use Korn or Bourne shell.
DISPLAY
DISPLAY is the name of the X-Windows display and is usually set by the login
system (XDM, DTLOGIN). If the display is not set, Multiservice Data Manager
assumes a console login and sets the DISPLAY variable to :0.0.
LANG
LANG identifies the local language (the Locale). If not set, Multiservice Data
Manager sets the value of this variable to C. This value represents traditional
UNIX and English. Other values that can be used with Solaris and with the
software are ja for Japanese and zh for Chinese.
USMSERVER
USMSERVER is used internally by some Multiservice Data Manager tools
and is set to the same value as DISPLAY.
PATH/path
PATH/path lets you invoke Multiservice Data Manager tools without specifying
the full path name when you enter the startup command. Multiservice Data
Manager appends its macros and bin directories to it
(/opt/MagellanNMS/cfg/macros/user/opt/MagellanNMS/cfg/macros/nms and
/opt/MagellanNMS/bin).

NN10470-305 01.02 Standard
16.2 May 2007
- 20 -
XUSERFILESEARCHPATH
This is the Motif Resource lookup path. Nortel Multiservice Data Manager
appends its resource paths to it
(/opt/MagellanNMS/cfg/app-defaults/%L/%N and
/opt/MagellanNMS/lib/app-defaults/%L/%N). For an explanation of %L and
%N, see the man pages for the X command.
CAUTION
Inability of Multiservice Data Manager tools to run
correctly
This variable must be set with at least these two paths for
Multiservice Data Manager tools to run properly.
Optional variables
The following variables are optional and are not set in the skeleton files
supplied with the default Nortel Multiservice Data Manager environment. Set
them in file .cshrc for C-shell accounts and file .profile for Bourne or Korn shell
accounts.
NMSXTERM
NMSXTERM is the path for the preferred terminal console tool that the
Multiservice Data Manager software uses whenever it needs to start a
terminal window for UNIX Access or to execute a macro. If this variable is not
set, MDM software uses dtterm for the Common Desktop Environment (CDE)
window manager, and xterm for other window managers.
NMSTSETS
NMSTSETS is the toolsets definition file which is used to open a Multiservice
Data Manager window. If this variable is not set, Multiservice Data Manager
software uses the English language toolset definition file
/opt/MagellanNMS/lib/tsets/C/Full.tsets. For a list and description of the
toolset definition filenames you can use for this variable, see Nortel
Multiservice Data Manager AdministrationTools (NN10470-300).
LPDEST
LPDEST is the name of the default printer for the user account. The values of
the LPDEST and PRINTER environment variables must be identical to ensure
the same results with BSD and SVR4 style applications.
Environment setup scripts

Nortel Multiservice Data Manager software contains two scripts to set up the
Multiservice Data Manager environment. These scripts can be run from the
command line, or from within set-up files of a UNIX user account, as described
in Nortel Multiservice Data Manager Administration (NN10470-303).

NN10470-305 01.02 Standard
16.2 May 2007
- 21 -
In the skeleton files that are provided with the MDM software, these scripts are
called in file .cshrc for user accounts that use C-shell or in set-up file .profile
for user accounts that use Korn or Bourne shell.
The scripts are as follows:
/opt/MagellanNMS/bin/nmscsh
This script sets up environmental variables for user accounts that run C-shell.
Invoke this script from a non-default .cshrc file
(source /opt/MagellanNMS/bin/nmscsh) to establish Nortel Multiservice Data
Manager environment.
/opt/MagellanNMS/bin/nmssh
This script sets up environmental variables for user accounts that run Korn
shell or Bourne shell. Run this script from a non-default .profile file
(. /opt/MagellanNMS/bin/nmssh) to establish the Multiservice Data Manager
environment.
User session startup scripts

Nortel Multiservice Data Manager software contains two scripts to start a
session and open a Multiservice Data Manager window. These scripts can be
run from the command line, or can be called from within set-up files of a UNIX
user account, as described in Nortel Multiservice Data Manager
In the skeleton files that are provided with Multiservice Data Manager
software, these scripts are invoked in file .xsession for accounts that run the
SDK Motif Window Manager, in file .xinitrc for accounts that run OpenWin, and
in files .dtprofile, .sessionetc, and .sessionexit for accounts that run the
Common Desktop Environment (CDE).
The scripts are as follows:
/opt/MagellanNMS/bin/nmssession
This script starts a Nortel Multiservice Data Manager session and maintains
it and its session servers. This script must be run once per DISPLAY session
and terminated when the session is terminated.
Attention: Do not call this script if nmstool is already running.
/opt/MagellanNMS/bin/nmstool
This script opens a Nortel Multiservice Data Manager window. By default this
script starts the English language toolset Full.tsets. For the instructions to use
a different toolset, see Nortel Multiservice Data Manager Administration
Tools (NN10470-300).

NN10470-305 01.02 Standard
16.2 May 2007
Disruptive Command Safeguard
Review this section for a description of the instructions required to set up the
Disruptive Command Safeguard feature. This feature applies only to DPN
nodes.
For initial installation, you can use the information in this section to configure
the Disruptive Command Safeguard, or you can use the Nortel Multiservice
Data Manager Software Configuration tool, as described in Nortel
Multiservice Data Manager Installation and CommissioningSoftware
(NN10470-100).
Navigation
About the Disruptive Command Safeguard feature (page 22)
The /opt/MagellanNMS/cfg/DCS.cfg configuration file (page 23)
Checking, enabling, and disabling the Disruptive Command Safeguard
(page 24)
About the Disruptive Command Safeguard feature

The Disruptive Command Safeguard is a command input management facility
that intercepts potentially disruptive DPN commands entered from a Nortel
Multiservice Data Manager workstation and presents a confirm or cancel
message to the operator. The commands intercepted by the Disruptive
Command Safeguard are defined in the /opt/MagellanNMS/cfg/DCS.cfg
configuration file. You can enable, disable, or query the status of the Disruptive
Command Safeguard from the application main window or from the UNIX
command line.
The Disruptive Command Safeguard can be called from application programs

such as the Multiservice Data Manager VT100 operator facility or the
Command Console tool. Systems built on top of the VT100 operator facility
using the RNCS primitives can take advantage of the disruptive command
library in the same manner that the VT100 operator facility does.

NN10470-305 01.02 Standard
16.2 May 2007
- 23 -
Attention: The Disruptive Command Safeguard facility does not apply to

commands entered through local operator terminals connected directly to
the operator port of a packet module or an NM, or to the DPN-50 based NCS
VT100 operator terminal facility.
The /opt/MagellanNMS/cfg/DCS.cfg configuration file

The commands intercepted by the Disruptive Command Safeguard are
defined in the /opt/MagellanNMS/cfg/DCS.cfg configuration file. A default file
is supplied. See The default /opt/MagellanNMS/cfg/DCS.cfg file (page 24).
You need to have root privileges in order to edit the file.
File format
The opt/MagellanNMS/cfg/DCS/.cfg configuration file consists of a series of
lines, each having the following syntax:
<KEYWORD> <min_length> <NCS_CAPABILITY> [<MESSAGE>]
where:
<KEYWORD> is the command keyword for which you want to search
<min_length> is the minimum number of characters required to match the

keyword
<NCS_CAPABILITY> is the user capability expressed in the format TYPE

LEVEL IMPACT
[<MESSAGE>] is an optional message that is displayed with the confirm or

cancel message
Example
Assume the /opt/MagellanNMS/cfg/DCS.cfg file contains the following line:
FORMAT 6 SWITCHING DEVICE PRIVILEGED Disk formatting
will cause instability
and the Nortel Multiservice Data Manager operator issues the following
command:
R72 2 DISK 0 FORMAT 2 1 R70 2 SEC 512 DIR 1000
If the operator has capability SWITCHING DEVICE PRIVILEGED, the
Disruptive Command Safeguard facility instructs the NCS access tool to issue
the prompt Disk formatting will cause instability, followed by confirm or cancel
instructions.
If the operator does not have SWITCHING DEVICE PRIVILEGED capability,

no message is issued, since the command is rejected by the module anyway.

NN10470-305 01.02 Standard
16.2 May 2007
- 24 -
The default /opt/MagellanNMS/cfg/DCS.cfg file

A default /opt/MagellanNMS/cfg/DCS.cfg file is included with the Nortel
Multiservice Data Manager software. You can edit this file or use it as a
template to create your own file. The contents of the file are shown in the figure
The default /opt/MagellanNMS/cfg/DCS.cfg file (page 24).
The default /opt/MagellanNMS/cfg/DCS.cfg file
#
# Disruptive Command configuration file.
# Syntax:
# Command minimum-length NCS capability (TYPE LEVEL IMPACT) message
#
ACTIVATE 3 SWITCHING LINE CONFIGURATION
COMMIT 3 SWITCHING DEVICE CONFIGURATION
CONFIRM 4 SWITCHING DEVICE CONFIGURATION
DEREGISTER 3 NONE NONE NONE
DISABLE 7 SWITCHING DEVICE SERVICE
ERASE 5 SWITCHING DEVICE PRIVILEGED
FILTER 1 NAMS NETWORK CONFIGURATION
FORMAT 6 SWITCHING DEVICE PRIVILEGED
LOAD 4 SWITCHING DEVICE PRIVILEGED
REFUSE 6 SWITCHING LINE SERVICE
REGISTER 3 NONE NONE NONE
RELOAD 6 SWITCHING DEVICE PRIVILEGED
RESET 5 SWITCHING DEVICE CONFIGURATION
RESTART 7 SWITCHING DEVICE PRIVILEGED
STOP 4 SWITCHING LINE SERVICE
Checking, enabling, and disabling the Disruptive Command

Safeguard
Nortel Multiservice Data Manager provides a Disruptive Command Safeguard
menu. You can access the menu items from the application main window by
selecting System -> Security -> Disruptive Command Safeguard. This toolset
is not available when the Multiservice Data Manager session launches toolset
User.tsets.
Disruptive Command Safeguard menu

The Disruptive Command Safeguard menu provides the following commands:
Check Status tells you if the Disruptive Command Safeguard is enabled or
disabled.
Enable Safeguard enables the Disruptive Command Safeguard.
Disable Safeguard disables the Disruptive Command Safeguard.
Attention: The Disruptive Command Safeguard is disabled when

Multiservice Data Manager is first installed.

NN10470-305 01.02 Standard
16.2 May 2007
Fundamentals for configuring
Multiservice Data Manager servers for
Multiservice Switch
Use the information in this section in conjunction with the procedures used to
configure Nortel Multiservice Data Manager servers for Nortel Multiservice
Switches. Nortel Multiservice Data Manager servers can be configured to
support the three following basic functions for networks that contain Nortel
Multiservice Switches:
network access: allows users to log on to nodes and enter commands to
perform operations such as troubleshooting
surveillance access: allows Multiservice Data Manager software to gather
surveillance information from nodes
provisioning access: allows users to configure nodes and upload Service
Data Descriptions (SDD) to the workstation
For information about servers other than those that support these basic
functions, and for references to the instructions for configuring them, see
Nortel Multiservice Data Manager AdministrationServer Management
(NN10470-310).
For the procedures relating to the information listed below, see Nortel
Multiservice Data Manager Administration (NN10470-303). Descriptions of
the administrative tools used to perform the tasks listed here are found in
Nortel Multiservice Data Manager AdministrationTools (NN10470-300).
Navigation
Servers required to support Multiservice Switch network access,
surveillance, and provisioning access (page 26)
Groups of nodes for network access (page 27)
Reasons for Multiservice Switch groups and guidelines for set up
(page 26)

NN10470-305 01.02 Standard
16.2 May 2007
- 26 -
Fundamentals for configuring Multiservice Data Manager servers for Multiservice Switch
Guidelines to group nodes for surveillance access (page 30)

FMDR server redundancy for surveillance access (page 33)
Servers required to support Multiservice Switch network access,

surveillance, and provisioning access
The figure Interdependencies of servers that support basic functions,
networks containing Multiservice Switches (page 27) shows the servers that
need to be configured to support the basic functions of Nortel Multiservice
Switch network access, surveillance access, and provisioning access, and it
illustrates the dependencies between these servers.
The servers that need to be configured to support these functions are as

follows:
Multiservice Switch Communication Manager (FDTM)
Host Group Directory Server (HGDS)
FMIP Management Data Router (FMDR)
Data Manager Agent (DMA)
General Management Data Router (GMDR)
For detailed descriptions of these servers, see Nortel Multiservice Data

Manager AdministrationServer Management (NN10470-310).
Reasons for Multiservice Switch groups and guidelines for set up

A Nortel Multiservice Switch group is a set of Multiservice Switch nodes that
share a least one common user ID and password for performing a common
management role such as network access, surveillance, or provisioning, and
which is defined as a group in the configuration files of the Nortel Multiservice
Data Manager software.
Because the user ID defines the administrative capability (scope and impact)
of a user, you can use groups to control access to the administrative functions
on a node. When a user logs on with a user ID, the user has access to all of
the nodes defined in the group and can perform any administrative functions
allowed by the administrative capability of the user ID.
Multiservice Switch groups are therefore used to control access to the

network. Access is required for two main reasons:
network access: to allow an operator or administrator to log in to a node
with the Command Console or to perform provisioning operations
surveillance access: to allow the FMIP Management Data Router (FMDR)
server to log in to a group of nodes and obtain surveillance information

NN10470-305 01.02 Standard
16.2 May 2007
- 27 -
A Multiservice Switch node can belong to several groups, so that it can be

accessed by different user IDs for different tasks. For example, the same node
can be accessed by an operator for surveillance, and by a network
administrator for provisioning.
Interdependencies of servers that support basic functions, networks containing Multiservice

Switches
GMDR
FMDR OAM
HGDS
Node
FDTM provisioning
stack
FDTR
Multiservice Switch
network
data flow
control flow
servers that you must configure manually
servers that are configured automatically
network access servers
surveillance access servers
provisioning access servers
Groups of nodes for network access

You can define groups that allow users, such as operators or administrators,
to access all of the Nortel Multiservice Switches in a group and perform
operations such as provisioning or troubleshooting. When a user logs on to a

NN10470-305 01.02 Standard
16.2 May 2007
- 28 -
group with a user ID defined on all nodes in the group, the user has access to
all of the nodes and can perform all of the functions that the scope and impact
of the user ID allows.
Guidelines for grouping nodes to provide network access are as follows:

You must define at least one common user ID and password on all the
nodes in a group for performing network access functions. This common
user ID and password must authenticate in the same way on all the nodes
in the group. That is, you must define the user ID and password with the
same scope and impact, and all of the nodes must return the same
CNMID.
You are not limited to defining just one common user ID and password.
You can define several common user IDs and passwords on the nodes in
a group, and dedicate each to a different function. For example, one user
ID could have access privileges for provisioning, while another could have
access privileges for performing maintenance functions. However, any
common user ID and password must authenticate in the same way on all
of the nodes in the group.
You can include a node in more than one group.
For an example of grouping nodes, see Do not create groups containing more
than 60 nodes for surveillance access. (page 32).
Grouping nodes for surveillance access

To use the guidelines in this section to group Nortel Multiservice Switches for
surveillance access, you first require an understanding of how surveillance
information is obtained from the network. This section is therefore divided into
two parts:
At startup time (page 28)
At run time (page 29)
At startup time
To obtain surveillance information the following sequence occurs. See the
figure How the filtering of surveillance information is set up (page 30) for an
illustration of this sequence.
1 The FMDR server on a Nortel Multiservice Data Manager workstation logs
in to all of the nodes in a surveillance group with a common user ID and
password that it obtains from arguments in its startup command.
2 Each node authenticates the user ID and password, and returns a
customer network identifier (CNMID).
To perform its filtering function, an FMDR server needs to receive
surveillance information from all of the devices on all of the nodes in the
surveillance group. For an FMDR server to receive the information, the

NN10470-305 01.02 Standard
16.2 May 2007
- 29 -
common user ID and password must be defined on all the nodes such that
is has a scope impact sufficient to obtain the required surveillance
information, and that it causes all the nodes to return a CNMID of 0.
Once logged in, the FMDR server is ready to receive alarms and status
records automatically from all of the nodes in the surveillance group.
3 To obtain surveillance information from an FMDR server, a client
application, such as the GMDR server, registers with the FMDR server.
This registration request also includes a user ID and password, which can
set up by means of the GMDR Administration tool.
4 The FMDR server passes the user ID and password contained in the
registration request to one of the nodes in the surveillance group for
authentication.
5 The node authenticates the user ID and password, and returns a customer
network identifier (CNMID) to the FMDR server. The FMDR server stores
this CNMID for filtering purposes.
6 The FMDR initiates a state walk-through to obtain the states of all
components that it surveils. It also contains information about links that
terminate on TRK components and DPNGATE components and sets the
initial state of these links to in-service.
Attention: The Network Model Server determines and sets the actual states
of these links based on the states of components at both ends of each link.
The setup is now complete.
At run time
When setup is complete and a node forwards surveillance information to the
Multiservice Data Manager workstation, the FMDR server filters the
surveillance information for the client application (GMDR) according to client
applications stored CNMID.
For a client application (GMDR) to be able to receive surveillance information

from all devices on all nodes in the surveillance group, the user ID and
password provided by the client application (GMDR) must cause the node to
return a CNMID of 0. For virtual private networks (VPN), in which a customer
should only receive information about the devices in the VPN, the user ID and
password must cause the nodes to return a CNMID other than 0, and that is
unique to the customers VPN.

NN10470-305 01.02 Standard
16.2 May 2007
- 30 -
How the filtering of surveillance information is set up
Client application
(GMDR server) FMDR server Multiservice
Setup begins Switch
FMDR server
is started 1
user ID and
password from
FMDR servers Authentication
startup command
2
GMDR server
is started 3 CNMID of 0
GMDR admin
tool is used to 4
associate Registration
request
FMDR server (userid and,
with GMDR user ID and
server password) password
5
Authentication
CNMID of 0 for
all devices or
other CNMID
for a VPN
6
State walk through
Setup is complete and surveillance begins
Surveillance
information is
generated
Filter according Surveillance

to CNMID information
Filtered
surveillance
information
Guidelines to group nodes for surveillance access

Guidelines to group Nortel Multiservice Switches for surveillance access are
as follows:
User IDs and passwords

The following considerations apply to user IDs and passwords
All nodes in a surveillance group must support at least one common user
ID and password for surveillance purposes. This common user ID and

NN10470-305 01.02 Standard
16.2 May 2007
- 31 -
password must authenticate in the same way on all nodes. That is, it must
have the same scope and impact, and must return the same CNMID.
For security reasons, a common user ID and password for surveillance
purposes must have the lowest possible scope and impact that still allows
the user to obtain surveillance information. The scope to do this is Device
and the impact is Service if the data model (SDD) is to be retrieved
automatically. A Passive impact will also work if the data model is already
available on the workstation.
To ensure that an FMDR server receives surveillance information from all
components in its group, the CNMID returned in response to the user ID
and password in the FMDR servers startup command must be CNMID 0,
also known as netman.
To ensure that a client application (GMDR) receives surveillance
information from all components in a surveillance group, the CNMID
returned in response to the user ID and password that the client
application provides must also return a CNMID of 0.
To ensure that a client application (GMDR) which monitors components in
a VPN only obtains surveillance information for the components that
belong to the VPN, the CNMID returned in response to the user ID and
password that the client application provides must be a CNMID other than
0, and it must be unique to that VPN.
For cases in which the FMDR server and the client application both need
to obtain surveillance information from all components on all nodes in a
surveillance group, they can use the same user ID and password. The
CNMID returned must be CNMID 0.
For cases in which the client application obtains surveillance information
for a VPN, and only needs to receive surveillance information from the
components in that VPN, the user ID and password provided by the client
application cannot be the same as the user ID password in the FMDR
servers startup command. The user ID and password provided by the
client application must also authenticate in the same way on all nodes on
which it is defined, and the CMNID returned must also be a CNMID other
than 0.
FMDR servers and groups:

The following considerations apply to FMDR servers and groups:
For surveillance, you must define at least one surveillance group.
A node can be included in more than one group.
There must be one FMDR server for each surveillance group.
The names of surveillance groups must be unique on a given Nortel
Multiservice Data Manager workstation. For example, you cannot have

NN10470-305 01.02 Standard
16.2 May 2007
- 32 -
two groups called TOTO on the same workstation. You can, however,
duplicate the names of surveillance groups on different workstations.
Do not create groups containing more than 60 nodes for surveillance access.
CAUTION
Risk of difficulty in obtaining surveillance information
Defining groups with more than 60 members for surveillance
access may cause difficulty in connecting to all of the nodes in
the group to obtain surveillance information.
Grouping nodes, a simple example

The figure Multiservice Switch groups (page 32) contains a simple example of
grouping in a network that contains five nodes. Two of the nodes (NEWYORK1
and NEWYORK2) are located in New York, and the other three are located in
Paris (PARIS1, PARIS2, and PARIS3).
Multiservice Switch groups
Group NY
NEWYORK1 NEWYORK2
Users: survey, Users: survey,
netman, prony netman, prony
Group NETWORK
Group PARIS
PARIS1 PARIS2 PARIS3

Users: survey, Users: survey, Users: survey,
netman, propar netman, propar netman, propar
Network administrative requirements

The network has the following administrative requirements:
User survey needs to access all nodes in the network for surveillance.
User prony needs to perform provisioning on all of the nodes in New York
and user propar needs to perform provisioning on all of the nodes in Paris;
node provisioning is performed locally.
User netman needs to access all nodes in the network for network
management purposes.

NN10470-305 01.02 Standard
16.2 May 2007
- 33 -
Group setup
Administering this network requires three groups:
a group that contains all of the nodes (NETWORK) that can be accessed
by users survey and netman
a group that contains only the New York-based nodes (NY) that can be
accessed by user prony
a group that contains all of the Paris-based nodes (PARIS) that can be
accessed by user propar
For a detailed description of how you can share servers among Nortel
Multiservice Data Manager workstations that are connected to an Ethernet
LAN, see the description of the Service Selection tool in Nortel Multiservice
Data Manager AdministrationTools (NN10470-300).
FMDR server redundancy for surveillance access

If you have two or more Nortel Multiservice Data Manager workstations that
are connected by a LAN, one of the ways to add redundancy for surveillance
gathering is to take advantage of the ability of a GMDR server to discard
duplicate surveillance information that it receives from FMDR servers.
To achieve redundancy, you can create duplicate surveillance groups on each

of the workstations and run a separate FMDR server on each workstation, as
shown in the figure FMDR server redundancy (page 34). Then, using the
GMDR Administration tool, as described in Nortel Multiservice Data Manager
AdministrationTools (NN10470-300), you can set up the GMDR server on
each workstation to gather surveillance information from the FMDR servers
on both workstations.
The GMDR server receives alarms from the FMDR servers on both
workstations but only displays the alarms once, because the GMDR server
discards duplicate alarm notifications. Therefore, should one of the FMDR
servers fail, the GMDR server continues to receive surveillance data from its
redundant FMDR server without producing an impact on the Fault tools that
rely on this information.
The figure FMDR server redundancy (page 34) shows a network containing
three nodes that are monitored by two standalone MDM workstations
connected by a LAN. Identical groups called G1 are defined on both
workstations. Separate FMDR servers are started to retrieve surveillance data
from the groups. The startup command for each FMDR server includes the
server name FMDR_G1.

NN10470-305 01.02 Standard
16.2 May 2007
- 34 -
Using the GMDR Administration tool, each GMDR server is configured to

receive surveillance data from the FMDR server on its own workstation and
from the FMDR server on the redundant workstation through the LAN
connection.
The GMDR server on workstation A discards duplicate data from the FMDR
servers. Should server FMDR_G1 fail on workstation A, the GMDR server on
workstation A still gets the same surveillance information from the redundant
FMDR through its LAN connection to workstation B.
FMDR server redundancy
LAN
Workstation A Workstation B
GMDR GMDR
FMDR_G1 FMDR_G1
Multiservice Switch Duplicate

group G1 Multiservice Switch
group G1
Distribution of servers among workstations on a LAN in big networks

For small networks, all of the servers that support Nortel Multiservice Switch
network access, surveillance access, and provisioning access can run on the
same workstation.
For medium and large networks, servers can be deployed among Nortel
Multiservice Data Manager workstations connected by the same Ethernet
LAN or by a WAN IP connection. This is can be done for a number of reasons
including the following:
to distribute the workload over a number of Multiservice Data Manager
workstations to improve performance

NN10470-305 01.02 Standard
16.2 May 2007
- 35 -
to permit effective use of older less powerful workstations along with new
more powerful workstations
to add redundancy and resiliency for fault management
The following guidelines apply to deploying the servers for Multiservice Switch
network access, surveillance, and provisioning access over multiple
workstations:
The following servers must run on a workstation that provides network
access (a workstation that has an X25 or Frame Relay link to the network):
HGDS, FDTM, and FDTR.
The FMDR server must run on the workstation that provides network
access by default. You can run it on another workstation, provided that you
specify the hostname of the workstation that runs the network access
server, as part of the FMDR servers startup command.
The GMDR server can run on any workstation on the LAN, provided the
workstation can handle traffic to the server. To ensure that the GMDR
server receives surveillance information, you must use the GMDR
Administration tool to specify the FMDR server (or servers) from which the
GMDR server is to obtain the surveillance information for nodes.

NN10470-305 01.02 Standard
16.2 May 2007
Fundamentals for configuring
Multiservice Data Manager servers for
Multiservice Provider Edge
Read Nortel Multiservice Provider Edge server fundamentals to understand
how servers work together to support provisioning, surveillance, and network
access.
For the procedures relating to the information listed below, see Nortel
Multiservice Data Manager Administration (NN10470-303). Descriptions of
the administrative tools used to perform the tasks listed here are found in
Nortel Multiservice Data Manager AdministrationTools (NN10470-300).
Navigation
Servers required to support Multiservice Provider Edge network access,
surveillance, and provisioning access (page 36)
Reasons for groups and guidelines for set up (page 37)
Guidelines for grouping nodes for surveillance access (page 40)
NMDR server redundancy for surveillance access (page 42)
SNMP Proxy Agent (SPA) fundamentals (page 44)
Servers required to support Multiservice Provider Edge network

access, surveillance, and provisioning access
The figure Interdependencies of servers that support basic functions in
networks containing Multiservice Provider Edge (page 38) shows the servers
that need to be configured to support the basic functions of Multiservice
Provider Edge network access, surveillance access, and provisioning access,
and it illustrates the dependencies between these servers.

NN10470-305 01.02 Standard
16.2 May 2007
- 37 -
Fundamentals for configuring Multiservice Data Manager servers for Multiservice Provider Edge
The servers that need to be configured to support these functions are:

Multiservice Provider Edge Communication Manager (NDTM)
Host Group Directory Server (HGDS)
Multiservice Provider Edge Management Data Router (NMDR)
General Management Data Router (GMDR)
MDM Log Collector (OAMC)
For detailed descriptions of these servers, see Nortel Multiservice Data

Reasons for groups and guidelines for set up

A Nortel Multiservice Provider Edge group is a set of Multiservice Provider
Edge nodes that shares a least one common user ID and password for
performing a common management role such as network access,
surveillance, or provisioning, and which is defined as a group in the
configuration files of the Nortel Multiservice Data Manager software.
Because the user ID defines the administrative capability (scope and impact)
of a user, you can use Multiservice Provider Edge groups to control access to
the administrative functions on a node. When a user logs on with a userid, the
user has access to all of the nodes defined in the group and can perform any
administrative functions allowed by the administrative capability of the userid.
Multiservice Provider Edge groups are therefore used to control access to the
network. Access is required for two main reasons:
network access: to allow an operator or administrator to log onto a node
with the command access or to perform provisioning operations
surveillance access: to allow the Management Data Router (NMDR)
server to log on to a group of nodes and obtain surveillance information
A Multiservice Provider Edge node can belong to several groups, so that it can
be accessed by different userids for different tasks. For example, a node can
be accessed by an operator for surveillance, and by a network administrator
for provisioning.

NN10470-305 01.02 Standard
16.2 May 2007
- 38 -
Interdependencies of servers that support basic functions in networks containing Multiservice

Provider Edge
GMDR
NMDR OAM
HGDS
Node
NDTM provisioning
stack
NDTR
Multiservice
Provider Edge
network
data flow
control flow
servers that you must configure manually
servers that are configured automatically
network access servers
surveillance access servers
provisioning access servers
Groups of nodes for network access

You can define groups that allow users, such as operators or administrators,
to access all of the nodes in a group of nodes and perform operations such as
provisioning or troubleshooting. When a user logs on to a group with a user ID
defined on all nodes in the group, the user has access to all of the nodes in
the group and can perform any of the functions allowed by the user ID.
Guidelines for grouping nodes to provide network access are as follows:

You must define at least one common userid and password on all nodes
in a group for performing network access functions. This common user ID

NN10470-305 01.02 Standard
16.2 May 2007
- 39 -
and password must authenticate in the same way on all nodes in the
group. That is, the userid and password must be defined with the same
login class permissions.
You are not limited to defining just one common userid and password. You
can define several common user IDs and passwords on the nodes in a
group and dedicate each to a different function. For example, one user ID
could have access privileges for provisioning, while another could have
access privileges for performing maintenance functions. However, any
common userid and password must authenticate in the same way on all
nodes in the group.
A node can belong to more than one group.
Attention: For an example of grouping nodes, see Multiservice Provider

Edge Groups (page 41).
A Multiservice Provider Edge group cannot contain Nortel Multiservice

Switch nodes, and a Multiservice Switch group can not contain
Multiservice Provider Edge nodes.
Group names must be unique.
Grouping nodes for surveillance access

To use the guidelines in this section to group nodes for surveillance access
you first require an understanding of how surveillance information is obtained
from the network. This section is divided into two parts:
At startup time (page 39)
At run time (page 40)
At startup time
To obtain surveillance information the following sequence occurs. See the
figure NMDR server redundancy (page 43) for an illustration of this sequence.
1 The NMDR server on a Nortel Multiservice Data Manager workstation
logs in to all of the nodes in a surveillance group with a common userid
and password that it obtains from arguments in its startup command.
2 Each node authenticates the user ID and password, and returns a
customer network identifier (CNMID).
To perform its filtering function, an NMDR server needs to receive
surveillance information from all of the devices on all of the nodes in the
surveillance group. For an NMDR server to receive the information, the
common userid and password must be defined on all nodes.

NN10470-305 01.02 Standard
16.2 May 2007
- 40 -
3 To obtain surveillance information from an NMDR server, a client

application, such as the GMDR server, registers with the NMDR server.
This registration request also includes a user ID and password, which can
set up by means of the GMDR Administration tool.
4 The NMDR server passes the user ID and password contained in the
registration request to one of the nodes in the surveillance group for
authentication.
5 The node authenticates the user ID and password.
6 The NMDR initiates a state walk-through to obtain the list of all
components that it surveils.
The setup is now complete.
At run time
When setup is complete, the node forwards surveillance information to the
Nortel Multiservice Data Manager workstation.
Guidelines for grouping nodes for surveillance access

Guidelines for grouping nodes for surveillance access are as follows:
Userids and passwords

The following guidelines apply to User IDs and passwords:
All nodes in a surveillance group must support at least one common user
ID and password for surveillance purposes. This common user ID and
password must authenticate in the same way on all nodes.
For security reasons, a common user ID and password for surveillance
purposes must have the minimum login class with a permission of view.
NMDR servers and groups:

The following guidelines apply to NMDR servers and groups:
For surveillance, you must define at least one surveillance group.
A node can belong to more than one group.
There must be one NMDR server for each surveillance group.
The names of surveillance groups must be unique on a given workstation.
For example, you cannot have two groups called TOTO on the same
workstation. You can, however, duplicate the names of surveillance
groups on different workstations.
Do not create groups containing more than 60 nodes for surveillance access.

NN10470-305 01.02 Standard
16.2 May 2007
- 41 -
CAUTION
Risk of difficulty in obtaining surveillance information
Defining groups with more than 60 members for surveillance
access may cause difficulty in connecting to all of the nodes in
the group to obtain surveillance information.
Grouping nodes, a simple example

The figure Multiservice Provider Edge Groups (page 41) contains a simple
example of grouping in a network that contains five nodes. Two of the nodes
(NEWYORK1 and NEWYORK2) are located in New York, and the other three
are located in Paris (PARIS1, PARIS2, and PARIS3).
Multiservice Provider Edge Groups
Group NY
NEWYORK1 NEWYORK2
Users: survey, Users: survey,
netman, prony netman, prony
Group NETWORK
Group PARIS
PARIS1 PARIS2 PARIS3

Users: survey, Users: survey, Users: survey,
netman, propar netman, propar netman, propar
Network administrative requirements

The network has the following administrative requirements:
User survey needs to access all nodes in the network for surveillance.
User prony needs to perform provisioning on all of the nodes in New York
and user propar needs to perform provisioning on all of the nodes in Paris;
node provisioning is performed locally.
User netman needs to access all nodes in the network for network
management purposes.
Group setup
Administering this network requires three groups:
a group that contains all of the nodes (NETWORK) that can be accessed
by users survey and netman
a group that contains only the New York-based nodes (NY) that can be
accessed by user prony

NN10470-305 01.02 Standard
16.2 May 2007
- 42 -
a group that contains all of the Paris-based nodes (PARIS) that can be
accessed by user propar
For a detailed description of how you can share servers among Nortel
Multiservice Data Manager workstations that are connected to an Ethernet
LAN, see the description of the Service Selection tool in Nortel Multiservice
Data Manager AdministrationTools (NN10470-300).
NMDR server redundancy for surveillance access

If two or more workstations are connected by a LAN, one of the ways to add
redundancy for surveillance gathering is to take advantage of the ability of a
GMDR server to discard duplicate surveillance information that it receives
from NMDR servers.
To achieve redundancy, you can create duplicate surveillance groups on each

of the workstations and run a separate NMDR server on each workstation, as
shown in the figure NMDR server redundancy (page 43). Then, using the
GMDR Administration tool, as described in Nortel Multiservice Data Manager
AdministrationTools (NN10470-300), you can set up the GMDR server on
each workstation to gather surveillance information from the NMDR servers
on both workstations.
The GMDR server receives alarms from the NMDR servers on both
workstations but only displays the alarms once, because the GMDR server
discards duplicate alarm notifications. Therefore, should one of the NMDR
servers fail, the GMDR server continues to receive surveillance data from its
redundant NMDR server without producing an impact on the Fault tools that
rely on this information.
The figure NMDR server redundancy (page 43) shows a network containing
three nodes that are monitored by two standalone workstations connected by
a LAN. Identical groups called G1 are defined on both workstations. Separate
NMDR servers are started to retrieve surveillance data from the groups.
Using the GMDR Administration tool, each GMDR server is configured to

receive surveillance data from the NMDR server on its own workstation and
from the NMDR server on the redundant workstation through the LAN
connection.
The GMDR server on workstation A discards duplicate data from the NMDR
servers. Should server NMDR_G1 fail on workstation A, the GMDR server on
workstation A still gets the same surveillance information from the redundant
NMDR through its LAN connection to workstation B.

NN10470-305 01.02 Standard
16.2 May 2007
- 43 -
NMDR server redundancy
LAN
GMDR GMDR
NMDR_G1 NMDR_G1
Multiservice Provider Duplicate

Edge group G1 Multiservice Provider
Edge group G1
Distribution of servers among workstations on a LAN

For small networks, all of the servers that support Nortel Multiservice Provider
Edge network access, surveillance access, and provisioning access can run
on the same workstation.
For medium and large networks, servers can be deployed among

workstations connected by the same Ethernet LAN or by a WAN IP
connection. This is can be done for a number of reasons including the
following:
to distribute the workload over a number of workstations to improve
performance
to permit effective use of older less powerful workstations along with new
more powerful workstations
to add redundancy and resiliency for fault management
The following guidelines apply to deploying the servers for Multiservice

Provider Edge network access, surveillance, and provisioning access over
multiple workstations:
The following servers must run on a workstation that provides network
access: HGDS, NMDR, NDTM, and NDTR.

NN10470-305 01.02 Standard
16.2 May 2007
- 44 -
If you intend to use LAN Service Selection in a mixed Multiservice

Provider Edge and Nortel Multiservice Switch network, the Multiservice
Provider Edge access servers and the Multiservice Switch access servers
must be running on the same workstation.
The GMDR server can run on any workstation on the LAN, provided the
workstation can handle traffic to the server. To ensure that the GMDR
server receives surveillance information, you must use the GMDR
Administration tool to specify the NMDR server (or servers) from which the
GMDR server is to obtain the surveillance information for nodes.
SNMP Proxy Agent (SPA) fundamentals

The SNMP Proxy Agent (SPA) provides SNMP access to Nortel Multiservice
Provider Edge (MPE) equipment. SPA provides a single point of SNMP
access to several Nortel Multiservice Provider Edge nodes through a Nortel
Multiservice Data Manager server. SPA receives SNMP requests from SNMP
management processes and then performs the following functions:
forwards SNMP requests received from SNMP management processes to
the appropriate nodes,
forwards SNMP replies received from nodes to the requesting SNMP
Manager,
forwards SNMP traps received from nodes to registered SNMP Managers,
supports versions V1 and V2C of the SNMP protocol,
supports multiple community strings per node.
SPA runs only on Multiservice Data Manager workstations. Each SPA

instance is created and monitored by Multiservice Data Manager Server
manager (SVM). It obtains the list of nodes it provides access to from the Host
Group Directory Server (HGDS) and receives traps issued by the MPE
devices through the Multiservice Data Manager Trap Server (TSVR).
SPA issues logs to notify operators of important server events and problems.
These logs are collected and displayed by the Multiservice Data Manager
OAM log collector. SPA can also record a trace of its execution by storing logs
in a server log file. The level of detail logged depends on which log levels are
selected as part of the SPA configuration. The log file is located in /opt/
MagellanNMS/data/log/spa/spa_<portnumber>.nlog and can be displayed by
the MDM Log Browser. For additional information see Nortel Multiservice Data
Manager Administration (NN10470-303) and Nortel Multiservice Data
Interface with the MDM Server Manager

Each SNMP Proxy Agent instance is created and monitored by the MDM
Server Manager (SVM).

NN10470-305 01.02 Standard
16.2 May 2007
- 45 -
You can start up several SPA instances on one workstation to take care of
different groups of MPE devices separately or to share the load resulting from
a large number of SNMP managers.
Each SPA process has its own name and runtime parameters, uses a distinct
UDP port to receive requests and provides trap forwarding services to its own
SNMP managers list. The user must create a set of configuration files for each
SPA instance.
Interface with the Host Group Directory Server

The SNMP Proxy Agent obtains the list of MPE devices it provides access to
from the Host Group Directory Server (HGDS). By default, SPA provides
access to all the MPE devices known by HGDS on its workstations. However,
SPA can be configured to provide access to the MPE devices part of the
specified list of HGDS groups.
Interface with the MDM Trap Server

The SNMP Proxy Agent registers with the MDM Trap Server (TSVR) on its
workstation to receive traps. This interface is essentially the same interface
used by the MDM SNMP Surveillance Adapter.
The SPA design assumes that the workstation is configured on each managed
MPE device as a SNMPv1 trap destination. SPA translates these traps into
SNMPv2c traps for SNMP managers requiring traps in this version.
TSVR is designed to optionally perform two types of pre-filtering on traps

forwarded to its client processes:
Trap OID based filtering ensures that a client process only receives the
incoming traps that have a trap OID that is accepted by one of the OID
filters specified by the client process upon connection with TSVR.
SPA does not use this capability. SPA can therefore receive traps sent to
its workstation by non-MPE devices and reject those traps because the
sending device address does not match the IP address of any of the
managed MPE devices.
Address based filtering ensures that a client process only receives the
incoming traps sent from an IP address that is accepted by one of the IP
address filters specified by the client process upon connection with TSVR.
This capability is useful if more than one instance of the same server type
run on the same workstation and those instances are intended to manage
different regions of the network. By using this filtering option, the load put
on each instance is optimized by forwarding to each instance only the
traps originating from the network region that it is intended to manage.
SPA can optionally use this capability. However, SPA does its own address

NN10470-305 01.02 Standard
16.2 May 2007
- 46 -
filtering, using this option is never mandatory. If several SPA instances run
on the same workstation and are intended to manage different network
regions, using this option minimizes the number of traps forwarded to each
instance
SPA process name

Each SNMP proxy agent instance has its own process name as follows:
spa_<port number>. This process name is created and registered with MNSD
after reading the UDP port number from the command line or using a default
value of 361. For example: spa_361. This process name appears in logs to
identify the process instance and is also the first part of the process
configuration files name.
UDP Port for requests

Each SNMP proxy agent process binds to a distinct UDP port to which SNMP
managers send their SNMP requests. The default value is 361 and it can be
changed from the command line.
By default, SPA does not use the 161 UDP port generally used by device
SNMP agents to receive SNMP managers requests. This is to avoid
conflicting with the MDM workstation SNMP Agent which binds to this UDP
port 161. If a SPA instance binding to the UDP port 161 is required, the MDM
workstation SNMP agent must first be disabled to free this port for SPA usage.
Since only one process can bind to each UDP port, each SPA instance on the
same workstation must use a different port. Trying to start a new SPA instance
using the same port as another SPA instance results in the attempt to create
2 SPA servers with the same name causing the new SPA to abort after issuing
the appropriate FATAL log. Trying to start a new SPA instance using a UDP
port already assigned to another process results in a failure to bind to this port
causing the new SPA to abort after issuing the appropriate FATAL log.
SNMP versions
The SNMP proxy agent supports both SNMP v1 and SNMP v2c. Managers
can send either SNMP v1 or v2c requests through SPA and get a
corresponding reply from the targeted MPE device. SPA does not perform any
request or reply translations.
SPA provides an SNMP v1 and v2c traps forwarding service by specifying

which version of traps each manager wants to receive in the managers
configuration file. SPA expects SNMPv1 traps from MPE devices and maps
them to the SNMPv2c traps for those managers who require SNMPv2c traps.
Request types
This version of SNMP proxy agent supports GET, GET NEXT and GET BULK
request types.

NN10470-305 01.02 Standard
16.2 May 2007
- 47 -
From the SPA perspective, all requests received from SNMP managers and
all responses received from MPE devices have the same destination address
which is the SPA IP address. To forward these requests to the correct device
and help SNMP managers identify the device sending each response, all the
SNMP managers communicating with SPA are required to encode a special
community string in each request (the same community string format is used
by SPA in replies forwarded to managers). The required format is:
<NE id>[@<community>]
where:
<NE id> is either the IP address or the name of the MPE device
<community> is an optional community string to be used to send the request

to the device.Public or another default community string specified in the run-
time configuration file is used by default.
For example:
TORONTO@abc Indicates that the request must be sent to the MPE

device named TORONTO (if this device is
present in the managed devices list) using abc as
the forwarded request community string.
MONTREAL Indicates that the request must be sent to the MPE
device named MONTREAL using the community
string that has been configured as the SPA default
community string.
55.101.33.12@xyz Indicates that the request must be sent to the MPE
device that has an address of 55.101.33.12 (if this
device is present in the managed devices list)
using xyz as the forwarded request community
string.
When SPA receives a request with this special community string, it extracts
<NE id> from the string and converts it to the device IP address. After
replacing the source IP address of the request with its IP address, the
destination IP address with the MPE IP address, and the encoded community
string with the selected community string, SPA forwards the SNMP request to
the destination MPE. Similarly, when SPA receives a response from MPE, it
replaces the source IP address with its own address, destination IP addresses
with the address of the manager that originated the request and adds the <NE
id> to the community string before forwarding the modified response to the
SNMP manager. The manager can therefore learn from this modified
community string where the source of the reply.

NN10470-305 01.02 Standard
16.2 May 2007
- 48 -
Traps handling
The SNMP Proxy Agent requires its workstation to be registered as a
SNMPv1 trap destination on each managed MPE device. Therefore, SNMPv2
traps received from TSVR are silently discarded without even trying to identify
the sender (they could have been sent by non-MPE devices).
For each SNMPv1 trap received, SPA first tries to find a managed MPE with
the same IP address. If no managed MPE is found, the trap is discarded.
If there are SNMP managers requiring SNMPv1 traps, the incoming trap is
cloned into another SNMPv1 trap with the following characteristics:
sender address SPA address

community string <NE id>@<incoming trap community>
trap variables same as incoming trap. This trap is sent to
each SNMP manager requiring SNMPv1
traps.
If there are SNMP managers requiring SNMPv2 traps, a new SNMPv2 trap
PDU is created with the following characteristics:
sender address SPA address

community string <NE id>@<incoming trap community>
upTime variable copied from SNMPv1 trap corresponding field
notification OID variable <incoming trap OID>.0.<incoming trap
specific code> If the incoming trap is a generic
trap, the corresponding SNMPv2 trap OID is
used instead.
other trap variables same as incoming trap this trap is sent to each
SNMP manager requiring SNMPv2 traps.
Logs
The SNMP proxy agent complies with the new MDM Server Logging
guidelines. It uses the new logging library to generate logs.
The logs with the following levels are sent to the OAMC server:
FATAL, ALERT, CRITICAL, CLEARED, NOTICE
SPA is also configured to send logs of selected levels to its server log file:
/opt/MagellanNMS/data/log/spa/
spa_<port_number>.nlog_<YYYYMMDD>

NN10470-305 01.02 Standard
16.2 May 2007
- 49 -
The following levels are selected by default to be sent to this server log file:
FATAL,ALERT,CRITICAL,ERROR,CLEARED,NOTICE,INFO
This selection can be modified using the logLevels option in the run-time
configuration file.
The USR1 signal can also be sent to SPA to dynamically toggle between the
selection of all log levels and the list of levels selected by the runtime
parameters configuration file. Since the selection of WARNING, DEBUG and
especially TRACE levels generates a very high quantity of logs, SPA should
only be left in this state for a short period of time.
Statistical logs
SPA issues statistical information to logs according to the statisticInt
configuration parameter to help a user monitor SPA performance and identify
communication problems. This statistical information includes the following
items:
average number of requests received per hour
average number of responses sent per hour
average number of traps forwarded per hour
number of requests discarded during the last statistical period because
the device did not respond in time
they could not be correctly decoded
the maximum number of concurrent requests had been reached
the targeted device cannot be identified
number of managed MPE devices
number of SNMP managers requesting SNMP v1 traps
number of SNMP managers requesting SNMP v2c traps
The first seven items each have a counter which accumulates during the
statistic collection interval. When this interval terminates, SPA calculates the
statistical values required, generates the corresponding logs at the INFO
level, resets those counters to 0, and starts a new statistical interval.
Because these logs are issued at the INFO level, they are not sent to OAMC
and are sent to the server log file under the default log levels selection.

NN10470-305 01.02 Standard
16.2 May 2007
- 50 -
The user can also require the statistical logs to be issued on demand by
sending the USR2 signal to SPA. This signal causes
the current statistical interval to be terminated immediately.
the statistical values to be computed for the terminating interval.
the corresponding logs to be issued.
a new statistical interval to be started.

NN10470-305 01.02 Standard
16.2 May 2007
Multiservice Switch SDD file
management
Review this section for a description of Nortel Multiservice Switch SDD files
and an explanation of the procedures for generating, installing, and deleting
them.
Navigation
About SDD files (page 51)
Manually generating model files (page 53)
About SDD files

Nortel Multiservice Switch Software Data Definition (SDD) files define the
structure and format of service data for Multiservice Switches. This
information is needed as the framework for performing provisioning and
surveillance operations on a node.
More than one SDD file is used to define the structure and format of the
service data for a node. Together these files constitute a model that is
identified by a version number, for example: AC0053C. Because SDD files
constitute a model, they are also referred to as model files.
Model files can be obtained in the following ways:

automatically by starting a provisioning session to a node
manually by generating them from a tar file on compact disk, on tape, or
that has been transferred electronically
manually by generating them from a tar file uploaded from a node
automatically by generating them from a tar file uploaded from a node
when new software is detected
For more information, see the following:

SDD files and provisioning applications (page 52)

NN10470-305 01.02 Standard
16.2 May 2007
- 52 -
Multiservice Switch SDD file management
SDD files and provisioning applications

When a provisioning application, such as the Component Provisioning tool,
requires access to a model file, the provisioning stack (fps) does the following
to provide access to the file:
Fps determines if the model file is loaded into its local memory and if it is,
provides access to it.
If the model file is not loaded into memory, fps searches for it on the Nortel
Multiservice Data Manager disk and uploads it into its own memory.
If fps cannot find the model file on the Multiservice Data Manager disk, it
automatically uploads the model file from the node, copies it onto the
Multiservice Data Manager disk, and loads it into its own memory.
SDD files and surveillance applications

When a surveillance tool, such as Network Viewer, requires access to a
Network Model file, the network model file is loaded into shared memory,
meaning that the SDD file is parsed and the corresponding model is created
in shared memory. model files are updated dynamically in shared memory.
Dynamic updating refers to the following behaviors:
SDD files are automatically retrieved from the node when new software is
detected.
Applications in the middle of processing can cut over to new network
model files without causing any service interruption.
Dynamic updating of models occurs under the following conditions:

Each time a login to a node occurs, the software versions on the node and
the loaded model files are compared. If the software version on the node
is higher than the software version of the loaded model for that family, a
new model based on the software on the node is dynamically loaded into
shared memory.
The script fdtm.newsdd.kick has been run. Run this script as part of an
explicit management operation when you use the getsursdd script to
retrieve an SDD file from a node. Fdtm.newsdd.kick signals FDTM to
check each familys SDD files. If FDTM finds any updated SDD files,
fdtm.newsdd.kick parses the SDD files and dynamically loads the new
model into shared memory.
After dynamic updating is complete, all applications are notified to

synchronize to the new network model files. When all applications respond
that they have synchronized, the shared memory segment associated with the
old model files is released.

NN10470-305 01.02 Standard
16.2 May 2007
- 53 -
Manually generating model files

Although fps uploads model files automatically for a provisioning application,
it is sometimes necessary to generate model files manually from a tar file. For
example, if you are only using a workstation for surveillance purposes, you will
never launch a provisioning session and fps will not upload the required model
files. When this is the case, you need to generate them manually from a tar
file.
Generating the model files manually requires the use of the fmsgetmod or
getsursdd utilities provided with the Nortel Multiservice Data Manager
software.

Fmsgetmod (page 53)
Getsursdd (page 55)
Fmsgetmod
This utility extracts source files from the tar file, generates output model files,
and installs them in the /opt/MagellanNMS/cfg/PassportSchema directory on
Nortel Multiservice Data Manager disk. The tar file can be on disk, in a
directory, or on a node. If the file is on a node, the fmsgetmod utility can be
used to upload the tar file first before doing the generate and install
operations.
The fmsgetmod utility also creates model files that are used to provision the
user interface. These model files are needed only for Nortel Multiservice
Switch provisioning applications. For all other applications, use the simpler
getsursdd utility to retrieve an SDD file from a node.
The fmsgetmod utility can also be used to delete old model files. You can
delete the files with the rm command, but you need to manually determine the
correct files to delete for a given version of the model. Because the fmsgetmod
utility automatically determines the correct files to delete for a given version
and deletes them, it is the recommended method.
Attention: If you used the getsursdd utility to retrieve an SDD file from a
node, you can use the rm command to delete the SDD file. No other files are
created by getsursdd.
Use the following command to run the fmsgetmod utility:

/opt/MagellanNMS/bin/fmsgetmod
-v <version>
[-u <host userid passwd> |-s <src_dir> |-t <tarfile>]

NN10470-305 01.02 Standard
16.2 May 2007
- 54 -
[-d]
[-f]
where:
-v <version> specifies the version of the model, for example, AC0323c
-u <host userid passwd> uploads a tar file from a node, generates model
files from it, and installs them where:
host is the IP address or NIS name of the node
id is a valid user ID on the node
passwd is the valid password for the user ID
Attention: The PROV_TEMPDIR_PATH environment variable can be set to

specify the directory on the Multiservice Data Manager disk into which the
tar file is uploaded. If this variable is not set, fmsgetmod uploads the tar file
into directory /opt/MagellanNMS/data/architect_tmp. If this directory does
not exist, fmsgetmod uploads the file into directory /tmp.
-s <src_dir> generates new model files from a directory containing

existing model files. The value for src_dir is the path to the directory that
contains the existing model files.
-t <tarfile> is the full pathname of the tar file on the Multiservice Data
Manager disk or on compact disk
-d removes all model files associated with the version except the files
/opt/MagellanNMS/cfg/PassportSchema/sursdd<version>.act, and
/opt/MagellanNMS/cfg/ANP/comp/<version>/anpmdl.co, where <version> is
the version of the model, for example, AC0323C. These files are master files
from which all other models files can be generated. To remove all files,
including the master files, use the -f option at the same time.
-f removes all model files associated with the version, including the file
named sursdd<version>.act, and then regenerates the model files
If you specify the -d option, the -u, -s, and -t options are ignored.
The -u, -t, and -s options are mutually exclusive. You can only use one of
them at a time.

NN10470-305 01.02 Standard
16.2 May 2007
- 55 -
Getsursdd
If the SDD file does not already exist on the Nortel Multiservice Data Manager
workstation the getsursdd utility retrieves the specified SDD file from a node.
This utility does not create any other files, such as the model files for the
provisioning user interfaces. The fmsgetmod utility performs that function.
Use the following command to run the getsursdd utility:

/opt/MagellanNMS/bin/getsursdd -v <version>\
-u <host userid passwd>
where:
-v <version> specifies the version of the model, for example, AC0323c
-u <host userid passwd> specifies the node and valid user ID and
password from which to retrieve the SDD file
After you run the getsursdd utility, run the fdtm.newsdd.kick utility, which
signals FDTM to check the software version of each familys model files. If
FDTM finds any updated SDD files, fdtm.newsdd.kick parses the SDD files
and dynamically loads the new model files into shared memory.
You must be logged on as root to run fdtm.newsdd.kick. Use the following

command to run the utility:
/opt/MagellanNMS/bin/fdtm.newsdd.kick

NN10470-305 01.02 Standard
16.2 May 2007
Shared memory
Review this section for a description of the instructions to re-configure the
shared memory segment size in the kernel of the Solaris operating system.
Additionally, this section describes how the following applications use shared
memory:
the Network Model
Multiservice Switch Communications Manager (FDTM)
MSS Configuration Model Server (PCMS)
Navigation
Determining the requirements for shared memory (page 56)
Setting the amount of shared memory in the kernel (page 56)
Determining the requirements for shared memory

You need to configure shared memory in the kernel of the Solaris operating
system on the workstation. The amount of shared memory of the following
applications should be less than the system default of 256 Mbyte:
the amount of shared memory to support the size of the network model on
your workstation
the amount of shared memory required by Multiservice Switch
Communication Manager (FDTM) to load network models
the amount of shared memory required by MSS Configuration Model
Server (PCMS)
Setting the amount of shared memory in the kernel

Setting the amount of shared memory in the kernel involves setting the value
of variable shmysis:shminfo_shmax in the system kernel file /etc/system, then
rebooting the workstation to make the changes effective. This variable
specifies the amount of memory that an application can create as a shared
memory segment. You can create multiple such segments. Because shared
memory is swapped in and out just like the workstations virtual memory, it can
therefore can be larger than the workstations physical memory size. By
default the amount applications can create is 1 Mbyte.

NN10470-305 01.02 Standard
16.2 May 2007
- 57 -
Shared memory
If you need to increase the amount of shared memory, you can use an editor,
such as vi, to change the value of the shared memory variable in kernel file
/etc/system, but Nortel Multiservice Data Manager software provides a
convenient script for this purpose. This scripts are contained in the files /opt/
MagellanNMS/system/config/config_sys_shmem <size> and
/opt/MagellanNMS/system/config/config_sys_semaphores. These scripts
have the following advantages:
reads the amount of shared memory allocated in the kernel file, and
increases the amount only if you specify an amount greater than the
amount that is already allocated
retains a copy of the existing kernel in file /etc/system.old
If you want to decrease the amount of shared memory, you cannot use script
config_sys_shmem. You need to edit the file with a UNIX editor.
Use the procedure for Using the config_sys_shem script to configure shared
memory in Nortel Multiservice Data Manager Administration (NN10470-303)
to reconfigure the amount of shared memory using the config_sys_shem
script.

NN10470-305 01.02 Standard
16.2 May 2007
Network time synchronization
Review this section for a description of Network Time Synchronization (NTS)
for Nortel Multiservice Data Manager and an explanation of the procedures
used for setting up NTS on Multiservice Data Manager workstations.
Procedures relating to the concepts described here are located in Nortel

Multiservice Data Manager Administration (NN10470-303).
Navigation
Overview of Network Time Synchronization (NTS) (page 58)
Overview of Network Time Synchronization (NTS)

The overview contains the following sections:
What is NTS (page 58)
What a workstation can have as a time server (page 60)
What a workstation can have as a time client (page 62)
How workstations synchronize the time with everything except DPN
(page 63)
How workstations synchronize the time with DPN (page 66)
What is NTS
The Network Time Synchronization (NTS) system synchronizes the time of
day between Nortel Multiservice Data Manager workstations and network
elements, and ensures that
time clocks on workstations and network elements show a consistent time
of day
accounting records, alarms, statistics and logs bear a consistent
timestamp
NTS has nothing to do with clocking on synchronous data linksonly with

synchronizing the time of day.

NN10470-305 01.02 Standard
16.2 May 2007
- 59 -
When NTS is configured, Multiservice Data Manager workstations and

network elements form a timing hierarchy in which each device obtains its time
of day from a time source, and optionally, acts as a time source for one or more
network elements, as shown in figure A simple timing hierarchy (page 59).
As you descend the hierarchy, the precision of clocks in network elements

decreases. Devices with the most precise clocks are at the top of the
hierarchy, and devices with the least precise clocks are at the bottom of the
hierarchy.
Network elements in a timing hierarchy that provide the time to other devices
are known as time servers and those that receive the time are time clients. In
the figure A simple timing hierarchy (page 59), the Internet clock is the time
server for workstations A and B. Workstation A is a time server for the DPN
nodes and workstation B is a time server for Nortel Multiservice Switches. The
DPN nodes are time clients of workstation A and the Multiservice Switches
are time clients of workstation B. Devices containing clocks that have the
same precision are known as peers. In the figure A simple timing hierarchy
(page 59), workstations A and B are identical and have the same precision
clock; therefore, they are peers. Peers can obtain the time or provide the time
to one another.
A simple timing hierarchy
Precision
Internet
clock Most
DPN Multiservice
node Switch Least
The relationships shown in the figure A simple timing hierarchy (page 59) are
oversimplified. In a real timing hierarchy, devices are provisioned as backups.
An example of a timing hierarchy with backups is shown in the figure A timing
hierarchy with backups (page 60). In this figure, the workstations use an

NN10470-305 01.02 Standard
16.2 May 2007
- 60 -
Internet clock as a time server. If workstation A fails, primary backup

workstation B provides the time to the DPN and Multiservice Switches. If
workstations A and B both fail, secondary backup workstation C provides the
time to them. Many other backup arrangements are also possible.
A timing hierarchy with backups
Internet
clock
Workstation B Workstation C
Workstation A
(Primary backup) (Secondary backup)
DPN Multiservice
node Switch
primary timing path

backup timing paths
Timing relationships are complex, especially in large networks with many

backups. Before you can configure NTS on a Nortel Multiservice Data
Manager workstation, ensure that you understand the possible timing
arrangements between workstations and other devices in the network. These
arrangements are described in the following sections.
What a workstation can have as a time server

A Nortel Multiservice Data Manager workstation can use several time sources
as a time server to set the time of day on its internal clock. These sources are
shown in the figure, What a workstation can use as a time server (page 62).

NN10470-305 01.02 Standard
16.2 May 2007
- 61 -
In the most basic arrangement, the workstation uses its own internal clock as
a time server. The internal clock is the easiest time source to define because
it requires no IP connections to an external clock, and no expensive
equipment hardware such as a radio clock. The drawbacks to using the
internal clock are as follows:
the internal clock is relatively inaccurate compared with other types of time
sources
each time you wish to update the time you must manually enter the UNIX
date command
updating the time requires frequent and consistent monitoring and
intervention by a human operator
Other more precise possibilities include

a precise timing device that is connected directly to the workstation, such
as a radio clock
A radio clock is designed to receive time signals broadcast from a radio
transmitter that uses a national time standard clock, such as an atomic
clock, as its time reference.
a clock that is accessible through the Internet
The Internet contains a number of primary time servers that are
synchronized to national time standard clocks by wire links or radio links.
These primary time servers are also connected to one or more secondary
time servers throughout the Internet and are kept in sync with the primary
time servers by XNTP software that runs on the time servers. You can
access a primary or a secondary Internet server and use it as the time
source for your network.
the clock in another workstation
You can do this when your network contains several workstations and one
of them is connected to an accurate time source, such as a radio clock.
a DPN operations agent (OA)
In an existing DPN-100 network, the OAs may already be configured so
that they synchronize with an accurate clock, such as a radio clock or an
atomic clock. In such a situation, you can use an OA as a time source.
Because the time on all DPN OAs is kept in sync by the Top DPN OA, any
OA can be used as the time source.
You can configure the Multiservice Data Manager workstation to access more
than one time source to provide backup. However, when you use a DPN OA
as a time source, do not configure any other time source for the workstation.
If you do, the cron job used to synchronize the workstation to the DPN OA, and

NN10470-305 01.02 Standard
16.2 May 2007
- 62 -
the XNTP software used to synchronize the workstation to the other time
sources will both attempt to reset the workstations time. This will lead to
timing conflicts and fluctuations.
What a workstation can use as a time server
Internet Precise
clock timing
device
MDM MDM
workstation workstation
InterNet
Internal
clock
OA
OA OA
DPN nodes
What a workstation can have as a time client

A Nortel Multiservice Data Manager workstation can act as a time server for
the following time clients:
another workstation
When your network contains several workstations, you may want to have
one workstation act as a time server for other workstations.
the TopOA for Network Control System (NCS) that runs on the DPN nodes
in your network
In some networks, the workstations may have access to a time server that
is more precise than any of the existing time sources for the DPN nodes.
In this situation, you can configure the workstation to provide the time to
the Top OA. Because the Top OA synchronizes the time on all DPN OAs,
all DPN nodes will synchronize their time to the workstation.
The workstation can only provide the time to the DPN nodes or obtain the
time from them, it cannot do both.
Nortel Multiservice Switches in your network. Multiservice Data Manager
workstations are the preferred time servers for these nodes. If your

NN10470-305 01.02 Standard
16.2 May 2007
- 63 -
network contains Multiservice Switches, you should configure at least one

of the workstations to act as their time server.
What a workstation can have as a time client
workstation workstation
Multiservice
Switches
OA
OA OA
DPN nodes
A Multiservice Data Manager workstation can only provide the time to DPN
nodes or obtain the time from them.
If your network contains any Multiservice Switches, at least one workstation

must have XNTP software running on it so that it can act as a time server for
the nodes.
How workstations synchronize the time with everything except DPN

To synchronize the time on Nortel Multiservice Data Manager workstations,
Nortel Multiservice Switches, and external clocks such as an Internet clock,
NTS uses XNTP software installed on each of these devices.
What is XNTP
XNTP is an Internet Standard Recommended Protocol that is built on two
protocols: the Internet Protocol (IP) and the User Datagram Protocol (UDP).
Although it was developed for synchronizing and distributing the time
throughout the Internet, XNTP can be used to synchronize and distribute the
time among most network elements that are connected by an IP link. Internet
clocks, Nortel Multiservice Data Manager workstations, and Multiservice
Switches support IP and can run XNTP. As a result, XNTP can be used to
synchronize and distribute the time among these devices.

NN10470-305 01.02 Standard
16.2 May 2007
- 64 -
Attention: Because workstations use X.25 to communicate with DPN

nodes, a means other than XNTP must be used to synchronize the time on
workstations with DPN nodes. This task is performed by the syncToDPNtime,
syncDPNtime, and syncDPNtime.backup programs described in How
workstations synchronize the time with DPN (page 66).
XNTP and the Internet

The Internet contains a number of primary time servers that are synchronized
to national time standard clocks by wire links or radio links. These primary
time servers are connected to one or more secondary time servers throughout
the Internet and are kept synchronized to the primary time servers using
XNTP. You can configure XNTP on a workstation to access a primary or a
secondary Internet server and use it as the time source for the Nortel
Multiservice Data Manager workstations and Nortel Multiservice Switches in
your network.
With XNTP, the Internet time servers calculate clock offset and delay between
them using timestamps with a resolution of 200 picoseconds that are
exchanged at intervals of up to 1000 seconds.
For a detailed description of XNTP, see Mills, David L. RFC-1305 Network

Time Protocol (Version 3) Specification and Implementation, University of
Delaware, 1992.
XNTP, workstations, and Multiservice Switches

XNTP installed on Nortel Multiservice Data Manager workstations and Nortel
Multiservice Switches runs as an XNTP subnetwork. Once configured, XNTP
performs the following functions:
Automatically select the time server with the most precise clock (lowest
stratum number) available from a pool of time servers that are configured
on the workstation.
If the time server fails, the XNTP software automatically selects the next
most precise time source until it runs out of time sources. Then it uses the
workstations internal clock as a time source.
If a local clock is configured as a time source along with other time
sources, XNTP always uses the workstations internal clock as the time
server of last resort, regardless of its precision relative to the other time
sources.
Keep the time synchronized to the device that XNTP selects as the current
time server.
To determine which timer server to use, XNTP software dynamically assigns

a stratum number to the device on which it is running. The stratum number
indicates the relative accuracy of the clock compared with the clocks on other

NN10470-305 01.02 Standard
16.2 May 2007
- 65 -
time servers available. The stratum number ranges from 0 for very precise
clocks, such as atomic clocks, to 15 for the least precise clocks. For any given
device in a network XNTP dynamically calculates the stratum number of the
devices clock to be a lower value than that of its time server because the
server is higher up the timing hierarchy. When XNTP chooses a device to use
as a time source, it selects the device with the lowest stratum number first,
then the next lowest, and so on, until it runs out of configured devices.
To configure XNTP on a Nortel Multiservice Data Manager workstation, refer

to the manual page for XNTPD (man xntpd).
XNTP and Multiservice Switches

Nortel Multiservice Switches can obtain the time from Nortel Multiservice Data
Manager workstations, or other time servers. To obtain the time from a
workstation, the nodes must be connected to at least one workstation with
XNTP configured. The network elements retrieve the time by polling all
configured time servers or, if no time servers are configured, all workstations
to which an FMIP connection running over IP exists and determining the best
time server to use according to the clock selection algorithm detailed in XNTP
specification RFC-1305 Network Time Protocol (Version 3) Specification and
Implementation, University of Delaware, 1992. The network elements cannot
synchronize the time to each other using XNTP, they can only obtain it from a
Multiservice Data Manager workstation or other time servers.
With Multiservice Switch, you can add a provisionable server subcomponent

under the time component. Provision the IP address of the source you want
the node to synchronize to. The source is usually the workstation. You can
also indicate the connection method to this source. The connection choices
are as follows:
vrlp (virtual router, used with Ethernet connectivity)
ipiFrIPiVc, which is used if the workstation is connected by ipiFR or ipiVC.
If you are using ipiFR, the Frame Relay daemon must be running on the
workstation. To check this, enter the command at the UNIX prompt:
ps -ef | grep frd

The times on the node and the syncSource must be within 1000 seconds of
each other before the node will synchronize to another source. If the two are
not within 1000 seconds of each other, lock the time server component and
then set the module time on the node to be within 1000 seconds of the source.
The time component must be locked because the node will continue to
synchronize and you cannot independently set the time on the node unless
the component syncStatus is unsynchronized.

NN10470-305 01.02 Standard
16.2 May 2007
- 66 -
How workstations synchronize the time with DPN

Because DPN nodes have no direct access to XNTP (no IP connection for
network management purposes), the time on a Nortel Multiservice Data
Manager workstation and the time in a DPN network must be exchanged by
means of programs that are run by a cron job on each workstation. The
programs, called syncDPNtime, syncDPNtime.backup, and syncToDPNtime,
are provided with Nortel Multiservice Data Manager software.
The workstations can either obtain the time from the DPN nodes or provide
the time to them.
Providing the time to DPN nodes

On each Nortel Multiservice Data Manager workstation that provides the time
to DPN nodes and maintains time synchronization, you must schedule a cron
job to run one of two programs: syncDPNtime or syncDPNtime.backup.
If you have more than one workstation in your network, choose one of them
as the primary time server for the DPN nodes, a second as backup time
server, and a third (if available) as a secondary backup time server. If you have
only one workstation, choose it as the primary time server.
On the MDM workstation you choose as the primary time server, schedule the
cron job to run the syncDPNtime program as shown in the figure Programs to
run to provide the time to DPN (page 67). On the workstations that are the
backup and secondary backup time servers, schedule the cron job to run the
syncDPNtime.backup program.
These two programs establish a connection to the DPN Top OA and send the
workstation time. The Top OA provides the time of all other DPN OAs and
synchronizes them to that time. The difference between the two programs is
that the syncDPNtime.backup also monitors other workstations that are acting
as time servers for DPN to determine if it should provide the time to the Top
OA.
To set up a workstation to provide the time to DPN, see the section on

Synchronizing the network time in Nortel Multiservice Data Manager

NN10470-305 01.02 Standard
16.2 May 2007
- 67 -
Programs to run to provide the time to DPN
syncDPNtime syncDPNtime.backup syncDPNtime.backup
Backup Secondary
Primary
time backup
time
server time
server
server
Top OA
OA OA
DPN nodes
Obtaining the time from DPN nodes

On each Nortel Multiservice Data Manager workstation that obtains the time
from DPN nodes and maintains time synchronization, schedule a regular cron
job to run the syncToDPNtime program.
Schedule the cron job to run the syncToDPNtime program on each of the
workstations obtaining the time from DPN, regardless of whether the
workstation is a primary, backup, or secondary backup time server for your
network. See the figure Program to run to obtain the time from DPN (page 68).
The function of this program is to set up a connection to a DPN Operations

Agent (OA), get the DPN time, and set the time of the internal clock on the
workstation.
To set up a workstation to obtain the time from DPN, see the section on
Synchronizing the network time in Nortel Multiservice Data Manager

NN10470-305 01.02 Standard
16.2 May 2007
- 68 -
Program to run to obtain the time from DPN
syncToDPNtime syncToDPNtime syncToDPNtime
Secondary
Primary Backup
backup
time time
time
server server
server
OA
OA OA
DPN nodes

NN10470-305 01.02 Standard
16.2 May 2007
Maximum heap size
Review this section for a description of the instructions used to configure the
maximum heap size for a shared Java virtual machine (JVM) and for all
Operator Client applications. Shared JVM is a single Java virtual machine that
is shared by a number of applications.

Navigation
About the maximum heap size (page 69)
The default /opt/MagellanNMS/lib/cfg/SharedJVM.cfg configuration file
(page 70)
Monitoring the maximum heap size (page 70)
About the maximum heap size

Heap size is the dynamic allocation of memory allowed for running Java
processes. The following applications can be run simultaneously using one
shared JVM process:
Data Viewer
Shelf View
Nodal Provisioning
Embedded Nodal Provisioning (ENP)
Nodal Provisioning Template Editor
Service Selection
Operational Command
Log Browser

NN10470-305 01.02 Standard
16.2 May 2007
- 70 -
Maximum heap size
The default /opt/MagellanNMS/lib/cfg/SharedJVM.cfg configuration

file
The maximum heap size is defined in the default configuration file
/opt/MagellanNMS/lib/cfg/SharedJVM.cfg. You can make a copy of this file in
the directory /opt/MagellanNMS/cfg/ and use it as a template to create a new
file with custom settings. See the procedure for changing the maximum heap
size for Nortel Multiservice Data Manager Toolset in Nortel Multiservice Data
Manager Administration (NN10470-303).
The minimum heap size is 20M. The default for maximum heap size is 128M.
The default of 128M allows a user to run the following:
one instance of Nodal Provisioning
one instance of Shelf View with ENP
two instances of Data Viewer with default parameters, or one instance of
Data Viewer replaying a BDF file of about 10M in size.
For Operator Client applications, the default value is 256M.
File format
The /opt/MagellanNMS/lib/cfg/SharedJVM.cfg file consists of the following
syntax:
MAXHEAPSIZE <size in megabytes>
where:
MAXHEAPSIZE is the maximum allocation of dynamic memory (heap) for

running simultaneous applications in a shared JVM and Operator Client.
<size in megabytes> is the maximum number of megabytes allocated for the

heap.
Example
The following example demonstrates the file format:
MAXHEAPSIZE 128
Monitoring the maximum heap size

The maximum heap size is monitored to ensure that the shared JVM or
Operator Client applications do not run out of heap space. The heap size is
monitored every 60 seconds. The criteria used to monitor the heap size is:
Maximum heap size minus Currently used heap size < 20M

NN10470-305 01.02 Standard
16.2 May 2007
- 71 -
Maximum heap size
Memory usage warning dialog

A pop-up dialog opens whenever the currently-used heap size reaches 20M
less than the maximum heap size configured. The dialog informs the user that
system resources (heap size) are running low, and some applications must be
closed.
If the dialog is displayed frequently, it indicates that the shared JVM or

Operator Client application is not configured with the appropriate maximum
heap size. It is recommend that the maximum heap size be increased. See the
procedures for changing the maximum heap size for Multiservice Data
Manager Toolset in Nortel Multiservice Data Manager Administration
(NN10470-303).

NN10470-305 01.02 Standard
16.2 May 2007
Multiservice Data Manager server
maintenance fundamentals overview
Use the topics listed in this section to support the procedures used to maintain
Nortel Multiservice Data Manager (MDM) servers.
The information in this section is directly related to procedures located in

Nortel Multiservice Data Manager Administration (NN10470-303). The
administrative tools referred to in several of the topics listed below are
described in Nortel Multiservice Data Manager AdministrationTools
(NN10470-300). Reference information about specific servers is located in
(NN10470-310).
Navigation
(page 73)
Workstation surveillance (page 75)
Multinodal Naming Service domains (page 78)
Multinodal Naming Service TCP/UDP port mappings (page 82)
Network access data mediation (page 84)
Multiservice Switch alarm clearing and storage (page 94)

NN10470-305 01.02 Standard
16.2 May 2007
Server alarm distribution and
workstation status probing
configuration
Set up server alarm distribution and workstation status probing to:
provide workstation server alarms to other workstations through a GMDR
server
provide workstation server alarms to the Network Control system (NCS)
that runs on the DPN nodes in your network
set up the NCS so that it probes the workstation to determine the
workstations status.
For a first time installation, you can use the procedures in Nortel Multiservice
Data Manager Administration (NN10470-303) to set up server alarm
distribution and workstation status probing, or you can use the Nortel
Multiservice Data Manager Software Configuration tool, as described in
Nortel Multiservice Data Manager Installation and CommissioningSoftware
(NN10470-100).

Navigation
About server alarm distribution and workstation status probing (page 73)
About server alarm distribution and workstation status probing

There are two ways in which you can configure a workstation to distribute
alarms and status changes from its Nortel Multiservice Data Manager servers
to other workstations in the network.
You can configure the workstation to distribute them to a GMDR server that
runs on the workstation, or that runs on another workstation. By setting up a
hierarchy of GMDR servers on the workstations in your network, it is possible
to forward the workstations alarms and status changes to some, or to all of
the workstations in your network. For a detailed description of how server

NN10470-305 01.02 Standard
16.2 May 2007
- 74 -
alarms and status changes are propagated through GMDR, see Nortel
Multiservice Data Manager AdministrationServer Management
(NN10470-310).
You can also configure the workstation to distribute server alarms and status
changes to the NCS that runs on the DPN nodes in your network by
forwarding them to an OA in the NCS over an X.25 link. The X.25 link connects
to a Control Device Manager on the OA. The NCS propagates these alarms
and status changes throughout the OAs on all DPN modules in the network.
Any workstation that is configured to obtain surveillance information from the
NCS receives these alarms and status changes and can display them. For a
detailed description of how server alarms and status changes are propagated
through NCS, see Nortel Multiservice Data Manager AdministrationServer
Management (NN10470-310). This method of alarm distribution only applies
to networks that contain DPN nodes.
When setting up a connection to an OA to allow the workstation to have its

server alarms and status changes distributed throughout network, it is also
possible to specify a probing interval that is sent to the NCS in the data
packets used to set up the connection over the X.25 link. The NCS uses the
probing interval information to poll the workstation at regular intervals. After
every poll, the NCS waits for an acknowledgment. If the NCS does not receive
an acknowledgment, it creates a workstation alarm and propagates this alarm
throughout the OAs in the NCS. Any workstation that is configured to obtain
surveillance information from the NCS receives this alarm and can display it.
For a detailed description of how server alarms and status changes are
propagated using NCS, see Nortel Multiservice Data Manager
AdministrationServer Management (NN10470-310).

NN10470-305 01.02 Standard
16.2 May 2007
Workstation surveillance
Review the material in this section for an explanation of configuration
thresholds and logs output for workstation surveillance.

Navigation
Threshold configuration (page 75)
Threshold configuration
The configuration file lets you customize the thresholds at which workstation
surveillance generates alarms. You can also set the time interval at which the
workstation polls its managed components. The configuration file also
includes information on component-assigned fault codes. To change
configuration parameters, run the /opt/MagellanNMS/bin/sfm_config script to
create this file: /opt/MagellanNMS/cfg/SFM.cfg
You can edit the parameters in this file using any text editor. Prior to
undertaking each poll, workstation surveillance reads the configuration
parameters from this file. Only future alarms are affected; previous alarms are
not affected.
The Server Administration tool requires the following entry to enable

workstation monitoring: /opt/MagellanNMS/bin/sfm
For information on the logs generated by the Server Administration tool, see
Nortel Multiservice Data Manager AdministrationTools (NN10470-300). For
information on alarms generated by this tool, see Nortel Multiservice Data
Manager Alarms Reference (NN10470-501).
When editing the SFM.cfg file, take the following points into consideration:
you can edit and save this file while the scripts are running
when defining numerical values, include only the number; do not add units

NN10470-305 01.02 Standard
16.2 May 2007
- 76 -
for any resource, the value for the minor alarm must be lower than the
value for the major alarm; the value for the major alarm must be lower than
the value for the critical alarm
always includes at least one space between the parameter name and the
configurable value
The table Configurable workstation surveillance parameters (page 76)

identifies the configurable parameters and the default values.
Configurable workstation surveillance parameters
Configurable Default Description

parameter value
Interval 600 Interval defines the polling interval in seconds. The range is 10-
86400 seconds.
CPU_Sampling 300 CPU_Sampling defines the sampling duration used to determine
the CPU usage. The range is 10-86400 seconds.
CPU_Load_Minor 70 CPU_Load_Minor, CPU_Load_Major, and CPU_Load_Critical
define the threshold for minor, major, and critical CPU alarms in
CPU_Load_Major 80
terms of percentage of CPU resource used. The range is 1 to 100.
CPU_Load_Critical 90
FS_Minor 80 FS_Load_Minor, FS_Load_Major, and FS_Load_Critical define
the threshold for minor, major, and critical disk alarms in terms of
FS_Major 90
percentage of disk resource used. The range is 1 to 100.
FS_Critical 95
Mem_Minor 80 Mem_Load_Minor, Mem_Load_Major, and Mem_Load_Critical
define the threshold for minor, major, and critical memory alarms
Mem_Major 90
in terms of percentage of memory resource used. The range is 1 to
Mem_Critical 95 100.
Remote_Connection Remote_Connection defines the IP addresses/host names of peer
devices. Workstation surveillance periodically checks the
connectivity with the IP addresses/host names assigned to the
parameter. If you add a description for the managed IP addresses/
host names, it will appear in the alarm when the device is
unreachable. The description should be separated from the IP
address/hostname field by at least one space. This connection
supports multiple field input, letting you manage more than one
device. For example:
Remote_Connection 1.2.3.4 Passport 15K
Remote_Connection MDM2 MDM mate
(1 of 2)

NN10470-305 01.02 Standard
16.2 May 2007
- 77 -
Configurable workstation surveillance parameters (continued)
Configurable Default Description

parameter value
Local_Port_Connection Local_Port_Connection defines the IP addresses/host names of
the local port that you want to manage. SFM periodically checks
the connectivity with the IP addresses/host names assigned to the
parameter. If you add a description for the managed IP addresses/
host names, it will appear in the alarm when the device is
unreachable. The description should be separated from the IP
address/hostname field by at least one space. This connection
supports multiple field input, letting you manage more than one
device. For example:
Local_Port_Connection 4.3.2.1 hmeo port to lan
Local_Port_Connection mdmpriv qfe1 port to privatenet
Manage_FS Manage_FS defines which file systems that workstation
surveillance monitors. Separate multiple file system entries with at
least one space.
(2 of 2)

NN10470-305 01.02 Standard
16.2 May 2007
Multinodal Naming Service domains
You must set up MNS domains before you can use the Service Selection tool.
See Nortel Multiservice Data Manager AdministrationTools (NN10470-300)
for a description of the tool and instruction in its use.
Skip this chapter if your Nortel Multiservice Data Manager workstations are
not located on a LAN, if your network only contains standalone workstations,
or if you are not planning to use the Service Selection tool.

Navigation
What MNS domains are used for (page 78)
Guidelines for setting up level 2 MNSD domains (page 80)
What MNS domains are used for

To manage medium and large networks, several workstations running Nortel
Multiservice Data Manager software can be deployed on the same Ethernet
LAN. In these networks, Multiservice Data Manager software can be deployed
in a server-client fashion among the workstations on the LAN.
The server workstations can be configured to run sets of Multiservice Data

Manager processes called servers, which support the following main areas of
service: surveillance, support for the Network Model tool, provisioning, and
network access (access to the network elements). Workstations configured to
run these servers are referred to as Server Set workstations.
The client workstations can be configured to run just the servers that support
user sessions and provide access to Multiservice Data Manager tools.
Workstations configured to run these servers are referred to as Client Set
workstations.To perform their functions, the servers on the Client Set
workstations rely on the services provided by the servers on the Server Set
workstations.

NN10470-305 01.02 Standard
16.2 May 2007
- 79 -
To allow processes on the same workstation and on different workstations to

share services, the processes must be able to locate one another. The Multi-
nodal Naming Service (MNS) makes this possible by providing a place for
processes to register and obtain the information needed to locate one
another. MNS provides a two-level service as follows:
It provides a level 1 service that allows processes on the same local
workstation to locate one another. To allow processes on the same
workstation to locate one another, a workstation must be running a level 1
MNSD process. Every workstation on the LAN must be running this
process.
It provides a level 2 service that allows processes on different workstations
to locate one another. To allow processes on different workstations to
locate one another, at least one of the workstations must be running a
level 2 MNSD process. This process provides access to the process
identifiers, hostnames, and IP addresses of all workstations that run
processes which must be able to interact.
A group of Server Set and Client Set workstations that run processes that
interact is referred to as a level 2 MNSD domain. You are not limited to just
one level 2 MNSD domain on a LAN. For networks that are being managed by
a number of workstations, you can define two or more level 2 MNSD domains,
each with its own set of workstations running processes that interact. For a
sample MNS configuration containing two level 2 MNSD domains see the
figure A sample MNS configuration of 2 MNS domains (page 80).
To provide redundancy, you can configure more than one workstation in a level
2 MNSD domain to run the level 2 MNSD process, as shown in the figure A
sample MNS configuration of 2 MNS domains (page 80). With more than one
workstation running a level 2 MNSD process, the servers on a workstation
have an alternate place to find the location of servers on other workstations in
the domain, in case of failure. In the sample configuration shown in the figure
A sample MNS configuration of 2 MNS domains (page 80), the servers
running on workstations in Domain 1 can select the MNSD level 2 process on
hosts A, B or C.
You can set up a workstation so it belongs to more than one level 2 MNSD
domain. In the figure A sample MNS configuration of 2 MNS domains
(page 80), workstation Host D belongs to two domains: Domain 1 and
Domain 2.
No work is required to set up a level 1 MNSD process on a workstation. This

process starts automatically at boot time. You must start a level 2 MNSD
process manually from command, or with the Server Administration tool.

NN10470-305 01.02 Standard
16.2 May 2007
- 80 -
A sample MNS configuration of 2 MNS domains
Domain 1
HostA HostB HostC
MNSD MNSD
level 2 level 2
process process
MNSD MNSD MNSD

level 1 level 1 level 1
process process process
Other Other Other

processes processes processes
Domain 2
HostD HostE HostF
MNSD
level 2
process
MNSD MNSD MNSD

level 1 level 1 level 1
process process process
Other Other Other

processes processes processes
Guidelines for setting up level 2 MNSD domains

Determining the number of level 2 MNSD domains to set up on a LAN
depends the number of workstations on the LAN and how you wish to
organize the workstations for managing your network.
Two main ways for organizing level 2 MNSD domains are possible. You can
choose to set up level 2 MNSD domains to manage the network on a
functional basis (specialization). For example, you can set up one domain that
contains workstations dedicated to provisioning, and another that contains
workstations dedicated to network access. Alternatively, you can choose to

NN10470-305 01.02 Standard
16.2 May 2007
- 81 -
set up level 2 MNSD domains on a regional basis. For example, you can
dedicate one domain that contains workstations for managing the eastern part
of your network, and another that contains workstations for managing the
western part.
Guidelines for setting up level 2 MNSD domains are as follows:

If you have more than one workstation on a LAN, and the workstations are
to share tools and servers (they are not standalone), you must configure
are least one level 2 MNSD domain on the LAN.
Attention: You can configure more than one level 2 MNSD domain.
For redundancy, consider running a level 2 MNSD process on more than

one workstation in a level 2 MNSD domain. To provide the most
redundancy possible, we recommend that you run a level 2 MNSD
process on every Server Set workstation in a level 2 MNSD domain.
You can configure a workstation to belong to more than one level 2 MNSD
domain. This is useful if you wish to use workstation to manage different
regions, or to use a service that is only available in a different level 2
MNSD domain.
To minimize the impact on workstation performance, we recommend that
you do not configure a workstation to belong to more than two level 2
MNSD domains.

NN10470-305 01.02 Standard
16.2 May 2007
Multinodal Naming Service TCP/UDP
port mappings
Configure Multipnodal Naming Service TCP/UDP port mappings to allow
Nortel Multiservice Data Manager processes to locate and talk to each other.

Navigation
Mapping service names to TCP/UDP port numbers (page 82)
Configuring TCP/UDP port numbers (page 82)
Mapping service names to TCP/UDP port numbers

Nortel Multiservice Data Manager uses the MNSD server to store the
mappings of service names to TCP/UDP port numbers. These port number
mappings allow Multiservice Data Manager processes to locate and talk to
each other. Normally, the operating system selects the actual TCP/UDP port
number allocated (bound) by a Multiservice Data Manager server for a
service. As a result, the TCP/UDP port number can change each time the
server restarts (generally, the service name does not change).
Dynamic port assignment is desirable because Multiservice Data Manager

relies on a large number of dynamic processes to provide its services.
Otherwise, it would be difficult to statically assign the TCP/UDP port numbers
in advance in a fail-safe manner. Dynamic port assignment makes it
impossible to deploy Multiservice Data Manager servers and clients across a
communication firewall.
Configuring TCP/UDP port numbers

To allow deployment across a communication firewall, Nortel Multiservice
Data Manager provides the following two methods to predetermine the TCP/
UDP port numbers for use by Multiservice Data Manager processes.
Configure a range of TCP/UDP port numbers that Multiservice Data
Manager processes will be allowed to bind.

NN10470-305 01.02 Standard
16.2 May 2007
- 83 -
Multinodal Naming Service TCP/UDP port mappings
Configure the TCP/UDP port numbers that a specific Multiservice Data

Manager server will be allowed to bind.
For procedures on configuring TCP/UDP port mappings, see Nortel

Multiservice Data Manager AdministrationServer Management
(NN10470-310).
Services used specifically by Operator Client are documented in Nortel

Multiservice Data Manager Network SecuritySecure Communications
(NN10470-607).

NN10470-305 01.02 Standard
16.2 May 2007
Network access data mediation
Configure the Network Data Access Mediation server (NDAM) for the
following purposes:
to provide clients such as HP OpenView NNM desktop with access to
Multiservice Data Manager surveillance information
to perform filtering according to component type or geographic region for
the HP OpenView NNM desktop and Fault tools
The NDAM server is mandatory for the deploying HP OpenView NNM

desktop. For Fault clients, the NDAM server provides an optional capability
that is described in this chapter.
Navigation
Purpose of network data access mediation (page 84)
NDAM deployment and configuration strategies (page 89)
NDAM authentication configuration (page 91)
NDAM filterset file configuration (page 92)
Purpose of network data access mediation

The Fault servers collect, interpret, and concentrate the management data
from the network. If you are not familiar with the Fault servers, and how to
configure them, see the following sections:
For networks that contain DPN equipment, see Nortel Multiservice Data
For networks that contain Nortel Multiservice Switch 7400/15000/20000
equipment, see Nortel Multiservice Data Manager Administration
(NN10470-303).
The Fault clients (Alarm Display, Component Information Viewer) can access
the information collected by Nortel Multiservice Data Manager data collection
servers from the Global Management Data Router (GMDR) server and the
Network Model (NMSERVER) server. This information can be forwarded to
the clients such as HP OpenView NNM desktop.

NN10470-305 01.02 Standard
16.2 May 2007
- 85 -
If all of the information were made available to a client, users would be

subjected to huge amounts of information and not all of it would be useful to
perform their jobs. A way of limiting the amount of data forwarded to these
clients is required. Fault supports a number of ways to reduce the information
forwarded to clients (or to hierarchical GMDR servers):
through Component Criticality Thresholds. To configure these thresholds:
specify thresholds when setting up hierarchical GMDR servers
supply parameters in the startup command for the SURNUP server.
See Nortel Multiservice Data Manager AdministrationServer
Management (NN10470-310) and Nortel Multiservice Data Manager
AdministrationTools (NN10470-300) for more information.
through component type and regional filtering performed by an NDAM
server

NN10470-305 01.02 Standard
16.2 May 2007
- 86 -
Use of component criticality-based filtering for regional-central network management
Fault
tools/API
The superior GMDR

server specifies a GMDR
criticality threshold when
it connects to a
subordinate GMDR The subordinate GMDR
server. server only forwards
major component
information (greater than
the criticality threshold).
Fault Fault
tools/API tools/API
GMDR GMDR
Network Region B
Network Region A
Data
Component Criticality Filtered Data
Servers that you must configure manually
Regional Operations Center
Central Operations Center
Component criticality thresholds

A subordinate GMDR server assigns a criticality value to all components it
manages. When a superior GMDR server connects to a subordinate GMDR
server, it can supply a component criticality threshold value. The subordinate
GMDR only provides management data for components whose faults pass a
threshold test. With thresholding, it is possible to deploy regional management
centers that have full view of their managed devices and central management
centers (fed from the regional GMDRs) that can see all devices in the network,
but only get information for the most important sub-components as controlled
by the criticality threshold. See the figure Use of component criticality-based
filtering for regional-central network management (page 86). You can

NN10470-305 01.02 Standard
16.2 May 2007
- 87 -
customize the component criticality assignments by modifying the GMDR

criticality schema and by adding exceptional mappings to its criticality
overrides configuration file (/opt/MagellanNMS/cfg/GMDRCritOverrides.cfg).
Component type and regional filtering

Component Type filtering lets you specify the type of module, subcomponent,
and link types for which a client can receive management data. Regional
filtering lets you subdivide the network into different regions and only supply a
client with information from the devices in a region. The network data access
mediation capabilities of the NDAM server provides these two forms of
filtering. You can set up filtering in two ways:
for HP OpenView NNM desktop, by specifying a list of type and device
filtersets and individual overrides at connection time
for Nortel Multiservice Data Manager Fault clients, by forced
authentication and filtering
The NDAM server can be deployed as a superior GMDR server, a subordinate

GMDR server, or as a proxy GMDR server (in place of a GMDR server).
For HP OpenView NNM desktop clients, the NDAM server provides combined
access to the GMDR database and Network Model information. For
Multiservice Data Manager Fault clients, the NDAM server provides access to
the GMDR servers information only.
NDAM therefore supports all the capabilities of GMDR plus the filtering
described previously. NDAM is therefore always associated with a single
GMDR server and its clients. Unlike GMDR, NDAM does not store information
in a memory database. It passes through all queries to its assigned GMDR
and Network Model servers, and filters the replies according to the filtersets
associated with the client connections.
NDAM also uses a single notification stream from the GMDR and Network
Model servers, filters it and multiplexes it for NDAM clients. For example, the
NDAM server receives an alarm only once from GMDR but can forward the
alarm to many clients. An important fact is that NDAM supports Component
Criticality Filtering just like GMDR so it is possible to combine both forms of
filtering. This lets you do such things as divide the network into a number of
regions, one of which represents the network backbone. You can then access
data for each region with different Criticality Thresholds as follows:
connectivity information from the backbone
full regional information for the regional centers
hardware and connectivity information from the regions
full backbone information for the central operations center

NN10470-305 01.02 Standard
16.2 May 2007
- 88 -
For an example, see the figure Example of component criticality-based

filtering for regional-central network management (page 88).
NDAM also supports service name aliasing to allow a single NDAM server to
act as multiple subordinates to the same GMDR server, each connection with
a different filterset and criticality threshold mapping.
Example of component criticality-based filtering for regional-central network management
Fault Fault
tools/API tools/API
GMDR GMDR
Forwards all Forwards all

data for region Fault data for region
tools/API
Single notification Forwards
stream for all Component
aliased NDAM Criticality filtered
A NDAM B
(GMDR)
GMDR
Network Core
Network Region B
Network Region A
Data
Component Criticality/Device/Type Filtered Data
Servers that you must configure manually
NDAM server acting as a proxy-GMDR
Aliased NDAM Services
Regional Operations Center
Central Operations Center

NN10470-305 01.02 Standard
16.2 May 2007
- 89 -
NDAM deployment and configuration strategies

To deploy NDAM for HP OpenView NNM desktop clients, you need to start the
NDAM server with the GMDR server option (-g) and the Network Model option
(-m). If multiple NDAM servers need to run on the same workstation, you can
configure multiple NDAM servers, but you must assign each one a separate
service name by means of the -n option.
NDAM does not automatically prefix the provided alternate name as GMDR
does. This allows NDAM to act as a proxy for GMDR. If you want the service
name to include an NDAM_ prefix, you must include it in the value for the -n
option. In this deployment it is atypical to start NDAM with the forced
authentication (no -s) option.
For Fault deployment, NDAM can be configured in two ways:

as a subordinate GMDR server
as a proxy server for GMDR
Subordinate GMDR server

When used with a subordinate GMDR server, the NDAM server acts as the
intermediary for two hierarchical GMDRs. See the figure Deployment of
NDAM between GMDR servers (page 89). A superior GMDR server obtains
information from a subordinate GMDR possibly on a remote workstation, and
the subordinate GMDR server is capped by an NDAM server which is
configured as a sub-server to the superior GMDR server.
Deployment of NDAM between GMDR servers
Client
GMDR server
NDAM server
Subordinate
GMDR server

NN10470-305 01.02 Standard
16.2 May 2007
- 90 -
This allows the superior GMDR server to gather information that is filtered
according to region or according to component type from subordinate GMDRs
and provide it to its clients (Fault tools, SURNUP servers, API and EPI clients
and GMDR Administration tool).
In this configuration, you must start the NDAM server with the following
options:
GMDR option (-g)
-m option with a value of ~. The quotation marks are mandatory. The
-m~ value specifies that no network model information is involved.
-s option to set up forced authentication
You cannot configure the NDAM authentication information on the superior

GMDR to specify the Filtersets explicitly. You must assign them implicitly
through the authentication mechanism.
If the NDAM server needs to be configured as a subordinate to the same

superior, GMDR server with the goal of extracting different Filterset/Criticality
Threshold filtering combinations from the same GMDR server, you must
specify multiple service name aliases with the -a option and each alias must
include a prefix of GMDR_.
To use NDAM as a GMDR replacement, a similar configuration applies; You

need to start the NDAM server with the following options:
-g (GMDR) option
-m ~ option to disable the Network Model.
-s option to enable the forced authentication mode. The forced
authentication configuration must include a password-less wildcard entry.
This is necessary because the Fault tools all access the GMDR server
named GMDR by default, and lack the means of specifying explicit
authentication information when connecting to it.
-n option to specify the service name of NDAM server as GMDR
In this mode, NDAM does not support the GMDR Administration Interface.
The GMDR Administration tool must be connected directly to the real GMDR
server used by NDAM. Similarly, NDAM used as a proxy-GMDR does not
support the Inbound API capabilities of the Alarm and Status API. To inject
alarms, you must connect directly to the underlying GMDR server. Finally, the
Alarm and Status API repFilter, repInfo, repScope, repOClass, and repOid
sieve attributes are not available because NDAM does not have an object
model of its own to which these filters can be applied.

NN10470-305 01.02 Standard
16.2 May 2007
- 91 -
NDAM authentication configuration

NDAM can be used in either plain or forced-authentication mode (-s option).
In plain mode, NDAM requires a REGISTER message. This message is

provided by superior GMDR servers, the Alarm and Status API REGISTER
message, and implicitly by the various Nortel Multiservice Data Manager Fault
tools. However, NDAM actually ignores its contents (user name and
password) just like GMDR. In forced-authentication mode though, NDAM
checks the authentication information against a list of pre-configured
authentications and only accepts matching entries. The authentication
information also contains a list of device and type filtersets to be automatically
applied to the client connection. This therefore allows the server side of the
Fault stack to control the filtering applied to specific client connections.
To support Fault tools directly without having to deploy an additional GMDR

server superior to NDAM, NDAM also supports wildcard authentication. There
are two forms of wildcards:
Multiple service specific wildcards that are specified as
%<NDAM SERVICE NAME> or an alias. For example, %EASTREGION)
with no password. Any registration made through this service name that
does not match a non-wildcard authentication will be accepted with the
specified list of filtersets.
A single global wildcard that is specified as x with no password. In this
form the wildcard accepts any authentication that does not match a
specific entry nor a service specific wildcard.
In addition, on any other type of authentication, it is possible to omit the

password (actually specify an x or an empty string). The password is then
optional for the corresponding REGISTER messages.
The list of allowed authentications is created using the

/opt/MagellanNMS/bin/ndamuser utility with the following command line:
/opt/MagellanNMS/bin/ndamuser <user name> \
[<password> [<typeset(.typ) and deviceset(.dev)
names...>]]
where:
<user name> is x for a global wildcard, %<service name> for a service-

specific wildcard (the service name must be in upper-case), or another string
for the corresponding authentication.
<password> is a valid password or x to indicate that no password is

necessary.

NN10470-305 01.02 Standard
16.2 May 2007
- 92 -
<typesets> and <devicesets> are the names of the filtersets associated

with this authentication, they can be specified with or without the NDAM_
prefix (though the corresponding files must be found in
/opt/MagellanNMS/cfg/ for the devicesets and /opt/MagellanNMS/cfg or
/opt/MagellanNMS/lib/cfg for the typesets). The names must also have a .typ
or .dev suffix to distinguish them as typesets or devicesets files respectively.
If forced authentication is used in the context of HP OpenView NNM Desktop

clients, you must supply a correct wildcard authentication for NDAM.
The ndamuser utility can be used to add or modify existing authentication

entries. To remove authentications, use a UNIX text editor to remove the
corresponding line from the /opt/MagellanNMS/cfg/private/NDAM.passwd file
(do not add entries manually to this file because the password is encrypted).
NDAM filterset file configuration

There are two types of NDAM filtersets files: typeset files and deviceset
files.Typeset files define the types of components that NDAM reports data on.
Deviceset files contain lists of devices and can be used to divide the network
elements (modules) into geographic regions. Device set files therefore list the
modules that are part or are not of the region and support GLOB style pattern
matching for more efficiency.
Typeset filers can be specified in one of two ways as controlled by the -F

option to NDAM. Without -F (the default option), the filterset files are specified
as in the Network Model API by their highest and lowest categories only. For
example:
EM-FRAMER accepts data for all Nortel Multiservice Switch FRAMER

components (Unacked trunks, FrUni, ...). However, !PM and !PM-* reject all
DPN-100 module and subcomponent information.
With the -F (full types) option, the filterset files must be specified with all
intermediate types. For example:
EM-FRUNI-FRAMER accepts only FRUNI FRAMER information but no

Unacknowledged Trunk Framer information.
GLOB style patterns are supported so that EM-*FRAMER is equivalent to EM-

FRAMER without the -F option.
All the default typeset files provided with Nortel Multiservice Data Manager
are specified with first-last types only. It is not possible to mix both types of
typeset files. If the -F option is used, all typeset files used must follow the full
type specification.

NN10470-305 01.02 Standard
16.2 May 2007
- 93 -
Multiple filterset files can be specified by the client application, such as HP

OpenView NNM desktop, or as forced authentication parameters. The files
are examined in the specified order and matching data is either rejected as
soon as a file is found that explicitly rejects it or accepted as soon as a file
explicitly accepts it. If match is found for a component in any of the files, the
data is rejected.
For more details about the structure of deviceset files and typeset files, see
(NN10470-310).

NN10470-305 01.02 Standard
16.2 May 2007
Multiservice Switch alarm clearing and
storage
Review this section for an explanation of Multiservice Switch alarm clearing
and storage.

Navigation
Types of Multiservice Switch 7400/15000/20000 alarm clearing (page 94)
How alarms from Multiservice Switch 7400/15000/20000 are collected
and stored (page 96)
Types of Multiservice Switch 7400/15000/20000 alarm clearing

Three types of alarm clearing are available to clear Nortel Multiservice
Switch 7400/15000/20000 alarms: Local Clear, Global Clear, and Global
Clear tool. It is recommended that only one of the Global Clear methods be
configured by your administrator.
Local clear (page 95)
Global clear (page 95)
Global clear tool (page 96)
A Nortel Multiservice Data Manager (MDM) operator can delete alarms from
the active alarm lists (AALs) with the Component Information Viewer (CIV)
tool or the Alarm Display (AD) in active mode tool by selecting a specific alarm
or alarms with the mouse and selecting local or global clearing from a popup
menu. For information on clearing alarms, see the Alarm Display and
Component Information Viewer sections in the Nortel Multiservice Data
Manager Fault ManagementTools (NN10470-011).

NN10470-305 01.02 Standard
16.2 May 2007
- 95 -
Multiservice Switch alarm clearing and storage
Local clear
Local alarm clearing lets an operator clear alarms locally from the GMDR
database on a Nortel Multiservice Data Manager (MDM) workstation. When
an operator selects local clear with CIV or AD tool, the GUI applications sends
a clear request to the GMDR databases. The alarm is then cleared from the
GMDR databases on the workstation and the associated FMDR server(s).
Global clear
Global Clear lets an operator clear SET alarms from the Nortel Multiservice
Data Manager (MDM) servers and from the on-switch active alarm list (AAL).
The main reason for removing SET alarms from the AALs is to clean up the
lists so that only alarms of interest to the network operator remain. This makes
monitoring easier.
Global Clear is initiated in several ways:

From the Alarm menu by selecting Global Clear
Using ManClear from a VT-100 terminal or in the UI of the Command
Console (CC)
Clearing alarms using Global Clear from the Alarms menu allows many
alarms to be cleared at once. Anyone from Alarm Display or Component
Information Viewer can globally clear alarms that belongs to the node
members of the specified groups in the DMA configuration file.
Global Clear and the ManClear macro uses the DMA architecture for clearing
alarms. By default, Global Clear is available from the Alarms menu. Global
Clear can be removed from the menu by touching the following file:
opt/MagellanNMS/cfg/.DMAGlobalClearDisabled.
When the operator selects Global Clear from the CIV or AD tool, the DMA
server sends a clear request to the GMDR databases to clear the alarm local
on the workstation. The DMA server also logs on to the node using the
information contained in file /opt/MagellanNMS/cfg/DmaClrPP.cfg. For details
on how the DMA server performs this function, see the Data Manager Agent
(DMA) in Nortel Multiservice Data Manager AdministrationServer
Management (NN10470-310).
See setting up global alarm clearing for Nortel Multiservice Switch 7400/
15000/20000 in Nortel Multiservice Data Manager Administration
(NN10470-303).
Network operators using VT100 access or the Command Console tool can
delete alarms using the ManClear command with appropriate parameters.
See the Nortel Multiservice Data Manager AdministrationTools
(NN10470-300) for more information on ManClear.

NN10470-305 01.02 Standard
16.2 May 2007
- 96 -
Multiservice Switch alarm clearing and storage
Global clear tool

The Global Clear tool lets an operator clear SET alarms from the Nortel
Multiservice Data Manager (MDM) servers and from the active alarm lists
(AALs) on the switch. The main reason for removing SET alarms from the
AALs is to clean up the lists so that only alarms of interest to the network
operator remain. This makes monitoring easier.
Global Clear tool is initiated from the Alarm menu by selecting

Start Tool ->Fault ->Global Clear of Alarm.
Clearing alarms using Global Clear tool from the Start Tool ->Fault menu
allows only one alarm to be cleared at a time. Using the method, the user
needs an up-front authentication with a group before globally clearing an
alarm.
How alarms from Multiservice Switch 7400/15000/20000 are collected

and stored
In a Nortel Multiservice Switch 7400/15000/20000 network, alarms from
devices are stored in each individual Active Alarm List (AAL), if the AAL is
installed and provisioned on the node. See Activating the Active Alarm List in
the Nortel Multiservice Data Manager Installation and Commissioning
Software (NN10470-100).
These alarms remain in the AAL until the corresponding alarm has been
cleared, or until the alarm is manually deleted. In both cases the alarm is
removed from the AAL.
Lists of active alarms are collected and maintained in the following places:
locally on the workstation in a database associated with the FMIP
Management Data Router (FMDR) server and in the GMDR database
in the AAL stored in the node.
When the FMDR server connects to nodes in a group, it requests a dump of

each AAL of each node and uses it to update the FMDR database with all the
current SET alarms that are not in the FMDR database (if there are
discrepancies) and forwards them to GMDR. Once the connection between
the FMDR and each node is established, any SET/CLR and MESSAGE
alarms are automatically received, computed, and stored into the FMDR and
GMDR database.
Alarms stored in the FMDR and GMDR databases can be cleared with local
alarm clearing [local to the Nortel Multiservice Data Manager workstation] or
with global alarm clearing. However, alarms stored in the AALs of each node
can only be cleared by means of global alarm clearing.

NN10470-305 01.02 Standard
16.2 May 2007
User interface customization
fundamentals
Use the topics listed in this section when you require information about the
procedures used to customize the Nortel Multiservice Data Manager (MDM)
user interface.
The information in this section is directly related to procedures located in

Nortel Multiservice Data Manager Administration (NN10470-303). Where
specific procedures are not provided, example procedure are used to illustrate
the customization process.
Navigation
Multiservice Data Manager user customization fundamentals (page 98)
fundamentals (page 109)
Menu customization fundamentals (page 121)
Component Information Viewer diagnostics (page 150)
snmpCmd macros (page 158)
Alarms in text format (page 169)
Helpsets for MPE devices (page 172)

NN10470-305 01.02 Standard
16.2 May 2007
Multiservice Data Manager user
customization fundamentals
Use this section to review the methods used to customize Nortel Multiservice
Data Manager user and workstation access to tools and the look and feel of
the graphical user interface (GUI).

Navigation
Access Control (page 98)
Service Selection (page 99)
Menu customization (page 99)
User Preferences (page 99)
Operator Client logging preferences (page 108)
Access Control
Access to applications running in the OC environment can be controlled by
displaying them based on the user ID. Access Control involves assigning
users to application categories such as Fault, Configuration, and
Performance. Launch and Tools menus are mapped to application categories
to restrict a users access to the assigned menus.
For example, a user assigned to the Fault category can only launch Alarm
Display, Component Information Viewer, and other fault applications. When
this Fault user opens a tools menu from any other tool, only those three items
are enabled.
Nortel Multiservice Data Manager user management is centralized for

administrators from the Toolset. The Toolset provides a set of security GUIs to
allow the administrator to perform the various user management functions
such as access control, password administration, and application launch
permissions. The security tools work in conjunction with the Sun ONE Identity
Server that provides secure access to Multiservice Data Manager. These

NN10470-305 01.02 Standard
16.2 May 2007
- 99 -
Multiservice Data Manager user customization fundamentals
tools can be used to set up Access Control for users. For information about
Multiservice Data Manager security, see Nortel Multiservice Data Manager
Network SecurityUser Access (NN10470-606).
Service Selection
The Service Selection tool can be used by Nortel Multiservice Data Manager
administrators and operators to modify Multiservice Data Manager default
service selection settings for workstations and specific users. Service
selection defines which workstation is to be used for connecting a specific
server from a Multiservice Data Manager tool.
See Nortel Multiservice Data Manager AdministrationTools

(NN10470-300).
Menu customization
Menu customization refers to controlling which Nortel Multiservice Data
Manager tools appear in the Launch and Tools menus. The Tools menus are
referred to as Start Tools menus and are displayed as popup menus in specific
contexts within each tool.
The ability to launch a tool in context means that within each tool the user can
select specific items and open a Start Tools category menu that provides a list
of tools that can be used with that item in the context of that tool.
Only Multiservice Data Manager administrator can customize the Launch and
Tools menus. For information about how to customize these menus, see the
description of customizing menus in Nortel Multiservice Data Manager
Administration (NN10470-303)
User Preferences
The user preference system allows Nortel Multiservice Data Manager
administrators to customize the default preferences for the Java applications
in the OC and MT environments.The user preference system for the MT and
OC environments is centralized at the User Administration server. See
Preferences system used by OC and MT environments (page 100).
Default preferences are defined for each application. They can be customized
at the system level or at the user level. System level preferences are changed
by an administrator outside a desktop session by editing a file. The change
takes effect only in subsequent desktop sessions. User level preferences are
changed within a desktop session. These preferences take effect immediately
and are visible with the relevant user action.
In the OC environment, the users preferences are stored against the user id
in the Sun One Identity server. In the MT environment, the user ID is the UNIX
user ID.

NN10470-305 01.02 Standard
16.2 May 2007
- 100 -
Preferences system used by OC and MT environments
Operator Client Operator Client
Sun workstation PC
Preferences System
Toolset Toolset
Sun workstation
Preference system directory structure

The preferences system supports both the local and remote file system as the
preferences factory. A preference factory represents the underlying
mechanism that stores/retrieves data associated with the preferences by
mapping preferences nodes to UNIX file system directories.
The OC environment uses a remote file system implementation.The MT

environment uses a local file system implementation. The directory structures
are set up so that there are separate directories for default preferences,
system preferences, and user preferences.
To change a system level preference, the administrator must copy the

prefs.xml file from the default directory and place it in the system directory.
User level preferences are changed through the GUIs of the tools that support
user preferences.
The OC environment uses the following top-level directories for its Preference
System:
DEFAULT_SYSTEM_PREF_LOCATIONS = /opt/nortel/data/applications/
desktop/jws/MDM/prefs/default
SYSTEM_PREF_LOCATION = /opt/nortel/data/applications/desktop/jws/
mft/prefs/system

NN10470-305 01.02 Standard
16.2 May 2007
- 101 -
USER_PREF_LOCATION = /opt/nortel/data/applications/desktop/jws/
mft/prefs/users
The MT environment uses the following top-level directories for its Preference
System:
DEFAULT_SYSTEM_PREF_LOCATIONS = /opt/nortel/data/applications/
desktop/local/MDM/prefs/default
SYSTEM_PREF_LOCATION = /opt/nortel/data/applications/desktop/
local/mft/prefs/system
USER_PREF_LOCATION = /opt/nortel/data/applications/desktop/local/
mft/prefs/users
User preferences for Data Viewer

The DefaultAndAdmin default system preferences can be changed only by the
administrator. The prefs.xml files are located in:
<DEFAULT_SYSTEM_PREF_LOCATIONS>/com/nortel/mdm/dvr
In this directory, there are three default Data Viewer user prefs.xml files:
one for basic Data Viewer operational preferences in /prefOptions/
one for Windows directory preferences in /filePathWinOptions/
one for Solaris directory preferences in /filePathSolOptions/
To change the preferences, the administrator copies the prefs.xml file to the
appropriate corresponding directory, either:
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/dvr/prefOptions/
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/dvr/filePathWinOptions/
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/dvr/filePathSolOptions/
See Data Viewer modifiable operational parameters for DefaultAndAdmin

preferences (page 102), Data Viewer modifiable Windows directory
parameters for DefaultAndAdmin preferences (page 102), and Data Viewer
modifiable Solaris directory parameters for DefaultAndAdmin preferences
(page 103).

NN10470-305 01.02 Standard
16.2 May 2007
- 102 -
Data Viewer modifiable operational parameters for DefaultAndAdmin preferences
Parameter Definition Default value

Max_File_Size The maximum file size allowed for files to be replayed in 10M
replay mode
Max_Data_Size The maximum number of data sets to be collected in real- 200
time mode. When the maximum is reached, the oldest
data set is discarded.
Max_Lines_In_Graph The maximum number of lines/graphs to be displayed in a 20
graph window.
Max_Graph_Window The maximum number of graph windows to be displayed. 3
Auto_Label_On_Graph Sets the Multi graph auto labels to display (On) or not Off
(Off).
Ignore_Negative_Delta Determines if the counter rollover calculation is performed No
when a negative delta is detected. If the value is No, a
value is calculated to compensate for the rollover. If the
value is Yes, a null data point is created.
Data Viewer modifiable Windows directory parameters for DefaultAndAdmin preferences

All_Path The default directory path for all replay files. D:\Profiles\<user>\My
Documents
Accounting_Path The default directory path for MDP accounting files. D:\Profiles\<user>\My
Documents
Alarm_Path The default directory path for MDP alarm files. D:\Profiles\<user>\My
Documents
Availability_Path The default directory path for MDP availability files. D:\Profiles\<user>\My
Documents
Log_Path The default directory path for MDP log files. D:\Profiles\<user>\My
Documents
Outage_Path The default directory path for MDP outage files. D:\Profiles\<user>\My
Documents
Scn_Path The default directory path for MDP scn files. D:\Profiles\<user>\My
Documents
Statistics_Path The default directory path for MDP statistics files. D:\Profiles\<user>\My
Documents
SRS_Path The default directory path for MDP Statistic D:\Profiles\<user>\My
Retrieval System files. Documents
(1 of 2)

NN10470-305 01.02 Standard
16.2 May 2007
- 103 -
Data Viewer modifiable Windows directory parameters for DefaultAndAdmin preferences

(continued)

PMSP_Path The default directory path for Streamed MSS D:\Profiles\<user>\My
Statistics files. Documents
DataViewer_Path The default directory path for Data Viewer saved D:\Profiles\<user>\My
Statistics files. Documents
(2 of 2)
Data Viewer modifiable Solaris directory parameters for DefaultAndAdmin preferences

All_Path The default directory path for all replay files. users home directory
Accounting_Path The default directory path for MDP accounting /opt/MagellanMDP/data/
files. mdp/dump/accounting
Alarm_Path The default directory path for MDP alarm files. /opt/MagellanMDP/data/
mdp/dump/alarm
Availability_Path The default directory path for MDP availability /opt/MagellanMDP/data/
files. mdp/dump/avail
Log_Path The default directory path for MDP log files. /opt/MagellanMDP/data/
mdp/dump/log
Outage_Path The default directory path for MDP outage files. /opt/MagellanMDP/data/
mdp/dump/outage
Scn_Path The default directory path for MDP scn files. /opt/MagellanMDP/data/
mdp/dump/scn
Statistics_Path The default directory path for MDP statistics files. /opt/MagellanMDP/data/
mdp/dump/statistics
SRS_Path The default directory path for MDP Statistic /opt/MagellanMDP/data/
Retrieval System files. mdp/dump/srs
PMSP_Path The default directory path for Streamed MSS /opt/MagellanMDP/data/
Statistics files. mdp/dump/pmsp
DataViewer_Path The default directory path for Data Viewer saved users home directory
Statistics files.
User preferences for Operational Command GUI

The DefaultAndAdmin default system preferences can changed only by the
administrator. The prefs.xml file is located in:
<DEFAULT_SYSTEM_PREF_LOCATIONS>/com/nortel/mdm/ocGUI
To change the preferences, the administrator copies the prefs.xml file to:

NN10470-305 01.02 Standard
16.2 May 2007
- 104 -
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/ocGUI/prefOptions
See Operational Commands GUI modifiable parameters for DefaultAndAdmin

preferences (page 104).
Operational Commands GUI modifiable parameters for DefaultAndAdmin preferences
Parameter Definition Default

value
Max_Command_Output Defines the maximum number of commands displayed in the 25
Operational Command History. The maximum number that
can be defined is 25.
User preferences for MSS Shelf View

MSS Shelf view user preferences are delivered for the DefaultAndAdminOnly
category. The groups of preferences that can be modified are:
State preferences (page 104)
Severity preferences (page 106)
State preferences
State preferences are the common system preferences shared by all the Fault
applications. The default system preferences are delivered in the prefs.xml file
in the system directory:
<DEFAULT_SYSTEM_PREF_LOCATIONS>/com/nortel/mdm/fault/state/
<state_node>/.
The parameters can be changed only by the system administrator. To modify

these parameters, copy the prefs.xml file to:
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/fault/state/<state_node>/
and change the relevant default values.
The value of state-node can be:

fg_and_bg_colors. See MSS Shelf View modifiable parameters for State
fg_and_bg_colors (page 105)
short_label. See MSS Shelf View modifiable parameters for State
short_label (page 105)
long_label. See MSS Shelf View modifiable parameters for State
long_label (page 106)

NN10470-305 01.02 Standard
16.2 May 2007
- 105 -
MSS Shelf View modifiable parameters for State fg_and_bg_colors

UNK_BG Sets the background color for state of unknown. Gray
UNK_FG Sets the foreground color for state of unknown. Black
INSV_BG Sets the background color for state of in-service. Green
INSV_FG Sets the foreground color for state of in-service. Black
ISTB_1_BG, Sets the background color for state of in-service troubled. Yellow
ISTB_2_BG
ISTB_1_FG, Sets the foreground color for state of in-service troubled. Black
ISTB_2_FG
ISTB_3_BG, Sets the background color for state of in-service troubled. Orange
ISTB_4_BG,
ISTB_5_BG
ISTB_3_FG, Sets the foreground color for state of in-service troubled. Black
ISTB_4_FG,
ISTB_5_FG
OOS_1_BG, Sets the background color for state of out-of-service. Red
OOS_2_BG,
OOS_3_BG,
OOS_4_BG,
OOS_5_BG
OOS_1_FG, Sets the foreground color for state of out-of-service. Black
OOS_2_FG,
OOS_3_FG,
OOS_4_FG,
OOS_5_FG
MTCE_BG Sets the background color for state of maintenance. Sky-blue-1
MTCE_FG Sets the foreground color for state of maintenance. Black
HIER_MTCE_BG Sets the background color for state of hierarchical maintenance. Sky-blue-2
HIER_MTCE_FG Sets the foreground color for state of hierarchical maintenance. Black
ACK_BG Sets the background color for state of acknowledged. Aquamarine
ACK_FG Sets the foreground color for state of acknowledged. Black
MSS Shelf View modifiable parameters for State short_label

UNK Sets the short label for state of unknown. UNK
INSV Sets the short label for state of in-service. INSV
(1 of 2)

NN10470-305 01.02 Standard
16.2 May 2007
- 106 -
MSS Shelf View modifiable parameters for State short_label (continued)

OOS Sets the short label for state of out-of-service. OOS
MTCE Sets the short label for state of maintenance. MTCE
HIER_MTCE Sets the short label for state of hierarchical maintenance. HIER_MTCE
ACK Sets the short label for state of acknowledged. ACKED
(2 of 2)
MSS Shelf View modifiable parameters for State long_label

UNK Sets the short label for state of unknown. Unknown
INSV Sets the short label for state of in-service. In-service
OOS Sets the short label for state of out-of-service. Out-of-service
MTCE Sets the short label for state of maintenance. Maintenance
HIER_MTCE Sets the short label for state of hierarchical maintenance. Hierarchical
maintenance
ACK Sets the short label for state of acknowledged. Acknowledged
Severity preferences
Severity preferences are the common system preferences shared by all the
Fault applications. The default system preferences are delivered in the
prefs.xml file in the system directory:
<DEFAULT_SYSTEM_PREF_LOCATIONS>/com/nortel/mdm/fault/
alarm_severity/<severity_node>/.
The parameters can be changed only by the system administrator. To modify

these parameters, copy the prefs.xml file to:
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/fault/alarm_severity/
<severity_node>/ and change the relevant default values.
The value of severity-node can be:

fg_and_bg_colors. See MSS Shelf View modifiable parameters for State
fg_and_bg_colors (page 105)
short_label. See MSS Shelf View modifiable parameters for State
short_label (page 105)
long_label. See MSS Shelf View modifiable parameters for State
long_label (page 106)

NN10470-305 01.02 Standard
16.2 May 2007
- 107 -
MSS Shelf View modifiable parameters for Severity fg_and_bg_colors

Critical_BG Sets the background color for alarm severity of critical. Red
Critical_FG Sets the foreground color for alarm severity of critical. Black
Major_BG Sets the background color for alarm severity of major. Orange
Major_FG Sets the foreground color for alarm severity of major. Black
Minor_BG Sets the background color for alarm severity of minor. Yellow
Minor_FG Sets the foreground color for alarm severity of minor. Black
Warning_BG Sets the background color for alarm severity of warning. Sky-blue-3
Warning_FG Sets the foreground color for alarm severity of warning. Black
Cleared_BG Sets the background color for alarm severity of cleared. White
Cleared_FG Sets the foreground color for alarm severity of is cleared. Black
MSS Shelf View modifiable parameters for Severity short_label

Critical Sets the short label for alarm severity of critical. C
Major Sets the short label for alarm severity of major. M
Minor Sets the short label for alarm severity of minor. m
Warning Sets the short label for alarm severity of warning. w
Cleared Sets the short label for alarm severity of is cleared. c
MSS Shelf View modifiable parameters for Severity long_label

Critical Sets the short label for alarm severity of critical. Critical
Major Sets the short label for alarm severity of major. Major
Minor Sets the short label for alarm severity of minor. Minor
Warning Sets the short label for alarm severity of warning. Warning
Cleared Sets the short label for alarm severity of is cleared. Cleared

NN10470-305 01.02 Standard
16.2 May 2007
- 108 -
User preferences for Nodal Provisioning and Nodal Provisioning

Template Editor
Information on setting user preferences for Nodal Provisioning and Nodal
Provisioning Template Editor are covered in Nortel Multiservice Data Manager
ConfigurationTools (NN10470-023), User Preferences.
Operator Client logging preferences

Debug information can be useful for Nortel GNPS when troubleshooting
problems in Operator Client applications.
The default preference for logging is OFF. To activate logging, the logging
preference for the Operator Client application must be changed to ON. The
can be done by the administrator or by any user. There is a default logging
preference file called prefs.xml for every Nortel Multiservice Data Manager
tool.
The default location for the logging preference is in:

/opt/MagellanNMS/lib/cfg/mft/preferences/com/nortel/
mdm/<application-subsystem>/logging/prefs.xml
To change the logging preference to ON, the user must copy the prefs.xml file
to a customization location and then change the logging preference to ON.
The customization location must be created for the user who is changing the
preference logging, as follows:
/opt/MagellanNMS/cfg/mft/OCpreferences/users/<userid>/
com/nortel/mdm/<application-subsystem>/logging/
prefs.xml
where:
<userid> is the desktop user ID
<application-subsystem> is the name of the application whose logging

preference is activated. For example, dvr for Data Viewer.
Attention: Exceptions are always logged regardless of the logging

preference setting. The exceptions are logged in the common exceptions file.

NN10470-305 01.02 Standard
16.2 May 2007
Resources for Multiservice Data
Manager tools customization
fundamentals
This section contains information that allows you to customize X-window
resources and Nortel Multiservice Data Manager resources to change the
appearance of some of the Multiservice Data Manager tools to suit your
requirements.

Navigation
About resources used by Multiservice Data Manager tools (page 109)
Syntax of a resource definition statement (page 110)
Predominance (page 111)
Specificity (page 111)
Customizing resources for all users (page 113)
Customizing resources for specific users (page 117)
Setting resources for a single user in the .Xdefaults file (page 118)
Customizing resources in a command line (page 119)
Useful utilities (page 119)
About resources used by Multiservice Data Manager tools

Nortel Multiservice Data Manager tools are built using X toolkits of the OSF/
Motif type. Toolkits provide a means to simplify the design and coding of the
software needed to build tools and to ensure consistency in the appearance
of the tools and the way in which their buttons and menus operate. Toolkits
provide a standard set of objects known as widgets for such things as push-
buttons, scroll bars, text fields, and so on. Each widget has a set of resources

NN10470-305 01.02 Standard
16.2 May 2007
- 110 -
Resources for Multiservice Data Manager tools customization fundamentals
associated with it that defines the appearance of the widget and how it acts.
For example, resources that define the background color and border width for
a push-button in the icon bar of a tool.
There may be widgets within widgets arranged into a hierarchy. For example,
the Network Viewer is equipped with many widgets such as an icon bar, and
the icon bar has a number of push-buttons that are subwidgets of the icon bar
widget.
In addition to the standard X resources for OSF/Motif widgets, Multiservice

Data Manager software uses many non-widget-based X resources for
controlling various aspects of the appearance and functions of tools.
Many sources are available to obtain information about setting standard X

resources. These include the X man pages and third-party publications such
as the X-Window System Users Guide, ISBN 1-56592-015-5, from OReilly
and Associates Inc.
The following sections explain the syntax used for writing resource definition
statements, provide predominance rules for resource definition statements,
explain the methods used to set resources for tools, and contain a few
examples that show how to set them.
Syntax of a resource definition statement

The syntax of a statement used to define a resource for a Nortel Multiservice
Data Manager tool is as follows:
<client>*<widget>[<b>subwidget>]<b><attribute>: <value>
where:
<client> is the client program, or a specific instance of the client program.

If you omit the client name, the definition applies to all client programs.
<widget> corresponds to the name of a widget for which the value of a

resource is being set
<b> is an asterisk (*) or a period (.) character that represents the

relationship (the binding) between items such as widgets, subwidgets, and
attributes. If there can be no other item between two items in the hierarchy to
which the items belong, the items are said to have a tight binding and a period
is used to separate them. If other items from the hierarchy can be inserted
between the two items, the items are said to have a loose binding and an
asterisk is used to separate them.
<subwidget> corresponds to the name of a subcomponent that belongs to

the component specified by widget

NN10470-305 01.02 Standard
16.2 May 2007
- 111 -
<attribute> is the name of the resource attribute being set
<value> is the value of the attribute
The following is an example of a resource definition statement that sets a

resource for the Network Viewer tool. This statement sets the background
color for the title (label) of the Network Viewer window to the color blue.
ND*statusLabel.background: blue
In this example, ND is the client, statusLabel is the name of the widget,
background is the attribute name, and blue is the value of the attribute.
Predominance
Two main factors affect the way in which one resource definition statement
overrules (predominates) another. These are:
the specificity of the resource definition statement
the location of the resource definition statement
Specificity
You can write resource definitions with varying degrees of specificity. As an
example, you can use the following five definitions to set the color of the label
in the main window of the Network Viewer tool. These sample definitions are
listed with the most specific statement first and the least specific statement
last:
ND*statusLabel.background: blue
ND*XmLabel.background: yellow
ND*background: brown
ND*Background: grey
*XmLabel.background: green
*background: red
*Background: pink
The general rule is that the more specific a resource definition statement is,
the more likely it is to overrule (predominate) a less specific statement, as
follows:
The more widgets and subwidgets there are in a resource definition
statement, the more specific the definition. In the samples, client names
are in fact widgets, so definitions that contain client names (ND)
predominate definitions that do not contain client names.
Widget names that begin with an uppercase letter represent classes of
widgets and widget names that begin with a lowercase letter are specific
instances of a class of widget. Resource definitions for specific instances
of a widget predominate resource definitions for classes. In the samples,
the definition *background: red predominates the definition *Background:
pink and the definition ND*statusLabel.background: blue

NN10470-305 01.02 Standard
16.2 May 2007
- 112 -
which is a specific instance of an XmLabel predominates the definition

ND*XmLabel.background: yellow
Bindings between items such as clients, widgets, and attributes are
indicated by an asterisk (*) or a period(.). If there can be no other item
between two items in the hierarchy to which them items belong, the items
are said to have a tight binding and a period is used to separate them. If
other items in the hierarchy can be inserted between them, the items are
said to have a loose binding and an asterisk (*) is used to separate them.
Tight bindings overrule loose bindings.
Location
On UNIX platforms you can to define resources for Nortel Multiservice Data
Manager tools in multiple locations. For user accounts that run the default
Multiservice Data Manager user environment, you can define resources in five
main locations. These locations and the order in which the system consults
them to determine settings for resources are as follows:
1 resources specified by means of -xrm arguments added to the command
lines used to start a tool.
These arguments can be added to the tool startup commands in the
toolsets menu definition files, start tool menu definition files, and icon bar
definition files.
2 the .Xdefaults file in a users home directory
Resource definitions in this file apply only to a single Multiservice Data
Manager user account. Resource definitions in this file are automatically
applied to the users session whenever the user logs in. However, if they
are to be applied without having the user log out then log back in again,
they must be applied manually by means of the xrdb utility.
3 a common resource definition file, whose definitions are added to a users
session by executing the xrdb -merge command
When this command is added to the .dt/sessions/sessionetc (CDE) file or
.xsession (Bourne Korn, or C-shell) file of every user account that is to use
the common resource definition file, it applies the definitions to the users
session whenever the user logs in.
Resource definitions applied this way can apply to a single user, specific
users, or all users of the tool. This method is best suited for applying
resource definitions to some users, but not all users of a tool.
4 MDM tools resource definition files located in directory /opt/MagellanNMS/
cfg/app-defaults
This directory also contains three subdirectories called C, ja, and zh.
Subdirectory C is used for storing customized English language resource
definition files. Subdirectories ja and zh contain the Japanese and
Chinese language equivalents. Resource definitions in these files apply to
all users of a tool.

NN10470-305 01.02 Standard
16.2 May 2007
- 113 -
5 Multiservice Data Manager tools resource definition files are located in

directory /opt/MagellanNMS/lib/app-defaults
This directory contains three subdirectories called C, ja, and zh.
Subdirectory C contains the default English language resource definition
files provided with Multiservice Data Manager software for each of the
tools. Subdirectories ja and zh contain the Japanese and Chinese
language equivalents. Multiservice Data Manager tool resource definition
files are named according to the tool to which they apply. For example, ND
is the file name for the Network Viewer tool. Resource definitions in these
files apply to all users of a tool.
How specificity and location affect predominance

When the software obtains the resource definitions from various resource
locations, it merges them and applies them according to their specificity as
described in Predominance (page 111). The most specific definition
predominates. However, if a given resource is defined with the same degree
of specificity in more than one of the locations listed in Specificity (page 111),
the software uses the definition it consults last to determine the setting for the
resource.
Customizing resources for all users

Use the information in this section to customize resources for all users of a
Nortel Multiservice Data Manager tool by customizing resource definition files.
Guidelines for setting resources in a tools resource definition file are as

follows:
Do not modify a resource definition file in directories
/opt/MagellanNMS/lib/app-defaults/C,
/opt/MagellanNMS/lib/app-defaults/ja, or
/opt/MagellanNMS/lib/app-defaults/zh. These directories are reserved for
files that are provided with Multiservice Data Manager software. Instead,
copy the file into one of directories /opt/MagellanNMS/cfg/app-defaults/C,
/opt/MagellanNMS/cfg/app-defaults/ja, or
/optMagellanNMS/cfg/app-defaults/zh and use this new file as the starting
point for creating a customized resource definition file.
At the first line of your new file, use the #include statement to include the
original resource file you copied from.
In any new customized resource definition file you create, only retain
statements that define the resources that you wish to set. Remove all
other statements from your new file.
Some tools only allow you to modify a subset of the resources. For
information about such restrictions, refer to Nortel Networks technical
publication that describes the use of the tool. For example, for the
resources you are allowed to modify for the Network Viewer tool, see

NN10470-305 01.02 Standard
16.2 May 2007
- 114 -
Nortel Multiservice Data Manager Fault ManagementTools

(NN10470-011).
Example 1, customizing resources for Network Viewer in the ND tools

resource file
The following procedure is an example of how you can set resources in a
resource definition file for all users of a Nortel Multiservice Data Manager tool,
using the Network Viewer tool as an example.
1 Log on as root.
2 Copy the resource file for the Network Viewer tool into a new file in
directory /opt/MagellanNMS/cfg/app-defaults/C:
cp /opt/MagellanNMS/lib/app-defaults/C/ND \
/opt/MagellanNMS/cfg/app-defaults/C/ND
3 Access the directory that contains the copied file.
cd /opt/MagellanNMS/cfg/app-defaults/C
4 Change the file permissions of the newly created file so you can modify it,
and to allow read access by the group and by others.
chmod 644 ND
5 Using a UNIX editor, open the new file and change the settings of the
resources you wish to modify.
See Nortel Multiservice Data Manager Fault ManagementTools
(NN10470-011) to determine which ND resources you are allowed to
modify.
6 At the first line of your new file, use the #include statement to include the
original resource file you copied from.
7 Remove all statements from this file, except the ones you have modified.
Attention: Another way to proceed is to open the file provided with

Multiservice Data Manager software, open a new file in directory
/opt/MagellanNMS/cfg/app-defaults/C, copy the statements you wish to
modify from the old file into the new file, then modify the resource definitions
in the new file.
8 Save the file and exit from it.

9 Have users restart Network Viewer and verify that the changes are
successful.
Example 2, Customizing font resources in the Msm resource file

The following example shows how to set resources in a resource definition file
for all users of a Nortel Multiservice Data Manager tool, using the Motif
Session Manager (Msm) tool as an example. Most resources in the Msms

NN10470-305 01.02 Standard
16.2 May 2007
- 115 -
resource definition file only apply to the appearance of the cascading menus
that are available from the MDM window. However, some of the resources
affect all tools that are started from the cascading menus. The following
example defines a resource that affects all Multiservice Data Manager tools.
The default Msm tool resource file contains font resources that allow an
operator to select one of five fonts for displaying information in the main
windows of all tools that are opened from the MDM window.
Attention: Font changes and substitutions have no effect on Java

applications that are part of Multiservice Data Manager, for example Backup
and Restore, Data Viewer and Nodal Provisioning.
The default font selection menu available to an operator from the MDM
window is shown in the figure Default font selection menu (page 115).
Default font selection menu
The resource modification in this example defines a new sixth font selection
called nicefont.
Three resource definition statements are used to define a font select in the
Fonts menu. These are as follows:
Msm*numFonts: <number of fonts>
defines the maximum number of font selections available from the Fonts
menu. In file /opt/MagellanNMS/lib/app-defaults/C/Msm, this resource is set
to 5. If you wish to provide more than five choices in the Fonts menu, you must
increase this number accordingly.
Msm*fontMnemonic<n>: <fontname>

NN10470-305 01.02 Standard
16.2 May 2007
- 116 -
defines the name that appears as a selection under the Fonts menu. In this
resource, <n> identifies the font selection involved. The value for <n> must lie
within the range of numbers defined for resource Msm*numFonts
Msm*fontname<n>:<font specification>
defines the size and type of the font to be displayed. In this resource <n>
identifies the font selection involved. The value for <n> must lie within the
range of numbers defined for resource Msm*numFonts.
Setting font resources in the Msm resource file

Steps
1 Log on as root.
2 Copy the Msm resource file into a new file in directory /opt/MagellanNMS/
cfg/app-defaults/C:
cp /opt/MagellanNMS/lib/app-defaults/C/Msm \
/opt/MagellanNMS/cfg/app-defaults/C/Msm
3 Access the directory that contains the newly copied file:
cd /opt/MagellanNMS/cfg/app-defaults/C
4 Change the file permissions of the newly created file, so you can modify
it, and to allow read access by the group and by others.
chmod 644 Msm
5 Enter the following command to display a list of all of the fonts available for
use on your workstation, then select one of the fonts for the new menu
item.
/usr/openwin/bin/xlsfonts | more
6 Using a UNIX editor, open the new file for editing.
7 Modify resource Msm*numFonts to allow for the creation of a new sixth
font selection as follows:
Msm*numFonts: 6
8 Add the two resource definitions to define the new font selection, as
follows:
Msm*fontMnemonic6: nicefont
Msm*fontName6: 20x20
where:
20X20
is one of the fonts that appears when you enter the xlsfonts command.

NN10470-305 01.02 Standard
16.2 May 2007
- 117 -
10 Have users log out and log back in again to make the changes active.
Customizing resources for specific users

Use the information in this section to set resources for specific users of a
Nortel Multiservice Data Manager tool.
The following example shows how resources for Network Viewer can be set
for multiple Multiservice Data Manager users by defining the resources in a
common resource file then applying them to each users account by running
the xrdb utility whenever the user logs in. To ensure that a user account
obtains resource definitions from the common file whenever the user logs in,
the following command must be added to the .dt/sessions/sessionetc (CDE)
or .xsession (Bourne, Korn, or C-shell) file of every user account that is to use
the common resource file:
xrdb -merge <pathname of common resource file>
Although this method is most useful when you wish to customize resources for
multiple users of a tool, you may also use it to customize resources for all
users. Do not customize resources for some tools with this method and
customize resources for other tools by creating new customized resource
definition files in directories /opt/MagellanNMS/cfg/app-defaults/C,
/opt/MagellanNMS/cfg/app-defaults/ja or
opt/MagellanNMS/cfg/app-defaults/zh
Setting resources for the Network Viewer in a common resource file

This example procedure demonstrates how to set resources for Network
Viewer in a common resource file.
1 Log on as root.
2 Access the directory in which you wish to store the common resource file.
cd <directory path name>
3 Using UNIX editor, open a new file for editing. This file is to contain
resource definitions common to all Multiservice Data Manager users. For
example, the absolute path name for this file is /opt/settings/myfile.
4 Insert statements into the file to define resources for all tools, or for a
single tool. For example, to set the color used in Network Viewer for
indicating the in-service state (stateINSV) to white:
ND*stateINSV: white
6 Change file permissions to allow read access by the group and others, and
read-write by the owner.
chmod 644 myfile

NN10470-305 01.02 Standard
16.2 May 2007
- 118 -
7 Do one of the following for each user account that will use the common
resource file:
If the account is running CDE, add the following command to set-up file
.dt/sessions/sessionetc:
xrdb -merge /opt/settings/myfile
If the account is running Bourne. Korn, or C-Shell add the following
command to set-up file .xsession:
9 Have each of the users log out and log back again to obtain the new
settings, or alternatively have each user enter the following command to
activate the settings:
Setting resources for a single user in the .Xdefaults file

Use the information in this section to set resources for a single Nortel
Multiservice Data Manager user by defining them in the .Xdefaults file of user
accounts home directory. Resources in this file are automatically applied to
the user session whenever the user logs in, but if they are to be applied
without having the user log out then back in again, they must be applied
manually by means of the xrdb utility.
The resource set in the following example defines the color used to display the
in-service state in the Network Viewer tool.
Setting resources for Network Viewer in the .Xdefaults file

This example procedure demonstrates setting resources for Network Viewer
in the .Xdefaults file
1 Using a UNIX editor, open the .Xdefaults file in the users home directory.
2 For every resource specification you want to customize, add a line to this
file but make sure that this line is prefixed with the tools resource file
name. For example, to change the IN-SERVICE state color to white for the
Network Viewer, add the following line to the .Xdefaults file:
ND*stateINSV: white

NN10470-305 01.02 Standard
16.2 May 2007
- 119 -
Attention: As written, this command changes state and color resources.

Omitting ND at the beginning of the command allows the changes to state
and color resources to apply to both Network Viewer and Component
Information Viewer related components panels.
See Nortel Multiservice Data Manager Fault ManagementTools

(NN10470-011) for more information about the resources you wish to
modify.
4 Apply the new resource settings to the users account by entering the
following command in a UNIX Access window:
xrdb -merge ~/.Xdefaults
Customizing resources in a command line

Use the information in this section to set resources in the startup command of
a Nortel Multiservice Data Manager tool.
You can set resources for an tool by adding resource definitions in -xrm
arguments to the tools startup command. However, the number of resources
that can be set in this way is limited because of the potential length of the
command line.
Startup commands for tools that appear in the MDM window cascading menus
are contained in toolset definition files. For descriptions of these files, see
Toolset definition files (page 137).
The following example shows a command that starts Network Viewer with the
labels visible and icons hidden:
/opt/MagellanNMS/bin/nd -xrm ND*showAllabels: True \
-xrm ND*showAllIcons: False"
Useful utilities
The following utility programs are provided with the Solaris operating system
and may be used for such things as setting resources, or determining the
values that can be used to set the attributes of a resource. The names of the
utilities and their purposes are as follows:
xrdb is used for two main purposes:
updating some Nortel Multiservice Data Manager tool users (but not
all users) with resources from a common resource definition file
updating a single user of a tool with resource set in the user accounts
.Xdefaults file

NN10470-305 01.02 Standard
16.2 May 2007
- 120 -
For information about this utility, see the man pages for the xrdb command and
for an example of its use to set resources for multiple Multiservice Data
Manager users, see Customizing resources for specific users (page 117).
xlsfonts displays the names of fonts available on the workstation. The
names displayed can be used as attribute values in resource definition
statements for font resources. For information about this utility, see the
man pages for the xlsfonts command.
xco displays the colors available on the workstation and their names. The
names displayed can be used as attribute values in resource definition
statements for color resources. For information about this utility, see the
man pages for the xco command.

NN10470-305 01.02 Standard
16.2 May 2007
Menu customization fundamentals
This section describes how to customize the toolsets and Start Tool menus so
that you can launch Nortel Multiservice Data Manager tools and utilities to suit
your requirements.

Navigation
Attention: The shared JAVA tool and Start Tools menus used in the Toolset
and Operator Client environments are defined and customized using files
different from those used for the other tools in the Toolset environment. See
Customizing menus for Shared Java and Operator Client tools (page 142).
About menu items that can be customized (page 121)

Menu definition records (page 124)
Customizing menus for Shared Java and Operator Client tools (page 142)
About menu items that can be customized

Nortel Multiservice Data Manager tools are equipped with several menu items
that you can customize. See the following sections for more information on
these menu items:
MDM window (page 122)
Start Tool menus (page 123)
Push-buttons in icon bars (page 124)
Although push-buttons in icon bars are not normally thought of as having an

association with menus, they are categorized as menu items because they are
defined and customized in a similar manner to toolset menus and Start Tool
menus.

NN10470-305 01.02 Standard
16.2 May 2007
- 122 -
MDM window
When you log in to a UNIX account that is set up to run the default user
environment, as described in Nortel Multiservice Data Manager
Administration (NN10470-303), a Nortel Multiservice Data Manager session
starts and the MDM main window opens. The main window provides you with
access to Multiservice Data Manager tools through
a primary menu consisting of the menu items of fault, configuration,
accounting, performance and system
a set of cascading submenus from which you can start Multiservice Data
Manager tools
For information on customizing the toolsets menus, see customizing toolset

menus in Nortel Multiservice Data Manager Administration (NN10470-303).
The figure MDM main window and menus (page 122) shows the Fault menu
and its submenus.
MDM main window and menus
Main
window
Toolsets menu
Tools submenu

NN10470-305 01.02 Standard
16.2 May 2007
- 123 -
Start Tool menus

Several Fault tools support one or more pop-up Start Tool menus that let you
start another tool from within that Fault tool. Fault tools that support Start Tool
menus include the following:
Network Status Bar
Network Viewer
Component Status Display
Alarm Display
Component Information Viewer
For information on customizing Start Tool menus, see Nortel Multiservice Data
An example of a Start Tool menu is shown in the figure Sample Start Tool
menu for the Component Status Display (page 123).
Sample Start Tool menu for the Component Status Display
Start Tool
category menu Start Tool menu

NN10470-305 01.02 Standard
16.2 May 2007
- 124 -
Push-buttons in icon bars

The main window of the Network Viewer tool has an icon bar. Currently,
Network Viewer is the only tool that has an icon bar. An icon bar contains a
set of push-buttons, some of which display an icon to indicate what the push-
button does, and others that display a string label.
For information on customizing push-buttons, see Nortel Multiservice Data

The figure Sample icon bar from Network Viewer main window (page 124)
shows the icon bar.
Sample icon bar from Network Viewer main window
Menu definition records

Each entry in Nortel Multiservice Data Manager window menu or in a Start
Tool menu, and each push-button in an icon bar is defined by a set of records
contained in a menu definition file. All menu definition records have a common
syntax.

File syntax (page 124)
Substitution variables in a Start Tool menu definition file (page 134)
Useful OSF/Motif resources (page 135)
Automatic search path (page 135)
Finding menu definition files for the main window menus (page 136)
Finding menu definition files for Start Tool menus (page 138)
Where to find icon bar definition files for the Network Viewer icon bars
(page 140)
File syntax
In a menu definition file, a record for a menu entry consists of one or more
specification lines. General rules for creating such records are as follows:
each record must be followed by at least one blank line
each comment line must begin with an exclamation mark (!)
the information for a record should fit on one line

NN10470-305 01.02 Standard
16.2 May 2007
- 125 -
file path and script path specifications do not need to start with a directory.
If there is no directory, the search paths described in Automatic search
path (page 135) are invoked.
The records in a menu definition file are partial Motif widget resource
descriptions with a few extra resources added. Partial descriptions mean that
you only need to specify the resource name and value; the tools menu system
manages the widget name itself. See Resources for Multiservice Data
Manager tools customization fundamentals (page 109) for more information
about widgets and X resource specifications.
See the following sections for information on the categories into which menu
definition records are grouped:
Include records (page 125)
Menu entry descriptions (including icon bar push-buttons) (page 127)
Titles (page 131)
Separators (page 132)
Submenus (page 132)
Include records
These records are used to call up the contents of other files. Include records
take one the following forms:
#include <file path|GLOB pattern>
#ifinclude <file path|GLOB pattern> <presence test>
where:
include forces the file specified by <file path|GLOB pattern> to be included
ifinclude includes the file specified by <file path|GLOB pattern> only if the
presence test succeeds
<file path> is the pathname of the file to be included. The <file path> can
start with a tilde (~) character, which resolves to your current home directory.
The absolute file path can also contain the string $LANG. See Resolving the
value of $LANG (page 136).
<GLOB pattern> indicates you can use a series of wildcards to expand the
file path. The file path resolves to the first match found for every matching
filename found in a specified absolute path or all paths described in Automatic
search path (page 135) for a specified relative path.
<presence test> specifies a test to determine if the menu item represented

by the record should be visible in the menu. The supported tests are:

NN10470-305 01.02 Standard
16.2 May 2007
- 126 -
-f <file path> checks that the specified file exists
-r <file path> checks that the specified file can be read
-w <file path> checks that the specified file can be written to
-x <file path> checks that the specified file can be executed
-d <file path> checks that the specified file is a directory
-h <file path> checks that the specified file is a symbolic link
-e <script path and arguments> executes the specified script, which

should exit with a return code of 0 to indicate success
The <file path> and <script path> options can include the tilde (~) character,
which resolves to your current home directory. Also, you can include the string
$LANG in either of these options. See Resolving the value of $LANG
(page 136) for more information.
-E <environment variable> [<value>] checks to see if the named

environment variable exists and if a value is specified, whether the variables
value matches. Two additional environment variables are supported that let
many tools use a single menu definition file, but display different menu entries
for different tools. For example, with these variables the entries displayed on
a Start Tool menu can vary depending on which Fault tool is invoking the Start
Tool menu. These two environment variables are:
$APPCLASS identifies the tool loading the menu.
$APPMENU identifies the menu that is being built.
The table $APPCLASS and $APPMENU values (page 127) lists the allowed
values of $APPCLASS for toolset menus and Start Tool menus and the
allowed values of $APPMENU for Start Tool menus. For main window menus,
the value of $APPMENU is the name of the toolset definition file, for example,
Full.tsets.
You can set the value of $APPMENU in a toolset definition file such as
Full.tsets using the tMMenuAppName parameter.
You can also use $@ to test the numerical user-ID value. For example, to allow
certain tools to be invoked only by the root user (user-ID 0), use the following
test:
-E $@ 0.
Other environment variables are substituted as usual.

NN10470-305 01.02 Standard
16.2 May 2007
- 127 -
-L <product license number or name prefix>] checks to see if the

product identified either by license number or name prefix is enabled on the
workstation. For example, -L Global Data Manager verifies if the Global
Data Manager product is licensed on the workstation.
By convention, the toolset definition file and tools definition file are the only
files that contain include and ifinclude records. See Toolset definition files
(page 137) and Tools definition file (page 140) for more information.
$APPCLASS and $APPMENU values
Tool/Target $APPCLASS value $APPMENU value

Component Information Viewer/Alarm List Items CIV CIV-Alarm
Component Information Viewer/Related CIV CIV-Comp
Components List Item
Component Information Viewer/Diagnostic CIV CIV-Diag
Commands
Component Status Display/Component List Item CSD CSD-Comp
Alarm Displays/Alarm List Item IAD AD-Alarm
Network Viewer/Icon Bar ND ND-Icon
Network Viewer/Editing Mode Icon Bar ND ND-IconEdit
Network Viewer/Link Component ND ND-Link
Network Viewer/Node Icon ND ND-Node
Network Viewer/Subcomponent List Item ND ND-Sub-comp
(Subcomponent dialog) or Button (Shelf dialog)
Network Status Bar/Component and Subcomponent StatsBar StatsBar-Comp
List Items
Menu entry descriptions (including icon bar push-buttons)

Menu entries are actually Motif PushButton widgets and therefore support all
of the corresponding Motif resources. There are two main forms of records for
these entries: with and without bitmap image files. Records that specify
bitmap image files are used mainly for defining an icon that appears on a
push-button in an icon bar.
The general form without a bitmap image specification is as follows:

labelString: <menu entry name>
tMCommandLine: <command line to invoke>
tMAction: <internal tool action to invoke>
tMSelectionPatterns: <enabling patterns>
tMPresenceTest: <presence test>

NN10470-305 01.02 Standard
16.2 May 2007
- 128 -
tMPresencePatterns: <pattern alternatives>

helpText: <help information>
<Motif resource line for Push-Buttons>
The general form with a bitmap image specification is as follows:

labelType: pixmap
labelPixMap: <pixmap path>
<Motif resource line for Push-Buttons>
As a minimum, you must specify the labelString record, plus one of the
tMCommandLine or tMAction lines. Explanations for each of these lines are
as follows:
is the name of an entry in a menu or the name of a push-button in an icon bar.

Some Fault tools allow the use of a substitution variable in this string. See
Substitution variables in a Start Tool menu definition file (page 134) for
information about the use of substitution variables in these lines.
labelType: pixmap
is used in icon bars to specify that a push-button should be displayed as an

icon instead of as text. If this line is specified, the labelPixMap line must also
be specified.
labelPixMap: <pixmap path>
is used in icon bars to specify the full path name of the bitmap image to display
as an icon on a push-button. If this line is specified, the labelType line must
also be specified. The icon must be in X-11 Bitmap format.
is the command line to execute when the menu entry or the push-button is
selected. This string is in Bourne shell syntax and executed through the Motif
Session Manager (MSM). The MSM label in the main window displays a
response to indicate when a tool is started.

NN10470-305 01.02 Standard
16.2 May 2007
- 129 -
For some Fault tools, this line can contain a substitution variable that passes
the name of a component or other information along to the tool being started.
See Substitution variables in a Start Tool menu definition file (page 134) for
This line can also be used to invoke a macro. For an example, see Example
2, Creating a submenu item that invokes a macro (page 142).
If this line is specified, omit the tMAction line.
identifies an internal action to perform and its parameter. The internal action
depends on the tool. See Nortel Multiservice Data Manager Fault
ManagementTools (NN10470-011) for more information.
For some Fault tools, this line can contain a substitution variable that passes
the name of a component or other information along to the tool being started.
See Substitution variables in a Start Tool menu definition file (page 134) for
If this line is specified, the tMCommandLine line must be omitted.
are pattern alternatives similar to those provided with the UNIX egrep
command that are used to enable or disable the menu item for certain
components. For example, the pattern ^PM.*|ÔA.*enables the menu item for
DPN-100 modules (PMs) and operations agents (OAs). If this line is omitted,
the menu items is enabled for all components.
specifies a test to be used to determine if an entry should appear in a menu.

The supported tests are:
-f <file path> checks that the specified file exists
-r <file path> checks that the specified file can be read
-w <file path> checks that the specified file can be written to
-x <file path> checks that the specified file can be executed
-d <file path> checks that the specified file is a directory
-h <file path> checks that the specified file is a symbolic link

NN10470-305 01.02 Standard
16.2 May 2007
- 130 -
-e <script path and arguments> executes the specified script, which

should exit with a return code of 0 to indicate success
The <file path> and <script path> options can include the tilde (~) character,
which resolves to your current home directory. Also, you can include the string
$LANG in either of these options. See Resolving the value of $LANG
(page 136) for more information.
-E <environment variable> [<value>] checks to see if the named

environment variable exists and if a value is specified, whether the variables
value matches. Two special environment variables are supported that let
many tools use a single menu definition file, but display different menu entries
for different tools. For example, with these variables the entries displayed on
a Start Tool menu can vary depending on which Fault tool is invoking the Start
Tool menu. These two environment variables are:
$APPCLASS identifies the tool loading the menu
$APPMENU identifies the menu that is being built
The table $APPCLASS and $APPMENU values (page 127) lists the allowed
values of $APPCLASS for main window menus and Start Tool menus and the
allowed values of $APPMENU for Start Tool menus. For main window menus,
the value of $APPMENU is the name of the toolset definition file, for example,
Full.tsets.
You can set the value of $APPMENU in a toolset definition file such as
Full.tsets using the tMMenuAppName parameter.
You can also use $@ to test the numerical user-ID value. For example, to allow
certain tools to be invoked only by the root user (user-ID 0), use the following
test:
-E $@ 0.
Other environment variables are substituted as usual.
-L <product license number or name prefix>] checks to see if the

product identified either by license number or name prefix is enabled on the
workstation. For example, -L Global Data Manager verifies if the Global
Data Manager product is licensed on the workstation.
Multiple tests can be strung together with && (AND) and || (OR) operators. For
example, the following test includes a tool in the menu if the executable is
found and the current DISPLAY is not the main console:
tMPresenceTest: -x /opt/MagellanNMS/bin/svmadm \
&& ^ -E DISPLAY :0.0

NN10470-305 01.02 Standard
16.2 May 2007
- 131 -
are pattern alternatives that are used to make an menu entry visible or hidden.
Unlike a presence test, a presence pattern does not hide a menu entry
permanently. If a presence pattern is specified, the menu item is visible only if
the target component ID matches one of the pattern alternatives. Presence
patterns are only supported in Start Tool menus, where a component ID
context exists.
is used in icon bars to specify a short string of text that is to be displayed in a

dialog when the user selects context sensitive help from a menu, then moves
the cursor to the push-button and clicks the select mouse button.
<Motif resource line for PushButtons>
resources for Motif PushButtons that specify the appearance of the menu item
or push-button. See Useful OSF/Motif resources (page 135).
Titles
Titles are actually Motif Label widgets and therefore support all of the
corresponding resources. The general syntax for a title record is as follows:
labelString: <title name>
tMMenuAppName: <$appmenu env. variable>
<Motif resource line for Labels>
Only the labelString line needs to be specified in a title. Explanations for each
of these lines are as follows:
is the title that appears in the menu. Some Fault tools allow you to use a
substitution variable in this string. See Nortel Multiservice Data Manager Fault
ManagementTools (NN10470-011) for information about the use of
substitution variables in these lines.
is used to set the value of the environment variable $APPMENU. For more
information, see the explanation given on page 126 with
-E <environment variable> [<value>].
specifies a test to be used to determine if an item should appear in a menu. A

number of presence tests are possible. For information about them, see Menu
entry descriptions (including icon bar push-buttons) (page 127).

NN10470-305 01.02 Standard
16.2 May 2007
- 132 -
<Motif resource line for Labels>
are resources for Motif Labels that specify the appearance of the title. See
Useful OSF/Motif resources (page 135).
Separators
Separators are actually Motif Separator widgets and therefore support all of
the corresponding resources. The general syntax for a separator record is as
follows:
tMSeparator:
<Motif resource line for separators>
Only the tMSeparator line needs to be specified. Explanations for each of
these lines are as follows:
tMSeparator:
indicates only that the record is for a separator. By default, this is a single
horizontal line.
specifies a test to be used to determine if an item should appear in a menu. A

number of presence tests are possible. For information about them, see Menu
entry descriptions (including icon bar push-buttons) (page 127).
<Motif resource line for Separators>
resources for Motif Separators that specify the appearance of the separator.
See Useful OSF/Motif resources (page 135).
Submenus
Submenus begin with a submenu header record and end with a submenu
footer record. Submenus can be nested one within another, each of which
must be started with its own submenu header record and terminated by its
own submenu footer record.
Submenu headers are in fact Motif CascadeButton widgets and therefore

support all of the corresponding resources. The general syntax for a
submenu header record is as follows:
tMSubMenu: <submenu name>
labelString: <submenu title>
tMSelection Patterns: <enabling patterns>
tmPresenceTest: <presence test>

NN10470-305 01.02 Standard
16.2 May 2007
- 133 -

<Motif resource line for Cascade Buttons>
The general syntax for a submenu footer record is as follows:
tMEndSubMenu: <submenu name>
Only the tMsubMenu and labelString lines need to be specified in a submenu

header record. Explanations for lines in submenu header and footer records
are as follows:
tMSubMenu: <submenu name>
introduces the submenu. The submenu must be terminated by a

tMEndSubMenu record.
is the name of the submenu as it is displayed in the menu button of the menu
that opens the submenu. Some tools allow you to specify a substitution
variable name in this string that is replaced by the appropriate value when the
menu is displayed.
is used to set the value of the environment variable $APPMENU. For more
information, see the explanation given on page 126 with
-E <environment variable> [<value>].
tMSelectionPatterns:<enabling patterns>
are pattern alternatives similar to those provided with the UNIX egrep
command that are used to enable or disable the entire submenu in certain
contexts. For example, the pattern ^PM.*|ÔA.*enables a command for DPN-
100 modules (PMs) and operations agents (OAs). If this line is omitted, all
components are enabled.
specifies an optional test to be used to determine if the entire submenu should

be included in the menu, at all. The supported tests are identical to those for
line tMPresenceTest described in Menu entry descriptions (including icon bar
push-buttons) (page 127).

NN10470-305 01.02 Standard
16.2 May 2007
- 134 -
are pattern alternatives that are used to make an menu entry visible or hidden.
Unlike a presence test, a presence pattern does not hide a menu entry
permanently. If a presence pattern is specified, the menu entry is visible only
if the target component ID matches one of the pattern alternatives. Presence
patterns are only supported in Start Tool menus, where a component ID
context exists.
<Motif resource line for Cascade Buttons>
resources for Motif CascadeButtons that specify the appearance of the menu
item that causes the submenu to appear. See Useful OSF/Motif resources
(page 135).
tMEndSubMenu: <submenu name>
ends the submenu begun by the tMSubMenu record.
Substitution variables in a Start Tool menu definition file

The following records are an extract from a menu definition file that defines the
Start Tool menu that opens when you select a node in the Network Viewer and
press the select mouse button. The records in the extract define the menu
item that calls up the Component Provisioning tool:
labelString: Component Provisioning
tMCommandLine: /opt/MagellanNMS/bin/pui \
-defaultComponent $DCOMP
tMSelectionPatterns: ^PM.*|ÊM*
tMPresenceTest: -x /opt/MagellanNMS/bin/ppsxterm
Substitution variables, such as $DCOMP (shown in the extract) can be added
to some records in Start Tool menu definition files. These variables are used
for such things as replacing the name of a component in a startup command
with the name of a component an operator has selected in the Network Viewer
main window. The substitution variables allowed depend on the type of record
(labelString, tMCommandLine, or tMAction) and the tool. For a list of the
substitution variables and the records in which they can be used for various
tools, see the following tools in Nortel Multiservice Data Manager Fault
ManagementTools (NN10470-011):
Network Status Bar
Network Viewer
Component Status Display
Alarm Display
By convention, only the records in the extract are used in Start Tool menu
definition files.

NN10470-305 01.02 Standard
16.2 May 2007
- 135 -
Useful OSF/Motif resources

The following OSF/Motif resources are common to the OSF/Motif widgets
used in menus and icon bar push-buttons, titles, separators, and submenus:
background: <background color>
controls the background color of a tools menu entry or a push-button
foreground: <foreground color>
controls the foreground color of a tools menu entry or a push-button
fontList: <font list specification>
controls the font used for in tools menu entry or push-button
alignment: <alignment_beginning|alignment_center
|alignment_end>
controls the way in which the tools menu entry or push-button is displayed: left
justified, centered, or right-justified
shadowThickness: <separator thickness>
is used in separators to control the thickness of the separator bar
Automatic search path

If you do not specify a full path for the menu definition files, the following
standard directories are searched in the following order:
1 $HOME/MagellanNMS
This path is for customized menu definition files for a single Nortel
Multiservice Data Manager user.
2 /opt/MagellanNMS/cfg/tsets/$LANG
This path is for customized menu definition files for the workstation.
3 /opt/MagellanNMS/lib/tsets/$LANG
This path contains the menu definition files provided with Nortel
Multiservice Data Manager software. The menu definition files that come
with the software should never be altered.
The tools menu system applies search paths, $LANG substitutions, and
GLOB pattern matching and picks the first found match for each resolved
filename. This search pattern means that user customizations take
precedence over workstation customizations, which take precedence over
Multiservice Data Manager defaults.

NN10470-305 01.02 Standard
16.2 May 2007
- 136 -
See Resolving GLOB patterns (page 136) and Resolving the value of $LANG
(page 136) for more information on how pathnames are resolved.
Resolving GLOB patterns

You can also use GLOB style patterns to identify file locations. When you use
GLOB style patterns, all matching files are loaded in alphanumeric order as if
they were included individually. The filenames are scanned until a match is
found.
Resolving the value of $LANG

When the string $LANG appears in a pathname, it resolves to one of the
following values in this lookup order:
1 The current setting of the LANG environment variable. The value of this
environment variable can be C for the English language toolset files, ja for
the Japanese language toolset files, or zh for the Chinese language
toolset files.
2 The value C if the LANG environment variable exists but no match is found
with the values described in the previous step.
3 Nothing, if the LANG environment variable does not exist. In this case, the
string $LANG is ignored.
Finding menu definition files for the main window menus

The menu definition files for toolsets menus are grouped in several
subdirectories. Use the following path to find the menu definition files:
<search path>/toolsets/fcaps/<area>/<filename>
where:
search path is one of the paths described in Automatic search path

(page 135). The path /opt/MagellanNMS/lib/tsets/C contains the default menu
definition files that come with Nortel Multiservice Data Manager software.
area is one of the subdirectories that contain menu definition files for entries
on the main window primary menu. See Toolset definition files (page 137) for
information on how these subdirectories are ordered for display purposes.
The following subdirectories come with the software:
fault contains menu definition files for fault menu items. For example
Network Status Bar.
configuration contains menu definition files for configuration menu items.

The tools are organized by device type.

NN10470-305 01.02 Standard
16.2 May 2007
- 137 -
configuration/nrs_common contains menu definition files that are

common between network devices.
accounting contains menu definition files for Management Data Provider

(MDP) menu items.
performance contains menu definition files for performance menu items.
security contains menu definition files for security menu items.
administration contains menu definition files for the administration menu

entries. For example System -> Administration -> System Log Display.
utilities contains menu definition files for utilities menu items. For
example System -> Utilities -> Customer Data.
help contains menu definition files for help menu items.
filename is one of the menu definition files. A menu definition file contains
the records that define one entry on the main window primary menu and the
submenus that cascade from the entry. The names of the menu definition files
begin with a number, which determines the order in which the menu entries
are displayed in the primary menu. Menu definition files for the main window
menus have the extension .tools.
/opt/MagellanNMS/lib/tsets/C/toolsets/fcaps/fault/30fault.tools contains the

menu definition for the general tools file name.
/opt/MagellanNMS/lib/tsets/C/toolsets/fcaps/fault/50circuit.tools contains the

menu definition records for the entry Fault -> Circuit Viewer on the main
window.
/opt/MagellanNMS/lib/tsets/C/toolsets/fcaps/configuration/60service.tools.
/opt/MagellanNMS/lib/tsets/C/toolsets/fcaps/fault/70hpovdt.tools contains the

menu definition for the entry Fault -> HP OpenView NNM on the main window.
The entry Fault -> Circuit Viewer precedes the HP-OV NNM entry, but follows
all other Fault tool entries on the Fault menu because of the values of the
numbers that begin with filenames.
Toolset definition files

The order of the entries on the primary menu is determined by the numbers
that begin the names of the menu definition files. The toolset definition file also
influences both the order of the entries and what entries are visible. There is
only one toolset definition file used in a Nortel Multiservice Data Manager
session.

NN10470-305 01.02 Standard
16.2 May 2007
- 138 -
Toolset definition files are written using the same syntax as menu definition
files. In a toolset definition file, the area subdirectories are listed in the order
in which their menu definition files appear in the primary menu.
For example, in the figure MDM main window and menus (page 122), the
toolset definition file would list the area subdirectories in this order: fault,
configuration, configuration/nrs_common, accounting, performance, security,
administration, utilities, and help.
Use the following path to find the toolset definition files:
<search path>/<filename>
where:

(page 135). The path /opt/MagellanNMS/lib/tsets/C contains the default
toolset definition files that come with the software.
filename is one of the toolset definition files. The default toolset definition
used by Multiservice Data Manager is
/opt/MagellanNMS/lib/tsets/C/Full.tsets. The default value of Full.tsets is set
by the environment variable NMSTSETS. Multiservice Data Manager
software provides a number of toolset definition files that you can use and they
are:
Full.tsets is the default toolset definition file. Admin.tsets,

NMSAdmin.tsets, and User2.tsets are the same as the Full toolset.
These toolsets list the area subdirectories of the menu definition files in the
following order: fault, configuration, configuration/nrs_common, accounting,
performance, security, administration, utilities, help.
User.tsets removes access to some administration tools.

Web.tsets removes access to UNIX by way of the System -> Utilities ->
UNIX Access.
Finding menu definition files for Start Tool menus

The menu definition files for Start Tool menus are grouped in several
subdirectories. Use the following path to find the menu definition files:
<search path>/tools/<application area>/<filename>
where:

(page 135). The path /opt/MagellanNMS/lib/tsets/C contains the default menu
definition files that come with the Nortel Multiservice Data Manager software.

NN10470-305 01.02 Standard
16.2 May 2007
- 139 -
application area is one of the subdirectories that contain menu definition

files for entries on the Start Tool menus. See Tools definition file (page 140)
for information on how these subdirectories are ordered for display purposes.
The following subdirectories come with the software:
top contains menu definition files for menu entries you add to the top of the
Start Tool menu. Until you add menu definition files to it, this subdirectory is
empty.
surv contains menu definition files for the Fault menu entry on the Start Tool
category menu. For example, Component Information Viewer and Alarm Help.
prov contains menu definition files for the Configuration menu entry on the
Start Tool category menu.
misc contains menu definition files for the Utilities menu entry on the Start
Tool category menu. For example, Customer Data and Command Console.
custom contains menu definition files for the Custom menu entry on the Start
Tool category menu. Until you add menu definition files to it, this subdirectory
is empty and the Custom menu entry is not displayed.
bottom contains menu definition files for menu entries you add to the bottom
of the Start Tool menu. Until you add menu definition files to it, this
subdirectory is empty.
filename is one of the menu definition files. A menu definition file contains
the records that define one entry on the Start Tool menu and any submenus
that cascade from the entry. The names of the menu definition files begin with
a number, which determines the order in which the menu entries are displayed
on the Start Tool menu. Menu definition files for the Start Tool menus have the
extension .menu.
Example
/opt/MagellanNMS/lib/tsets/C/tools/surv/10adv_diagnostic.menu contains the
menu definition records for the entry Component Information Viewer and
/opt/MagellanNMS/lib/tsets/C/tools/surv/20adv_performance.menu contains
the menu definition records for the entry DPN Performance Viewer on the
Start Tool menu. See the figure Sample Start Tool menu for the Component
Status Display (page 123).
The entry Component Information Viewer precedes the entry DPN

Performance Viewer on the Start Tool menu because of the values of the
numbers that begin the filenames.

NN10470-305 01.02 Standard
16.2 May 2007
- 140 -
Tools definition file

The order of the entries on the Start Tool menu is determined by the
alphanumeric order of the menu definition files. The tools definition file
influences the order of the entries as well as what entries are visible. A Nortel
Multiservice Data Manager session uses only one tools definition file.
The tools definition file is written using the same syntax as menu definition
files. In a tools definition file, the application area subdirectories as described
in Finding menu definition files for Start Tool menus (page 138) are listed in
the order in which their menu definition files appear in the Start Tool menu. For
example, in the figure Sample Start Tool menu for the Component Status
Display (page 123), the tools definition file would list the application area
subdirectories in this order: top (empty), survs, prov, misc, custom (empty),
and bottom (empty). This order causes the entries for the surveillance tools to
be listed first, followed by the provisioning tools, and the miscellaneous tools.
Use the following path to find the tools definition file:
<search path>/NMSToolsMenu.menu
where:

(page 135). The path /opt/MagellanNMS/lib/tsets/C contains the default tools
definition file that comes with the software.
Where to find icon bar definition files for the Network Viewer icon bars
Icon bars are defined in icon bar definition files, which use the same syntax as
menu definition files. Network Viewer has two icon bars but only one is
displayed at a time.
Use the following path to find the icon bar definition files:
<search path>/<filename>
where:

(page 135). The path /opt/MagellanNMS/lib/tsets/C contains the default icon
bar definition files that come with the Nortel Multiservice Data Manager
software.
filename is one of the icon bar definition files.

NN10470-305 01.02 Standard
16.2 May 2007
- 141 -
The default icon bar definition files that come with the software are:
/opt/MagellanNMS/lib/tsets/C/NDIconBar.menu
This icon bar file defines the icon bar displayed while Network Viewer is
being used in surveillance mode.
/opt/MagellanNMS/lib/tsets/C/NDIconBarEdit.menu
This icon bar file defines the icon bar displayed while Network Viewer is
being used in Network Model Edit mode.
Customization examples
See the following sections for examples of customizing menus and setting
resources in startup options:
Example 1, Setting the startup options in a menu definition file (page 141)
Example 2, Creating a submenu item that invokes a macro (page 142)
Example 1, Setting the startup options in a menu definition file

This section contains two examples that show how to create records that set
resources in startup options for a Nortel Multiservice Data Manager tool in a
menu definition file. The tool used in the examples is the Network Viewer.
You can also set resources in other places, including the user
accounts.Xdefaults set-up file and the Network Viewer default resource
definition file /opt/MagellanNMS/cfg/app-defaults/C/ND. See Resources for
Multiservice Data Manager tools customization fundamentals (page 109) for
information about setting resources by other means.
Starting Network Viewer with labels and icons turned on

When starting the Network Viewer tool you can specify whether labels and
type icons are displayed by default. The following example shows the record
needed to start the tool with the labels shown by default and all icons turned
off.
tMCommandLine: /opt/MagellanNMS/bin/nd \
-xrm ND*showAllabels: True \
-xrm ND*showAllIcons: False"
Setting Network Viewer window position and dimensions as a
startup option
The following example shows the record needed to start the Network Viewer
tool, position the main window of the tool at coordinates 50 and 60, and set
the window size to a width of 600 and a height of 500:
tMCommandLine: /opt/MagellanNMS/bin/nd \
-geometry +50+60 \
-xrm "ND*mainWindow.width: 600" \
-xrm "ND*mainWindow.height: 500"

NN10470-305 01.02 Standard
16.2 May 2007
- 142 -
Example 2, Creating a submenu item that invokes a macro

The following example shows the records needed to create a submenu item
called Current Path that invokes a macro. The macro invoked in this example,
inactive, uses the current connection to display the inactive Processing
Elements (PEs) of a module. The record that invokes the macro also opens
an X-Terminal window that displays the response to the macro. It also display
the words press return in the X-Terminal window to remind you to press the
return key when you have finished reading the output from the macro. For
information about writing macros, see creating macros in Nortel Multiservice
Data Manager Routine MaintenanceUtilities (NN10470-804).
labelString: List Inactive Components
tMCommandLine: /opt/MagellanNMS/bin/nmxterm \
-c inactive r72; \
echo press return ; read <a>
where
<a> is user defined text
Customizing menus for Shared Java and Operator Client tools

You can customize the Launch and Tools menus for the Operator Client Data
Viewer and Nodal Provisioning tools. You can customize only the Tools menus
for the Toolset Data Viewer and Nodal Provisioning tools.
All of the applications in the OC environment are access controlled. Access

control for a user overrides the default and customized menus available to that
user. See Access Control (page 98).
The presence of the items in the menus is defined in the Application Launch
(AL) configuration files for the MT and OC environments. The MT AL
configuration file contains all applications, including those for the JAVA tool
plug-ins, while the OC AL configuration file contains only the Java tool plug-
ins.
Do not modify the existing default AL configuration files. You must copy the file,
place it in the customization location, and edit the copied file.
For the OC environment, the default AL configuration files are stored on the
web server and are located in:
/opt/nortel/config/applications/desktop/jws/MDM/
launchscripts/default
For the MT environment, the default AL configuration files are stored in the
UNIX local file system and are located in:
/opt/nortel/config/applications/desktop/local/MDM/
launchscripts/default

NN10470-305 01.02 Standard
16.2 May 2007
- 143 -
The Launch menu AL files are named with the following syntax:
<Tool name>LM.cfg
The Tools menu AL files are named with the following syntax:
<Tool name>OM.cfg
Each AL configuration file contains a Command Block for each tool with the
parameters that describe the tool presence in the specified menu.See
Example of Command Block in an AL configuration file (page 143).
Example of Command Block in an AL configuration file
Field Entry
Menutype = MenuBar
Menu/Submenu = Configuration
CommandLabel = Nodal Provisioning
CommandType = Plugin
Command = Class=com.nortel.cpt.gui.CoreProvisioningTool,Client=yes,Single=no
SandboxName = NodalProvisioningSandbox_<sandbox_id>
SandboxJars = /opt/MagellanNMS/lib/jar/ANPClient.jar
/opt/MagellanNMS/lib/jar/ ANPShared.jar
/opt/MagellanNMS/lib/jar/ANPTemplateIcons.jar
/opt/MagellanNMS/lib/jar/MdmLib-MftApp.jar
/opt/MagellanNMS/lib/jar/nmsweb.jar
/opt/MagellanNMS/lib/jar/parser.jar
/opt/MagellanNMS/lib/jar/jaxp.jar
/opt/MagellanNMS/lib/mft/pluginJars/applications/sharedJVMApp.jar
Launch menu customization for Operator Client

The Launch menus in the OC desktop menu bar can be customized by adding
a third party tool or by removing an existing tool.
The custom location for new launchscript files and copies of existing
launchscript files is:
launchscripts/custom
To remove a tool from the launch menu, the Command Block must be deleted
from the copy of the *LM.cfg file that has been stored in the custom location.
To add a third party tool a new launchscript file must be created in the custom
location, with a Command Block to describe the parameters for the tools
appearance in the menu.

NN10470-305 01.02 Standard
16.2 May 2007
- 144 -
Attention: A third party tool can be added to the launch only if the
application is present on the client workstation. There must be a local
executable and its full path must be used.
For an example of a Command Bloc created for a third party tool, see Example
of Command Block to launch Outlook (page 144)
Example of Command Block to launch Outlook
Field Entry
Menutype = MenuBar
Menu/Submenu = System/Customer
CommandLabel = My Outlook
CommandType = Local Application
ApplicationType = Fault
ACLevel = ISACLevel
Command = C:\Program Files\Microsoft Office\Office10\OUTLOOK.EXE
Mnemonics launchscript customization

Mnemonics and accelerators for application launch are specified in the plug-
in launchscript files. The following optional parameters are used to specify
mnemonics and accelerators:
MenuMnemonic signals a mnemonic for menu and submenu of the plug-
in menu.
CommandMnemonic defines a mnemonic for the plug-in menu (this is the
CommandLabel in a launchscript configuration file).
Command Accelerator defines an accelerator for the plug-in menu.
In the following table, the MenuMnemonic takes effect if new menus/sub

menus are being defined. Otherwise, the MenuMnemonic is ignored. This
launchscript defines a menu System with underlined letter S to be added to
the Desktop Menu. A submenu Utilities with a mnemonic of U is added to the
System menu. The Operational Commands plug-in is added to the Utilities
submenu. Typing Alt-S followed by U will pull-down the Utilities submenu and
pressing O will launch the Operational Commands plug-in.
The PersistWindow value will cause the Desktop to remember size and
position data of the Operational Commands main window and associate such
data with the authenticated user.

NN10470-305 01.02 Standard
16.2 May 2007
- 145 -
The CommandCluster launchscript parameter groups menu items into

clusters.
Example of a Mnemonic launchscript
Field Entry
Menutype = MenuBar
Menu/Submenu = System/Utilities
CommandLabel = Operational Commands
ApplicationType = Nodal Access
ACLevel = ISACLevel
CommandType= Plugin
Command= Class="com.nortel.mdm.operationalCommands.gui.OperationalCommands",
Client="yes", Single="no"
SandboxName= OperationalCommandSandbox_<sandbox_id>
SandboxJars= MDM/pluginJars/TableLayout.jar MDM/pluginJars/operationalCommands.jar
MDM/pluginJars/MdmLib-General-MftApp.jar MDM/pluginJars/MdmLib-
LoggingNSecurity-MftApp.jar MDM/pluginJars/MdmLib-ServersNCom-
MftApp.jar MDM/pluginJars/MdmLib-GenericGUI-MftApp.jar MDM/
pluginJars/MdmLib-SharedJVM-MftApp.jar
MenuMnemonic= S/U
CommandMnemonic= 0
PersistWindow= True
Window plug-in customization

The desktop provides the ability to persist the size and position of a plug-in
window. The values of size and position are stored when the plug-in is closed
or the desktop is exited by a user. Upon re-launching the plug-in in the same
desktop session or in a new desktop session started by the same user, the
plug-in window will re-open in the same position and with the same size as it
was previously before it was closed using the stored values.
By adding the following attribute value pair persistWindow=YES to a plug-in

launchscript file, a plug-in will have its size and position saved as user
preferences upon exiting. These values will be restored upon restarting. The
running status of a plug-in is not preserved. As a result, a user must manually
re-launch desired plug-ins. It is their size and position that are restored.

NN10470-305 01.02 Standard
16.2 May 2007
- 146 -
Window size and position preferences are user preferences. The key used to
save these preferences is an ID constructed from the plug-in class name and
window title. If there are multiple windows with the same title and plug-in, the
size and position preferences for the last window in focus is saved.
If the Desktop is resized after a plug-in is closed and as a result will be

rendered beyond the current Desktop size, then the window will be placed
such that part will be visible and then be repositioned. Until the window is
repositioned this calculated position will not be saved.
A delete preference script can be used to remove any Desktop saved position
and size parameters. To restore default size and position, the user must either
manually reset them using the preference script or by manually placing each
plug-in main window. The following command removes the Operator Client
preferences for all plug-in windows size and position:
/opt/nortel/applications/desktop/current_desktop/bin/
deletepreferences.sh [ -h ] [ -f ] {-user <user_id> |
[-windows]} | {-local | -jws}
Add the -f switch if no confirmation is required before preference files are
removed.
Window size and position preferences can be saved for sub-windows if

individual plug-in code is modified to generate a consistent identifier for sub-
windows that need to maintain size and position. Maintaining window size and
position preferences is not supported for multiple instances.
Care should be taken to avoid reuse of mnemonics in the same menu. When
customizing, you need to examine existing mnemonics and accelerators to
avoid using duplicates. A duplicate mnemonic or accelerator could be
encountered when:
Two (or more) cfg files specify the same mnemonics for the same Menu /
Submenu
Two (or more) cfg files specify the same accelerator for their
CommandLabel
When duplicates are created, the Desktop will use Java default behavior to
handle them. Based on the current Java behavior, the menu item positioned
higher in the menu is selected first. The other items are selected upon
subsequent typing of the duplicated mnemonics.
The following table contains launchscript tokens and values for MDM plug-ins:

NN10470-305 01.02 Standard
16.2 May 2007
- 147 -
Launchscript tokens and values for MDM plug-ins
Launch Script Name MenuMnemonic Command Persistwindow

Mnemonic
C10NodalProvisioningFC not applicable not applicable Yes
C10PPNodalProvisioningLM C N Yes
C20NPTemplateEditorFC not applicable not applicable Yes
C20PPNPTemplateEditorLM C T Yes
C30MPENodalProvisioningLM C 2P Yes
C40MPENPTemplateEditorLM C 4E Yes
F10AlarmDisplayLM U A Yes
F15AlarmHelpLM.cfg U H N/A
F30NetworkBrowserLM U N Yes
F35NetworkStatusBarLM U B Yes
F50ComponentInformationViewerLM U C Yes
F50ComponentInformationViewerOM M/S/U C Yes
F60PPShelfViewLM U 3S Yes
F60PPShelfViewOM M/S/U 3S Yes
F61MPEShelfViewLM U V Yes
F61MPEShelfViewOM M/S/U V Yes
GC10PPNodalProvisioningOM M/S/C N Yes
GC30MPENodalProvisioningOM M/S/C N Yes
P30DataViewerLM P D Yes
P30DataViewerOM M/S/P D Yes
SA50ServiceSelectionLM S/A U Yes
SA70LogBrowserLM.cfg S/A L Yes
SS10ChangePasswordLM S/S C Yes
SU05OperationalCommandsLM S/U O Yes
SU05OperationalCommandsOM M/S/S/U O Yes
SU10CommandConsoleFC not applicable not applicable Yes
SU10CommandConsoleLM S/U C Yes
SU10CommandConsoleOM M/S/S/U C Yes
SU30telnetPluginLM.cfg S/U 2T N/A
(1 of 2)

NN10470-305 01.02 Standard
16.2 May 2007
- 148 -
Launchscript tokens and values for MDM plug-ins (continued)
Launch Script Name MenuMnemonic Command Persistwindow

Mnemonic
SU30telnetPluginOM.cfg M/S/S/U 2T N/A
SU70OnlineDocumentationLM.cfg S/U D N/A
(2 of 2)
Tool menu customization

The Tools menus can be customized in the OC and MT environments. The
Tools menus allow the user to open up applications from a context within the
Java tools GUIs. Nortel Multiservice Data Manager software provides default
sets of Start Tools for specific context. The administrator can modify
application names or remove applications from the Start Tools menus.
In the OC environment, the custom location for new launchscript files is:
In the MT environment, the custom location for new launchscript files is:
/opt/nortel/config/applications/desktop/local/MDM/
To remove a tool from a Tools menu, the Command Block must be deleted
from the copy of the *OM.cfg file that has been stored in the custom location.
To modify a tool name, the Command Block must be modified in the copy of
the *OM.cfg file that has been stored in the custom location.
Customizing Data Viewer tools menu command entry

The popup tools menu that is displayed when the user right-clicks on a Nortel
Multiservice Switch component in the Component, Spreadsheet, Latest, and
Record views of the Data Viewer can be customized.
Only the following fields in the DataViewerOM.cfg file can be modified:

PresencePattern: used to match the component name obtained form the
source plug-in application. The PresencePattern for Data Viewer is set to
match the relevant device type in the format ^<device type>.*. More than
one device type can be entered by separating each entry with the |.
For example for MSS and MPE device type, respectively:
PresencePattern=ÊM.*|^SRS.*
The option -component <component name> in the Args parameter of the
Command field is used to translate the context data from the source plug-
in application. If the source plug-in has set the <component name> and
the component name satisfies the criteria specified in the

NN10470-305 01.02 Standard
16.2 May 2007
- 149 -
PresencePattern field, then the Data Viewer launch menu will be visible in
the tools menus and can be launched with the component name as the
context.
The entries for the modifiable fields are shown in bold in Data ViewerOM.cfg
file (page 149).
Data ViewerOM.cfg file
Field Entry
Menutype = objectmenu
Menu/Submenu = ExternalLaunches/Start Tools/Performance
CommandLabel = Data Viewer
ApplicationType = Performance
ACLevel = ISACLevel
CommandType = Plugin
Command = Class=com.nortel.mdm.dvr.apps.DataViewer,Clien=yes,Single=no,Args=
-component <component name>
PresencePattern = ^<device type>.*|^<device type>.*
SandboxName = DataViewerSandbox_<sandbox_id>
SandboxJars = /opt/MagellanNMS/lib/jar/dataViewer.jar
/opt/MagellanNMS/lib/jar/ MdmLib.jar
/opt/MagellanNMS/lib/jar/nmsweb.jar
/opt/MagellanContrib/Advent/current/ builder/classes/AdventNetCharts.jar
/opt/MagellanContrib/Advent/current/builder/classes/AdventNetSnmp.jar
/opt/MagellanContrib/Advent/current/builder/classes/jcchartK.jar
Customizing tools menu for SNMP devices

Data Viewer supports SNMP devices through customization and integration.
The tools menu command entry can be customized to launch Data Viewer
with an SNMP device component by adding the <SNMP device type> to the
PresencePattern, as follows: PresencePattern=^<SNMP device type>.*
For example, to create a new command entry for the PP4400 device type:
PresencePattern=^MPA.*
Customizing tools menus for Nodal Provisioning
The information on menu customization for Nodal Provisioning is covered in
NN10470-610 Nortel Multiservice Data Manager Nodal Provisioning User
Guide, chapters Nodal Provisioning Procedures and Nodal Provisioning
Template Editor.

NN10470-305 01.02 Standard
16.2 May 2007
diagnostics
This section describes how to customize the Component Information Viewer
tools Diagnostic menu and details available diagnostic utilities.
Navigation
Diagnostic menu management (page 150)
Component Information Viewer diagnostic utilities (page 152)
Diagnostic menu management

You can customize the diagnostic commands that appear in the Component
Information Viewer diagnostic menus. You customize the diagnostic menu the
same as any other Start Tool menu or tool. Customizing the diagnostic menu
lets you specify the following:
your own command line using substitution variables for the target
component
labels
patterns to determine when the command applies
tests to determine whether or not a command appears in the menu
When customizing, you can use wild cards and presence test patterns.
Component Information Viewer diagnostics supports a resource line that lets

you specify the use of an input dialog. The resource line is as follows:
queryParameter: [<substitution variable name>] \

<prompt string>
Example
Command
queryParameter: $VAL Nb seconds between polls:
queryParameter: Lock the component?

NN10470-305 01.02 Standard
16.2 May 2007
- 151 -
Component Information Viewer diagnostics
If you specify a substitution variable name using the $ prefix, an input dialog
opens and prompts for a value. The input value is then substituted in the
command line where the identified variable name is used. If you do not specify
a substitution variable, a confirmation dialog opens and prompts to continue
or abort the command execution.
The Component Information Viewer diagnostic menus support the existing

tMAction resource. This resource specifies that a command is to be executed
by Nortel Multiservice Data Manager main window, and not directly.
Consequently, no output from the command is expected or displayed in the
Component Information Viewer window. The syntax is as follows:
tMAction: startTool <command and arguments>
The default diagnostic menu is configured in the file

/opt/MagellanNMS/lib/tsets/C/CIVDiagnostics.menu. The file includes some
default items and all item description files found in the following file:
<search path>/dial/*.menu>
where:
<search path> is the usual search path sequence. (see Automatic search
path (page 135)).
To add new diagnostic commands, you need only add a file in the directory
$HOME/MagellanNMS/diag to customize a single user
/opt/MagellanNMS/cfg/tsets/$LANG/diag/ to customize a workstation,
(where $LANG is C for standard-ANSI/English language)
The default Component Information Viewer diagnostic menus provided with

Multiservice Data Manager are located in the directory
/opt/MagellanNMS/lib/tsets/$LANG/diag/ and consist of the following files:
10_PPDiagnostics.menu
for Nortel Multiservice Switch related commands
15_PPTests.menu
for Multiservice Switch related tests and traces
20_PPInventory.menu
for Multiservice Switch Inventory reports
30_DPNDiagnostics.menu
for DPN related commands
40_DPNInventory.menu
for DPN Inventory reports

NN10470-305 01.02 Standard
16.2 May 2007
- 152 -
Component Information Viewer diagnostic utilities

To assist in the creation of diagnostic commands based on device command
macros, use the following utilities:
execDPNCommand (page 153)
execDPNCommand (page 153)
execPPCommand (page 154)
ppCompSelector (page 156)
execWithIPAddr (page 156)
execWithDest
The execWithDest utility performs the following activities:
identifies the default destination as specified in the diagnostic command
Select Command Route
opens the Connection Console to establish the connection when needed
executes a specified command in the context of that connection
The $CMC_CURRENT_ROUTE environment variable stores the selected

destination name. This environment variable is provided at script run time. It
is not a substitution variable of the Nortel Multiservice Data Manager menu
system. If you specify $CMC_CURRENT_ROUTE as a command line
argument to a diagnostic command, then you must ensure that the command
is escaped (\\$CMC_CURRENT_ROUTE) so that it will substitute only at final
execution time.
The command line is as follows:

/opt/MagellanNMS/bin/execWithDest
[-inline]
[-ask|-noask]
[-oa|-group]
[-def <default dest>]
[-mod <module name>]
[-name <command name>]
[<command and args]
Variable definitions
The following variable definitions apply to execWithDest command.

NN10470-305 01.02 Standard
16.2 May 2007
- 153 -
Variable Definition
-inline is used when execWithDest is invoked from a DtKsh script. The
utility is sourced rather than invoked as a subprocess
(. /opt/MagellanNMS/bin/execWithDest -inline). This option
directs the utility not to drop the EPI Command Interface
connection so that the connection can be used again by the
sourcing script.
-ask|-noask controls whether the Connection Console is invoked. If you
specify -ask, the Connection Console always opens. If you
specify -noask, the Connection Console never opens and the
command does not execute if there is no current default
applicable.
-oa|group specifies the destination type
-def <default destination> specifies the default destination name.
-mod <module name> specifies the name of the module and is used in selecting an
appropriate connected destination, if possible
-name <command name> specifies a meaningful name for the command to be executed.
This option is used only for prompts and messages.
<command and args> specifies the command line to execute, in context of the selected
destination. When you source the utility into a DtKsh script,
usually with the -inline option, do not specify the command and
arguments.
execDPNCommand
The execDPNCommand utility executes a single DPN command as a macro
in the context of an OA route similar to execWithDest -OA. The command
line is as follows:
/opt/MagellanNMS/bin/execDPNCommand
[-msg <message>]
[-pe|-pi|-po]
<command> <arguments> <component>
The following variable definitions apply to the execDPNCommand utility.
Variable Definition
-msg <message> outputs the value of a message on the standard output stream before
the command output.
-pe|-po|-pi identifies the level to which the component ID is interpreted.
Superfluous component ID elements are dropeed and the utility
converts the remainder to the appropriate component ID format.

NN10470-305 01.02 Standard
16.2 May 2007
- 154 -
Variable Definition
<command> specifies the command to execute, in context of the selected
destination
<arguments> specifies the command line arguments for <command>
<component> specifies the component ID in canonical format ($COMP, space
separator) that will be used by <command>
The execDPNCommand analyzes the component ID and determines the

module name and subcomponent to be used for the specified command. The
execDPNCommand executes the specified command against the identified
component ID as follows:
<module> [<subcomponent spec.>] <command> <arguments>
The component ID is interpreted as a subcomponent. If you specify a -pe, -pi,
or -po option, the utility interprets the component ID only to the specified level.
For example, the following command invokes the Display Hardware command
on the corresponding PE, even if the target component is more specific.
/opt/MagellanNMS/bin/execDPNCommand -pe d \
hard $COMP
Using the example above with a $COMP value of PM TOTO PE 1 PI 2
PO 2, the following command executes:
<OA dest> TOTO PE 1 d hard
where:
<OA dest> is the OA destination selected by execWithDest
execPPCommand
The execPPCommand utility executes a single Nortel Multiservice Switch
CAS command as a macro in the context of a group route similar to
execWithDest -group. The command line is as follows:
/opt/MagellanNMS/bin/execPPCommand
[-msg <message>]
[-level <category>]
[-selector <patterns>]
<command and options> <arguments> <component>
The following variable definitions apply to the execPPCommand utility.

NN10470-305 01.02 Standard
16.2 May 2007
- 155 -
Variable Definition
-msg <message> outputs the value of a message on the standard output stream before
the command output
-level <category> identifies the category to which the component ID is interpreted.
Superfluous component ID items are ignored
-selector <patterns> appends the specified patterns (separated by a | character) to the
interpreted subcomponent to produce a set of component patterns.
These patterns are used by the ppCompSelector utility to open a
dialog listing all the matching components existing on a target node.
The component selected from the dialog is used for the command
execution. This option allows you to create diagnostic commands for
components that are not managed by fault tools and do not appear in
the CIV Related Components List. For a description of
ppCompSelector, see ppCompSelector (page 156).
The execPPCommand utility analyzes the component ID and determines the

module name and subcomponent to be used for the specified command. The
utility executes the specified command against the identified component ID as
follows:
<module> [<subcomponent spec.>] <command> <arguments>
The component ID is interpreted as a subcomponent. If you specify a -level
option, the utility interprets the component ID only to the specified level. For
example, the following command executes the ping command on the IP ICMP
component of the named Virtual Router (VR), even if the target component is
a VR subcomponent:
/opt/MagellanNMS/bin/execPPCommand -level VR \
ping -ipAddr ($VAL) -traceRoute IP ICMP $DCOMP
Using the example above with a $COMP value of EM TOTO VR 12 PP
FRDTE102, the following command executes:
<group dest> TOTO ping -ipAddr (<value>) -traceRoute \
VR/12 IP ICMP
where:
<group dest> is the destination selected by execWithDest
<value> is the result of a variable substitution specified through a query

parameter dialog
The $VAL is a prompting dialog substitution variable. The execPPCommand

arguments are used to construct the actual component ID that will be used for
the command after the -level option interpretation.

NN10470-305 01.02 Standard
16.2 May 2007
- 156 -
ppCompSelector
The ppCompSelector utility provides a selection dialog with a list of Nortel
Multiservice Switch components matching the specified patterns. The
command line is as follows:
/opt/MagellanNMS/bin/ppCompSelector
[-title <dialog title>]
<group name> <component patterns>
The following variable definitions apply to the ppCompSelector utility.
Variable Definition
-title <dialog title> is the title in the dialog bar
<group name> specifies a group to be used for command access
<component patterns> specifies full component IDs in Nortel Multiservice Data Manager
display format. Specify components using Multiservice Switch CAS
wild cards. Separate multiple patterns with the | character. If you use
wild card in the module name, all matching nodes within the specified
group are used. The group is also used to query the target modules
for the matching subcomponents.
For example, the following command opens a dialog with all LPs of all nodes
in the UNIVERSE group:
ppCompSelector UNIVERSE EM/* LP/*
In the following example, all circuits of a specific ATM interface are used:
ppCompSelector UNIVERSE EM/NODEA05 ATMIF/122 VPC/*|EM/
NODEA05 ATMIF/122 VPT/*|EM/NODEA05 ATMIFf/122 VCC/*|EM/
NODEA05 ATMIF/122 VPT/* VCC/*
execWithIPAddr
The execWithIpAdd utility extracts an IP address, community string or generic
property name for a specified component ID. The IP address, community
string or generic property name is then substituted in the command line and
the command is executed. The command line is as follows:
/opt/MagellanNMS/bin/execWithIPAddr
[-warn|-best-effort] <component ID> <command line>
The following variable definitions apply to the execWithIPAddr utility.

NN10470-305 01.02 Standard
16.2 May 2007
- 157 -
Variable Definition
-warn displays a warning dialog when the IP address or community string
cannot be identified and the command line does not execute. By
default, the execWithIPAddr utility does not display warnings when the
properties cannot be identified.
-best-effort executes the command line when the IP address and community
string cannot be identified, substituting an empty string for the
matching parameter in the command line.
<component ID> specifies the component or subcomponent for which the IP address
and/or community string is required. If the component ID identifies a
sub-component and the property cannot be extracted at that level,
execWithIPAddr automatically tries to fetch them at the module level.
<command line> specifies the command line to be executed. The utility substitutes any
occurrence of %IPADDR% and %COMMUNITY%, or any generic
property name embedded within % characters, in the command line to
the extracted IP address, community string, or generic property name
respectively. If a generic property name is specified and the property
cannot be identified, nothing is substituted in the command line.
You can use this utility to perform IP address substitution using the component
variable IPADDR and the generic property name
NortelMomsProxyIpAddress, for example
/opt/MagellanNMS/bin/execWithIpAddress "EM/<node_name>"
/bin/echo "IP address is %IPADDR% or
%NortelMomsProxyIpAddress%."
You can use this utility to start a Telnet session in context of a selected
component ID, for example
/opt/MagellanNMS/bin/execWithIPAddr -best-effort \
"$COMP" "/bin/telnet %IPADDR%"
To enable context launching, specify the preceding command line in the
Multiservice Data Manager device-type specific tools-menu configuration
files. For details on customizing the toolsets and Start Tool menus, see Nortel

NN10470-305 01.02 Standard
16.2 May 2007
snmpCmd macros
This section contains information to help programmers create snmpCmd
command macros for devices that are monitored using SNMP protocol. These
devices include Passport 4400 series devices.
Navigation
What you need to know (page 158)
Runtime environment (page 158)
About snmpCmd macros (page 162)
What you need to know

Information in this section is directed at programmers who have:
programming experience using Tool Command Language (TCL) as a
scripting language and Scotty for writing interface routines to Simple
Network Management Protocol (SNMP) devices.
You are not limited to writing command macros using TCL and Scotty.
Other languages such as Bourne shell can be used, provided that your
macro provides the capability of setting up an SNMP session to the
managed device. TCL and its extension language Scotty were chosen for
creating the snmpCmd macros supplied with the Nortel Multiservice Data
Manager software because Scotty has the advantage of loading in the
standard ASN.1 MIB directly without the need to run the MIB through a
MIB compiler.
knowledge of the hardware structure and of the Management Information
Bases (MIBs) for the SNMP devices being managed
For the location of directories in which these MIBs are stored, see also
Runtime environment (page 158).
Runtime environment
Tool Command Language (TCL) and Scotty are used to create the snmpCmd
macros that are provided with the Nortel Multiservice Data Manager software
package.

NN10470-305 01.02 Standard
16.2 May 2007
- 159 -
snmpCmd macros
TCL and Scotty executables are part of the Magellan Contrib MagTcl software
package, which must be installed on the workstation along with the
Multiservice Data Manager software package to be able to run snmpCmd
macros.
Paths to the TCL and Scotty executables are set up automatically when the
Magellan Contrib MagTcl package is installed. Paths to these executables are
as follows:
TCL: /opt/MagellanContrib/bin/tclsh
Scotty: /opt/MagellanContrib/bin/scotty
Environment variables related to Scotty and TCL

Environment variables TCL_LIBRARY and TCLLIBPATH need to be set in the
set-up files of the UNIX user account from which macros are to be run.
When the account is set up to run the default Nortel Multiservice Data
Manager environment, the values of these variables are set automatically and
no intervention is required. The method used in the default environment for
setting up the values of the environmental variables is as follows:
For user accounts that run C-shell, the values are set by script
/opt/MagellanNMS/bin/nmscsh which is called by the .cshrc file in the
users home directory.
For user accounts that run Korn or Bourne shell, the values are set by
script /opt/MagellanNMS/bin/nmssh which is called by the .profile file in
the users home directory.
If the account is not using the default user environment, you must take steps
to ensure that these environment variables are set either when the user logs
in or once login is complete.
TCL_LIBRARY
The value of variable TCL_LIBRARY is set to path /opt/MagellanContrib/lib/
tcl17.5. This path provides access to the high level init script for TCL and to
high-level utilities and error checking routines.
TCLLIBPATH
The value of variable TCLLIBPATH is set to the following paths:
/opt/MagellanContrib/lib/tnm2.1.7
/opt/MagellanContrib/lib/tkined1.4.7
/opt/MagellanNMS/cfg/snm
If the Passport 4400 Configuration software package is installed, an additional

path of /opt/MagellanMPA/lib is appended to the values for this variable.

NN10470-305 01.02 Standard
16.2 May 2007
- 160 -
snmpCmd macros
General purposes of the paths are as follows:

Path /opt/MagellanContrib/lib/tnm2.1.7 provides access to the high level
Management Information Bases (MIBs) that are common across all SNMP
devices.
Path /opt/MagellanContrib/lib/tkined1.4.7 provides access to TK routines
for windowing and graphical user interface applications. This path is not
currently used for snmpCmd macros but is provided for future use and for
creating your own windowing applications.
Path /opt/MagellanMPA/lib provides access to the init.tcl file, which
specifies the location of the Passport 4400 series MIBs.
snmpCmd macros
A number of snmpCmd macros are provided with the Nortel Multiservice Data
Manager software. These are located in the following subdirectories of
software library directory
opt/MagellanNMS/lib/cfg/snm/Commands:
GEN contains general command macros.
MPA contains device-specific command macros for Passport 4400 series
devices.
Any snmpCmd macros you write are stored in subdirectories GEN or MPA in
customer configuration directory /opt/MagellanNMS/cfg/snm/Commands.
When attempting to locate a macro, Multiservice Data Manager software first

searches the subdirectories of the customer configuration directory, then
subdirectories of the software library directory. If there are two macros with
same name in these directories, the macro in the customer configuration
directory takes precedence.
If there is a user-defined macro that overrides a Multiservice Data Manager-

supplied macro, an asterisk (*) appears after the macro name when you
display the available commands by running the showcmds macro.
MIBs
A Management Information Base (MIB), is a set of files that list of all the
variables you can use to retrieve management information about SNMP
devices and their interfaces. Locations of the MIBs for SNMP devices used by
snmpCmd macros are as follows:
standard high-level MIBs provided with the Magellan Contrib software
package: /opt/MagellanContrib/lib/tnm2.1.7/mibs
MIBs for Passport 4400 series devices: /opt/MagellanMPA/mibs

NN10470-305 01.02 Standard
16.2 May 2007
- 161 -
snmpCmd macros
Utilities
A number of TCL and Scotty utilities have been created for Nortel Multiservice
Data Manager supplied macros. These are located in file
/opt/MagellanNMS/lib/cfg/snm/Commands/libraryRoutines.tcl. A summary of
these utilities is as follows:
getIpAddr <device type> <device name>
This utility attempts to get the IP address of an SNMP device from a
number of locations, according to the <device type>. For example,
Passport 4400 uses GMDR as the primary source of the IP address. If the
attempt to get the address is unsuccessful, the utility returns a dash (-).
getDevNames <device type> <device name>
This utility obtains a list of devices for the specified <device type>. This
utility can also be used to get subcomponent names of a particular device
by specifying the additional <device name> parameter. For sample usage
of this utility, look at files showdev and showcomp in directory
/opt/MagellanNMS/dev/lib/cfg/snm/Commands/GEN.
getIndexStringFromGMDR <comp id>
This utility accepts a <comp id> parameter, which is used to fetch the
SNMP index from DCD (through GMDR) for a specified component. An
example of a <comp_id> is MPA MPADEV1 CARD 1 PO 1.
The indexes are in the form <index_name>/<index_val>.
The index name is actually the name of a MIB table which indicates that
the index value can be applied to any element in the table. For example, if
the index string returned is ifTable/1.1., it would be possible for the
command macro to get the state of the component by doing an SNMP
GET on ifOperStatus.1.1.
This utility returns the index string returned from GMDR, or - if the index
name was not found, in which case the invoking script can choose another
course of action.

NN10470-305 01.02 Standard
16.2 May 2007
- 162 -
snmpCmd macros
getReadComString <device type> <device name>

This utility gets a read community string value for the specified device type
and/or device name. This value, if present, is stored in an environment
variable in the form:
<device_type> <device_name>_READ_COMMU_STR =<value>
This variable can be set using the setreadcom general macro. If no such
environment variable exists, the utility returns the default value of public.
getWriteComString <device type> <device name>
This utility gets a write community string value for the specified device type
and/or device name. If present, this value is stored in an environment
variable of the form:
<device_type> <device_name>_WRITE_COMMU_STR=<value>
This variable can be set using the setwritecom general macro. If no such
environment variable exists, the utility returns the default value of private.
getSnmpPort <device type> <device name>
This utility gets the UDP port value used to receive SNMP messages for
the specified device type and or device name. If present, this value is
stored in an environment variable of the form:
<device_type> <device_name>_SNMP_PORT=<value>
This variable can be set using the setsnmpport general macro. If no such
environment variable exists, the utility returns the default value of 161.
About snmpCmd macros

Writing snmpCmd macros requires a knowledge of existing Nortel
Multiservice Data Manager supplied snmpCmd macros, the snmpCmd
processor, and how snmpCmd macros interact with the command processor.
This section provides a high-level view of this information.
A set of snmpCmd command macros is provided with Multiservice Data

Manager software. These macros are of two types:
general command macros (GEN) that can be applied to more than one
type of SNMP device
device-specific command macros that can only be applied to a specific
type of SNMP device
General command macros

General command macros supplied by Nortel Multiservice Data Manager
reside in directory /opt/MagellanNMS/lib/cfg/snm/Commands/GEN.

NN10470-305 01.02 Standard
16.2 May 2007
- 163 -
snmpCmd macros
Commands for general snmpCmd macros

Commands to run these macros have the structure:
<command verb> [optional parameters]
where:
<command verb> is the name of an snmpCmd macro in subdirectory GEN of

customer configuration directory /opt/MagellanNMS/cfg/snm/Commands or
software library directory /opt/MagellanNMS/lib/cfg/snm/Commands.
[optional parameters] define what the command verb is to act on. These
depend on the specific implementation of the macro whose name is
<command verb>.
Examples of general commands:

help
help gen showcmd
showdev mpa
showcomp mpa m31
To display the syntax of commands to run Multiservice Data Manager-

supplied snmpCmd macros, see Nortel Multiservice Data Manager Routine
MaintenanceUtilities (NN10470-804).
Summary of general command macros

Because general command macros are equipped with built-in help that
explains their purpose and command syntax, we have only summarized the
command macros in this section.
The general command macros are as follows:

help provides help for a specific Nortel Multiservice Data Manager-
supplied snmpCmd macro. The help information displayed includes the
purpose of the macro and the command syntax for running the macro.
showcmds displays a list of commands for a specified category of
commands (GEN, MPA).
showdev displays the IP address and state of all SNMP devices of a
specified type (MPA) or of a specified SNMP device.
showcomp lists all subcomponents of a specified SNMP device or of a
specified component for an SNMP device.
setreadcom creates an environment variable for a specified read
community string for all SNMP devices of a specified type, or for a single
specified SNMP device. This environment variable can then be used by

NN10470-305 01.02 Standard
16.2 May 2007
- 164 -
snmpCmd macros
any macro that wishes to establish read access to the SNMP device (or
devices).
If the command is entered without a read community string, the
corresponding environment variable is removed and the default value of
public is assumed.
setwritecom creates an environment variable for a specified write
community string for all SNMP devices of a specified type, or for a single
specified SNMP device. This environment variable can then be used by
any macro that wishes to establish write access to the SNMP device (or
devices).
If the command is entered without a write community string, the
private is assumed.
setsnmpport creates an environment variable for the port number used for
establishing sessions to all SNMP devices of a specified type, or to a
single specified SNMP device. This environment variable can then be
used by any macro that wishes to establish a session with the SNMP
device (or devices).
If the command is entered without a read community string, the
port 161 is assumed.
setenvironment contains a template that allows you to run multiple
setreadcom, setwritecom, and setsnmpport commands at a time to set
environment variables at the beginning of a command console session. To
use the macro, edit the macro and add the commands to the macro then
enter setenvironment to run it.
native allows you to direct commands in native SNMP protocol format to a
specified SNMP device.
Device-specific snmpCmd macros

Device-specific command macros supplied by Nortel Multiservice Data
Manager reside the following directory:
macros for Passport 4400: /
opt/MagellanNMS/lib/cfg/snm/Commands/MPA
Commands for device-specific snmpCmd macros

Commands to run device-specific snmpCmd macros have the structure:
<device type> <device name> <command verb> \
[optional parameters]
where:
<device type> is the type of SNMP device such as MPA.

NN10470-305 01.02 Standard
16.2 May 2007
- 165 -
snmpCmd macros
<device name> is the name of the SNMP device.
<command verb> is the name of an snmpCmd macro in subdirectory MPA in

customer configuration directory /opt/MagellanNMS/cfg/snm/Commands or in
the software library directory /opt/MagellanNMS/lib/cfg/snm/Commands.
[optional parameters] define what the command verb is to act on. These
depend on the specific implementation of the macro whose name is
<command verb>.
Example of device specific commands:

mpa mpadev1 showstate card1 en1
To list the device-specific Multiservice Data Manager-supplied snmpCmd

macros available for each of the SNMP devices, to find the syntax of the
commands to invoke them, and to list the optional parameters, see Nortel
Multiservice Data Manager Routine MaintenanceUtilities (NN10470-804).
What happens when you run an snmpCmd macro

Commands to run snmpCmd macros can be entered at:
the Command Console tool
See the section on entering commands in Nortel Multiservice Data
Manager Routine MaintenanceUtilities (NN10470-804).
any application that uses the command console API (cmcmd)
the RNCS tool
See the section on starting RNCS in Nortel Multiservice Data Manager
Fault ManagementRemote Network Communication System
(NN10470-013).
the Embedded Programming Interface (EPI)
See the command access section in Nortel Multiservice Data Manager
Embedded Programming Interface Reference (NN10470-211).
Commands must be directed to the @ route to ensure that they are directed
to snmpCmd processor which then locates the macro and invokes it with the
required variables.

NN10470-305 01.02 Standard
16.2 May 2007
- 166 -
snmpCmd macros
Dataflow diagram for snmpCmd command macros
Application
Local workstation Remote workstation

Sparc (Solaris) running HP OV
(Sparc or HP)
EPI CC Multiservice Data DCD/OVMDR software

Manager software package
package
API
CMCfun
GMDR
Network OVMDR
SNMPcmd element
file
macro
Passport 4400
Running an snmpCmd macro involves the following steps (see the figure
Dataflow diagram for snmpCmd command macros (page 166)):
1 The user sets the command route to @ to indicate that the command is to
run an snmpCmd macro, in one of the following ways:
If you use the Command Console, select @ with the Route menu button.
If you use the API of the CMCFun server (cmcmd), prefix the command
with @.
If you use the RNCS tool, prefix the command with @.

2 The user enters the prefix (if required) followed by the command to run the
macro, along with the required parameters.
3 The CMCFUN server recognizes the @ route and passes the command
to the snmpCmd processor.

NN10470-305 01.02 Standard
16.2 May 2007
- 167 -
snmpCmd macros
4 The snmpCmd processor determines the command category (GEN,

MPA).
5 The snmpCmd processor converts the command verbs to lowercase. This
means that command verbs can be entered in lowercase, uppercase, or
mix of uppercase and lowercase.
6 The snmpCmd processor searches for the macro according to the
command category, as follows:
It searches in one of the customer configuration directories

(/opt/MagellanNMS/cfg/snm/Commands/<category>)
Then it searches in one of the Nortel Multiservice Data Manager software

library directories
(/opt/MagellanNMS/lib/cfg/snm/Commands/<category>).
If it finds two macros with the same name, the macro in the customer
configuration directory takes precedence.
7 If the macro is device-specific, the snmpCmd processor obtains the IP
address of the device as follows:
For Passport 4400, the snmpCmd processor sends a request to the
GMDR server. GMDR sends a property request to OVMDR running on a
remote workstation through the PSERVER. OVMDR automatically obtains
and updates information about SNMP components, including the IP
addresses of PP4400s. This notification requests injection of device and
component information, including the IP address. The IP address is
injected back to IMDR through the PSERVER and is supplied to GMDR
and to the snmpCMD processor.
8 The snmpCmd processor calls the macro and passes it the required
options and parameters as follows:
For a general macro the command structure is <command verb> <optional
parameters>. The snmpCmd processor passes the optional parameters to
the macro.
For a device-specific macro the command structure is <device type>
<device name> <command verb> <optional parameters>. The snmpCmd
processor passes arguments to the macro in the following order:
the device type

the device name
the IP address or - if the IP address cannot be obtained
Having the snmpCmd process pass - to indicate that the IP address

cannot be found provides the macro with the opportunity to take
alternative action, such as displaying the response: no such IP address.

NN10470-305 01.02 Standard
16.2 May 2007
- 168 -
snmpCmd macros
the optional parameters
1 The macro runs. If a device-specific macro is involved, the macro gets the
SNMP device index from GMDR for Passport 4400 devices, translates the
parameters into an SNMP command, and routes the command to the
managed device.
2 Replies and error messages are returned to the originating application.

NN10470-305 01.02 Standard
16.2 May 2007
Alarms in text format
This section describes the instructions for extracting alarms in text format
through the rncsalarm utility.
Navigation
About the rncsalarm utility (page 169)
Command syntax (page 170)
About the rncsalarm utility

Use the rnsmclarm utility to extract alarms from Nortel Multiservice Data
Manager and display them, redirect them to a file or pipe them to another
system. You can also use the Alarm Display tool to save alarms to a file,
however, an operator must be logged in to Multiservice Data Manager.
Consider the following alternatives to the rncsalarm utility for extracting alarms
from Multiservice Data Manager:
using the Alarm and Status API described in Nortel Multiservice Data
Manager Fault ManagementAlarm and Status API Reference
(NN10470-203)
Because of its field selection and filtering capabilities, and its regular
(parsable) output format, the Alarm and Status API is a better source of
information, especially for alarms that need to be processed by other
applications, such as an umbrella management system.
using alarm on-switch alarm spooling facilities
For devices that support it, spooling of alarms is a more reliable way of
collecting alarms for later analysis.
When it is run without the -d and -h options (the default situation), the
rncsalarm utility continuously receives matching alarms from a specified
GMDR server and displays them in a specified format and mode. When it is
run with the -d and -h options, the rncsalarm utility dumps the matching
contents of the Active Alarm list (-d option) or the Alarm History list (-h option).

NN10470-305 01.02 Standard
16.2 May 2007
- 170 -
Command syntax
The command syntax for the rnscalarm utility is as follows:
/opt/MagellanNMS/bin/rncsalarm \
[-d] \
[-h] \
[-f TERSE|NORMAL|FULL] \
[-m DPN|COMMON] \
[-i <component name>]... \
[-n <NTP index>]* \
[-s <severity>]* \
[-l <server name>] \
[-H <server host>]
where:
[-d] dumps the matching Active Alarms
[-h] dumps the matching alarms from the Alarm History list
[-f TERSE|NORMAL|FULL] displays the alarms in TERSE, NORMAL, or

FULL format. By default, alarms are dumped in TERSE format. For an
explanation of the common alarm format see Nortel Multiservice Data
Manager Fault ManagementTools (NN10470-011).
[-m DPN|COMMON] displays the alarms in DPN or COMMON mode. By

default the mode is DPN. For an explanation of these modes, see Nortel
Multiservice Data Manager Fault ManagementTools (NN10470-011).
[-i <component name>]... displays only the alarms for components that
match the specified component name. Adding an asterisk (*) after the
component name displays all alarms matching the specified component
name. You can specify up to 5 -i options. When you specify more than one
component name, alarms matching any of the component names are
displayed. The component name must be specified in API format, with blank
separators and no slashes. For example, EM TOTO LP 2, not EM/TOTO/LP/2.
[-n <NTP index>]* displays only the alarms whose NTP index matches the
specified NTP index. You can specify up to 5 -n options.
[-s <severity>]* displays only the alarms whose severity matches a specified
alarm severity. Valid severities in DPN mode display are: NONE, DEGRADE,
OVERLOAD, MAJOR, and MINOR. For COMMON mode display, valid
severities are: UNKNOWN, WARNING, MAJOR, MINOR and CRITICAL. You
can specify up to 5 -s options.
[-l <server name>] lets you name an alternate GMDR server to connect to.
By default, the server name used is GMDR.

NN10470-305 01.02 Standard
16.2 May 2007
- 171 -
[-H <server host>] lets you override the host on which the connected GMDR
server is running. By default, the host that has been selected for Surveillance
Access with the Service Selection tool is used as the host on which the GMDR
server is running.
If -i, -n, and/or the -s options are specified, only alarms matching all specified
sets of filters are displayed.

NN10470-305 01.02 Standard
16.2 May 2007
Helpsets for MPE devices
This section provides instructions for customizing Multiservice Provider Edge
alarm helpset using the mpegetmod command and for removing helpsets that
are no longer being used.
Navigation
About customizing the MPE helpset (page 172)
Command syntax (page 173)
About customizing the MPE helpset

When an MPE network access server connects to an MPE device, it retrieves
the release version and determines whether the help set for the version needs
to be retrieved. If so, the mpegetmod script is invoked to retrieve the set. The
set is stored with the installed helpsets in /opt/Nortel/MDMDocs/ALM/<MDM-
release-name/C/<MPE-release-version>.
The master Alarm Help index is also updated to reflect the change using the
mpegetmode script. In addition, the script is used to retrieve the configuration
data model from a Multiservice Provider Edge device. This script is also used
to retrieve the configuration data model from an MPE device. The update
process is illustrated in Alarm help update process (page 173).
This process is automatically triggered on device connection, but a user can

also manually invoke it from the command line.

NN10470-305 01.02 Standard
16.2 May 2007
- 173 -
Helpsets for MPE devices
Alarm help update process
Command syntax
The command syntax for the mpegetmod command is:
mpegetmod
[-h]
[-version <version>]
[-u <device> <user-id> <password>]
[(-a | -xa)]
[-fa
[-da]
Variable Definition
-h provides the usage information to the user.
-version version specifies the version of MPE software being run.
-u <device> <user-id> specifies the MPE device name/ip address, user ID and
<password> password.
-a retrieves the alarm help file in addition to the configuration
model file
-xa retrieves only the alarm help file
-fa forces the retrieval of the alarm help file if it already exists
-da removes the specified version of the alarm help file

NN10470-305 01.02 Standard
16.2 May 2007
Copyright 2007 Nortel Networks. All Rights Reserved
Sourced in Canada and the United States of America.
Publication: NN10470-305
Document status: Standard
Document issue: 01.02
Document date: May 2007
Product release: 16.2
Job function: Administration and Security
Type: NTP
Language type: U.S. English
Nortel, the Nortel logo, and the Globemark are trademarks of Nortel Networks.
To provide feedback or report a problem with this document, go to www.nortel.com/documentfeedback.

NN10470 305

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

NN10470 305

Transféré par

Droits d'auteur :

Formats disponibles

Nortel Multiservice Data Manager

Sourced in Canada and the United States of America.

Copyright 2007 Nortel Networks. All Rights Reserved.

Disruptive Command Safeguard 22

Fundamentals for configuring Multiservice Data Manager servers

Nortel Multiservice Data Manager

Grouping nodes for surveillance access 28

Fundamentals for configuring Multiservice Data Manager servers

Multiservice Switch SDD file management 51

Nortel Multiservice Data Manager

Network time synchronization 58

Maximum heap size 69

Multiservice Data Manager server maintenance fundamentals

Multinodal Naming Service domains 78

Multinodal Naming Service TCP/UDP port mappings 82

Network access data mediation 84

Multiservice Switch alarm clearing and storage 94

Nortel Multiservice Data Manager

User interface customization fundamentals 97

Resources for Multiservice Data Manager tools customization

Menu customization fundamentals 121

Nortel Multiservice Data Manager

Push-buttons in icon bars 124

Component Information Viewer diagnostics 150

snmpCmd macros 158

Nortel Multiservice Data Manager

Alarms in text format 169

Helpsets for MPE devices 172

Nortel Multiservice Data Manager

Nortel Multiservice Data Manager

Conceptual information supporting the Nortel Multiservice Data Manager

Nortel Multiservice Data Manager

Multiservice Data Manager server maintenance fundamentals overview

Nortel Multiservice Data Manager

Multiservice Data Manager User Environment

Nortel Multiservice Data Manager

To run properly, Multiservice Data Manager requires the setting of global

For an example of the directory structure for a workstation with Multiservice

The subdirectories of /opt/MagellanNMS and their contents are as follows:

Nortel Multiservice Data Manager

Nortel Multiservice Data Manager

2 /opt/MagellanNMS/ext/lib/model/types (second-party customization)

Like the main,/opt/MagellanNMS/bin and /opt/MagellanNMS/lib, consider

Sample directory structure

Directories that are read-only to the MDM tools

NMS110DaaS2400/ (A specific software load)

bin -> /opt/MagellanNMS/loads/NMS110DaaS2400/bin

data/ (Local data files)

nrs/rdf/[ppe|ppc|dpn|custom] (RDFs for NRS)

cfg/ (Local configuration files)

MagellanMDP/ (MDP software)

MagellanNTP/ (NTPs and context-sensitive

... (Other Nortel software such

Symbolic links to directories in the active load

Nortel Multiservice Data Manager

Default MDM user environment skeleton files

Nortel Multiservice Data Manager

/opt/MagellanNMS/bin/rncsuser to copy the files for an RNCS user

The skeleton files are all located in directory /opt/MagellanNMS/system/skel.

The skeleton files and their contents are as follows:

Nortel Multiservice Data Manager

Nortel Multiservice Data Manager

Global environment variables