This idea is a result of case TS002735466 and is being opened as recommended by IBM Support.
Currently, there is an undocumented limit of the internal buffers which are managed by DB2 and which are used when processing DISPLAY DB command. When it happens that this buffer limit is reached, it simply does not contain the complete information about some of the restricted objects as those did not fit in. This results in an incorrect view on the system, but also has an impact on DSNACCOX stored procedure execution and processing. DSNACCOX in such case does not know about objects that could qualify for reorg for example even though those are in AREO* redistricted state only because they did not fit into the buffer of internally issued DISPLAY DB(*) SP(*) RESTRICT command.
Why is it useful?
|Who would benefit from this IDEA?||Every administrator and user of DB2|
How should it work?
We propose the solution to be implemented in both areas reported.
1) The internal buffer size should be adjusted to fit as many objects as required and this should go in line with the growing number of allowed objects created in DB2 - we believe this buffer size limit was not correctly adjusted and is just estimated based on very old DB2 version scalability.
2) The DSNACCOX SP should be enhanced to include the specified filtering criteria in CRITERIA clause and display only the limit objects as per for example provided database name etc.
|Priority Justification||No way to identify restricted objects in situation like ours leads to other problems|
NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "firstname.lastname@example.org" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions