The session which burns CPU will have threads predominantly in "running" state.
It's very unlikely that single thread (session) will use 100% of ALL system's CPUs.
Quick look at the overall picture in real time can be observed with something like this:
onstat -g ath -r 1 | grep sqlexec | egrep 'Informix|running'
or, if CPU is consumed not by user sessions -
onstat -g ath -r 1 | egrep 'Informix|running'
Once you identify continuously running threads - you can trace these to sessions using output from "onstat -g ses 0" - and that will likely to have current SQL for that session too.
Any reason "onstat -g cpu" does not work for you as a starting point ?