MartinPacker 11000094DH Visits (5281)
I’ve been musing on counting transactions for a customer recently. I’d like to share some of that thinking with you.
This post is about RMF SMF Type 72 data, rather than middleware-specific stuff. That’s because it’s
I’m sure this customer is far from alone in being interested in where growth came from. Because they are a CICS / DB2 and DDF customer I’ll concentrate on that, particularly CICS.
I’ve actually had no IMS situations recently. Also TSO transaction rates are rarely significant in the customers I see, so I’ll ignore TSO.
Batch is quite significant in this customer, but it requires a completely different treatment. Perhaps I’ll write about it some other time.
When I say “growth” it is of course a combination of two factors:
But to recap what many people already know: DDF Transaction rate is recorded at the Service Class Period (also Report Class) level - in SMF 72.
This doesn’t really help you when it comes to CPU per transaction. For that - at the DB2 subsystem level - you get DDF transaction rate and Enclave CPU (plus response time). 
CICS is an interesting case, and one I’ll talk about for the rest of this post.
In what follows I’ll refer to the following example, which incorporates a number of typical elements.
If your CICS work is managed to WLM Region goals you don’t get transaction endings.
If transaction Service Classes are used the transaction rate is recorded. 
In the example transactions enter through a TOR and progress thence to an AOR. For most topologies the transaction is counted once in SMF 72 even if the transaction spans multiple regions. With SMF 110 CICS Monitor Trace enabled in both the TOR and the pair of AORs, you would see transactions ending in both places. The 110 view of transaction rate would be twice that of the 72 view.
On the subject of growth, for CICS at least difficult to calculate CPU per transaction
Difficult To Relate To Business Transactions
Both pass through some intermediate infrastructure, perhaps a web server. Even how non-z/OS transactions turn into z/OS ones can be difficult to ascertain. In our example:
It’s worth keeping an eye on how Applications folks wire together transactions as they can be subject to change; While CPU per CICS transaction might not change the number of them that form a business transaction might.
The trend is towards more complex business transactions - which could mean a heady mix of more CICS transactions and heavier ones.
Difficult To Calculate CPU Per Transaction
If, however, you had a transaction Report Class that corresponded to the region Report Class you would be able to use the data from the two to perform the calculation - CPU from the region Report Class and transaction count from the transaction Report Class.
But what do I mean by this?
If the transactions for a region in a specific Report Class had one of a set of Report Classes that were specific to that Report Class the correspondence could be made.
So, for instance, all the regions for the ATM application have Report Class RRCICATM. The second “R” refers to “Region” and “ATM” refers to the fact this is for the ATM application.
All the transactions that run in these regions have Report Classes like RTCICAT1, RTCICAT2, etc.. When these transactions run in different regions their Report Classes have to be different. Here the first “T” says “this is a transaction Report Class”. “AT1”, “AT2” etc are for the ATM application.
Personally, I think this might be a little fiddly to achieve. But I offer it as a suggestion.
Time To Rework CICS Report Classes?
There are lots of reasons for examining your WLM policy periodically. What I’ve discussed in this post is just another reason to.
Some specific things I’d suggest in this area, for Report Classes, are:
A couple of notes on implementation:
In general, though, I would be trying to calculate transaction rates and CPU per transaction on a daily basis, as well as over the longer term.
“Daily” might surprise you but with SMF 72 it’s lightweight and it just might catch an application change that either introduces more IT transactions or makes them heavier.