Background Processes on the SMS

Overview

This chapter provides a description of the programs or executables used by the System as background processes on an SMS.

Executables are located in the /IN/service_packages/SMS/bin directory.

Some executables have accompanying scripts that run the executables after performing certain cleanup functions. All scripts should be located in the same directory as the executable.

For more information about the processes and systems that use these programs and executables, see System Overview.

Note:

It is a pre-requisite for managing these core service functions that the operator is familiar with the basics of Unix process scheduling and management. Specifically, the following Unix commands:

init (and inittab)
cron (and crontab)
ps
kill

cmnConfigRead

Purpose

cmnConfigRead is used by the installation process to read the configuration files.

cmnConfigRead reads the Convergent Charging Controller configuration file (eserv.config), specified by the Oracle_CONFIG_FILE environment variable and returns the value of path.

This can be used in commands to return the eserv.config specified path value.

Example:

FILENAME=`cmnConfigRead CCS.MyReport.filename

/IN/service_packages/CCS/tmp/MyReport.log`

This sets $FILENAME to the value of CCS.MyReport.filename. If CCS.MyReport.filename is not present or there is an error, $FILENAME defaults to /IN/service_packages/CCS/tmp/MyReport.log.

Startup

cmnConfigRead is started by the system and is not intended to be changed by the user.

cmnReceiveFiles

Purpose

cmnReceiveFiles collects EDRs from cmnPushFiles and writes them to the specified directory on the SMS.

WARNING:

You must install the xinetd daemon as a prerequisite to running cmnReceiveFiles. You install this daemon by entering the following command:

yum install xinetd

Startup

cmnReceiveFiles is started by the following entry in /etc/inetd.conf:

smsoperFile    stream tcp    nowait smf oper    /IN/service_packages/SMS/bin/cmnReceiveFilesStartup.sh   cmnReceiveFilesStartup.sh

Parameters

cmnReceiveFiles does not have any direct parameters or configuration. Most details are provided by cmnPushFiles with the EDR.

The port cmnReceiveFiles listens on is set in /etc/services in the following line:

smsoperFile 2028/tcp # cmnAddInetServicesEntry

Note:

The port number must match the port specified by cmnPushFiles.

Failure

If cmnReceiveFiles fails, the EDRs stay on the SLC and are moved to the retry directory. For more information about this process, see cmnPushFiles.

Output

cmnReceiveFiles writes the EDRs to the directory specified by cmnPushFiles.

smsAlarmDaemon

Purpose

The smsAlarmDaemon executable runs on all alarm-managed nodes in the SMS system, including the SMS node itself. The role of smsAlarmDaemon is to gather alarms from the following sources:

Error messages log (/var/adm/messages)
Oracle error log ($ORACLE_BASE/admin/SID/bdump/alert_SID.log)
Sigtran stack logs (/IN/service_packages/SLEE/stats) [If installed]

On the SMS machine itself, the error messages are written directly into the SMF_ALARM_MESSAGE database table. When run on other nodes, replication is used to update the SMF_ALARM_MESSAGE table.

Alarm replication and buffering

smsAlarmDaemon allows only a limited number of alarms to be sent within a configured time period. Both the number of messages that can be sent within a time period and the length of each period can be configured from the command line.

If more messages arrive than are allowed through the filter, the remaining messages are buffered and sent later. The buffer size is limited but can hold a large number of messages. If it needs to make more space, it discards messages of the lowest severity (informational). The buffer also has an upper limit, ensuring that the daemons do not grow unchecked. This upper limit defaults to a maximum of 1000 messages and can be configured.

If more than one of the same alarm appears within the configured time, only one update request is sent.

Startup

In an unclustered install, this task is started by entry sms5 in the inittab, through the /IN/service_packages/SMS/bin/smsAlarmDaemonSmsStartup.sh shell script.

In a clustered install, this task is started by the clustering software, through the /IN/service_packages/SMS/bin/smsAlarmDaemonCluster.sh shell script.

Configuration

smsAlarmDaemon accepts the following command-line arguments.

Usage:

smsAlarmDaemon [-l seconds] [-h seconds] [-n number] [-m number] [-p] [-d] [-a path] [-r node] [-u user/pass] [-f] [-i] [-g] [-c number] [-t seconds]

The available parameters are:

Parameter	Default	Description
`-a path`	Null	Propagate alarms from the specified Oracle alert log to the database. By default, smsAlarmDaemon does not propagate alarms from the Oracle alert log.
`-c number`	1	Commit Rate. The number of inserts before committing to the database.
`-d`	Sort messages	Disable sorting of messages in the buffer by severity. Specifically, messages are kept in the buffer and subsequently written into the SMF database, in the same sequence in which they are received.
`-f`	No filtering	Filtering. Delete duplicate alarms and increase the alarm count.
`-g`	Uses local time	GMT timezone. Use GMT instead of local time.
`-h seconds`	60	Heartbeat message. Will be forced to be greater or equal to time period (seconds).
`-i`	Use fuzzy matching	Filtering type. Use exact matching (rather than fuzzy matching). Indicates that duplicate matches should be performed on text only (that is, excluding digits). Note: Only valid when used in conjunction with -f.
`-l seconds`	2	Filter Period. Duration between linked-list checks (in seconds).
`-n number`	5	Filter Number. The number of alarm messages allowed within the time period. Allowed values: Integers
`-m number`	1000	Maximum number of alarm messages to buffer. Allowed values: Integers 1-1000000
`-p`	Do not drop messages	Drop low-priority messages when the buffer is full. Specifically, when -m number messages have been received but it is not yet time to write the buffer contents to the SMS database, low priority messages in the buffer are dropped in favor of higher-priority messages that may be received on its input stream.
`-r node`	Direct to the Oracle DB	Replication node. Specify the replication requester node.
`-t seconds`	1	Commit interval. The maximum interval between database commits (in seconds).
`-u user/pass`	/	Use the supplied Oracle user/password pair.

Usage example

Here is an example of using smsAlarmDaemon:

smsAlarmDaemon -l 5 -h 30 -n 10 -m 2000 -p -d -a /volB/home/saich -r 750 -u smf/smf -f -i -g -c 2 -t 2

Filter Period (-I) = 5 seconds
Commit Interval (-t) = every 2 seconds if 2 records not reached
Commit Rate (-c) = every 2 number of inserts
GMT timezone (-g) = Yes
Filtering type (-i) = Exact match
Filtering (-f) = Multiple alarms combined
Oracle User (-u) = smf/smf
Rep node (-r) = 750
Oracle Alert Log location (-a) = /volB/home/saich
Sort messages by severity (-d) = false
Drop low priority messages (-p) = true
Max number(-m) = 2000 records
Filter Number (-n) = 10 each period
Heart beat (-h) = Yes every 30 seconds

Failure

The smsAlarmDaemon on each alarm-managed node in the installation will by default generate a health-check alarm once per minute. These health check alarms will be relayed in the same fashion as all other alarms.

If these health check alarms are not received at the target destination, then the smsAlarmDaemon may have failed, and should be investigated.

Output

The smsAlarmDaemon writes error messages to the system messages file, and also writes additional output to /IN/service_packages/SMS/tmp/smsAlarmDaemonSms.log.

smsAlarmManager

Purpose

The smsAlarmManager runs on the SMS. The role of the smsAlarmManager is to:

Match alarm instances to the correct alarm types
Automatically time out alarms that have not been cleared
record alarm instances that have no alarm type match

Startup

This task is started by entry efm1 in the inittab, through the /IN/service_packages/EFM/bin/smsAlarmManagerStartup.sh shell script.

The inittab entry will be similar to that shown below:

