Dirty READ problem, with several readers.

We've been using dirty reads for many years in various reports to improve speed, diminish lock requests, etc. Lately, we find that when we have several requests against the same info, that one or more processes lock up. Here are the symptoms: 1). The backends start accumulating CPU time at a higher rate than normal - yet they do NOT consume all the available CPU. 2). The front-ends are stuck with the following back-trace [confirmed both by core-dumping the processes involved, and by actively attaching with xdb the running proc]. 0 _sqpread + 0x00000084 (0, 0x40011344, 0x2, 0x2) 1 _sqgetint + 0x00000060 (0, 0, 0x2, 0x2) 2 _sqgetreturn + 0x000000c8 (0x400016b8, 0x68faa814, 0x40041e30, 0xffffffeb) 3 _iqopen + 0x0000045c (0x4000a740, 0x4, 0x1def3, 0x40011308) Of course, no CPU time is being consumed by the front-ends, even though they have work to do. Sometimes, by killing some of the processes incolved, we can get some work done before the remaining process locks up again. MY SPECULATION is that something in the dirty-read buffer management gets hosed up. tbstat -a output has been forwarded to support, but as far as I can make out, it doesn't show anything except that one process is waiting for a buffer owned by the other process, but that should have cleared when we killed the other process, and why was the other process holding the buffer and not releasing it? VERSIONS: HP 9000/870 on HP-UX 8.0; Informix 4.11.UC1 Online, with 2.10 ESQL. Thanks for any help. Standard discclaimers apply, Ihor Kinal att!trumpet!ijk