IBM’s Transactional Analysis Workbench

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.

The importance of mainframe performance

It’s so easy to forget, or just take it as read, that mainframes have been able to successfully run with five nines availability for well over a decade. What that means is achieving 99.999% of scheduled uptime. In other words, it means that unscheduled downtime is less than five and half minutes in a year! Now that kind of amazing performance is something that boxes running other operating systems can only dream of. Some are working towards that level of availability, but others (you know who I’m thinking of here) aren’t even close.

But I wasn’t thinking about performance in that sense. We just take it for granted the operating system is going to be always working. What I was thinking about was the performance of the major subsystems running under z/OS. It’s very important to take steps to ensure that CICS or IMS are performing optimally. Monitoring software can be installed that will identify when preset thresholds are reached. They help identify bottlenecks and then the appropriate action can be taken to resolve them. This is the kind of stuff systems programmers have been working away at for years. They’ve been using faster processors, faster I/O, more efficiently-coded transactions, until every component is working as well as it can.

In previous blogs, we’ve talked about monitoring software that can arrange for alerts to be sent to designated staff as text messages or e-mails – allowing them to access the nearest iPad or laptop and take steps to resolve the new problem.

As well as CICS and IMS, there are monitors for DB2, WebSphere, and z/OS itself. These can all be integrated and produce wonderful moving graphs or other displays that allow users to tell at a glance whether everything is OK or whether a slight tweak to the subsystem is required. In addition, we’ve had software that learns how to maintain high performance and make appropriate changes on-the-fly, without any human intervention.

But the problem that many sites now face is what they can do if, for example, IMS users are reporting slow response times, but the problem appears to be coming from outside the IMS subsystem rather than from inside it. For example, what appears to be an IMS performance problem could be a CICS, DB2, WebSphere, or z/OS performance problem. The challenge facing systems programmers in this situation is to correlate performance data in IMS with activities in these other systems in order to discover the cause of the slow response time.

One new solution is Transaction Analysis Workbench, which is an IMS tool. If you’re interested in how to approach this type of situation, how to gather the necessary information from multiple subsystems, and then analyse, diagnose, and resolve the problem, you’ll be interested in the webinar from the Virtual IMS user group this week.

The Virtual IMS user group runs free webinars every other month. During the webinar, a technical expert shares their hard-won knowledge with the rest of the group. The webinars use Citrix GoToMeeting, which means you don’t have to face the hard task of convincing your company to fund your user group experience – you just sit down at your laptop and log in.

Anyone wishing to join the webinar needs to join the user group – which is also free. The next meeting is at 10:30 Central Standard Time on Tuesday 8 February. The user group’s Web site (where you can join) is at www.fundi.com/virtualims.

Poor mainframe performance

If my new batch applications aren’t performing as well as I’d hoped, what should I do? Well, the most likely answer is go back to the original code and see what was going wrong. Another solution might be to forget all about developing mainframe-based applications all together and move to a “newer” platform. I put newer in quotes because the IBM-compatible (does anyone ever say that anymore?) PC has been around since 1981 (12th August, I’m told) – which makes it older than many of the legacy applications it’s meant to replace and older than many of the “experts” who work on it! But there’s a third alternative – one well-known to senior mainframers who still inhabit enterprise sites. I can sum it up in three letters. J, C, and L – Job Control Language.

I had it drawn to my attention by Guy Giuffre that the main causes for batch applications wasting mainframe resources such as DASD, tape, and CPU cycles is invariably poor JCL and improper job scheduling. I was assured that the majority of performance problems are “caused by programmers who may know how to write code but are completely lost in writing effective JCL or in putting together job streams that run efficiently”. And if that particular blind spot wasn’t bad enough, there was another target of attack. Mr Giuffre asserted that: “These problems are then compounded by application support analysts who either blindly install what is given to them by the programmers or who do not have the ability to dissect what is given to them and optimize it.”

