How a Cat Works

"If you try and take a cat apart to see how it works, the first thing you have on your hands is a non-working cat.” - Douglas Adams

Yesterday, I discussed my love for second-level systems, and how the use of them makes us understand z/VM and gives us a place to experiment and learn. Earlier in this blog, I mentioned the aspect of architecture purity. I'd like to take a step down into an aspect of z/VM that not everyone has the need or time to examine. But it's powerful stuff that allows you to see inside the cat without taking it apart.

DISPLAY, TRACE, and STORE. These three CP commands are the keys to magical places. I didn't learn these reading a book, but again by seeing them used early in my job.

I seem to recall seeing DISPLAY used for both virtual and real to check eye catchers in modules. In Performance we'd often get new code to test and actually looking at it in memory was best way to make sure it was what we thought it was suppose to be.

I remember for some VTAM performance measurements, we'd want to disable some of the timer loops in the VTAM code. I remember being shown how to run a trace to see the addresses of where the code that triggered the loop existed, and thinking that's pretty cool. But then my mentor went on to disable the loop by storing branch into that code. This to me was like milking a cow while it was moving. And a whole new perspective opened up to me.

I would smile as I asked a developer how a particular diagnose or instruction like STSI works. Some, instead of getting out the full Principles of Operation, would just grab a virtual machine, drop into CP, store the opcode in memory perhaps change a register, and begin execution at that instruction. Geeky and yet fashionable.

In the late 1990s and early 2000s it seemed everyone working on VM had been working long enough that everyone knew these things. Linux changed that. A couple years ago a Linux developer from one of the distributions found himself working on System z. At a SHARE conference, he asked me if there were any utilities in z/VM to help with problem determination. He worked on an area of the kernel where the problems were often at a point where the kernel wasn't fully up or that tracing from Linux just wasn't feasible. So at a break between sessions, we sat down and I just started showing him some of the things you can do with Display, Trace, and Store. His eyes lit up. I had just armed him with various methods to solve a myriad of possible problems.

There are many examples. One last one I'll mention was working on the raised floor with Geoff Blandy. He took it a step too far when he started modifying the CP that we were running on at the time, with Store Host. Now I was milking the cow while riding on it; and I really didn't think that was particularly safe. At first it was just one or two instructions. This will be quicker than rebuilding he assured me. I think when we were done, he had put in a few dozen instructions this way while I kept an eye on RTM to see if anything was running. Somehow it all worked; or at least didn't crash. Of course I wasn't thinking of the Display Host when at the end he asked, "Ok, just take what we did and modify the source".

This approach is a bit unorthodox, but then so was Geoff in many ways. I did learn from him, and I do have my share of EXECs that modify code or constants in z/VM. All thanks to the keys of Display, Trace, and Store. A powerful aspect of the product that over the years has contributed not just to z/VM, but z/OS, VSE, Linux on System z, actually every OS that ever ran on it.