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/
