DB2 Data Sharing and XCF Job Name

(Originally posted 2009-04-25.)

Back in z/OS R.9 RMF Parallel Sysplex New Fields (in 2007) I mentioned a new field: R742MJOB (XCF Member Job Name.)

At the time I had no real customer data so I could only espouse the HOPE that this field would be useful. (When I asked for it to be added to the SMF 74 Subtype 2 record it seemed to me it probably would be.)

Now that z/OS R.9 is “mainstream” I’m seeing lots of data at this level. And so, because it’s mainstream, I think it’s time to talk some more about this field (and to tell you what I’m seeing in customer data). I think you’ll like it.

But first some preliminaries:

XCF Groups and Members

Before there was Parallel Sysplex there was Sysplex. And the main ingredient of (base) Sysplex was XCF signalling. Applications that use XCF consist of groups and members. A group is essentially an application. So the “SYSGRS” group is the GRS application. Members are address spaces participating in the application.

XCF’s job is to pass messages within members of the same group, whether on one system or several within the Sysplex.

Instrumentation

Since the advent of XCF we’ve had group names, member names and messages sent and received in the 74-2 record. But there’s a problem here, best illustrated by the example of DB2 Data Sharing:

A DB2 Data Sharing group comprises, amongst other Coupling Facility structures, a “LOCK1” structure. It’s a Lock structure and it’s called the “LOCK1” structure because its name is always “_LOCK1”. We can easily identify this structure and the group it belongs to. Associated with the LOCK1 structure are 2 XCF groups:

• IXCLOnnn – which is a particularly unhelpful name as ALL Lock structures have such an XCF group associated with them. (There usually being several other Lock structures in a single Parallel Sysplex – such as GRS Star and VSAM RLS’s Lock structure.) The member name, by the way, would be something equally unhelpful like “M102”.

  The purpose of this group is to resolve potential “False Contention” situations in the Lock1 structure (possibly caused by too small a lock table).

• DXRabcd – where the “abcd” is the Data Sharing Group Name. This is slightly better but it doesn’t help that the member name is e.g. “DXRDPG0$$IPB1003”.

  This XCF group is used by the various IRLM address spaces in the group to resolve locking conflicts from DB2’s perspective. (IXCLOnnn group traffic resolves to either a False Contention or an XES contention, the latter having to be resolved to either a lock being granted or IRLM negotiation causing the requester to wait.)

So, it would be really handy to isolate these two types of traffic for a particular DB2 Data Sharing group (and perhaps to work on reducing it). As you can see, it’s rather hard to do that without more useful information. This is where 74-2 XCF Jobname comes in…

It turns out that for BOTH the IXCLOnnn group and the DXRabcd group the job name is the IRLM address space name. So, if you know the IRLM job name (hopefully because you’ve given it a name close to that of the Data Sharing group it supports) you can easily tell which XCF groups relate to that Data Sharing group. And then perhaps you can do something about the traffic.

Perhaps I’m displaying my ignorance of DB2 here but in the test case I’m looking at right now I see 2 IRLM address spaces in one system and one in the other, all sharing the same XCF groups – both IXCLOnnn and DXRabcd. I didn’t know one could run 2 IRLMs in the same DB2 Data Sharing group in the same LPAR. I’ll admit I’m not really sure what to make of that.

But what about other XCF groups? It turns out that they also have good mnemonic address space names. But then for most other groups it’s obvious what the XCF group is anyway.

Glancing over a friend’s shoulder at a modern RMF XCF Activity Report I didn’t see the job name in the report (but rather the member name). But then I, and I expect most other people, don’t often look at RMF Postprocessor reports all that often.