Tag Archives: Computer Measurement Group
A guest post by Denise P. Kalm – You’ve probably met John Baker, mainframe guru at MVS Solutions. He speaks regularly at SHARE and CMG (and probably a few places I didn’t know about). His smiling face greets you at the MVS Solutions booth. But what you may not know is that he is passionate about volunteering for CMG – Computer Measurement Group.
With the General Chair overseeing the logistics, John is responsible for ensuring that CMG continues to provide quality mainframe content, in addition to the other tracks. Since mainframes are only a part of what CMG covers, John must work diligently to find the kinds of papers people really want to hear. Because of his wide network, he can draw on some of the ‘mainframe stars’ to help out.
Since the days when processor time was costly (and you input a job on punch cards), the CPU Busy metric has had intense focus. There are so many ways to look at the metric, all having vastly different meanings. Virtualization made it even more complicated. But for many in our field, this is still a very critical number. But is it the most important number?
Delays are part of our daily lives. We wait in line at the grocery store, at the drive-through, and on the road in our cars. While it may not seem like it, delays are a fact of life in your mainframe as well. As amazingly fast as these machines are, there are inevitably some measurable delays in application response times and throughput. The question is: should you care about these delays?
Performance Analysis is about identifying the distribution of response times and dealing with each component. For example, if a job runs for two hours but only uses ten minutes of CPU time, there is little to be gained by running the job on a faster CPU. The best “bang for the buck” is to look at where the other 110 minutes are being spent and try to reduce those delays.
At MVS Solutions, our goal is to ease the challenges faced by mainframe datacenter staff and management. While this mandate inevitably translates into innovative solutions—such as ThruPut Manager—in many ways, it extends beyond that. We’re not just here to develop better software. We’re here to move the industry forward.
While we strive to do that in a number of ways, we have been particularly recognized as innovators through our involvement in Canada’s Scientific Research and Experimental Development (SR&ED) program. In the early days—we’re talking 30 years ago—our company played a key role in helping SR&ED leadership integrate software development into the grant eligibility framework, and we continue to take part in the program—performing research and producing innovation that benefits the mainframe industry when applied to ThruPut Manager.
In an RNI context, IBM says the number of concurrent tasks is the primary factor in workload performance, particularly with today’s high frequency processors. The z13 architecture has a vast capacity to serve multiple, concurrent applications. Regardless of the amount of work you throw at it, z/OS will do its best to provide some service to all workloads. As result, we generally throw all the work at the machine at once.
Are you running too much or too little? Let’s look at some measurements and techniques to control how much concurrent work you are running. Cycles per instruction, Initiators, LPARs, Logical Processors and Weights are a few of the topics we’ll explore. You will find techniques to improve performance, throughput, and efficiencies of your mainframe. Come and see just how much less you should be doing.