Need a field (attribute), of the TASK resource table, which allows me to have the CPU time of a "THREADSAFE" task.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

We have no plans to change the way dispatcher accumulates cpu time. This requirement is being rejected.
Perhaps a better approach would be for DB2 to consider providing support for RLF for static SQL like they do for today for dynamic SQL. I know they have requirements for this in the past.

It is difficult, for applications, to argue at the level of the SQL number or at the level of the performance of a SQL request. Because every application has its specificity.
It is difficult to set an upper limit on the number of SQL request and apply it to the whole of the transactions (a threshold of 1000 EXEC SQL may seem like a good limit for most of the transactions but it might fall on cases with fewer requests and which can consume a lot of CPU).
To intervene at the level DB2 seems to me not simple because we can put thresholds on SQL requests or even on package DB2 but if a transaction calls several SQL orders or DB2 packages (Which individually consumes very little CPU) we can find ourselves in front of a very consumer transaction.
It is the agglomeration of these two parameters (number of SQL query and the performance of these SQL queries) which will allow me to say in a general way that the transactions consume a lot of CPU.
My purpose, it is to purge automatically any abnormally consumer tasks of CPU by means of CICS tools (RTA, events, policy, …) to avoid any problems of performances CICS (as I can make it with the Mainview for CICS killer).

P.S. : I did not try the POLICY, because they do not respond completely to my need. (cputime policy in CICS TS 5.1 won't help as it will just monitor the
same field that won't get updated until we come off the TCB.).

The CICS Dispatcher is a non-preemptible design and therefore in order for a transactions CPU time to get accumulated (on whatever CICS mnaged TCB, QR, L8, etc, ...) the transaction must give up control to the CICS dispatcher. This normally occurs whenever a transaction does some sort of CICS dispatcher wait or suspend (or change CICS TCB mode in the scenario described) but in the case where an L8 or other open TCB is used and depending in the EXEC commands that are used it may well be the case that CICS does not get the opportunity to accumulate any of the CPU time used until the task actually finishes. In this type of scenario I would suggest that perhaps using the number of DB2 requests as the trigger rather than CPU time might be a more useful unusual situation or loop detection indicator.
With the introduction of Policy thresholds for applications and platforms in CICS TS V5 various threshold conditions are now available, including the number of EXEC SQL requests, that can be defined to manage the behaviour of user tasks within CICS regions.

Have you consideredusing a threshold policy?

Rather than a loop, If its the case that a badly formed SQL command is consuming too much cpu in DB2, then we'd look to DB2 for a solution for that. Certainly in the past they have had customer requests to extending their Resource Limiting feature (RLF) to static SQL, because at the moment in only applies to dynamic SQL.