Evangelizing Mainframe
Print Email

Talking Mainframe: From MVS Commands to Zero-MIPS Upgrades

Greetings. I was delighted to be given the opportunity to occasionally dump some of my thoughts here at Destination z.

I’ve been working on mainframes—more specifically the development of mainframe software and hardware—for more than four decades, so even without being a genius, I know a lot of stuff. What I need to figure out is what part of that stuff you-all would be interested in reading about. I’d really appreciate some help on this.

I call myself a “z/OS philosopher” because, although I know a lot of stuff, I have no real experience at actually running a mainframe installation, and thus most of my knowledge is somewhat abstract. So, if there’s some mystery that you think my mainframe arcana can illuminate, or an option you’d like my two cents on, perhaps you can take the time to leave a comment here.

In the meanwhile, I’ll try to fill out the rest of this with some stuff that you might find amusing.

Have you ever wondered about the one-letter abbreviations of the common MVS commands? Maybe not, but I did when I was a young computer operator in 1969. I was a computer operator for the people that were developing OS/360 MVT in Poughkeepsie, N.Y. These were the days before we used CP67 (and later VM) to give the programmers their own virtual machines that they then could operate for themselves. Like most new computer operators in those days, I had virtually no previous exposure to computers, so literally everything was new.

I had lots of questions—many of them pretty stupid in retrospect. One question was, “Why are the one-letter abbreviations for commands so whacky?” For example, why was Z as an abbreviation for HALT? Well, I think I figured it out. They could not use H because that was short for HOLD. They could not use A because that was short for RELEASE. But why A for RELEASE? That’s because R was already taken for REPLY, and E was already taken for RESET. The E for RESET was again explained by the fact the R was already for REPLY. Are you still following this?

OK, let’s get back to HALT. They could not use L because that was for LOG. They could not use T because that was for SET, which was because S was for START and E was for RESET as pointed out above. So, the letter Z was chosen because it was not taken for any other MVT system command. Yet, it may have been a very good choice. One can interpret the command Z EOD to mean, “go to sleep, the day is done.” I leave it as an exercise for the reader to figure out why G is the abbreviation for the SWAP command!

For my second little piece, I have to poach a bit on the territory of the blogs devoted to performance. But, since I’m not going to include any numbers, it doesn’t really step on their toes that badly. It’s based on a conversation I had recently about what can happen when a processor upgrade is done without increasing the capacity. You might call it a zero-MIPS upgrade. What happened, in this case, was that an important program was taking a lot more CPU time and, since the machine was running at high utilization, this actually elongated the elapsed time of the jobs that executed the program. Many of you may already know how this comes about, but I’ll continue to string together the facts that bring about this unhappy outcome.

The first fact is that every different processor line has a different design. Even though the new processor is, on average, faster than the older design, there will still be some things which it does relatively slower. By this I mean that even though the base cycle time of the newer processor is faster, there are things that take more cycles to complete than they did on the older machine. For example, suppose that the Load Half (LH) instruction takes one cycle on the older machine and two cycles on the newer one, but that the cycle time of the newer machine is three times faster than the older machine. In this case, although the LH instruction is absolutely faster on the newer machine, it is relatively slower on the newer machine. That is, relative to the Load (L) instruction, which may be one cycle on both machines, LH has become slower. A program written with only L instructions would run a lot faster on the new box but one written with only LH instructions would only run a little faster.

The second fact is that mainframe processors are rated based on a limited set of benchmark workloads. In most cases, the prediction of actual performance is pretty good, but the reliability of the prediction depends on the instruction mix of the benchmarks and of the customer workload being reasonably similar. When this is not the case—when the customer application is very different from the benchmark mix—the prediction can be somewhat off.

A third fact is that, although the instruction processors keep getting faster, the latency for data access is not really decreasing. This means that memory accesses, and accesses to the several levels of cache, take more CPU cycles to complete as the processor cycle time speeds up. In this sense, data access is getting relatively slower as the processor gets faster. That means the relative speed-up in upgrading from one processor line to another is somewhat dependent upon the data access pattern of the application program compared to the data access pattern of the benchmark workloads used to rate the machines. Applications that have lower data-access intensity than the benchmarks will enjoy a greater than predicted speed-up. Applications that have a higher data-access intensity will not experience as much speed-up and, in extreme cases, may actually run slower.

The last fact I want to point out is the most arcane and pertains to the so-called subcapacity processors—that is, processors that do not provide the capacity of a full-capacity processor. Typically, the mid-range mainframes from IBM offer a wide range of capacity settings. Yet, they all run at the same GHz clock speed. This also can lead to the kind of performance non-uniformities that I touched upon above. It certainly can aggravate the data-access issues when the access intensity is great.

Usually the phenomena that I’ve described are lost in the mist if the upgrade to a different processor line also includes a substantial increase in system capacity. But, they can stick out like sore thumbs after a zero-MIPS upgrade. So, extra care is need when planning such an upgrade.

Gary King from the System z lab in Poughkeepsie gives a presentation at SHARE which covers these issues and much more. At Anaheim in March 2011, it was called, “To MIPS or Not to MIPS—That is the CP Question.” He will be giving it again this March at SHARE in Atlanta if you are lucky enough to get a chance to see it live.

I’m tired of typing, so I’ll close for now. Your comments and suggestion are very welcome. Enjoy …

Bob Rogers is a z/OS designer, philosopher and evangelist. An IBM Distinguished Engineer, he frequently presents at SHARE and other conferences.

Posted: 2/27/2012 5:22:42 AM by Bob Rogers | with 3 comments

Print Email

Please sign in to comment.

Sign In


This was a very interesting article. I was wondering if you could do an article on WLM. Also, where can a newbie get started on Capacity Planning and Performance Tuning?
Posted: 3/2/2012 11:41:19 AM by Scott
Thanks Bob, as a capacity planner, I appreciate the subject. We ran into this with the install of z10. A batch process didn't have the same reduction in CPU time as other processes, when it executed on z10 (formerly on z9). It was identified as the LH change that you describe.

I'm interested in the pipeline or instruction ordering mechanisms. You touch on it in your "How Do You Do What You Do When You're a z196 CPU?". Are there any sample statistics from the z196 Microprocessor Pipeline that can give us an idea of how well the process is performing?
Posted: 3/1/2012 3:40:04 PM by Mark Smith
For most of my 40+ years as an IBM programmer, most of the development was based on assembly language programming for a computer system that was CPU-bound during the critical hours every day (14 to 24 hours per day). Approximately a third of my time was with assembly language programs. Knowing instruction timing was critical to reducing CPU-time. It was a sad day when IBM discontinued documenting instruction timing, for reasons that were not made clear. It is encouraging to know there are still those who recognize the importance of understanding 'instruction timing' information is valuable, useful information still. It gives hope that even IBM will once again understand the importance of releasing this information and not require multiple customers to develop software whose sole purpose is to measure instruction timing. For programmers who have not had the pleasure of considering the performance of their code, in my experience performance could result in a 20 to 98 percent reduction in CPU-time, resulting in a saving for a original program that uses 1 hour of CPU time to run 48 minutes and 1.2 minutes. This is something you may want to consider the next time you are thinking about upgrading to a faster CPU or worrying about not being able to complete critical processing in the available time period.
Posted: 3/1/2012 2:27:46 PM by shelley

Join Now!