6 LSMS Logs and Measurements

This chapter describes the logs maintained by LSMS and how to access, navigate, and print them.

Introduction

This chapter provides general information about viewing logs in a browser window (except for measurement logs, which are viewed in an HTML viewer as described in Measurement Logs), as well as removing accumulated logs. It also provides examples and formats of the different types of logs.

Note:

• For information about the permission groups that are authorized to view the various logs, see Table 2-8 and Table 2-9.

• Logs are maintained up to 20 MB for rejected logs and up to 500 MB for transaction logs. The old rotated logs get deleted automatically in a day and new logs start getting pegged in the newly created files.

How Logs are Displayed

The browser from which you launched the GUI is used to display the logs.

A new browser window opens for the first log that you view, and is reused for viewing all subsequent logs.

Use the browser file functions to perform desired tasks, such as printing, searching, and exiting.

Note:

Measurement logs are displayed in the HTML viewer. See Measurement Logs for more information.

Viewing a Log File

To view a log file:

1. Select the type of log file you want to view from the Logs menu.

   Figure 6-1 Logs Pull-down Menu

   
   
   
2. When the Open window appears, select the file you want to view and then click Open to view the log file.

   Figure 6-2 Open Window

   
   
   

Log File Names and Locations

This section describes how log files are named and where they are located.

Log Naming Conventions

Table 6-1 lists information about log files, whether they can be viewed from the LSMS GUI, and the page reference where you can find examples. (<MMDD> refers to the month and day, respectively, on which the log or file was created. Because these logs and files are deleted after seven days, it is not necessary to include the year.)

Table 6-1 Log File Information

Log Type	File Name		Accessible From the GUI?
Security Logs	LsmsSecurity.log.<MMDD>		Yes
NPAC Transactions Logs	LsmsTrans.log.<MMDD>		Yes
Local Data Transactions Logs	LsmsLocalEntry.log.<MMDD>		Yes
NPA Split Logs	LsmsSplit.log.<MMDD>		Yes
Activity Logs	LsmsActivity.log.<MMDD>		Yes
Alarm Logs	LsmsAlarm.log.<MMDD>		Yes
CMIP Logs	LsmsCMIP.log.<MMDD>		Yes
Event Logs	LsmsEvent.log.<MMDD>		Yes
Trace Logs	LsmsTrace.log.<MMDD>		Yes
EAGLE Agent Logs	Lsmseagleagent.log.<MMDD>
Rejected Transactions Logs	LsmsRejected.log.<MMDD>		Yes
LNP Database Synchronization Logs (Audit, Bulk Load, Re-sync)	Refer to the LNP Database Synchronization User's Guide		Yes
Measurement Logs	<CLLI>.meas.<MMDD>		Yes
Surveillance Logs	survlog.log.<MMDD>		No
Sentry Logs	sentryd.log.<MMDD>		No

LSMS Log File Names and Locations

This figure shows the directory structure under /var/TKLC/lsms/logs where LSMS application log files are located.

Figure 6-3 LSMS Application Log File Locations

Removing Accumulated Logs

To remove accumulated activity, trace, and application logs:

Note:

Logs are automatically removed after seven days.

1. Log in as root on the active server.
2. Change to the logs directory by typing the following command:
   cd /var/TKLC/lsms/logs
3. Determine the existing log files by typing the following command:
   ls -R
   Each subdirectory under the /var/TKLC/lsms/logs directory is represented in the following output by the name of the directory followed by a colon (for example, Northeast:). For each directory that contains log files, the complete listing of all log files is shown below the name of the directory. The naming convention of the log files is:

   
   LsmsType.log.<MMDD>
   
   

   where Type is the kind of log (such as Activity, Trace, Application), MM is month; and DD is day. The following example output lists all the subdirectories for an LSMS that supports eight regions and shows two log files:

   
   ./MidAtlantic:
   ./Midwest:
   ./Northeast:
   LsmsActivity.log.0918 LsmsTrace.log.0918
   ./Southeast:
   ./Southwest:
   ./WestCoast:
   ./Western:
   ./Canada:
   ems:
   supported:
   

4. To delete the logs, do the following steps:
   1. Change to the subdirectory for the desired region by typing the following command:
      cd <subdirectory>
      where <subdirectory> is the subdirectory of the region, such as Western.
   2. Determine which days you want deleted and type the following command:
      rm *.log.<MMDD>
      where MM is the month and DD is the day of the log files you want to delete. For example, if you wanted to delete all logs in the Western region for September 18, you would type the following commands:

      cd Western

      rm *.log.0918

Measurement Logs

Measurement logs are viewed in the HTML viewer. The following sections describe how to navigate, print (from Linux and Windows computers), and exit measurement logs.

Navigating Measurement Log Windows

If there is more information in a log than can be viewed in the window, use the vertical and horizontal scroll bars to scroll in either direction.

Printing Measurement Logs from Linux and Windows Computers

To print an LSMS-generated measurement log from a Linux computer, see Printing Measurement Logs from a Linux Computer.

To print an LSMS-generated log from a Windows computer, see Printing Measurement Logs from a Windows Computer.

Note:

• Measurement logs are automatically scaled to fit the width of the page.
• The orientation of all measurement logs is portrait and cannot be modified.

Printing Measurement Logs from a Linux Computer

To print an LSMS-generated measurement log from a Linux computer:

1. From a window displaying the log (after selecting Open), select File, and then Print.

   Figure 6-4 Printing Measurement Logs Using the File Pull-down Menu

   
   
   

   The Print window appears.

   Figure 6-5 Linux Print Window Example

   
   
   
2. In the Print Command Options field, enter the Linux print command to print the log.
   Example: lpr -P printer1
