Services Configuration File
The Services Configuration Data File (system.dat) configures services for operation. It determines how services are defined, which default flags to use, on which computers, and how long the waitfor timer runs. The system.dat file is located in the $NMS_HOME/etc directory.
There are a number of sections in the system.dat file. The most critical sections include:
• scripts
• server
• services
• applications
• program
• instances
Scripts
The following table defines the scripts that SMService uses to perform various tasks.
 
Script
Description
LaunchScript
Used to launch a service. The most widely used mechanism for starting all the services is:
sms-start
The default script to start a single service is sms‑start‑service. Its syntax is:
sms-start-service [host] [service] [process] [options]
• host: Name of the machine on which to run the service
• service: Name of the service
• process: Name of the executable that launches the service
• options: Command line options that are passed to the process at initialization
 
For example, to start DBService, type:
sms-start-service train1 DBService DBService -nodaemon
Define the launch script in system.dat as follows:
LaunchScript [script name]
If no script is specified, then sms-start-service is assumed.
Notify Script
Announces an event. This script eliminates the need for an isis tool as an announcer. It can be used to generate e-mails and logs, or to interface to paging systems. When developing this script, keep in mind that it does not connect to isis. The syntax is:
[script name] [time] [host] [process] [event type] [system state]
[old system state] [message]
• time: Date/time stamp.
• host: Name of the machine on which the processes are running.
• process: Name of the process.
• event type: The process state. Valid values are:
• STARTING: The process has started.
• INITIALIZING: The process has registered and is initializing.
• RUNNING: The process reports as initialized.
• FAILED: The process has failed.
• FAILED_INTERFACE: The process reports a failed interface.
• STOPPED: The process intentionally stops.
• INFO: The process generates a progress report.
• system state: State of the system. Valid values are:
INITIALIZING: SMService is launching processes from system.dat.
NORMAL: All processes are running or are intentionally stopped.
WARNING: A non-critical process has failed. This state also refers to failed critical
processes that have another instance running.
CRITICAL: A critical process has failed and there are no other instances running.
• old system state: State of the system before the event generating the announcement occurred.
• message: Message supplied by SMService or the process that caused the event.
 
Define the notify script in system.dat as follows:
NotifyScript [script name]
There is no default value, so if a script is not defined here, then only isis announcements are generated.
CoreScript
SMService looks to this script for instructions when a core file is detected. This script determines what should be done with the file, such as announce the existence of the file, delete it, archive it, or e-mail the administrator. It does not connect to isis. Its syntax is:
[script name] [process] [corefile]
process: Name of the process that has produced the core file
corefile: Path to the core file
Define the core script in system.dat as follows:
CoreScript [script name]
If a script is not defined, the core file remains and will be detected by SMService during the next cycle.
Example Scripts
The following scripts demonstrate defaults/examples and show how SMService can be extended.
 
Name
Description
sms‑notify
This is a NotifyScript and can be configured as the notify script in system.dat (this example is very simple), it merely calls the notify by email script.
sms‑notify‑by‑email
This is a somewhat more advanced script for sending notifications of selected events to a group of administrators by email.
The script uses the information supplied by SMService on the command line to determine if this event is putting the system into a critical state - or is clearing a previously existing critical state. If either of these two events are detected an email is constructed and sent to the appropriate people.
The script is quite configurable and can be easily modified to change the names of the recipients, the mailer program used to generate the email, etc.
This script can be configured directly as the NotifyScript in system.dat, or it can be invoked by an intermediate script such as sms‑notify .
sms‑core‑save
This is an example of a CoreScript. It simply moves the core file to an archive directory and renames it based on machine name, process name and timestamp. It then generates an email to the administrators to inform them that a core file was found.
sms-start
This script is the way you start the NMS services. SMService is launched and then smsReport is run in one-shot mode. This means that the script will run until SMService starts reporting a system state as something other than initialized sms-start uses the Action command to determine if SMService is already running on this machine. If it is, it simply sends it a restart message.
 
Server
This section of the system.dat file defines all machines that run services. Each server must be assigned a separate server ID number from 1 to 10. The format is:
service [hostname] [server id]
For example, for services running between machines london and paris:
server london 1
server paris 2
The value for hostname can be specified literally as <local>. If this is the case, then SMService will automatically substitute the name of the current node as the machine name. For example:
server [local] 1
Support for running NMS Services on multiple nodes is a legacy option; the only practical and supported option is to use the "server [local] 1" type configuration.
Parallel Start
This entry specifies whether services will be started in parallel.
parallelStart 1
If set to 0 or omitted, services will be started serially in the order the instance lines appear in this file. SMService will wait for each service to report that it is running before starting the next service. If set to 1, services will be started in parallel. This is faster, but the <start> parameter for each service line must account for the extra time a service takes waiting for another service it depends on to start. This parameter can be overridden by passing the -parallel or -p option to sms-start to force services to start in parallel or by passing the -serial or -s option to sms-start to force services to start serially. parallelStart is turned on in system.dat.template, but not system.dat.init.template or system.dat.model_build.template.
Service
These entries in the system.dat file are definitions of services and process groups, such as interfaces, that are launched and monitored by SMService. Below is a sample service section:
# NAME
REQUIRED
START
DELAY
RESTARTS
RESET
MODE
service SMService
Y
60
0
10
86400
 
service DBService
Y
90
0
10
86400
 
