Has anyone seen this before?

The problem is that during a period of multiple messages stacked on a queue that is set to trigger FIRST, the IPPROCS value does not reflect the triggered process having the queue open. In other words the open for input count stays at zero. The result is that several trigger msgs get created causing several parallel processes to begin running.  The IPPROCS value is never updated from 0 until the queues CURDEPTH goes to 0.  At that point IPPROCS is updated showing the then current number of active processes with the queue open. 

The triggered process in this case is designed to open the queue, get a message, process the message and get again until the queue is empty then close the queue and terminate.  All gets are with a 5 second wait.

 

Our understanding is that this is not normal can anyone explain what we are seeing?

 

Dan Reinhart        

Ameren Services

 

Reply via email to