efm1:34:respawn:su - smf_oper -c "exec /IN/service_packages/EFM/bin/smsAlarmManagerStartup.sh >> /IN 
/service_packages/EFM/tmp/smsAlarmManager.log 2>&1" > /dev/null 2>&1 0<&1

Configuration

The smsAlarmManager accepts the following command line arguments.

Usage:

smsAlarmManager -a alarm_batch_size -c correlate_batch_size -o timeout_commit_rate -p pending_timeout_length -r reload_defn_interval -s number -t timeout_check_interval -u user/password

The available parameters are:

Parameter	Default	Description
`-a alarm_batch_size`	20	The number of alarms to attempt to find an ID for before carrying on to other tasks.
`-c correlate_batch_size`	20	The number of non-correlated CLEAR alarms to attempt to correlate against open alarms before carrying on to other tasks.
`-o timeout_commit_rate`	1000	The number of rows to update with automatic timeout before committing.
`-p pending_timeout_length`	280	The amount of time given to another node in the cluster before assuming that it has failed to generate an ALARM_TYPE_ID
`-r reload_defn_interval`	86400	interval (s) for reloading the alarm definitions for the DB. Interval between reloading the regular expressions from SMF_ALARM_DEFN and SMF_ALARM_IGNORE. This should only be needed after an install of new packages/patches, and also acts to keep the preferred cache current
`-s`	50000	interval (microseconds) to sleep for when no work to do
`-t timeout_check_interval`	300	Interval between checks for alarms that need to be closed with a timeout.
`-u "user/password"`	/	u ”/” The username/password combination used to log into the database. The default value is sufficient if smsAlarmManager is run from the smf_oper user account.

smsAlarmManager will respond to SIGHUP, to reread the regular expressions from the database.

Failure

On startup the smsAlarmManager logs the following information:

smsAlarmManager startup. 
Alarm Batch Size = 20 
Correlate Batch Size = 20 
Pending Timeout Length = 280 
Timeout Check Interval = 300 
Reload Defn Interval = 86400 
Timeout Commit Rate = 1000 
Sleep Time (microseconds) for no Work = 50000 
Username/Password = / 
Aug 30 15:31:07 smsAlarmManager(18347) NOTICE: smsAlarmManager started. 
Cache successfully reloaded

Output

On startup the smsAlarmManager logs the following information:


smsAlarmManager startup.
        Alarm Batch Size = 20
        Correlate Batch Size = 20
        Pending Timeout Length = 280
        Timeout Check Interval = 300
        Reload Defn Interval = 86400
        Timeout Commit Rate = 1000
        Sleep Time (microseconds) for no Work = 50000
        Username/Password = /
Aug 30 15:31:07 smsAlarmManager(18347) NOTICE: smsAlarmManager started.
Cache successfully reloaded

smsAlarmRelay

Purpose

The smsAlarmRelay is responsible for implementing the SNMP Agent. It runs continuously, polling the database to check for new entries written into the SMF_ALARM_MESSAGE table by the smsAlarmDaemon processes running on the various managed nodes which form the SMS-managed installation.

The information in the SMF_ALARM_MESSAGE is relayed to the destinations, as configured in the SMF_ALARM_HANDLER table using the Alarm Notification screens. For more information about how to configure alarm relay destinations, see the Service Management System User's Guide.

You can configure smsAlarmRelay to do the following:

Send X.733 information with all forwarded alarms
Check for SNMP requests (to resend alarms)
Send version 3 (instead of version 1) SNMP traps

Startup

In an unclustered installation, this task is started by entry sms1 in the inittab, through the /IN/service_packages/SMS/bin/smsAlarmRelayStartup.sh shell script.

In a clustered installation, this task is started by the cluster software, through the /IN/service_packages/SMS/bin/smsAlarmRelayCluster.sh shell script.

Parameters

The smsAlarmRelay accepts the following command line arguments.

Usage:

smsAlarmRelay [-u <usr/pwd>] [-s <secs>] [-p] [-x] [-t] [-e]

Note:

SNMP processing is not currently enabled by default.

The available parameters are:

-u

Syntax:	`-u user/pwd`
Description:	The Oracle user and password pair.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	/
Notes:
Example:

-s

Syntax:	`-s seconds`
Description:	The number of seconds to sleep between database checks.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	1
Notes:
Example:

-p

Syntax:	`-p`
Description:	Whether to do SNMP processing or not.
Type:	Boolean
Optionality:	Optional (default used if not set).
Allowed:	set: Use SNMP not set: Do not use SNMP
Default:	not set
Notes:
Example:

-x

Syntax:	`-x`
Description:	Whether to send SNMP traps in X.733 format or not.
Type:	Boolean
Optionality:	Optional (default used if not set).
Allowed:	set: Use SNMP not set: Do not use SNMP
Default:	not set
Notes:
Example:

-t

Syntax:	`-t`
Description:	Whether to format the enterprise id with the severity.
Type:	Boolean
Optionality:	Optional (default used if not set).
Allowed:	set: Use SNMP not set: Do not use SNMP
Default:	not set
Notes:
Example:

-e

Syntax:	`-e`
Description:	Loads the EFM rules from the smf_alarm_relay_filter database table to provide alarm filtering.
Type:	Boolean
Optionality:	Optional.
Allowed:	Set or not set.
Default:	Not set

Resend Alarms

The smsAlarmRelay can be configured to listen for a request to resent all alarms above a certain alarm number. This is designed for use by an SNMP Manager that has been off line for a while and may have missed some alarm notifications.

To request a resend of alarms the relay application needs send an SNMP set-request using the format described in the variables.mib file.

The smsAlarmRelay will listen using the port number specified as the listenPort parameter in snmp.cfg. The alarmRelay keeps an internal count of the highest alarm number sent. When a valid SNMP set-request is received, the alarmRelay will take note of the number in the message and send all alarms with an alarm ID greater than this number.

Failure

The smsAlarmDaemon on each alarm-managed node in the installation will by default generate a health-check alarm once per minute. These health check alarms will be relayed in the same fashion as all other alarms.

If these health check alarms are not received at the target destination, then the smsAlarmRelay may have failed, and should be investigated.

Output

The smsAlarmRelay.sh writes error messages to the system messages file, and also writes additional output to /IN/service_packages/SMS/tmp/smsAlarmRelay.log.

The following table summarizes the information in the Service Management System User's Guide.

Destination	Field Content
SNMP	Host name of the target SNMP TRAPS recipient
FILE	Name of a file to which the daemon has write access
NFM	Host name of the NFM target.
Q3	Host name of the Q3 target.
SNMP	Host name of the SNMP target.
NORELAY	The field is empty, as the alarm is not forwarded to a target

Note:

Setting the target to NORELAY will stop any other notification rules being actioned. Consequently, the NORELAY rules must be very specific. Otherwise an important alarm may accidentally be missed.

smsConfigDaemon

Purpose

smsConfigDaemon exists on both the source node (example, SMS) as well as the target node (example, SLC). It takes an optional parameter (-m) which decides its action.

When run with the -m, it monitors for changes to the master XML file (example, esgConfigMaster.xml). If it finds changes made to the master config file, smsConfigDaemon will call smsSendConfig.sh.

If the the -m parameter is missing, smsConfigDaemon monitors for changes to the derived eserv.config file (example, eserv.config.derived) on the target node, and calls smsApplyConfig.sh if it finds changes to the file.

About Database Connections

smsConfigDaemon connects to the database on a local or a remote SMS node by using the user credentials set in the following environment variables in smsConfigVariables.sh:

SMP_DB_USER_NAME
SMP_DB_CONNECT_STRING
SMP_DB_PASSWORD

For connections to a:

