(Originally posted 2012-12-11.)
There was a time before blogging đŸ™‚ and what I’m about to talk about is something I used to explain quite often back in those days.
Reminded by a current customer situation – and needing to explain it again – I thought it time to do it this way.
(Here I’m presenting a simplified view, but one that covers the salient features that might help you.)
The CICS / DB2 Connection code provides a number of possibilities for optimisation, one of which is Thread Reuse. This post won’t discuss the mechanics of this in any depth but aims to explain the effect of it on DB2 instrumentation – in fact DB2 Accounting Trace (SMF 101).
Consider the following diagram, with time flowing from left to right…
I’ve shown the two scenarios one above the other. Blue bars represent periods of Class 1 elapsed time. Green bars periods of Class 2 elapsed time. Notice how the blue bars are unbroken but the green ones can have gaps: Because Class 2 represents the time actually in DB2 there can be time between “stanzas”. (But SMF 101 doesn’t record the timings of the gaps – just two numbers which when subtracted give you the total time.)
The diagram shows three CICS transactions running one after the other, with Thread Reuse and without:
- In the case without Thread Reuse three threads have to be created and terminated, one after the other. This is an expensive process, which is why Thread Reuse is used.
- In the Thread Reuse case the thread is reused twice, avoid the thread management lifecycle.
The reason for discussing this is that with Thread Reuse DB2 timings in Accounting Trace (SMF 101) work a little differently.
(One thing that remains unchanged is the relationship between Class 2 elapsed time, Class 2 CPU time, the Class 3 wait components, and what’s not accounted for but still part of Class 2 elapsed time. So I won’t discuss those here. What’s also not changed is Class 1 CPU time – so computing Non-Class 2 CPU time is the same – Class 1 CPU minus Class 2 CPU.)
The most important thing to notice in the diagram is the difference in Class 1 time behaviour:
Instead of – as with the non-reuse case – starting and ending at the transaction boundaries, Class 1 time now ends when the next transaction that uses the thread starts. (And that’s when the DB2 Accounting Trace (SMF 101) record is produced.) This means, as you can see, a lot of the Class 1 elapsed time has nothing to do with executing the transaction. Obviously, under these circumstances, you can’t use Class 1 elapsed time for much.
An obvious question is “when can you trust Class 1 time in a CICS environment?”
Fortunately the answer is quite simple: The value of a field in the 101 record (QWACRINV “Reason For Invoking Accounting”) determines whether you can.
If QWACRINV has a value signifying either “New User Signon” or “Same User Signon” you know the thread was reused. Otherwise – probably with the value signifying “Deallocation” – you know it wasn’t.
(If you wanted to know how effective Thread Reuse was you’d calculate – as my code does – some ratio relating these two Signon values to Deallocation.)
In the case I’m dealing with some of the transactions in the CICS region use Thread Reuse and some don’t. For those that do I’m discarding the Class 1 elapsed time and for the rest I’m using it to give some understanding of the timings outside of DB2.
I have to be very careful when I say “some understanding of the timings outside of DB2” – but that’s really a topic of a completely different discussion, involving things like Unit Of Work Identifiers. (CICS PA does a nice job of bringing it all together – to the extent it can be.)
For now I wanted to explain why I’m careful in handling DB2 Class 1 Accounting elapsed times for CICS transactions. And to socialise a briefing for friends of mine. I had honestly aspired to be brief – and it’s frightening to me how much detail I’ve left out – but brevity was not to be.
Mainframe, Performance, Topics 