Transaction Counts

(Originally posted 2016-10-06.)

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

• Generic – applicable to multiple transaction managers.
• Much lighter weight – so every customer can collect, retain indefinitely, and process it.

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:

• Growth in transaction rates.
• Changes in CPU time for each transaction.

DDF

I’m going to discuss DDF transactions only briefly; I’ve talked about them a fair amount, not least in More Fun With DDF.[1]

Perhaps more useful is this presentation of mine[2]

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). [3]

CICS

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. [4]

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

• Transaction service classes not same as region ones
  • CPU recorded in region service classes

Difficult To Relate To Business Transactions

How IT transactions are wired together to form business transactions can be difficult to ascertain. In the example there are two business transactions – one in blue and one in green.

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:

• Business Transaction 1 (in blue) spawns two CICS transactions – which each pass through the TOR to separate AORs the one DB2.
• Business Transaction 2 (in green) spawns a single CICS transaction – which passes through the same middleware components. Possibly it uses the same transaction IDs as Business Transaction 1.

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

As I alluded to when discussing DDF, the CPU per CICS transaction can’t be gained from SMF 72 as the region Service Classes have the CPU and the transaction Service Classes the transaction rate.

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[5] 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:

• Make good use of report classes for transactions.

  For example, breaking out Mobile.

• Ensure report class transaction rates add up to the corresponding service class’s transaction rate.

  Unless you’re using Report Classes to aggregate Service Classes they should provide a useful breakdown of the Service Class transaction rate.

• Consider the technique I outlined to relate transactions to regions.

A couple of notes on implementation:

• It’s safe to introduce changes to the Report Class setup one step at a time; There is no impact on performance.
• If you’re tracking through time (and you should) changes to the Report Class (and Service Class, for that matter) setup are likely to introduce problems when comparing “before” to “after”. [6]

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.