Event Management (Release 4.6.2)

Intelligent Contact Management software tracks events for processes and applications running in the system. An event is any significant occurrence within the ICM system that you might want to know about. Events are recorded on a local and system-wide basis to aid you in maintaining the ICM system.

This chapter provides an overview of event logging and management in the ICM system. It also describes how to use the ICM's event viewing tool.

Overview

Intelligent Contact Management software is a distributed call routing system with components that span several networks. The major components of ICM software generate event data that can be useful in troubleshooting and maintaining the system.

The ICM Event Management System (EMS) logs events from processes throughout the system and stores the event data in the central database. For example, a typical EMS event might record that a system component has been disconnected.

The EMS also saves events from individual processes in per-process log files on the local computer. These files document events for a specific process running on a specific computer.

These ICM components are critical to the effective routing of calls in the ICM system. As a system administrator, you need to be informed almost immediately when significant events occur on these components. Admin Workstations also log EMS events, but only to the NT Application event log. This is because Admin Workstations are not as critical to call routing as the other components of ICM software.

As shown in Figure 7-1, event logging in the ICM system involves central and remote system components. The Event Management System (EMS) enables ICM components and the processes that run on them to report events back to the Central Controller. The Central Controller then forwards the events to the Logger for storage in the central database. If the Historical Data Server (HDS) option used, events are also forwarded to the HDS database on the Distributor AW. Some of these EMS events are also forwarded to the Customer Support Center Listener process by the Distributed Diagnostic and Services Network (DDSN).

ICM software classifies events based on their severity. Table 7-1 lists the severity levels for ICM events.

Event Data Storage

All computers that have SQL Server also contain SQL Server transaction log files. These files are found under the SQL installation directory on individual computers. You can examine the transaction logs using a standard text editing tool such as Notepad.

Table 7-1 Event Severity
Severity	Description
Error	Indicates a significant problem such as a loss of data, incorrect configuration data, or a loss of functions. For example, an error would be logged if a Peripheral Gateway were to become disconnected.
Warning	Indicates a potential problem in the ICM system. For example, a warning event might be logged if a user attempted to add a duplicate record to the configuration. Although an event such as this does not cause a loss of functions, it is something that you should note.
Informational	Documents a successful operation for a major process or application in the system. For example, an informational event might indicate that the peripheral data service was activated on a specific Peripheral Gateway in the system.
Trace	Used for internal testing and diagnostics only.

Table 7-2 Event Logging Locations
Location	Events	Viewer
ICM central database and HDS database (Application_Event and Event table)	The Event table contains all events that have been logged by the Event Management System from ICM processes throughout the system. The Application_Event table contains only those events that are of interest to a Limited AW user. The central and HDS databases do not store trace messages.	Monitor ICM Event Viewer
Windows NT event logs	NT-specific event data from the local computer. This event data includes EMS Warning and Error events that were generated by ICM processes on the computer.	Windows NT Event Viewer
ICM per-process log files (.ems)	All EMS events and trace messages logged by processes on the individual computer. The log files are saved in the ICM component \logfiles directory on each computer. For example, on an Admin Workstation the log files are stored in the aw\logfiles directory.	ICM Dumplog utility
ICM command log files (.log)	Status information reported by scheduled jobs. These files are saved in the \logfiles directory along with the per-process log files.	Notepad or WordPad

For more information on SQL Server log files, see the Microsoft SQL Server System Administrator's Guide.

Event Viewing Tools

Viewing event data in the ICM system requires that you use different tools to view the event data that reside in different parts of the system.

•

Monitor ICM Event Viewer. This tool is part of the Monitor ICM application. It allows you to retrieve near real-time and historical EMS event data from the ICM central or HDS database. The Monitor ICM Event Viewer allows you to display only EMS-generated events that are stored in the central database. On a Limited AW, the Event Viewer reads events from the Application_Event table; on all other Admin Workstations it reads events from the Event table.

•

Windows NT Event Viewer. This tool is part of Windows NT. Use the Windows NT Event Viewer to manage NT event logs for Windows NT systems.

•

Dumplog.exe utility. This is a utility for displaying per-process log files at individual ICM computers. You can view the log files on the screen or export them to text files.

•

Notepad or WordPad. These Microsoft tools can be used to view command log files and any other event log files that have been saved in a text file format.

When to View Events and Log Files

The following guidelines apply to examining the different types of event data collected by the ICM system:

•

Daily enterprise check. Use the Monitor ICM Event Viewer at least once a day to examine the event data in the central database. If you notice that an unusual number of events are being logged by certain processes, you can further investigate individual computers by viewing Windows NT events and the per-process log files.

•

