disconnect use and lock release

[ymjamal]

Hi,
We need to disconnet a user that is locking record(s) needed by a batch process.
Using the _UserLock table we identify the user that is locking the record, as dbadmin we disconnect the user using _proshut, the user connection disappears OK, but the lock reamins in _UserLock table until the user aborts the transaction.
Note: The user may be away from the terminal. (I know there a is design shortcoming,. It should not lock until ready to commit, but this a purchased software that we can not affort to rewrite).

My question is how can we release the lock from a disconnect user.
We can not afford to wait for wdog because the batch cannot wait more that few minutes after we diconnect the locking user.
Tia

 

[Cringer]

I've not tried, but why not give promon a try. You should be able to kill a user in there.

 

[ymjamal]

I tried. Same result. I guess promon option 8 uses proshut.
The user is shown disconnected by lock is not released until the locking users aborts.

 

[TomBascom]

That is correct.

The lock will not be released until the disconnect completes. Disconnecting a user means that you are aborting and rolling back any transactions that that user had active. The record lock in question is probably scoped outside the transaction being undone and, therefore, cannot be released until the whole disconnect process completes and the user is completely aborted.

There is no "release a lock" function at the database level that operates any differently. Nor should there be. It would violate transactional integrity.

 

[ymjamal]

Thanks Tom,
What you say is helpful.
My problem may be transaction scopping.
This is the piece of code that I tried to use for testing.
Do you see anything that can help me?
This is the offending session:
[FONT=r_ansi]F[/FONT][FONT=r_ansi]ile Edit Search Buffer Compile Tools Help[/FONT]
[FONT=r_symbol],,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,[/FONT]
[FONT=r_ansi]find first gen_loc[/FONT]
[FONT=r_ansi]where gen_loc.entity = ""[/FONT]
[FONT=r_ansi]and gen_loc.loc = "01" no-lock no-error.[/FONT]
[FONT=r_ansi]if available gen_loc then do transaction:[/FONT]
[FONT=r_ansi]find current gen_loc exclusive-lock no-error.[/FONT]
[FONT=r_ansi]if not available gen_loc then[/FONT]
[FONT=r_ansi]message "???" view-as alert-box.[/FONT]
[FONT=r_ansi]else[/FONT]
[FONT=r_ansi]update gen_loc.add1.[/FONT]
[FONT=r_ansi]/* and the user leaves at this point */[/FONT]
[FONT=r_ansi]end.[/FONT]

[FONT=r_ansi]Program is left in this status, i.e. prompting for add1:[/FONT]
[FONT=r_symbol]R,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,T[/FONT]
[FONT=r_symbol].[/FONT][FONT=r_ansi]Add1 [/FONT][FONT=r_symbol].[/FONT]
[FONT=r_symbol].,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,.[/FONT]
[FONT=r_symbol].[/FONT][FONT=r_ansi]PRINCE GEORGE SAWMILL [/FONT][FONT=r_symbol].[/FONT]
[FONT=r_symbol]F,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,G[/FONT]


This is promon log while the transaction is active:

[FONT=r_ansi]OpenEdge MONITOR Release 10[/FONT]

[FONT=r_ansi]Database: /u1/ltrack[/FONT]

[FONT=r_ansi]1. User Control[/FONT]
[FONT=r_ansi]2. Locking and Waiting Statistics[/FONT]
[FONT=r_ansi]3. Block Access[/FONT]
[FONT=r_ansi]4. Record Locking Table[/FONT]
[FONT=r_ansi]5. Activity[/FONT]
[FONT=r_ansi]6. Shared Resources[/FONT]
[FONT=r_ansi]7. Database Status[/FONT]
[FONT=r_ansi]8. Shut Down Database[/FONT]

[FONT=r_ansi]R&D. Advanced options[/FONT]
[FONT=r_ansi]T. 2PC Transactions Control[/FONT]
[FONT=r_ansi]L. Resolve 2PC Limbo Transactions[/FONT]
[FONT=r_ansi]C. 2PC Coordinator Information[/FONT]

[FONT=r_ansi]J. Resolve JTA Transactions[/FONT]

[FONT=r_ansi]M. Modify Defaults[/FONT]
[FONT=r_ansi]Q. Quit[/FONT]

[FONT=r_ansi]Enter your selection: T[/FONT]

