CICS and Batch
MartinPacker 11000094DH Visits (10655)
In my experience there are two kinds of CICS installations: Those that take CICS down at night - to run the Batch - and those that don't.
There is a loose correlation between what the data manager is and which approach is taken: VSAM-based CICS applications tend to be less 24x7 than DB2 ones, though it's not that clear cut.
This post is about how you (really I) might glean how you run CICS vis-a-vis Batch, using SMF. Even if you know the principle of how you manage CICS regions the numbers should still be useful and not too onerous.
If you're the kind of installation that takes CICS down the SMF 30 Job-End records (Subtype 4) will tell you when CICS started and stopped. (If you want to know when CICS came down in an unscheduled manner the same data applies.)
If you don't expect CICS to come down often the SMF 30 Interval Records (Subtypes 2 and 3) will confirm the region is still up.
(The (ancient) SMF processor I use - SLR - has an Availability Reporting capability. I would expect and hope other tools have something similar. In any case it's just another take on regular performance data. I'm considering playing with SLR Availability Reporting.)
For the purposes of this discussion I consider any address space running program "DFHSIP" to be a CICS region. There may be other program names of relevance, too.
My preferred means of display is a Gantt chart - my (also ancient) formatting tool - Bookmaster - doing very nicely in that regard. I got into Gantt charts for Batch Suite display but the technique is fine for online regions. I'm beginning to annotate Gantt charts with commentary - a technique you may find useful. (I might post soon on how I'm doing the annotation - as that has been an interesting side project.)
I was reminded by a couple of recent current customer studies of some of the reasons Batch and CICS often don't run alongside each other. Sometimes it's logical "end of day" quiesce points (or "Positions") and sometimes it's to ensure CICS and Batch don't compete for resources. (More than half the customers I know have a higher Batch Window CPU Utilisation (if you squint at it) than that of their online day.) The "end of day" reason often shows up as CICS closing data sets and batch jobs opening them (and conversely at the other end of the night). I saw this in the study I'm currently finishing off. As many of you know I use the Life Of A Data Set (LOADS) technique - and this time I saw CICS regions as well as batch jobs. I think it would be useful to see how long after CICS comes down the first batch job processes any of the region's data. And the same at the other end.
It's much more difficult to see the DB2 objects - table spaces and index spaces - accessed by CICS regions and batch jobs. But then, as I said, overlap is more common here. It raises the interesting question of how an installation knows it's safe to run CICS and the related batch concurrently. Maybe you can share your experiences. I think it has something to do with Applications people (shudder) designing things.
The same applies to MQ queues, of course. And IMS is a whole other game.
So we can use SMF 30 to document uptime for CICS. I think it would be useful also to form a view of what the transaction profile looks like while the regions are up. This would probably be driven by CICS SMF 110 records, possibly pulling in correlated DB2 SMF 101 and MQ SMF 116 records. There are two reasons to do this:
By the way everything I've said above (other than the specific program name) applies to most of the other online application styles. I'm just reminded of CICS, as I say, by a couple of current customer engagements. Undoubtedly the next one will remind me of something else.