Local database, specify the username and password by setting the SMP_DB_USER_NAME and SMP_DB_PASSWORD variables. You can set only the user name in the SMP_DB_USER_NAME variable, if required.
Remote database, specify the username and password by setting the SMP_DB_USER_NAME and SMP_DB_PASSWORD variables, and specify the SID of the remote database in the SMP_DB_CONNECT_STRING variable. You can set the SMP_DB_USER_NAME and the SMP_DB_CONNECT_STRING variables only, if required.
Local or a remote database by using the Oracle wallet secure external password store, specify only the TNS connection string in the SMP_DB_CONNECT_STRING variable, where the connection string is the alias defined for the username and password credentials in the external password store. This alias can be either a TNS name or a service name from tnsnames.ora. The SMP_DB_CONNECT_STRING variable has the following format: "\@connect_string".

Note:

If you set none of these variables, smsConfigDaemon connects to the database by using the default value of "/".

Startup

smsConfigDaemon is started by the script smsConfigDaemonScript. This process is driven by the system and is not intended to be changed by the user.

Configuration

For more information on the parameters used by smsConfigDaemon, see smsConfigDaemonScript.

Failure

If the smsConfigDaemon fails, the secondary scripts, smsSendConfig.sh and smsApplyConfig.sh will fail to start and distribution of the updated configuration files is affected. Appropriate alarm messages are generated.

Output

The smsConfigDaemon and its sub-scripts write error messages to the system messages file, and also write additional output to /IN/service_packages/SMS/tmp/smsConfigDaemonMaster.log if they reside on the target node to /IN/service_packages/SMS/tmp/smsConfigDaemonClient.log.

smsConfigDaemonScript

Purpose

smsConfigDaemonScript is responsible for starting the smsConfigDaemon process. It also runs the smsConfigVariables.sh script which includes a set of configurable environment variables that are used by smsConfigDaemon and its helper scripts; for example, to set the username and password credentials for connecting to the Oracle database.

For more information about smsConfigDaemon, see smsConfigDaemon.

Environment Variables Set in smsConfigVariables.sh

The smsConfigVariables.sh file is located in the following directory:

/IN/service_packages/SMS/bin

Table 5-1 lists descriptions for the environment variables that you can configure in the smsConfigVariables.sh file and provides their default values.

Table 5-1 Descriptions for the Environment Variables

Variable	Default Value	Description
SMP_DB_USER_NAME	None	The Oracle user that smsConfigDaemon uses to log in to the Oracle database.
SMP_DB_PASSWORD	None	The password for the Oracle user that smsConfigDaemon uses to log in to the Oracle database.
SCP_DB_USER_NAME	None	The Oracle user that the smsSignalConfigChange script uses to access sqlplus.
SCP_DB_PASSWORD	None	The password for the Oracle user that the smsSignalConfigChange script uses to access sqlplus.
SMP_DB_CONNECT_STRING	None	Any extra connect parameters that smsConfigDaemon requires to log in to the Oracle database.
DETECTION_PERIOD	10	The number of seconds between smsConfigDaemon change detection attempts.
RETRY_PERIOD	60	The number of seconds between smsConfigDaemon sendConfig retry attempts.
SLEEP_TIME	100	The number of milliseconds to sleep inside the smsConfigDaemon main loop.

Configuration

smsConfigDaemonScript sets the configurable parameters for smsConfigDaemon and its helper scripts.

The available parameters are:

Parameter	Default	Description
smp_db_user user/password		Oracle user/password for the SMF. Example: `smf/smf`
scp_db_user user/password		Oracle user/password for the smsSignalConfigChange script should use for sqlplus. Example: `scp/scp`
connect_string		Any extra connect parameters to be used by smsConfigDaemon
detection_period	10	Period (in seconds) after which smsConfigDaemon attempts to detect changes.
retry_period	60	Period (in seconds) after which smsConfigDaemon attempts to retry initiating sendConfig.
sleep_time	100	Period (in milliseconds) to wait inside smsConfigDaemon's main loop.
source_root	/IN/html/Configuration	Location where all the XML-driven config files and directories are stored. Not to be changed by the user.
master_xml_dir		Location of the master config.xml file. Not to be changed by the user.
master_config_file	esgConfigMaster	Name of the master configuration xml file.
master_config_file_full_path		Full path of the master configuration file monitored by the SMP config daemon (derived from the master config xml file).
archive_xml_dir		Location where the master config.xml files are archived to prior to modification.
derived_eserv_dir		Location of the derived eserv file.
pending_dir		Location where the config files from failed updates are held, pending a retry.
xml_convert_script		Location of the XML to eserv.config converter script.
target_root	/IN/service_packages/Configuration	Location of the USP nodes where the eserv.config file is sent.
target_eserv_config_dir		Location on the USP nodes where the eserv.config file is pushed out to.
derived_eserv	eserv.config.derived	Name of the eserv.config file sent to the target nodes.
derived_config_file_full_path		Full path of the derived config file monitored by the SCP config daemon (derived from the eserv.config file sent to the target nodes)
management_interface_host	localhost	Location of the management interface.
management_interface_port		Port is the management interface listening on.

Note:

It is not recommended to change the values of these parameters. All necessary configuration is done at installation time by the configuration script; this section exists for information only. Please contact Oracle support prior to attempting any modification to configuration data.

Startup

smsConfigDaemonScript is started by the system and is not intended to be changed by the user

Failure

If smsConfigDaemonScript encounters problems, the smsConfigDaemon will fail to start and the updated eserv.config data will not be copied to the relevant platforms. Appropriate alarm messages are generated.

Output

The smsConfigDaemonScript writes error messages to the system messages file, and also writes additional output, when smsConfigDaemon has been started using the -moption, to the /IN/service_packages/SMS/tmp/smsConfigDaemonMaster.log.

If the -m option is not used, output will be written to

/IN/service_packages/SMS/tmp/smsConfigDaemonClient.log.

smsCdrArchiver

Purpose

smsCdrArchiver performs a daily search of a specified input directory for CDR or EDR files to archive, and archives them to a file in a specified output directory. It also compresses and deletes old archive files according to the rules specified in the smsCdrArchiver configuration.

About Archive File Names

The name of the archive file output daily by smsCdrArchiver has the following format:

[machineName]+[outputFileTag]+[_serviceType]+_Date[-HH]+[outputFileSuffix]

Where

machineName is the name of the machine that generated the data record. smsCdrArchiver prefixes the output file name with the machine name when you set the useMachineName parameter to true.
outputFileTag is an identifying tag for the output file that you specify in the optional outputFileTag parameter.
serviceType is the service type that generated the data record. smsCdrArchiver includes the service type in the output file name when you set the useServiceType parameter to true.
Date is the date timestamp for the data record formatted as: YYYYMMDD.
HH is the record hour that is appended to the Date value by using the following format: YYYYMMDD-HH, when you set the UseRecordHour parameter to true.
outputFileSuffix is the suffix specified in the optional outputFileSuffix parameter that is appended to the output file name.

File name example

smsCdrArchiver has the following output file parameters configured in the eserv.config file:

smsCdrArchiver = { 
... 
outputFileTag = "ACS" 
outputFileSuffix = ".cdr" 
useRecordHour = true 
useMachineName = true 
useServiceType = true 
... 
}

For machine name "telco-p-uas", service type "ACS", and timestamp "2014061512", the following output file would be created:

telco-p-uasACS_ACS_20140615-12.cdr

Startup

The smsCdrArchiver process is started by the smsCdrArchiver.sh script, that is located in the /IN/service_packages/SMS/bin/ directory. The smsCdrArchiver.sh script runs in the crontab for the smf_oper user.

Note:

