(Originally posted 2012-07-10.)
I can tell when a CICS region came up – without looking at CICS-specific instrumentation. What’s more I can repeat the "trick" for any of MQ, DB2, IMS, etc – and so can you.
I’ve just started work on a new piece of reporting. I’ll call it "raddrspc" as that’s the name of the REXX EXEC that I’m writing. It’s about address spaces – most notably long-running ones.
In the mid-1990s when we were building our Batch Tuning offering PMIO, we came up with the term "Job Dossier". I think it was my term, but others in the team reading this are welcome to disagree. 🙂
The idea of a job dossier was to have reporting code put together – in a structured fashion – all the information about a particular batch job we could glean. Essentially from SMF but not necessarily so. I still use job dossiers in my Batch work. But the focus was on timings and things which ended i.e. batch jobs. What I’m starting on is analogous: a "dossier" of stuff about an address space. Call it an "Address Space Dossier".
The key difference is that I’m interested in interval-level information, rather than events such as data set CLOSEs and steps ending. But I AM interested in events as well. "Interval-level" because I want to apply the Job Dossier idea to things that run for hours, days, weeks or months – such as DB2 subsystems and CICS regions.
It’s been interesting these past few weeks: I’ve been involved in lots of very diverse situations – but they all indicate one thing: It’s time to get nosey about address spaces. And the only way I’m going to do it is if I can write analysis code that makes me quick and aids structured thinking.
SMF 30 Interval records are cut for every address space I’m interested in – so that is a good unifying place to start. I’ll most certainly report on address spaces in an "idealised" way using this data. Then I will detect whether to go down the CICS "leg of the trousers" 🙂 , the DB2 DBM1 one, or whatever. Each of these have their own instrumentation. So if it’s available (for instance DB2 Statistics Trace) I can get specific using it.
There are other sources of information that work for any address space I might be interested in: One is SMF 42-6 Data Set Performance records – also cut on an interval. (Interval proclivities will make this complex, I’m sure.)
But for now, let’s talk about Up Time:
One of the first things I’ve done in raddrspc is extract from SMF 30 Interval records the Reader Start Time (fields SMF30RST and SMF30RSD) for the address space I’m interested in. Because I’m parsing all the interval records for the address space I can see if this changes. In my test case it certainly does: For CICS regions I can see a restart in the middle of my data – which is for a week. I can also see that the previous restart was 24 days before the data starts. And this picture is consistent across all the CICS regions.
So this is not a set of data from a customer who restarts CICS every night. I think that’s a useful nugget of information.
So, in your installation you can conclude similar things – if you don’t know them already.
As I carry on with building raddrspc – which frankly has to be a background activity – I’ll see if there are other pieces of information of similar interest and share them in this blog. I’m sure there will be – because I already know what some of them are.