service ODService
Y
180
0
10
86400
 
service DDService
Y
180
0
10
86400
 
service MTService
Y
180
0
10
86400
 
service MBService
Y
180
0
10
86400
 
service JMService
Y
280
0
10
86400
 
service SwService
Y
280
0
10
86400
 
service PFService
Y
4000
0
10
86400
 
service FLMService
Y
4000
0
10
86400
 
service FLTService
Y
4000
0
10
86400
 
service VVOService
Y
4000
0
10
86400
 
service corbagateway
Y
120
0
10
86400
 
service service_alert
Y
120
0
10
86400
 
 
The following table describes the SMService Service fields.
Field
Description
NAME
The name of the executable for the particular service.
REQUIRED
Indicates whether the instance of the service is required for the system to be functional. Valid values are ‘Y’, ‘Yes’, ‘N’, or ‘No’. If there are no instances of a required service, the system locks until an instance is started.
START
The time taken for a service to start. If the service is not running after this many seconds, it is considered failed. If services are started in parallel (if parallelStart is set to 1 in system.dat or sms‑start -p is used). This value must take into account the start time of each of the services this service depends on.
DELAY
Sets the number of seconds to wait before restarting a failed service. It only applies to processes that failed after they were running. Processes that fail before initialization are restarted based on the period parameter. A negative number indicates that the process is not restarted.
RESTARTS
The number of times to attempt restarting a process. A process is no longer automatically restarted after this value is exhausted until the process is reset (see below).
RESET
The timeout period that controls the rate at which processes are reset. When a process is reset, the restart counters re-initialize. A negative value deactivates this feature.
MODE
An optional argument that specifies the high availability mode of the service. If a mode is specified, the service starts with -[mode] and -number [n], where [n] is the id defined for the node in the server line. Valid modes are exclusive, redundant, parallel or not specified.
Exclusive runs with only one server.
Redundant specifies running two servers, each with a database that mirrors the other.
Parallel involves using Oracle Parallel Server to run two servers with a shared database.
Program
The program section of the system.dat file defines the executable program and command line options for each service. This section is optional, but can be used for the following:
• Specifying an alternative executable for a particular service. For example, setting TCDBService as an instance of DBService.
• Specifying command line options across all instances of a service. This simplifies the instance definition so that the command line options do not have to be duplicated for each definition.
Below is a sample applications section:
 
# NAME
EXE
ARGS
program DBService
DBService
-nodaemon
program ODService
ODService
-nodaemon -aggregates
program DDService
DDService
-nodaemon -zones -subscribezone -allowReset
-alarms ALL
program MTService
MTService
-nodaemon
program MBService
MBService
-nodaemon
program JMService
JMService
-nodaemon -dbs
program SwService
SwService
-nodaemon
program PFService
PFService
-nodaemon
program FLMService
FLMService
-nodaemon
program FLTService
FLTService
-nodaemon
program VVOService
VVOService
-nodaemon
program corbagateway
Corbagateway
-nodaemon
-ORBInitRef NameService=iioploc://[hostname]:1750/NameService
-ORBLogFile /users/[username]/dialog_log/orb.log
-ORBDebugLevel 3
-implname InterSys_[hostname]_[username]
-iorfile /users/[username]/etc/[username]_vns.ior
-publisher
-xmldir /users/[username]/dist/wwwroot/xml
program service_alert
Mycentricity
-nodaemon -xmldir /users/[username]/dist/wwwroot/xml
 
 
 
 
The following table describes the SMService Program fields.
Field
Description
NAME
Specifies the name of the service that the executable belongs to. Valid services for this value are defined in the service section.
EXE
Specifies the name of the executable that runs the service.
ARGS
Defines the command line options that are used in all instances of the service.
displayName
The displayName section of the system.dat file defines the display name for executable programs. This section is optional, but can be used to define user-readable names for the executables.
Below is a sample displayName section:
# NAME DISPLAY NAME
displayName SMService System Monitor Service
displayName DBService Database Service
displayName TCDBService Trouble Call Database Service
displayName MBDBService Model Build Database Service
displayName ODService Object Directory Service
displayName DDService Dynamic Data Service
displayName MTService Managed Topology Service
displayName MBService Model Build Service
displayName JMService Job Management Service
Instance
The instance section of the system.dat file defines how the services are started. The format of each line is:
instance [node] [service] [database/args]
The following example starts nine services on the local node.
#
NODE
SERVICE
DATABASE/ARGS
instance
[local]
SMService
 
instance
[local]
DBService
 
instance
[local]
ODService
 
instance
[local]
DDService
 
instance
[local]
MTService
 
instance
[local]
JMService
 
instance
[local]
SwService
 
instance
[local]
corbagateway
 
instance
[local]
service_alert
 
The following table describes the SMService Instance fields.
 
Field
Description
NODE
Defines the node. Valid nodes for this value are defined in the server section.
The value for NODE can be specified literally as [local]. If this is the case, then SMService will automatically substitute the name of the current node as the instance for which the service is to be started. By using [local] in place of a specific machine name, you can simplify your effort when replicating a system; you will not need to make changes to the system.dat at all.
SERVICE
The service being defined.
DATABASE/ARGS
Command line arguments that are applied when the service starts at this node. If the program section specifies command line options for a particular service, it applies to all nodes, so the arguments do not need specification here.
 
See Appendix A - Command Line Options and High Level Messages for service command-line options and Action commands.