If smsCdrArchiver.sh script or smsCdrArchiver binary is not found under /IN/service_packages/SMS/bin directory, copy them from /IN/service_packages/SUPPORT/bin directory.

Rename smsCdrArchiverStartup.sh to smsCdrArchiver.shbefore moving the file to /IN/service_packages/SMS/bin directory.

Configuration

You configure smsCdrArchiver in the SMS, smsCdrArchiver section of the eserv.config configuration file:

SMS = { 

smsCdrArchiver = { 
    recordType = "CDR"     
    inDir = "/cdr/processed" 
    outDir = "/cdr/CDR-archive" 
    outputFileSuffix = ".cdr"  
    useRecordHour = true 
    useMachineName = true 
    useServiceType = true 
    writeIndexFile = false 

    useDateOutDirs = true     
    prefixFileName2Data = false 
    fileMatch = "telco-p-uas\*_ACS_"  
    fileOwner = "smf_oper"  
    compressionCommand = "GZIP" 
    compressModTime = 2 
    compressImmediately = false 
    compressMinRunTime = 0 
    deleteModTime = 31    
    runCleanupHour = 03    
    BFT = { 

        exportBFTDataRecords = true 
        exportBFTOutDir = "/cdr/export/BFT" 
        exportBFTOutputFileSuffix = "" 
        changeBFTOutputFileGroup = ""         
        compressBFTDataRecords = true 
        exportBFTKeepDays = 4 
        ext5BFTHex2Dec = false         
        zeroPadExt5Hex2Dec = 0 
            }     
        } 
}

smsCdrArchiver Parameters

The smsCdrArchiver section accepts the following parameters.

recordType

Syntax:	`recordType = "str"`
Description:	Defines the type of data records to archive. When `recordType` is set to: CDR ( for ACS Call Data Records), the ACS TCS (Time Call Start) tag is used to find the timestamp EDR (for VWS Event Data Records), the VWS RECORD_DATE tag is used to find the date timestamp
Type:	String
Optionality:	Required
Allowed:	CDR, EDR
Default:
Notes:
Example:	`recordType = "CDR"`

inDir

Syntax:	`inDir = "dir"`
Description:	The directory that contains CDR or EDR input files.
Type:	String
Optionality:	Required
Allowed:	A vaild directory path and name.
Default:
Notes:	ccsCdrArchiver will not search sub-directories of the specified directory for input files.
Example:	`inDir = "/cdr/processed"`

outDir

Syntax:	`outDir = value`
Description:	The output directory for the archived CDR or EDR file.
Type:	String
Optionality:	Required
Allowed:	A valid directory path and name
Default:
Notes:
Example:	`outDir = "/cdr/CDR-archive"`

outputFileTag

Syntax:	`outputFileTag = "str"`
Description:	An identifying tag for the output file, such as the name of the application that generated the data records. For example, for ACS CDRs set `outputFileTag` to "ACS".
Type:	String
Optionality:	Optional
Allowed:
Default:	Not used
Notes:
Example:	outputFileTag = "ACS"

outputFileSuffix

Syntax:	`outputFileSuffix = "suffix"`
Description:	The suffix to append to the name of the output file; for example, ".cdr" or ".edr" .
Type:	String
Optionality:	Optional
Allowed:
Default:	Not used
Notes:
Example:	`outputFileSuffix = ".cdr"`

useRecordHour

Syntax:	`useRecordHour = true\|false`
Description:	When set to true, the record hour is appended to the record date in the archive output file name by using the following format: YYYYMMDD-HH Where YYYYMMDD is the record date, and HH is the record hour.
Type:	Boolean
Optionality:	Optional
Allowed:	true, false
Default:	Not used
Notes:
Example:	`useRecordHour = true`

useMachineName

Syntax:	`useMachineName = true\|false`
Description:	When set to true, codephfix the archive output file name with the name of the machine that generated the data record.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true, false
Default:	false
Notes:	The machine name can only be used in the output file name if the input file name has been codephfixed with the machine name. This is the standard used by the cmnPushFiles process.
Example:	`useMachineName = true`

useServiceType

Syntax:	`useServiceType = true\|false`
Description:	Include the data record service type tag in the output file name. The service type: For CDR records is specified in field 1 For EDR records is specified in the CDR_TYPE field
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true, false
Default:	false
Notes:
Example:	`useServicetype = true`

writeIndexFile

Syntax:	`writeIndexFile = true\|false`
Description:	When set, smsCdrArchciver writes an index file that links data record entries to the output file name. The name of the index file is outputFilename.idx, where outputFilename is the archive output file name. Index file entries have the following formats: CDR index file format: `Date Time CID CLI ServiceType(field 1) [Data_SessionID]` EDR index file format: `Date Time SEQUENCE_NUMBER CLI CDR_TYPE [Data_SessionID]` Where: `Data_SessionID` is the ID for the data session CID in the CDR index file correlates to the VWS EDR SEQUENCE_NUMBER value (where applicable) You use the index file to search, based on the fields listed above, for the identity of the archived output file containing the complete record.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true, false
Default:	false
Notes:	Using this option requires extra processing that can cause the smsCdrArchiver to run more slowly.
Example:	`writeIndexFile = true`

useDateOutDirs

Syntax:	`useDateOutDirs = true\|false`
Description:	When set to true, smsCdrArchiver separates output files into date (YYYYMMDD) directories based on the TCS or RECORD_DATE values. The output files are written to the following location: `outDir/YYYYMMDD/outFile`.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true, false
Default:	false
Notes:	Using this option requires extra processing that can cause the smsCdrArchiver to run more slowly.
Example:	`useDateOutDirs = true`

codephfixFileName2Data

Syntax:	`codephfixFileName2Data = true\|false`
Description:	When set to true, smsCdrlArchiver codephfixes the archived data record with the filename of the CDR or EDR record, by using the following format: `original_filename:data_record_entry`. Where: original_filename is the name of the original file that contains the CDR or EDR record data_record_entry is the archived data record You can use this option to identify the original filename in case of loading errors; for example, for CCS EDRs that are post-processed by the ccsCdrLoader.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true, false
Default:	false
Notes:	You should use this option for EDRs only.
Example:	`codephfixFileName2Data = true`

fileMatch

Syntax:	`fileMatch = "str"`
Description:	Use to search for file names that match the codephfix defined by the specified regular excodephssion. You can define more than one codephfix to match. The codephfixes should be enclosed in double quotes "", and separated by white space. You can include the following wild cards in codephfix strings: * wild card at the end of each codephfix string \ wild card to codephvent shell expansion and unexpected results
Type:	String
Optionality:	Optional
Allowed:
Default:	Not set
Notes:
Example:	`filematch = "telco-p-uas\*_ACS_"`

fileOwner

Syntax:	`fileOwner = "str"`
Description:	When set, smsCdrArchiver locates only those files that are owned by the specified user.
Type:	String
Optionality:	Optional
Allowed:
Default:	Not set
Notes:
Example:	`fileOwner = "smf_oper"`

comcodephssionCommand

Syntax:	`comcodephssionCommand = "str"`
Description:	Specifies the comcodephssion utility to use for comcodephssing old archive files.
Type:	String
Optionality:	Optional (default used if not set)
Allowed:	GZIP, BZIP2, PBZIP2
Default:	GZIP
Notes:
Example:	`comcodephssionCommand = GZIP`

Billing Failure Treatment CDR parameters

The Billing Failure Treatment (BFT) parameters define rules for exporting BFT data records to a special directory for BFT post processing by the billing server.

Note:

The BFT parameters apply only to ACS CDRs, where the recordType field is set to "CDR".

You configure BFT parameters in the smsCdrArchiver, BFT section of the eserv.config file by using the following syntax:

