(Originally posted 2015-06-22.)
As a matter of chance, over the past few months I've been involved in a number of situations where IMS has been an important component of the customers' infrastructure (and I'm about to be involved in another one).
Although I hope my customers don't think I think of them only as test data 🙂 it's been good to have their data move my story forward: Several nice pieces of analysis code have appeared, or been enhanced. 1
But this post isn't really trumpeting the enhancements I've made, so much as discussing how I now view IMS. It should help anyone who – as an outsider – is trying to understand IMS.2
So I'd like to look at how I detect IMS components in two categories:
Actually a third is really a hybrid of the two:
In fact what I call “Applications” some people might well call “System”; To me it's just a useful division.
There are three major IMS address spaces that I consider “System” – Control Region, DBRC and DL/I SAS (Separate Address Space).3
To detect these I look for a program name of “DFSMVRC0” and use the job name to distinguish between them, the endings being generally CTL, DBRC and SAS respectively.
For Data Sharing an IRLM address space is necessary – with program name “DXRRLM00” – but it's difficult to tell the difference between and IMS one and a DB2 one. Possibly naming conventions help here.4
The address space doing all the I/O is the Control Region; I see this in both SMF 30 and 42 Subtype 6.
I can see the Virtual Storage Allocated for 24- and 31-bit (and both can be a big deal sometimes). Likewise 64-bit, though that tends to be rather small for IMS.
The SMF 30 Usage Data Section confirms this is IMS and tells me the version. Note IMS Version 11 says “V1R1” but I believe it's been corrected in subsequent versions. 5
Unlike DB2, however, The Usage Data Section for IMS doesn't encode the subsystem name. 6
IMS applications are reasonably easy to detect, even if they're from e.g. CICS.7
So detecting an Application address space that talks to IMS is easy, one of two ways:
- It has IMS in the Usage Data Section.
- It has a program name of “DFSRRC00”.
Both are definitive. But after that it gets more difficult:
You can't necessarily easily tell a Batch Message Processor (BMP) batch job from a Message Processing Region (MPR). The “necessarily” refers to the fact that while conventionally an MPR has a Proc Step of REGION that's just JCL and, I guess, could be changed.
My code uses this but also looks for “JES” or “BMP” or “BAT” in a number of attributes – WLM Workload, Service Class and Report Class. As long-running address spaces can be started as started tasks or jobs even “J”/“JOB”8 vs “S”/“STC” isn't definitive for job IDs.
But mostly my code gets it right.
Recently I've been creating Gantt charts of when (groups of identically-named) MPRs stop and start. That's quite interesting as you see whether there are times when no MPRs with a given name are up, or whether there is a gap between when a set comes down and gets restarted.
I'm able to observe a number of interesting things about MPRs and BMPs, such as which DB2 and MQ subsystems they talk to, I/O despite the data being owned by the System address spaces, and virtual storage. On the topic of virtual storage in one customer I've just spotted a group of MPRs with very similar names, and the same Service Class and Report Class. You'd think they were cloned regions but it appears they're not, not least because their virtual storage allocations are very different.9
Batch DL/I is kind of a hybrid between the “Applications” and “System” categories above. A DL/I Batch job acts as a stand-alone IMS instance, for example managing its own buffers, I/O etc.
From a batch tuning perspective this is much easier to handle, precisely because of the above. I can see virtual storage and I/O to individual data sets and so can form a view of tuning actions and the nature of dependencies.
So, I think we can get quite a long way in identifying and observing aspects of the behaviour of IMS componentry. But, as usual, you really need to talk to your IMS specialists to go deeper. And this blog post barely scratches the surface of how you can look at IMS with non-IMS instrumentation.
And, in case you hadn't noticed, IMS has gained new capabilities – in terms of application styles, if nothing else. And that is one specific reason why I'm looking forward to the next IMS client engagement; I already know they have Java in their dependent regions.
So a “Part Deux” 🙂 seems likely some time. Actually this is pretty inevitable as I'm always learning (and keen to share.)
I like to return the favour by discussing the relevant new insights with them. If you've been my client you'll know I like to be pretty explicit about this. (And sometimes this looks like and is a test of my analysis.) ↩
Long ago the DL/I SAS was optional – to provide 24-Bit Virtual Storage Constraint Relief (VSCR) – but I don't know if it still is and I haven't seen an IMS installation without for a long time. At the beginning of my mainframe career I did Virtual Storage (including IMS). ↩
IMS Coupling Facility structures are quite easy to detect but again tying them back to IMS subsystems is difficult. ↩
But you should see the other guy. 🙂 One of the other major software vendors has garbage in the Version field. Another doesn't use the Usage Data Section at all. ↩
This is true for all: System, Applications and Batch DL/I. ↩
Here the Usage Data Section in SMF 30 tells you that IMS is connected to, but again not which IMS. ↩
For 5-digit job numbers a job ID is of the form “JOBnnnnn” whereas for 7-digit it's “Jnnnnnnn”. ↩
It's worrying that one of these 8 regions has a 31-bit virtual storage allocation of 1066MB, which is more than 80% of the limit. The rest aren't even close to this. ↩