Thursday, July 22, 2010

Other log files in the logs directory

Apart from the cogserver.log, there are many other log files in the logs directory. Logs for Cognos Configuration, the Tomcat log, the dispatcher log and so on. We will look at the dispatcher logs in a future post. The other logs are useful too but not very significant.

(Do note that some of the traces are also redirected to files in this folder. For example the CAM tracing which is done using IPF, will create an AAAClient.log in the logs directory. Again, we will look at traces in a later post.)

Usually, as mentioned in the previous post on the cogserver.log, it is better to send in the whole logs folder to support. It is advisable to rename the logs folder appropriately as it helps the analyst to map the logs to the Cognos architecture.

In the next post, we will look at the cogstartup.xml file.

Wednesday, July 14, 2010

cogserver.log

The cogserver.log can be found in the logs directory in the Cognos installation folder. One of the most common logs requested by support, it provides an entry point for the diagnosis. Though you can use the Log Console for dissecting the log, I am more comfortable viewing it using Wordpad or VIM. They are much more lightweight. Of course, they do not provide a quarter of the functionality provided by the Log Console (we will discuss Log Console in a later post).

Along with the cogserver.log, it is very important to pass the exact time that the error was seen. Also, if there are multiple installations and they are all logging to local files, it is important to pass all the cogserver.log files after renaming them properly. An architecture diagram or description can be attached for a better understanding of the problem.

Depending on the settings, you may find a cogserver.log.1 and a cogserver.log.2 and then a cogserver.log. Please send all of these files rather than just sending the cogserver.log. To avoid this confusion, analysts will usually ask you to send the zip of the logs folder. It would be a better idea to send the log folder after appropriately renaming it so that it is known which part of the architecture it came from.

For example:

dispatcher1.logs.zip
dispatcher2.logs.zip
cm.logs.zip


If you increase the logging level, the cogserver.log will grow faster than usual. Also if you start IPF tracing for any component, it is usually directed to the cogserver.log. CAF related errors are usually posted to the cogserver.log file. If you get a CAF error, it will give you a code which you can search for in the cogserver.log.

The best way to get familiarized with the cogserver.log is to open it and go through it. A typical entry in the cogserver.log looks like this:

172.21.140.175:9300 3672 2010-06-16 17:11:51.741 +5:30 BootstrapConfigurePublish na 0 Thread-16 DISP 6009 1 Audit.Other.dispatcher.DISP.com.cognos.pogo.contentmanager.coordinator.CMBootstrap StartService dispatcherBootstrap Info DPR-DPR-1002 Successfully registered the dispatcher http://01hw265803:9300/p2pd in Content Manager.

Dispatcher: 172.21.140.175:9300
Timestamp: 2010-06-16 17:11:51.741 +5:30
Component: Audit.Other.dispatcher.DISP.com.cognos.pogo.contentmanager.coordinator.CMBootstrap
Logging Level: Info

Now try dissecting this entry:

172.21.140.175:9300 3072 2010-06-21 11:50:15.806 +5:30 rsProcessStarter na 0 warpmta-ProcessManager-ProcessMgrThread DISP 6009 1 Audit.Other.dispatcher.DISP.com.cognos.pogo.reportservice.ReportServerProcess Start com.cognos.pogo.reportservice Info Start the BIBusTKServerMain with pid 4624.


The entries will look more or less the same. If you get any error code in Cognos Connection you can simply search for that error code around that timestamp when the error occured. Looking around that part you may find useful information which you can point out to support. I am sure they would not mind !

Friday, July 9, 2010

cmplst.txt

The cmplst.txt is the first thing most Cognos BI support analysts will ask you. In fact, even if they don't I suggest you pass them this file any way. The cmplst.txt is a component list in a text format. Cognos is made up of various components; the cmplst.txt states what all components are present in a certain installation and their versions. You will find the cmplst.txt in the Cognos installation folder. It is very easy to spot.

Some of you might not have access to the Cognos installation folder. In such scenarios, you can also see the cmplst.txt using the following URL format:

http://darshan.ibm.com/cognos8/cgi-bin/cognos.cgi?b_action=cmplst

This works nicely in a single server setup. For a distributed install, it is better to go for the text file.