smsCdrArchiver = { 
    BFT = { 

        exportBFTDataRecords = true 
        exportBFTOutDir = "/cdr/export/BFT" 
        exportBFTOutputFileSuffix = "" 
        changeBFTOutputFileGroup = "" 
        compressBFTDataRecords = true         
        exportBFTKeepDays = 4 
        ext5BFTHex2Dec = false 
        zeroPadExt5Hex2Dec = 0     
    } 
}

exportBFTDataRecords

Syntax:	`exportBFTDataRecords = true\|false`
Description:	Enables BFT CDRs to be exported to the directory specified by the exportBFTOutDir parameter.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true, false
Default:	false
Notes:
Example:	`exportBFTDataRecords = true`

exportBFTOutDir

Syntax:	`exportBFTOutDir = "str"`
Description:	The directory path for the directory to which to export BFT CDRs.
Type:	String
Optionality:	Optional
Allowed:
Default:
Notes:
Example:	`exportBFTOutDir = "/cdr/export/BFT"`

exportBFTOutputFileSuffix

Syntax:	`exportBFTOutputFileSuffix = "str"`
Description:	Specifies the suffix for the BFT output file. If this is unset, then the original input file name is used.
Type:	String
Optionality:	Optional
Allowed:
Default:
Notes:	White spaces are replaced by the _ (underscore) character.
Example:	`exportBFTOutputFileSuffix = ""`

changeBFTOutputFileGroup

Syntax:	`changeBFTOutputFileGroup = "str"`
Description:	Sets the group file permissions for the output file; for example, to change group read/write access to allow third parties to collect BFT CDRs for post processing.
Type:	String
Optionality:	Optional (default used if not set)
Allowed:	The group file permissions must be valid for the user running the smsCdrArchiver script.
Default:
Notes:	If the group is invalid, or left undefined, then the group file permissions are not changed.
Example:	`changeBFTOutputFileGroup = ""`

compressBFTDataRecords

Syntax:	`compressBFTDataRecords = true\|false`
Description:	Set to true to compress the BFT oputput files as they are written. If set to false, then the compressModTime parameter does not take the BFT CDR files into account and no further compression will be done.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true, false
Default:	true
Notes:	The compression utility used is defined by the compressionCommand parameter.
Example:	`compressBFTDataRecords = true`

exportBFTKeepDays

Syntax:	`exportBFTKeepDays = int`
Description:	The number of days to keep the exported BFT CDRs before they are deleted.
Type:	Integer
Optionality:	Optional (default used if not set)
Allowed:
Default:	1 - The default value of one will be used if you specify a value that is less than one.
Notes:
Example:	`exportBFTKeepDays = 4`

ext5BFTHex2Dec

Syntax:	`ext5BFTHex2Dec = true\|false`
Description:	Whether the ACS CDR EXT5 field is written as a hexidecimal value, such as EXT5=0000000A, or whether it is converted to a decimal value, such as EXT5=10, for the BFT post-processing tools.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	true (use decimal values) false (use hex values)
Default:	false
Notes:
Example:	`ext5BFTHex2Dec = false`

zeroPadExt5Hext2Dec

Syntax:	`zeroPadExt5Hext2Dec = int`
Description:	The number of leading zeros to use when padding the converted EXT5 decimal number (if ext5BFTHex2Dec is set to true). Set to 0 (zero) or 1 (one) for no leading zero padding.
Type:	Integer
Optionality:	Optional (default used if not set)
Allowed:
Default:	0
Notes:	If zeroPadExt5Hext2Dec is set to a negative number then the decimal number will be padded so that it is the same length as the original hex number. For example, the hex number: 0000000A is converted to the decimal number: 00000010.
Example:	`zeroPadExt5Hext2Dec = 0`

smsCdrProcess.sh

Purpose

smsCdrProcess.sh performs basic EDR processing and archiving. smsCdrProcess.sh runs the smsProcessCdr binary with specified command line parameters. One output EDR file is created for each input EDR file.

smsCdrProcess.sh can also be configured to prevent processing the EDR.

For more information about how smsProcessCdr processes EDRs, see smsCdrProcess.sh.

EDR Format

The format of the records in the EDR file are specific to the application which generates them. The most commonly used EDR format processed by this mechanism is the ACS "Pipe Tag LF" format, which uses TAG=VALUE pairs separated by the "|" character. Records are line field delimited.

For more information about this format, see the ACS Technical Guide.

Startup

This task is run in the crontab for smf_oper, by default at 1:00 am system clock time. It is scheduled as the /IN/service_packages/SMS/bin/smsCdrProcess.sh script.

The script runs the smsProcessCdr process with set parameters.

Configuration

The following command in the smsProcessCdr.sh prevents the EDR from being processed and copies it directly to the output directory.

Example Command: $BINDIR/smsProcessCdr -d $CDRDIR -D $OUTDIR -s $INSFX -S $OUTSFX

To process EDRs, use the following command instead:

Example Command:$BINDIR/smsProcessCdr -t $OUTFMT -d $CDRDIR -D $OUTDIR -s $INSFX -S $OUTSFX

Failure

If the process is not running, EDR files will build up in the /IN/service_packages/SMS/cdr/received directory.

The filesystem usage will rise above standard operational levels.

Output

The smsCdrProcess.sh writes error messages to the system messages file, and also writes additional output to /IN/service_packages/SMS/tmp/smsCdrProcess.sh.log.

smsDbCleanup.sh

Purpose

This task executes SQL statements to delete old data from the following table.

SQL Statement	Data deleted
SMF_AUDIT	Audit trail of database changes.
SMF_STATISTICS	Application bulk usage counters.
SMF_ALARM_MESSAGE	System messages.
SMF_ALARM_UNKNOWN	System messages which do not match any known alarm definitions.

Startup

This task is run in the crontab for smf_oper, by default at 1:00 am system clock time. It is a shell script, specifically /IN/service_packages/SMS/bin/smsDbCleanup.sh.

Parameters

The decision on when to delete data is determined according to various parameters configured in eserv.config. These values can be changed by the usual eserv.config editing method, subject to database sizing limitations and availability of space for additional historical data.

The default parameters are:

Parameter	Default	Description
`alarmAge`	7	Delete records older than this number of days. Refers to the actual age of the alarm, and controls the deletion of all alarms of a certain age, regardless of whether they are noted (closed).
`alarmMax`	100000	Maximum number of records to keep. After this value is reached, smsDbCleanup.sh delete records.
`alarmNotedAge`	3	Controls the deletion of noted (closed) alarms.
`auditAge`	7	Delete records older than this number of days.
`commit`	100	Number of statistic records to delete before committing the deletions.
`statsAge`	30	Delete records older than this number of days.
`unknownMax`	5000	Maximum number of alarms to keep in table smf_alarm_unknown. After this value is reached, new additions cause oldest to be deleted from the table.

Failure

If the process is not running, old data will not be purged from the database. The database may reach maximum size, and inserts may fail.

Output

The smsDbCleanup.sh writes error messages to the system messages file, and also writes additional output to /IN/service_packages/SMS/tmp/smsDbCleanup.sh.log.

smsLogCleaner

Purpose

smsLogCleaner archives the following types of log files:

Convergent Charging Controller process log files (/IN/service_packages/Product/tmp/Process.log)
System log files (syslog)

For more information, see System Administrator's Guide.

Startup

This task is run in the crontab for smf_oper. By default, it runs at 30 minutes past each hour. It is run via the shell script:

/IN/service_packages/SMS/bin/smsLogCleanerStartup.sh

Parameters

smsLogCleaner supports the following command-line options:

Usage

smsLogCleaner -c configuration_file -d days -s storage_file [-h]