3. Click the Print button.

Printing Measurement Logs from a Windows Computer

To print an LSMS-generated measurement log from a Windows computer:

Note:

When printing from a Windows computer, a list of available printers is automatically generated and displayed.

1. From a window displaying the measurement log (after selecting Open), File, and then Print.

   Figure 6-6 Printing Measurement Logs Using the File Pull-down Menu

   
   
   

   The Print window displays.
2. Select the printer you want to use and print the measurement log.

Exiting Measurement Log Windows

1. To exit the Measurement Log output window, select File, and then Exit

   Figure 6-7 Exiting Measurement Logs Using the File Pull-down Menu

   
   
   

Security Logs

Security logs contain login, logout, locally provisioned commands, and all GUI activity information, which you can save, view, and print. These logs are stored in text format and are created on a daily basis. LSMS allows you to access the current day’s log and the logs created over the preceding seven days.

Viewing Security Logs

To view an LSMS security log:

1. From the LSMS Console window, select Logs, and then Security.

   Figure 6-8 Logs Pull-down Menu

   
   
   

   The security log Open window appears.

   Figure 6-9 Security Log Open Window

   
   
   
2. Select the log you want to view and click Open.
   The security log appears.

   Figure 6-10 Example Security Log

   
   
   
3. When you are done viewing the log, close the file.

NPAC Transactions Logs

The transactions logs provide information associated with M-Create, M-Delete, and M-Set CMIP operations initiated from the NPAC. The maximum size of the log file is 60 MB.

Table 6-2 explains each field used in the NPAC transactions log for SVs, and also provides the possible values for each variable. Table 6-3 explains each field used in the NPAC transactions log for NPBs, and also provides the possible values for each variable. Following each table are examples of the M-Create, M-Delete, and M-Set transactions log formats.

Table 6-2 NPAC Transactions Log Format Symbols (for SVs)

Field	Content	Description
1	NPAC Region	2 characters: CA = Canada NE = Northeast SW = Southwest SE = Southeast MW = Midwest WC = West Coast WE = Western MA = Mid Atlantic
2	Received timestamp Format: YYYYMMDDhhmmss	14 characters: YYYY = Year (1997 - 9999) MM = Month (01 - 12) DD = Day (01 - 31) hh = Hour (00 - 23) mm = Minute (00 - 59) ss = Second (00 - 59) Example: 19990315182028
3	Label	subVersn
4	CMIP operation	1 character: C = M-Create D = M-Delete S = M-Set
5	NPAC version ID	10 characters: Example: 2000000001
6	Subscription version TN	10 characters: Example: 9195551234
7	Subscription version LRN	10 characters: Example: 2222223333
8	Service Provider ID	4 characters: Example: TKLC
9	Billing ID	4 characters: Example: Bill
10	Activation timestamp Format: YYYYMMDDhhmmss	14 characters: YYYY = Year (1997 - 9999) MM = Month (01 - 12) DD = Day (01 - 31) hh = Hour (00 - 23) mm = Minute (00 - 59) ss = Second (00 - 59) Example: 19990315182028
11	Subscription LRN Type	1 character: 0 = lspp (interservice provider port) 1 = lisp (intraservice provider port) 2 = POOL (Pooled numbers) Example: 0
12	Subscription download reason	1 character: 0 = New 1 = Delete 2 = Modify 3= Audit discrepancy Example: 2
13	SVType	1 character: 0= Wireline 1= Wireless 2= VoIP 3= VoWiFi 4= SVType4 5= SVType5 6= SVType6 Example: 1
14	AlternativeSPID	4 characters: [0-9, A-Z], or NULL Example: 1234
Note: SVType and AlternativeSPID fields are not present in delete transactions.

Following are examples of M-Create, M-Delete, and M-Set transactions log formats for SVs:

M-Create Transactions Format

         MW|19980123172028|subVersn|C|2000000001|9195555555|2222223333|TKLC|BILL|19970202020202|0|0

M-Delete Transactions Format

MW|19980123172031|subVersn|D|2000000001|9195555555|

M-Set Transactions Format

MW|19980123172028|subVersn|S|2000000001|9195555555|2222223333|    |TILL|              |0|2
MW|19980123172029|subVersn|S|2000000001|          |4444444444|TKLC|JILL|19970202020202| |2

Figure 6-11 shows a portion of an example Transactions Log for SVs.

Figure 6-11 Example NPAC Transactions Log (SVs)

Table 6-3 NPAC Transactions Log Format Symbols (for NPBs)

Field	Content	Description
1	NPAC Region	2 characters: CA = Canada NE = Northeast SW = Southwest SE = Southeast MW = Midwest WC = West Coast WE = Western MA = Mid Atlantic
2	Received timestamp Format: YYYYMMDDhhmmss	14 characters: YYYY = Year (1997 - 9999) MM = Month (01 - 12) DD = Day (01 - 31) hh = Hour (00 - 23) mm = Minute (00 - 59) ss = Second (00 - 59) Example: 19990315182028
3	Label	nmPoolBlk
4	CMIP operation	1 character: C = M-Create D = M-Delete S = M-Set
5	NPAC version ID	10 characters: Example: 2000000001
6	Subscription version TN	10 characters: Example: 9195551***
7	Subscription version LRN	10 characters: Example: 2222223333
8	Block Holder	4 characters: Example: TKLC
9	Activation timestamp Format: YYYYMMDDhhmmss	14 characters: YYYY = Year (1997 - 9999) MM = Month (01 - 12) DD = Day (01 - 31) hh = Hour (00 - 23) mm = Minute (00 - 59) ss = Second (00 - 59) Example: 19990315182028
10	Placeholder	1 character: T Note: This field is present for historical purposes and the value is always T.
11	Subscription download reason	1 character: 0 = New 1 = Delete 2 = Modify 3= Audit discrepancy Example: 2
12	SVType	1 character: 0 = Wireline 1 = Wireless 2 = VoIP 3 = VoWiFi 4 = SVType4 5 = SVType5 6 = SVType6 Example: 1
13	AlternativeSPID	4 characters: [0-9, A-Z], or NULL Example: 1234
Note: SVType and AlternativeSPID fields are not present in delete transactions.

Following are examples of M-Create, M-Delete, and M-Set transactions log formats for NPBs:

M-Create Transactions Format

         MW|19980123172028|nmPoolBlk|C|2000000001|9195551***|2222223333|TKLC|19970202020202|T|0

M-Delete Transactions Format

MW|19980123172031|nmPoolBlk|D|2000000001|9195551***|

M-Set Transactions Format

MW|19980123172028|nmPoolBlk|S|2000000001|9195551***|2222223333|    | |T|2

Figure 6-12 shows a portion of an example Transactions Log for NPBs.

Figure 6-12 Example NPAC Transactions Log (NPBs)

Local Data Transactions Logs

Local data transactions logs provide information about locally provisioned data. Figure 6-13 shows an example of a local data transactions log.

Figure 6-13 Example Local Data Transactions Log

Audit Logs

Audit log files are generated for Range Audits. One log file is created for each day that a Range audit is performed. The log file is named LsmsAudit.log.<MMDD>, where <MMDD> is the timestamp that contains month and day. This log file is located in the directory /var/TKLC/lsms/logs/<CLLI>, where <CLLI> is the Common Language Location Identifier of the network element being audited. Log files are maintained for seven days after they are created; then they are automatically removed from the LSMS.

Note:

No log file is generated for a Single SV/NPB Audit.

Viewing Audit Log Files

You can view audit log files in either of the following ways

• From the GUI, any time after a Range audit has begun, you can view the audit log file by clicking the View Log button. If the browser window used for displaying reports and logs is not already open, it is opened automatically and displays the log file.

• You can also use one of the following methods to open the window used to browse for audit logs:

  Figure 6-14 Browsing for Audit Log Files

  
  
  

  • Select Logs, and then Other... from the main menu of the LSMS Console window.

  • Click on the LSMS Console window’s EMS Status Icon that corresponds to the network element being audited so that the icon is highlighted. Right-click and select Logs, and then LNP Database Synchronization, and then Audit.

    Scroll down to find the folder that has the <CLLI> name for the NE that is being audited. Double-click the folder name, and then double click the file name LsmsAudit.log.<MMDD> that corresponds to the month and day you desire.

Audit Log File Contents

Whenever a Range audit is started, the audit log file for that day is appended (if this is the first audit of the day, the file is created). For each audit performed on that day, the audit log file contains information similar to the information displayed on the Audit Range, Audit Results, and Download Results tabs, such as start and end times for each stage, and numbers of missing, extra, and different objects in various LNP categories. The log and window also record whether database entries are present at the LSMS but missing at the NE, present at the NE but missing at the LSMS, or present at both the LSMS and NE but containing different values.

The audit log file contains the following sections:

• Header Section
• Audit Section
• Reconcile Section
• Summary Section

  Note:

  Starting with LSMS Release 8.X, summary sections for Object Range Audits indicate whether object types were completely audited, partially audited, or not audited, and shows results for both completely and partially audited object types.

Audit Log File Example for a Completed Audit

Figure 6-15 shows an example of an audit log file that contains two separate audits and reconciles performed on the same day.

Figure 6-15 Example of an Audit Log File for a Completed Audit

Thu Nov 1 13:36:16 EST 2001

Username: lsmsuser
NE CLLI:  LARCH

Thu Nov 1 13:36:15 EST 2001
Connection established with network element (192.168.61.202:1030)

Audit of Override GTTs started on Thu Nov 1 13:36:20 EST 2001

2000000000 MISSING

Audit of Override GTTs completed on Thu Nov 1 13:36:20 EST 2001

   0000000000 LRN Start
   9999999999 LRN End
            5 Total audited on LSMS
            4 Total audited on NE
            4 Same on Both
            0 Different on NE
            1 Missing on NE
            0 Extra on NE
            1 Total Discrepancies

Reconcile started on Thu Nov 1 13:37:40 EST 2001

Reconcile completed on Thu Nov 1 13:37:44 EST 2001

           NPA Splits   0 Downloaded     0 errors
   Number Pool Blocks   0 Downloaded     0 errors
Subscription Versions   0 Downloaded     0 errors
         Default GTTs   0 Downloaded     0 errors
        Override GTTs   1 Downloaded     0 errors
                Total   1 Downloaded     0 errors

Audit Log File Example for a Partially Completed Audit

Figure 6-16 shows an example of an audit log file for an Object Range Audit that was interrupted.

Figure 6-16 Example of Audit Log File for Partially Completed Audit

Mon Jun 6 14:40:20 EDT 2005

Username: lsmsall
NE CLLI:  PALM

Mon Jun 6 14:40:20 EDT 2005
Connection established with network element (192.168.61.100:1030).

Audit of NPA Splits started on Mon Jun 6 14:40:20 EDT 2005

Audit of NPA Splits completed on Mon Jun 6 14:40:27 EDT 2005

         200 Old NPA Start
         999 Old NPA End
           5 Total audited on LSMS
           5 Total audited on NE
           5 Same on Both
           0 Different on NE
           0 Missing on NE
           0 Extra on NE
           0 Total Discrepancies

Audit of Subscription Versions started on Mon Jun 6 14:40:27 EDT 2005

9195551212 EXTRA
9195551213 EXTRA
9195551214 MISSING

Audit of Subscription Versions interrupted on Mon Jun 6 14:40:27 EDT 2005

Partial Subscription Version Summary
 919550 NPA-NXX Start
 919559 NPA-NXX End
 919554 NPA-NXX Last Completed Successfully
   4999 Total audited on LSMS
   5000 Total audited on NE
   4997 Same on Both
      0 Different on NE
      1 Missing on NE
      2 Extra on NE
      3 Total Discrepancies

Objects Completely Audited: NPA Split
Objects Partially Audited:  Subscription Version
Objects Not Audited:        Default GTT, Override GTT
Partial Reconcile File:     /var/TKLC/lsms/free/ebda/<CLLI>.reconcile
                            File.0606144036.tar.gz

Continuing an Interrupted Object Range Audit

Starting with LSMS Release 8.X, if an Object Range Audit is interrupted, you can interpret the contents of the audit log file to determine how many objects were completely audited. After the interruption has been resolved, you can complete your original audit goal by performing the following actions in any order (the file shown in Figure 6-16 is used as an example):

• Perform a Post-Audit Reconcile (refer to the LNP Database Synchronization User's Guide), selecting the Partial Reconcile File listed in the Audit log (<CLLI>.reconcileFile. 0606144036.tar.gz in the example file). This Post-Audit Reconcile will reconcile the three discrepancies found in the Subscription Version range from 919550 to 919554 (there were no discrepancies found in the NPA Splits).

• Perform another Range audit and reconcile of just SVs in the range 910555 to 910559.

Audit Log File Example for Data Discrepancies

An audit can detect three types of data discrepancies (different, missing, and extra) that may exist on a network element. Each discrepancy that is detected is counted and recorded in the audit log file. Duplicate LNP data is not considered to be a discrepancy. Figure 6-17 shows an example of an audit section of an log file that contains data discrepancies.

Figure 6-17 Audit Log File Example for Data Discrepancies

Audit of Subscription Versions interrupted on Mon Jun 6 14:40:36 EDT 2005

Partial Subscription Version Summary

        919550 NPA-NXX Start
        919559 NPA-NXX End
        919554 NPA-NXX Last Completedly Successfully
          4999 Total audited on LSMS
          5000 Total audited on NE
          4997 Same on Both
             0 Different on NE
             1 Missing on NE
             2 Extra on NE
             3 Total Discrepancies

Objects Completely Audited: NPA Split
Objects Partially Audited:  Subscription Version
Objects Not Audited:        Default GTT, Override GTT
Partial Reconcile File:     /var/TKLC/lsms/free/ebda/<CLLI>.reconcile
                            File.0606144036.tar.gz

NPA Split Logs

The LSMS records all changes to LSMS NPA split objects in split log files. Log information for all eight regions is included in one log file.

Figure 6-18 Example LSMS Split Log

As with other log files, the split log files use the current date in the filename so they are automatically deleted after seven days. The split log file name has the following format, where MM is the creation month and DD is the creation day:

LsmsSplit.log.MMDD

The daily limit for this log file is 75 megabytes. (Each TN uses 5 bytes in the Split log file entry. If 500 NXX—half of the 1000 maximum— in the old NPA change to the new NPA and each NXX contains the maximum 9999 SVs, that is 25 megabytes in the log file on the Start Date of that NPA Split. Because up to three NPA splits have occurred on the same day, the maximum size limit for a Split log file is set at 75 megabytes.)

The following figures show examples of create, activation, and delete entries, respectively, in a split log file.

Figure 6-19 Sample Create Entry in a NPA Split Log File

Figure 6-20 Sample Activation Entry in a NPA Split Log File

Figure 6-21 Sample Delete Entry in a NPA Split Log File

Formats Common to All Entries

The following formats apply to all split log entries:

• Time fields for all time stamps are in the 19-character YYYY-MM-DD HH:MM:SS format, representing year, month, day, hour, minute, and second, respectively.

• Time fields for PDP start and end times are in the 14-character YYYYMMDDHHMMSS format, representing year, month, day, hour, minute, and second, respectively. The values for hour, minute, and second are always zero.

• Each entry specifies OK or FAIL to indicate whether the action was completed successfully.

Create Entry

A create entry, with the following format, is recorded in the log file each time an NPA Split is created using the GUI or an input file.

CREATE|<OK or FAIL>|<creation time>|<optional failure reason text>
<old NPA>|<new NPA>|<NXX>|<start PDP time>|<end PDP time>

Activation Entry

An activation entry, with the following format, is recorded in the log file each time an NPA Split is activated.

START ACTIVATE|<activation time>
<old NPA>|<new NPA>|<NXX>|<start PDP time>|<end PDP time>
NPB:
<X>***|<X>***|…|<X>***
SV:
<XXXX>|<XXXX>|…|<XXXX>
…
<XXXX>|<XXXX>|…|<XXXX>
END ACTIVATE|<OK or FAIL>|<activation time>|<optional failure reason text>
<old NPA>|<new NPA>|<NXX>|<start PDP time>|<end PDP time>

The list of NPBs modified contains up to ten numeric entries. Each entry contains the last digit in the NPA-NXX-X string that identifies an NPB followed by three asterisks (***).

Because each line in the list of SVs modified contains up to ten 4-digit numeric entries for the last four digits of a ten-digit TN identifying an SV, there may be up to one thousand lines in each list of SVs modified for a given NPA-NXX split.

Delete Entry

A delete entry, with the following format, is recorded in the log file each time an NPA Split is manually deleted using the GUI.

DELETE|<OK or FAIL>|<deletion time>|<optional failure reason text>

For more information about Split logs and LSMS NPA Splits, see Managing Locally Provisioned Data.

Activity Logs

The LSMS activity log contains all CMIP operations initiated from the NPAC agent to a local database or to the NPAC. It contains the decoded CMIP operations including M_GET, M_SET, M_DELETE, M_ACTION and EVENTREPORT. The maximum size of the log file is 2 MB. See Figure 6-22 for an example of a partial activity log.

Figure 6-22 Example (Partial) Activity Log

Alarm Logs

Alarm logs contain the following elements:

• Prefix line – Single line with title and timestamp for each alarm.

• Event Report Argument – Variable-length decoded CMIP.

• Origin – Single line that ends with a 1 to indicate that the message came from the NPAC agent.

• Severity – Single line that ends with one of the following numbers:

  • 1 – Indicates that the problem is Critical

  • 2 – Indicates that the problem is Major

  • 5 – Indicates that the problem is Cleared

• Message – Text message printed on GUI as notification.

Figure 6-23 Example Alarm Log

CMIP Logs

The CMIP log collects for later analysis all CMIP protocol data units (PDUs) received from the NPAC. If a problem arises during an NPAC transaction, support personnel can print the relevant CMIP log and attach it to the problem report. The maximum size of the log file is 2 MB. See Figure 6-24 for an example of a CMIP Log.

Figure 6-24 Example CMIP Log

Event Logs

The event log provides GUI notification information about events not related to problems. The maximum size of the log file is 2 MB and is kept for seven days.

The event log holds the following types of records, each of which contains varying numbers of information fields (see Table 6-4 for descriptions of each field).

• New NPA-NXX Event, which contains 10 information fields

• First Use of NPA-NXX Event, which contains eight information fields

Note: Optional fields for which no information is generated appear in the event log as two consecutive pipes (||).

Figure 6-25 Example Event Log

New NPA-NXX Event Log Record

Following is the format of the event message logged when a new serviceProvNPA-NXX object is created:

<Timestamp> | <EventTime> | <EventId> | <EventType> | <SPID> | <NPANXX-ID>
| <NPANXX> | <EffectiveTimestamp> | <DownloadReason> |
<CreationTimestamp>

See fields 1 through 10 in Table 6-4 for descriptions of each field included in the New NPA-NXX Event Log Record.

Following is an example of a New NPA-NXX Event Log Record when a new serviceProvNPA-NXX object is created:

Example:

1998-08-18 12:00:00| 19980818120000 | 300 | New NPA-NXX| 0001 | 25 |
919361 | 19980801120000.0Z | 0 | 19980701120000.0Z

In this example, 19980801120000.0 in field 8 and 19980701120000.0 in field 10 represent the time stamp values (YYYYMMDDhhmmss.0Z format, where the.0 that immediately precedes the Z indicates tenths of a second) and Z indicates Zulu time.

Note:

Time Stamp values are entered in local time. LSMS automatically converts local time to Z (Zulu), which is also called GMT (Greenwich Mean Time). For more information, see Appendix A, "Local Time Calculation and World Time Zone Data.".

First Use of NPA-NXX Event Log Record

Following is the format of the event message logged when a subscriptionVersionNewNPA-NXX notification is received:

<Timestamp> | <EventTime> | <EventId> | <EventType> | <SPID> | <NPANXX-ID>
| <NPANXX> | <EffectiveTimestamp>

See fields 1 through 8 in lsms-logs-and-measurements1.html for descriptions of each field included in the First Use of NPA-NXX Event Log Record.

Following is an example of an NPA-NXX event log record when a subscriptionVersionNewNPA-NXX notification is received:

Example:

1998-08-18 12:00:00| 19980818115500 | 301 | First use of NPA-NXX | 0001 |
25 | 919361 | 19980801120001.0Z

In this example, 19980801120001.0 in field 8 represents the time stamp value (YYYYMMDDhhmmss.0Z format, where the.0 that immediately precedes the Z indicates tenths of a second) and Z indicates Zulu time.

Note:

Time Stamp values are entered in local time. LSMS automatically converts local time to Z (Zulu), which is also called GMT (Greenwich Mean Time). For more information, see unresolvable-reference.html#GUID-E0AD51E6-2AF9-4997-91EE-910A63016EE9.

NPAC Event Log Fields and Field Descriptions

lsms-logs-and-measurements1.html provides a summary of the NPAC event log fields and field descriptions.

Fields 1 through 10 are included in the New NPA-NXX Event Log Record, and fields 1 through 8 are included in the First Use of NPA-NXX Event Log Record.

Table 6-4 NPAC Event Log Fields and Field Descriptions

Field	Field Name	Field Description
1	<Timestamp>	The date and time that the notification appeared on the GUI. It is in the same format as the GUI notification: YYYY-MM-DD hh:mm:ss YYYY -Year (1997–9999) MM - Month of the year (01–12) DD - Day of the month (01–31) hh - Hour (00–23) mm - Minute (00–59) ss - Second (00–59) Example: 1998-08-18 12:00:00
2	<EventTime> Format: YYYYMMDDhhmmss	The time that the event actually occurred (it is also an optional field in a CMIP event). If present, it is in the Abstract Syntax Notation (ASN.1) Generalized time format. Example: 19980818120000
3	<EventId>	The event messages are assigned a unique integer identifier. One of the following identifiers appears in the <EventId> field, depending upon the type of record: 300 (New NPA-NXX) 301 (First Use of NPA-NXX)
4	<EventType>	One of the following entries appears in the <EventType> field, depending upon the type of record: New NPA-NXX is the descriptive text associated with an <EventId> of 300. First Use of NPA-NXX is the descriptive text associated with an <EventId> of 301.
5	<SPID>	Alphanumeric 4-character Service Provider ID.
6	<NPANXX-ID>	Integer identifier that provides a unique key for the object.
7	<NPANXX>	The NPA-NXX value of the portable NPA-NXX.
8	<EffectiveTimestamp> Format: YYYYMMDDhhmmss.0Z (The.0 that immediately precedes the Z indicates tenths of a second. The Z indicates Zulu time.)	Timestamp that specifies when the NPA-NXX is available for LNP in the service provider networks. Example: 19980801120000.0Z (The.0 that immediately precedes the Z indicates tenths of a second. The Z indicates Zulu time.)
9	<DownloadReason>	Integer that specifies the reason that the NPA-NXX was downloaded to the LSMS. The valid reasons are: 0 - New 1 - Delete 2 - Modified 3 - Audit discrepancy
10	<CreationTimestamp> Format: YYYYMMDDhhmmss.0Z (The.0 that immediately precedes the Z indicates tenths of a second. The Z indicates Zulu time.)	Timestamp that specifies when the NPA-NXX object was created at the NPAC by the service provider that owns the NPA-NXX. Example: 19980801120000.0Z (The.0 that immediately precedes the Z indicates tenths of a second. The Z indicates Zulu time.)

Trace Logs

The trace log is used by Oracle applications developers. Each entry, as shown in Figure 6-26, contains a timestamp and debug information.

Figure 6-26 Example Trace Log

eagleagent Logs

The LSMS maintains a set of logs for the LSMS’s interface to the network elements. These logs are viewable from all running GUI sessions, and have a maximum file size of 200 MB each. The following eagleagent logs are described in this section:

• “eagleagent Transactions Log”

• “Rejected Transactions Log”

• “Measurement Logs”

In addition to these logs, LNP Database Synchronization logs are also eagleagent logs. A log file is created to record the results of each audit, bulk load, and user-initiated resynchronization. These logs files are described in the LNP Database Synchronization User's Guide.

eagleagent Transactions Log

The Transactions log records all request/response transactions between the LSMS and the network element. The eagleagent Transactions log shows every message sent to the EAGLE and (optionally) responses from the EAGLE. The log includes EBDA reconcile messages and resynchronization messages. The log format identifies which filter was used and whether the message came from EBDA, local data, or which Region.

Example Transactions Log Entry

Figure 6-27 shows an example of an entry in the eagleagent Transactions log.

Figure 6-27 Example eagleagent Transactions Log

Transactions Log Fields

Table 6-5 shows describes the fields in entries in the eagleagent Transactions log.

Table 6-5 eagleagent Transactions Log Fields, Field Descriptions, and Sample/Restriction Data

Field Number	Field	Description	Sample/Restriction Data
1	Timestamp	Local timestamp of event	27 characters Tue Oct 30 17:48:35 EST 2001
2	Space #1	Space character	1 space
3	Parenthesis #1	Open Parenthesis	1 character (
4	Filter Type	Identifies type of filtering used by LSMS	13 characters G indicates GTT Group Filter T indicatesTN Filter Example: FilterType=G,
5	Space #2	Space character	1 space
6	Filter Data	Based on Filter Type in Field #4, contains information specific to filter	Variable number of characters See 6a or 6b
6a	TN Filter Data	Identifies Region Name and NPA-NXX for this transaction, when FilterType=T for #4	For Region, possible values are Canada, MidAtlantic, Midwest, Northeast, Southeast, Southwest, Western, WestCoast NpaNxx is 6 digits Example: Region=Southeast, NpaNxx=706595,
6b	GTT Group Name	GTT Group Name when FilterType=G in #4.	Example: GttGroupName=Group1,
7	Space #3	Space character	1 space
8	CMIP Operation Type	Identifies CMIP operation	7 characters C indicates Create S indicates Set (modify) D indicates Delete N indicates Not Set Example: CMIP=N,
9	Space #4	Space character	1 space
10	Source	Integer identifying source of update within the LSMS	6 characters Integer (1-9) Example: SRC=4,
11	Space #5		1 space
12	Start of LSMS Command	Identifies the start of the LSMS Command information	5 characters Cmd=(
13	Function ID	Identified HSOP Function ID	Variable number of characters Format is funcId=<id>=<name>, Possible values for <id>=<name> are: 39=HSOP_UPD_SUB_TS 40=HSOP_UPD_GTT_OVERRIDE_TS 41=HSOP_UPD_GTT_DEFAULT_TS 42=HSOP_UPD_NPA_SPLIT_TS 43=HSOP_DLT_SUB_TS 44=HSOP_DEL_GTT_OVERRIDE_TS 45=HSOP_DEL_GTT_DEFAULT_TS 46=HSOP_DLT_NPA_SPLIT_TS 47=HSOP_RTRV_SUB 53=HSOP_MAX_FUNC_ID (Invalid)
14	Space #6		1 space
15	Command Length	Denotes length of command excluding header	5-7 characters Format is len=xxx where xxx can be 1 to 3 digits. Example: len=49,
16	Space #7		1 space
17	Timestamp	Timestamp at which command is sent by LSMS to EAGLE	26 characters. Format is timestamp=yyyymmddHHMMSS\0, Example: timestamp=20050131120000\0,
18	Record data	One or more pipe-delimited record forwarded to EAGLE from LSMS	Variable length character string Each record type (SV, NPB, Override GTT, Default GTT, NPA Split) has its own format. See Table 6-6 and Table 6-7 for formats of Pipe Delimited Records.
19	End of record data		\n
20	End of LSMS Cmd	Ending parenthesis	1 character )
21	End of RMTP Cmd	Ending parenthesis	1 character )

Transactions Log Record Data Formats

As described in field 18 in Table 6-5, the format of the pipe-delimited record data in a Transactions log entry differs according to the record type and the type of command. Table 6-6 shows the format for each record type and command type and Table 6-7 describes each of the fields used in these formats.

Table 6-6 Format of Pipe-Delimited Record Data in Transactions Log Entry

Record Type	Format for Update Command	Format for Delete Command
SV	TN|LRN|SPID|PoolType|Class DPC|Class SSN|LIDB DPC|LIDB SSN|ISVM DPC|ISVM SSN|CNAM DPC|CNAM SSN|WSMSC DPC|WSMSC SSN\0	TN \0
NPB	NPANXXX***|LRN|SPID|3|Class DPC|Class SSN|LIDB DPC|LIDB SSN|ISVM DPC|ISVM SSN|CNAM DPC|CNAM SSN|WSMSC DPC|WSMSC SSN\0	NPANXXX***\0
Override GTT	LRN|SPID| Service 1|Service 2|Service 3|Service 4|Service 5\0	LRN\0
Default GTT	NPA-NXX|AIN|IN|Service 1|Service 2|Service 3|Service 4|Service 5\0	NPA-NXX\0
NPA Split	New NPA-NXX|Old NPA-NXX\0	Old NPA-NXX\0
Table 6-7 describes each of the fields shown in this table.

Table 6-7 Definitions of Fields for Pipe Delimited Records

Name	Description	Restrictions/Comments
TN	Telephone Number	10 digits
LRN	Location Routing Number	10 digits
SPID	Service Provider ID	4 alphanumeric characters
PoolType	Pool Type	1 digit: 1 indicates Local Service Provider Portability (LSPP) 2 indicates Local Intra-Service Provider Portability (LISP) 3 indicates Pooled Block Number (POOL)
Class DPC LIDB DPC ISVM DPC CNAM DPC WSMSC DPC	Destination Point Code	Absent or 9 digits consisting of 3 octets each between 0 and 255
Class SSN LIDB SSN ISVM SSN CNAM SSN WSMSC SSN	Subsystem Number	Absent or Up to 3 digits (0-255)
Service 1 Service 2 Service 3 Service 4 Service 5	Default GTT and Override GTT commands can contain from one to five services (Class, LIDB, ISVM, CNAM, or WSMSC) depending on which of those services have been defined for the Default GTT or Override GTT. Each Service field consists of additional pipe-delimited fields: Default GTT entry, 5 fields: TT|DPC|SSN|RI|NGT OverrideGTT entry, 6 fields: TT|DPC|SSN|RI|NGT|RGA	TT is 0 to 255 or absent DPC is 0 to 255 or absent SSN is 0 to 255 or absent RI is G, D, or absent NGT is 0 to 255 or absent RGTA is L, T, or absent
NPA-NXX New NPA-NXX Old NPA-NXX	Number Porting Area - Exchange	6 digits
AIN	Advanced Intelligent Network indicator	2 or 3 characters Either LA or NLA
IN	Intelligent Network indicator	2 or 3 characters Either LI or NLI

Rejected Transactions Log

Rejected transactions logs record exception conditions for LSMS transactions. You can use these logs to help identify when, where, and why LSMS data is not correctly provisioned. The rejected transactions log records rejected revision commands that the LSMS sends to network elements.

The LSMS checks to make sure that accurate data is successfully forwarded to a network element. When the LSMS receives a subscription version of any kind (create, delete, or modify) from the NPAC or when an LSMS user creates or modifies a Default or Override GTT entry, the LSMS sends appropriate commands to the network elements.

If, after the configured number of retries, the command used to forward the new information is rejected by a network element, an entry is logged in the rejected transactions log file.

Rejected Transactions Log Location

One log file is created for each day (if there are rejected transactions on that day), up to a maximum of seven daily log files. After a log file is seven days old, LSMS automatically deletes it.

The rejected transactions log files are located in

/var/TKLC/lsms/logs/<clli>/LsmsRejected.log.<MMDD>

where <MMDD> represents the month and day the file was created. For example, a log file created April 7th would have the file name:

LsmsRejected.log.0407

Rejected Transactions Log Description

Each record in the log file is a single line of data. The maximum number of entries in each daily log file is 30,000; the maximum size of each daily log file is 2,340,000 bytes. Figure 6-28 shows an example of one entry in a Rejected Transactions Log.

Figure 6-28 Example eagleagent Rejected Transactions Log Entry

The Rejected Transactions log shows every message rejected by the EAGLE. Since a message must be sent to be rejected, that means every message in the Rejected Transactions log is also in the Transactions log. However, the entry in the Rejected Transactions log has error text attached to explain why it failed.

The format of the Rejected Transactions Log is the same as for the Transactions Log for a Transmission for fields 1 through 18, as described in Table 6-5, Table 6-6 , and Table 6-7. Table 6-8 shows the format of fields 19 through 22 in the Rejected Transactions Log.

Table 6-8 Rejected Transactions Log

Field Number	Field	Description	Sample/Restriction Data
19	End of record data		3 characters \n,
20	Space #8		1 space
21	Error Text	Description of error leading to Rejection.	Variable length text Example: errorTxt=Command Error! \0
22	End of LSMS Cmd	Ending parenthesis	1 character )
22	End of RMTP Cmd	Ending parenthesis	1 character )

Measurement Logs

Measurement logs are not created by default. You can view measurements from the GUI as shown in Figure 6-29.

Figure 6-29 EMS Status Icon Popup Menu

In addition, you can use the measdump command to view measurement logs. This command is located in the following directory:

$ LSMS _DIR/../tools/

(For backward compatibility, you can use the measdump command to create the measurement files.) For more information about this command, refer to the Alarms and Maintenance Guide.

The measurement log file provides the following information:

• Region – The name of the NPAC region.

• Last Updated – When this information was last updated in the following format:

  • ddd – Day of the week (Sun, Mon, Tue, Wed, Thu, Fri, Sat)

  • MMM – Month (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec)

  • DD – Day of the month (01–31)

  • hh – Hour (00–23)

  • mm – Minute (00–59)

  • ss – Second (00–59)

  • YYYY – Year (1997–9999)

• Binds – Cumulative number of NPAC-LSMS association binds during the hour.

• SuccessOps – Cumulative number of M-Create, M-Delete, and M-Set commands that went into the LSMS database and also successfully passed to the supported manager.

• FailedOps – Cumulative number of M-Create, M-Delete, and M-Set commands that failed to go into the LSMS database.

The following operations are not measured or contained in this file:

• M-Get operations

• Unsuccessful bind operations

• Unbind operations

• Event responses

• Operations that are rejected because of a duplicate entry or invalid attribute

An example of a measurements log is shown in Figure 6-30.

Figure 6-30 Example Measurements Log File

LSMS Evaluation Log Files

Several LSMS log files keep track of system functionality. These log files cannot be accessed directly from the GUI, but can be found by using the browse feature to look into the appropriate directory. These include the following types of log files:

• Surveillance

• Sentry

Surveillance Log Files

The LSMS surveillance application monitors various hardware parameters. This feature creates two log files that are stored in the /var/TKLC/lsms/logs directory.

The survlog.log file contains debug information from the surveillance application. It can be used by the surveillance application to monitor itself for improper functioning. Each line in this log file begins with a timestamp. A text message following the timestamp indicates the state of the surveillance application. For example:

12/31/1997 08:45 => Unable to open second serial port configuration file

12/31/1997 08:45 => Second serial port not to be used

12/31/1997 08:45 => Console window successfully opened!

The survlog.log file is a persistent log of all console notifications. The format of this log file is same as the format of console notifications. For example:

LSMS0009|11:55 Feb 04, 1998|lnp13|Keep Alive

LSMS0500|11:56 Feb 04, 1998|lnp13|Notify:Sys Admin

LSMS0501|11:57 Feb 04, 1998|lnp13|Notify:Sys Admin - SAM1

LSMS0502|11:57 Feb 04, 1998|lnp13|Notify:Sys Admin - SAM1

Sentry Log Files

The LSMS sentry application monitors other software processes and attempts to restart them automatically in certain failure conditions (refer to the Alarms and Maintenance Guide for more information about the Sentry application). This feature creates one log file, sentryd.log file,which is stored in the /var/TKLC/lsms/logs/sentry directory.

The sentryd.log file contains general information from the LSMS sentry application. It can be used for tracking what the LSMS sentry process is doing regarding the state of the LSMS applications it is monitoring. Each line in this log file begins with a timestamp. A text message following the timestamp indicates the state of the LSMS sentry application. For example:

12/31/1997 08:45 => fatal: environment variable LSMS-DIR not set

09/10/1998 08:45 => sentryd starting

09/10/1998 08:45 => restarting rmtpagent

09/10/1998 08:45 => sentryd stopped

Bulk Data Downloads for Notifications (Optional)

When the optional NANC 3.3 Feature Set is activated, support of Bulk Data Downloads (BDD) for notifications is enabled. The bulk download file is supplied by the NPAC like other bulk download files, and notifications are processed by the LSMS.

A notifications file is generated for a particular SPID and time range. All attempted notifications for the SPID in the time range are included in the file, and they are sorted in order by ascending notification attempt timestamp. The notification BDD filename is in the following format:

Notifications.<start download>.<start time range>.<end time range>

Note:

Each timestamp has the format <DD-MM-YYYYHHMMSS>

For example, this file:

Notifications.18-09-2006081122.15-09-2006080000.16-09-2006133022

was created starting at 08:11:22 on September 18, 2006 and covered the time ranged from 08:00:00 on September 15, 2006 through 13:30:22 on September 16, 2006.

Although there are more than 20 possible notification IDs, the LSMS only receives notification types 1 and 8. Notification ID 1 is “Operational Information” from NPAC, and Notification ID 8 is the “Subscription Version New NPA-NXX” notification.

The field values for Notification ID 1 are described in Table 6-9.

Table 6-9 Notification ID 1 Field Values

Field Number	Field	Range of Values
1	Creation Timestamp	YYYYMMDDHHMMSS
2	LSMS Customer SPID	[0-9 A-Z] four alphanumeric characters
3	System Type	0=SOA, 1=LSMS
4	Notification ID	1
5	Object ID	[0-9]
6	Maintenance Start Time	YYYYMMDDHHMMSS
7	Maintenance End Time	YYYYMMDDHHMMSS
8	NPAC Contact Number	Telephone number
9	Additional Download Time Information	Graphic string of up to 255 characters (not used by LSMS)

The field values for Notification ID 8 are described in Table 6-10.

Table 6-10 Notification ID 8 Field Values

Field Number	Field	Range of Values
1	Creation Timestamp	YYYYMMDDHHMMSS
2	LSMS Customer SPID	[0-9 A-Z] four alphanumeric characters
3	System Type	0=SOA, 1=LSMS
4	Notification ID	8
5	Object ID	21, when generated by SV 12, when generated by NPB
6	NPA-NXX ID	[0-9]
7	NPA-NXX	[0-9] six digits
8	NPA-NXX Effective Timestamp	YYMMDDHHMMSS
9	Subscription Version New NPA-NXX SPID	[0-9 A-Z] four alphanumeric characters