What is this “long running UOW problem”

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”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s