Sorry, but there has been no progress on this issue. The problem is that (as far as I am aware), Microsoft doesn't provide the means to discover the information, and so we can't provide it.

There is a work-around for this.
How many users do you have?

The customer has 40 users.
Is there a limitation for your solution ?

It is a while since I did it, and I need to find all the .BAT files that enabled the work-around.
In the meantime, just so you know where I am going. . . . . . :
I assume you want to terminate a process that is holding a lock for a long time?
I could not identify the PID but I could identify the WRUN32 processes that were not using CPU time.
(a looping .BAT file that got the info and continuously updated a cobol data file). I was also able to identify a user for that process, and had a database of user cell-numbers which I could programmatically SMS.
Using these tools, idle users were requested to logout.
Thereafter I could build a .BAT file to terminate the remaining idle processes.
I used tools from "Windows Sysinternals Suite" which you can download.
Does this sound at all helpful? Should I see what I can find in the dark recesses of my life? :)
I also toyed around with copying   WRUN32   to   WRUN32-UserName   for each user, to help identification

There is another way which I found very convenient because I use a code generator which would automatically include a snippet of code that I could trigger for all, or specifically troublesome files.
Update a record keyed on file name and primary key whenever a user acquires a lock on a record of a file; record that users name.
Another user encountering a lock can read the "current locks" and identify the user holding the lock. No need to update when the first user releases the lock because then the record would no longer be locked, removing the need to read the "current locks."

Use in conjunction with the utilities I referred to earlier, or simply Task Manager to get/terminate a PID 

Hi Peter,

sorry for the late reply. We're quite busy with the new customer.

However, we've decided to resolve the issue with an indexed file, as you suggested.
Thanks for your input!