tag:blogger.com,1999:blog-4516533711330247058.post4497536790779521021..comments2024-03-29T05:35:42.451-07:00Comments on Robert's Db2 blog: DB2 for z/OS Data Sharing: the Lock List Portion of the Lock StructureRoberthttp://www.blogger.com/profile/02058625981006623480noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-4516533711330247058.post-50323878645256284842022-12-16T02:24:14.501-08:002022-12-16T02:24:14.501-08:00Understood the split. Thank you very much, Robert....Understood the split. Thank you very much, Robert.Kirthananoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-17473781550445799742022-12-15T19:03:04.328-08:002022-12-15T19:03:04.328-08:00Actually, with a lock structure INITSIZE of 1320 M...Actually, with a lock structure INITSIZE of 1320 MB, my expectation would be a 512 MB lock table and an 808 MB lock list - this because, by default, the system will divide space between the lock table and the lock list so as to get as close to a 50-50 split as possible, given that the lock table size has to be a power of 2. A 512/808 (MB) split between lock table and lock list is a lot closer to 50-50 (for a 1320 MB structure) than a 1024/296 split.<br /><br />So, if you have an 808 MB lock list and it's getting close to full, you just have a whole lot of currently-held X-type global locks in your data sharing system at certain times. That could be due to things such as use of row-level locking and/or to processes that accumulate a large number of global X-type locks between commits. If you dynamically increase the lock structure's allocated size up to the current SIZE limit, all the extra space will indeed go to the lock list.<br /><br />If you want a split of lock structure space that gives more room to the lock list than the default "as close as possible to 50-50" rule, you can specify your own lock table size via the command MODIFY irlmproc, with an LTE specification (through that command option you provide a power-of-two number of lock table entries, and the rest of the lock structure will be used for lock list space).<br /><br />As an alternative to a MODIFY irlmproc command, you can include the same LTE specification in your IRLMPROC.<br /><br />Whether you use a MODIFY irlmproc command with an LTE specification or you change the LTE value in your IRLMPROC, a rebuild of the lock structure would be required to effect the requested change in the split of space between the lock table and the lock list.<br /><br />A couple of useful references in the online Db2 for z/OS documentation are https://www.ibm.com/docs/en/db2-for-zos/12?topic=commands-modify-irlmprocset-zos-irlm and https://www.ibm.com/docs/en/db2-for-zos/12?topic=structure-changing-size-lock-by-rebuilding.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-22285321948033789322022-12-15T04:58:57.988-08:002022-12-15T04:58:57.988-08:00Hi Robert, Thanks for this wonderful explanation a...Hi Robert, Thanks for this wonderful explanation about lock structures. Looking at several links and guides from different places to understand this, it was mind boggling. <br /><br />One question, from the example you mentioned about 327MB for lock structure (128M for lock table and rest 199M for lock list). Is there a chance that it could allocate this as 256M for Lock table and only 71M for Lock list ?<br /><br />Because in my environment, the INITSIZE is 1320M and SIZE is 1660M. And we are getting DXR142E at times. <br />So if I had to increase INITSIZE (considering power of two), it could go to 2048M (which I think is very high). <br />If you can solve my doubt (mentioned in first para), I believe, so far with INITSIZE 1320M, the lock table uses 1024M and only remaining 296M is available for lock list and that is the reason we keep getting DXr170Is and 142Es. In that case, I could just increase 1320M to 1600M (about 20%) and so the lock list has about 576M for it now.<br />Regards,<br />KirthanaKirthananoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-57848935927963689142017-11-01T10:00:22.336-07:002017-11-01T10:00:22.336-07:00Might be a good idea to open a PMR for this issue ...Might be a good idea to open a PMR for this issue with the IBM Support Center.<br /><br />The 0C1C0C17 reason code from MVS IXLLIST indicates that the structure could not be accessed because it is full. If you think that you should not be getting this error (e.g., if you display information about the structure and see that in fact it is not full), one possible cause for the problem could be a SIZE for the structure in the CFRM policy that is more than twice the value of INITSIZE (see info APAR II14807: http://www-01.ibm.com/support/docview.wss?uid=isg1II14807).<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-50176972911640937922017-10-31T07:08:47.581-07:002017-10-31T07:08:47.581-07:00Hi Robert, We are facing issues with rebuilding SC...Hi Robert, We are facing issues with rebuilding SCA when we migrate our DB2 V11 system(on z/OS 2.2) from ENFM to NFM. Reason ABND=04E-00F70601. <br /><br />DSN7508I -DBN1 DSN7LRW1 <br />ACCESS TO THE SCA STRUCTURE DSNDBN0_SCA FAILED.<br /> MVS IXLLIST RETURN CODE = 0000000C, <br /> MVS IXLLIST REASON CODE = 0C1C0C17. <br /><br />Do we have any limitations with the size of SCA as we have only 6MB in our sandbox system and its only 10% used.<br /><br />Thanks,<br />Ram R. Anonymousnoreply@blogger.com