Helping us help you - The Life of a TCR PMR

Body

Hello folks,

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.

Thanks for reading.

Check out all our other posts and updates:

Academy Blogs:                    http://ibm.co/1wFBCSR
Academy Videos:                  http://bit.ly/1wFKveY
Academy Google+:               http://bit.ly/1sR5QTV
Academy Twitter Handle:     http://bit.ly/1CknfoF