>From the Administering UniVerse 10.2 Guide section is UniVerse Configurable
Parameters Chapter 4-4 has the following information Managing Locks is
Chapter 9.  Link to all 10.2 documentation
http://www-306.ibm.com/software/data/u2/pubs/library/102univ/

FLTABSZ Sets the number of file lock entries in a file lock semaphore set.
The default value is 11.

FSEMNUM Sets the number of file lock semaphore sets used for concurrency
control. The default value is 23.

GLTABSZ Sets the number of group lock entries in a group lock semaphore set.
The default value is 75.

GSEMNUM Sets the number of group lock semaphore sets used for concurrency
control. The default value is 97.

MAXKEYSIZE Specifies the maximum number of characters for a primary key. It
must be any multiple of 64 between 256 and 2048. The full record ID is
stored in the record lock entry. The default value is 255. Do not change
MAXKEYSIZE from the default value without understanding its effect on the
record lock table entries.

MAXRLOCK Sets the maximum number of record locks that can be held by an SQL
transaction on a physical file (a device or ani-node) before a file lock is
requested. The default is 74.

PAKTIME Specifies the number of seconds the system waits at the Press Any
Key to Continue message before releasing a pending group lock. The default
value is 300.

PSEMNUM Sets the number of BASIC user process control locks. The default
value 64.

RLOWNER Sets the number of lock owner entries maintained for shared record
locks in a group semaphore set. The default value is 300.

RLTABSZ Sets the number of update record lock entries in a group lock
semaphore set. The default value is 75.



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brenda Price
Sent: Wednesday, July 02, 2008 9:08 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] locking question

Like the original poster we don't have any locking issues and since it
has been 2-3 years since I took the UV Internals course and about 2
years since the last time I had to change UV settings, I just didn't
remember the GSEMNUM setting default and recommendation.

Our license count was originally less than the GSEMNUM value of 97,
we've slowly added licenses until we got to 117.  We'll have to keep
this in mind the next time we add licenses. Definitely will be something
to look at, if we ever switch to device licensing.

Brenda

-----Original Message-----
From: Martin Phillips [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 02, 2008 9:05 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] locking question

Hi Brenda,

> Is the rule of thumb about the value of GSEMNUM valid for
> other systems?

In my personal opinion (which may be wrong!), the "rule of thumb" is not

right.

UV locking is a very complex topic. It is another good reason to
recommend 
the UniVerse Internals course.

To explain the mechanism briefly, the record lock table has GSEMNUM
rows, 
each of which can hold at most RLTABSZ locks. The group lock table also
has 
GSEMNUM rows but each can hold GLTABSZ locks. Given a big system, the 
chances are that most record locks also require a separate informational

group lock so it usually makes sense that GLTABSZ and RLTABSZ are the
same. 
The two tables always have the same number of rows for reasons that I
won't 
go into here.

The default values are GEMNUM = 97, RLTABSZ and GLTABSZ = 75. That's
7275 
entries in each table.

Now the fun bit....

Let's think only about record locks. A particular record lock can only
ever 
appear on a specific row of the table because the row number is
calculated 
from the file's inode number and the group number within which the
record 
exists. Once we know the row number (this is the mysterious number in
the 
Lmode column of LIST.READU), the system simply scans the row of the
record 
lock table to look for (a) an existing lock on this record, and (b) a
spare 
space.

If the record is already locked, the program takes what ever action is 
defined by the LOCKED clause or lack thereof. If it is not locked and we

find a spare space in the row, we lock the record. If there is no space,

this is handled just like the record being locked - the lock cannot be
moved 
to another row.

This is where it all gets horrible. It is unlikely but technically
possible 
(and easy with contrived demonstration programs) for one row of the
table to 
be full while all the other rows are completely empty. Ultimately, it
all 
comes down to statistics about how your application is likely to use
locks. 
Assuming that it doesn't have some strange pattern about how it locks 
records, or lots of modulo 1 files, I tend to work on the assumption
that 
records will be scattered randomly through the table and you should
expect 
to be able to (guesswork time) about 60% fill the table before the risk
of a 
row becoming full becomes significant.

Sizing the tables is not about how many users you have but about how
many 
concurrent locks you will have. Only you know the answer to this.

The significance of breaking the table into a two dimensional structure
(not 
the only way to do it) is that the search for a lock has at most RLTABSZ

entries to examine. The downside of this is that you can get the problem
of 
a row becomming full.

There are some excellent technical papers about sizing the locking
tables. 
Don't fiddle with the numbers unless you know what you are doing. You
can 
totally destroy performance.

I have neatly avoided group locks in all of this. There has been recent 
discussion on this list about RD and WR group locks. The mysterious 
"informational lock" is a mechanism to improve performance of the lock
seach 
and is nothing more than a count of how many record locks there are in
the 
group.


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/
-------
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/

Reply via email to