Component check. Use the Windows NT Event Viewer as needed to examine the NT Application and System event logs on systems you have identified as having problems. For example, if you notice EMS error events being generated by the CallRouter, you can use the Windows NT Event Viewer on an Admin Workstation to examine the event data on the CallRouter computer.

•

Process check. Use the per-process log files as needed to evaluate the specific processes that may be responsible for generating errors. To view these logs, use the Dumplog utility provided with ICM software.

Historical Database Event Data

The EMS event data can give you a good idea of activity throughout the ICM system. You can retrieve this data on demand at any Admin Workstation by using the Monitor ICM Event Viewer.

Note Admin Workstations do not log EMS event data to the ICM central or HDS database. Processes running on Admin Workstations log events only to per-process log files and local Windows NT event logs.

Purging the Event Data

The EMS event data is stored in the Application_Event and Event tables of the central or HDS database until the data are purged. When you set up the ICM Logger and the HDS machine, you can specify the number of days for which these data are maintained.

For more information on data retention in the central and HDS databases, see Chapter 4, "Database Sizing."

Viewing the Event Data

Monitor ICM provides an Event Monitor and an Event Viewer to help you manage events in the ICM system. The Event Monitor is a simple counter that counts, in real-time, the number of EMS events being logged to the central or HDS database. The Event Viewer is a tool that allows you to retrieve event data from the database and display it at the Admin Workstation. Once the data is displayed, it can be sorted, filtered, printed, or exported in any of several file formats.

For a Limited AW, the Event Monitor and Event Viewer take information from the Application_Event table. In other environments, they take information from the Event table.

Event Monitor

The Event Monitor appears each time you start Monitor ICM. It allows you to see how many events of each severity (error, warning, and informational) are occurring in the system. Each time an event is logged at the central database, the real-time feed signals the Distributor Admin Workstation and one of the counts is incremented. If the Real-Time Client or Distributor processes are inactive, these counts are not incremented.

You can clear the Event Monitor counts by clicking on the colors. You can close the Event Monitor by choosing Close from the Event Monitor Control menu. Once the Event Monitor is closed, you can redisplay it by choosing View > Event Monitor from the Monitor ICM menu.

The Cisco ICM Software Supervisor Guide provides more details on using the Event Monitor.

Event Viewer

The Monitor ICM Event Viewer allows you to view the event data that is stored in the central database. These data include EMS-generated events that indicate potential hardware, application, or communications problems within the ICM system. ICM software records the specific process that generated the event and provides other details that can help you pinpoint the cause of the problem.

To display the Event Viewer:

Start Monitor ICM by double-clicking the Monitor ICM icon in the Admin Workstation group.Click the Events button or choose View >Event Viewer. The Event Viewer window appears:

On initial display, the Event Viewer displays the most recent event data. If you need to see earlier event data, specify your own start and end dates and times by using the Specified option.

Note Some categories, such as the X25 and TCP/IP Handlers, may be used by various system components. Where possible, the specific components that use each category are listed. However, this information is subject to change.

