Engineering – Part 7 – RMF Processor Home Address Fields

I was recently asked where I was getting the home addresses for logical processors from in RMF SMF 70. I will agree the fields I use are not that easy to interpret – so here’s my go at making them more accessible. Along the way I’ll also talk about SMF 74 Subtype 4 Coupling Facility fields that cover the same ground. But therein lies a problem.

It’s important to note these new fields only became available with z16 and RMF’s support for it; z15 and prior won’t populate the fields. The RMF APARs are OA62064 and OA61041. If you’ve ever tried to read the SMF manual you’ll’ve had one of two reactions:

  1. I’ll take this field description at face value.
  2. What exactly does this field mean?

Both are valid reactions. Most people have Reaction 1. I, like most seasoned Performance people, have Reaction 2. I’d say it’s my job to have Reaction 2.

The names of fields and their descriptions are, of course, obscure. Which is why I advocate playing with data to see how it behaves – on top of attempting to make sense of the SMF manual. But that’s someone with Reaction 2 speaking. 😃

The z/OS 3.1 manual seems to have caught up with this instrumentation. 1

I’ve added links to the two relevant sections below.

SMF 70-1 Logical Processor Data Section

There are newer fields in the Logical Processor Data Section. Some decoding of offset 89 onwards is needed.

The Logical Processor Data Section is documented here. It’s a very nice section but most of its contents aren’t new.

So here is a subset of the section of relevance:

Offset (Decimal) Offsets (Hex) Name Length Format Description
89 59 SMF70MaxNL 1 binary Maximum number of topology nesting levels. The value is model dependent with a maximum of 6.

0 The model does not provide information about the topological nesting levels.

1 There is no actual topological nesting structure.

2 – 6 Topological nesting levels are available, beginning with field SMF70CordL1 up to field SMF70CordLx, where x is the value that defines the maximum number of topology nesting levels.
90 5A SMF70CordL1 1 binary Coordinate of the preferred dispatch location of the logical core at topological nesting level 1. Valid if SMF70MaxNL > 0
91 5B SMF70CordL2 1 binary Coordinate of the preferred dispatch location of the logical core at topological nesting level 2. Valid if SMF70MaxNL > 1
92 5C SMF70CordL3 1 binary Coordinate of the preferred dispatch location of the logical core at topological nesting level 3. Valid if SMF70MaxNL > 2
93 5D SMF70CordL4 1 binary Coordinate of the preferred dispatch location of the logical core at topological nesting level 4. Valid if SMF70MaxNL > 3
94 5E SMF70CordL5 1 binary Coordinate of the preferred dispatch location of the logical core at topological nesting level 5. Valid if SMF70MaxNL > 4
95 5F SMF70CordL6 1 binary Coordinate of the preferred dispatch location of the logical core at topological nesting level 6. Valid if SMF70MaxNL > 5

The way to handle this is to take the first SMF70MaxNL nesting levels and decode them. As the description indicates, the meaning of each level is model dependent. It’s worth noting that I don’t expect to see values of SMF70MaxNL below 2 as this support only came in with z16 – but it might be this RMF support gives it the value 0 or 1 for eg z15.

With z16 SMF70MaxNL is 4 – but I don’t think you should hardcode this as one day it might change. That’s not a heavy hint, by the way.

For z16 the coordinates work the following way:

Field Level Meaning
SMF70CordL1 1 Always 0 (unused)
SMF70CordL2 2 Chip
SMF70CordL3 3 Dual Chip Module (DCM)
SMF70CordL4 4 Drawer
SMF70CordL5 1 Always 0 (unused)
SMF70CordL6 1 Always 0 (unused)

You’ll note we don’t have physical core number.

So you get down to the individual chip in a Dual Chip Module – so which side of the DCM.

What’s really nice is this field is available for all logical processors for all LPARs on the machine. And I conjecture for LPAR “PHYSICAL” this is the address of each characterised physical processor. 2 So far the latter has been credible.

SMF 74-4 Processor Utilization Data Section

The Processor Utilisation Data Section is documented here .

The new field is 16 bytes long at offset 28:

Here is a subset of the section in SMF 74 Subtype 4 that deals with Coupling Facility CPU – at the logical processor level:

Offset (Decimal) Offsets (Hex) Name Length Format Description
0 0 R744PNUM 4 binary CPU number.
4 4 R744PBSY 4 binary Busy time (in microseconds).
8 8 R744PWAI 4 binary Wait time (in microseconds).
14 E R744PWGT 2 binary Shared processor weight. Valid if R744FLVL > 14.
28 1C R744PTLE 16 EBCDIC CPU-type topology list entry, as returned by the STSI instruction SYSIB 15.1.2 (Configuration Topology). See IBM z/Architecture Principles of Operation for the format. Valid if R744FLVL > 24.

RMF gets this new field from XES using mapping macro IXLYAMDA submapping IXLYAMDCFMINFO. I was aware of IXLYAMDA for many years, but not this sub mapping.

The documentation for IXLYAMDCFMINFO describes the field as “CPU-type topology list entry, as returned by the STSI instruction SYSIB 15.1.2. Refer to Principles of Operation for format. (LEVEL25)”

“LEVEL25” refers to Coupling Facility Control Code (CFCC) – which is indeed new with z16.

I’ve tried to examine this mysterious “SYSIB 15.1.2” in a little more detail. But this is where I’m stuck: With numerous sets of customer data I’ve not been able to decipher it. There is a lot written about it in Principles Of Operation but it’s not something I’ve been able to make sense of. I’m sure among my readership there are people who can decipher it. If so please comment below. I’m not the only one who wants to know.

What’s nice about this instrumentation is it describes the addresses of coupling facility images on machines that might not have a z/OS LPAR to cut SMF 70-1 for. So it would be really nice to be able to decipher it. Having said that, SMF 74-4 has for many years told you Plant Number and Serial Number for each coupling facility.

Making Of

I started this blog post a few weeks ago, convinced I’d be able to decipher all the new topology information. Well, I got the most important piece done – as it was pretty trivial. However, it’s annoying not to have got the second piece done.

I’m actually finishing off this blog post sat on a plane at Gate A9 of Heathrow Terminal 5. We’re due to fly to Copenhagen – in my case for a customer workshop tomorrow. And we have a 90 minute delay due to something wrong with the wing of this British Airways Airbus A319. I think the captain made the right call. 😃


  1. You’d be amazed how many web searches still resolve to older z/OS releases. However, it’s easy to get to the 3.1 equivalent from there. 

  2. It certainly behaves that way – in that the home addresses for LPARs consistently fit inside the set of drawers / DCM’s / chips that it suggests. Further, IFLs and ICFs do tend to be in the top drawer. So it’s not garbage. 

Published by Martin Packer

I'm a mainframe performance guy and have been for the past 35 years. But I play with lots of other technologies as well.

2 thoughts on “Engineering – Part 7 – RMF Processor Home Address Fields

Leave a comment