Hi Michael,
A bit of a tough one.
That wait event can be quite ambiguous (perhaps we should improve it..).
It's basically a wait that is registered when are no slots left in an object memory pool.
The problem is we have many object memory pools (just a type of memory pool from ASE perspective) and the wait event itself isn't granular enough to give an indication of which object memory pool it is. There could be 30 or more possibilities from various 'usual' metdata descriptors, to sql text objects, lobs, all kinds of things.
Are there any other wait events alongside it that might give a clue? (even if they are not relevant in terms of time). Did you get an sp_monitorconfig 'all' output by any chance, see if any of the obvious stuff looks high?
I think the only time I recall someone reporting and resolving a high count of 157 wait events was with the audit queue, that uses a object memory pool.
A broad question was this process doing anything that may have caused vast amounts of audit events or anything else that may differ from your normal workload?
HTH,
Simon