To carry Glenn's response a little further, think of the Group lock table and the READU lock table as comprised of GSEMNUM rows, and GLTABSZ and RLTABSZ columns respectively.
The group lock associated with the READU lock will be in the same row. It is determined by taking the group number plus Inode Number mod GSEMNUM. If you wish to do the hexadecimal math, that would be the group address divided by the group size. The extension to Glenn's remarks comes from considering the implications of the expression MOD(GroupNumberPlusInodeNumber,GSEMNUM). If you take a directory type file, type 1 or 19, or a poorly sized file with a small number (one, for instance) of groups, all of the READU locks fall in one group as far as the GroupNumber calculation is concerned. So if GSEMNUM is 300, and your users collectively attempt to take 301 concurrent READU locks in that file, one will see the "READU threshold exceeded" message. In this case, you would need to raise GLTABSZ; increasing GSEMNUM would not help. Also note that the GSEMNUM entries in the READU lock table are competing with locks in other files. So to find the likely culprit, consider the following contrived example. (Without a lock, you do not get the headers.) If the mail client alters the font from a fixed point font, you can fix it to align it better after the fact. LIST.READU EVERY will show group locks in addition to READU locks. For a particular Device and Inode, you will see a group address, G-Address. For that address you will see a number of Record Locks. One of these will be a large number relative to GSEMNUM. >list.readu EVERY No locks or semaphores active. >ED VOC FRED New record. ----: XEQ LIST.READU EVERY Executing the command "LIST.READU EVERY". Active Group Locks: Record Group Group Group Device.... Inode..... Netnode Userno Lmode G-Address. Locks ...RD ...SH ...EX 1236237959 2098059265 0 1988 45 IN B000 1 0 0 0 Active Record Locks: Device.... Inode..... Netnode Userno Lmode Pid Item-ID.................... 1236237959 2098059265 0 1988 45 RU 1988 FRED ----------------- Returned to the EDITOR from the XEQ command. Top. ----: If this is a hashed file, RESIZE the file to something more appropriate. If it is a directory file, and needs to be one, perhaps for BASIC source or communicating with some other environment, you options will be limited. If two directory type files collide, getting a different inode number could displace them from the same GSEMNUM entry. Glenn Herbert <[EMAIL PROTECTED]> wrote: > Changing FLTABSZ will do nothing for you unless you are setting an > inordinate number of file locks, which, if you are getting the "READU...." > message, then this is not the case. Rather, you should be concerned with > the GSEMNUM value. Think of GSEMNUM as the number of the locking tables, > whereas GLTABSZ and RLTABSZ should be thought of as the number of entries > allowable within each table. > You can increase the size of any of these, though usually there are less > GROUP latches/locks (GLTABSZ) than READU locks (RLTABSZ). Since both are > already set to 300, which is good sized, you may want to consider > increasing the number of locking tables by upping the GSEMNUM value by a > little bit. I don't recall what the universe default value for this is > anymore (it's 97 for DataStage Engine), but you should really only be > limited by the size which you can create your shared memory segment. When > you change GSEMNUM, you then run uvregen, which will fail if you exceed > your maximum shared memory value. Mark A. Baldridge Principal Consultant North American Lab Services DB2 Information Management, IBM Software Group (607) 351-5666 ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