[FONT=r_ansi]1. Display all entries[/FONT]
[FONT=r_ansi]2. Match a user number[/FONT]
[FONT=r_ansi]3. Match a range of user numbers[/FONT]

[FONT=r_ansi]Q. Return to main menu[/FONT]

[FONT=r_ansi]Enter your selection: 1[/FONT]


[FONT=r_ansi]Transaction Control:[/FONT]
[FONT=r_ansi]Usr Name Trans Login Time R-comm? Limbo? Crd? Coord Crd-task[/FONT]
[FONT=r_ansi]14 jamaly 1222640510 11/01/11 15:33 no no no 0 [/FONT]

[FONT=r_ansi]RETURN - repeat, U - continue uninterrupted, Q - quit: Q[/FONT]


[FONT=r_ansi]OpenEdge MONITOR Release 10[/FONT]

[FONT=r_ansi]Database: /u1/ltrack[/FONT]

[FONT=r_ansi]1. User Control[/FONT]
[FONT=r_ansi]2. Locking and Waiting Statistics[/FONT]
[FONT=r_ansi]3. Block Access[/FONT]
[FONT=r_ansi]4. Record Locking Table[/FONT]
[FONT=r_ansi]5. Activity[/FONT]
[FONT=r_ansi]6. Shared Resources[/FONT]
[FONT=r_ansi]7. Database Status[/FONT]
[FONT=r_ansi]8. Shut Down Database[/FONT]

[FONT=r_ansi]R&D. Advanced options[/FONT]
[FONT=r_ansi]T. 2PC Transactions Control[/FONT]
[FONT=r_ansi]L. Resolve 2PC Limbo Transactions[/FONT]
[FONT=r_ansi]C. 2PC Coordinator Information[/FONT]

[FONT=r_ansi]J. Resolve JTA Transactions[/FONT]

[FONT=r_ansi]M. Modify Defaults[/FONT]
[FONT=r_ansi]Q. Quit[/FONT]

[FONT=r_ansi]Enter your selection: 8[/FONT]
[FONT=r_ansi]usr pid time of login user id tty Limbo?[/FONT]
[FONT=r_ansi]5 319 Fri Aug 26 14:10:49 2011 APW no[/FONT]
[FONT=r_ansi]6 323 Fri Aug 26 14:10:50 2011 APW no[/FONT]
[FONT=r_ansi]7 331 Fri Aug 26 14:10:52 2011 BIW no[/FONT]
[FONT=r_ansi]8 337 Fri Aug 26 14:10:54 2011 WDOG no[/FONT]
[FONT=r_ansi]9 378 Fri Aug 26 14:10:56 2011 BATCH batch no[/FONT]
[FONT=r_ansi]10 3119 Fri Aug 26 14:41:13 2011 FINISHER batch no[/FONT]
[FONT=r_ansi]11 26200 Tue Nov 1 12:50:38 2011 jamali /dev/pts/td no[/FONT]
[FONT=r_ansi]12 20293 Tue Nov 1 08:54:48 2011 rossif /dev/pts/ta no[/FONT]
[FONT=r_ansi]13 14722 Tue Nov 1 10:23:36 2011 jamaly /dev/pts/tb no[/FONT]
[FONT=r_ansi]14 12645 Tue Nov 1 15:33:35 2011 jamaly /dev/pts/tg no[/FONT]
[FONT=r_ansi]15 23255 Tue Nov 1 09:06:49 2011 EWRAPPER batch no[/FONT]
[FONT=r_ansi]16 21564 Tue Nov 1 14:19:57 2011 jamali /dev/pts/th no[/FONT]

[FONT=r_ansi]1 Disconnect a User [/FONT]
[FONT=r_ansi]2 Unconditional Shutdown[/FONT]
[FONT=r_ansi]3 Emergency Shutdown (Kill All)[/FONT]
[FONT=r_ansi]x Exit[/FONT]

[FONT=r_ansi]Enter choice> 1[/FONT]

