6 Background Processes

This chapter explains how to manage the Advanced Control Services (ACS) processes.

The chapter lists the ACS processes which run on an installed ACS platform. These processes are a combination of inittab processes, and cron processes.

It is a prerequisite 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

Automated ACS Processes (SMS Machine)

The acsSmp package installs three tasks into the /etc/inittab. These tasks should be running at all times. The tasks are:
  • acsCompilerDaemon
  • acsStatisticsDBInserter
  • acsProfileCompiler

These three binaries run from /IN/service_packages/ACS/bin, through start shell scripts also in that directory. The acsSmp packages also install the acsDbCleanup.sh task into the crontab for user acs_oper.

acsCompilerDaemon

The acsCompilerDaemon runs continuously, polling the database to look for newly written control plans and control plan structures (for example, indicated by database field ACS_CALLPLAN.BUILD = B).

The control plan compiler generates the fast-lookup binary compiled control plan data which is actually used at processing time.

The compiler can use plug-ins for additional, specialized functions.

The compiler uses the plug-ins after the standard compilation has completed, and in the order the plug-ins are listed in acs.conf.

Table 6-1 acsCompilerDaemon plug-in

Plug-in Description
libwsdlGenerator.so

This plug-in produces the WSDL code for the operation used by the control plan.

If this is the first operation, the complete WSDL operation set file is produced and this operation inserted.

For all other operations for the same operation set, the code is inserted after the previous operation code.

For further information on operations and operation sets, see OSD User's and Technical Guide.

Startup

This task is started by entry acs0 in the inittab, through the /IN/service_packages/ACS/bin/acsCompilerDaemonStartup.sh shell script.

Location

This binary is located on the SMS node.

Parameters

The acsCompilerDaemon does not support any command line parameters; it is completely configured through the acs.conf file. For more information, see Configuring the acs.conf

Failure

If the acsCompilerDaemon has failed, then control plans will not be compiled. This can be detected by processing the following SQL statement on the SMF database instance:

SELECT ID from ACS_CALL_PLAN where BUILD='B' ; Under normal operation, control plans will only remain in the B state for a few seconds at most.

Output

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

acsSnCpActAlarms

acsSnCpActAlarms queries the ACS_SN_CALL_PLAN_ACTIVATION database table and generates alarms when it finds any scheduled control plans that have been temporarily disabled by Emergency Control Plan Activation.

Location

This binary is located on the SMS node.

Startup

This task is run in the crontab for acs_oper.

/IN/service_packages/ACS/bin/acsSnCpActAlarms

Note:

You may optionally write a shell script (to manually start) if you wish to change defaults.

Parameters

The acsSnCpActAlarms does not support any command line parameters. It is configured through the eserv.config file.

acsSnCpActAlarms Parameters in eserv.config

Here is an example of the acsSnCpActAlarms section in the eserv.config file:
acsSnCpActAlarms = {
              oracleUserIdPassword = "/"
              alarmCheckInterval = 60
              repeatAlarm = false
              serviceNumberTerm = "Service Number"
              alarmReason = "by Alternative Control Plan Activation"
}

oracleUserIdPassword

Syntax: oracleUserIdPassword = "user/pw"
Description: The Oracle user ID and password that acsSnCpActAlarms uses to log into the database.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "/"
Notes:
Example: oracleUserIdPassword = "/"

alarmCheckInterval

Syntax: alarmCheckInterval = mins
Description: Alarms will be generated if the difference between the current time and the control plan's effective date (being in the past) is less than the value specified by this parameter.
Type: Integer
Optionality: Optional (default used if not set).
Allowed:
Default: 60
Notes:

Set this value to a similar/compatible value when running acsSnCpActAlarms from crontab. For example, if crontab is set up to run this process every hour, set this value to 60 minutes.

Warning: Running this process too frequently from crontab may adversely affect system performance. The recommended crontab configuration is to run this process every hour or at a greater interval.

Example: alarmCheckInterval = 60

repeatAlarm

Syntax: repeatAlarm = true|false
Description: If set to true, relevant alarm(s) will be repeated every alarmCheckInterval minutes until alternative control plan replacement is deactivated.
Type: Boolean
Optionality: Optional (default used if not set).
Allowed:
Default: false
Notes:
Example: repeatAlarm = false

serviceNumberTerm

Syntax: serviceNumberTerm = "snterm"
Description: The preferred term used to describe a Service Number.
Type: String
Optionality: Optional (default used if not set).
Allowed:
Default: "Service Number"
Notes:
Example: serviceNumberTerm = "Freephone Number"

alarmReason

Syntax: alarmReason = "reason"
Description: The reason the alarm is generated. This text is used in the alarm description.
Type: String
Optionality: Optional (default used if not set).
Default: "by Alternative Control Plan Activation"
Notes:

Example alarm:

If serviceNumberTerm = "Freephone Number" and alarmReason = "by Emergency Control Plan Activation", then the alarm description would be:

"WARNING. Scheduled Control Plan(Name) for Customer(Name), Freephone Number(123) has been temporary disabled by Emergency Control Plan Activation"

Example: alarmReason = "by Alternative Control Plan Activation"

acsDbCleanup.sh

Purpose

This task runs the SQL statements to delete old data from the ACS Event Counter table ACS_STATISTICS_COUNT, and also to delete old compiler output from the ACS_COMPILE_ERRORS table.

Startup

