Page 1 of 1

Avoiding DISPATCHER condition

PostPosted: Fri Mar 30, 2012 2:22 pm
by jaggz
Hello All,

We all knew in CICS region a transaction runs in DISPATCHER condition when the task is waiting to get dispatched, eg. to run on QR TCB. The problems we are seeing is likely that some tasks are monopolizing the QR TCB and therefore building up a queue of waiting tasks. Some reasons can be too high value for run away tasks (i.e. something is looping), too much work (QR TCB runs 100%), CICS does not get enough CPU.

For our CICS test region we dont have any TOOLS to monitor the Transaction which consumes more CPU. Mostly the DISPATCHER condition occurs during CICS DB2 load activity.

Could anyone please throw some light to avoid the dispatcher condition to occur.

Jaggz

Re: Avoiding DISPATCHER condition

PostPosted: Fri Mar 30, 2012 2:51 pm
by Monitor

Re: Avoiding DISPATCHER condition

PostPosted: Fri Mar 30, 2012 3:17 pm
by jaggz
The ICVR values are not helpful for the program which are running in Loop. ICVR is reset everytime and CICS is not able to detect the Loop.

Re: Avoiding DISPATCHER condition

PostPosted: Fri Mar 30, 2012 3:31 pm
by jaggz
Hello,

I am looking a way to purge the yielding loops.

Re: Avoiding DISPATCHER condition

PostPosted: Fri Mar 30, 2012 3:38 pm
by BillyBoyo
Surely you don't get many "loops" in your CICS, even in development?

When it happens, the person who pressed enter (or emulated pressing enter) knows about it. Why not ask anyone to give you a call when they set off a loop. Make some sort of "forfeit" for anyone who sets off a loop and doesn't tell you.

Re: Avoiding DISPATCHER condition

PostPosted: Sat Mar 31, 2012 2:41 pm
by Monitor
Why not enable Auxiliary trace for a while until the problem occurs. You say the ICVR doesnt work, which meens that the task causing the problem issues CICS-commands, as the timer is reset when you are back in your program again.
An analysis of the trace output could help you find the "looping" task/program.