[FONT=r_ansi]Enter the user number which is to be disconnected: 14[/FONT]
[FONT=r_ansi]User 14 disconnect initiated. (6796)[/FONT]
[FONT=r_ansi]usr pid time of login user id tty Limbo?[/FONT]
[FONT=r_ansi]5 319 Fri Aug 26 14:10:49 2011 APW no[/FONT]
[FONT=r_ansi]6 323 Fri Aug 26 14:10:50 2011 APW no[/FONT]
[FONT=r_ansi]7 331 Fri Aug 26 14:10:52 2011 BIW no[/FONT]
[FONT=r_ansi]8 337 Fri Aug 26 14:10:54 2011 WDOG no[/FONT]
[FONT=r_ansi]9 378 Fri Aug 26 14:10:56 2011 BATCH batch no[/FONT]
[FONT=r_ansi]10 3119 Fri Aug 26 14:41:13 2011 FINISHER batch no[/FONT]
[FONT=r_ansi]11 26200 Tue Nov 1 12:50:38 2011 jamali /dev/pts/td no[/FONT]
[FONT=r_ansi]12 20293 Tue Nov 1 08:54:48 2011 rossif /dev/pts/ta no[/FONT]
[FONT=r_ansi]13 14722 Tue Nov 1 10:23:36 2011 jamaly /dev/pts/tb no[/FONT]
[FONT=r_ansi]15 23255 Tue Nov 1 09:06:49 2011 EWRAPPER batch no[/FONT]
[FONT=r_ansi]16 21564 Tue Nov 1 14:19:57 2011 jamali /dev/pts/th no[/FONT]

[FONT=r_ansi]1 Disconnect a User [/FONT]
[FONT=r_ansi]2 Unconditional Shutdown[/FONT]
[FONT=r_ansi]3 Emergency Shutdown (Kill All)[/FONT]
[FONT=r_ansi]x Exit[/FONT]

[FONT=r_ansi]Enter choice> x[/FONT]


[FONT=r_ansi]OpenEdge MONITOR Release 10[/FONT]

[FONT=r_ansi]Database: /u1/ltrack[/FONT]

[FONT=r_ansi]1. User Control[/FONT]
[FONT=r_ansi]2. Locking and Waiting Statistics[/FONT]
[FONT=r_ansi]3. Block Access[/FONT]
[FONT=r_ansi]4. Record Locking Table[/FONT]
[FONT=r_ansi]5. Activity[/FONT]
[FONT=r_ansi]6. Shared Resources[/FONT]
[FONT=r_ansi]7. Database Status[/FONT]
[FONT=r_ansi]8. Shut Down Database[/FONT]

[FONT=r_ansi]R&D. Advanced options[/FONT]
[FONT=r_ansi]T. 2PC Transactions Control[/FONT]
[FONT=r_ansi]L. Resolve 2PC Limbo Transactions[/FONT]
[FONT=r_ansi]C. 2PC Coordinator Information[/FONT]

[FONT=r_ansi]J. Resolve JTA Transactions[/FONT]

[FONT=r_ansi]M. Modify Defaults[/FONT]
[FONT=r_ansi]Q. Quit[/FONT]

[FONT=r_ansi]Enter your selection: t[/FONT]

[FONT=r_ansi]1. Display all entries[/FONT]
[FONT=r_ansi]2. Match a user number[/FONT]
[FONT=r_ansi]3. Match a range of user numbers[/FONT]

[FONT=r_ansi]Q. Return to main menu[/FONT]

[FONT=r_ansi]Enter your selection: 1[/FONT]


[FONT=r_ansi]Transaction Control:[/FONT]
[FONT=r_ansi]Usr Name Trans Login Time R-comm? Limbo? Crd? Coord Crd-task[/FONT]
[FONT=r_ansi]14 jamaly 1222640510 11/01/11 15:33 no no no 0 [/FONT]

[FONT=r_ansi]RETURN - repeat, U - continue uninterrupted, Q - quit: [/FONT]


Even after 10 min that transaction is still active.

 

[RealHeavyDude]

You issue is buffer scope. Never use the same buffer which you use to fetch the records outside of the transaction for updating the database (or a FIND EXCLUSIVE-LOCK) because doing so will extend the buffer scope to the most outer block in which it is first referenced - which, in your case, is your whole procedure. You should use a named buffer for doing the transaction against the database. Something like this (coded in FireFox IE, therefore not syntax checked) should do:

DEFINE BUFFER b_myTable for myTable.

FIND myTable NO-LOCK WHERE ... NO-ERROR.

