Re: [U2] group locks and user nbr's

2008-06-24 Thread T Stokes
This is a version of an expanded LIST.READU  EVERY.
It changes the pid for the user name. Slight modifications can be made to
use replace the inode with the file name.

  PID.ARRAY = '' ; ID.ARRAY = ''
  EXECUTE LISTU CAPTURING EXEC.LINE.OUT
  HEADER.LINE1 = TRIM(EXEC.LINE.OUT2)
  HEADER.LINE2 = EXEC.LINE.OUT4
  FOR A = 1 TO DCOUNT(EXEC.LINE.OUT,@AM)
 LINE = TRIM(EXEC.LINE.OUT )
 DISPLAY.LINE = EXEC.LINE.OUT 
 IF FIELD(LINE,' ',1) = * THEN
PID = FIELD(LINE,' ',3)
ID = FIELD(LINE,' ',4)
ID = FIELD(ID,\,2)
 END ELSE
PID = FIELD(LINE,' ',2)
ID = FIELD(LINE,' ',3)
ID = FIELD(ID,\,2)
 END
 LOCATE PID IN PID.ARRAY SETTING PID.POS ELSE
PID.ARRAY = INSERT(PID.ARRAY,PID.POS,0,0,PID)
ID.ARRAY = INSERT(ID.ARRAY,PID.POS,0,0,ID)
 END
  NEXT A
  EXECUTE LIST.READU EVERY CAPTURING EXEC.LINE.OUT
  NUM.OF.LINES = DCOUNT(EXEC.LINE.OUT,@AM)
  FOR A = 1 TO NUM.OF.LINES
 LINE = EXEC.LINE.OUT 
 TRIM.LINE = TRIM(LINE)
 IF NUM(TRIM.LINE[1,1]) THEN
USER.ID = FIELD(TRIM.LINE, ,4)
LOCATE USER.ID IN PID.ARRAY SETTING PID.POS THEN
   NAME = ID.ARRAYPID.POS
END ELSE
   NAME = USER.ID
END
LINE = CHANGE(LINE, :USER.ID: , :FMT(NAME,'20L'): )
 END
 PRINT LINE
  NEXT A


Doug Chanco wrote:
 
 Hey all,
 Can someone please help me understand the differences between group 
 locks and record locks?  Also are high user numbers (Userno below) 
 indicative of a phantom process?
 
 
 *Active Record Locks:
 Device Inode  Netnode Userno  Lmode   Pid Login Id Item-ID.
3080194   38458010137   6 RU 32694 crumjo   61570..5
 
 Active Group Locks:Record Group 
 Group Group
 Device Inode  Netnode Userno  Lmode G-Address.  Locks ...RD 
 ...SH ...EX
30801943289350 53   1 RD935D800  0 1 
 0 0
 
3080194389951   27  63180   2 RD E17000  0 1 
 0 0
 
 *
 one last question is there an easier way than finding out the file 
 associated with the inode and then doing a fuser on that file to find 
 out what is accessing the file?  For example I would like to know 
 who/what is holding this group lock
 
 * 3080194389951   27  63180   2 RD E17000  0 1 
 0 0
 
 *yet all I have is an inode and a userno of 63180 DOING a LISTU does NOT 
 show anything with that userno
 
 any and all assistance appreciated!
 
 thanks,
 dougc
 
 
 
  *
 *
 ---
 u2-users mailing list
 u2-users@listserver.u2ug.org
 To unsubscribe please visit http://listserver.u2ug.org/
 
 

-- 
View this message in context: 
http://www.nabble.com/group-locks-and-user-nbr%27s-tp18010061p18093258.html
Sent from the U2 - Users mailing list archive at Nabble.com.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] group locks and user nbr's

2008-06-23 Thread Nancy Fisher

I like to know what worked...

Nancy Fisher
Peninsula Truck Lines, Inc
Auburn, Washington
253/929-2040
Visit our Website www.peninsulatruck.com
[EMAIL PROTECTED]
- Original Message - 
From: Dave Taylor [EMAIL PROTECTED]

To: u2-users@listserver.u2ug.org
Sent: Thursday, June 19, 2008 3:00 PM
Subject: RE: [U2] group locks and user nbr's



Doug,

I vote for  snip-the-msg-and-say-thanks.

Dave Taylor
Sysmark Information Systems, Inc.
Authorized IBM Business Partner
49 Aspen Way
Rolling Hills Estates, CA 90274
(O) 800-SYSMARK (800-797-6275)
(F) 310-377-3550
(C) 310-561-5200
www.sysmarkinfo.com
- Original Message - 
From: Doug Chanco [EMAIL PROTECTED]

