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: [email protected] 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 [email protected] 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 [email protected] To unsubscribe please visit http://listserver.u2ug.org/
