threadsafe transaction waiting on QR TCB?

xsray · New User Joined: 16 Sep 2008 Posts: 19 Location: illinois

We have a threadsafe transaction where the average time for completion is 250 milliseconds.

There are times when the transaction takes over a minute to run. I'm trying to track down where the slowdown is.

At first we thought it was a DB2 problem, but after much monitoring, DB2 was ruled out as the problem.

I then started looking at the threadsafe programs and could not find a problem with them.

I was able to get a SMF report from record type 110. The systems programmer cannot tell me what the following fields mean and I am out of my element on this. I did try reading the manual.

How do I interpret this data? We are not using TCP/IP, we use SNA?

task dispatch time - TASDSPTM = 01:04.551
tcpip init time - TCPINITM = 01:04.544
TCP Write Time - TCPWRITM = 01:04.543
- TASCPUTM = 00:02.049

Bill O'Boyle · Posted: Thu Jul 15, 2010 8:56 pm

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.

Bill

xsray · New User Joined: 16 Sep 2008 Posts: 19 Location: illinois

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
(TS 3.1).

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.