IF AVAILABLE THEN DO FOR b_myTable TRANSACTION:
FIND b_myTable EXCLUSIVE-LOCK WHERE ROWID ( b_MyTable ) = ROWID ( myTable ).
/* Stuff to update the record */
END.

Please be aware that a DO block does not have scoping capabilities for buffer and transaction unless you explicitly code it using strong buffer scoping and the TRANSACTION keyword.

Heavy Regards, RealHeavyDude.

 

[ymjamal]

I replaced by this code with same result.

[FONT=r_ansi][FONT=r_ansi] define buffer bgen_loc for gen_loc.
find first gen_loc
where gen_loc.entity = ""
and gen_loc.loc = "01" no-lock no-error.
if available gen_loc then do for bgen_loc transaction:
find bgen_loc where recid(bgen_loc) = recid(gen_loc)
exclusive-lock no-error.
if not available bgen_loc then
message "???" view-as alert-box.
else
update bgen_loc.add1.
/* and the user leaves at this point */
end.


[/FONT][/FONT]

 

[LarryD]

You could always do it with a temp table, but there are other considerations necessary when doing this method (e.g. another user updates the same record at the same time). You'd have to do some additional work to insure data integrity.

and yes, I know the pitfalls/dislike by some of the "like dbtable" in the def temp-table statement . ;-)

Quick and dirty code:

[FONT=r_ansi][SIZE=2][FONT=r_ansi][SIZE=2]define buffer bgen_loc for gen_loc.
define temp-table tt_gen_loc like gen_loc no-undo.

find first gen_loc
     where gen_loc.entity = ""
       and gen_loc.loc = "01" no-lock no-error.
if available gen_loc then do for bgen_loc transaction:
   create tt_gen_loc.
buffer-copy gen_loc to tt_gen_loc.
update tt_gen_loc.add1.
/* if user leaves at this point, nothing happened */
find bgen_loc where recid(bgen_loc) = recid(gen_loc)
                 exclusive-lock no-error.
   if not available bgen_loc then
      message "???" view-as alert-box.
   else
      assign bgen_loc.add1 = tt_gen_loc.add1..
end.
empty temp-table tt_gen_loc.

[/SIZE][/FONT][/SIZE][/FONT]

 

[ymjamal]

Thanks LarryD,
That would means re-writing the software. Which is not an option for me. The piece of code that I used was just to ilustrate my predicament.
What I'm looking for is a method of desconecting an user and terminating a lock (and by rolling back transactions), so that another process (batch) waiting to acquire lock does not die after 30 min of wait.
In my specific case, this batch wrapper process updates order, customer, shipment and other tables (which I am not aware of). In this batch process I already get these tabels with exclusive lock and if I can't, I postpone the processing of that transaction with an email to concerned parties.
What has happned is other tables where locked and this then caused the batch process to terminate.
If I do not find a solution I'll have to find which other tables can this process need and deal with them and hope that I do not miss any.

 

[SergioC]

I've not tried, but maybe work fine.
Client Startup Parameter
-lkwtmo 90 (in seconds)

KB-16073

When you need disconnect the user, use "proshut" and check for releases the lock in 90 seconds.

Regards.

 

[TomBascom]

Is the problem in your test code? Or in the batch process? I think you have only shown test code for one half of the problem.

define buffer bgen_loc for gen_loc.
find first gen_loc where gen_loc.entity = "" and gen_loc.loc = "01" no-lock no-error.
if available gen_loc then
  do for bgen_loc transaction:
    find bgen_loc where recid(bgen_loc) = recid(gen_loc) exclusive-lock no-error.
    if not available bgen_loc then
      message "???" view-as alert-box.
     else
      update bgen_loc.add1.
      /* and the user leaves at this point */
  end.

What do you mean by "and the user leaves"??? Are you saying that the user gets up and goes to lunch? Or that a lock conflict arises? Or that you disconnect the user at that point?

In any event... you have an UPDATE statement inside a block with the TRANSACTION property. You are, therefore, mixing blocking IO with a databases transaction. That is another huge no-no. Maybe it is "just test code" and you would never do that in real life. But, if so, it is not a test of your real situation. And if it is a valid test it is yet another big problem.

Proper buffer scoping and lock handling has to be handled on both sides of the equation. You cannot fix these things by only changing one of them.

