Does this DSNR035I message has anything to do with BIND parameters? This is because, after making a few changes to a program, I'm keep on getting this message.
Also, the programs that normally executes in 10 minutes, consumes nearly an hour after the implementation of new changes.
Should I check for cursors to corner this DSNR035I message? Are there any specific SQL code present, if mishandled, will raise this message?
DSNR035I csect-name WARNING - UNCOMMITTED UR AFTER nn CHECKPOINTS -
CORRELATION NAME = xxxxxxxxxxxx CONNECTION ID = yyyyyyyy LUWID
= logical-unit-of-work-id=token PLAN NAME = xxxxxxxx AUTHID =
xxxxxxx END USER ID = xxxxxxxx TRANSACTION NAME = xxxxxxxx
WORKSTATION NAME = xxxxxxxx
Explanation: This message indicates that during checkpoint, DB2
encountered an uncommitted UR that has an INFLIGHT status.
The value nn is cumulative, and it indicates the number of checkpoints
taken since the beginning of the UR. CORRELATION name, CONNECTION ID, and
LUWID together identify a thread associated with the UR. If the LUWID is
an '*', it indicates that the thread originated at this site. token is a
unique token number associated with the LUWID. PLAN NAME and AUTHID
further identify the thread associated with the UR. If the thread was
created with client End User information, the End User's ID, TRANSACTION
NAME, and WORKSTATION NAME will be displayed. Otherwise, these fields will
contain an '*'.
System Action: DB2 continues processing. If statistics class 3 is turned
on, IFCID 0313 is written.
System Programmer Response: Consult with the application programmer to
determine if this is a problem UR. See Part 4 (Volume 1) of DB2
Administration Guide for more information about problems caused by
uncommitted URs. If the UR is caused by an application program, you can
use CANCEL THREAD to delete the UR, if necessary. If an uncommitted UR is
deleted, DB2 will undo the changes. The amount of time required for this
process depends on the amount of work done by the UR.
Programmer Response: Ensure that the application commits frequently
enough, or consult with your DB2 administrator about decreasing the
frequency of the check.
.jpg)