To: u2-users@listserver.u2ug.org
Sent: Thursday, June 19, 2008 12:08 PM
Subject: RE: [U2] group locks and user nbr's

snip
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] group locks and user nbr's

2008-06-20 Thread Bill Haskett
I was just going to add I think UniData has the STATUS() function.  So I test 
locks
like:

** Read vendor  route selection
READU VREC FROM APVENDOR, VENDNO LOCKED
   LOCK.SW= 1
   FileString = NULL$
   LogFlag= NULL$
   CALL LOCK.MSG (FileString, LogFlag, LockMsg) ; LockMsg :=  Press [Enter].


Then the locking subroutine looks like:

SUBROUTINE LOCK.MSG ( FileString, LogFlag, LockMsg )
*
** Get user# who has the lock
PIBS.ID = STATUS() ; ** U2 version
*
** Initialize what's locked
IF Filestring NE NULL$ THEN
  MSG1 = FileString: LOCKED by 
END ELSE
  MSG1 = Record LOCKED by 
END
*
** Figure out who has the record locked
LOCK.ID   = PIBS.ID; ** U2 version
LOCK.NAME = GETUSERNAME(PIBS.ID)   ; ** UD version
*LOCK.NAME = CALL GET.USERS(PIBS.ID); ** UV version
*
** Assign the message to return
LockMsg = MSG1 : LOCK.NAME :  (port#  : PIBS.ID : ).
*
** Create log if requested
IF LogFlag THEN
   CALL LOGMSG ('', '', LockMsg, '')
END
*
RETURN
END

The more I can do within U2 the more portable the code is when I'm using both 
Windows
and Linux.

Bill
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] group locks and user nbr's

2008-06-19 Thread Brian Leach
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

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of doug chanco
 Sent: 19 June 2008 14:18
 To: u2-users@listserver.u2ug.org
 Subject: [U2] group locks and user nbr's
 
 Hey all,
 Can someone please help me understand the differences 
 between group locks and record locks?  Also are high user 
 numbers (Userno below) indicative of a phantom process?
 
 
 *Active Record Locks:
 Device Inode  Netnode Userno  Lmode   Pid Login Id 
 Item-ID.
3080194   38458010137   6 RU 32694 crumjo   61570..5
 
 Active Group Locks:Record Group 
 Group Group
 Device Inode  Netnode Userno  Lmode G-Address.  Locks 
 ...RD ...SH ...EX
30801943289350 53   1 RD935D800  0 
 1 
 0 0
 
3080194389951   27  63180   2 RD E17000  0 
 1 
 0 0
 
 *
 one last question is there an easier way than finding out the 
 file associated with the inode and then doing a fuser on that 
 file to find out what is accessing the file?  For example I 
 would like to know who/what is holding this group lock
 
 * 3080194389951   27  63180   2 RD E17000  0  
1 
 0 0
 
 *yet all I have is an inode and a userno of 63180 DOING a 
 LISTU does NOT show anything with that userno
 
 any and all assistance appreciated!
 
 thanks,
 dougc
 
 
 
  *
 *
 ---
 u2-users mailing list
 u2-users@listserver.u2ug.org
 To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] group locks and user nbr's

2008-06-19 Thread Martin Phillips

Hi Doug,

Record locks protect your data records. Group locks protect the internal 
pointers within the file.


A user program cannot directly get or release group locks but they come and 
go automatically under the covers.


Group locks are of three types:

WR (write): very much like a READU, this allows a user exclusive access to 
the group to perform an update. It is held for a brief moment while UV 
passes data to Unix to write.


RD (read): similar to a READL, any number of users can hold the same RD lock 
at one time but no other user can own the WR lock while this is active. RD 
locks are held while reading a group from the file.


IN (informational): Not really a lock at all. This is simply a counter of 
how many record locks there are in the group and is used to improve 
performance.


Note that there is an oddity in UV that I have never understood properly. 
The query processor holds an RD lock when it is on the Press any key to 
continue prompt. If someone tries to write the the locked group, their 
process will hang until the user moves on to the next page. To partially 
ease this situation, the query processor will release the RD lock after five 
minutes (configurable with PAKTIME) and get it again when continuing from a 
long wait. Quite why it holds a lock that it can get back anyway is a 
mystery to me.



Yes, high user numbers are phantom processes.

one last question is there an easier way than finding out the file 
associated with the inode and then doing a fuser on that file to find out 
what is accessing the file?


If you routinely use ACCOUNT.FILE.STATS to analyse your system, this records 
inode numbers in its data file and is quite a useful reference. I have 
sometimes used a simple program that scans the VOC and builds a database of 
file inode values.



Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200 
---