-lkwtmo will change the amount of time that it takes for a session to give up on waiting. The session will then undo the transaction and terminate. But you said that you do NOT want the session to terminate and die (after 30 minutes). -lkwtmo will simply reduce 30 minutes to 1 minute (or whatever). The session will still die.

 

[ymjamal]

Tom, thanks for your input.
My problem is not with the test code, that is just to illustrate the situation (only one side of it).
My problem is when a user startes an update to a shipment record and then leaves the desk (could be for lunch or even for the night). These are remote user that connect via TCP so it could be that the communation line has dropped or the user does not sign off properly, turn the pc off without leaving the appication etc.
Later a batch process (sonic shipment transactions being processed by a wrapper) needs to lock that record and after waiting 30 min (our default lock wait time) disconnects.
Yes, I have only shown half of the problem, the other half is the batch process that waits for the lock 30 min and then dies.
I have written a process that would run every 10 min and by querying the lock tables would send an email to the users that is locking a transaction for which the batch job was waiting.
If in the next cycle (after 10 min), the same user was locking the same record I would diconnect that user. All that works OK but the lock is not released.
Main aim is to disconnect the user session (leting progress backout his transaction) and let the batch job proceed.
This happens once every six months. May be I should live with it. It would be very expensive to rewrite the sales order system.

I was hopping that there was something I was doing wrong when disconnecting the user.

Thanks

 

[RealHeavyDude]

It appears to me that the "real" problem is that the application uses a pessimistic locking strategy where records are grabbed with an EXCLUSIVE-LOCK as soon as the user attempts to update a record. What you describe is the classical behavior of such an application. Users lock record and keep the lock unintentionally just because they leave without pressing the save or cancel button causing other processes to wait for that records and finally die if the users don't release the lock in time.

You can try to discipline your users, but, out of experience I can tell you this won't work for long. How should it? How are user supposed to know that the application has bad manners and how to avoid them causing problems? The only real solution, although this advise won't help you in your situation, is to introduce an optimistic locking strategy into your application where records only get locked when users save updates for as long as it takes to write this updates to the database. IMHO, pessimistic locking is an ancient strategy that has no place in a modern application.

Heavy Regards, RealHeavyDude.

 

[rzr]

I agree with RHD. Do away with the bad programming logic !!
If this is only one specific program - should'nt be *too* much of an effort coding + testing it...
you would have *spent* an equal amount of time - working on work around.. that will sooner or later.. well you know... so....
fix the root cause... !!

 

[ymjamal]

Agree 100%.

 

[casorohi]

Hi I also faced the same issue twice on OE 10.2B03/linux and the incident happened on two different DBs, where after disconnecting the user through promon the lock is not clearing.
The incident was not in version 9, once we migrated to OE102B03.B it pops up. Even we terminate the server to get lock release but it didn’t work. At end to release the locks I have to shut down the DB, even this is issue also reported to progress corporation but concrete solution L, they update us they are not able to stimulate the scenario.
Hi I also faced the same issue twice on OE 10.2B03/linux and the incident happened on two different DBs, where after disconnecting the user through promon the lock is not clearing.
The incident was not in version 9, once we migrated to OE102B03.B it pops up. Even we terminate the server to get lock release but it didn’t work. At end to release the locks I have to shut down the DB, even this is issue also reported to progress corporation but concrete solution L, they update us they are not able to stimulate the scenario.
Thanks

 

[ymjamal]

Thanks casorohi.

The following may explain why Progress Corporation could not replicate the scenario:

If the locking process is by userid 'dbadmin', then, when disconecting the user releases the lock.

 

[TomBascom]

Perhaps you could elaborate? I'd be especially interested to know what "concrete solution L" is.

I'm not seeing any explanation in either of the last two posts. Just some vague assertions that a hard to parse problem related to record locks that the reporting parties don't think should exist might be occurring.

Terminating servers does not correspond to disconnecting users and it would not, by itself, be expected to release any locks. (Of course that might depend a bit on what you mean by terminating a server and just what actions you take to accomplish that feat...) I'd be curious to know what you mean by "terminate the server" and what steps you take to do so.

Disconnecting a user is a very specific process and is unrelated to terminating a server. If it succeeds (just selecting it from the menu is not the same as success) then all of the locks held by the user will be released. Various entries will be written to the .lg file showing that the process has been disconnected and that any associated transactions have been rolled back.

