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

Print Email

Join Now!