Now I’m not here to tell you what software to buy and what to ignore, but if you haven’t had a look at IBM’s Transactional Analysis Workbench software yet, I think you should. It’s one of those pieces of software that kind of joins up the dots and allows you to see the bigger picture when you thought there was a performance problem. It can help identify performance issues in one subsystem – CICS, IMS, DB2, MQ, or even z/OS itself – when the symptoms of the problem are appearing in a completely different subsystem.
20 years ago, the world was a much simpler place. You’d be running IMS or CICS, and you’d be picking up data from your IMS database or DB2. But what was so simple, was the fact that the users of the data would be company employees. So, if there was a problem, you could use a fairly specific monitor to identify the location of the problem and fix it. Nowadays, you still run CICS and/or IMS as your transaction manager, but it can be linked to WebSphere MQ, and data can be coming from non-Z servers as well as IMS DB and DB2. But what makes life even more complicated is that the users are not just your staff, but also customers and potential customers, as well as automated systems that could be using your data in some mash-up appearing somewhere else entirely. Which means that it’s even more important to fix a slow-running system. And that means it’s vitally important to be able to quickly and easily identify where the problem actually is.
From a business perspective, there may be a single transaction that goes away, gets some data, and displays it. From a technical perspective, that single, say, CICS transaction may involve an IMS transaction running, and a DB2 intervention, and something involving MQ, before the results get back to the user’s screen. Now, if you think the problem lies with CICS, you can use CICS Performance Analyser to identify the problem. Or with IMS problems you can use IMS Performance Analyzer. Or for DB2 you can use DB2 Performance Manager, etc. But, what if the symptom appears to be IMS, but is really MQ? How can you combine this analysis to get to see the big picture of what’s happening on your system? This is where Transactional Analysis Workbench comes in.
You can check out the Web site to get all the specific details of why it’s a wonderful product, but I’d like to highlight just a couple of points. Transactional Analysis Workbench automated the collection of the data needed for problem analysis, and it provides a session manager to manage problem analysis through its life-cycle.
Rather cleverly, it allows slightly less-experienced or less highly-trained staff to identify the source of the problem. And then, when the ‘experts’ are available, it allows them to look in great detail to determine the problem. This is because the product links closely with other tools.
Transaction Analysis Workbench can provide a window into other subsystems that impact CICS and IMS performance. And by using information from SMF, OPERLOG, and other data sources such as CICS-DBCTL transaction performance, IMS address space resource consumption, WebSphere address space performance, MQ and DB2 external subsystem (ESAF) performance, APPC transaction performance, and IRLM long-lock activity, it can give an insight into what’s changed and where the problem might be originating.
Joined up software has got to be a good thing. And a product that can link closely with more specific monitoring or analysis tools has got to be a great help in finding out what’s different today compared to yesterday that’s causing a sudden drop in performance. But take a look yourselves.
20 years ago, the world was a much simpler place. You’d be running IMS or CICS, and you’d be picking up data from your IMS database or DB2. But what was so simple, was the fact that the users of the data would be company employees. So, if there was a problem, you could use a fairly specific monitor to identify the location of the problem and fix it. Nowadays, you still run CICS and/or IMS as your transaction manager, but it can be linked to WebSphere MQ, and data can be coming from non-Z servers as well as IMS DB and DB2. But what makes life even more complicated is that the users are not just your staff, but also customers and potential customers, as well as automated systems that could be using your data in some mash-up appearing somewhere else entirely. Which means that it’s even more important to fix a slow-running system. And that means it’s vitally important to be able to quickly and easily identify where the problem actually is.
From a business perspective, there may be a single transaction that goes away, gets some data, and displays it. From a technical perspective, that single, say, CICS transaction may involve an IMS transaction running, and a DB2 intervention, and something involving MQ, before the results get back to the user’s screen. Now, if you think the problem lies with CICS, you can use CICS Performance Analyser to identify the problem. Or with IMS problems you can use IMS Performance Analyzer. Or for DB2 you can use DB2 Performance Manager, etc. But, what if the symptom appears to be IMS, but is really MQ? How can you combine this analysis to get to see the big picture of what’s happening on your system? This is where Transactional Analysis Workbench comes in.
You can check out the Web site to get all the specific details of why it’s a wonderful product, but I’d like to highlight just a couple of points. Transactional Analysis Workbench automated the collection of the data needed for problem analysis, and it provides a session manager to manage problem analysis through its life-cycle.
Rather cleverly, it allows slightly less-experienced or less highly-trained staff to identify the source of the problem. And then, when the ‘experts’ are available, it allows them to look in great detail to determine the problem. This is because the product links closely with other tools.
Transaction Analysis Workbench can provide a window into other subsystems that impact CICS and IMS performance. And by using information from SMF, OPERLOG, and other data sources such as CICS-DBCTL transaction performance, IMS address space resource consumption, WebSphere address space performance, MQ and DB2 external subsystem (ESAF) performance, APPC transaction performance, and IRLM long-lock activity, it can give an insight into what’s changed and where the problem might be originating.
Joined up software has got to be a good thing. And a product that can link closely with more specific monitoring or analysis tools has got to be a great help in finding out what’s different today compared to yesterday that’s causing a sudden drop in performance. But take a look yourselves.
