CICS Takes The Liberty
MartinPacker 11000094DH Visits (396)
Sometimes I can plan ahead, designing analysis code for an upcoming feature of e.g. z/OS. Often, however, a condition falls into my lap - without my having thought about it first. This is about the latter.
It’s about CICS’ support of Java Liberty Profile - or “Lib Profile” for short.
I want to talk about two things:
I discovered, inadvertently, that a recent customer’s 4 Production LPARs each had a pair of CICS regions running Lib Profile. These happen to be small regions right now, so their performance numbers are small. But, that’s enough to get me sensitised to the topic of this post.
What Is CICS Liberty Profile?
Real CICS people, get your cringing / sniggering over now. But do feel free to “well actually”1 me.
Let’s divide this into two questions:
WebSphere Application Server (WAS) V8.5 introduced Lib Profile - enabling lightweight java servers, with a quick startup time and a small footprint. It also has configurability - through its (XML) server configuration.
It has less function than the full-function WAS java profile, though selectability (through server.xml) allows you to add from a bunch of functions.
But Lib Profile is not just about WAS. In z/OS 2.1, z/OSMF was reworked to use Lib Profile. So this makes z/OSMF much more consumable - as its footprint and startup times are improved.
CICS Support For Liberty Profile
CICS support for Lib Profile was introduced in 5.1 and enhanced thereafter. Basically you can run Lib Profile applications in a CICS region.
If you want a deeper treatment read the IBM CICS and Liberty: What You Need To Know Redbook.
One thing I note is this Redbook mentions setup considerations for both Type 2 and Type 4 JDBC drivers. To state the obvious the “J” stands for “java”. I’ll mention DB2 in a bit.
Detecting CICS Regions With Liberty Profile
So, I got SMF 30 Interval data from a customer. As loyal readers3 will know, I use the Usage Data Section data to discern what I can about individual address spaces. Mostly this is software level and topology information. More on both of these presently.
My code, for quite a few years now, has detected CICS regions. In this customer there were many and the “DFHSIP” Usage Data Section says CICS TS 5.3. It also mentions DB2 and MQ. So far so good.
I wrote the code in an “open minded” way - so any usage data will show up, including that from some other vendors.4
Now, this is where it got interesting. Of the many CICS regions, 8 showed a ‘CICS LIBERTY’ data section. 2 on each of their 4 cloned5 LPARs.
This customer has a good CICS naming convention - and these 8 regions followed that, with the LPAR letter embedded in the region name. In this case all 8 regions’ names ended with “J”. Might be the beginnings of an evolution of the naming convention, but I digress.
The point is, the presence of ‘CICS LIBERTY’ in a Usage Data Section tells you the region is using Lib Profile.
Other Numbers You Can See
In many ways these regions are just normal CICS regions. So, I would expect connections to DB2 and MQ to show up in their own Usage Data Sections. Indeed the above-mentioned Redbook makes the point you have to set up the standard CICS/DB2 and CICS/MQ machinery first.
And I do see MQ and DB2 connections for these regions, complete with their versions and subsystem names.
As these are small, I gather under development, regions I’m not surprised the numbers are small. So, the zIIP-eligible CPU for each region is about 0.3% of a processor. The non-zIIP portion is about 0.1%. Like I said, small regions.
So, I would expect that 3:1 zIIP:GCP ratio to be about right, scaled up. But I’m guessing. Recall JNI code and the like wouldn’t be zIIP-eligible. But the application code ought to be. But at least this is readily measurable.
Another thing that is measurable is ZFS / HFS I/O, Pipe I/O etc - as detailed here.
In these regions I only see a relatively small amount of file system I/O. I would expect to see quite a bit more for busier regions. The EXCP counts are modest, too.
Virtual storage is an interesting one. You can see allocated virtual storage in the three obvious areas:
It’s uncommon these days to see signs of constraint below the bar but the other two warrant some attention. But recall this is allocated virtual memory. There’s nothing in SMF 30 to document how it’s actually used.
For CICS, I would view 31- and 64-bit memory differently.
Of course, virtual memory accessed turns into real memory used - at least to a first approximation.
So let’s look at one of these regions, from the virtual storage point of view.
I’m going to repeat something I’ve often said: The beauty of SMF 30 is that it is scalable. Meaning that you can work with arbitrarily large numbers of address spaces, from many systems. In other words your entire z/OS estate. Something which isn’t true of middleware-specific instrumentation. Few people object to sending me SMF 30; Most are wary of sending middleware-specific SMF across the board.
The aim of this post is to show, yet again, how you can use SMF 30 to scan your CICS regions, bringing the relevant ones to life - at least a little bit.
One thing I’d like to see - and I don’t know how feasible this is - is an encoding of Lib Profile level in the Usage Data Section. Today there is no real clue - with the product number being “0000-000”. But then mangling e.g. ‘220.127.116.11’ into 8 characters might be difficult. Actually that’s an easy one…