The available parameters are:

Parameter	Default	Description
-c configuration_file	logjob.conf	The name of the configuration file.
-d days	7	How often to clean the archive (in days).
-s storage_file	storage.txt	The name of the storage file.
-h	Not applicable.	Provides help information.

At installation, the cronjob is configured to execute by default with the following command-line parameters:

-c/IN/service_packages/SMS/etc/logjob.conf

-s/IN/service_packages/SMS/tmp/sms_storage.txt

-d 7

An operator can change these values, subject to disk storage availability and site-specific archiving policies.

Failure

If the process is not running, log files in the following directory will accumulate in size and age beyond the expected values.

/IN/service_packages/SMS/tmp

Output

The smsLogCleaner run by smf_oper writes error messages to the system messages file, and also writes additional output to /IN/service_packages/SMS/tmp/smsLogCleaner.log.

logjob.conf

The logjob.conf configuration file has the following format:

log file age hrs size size arcdir dir logonce zip size

The available parameters are:

Parameter	Description
log file	The full directory path and name of the file to be cleaned. You can include the '*' wildcard in the file name if required. Example: `log /IN/service_packages/SMS/tmp/smsNamingServer.log` Tip: Most processes and tools document where their output is written to in their Output topic.
age hrs	Sets the minimum age, in hours, for the log file before it is cleaned. You must set either this parameter or the size parameter. If both parameters are set, the log file is cleaned when either condition is met. Example: age 100
size size	Sets the minimum size for the log file before it is cleaned. You must set either this parameter or the age parameter. If both parameters are set, the log file is cleaned when either condition is met. Examples: size 60K, or size 60M
arcdir dir	The directory for storing the old log file. If this parameter is not specified, the log file is deleted. Example: `arcdir /IN/service_packages/SMS/tmp/archive`
logonce	Include this parameter if you want to keep only one archived version of the log file.
zip size	Automatically compress log files that exceed the specified size. Example: zip 100M

smsMergeDaemon

Purpose

The smsMergeDaemon monitors the connections between the SMS and SLCs via a heartbeat. The smsMergeDaemon will initiate a startMerge to resyncronise the SMS and SLCs where:

the infMaster on the disconnected SLC reports that it has received updates that would have normally gone to the SMS or it has an updateLoader or updateRequester pointing to it, and
the heartbeat to the SMS and SLC have been stable for a period.

For more information about the startMerge process, see startMerge.

Startup

This task is started by entry sms9 in the inittab, via the shell script:

/IN/service_packages/SMS/bin/smsMergeDaemonStartup.sh

Note:

smsMergeDaemon is not used in a clustered install.

Parameters

The smsMergeDaemon accepts the following command line arguments.

Usage:

smsMergeDaemon -nodeid

The available parameters are:

Parameter	Default	Description
-nodeid	1000	The node number of the smsMergeDaemon.

The rest of the configuration details are taken from replication.def File. Relevant parameters include:

HB PERIOD
TICK_TIME 1000
SMS_PORT 7
REP_PATH "/IN/service_packages/SMS/etc/replication.config"
MERGE_INTERVAL 600
MAX_CONNECTION_TIME 100000000
MAX_ROUNDTRIP 3
LONG TIMEOUT

Failure

If the smsMergeDaemon's connection to the smsMaster is lost, it will exit.

Output

The smsMergeDaemon.sh writes error messages to the system messages file, and also writes additional output to /IN/service_packages/SMS/tmp/smsMergeDaemon.log.

smsMaster

Purpose

The smsMaster is the central correlation point for the replication system.

smsMaster:

Sends notifications of updates to remote updateLoaders to be loaded into secondary databases.
Accepts update requests from remote systems that wish to change the master database (including the smsStatsDaemon, RequesterIF and smsAlarmDaemon).
Correlates full resynchronization with remote databases, and communicates with inferior masters which can assume some smsMaster functions in the case of a platform or network failure.

Startup

This task is started by entry sms7 in the inittab, through the shell script:

/IN/service_packages/SMS/bin/smsMasterStartup.sh

Configuration

The smsMaster supports the following command-line options:

Usage:

smsMaster -maxpending int

The available parameters are:

-maxpending

Syntax:	`-maxpending int`
Description:	The size of pending request queue.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	10000
Notes:
Example:

Failure

Remote replication nodes such as update loaders, updated requesters, inferior masters will generate alarms indicating connection failure to the smsMaster.

Output

The smsMaster writes error messages to the system messages file, and also writes additional output to /IN/service_packages/SMS/tmp/smsMaster.log.

smsNamingServer

Introduction

The smsNamingServer listens for IORs being exported from CORBA processes, and stores them in the database in the IORS table owned by Oracle user SMF. It also serves requests to read IOR strings from the database.

This functionality is required to support processes that wish to store/retrieve IOR strings, but which do not have Oracle access to the SMF database instance, for security or licensing reasons.

Startup

In an unclustered installation, this task is started by entry sms2 in the inittab, through the shell script:

/IN/service_packages/SMS/bin/smsNamingServerStartup.sh

In a clustered installation this task is started by the cluster software, through the shell script:

/IN/service_packages/SMS/bin/smsNamingServerCluster.sh

Parameters

The smsNamingServer supports the following command-line options:

Usage:

smsNamingServer [-u usr/pwd] [-p port]

The available parameters are:

-u

Syntax:	`-u usr/pwd`
Description:	The Oracle user and password pair.
Type:	String
Optionality:	Optional (default used if not set)
Allowed:
Default:	/
Notes:
Example:	`-u /`

-p

Syntax:	`-p port`
Description:	The port number on which to listen for requests.
Type:	Integer
Optionality:	Optional (default used if not set)
Allowed:
Default:	7362
Notes:
Example:	`-p 7362`

Failure

If the smsNamingServer fails, then processes attempting to access the specified port will not be able to access the service, and should report an error indicating this.

Output

The smsNamingServer writes error messages to the system messages file, and also writes additional output to /IN/service_packages/SMS/tmp/smsNamingServer.log.

smsReportsDaemon

Purpose

smsReportsDaemon is a CORBA server process that generates reports on demand.

When the SMS user interface (UI) Reports function requests a report, smsReportsDaemon:

Returns the report output filename
Writes the report output to a specified directory on the SMS

The SMS UI Reports function then displays the report. For more information about the SMS Reports function, see Service Management System User's Guide.

Startup

In an unclustered installation, smsReportsDaemon is started by entry sms3 in the inittab, via the shell script:

/IN/service_packages/SMS/bin/smsReportsDaemonStartup.sh

In a clustered installation, smsReportsDaemon is started by the cluster software, via the shell script:

/IN/service_packages/SMS/bin/smsReportsDaemonCluster.sh

Parameters

smsReportsDaemon supports the following command-line options.

Usage:

smsReportsDaemon [-h host] [-p port] [-i dir] [-o dir] [-f dir] [u user/password] [t host] [s port] [z timezone] [m num]

The available parameters are:

Parameter	Default	Description
-h host	Value returned by gethostname	smsNamingServer hostname. Allowed value type: ASCII String
-p port	7362	smsNamingServer port number. Allowed value type: Number
-i dir	/IN/service_packages/SMS/input	Report scripts/binaries input directory. Allowed value type: ASCII String
-o dir	/IN/service_packages/SMS/output	Generated report output directory. Allowed value type: ASCII String
-f dir	/IN/service_packages/SMS/input	The setTZ.sql file directory. By default, the file is located in /IN/service_packages/SMS/input.
-u user/password		Oracle SMF database username and password. Allowed value type: ASCII String
-t host	Default determined by CORBA	CORBA transport layer hostname.
-s port	Default determined by CORBA	CORBA transport layer port number. This parameter is ignored if the CorbaServices section is present in the eserv.config configuration file. For more information, see Configuring Connections for CORBA Services.
-z timezone		Timezone in which the smsReportsDaemon SQL queries are run generating the report output.
-m num	2	Maximum number of concurrent reports per node.

