If you're currently using Derby as a content store in your production TCR environment, then I'm afraid this is not a supported configuration.
IBM have issued a flash about this, the details of which can be found here - http://www-01.ibm.com/support/docview.wss?uid=swg21609287
Derby is recommended for demonstration/testing purposes only, it's just not designed to be used in a production or enterprise level environment. If you are using Derby at present, we would strongly advise you to change away from this to one of the supported databases as quickly as you can.
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.
Start the WebSphere administrative console; for example, select Start > IBM WebSphere > IBM® WebSphere® Application Server > Profiles > JazzSMProfile > Administrative console.
Enter the WebSphere administrator user ID and password, and click Log in.
Select Security > Global security.
Select Web and SIP Security > Single sign-on (SSO).
Select the Enabled check box to enable SSO.
Select the Requires SSL check box, if the HTTPS protocol must be used for all requests.
In the Domain name, enter UseDomainFromURL to set the domain name to the domain of the host that makes the request.
In the LTPA V2 cookie name field, enter the name of the cookie Please enter the cookie name as 'LtpaToken2' that transmit the LTPA tokens between servers.. The cookie name is case sensitive. If the cookie name 'LtpaToken2' is different, The Common Reporting would prompt for logon to enter valid credentials.( you can leave as blank also)
Select the Web inbound security attribute propagation check box to propagate information from the first login application server to the other application servers.
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
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.
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 "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.
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.
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.
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.
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.
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.
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.