Table 7-3 Monitor ICM Event Viewer Categories
Category	Description
ACP1000 PIM	The PG component that communicates with an Ericsson ACP1000 ACD.
Admin Workstation	The personal computer used to monitor the handling of calls in the ICM system. The Admin Workstation is also used to modify the system configuration and scripts.
Alcatel A4400 PIM	The PG component that communicates with an Alcatel A4400 ACD.
App Bridge Server	A server process that operates between the Peripheral Gateway and the Aspect CallCenter ACD. The Application Bridge Server monitors disconnect and transfer messages between the Peripheral Gateway and applications running on the Aspect CallCenter Application Bridge.
Application Gateway	An entity that allows an ICM routing script to communicate with an external process.
ECS (G3) PIM	The PG component that communicates with a Lucent DEFINITY ECS ACD.
BT NIC	The Network Interface Controller is the ICM component that communicates directly with the British Telecom signaling network.
CallRouter	The part of the ICM system that receives call routing requests and determines call destination.
CIC	The Customer Interface Controller. Process that maintains communication between the NAM, on which it runs, and one or more CICMs.
CompuCall Server	A server process that operates between the Peripheral Gateway and the Nortel DMS-100 ACD.
CSC Listener	The Customer Support Center process that receives alarms from customer sites.
CSFS	The Customer Support Forwarding Service that sends information to the Customer Support Center.
CTI Link	Computer Telephony Integration link. The CTI Server process on a PG that serves as an interface between ICM software and client CTI applications.
DB Agent	A communications process on the Central Controller that is responsible for validating access to the central database from Admin Workstations. In addition, the DB Agent manages communications between the Update Central Controller tool and the central database.
DBWorker	Host Database Lookup. Process that queries external databases and uses resulting data in call routing.
DCServer	The PG component that handles Demand Commands for a Rockwell Galaxy ACD.
Device Management	The Device Management Protocol (DMP) is the session layer communications protocol used within the ICM system.
Diagnostic	Used for diagnostic messages.
EMS Test Message	Reserved for internal testing of the Event Management System (EMS).
EMT Protocol	The External Message Transport Protocol. EMT is the transport layer protocol used in ICM software. It is responsible for the ordered, reliable delivery of messages between nodes in the ICM system. EMT is layered over TCP.
FrTelecom NIC	This Network Interface Controller is the ICM component that communicates directly with the France Telecom signaling network.
G2 PIM	The PG component that communicates with a Lucent G2 ACD.
Galaxy Demand Command Server	Rockwell Demand Command Server. Admin Workstation process that provides access to Demand Commands on attached Galaxy ACDs.
Galaxy PIM	The PG component that communicates with a Rockwell Galaxy ACD.
Generic NIC	A special Network Interface Controller used in testing. The Generic NIC receives route requests from the ICM's call generator. (CallGen).
Generic PIM	The PG component that communicates with a generic ACD.
ICP NIC	The Network Interface Controller that communicates directly with the AT&T signaling network.
ICRP NIC	The Intelligent Call Routing Protocol (ICRP) Network Interface Controller (NIC). This NIC resides on the NAM. It allows the NAM to send route requests to CICMs by using the ICRP.
INAP Gateway	The Intelligent Network Application Protocol (INAP) Gateway is a DOS-based process that communicates directly with an SS7 network. The function of the INAP Gateway is to transport INAP messages between the SS7 network and the INAP NIC.
INAP NIC	A network interface controller that uses the Intelligent Network Application Protocol (INAP) to communicate with the SS7 network.
INRCEngine	The Routing Client (RC) Engine for the INAP NIC. This process provides a network-independent application programming interface which allows NICs to interface with the CallRouter process.
INCRP NIC	The Intelligent Call Routing Protocol (ICRP) Network Interface Controller (NIC) for CICMs. This NIC resides on the CICM. It allows the CICM to communicate with NAMs by using the ICRP. The ICRP NIC component for the CICM.
Logger	The part of ICM software that stores information about the entire system in the central database. The Logger is the interface between the CallRouter and the Database Manager (SQL Server). The Logger works with the Database Manager to maintain the data that is used in reporting and making routing decisions.
MCI NIC	The Network Interface Controller that communicates directly with the MCI signaling network.
Meridian PIM	The PG component that communicates with a Nortel Meridian ACD.
Message Delivery	The Message Delivery Service (MDS) is a Central Controller and Peripheral Gateway component that provides a reliable message delivery service to the ICM application processes. MDS allows applications to communicate by sending messages to and receiving messages from other applications.
NEC NIC	The Network Interface Controller that communicates directly with the NEC signaling network.
Node Manager	A process that runs on each physical node (computer) in the ICM system and manages other ICM processes on that system. The Node Manager is responsible for initializing nodes and for restarting failed processes.
Nortel NIC	The Network Interface Controller that communicates directly with the Nortel signaling network.
Peripheral Controller	The Open Peripheral Controller (OPC) is the interface between the Peripheral Interface Manager (PIM) and the CallRouter. The OPC is responsible for supplying uniform message sets from various PGs to the CallRouter. This ensures that the CallRouter sees no difference when communicating with PGs that are connected to proprietary switches.
Peripheral Interface	The Peripheral Interface Manager (PIM) is the proprietary software that manages the interface between the Open Peripheral Controller on the PG and the peripherals (ACDs) of different vendors.
Peripheral Gateway Library	A library of code on PGs that is shared by the Peripheral Interface Manager (PIM) and the Open Peripheral Controller (OPC). This library contains shared objects and protocol conversion code that can be used by both the PIM and OPC.
Process Synchronization	Software that manages the state transfer for the two sides of the duplexed ICM system. For example, if SideA of the CallRouter fails, SideB immediately takes over. When SideA returns, the Process Synchronization software synchronizes SideA with the current state of ICM processes. In this way, state transfers from SideA to SideB can take place without interruption to the system.
RC Engine	The Routing Client (RC) Engine provides a network-independent application programming interface which allows the network-specific Network Interface Controllers (NICs) to interface with the CallRouter process.
Real-Time Feed	A communications channel that operates between the Central Controller (Real-Time Server) and Admin Workstations (Real-Time Clients). The real-time feed forwards to Admin Workstations the real-time data that has been retrieved from Peripheral Gateways.
Registry Synchronization	Software that synchronizes registry settings on nodes on both sides of a duplexed ICM system. For example, if SideA of the CallRouter fails, SideB immediately takes over. When SideA returns, the Registry Synchronization software synchronizes the SideA CallRouter registry with the current Side B CallRouter registry to account for any registry changes that may have taken place while SideA was down. In this way, nodes on both sides of a duplexed system maintain identical registry settings.
R9005 PIM	The PG component that communicates with a Siemens Rolm 9751 CBX.
SER Handler	An ICM-supplied serial communications library that is used by the Spectrum PIM.
Siemens	The PG component that communicates with a Siemens Hicom 300E ACD.
Spectrum PIM	The PG component that communicates with a Rockwell Spectrum ACD.
Sprint NIC	The Network Interface Controller that communicates directly with the Sprint signaling network.
Stentor NIC	The Network Interface Controller that communicates directly with the Stentor signaling network.
Symposium PIM	The PG component that communicates with a Nortel Symposium ACD.
TCP Handler	An ICM-supplied library that is used by the Spectrum PIM.
VarCTI Link	A subcomponent of the Galaxy PIM that communicates with a VarCTI system.
VRU PIM	The PG component that communicates with a Voice Response Unit peripheral.
Windows Sockets	Windows sockets are a standard UNIX-style interface for networking. Sockets combine a port number and an IP address to uniquely identify applications running in a Windows NT network.
X25 Handler	An ICM-supplied library that is used by the Spectrum PIM, France Telecom NIC, and the DMS-100 ACD.
X25LIB	An ICM-supplied library that resides on top of the X.25 protocol. The X.25 protocol and the X25LIB are used in ICM communications with the Rockwell Galaxy Peripheral Gateway (PG) and the Rockwell Galaxy Demand Command Server.