Failure

If smsReportsDaemon fails, you will not be able to generate reports.

Output

smsReportsDaemon writes error messages to the system messages file, and writes additional output to /IN/service_packages/SMS/tmp/smsReportsDaemon.log.

smsReportsDaemon writes report output to subdirectories of the specified output directory (by default, /IN/service_packages/SMS/output). The subdirectory depends on the application and category defined for the report:

/IN/service_packages/SMS/output/Application/Category

The report output filename is in the format:

YYMMDDHHmmss.9_random_characters.txt

Interactive Reports

smsReportsDaemon generates on-demand reports.

Reports are defined through SQL commands, shell scripts, or compiled executable programs. Additional reports can be created and made available for on-demand and scheduled generation as a post-installation manual function. For more information, see Reports.

At startup, smsReportsDaemon publishes its IOR string via the smsNamingServer. If not specified, the IP port number on which the CORBA service is provided will be determined by the CORBA framework. In most installations, a firewall is used to protect the SMS host, and hence the CORBA service port must be fixed. Use the -s parameter for this purpose.

smsReportScheduler

Purpose

The smsReportScheduler monitors the database table SMF_REPORT_SCHEDULE for entries inserted via the SMS Java screens.

smsReportScheduler sleeps until the next report is due to be run. The output of the report is optionally copied to a specified directory, spooled to a specified printer, or sent to a specified email address. For more information about how to schedule reports which will be performed periodically and how to configure the report destination, see the Service Management System User's Guide.

Startup

In an unclustered installation, this task is started by entry sms4 in the inittab, via the shell script:

/IN/service_packages/SMS/bin/smsReportSchedulerStartup.sh

In a clustered installation this task is started by the cluster software, via the shell script:

/IN/service_packages/SMS/bin/smsReportSchedulerCluster.sh

Parameters

The smsReportScheduler supports the following command-line options:

Usage:

smsReportScheduler [-i dir] [-o dir] [-u usr/pwd] [-v] [-z timezone]

The available parameters are:

-i dir

Syntax:	`-i dir`
Description:	The input directory for report generation scripts/binaries dir.
Type:	String
Optionality:	Optional (default used if not set)
Allowed:
Default:	/IN/service_packages/SMS/input
Notes:
Example:

-o dir

Syntax:	`-o dir`
Description:	The output directory for report generation.
Type:	String
Optionality:	Optional (default used if not set)
Allowed:
Default:	/IN/service_packages/SMS/output
Notes:	Report may provide a default output directory which overrides smsReportDaemon's default.
Example:

-u usr/pwd

Syntax:	`-u usr/pwd`
Description:	The userid and password for oracle login string.
Type:	String
Optionality:	Optional (default used if not set)
Allowed:
Default:	/
Notes:
Example:

-v

Syntax:	`-v`
Description:	What level of information to output.
Type:	Boolean
Optionality:	Optional (default used if not set)
Allowed:	set: Print additional information. not set: Only print the standard level of information.
Default:	not set
Notes:
Example:

-z timezone

Syntax:	`-z timezone`
Description:	The timezone in which to schedule the report.
Type:	String
Optionality:	Optional (default used if not set)
Allowed:	Java supported timezone
Default:	GMT
Notes:	For a full list of Java supported timezones see ACS Technical Guide - Appendix TimeZones.
Example:	`-z "EST"`

Failure

In the case of failure, the scheduled report will not appear at the specified destination, or may contain incorrect or missing output.

Output

The smsReportScheduler writes error messages to the system messages file, and also writes additional output to /IN/service_packages/SMS/tmp/smsReportScheduler.log.

Unix Utilities

The table below lists the Unix utilities required for scheduling.

Unix Binary Required	Description	Location Expected
mailto	E-mail agent used by report generation component to send emails.	/usr/bin/mailto
sendmail (or equivalent delivery agent)	E-mail delivery agent.	daemon started at boot time.
lpr	Printing utility.	/usr/ucb/lpr

Note:

E-mail sending/receiving/delivery agent requires all local e-mail user names to be under 13 characters. For local e-mail user names longer than 13 characters, mailto and sendmail will not function properly.

smsReportCleanupStartup.sh

Purpose

The Reports cleaner looks for output from ad-hoc and scheduled reports generated by the smsReportsDaemon and the smsReportScheduler.

It deletes files that are older than a specified age.

Startup

This task is run in the crontab for smf_oper. By default it runs at 2:00 am system time. It is scheduled as the following script:

/IN/service_packages/SMS/bin/smsReportsCleanerStartup.sh

Parameters

The command inside the script contains a command line parameter specifying the cleanup age of report output files. By default this is seven days. Report output files older than this age are deleted.

An operator may change this value, subject to disk storage availability and site-specific archiving policies.

Failure

If the process is not running, reports files in the following directory will accumulate in size and age beyond the expected values.

/IN/service_packages/SMS/output

Output

The smsReportsCleaner run by smf_oper writes error messages to the system messages file, and also writes additional output to:

/IN/service_packages/SMS/tmp/smsReportsCleanerStartup.sh.log

smsStatsDaemon

Description

smsStatsDaemon can be run as a background process on an SMS, SLC, and also on other IPs such as Voucher and Wallet Servers.

For more information about smsStatsDaemon, see the discussion about the smsStatsDaemon in Background Processes on the SLC.

smsStatisticsWriter

Purpose

The smsStatisticsWriter is responsible for collecting statistical data provided by the smsStatDaemons and writing it to files, either for standalone statistics, or for groups of statistics associated with an event.

smsStatisticsWriter structure

Here is an example structure of the smsStatisticsWriter.config file.

