Anyhow, to answer the question...
There is nothing that you can do after the fact. The message is just saying that a session was blocked on a record lock for 1,800 seconds. It never got the lock and, as a result, the session ended. You know the USR number so, in theory, you could trace back through the .lg file and figure out who that was. You might try asking them what they were doing and seeing if that leads you to the code that had the problem (good luck!).
On the other hand... if this is occurring regularly (the original post says it has been going on for 3 days) then:
1) What changed? Was some new code released 3 days ago? Is someone using some option in the system that was never used before? Has there been a change in the data that might lead to longer processing times? etc, etc...
2) Try monitoring "blocked sessions". You can do this in PROMON: R&D, Status, Processes/Clients, Blocked Clients. But that's a bit of a PITA, I prefer ProTop
http://dbappraise.com.protop.html That should show sessions that are blocked waiting on record locks
before they time out. I wouldn't worry about any that wait less than 5 minutes at this point. You're looking for stuff that might timeout. Once you know who they are you can start drilling in to what they are waiting for and why. (ProTop will tell you what table and which RECID they are waiting on... PROMON cannot do that.)
2a) This is an "advanced topic" but if you are running 10.1C or higher you can also turn on client statement caching (in PROMON) and start tracing which line of code in what program is involved with each db access. If you combine that with observations of the blocked sessions you will have a much easier time getting to the bottom of the problem.
