Doug,
As Brian mentioned, a group lock is asserted to maintain integrity of the
group while the group is being updated, as the order of the items within
group may change due to deletes and changes.
Here is generic routine I use to perform a readu and resolve who has the
record locked - and send them a message. Note the part when I execute
LIST.READU and parse the results to get the user that has the record locked.
/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006
----- start basic
SUBROUTINE PC.READU(RESULT,FILEVAR,ID,ATTRIBUTE,ERR,POS)
* standardized subroutine to read item or attribute & handle locks
* universe version
* like READU RESULT FROM FILEVAR,ID ELSE ERR = 1 if ATTRIBUTE is null or
zero
* else READVU RESULT FROM FILEVAR,ID,ATTRIBUTE ELSE ERR = 1
* POS is column number to start msg display on current line of screen
BELL = CHAR(7)
CLR = @(-4)
ERR = 0
DONE = 0
TRIES = 0
RESULT = ""
WAIT = 10
T = TIME()
IF NOT(POS MATCHES "1N") AND NOT(POS MATCHES "2N") THEN POS = 0
IF ATTRIBUTE EQ "" THEN ATTRIBUTE = 0
*
LOOP UNTIL DONE OR ERR DO
IF NOT(ATTRIBUTE) THEN
READU RESULT FROM FILEVAR,ID LOCKED GOSUB 1000 THEN DONE = 1 ELSE ERR =
1
END ELSE
READVU RESULT FROM FILEVAR,ID,ATTRIBUTE LOCKED GOSUB 1000 THEN DONE = 1
ELSE ERR = 1
END
REPEAT
IF TRIES THEN PRINT @(POS):CLR:
RETURN
1000 *
IF MOD(TRIES,WAIT) EQ 0 THEN
PORT = STATUS() ;* after readu
IF PORT NE "" THEN X = " USER ":PORT ELSE X = ""
EXECUTE "LIST.READU":X CAPTURING LIST.READU.TXT
USER = "?"
MAX = DCOUNT(LIST.READU.TXT,@AM)
FOR N = 4 TO MAX
L = TRIM(LIST.READU.TXT<N>)
IF FIELD(L," ",9) EQ ID THEN
USER = FIELD(L," ",8)
DATA "please unlock record '":ID:"'"
EXECUTE "MESSAGE ":USER CAPTURING XXX
EXIT
END
NEXT N
IF TRIES EQ 0 THEN
WAITED = ""
END ELSE
WAITED = OCONV(TIME()-T,"MTS")
IF WAITED[1,2] EQ "00" THEN WAITED = WAITED[4,5]
WAITED = " (":WAITED:")"
END
* make sure text msg does not wrap to next line
TXT = "Record '":ID:"' is locked by user ":USER:WAITED
LEN = LEN(TXT)
TOT.LEN = LEN + POS + WAIT
IF TOT.LEN GT 79 THEN TXT = TXT[1,(LEN-(TOT.LEN-79))]
PRINT BELL:@(POS):CLR:TXT:
END
TRIES += 1
SLEEP 1
PRINT ".":
RETURN
---- end basic
On Thu, Jun 19, 2008 at 9:51 AM, doug chanco <[EMAIL PROTECTED]> wrote:
> 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/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