The main information that can be derived from the cmplst.txt is the fixpack level you are on. This information is available in the first two sections of the cmplst.

For example:

[Product Information]

C8BISRVR_version=C8BISRVR-AX64-ML-RTM-8.4.27.78-0
C8BISRVR_name=Cognos 8 Business Intelligence Server

[Product Update Information]

C8BISRVR_UPDATE_version=C8BISRVR-AX64-ML-RTM-8.4.29.13-0
C8BISRVR_UPDATE_name=Cognos 8 Business Intelligence Server Update

What all can we derive from these two paragraphs ?

1. This is an AIX 64-bit install - C8BISRVR-AX64-...

2. It is version 8.4 - C8BISRVR-AX64-ML-RTM-8.4.27.78-0

3. Fixpack2 has been installed on top of the 8.4 base install

GA: C8BISRVR-AX64-ML-RTM-8.4.27.78-0
FP1: C8BISRVR-AX64-ML-RTM-8.4.28.xx-x
FP2: C8BISRVR-AX64-ML-RTM-8.4.29.13-0

4. Only the BI server has been installed. No gateway here.

This information is used by the support analyst when he/she is trying to recreate an issue in the labs. So knowing the exact fixpack level and component levels is crucial.

The later sections have much more information which is useful if a defect is found through a PMR and it goes to development. Development works on components, so if they want to fix some defect, they need to know the exact build level of the component.

The above facts make the cmplst.txt a very important part of any diagnosis of a Cognos BI issue. Next time you raise a PMR, make sure you pass it along. Also, if you have a distributed install, it makes sense to send the cmplst.txt for each Cognos installation. That should be bundled with an architecture diagram and each cmplst.txt should be renamed so that the analyst knows the origins of that cmplst in your architecture.

Wednesday, July 7, 2010

Data requested by Cognos BI support

Many customers who have raised PMRs with Cognos BI support know the usual data items that are asked by that team. But for a newbie it is important to understand the things that support is asking for, the reason they are asking for it and the correct way to provide it. In the next few posts we will be going through these items one by one.

The next post will be about the humble but very important: cmplst.txt

Monday, July 5, 2010

Problems connecting to Oracle data sources.

Many customers (mostly first time customers) face challenges connecting to their Oracle data sources from Cognos. A thing to note, is that these are configuration issues and very rarely product defects. This is basic functionality so it goes through a great deal of regression testing. There is very less chance for database connectivity to be a defect.

The most frustrating part with this connectivity issue is that it is pretty difficult to detect the configuration setting that is causing it. The problem can lie anywhere: user permissions, Oracle client installations, environment variables, Oracle settings, etc. The best way to deal with this is using the checklist approach; you checkout one factor at a time.

The best checklist can be found in this technote:
http://www-01.ibm.com/support/docview.wss?rs=3442&uid=swg21341734

In most cases, we have found this technote to resolve the connection problem. As and how we discover newer problems, we make it a point to update the technote. So you can be very sure that this technote covers most of the ground.

Sunday, July 4, 2010

Proven Practices landing page

This is one page you would want to bookmark:

http://www.ibm.com/developerworks/data/library/cognos/cognosprovenpractices.html

Created by Cognos experts from real-life customer experiences, Cognos Proven Practices is your source for rich technical information that is tried, tested, and proven to help you succeed with Cognos products in your specific technology environment.

Saturday, July 3, 2010

New Proven Practices article

Looks like we have a new Proven Practices article available:

This document describes an approach that can be used to dynamically sort on a Numerical Column.

http://www.ibm.com/developerworks/data/library/cognos/reporting/layout_and_formatting/page508.html

Welcome to Cognos Commentary !

This is my first technical blog. When prompted for a name for this blog, I was raking my brains for a good five minutes. I do have previous experience with articles but articles are very different from blogs. You write a nice ten page writeup about a technical topic, add some informative diagrams and you are done ! But a blog is like a relationship; you need to keep contributing :) So, I could not think of any better name and went with Cognos Commentary.

What will I be posting here ? I don't really know. But yes the theme is going to be the IBM Cognos BI platform. To make my life easier I shall be posting whatever I learn about the product - I learn something new everyday !