All Forums Database
Random_Thought 87 posts Joined 06/09
21 Sep 2009
TASM issues


Query on TASM. If we configure a group to have a MAXIMUM CPU utilisation of 60 Seconds, we would expect the query to migrate over to the next group when it reaches 60 Seconds.

Why then do we see queries running and consuming more than 60 seconds (sometimes up to 1 hours worth of CPUTIME) before migrating. We can see this in viewpoint, looking in DBQL only show the startingbands and ending bancds.

This is causing serious confusion to our TASM rules here, and we don't want to increase the concurrency of the group to allow more in as queries have a tendancy to migrate up through the groups, due to bad optimiser guessing incorrectly placing the queries in the short running query groups when they actully turn out to be long running queries. Therefore we have legitimate short running queries being help up by queries that should not be there.

anyone else seen this?


Random_Thought 87 posts Joined 06/09
23 Sep 2009


i have solved this issue. TASM will check each job at the end of each step, or at the delaytime setting set in the TASM manager. Ours was set high, and only checking every 10 minutes.

This meant that long running steps may run for 10 minutes unchecked consuming loads of CPU and blocking the queue for others.


monisiqbal 119 posts Joined 07/09
20 Dec 2009

It takes some time to absorb TASM :-)

Vador 36 posts Joined 08/07
21 Dec 2009

In which version of TD are you ?
how many period have you defined ?
If you have serveral regulation periods, you must specify degradation rules of workloads for each period. I observe the same behavior of TASM in a V2R6.2 system and solve the problem by defining workload change rules for each period of time.

You must sign in to leave a comment.