Hard-hitting stuff, but where’s the evidence? Again, Guy was able to identify his own successes by confirming that he didn’t need code to be re-written, he could achieve better performance by rewriting JCL and realigning job scheduling so successfully that he achieved DASD reductions of as much as 45%, tape reductions of as much as 50%, and overnight batch application run-time reductions of as much as 40%.

There are more savings to be had for an organization. For example, it becomes possible to avoid having to man shifts over a weekend because this and scheduling optimization results in the weekend cycle finishing by 7:30am on a Saturday morning instead of 5:30pm on a Saturday evening.

If someone were to turn up for a meeting with the IT Director and offer them a product that could bring about similar savings, then I bet they would have an easy sale on their hands. And yet, many sites have experienced mainframe programmers or system support personnel like Guy Giuffre, who understand the bigger picture and are not seduced by the need to run every application from a browser using AJAX and RESTful states. They can picture what’s going on inside the mainframe and make changes to improve performance of individual applications. And because it’s their job, their skills and abilities are not always celebrated the way more fashionable successes might be.

And, with so many experienced mainframe people coming towards retirement age, this powerful ability – this sense of what needs to be done to improve performance without pouring over hundreds of line of code – may soon become lost to many organizations. So I suggest that managers start picking the brains of the mainframe staff they have to ensure that this kind of knowledge is preserved. Otherwise, their companies will need bigger and faster hardware, not because their programs are bigger or clumsier, but because no-one has taken the trouble to look at the JCL and the job scheduling. Thanks Guy, for drawing our attention to this.

Mainframe performance

Suppose you wanted your transaction processing environments to work faster – and come to think about it, who wouldn’t? – what are your choices? Well, one solution is available from Ottawa-based DataKinetics (www.dkl.com) – who, you may recall, sponsored this year’s Arcati Mainframe Yearbook (www.arcati.com/newyearbook10).

DataKinetics produce tableBASE, which they describe as a “real-time in-memory table management solution that reduces mainframe resource usage”. They go on to say that its usage can lower costs and mainframe TCO (Total Cost of Ownership), and it also optimizes MIPS (Millions of Instructions Per Second) usage, and all this results in performance benefits and “more powerful and efficient applications”.

The product, they claim, provides huge performance increases over existing I/O intensive DB2 systems and buffered DB2 or cached DB2 systems. At sites using tableBASE, the DB2 database populates in-memory tables once. Application I/O calls are substituted with calls to memory-based tables, resulting in these improvements in application performance. Instead of fetching data at I/O speeds, or buffered I/O speeds, applications are able to fetch data at memory speeds – without buffering or using extra hardware. By optimizing existing IT resources, expensive and large-scale upgrade projects or even complete IT infrastructure swap-out projects can be avoided.

DataKinetics has recently decided to enter into partnerships with resellers around the world to make its products more easily available to mainframe customers. So, in South America it’s through Sun Software (www.sunsoftware.com.br). In Australia and Asia it’s through Serus Software (SSZ) (www.ssz.com.au). And in the United Kingdom it’s through our old friends at RSM Partners (www.rsmpartners.com).

DataKinetics CEO Allan Zander said: “This is a very important opportunity for us to tap into the mainframe market in the UK. RSM Partners is a significant player in mainframe and IT support for financial services organizations and insurers within the UK, and this agreement will provide us [with] the opportunity to penetrate a key market in which we currently have a very limited presence. We’re very excited about this agreement, as it gives us immediate access to a market that has seen very little of the type of mainframe cost control capabilities that DataKinetics’ products can offer.” 

Mark Wilson, Technical Director at RSM Partners commented: “We enter partnerships with only those companies with a demonstrated track record of providing value to their customers. With DataKinetics’ 30-plus years of delivering optimization and performance solutions, and their unparalleled client list, we’re confident that their technology will make a difference to our mainframe customers.”

So, some good news for UK-based mainframe users.