Event Indication

The Event Monitor remains open while you view event data in the Event Viewer. It continues incrementing the counts as new events are received at the central database. Counts are incremented only for those events that meet the current event filter settings. Other event data might also be accumulating in the central database, but this accumulation is not indicated through the Event Monitor.

For more information on filtering event data, see " Filtering Events," later in this chapter.

The Fetch More button is disabled as long as no new events are being logged to the central database. When the Fetch More button becomes enabled, it indicates that new events have been logged. You can retrieve this new event data by clicking the Fetch More button.

Retrieving Historical Event Data

You may want to view events that took place earlier in the day or on previous days. Remember that only events that match the event filter settings are retrieved from the ICM central database. To retrieve other events, you must set the event filter appropriately.

For information on the event filter settings, see " Filtering Events," later in this chapter.

To retrieve historical event data:

Step 3

Double-click on a day to specify the start of the event list. (You can also click on the left and right arrows in the calendar to display a different month.)

Step 4

Enter a Start Time by highlighting the characters and incrementing the time using the up and down arrows.

Step 5

Click on the End Date/Time down arrow and choose an end date from the calendar. (If you leave the End Date/Time fields blank, the Event Viewer displays events up to the current day and time.)

Step 8

By default, the most recent events in the range are listed at the top of the list. You can change the way the events are sorted. See "Sorting Events," later in this section, for more information. Use the scroll bars to view more events in the list.

Note The amount of data retrieved from the central database is directly related to the range of time you enter in the Start and End Date/Time fields. Try to be specific in your date range selection. Too much event data may be difficult to work with.

Viewing Event Details

Once you have a list of events displayed, you can choose an event entry and get more detailed information such as the specific process that generated the event.

To view more details about an event:

Step 1

Double-click on an event entry in the Event Viewer window. An Event Detail dialog box similar to the following appears.

Step 2

Click the Previous and Next buttons to display details about other events without returning to the Event Viewer window:

Step 3

To print the event detail, click the Print button. The event detail is automatically sent to the printer.

Step 4

Click Close to close the Event Detail dialog box and return to the Event Viewer window.

Filtering Events

Monitor ICM allows you to filter events so that only specific event types are displayed in the Event Viewer and counted by the Event Monitor. Event data for the entire ICM system is still logged to the central database, but only event data that meets the event filter criteria is displayed at the Admin Workstation.

For example, you might set the event filter to display only errors and warnings that are associated with the Logger. These filter settings would exclude any event data from processes in the ICM system other than the Logger. In addition, only errors and warnings would be counted in the Event Monitor. The informational event counter would not be incremented.

To set the Event Filter:

Step 1

Choose View > Set Event Filter from the Monitor ICM menu. The Event Filter dialog box appears:

By default, the Event Monitor and the Event Viewer display events for all processes in the ICM system and for all three severity levels. However, you can choose your own event filter options and set them as the default.

Step 2

Select options from the Event Category, System Type, and Severity Type lists. You can combine selections to limit or expand which events are displayed. You must select at least one item from the Event Category, System Type, and Severity Type lists. (See the subsections that follow for information on each filter option.)

Events are displayed for the categories, system types, and severity levels you select. Items that are not selected are excluded from the Event Viewer and from the Event Monitor. Events for the items that are not selected are still logged to the central database, but they are not displayed at the Admin Workstation.