u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] group locks and user nbr's

2008-06-19 Thread Kishor Parmar
We used to have a xref file to hold a list of I-nodes and the file name.
As Brain rightly states on a *nix system you can use a ls -ip | sort -k 1,1n 
command or ls -ip | sort +0 -1 -n

For windows we would run the Hamilton C shell so we could shell out and perform 
*nix command in a windows environment. The command we would run is ls -1F | sort

We would then wrap the LIST.READU command so it displayed the filename, record 
id, login id, extn no etc



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Brian Leach
Sent: 19 June 2008 15:13
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] group locks and user nbr's


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

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of doug chanco
 Sent: 19 June 2008 14:18
 To: u2-users@listserver.u2ug.org
 Subject: [U2] group locks and user nbr's
 
 Hey all,
 Can someone please help me understand the differences 
 between group locks and record locks?  Also are high user 
 numbers (Userno below) indicative of a phantom process?
 
 
 *Active Record Locks:
 Device Inode  Netnode Userno  Lmode   Pid Login Id 
 Item-ID.
3080194   38458010137   6 RU 32694 crumjo   61570..5
 
 Active Group Locks:Record Group 
 Group Group
 Device Inode  Netnode Userno  Lmode G-Address.  Locks 
 ...RD ...SH ...EX
30801943289350 53   1 RD935D800  0 
 1 
 0 0
 
3080194389951   27  63180   2 RD E17000  0 
 1 
 0 0
 
 *
 one last question is there an easier way than finding out the 
 file associated with the inode and then doing a fuser on that 
 file to find out what is accessing the file?  For example I 
 would like to know who/what is holding this group lock
 
 * 3080194389951   27  63180   2 RD E17000  0  
1 
 0 0
 
 *yet all I have is an inode and a userno of 63180 DOING a 
 LISTU does NOT show anything with that userno
 
 any and all assistance appreciated!
 
 thanks,
 dougc
 
 
 
  *
 *
 ---
 u2-users mailing list
 u2-users@listserver.u2ug.org
 To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


-
**
The contents of this e-mail are subject to contract in all cases
and
William Hill PLC, its subsidiaries or affiliates make no
contractual
commitment save where confirmed by hard copy.

The contents of this e-mail do not necessarily represent the views
of William Hill PLC, its subsidiaries or affiliates. We accept no
liability, including liability for negligence, in respect of any
statement in this e-mail.

This e-mail and any files transmitted with it are confidential,
may
be subject to legal privilege and intended solely for the use of
the
individual or entity to which they are addressed. If you are not
the
intended recipient, you are hereby notified that any use or
dissemination of this communication is strictly prohibited. If you
have received this e-mail in error, please notify us immediately,
then delete this e-mail.

Please note that William Hill can accept no responsibility for
viruses and it is your responsibility to scan any emails and their
attachments.

This message was from William Hill PLC whose registered office is
Greenside House, 50 Station Road, Wood Green, London N22 7TP.
Company Registration Number: 4212563 England.
*
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] group locks and user nbr's

2008-06-19 Thread doug chanco
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
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] group locks and user nbr's

2008-06-19 Thread Brian Leach
Doug

 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?
 
A group in a file contains pointers between records and pointers to overflow
groups. So the group lock is there to ensure that no process can be changing
those pointers whilst another is coming along trying to eiterh read through
them or to write to the group. By doing this at the group level it means
that file integrity is perserved whilst at the same time ensuring that
multiple processes can still write (different groups within) the file at the
same time. So no, the whole file is not locked.

It's another reason to keep files well sized though since the group lock is
set on the primary group, so if you have long overflow chains that increases
contention on the lock table.

Brian 
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] group locks and user nbr's

2008-06-19 Thread Doug Chanco
Thanks!

Dougc

Ps

One other question (not related to locking).  I always think it's polite
to say thanks after getting good info from users on this list but I also
hate to increase email volume with a reply of thanks.

So is it better to not reply when you have the info you need (but assume
the person who replied knows that your grateful) or better to let the
person know you appreciate their taking the time to respond?  I want to
be grateful but at the same time not flood the list with thanks for the
info emails ...


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Phillips
Sent: Thursday, June 19, 2008 10:42 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] group locks and user nbr's

Hi Doug,

Record locks protect your data records. Group locks protect the internal

pointers within the file.

A user program cannot directly get or release group locks but they come
and 
go automatically under the covers.

Group locks are of three types:

WR (write): very much like a READU, this allows a user exclusive access
to 
the group to perform an update. It is held for a brief moment while UV 
passes data to Unix to write.

