Welcome to the new CogKnowHow.com!


If you have trouble logging in, reset your password via the login window
by clicking the 'Forgot Password' link.

PlanningErrorLog.csv Explained


#1

General Error Logging

Most components of the application log their errors to a file named PlanningErrorLog.csv. In Windows NT4, this is stored in the Temp directory. In Windows 2000 and later, it can be found in:

Documents and Settings\user name\Local Settings\Temp\

These logs can be created on the client, the Administration Console machine, administration server, web server, or the job server. Most components and applications log to this file including IBM Cognos 8 Planning - Analyst. So multiple logfiles with the same name planningerrorlog.csv on different computers.

How Errors are Logged in the Administration Console

Errors that occur in the Administration Console are logged to help bug tracking.

Due to the distributed nature of the execution of Contributor, it is also necessary to distribute the error handling/logging. For example, it does not make sense to log all the errors on the users’ web client for errors that happen on the web server.

The logs created by components are put on the machine on which they execute.

The log file created is in tab separated format, but it has a .csv extension so that it automatically loads into Excel when it is double clicked (if Excel is installed). Excel 97 gives you a warning that the format is not recognized, but actually opens the file without any problems. Opening the file in Notepad makes it difficult to read as the columns do not align due the varying length of the log entries. If the log cannot be written, for example, the file is locked by another process, or is read-only, then the log entry is written to the NT event log (if it exists) and the application fails with a message saying that logs cannot be written. If no log is written for a long time, the application can continue to execute even if the logging would cause problems in the future - this is normal "on demand" resource usage as recommended by Microsoft.

During execution you may get an error that passes through multiple components as it works its way up the call stack. In this case there will be entries in the log for each procedure that is affected with a line number. For errors to be traced correctly, we need the log for each machine and user context affected by the error. This can be difficult if you do not know where all the code is executing, so it is advisable to send technical support all the logs you can find. We can usually tell if there is a log entry missing from the identity information that is associated with each error.

An error log contains the following fields:

Field Name Description

GUID

Each distinct error has a unique GUID (a unique identifier) by which it is identified. By looking at entries in the log with matching GUIDs it is possible to group log entries by particular errors. It is possible to cross reference errors between different log files if the error stack spans server side and client side components.

Stack

This is used in conjunction with the GUID to determine the source of the error, and the call stack that the error was passed through before being reported. A value of 1 indicates the source of the error, and the highest value is the point at which it was reported to the user. Again these sequences can span log files.

Date Time

The date and time at which the error occurred. The time is taken from the machine where the component represented in the current log entry is running.

Component

The name of the component represented in the current log entry.

Module

The code module in which the error occurred.

File

The source file name.

Version Information

The version of the component represented in the current log entry.

Procedure

The procedure within the file where the error occurred.

Line Number

The line number within the procedure where the error occurred. This enables a developer to trace exactly which call caused the error, and in conjunction with the error number and error message, it gives a high degree of detail about the problem.

Source

The origin of the error. May or may not be within IBM Cognos components.

Error Number

The identifier for the error condition.

Error Description

A description of the error which has occurred.

User Domain/User Name

The User Domain/User Name under which the component represented in the current log entry was executing.

Machine Domain/Machine Name

The Machine Domain/Machine Name on which the component represented in the current log entry was executing.

Previous User Domain/ Previous User Name

The domain on which the user was logged into and the previous user name.

Previous Machine Domain\ Previous Machine Name

The machine from which the call was made to the current component. This is the indicator to go and look for error logs on this machine, where it may be possible to find corresponding entries (matched on GUID), lower down the call stack. It may also provide clues to other errors that occurred prior to the issue being investigated.

Process ID

The current process ID.

Thread ID

The current thread ID.