Ude i SDSF eller SYSVIEW kan du se, hvilke address spaces, der bruger mest CPU. Inde i maven på et address space kan der blive udført en masse forskellige tasks. Det kan SDSF eller SYVIEW ikke umiddelbart vise (SYSVIEW har en funktion, der viser TCB strukturen, men ikke hvor i address spacet CPU forbruget er). Der findes selvfølgelig monitorer (typisk dyre, som kun sysprogrammører har adgang til), der kan fortælle mere. Det gælder især for produkter som CICS og DB2.

Hvis nu du i SDSF eller SYSVIEW kan se, at en CICS bruger rigtig meget CPU og bliver ved med det, så kan du faktisk blive klogere på, hvad der foregår med CICS transaktionen CEMT I TASK. Log på den CICS, der bruger meget CPU. Hvis du ikke kan logge på, så er det på tide at ringe til driftsovervågningen eller en CICS systemprogrammør og fortælle dem, at der er noget helt galt med den pågældende CICS, så den kan blive genstartet.

Når du er blevet logget på, så udfør en CEMT I TASK. Nu får du vist alle de tasks, der bliver eksekveret på den pågældende CICS lige nu. Det kan være et uoverskuelig stort antal og CEMT brugerinterfacet er ikke vildt brugervenligt. Det kan der heldigvis gøres noget ved. Brug i stedet CEMT I TASK RUN. Denne transaktion viser kun de tasks, der rent faktisk bruger CPU lige nu. Du gentager transaktionen ved at trykke Enter. Der vil altid være mindst et task, der bruger CPU lige nu, nemlig din egen CEMT transaktion. Det kan godt være, at din CEMT transaktion er det eneste task, der bruger CPU, og så er der jo ikke meget at se. Det kan faktisk godt være tilfældet, selv om CICS'en i følge SDSF eller SYSVIEW fortsat bruger en masse CPU. Det er desværre kun selve transaktionerne, som CEMT I TASK RUN rapporterer på. Interne CICS operationer (såsom at tage CICS dumps) kan du ikke se med CEMT I TASK.

Hvis det samme task (ikke din CEMT) bliver ved med at dukke op, så har du sandsynligvis fundet synderen. For hvert task vises to linier og i disse linier kan du både se, hvilken transaktion det drejer sig om (TRANS(XXXX)) og hvilken user (USE(YYYY)). Du kan faktisk også se, om det er et loop, eller en ny eksekvering af den samme transaktion. Du skal for hver gang, du trykker Enter se, om værdien af feltet UOW(ZZZZ) skifter værdi. Hvis det gør, så er det enten et nyt task med samme transaktion, eller også har task'et udstedt en EXEC CICS SYNCPOINT, men hvis det ikke skifter værdi, så er det et task, der looper.

Du har faktisk mulighed for at skyde et task ned (hvis du har autorisation til det, hvilket er meget sandsynligt, hvis du har adgang til at udføre CEMT transaktionen). Ude til højre lige til højre for det sidste felt i den første linie for det task, du vil skyde ned, kan du skrive P for Purge og trykke Enter. Hvis det pågældende task forsvinder fra din gentagne eksekvering af CEMT I TASK RUN, så har du med stor sandsynlighed fået stoppet task'et. Hvis du også kan konstatere, at CPU forbruget er faldet i SDSF eller SYSVIEW, så er operationen en success. Det er dog ikke sikkert, at det sker. Så kan du prøve med FP i stedet for P. FP står for Force Purge. Med FP kan du i ekstreme tilfælde risikere at rive hele CICS'en ned eller gøre den ustabil så pas på, især hvis du kommer til at skrive FP ud for det forkerte task.

Hvis du overvejer at bruge Purge eller Force Purge på et task, som du ikke umiddelbart har noget med at gøre, så husk for en god ordens skyld at orientere den ansvarlige for den pågældende transaktionskode om, at der er et problem, og at du har tænkt dig at stoppe task'et.