"It is my understanding that you can determine how busy the QR-TCB is by dividing the accumulated CPU time for this TCB by the accumulated time the TCB was dispatched.
"If this percent busy is at 80% or greater, will there be performance
The rule of thumb still applies: If the main CICS QR TCB gets too busy then performance will suffer.
If you were using compiled Java (which used the H8 TCBs) and now changed into CTS 2.2 native Java using a JVM (J8 TCB) then this does not have an affect on QR usage.
If you are on CTS 2.2 then some of the processing that was done on the QR TCB (or its subtasks) is done on L8 TCBs (mainly DB2 access). This means that there will be a (small) utilization improvement (i.e., CPU time on the QR TCB reduces) as the QR TCB will be less busy.
Nevertheless, I would not consider that this utilization reduction would be significant for sizing purposes when compared with all the other things that go into capacity planning.
Where you can reduce the QR TCB time for CTS 2.2 is by ensuring your CICS regions are threadsafe and then changing your applications so that all DB2 accesses are next to each other (without any intervening XC calls). These applications can be RDO configured so that the swap back to QR after DB2 activity on L8 does not occur (staing on the L8) so reducing the load on the QR TCB to the benefit of everything else.
If you have a look on the CICS Web site, I have put up a doc on 1.3->2.2
migration which goes into this.
This was first published in January 2003