RD (read): similar to a READL, any number of users can hold the same RD
lock 
at one time but no other user can own the WR lock while this is active.
RD 
locks are held while reading a group from the file.

IN (informational): Not really a lock at all. This is simply a counter
of 
how many record locks there are in the group and is used to improve 
performance.

Note that there is an oddity in UV that I have never understood
properly. 
The query processor holds an RD lock when it is on the Press any key to

continue prompt. If someone tries to write the the locked group, their 
process will hang until the user moves on to the next page. To partially

ease this situation, the query processor will release the RD lock after
five 
minutes (configurable with PAKTIME) and get it again when continuing
from a 
long wait. Quite why it holds a lock that it can get back anyway is a 
mystery to me.


Yes, high user numbers are phantom processes.

 one last question is there an easier way than finding out the file 
 associated with the inode and then doing a fuser on that file to find
out 
 what is accessing the file?

If you routinely use ACCOUNT.FILE.STATS to analyse your system, this
records 
inode numbers in its data file and is quite a useful reference. I have 
sometimes used a simple program that scans the VOC and builds a database
of 
file inode values.


Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200 
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

-- 
This message has been scanned for viruses and
dangerous content by SecureMail, and is
believed to be clean.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] group locks and user nbr's

2008-06-19 Thread Louie Bergsagel
I don't know if this is very elegant, but it matches up the record lock with
a user name:

0020   LOOP
0021  LOOP.COUNTER += 1
0022 *DISPLAY LOOP.COUNTER
0023  IF LOOP.COUNTER GT 100 THEN EXIT
0024  TRY.AGAIN = 
0025  READVU FIELD1 FROM VOC.FILE,VOCLIB,1 LOCKED
0026 USER.NO.WITH.LOCK = STATUS()
0027 EXECUTE LIST.READU CAPTURING LIST.READU.ARRAY
0028 LIST.READU.COUNT = DCOUNT(LIST.READU.ARRAY,@FM)
0029 FOR LIST.READU.CTR = 1 TO LIST.READU.COUNT
0030USER.NO = FIELD(TRIM(LIST.READU.ARRAYLIST.READU.CTR),
,4)
0031IF USER.NO.WITH.LOCK = USER.NO THEN
0032   LOGIN.ID =
FIELD(TRIM(LIST.READU.ARRAYLIST.READU.CTR), ,8)
0033   ITEM.ID =
FIELD(TRIM(LIST.READU.ARRAYLIST.READU.CTR), ,9)
0034   ERROR.DISPLAY = User :USER.NO.WITH.LOCK: :
LOGIN.ID: has the ITEM.ID of :ITEM.ID: locked.
0035   ERROR.DISPLAY.LENGTH = LEN(ERROR.DISPLAY)
0036   DISPLAY STR(-,ERROR.DISPLAY.LENGTH)
0037   DISPLAY User :USER.NO.WITH.LOCK: :LOGIN.ID: has
the ITEM.ID of :ITEM.ID: locked.
0038   DISPLAY STR(-,ERROR.DISPLAY.LENGTH)
0039   DISPLAY LIST.READU.ARRAY2
0040   DISPLAY LIST.READU.ARRAY3
0041   DISPLAY LIST.READU.ARRAYLIST.READU.CTR
0042END
0043 NEXT LIST.READU.CTR
0044 DISPLAY
0045 DISPLAY Would you like to try again? :
0046 INPUT TRY.AGAIN
0047 TRY.AGAIN = UPCASE(TRIM(TRY.AGAIN)[1,1])
0048 IF TRY.AGAIN NE Y THEN GO END.PROGRAM
0049  END THEN
0050 IF USER.NO.WITH.LOCK NE '' THEN
0051DISPLAY Lock released.
0052 END ELSE
0053DISPLAY To test this, ED VOC VOCLIB in another
session.
0054 END
0055 EXIT
0056  END
0057   REPEAT
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] group locks and user nbr's

2008-06-19 Thread Scott Ballinger
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.TXTN)
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
 u2-users@listserver.u2ug.org
 To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] group locks and user nbr's

2008-06-19 Thread Dave Taylor

Doug,

I vote for  snip-the-msg-and-say-thanks.

Dave Taylor
Sysmark Information Systems, Inc.
Authorized IBM Business Partner
49 Aspen Way
Rolling Hills Estates, CA 90274
(O) 800-SYSMARK (800-797-6275)
(F) 310-377-3550
(C) 310-561-5200
www.sysmarkinfo.com
- Original Message - 
From: Doug Chanco [EMAIL PROTECTED]

To: u2-users@listserver.u2ug.org
Sent: Thursday, June 19, 2008 12:08 PM
Subject: RE: [U2] group locks and user nbr's

snip
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/