The filter settings remain in effect only for the current Event Viewer session. Optionally, you can save the settings and make them the new default.

To make the current filter settings the default:

Click the Make Default check box. The filter settings remain set for subsequent Monitor ICM sessions until you change them again.

Sorting Events

The Event Viewer provides several options for sorting events once they are displayed. The sorting options help you further organize the list of events. By default, events are sorted first according to the time they were received at the ICM central controller. The most recent events are listed at the top of the list followed by older events.

To sort events in the Event Viewer:

Step 1

With the Event Viewer displayed, position the mouse cursor within the event list and click the right mouse button. The Specify Sort Columns dialog box appears:

Step 2

Click and drag the column names you want to sort by from the Source Data box into the Columns box. For example, if you want events sorted by Category, drag the Category column name to the Columns box. (Any items in the Columns box that you no longer want as sort items can be dragged back to the Source Data box.)

Step 3

To add another sort item, click and drag another Source Data item (column name) into the Columns box. The order in which you place items in the Columns box determines the precedence of the sort. For example, if you selected Category and then Side, the Event Viewer sorts first by Category and then by Side. (You can also drag names within the Columns box to switch their order.)

Note

The sort options you set remain in effect for the current Event Viewer session only.

The Ascending sort order check box is selected by default for all sorting options. If you want Descending sort order, you can deselect the Ascending checkbox:

If required, you can edit individual column expressions to change how they sort data. If you double-click on a column name in the Columns box, the Modify Expression Dialog box appears. Typically, you do not need to modify any of the column expressions.

Exporting Event Data

Monitor ICM supports data export to several file formats. You can export the event data in a format for use in another application or simply save the data in a text file format. You can also use the export feature to record specific events that you want to distribute to the Customer Support Center (CSC).

For more information on using event data and forwarding files to the Customer Support Center, see Chapter 8, "Support Facilities."

To export event data:

Monitor ICM saves all the data displayed in the Event Viewer columns. Be sure to filter out any event data that you do not need; otherwise, you may create a file that is too large to be viewed using a standard text editor.

Step 1

With the Event Viewer window displayed, filter and sort the event data using the options described earlier in this section.

Step 2

When the appropriate data is displayed on the screen, click the Export Data button.

Step 4

Click on the Save in down arrow to choose a drive and directory in which to store the exported data. The Save As dialog box defaults to the last directory in which you worked. (See the following note.)

Step 5

Specify a file name for the export file. (You do not have to enter a file extension.)

Step 6

Click the Save as type down arrow and choose a format for the export file.

Note

During the current Monitor ICM session, you may have saved reports or exported report data to another directory (for example, the aw\custom\persvc directory). This directory may now appear as the current directory in the Save As dialog box. You can select any other directory in which to export the data.

Windows NT Event Logs

Each Windows NT computer logs NT events to its own local NT System, Application, and Security event logs. You can view NT event data through the Windows NT Event Viewer (on the local computer or from a remote computer). Windows NT computers include CallRouters, Loggers, PGs, and Admin Workstations. Windows NT does not track events for DOS-based NICs.

All EMS events that are logged to the central database with an Error or Warning severity level are also logged to the local computer's Windows NT Application Event Log. This ensures that ICM events are logged at the source and can be viewed locally through the NT Event Viewer.

NT Event Log Settings

These values ensure that none of the logs becomes full. The 1024K setting ensures that large log files can be accommodated in any of the logs. The Application log must overwrite events as needed because it logs EMS Errors and Warnings, NT application events, and SQL Server events. If it could not overwrite events, the Application log could quickly become full.

Viewing the NT Event Logs

The Microsoft Windows NT Event Viewer allows you to view and manage events on a system-by-system basis. You can use the NT Event Viewer to isolate problems on specific computers. Typically, you first check for unusual event activity in the system by using the Monitor ICM Event Viewer. Once you identify an individual computer as generating errors, you can use the Windows NT Event Viewer to view the computer's local NT event data. All EMS-generated Error and Warning events are logged to the local computer's Windows NT Application Event Log.

The Windows NT event logging process starts automatically each time a Windows NT system is started. At an Admin Workstation, you can use the NT Event Viewer to view event data for that computer or for other locally connected computers. For example, you might select a PG or a Logger and view the NT event data for those computers.

Table 7-4 NT Event Log Settings
Log	Size	Wrapping
Application	1024K	Overwrite as Needed
System	1024K	Overwrite Events Older than 7 days
Security	1024K	Overwrite Events Older than 7 days

Note The Windows NT Event Viewer allows you to view events for Windows NT systems only. You cannot view events for DOS-based NICs.

To start the Windows NT Event Viewer:

In the Administrative Tools group in the Windows NT Program Manager, double-click the Event Viewer icon. The Event Viewer window is displayed:

