TCR installs an embedded lightweight database (Derby) to house reporting artifacts. The derby database is not supported in production and it is recommended to use an relational database such as
DB2. So, it is strongly recommends to migrate from derby database to a relation DB.

1. Create the database with endoding=UTF-8 and protocol TCP/IP

We can use this script template to create the content store. Replace the database_name with the name of the database, for example TCRDB and userID with the user that tcr will use to connect to the content
store, for example cognos. The database user account must exist for the product function and you must run the script as a user with sufficient privileges to access and create database:

1.2 create a script with the above template named: create_database.bat/sh

1.3 from “command window/DB2” we run the script with Administrator or db2admin or from “command line processor” (DB2) run the above sentences.

2. Set up database connectivity for the content store database :

2.1 if you are using type 2 jdbc connectivity , install the DB2 client on the Content manager if you are using type4 jdbc connectivity for DB2, you are not required to install the DB2 client in the content manager.

Although TCR 2.1.1 is already an old product , we can still find customers with this version installed and using Derby like their Content store. In these cases the best practice should be install the newest TCR

version 3.1.x but I also know that sometimes it is not possible and we have to install a parallel env. and we need to mount another environment 2.1.1 like our production env. before upgrading to TCR 3.1 .

In this blog I'm going to show you a step by step about how to install TCR 2.1.1 in a single machine and how configure the Content Store from Derby to DB2 database. To avoid to have a very very long

blog I will split it in two: Installing TCR and Configuring Content Store for DB2

