Thanks for the response! I was more interested in matching a user to a
lock than the file (I have a program that I can call that will return
the file name if you pass it a inode), what I was hoping for was a
better way of figuring out the user, instead of doing the following:
1. convert the inode into a file name
2. do a fuser -u <filename>
3. parse the results of 2 to get the user name
while thats certainly do able I was hoping for a more elegant pick solution.
sorry for not including this earlier but we are on aix 5.2 and universe 10.1
But I am still a little confused on what would set a group lock (I
understand the record locks) and why a group lock would need to be set
and does it lock the entire file?
If we have a pick file called "CONTROL" and there is a group lock on the
CONTROL file what I am curious about would be:
1. why would a group lock be set?
2. does it lock the ENTIRE file?
3. figuring out who set/has the group lock
4. how would it be set (I did not see any reference in the basic manual
about setting group locks)
5. best way to release the lock
thanks again
dougc
Brian Leach wrote:
Doug
To take the first part of your question:
The lock table is used for application locks like READU and READL locks, and
also for synchronisation locks.
The RD and WR locks are synchronisation locks that control access to a group
in a file during a read or write operation. these should be transitory only
lasting milliseconds unless your system is stuffed or badly maintained.
The IN locks are information locks: these are not real locks but point to
the existence of a record lock somewhere in that group, to make for quicker
checking.
The record locks are those from Basic.
As for matching up with inodes that has been discussed here various times
before. If you are on UNIX you can use the ls -lsi command to list the
inodes associated with files if you have a rough idea where it is. You can
use find to locate the file with that inode. Under Windows inodes don't
exist, they are just emulated by UniVerse, so no help there.
Doing an ACCOUNT.FILE.STATS and a LIST.FILE.STATS will show you, but that
does take time: something to run overnight.
That user number could be a background process or a process that has died
part way through a read leaving a lock behind.
Brian
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
