The "IBM Monitoring Academy Seminars" are a series of LIVE video blogs presented by Mark Leftwich and Shaun Rodger.
The series is designed to be slightly less formal and give you the latest monitoring information directly from the hands on experience of our subject matter experts.
We work on the products daily, work on site with customers and are always up to speed with the latest information on the products. We are now passing this information on directly to you in a nice easy to digest format.
We encourage you to provide feedback on the type of content you wish to see, what you want more of, etc. This video series is for all of you out there, so we'd really appreciate if if you can help us shape it to what you want and need. Just drop a comment in the box below and we will try our best to include any requests for content.
This inaugural episode focuses on both ITM and TCR and includes a live demo, some how-to's and generalized discussion on current important information in the world of monitoring!
Each episode in the series will aim to contain the latest information on:
- Product information updates
- New releases information,
- News flash updates you need to be aware of
- Issues Support are seeing a rise in number of and their solutions
- Known Gotchas
- Requests received from customers sites and how you can create the same solutions yourself
- Personal hands on experience on working with the products with tips and tricks we use.
We really hope you find this useful. Thanks for reading and watching today.
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 22.214.171.124 (bundled with TPC 126.96.36.199) on a SLES 11 SP3 64bit system.
The installation of TCR fails always with an error "Return Code 255" in the deployment log:
everything looks well, also the Prerequisite Scanner shows neither errors nor FAIL.
In the in the end i found the following in the tcr.cognos.err:
/db2log/JazzSM_Install/TCRInstaller/COI/PackageSteps/TCRCore/FILES/c8/image/linuxi38664h/issetup: error while loading shared libraries:
libpng14.so.14: cannot open shared object file: No such file or directory
This means, the package libpng14-14-1.4.4-23.1.x86_64 doesn't exist on the host.
The client installed the libpng14-14-1.4.4-23.1.x86_64 package on SUSE 11 64-bit machine.
Now the installation of TCR 188.8.131.52 was successful.
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:
Just a little something to keep in mind when upgrading your installed report bundles. We've had an issue in the past where a customer had imported product report package, then later imported a new version. However, the upgraded reports were still using the old data model.
Even after re-importing the reports, and even after deleting the package from within Cognos Administration, the import wizard still claimed that the package already existed (with its short name) and asked if they wanted to replace the package or rename the newly imported package.
What we think happened in this instance is that they did not choose to replace it in the first place, and so the new reports ended up linked to the old data model. Just a little something for you to keep in mind when you're upgrading your report packages, always make sure to choose replace or you can end up getting yourself in a bit of a tangle.
We've recently had some PMRs come in to support asking when we're planning to upgrade the version of Cognos that we bundle with TCR 3.1, specifically when/if we're planning to upgrade to either version 10.2.1 or 10.2.2.
I'm afraid that the current plan is NOT to include either of these versions with the next release of Jazz/TCR (v1.1.2) that will be available for customer download as of the end of April. This version of Jazz will include TCR 3.1.2 which comes bundled with Cognos 10.2.0.4.
An upgrade to Cognos 10.2.2 is in the pipeline for the future but I currently do not have a definitive timescale for its release. Watch this space!
Thanks for reading.
UPDATE: We now have a tentative release date of September 2015 for a version of TCR including Cognos 10.2.2. I will keep an eye on this and update the blog accordingly.
Basically, we will no longer be issuing any code fixes for this version of TCR. There's a couple of reasons for this.
1. No current product release by IBM is still bundling this version of TCR.
2. Cognos 8.4.0, a core component of TCR, has already gone out of support some time ago.
Something to keep in mind as a consequence of this is that it's not just code fixes going forward we're talking about. We will also NOT be issuing a fix for the infamous "POODLE" vulnerability (CVE-2014-3566) among other current vulnerabilities. Our advice would be that if you are still using TCR 1.3, you look into upgrading your bundled software to a version that at least ships version 2.1 to ensure that you're on a still-maintained code level as soon as you can.
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.
When you log a PMR for a TCR issue with IBM support, whether it be for problems running a report, problems launching the reporting portlet or any other related questions, there's a number of questions that we'll ask you to help us troubleshoot the issue. If you can provide that information to us right from the start, it'll save everyone a lot of time.
This blog will list some of the most common questions IBM Support will ask, and will provide you with links so that you have the documentation/instructions you need to collect it for us.
The Questions and why we ask them.
1. Is this a brand new install of TCR or an upgrade? Why - Because this will help us narrow down the logs to check, initially. It will also help guide the investigation as there are issues that might occur during an upgrade that we would not need to look for during a fresh installation.
2. What version of TCR are you running? You can get this information for us by running the "listiu" command. See below for the formats.
Unix - /usr/ibm/common/acsi/bin/listIU.sh -v
Windows - %ProgramFiles%\IBM\Common\acsi\bin\listIU.cmd -v Why - There are multiple versions of TCR in circulation, with different versions of TIP and Cognos bundled with them so knowing exactly which version you're running will help guide our investigation.
3. What database are you using for your content store? If you're using Derby please be aware that this is only meant to be used for testing purposes and is not supported in a production environment. Please see the following technote from IBM - http://www-01.ibm.com/support/docview.wss?uid=swg21609287 Why - Again, there are multiple options for the database here, and knowing which version it is will help us eliminate obvious issues like using a non-supported database, and will enable us to provide you with quick checks you can carry out to make sure everything is working okay.
4. Has this been working before and now stopped, or did it never work at all? Why - An important one here. It will help us narrow down the times we need to be checking in the logs. If it's recently stopped working, for instance, we know we need to look at the most recent logs to try and find out what might have changed.
5. Are you getting an error? Please supply a screenshot or a complete error message. Why - Without an accurate error message, even the messages in the logs may not be of any use as the error logged in the background is often different from the one that the end user has displayed.
6. What web browser are you using to access TCR? If possible, can you test with another browser before you contact support? Why - Only certain browsers are officially supported with TCR, and some versions can cause issues so knowing exactly which one you're using will again help speed the investigation.
7. If this is a report issue, which reports are giving you problems? Is it only the reports for one specific product or all reports in general? Please be specific as this will impact how the PMR is handled. Why - If it is a problem with one specific set of reports, then your PMR will be passed to the team that created the report bundle for initial investigation. The more information you can give us and the more specific you can be, the quicker the team will be able to focus their investigation efforts.
8. Where did your reports come from? Were they supplied by IBM with the product, or were they created/modified by yourself? Why - At this point any customised report, be it user created or user modified, is not officially supported by IBM. We'll take a look at it for you and do our best to offer assistance but it's on a best effort basis only and we can't promise a resolution.
9. Regarding logs, the best way to get us all the logs and config files we might need is to use the "tcrpdcollect" script. You can find it here -
When the script completes, it'll give you a file called tcr-collect-%COMPUTERNAME%.jar. Please take a moment to doublecheck the contents of this file to make sure that the Cognos and TCR log directories have been properly collected. If this fails, then please collect the contents of the following directories and send them to us instead -
If you log a PMR with IBM support without supplying this information, then the chances are that the first email you receive in reply will ask for most if not all of this so that the engineer can begin their investigation. The more of this you can provide right at the start, the quicker we can begin working the issue and getting your installation working properly.
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.
4.Select Public Folder + IBM tivoli monitoring OS Agents Reports + Prerequisites validation + OS agents Report Prequisites scanner report
5.Select between the two reports type:
Show all sections: success and un-success
Show failing sections: show sections with failing.
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:
Linux IP address
Unix IP address
KSY summarization config
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.
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:
Share Dimension tables:
TIME_DIMENSION, MONTH_LOOKUP and WEEKDAY.
Resource dimension tables:
MANAGEDSYSTEM, MANAGEDSYSTEMLIST and
3.Restart the S&P agent.
1. Configuring the S&P agent to maintain the dimension tables:
KSY_SQL_OUTPUT_FILE_PATH = (optional file path for sql output)
3.Ensure the TEPS is started
4.run: tdwschema -rspfile tdwschema.rsp
IMPORTANT: you have to be a database administrator
5.Run the following scripts in order with an user having admin access to the DW database. If you are using Oracle or MSSQL server you must run the scripts as the TRAM user “IBM_TRAM”.
db2 connect to WAREHOUS (with db2admin)
db2 -tvf tdw_schema_table.sql
As we can see the share dimension tables were created:
db2 -tvf tdw_schema_index.sql
db2 -tvf tdw_schema_view.sql
db2 -td# -f tdw_schema_function.sql
db2 -tvf tdw_schema_insert.sql
Now the table has been filled in:
Note: for Oracle or MSSQL server to check , page 498 for ITM6.3 administration guide.
3.Starting the S&P agent
1.we are going to find how the TIME_DIMENSION table has been populated:
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.
1. TCR is deployed on Websphere Application Server and It uses the Websphere Application Server JRE.
2. By Default, The TimeZone is picked up from the Machine’s default TimeZone.
3. For some reason, if the Websphere Application Server didn’t pick up the machine's default TimeZone, you can manually set the default TimeZone.
4. Please stop the TCR Server.
5. Please take a backup of this file <tcr_install>/tipv2/profiles/TIPProfile/config/cells/TIPCell/nodes/TIPNode/servers/server1/server.xml (TCR 2.x)
6. After taking backup, Please find the below entries in the server.xml file
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Feb 4, 2014 12:44:27 PM com.ibm.tivoli.reporting.advanced.cognos.cli.TRCommand main(String)
Please check the latest log file (log file name starts with some random number, eg 1393579360824.log) for more information from this location <JazzSM_HOME>\reporting\lib\birt-runtime-2_2_2\ReportEngine\configuration\
If you find the following exception,
Caused by: java.lang.StackOverflowError
This could be a reason of the locale of the machine not picked by Birt Engine
Date/time stored in Tivoli Data Warehouse by IBM Tivoli Monitoring agent is in Candletime format and not in Timestamp format.
Candletime Format = CYYMMddhhmmssSSS
C – Century, YY – Year, MM – Month, dd – Day, hh – Hour, mm – Minute, ss – Second, SSS - Milliseconds
CYY - (to be added to 1900 as candle time assumes 1900 as the base)
Century with year = CYY = 113
Year = 1900+113 = 2013
For Cognos, the time stamp should be in the following format:
WRITETIME is the column in the Warehouse which contains the date/time in Candletime format. And in the Cognos model or report, WRITETIME is referred in a data item. Lets say, it is [Consolidation View].[CPU Usage - NT].[WRITETIME]. So, now lets add a new query/data item in that query subject and add the following
To alleviate some consumability issues with TCR 3.1 and to act as a stopgap until the new deployment design has been implemented in the next major Jazz for Service Management release, TCR deployment enhancements have been introduced in Fix Pack 1. Here are some pointers to help you with a clean installation of Tivoli Common Reporting 184.108.40.206 on a single server.
What's different from TCR 3.1 installation?
New Jazz for Service Management launchpad custom workflow that allows you to install Tivoli Common Reporting and its supporting components on a single server by using the default values that you specified.
New Installation Manager software package that installs the Reporting Services environment, that is, the Cognos Content Store and the application server profile into which Tivoli Common Reporting is installed.
Tivoli Common Reporting no longer has a dependency on Dashboard Application Services Hub as a host for its Common Reporting user interface. You can install Dashboard Application Services Hub after the Tivoli Common Reporting installation, and then integrate it with Tivoli Common Reporting.
What do I need?
Installation media – either you've obtained the JazzSM DVDs with the Cloud & Smarter Infrastructure (Tivoli) product you purchased, or you can download electronic images from IBM Passport Advantage website. You'll need installation media for:
IBM DB2 Enterprise Server Edition 10.1 (or use your own installation of DB2 9.7 Fix Pack 5 or 10.1)
IBM WebSphere 220.127.116.11 (or use your own installation of WebSphere Application Server 18.104.22.168 or 22.214.171.124)
Jazz for Service Management 126.96.36.199 (has the launchpad, Installation Manager, and Reporting Services environment package that creates the Cognos Content Store and application server profile)
Tivoli Common Reporting 188.8.131.52 (also contains IBM Cognos Mobile that provides mobile support in Tivoli Common Reporting)
Framework Manager 10.2 (should you want to model business data views of data)
Where do I start?
If you have a browser available in your target environment, then start here:
Tivoli Common Reporting Quick Start Guide (PDF/HTML) – Summarizes how to install Tivoli Common Reporting and supporting middleware components by using the launchpad custom flow. It is available in the JazzSM Info Center and on JazzSM QSG DVD and eImage.
What if you don't have a browser but there's a graphical environment, then use GUI mode in Installation Manager and the Tivoli Common Reporting installation program:
Use Installation Manager to install WebSphere Application Server, Jazz for Service Management extension for IBM WebSphere, and the Reporting Services environment. Select the relevant software packages in the Installation Manager > Install Packages panel and then complete the remaining Installation Manager panels. See Application and database server: Installing multiple integration services.
Use Installation Manager to silently install WebSphere Application Server, Jazz for Service Management extension for IBM WebSphere, and the Reporting Services environment with the Cognos Content Store and the application server profile. Learn more from Silently setting up the environment for Tivoli Common Reporting.