Badly designed applications which put or get messages in syncpoint and then fail to commit or rollback are not good for the queue manager.
Eventually the log records needed to recover will almost fall out of the active logs. For many years MQ detects this, and moves all of the log records needed for recovery of this unit of work, into the current active log. This is additional work, and impacts logging, and needs CPU to move the data. It can also increase the restart time.
The queue manager detects this and give you a message
CSQJ160I MQPR CSQJLRUR Long-running UOW found URID=0000000012340000 Connection name=MQPRCHIN
Great – but what do you do with this?
You can use the command
DIS CONN(*) WHERE(QMURID,EQ,0000000012340000 ) ALL
This displays enough information to see what task is causing the problem.
If this is a channel, you get the channel and conname which should be enough to identify which is causing the problem.
Of course you want to change your automation so that when you get the CSQJ160I MQPR Long-running UOW found…
you issue the display command.
How do you display which UOW are active
for example
echo "dis conn(*) type(all) where(uowstate NE NONE )" | runmqsc QMA
or echo "dis conn(*) type(all) where(uowstti ne ' ' )" | runmqsc QMA |grep APPLTAG
I struggled with getting the WHERE clause to work with empty data for example
UOWSTTI( )
You have to specify (WHERE UOWSTTI EQ ‘ ‘) with a blank .
One thought on “What is this “long running UOW problem””