In SYSVIEW or SDSF you are able to see the address spaces consuming all the CPU. Looking into an address space there might be a lot of different tasks running. Neither SDSF nor SYSVIEW are able to show CPU consumption on individual tasks running in the same address space (SYSVIEW has a function to view the TCB structure, but not the CPU consumption on those TCBs). There are of course performance monitors available that can tell you more, but they are normally quite expensive and restricted to be used only by systems programmers. Especially for CICS and DB2 there are a wide range of different performance monitors available.

Suppose you discover using SDSF or SYSVIEW that a CICS address space is consuming af lot of CPU and continues to do so, you can actually investigate the situation using the CICS transaction CEMT I TASK. Log on to the CICS using a lot of CPU. If you are not able to log on it is time to call operations or a CICS systems programmer and tell them that there is something wrong with that CICS system. Maybe it needs to be restarted.

When you have been logged on then perform a CEMT I TASK. The output will show you all the tasks being executed right now on the CICS you have logged on to. There might be an overwhelming number of tasks and the CEMT user interface is not helping. Fortunately you can do someshing about it. Use instead CEMT I TASK RUN. This transaction only shows you the tasks actually consuming CPU right now. You repeat the transaction by pressing Enter. There will always be at least one task using CPU right now and that is your own CEMT transaction. It might be the case that your CEMT transaction is the only task using CPU and then there is not much to see. This is actually possible even though the CICS address space according to SDSF or SYSVIEW is still using a lot of CPU. Unfortunately CEMT I TASK RUN only reports on the CICS transactions. Internal CICS operation (like taking a CICS dump) you are not able to see using CEMT I TASK.

If the same task (not your CEMT) keeps popping up you have most likely found the transaction using all the CPU. For each task two lines are displayed and in these lines you are able to see which transaction it is (TRANS(XXXX)) and which user (USE(YYYY)). Actually you can also see if it is a loop or a new execution of the same transaction. You do this by checking whether the value of the field UOW(ZZZZ) changes for each time you press Enter. If the value changes it is either a new task running the same transaction or the task has issued an EXEC CICS SYNCPOINT, but if the value does not change the task is most likely looping (or very bad designed).

Actually you are able to cancel a task (if you are authorised which is very likely if you have access to execute the CEMT transaction). On the first line of the task you want to cancel there is an empty field to the right of the rightmost field containing a value. In this empty field you can type in a P for Purge and press Enter. If the task has disappeared when you repeat your CEMT I TASK RUN you most likely succeeded in cancelling the task. If you also can see that the CPU consumption has dropped in SDSF or SYSVIEW your operation was a success. Maybe you are not that lucky. Then you can try using FP instead of P. FP stands for Force Purge. Using FP you might risk bringing the CICS system down or making it unstable, so please watch out especially if you use FP on the wrong task.

If you consider using Purge or Force Purge on a task that normally is "none of your business", please remember to contact the person or persons responsible for the transaction causing the excessive CPU consumption. Tell them there is something utterly wrong and that you are ready to help them by cancelling the task.