I blogged about IBM’s IMS (Information Management System) at the end of July, saying that it has been around since 1968 and originated as a bill-of-materials program for NASA’s Apollo programme. I said that IMS effectively comes in two parts – there’s the Transaction Manager (TM) part and the Data Base (DB) part. I talked about different types of database, and I mentioned the Virtual IMS user group at www.fundi.com/virtualims.
Today I want to pose the questions: how much does an IMS development/test system cost? And how many development test systems does a site typically have installed?
It’s a bit like asking: how long is a piece of string? Obviously every piece of string has a length, but it is unknown, a quantative answer can’t be given. And by implication, whatever else is being discussed will contain a degree of indeterminate uncertainty!
Our experience at iTech-Ed (where we administer the Virtual IMS user group) is that a single IMS development test system can cost an organisation between US$1,000,000 per year and $2,000,000 per year (and possibly more in some cases).
There are some sites that run their development systems on dedicated machines that can be larger than many average-sized organizations’ production systems.
However, there is an additional complication. We believe that, although IMS is a huge revenue earner for IBM, they will waive their fee for software for organisations that are development shops and don't use it for production.
We also estimate that the personnel costs for installing and maintaining IMS development systems can amount to about half a million US dollars per year.
And the number of IMS development/test systems can vary hugely from 1 or 2 true development systems (plus test, QA, etc) in smaller shops, to larger customers, who may have any number from around ten to perhaps 30+. We know of some users with 300+ test IMS regions, but the bulk of the bell-shaped curve is skewed to much lower values. The reason we believe the average is ten or slightly above is because of the amount of administrative effort these test systems take to maintain.
The waters can be muddied further by the fact that organizations can negotiate deals on price with IBM, but are then discouraged from sharing information about those prices with others.
Our conclusion is that the cost to the organisation of running a development system depends on the size of the installation. US$1-2M is a good estimate of the cost for each IMS development/test system, with 10 being a reasonable estimate of, on average, how many development/test systems exist.
And, of course, if you have any further information on this, we would be really interested to hear from you.
Showing posts with label Analysis. Show all posts
Showing posts with label Analysis. Show all posts
Monday, 29 August 2011
Sunday, 13 February 2011
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.
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.
Subscribe to:
Posts (Atom)