RE: [U2] locking question
I am curious about this also. GSEMNUM is 97 here also with a 117 UV user license on Redhat Linux UV 10.1.12. -Original Message- From: IT-Laure Hansen [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2008 5:43 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] locking question Is the rule of thumb about the value of GSEMNUM valid for other systems? We are running UV 10.2.3 on Win2003 server with a 110 UV user license. Our VAR set GSEMNUM to 97. Is this likely to cause any problems? I hasten to say we have no locking issues on our system. Thanks, Laure Hansen, City of Redwood City Information Technology 1017 Middlefield Road Redwood City, CA 94063 Tel 650-780-7087 Cell 650-207-3235 Fax 650-556-9204 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herve Balestrieri Sent: Tuesday, July 01, 2008 2:12 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] locking question If you are sure that this is a Group lock (of what type ?), you may adjust the UniVerse parameter PAKTIME, which stands for the duration of a Group lock corresponding to the record displayed just before the Press any key to continue... prompt. Reason being for that parameter that when a LIST displays records at a terminal, the item at the bottom may span to the next page which is not yet displayed. If it was possible to update that record while it is displayed, you would see the first part of the record as you picked it, and, after the Press any key to continue if the record is updated by other, the second part may have a chance to be inconsistent with the first part. Other recommendations: - Be sure that you have a GSEMNUM parameter = a prime number larger than the number of users in your UniVerse licence (as a rule of thumb) - Check if the file involved with that Group lock have appropriate sizing : Small files accessed with high frequency are generally neglected and would have proportionally to the number of records a larger modulo than larger files (i.e.: NO files under modulo 11 is a good practice). Hope this will help, Herve Balestrieri Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Sihge Social : Tour Descartes, 2, avenue Gambetta, La Difense 5, 92400 Courbevoie RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 542.737.118 euros SIREN/SIRET : 552 118 465 02430 --- 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] 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/
Re: [U2] locking question
we have a 473 user license of universe and GSEMNUM was 87 so I think we are woefully undersized as far as that parameter goes. Hopefully this will fix our issue and I'll owe you guys (and gals) a HUGE thank you! one question though what exactly is this parameter used for? I am trying to look it up for future reference but if anyone would care to share the for dummies . explanation I would be most appreciative once again thanaks to EVERYONE who responded. dougc --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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/
RE: [U2] locking question
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
Re: [U2] locking question
Hi Doug, has anybody run across/seen an issue where a process sets a lock via READU and then when it tries to write back the record cannot because the record is locked but somehow lost the fact that the process trying to write the record is the process that created the lock? My money (but not too much!) is on this being a group lock problem. As discussed recently on this list, the query processor holds a read group lock on the group it is processing when on the press return to continue prompt. Quite why, I have never worked out. If a program tries to write to this group, it will hang until the user running the query moves on to the next page or until the group lock times out. 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] locking question
I notice you're on nix ... Is the piece of code that writes invoked via an EXECUTE or PERFORM from the code that did the original READU? I wouldn't expect it to on doze, but on Unix that *might* change the execution environment enough to cause a problem... (grasping at straws to see if it gives you any more ideas...) Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of doug chanco Sent: 01 July 2008 15:03 To: u2-users@listserver.u2ug.org Subject: [U2] locking question hey all, has anybody run across/seen an issue where a process sets a lock via READU and then when it tries to write back the record cannot because the record is locked but somehow lost the fact that the process trying to write the record is the process that created the lock? I am not sure if this is even possible but we at are at a loss as to whats causing this lockup (which does not occur regularly but enough that its causing us concerns with our busy season coming around) We had a lock up last night that LIST.READU EVERY showed that that a process was holding a lock and that the same process was failing on a write (in a program) and 'stuck' (yes we have old old old old old code that does not believe in a failure clause or the handling of a write failure). Once I cleared the lock the process continued on its merry way ... Now the obvious things I checked 1. that there were no other users logged in as that particular user (yes they sometimes login multiple times with the same user but we are forcing them to change that) 2. the PID's were indeed the same system info: aix 5.2.6 RELLEVEL 001 X 002 10.1.7 003 PICK 004 PICK.FORMAT 005 10.1.7 any thoughts/suggestions/ideas/etc .. are welcomed! thanks everyone 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] locking question
Thats for the responses Wol and Martin! Wol - the lock and the write are in the same program so there is no execute involved. Martin - I need to look up the archives that previously talked about the query processor holding a group lock but that is exactly the lock we are seeing (a group lock). This is a very promising lead and if its the problem I MAY have to go to where you are and buy you a steak dinner! thanks guys! dougc Martin Phillips wrote: Hi Doug, has anybody run across/seen an issue where a process sets a lock via READU and then when it tries to write back the record cannot because the record is locked but somehow lost the fact that the process trying to write the record is the process that created the lock? My money (but not too much!) is on this being a group lock problem. As discussed recently on this list, the query processor holds a read group lock on the group it is processing when on the press return to continue prompt. Quite why, I have never worked out. If a program tries to write to this group, it will hang until the user running the query moves on to the next page or until the group lock times out. 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/
Re: [U2] locking question
If you are sure that this is a Group lock (of what type ?), you may adjust the UniVerse parameter PAKTIME, which stands for the duration of a Group lock corresponding to the record displayed just before the Press any key to continue... prompt. Reason being for that parameter that when a LIST displays records at a terminal, the item at the bottom may span to the next page which is not yet displayed. If it was possible to update that record while it is displayed, you would see the first part of the record as you picked it, and, after the Press any key to continue if the record is updated by other, the second part may have a chance to be inconsistent with the first part. Other recommendations: - Be sure that you have a GSEMNUM parameter = a prime number larger than the number of users in your UniVerse licence (as a rule of thumb) - Check if the file involved with that Group lock have appropriate sizing : Small files accessed with high frequency are generally neglected and would have proportionally to the number of records a larger modulo than larger files (i.e.: NO files under modulo 11 is a good practice). Hope this will help, Herve Balestrieri Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Sihge Social : Tour Descartes, 2, avenue Gambetta, La Difense 5, 92400 Courbevoie RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 542.737.118 euros SIREN/SIRET : 552 118 465 02430 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] locking question
Is the rule of thumb about the value of GSEMNUM valid for other systems? We are running UV 10.2.3 on Win2003 server with a 110 UV user license. Our VAR set GSEMNUM to 97. Is this likely to cause any problems? I hasten to say we have no locking issues on our system. Thanks, Laure Hansen, City of Redwood City Information Technology 1017 Middlefield Road Redwood City, CA 94063 Tel 650-780-7087 Cell 650-207-3235 Fax 650-556-9204 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herve Balestrieri Sent: Tuesday, July 01, 2008 2:12 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] locking question If you are sure that this is a Group lock (of what type ?), you may adjust the UniVerse parameter PAKTIME, which stands for the duration of a Group lock corresponding to the record displayed just before the Press any key to continue... prompt. Reason being for that parameter that when a LIST displays records at a terminal, the item at the bottom may span to the next page which is not yet displayed. If it was possible to update that record while it is displayed, you would see the first part of the record as you picked it, and, after the Press any key to continue if the record is updated by other, the second part may have a chance to be inconsistent with the first part. Other recommendations: - Be sure that you have a GSEMNUM parameter = a prime number larger than the number of users in your UniVerse licence (as a rule of thumb) - Check if the file involved with that Group lock have appropriate sizing : Small files accessed with high frequency are generally neglected and would have proportionally to the number of records a larger modulo than larger files (i.e.: NO files under modulo 11 is a good practice). Hope this will help, Herve Balestrieri Sauf indication contraire ci-dessus:/ Unless stated otherwise above: Compagnie IBM France Sihge Social : Tour Descartes, 2, avenue Gambetta, La Difense 5, 92400 Courbevoie RCS Nanterre 552 118 465 Forme Sociale : S.A.S. Capital Social : 542.737.118 euros SIREN/SIRET : 552 118 465 02430 --- 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/
