IMS Though My Eyes

(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. ¹

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.²

So I'd like to look at how I detect IMS components in two categories:

• System
• Applications

Actually a third is really a hybrid of the two:

• Batch DL/I

In fact what I call “Applications” some people might well call “System”; To me it's just a useful division.

System

There are three major IMS address spaces that I consider “System” – Control Region, DBRC and DL/I SAS (Separate Address Space).³

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.⁴

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. ⁵

Unlike DB2, however, The Usage Data Section for IMS doesn't encode the subsystem name. ⁶

Applications

IMS applications are reasonably easy to detect, even if they're from e.g. CICS.⁷

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”⁸ 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.⁹

Batch DL/I

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.

Conclusion

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.)