I notice you're on nix ... Is the piece of code that writes invoked via an EXECUTE or PERFORM from the code that did the original READU?
I wouldn't expect it to on doze, but on Unix that *might* change the execution environment enough to cause a problem... (grasping at straws to see if it gives you any more ideas...) Cheers, Wol -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of doug chanco Sent: 01 July 2008 15:03 To: [email protected] Subject: [U2] locking question hey all, has anybody run across/seen an issue where a process sets a lock via READU and then when it tries to write back the record cannot because the record is locked but somehow "lost" the fact that the process trying to write the record is the process that created the lock? I am not sure if this is even possible but we at are at a loss as to whats causing this lockup (which does not occur regularly but enough that its causing us concerns with our "busy season" coming around) We had a lock up last night that LIST.READU EVERY showed that that a process was holding a lock and that the same process was failing on a write (in a program) and 'stuck' (yes we have old old old old old code that does not believe in a failure clause or the handling of a write failure). Once I cleared the lock the process continued on its merry way ....... Now the obvious things I checked 1. that there were no other users logged in as that particular user (yes they sometimes login multiple times with the same user but we are forcing them to change that) 2. the PID's were indeed the same system info: aix 5.2.6 RELLEVEL 001 X 002 10.1.7 003 PICK 004 PICK.FORMAT 005 10.1.7 any thoughts/suggestions/ideas/etc ...... are welcomed! thanks everyone dougc ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
