Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
The first thing I would look at are the programs associated with this transaction. It could be that a plethora of TCB switches are going on between the L8 <---> QR TCB's, due to the use of non-threadsafe CICS commands or using the non-Threadsafe DSNCUEXT instead of the Threadsafe version DFHD2PXT.
Keep in mind that if program "A" is Threadsafe compliant and it CALLS (not Links-To) sub-program "B" and "B" is not-Threadsafe, then TCB switches could occur. CALLED sub-programs take on the characteristics of the CALLER, because a CALL is not recognized by CICS as an API.
However, having said this, there would have to be a significant number of TCB switches happening, as a TCB switch round-trip is about 4000 instructions, which in the grand scheme of things, is nothing nowadays.
Do you have TMON/CICS or Omegamon?
Both of these monitors log critical task-related information, which may assist you, such as a resource monopilizing the QR. Long browses of a file not defined to LSR (known as NSR) are notorious for this.
In TS 3.2, a PTF is avalable for making local VSAM Threadsafe. However, remote VSAM remains non-Threadsafe.
we used to have an average of 800 TCB switches before I made the transaction threadsafe, now we have an average of 8, a CICS trace confirmed. This transaction runs over a million times a day, so there were a lot of savings. Most of the switches are due to commits and VSAM
We do run a lot of batch during the day too. I should check which jobs were running when during these problem times. I'll also check the EXIT.