You can change to different logs (for example, the Application, System, or Security logs) by choosing Options from the Log menu.

Windows NT Logs and Event Types

You can choose between three different logs, depending on the type of event data you want to view. You can view these log files for any Windows NT computer. The Application log is typically the most useful log since it contains ICM-related events.

•

Application log. Records events logged by Windows NT applications (including all ICM applications and processes running on the local computer). For example, when the Node Manager restarts on the local computer, an informational event is entered in the Application log.

•

System log. Records events logged by the Windows NT local computer system components (for example, disk drives, network drivers, event log services). For example, the failure of a driver or other local component to load during startup is recorded in the System log.

•

Security log. Records security events. This log keeps track of changes to system security. For example, attempts to log on might be recorded in the security log.

The event types in the Windows NT Event Viewer (Error, Warning, and Informational) have similar meanings to those listed earlier in Figure 7-1. The NT Event Viewer provides two additional event types related to system security:

•

Success Audit. Audited security access attempts that were successful. For example, a user's successful attempt to log on to the system might be logged as a Success Audit event.

•

Failure Audit. Audited security access attempts that failed. For example, if a user tried to access a network drive and failed, the attempt might be logged as a Failure Audit event.

For more information on the NT Event Viewer, see the Microsoft Windows NT System Guide.

Viewing Event Data from Other Systems

When you first start the Windows NT Event Viewer, event data for the local computer is displayed. However, you can connect to another computer in the local network (for example, a Peripheral Gateway) in order to examine its event data.

Note To view events for other computers, you must be logged in as an NT Administrator.

To connect to another computer:

Step 2

In the Computer field, type the computer name of the computer to view. You can also select a Computer name from the Select Computer list.

Step 3

Click the OK button. The Event Viewer displays event data for the selected computer.

Per-Process Log Files

The per-process EMS log files are stored in the ICM component \logfiles directory on the local computer as well as forwarded to the central database. For example, per-process log files on Admin Workstations are stored in the aw\logfiles directory. EMS log files have the suffix .ems.

The \logfiles directory also contains command log files (.log), which document how commands such as printrpt executed. For information on these files, see the section, " Command Logs," later in this chapter.

Purging the Log Files

The purgeold command deletes old per-process log files. ICM software automatically schedules purgeold to run nightly and delete any log files more than 30 days old. This ensures that log files do not accumulate and take up too much disk space.

Not all log files are deleted; only those files or entries that are older than 30 days. This ensures that at least 30 days of data are kept on-line.

The setpurge command allows you to change the 30 day default. For example, the following command entered at the Command Prompt makes the purgelog job purge files that are older than 20 days:

Note The per-process log files contain detailed event data that is valuable to Customer Support. Do not change the purge schedule to delete these files too frequently. You could delete valuable diagnostic information.

Naming Conventions

Each per-process log file has a prefix that indicates the process within ICM that generated the event. Each file name includes the date and time the log was created. All log files end with an .ems file extension.

Table 7-5 lists the process names and prefixes and provides brief descriptions of each process. The following example shows the format of a log file name:

The PPP is a prefix that indicates the process. For example, the following log file is for the real-time distributor process. It was created on February 8, 1996 at 9:48:39 A.M.

The timestamp on a log file is in 24-hour format. For example, 3:00 P.M. is indicated as 15:00; 9:00 A.M is indicated as 09:00.