This task is run in the crontab for acs_oper, by default at 02:00 local system time. It is a shell script, specifically /IN/service_packages/ACS/bin/acsDbCleanup.sh.

Location

This binary is located on the SMS node.

Parameters

The purge-age in days is defined inside the shell script itself, and can be adjusted, subject to limitations of table space in the database.

Failure

If this process is not running, old entries in the specified tables will not be purged.

Output

The acsDbCleanup.sh script writes output to /IN/service_packages/ACS/tmp/acsDbCleanup.sh.log.

acsProfileCompiler

Purpose

The acsProfileCompiler polls for changes in the timezone and/or termination number ranges configured in the database. It then performs changes in the global profile, and in customer profiles for customers who have non-default termination ranges defined.

Startup

This task is started by entry acs2 in the inittab, through the /IN/service_packages/ACS/bin/acsProfileCompilerStartup.sh shell script.

Location

This binary is located on the SMS node.

Parameters

The acsProfileCompiler does not support any command line parameters, it is completely configured through the acs.conf file. For more information, see Configuring the acs.conf

Failure

If the process fails, then changes to the ACS timezone geography set will not be reflected on the SLC call-processing. Similarly, changes to the self-management control plan.

Note:

The termination number constraints for ACS GUI changes will continue to operate as expected.

Output

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

acsStatisticsDBInserter

Purpose

The acsStatisticsDBInserter communicates with the acsStatsMaster process (see below), and polls for changes to ACS event counters.

Note:

This process is not the same as the smsStatsDaemon, although the names are similar.

Startup

This task is started by entry acs1 in the inittab, through the /IN/service_packages/ACS/bin/acsStatisticsDBInserterStartup.sh shell script.

Location

This binary is located on the SMS node.

Parameters

The acsStatisticsDBInserter supports the following command-line options:

Usage:

acsStatisticsDBInserter -h hostname -p port -s sleep

These options can be used for testing to override the values specified in the acsStatisticsDBInserter section of the acs.conf, however they should not be required on an operational platform.

Table 6-2 acsStatisticsDBInserter

Parameter Description
-h hostname host name
-p port port
-s sleep sleep

Failure

This process will periodically write updated event counts to the ACS database, into the table ACS_STATISTICS_COUNT. If there are no event counts being modified by active control plans, the this process may appear to be inactive.

Failure of this process will result in no updates to the ACS_STATISTICS_COUNT table, even when EventCounting nodes are encountered in active control plans.

Output

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

Automated ACS Processes (SLC Machine)

The acsScp package installs one task into the /etc/inittab for one of the SLC machines in an SLC grouping. This task should be running on that one machine at all times. The task is:
  • acsStatsMaster

This binary is run from /IN/service_packages/ACS/bin, through start-up shell script contained within that same directory.

acsStatsMaster

Purpose

The acsStatsMaster runs only on one SLC machine, typically SCP1. All other SLC nodes communicate with the primary through TCP/IP to correlate their ACS event counter values.

Startup

This task is started by entry acs3 in the inittab, through the /IN/service_packages/ACS/bin/acsStatsMasterStartup.sh shell script.

Location

This binary is located on SLCs.

Parameters

The acsStatsMaster does not support any command line parameters, it is completely configured through the acs.conf file. For more information, see Configuring the acs.conf .

Failure

If the acsStatsMaster is not running, then individual nodes will not be able to correlate their event counter values. This will mean that control plans may perform incorrect branching. Additionally, the acsStatisticsDBInserter process will not be able to track changes to ACS event counter values, and there will be no updates to the corresponding table in the database.

Output

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

libacsChassisActions

Purpose

libacsChassisActions provides the functions which enable the ACS feature nodes to interact with other elements in the system, including:

  • SLEE interfaces (such as TCAP IF)
  • Other elements on the network (such as the VPU)

Startup

If libacsChassisActions is included in the acs.conf, libacsChassisActions will be available to slee_acs when the SLEE is started.

For more information about how this included in acs.conf, see ChassisPlugin.

Configuration

libacsChassisActions is configured by parameters in the acsChassis section of acs.conf. For more information, see Configuring the acs.conf.

libacsMacroNodes

Purpose

This slee_acs plug-in library provides the base ACS feature nodes. For more information about the feature nodes provided by this library, see CPE User's Guide.

Startup

If libacsMacroNodes is included in the acs.conf, libacsMacroNodes will be available to slee_acs when the SLEE is started.

For more information about how this included in acs.conf, see MacroNodePluginFile.

Configuration

libacsMacroNodes accepts the parameters from acs.conf. For more information about the available configuration, see:
  • Get Hunting Number Node Configuration
  • Play Variable Part Announcement Node Configuration

libacsService

Purpose

libacsService is the ACS service library plug-in for slee_acs which handles initial set up of control plans. Based on the incoming call details, it loads up the relevant control plan and feature nodes.

Note:

If other applications are installed, they may provide their own service libraries which will be used instead of libacsService.

Startup

If libacsService is configured in acs.conf, it is made available to slee_acs when slee_acs is initialized. It is included in the acsChassis section of acs.conf in a ServiceEntry parameter.

acsChassis ServiceEntry
          (ACS,libacsService.so)

For more information about this configuration, see acsChassis ServiceEntry Configuration (SLC).

Configuration

libacsService supports parameters from acs.conf. For more information, see Configuring the acs.conf .