One or both of you (casorohi and ymjamal) seem to be saying that you have seen situations where a user was properly, correctly and successfully disconnected and yet some of that user's locks remained. This certainly isn't common. If it happens at all it is a bug and a fairly serious one at that. It should be fairly simple to provide an extract of the .lg file to verify that the user was properly disconnected. A PROMON screenshot showing that the user still has locks would then back up the allegation that this misbehavior is really happening.

A much simpler explanation is that your "disconnect" process has not been adequately described and that you are doing something to interfere with proper cleanup of the process.

 

[ymjamal]

What I mean:
I signed on the UNIX box as 'dbadmin', and connected to the DB as 'dbadmin' and run the following code from pregress editor:
[FONT=r_ansi]
find first gen_loc[/FONT]
[FONT=r_ansi]where gen_loc.entity = ""[/FONT]
[FONT=r_ansi]and gen_loc.loc = "01" no-lock no-error.[/FONT]
[FONT=r_ansi]if available gen_loc then do transaction:[/FONT]
[FONT=r_ansi]find current gen_loc exclusive-lock no-error.[/FONT]
[FONT=r_ansi]if not available gen_loc then[/FONT]
[FONT=r_ansi]message "???" view-as alert-box.[/FONT]
[FONT=r_ansi]else[/FONT]
[FONT=r_ansi]update gen_loc.add1.[/FONT]
[FONT=r_ansi]/* and the user leaves at this point */[/FONT]
[FONT=r_ansi]end.[/FONT]

When I disconnect this user via promon option 8, the lock is released.

If Progress Corporartion is doing the test using 'dbamin' they would not be able to simulate this scenario.

I also tried to signon as plain user, say <abc>, then disconnect from another session of user <abc>, that did not release the lock.

My posting of Nov 1st has a screen log that shows then user disconnected and the lock still on.

I have asked our data base administrator to contact Progress for resolution.

Thanks

 

[TomBascom]

What I mean:
I signed on the UNIX box as 'dbadmin', and connected to the DB as 'dbadmin' and run the following code from pregress editor:
[FONT=r_ansi]
find first gen_loc[/FONT]
[FONT=r_ansi]where gen_loc.entity = ""[/FONT]
[FONT=r_ansi]and gen_loc.loc = "01" no-lock no-error.[/FONT]
[FONT=r_ansi]if available gen_loc then do transaction:[/FONT]
[FONT=r_ansi]find current gen_loc exclusive-lock no-error.[/FONT]
[FONT=r_ansi]if not available gen_loc then[/FONT]
[FONT=r_ansi]message "???" view-as alert-box.[/FONT]
[FONT=r_ansi]else[/FONT]
[FONT=r_ansi]update gen_loc.add1.[/FONT]
[FONT=r_ansi]/* and the user leaves at this point */[/FONT]
[FONT=r_ansi]end.[/FONT]

When I disconnect this user via promon option 8, the lock is released.

As we have previously discussed that can only be half of what you are really doing. There must be some other bit of code which is originally locking the record. I do not think that you have posted the other half yet.

None the less -- this part of things all seems to be working as expected and I don't think that you are complaining about it.

If Progress Corporartion is doing the test using 'dbamin' they would not be able to simulate this scenario.

Something doesn't make sense. Why would you want PSC to simulate (duplicate?) this scenario? According to your statements above, this scenario works. You disconnect the user and the lock gets released. There is nothing to be done and you are not complaining about this.

Or did you leave "not" out of "When I disconnect this user via promon option 8, the lock is not(?) released."

I also tried to signon as plain user, say <abc>, then disconnect from another session of user <abc>, that did not release the lock.

Is "dbadmin" a privileged user?

My posting of Nov 1st has a screen log that shows then user disconnected and the lock still on.

It shows that you went through the steps of disconnecting the user. It does not show the .lg file entries that confirm that the user was actually disconnected cleanly and that any associated transaction has been rolled back nor does it show any PROMON screens that would confirm the user was disconnected.

You then show that the lock is still active.

The first thing that I would do at that point is to confirm that the user was really disconnected. I would then check the .lg file to confirm that any active transaction associated with that disconnection has been completely rolled back.

I have asked our data base administrator to contact Progress for resolution.

Does your DBA have a better description of the problem to be resolved?

This thread is full of self-contradicting and incomplete descriptions of the problem.