Table 7-5 Process Prefixes and Descriptions
Prefix	Process	Description	Node(s)
acdsim	ACDSIM	An ICM software process that simulates the functions of an ACD. Used for testing purposes.	AW, Logger, CallRouter, PG
agi	APPGW	The Application Gateway process, which allows ICM software to interact with external host applications.	CallRouter
ccag	CCAGENT	Central Controller DMP Agent. Device Management Protocol Agent that manages session layer communications with ICM nodes.	CallRouter
cic	CIC	The Customer Interface Controller. A process that maintains communication between the NAM, on which it runs, and one or more CICMs.	CallRouter
csfs	CSFS	Customer Support Forwarding Service. Receives, filters, and saves appropriate events for delivery to the Customer Support Center.	Logger
ctisvr	CTILINK	Computer Telephony Integration server. A PG process that serves as an interface between ICM software and client CTI applications.	PG
dba	DBAGENT	Central Controller Database Agent. Communications process that validates access to the central database.	CallRouter
dbw	DBWORKER	Host Database Lookup. Process that queries external databases and uses that data in call routing.	CallRouter
dcserver	DCSERVER	Rockwell Demand Command Server. Admin Workstation process that provides access to Demand Commands on attached Galaxy ACDs.	Admin Workstation
dtp	DTP	Customer Support Data Transfer Process. Transfers events from the Logger to the Customer Support Center.	Logger
edt	SCRIPTED	ICM Script Editor. Tool used to create and schedule call routing scripts.	Admin Workstation
ftp	FTPPROC	File Transfer Protocol. Transfers Rockwell Resource Management Center (RMC) reports to the Admin Workstation.	Logger
hsl	HSLTRACE	Northern Telecom High-Speed Link diagnostic tool.	PG
hsltomei	HSLtoMEI	Northern Telecom High-Speed Link and Meridian Event Interface diagnostic tool.	PG
icrp	ICRP	NIC for sending route requests between NAMs and CICMs. Uses the Intelligent Call Routing Protocol (ICRP).	CallRouter
inapgate	INAPGATE	The Intelligent Network Application Protocol (INAP) Gateway is a DOS-based process that communicates directly with an SS7 network.	INAP Gateway DOS system
inapnic	INAPNIC	NIC for the Intelligent Network Application Protocol (INAP).	CallRouter
incrpnic	INCRPNIC	The ICRP NIC component for the CICM.	CallRouter
listener	CSCLISTENER	The process on the CSC Logger that receives events from multiple ICM installations.	Logger
lgr	LOGGER	Database Logger. Process that stores historical data and information about the entire system in the central database.	Logger
mci	MCI	NIC for ICM communication with the MCI signaling network.	CallRouter
mds	MDS	Message Delivery Service. Process that provides reliable message delivery between ICM processes.	CallRouter, PG
nm	NODEMAN	Node Manager. Process that manages, restarts, and initializes processes on ICM nodes.	Dist. AW, CallRouter, Logger, PG
nmm	NMM	Node Manager Manager. Process that manages, restarts, and initializes the Node Manager process on each ICM node.	Dist. AW, CallRouter, Logger, PG
nic	nic	A special Generic Network Interface Controller (NIC) used in testing. The Generic NIC receives route requests from the ICM's call generator (CallGen).	CallRouter
nortelnic	NTNIC	NIC for ICM communication with the Nortel signaling network.	CallRouter
opc	OPC	Open Peripheral Controller. Interface between the PIM and the CallRouter. Supplies the CallRouter with uniform message sets from different PG types.	PG
pgag	PGAGENT	Peripheral Gateway DMP Agent. The Device Management Protocol Agent that manages session layer communications between the PG and CallRouter.	PG
pim1, pim2, pim3, etc.	varies	Peripheral Interface Manager. The proprietary interface between a peripheral and the PG.	PG
rcv	RECOVERY	Central Database Recovery. Recovers central database historical data.	Logger
rmc	RMCPROC	Rockwell Resource Management Center process. Periodically generates a Rockwell RMC report and places it in a file.	Logger
rtc	RTCLIENT	Real Time Feed Client. A Distributor AW process that receives real-time data from the Real-Time Distributor.	Distributor AW
rtd	RTDIST	Real Time Feed Distributor. A Distributor AW process that distributes real-time data to client-only Admin Workstations.	Distributor AW
rtr	ROUTER	CallRouter. Process that receives call routing requests, determines call destinations, and collects information about the entire system.	CallRouter
rts	RTSERVER	Real Time Server. Process that takes real-time data retrieved from PGs and forwards it to Admin Workstations.	CallRouter
sef	SERIALFD	Serial Event Feed. Provides an alarm feed to an external management station.	Logger
spr	SPR	NIC for ICM communication with the Sprint signaling network.	CallRouter
stentornic	STENTORNIC	NIC for ICM communication with the Stentor signaling network.	CallRouter
tsyp	TESTSYNC	Diagnostic tool.	PG
tsyl	TESTSYNC	Diagnostic tool.	Logger
tsyr	TESTSYNC	Diagnostic tool.	CallRouter
upcc	UPDATECC	Update ICM Central Database tool. Copies data from the local database to the central database.	Admin Workstation

Sample File

The EMS creates a new log file each time a process initializes. This means that messages documenting the end of a process can always be found at the end of a log file; messages documenting the initialization of a process can always be found at the beginning of the log file.

Viewing Per-Process Log Files

You can view per-process log files by using the dumplog.exe command. The dumplog.exe command reads the file, formats the event data, and writes the formatted data to the workstation screen. You can also redirect output to a file using either the /o or /of arguments.

To view per-process log files:

Step 2

Change to the \logfiles directory. For example, at an Admin Workstation the directory is icr\instance\aw\logfiles.

You have several options for viewing log files. The most common option is to display the most recent events for a process on the screen.

To display today's events on the screen, type:

This command displays all of today's CallRouter (rtr) events. You can specify any process prefix. You can build on this basic dumplog command by adding date and time arguments.

To dump events for a specific day:

This command displays all rtr information that was logged on January 15, 1997 (the begin date, /bd). To see more than one day's log, use the end date (/ed) argument.

