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.
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.