NOTE: it is a blog following the one "Installing TCR 3.1 with non-root user" (https://ibm.biz/Bd4j94) . The Reporting services is installed in this way because to install TCR 3.1 with non-root the Content store has to be created manually and the Report Services configuration fail because it is already created.

In this case we are going to run the Reporting services installation using the “installation manager

1. cd /home/tcr/IBM/InstallationManager/eclipse

#./IBMIM

And click on “install”:

2. We select to be installed the “reporting Services environment”:

NOTE: If you want you can select “IBM Dashboard Application Service Hub” to be installed /configured as well since it will be needed to integrate TCR with Dashboard GUI. In our
case , we will do it later to show you another installation option.

The Prerequisites Scanner report provided by the OS agents report package, allows us to check our system's prereq. It verify that shared dimensions tables, time dimensions tables and resource dimensions tables are available and the prereq are right.

We are going to get something similar to this , indicating what things have to be resolve.

Once the . Preq problems have been resolved you can work with the report as usual: clicking on “public folder” + report package and selecting some report and the report scanned should show us something similar to:

In order to create the dimension tables, we must first configure the historical data collection for the following attributes depending on the OS we are setting reports:

Type

Attribute group

Table

Summarize

Linux

Linux IP address

Linux_IP_Address

Daily

UNIX

Unix IP address

UNIX_IP_Address

Daily

Windows

Computer Information

NT_computer_information

Daily

S&P agent

KSY summarization config

KSY_Summarization_Config_DV

Daily

IBM i

Miscellaneous

IOS_Miscellaneous

Daily

For example, for windows we should have:

From ITM 6.3 , there are two ways to create and maintain the dimension tables:

Using the summarization and pruning agent

Manually (as previous versions )

In this section we are going to use the S&P agent to do it but if you want to continue to manually update the dimension tables as it had to be done in versions older than ITM v6.3 you can still do it.

Best Practice:

1.Configure the S&P agent to maintain the dimension tables without starting it after configuration.
2.Create the dimension table using the “schema Publication tools” in update mode . Doing that we create both groups of tables:

1.we are going to find how the TIME_DIMENSION table has been populated:

IMPORTANT:

The MANAGEDSYSTEM table is populated using information from the WAREHOUSETCRCONTROL table. This table, WAREHOUSETCRCONTROL, is created on the first successful scheduled execution of the S&P agent.

It is the responsibility of each agent to put entries in the WAREHOUSETCRCONTROL table. In this case, the installer for the OS report package will promts us to provide JDBC connection details and credentials for the TDW database. This RegisterPackage script will insert data into WAREHOUSETCRCONTROL table. After this step, the MANAGEDSYSTEM and TIME_DIMENSION tables are kept up to date automatically by the S&P agent.

2.“The Resource dimension” and WAREHOUSETCRCONTROL tables have been created after the first successful scheduled execution of the S&P agent.

In cases where a Cognos report is to be used as a dashboard, an auto refresh capability in the report is required to load the data automatically at specific intervals without human intervention.
Following are the high level instructions on how to achieve it. A link to the detailed document is provided below.

- For all the queries in the report, set the property Use Local Cache to No.
- Add a HTML item at the top of the report and add the following meta tag in it.<meta http-equiv="refresh" content="5">
This will refresh the report every 5 seconds. Content attribute is in seconds. You cn set it as per your requirement
- If you have loaded the Cognos report into a Tivoli Integrated Portal dashboard, then set the session timeout value to not expire for the application server on which Tivoli Common Reporting is running.

NOTE: it is a blog following the one "Installing TCR 3.1 with non-root user" (https://ibm.biz/Bd4j94) . Here, we are going to install the TCR 3.1 with non-root user , tcr, as we will see it is a part very easy but we have to take into account that it is not the only step to get a TCR 3.1.x working correctly. It is needed to install a WAS, JAzzSM, ContentStore, etc as it was showed in our previous blogs. That's why I suggest you to start reading the first blog: "Installing TCR 3.1 with non-root user" and keep reading one by one the following ones.

1. Untar the tcr image package:

ITCR_3.1.0.1_FOR_LINUX.tar in /home/tcr/software_ibm/tcr/

2. Run the ./Launchpad.sh located in the jazzSM package image (JAZZ_FOR_SM_1.1.0.1_FOR_LNX.zip) in our case: /home/tcr/software_ibm/jazz

3. Now , we click on “tools”:

4. We select “IBM Tivoli Common Reporting Installation program”

5. Click on “install Program”

6. Set “/home/tcr/software_ibm/tcr/TCRInstaller/install.sh” for the “... installation image:” and click on “Run”

7. OK + Next +Next

8. We set the path were JazzSM was installed:

9. Next + Next + Next

10. Set the user used to logon in JazzSM websphere profile in our case: tipadmin

11. We set the data to connect to our Content Store created previously:

12. click Install . If the installation finishes correctly then we got the message:

Now we are going to install the JazzSM and webphere with our non-root user “tcr”.

1. The first step is unzip the packages:

JAZZ_FOR_SM_1.1.0.1_FOR_LNX.zip in /home/tcr/software_ibm/jazz and
WAS_V8.5.0.1_FOR_JAZZSM_LINUX_ML.zip in /home/tcr/software_ibm/was/

by using the “tcr” user.

2. Now we run ./launchpab.sh script from /home/tcr/software_ibm/jazz

3. Select “custom” in the screen :

4. Click on Next and as it is our first installation we don’t select any existing JazzSM installation in this screen , click next:

5. Now, we set the location for our JazzSM and WebSphere package. The db2 location is empty since it was installed previously and the TCR is empty as well since it will be installed after installing the Reporting Services.

6. Next

7. We only select the WebSphere to be installed like it is showed in this screenshot:

8. Next + Next

9. How we are installing as non-root user, tcr, we change the default installation location from :
/opt/IBM/JazzSM
/opt/IBM/WebSphere/AppServer
To
/home/tcr/IBM/JazzSM
/home/tcr/IBM/WebSphere/AppServer

And click NEXT

10. We set the user “tipadmin” user although you can set another if you want.

The content store is the database used by reporting services and where is store our TCR configuration: Schedule, plan.... and it is needed for running our reports correctly.
Installing with root user this step can be avoided since it is installed and configured during Reporting Services installation but when we install JazzSM as non root user, the installation for Reporting Services may fails with the following error:

Error during "post-install configure" phase:
Failed in configuring Reporting Services Database.
/home/non_root_user_home/opt/IBM/JazzSM/install/fsconfig.xml:227:
The following error occurred while executing this line:
/home/non_root_user_home/opt/IBM/JazzSM/install/reporting_services/reporting_services_config.xml:17:
The following error occurred while executing this line:
/home/non_root_user_home/opt/IBM/JazzSM/install/reporting_services/reporting_services_config.xml:23:
The following error occurred while executing this line:

/home/non_root_user_home/opt/IBM/JazzSM/install/reporting_services/tcr_db_config.xml:54:
The following error occurred while executing this line:
/home/non_root_user_home/opt/IBM/JazzSM/install/reporting_services/tcr_db_config.xml:66:
The following error occurred while executing this line:
/home/non_root_user_home/opt/IBM/JazzSM/install/reporting_services/tcr_db_config.xml:123:
The following error occurred while executing this line:
/home/non_root_user_home/opt/IBM/JazzSM/install/reporting_services/tcr_db_config.xml:142:
Failed in configuring Reporting Services Database.

To resolve this issue we are going to have to create and configure the ContentStore manually.

NOTE: the user account “non-root” that we are going to use for the installation will be “tcr”.
Default path for root user = /opt/IBM/JazzSM/
Default path for non-root = /home/name_user_no_root/IBM/JazzSM . So, in our case /home/tcr/IBM/JazzSM

NOTE: All package image will be downloaded in /home/tcr/software_ibm/

FOLLOW THESE STEPS:

1. Go to REPORTING_HOME from user_home_directory and run the following command as non-root user:

./TCR_generate_content_store_db2_definition.sh <db_name> <user_name>

WHERE:

DB_name = The name of the database to create for the Cognos Content Store. The database name can have up to 8 characters

User_name= The user name to connect to the Content Store, that is, the database owner.

In our case , we run from /home/tcr/software_ibm/tcr/TCRInstaller/ContentStoreDatabase with “tcr” user the script:

#./TCR_generate_content_store_db2_definition.sh tcrdb db2inst1

This command generates the tcr_create_db2_cs.sql script in:

/home/tcr/software_ibm/tcr/TCRInstaller/ContentStoreDatabase

2. Now we run the tcr_create_db2_cs.sql script by using the following command as db2 instance user (db2inst1):

3. In the next screens we are going to set the path installation, create the “dasusr1” user, create a db2 instance and single partition instance.

4. Now we create the owner of the instance: db2inst1 default + Next

5. Now appears a summary and click on “finish” to start the installation

6. Once the installation has finished we can validate the installation running the command : ./db2val

7. The last step is license the DB2 running with “db2inst1” the command:

./db2licm –a Db2ese_o.lic
----------------------------------------------------------------------------------------
LIC1402I License added successfully.
LIC1426I This product is now licensed for use as outlined in your License Agreement.
USE OF THE PRODUCT CONSTITUTES ACCEPTANCE OF THE TERMS OF THE IBM LICENSE
AGREEMENT, LOCATED IN THE FOLLOWING DIRECTORY: "/opt/ibm/db2/V10.1/license/
en_US.iso88591
------------------------------------------------------------------------------------------

NOTE: we can run the command " db2licm –l" to check it was correctly registered.

Normally we install TCR with root user but sometimes we are required to install TCR 3.1 without using non-root user and although it is not really complex, the procedure
is a little different to use the root user account. In this blog we are going to cover or at least to try to show a TCR installation with all necessary components required
using a non-root user, named "tcr", on RH 6 64bit machine. These are the points to discuss :

So today I've a couple of quick little tips for you, hence the "bitesize" moniker for this subseries of blogs. Both of these relate to TCR.

1 - Can you run both TCR 2.1.1. and TCR 3.1 on the same machine, for example while carrying out a migration?

A - You can, but there's a couple of caveats to bear in mind. You need to either make sure that the TCR 2.1.1 install is completely stopped before you try to run the 3.1 installation or you need to change the TCR 2.1.1 cognos log port from 9043 to something else to ensure that there's no conflict with 3.1 and then you can run both together.

2 - Less a question and more a little tip for those people just getting started with TCR - Potential issue with Cognos Framework Manager and Windows User Account Control.

If you are installing on Windows, and are running with the Windows UAC turned on, then you can run into problems with Cognos. Specifically, you may find that Cognos Framework Manager is unable to connect to the database even if all the tests are successful and it appears that everything is running correctly. In this instance, if everything else appears to be correctly configured, your only option will be to disable UAC and then the issue should clear.

I hope you find these little hints/tips useful, I will be posting more of these as I come across them.

Subscribe and follow us for all the latest information directly on your social feeds:

Just a quick update here to let you know I've made a Youtube video about how to run tcrpdcollect. You're likely to be asked for the output of this script when you log a PMR with us for some assistance with TCR. 9 times out of 10, the script completes without any bother and we have everything we need to troubleshoot your issue, but that 1 out of 10 is where it appears to run properly, but doesn't collect everything we need for the issue. This video will show you how to run the script, and how to check for the important folders before you send it through to support.

It has occurred to me that perhaps some of you out there aren't entirely familiar with this product called Tivoli Common Reporting, or perhaps you're a little confused by all the different versions and you're wondering what each one offers you in terms of functionality. Or maybe you're having some problems with your reports and you're thinking about logging a PMR with IBM Support.

If any of the above applies, then this video is for you.

If you have any questions not answered in the video, or need further information, please leave me a comment and I'll do my best to help out.

Yes, following on from the infamous "POODLE" vulnerability we now have "FREAK" (there's even another one doing the rounds at the moment called "Bar Mitzvah" but that doesn't impact TCR) and this is one you do need to be aware of as it impacts the versions of Cognos that we bundle with every version of TCR from 1.3 to 3.1. If you click into the link and scroll down,. there's links to the Interim Fixes that resolve this issue. We would recommend getting these on your environment as soon as is convenient for you.

I was workinng with a client to install TCR 3.1.0.2 (bundled with TPC 5.2.5.0) on a SLES 11 SP3 64bit system.
The installation of TCR fails always with an error "Return Code 255" in the deployment log:

After having several errors importing the Tivoli Performance Analyzer report v6.3 I have decided to create a new blog covering the errors , solutions and the right way to import them.

First of all , we have to notice that TPA 6.3 report are birt report and not cognos report , therefore they can not be imported directly from dashboard using .zip file since although they may be imported correctly will never work.

NOTE: The environment where we have tested the steps installation was a Windows 2008 with TCR 31 on windows and 6.3 OS cognos report imported.

Steps for a right importation:

1. Install the OS agent cognos Report using "setup_windows.exe" it is going to import the OS agent report and create a TDW datasource. Once it is done, check the TEST datasource connection and you can run any OS agent report.

As they are cognos report you can import them using another way if want. More information about importing cognos report in:

Following on from my first "helping us to help you" post, here's another insight into IBM Support - What happens with your PMR once you log it. We know that sometimes it can be frustrating to be asked questions from multiple teams, or asked for logs multiple times, so I want to try and shed a little light on exactly why we do that.

So let's say you've logged your PMR and you've sent us all the information we've asked for to begin our investigation. Depending on what Geo you're logging from, the front line engineers will usually take a look at your PMR and do some basic troubleshooting, then route the PMR on to one of the second line (L2) teams. This is where I come in.

I'm a L2 engineer for ITM and TCR and when your PMR comes to me, I'll review all the information you sent me (You DID send it all, right? See my previous post Here for the list of what we need) and will begin to diagnose the issue. Seems simple enough so far, right? Well, as most of you long time customers of IBM will know, our products are made up of lots of different components. TCR, for example, is actually made up of a number of different parts. The main ones are -

TCR (Tivoli Commmon Reporting) - This is the bit that actually does the report processing.TIP (Tivoli Integrated Portal) - This is the web portlet that you use to access TCR, Webtop and a number of other products.BIRT (Stands for Business Intelligence and Reporting Tools, though most folks stick with Birt) - This is one of the reporting tools we bundle with earlier versions of TCR, it's actually an open source product rather than one developed by IBM.COGNOS (Stands for Cognos!) - Another reporting tool. This is the one we bundle with every version of TCR from 1.3 onwards.DEV/LEVEL 3 (L3) teams - TCR, TIP, Cognos and the other teams all have their own Level 3 or Dev teams who may need to get involved depending on the complexity of the issue or if a code fix is required.PRODUCT TEAMS - Each IBM-supplied report bundle comes from a specific product team. Be it ITM, ITCAM, ITNM, etc, and each of those teams is responsible for any maintenance and issues with their specific reports.

It may be necessary to reach out to other teams within IBM as well, depending on the exact issue under investigation. DB2 support, for example, may become involved if there's a potential issue with the content store. If it's an authorization issue, then we would contact the TIP team. For problems with the actual design of a report, we would go to Cognos.

So your PMR comes to me and I start to investigate it. I might decide that the errors in there need to be looked at by TCR L3, who then review it and decide that they need to engage the Cognos L3 for their input as well.

Or perhaps the PMR comes to me, I escalate to TCR L3 who confirm that it's a defect in the code but it's actually an underlying TIP issue. We would then need to engage not only the TIP L3 but their L2 team as well to ensure that everyone was kept "in the loop" on what was going on with the PMR and make sure that any updates are quickly communicated between teams and geographies.

As we progress from team to team, the focus of the investigation will narrow and shift depending on what we find in the logs. Each team has their own particular focus, and that may lead to multiple requests coming in for tracing to further narrow down the issue. What a TCR L2 engineer needs for their investigation, for instance, will likely not be the same as a Cognos L3 engineer would need to be able to get to the root cause of the issue. We do understand that multiple requests for logs/traces can get frustrating, but we never ask for these unless we're convinced that we need more information, or that a new trace level will help us get closer to the root cause.

I understand that at this point you're likely wondering why we don't just have a trace level or a script that collects everything that all these teams might need for their investigation to cut down on these multiple requests, but there's a number of reasons why we don't do this. The main reasons are -

1. That sort of verbose tracing of all those different components would make for hugely complicated logfiles that would be difficult for an engineer to work through. You would end up with a lot of extraneous "noise" from all the other components that would actually make it even more difficult to pinpoint a root cause.

2. The logfiles would be huge. This could easily cause space/resource issues for machines with limited capability, the logs would also likely be rolling over so often that their window of relevance would be extremely small.

Throughout the lifecycle of the PMR, as long as it's with L2 then you should only ever have one engineer as your point of contact so regardless of what goes on in the background, you only ever need to worry about emailing one person within IBM.

I hope this has helped you understand a little more about what goes on with your PMR once you contact support.

Install/upgrade usually happens on the same hardware, conflicts are bound to happen with the shared resources when a second instance of the same product is being installed. In order to eliminate such failures, this utility can be used. As product install/upgrade failures often lead to customer dissatisfaction, IBM Tivoli Common Reporting (TCR) team has taken this step towards developing this utility to solve this pain point and gain customer confidence in using our products.

The tool, when invoked, detects the potential resource conflicts and recommends relevant changes to be made so that the product install/upgrade becomes successful. Examples of some cases where this tool can be used are:

a) Upgrading TCR from v1.2 to v2.1.1 on the same server
b) Upgrading TCR from v2.1.1 to v3.1 on the same server

However, this utility can be extended to be used with any other product which follows a similar installation mechanism (response file based) with necessary changes.