dumplog [ProcessName(s)] [/dir Dirs] [/if InputFile] [/o] [/of OutputFile] [/c] [/bd BeginDate(mm/dd/yyyy)] [/bt BeginTime(hh:mm:ss)] [/ed EndDate(mm/dd/yyyy)] [/et EndTime(hh:mm:ss)] [/hr HoursBack] [/all] [/last] [/prev] [bin] [/m MatchString] [/x ExcludeString] [/ms] [/debug] [/help] [?]

Table 7-6 Dumplog Parameters
Parameter	Description
ProcessName(s)	Specifies a process prefix from Table 7-5. The command dumps the current day's log for that process, unless you specify different dates or times with other arguments.
[/dir Dirs] Directory	Specifies the location of the log files for any processes listed on the command line after the /dir switch. If no /dir switch is used, the current directory is used by default.
[/if] InputFile	Specifies a specific .ems file to dump. The /if token is optional. If you specify an input file, the /bd, /bt, /ed, /et, /hr, and /all arguments are ignored.
/o	Writes output to a text file in the \logfiles directory. The filename is formed by adding the .txt suffix to the specified process prefix or input file name (without the .ems suffix). The file is written to the current directory.
/of OutputFile	Specifies an output text file; for example, c:\temp\mylog.txt.
/c	Specifies continuous output. The command does not exit after reaching the end of the log. Instead, it waits and writes any further any entries that appear in the log.
/bd BeginDate(mm/dd/yyyy)	Specifies the begin date. If specified with /bt, this specifies a range of dates. Otherwise, dumplog dumps events for only the specified date.
/bt BeginTime(hh:mm:ss)	Specifies the begin time. Use with /et to specify a range of time.
/ed EndDate(mm/dd/yyyy)	Specifies the end date. Use with /bd to specify a range of days.
/et EndTime(hh:mm:ss)	Specifies the end time. Use with /bt to specify a range of time.
/hr HoursBack	Specifies a number of hours back from the current time.
/all	Displays all information from the specified process's log files.
/last	Displays information from the most recent log file for the process.
/prev	Displays information from the next to last log file for the process.
/m MatchString	Displays only events that contain a match for the specified string.
/x ExcludeString	Displays only events that do not contain a match for the specified string.
[/ms]	Displays milliseconds in time stamps.
[/mc]	Use multiple colors when dumping merged logs. Each process is given a different color.

You must specify either a ProcessPrefix or an InputFile. If you give only a ProcessPrefix value (for example, rtr, nm, or lgr), dumplog displays the current day's log for that process by default.

To view redirected log files through Notepad:

If you save the log file to a text file (using the dumplog /of argument), you can open the text file from the command prompt by typing:

You can also print the file or include it in an E-mail message. To deliver a log file to the Customer Service Center, save it as a text file and place it in the Logger's export directory. The Distributed Diagnostic and Service Network (DDSN) automatically delivers the file to Customer Support.

Creating a File Type Association

You can make an association for .ems files in Windows NT. A file association allows you to invoke dumplog automatically by double-clicking on a log file name (any .ems file) within Windows NT Explorer.

To set up an association for .ems files:

Step 2

Choose Options from the View menu and select the File Types tab.

Step 3

Click the New Type button. The Add New File Type dialog box appears.

Step 4

Enter a name for the type and the extension ems. Optionally, choose an icon for the file type.

Step 6

Type open as the action type and click the Browse button to find the dumplog command. The command is in the icr\bin directory.

After you add the file association, you can double-click on any .ems log file in File Manager or NT Explorer to display a command window that contains the event data. You can also open log files that are currently logging event data. The command window shows events as they occur.

Command Logs

Certain ICM commands write information to their own log files. The log confirms whether the job properly executed. The log also contains any error messages the job generates.

These command logs are stored along with the per-process log files in the \logfiles directory. However, unlike the per-process log files, you can view command logs directly with a text editor such as Notepad or WordPad.

•

icrprint.log. Contains information from the Print Server. This information describes how the Print Server connected to the ICM database and how each printrpt print job executed.

•

printAT.log. Contains information from Job Scheduler for each printrpt job added.

•

purgecmd.log. Records an entry each time the purgecmdlog.pl command is executed. The entries document the command logs from which old data was deleted.

•

purgeold.log. Records an entry each time the purgelog command is executed. The purgeold command removes ICM per-process log files (.ems files) that are older than the purge limit (30 days, by default). Typical entries include how many .ems files were found and how many were deleted.

The purgecmd.pl job automatically removes entries older than 10 days from icrprint.log and printAT.log. This job is schedule to run automatically every night.

Chapter 6, "Scheduled Jobs," provides more information about viewing and managing the ICM command log files for scheduled jobs.

Table Of Contents