This did happen to us, but not for a long time. Long enough ago that I don't remember what version of XPP or Red Hat EL (well probably XPP 8.something and EL 5.something). And probably OpenText Exceed v14. In fact, this brings back a memory of where, every morning, part of the daily routine was to check for these rogue processes and kill them. I even wrote a Unix alias command called "pstimecpu" to sort the ps listing by CPU time to make them easy to find.

Sorry, this alias is nastier than I remember it being!   Surprised I didn't win some kind of Bad Perl award.

(csh) 

ps -efww | perl -p -e 's/ (\d\d):(\d\d) / ${1}0$2 /g; s/ (\d\d):(\d\d):(\d\d) / 000${1}0${2}0$3 /g; s/ (\d\d)-(\d\d):(\d\d):(\d\d) / ${1}0${2}0${3}0$4 /g; s/ (\d)-(\d\d):(\d\d):(\d\d) / 0${1}0${2}0${3}0$4 /g;' | sort -n -k1.40,1.50 -k1.25,1.29 | perl -p -e 's/ (\d\d)0(\d\d) ([\?p])/ ${1}:$2 $3/g; s/ 000(\d\d)0(\d\d)0(\d\d) /    ${1}:${2}:$3 /g; s/ (\d\d)0(\d\d)0(\d\d)0(\d\d) / ${1}-${2}:${3}:$4 /g;'

One other source of runaway CPU at the same time was batch composition processes that ran away for one reason or another. I don't remember the exact details but maybe a pickup that couldn't place and it sort of went into a loop without exiting. Too long ago.

Bill,

You didn't say what release of XPP you are using?

What was the user doing in the XYVIEW when it becomes 100% CPU bound?

You only said the user was "viewing" a DIV, but was the user actually doing a compose in the xyview?