smsStatisticsWriter = { 
    tempDir = "/IN/service_packages/SMS/tmp/smsStatisticsWriter" 
    outDir = "/IN/service_packages/SMS/logs/smsStatisticsWriter"     
    outDirType = 'FLAT' 
    outDirExpectedFiles = 65536 
    outDirBucketSize = 10 
    outFileName = "smsStatisticsWriter" 
    maxFileSize = 100 
    maxFileOpenTime = 3600 
    statsDaemonRestartDelay = 10 
    statsDaemonStartupTime = 5 
    scanInterval = 100000 
    replicationAllowance = 60 
    endOfEventTolerance = 5 
    resetInterval = { 
        days = 1 
        hours = 0         
        minutes = 0 
        seconds = 0 
    } 
        Events = [     
            { 
                eventName = "EventGood" 
                resetAllEventStatisticsOnStartup = true 
                eventResetBaseTime = "20110511130000" 
                resetInterval = {     
                    days = 0 
                    hours = 0 
                    minutes = 4
                    seconds = 0 
            }         
            eventStartDateTime = "20100728000000" 
            eventEndDateTime = "20101231000000" 
            eventWritePeriod = 30 
            Statistics = [
        {    
                applicationName = "TELEVOTING" 
                statisticName = "Stat1" 
        }
        { 
                applicationName ="TELEVOTING" 
                statisticName = Statn     
        } 
        etc 
    ] 
    { 
        eventName = "Event2"         
        parameters for event... 
    } 
    { 
    eventName = "Eventn" 
    parameters for event... 
    } 
    ] 
    Statistics = [ 
        { 
            StatisticName = "Stat2" 
            resetStatisticOnStartup = false 
            statWritePeriod = 0 
            statResetBaseTime = "20110511130000" 
            resetInterval = { 
                days = 0 
                hours = 0 
                minutes = 5 
                seconds = 0 
        } 
    }     
    { 
        statisticName = "StatN" 
        parameter for statistic... 
    }
    Etc 
]

smsStatisticsWriter parameters

The smsStatisticsWriter section accepts the following parameters.

tempDir

Syntax:	`tempDir = "dir"`
Description:	The temporary directory for writing intermediate statistics files to.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	"/IN/service_packages/SMS/tmp/smsStatisticsWriter"
Notes:
Example:	`tempDir = "/IN/service_packages/SMS/tmp/smsStatisticsWriter"`

outDir

Syntax:	`outDir = "dir`"
Description:	The base directory for storing completed statistics files.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	"/IN/service_packages/SMS/logs/smsStatisticsWriter"
Notes:
Example:	`outDir = "/IN/service_packages/SMS/logs/smsStatisticsWriter"`

outDirType

Syntax:	`outDirType: = "type"`
Description:	File store type.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:	HASH or FLAT
Default:	"FLAT"
Notes:
Example:	`outDirType: = "FLAT"`

outDirExpectedFiles

Syntax:	`outDirExpectedFiles = num`
Description:	The maximum number of files in outDir when outDirType is HASH.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	65536
Notes:
Example:	`outDirExpectedFiles = 65536`

outDirBucketSize

Syntax:	`outDirBucketSize = size`
Description:	The maximun number of files in any leaf directory when outDirType is HASH.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	10
Notes:
Example:	`outDirBucketSize = 10`

outFileName

Syntax:	`outFileName = "name"`
Description:	The base of the statistics file name.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	"smsStatisticsWriter"
Notes:
Example:	`outFileName = "smsStatisticsWriter"`

maxFileSize

Syntax:	`maxFileSize = size`
Description:	The maximum size of a statistics file (kilobytes).
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	100
Notes:
Example:	`maxFileSize = 100`

maxFileOpenTime

Syntax:	`maxFileOpenTime = sec`
Description:	The maximum time a statistics file can be kept open (seconds).
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	3600
Notes:
Example:	`maxFileOpenTime = 3600`

statsDaemonRestartDelay

Syntax:	`statsDaemonRestartDelay = sec`
Description:	The length of time to allow updated statistics to be replicated to the SLC nodes before restarting the smsStatsDaemon processes on those nodes. (seconds).
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	10
Notes:
Example:	`statsDaemonRestartDelay = 10`

statsDaemonStartupTime

Syntax:	`statsDaemonStartupTime = <seconds>`
Description:	The length of time (in seconds) to allow for smsStatsDaemon to restart and initialize after startUp request issued.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	5
Notes:
Example:	`statsDaemonStartupTime = 8`

scanInterval

Syntax:	`scanInterval = msec`
Description:	Length of time between scans of the statistics (microseconds).
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	100000
Notes:
Example:	`scanInterval = 100000`

replicationAllowance

Syntax:	`replicationAllowance = <seconds>`
Description:	The time (in seconds) to allow for stats to be replicated to SMS from SLC.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	60
Notes:	For best results this value should be less than any of the reporting periods of statistics included in event configuration.
Example:	`replicationAllowance = 40`

Events

Event configuration parameters may or may not have default values, where defaults are defined that parameter may be omitted, for all others the parameter is required. There may be multiple events configured.

Each event accepts the following parameters.

Events = [ 
    { 
        eventName = "EventGood" 
        resetAllEventStatisticsOnStartup = true 
        eventResetBaseTime = "20110511130000" 
        resetInterval = { 
            days = 0 
            hours = 0 
            minutes = 4 
            seconds = 0 
    } 
    eventStartDateTime = "20100728000000" 
    eventEndDateTime = "20101231000000" 
    eventWritePeriod = 30 
    Statistics = [ 
        { 
            applicationName = "TELEVOTING" 
            statisticName = "Stat1" 
}

eventName

Syntax:	`eventName = "name"`
Description:	The name of the event.
Type:	String
Optionality:	Required
Allowed:
Default:	no default
Notes:
Example:	`eventName = "eventGood"`

resetAllEventStatisticsOnStartup

Syntax:	`resetAllEventStatisticsOnStartup = true\|false`
Description:	Reset all statistics defined for the event on start up.
Type:	Boolean
Optionality:	Optional (default used when omitted)
Allowed:	true, or false
Default:	true
Notes:	If true, individual statistic resetStatisticOnStatup config is overidden.
Example:	resetAllEventStatisticsOnStartup = false

eventResetBaseTime

Syntax:	`eventResetBaseTime = "<date and time>"`
Description:	Sets a specific date and time base to calculate resets for the statistics configured for this event.
Type:	String
Optionality:	Optional (default used if not set).
Allowed:
Default:	"20100101000000" - (00:00:00 on Jan 1 2010)
Notes:	Date and time format is yyyymmddHHMMSS The event resetInterval parameter timing starts from this parameter's date and time.
Example:	eventResetBaseTime = "20110511130000"

resetInterval

Syntax:	`resetInterval = {<days>,<hours>,<minutes>,<seconds>}`
Description:	The interval between periodic resets of all statistics configured for the event.
Type:	Parameter list
Optionality:	Optional (default used if missing)
Allowed:
Default:	Global resetInterval values are used.
Notes:	If non zero, the reset period configured for individual statistics will be overridden.
Example:	resetInterval = { days = 0 hours = 0 minutes = 4 seconds = 0 }

eventStartDateTime

Syntax:	`eventStartDateTime = "dateandtime"`
Description:	The event start time.
Type:	String
Optionality:	Required
Allowed:	Expected format yyyymmddHHMMSS
Default:	no default
Notes:	Statistics will only be collected for the event between the start and end times.
Example:	`eventStartDateTime = "20100728000000"`

eventEndDateTime

Syntax:	`eventEndDateTime = "dateandtime"`
Description:	The event end time.
Type:	String
Optionality:	Required
Allowed:	Expected format yyyymmddHHMMSS
Default:	no default
Notes:	Statistics will only be collected for the event between the start and end times.
Example:	`eventEndDateTime = "20101231000000"`

eventWritePeriod

Syntax:	`eventWritePeriod = <seconds>`
Description:	The period (in seconds) between successive writes of statistics data to the report file.
Type:	Integer
Optionality:	Optional (default used if not set).
Allowed:
Default:	0
Notes:	When set to 0 the write period is synchronized to the shortest sample period defined for the statistics included in the event.
Example:	`eventWritePeriod = 30`

Event Statistics

Each event can collect more than one statistic.

For example the event "EventGood" is a contest where you can vote for three contestants. The statistic for each contestant is collected separately to determine the winner.

Each event statistic accepts the following parameters:

applicationName

Syntax:	`applicationName = "name"`
Description:	The name of application to which the statistic belongs.
Type:	String
Optionality:	Required
Allowed:
Default:	no default
Notes:
Example:	`applicationName = "TELEVOTING"`

statisticName

Syntax:	`statisticName = "name"`
Description:	The name of the statistic.
Type:	String
Optionality:	Required
Allowed:
Default:	no default
Notes:
Example:	`statisticName = "Stat1"`

Statistics

Statistics generated by the SMS and SLCs are collected in the SMF_STATISTICS table of the SMF database. A set of tools provides management functions. Functions include:

Filtering statistics
Setting rules for statistics thresholds which raise alarms
Running reports against the statistics held in SMF_STATISTICS

For more information about using these functions, see Service Management System User's Guide.

Event Name File Format

The smsStatisticsWriter process creates a file format as detailed below for an event configured in SMS.smsStatisticsWriter.Events.eventName:

===============================

"Event Name"

"Start Time"

"Stop Time"

===============================