MQ Batch CPU

(Originally posted 2018-09-23.)

This post is an update to Batch DB2 And MQ The Easy Way, which I wrote back in 2016.

There’s nothing wrong with what I wrote then – but there’s something extra I want to impart now.

In that post I said you can answer the question “What are the big CPU DB2 jobs accessing this DB2 subsystem?” If you substitute “MQ” for “DB2” you can answer the question “What are the big CPU MQ jobs accessing this MQ subsystem?” For MQ, always, you can go further – and that is what this post is all about. I’ll answer the question “why can’t you go further with DB2?” In a minute. But first things first.

A Further Question For MQ

The question I realised you can ask is “How much MQ CPU is there in this job step?” It’s subtly (and I think usefully) different from the question “How much CPU is there in this MQ job step?” We’ll see why this might matter in a minute.

In the SMF 30 Usage Data Section – as described in Batch DB2 And MQ The Easy Way – you can see which MQ subsystem the job step attaches to. But here’s the extra bit: You can also see the CPU in MQ the step uses.

If you subtract the MQ CPU from the Step CPU you, obviously, get the non-MQ CPU. So you can tell if a step is primarily MQ or not. This is helpful in working out where the real action is in a job step that accesses MQ. What you can’t tell this way is how much elapsed time is MQ related. For that you need the SMF 116 records. And these are rare.

I revisited this because we were doing a batch study when we spotted that one of the steps accessed MQ. There was a Usage Data Section that pointed – with the Product Qualifier – at a specific MQ subsystem.

It got my interest to the point I revisited our code and added some more columns to the table, including “Not Usage TCB Time”. Hence my comment above. I analysed this customer’s batch jobs accessing MQ. For some jobs – including the ones we spotted – the MQ CPU is over 90% of the step’s CPU. So it’s clear the step is essentially an MQ step. For others there is a considerable amount of non-MQ CPU, so this step is doing something more intensive than just putting messages on a queue or taking them off a queue.

I think this is a useful insight – whether a step is really “just MQ” or not.

Why Can’t We Do This For DB2?

DB2 has a “NO89” switch at the subsystem level. The impact of this is that DB2 won’t record TCB time in SMF 30 – if the “NO89” option is taken. To be clear, you still get step TCB and SRB times, just not DB2 TCB and SRB times in the Usage Data Section.

I have yet to see a customer that has enabled DB2 to record its CPU in the Usage Data Section. So I never see DB2 TCB in the Usage Data Section.

Of course, if you want to see DB2 TCB at a step level, you can get it in the DB2 Accounting Trace record (SMF 101). In fact you can get more detail – at the Package / Program level – if you turn on Package Accounting in DB2.

Conclusion

It’s nice to be able to look inside a step, particularly one where the elapsed time is hard to explain. For MQ you can definitely do it – at least for the CPU component – with SMF 30 and the MQ Usage Data Section. And the key thing is you can tell an intensively-MQ step from a not-so-MQish one. Another step forwards, if you’ll pardon the pun. 🙂