Getting the CPU-Measurement Facility to work in z/VSE

At long last - the promised guest blog entry from Martin Trübner! Vielen dank!

Let me first introduce myself

My name is Martin Trübner. I am German and work from here, but did (when being on site was vital) gigs all over Europe and the US. I was educated and did my first job in z/OS predecessors but did my first sysgen on DOS/VS R31. During my activities I do run into z/OS and it is a wonderful environment. You can do everything and everything can be avoided and/or forbidden (through real measures), but not so in DOS/VS. Today I am bit-wise active in z/VSE and CICS/TS, and as an application person (with enough background to be dangerous) in z/OS. 

First Encounter

With the announcement of the z196 I stumbled over the CPU-Measurement Facility (CPU-MF). I was delighted to read that it is available on the z10 as well. The various counters did not really interest me, but the sampling was something for which I could imagine a very rewarding use case. If you want details of what is collected, here is a picture with mouseover explanations. But I read that it is only available for native operating systems. Since most of the z/VSE shops do run with z/VM on top, there was no point for me to investigate further. 

During a presentation at the end of June 2012, I was alerted by a single sentence that read: 

New z/VM CPU MF COUNTERS support – APAR VM64961

I thought to myself: “Now this is good news. Let's dive into the details”. 

Preliminary checks

I Googled for it and found a few presentations, the book that documents the instructions and structures used for it, and some bits and pieces about it; I must also not forget documentation regarding Hardware Instrumentation Services (HIS) for z/OS (thanks to "E."). Here are my findings:

• For sampling, it needs a setting in the SE/HWC
• For VM it needs the above PTF
• z/OS has HIS that explores it and makes lots of extra information  available
• z/HISR from Phoenix has software that uses the z/OS HIS data.
• The CPU-MF "POP-equivalent" manual, Load-Program-Parameter and the Set-Program-Parameter and CPU-Measurement Facilities (IBM manual SA23-2260-02) says that this facility is a prerequisite for the CPU-measurement sampling facility.
• The structures for sampling are very clever and suitable for any number of samples
• There is even provision for emptying buffers while sampling is active  
• There is even extra space for extension (as it was when TRAP–ping was introduced, shortly before 64-bit was introduced).

Setup in z/VSE / Problems

Nothing is a show-stopper, so I decided to go for it and write a POC with only 1–minute sampling at every 2 milliseconds (just one SDB (sampling data buffer) at 1MB), and here is what happened…

(Please do not forget- this is all occuring in z/VSE 5.1, which is the first version of VSE that supports 64-bits virtual.)

• My hardware does not have it. Okay, there are customers with a z10/z196/z114 that willing to help but the switching on via the SE/HWC is not an everyday activity. So here we have a delay.
• It needs IARV64 – my first chance to use it – one more reason to go for it.
• For debugging I would like to display what I “prepared for the HW”/”got back from HW”. 
• Ah…well, SDUMPX does support areas above the bar–but how do I get an address space STOKEN. I know what it is but heck – should I really go for control blocks to get it? Thanks to "I.", who showed me an undocumented operand of ALESERV. So now we can display these areas even without the famous 0C3 or my debugger (TRAPPER, which does understand 64-bit storage).(Ray adds: I know of this operand. It can also be used to access other partitions via access registers.)
• IARV64 REQUEST=PAGEFIX,RANGLIST=RLIST_PTR,NUMRANGE=1 abends with a ABEND 2C5 reason 0598 which reads: “0598 IARV64: Parameter list or range list must be in 31-bit storage”. How can I guarantee 31 bit storage? I can do 24, below the bar, and any boundary- but 31? With the help of "I." it was identified as typo (meaning “not 64”) and a coding-error on my side.
• I have yet to find a place where my program needs to use LPP. I am not part of the operating system, and have no way to transport (and complement later) any specific information via these 8 bytes (as opposed to z/VM or z/OS which certainly do utilize the 3 fields (basic, logical, virtual) and would certainly produce confusing results with a program injecting its own 8 bytes).

The END

I coded it, commented out the QSI and LSCTL instructions, created entries as I expect the HW to do it, tested it, and removed the testcode…and then I learned that I have not read the fine print of the PTF (thanks to "E.", saving me hours of frustration in front of a z196) . Here is the fine print: 

Support for the CPU-Measurement Sampling Facility and ... interfaces for guest use are not provided.

So I can put this to a rest and wait. Maybe one day support for guests will show up.

Next

Next time I get a chance, I will write about CICS/TS and coding a simple TRUE and a GLUE.

Es freut mich sehr, euch Martin Trübner, unseren Gastblogger, vorzustellen

(That's enough German for today.)

Martin's blog entry will be published this week, but first I thought I would give you a little bit of information about him. 


Martin is a freelance technical software developer, with deep system roots in z/VSE, and he has carried over his vast CICS applications knowledge over into z/OS. He has also written some software for Windows platforms. He was born in 1953 and met his first bit (an EBCDIC one) in 1972. He speaks German, English, HLASM, Cobol, PLI, REXX and some lesser known dialects like Pascal, BASIC, and Perl (which, if you didn't know, is really a town near the Luxembourgish/French/German border, located near Borg and Apach(e)). Before becoming a freelancer he worked for various shops including applications, central development, a vendor of system programs, and for a PCM (Plug-Compatible Manufacturer, a producer of hardware that supported the IBM System/370 and 390 architecture)


I met Martin during my days in Software AG R&D. I was a developer for Entire System Server, working on the two supported IBM platforms (the third being BS2000/OSD). I don't remember all the details, but I know VSE/ESA was involved. He and I became good friends, and we finally met when I travelled to Germany in 2003, and we got together again in 2005. (From that last visit, I seem to recall lots of good beer and yelling back in unison "Wir wissen!" at the GPS' repetitive "links fahren" as he drove me back to the hotel.)


Martin is one of a small group of fellow mainframe developers whose opinions and advice I wholeheartedly trust. I am glad he asked me if he could be a guest blogger, and as I stated in the title, es freut mich sehr.


Welcome aboard, Martin!


(Und vielen dank, Martin, for making my title more German-sounding. I was pretty close with the original, just a couple minor transgressions, like forgetting that vor- is a separable prefix, and the wrong case for "unser".)

Guest blogger coming soon – and an open invite to others

So, after a few blog entries, it looks like that this blog is going to be a lot about the development and debugging experiences when writing system tools software, as well as the toils and tribulations of working with computers on what should be simple tasks (like updating Windows) from an old-school mainframe perspective. 


(GUIs? Ha! We don't need no stinkin' GUIs! When I was your age we had switches on the panel and blinking lights, and we liked it!)


A good friend of mine - or should I say ein gut Freund - Martin Trübner asked if he could contribute his experiences working with one of those other IBM mainframe operating systems, z/VSE. I said sure! I do miss working with z/VSE; it's been about 8 years since I worked with it on a regular basis. It requires a bit more hands-on management from a systems programming perspective, which is good, as it keeps the brain engaged. I wouldn't mind getting a chance to dip my fingers back in the platform.


Look for his first guest blog post in the next few days.


I also am extending an open invitation to all mainframe software developers to guest blog. You've seen what I've done so far. If you want to share your thought process on designing or debugging of your daily routine (nothing proprietary, of course!), please send me an email, drop me a note on FB, G+, LinkedIn, XING, or Twitter, or send smoke signals in the Sacramento vicinity, and please make sure they do not look like the recent spate of grass fires we've had.